Whether an IT project is going according to plan or is ready for acceptance is often determined by measuring it against milestones. This requires you to define clear milestones in the IT contract.
IT projects stand or fall on the clarity of their structure: Milestones provide predictability and concrete targets. A good IT contract specifies transparent milestones, defines clear success criteria and regulates the acceptance process.
Whether milestones are successfully achieved not only determines the overall success of the project, but often the remuneration as well. There is a lot in the contract to consider in this regard, not least because the (conscious) choice of contract type is enough to decide what course the project will take. In terms of the legal classification of milestones, there are considerable differences between the law on contracts for work and services (Werkvertrag) and other types of contract such as service contracts (Dienstvertrag). This article explains how to organise milestones and acceptance processes in a legally compliant manner so that milestones do not become stumbling blocks.
Milestones for monitoring progress and targeted project management
Milestones not only bring structure to an IT project; they are also used to precisely manage them. By defining milestones as interim goals in an IT contract, the contractual parties can assess on an ongoing basis, or at least at regular intervals, whether an IT project is progressing according to plan and make targeted adjustments if necessary. This increases planning certainty for clients, as they can identify any delays promptly. The result is that they do not have to wait until the day the project is scheduled to go live to find out about a problem and can discuss specific remedial measures with the contractor. In the event that a longer delay in achieving milestones or even the total failure of an IT project becomes apparent, clients can look for alternative solutions early on or extend the contracts for existing solutions.
Payment milestones: Linking achievement of targets and remuneration
The contractual parties in IT contracts often link payment of remuneration to the achievement of milestones. The parties can also only define selected milestones as payment milestones. By linking the successful and timely fulfilment of certain performance obligations with payment of remuneration in this way, a contractor is incentivised to comply with the corresponding contractual obligations.
The total remuneration for an IT project is usually divided into several instalments, each of which is linked to a payment milestone. Caution is required when allocating the remuneration instalments to the payment milestones: To ensure that there is an effective incentive for the contractor until the conclusion of an IT project, a substantial part of the remuneration should be linked to the final payment milestone. This is because if a client owes a significant portion of the remuneration for just the first payment milestones, only a small percentage will remain outstanding for the final milestone. In such a case, the contractor's monetary incentive to fulfil such a final milestone as agreed will be similarly low.
From the contractor's point of view, it is essential that payment milestones can be achieved by the contractor by its own efforts. This means that all the criteria agreed for achieving a milestone ideally can be fulfilled by the contractor on its own. Any project dependencies that play a role in the specific milestone should be clearly stated in the IT contract. The contractual parties should also regulate what the effect on the payment obligation and subsequent milestones will be if the contractor cannot complete a task required for a milestone because the client has not fulfilled a cooperation obligation on schedule. Such a provision is crucial for contractors not just with regard to payment milestones and not having to wait for payment through no fault of their own. Rather, such a mechanism plays an important role in liability issues relating to the delay or non-achievement of milestones in general.
What do contractual parties need to keep in mind to achieve clear and legally binding milestones in IT contracts?
In IT contracts, milestones form the interface between the service description and scheduling. The contractual parties combine certain tasks and (interim) results to create a milestone and assign a specific date to it. This can either be a specific date or a relative date (e.g. "four weeks after the start of the project" or "three months after the previous milestone").
For each milestone, the contractual parties should clearly describe the relevant tasks and results and define objective, verifiable criteria for when they are considered to have been successfully completed. It is also important that each of the required tasks and results is clearly assigned to one of the contractual parties. As banal as this may sound, milestone plans with long lists of tasks and deliverables without any allocation of responsibility are not uncommon in practice. In such cases, there is a risk of disputes over which contractual party is responsible for completing a task, which can significantly delay (and increase the cost of) a project. Acts of cooperation by the client that are required to achieve a milestone or other project dependencies should also be described in detail in the IT contract.
The contractual parties should also stipulate in the IT contract whether the dates given for the milestones are to be legally binding or are merely targets. The parties should also contractually clarify the legal consequences that will apply if a milestone is not achieved or is delayed. One structuring option is to provide for certain far-reaching legal consequences, such as a right of termination or rescission, only at particularly critical milestones.
Designing a practical review process
Regardless of whether the achievement of a milestone is marked by acceptance in the sense of a contract for work and services or by a release, the contractual parties should provide for a structured and documented process for this in the IT contract. Typically, this process is initiated when the contractor notifies the client of the conclusion of the relevant tasks and deliverables. Depending on the type of deliverables (e.g. software, manuals) and the available expertise, the client then reviews the work results – if necessary together with the contractor – and performs various tests (e.g. functional, integration or user acceptance tests). The IT contract should not only describe the individual test steps in detail, but also any test cases and which contractual parties will contribute (real or synthetic) test data.
In addition, the criteria used to determine whether a particular test has been passed should be objectively verifiable and clearly regulated in the contract. In the software sector, it is common to distinguish between different error categories, from minor to critical errors. Not every small error should automatically lead to a test being deemed failed or the acceptance/release of a milestone being denied. Nonetheless, the contractual parties should define threshold values in the IT contract above which even an accumulation of minor errors will lead to the failure of a test.
In addition to regulating the content of the tests in the IT contract, the contractual parties should define who has responsibility for the individual steps and their documentation. To prevent project delays or stoppages, the contract should also stipulate a maximum duration for the implementation of the individual test steps and an escalation mechanism in the event of differences of opinion.
Contract for work and services or service contract – these are the differences in milestones
The development or implementation of software in IT contracts is often subject to the law on contracts for work and services. In a contract for work and services (Werkvertrag), acceptance is a key issue to which the law attaches important legal consequences, such as the obligation to pay remuneration, the start of the limitation period for claims for defects and the transfer of risk, unless otherwise contractually agreed. From the contractor's point of view, it can be advantageous to divide the acceptance into multiple partial acceptances per milestone instead of a single overall acceptance after achieving the final milestone. Such an approach is particularly suitable for several independent sub-projects. Clients can also benefit from partial acceptances if they allow them to use modules that have already been accepted. Nevertheless, such an approach poses considerable risks from the client's perspective, especially in projects with many interfaces or interactions between the individual project parts. In such cases, a client would only be able to make limited complaints regarding defects in sub-projects that have already been accepted. For clients, therefore, a general acceptance is likely to be more favourable, or at least a final acceptance, which reviews the integration and interfaces between all (already accepted) sub-projects. In any case, the contractual parties should make a conscious choice and clearly agree the type of acceptance in the IT contract.
In a service contract (Dienstvertrag), by contrast, no acceptance is provided for by law, as it is not a particular result that is owed, but "merely" diligent work. This makes it all the more important in an IT contract subject to service contract law to contractually recreate an acceptance procedure as might appear in a contract for work and services. For example, the contractual parties can provide for the release of milestones based on specific criteria, to which in turn remuneration obligations or other contractual legal consequences are linked. Error categories and provisions to eliminate errors in connection with milestones can also be defined in IT service contracts.
Regardless of whether a contract for work and services or a service contract is concluded, it can be helpful for contractors to agree a legal fiction for acceptance in certain situations, for example if a work result is already being used by the client in productive operation or if there are massive delays in the acceptance process by the client.
In general, the more concretely and clearly milestones are regulated in the IT contract, the easier it is to avoid disputes between the contractual parties about the progress of the project and to precisely manage IT projects.
To summarise, the following specific recommended courses of action are helpful:
- Describe the relevant tasks and deliverables for each milestone and clearly assign them to one contractual party.
- Make a conscious decision as to which milestones are linked to remuneration payments. Ensure that the remuneration allocated to the various milestones is appropriate.
- Determine verifiable success criteria for each milestone and define suitable tests (e.g. functional, integration, user acceptance test) and test cases.
- Agree on a documented and structured review procedure, including records, error categories, roles, deadlines, escalation mechanisms.
- Classify errors (major vs. minor) and regulate their effects on acceptance/release and subsequent improvement.
- Make a conscious decision whether to base projects on contracts for work and services (Werkverträge) or on service contracts (Dienstverträge) and adjust the contractual provisions accordingly (acceptance vs. release).
- Regulate any acts of cooperation on the part of the client (e.g. providing test data, making decisions) and the consequences of delays.
In this blog series, we provide you with information about successful contract design for IT projects. We dedicate separate blog posts to key aspects of this, including topics such as
- Open source in IT projects
- The six most common mistakes in IT contracts
- Change management as a success factor for IT projects
- Open project scope: strategies for designing successful IT agreements
- Successfully managing IT projects – keeping an eye on project dependencies
- Cooperation obligations vs. responsibilities: acts of cooperation in IT projects
- Successful IT projects start with clear project contracts
