| Contracting in software business: Analysis of evolving contract processes and relationships | ||
|---|---|---|
| Prev | Chapter 6. Analysis of software contracting relationships and processes | Next |
Next the contexts where the software companies operate with their customers and partners are briefly discussed. The contextual issues are more extensively analysed in Section 6.4 during the analysis of COTS, tailored and MOTS software development approaches. To facilitate and to follow better the reasoning refer to Fig. 26 “Software contracting process” model. In this section are briefly discussed the supplier and customer context elements found in the conceptual model.
In the model (Fig. 26) building the new contractual approach[1] was seen as a central theme in the development of the contracting practice. This has had reflections on the software contracting as well, as the relational contracting paradigm with the processual approach is tailor-made for the project oriented software development projects in a turbulent and constantly changing environment. The different contracts and the contracting approach clearly manifested the imperative of this kind of contractual approach as it is explicated in Section 6.4.
The issue of information asymmetry emerged strongly in several cases. It could be found in the negotiation situation between a big and small company, where the small company does not have own independent law department. This puts the supplier company in an inferior position with an asymmetric information distribution. This is reflected in all legal issues concerning the contracts and the relevant clauses included in it. However, the asymmetry also expresses itself in the situation between a supplier and customer where the supplier has superior technological know-how. In this case the supplier may even be the smaller partner, but having special proprietary knowledge compared to the customer.
The intellectual property rights (IPR) have emerged as being the most important and central contracting issues and this also explicit came under the study. The IPR with its different modes of employment is still a contradictory issue in software business. In Finland negotiating on copyright issues is not always as easy at it seemed to be in the USA. In Finland the subcontractors unanimously demand the rights to belong to the customer, but in the USA the situation is totally different, their IPR stay with the software producer. However, the situation in Finland is also changing and this has influenced the growing understanding about the importance of the issue and also the template contracts published by the Keskuskauppakamari (2000). IPR matters were found central to draft balanced license agreements with different objectives.
Cooperation on different levels and in different modes is a central theme in software development. Relationship building for software companies is a compelling matter and it has manifestations between software companies as well as between the software companies and their clients. Cooperation is strongly linked to the fast change and development of the whole industry as the technology pushes companies into a constant development circle.
Cultural differences are explicated in more detail in Section 6.4 with several authentic quotations from the discussions with the company managers.
In this study the COTS, tailored and MOTS software business strategies were used as the central viewpoints, as their role was correctly anticipated, see Section 6.4. The question of resource shortage emerged during the discussions in some cases. Instead the usage of different forms of template contracting is in a predominant state in the software business. Innovative solutions with technical complexity are also central issues of the software development process. However, there are large variations. Today though more and more things emerge, that according to the managers nobody really has done before.
Contracting and governance issues are discussed in more detail in Section 6.4. The processual software development approach with project orientation was also clearly visible in the empirical data. Typically for the larger projects the partners establish a steering group together with the project group. Both groups are defined in writing: who the project manager in the software company is, who the developers are, who the customer’s project manager is and developers as well as the contact persons. In some cases the developers are defined on an individual level, as the customer wants specific professionals to work on the project. This is typical project organization.
| [1] | On the following pages the bold font indicates the element to be found in the discussed model or Fig. 29, Fig. 30, Fig. 33. |