IT contracts are mostly only taken back out of the (digital) drawer when a project has already hit serious problems. In order to ensure that there are no nasty surprises at this time, there are a few things the parties should consider before signing the contract. When IT projects go wrong, it can cost companies dearly. This makes it all the more important to have a suitable IT contract acting as a safety net.
Ill-fitting templates
Unsuitable or generic contract templates that do not correctly reflect the IT project or the planned IT services are not an adequate basis for successful project implementation. An inconsistent jumble of different existing contracts that have evolved over time or uncoordinated, parallel workstreams for creating contracts also pose problems.
Such contracts can jeopardise the success of an IT project in several ways: Firstly, there is a high risk of contradictory provisions, which harbours considerable potential for conflict. Moreover, confusing, hard-to-read contracts often end up being left in a drawer somewhere, causing the project to drift further and further away from what was originally agreed in the contract. In such cases, a contract is usually only dug out again when a conflict arises, and only then does it become clear that contractually agreed deadlines have elapsed or other formal requirements have not been met, or that additional services have been provided without being documented by change requests. In addition, such contracts often do not meet the expectations of one or both parties. If the differing expectations only become apparent during the project itself or when the services are being provided, there is great potential for conflict. At this point, during an ongoing IT project, it is also usually difficult or at least significantly more expensive to make adjustments in line with expectations.
Only comprehensible to those in the know
Another common mistake in IT contracts is unclear wording that makes it difficult to understand who is supposed to do what without background information. Examples include cryptic service or project descriptions (often peppered with numerous abbreviations), a list of activities without these being assigned to one of the parties or a lack of clear allocation of responsibility, for example for certain milestones or sub-projects. This not only carries a high potential for conflict, but also poses a considerable financial risk if, for example, more or more extensive services were unintentionally promised in the contract. If disagreements arise after years of working on longer projects or over the course of longer contractual terms, it may also be difficult to understand what was originally meant by a particular phrase.
Important issues or frequent challenges are not addressed
When a contract has to be concluded under intense time pressure, there is a risk that important but unresolved issues or frequent challenges will not be addressed in the contract. Wording such as the following is also tricky
The parties will agree on [a project plan / business continuity plan / dispute resolution mechanism, etc.] within the first three months after conclusion of the contract.
The positive spirit of optimism at the start of an IT project often masks the fact that agreement has not yet been reached on all important points when drafting and negotiating the contract. If such a disagreement only becomes apparent when the project is already underway or when the services are being provided, the parties must seek a solution under great time pressure. Typically, at this point, an issue has already become emotional or conflict-laden. In cases like this, finding a solution often fails, which is why quite a few IT projects also fail.
Without suitable contractually defined processes such as dispute resolution procedures or change request procedures, project participants lack a contractual framework for dealing with certain situations. This means that frequent occurrences in IT projects, such as change requests or disagreements, cannot be addressed promptly and smoothly. This can lead to project stoppages, inconsistencies and drawn-out conflicts.
Unrealistic formal requirements
Strict formal requirements such as written form and short deadlines supposedly offer security, but harbour considerable risks if they do not reflect the reality of the project. For example, it is often unrealistic to expect all project communication to be in writing, as in practice a lot is communicated verbally or by email. This can lead to a "parallel regime" in which contractual requirements and project reality diverge completely. In the event of a conflict, there is then uncertainty as to whether, for example, a change request has been effectively agreed or whether a reminder regarding the (non-)performance of a duty of cooperation has been sent as agreed. Before concluding a contract, the parties should therefore consider for which situations (if any) strict written form (section 126 German Civil Code (BGB)) is really necessary or which alternative communication channels might be appropriate.
Contractual deadlines should also not be blindly copied from a template, but should be carefully selected with the specific IT project in mind. While deadlines that are too short lead to ongoing breaches of contract, deadlines that are too long can, in turn, lead to project delays.
Similarly, contractual requirements for project meetings and reporting requirements should be adapted to the complexity of the respective IT project and the available project resources. Regular meetings at various project levels and structured reporting are valuable for the success of an IT project. However, excessive meetings or reporting obligations can tie up project participants, who then have too little time for the "actual" project work.
Duties of cooperation and dependencies not sufficiently taken into account
A successful IT project is often only possible with the cooperation of the company that wants to carry out such a project, to a greater or lesser extent. The extent to which an IT project ties up a company's resources is not always taken into account when concluding a contract. This includes the provision of infrastructure and information or making sure contact persons are available. Another aspect that is often underestimated is how many decisions have to be made when implementing an IT project. Dependencies on other sub-projects or third parties are also often dealt with far too briefly in IT contracts.
Ultimately, it is important to clearly define the expectations of both parties regarding their respective involvement in the IT project in the contract.
Highly one-sided IT contracts
Negotiating an IT contract is not about "winning". Rather, the goal should be to draw up a balanced contract that enables both parties to successfully implement and complete an IT project together. A contract that is too one-sided carries the risk that the disadvantaged party will lack incentives to participate in the project to its fullest potential. If the contractual balance shifts too far to the disadvantage of one party, that party no longer has any leeway to accommodate the other party in the ongoing IT project, e.g. in the event of unforeseen changes.
Avoiding stumbling blocks in IT contracts
Overall, a sense of proportion is required when drafting IT contracts. In order to avoid tricky stumbling blocks and to put the IT project on the road to success and secure it contractually, the parties should ask themselves questions such as the following:
- Is the template really suitable for the planned IT project?
- Will the contract text still make sense three years into the project?
- Is there really agreement and a common understanding between the parties on all key issues?
- Are the formal requirements and deadlines appropriate for the planned activities?
- Have cooperation duties and dependencies been sufficiently taken into account?
- Are the contractual provisions heavily weighted in favour of one party or are they balanced?
Suitable IT contracts can contribute to the success of a project and support the parties in finding a solution should something go wrong in the IT project.
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.
