In times of digital transformation, German companies are carrying out numerous IT projects. Most companies acquire a software license (purchase license) or a time-limited right to use the software (Software as a Service) and implement it in the company, the group of companies or in a cloud operated or leased by the provider or the company. Classic examples of such larger IT projects are the introduction of Enterprise Resource Planning (“ERP”), Customer Relation Management (“CRM”) or Human Capital Management (“HCM”) systems as well as a supplier management platform. These often costly IT projects are prepared and implemented intensively over a long period of time. Nevertheless, their failure is unfortunately no exception in many cases. Project plans and budgets that are far exceeded often finish off the project in question. And this despite the fact that the IT project makes sense and would facilitate and optimize processes and workflows in the company or group of companies. However, why do useful IT projects fail so often?
This article deals with the classic obstacles of IT projects and explains how proper contractual arrangements can help avoid these obstacles.
Contract Documents
To this end, the article will first explain which contract the parties normally conclude for a major IT project and which provisions it usually contains. In addition to the main contract, there are other contractual documents. These will also be briefly examined below, before the obstacles and useful regulations for avoiding them are presented:
Main Contract
In practice, the company or group of companies buys or rents a software product and has it implemented either by the software provider or a third party (hereinafter collectively referred to as the “Implementation Partner“) either in its own data center or in a cloud. Most larger IT projects consist of different project phases. Often, there is also a staggered rollout across the entire group of companies. In most cases, therefore, it makes sense to conclude an IT project framework agreement (“framework agreement“). This is because a framework agreement regulates the fundamental cooperation between the parties by specifying certain general conditions that apply to all individual contracts concluded under the framework agreement (e.g., in the form of an SOW or a purchase order – see below). The framework agreement typically governs general requirements for performance, the company’s duties to cooperate, default, the warranty and liability of the implementation partner, and acceptance, provided that the implementation services or other services, as the case may be, constitute work performance within the meaning of Section 631 of the German Civil Code (BGB). In the case of works services, in contrast to services, success is owed. Indications of a works services are the agreement of a fixed price and regulations on acceptance. If the implementation partner provides services on a “time and material” basis, this is more likely to be a service.
If the software is also to be purchased or leased via the framework agreement, this should also contain provisions on the scope of the license or scope of use as well as on support, maintenance and service levels (e.g. on response times and, in the case of implementation in the cloud, on availability).
Statement of Works and Purchase Orders
In addition to the framework agreement, there are also so-called statements of works (“SOW”). This is the actual description of services. The SOW thus specifies which services the implementation partner will provide in the respective project phase. SOWs often also contain the schedule for the respective project phase. The SOW can also represent the individual order under the framework agreement. The organization of some companies may also require a purchase order to be triggered from the company’s ERP system. Only the individual contract – whether in the form of the SOW or a purchase order – initiates performance and payment obligations of the parties.
Data Processing Agreement
If the implementation partner and/or the software provider processes personal data of the company on its instructions and on its behalf, the parties must also conclude a data processing agreement.
Obstacle 1: Unclear and Contradictory Contract Drafting
Clear and unambiguous contractual provisions in which all contractual documents are interlinked contribute to the success of the IT project. Both parties must know at all times in the project who must perform which services or cooperate at which point in time (see also obstacle 5). For this reason, the SOW should only contain legal regulations, e.g., on liability or the legal consequences of delayed or omitted duties to cooperate, if in individual cases both parties expressly want an exception to the often long and intensively negotiated regulation in the framework agreement. Since the legal department or external legal advisors are only involved in the negotiation of the framework agreement and the SOWs are primarily coordinated within the project team, it is recommended that the framework agreement conclusively regulates the legal terms. Otherwise, there is a risk that contradictions between the SOW and the framework agreement will arise unnoticed during the course of the IT project.
The framework agreement should also establish an order of precedence between the individual contractual documents and the framework agreement should take precedence over the SOW. It is also advisable to agree on a model SOW during the framework agreement negotiations, which is attached to the framework agreement as an annex. This should already leave no room for the deviating agreement of legal regulations, in which the document primarily defines services, cooperation obligations and milestones and clarifies, for example, by means of a commentary, that legal framework conditions are conclusively regulated in the framework agreement and therefore no regulation is required in the SOW. This ensures that the project team does not unnoticedly and inadvertently include regulations in the SOW that deviate from or contradict the framework agreement.
And what about the validity of the parties’ general terms and conditions? Their validity should be excluded. After all, what is the point of the parties having negotiated the framework agreement intensively over several weeks and months if, in the end, the sentence “our terms and conditions of purchase apply” in the purchase order means that, in the worst case, the parties have agreed nothing at all. The best thing to do is to delete such sentences from the purchase order, if the respective ERP system allows for so much individualism. In any case, the framework agreement should stipulate that general terms and conditions of business and purchase are excluded even in the event that they are included by one of the parties in a later document, e.g. the purchase order.
Obstacle 2: No “Correct” Subject of Performance due to Imprecise Requirements
The clear regulation of the services to be provided by the implementation partner in the various project phases takes place in the SOW and is crucial for the success of the project. The better the company has defined its requirements for the IT solution beforehand, the more detailed the service can be described.
In practice, many IT projects fail due to a lack of requirements management. Often, requirements are drawn up by employees who are later not even involved in the implementation of the project. In the run-up to the project, the company should think carefully about who the stakeholders of the respective IT project are; they should develop the requirements together as a team in workshops. In the case of new types of software products and due to the nature of the project, it may be difficult to provide a precise description of services because, for example, these may only develop during the project or may change frequently. In these cases or in general, catch-all clauses can be helpful in addition to a precise performance description, provided that they can be enforced with the implementation partner. These oblige the implementation partner to provide all the services required to implement the software. In this way, no dispute can arise about the agreed scope of services, but it may make the project more expensive because it is more difficult for the implementation partner to calculate the price.
Obstacle 3: Inaccurate Acceptance Processes
If requirements are not defined correctly, it is not uncommon that a precise acceptance process is also lacking. Acceptance is only required for works services (see above under main contract). Acceptance must be precisely regulated, as it is of great legal significance. The warranty period starts to run with the acceptance. Often further payments depend on the acceptance.
In complex IT projects, tests can be useful and should precede acceptance and be regulated in detail in the framework agreement. Acceptance must be declared in the event of a successful test. It may also be advisable to classify errors that may occur during acceptance or the acceptance test, e.g., according to high, medium and low. This is because, according to the German Civil Code, acceptance may not be refused in the case of insignificant defects. But what does this mean in concrete terms for an IT project? Defect classes can be used to define insignificant defects and avoid disputes in the IT project.
Obstacle 4: Missing and Incorrect Project Communication
Proper communication in the IT project also contributes to its success. Cooperation should be specified in more detail in the framework agreement. To this end, the parties define committees and their members, which meet at specific intervals. It has proven useful to agree on at least one regular jour fix of the project team as well as one of the steering committee with the technical superiors. The steering committee should meet and make decisions whenever the project team is stuck in the process.
For these regular meetings to be useful, they should be well prepared. Usually, the implementation partner is responsible for the preparation by sending an agenda and, if necessary, preparing a presentation. The implementation partner should also prepare minutes of each “official” meeting of the agreed-upon committees. These are to be read carefully by the company and objected to if the company is of the opinion that discussion contents of the meeting are not reproduced correctly or completely. This procedure should be regulated in the framework agreement. The framework agreement should also stipulate that the contents of the minutes can only have legal effect if they are signed by both parties (see also obstacle 5).
Obstacle 5: Lack of Project Management
Projects can be very dynamic and often the time pressure is high. Therefore, good project management is the key to everything. The framework agreement should stipulate, among other things, that only written agreements in the form of formal change request procedures can change the subject of the service, milestones and compensation in particular. Otherwise, mere e-mails, which the project team presumably sends back and forth to each other several times a day, as well as unsigned minutes of meetings between the parties, could change the subject of the service(s), the performance time as well as the compensation. In the course of the project, such unmanaged behavior carries the high risk that none of the parties involved in the IT project will be able to track which services are owed at which point in time.
Only with good and proper project management, which also includes proper documentation, can the company, when push comes to shove, claim any penalties in the event of delay (see obstacle 7) or damages for poor performance. The burden of proof as to whether a claim exists and the amount of this claim lies with the company as the client – a burden that should not be underestimated in practice – not least in very dynamic IT projects. Discipline is required here from all those involved in the IT project. Delays and defects must be carefully documented. To facilitate project work, appropriate templates can be provided for change request and other procedures such as acceptance.
Obstacle 6: Sufficient Qualification of the Project Manager
During the implementation of the IT project, the project manager provided by the implementation partner is also crucial to the success of the IT project. The project manager must have the necessary technical skills and be able to lead all those involved in the IT project. The company can insist on a provision in the framework agreement that the implementation partner may only use sufficiently qualified, trained employees familiar with the IT project, whose qualifications must be proven, for example, by sending the CVs and further training measures. This provision should be supplemented by the right of the company to demand the replacement of individual employees of the implementation partner if there is good cause. The lack of professional qualification should be mentioned as a good cause. In the case of such regulations, special attention must be paid to the correct wording in order to not expose oneself to the problem of employee leasing.
Obstacle 7: IT Projects often take Longer than Planned and thus become More Expensive
Very few larger IT projects are implemented on time. When selecting an implementation partner, the company should critically question whether the project schedule and costs, which are usually only estimated at the time anyway, are realistic and plausible.
Frequently, the company has various obligations to cooperate in implementation projects that can only be realized jointly. The implementation partner is dependent on information and cooperation from the company. If this does not happen, or if it happens late or in poor quality, this effectively means a project stop that the company itself has caused. The company must therefore plan and deploy its own resources well. A small IT department will find it difficult to manage several large IT projects in parallel. To avoid any unpleasant commercial surprises, particular attention should be paid when drafting the framework agreement to the legal consequences in the event of failure to cooperate or delayed cooperation. Useful “liability limitations” should be agreed here and the implementation partner should be obligated to inform the company about the consequences of the omitted and delayed cooperation duty.
In order to encourage the implementation partner to meet firmly agreed deadlines or milestones, contractual penalties or at least provisions for liquidated damages in the event of delay can be useful. These make it easier for the company to be compensated for the damage in the event of a delay by at least waiving proof of the amount of the damage and requiring the implementation partner to pay certain “liquidated” damages (but see obstacle 5).
Conclusion
In the case of extensive IT projects, special attention should therefore be paid to the drafting of contracts so that, in the best case, obstacles can be countered with the help of good contractual arrangements. In addition, IT projects must be carefully planned. It is particularly important that all the company’s employees required for the IT project are involved at an early stage and on a permanent basis, and that the company has sufficient resources of its own to support the implementation partner to the extent required. The complexity of the IT project should not be underestimated. If the cost estimates and schedules of the individual implementation partners are then critically checked for plausibility when they are selected, nothing can really go wrong.