7.2. Observations of process attributes and typologies

7.2.1. Process attributes

According to the process literature studied the following relevant factors were chosen for their interesting attributes: 1) the owner of the contracting process, i.e. the driving force of the process from the software company’s perspective or more formally he or she who is responsible of maintaining the process descriptions, 2) input and output of the process, i.e. document, product, service, bonds, performance, contract, etc issues and 3) events are more or less critical points in time that trigger the next activity to spring into action. In the analysis the different business modes – COTS, tailored and MOTS – are taken into account and their similarities as well as their dissimilarities are discussed. From the case material the process attributes were in some cases difficult to define clearly as a) the companies are small, b) the processes are not defined, c) there are no explicit owners for the processes and d) the process descriptions were in many cases short.

Owner of the processes and activities. The ownership of the process activities were found to be quite weak and scarce as it was only possible in a few cases to detect a real acting owner. This is a strong indication of the fact that the contracting processes are not well and specially defined in software companies. In some cases it can even be said that they have just evolved without any greater planning in mind, ref. Appendix H.

In the COTS business cases the owner was either the CEO (or equivalent) that represented the software company during the negotiations or the sales and account manager responsible for this specific customer or customer group. In some cases even the technical support group could be identified as the process owner. In the tailored business the process owners emerged as being the CEO and the software developers. Again in the MOTS business the owner is typically a management and marketing person, even the software-developers and application engineers. Thus representing quite a miscellaneous group of experts.

The process owners were a multitude of different participants which have a role during the negotiations and ownership of this focal process. Though typically fewer people in the tailored business mode, which can be explained with the comparative small sizes of analysed tailored software producers among the case companies. The management was able to handle the contract negotiations letting the developers work on their primary tasks, but software professionals were used more during the later definition phases.

Inputs to processes and activities. The process inputs were mainly the know-how and experience of the negotiators as well as previously prepared contract templates that were mostly used and offered as bases for the joint negotiations.

Besides the above mentioned essential process inputs in the COTS business also the customer registration cards, signed NDA contracts and of course applications themselves were found to be the universal tangible inputs. Especially during the assessment phase the usual inputs for these activities were the existing contracts with possible problem issues that had emerged. To realize the evaluation procedure of ended delivery, the focal inputs for this were the collected past experience, produced assessment reports and established personal relationships and feelings.

In the tailored business the inputs during the negotiations phase were found to be diverse ranging from the customer’s needs and interest to technology know-how, old software to be enhanced, customer’s orders, references to old contracts and past experiences. Inputs during the definition phase were the requirements of the customer’s quality systems, application specification documents, preliminary outlines of the new software, semi-finished or finished specifications and correction calculations of needed resources. Inputs during the production phase were the existing framework contracts, and more exact work load estimates. During the assessment phase the typical inputs were framework contracts, customer’s needs, delivered software, specifications, during the previous phases gathered know-how, knowledge of other joint business possibilities, bad and unsuccessful contract terms, emerged problem reports, other technical issues and contract attachments.

In the MOTS business the inputs for the processes were typically business related elements, e.g. credibility and common goals of business, value adding capacity of the software company’s product, confidentiality, interest in cooperation, fulfilment of the contract terms and the delivery related issues. Contractual issues among others were contract templates, existing contracts, assessment results, conflict issues between partners, the template contracts of employment, call for bid, offer, contract assessment and trial period assessment results. In the MOTS business the inputs were various and this could again be an indication of the diversity of this business mode as it incorporates issues from both COTS and tailored business modes.

Outputs of processes and activities. In the COTS business the (process element) activity outputs were the drafted and signed contracts that could be based on either of the companies’ own templates. Typically when the customer company was one of the so-called big ones, then in this case the software supplier usually had to accept the customer’s templates. However, in these cases there were possibilities to make some modifications to the templates if the software producer saw them as important enough and was also strong enough to demand them. Other outputs found were returned registration cards, delivery of software after successful piloting. Here is piloting and testing distinguished between as follows; software testing is an activity where the developers try to test and find out if the software is free from errors, so called bugs. On the other hand piloting is a process where the customer tries to find out and determine if the software is suitable for their purposes. In the assessment phase the outputs were in the worst case a broken contract and dissolved relationship or project.

The outputs of the tailored software business were also the agreed and signed NDA contracts, framework contract or work-order contract. Subsequently other outputs were determination and definitions of the project team, task definition with detailed and confirmed time schedule and estimated resource needs. In some cases also, changed work orders due to the detailed specifications. During the later phases outputs from processes were also the received feedback, possible modified framework contracts after new information and adaptations made. In some cases dissolved contract or sanctions as outputs were also found.

The MOTS software business resembled the tailored business with several expressions of negotiated, modified and signed contracts, i.e. offer, license agreement, project contract, systems selling contract. In further phases there were pilot-applications, defined software specifications, descriptions about project documents, possible change specifications with approved changes written down and minutes to send to the customer for inspection. During the assessment phase the outputs were: enhanced knowledge base, assessment reports and assessed contract. The cooperation ended in some cases in separation and the contract was dissolved.

Events of processes and activities. The event that usually triggered COTS process activities was found to be the need for partnering that started the negotiations that ended after a week or even after half a year in some cases. Other important events that trigger the processes are typically the customer’s decision to buy the proposed software or whole application emerging from the organizational or business development needs, after that the acceptance of license terms and signed contract, followed by a supply of software. The factors that started events during the assessment phase were successful acceptance of the installation, emerged delays during the software delivery, changed situations in the customer’s businesses strategies and the customer’s changed needs.

In tailored software business the triggering events during the negotiation phase were the customer’s showed interest towards the software company. This interest again started the negotiations that usually ended in a signing contract. Events during the definition phase were found to be the start of defining the specifications and finished design tasks. The task definition had shown a need for more resources than was anticipated in the framework contract. This again called for negotiations and subsequently contract closing. The typical production phase events were the emerging needs for change and information. During the assessment phase the events were the initiation of the software delivery, finished software installation and after the installation assessed software, with comparison to the signed contracts. In some cases problems emerged during the cooperation, e.g. the other party found out that it has made a bad contract and if the negotiations do not end in a compromise then a need for dissolving the contract exists and possibly the whole relationship as well.

Typical negotiation phase events in the MOTS business were the start and end of negotiations during which, in some cases, successful consulting was done, in order to show credibility and trust for the customer. After this comes the usual contract signing with the partner or customer. In other cases the triggering events can be a call for bid which when it arrives is responded to with an offer that is submitted to the customer and if it is accepted the work starts. During the following phases the typical events are the start and end of the specification project as well the start and end of the production processes. During the production phase a need for specification changes may raise that again evokes the need for a control group meeting and to accept the written minutes. Though in some cases some conflicts happen as assessment is done after the software is delivered and installed. This may again trigger an event to handle and correct the situation.

From the above can be seen that the tailored and MOTS software business is much more "eventful" compared to the COTS business. However, this is understandable as the former two business modes have substantially longer cooperation with several experts working on joint projects.

7.2.2. Process typologies

During the analysis the observed process activities were categorized into two relevant classes described in Section 3.1.3. These classes depicted the mode of the processes as follows:

The constructive process mode emphasizes the tendency to break with the past framework. This mode is linked specially with the dialectic and teleological processes. This on the other hand gives new ideas, innovative and discontinuous contracting models to disclose.

The prescribed process mode emphasizes the possible changes within the existing framework. This mode is especially connected with the life cycle and evolutionary processes where the variations in the processes are prescribed and predictable.

In Table 13 the percentage distribution of the typologies of process activities over the four contracting phases is collected. From the above array it can be deducted that a major part of the process activities belongs to the constructive mode that represents 65 % of the total occurrences. On the other hand 40 % of the constructive instances are executed during the negotiation phase. From this it can be again inferred that this phase of the negotiations is emphasized by an innovative and new solutions seeking process.

Table 13 and Table 14 do not give any clear patterns or indications as to how the process activities behave from the typological perspective in correspondence which the software development phases (Table 13) or the relationship development stages (Table 14). This can be interpreted that the various process activities collected in these tables do not give a proper picture of the scrutinized software contracting processes from the perspective of process typology.

To be able to deduce in more detail this typological analysis needs fewer processes – perhaps only one – with a longer analysis period. Though with some deliberation a shift may be observed from the exploratory – constructive pair into the developing stage into more even distribution to constructive and prescribed pairs (Table 14). This could be interpreted that the nature of the process mode shifts from a bare constructive mode also to capitalize on the prescriptive mode of contracting process when the partners’ relationship develops over time. Thus indicating the move from a teleological to life cycle process mode. Rationally thinking this observation makes sense as the companies strive towards a simpler and more efficient relationship and contracting process.

As this outline is still a depiction of small activity instances that itself form a whole processes though it is possible to analyse the tendency of the behaviour of the software contracting processes. Some elements characterize and mould these processes and among them are the business environment, technological development, the company’s inner organization and the company’s business strategy. In the long run the main purpose of the firm is to be profitable and yield earnings for the stockholders, therefore the managers try to control these variables as well as possible in order to achieve this goal. From the observation that is made from the empirical material the status of the company at the moment can be seen and it can also indicate the possible future situation according to the thoughts that were presented during the interviews.

As has come clearly out in Chapter 6 the software companies do not have any specified software contracting process, only in some rare cases there were indications towards this direction of development. Instead the contracting processes had evolved over the years into their present forms. The managers’ previous knowledge accumulation about contractual issues had strongly contributed to the development and shape of the process as had their experience of working with other companies in terms of contract management and contractual issues. This know-how had come as an inheritance and that knowledge was then reused in the new organization. The contracting could also develop by copying on adequate amount of old contracts used in other similar companies. Though a typical pattern also was that the companies relied on expertise, i.e. lawyers to draft the contract templates to match up to local requirements. This was developed mostly on ad hoc basis when new contractual issues or needs emerged without real planning in advance for the whole software contracting processes to be administered properly.

But from the discussions with the managers it was apparent that there was the desire to have a formal and administered contracting process with all the contract templates needed and advice on how to use and when to use them. The lack of time was the usual excuse why the process was not defined, thus the managers did not find a high enough priority to develop and specify the process as the other software development work in the turbulent environment required all the available resources and the management felt that the situation was still in hand.

According to the interviews the managers would understandably like to see the world become more manageable. For this reason they emphasize the importance of the framework contracting that brings continuation and stability to their business environment. The framework contracts lay the basis for future cooperation and the future contracting is quite easy and short as it does not excessively consume time and the companies are able to concentrate on their focal software development work and streamlining the support processes. This perspective calls for the life cycle mode of the processes. This process mode would also be better put in practice when the partner had achieved the Stable stage in their relationship. Then the software company would change the software contracting process into the life cycle mode.

For the following reasons the life cycle mode is not the only practical process mode usable in the software companies. When analysing the discussions and interviews the conclusion can be reached that at the present the software developing companies have their software contracting processes in a drifting and evolutionary state. But the software business environment is turbulent with fierce competition with innovative technological development enforcing the companies to conclude fast decisions especially when making business and establishing joint ventures. These activities and modes do not allow too predetermined institutions to act in new and unexpected situations. This mode of activities would again ask for teleological software contracting processes. This is the mode that the software companies are aiming for. Then the software contracting process would be predetermined and specified, i.e. written down explicitly with process owners etc. in a teleological mode. This mode rationally takes into consideration the environment and its possible changes, but it still has a precise set goal.

Thus it could be cautiously advanced with the proposition that: the motors of the software contracting processes develop from a constructive to a mixed constructive and prescriptive mode. More exactly said: from a teleological to a life cycle process type as elaborated below. In this case the constructive mode can be characterized by the teleological mode or even with the above-mentioned drifting type of development. Indicators for life cycle mode of processes are the well pre-formulated framework and license agreements and again for the teleological mode they are the different kinds of work orders, project contracts and assignment agreements that must be drafted carefully each time in detail to reflect the common understanding of the intended software, even with an old partner. If a well-defined contract processes had been found then this would have given strong support for the life cycle mode, but as indicated previously this was not the case.

Håkansson and Snehota (1995, 10) discuss this same phenomena that as the business relationships are often complex and informal they tend to become institutionalised over time. Though the studies on business relationships indicate the fundamental feature of the relationship to be constant organic change in the relationship between the partners. From this the conclusion can be drawn that the continuity, rather than stability is an important character of the business relationships. Thus to successfully run the software company the managers must be able to and understand how to govern the relationships with their customers in a continuously developing and changing business environment. For further studies the dialectic mode would be very interesting to follow and analyse in the inter-firm negotiation and cooperation situations.

It can be thought as an example: a contracting subprocess that fixes the software license price and compares its development with the four above frameworks how they suit this specific case. The author of this paper has, in past, been working as a head of a software developing unit that marketed and sold applications to businesses and local government organizations. The pricing of the applications is a very intricate operation as the supplier tries to get the price as high as possible and on the other hand the customer tries the converse but in the end both should be content. However, one of the hardest things is how to define the value of the application for the customer, i.e. the customer’s value and then resolve the customer’s “pain barrier”. In some cases it is dialectic process where the supplier gives their first price with some slack in the price and then the customer makes a counter offer with a lower price and so on, this discussion continues until a feasible price level is attained. In some cases the application’s price is set and fixed in advance e.g. depending on the installed CRTs or users or it is even related to the inhabitant base of the town. So this process is very predetermined in advance with guidelines to follow as in the framework of life cycle where the steps of the price setting is made in advance usually without any freedom to make any readjustments in the price tag. The teleological framework may (or may not) create an original (re) formulation to some predetermined procedures that still have a common goal, i.e. the final agreement between the parties, that is the envisioned end state. However, many times as the life is not so predetermined it must be adapted to these rules to be more competitive regarding competitors and it has been changed in an evolutionary way and the fixed pricing structure adjusted to match up with the needs of the customers. As this small example shows the business processes are polymorphic and there is not usually just one answer to the problem.

Table 15 shows the correspondence of different processual typologies with contractual issues emerging from the data. Van de Ven and Poole (1995, 524) have explicated a set of conditions, which “enables researchers to make an initial judgement concerning whether a given type of motor explains development in a particular situation”. This forms the left side column in Table 15. Into the right hand column are inserted corresponding explanations found specifically in the contracting process.

There are several reasons that support for teleological framework in this context are:

• The environment where the software companies operate today is turbulent and constantly changing with a need for new and novel ideas and business models,

• The young and small companies are still searching and developing their businesses, operations modes, channels and business relationships partners and

• For the well-established software companies it would be a good idea regularly to get loose from their old habits and customs that may hinder their future development. This would also keep them in pace with the younger and more flexible companies.

But there are also reasons that speak on behalf of the more predictable life cycle framework:

• The contract negotiations take resources – management’s, sales people’s lawyers’ time etc. – and risks incorporated in the process and

• As the pace of the customer’s needs and market develop fast the contract negotiation process should be fast and predictable.

The dialectical framework can be found in an inter organizational negotiating situation when two or more companies discuss possible future efforts. There is more interest in this study for inter company processes, i.e. contracting process the dialectical framework is not so well applicable for the purposes of this study. An evolutionary framework is an interesting one, too. The evolutionary model gives the freedom to develop that is required in this turbulent and constantly changing software business. In this sense it has the same change elements as the teleological framework described above, but they emerge more during the evolutionary process. The changes and solutions arise in the course of time. The reality may still prove to be more complicated with the non-predefined outcome or behaviour of an organization which also makes the evolutionary process approach interesting for the purposes in this study. See also as an idea about combining different motors in the software contracting process (Van de Ven & Poole 1995, 516). The final state may seem to be a simple one but the contract and contracting is only one concept in this inter organizational context. There are also other things that matter in a relationship between companies, e.g. psychological and inter- personal motives.

So in real life all three operational modes can be found and operate side by side. Still the approach is from the teleological to the life cycle framework, which is understandable referring to the above points. Also as Van de Ven and Poole state it is a risky oversimplification to try to explain these processes only with one of the change process frameworks. However, it is good to analyse both these concepts first separately as the motors behind them are quite different ones and then secondly proceed to examine them as related (ibid). Then questions about nesting, timing, complementarities and relative balance of the motors can be posed.

In this case the business processes that have been studied can be found and which also includes the selling process and contracting process depending on the phase and time of the negotiations. Where e.g. the business process as such could be described as having a larger and more stable perspective with a previously defined vision and strategy. But the contracting process may call for more innovative and novel solutions to be successful.

The timing is a similar relationship issue that could be found to be interesting between these both above-mentioned processes. They are sometimes hard to separate as in some contract negotiations cases the participants are the same people who shape and plan the visions and strategies of the companies, but in other cases these ‘heads’ are separate one these motors work in sequence. From the above-mentioned points how these mechanisms complement each other can be seen, depending on the company’s operational age.

The last of the above mentioned types of relationships are the relative balance that explains the patterns of stability and change in the organization. If the institutionally prescribed motor dominates then for companies in turbulent software markets it may pose a threat as the company may be too slow to response to the market needs or its operations are too predictable.