Large IT projects cannot be handled without the involvement of external service providers. Of course, the parties involved need a correspondingly detailed set of contracts as a basis for commissioning.
Conducting detailed contract negotiations has an invaluable advantage. The way of working in the project is worked through together, risk scenarios are discussed and how they would be managed. If this is omitted, an important phase of mutual scanning and getting to know each other before the actual project work starts is missing.
In any case, contract contents must cover the following topics:
- Goal and general conditions
- Description of results and road map
- Procedure model in general
- Tools used for
– Collaboration and documentation
– Requirements definition, development, test, operation
- Deliveries and services of the contractor
- Cooperation services of the client
- Remuneration for services
- Control, decisions, controlling
- Conflict settlement
- Rights and obligations of the contractual partners (before, during and after the project)
– Duties of care, warning and information
– Software maintenance and support
– Operation and support.
Passing on risk often backfires
Since the success of a project depends to a large extent on the performance of the external service provider, the effort to pass on the risk of success to the latter through contracts is understandable. However, if we look at the financial performance of such a company, we see that it has a relatively low level of capitalization. IT service companies finance themselves through contribution margins from ongoing sales. Even large IT groups can only compensate for fee reductions to a limited extent. In any case, liability for financial losses due to lost customer profits exceeds their financial capacity. No large company would sign a contract containing such an obligation.
This is even more true for smaller IT service providers. If such a company were to take the risk of signing such a contract, bankruptcy would be the inevitable consequence if liability were to arise. In this case, the continuation of the project would be almost impossible.
For this reason, clients are reluctant to apply the full rigor of contracts even in the case of serious performance deficiencies. Tough contracts won at the beginning at the expense of the contractor often impair the climate of cooperation, and in serious cases they regularly prove to be toothless. This makes it clear that the real damage resulting from a failed IT project is always much greater for the client than for the contractor, regardless of how the contract texts present it.
Lawyers know IT projects from a specific perspective
The drafting of contracts is a matter for lawyers. However, there is a fundamental problem here. Lawyers only know projects from contract negotiations and rarely have anything to do with normal project execution. Only projects that fail and perhaps even end up in court end up back with the lawyers. In such a situation, when continuation of the project is already ruled out anyway, „hard“ contract provisions are worth a lot. It is therefore only natural that lawyers look for hard hedging formulations, for example penalties and liability provisions. These provisions don’t matter in a project that goes reasonably well. Nor do they interfere.
If the only thing left to do in a failed project is to limit the financial damage, depending on the creditworthiness of the contractor, at least a little damage mitigation can be gained from such clauses. A legal dispute is shied away from, because the question of fault can only be clarified with a series of costly, time-consuming expert opinions whose statements are unpredictable. Therefore, such disputes usually end with an out-of-court settlement. The damage to the client is regularly far higher than can be gained in practice through penalties and liability claims. But the tougher the contractual clauses are formulated in favor of the client, the better the cards are in settlement negotiations.
The impact of contracts on project progress
Let us now turn to the effects of a contract on the „normal“ course of a project. The tougher the contractual provisions are and the more threatening they are for the contractor, the more the project managers, lawyers and claim managers at the contractor’s end are instructed by management to do everything in their power to avert threatening scenarios. As a precaution, they naturally try to compensate for concessions that had to be made during contract negotiations. This plan has a good chance of succeeding. There is no IT project in which the specifications and framework conditions given at the start of the project remain constant until the end of the project.
The more precisely everything was specified during the contract negotiations, the higher the probability that something will happen on the part of the customer that is not in accordance with the contract provisions. A classic example of this is the client’s cooperation. These are always necessary, the larger the project, the more so. The more pressure is exerted on the contractor during contract negotiations, the more the contractor will insist that the client’s cooperation services also be precisely defined. As the client, this is difficult to refuse. As soon as the first item in the customer’s list of obligations is not fulfilled, a domino effect is triggered.
The balance of power reverses in the course of an IT project
If, up to the time the order is placed and even in the first few months of the project, the client is the courted customer whose decisions count, then as the project progresses, the client develops a dependency on the employees of the external service provider who are now familiar with the subject matter. Eventually, the point is reached where the client’s greatest concern is that these key people may no longer be available. While in other industries, for example in the construction industry, the replaceability of service providers is high, this is not the case with IT projects.
After a relatively short time, the external employees are more familiar with the details than the client’s employees. Firstly, because they are usually highly qualified and highly motivated people, and secondly, because they are not caught up in the day-to-day business. They therefore acquire a solid knowledge of the requirements very quickly. Due to their routine and focus, they quickly become familiar with the subject matter and soon know more about it than an average clerk.
The client is therefore dependent on the contractor not withdrawing its key personnel. These people, who are all the more important as know-how carriers the less cooperation the customer has accepted, ultimately become aces in the power game between the contracting parties. Once this spiral is set in motion, the big end usually follows on its heels. New contract negotiations, now under significantly worse conditions for the client, who has his back to the wall, regulate the continuation of the project. After all, the project can now be completed, it will be finished later than planned and it will also be more expensive. It is not obvious that it was precisely the „great“ contract provisions at the beginning that made the problems significantly worse. Nor does anyone want to hear it at this point. It is also reasonable not to discuss the past now.
How should contracts be designed?
So when the parties involved draw up contracts, they should be oriented toward productive cooperation and regulate their modalities. As unsatisfactory as it may be if no fixed price can be agreed upon, the agreement of a procedure for price determination and for dealing with identified additional expenses is the more reasonable approach.
There are IT projects for which a fixed price agreement is possible and makes sense. This applies to the operation of a data center, the installation of hardware and standard software, or the handling of help lines. Penalties can also be defined there in such a way that they have a controlling effect on the contractor’s performance. It is only dangerous to apply an effective tool to the wrong object.
Contracts must enable constructive and productive cooperation. If a project is going well, then at best you look at the contract in the sense of „What have we agreed on this? – Aha, then we’ll do it like this!“
It is more beneficial for the client to rely on the economic interest of the contractor in a successful project than on penalties and liabilities in the event of failure. However, this requires understanding how an agile project works and acting accordingly.
Agile projects – the nightmare of classic contract designers
In general, the Standish Group’s figures prove that large IT projects in particular have a significantly better chance of success with an agile process model. While the tools of a classic work contract can be assumed to be universally known, the contract design for agile projects is not yet common knowledge. If a philosophy of project management is stipulated in project orders or contracts that contradicts an agile approach, the contractual partners either end up in a contract-free space or they constantly collide with contractual provisions that do not fit the actual approach.
In general, agile software development is based on effort allocation, since a fixed work charge cannot be defined due to the lack of a detailed description of the results. The resulting vagueness is regularly overestimated by all participants: Everyone knows from their own experience that fixed prices are regularly undermined by change requests. Therefore, an effort estimation with admitted bandwidth as well as a project control based on it by burn-down charts is the more honest and de facto also more effective method. However, one must be able to face the uncertainty made visible here, which not all clients are willing and able to do. This applies all the more if the implementation is not carried out by the company’s own IT department, but by an external company.
The central challenge can be formulated like this: Professional project management replaces detailed definition of results. Deviations are thus detected earlier than in classic projects. For this to work, suitable processes must be defined (also contractually) and lived. Agile projects require more project management skills, especially on the part of the customer.
Agile projects can therefore only succeed if there is active and knowledgeable participation by the customer. In the case of an external assignment, this applies not only to the user areas („business“), but also to the IT department of the client. Compared to a waterfall model, these end-to-end involvement services appear to be an additional expense. Whether this saving is lost again in later project phases due to rework is not known at the beginning. My own experience and that of all agile project managers shows that the actual total effort of well-managed agile projects is significantly lower than that of a classic project according to a waterfall model. However, the effort is distributed differently, namely fairly evenly over the entire duration. I have commented in more detail on questions of effort in Chapter 4.
The same applies: Agile procedures require trusting cooperation. For this, the willingness and ability for interdisciplinary work and social skills must be available among all participants.
What is the truly decisive success factor for agile IT projects?
In my experience, trust in the appropriateness of the realization partner’s efforts is a crucial success factor. Negotiating the waiver of features in order to stay within budget and the final deadline only works if the contractor’s estimated realization efforts are seen by the client as reasonable and understandable. Effort estimates that are regularly perceived as excessive may be due to architectural deficiencies and therefore may in fact be reasonable. In practice, however, these are usually interpreted as an indicator of unfair pricing by the contractor, leading to conflicts, mutual accusations and recriminations. These can only be resolved, if at all, by external expertise or – the more common case – resignation on the part of the client in view of the hopelessness of parting ways with the current contractor.
Contracts for work no longer work – a new paradigm is needed
The contract model must depart from the ideal of the work contract (transactional contract type: definition of a work to be created at a price fixed in advance) and implement „relational contracts“. Such contracts regulate the collaboration. Part of the agreements is the procedure for defining the desired result and the associated financial transactions.
A team of authors led by Nobel laureate Oliver Hart described this paradigm shift this way in the Harvard Business Review (September/October 2019):
- Traditional sales contracts do not work in complex strategic relationships where parties are highly interdependent, future events cannot be predicted, and flexibility and trust are necessary. Instead of fostering the collaborative relationships needed to address these challenges, traditional contracts undermine them.
- A relational contract lays the groundwork for trust, defines mutual goals, and establishes governance structures to harmonize the parties‘ expectations and interests over time.
- Relational contracts will never fully replace traditional transactional contracts, nor should they. But the process for agreeing a relational contract should be part of the contracting toolkit to govern highly complex relationships that require collaboration and flexibility.
Today, IT projects of a certain size fulfill exactly the requirements mentioned by Hart et al. It is therefore not surprising that they so often fail due to the application of traditional contract models. Karl Kraus once said that psychoanalysis is the disease it thinks it cures. I think something like that can rightly be said about many contracts that are supposed to ensure the success of an IT project.