6.4. Interaction processes and their outputs

6.4.4.1. Negotiation phase and coordination processes

The coordination part of negotiations is essential for relationship forming and it is a logical continuum for the previous pre-relationship discussions and familiarizing activities. The coordination process lays down the foundation for future mutual cooperation.

Non Disclosure Agreement. The negotiators dilemma on both sides of the business endeavour is when and how much to disclose their own ideas, know-how and trade secrets that may even concern the company’s strategic core competences. The non disclosure agreement (NDA) contract emerges after a commercial play during which the customer sketches for the supplier in general terms in what business they are in and what they need from the supplier. Based on these preliminary and vague descriptions and discussions the software company makes an assessment, if what the customer is after is of any interest to the software company. After this contemplation if the company is still interested then they will sign the NDA contract with the customer. The decisive factor to proceed in the negotiations can be quite straightforward issues, e.g. the suggested project must be worth financially at least some certain amount or a possibility must exist to reuse the solution, i.e. COTS or MOTS type of business opportunities.

The customer may have to disclose trade secrets, e.g. concerning a new innovative Internet application that they are going to use in business and which is of proprietary and confidential nature at this time. After the pre-relationship stage the customer has to further evaluate and weigh up how reliable the possible new business partner is. Do they even have the capacity and know-how required to build the needed software or application? How much must the customer disclose during the first stages of the negotiations in order to find out if the prospective cooperative partner is able to produce the needed end product? From the supplier’s perspective the problem is similar, as they must demonstrate the product or their knowledge base in order to conclude a contract of sale. However, doing this they expose a risk of unveiling their ideas and the company may loose its possible knowledge edge compared to its competitors.

In order to solve this dilemma the companies use, to a growing extent, several forms of non-disclosure agreements that will guard them from inappropriate use of disclosed material, but at the same time they should not restrict and harm the positive cooperation. These contracts are mainly used when establishing cooperative relationships and in the employment relationship arrangements. Typically the NDAs can be drafted and signed just to apply to only one side of the partnership, but in normal business negotiations where both sides have to disclose confidential information the contract is drafted to bind both sides in an equal manner. However, this is again a negotiable issue, though it can be said that the first phase of the contracting process is always the NDA signing and it binds both sides.

In COTS business the software companies may either do the sales directly to the end-users or they may conclude an agreement with their channel operators, i.e. distributors or dealers. As one of the interviewed business intelligence software companies responded to the discussion about NDA contracts accordingly:

Usually we sign first the NDA contract so we can trust that neither party gives information to the competitors if come up those kinds of issues at the beginning of the cooperation [E7].

This gives freedom to the later stages of cooperation to exchange information more openly, as noted by one manager:

It depends on the organization when we start to discuss about the contracts. In some cases the process is clearly conducted and governed by the lawyers. Thus the juridical issues start immediately with a discussion about what kind of NDA we will first sign, before we open our mouth for the first time [G1].

This is especially important when the emerging cooperation requires exposing the customer’s interests or supplier’s software and knowledge base, especially in a situation where the customer wants to make a piloting of the suggested application under discussion. Then the customer has to describe its business endeavours in more detail and openly in order to make it possible for the software supplier to be able to install or give advice on the implementation procedure that may also be done by the customer them self. However, this need to sign agreements in advance usually depends on the customer company’s operational environment and practices. In some cases the customer may advance through all these steps with piloting and so forth and the supplier company has almost an order in its hands when the customer starts with the contract negotiations. It may also happen that the customer’s end-user and the concerned business unit has approved the procurement and only after that the customer’s legal department notices the situation and phase of the negotiations and finds out that they have not been consulted in proper order during the case. As one manager has said that after this things can start to be intractable as the customer’s legal department start to do things according to the longer formula, as they want to put their own signature and modifications in the almost ready negotiated contract. The CEO from the communications solutions software company said:

… we have decided to impose in the NDAs a clear confidentiality fine and the degree of commitment must be explicitly written down. When we start to discuss issues that are important from our business strategy perspective, then we include in the NDA contract a liability fee that is consonant with our business opportunities [A4].

In some cases the companies had, in the past been more open with the distribution of their proprietary information, but after they had been established in U.S. markets they noticed that these markets were not so used to this. Accordingly in the U.S. markets it is harder to get relevant information from the partners and the companies sign NDAs much faster than in Finland. However, this may also depend on the fact, that there are tighter restrictions on the companies listed in the stock exchange.

Framework contract. As shown in Fig. 29 the NDA contract is typically followed by the framework contract that is largely used together with the channel and other delivery contracting forms to lay the base for further long standing cooperation. Framework contracting is one of the most central contracting forms in every type of the software business; it will be encountered in both the tailored and MOTS businesses.

Framework contracting in the COTS business (also in MOTS) is used for forming and establishing distributor relationships, closer alliance type cooperatives and Original Equipment Manufacturer sales channels cooperatives. Some of the software company managers interviewed had both their own sales forces and they also relied on distributor channels at the same time. To establish a working distributor network is not an easy task as can be seen out from the following history that was described by one CEO. In this focal case long and eventful discussions with four prospective partner candidates yielded in average only one contracted partnership. However, from these formally agreed partnerships only every tenth was viable and active. The efficiency was just one in forty. Thus the process of establishing smoothly working distributor relationships is a very cumbersome and resource consuming effort. With this case in mind the importance and benefit of judiciously executed partner selection procedures cf. Section 6.3 can well be understood.

Typically, companies start drafting the cooperation agreement writing down the road map and all the commercial conditions and commissions in the hope of establishing a viable cooperation. According to one company they also sketch an action plan where it is described in detail how the cooperation should function on a monthly and yearly level. The agreement also indicates what both parties should do in order to fulfil the set targets and how much they must invest in the joint effort. Companies find the negotiation procedure to be composed of mainly from business negotiations during this phase where the negotiating partners lay down the main elements for future cooperation. The contracting process is just a part of the whole business process by composing its formal part. One manager stated:

From the negotiation process viewpoint it is most important that we draft the term sheet, i.e. terms and conditions, early enough and that we do it well. Thus the business side things are agreed first. If they have been agreed in a smart and exact manner, then the actual contracting process advances quite fast. We do not need during the contract negotiations to refer back to the business issues. That would only complicate the negotiations [J8].

The general experience from the negotiation process in the software business is that the company must separate the technical competence, the economic competence and the law competence from each other. The managers tried to relieve the technical staff (software experts) from participating in the contract negotiations, as it does not belong to their normal work and competence. This view was not commonly accepted in the case companies but it depended on how big the company was with possible separate sales and marketing staff. The technical complexity of the discussions also affected this opinion.

In drafting a contract the companies try to comply with the industrial standards. This came up in several interviews of the Finnish companies established in the USA. They stated that everybody uses these quite standard form papers – boilerplate contracts. The acceptance depends also on how famous and well known the law office is with whom the company is cooperating. Software companies starting to build their customer base in COTS markets use the framework contracting for the following purposes. Mostly these same reasons hold in the two other software business environments:

1. The software company tries to establish long standing relationships with new, big and strategically important customers.

2. The software company increases its scope of markets by cooperation with delivery channels that know the local customer base and their needs. This may also be ideal if the application needs some extra work or service during the implementation process and it is not economically rational to try to handle all the cases alone. The geographical width may be a problem, too.

3. The software producer may need an OEM channel that embeds the proprietary software in their application to be sold further to the end-user.

4. The software company tries to build a smooth financial income and to anticipate the resource needs.

Even though, the framework contracts in all these above cases have different contract clauses, mostly they are similar concerning e.g. the business goals of the cooperation, general rights of use, warranty, indemnification and liability issues. Some companies tend to put some margin also in the offered framework in order to have some negotiation room for manœuvre during the later stages. These kinds of general terms mark out the future relationship, like one interviewed CEO explained:

Here [in the USA] the significance of the framework contract is mainly that we have agreed on paper about what is liable to what and what the liability issue is. That is why we want to do these. But of course we agree on provisions, commissions and etc. It does not differ so much between Finland and USA [E6].

When the partners have established a working relationship, in future it is easier and faster to make new contractual changes and insert new attachment documents into the framework contract and its appendix. Without needing to go through long lasting and resource demanding business negotiations all over again. As one manager indicated:

Our contract is almost a 30 page long basic contract that we offer to the customer in the initial stage. The agreement has an appendix where we can attach new products. In practice we always do a framework contract where we can add new products very easily [J5, 6].

This is the focal idea of framework contracting that when the supposed and nurtured cooperation continues and the customer needs to procure new applications, maintenance, or other services then the contracting is much easier and faster to accomplish between acquainted partners and the previously agreed courses of action.

Even though the companies did not seem to have defined contracting process they still have formed and established during the years procedures that would simplify and clarify the contractual activities. These procedures may vary between different customer groups but the managers try to smooth the contracting process as new issues emerge. As one manager explained:

We mostly use standard contract templates and framework contracts as much as possible for each customer category. We try to keep the framework contract in the customer group or in the same category constantly. However, sometimes we learn from a new customer case. Then we change all the contracts or the contract processes in that customer category or even in all other categories, too. When we e.g. find out that a liability exists that we have not noticed before at all. Even if it looks small, it still may be so significant that we must change the contract templates for all customers and accordingly include it into all other customer contracting processes [G5].

Summarizing the significance of the framework contract is that the framework contract and the negotiation process establishes more or less the environment for the future business relationship in a common formal agreement that later is used and attached with new appendices. One manager expressed the change in duration of the contracting process as follows:

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

6.4.4.2. Negotiation phase and exchange processes

The coordination processes are followed with process activities that are emphasized by more exact and (usually) with more information exchange issues related to the actual software development processes. Understandably the shifting between these processes proceeds smoothly and the partners start to discuss in more detail their needs and offerings in the exchange phase.

For example the communications solutions software company (first level) used two globally competing channels (second level) that in their turn again have established an extensive distribution channel (third level) with their retail dealers (fourth level) for the end-users (fifth level). This chain of partners was actually a five-tier construct where the software company is the first and the end-user is the last fifth member in the chain. The software provider makes the contract only with the channel (second level) and receives orders for the packaged products from them to be delivered directly to the end-user. All the invoices and payments are made with the channel. This is an optimal arrangement from the software company’s perspective, as they just needed to fulfil the order. The channel makes the actual customer search, the sales work and they organize with the software provider joint marketing campaigns for certain customer segments. They also did the invoicing practically at the same moment when they received the order, as they had to start buying hardware and other material for the product, however the software was still the same. From the company’s viewpoint the delivery was seen to have happened when the retailer’s installer had installed the software with the associated hardware and the end-user had made the acceptance test.

In this case the software company has three different contract types with the channel:

• General subcontracting contract,

• Retail contract and

• Delivery contract for the international markets.

The focal company does not have any process models about contracting, as they have not thought about the issue in this manner, of how the things combine and what they actually include. These things have been directed and evolved from the channel’s direction. In other words the company has done the contractual things the way the channel has demanded. However, with IPR issues they have unambiguous clauses in the contracts that in all the projects whichever project they do, they keep the IPR as the company’s property.

The things that the software company has learned during this cooperation are that it affects: the software development process as the big channel operators need to establish a quality system for the software development process, and quality control process. The back ground of the company is also carefully checked. The supplier had to totally change their previous product documentation style and contents. These documents were previously only for internal use and the features of the applications were therefore not so well documented, as there were always experts in house that could solve the problems without extensive documentation. However, now when the product started to live its own life in the channel and the second level channel operator was responsible that their equipments and software worked properly in connection with their subcontractor’s application, they had to have more exact specification documents. The supplier had to be more careful than previously with their possible modifications and enhancements as they had to take in consideration the channel’s products and possible effects on these, too. This software company has set the target of 100 % to only deliver through the channels, but as they noted they will never get to this level as they are interested in participating in the development projects with their end-users in order to launch new COTS and MOTS type of applications.

In this case again it is hard to separate the COTS or MOTS type of business, as the implementation must be decided on a case-by-case basis. One of the main tasks for the software company was to keep the channel as well as the retailers happy and eager to market and sell the product. To help this partners made joint campaigns and they set sales goals together that were checked twice a year and once a year they had more in depth discussions about the sales targets.

Licensing. Along the framework contract the licensing agreements emerged as the most common contracting forms in software business. In this section two different paths that both include licensing are followed. The first mode of contractual negotiations using licensing is performed with the (delivery) channel operators, i.e. they either sell the licensed software as such to the end-users or they embed the software into their own application and offer this combination to the end-users (OEM channel or distributor licensing). In this case the combined application may include software from several software providers including the channel operator itself. The software may have different kinds of license agreements with their IPR-owners. This requires from the channel operator a careful consideration concerning all the needed license agreements and their formulations so that they are in concordance with each others, e.g. related to the duration, scope and liabilities. The second mode is the licensing agreements completed directly with the end-users, i.e. the software producing company handles the marketing, sales and after-care efforts itself (end-user or global licensing).

From the software companies studied both kinds of firms were found. Characteristic for these firms was that they also did their own marketing as well as using the channel in either of the described ways. Either the channel was used for direct sales purposes or as an embedded software (OEM) marketer. However, in all cases the software company also marketed and sold the application directly.

One special issue with COTS licensing compared e.g. to MOTS licensing is that the customer may stay totally unknown to the software company when the application is procured either from the retailer or directly downloaded from the Internet. In these cases the customer will only be known if the customer returns the registration card or communicates otherwise with the software producer.

OEM channel licensing. The license agreement negotiations are typically conducted with a new partner at the same time as the basic framework contract is drafted, or sometimes the channel-licensing contract is done alone without any special framework contract such as the license agreement being formulated in a framework contract fashion.

To finish the OEM channel licensing agreement may typically take from one week to half a year. This depends again on the possible previous relationship and experiences of working together in the past. In one of the cases where the company was in data management solutions business they only had standard products that were the same for everyone. The products could be downloaded from the Internet for evaluation purposes and their use is time restricted. In practice all the features are shown and the supplier is able with a license key (software enable key) to restrict the functionality, as they need. They also license the products with differently restricted versions. Typically the procurement is put together from the following components:

1. A software development kit that is a development license for a software development unit.

2. A technology license which is a license to procure a certain partial right of use from which the company gets the royalties in advance.

3. Customer’s consulting.

The company management said that license selling is their main business. They also add to this the license for maintenance under which they give different technical support and maintenance services. Most part of the turnover comes from royalties when the customer and partners sell their own bundled software to end-users. The partner reports the number of applications sold to the software company after every quarter. This is a favourable arrangement for the software provider as they do not need to meet the end-user and they do not even need to participate in the sales efforts among the customers. The company focuses its sales only on the developers who build the actual products embedding the licensed software into their own application.

The company also offers a special, but general in wording, evaluation-agreement document to be accepted before Internet download is allowed. In this document they grant a 30 day period for evaluation purposes with limited rights. The normal non-disclosure of confidential information is also present. The supplier company does not give any warranties and disclaims itself from all liabilities. They further state that "any legal action or proceeding arising under this Agreement will be brought exclusively in the federal or state courts situated in San Francisco County, California and the parties hereby consent to the personal jurisdiction and venue therein". It would be interesting to really find out the validity of this document as well as its legitimacy even though the person who has downloaded and pushed the accept-button admits to comply with these conditions.

One manager when asked about the contract negotiations said that the commencement of the process depends much on the partner (i.e. the OEM channel), as some prospective partners want to see the contract itself and the prices before they even start the technical evaluations. More typical is that the customer first does the evaluation and after that partners start the preliminary business level talks during which they draft a term sheet that includes the terms and conditions. It is a Letter of intent type two page long document where we have agreed in writing that the parties have understood in the same way the basic business rules.

Yearly based support, maintenance and service contracts are of interest as the software companies aspire to a long standing relationship in order to get constant revenue flow. One of the managers said:

In practice, all our customers are at least covered for one year by the support contract and we try to renew the contract every year. Our customers will receive regular upgrades and technical information letters where we give advice and tips. This is still relatively new but the upgrades and updates work on a regular basis, we deliver them daily if there is a need [G8].

We call, in this context, the renewal of contract (second round) the situation when the old customer comes back for new software procurement. This is either done under the existing framework contract or the customer and the supplier have not signed an agreement for a long-standing relationship. But in both cases the partners know each other from the past and (usually) must have good experiences in order to start a new undertaking together. This again shows the importance of taking good care of the existing customers as they represent great potential for further business. This also illustrates the benefit of framework contracting as the joint business issues have been understood and the partners do not need to conduct those negotiations anymore, but they can advance straight to negotiate about the licensing or other details. The supplier can use the existing old framework contract and just add to that contract a new product. They need only attach an annex or a schedule and all the other things are agreed in the old framework contract.

Distributor licensing. The company that develops and markets business intelligence software combines the licensing with framework contracting. The software company that develops telecommunications software for the Internet environment had produced a basic version of their license contract two-three years ago in a group of companies that had discussed the development of the IT-contracts. Using these distributor licencing templates as a background they made their own version utilizing the managers previous knowledge about software contracting and also model contracts from other companies. The contract drafts were later finalized with a lawyer who was acquainted with international contracting practices and had long experience in the line of business. The CEO further stated that:

In short I am responsible to the software business side of know-how and the lawyer is answerable to the juridical aspects of the contracts so it fulfils the requirements on international forums and it uses the right wording etc. [B1].

This can be said to be the typical approach for small start-up software companies when they acquire and produce their own contract templates. The manager, usually also the (co)owner of the company, gives industry specific knowledge to the contracts and the consulting lawyer then formulates the contracts to obey the juridical language. However, when the companies use outside expertise for this purpose the consulted lawyer still should be capable of understanding the specific industry and its peculiarities with the international law issues.

The CEO of a business intelligence software company described one case where they have been with their partner in a cooperation type of contractual situation before, but wanted to change and enhance the relationship in the direction of a channel relationship:

In this case we had a cooperation agreement with our partner and then we made a distributor (dealer) type of contract. With it we have taken the old cooperation further in a closer cooperation direction [E7].

This relationship was then strengthened and modified with a license agreement.

End-user licensing. In the case of the business intelligence software company they made the same kind of end-user license contracts with everyone. In the USA the lawyers prepare them. It includes the software license and the elements which are especially important in the USA and also the conditions concerning the deal and payments timetable, delivery timetable and how it will be done. The manager further stated that almost always the customers require changes to be made to the suggested license agreement, this is especially the case in the States where every big company has its own law department. Customer’s lawyers check it and usually change a clause or two.

Another case for the use of a framework contract for global licensing is e.g. when the customer is a globally operating multinational corporation with offices around the world. Then for the customer it is easier and resource saving to make the evaluation of the application under procurement once and then with the succeeding negotiations agree on the software and affiliated service prices, quantity discounts, service levels including maintenance etc. relevant issues that could be decided and agreed with a global license. This mode of operation may again follow two paths. The customer procures either all the applications through a central IT-department, or the customer’s individual units around the world are able to procure the application independently through local delivery channels, but utilizing the signed global framework contract.

Offer. During the business negotiations the managers or the sales representatives usually discuss with the customer the contract at the end of the negotiation process. It is done after the customer has found out that the product is interesting and suitable for them and corresponds to their requirements. This is promoted with demonstrations and with customer visits after which the software provider makes an offer and the customer subsequently accepts the offer. Actually, only after the customer has accepted the proposed offer do they present the contract. It is a license contract that also includes general business aspects.

The companies try to make the negotiating process to be same for all customers. They try to make the negotiating process as short as possible with as little work as possible. However, the life cycle of the process is totally different if the customer wants to enter into a formal competitive bidding process that may include several steps for success. First in the order there is the Request for Information (RFI), that is responded to with the required information and supporting sales calls etc. In a positive case this step is followed by the Request for Proposal (RFP) where the customer asks the supplier to provide a detailed offer according to the customer’s needs and specifications. Again in a positive case the software provider enters either into a deeper negotiation phase or the customer asks the software under procurement to be evaluated more thoroughly from a technical aspect or they ask for the whole application to be further piloted in an actual environment to be used.

However, as the managers stated it is usually quite standard sales process in these software products. To establish a long-standing and strong relationship it is important to understand what the cooperation is all about and how advantageously both parties experience the contract under drafting. As one of the managers stated that if it is a real win-win situation then the lawyers do not interfere, but if it so called “shotgun marriage”, so in these cases the juridical issues may take a long time to settle.

However, the need for contracts also depends on the requirements that customers put on the supplier, e.g. if the negotiated project demands from the supplier some efforts that include customisation, adding features, to change the company’s road maps, or to do some extensive testing. Then the software company is interested in getting some kind of formal commitment from the customer’s side as soon as possible, in the form of some preliminary contract. If the customer does not require things like these then the company would start the contract negotiations as late as possible. As a matter of fact in some cases stated that the firms would not like to draft a contract at all, just to use the end-user license agreement, where they state the customer’s rights to use the software. For the software company it would be the easiest way to handle the situation. Otherwise if they have to enter into thorough and hard contract negotiations then they must start to negotiate about business issues, terms of payment, disclaimers and what the security issues for both partners are.

The company producing telecommunications software for the Internet offers the software either directly to the customers through their dealers or directly from the software company’s Internet-site where the application is downloadable. In any procuring mode from the customer a signed license agreement is required that is typically a four page long document including statements about the granting of limited right of use and description of other rights and limitations. Interestingly the contract also covers the issues of the software upgrades. Also the copyright issues are depicted clearly with limited warranties and liabilities. The supplier entitles the customer to contact the supplier’s or its representative’s (VAR) customer support only if the customer has returned a filled registration card or done the registration via the Internet. This is required in order to get customer feedback and so that the supplier knows that they are giving a service to an authorized user. Termination of the contract includes a return of all material received back to the supplier.

6.4.4.3. Definition and production phases

The specification and development of the COTS software is typically done by the software company at their own expenses and without any contracts with buying customers, refer the concurrent development model in Section 2.2.2. Though there may be drafted contracts with the subcontractors for the software developer, these contracts did not emerge from the analysed data. Only in two cases did the interviewees reported existing subcontracts, but as they covered contracts with hardware producers they were not taken into this study.

6.4.4.4. Assessment phase and coordination processes

The companies do the after sales assessments differently. One typical pattern is that the companies tend to forget the made contracts after they have been signed, at least until the relationship encounters problems. Though in many cases in COTS business no real relationship it does not even exist as the product is just bought and installed for use without further cooperation needs. But as one of the managers stated:

We should watch the contract more often than we do. It is quite typical that in the daily work we complete the contract and then we forget it. But here in the USA the significance of the contract is mainly that we have agreed on paper about the liability issues. That is why we want to make these contracts. But of course we agree on provisions, commissions and other issues concerning the cooperation. In this matter it does not differ so much between Finland and the USA [E6].

The after-sales (after-care) activities may also have marketing purposes, e.g. one company even did it at the CEO level and he excused this by the fact that they had just recently entered the US markets and they wanted to show their presence and commitment. Usually this was done at the normal sales representative level. However, the customers were also important ones for further reference purposes and the companies also utilized them for marketing purposes. The companies ask their customers to speak in seminars and at different marketing occasions. Some suppliers even publish case-descriptions in their printed bulletins and also on their web sites. This helps the marketing but also benefits other users of the same applications with the common experiences.

Follow-up. Some companies do follow-up doing so called customer satisfaction surveys by calling their customers regularly. For example in one case they contact several hundred customers every month and they seek feedback from their customers by inquiring their satisfaction with the delivery process of the software and their contentment with the support provided by the software developer or by their distributors after the installation has been done. In the case where the distributor or OEM is the main channel for the software delivery also the channel and retailers do the after-sales. This again relieves the software company from this task. But they must still have some kind of connection with the end-users in order to sense the developments in the market. This can be done either through active contacts with retailers or with contact with end-users itself by arranging user-days etc. contact seminars.

Delivery problems. The environment and the basic way of conducting business in the USA is different from Finnish customs as in the USA the companies sell and market the product exceedingly hard even before it exists. More choices in the product selection exist. In some cases the managers had experienced that they had a different view from the partner software company on how the product should be developed together further and this created delivery problems. Also technical compatibility or other problems turned up, e.g. the software development platform was not simply sufficiently scalable. Even personal misunderstandings played a role and the chemistry did not work out. These were some important problems that the companies had encountered as they had started cooperation with local US companies.

Dissolving. These usually unforeseen events of relationship dissolving happen, though they are quite seldom, as our interviewees described. The dissolving of relationships depends on the partner’s changing interest in the cooperation. In one reported case in the customer company there was only one person who was interested and willing to get the contract signed, but the company as whole was not interested about the cooperation [E8]. As one of the managers noted:

Even if you have it on paper so what can you do? It is then a disappointment, you may get some financial compensation, but still I do not have the component as part of my services. It is lost time, you do not start to fight with the company you go and find a new one [C3].

This above statement emphasizes the fact that time is money and the companies are not eager to start fighting with their former partners about broken and unmet contracts. This again is a characteristic of the businesses like the software business where the companies do not have time to look behind. Instead they try to keep pace with the development and that is already demanding enough and resource consuming.

It is also interesting to notice how the dissolving of a relationship happens. These are cases where the partner company has ended its existence or its product line has been finished where the software company’s product was embedded. It is usual that the relationship just fades away without any extra notice and the partners just keep a low profile, no contacts, and promised things do not happen. In some cases the end of cooperation is not so easy as the partners have to agree on the remaining end-user issues and perhaps of some forms of financial compensation. But in the simplest case the supplier just informs the other party with an agreement that as the following issues have arisen or not, they must end the cooperation formally and after drafting and signing this document then it is all clear. However, the problem is that the cooperation just ends without any notice, but it can still emerge after years when e.g. the other customer company (why not also the software company) is bought and the new owner starts to check the existing valid contract portfolios.

One manager described the common reasons for relationship dissolving to be the case where the customer’s procurement budget is for some reason torn up, their champion of the project or of the whole relationship is changed, the customer company is bought by acquisition, the customer’s own development unit wants to produce the solution, or lastly the manager’s friends in another software company is interested in carrying an project. For the relationship to flourish the managers had the opinion that it is most important to get in contact with some management level person who has the cooperation as his responsibility, finds it important and is interested to make a contract and is also willing to do more than just the contract, in other words put the case forward. The contract signing is not a big deal but to make the cooperation work rationally, that takes work.

6.4.4.5. Governance and communication

But as many managers responded there is always the human factor that helps the relationship development process, even though, especially in this tumult business environment, the companies must be alert and prepared for changes in the people taking part in the relationship forming. This change is also problem during the contract negotiations as if they tend to last a longer time; the possibility grows that the key negotiators may change during the process, which again slows down the process.

The COO from the data management solutions provider explained the situation:

As usual the relationship tends to deepen and we have more and more projects together and we get new customers or new projects with the same customer. The relationship develops, but it depends on whether or not the same responsible people stay on the customer"s side or, if they change [J9].

Further the CEO of the business intelligence software provider noted:

The sales and contracting processes are easier of course when we have existing business relationships with the customer. Then it is considerably easier to sell as we have a satisfied customer as they do not have to go through these things about the company, is it a good company and are their products plausible. They just check how the products work and if they are suited to them and what do they get with the products. So everything goes much faster [E12].

The VARs (Value Added Reseller), OEMs, or Systems integrators are also targets and partners for the COTS application developers in order to gain a wider market base. One of the interviewed software companies described the role of their VARs and systems integrators as being their feet and scouts on the market who make the business with their local customers and they also know their needs best. They have it easier when visiting the customer’s premises doing product demonstrations. After they have got the deal with the customer, they also do the integration and implementation work that the software possible requires. In this operation mode it does not so much differ from the MOTS business described below as the line between the COTS and MOTS business is many times quite thin and depending more on the definition. The CEO of the security solutions provider finds the VARs and systems integrators as their important and close partners. On the other hand the OEMs again bundle the software product into their own solutions and the end-users get their security solutions in one box which helps the customer’s start as the security solutions are many times only done afterwards.

6.4.4.6. Conclusions

From the above interview extracts and from the subsequent discussion is clear that the two contractual forms of framework and license contracts have a central role in COTS software business. However, the business negotiations can be started in earnest after the NDA contracts have been signed to pave the way for trust connected to formal legal tools. Fig. 1 depicts the general form of the observed contracting process with connected contractual issues showing the multitude that the managers must administer in order to run their focal business correctly. The general form of COTS contracting can be found in the “Software contracting process” model, especially in the central parts of the interaction processes and their outputs with the effects and events that come continuously in the relationship from both partners’ side, i.e. customer and supplier. The communication channel is of utmost importance in a positively developing business relationship, as it enables both parties to always communicate in a proper manner when needed.

6.4.5.1. Negotiation phase and coordination processes

The analysis of the contracting process in tailored software business starts with the same contractual activities that were present in the previous COTS software business, i.e. the confidentiality issues, Fig. 30.

Non Disclosure Agreement. During the first phase of the negotiations the NDA contracting does not diverge from the previously analysed COTS environment with the usual timing, information exchange and other issues included in the start of the negotiation process. Though the relevance for the NDA contracting is still more meaningful as the tailored software development relationship is meant to be a long lasting cooperation effort during which the partners will and must disclose matters essential to their core business secrets and strategies.

One manager described the mentality difference between Finnish and American attitude on this matter:

To exchange information, the USA is a promised land for non disclosures. Here we must take them seriously. However, certain partners never sign NDAs and they are the venture capitalists, as they get useful information all the time, they cannot take that risk [to bind themselves with a NDA contract] [I10].

The NDA contract is an important and central element in forming and governing a long-standing relationship – during the first as well as later stages – from the point of view of information exchange. The turbulent business environment requires the companies to remember what is today seen as a friendly partner, can tomorrow be a competitor followed by an acquisition or a result of some other unexpected activity that changes the base of agreed cooperation. Thus from this perspective it is hard to aspire naively to free information distribution.

The tailored software business differs from the previously described COTS business in the contracting aspect, as the secrecy issues are usually included in the framework contract as an organic part of that. The NDA contract is usually renewed and specified in the framework contract.

Framework contract. The framework contract is a central part of the tailored software business as the customer and supplier aspire to a long-standing relationship with mutual commitment and understanding. The nature of the tailored software business also causes and requires long-standing interdependence from both partners side. The negotiation process follows with framework contract negotiations that actually are business negotiations during which the partners establish the foundation for their future cooperation and joint efforts. The framework contract is so important that e.g. one of the interviewed companies did not even start further specific project negotiations before they had signed a framework contract with their new customer. Concerning the indispensability of the framework contract one manager noted:

With the yearly [framework] contracts we can focus on the essential issues. Project or whatever the work there is, we do not need to remember in vain. The most important things here are the workload estimates, which the customer is interested in. The price and timetable is calculated from the workload estimates [L].

However, the company does not just stop there as they follow the yearly negotiation and possible contract revisions with smaller and less time-consuming meetings where they check every three to four months the joint project situation. They try to keep it quite smooth as the continuous assessment of the development helps the company to estimate its resource situation and future requirements as well as possible delivery problems and delays in the time schedule. This is also done from the future know-how need perspective, i.e. where the customer is directing its coming business and what expertise should the software producer obtain to keep pace with and anticipate the technology and business development.

The price level of the resources, i.e. hourly cost, in the framework contract is one of the negotiable issues. As one manager stated after all the price level as such is not a problem. In one case they had to negotiate as follows:

We have not had any problems with the contracts but one challenging negotiation issue was to negotiate the prices, software development prices to the level of Silicon Valley. We agreed that during this [first] contract period we will negotiate more market based prices, if only the parties are able to show references to what the market level is [F5].

The idea and rational behind the framework contract is that it includes the general conditions – the business issues. After the framework contract is drafted and signed the partners can continue with contracts with much shorter agreement texts focusing specially on the issue in question, i.e. the software and the timetables.

Before the companies start to discuss the contract issues in detail it can take months to conduct the preliminary business accentuated negotiations as one manager stated:

When we start to discuss with our new subcontracting client about the projects that we are going to do, it took about one and half months before we started to talk about an actual contract. The written contract was drafted using the customer"s contract model and we discussed and modified that. From the moment when we had the first draft document at hand it took some two months before the contract was signed. This is the so called framework contract that specifies our cooperation model, it also defines the costs, tools and the line of action in general [F1].

One of the software companies in question had obtained an ISO 9000 certificate that demands specific written procedures to be followed during the contracting practices. The company had to use it and the certifiers also check it when they audit the company, refer Fig. 31. The defined and standardized process is followed in detailed during the contracting process, as the management requires especially a commitment from both sides, so it is from the quality perspective important. This framework contract is written in the quality handbook. Actually this was the only really defined contracting process that was found in the case material.

The observation is that usually the framework contracts are drafted until further notice and they are discussed mostly after each larger project if any need has emerged for contract refinement or modifications. The yearly contract is mandatory in this focal company as in it the partners agree on the general business characteristics. However, as this company did comply with the ISO 9000 quality standards the yearly contract also had to be approved by an inspection procedure and the notations were made to the required quality protocols. For the first time it takes approximately three to four months to draft this contract and the CEO from the software company’s side participates in the negotiations, and it is they who communicate with the lawyers about possible modification needs. From the customer’s side the manager of the IT-department typically participates as well as company lawyers.

Teaming. Besides these business negotiations during the coordination phase the software companies also internally reason and select activities corresponding to possible future project needs with the experts that would form the project team. The team members would also participate when needed in the negotiations with the customer. This process could also be seen positively from the team commitment perspective as the team members could express their viewpoints about the time schedules and resources needed etc. and their know-how is thus appreciated. One manager stated that they try to avoid inferring in and disturbing the project people with their present work as the negotiations may extend over half a year before they start to make detailed specifications.

6.4.5.2. Negotiation phase and exchange processes

After the coordination part of the negotiations has been conducted the partners move to the exchange phase where they start to specify the future cooperation in more detail. The importance of the framework contracting is emphasized in the tailored software development business and this could also be found from the interviews as they mostly discussed the second or further contracting rounds and issues relevant in those cases. The subsequent contracting rounds are easier as the companies have established certain patterns of negotiating a contract. One manager said:

The previous joint project is assessed to see if any contractual issues have emerged that need modification in order to improve the prevailing framework contract. However, it is usually just to refine some details of the contract in order to serve better their purpose [B10].

It is also noteworthy that the duration shortens considerably as the companies have a certain frame to which they can refer. Further they have common experiences of doing things together in a certain way and no big problems from working together in the past have emerged. The same manager continued:

In practice it is so that when we have succeeded in opening the door and if the customer is satisfied with the results so they will for specific types of software projects turn to us [B9].

Project bid. After this formal procedure of framework contracting the software company is able to start to receive project bids from the new customer. Usually the bids are directed only to this focal software company as the lengthy framework contract negotiations have already been conducted for this purpose.

Offer. After receiving the project bid the software company prepares and sends an offer that subsequently is the base for further negotiations and possible modifications. These negotiations are done together with the project manager from the software company and with the customer’s IT-department and also with the representatives of the end-users of the customer organization. Next the software company either receives an order from the customer’s IT-department or from the buying organization. The difference between the order and assignment contract after the bid is received in one of the case companies is as follows, ref. Fig. 32.

Work order. The software company dispatches an inspected offer according to the previous negotiations with the customer and based on the customer’s bid. After the customer has received the offer it is examined and approved in the customer organization using its procurement procedures. The customer organization sends a work order in which they refer to the received and accepted offer document as well as to the prevailing framework contract where the partners have stated the general business terms. The software company starts the work according to the agreed offer. In this procedure the documents – offer and order – are signed only by the dispatching partner.

Assignment. The other procedure has the same initial stages with the software company sending the offer and then receiving an order from the customer. However, some customers want to further draft an assignment contract covering the project in further detail. From the contractual perspective this document resembles the offer with some minor contractual additions and both partners sign the document. These amendments are typically the issues rewritten from the offer, or there is an indication to the offer made and to the yearly framework contract. This is in a sense a more formal and exact document than the plain offer – order documents.

The software companies that subcontract tailored software for their customers can actually start the development work from any stage of the software development process. This also is a challenge for the software companies and requires their professionalism to give correct estimates of the resource needs and timetables in each stage of the process, be the stage ambiguous. The usual approach is that the software company must understand the situation and be able to divide the project in several stages from which the first ones should be able to be estimated for the resource needs in more detail than the subsequent ones. This is also the case when using the assignment contracts, in which the software company can specify in detail first the resource needs and timetables for the definition phase and then some crude estimates for the following specification and production phases. Again when the definition phase is over the supplier can give better estimates for the subsequent specification and production phases. This may include minor or even major changes and adjustments in the resource needs and overall timetables.

Project order. The framework contract is a general contract between the companies to which they refer in all necessary situations afterwards, in order not have to negotiate and write the long contracts all over again. This is followed by specific, but simpler contracts for the project purposes. In some companies the project order is used when the customer needs start quickly for the development work as in this case the partners do not go through these bid and offer stages. The possibility of using this type of contracting depends on the closeness of previous cooperation and the size of the new negotiated software. The project orders are fast to draft and their meaning increases as the partners’ relationship develops.

The framework contract does specify in general business terms the relationship including e.g. following issues: liabilities, responsibilities, operations model, costs, quality processes and the tools to be used in the project. Then in the work orders the partners describe more exactly what they are going to do in their joint project. One manager noted:

If a need emerges to change e.g. the work order so the developer can change it as in practice the timetables changes, estimation of the workload changes and the work itself changes. We have been able to discuss on that level quite flexibly, so it is done in practice on the project terms [F3].

To negotiate and draft a framework contract normally takes some four to five face-to-face meetings that last usually one hour each. However, the two first ones may even last a whole day. After that still several email discussions and draft modifications are required. The total time to contract signing may take two weeks time of work. Then the reward comes later, as the subsequent work orders just take a couple hours to negotiate with some additional email exchanges. The project (work) orders can even be developed without any face-to-face meetings. As one of the CEOs stated:

The framework contract is really the framework for the work to be done and it must be agreed upon in advance, as the customer needs to know that the required experts exist. So they know how many resources are allocated for their use [B3].

The project order is typically followed by specifications as described next.

6.4.5.3. Definition phase and exchange processes

The importance and existence of the definition phase is mainly found in the tailored software business and to some extent in the MOTS software business, too. This is due to the nature of the software development process under these modes of software production. The application development process characterizes the tailored software development process where the customer and supplier organizations usually together specify the new software to be developed. This also makes the lack of or insignificant appearance of other process types understandable, i.e. coordination and adaptation as during the definition phase of software development process the main emphasis is on the pure production work that is characterized especially by exchange processes as defined in the previous chapters. One manager also wanted to participate in the next phase negotiations when needed as he had the required knowledge – tacit knowledge – about the contracting process issues that were not explicitly written down in the contracts, he had the spirit of the cooperation in his possession:

I participate also at the beginning to the specification process, as I know the volume requirements etc. best, in order to relay the know-how about the framework contract further to the experts [B9].

As the software companies start to discuss and negotiate about the detailed specifications for the new application, there exist several approaches where:

1. The customer has adequately specified the project. The supplier’s role is then to start the work in a straightforward manner. Executing it according to the framework contracts agreed customer’s quality system and subsequently implementing the agreed testing, etc. agreed issues.

2. In most cases the customer has a certain idea or an overall view about what they want the application to accomplish. In this rough description of the required application the detailed specifications are done together with the customer.

3. In some cases the detailed specification work is done almost solely by the supplier, though with joint team-sessions with the customer’s representatives.

When the software company and the customer have agreed upon the specifications the supplier must check the resource needs as well as the availability of the resources at the required level of experience. As one CEO stated:

If we have allocated [in the framework contract] more resources in man months, so it is no problem as we can accomplish the work as agreed. But if the detailed plan exceeds e.g. the time schedule then we must start the negotiations to acquire more resources somewhere. The customer pays of course for this additional work [B5].

Specification. The estimation of the resources, timetable and other issues depend on the stage where the software company enters into the cooperation with the customer. If the software company starts with ambiguous descriptions concerning the application needed the fuzzier estimates are for the resource and time schedules. If the customer approaches with ready made exact specifications and they only require the development and production work, then the work in its total is more compact and the software company can give fairly exact estimates for the project. Still problems emerge in the understanding of the specifications delivered. This issue is again alleviated by the long-standing relationship during which the partners have worked together in various joint projects and learned each other’s work habits and standards to describe the future applications. Only after these negotiation and specification rounds the project team is able to start its software development work, the coding of the application software.

The separate projects are then agreed with so called project orders. That in some cases can even be oral, or just a short email, or in some cases it can be quite a formal document. Interestingly the oral orders may be as extensive as some man years long. This must require a good working relationship and trust between the partners. Though in one of the companies studied they have had the same flexibility in the past to start the development work just by oral orders. Though they had to abandon this practice after some problematic liability issues had emerged when the customer company had internally disputed the specifications of the ordered application. The procurement procedure may even vary with the same customer but with its different units.

One important question that arises frequently in the discussions is the exactness of the drafted contracts, i.e. how detailed and specific the contract can be. Here is one typical opinion of one interviewed CEO:

It is impossible to draft contracts that do not have gaps. It is hard to outline all the changing situations. During the contracting the customer company can have a friendly attitude and we draft the contract in good faith and in a good relationship. But it may happen that in the next situation the company is bought by a competitor and then the company changes and is hostile [I4].

The difference between new and old customers in the contracting process is that the software company’s management and employees perceive from past experience an idea and feeling about the customer’s behaviour pattern and from the customer’s so called “trigger sensitivity”. One manager stated that this is a big difference between Finnish and American attitudes to contracting. As the Finns do not draft the contract with the idea in mind that they will be later sued. However, the Americans always do it having in their mind that in future they will be sued in court based on this contract. It is also interesting that this also holds still in long-standing relationships, as noted by one CEO:

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].

Call for bid. The continuation of the negotiations after the specifications have been produced resembles the procedure depicted in Fig. 30. With the call for bid document the customer inquires a cost and time table estimation of the planned project. The customer is also typically interested in knowing who would be the software developers as they already have learned to know and work together with some specific software experts in the software company. For this reason also the software company is interested in keeping the specific teams intact for the given customer as it also helps the design and development processes considerably as the negotiating and working partners know each other beforehand. Moreover the technical environment and organizational characteristics are familiar.

The customer’s bid includes further estimations for the timetable for the work as well as the amount of different resources needed to fulfil the order. Only in some cases does the customer send an offer to other companies too and that is typically when the customer is procuring a new application with a specific state of the art technology know-how and they want to make a survey of possible new software developers. Of course, to ask for an offer from some other software companies in a normal relationship would be an expression of lack of confidence from the customer’s side and an indication of possible commencement of mistrust.

In fast and effective contracting the software company just accepts the call for bids and then they respond with an offer and the customer usually accepts it directly with a work order or the customer wants some assignment negotiations done. After the contract is done the software company files it and the work starts.

6.4.5.4. Production phase and exchange processes

During the production phase the exchange processes are emphasized, as was the case during the previous definition phase. The software company may use its own development processes or if agreed they can apply the customer’s process descriptions and practices in order to maintain the desired quality level and quality procedures. The managers noted that they do expressly adapt to the processes required by their customer’s. They may even be lighter process practices than their own if the customer so desires.

(Un)expected modification. The software development projects have one common problem and that is that the specifications change all the time. Thus the development team is required to make some change to it. These changes may be in their character unexpected modification needs or they may be anticipated and expected modification needs. The source of the change needs is important. If the customer comes out with the possible additional ideas that require the changes, then it is easer for the software company to change the contracts if even needed, as there is no need to assure the customer. One manager constated:

We have not needed to change the contract texts itself, but the estimations of the workload, timetables and of course the contents itself and also goals we have had to rewrite. This mainly depends on the fact that the projects depend on the customer’s timetables [F].

The discussions concerning the changes in specifications are a common activity. They are easier to accomplish if the customer’s needs initiates the change, especially when there are financial issues to agree. In some cases the project team is allowed to make some minor changes in the plans if they do not endanger the timetable. Though there is some freedom of action for the developers, they can decide how to do it, but they cannot decide what to do. This means that the developers are allowed to decide things concerning the implementation of the coding level whereas the functionality must be agreed on some other level, what the functionality is and what is accepted as right functioning and what is not. One manager noted that the less you give freedom to make decisions the better, as there always comes the question of responsibility.

But if the customer starts to overload the team with a need for change and there is a fear that the timetables will go over as they strain the team. Otherwise the managers would be alarmed and they would start the negotiations with the customer, as they know the contract best and the discussions which drafted the contract.

One relevant problem characterizing the software business is the fast developing environment that also affects the contracting processes as the work must be started and done even though the applicable standards are still evolving and changing. The customer and the supplier know this and they have to take this in consideration when drafting contracts. The drafting is not an easy task, as the partners do not always know the extent and issues to which the developing standards will change. One of the interviewed companies had to live with this kind of problems and the manager stated:

No standards exist on that [standardized specifications of the interface in question]. So we do the project in parallel and when we are able to freeze the interface, we perhaps need to make some modifications. However, as we are aware of that, we try to keep them separate, so it would not be a big job even though the interface would need some changes [F4].

Adaptations. As one manager said about the adaptations during the development process:

Seldom do we do any equipment investments. But if we develop it for a specific environment then the other party supplies the equipment needed for the other party’s use. This is the way that it works. Of course in some extreme situation you must buy the platform in order to be able to do the development work [I8].

During the production phase the main activity besides the software development process is communication between the partners, i.e. the developers and the representatives from the customer organization. During the normal project development work the developers have daily contact or they have weekly meetings with set mile stones. One of the managers had the opinion that between the developers the communication should be informal, but between the partner’s management it should be formal. This also depends on the business practice that the partners have developed over a longer time in the relationship. Though the acting and communication with the same partner defended the style of approach that the partners had done. As one of the managers noted, these customs have never been explicitly agreed on paper, i.e. how to act but they have in practice agreed on their business practices.

6.4.5.5. Assessment phase and coordination processes

The assessment phase is represented mainly by the coordination process type of activities. The activities during the assessment phase are post installation procedures with possible on site testing and training. After the accepted installation is done, the warranty period starts which has varying lengths. The managers reported warranty periods lasting from 90 days up until six months. One manager described their activities in this phase:

When the project is finished we get from the customer a written statement that the project is properly delivered and the results match the agreed quality level. We use a 90 days warranty period, starting from the delivery date [B7].

Contractually these issues have several possibilities, e.g. the customer may require the software supplier to do all testing and install the application delivered. However, the partners agree and try to write all these conditions in the contract and that the acknowledgement returns in a certain time period. Some companies understand the delivery as accepted if the customer has not indicated anything during agreed time period. In this case they do not require any explicit indication of the acceptance.

Evaluation of the delivery. The contracts include a mechanism with which the partners can check and make an evaluation of the delivery and compare it with the original contract text. Some companies use the attachment of the contract where they have included the detailed descriptions of the software. The contracts may include explicit requirement points where the partners can check how the delivered application corresponds to the agreed application. If the delivery does not correspond to that, then the partners must go back to the contract to check the possible sanctions. One manager described their custom of finding out when they had delivered the promised software; in the offer that they had sent to the customer they could see what elements have been specified. These issues could be about the documentation, commenting the code, the software described, what it includes and other relevant matters. Documents can also include training during and after the implementation.

The proper and commonly understood delivery date and acceptance of the delivery with the following warranty period is important from both partners’ perspectives as during the warranty period the mistakes and errors found in the software code are corrected by the supplier. As the warranty period is over the updates are done solely on the customer’s request and at the customer’s expense. The bug fixes are also done at the customer’s expense after the warranty period.

Contract enhancement. If the contract is found to be unsuccessful it may have already inflamed on some level the relationship between the partners. The partners could try to enhance the contract but if this is not possible or successful then the relationship does not work any more. The question is then if the contract itself is bad, did the contract give either side too extensive rights with too low a price? This is the question that one of the CEOs proposed:

If the other party has gained the benefit, why should they change? The bad contract is bad only from the one side’s perspective, not from the both. Seldom a situation exists where both parties admit that they have made a bad contract. Usually, in these situations there is one very content partner and one very discontent partner [I5].

The situation can be remedied only if the partners are engaged in some other business too, that may affect their common future. Then an intention to come back and try to neutralize the bad contract exists. If there is no other reason to continue together then the partner who has gained the advantage has no cause to come back. However, surely this will be the end of the relationship and the companies always have the problem of how to keep their reputation after these kinds of incidences.

The managers also saw that the change of the partners is like an evolution and the same thing is with their employees. The companies would not like change to happen all the time, as it is hard from the organization’s point of view. 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 client with whom the company has operated together for a long time. The managers further note that ideally there should be some change of the customer.

Feedback of the cooperation. The other issue that is dealt with during the assessment phase are the possible problems encountered in the relationship during the cooperation; the feedback of the cooperation is collected during the previous phases of the software development. The possible problems are discussed during or after the development process depending on the nature of the issues.

Dissolving of relationship. The managers similarly reported having had only few cases concerning the dissolving of relationship. They had the experience that usually business relationships dissolve on their own. They insisted that it is better to examine the contract so no obligations and liabilities remain that may bounce back after some time. If there is any possibility of that then it is better to check the contract thoroughly and end the contract with another contract that puts a formal end to the relationship.

The managers had a common view that seldom when they have entered into a contract they have needed to go back to the negotiations and open the contract for reappraisal. As one of the CEOs strongly stated:

When you have agreed upon the contract, it’s done and that’s it [I7].

6.4.5.6. Governance and communication

From the governance perspective what companies do after the contract is signed depends on how the contract has been negotiated and drafted. Usually, included in the contracts is a follow-up mechanism. Depending on if the contract is a non-recurrent nature or if some work orders are attached with mile stones and of a corresponding payment’ schedule. Those of course create natural checkpoints. Commonly the customers include in the contracts some clauses that indicate the level of professionalism that is required from the suppliers developing team as one of the CEOs remarked:

If the customers claim that we are not using professional experts then it is our duty to assert to them that in the contract we have clearly written terms that we offer professional expertise and the customer can usually check our employees for the project in question [B6].

For the larger projects the partners typically establish a steering group that could also be called the control group together with the project group. Both groups are defined in writing: who the project manager is in the software company, 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.

The duration of the contracting process varies much in the tailored software business as the developed application range varies considerably in several elements. But some of the managers were divided in the opinion that it takes several months to conduct typical negotiations with a new customer. This depends on the complexity; from three months to one year is easily the timetable. The negotiation process is put together from two conceptual parts:

But there are usually the business negotiations and contract negotiations, two stages. You cannot even detach them, if you wind up in a situation where you have to change something then it also easily affects the business construction and you must change that too [I2].

Indications also exist– this is in the later stages of the relationship development – that the software companies need more advice and support not on the legal aspects from the lawyers, but more on the commercial – technological issues. How the contract affects the whole organization depends on the contract type itself. If the contract is trivial then the impact depends on the size and level of the contract. If it is again tactical then it is a normal simple contract. However, if it is strategic then the drafting should start almost from the board level before you understand that you are positioning intentionally or unintentionally, as this may be a strategic question. The delicate situation described by one manager:

When you enter into a contract with certain partners and they are announced, then you must understand if it opens doors to also sell to the other competitors of the contracting party or does it close them effectively [I6].

6.4.5.7. Conclusions

The tailored software business differs from the COTS business significantly at least regarding the close cooperation and the duration of this relationship. These facts again urge for different contractual issues that enable and foster the emerging and developing relationship. In Fig. 30 the diversity of contractual issues the managers in tailored software business must handle can be seen. These elements can also be found in the “Software contracting process” model with all the depicted phases embedded in the models’ exchange processes and relevant outputs.

6.4.6.1. Negotiation phase and coordination processes

Depending on what the software provider’s business is, the contracting process also reflects the different parts of the company during and after the negotiations. These are e.g. the sales department, production, occasionally the product development, the whole administration and other business units.

Non Disclosure Agreement. As indicated in the previous COTS and tailored software sections covering the NDA contracts the software companies need to draft these documents in order to be able to openly discuss the business and application issues. This is especially important when the software companies are establishing their operations in a new business environment and culture, as is the case with Finnish firms opening their businesses in the USA. In this environment the Finnish companies have found it of utmost importance to comply the US business conventions and to secure right procedures they typically consult local lawyers with their NDA and other contract templates. One manager told:

First we sign the NDA. We have our own NDA template, but often it happens that the customer does not accept it. Especially if the customer is a big globally operating company, they just want to use their templates [D].

The NDA contract discussion emerges after a commercial play as one managers described the situation during the negotiations. The customer tells the software company in general terms what business they are in and what they are doing. After this preliminary information the software company assess the prospect customer from their business and strategy perspective. If the software company is still interested then they will draft the NDA contract that binds both partners. So the first phase of serious business talks and a contracting process is always the NDA.

Framework contract. The sales cycle in the MOTS business spans a long period of time and is filled with commercial terms that when these have been agreed on after that new follow-up contracts are more or less just a formality. One manager said the greatest challenge for them is to convince the customer that the technology they have is necessary and useful for the customer. After this idea has been sold, then all other things are in a way just minor points when the customer has decided that this is what they will need and do. Of course, during the sales phase the suppliers’ sales representatives often visit the customer often and they have learned from the customer’s processes and environment. Additionally they use email and Internet as well as video conferencing possibility for communication with the customer. The framework contracting is an equally used practice in the MOTS business, as it is in both the COTS and tailored software business, see Sections 6.4.4 and 6.4.5. In some companies the framework contracts were the same for both business modes (COTS and MOTS). This is true also with the licensing of the software as in COTS and MOTS business the software provider licenses, i.e. gives the right to the customer to use the application according to the written terms. In both modes the application software is still the supplier’s property.

6.4.6.2. Negotiation phase and exchange processes

The negotiation situation depends on the customer’s strategic position from the supplier’s point of view and the level at which the supplier is operating in the customer company. Here again at first the essence of the negotiations is usually characterized by sales and a future business development focus. After some time the customer’s technical people come into the picture, too. However, in some cases this is also a problem as one manager described:

Many times the problem is that there are too many technical people who want to know different kinds of things that do not belong to them at all and do not have any relevance concerning the solution [D1].

A typical contracting and development procedure in the MOTS software environment is close to the tailored software business. As previously discussed the characteristics of the MOTS software where the MOTS application typically encompasses from 70 – 80 percent completed, tested and elsewhere used software and the remaining 30 – 20 percent of the software is user dependent, i.e. it must be tailored for each specific customer environment. In this sense this software resembles the development work in total. As in the tailored software business the applications are typically custom built, large and more resource demanding compared to the MOTS software that especially seeks the advantage from the fact that even though the MOTS application may be the same in size or even bigger compared to the equivalent tailored software the MOTS applications producing company only needs to tailor some small part of the whole application for each of the customer’s needs.

The supplier’s know-how on how to implement and install the software increases during the work with previous customers. This also makes the contracting faster and easier as the supplier can use templates where they are able to include the required details and terms that they have learned from the previous cases. The supplier also understands the business environment of the application well as they are specialized not just in using some special technologies but they understand the customer’s business as well. It may be said that an efficient and skilful software company in the MOTS business understands and has the knowledge of both the required IT-technology as well as the business environment.

License. The MOTS license negotiations resemble the license negotiations of the COTS business, as the drafting process of the license agreement is done fairly closely together with the framework contract. In many cases these contracts are legally one and the same document. These license contracts have their different characteristics depending on the object of use as discussed below. The management sees the contract negotiations to be part of the actual sales negotiations. The usual thing to negotiate first is the price level of the whole effort. Subsequent issues of discussion are how much the supplier company will take part in the implementation process, how many licenses the customer procures in the first place and what the structure of the licenses is as a whole. After these issues have been agreed upon i.e. the commercial conditions have been decided then these contracts are quite standardized documents. So the successfully conducted preliminary business negotiations are important and decisive to start a joint project. In one case it was interesting to find out that the software company starts the cooperation with training sessions for the customers end-users which will also be the main position from which to evaluate the appropriateness of the application for their purposes.

In some cases the next step is to submit an internal order with that the company makes an in-house reservation of resources for the future delivery. This means that the sales department asks the company’s production to reserve resources for the possible deal. With this they ensure that in a certain specific timetable technical implementation is possible and the production appoints resources to it.

Technology transfer with OEM. The software company selling or procuring technology, i.e. technology transfer, must do the contracting very carefully as there are especially in new and unknown environments, potholes that the company cannot possibly understand or is not able to anticipate. One manager described the situation when Finnish companies establish their operations in the USA as follows:

Usually the Finnish company has the technical know-how and to modify this knowledge to marketing know-how is quite challenging for many of us Finns. In fact we close the window for marketing from the other competitors by having a good partner with whom we operate and who is considerably bigger than we are. They do not change [their partner] if we bring them added value, as it is a big operation to change after, as we have already implemented software.

Of course there are also other dangers. However, 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 habits. Of course we want to be seen also at the end-user, because this is again our industry brand building [D4-5].

Further from the technology-transfer the CEOs warned not to give too extensive rights to the partner deliberately or unintentionally. Often the partner tries to secure himself as extensive rights as possible just for safety reasons, even though they would never need to use them. In this way it is possible to close doors on other technology developers.

The contracting process unfolds according to the situation that can be characterized and examined through the following aspects: how clear and distinct is the technology in question, how well defined is the target customer group, is it a homogeneous group with the same kind of application and technology need? According to these parameters the company drafts a template that may be used for other customers as well. As one CEO noted:

This works in a retail business and it is much faster because then you only need to agree that here you have the product, price and the conditions and we start the same process that is attached to it [I3].

But if the business is mainly about a clear technology transfer then the company must take into an account to whom they transfer, what is their environment, what possible changes they should do as seldom the technology component is as such ready and applicable to the customer. The company must possibly make some modifications in the software and they must decide and agree on the sphere of responsibilities (liabilities), e.g. who is responsible if the technology (software) does not function as agreed. According to the CEOs these are things that are quite difficult to write down explicitly.

Delivery contract with distributor. Straightforward delivery contract based cooperation described by one manager unfolds as follows:

First we have the delivery contract in the first project. The customer has announced their need, we have made an offer, they have given an order and we have concluded the delivery contract. In this delivery contract we describe the system to be delivered, the content of the delivery, the properties. Then we describe the timetables and all these normal things [A1].

After receiving the order the supplier drafts a delivery contract together that is again negotiated to a detailed level with the customer. Here some modifications concerning the content, scope, timetable and price of the delivery can still emerge. All these possible changes are done in mutual understanding with the customer. At the same time the partners negotiate exact reciprocal liabilities, warranties and discuss about possible follow-up projects, launching, limitations etc.

Project contract with end-user. This is done to specify exactly the interface between the supplier’s application and the customer’s environment. The project contract in itself further describes the things that the supplier is going to specify in the project.

Again the MOTS business has similarities to the contracting with the COTS business as both use the licensing as the base contracting method. Also both businesses can be in both the channel business and in the direct sales to the end-user organizations. Of course, the different situation and customer/partner needs ask for separate contracts to be used even though they mostly have the same substance. One manager noted:

If it is a sales contract [to the end-user] then we include in it certain liabilities as well as restrictions for the delivery. If it is again a partnering contract then we try to do it a non-exclusive manner so that we can end the partnership if it does not work out [D7].

This non-exclusivity and restricted time period that the contract is effective are the central issues in the channel contract and the written clearly defined common goals are important too.

6.4.6.3. Definition phase and exchange processes

Specifications project. The software companies divide the customer projects typically in two parts. First the specifications project is done and after this the actual software development project in the production phase. The specification project must be done if the customer’s specifications are not exact and detailed enough when the preliminary discussions end. The obscurity of details prevents the supplier giving a binding exact work contract at this stage. There are also other reasons for the specification project as one CEO noted:

The specification project is usually done to synchronize the terminology and we are able to understand correctly the specifications [A3].

One company extensively did their MOTS software development using the following division of subprojects:

– Base product, 80 % part of the application that is same for every customer,

– The specification project to define the remaining 20 % of the application, i.e. the customisation part. This project defines exactly the interface with the customer environment as well as the required functionality of the application. This project is done under the project contract whereas the whole procurement is defined with a delivery contract where the partners describe and agree on the resources and timetables.

– The development project is done using the specifications produced in the previous subproject together with the end-user.

One central issue in contracting is the internal commitment building. In one of the companies it was done parallel to the contracting process by the task definition activity where the company was able to commit the project team and let them express their own professional views and their opinions on a realistic timetable and resource needs. The task definition is a very important part of the specification process and the supplier must at least give an estimation of how much time each task takes. They must also include some margin in the schedule as it always happens that some task is finished faster than anticipated and others take more time. According to their experience the smaller and shorter projects are riskier as there is no slack in the time schedule. In a bigger project there is always some margin to play with. As the CEO concluded:

We must define the interdependence of different tasks, which can run in parallel and which can run in a sequence. The change management should be planned in the project plans, but I think this is one of the most difficult issues to which I do not know if anybody has found a solution [B].

Otherwise the project management and cooperation is accompanied in this case company by weekly video-conferencing with the customer and the all the relevant documents are inspected jointly. The appropriately finished task can be verified by using these documents and by the delivered, functioning and tested software components. The same manager has much experience in the project business and he argued further that requirement engineering could be one solution in this direction. As he concluded, the software business lives all the time in great change and these things must be managed with an intrinsic touch, thus fixed process thinking does not work here.

Offer. If the start of the cooperation needed a specification project to be implemented this was followed by an offer to the customer based on the specifications and the negotiations conducted with the customer on the delivery and its description. This offer is not yet binding the software company, however with this document they mainly strive to depict what they would deliver to the customer including the costs of the application and the other services including in the delivery. The offer though, creates a basis for the possible work order.

This straightforward style is a typical way of action especially in situations where the customer and supplier have been working together for a longer period and they have a valid framework contract covering their relationship.

If we start a new project with the old customer it then depends on if it is a continuation of the previous one or some other joint project. In some cases it has been quite easy, we have just made an offer and they accepted the offer and then we started [D4-5].

In the Internet tools and platform software company case the company tries to make their offers as exact as possible. The following operation depends on the level of the specifications that the customer can deliver. If the specifications are exact enough then the supplier can start the development work in quite a straightforward manner, but in other cases they run first a pilot-case (quick and dirty as they call the method) with the customer together, where the details are more loosely defined. Especially when the project starts to cost and also in cases when the customer has to sell and adapt it to their own organization.

The pilot-case is a good approach, as then the software company is able to make the specifications exactly. This piloting is done after they have signed a formal contract, though it resembles a bid-offer style of contract. Only in some cases where the application is big they do otherwise conclude a more extensive contract, but it is seldom done as with this piloting the supplier tries to show their technological know-how and ability in order to get the customer convinced that the solution provided works.

Work order. After accepting the offer the customer makes a work order that is based on the submitted offer that is exactly according to the offer or perhaps the customer wants some additional negotiations to be made to augment some details in the offer.

The channel building with their OEM and distributor partners is similar to the COTS business. This produced difficulties to some extent in analysing the interviews as many times the discussion affected both business modes. This duality can be found in Appendix C where the case company’s business modes are indicated.

One manager described tailored software business as having the same problem of the ownership of the source code in this case:

The source code is of course ours and we do not deliver in any case. The delivery is based on our products and it includes to some extent tailor made software too, but most part of the software is our ready-made software [B12].

The MOTS type of delivery includes a system license contract that gives the customer a right to use the software. However, the actual sales process with the customer is again a systems sales process – i.e. tailored software sales process – during which the supplier defines the customer’s needs and the interface between the supplier’s proprietary software and the customer’s environment. Included in the systems sales, they describe the solution of how to solve the customer’s problem and its costs and the software components it includes as well as the delivery dates and places.

One manager described their approach with the customer to be first sales oriented:

First we have the sales representatives [with the customer] and then we emphasize the application part. Usually the sales people leave it then to the application experts for further specification to be done. The sales representatives just follow up the case later. However, first we are sales oriented, because we must wake up the need and in a manner of speaking to sense where and what the value added is that we are bringing there. If you do not find it [the value added] there is no use continuing [D2].

6.4.6.4. Production phase and exchange processes

The idea and advantage of the MOTS software development process is in its ability to realize the partially tailored application deliveries in the shortest possible time. In best cases the tailoring part of the software only takes one week to at most one-month. As the supplier carries out several deliveries then the time shortens and the company builds up their knowledge base. The first MOTS delivery may even take a couple of months. Then the developers start to learn the tailoring procedure and more about the common interface layer. According to one manager it takes three to four cases to learn the implementation process.

If the application in question is extensive then the companies utilized the phased offer. Where the first one may be a running version of one product or part of a product family. After the platform is properly installed and it is functioning well, then the supplier starts to define the specifications in detail for phase two and for phase three in more vague terms. Phase three specifications will later be defined again in more detail after phase two is fulfilled successfully. One manager described that they may have to depict in the offer an outline of the whole case, the products and the features that are included in the delivery. However, in the contract there are also issues that get more detailed on the way. If the project team encounters needs for changes in the specifications then it is usually the responsibility of the account manager and his counter part in the customer organization who are able to decide how to proceed. If it is extra work that is out side of the specifications then the financial side also comes into question. This again depends on the customer and if they have the possibility to make changes in the budget.

In the channel business as the companies have an existing framework contract they move fast as they do not have to negotiate the contract relationship with the end-user as the channel or systems integrator does if they do not have a proper framework contract. For the entrepreneur the interesting parts of the contracts are usually the general nature of the contract, delivery time schedules, liabilities and finance. Production is interested in the issues concerning when the application must be deliverable and whether or not the organization has the required components and does a need exist for further development. After this comes the implementation phase and how it will be taken care of and by whom.

The engineering software company used a so called application group during the sales efforts that defined the project what it should do for the customer. These people have a crucial role to define the process and technology, and to run the demos and demonstrations with the customer. The sales people though lead the sales effort. Then after these negotiations and specifications the special applications groups first do the tailoring part of the application as the base technology of their product A is so general that it expressly demands tailoring. The other developed and marketed product B is again sold as a ready-made packet on a CD-ROM and the customer is ready to use the application and its tools for their purposes. For application A the tailoring is without question at least 50 % and for the application the corresponding percentage is about 80 % ready made and 20 % is tailored. The application group is responsible for the whole project including the project management, start of the project and customer training.

6.4.6.5. Assessment phase and coordination processes

The software producing company may apply a certain engagement period with their channel operator, where the partners first do one specific project together and after some specific time period (e.g. one year) they analyse what both sides have achieved and learned from and during the relationship. After this probation period with hard facts the partners are in a better position to evaluate the outcomes of the relationships and they are able to end the relationship if so needed or they can just negotiate the terms again in order to better match the relevant business situation. Note by one manager:

I think, this is the best way to protect oneself, be it an agent contract or partnering contract, be non-exclusive for one year and then check the situation anew [D7].

Follow-up. The channel contracts are usually more specific with targets agreed in advance for sales volumes connected to exact reporting and payment milestones. The contracts must also include the possibility of auditing – usually done by a third party – if a situation of lack of confidence between the partners emerges. He noted further:

If it is a dealer contract and it has not worked out or they have not met what we have anticipated or the business field has changed, so it is no sounder. Firm acquisitions, or other unforeseeable competition issues may arise. Those are the things that matter [D7].

The successful partnering agreement releases both sides to start operating after the common plan i.e. both partners market and sell the same common concept. The companies have to regard how the environment is developing and the supplier should adapt to it thus taking the partners – i.e. the channel – into consideration and developing their software according to these developments. This line of action must be both ways, the channel feeding the software developer with developments emerging in the markets and general know-how gathered among the customers. Vice versa the supplier must take this data into an account and in a proper way use the information for further development and enhancement work of the MOTS software.

Some companies did the contract assessment regularly after each finished project in order to develop their contracting process, development process as well as their delivery process. But the most common situation among the interviewed companies was that they go back to the contracts and evaluate them only when the partners have come across some conflict situation. E.g. if the partners have agreed upon the division of commissions, so the rest of the cooperation works according to the contract. But in principle the partners need the contract when any kind of conflict emerges then it is good to have it at hand. But usually the contracts are not needed anymore after they have been signed. The partners return to them only when they have a problem. As one COO stated quite pertinently:

The main question in contracting is that during that process we negotiate the terms and the framework that we will use to operate within. It is an essential process. After we have done it we actually do not need it anymore [D9].

This reveals the second most important and imperative factor for the contracting process. The whole contracting event and process is an acquaintance and learning process for the prospective partners concerning their both organizations and the way these organizations are conducting their businesses. The first most important factor is of course the contract itself to describe the joint effort and on the other hand safeguarding the relationships from unexpected incidents.

During the assessment phase the partners evaluate their past doings and discuss possible future efforts. The information is collected all the time during the project either consciously or unconsciously and it depends on the company size and policy how these matters are collected and used afterwards. One VP explained their approach:

Fortunately we are a small firm and everybody knows what happens in the firm and these customer projects are big and important so the firm’s management follows them very closely [K4].

If so called bad and failing contracts emerge then according to the interviewees:

1. The interviewees only reported a few cases that had ended in a so-called bad contract.

2. The bad contracts we have in that sense, were that the price did not corresponded to the workload that we had to do. So in economic terms the contract has not been as good as it could have been [A8].

3. Bad contracts could just be those that have not brought so much money but they can be seen as providing learning and in the long run they have been good references [D7].

Evaluation of delivery. The as stated above the follow-up is not done systematically by every case company, this may be due to the fast growth and young age of the companies. But there were exceptions, e.g. the Internet tools and platform software company do the follow-up. The main reason behind this is that the turnover comes mainly from the licenses and they expressly pursue the idea that the more a company has license business the better their finances are. So they had greater interest in the customer projects being successful and they use the application extensively. The customer starts to build their solution on the supplier’s technology and if this installed application is successful and the customer takes it into operational use then suddenly they may need hundreds of new licenses. This makes them interested in the project’s quality.

6.4.6.6. Governance and communication

One of the governance structures used during the joint software project is a combination of a management group (also named as a control group) and a project group, where the former one consists of the management representatives from both companies. The project group managers are also represented in the control group in order to link both the groups and deliver the opinions and decisions both ways. The other members in the project group are developers and designers from both organizations, and as well as in some cases, the end-user representatives. One manager concluded:

Nowadays we always have the project and management groups. Whether the control groups function or not, well that is another matter [A7]?

If the project is not a very big one then the management group may just function via discussions and meetings arranged by phone and the representatives discuss issues that have emerged and make the decisions if they need to be made. They usually include matters such as what extra needs have been put forward and how they will affect the timetables and subsequent costs. The partners have to decide on these issues and they must make minutes from the discussions. After the minutes have been made the supplier will send them to the customer and if they do not react the supplier interprets them as accepted and includes them in the contract documents and in some formal cases they are even signed by both sides.

If some problems emerge during the development process the partners start to read these minutes in a backward order to check where we have made decisions and what. The minutes and their decisive role were not mentioned in the contracts and the CEO said that this should actually be added into the templates.

In some cases when the changes only affect the end product, but not the timetable and costs, then the customer’s project manager can decide, e.g. to add or delete some features to or from the application under development. If the changes affect the costs then as one CEO described:

If the changes affect the costs then we have a sliding percentage and that again depends on the project’s risk factor and its size. If the changes affect the costs then it must be accepted in the management group [A7].

The company producing engineering software used the strategy with their customers to train the end-users in order to teach them to be independent in the future from the supplier as the customer’s product develops and the planning know-how changes they must be able to maintain the solution themselves.

We usually start with training and the training changes itself smoothly to a consulting project, as we do not want to produce a too ready-made solution for the customer. The customer still has the planning know-how and we want to pull ourselves out of the project and we hope that it continues afterwards with customer’s own resources [K3].

The NDA contracts discussed previously are also during the later stages of the software development process. In one case the COO described their position in relation to these contracts. The customer and the supplier were cooperating in an applied development project. The governance structure is constructed in the early phases of the business negotiations and with signed NDA and other contracts. Then the "technique" experts administer and operate together from both companies. The negotiators – usually the managers – again check that the NDA contracts exist and also that formal levels on how to operate jointly exist.

Though the companies operate within their sensitive areas of business some problems in the relationship may emerge. With companies that the supplier knows better then everything usually runs well, and they even may skip these contractual issues. As one manager stated:

Our employees just state [during the software project] that as we have the basic NDA [contract] and these things go under it, so if you find any bugs just tell us or if some other issues come up. This works well. But the question is of course how close to each other’s core and competence these things go. This also depends on the person, does (s)he feel that he loses something [D11].

This again concerns the assessment procedures of the relationship. The contract evaluation, under the MOTS business, is basically done from several aspects depending on the business and the relationship where the partners are cooperating.

6.4.6.7. Conclusions

When summarizing the MOTS software development and sales business it is interestingly found to be a combination of both the COTS and tailored approaches. The business part has features from the COTS business in the different channel building work. This is supported with COTS type of licensing structures and important IPR issues as well. In addition to this, the tailored type of software sales includes an extensive customisation and specification part that may be needed in several rounds of bids and offers. During the development process the software is produced according to the mode of COTS business where the software company develops the software after its own specifications for further use and marketing. This ready-made part of the software is then complemented with the customized part of the software. This operation again resembles the tailored software development process. Fig. 33 depicts the phase and processual elements which are clearly visible in the “Software contracting process” model.