Chapter 4. Software contracting model
The model (construct) characterizes the phenomena studied and establishes a specialized language utilizing common knowledge of the discipline under study (March & Smith 1995). March and Smith define the model to be a set of propositions or statements expressing relationships between the constructs that are used to describe the tasks, situations and other artefacts in question to depict and analyse the software contracting process (ibid). The model could only be used to explain how the things are and unfold over time, but the aim is also to give it utility perspective in order to give further ideas about how things should be. March and Smith (ibid) emphasize that design science is in its nature prescriptive, i.e. a knowledge-using activity and it deals e.g. with organizations and information systems. For this purpose the model and taxonomy of Möller and Wilson (1995b) is exploited, as it gives a shared language to discuss the phenomenon appearing in this research context. In compliance with March and Smith’s terms this study first builds constructs and concepts that form the vocabulary of the domain and the focal issue (ibid). This gives the basic toolbox, i.e. the proper language used in the context of the research domain and the existing knowledge of the disciplines in an adequate manner in relation to the study. Using the available concepts the model that expresses the relationships between these concepts is built next.
The chapter starts with analysis and description of the “sub-model” of software development and contracting interaction phases. This model is developed from the prevailing software development models and the model is intentionally designed to be simple and robust. It is subsequently embedded into the Möller and Wilson (1989, 1995b) model of “Dyadic Interaction” to give it the line of business specific expression. This model is used as the base for the “Software contracting process” model that is next developed using the elements and understanding gathered in previous chapters. This elaborated model is subsequently used in the analysis work of the empirical data in the Chapter 6.
4.1. Software development and contracting interaction processes
Section 3.3.2 scrutinized the customer-supplier business process models from Burlton (1995), Scherr (1993) and Ring and Van de Ven (1994). These phase models described the relationship development in a processual manner during one relationship instantiation from its nascent to the fulfilment of agreed obligations. Using the phases described and defined in the above studies the phases for the purposes in the software development environment are defined. The conceptual model shown in Fig. 24 gives a perspective for the processes and interactions, the processual model phases are named according to the main phases in software development seen from the contracting point of view. They emphasize the different needs and usage concerning the contracts during these stages which unfolds over time.
The contracting process has been drawn as development phases following each other in a circular fashion. It is used in this software contracting model with intuitive names for the phases from the software development viewpoint. Section 2.2.2 analysed some of the general software process models and among these were the waterfall and spiral models. Both models by definition have a similar content but the manner of representation and unfolding of the process is different. How many phases there are in the model and how the phases are named is not the main point, even though it helps to follow the analysis if they follow the taxonomy of the business line. Still the subdivision into too many phases is harder to justify, as the boundaries between the different phases are not always so clear. More important is to find and analyse the processes and events behind these phases. The phases of the spiral model reflects well the phases in the software contracting model. Accordingly the four different phases have been named: negotiation, definition, production and assessment to delineate the main phases in the software development as well as in the software contracting, cf. Fig. 24.
The negotiation phase provides a setting for future cooperation and during the assessment phase these settings are revalued together with the knowledge gathered during previous cooperation and also the new information from the surrounding environment affects the judgment. The definition and production phases belong to the most central core processes of the firm. These processes incorporate all the important and exclusive know-how for what the company is known, i.e. this knowledge base, and is the basis for the company’s existence.
The question is, how does the process-circle start to unfold? The first time when the contracting partners initiate their cooperation they must proceed through successful prerequisites and formation of the relationship part in the negotiation phase, Fig. 24. This also includes the screening process of evaluating the partner’s abilities, skills and commitment to joint operations. This starting process is done only once as the partners enter in the relationship. The wider grey and upward pointing arrows in Fig. 24 again show the possible termination points of the relationship. From the figure is left out the feedback loops and iterations that are normally present during the software development process.
4.1.1. Negotiation phase
According to Holmes and Glaser (1991) "the business negotiation is the process of bargaining over a set of issues for the purpose of reaching an agreement". This definition is also perceived to be suitable for these analysis purposes. This definition implies that there are two parties presuming that they would be better off as a result of negotiations. Further there is a range of issues present over which the parties are prepared to make concession and compromise. Lastly the definition states that the parties are aspiring to reach an agreement. In every negotiation a good outcome is when both sides win, the parties reach a so-called win-win situation, as the relationship should be mutually beneficial to both parties. Usually bargaining occurs over a wide range of issues that are characteristic of respective line of business. These conditions of satisfaction include matters of quality, delivery forms and dates, payment terms, price, specifications and termination settlements. All these issues are interrelated with others; this implies that if the other party wants to change one of these conditions then other condition is also altered, if other party wants to lower the price then e.g. the quality is lowered, too. It is also found that there are many different issues to bargain, not just the price.
There are two central concepts of business-to-business negotiations. First, the bargaining strength that refers to the power that one party is able to exert against the other. Second, the bargaining range that refers to the degree of movement that is possible for each party with respect to individual issues on the agenda (ibid). Further, Holmes and Glaser define four commonly found stages in negotiations that are preparation, positioning, reflecting and bargaining. Preparation is a must if the negotiator is professional buyer or seller. The negotiator has to make plans and acquire information beforehand about the other partner as well as about the issues possible coming under question during the negotiation. Positioning is done by submitting a proposal that suggests joint action with another. After this both parties have revealed their positions and they must start to reflect both parties’ stance. Then the parties enter into bargaining which the purpose of is to settle the differences that stand in the way of a contract. Achieving a good agreement would optimise both parties objectives, but this is still seldom the case as more usual is the situation where both sides are satisfied with the contract but the other party has been able to maximize its interest better than the other one (ibid).
The software development models (ref. Section 2.2.2) include in principle only the descriptions and definition of the tasks to carry out the software development process itself. They do not explicitly speak out for the tasks that belong to this relationship forming and business negotiations phase in software business. The negotiation phase is emphasized and characterized by interactions between the partners in the form of communications, meetings, engagements between partners’ management and sometimes-even lawyers and the exchange of information is frequent. These issues are discussed in more general terms as it is common during this phase to agree upon larger framework contracts that are later in the definition phase then specified in more detail. This approach also embodies the possible seed of future problems if the framework contract and the subsequent definition of the project contract do not match. For example the resource needs are increased, the delivery date may turn out to be excessive and technologies and platforms used need more changes than anticipated. In order to facilitate the situation the companies have moved from discrete contracts to recurrent contracting and relational contracting. But the last mentioned relational contracting also requires a more elaborate internal governance structure (Ring & Van de Ven 1992). Ring and Van de Ven argue that harmony flows from the increased production and transaction flexibility available to the parties as they rely on relational contracts, (ref. Section 2.1 about relational contracting). This approach makes it possible not to over-specify the contracts and parties can leave gaps in them as they have up built trust between them.
Compared to Scherr’s (1993) general customer-supplier development phase model his definitions of the opening and negotiation phases belongs to this first negotiation phase in the above model. The negotiation phase is arguably one of the more important ones as during the negotiations the customer states his conditions of satisfaction for the outcome of the joint project and the supplier states its conditions to fulfil the agreed tasks. This joint agreement in turn is needed to make it possible to manage customer expectations, which again enables the management of customer satisfaction. The customer (and supplier) will return to these written or unwritten terms of satisfaction later during the assessment phase at the latest if nothing unforeseen has happened before that in the shape of misunderstandings and unmet obligations during the course of the project. The negotiation phase hopefully shortens in duration in the future for new systems development between the partners. This of course, depends on how successful and satisfactory the outcomes are along the way of the cooperation and how smoothly the cooperation runs during different phases as well as on different organizational levels of the focal companies. Essential output of this phase is the answer to the question: will we go ahead together?
4.1.2. Definition phase
From the contracting point of view this phase is characterized by more specific negotiations concerning the technical and practical details of the joint software development project. Among the details to be specified include the software platform, programming language(s), hardware and network architecture as well as the software architecture with databases and the interfaces that communicate with the users. Depending on the software development model used some of these issues are specified later as the prevailing paradigm is to postpone the design decisions to as late a moment of the development as possible stemming from the fast market development and changes in user needs. The concurrent software development model does not have the phase distinction as clear as the spiral model, therefore it is also harder to describe it with these phases as it is more suitable for use in the independent software producing companies that make the COTS type of software applications according to their own specifications. They do not need to discuss and adapt them to outside requirements.
As could be seen in Section 2.2.2 the different models of software development, e.g. the spiral model during this phase evaluates the objectives, alternatives, constraints of the focal system and the possible sources of risks. To help the design process during this phase the spiral model utilizes prototyping and modelling of the application to be constructed.
If the cooperation has started successfully with constructive negotiations and with consensus then after completing this phase the partners should have a common clear understanding about the target of the subsequent cooperation.
4.1.3. Production phase
The software development models produce most of their outputs in this production phase, as this is the phase where the software is actually built. If everything runs smoothly during the production phase then there is no need to contracts. The only situations are when e.g. the resources are overrun or some unanticipated technical problems that may endanger the promised delivery date or the resulting application have emerged. Though the partners consciously collect or even unconsciously data about the relationship development.
The central output of this phase is the finished and functioning software product, e.g. system, application, component, etc.
4.1.4. Assessment phase
The assessment phase is interesting from the contracting perspective, as during this phase the customer and the supplier will come back to the contract and refer to the conditions of satisfaction for the outcome of the project. Scherr introduces two critical factors to be considered in this phase. They are: are the promised products or services delivered promptly on time and is the customer satisfied with the outcome (Scherr 1993)? During this phase all the understanding be it emotional or rational will affect the degree of satisfaction of the whole life cycle of the cooperation. If the feedback of the whole process is left to this end phase they may come too late to be constructive and useful for the outcome. Tikkanen (1997) uses from this phase the term, transition. Tikkanen defines other phases as bidding and negotiation, planning, design and implementation, see also (Seppänen 2000).
The agreed contract is followed and consulted more or less during consecutive phases. During the follow-up participants receive and collect data on how the relationship and cooperation unfolds over time. This data together with the final outcomes then are inputs to the decisions made in the last assessment phase that will affect future cooperation possibilities. After this the partners remain in this loop as long as they are in cooperation with each other. In the above framework all the above phases with their processes belong to the interaction processes. The processes constantly produce outcomes that by feedback again affect the course of the processes. This feedback can be in its nature positive or negative, enhancing or dampening the cooperation respectively.
The software contracting process loops this circle with the above-described phases. However the phases change their duration, content and importance as the cooperation and the relationships evolve over time into the different stages of the relationship development. This goes on until for some reason the cooperation is ended, due to changes and developments in the outer or inner environment of the companies (Tähtinen 1999).
At the conclusion of each exchange episode, by which is understood to comprise the whole life cycle of the development process from the first negotiations to the satisfactory delivery of the product or service, each firm decides whether to continue the relationship at the same level, to broaden it, or to curtail it. During the assessment period the continuing screening process should be done in order to ensure the vitality of their working relationship (Anderson & Narus 1999, Warsta, Lappi et al. 2001). Progressive and alert companies validate the relationship from both sides i.e. customer and supplier.
During the whole life cycle of this negotiation-definition-production-assessment cycle the parties collect data from relationship events and also from the surrounding environment that is later used in the assessment phase to analyse the situation for possible further joint efforts. This could make it possible to define a continuous screening process that lasts the whole life cycle of the cooperation (Warsta, Lappi et al. 2001).
The result of this phase is genuine knowledge how the cooperation did in practice function and how the relationship will evolve.