The world of enterprise applications (ERP, CRM, BI and SCM apps) tells many stories of IT implementation - especially ERP solutions - disasters and are numerous and stunning in scale and frequency. These failures are so common that reading the literature on the subject leads to the conclusion that successes are in the small minority. In fact, one recent study estimated that only 6.7 percent of ERP projects are completed on time and within budget.


Companies routinely underestimate the complexity and difficulty of IT implementation projects. Among the most-cited reasons for implementation failures are:

  • Lack of a clear understanding of what the company wants to achieve
  • Lack of a detailed plan for achieving what the company wants
  • Underestimating the effort required by the company’s management and personnel
  • Unplanned reports, interfaces, forms and enhancements
  • Insufficient testing
  • Insufficient training of company personnel impacted by the project
  • Insufficient work done to overcome the natural resistance to the changes needed to adapt to the new systems
  • Incentives for the implementation provider to expand the project
  • Inadequate project management


The contract can promote success in three important ways. First, the contract can define key project details, including deliverables, milestones and acceptance criteria. Second, the contract can provide the process for how the parties will work together, including making changes and obtaining required approvals. Third, the contract can provide incentives for the service provider to achieve the company’s desired outcome.


Develop a project plan: A solid project plan would set forth a detailed list of activities, staffing, interim and final deliverables and associated milestones. The project plan should be linked to the contract through the use of defined terms and milestone dates from the contract. Each milestone should clearly identify all required completion criteria. Contentious milestone discussions often signal that the parties have not clearly defined and documented the project’s goals and scope.

Allocate responsibilities between the parties: This can be done using a matrix that details project activities and defines which party will be responsible for each activity. “Joint responsibility” should not be used since that may mean neither party will be in breach if there is a failure. Likewise, assumptions should be removed unless there is a clear outcome if an assumption fails. If there is a constraint that may be exceeded, it is best to have a clear change process and default pricing in case price changes cannot be agreed.

Choose a deal structure: The best choice of structure depends on the project, and the company’s skills, risks and service provider. Available structures fall into three main categories: “assist,” “deliver” and “shared risk.” Each structure has its own unique features.

In the assist structure, the service provider works at the company’s direction and is paid on a time and materials basis. This approach allows the company to start quickly and make changes at its discretion, but the company bears the entire risk of budget overruns and schedule delays.

In the deliver structure, the service provider commits to work according to a specified schedule for a fixed fee. This makes the service provider highly motivated to complete the project quickly and efficiently, but may result in the company having to sign change orders that increase the fixed fee and extend the schedule if the contract fails to clearly and completely define desired outcomes. These risks are heightened by the service provider’s financial incentive to understate scope and price to win the deal.

The shared risk structure is designed to reduce overall risk by aligning incentives and creating a spirit of partnership. It does this by establishing a target budget with shared risks and rewards if the service provider exceeds or stays within budget. For instance, the service provider’s hourly rate may be progressively discounted as it exceeds the target budget and, conversely, increased if it comes in under budget. However, like the deliver structure, the shared risk structure requires an up-front investment in carefully defining desired outcomes. The shared risk structure also requires more sophisticated contracting to address changes in scope and direction because of their impact on the target budget and incentives. This requires, among other things, defining clear boundaries between chargeable and non-chargeable changes.


Contractual processes and protections are only valuable if understood and properly applied by the parties. Objective counseling - e.g. by a lawyer or another qualified IT facilitator - supporting an ERP implementation project should train the company’s project team and key stakeholders on the key operational elements of the contract, including the importance of aligning project activities with the responsibility allocations in the contract, and documenting changes using contract processes and documents. The advisor should then periodically check in with the project team to make sure the project is staying on track and to address questions that arise from time to time that require legal interpretation and guidance. If disputes arise, the advisor should assist in promptly resolving those disputes to help foster a productive project environment.

While the success or failure of an ERP implementation project lies primarily with the operational, technical and business teams, a well-crafted, well-managed contract can dramatically increase the opportunity for success.