Open project scope: strategies for designing successful IT agreements

How to successfully define and manage open project scope in IT projects to allow for flexibility while at the same time minimising risks

IT projects where the scope of the services is – at least partially – open are now the rule rather than the exception. However, principals and contractors are frequently faced with specific challenges when considering how to design agreements for such projects. Fairly distributing risk usually requires individual, creative and project-related solutions.

Situation

Many IT projects are characterised by the fact that the products or solutions to be developed cannot yet be sufficiently specified at the time when the agreement is concluded. This harbours considerable risks for the principal: the development costs can get out of hand and the project may not lead to a satisfactory result. On the other hand, the contractor cannot be expected to promise a specific result for a fixed price or in the framework of a fixed budget cap without being provided with specific requirements. The contractor does not know what the later design of the product will be at this point in time either.

This problem is particularly common in (partially) agile projects. In order to counter this risk, these projects are sometimes artificially divided into many small "mini-waterfall" phases, each of which is regarded as an independent contract for a specific work result. Unfortunately this approach does not adequately reflect the reality of the project or the actual responsibilities.

What is more, a lock-in effect quickly arises, especially with larger projects. Even if there are contractually stipulated exit options, changing the provider during the course of an ongoing project is only possible – if at all – with considerable effort or financial losses, even if proper documentation is available (which is rarely the case in practice).

It is therefore advisable for the parties to work together at the start of the project to find a contractual framework that offers a balanced, viable solution for both sides despite conflicting interests.

Design options

The classic separation into a contract for services or a contract for a specific work result often falls short in IT projects where the scope is open. Contracts for services do not bind the contractor to a specific result, while contracts for a specific work result require a detailed description of the product – both are only suitable for dynamic IT projects in certain circumstances.

What are needed instead are hybrid contract models that leave room for flexibility and at the same time contain mechanisms to allow risk to be distributed fairly. The decisive factor here is the willingness of both parties to bear a certain degree of risk.

Broad scope and remuneration based on the time spent

One approach frequently chosen is to agree on a broad scope of services that is not limited to the provision of products specifically described. Instead it can be stipulated in the agreement that the contractor is to provide all products and services that serve the – possibly only roughly defined – project objective or which are related to it. This gives the principal the certainty of knowing that requirements which could not be specified at the outset can be taken into account during the course of the project.

In return, the contractor receives remuneration based on the time spent, i.e. all services actually provided are remunerated on the basis of daily rates. There is often no alternative to this option in projects where the scope is open as it offers the contractor planning certainty and prevents it having to carry out its calculations on the basis of guesswork.

Sharing the financial risk: daily rate degression

A remuneration model based on the time spent initially shifts the financial risk entirely to the principal. In order to create balance here, daily rate degression can be agreed, for example, which takes effect once certain budget limits are reached. The daily rate therefore decreases in steps as soon as the project exceeds predefined cost thresholds.

This degression should be designed in such a way that it motivates both sides to behave responsibly: the reduced daily rate must remain high enough for the principal to prevent it wanting to realise unnecessary or economically unreasonable additional requirements. At the same time, it should be low enough that the contractor has an interest of its own in staying within the budget – for example, by using powerful resources that work efficiently.

Experience has shown that setting suitable budget limits is challenging. A sound estimate by the contractor at the start of the project can serve as a useful basis here. Compared to fixed-price or lump-sum remuneration, the risks are, however, easier to manage.

Further control instruments

In addition to the financial design, the usual contractual control mechanisms should, of course, also be included. These include provisions on project management, cooperation and the process model as well as decision-making and escalation channels ("governance").

Key performance indicators (KPIs) are also useful – both for measuring qualitative criteria (e.g. via surveys of project participants) and for assessing compliance with schedules and milestones. These KPIs can be linked to bonus or malus provisions to create additional incentives for efficiency and quality.

Finally, it is important for both parties to ensure they both have balanced termination rights in the agreement. The contractor should be allowed to terminate the agreement, for example, if the principal persistently refuses to cooperate. The principal, in turn, should be able to withdraw from the project without giving reasons if key project objectives are not achieved or, if necessary, in return for payment of appropriate compensation for tied-up resources.

A contractual framework for IT projects where the scope is open that is acceptable for both parties requires careful consideration of interests and customisation 

The challenge with IT projects where the scope is open is to combine transparency and flexibility with a fair distribution of risk. If this is successful, even complex and dynamic IT projects are contractually manageable. It is "only" the details that then need to be clarified.

You can find out more about this in our blog series on IT projects (in German). You can subscribe to this blog series via the RSS feed to be informed about new posts.