6.6. The relationship development

6.6.1. Change of stages

The focus is on the reasons and consequences of the change of stages, i.e. from the pre-relationship stage until the stable stage. The process activities in each different stage are not described here, as it would be more or less rephrasing the activities that have just been described in previous sections, only from a different perspective. In practice the available empirical case material enables the analysis of the movement from the exploratory stage to the developing stage, as there is not enough instances to analyse the next step phenomena, Table 2. The numbers in the table are derived from the tables in Appendix D and they are here given in percentual figures in order to express more recognizably the movement from the exploratory stage to the developing stage as it is interesting for this study.

Pre-relationship stage. This stage has been discussed and analysed extensively in Section 6.3. It was indicated there that only one reference to NDA contracting was found belonging to this stage. The stage is relevant and important also from the contracting viewpoint as it lays the base for future successful relationship development for the negotiating parties.

Exploratory stage. This stage observes the distribution of the 66 separate process activities accumulating mainly in the negotiation phase category. This indicates and affirms the opinion that the exploratory stage is, according to its name, used substantially for acquainting and learning from each party during the software contract process. The business and contract negotiations take longer time to be brought to a successful end.

Developing stage. The most interesting here, for analysis purposes, is the developing stage as it is situated between the exploratory and stable stages and where, after the first periods of the cooperation the relationship starts really to develop and grow. The partners have concrete evidence of each others’ practices and skills with know-how during the different kinds of operations and projects executed during the exploratory stage. In the available data 24 process activity instances were found that could be classified this category. Using these findings it is possible to conclude that as the companies move from the exploratory stage to the developing stage, the emphasis in the software contracting process switches from negotiations to definition and production phases. This indicates the understandable and sensemaking fact that the old cooperating companies do not need to use their time and resources anymore to conduct lengthy negotiations. Instead they can focus on more productive work. These are the phases of definition and production.

Stable stage. No more than three process activity instances exist classified in the stable stage this stage is not scrutinized in more detail. The reason why there are so few findings in this category is explained by the perception that was made during the analysis work with the empirical data that between the exploratory, developing and stable stages it is difficult many times to decide on the exact stage where the activity belongs. This is especially the case between the exploratory and developing stages as the companies were young and the relationships were still nascent and short in duration. The stable stage is somewhat easier to detect though in the material at hand only these few suitable instances emerged. It would be interesting to have more instances also in the stable stage to be able to analyse the movement from development stage to stable stage. To find out the reasons, directions and the behaviour of the shift would be an interesting issue to study. What would be the decisive elements that indicate this occurrence?

6.6.2. Analysis of the developing stage

This section analyses the process activities found in the empirical data that fell into the developing stage category. As described above the classification between the stages is not always so evident and definite, though categorizing similar activities helps the analysis work and gives perspective for further discussion. The broad interesting questions in this context are how does the governance of the relationship and contracting process develop and change when the partners pass from one stage to another? The movement from one stage to another was also discussed above, as it is not always an obvious and eye-catching event. More or less it can be described as a slow development and change process that only gives the possibilities for real comparison only between longer time periods in the relationship development.

The above questions are analysed using the empirical data that could be defined and inserted in the following four subclasses of activities as depicted in Appendix D. These groups were named to reflect the contents as follows: relationship evaluation, recurrent cooperation, follow-up contracting and relationship building.

Relationship evaluation. The contract is one way of managing the relationship with formal tools, but what the partners actually do with the signed contract afterwards depends on how the contract has been drafted. In the contracts the companies typically include some kind of follow-up mechanisms. If the contract is of a non-recurrent nature then the follow-up mechanism is more limited and restricted to its extent, as the supplier may not expect further sales of products or services. If the project is based on an existing framework contract then the situation is different with some attached work orders and specified mail stones and corresponding payments. That of course creates natural checkpoints and possible feedback situations. On the other hand if the contract is a delivery contract concerning the channel with predetermined sales volumes or other agreed targets, that again involves reporting and payments to give the feedback on the relationship development.

The managers of the Finnish software companies interviewed operating in the USA had an interesting view on the different institutional environments when comparing US and Finnish customs for contracting purposes. According to them the default value in business relationships is that the some day the cooperating partners will meet in court disputing over their workings, but the companies must be able to do the business even after these possible disputes. This is just a part of the different culture and everyone accepts it. It is included in the business processes and it does not cause much of a negative image even though the companies sometimes go to court. From a Finnish firm point of view this would be an extremely hard course of action, as it is not a typical built-in mechanism in the Finnish business environment. Here if you get involved in a conflict it is almost impossible to get out of it without further damages. Also to continue with the same partner is almost impossible after this kind of incident.

One manager clearly expressed his opinion that the partnership of the relationship should dominate over the contract-ship. The contracts are typically put aside after they have been signed as one manager noted:

There is also the possibility of auditing if a situation emerges of lack of confidence. But these are economic points, seldom when you have done the contract do you need to come back to the negotiations anymore [I7].

The contract is also a document against what the partners are able to compare the outcome to the promised and jointly agreed one before the software development starts. As one manager noted:

A mechanism must exist with which we can check what we deliver is what is in the original text. In the attachment of the contract we have the description and we have certain requirement points where we can check it. And if what we deliver does not correspond to what we have promised then we go back to the contract to check the possible sanctions [I7].

Recurrent cooperation. This category of process activities is characterized by contract negotiations that take place when the partners are presently working in a joint project or they have finished the previous effort successfully. This group is labelled as recurrent cooperation. It could also be named for the Nth round contracting during which the partners negotiate about totally new application projects or just the next follow-up projects for the previous software development projects. One manager explicated the changing contracting environment in well-defined terms:

In some cases when we have negotiated a big OEM type framework contract it can take even one year. But after that, when we do these new projects, the contracting only takes a couple of weeks [B10].

Several managers confirmed the advantages of the long-lasting relationships that make the contracting practices easier with the customer. As the companies have established certain forms of negotiating a contract with the customer. They usually just check after the assessment if any experiences and issues have arisen from the previous project that could give reason to make modifications. However, as they noted they only need to refine some details, in order to better serve their purpose than the old wording in the previous contract.

Knowing both parties’ procedures for cooperation governance and the way of working also eases communication and dealings. Some typical institutions have the customers with the different project and control groups. Some managers questioned whether or not the control group functions formally. If the project is not very big then the group may function so that representatives discuss by phone the kinds of issues which have emerged, the kinds of needs which have been put forward, the kinds of timetable changes which are coming and the costs of all these. They then agree and take minutes of the discussions.

The long-standing relationship and recurrent joint projects paves the way and builds trust between the companies and their experts and this again has positive effects on the end product, timetable and costs as the project managers can decide together if there is e.g. he need or possibility to add or delete some features.

In some cases where the partners have a framework contract operating and with whom they have made business during a longer period of time the partners have practically agreed that when the customer needs some software applications they only contact the focal software company. The communication may be quite brief as the customer just informs them that this would be the next project; who would be the specialist from the supplier side to do it, what the timetable is and how many resources the development work requires. The CEO of the systems house described their practice with their long-standing partners:

When we have an valid yearly contract [with the customer] then we just accept call for bids and we responded with an offer and the customer accepts it directly or the asks for negotiations. In general they accept the offer [L3].

He further explained the benefits of the yearly framework contract that they pursued to renew every year with extensive negotiations followed by two smaller negotiation rounds between the yearly meetings. As he concluded:

In the yearly contract we do not yet decide on any particular application development but we draft the framework for the cooperation so the yearly contract is open but they will later shorten it considerably if it were then an offer or a project. After that only a couple options exist: when they have accepted our offer, they either make an order where they refer to this, or they make a delivery contract [L4].

In this contract they lay down the general conditions. Thus, subsequently the delivery contract only needs to concentrate on the specific new project contract. In this contract they just describe the application and its preliminary specifications are attached to it. The partners’ responsibilities during the cooperation are also depicted. For example what the supplier part in the project is and what the customer’s part is, the timetables, resource estimations, and the timetable and contents of partial deliveries are listed in the document.

The time used for the negotiation process shortens considerably as the partners do not need to enter into lengthy business negotiations with different kinds of trust showing and building efforts. The partners have established a certain framework to which they are able to refer that have worked in previous projects and as no problems have emerged there is no use in changing the procedures. The partners have succeeded in establishing an institution on how they work and manage joint projects together.

The same CEO concluded:

This [the relationship] also includes trust and I think that we are not able to do things in another way. The contracts in this setting are more or less a necessary evil. But without any formal contract we cannot live [B10].

Another manager also shared this same opinion in the following statement:

If we start a second project with the same customer it depends on whether is it a continuation of the previous one or some other. In some cases it has been quite easy, we have just made an offer and they accept the offer and then we start to do it [D4-5].

However, this cooperation is based on a working relationship between the partners as concluded by the same manager:

But when we have a good partnership and we have the basic contracts and we have evidence of operation, so then our work is quite simple, as when we operate with them we do not even have a contract with the end-user. This accelerates our operation procedure habits [D4-5].

The developing relationships are nurtured with several after-care programs with the customers and their management. Responsible sales representatives or in some cases even the supplier’s management level people approach the customers. This of course depends on the importance of the customer and also how the new software company is in the markets. Thus the customers are important for further reference purposes and they are also utilized for marketing purposes. A common custom is to invite the customers to speak in seminars and other marketing occasions.

The easiest procedure from the software company’s perspective is to have a valid framework contract constructed so that the new procured or to be developed applications can be put under the existing contract. This considerably shortens the negotiation time. As one manager said:

If we do the second round with the customer then we usually use the existing contract. It is the old contract still and we just add a new product to the contract so we update an attachment or a schedule, but then all the other things are agreed on in the old contract [G4].

Another manager further supported this same opinion as follows:

The difference between new and old customers in the contracting process is that you get from past experience an idea about the customer’s behaviour pattern and from the customer’s ”trigger sensitivity”. This also holds still in long-standing relationships. There is no reason and need to loosen up this process for the reason that you have been cooperating already for a longer time [I4].

Or in the words of the COO of the data management solutions company:

If we have previously had cooperation with the customer then we usually do not need to touch the contract so much. The basic contract that we offer in the initial stage is over 20 pages, almost 30. The agreement has an appendix where we can attach new products. In practice we always make a framework contract where we can add new products very easily [J6].

The same manager described the significance of the relationship as follows:

At the moment we have had little experience of these bigger customer relationships, only a couple of years. But as usual the relationships tend to deepen and as we have more and more projects we get new customers or new projects with the same customer. The relationship grows and it depends on whether the same responsible people stay there or change [J9].

As could be understood from the above quotations the managers find in common that the positively developing relationship with the right contractual tools easies the future contracting process and gives more time to the actual software specification and development work.

Follow-up contracting. With several kinds of follow-up contracting methods the software supplier tries to keep and extend the contact with the customer. The change of partners is normal evolution in business life and the same is with the employees, too. But as the managers noted the companies would not like change to take place constantly as it is hard from the organization point of view, as the organization must regenerate itself. Though this could be good for some companies in the fast changing software business environment. It is expensive to get a new customer but it is still more expensive to get an old lost customer back. The cheapest is a customer with whom the companies have operated for along time, and also the quality of cooperation is always better with people you know. According to the managers the ideal customer change should be around 10 – 20 %. However, in a worse case scenario if the company sells a non-recurrent product, then the customers change constantly.

One manager described their contractual procedures that attach them to their customers:

In practice all our customers are under the support contract for at least one year and we try to renew the contract every year after the first year. Then they will regularly receive upgrades and then these technical information letters where we give advice and tips as well as the manuals [G8].

The support and service contract is one typical method of keeping the customers close to the software supplier. There are of course several good reasons for this as indicated before, after sales is one of the most important reasons, also to block the customer from changing from one camp to another is one reason and from the financial perspective the smooth and continuous stream of money is also seen as an important reason. One manager of a company that was strong in the channel business with two multinational supply channels described their feelings concerning after-care issues:

We have a 12 month warranty with the hardware [and software] and [end-users] in 95 % of the cases a support contract that Channel A redirects to us. The channel invoices the customer and we just invoice the channel. After-sales is done by the channel and retailers, we are not interested in it [M5].

This division of work described above is quite straightforward in its nature and works well but it has required hard and long cooperation that this very clear and trusty situation has been able to develop. The after care and the associated contract can also be just to provide the warranty period.

Relationship building. The companies are interested to work with their customers on a long-standing basis and they indicated that they were not interested in any sporadic and sort time projects. However, in some cases the managers admitted that in the early stages of the company’s life it was not an easy task to reject possible financially interesting business opportunities. The issues belonging to these selection strategies have been discussed in the section of the pre-relationship stage of relationship development. The successful contracting and from this smooth cooperation, also releases resources for both sides to start to operate after a common plan.

One manager described the importance of good past experiences and their situation:

In practice, when we have succeeded in opening the door and if the customer is satisfied with the results so they will for specific software projects turn to us. At least I do not know of any case where they would have put us in a competition with others [B9].

The same company had formed from the beginning its strategy to become the best in its narrow telecommunication niche. All the future application development projects were aimed at knowledge and speciality building of this special telecommunication’s sector. The CEO further noted that:

This is also our goal; that we have this kind of expertise that not so many other companies have. We have deliberately tried to get hold of those kinds of projects where the customer also knows our knowledge base [B9].

Only a few explicit adaptation instances were observed as the companies were in general young and they had not had time to adapt. The software companies in question had as a matter of fact made these adaptations in several cases in advance even before the partners started the cooperation.

6.6.3. Conclusions

This section has described and analysed from the empirical material emerging managerial views that explicate and confirm the dynamism embedded in the “Software contracting process” model. The observations and opinions stated by the managers clearly give the indication that as the relationship develops positively over time shown with concrete joint projects, the supporting processes tend to diminish. The phenomenon is evident also from Table 9though the information it shows must be interpreted with deliberation, as the number of activities does not allow making too far-reaching conclusions. This fact especially affects the recurrent joint cooperation. This again gives the impetus for new follow-up contracting projects and further relationship building.

The change in the contractual issues depending more on the relationship development as the cooperation unfolds can explicitly be seen from the above statements. The deeper and more open the cooperation is the less time the companies need to use for the contracting process.