Contracting for ERP Implementation Success

Enterprise Resourcing Planning (ERP) systems have only grown in importance as companies undertake digital transformations and face increasing competitive pressures and legal compliance burdens. ERP systems revolutionized modern business by giving companies the ability to integrate and visualize data spread across their entire enterprises. Most companies are now aware of the value of ERP technologies and view them as essential for operating their businesses effectively.

Yet, despite the promise of ERP systems, projects to implement them often fail. The stories of failures are so numerous and the resulting losses so large in scale that the successes seem the small minority. One recent study estimated that only 16% of ERP projects were successful and 50% were challenged, meaning they faced budget and delivery date problems.¹ The reported costs of abandoned projects can be enormous, in some cases hundreds of millions of dollars. But the costs of an improperly implemented system are equally high. For a major candy maker and sports footwear company each reported $100 million in lost sales and significant drops in stock price due to problems in their new ERP systems.²

Understanding why these failures occur and what success looks like are critical to putting in place contract structures that promote success. This chapter will discuss some of the keys risks of ERP implementations and ways to mitigate them through effective preparation and contracting.

Background

Which companies might undertake ERP projects?

The size of the global market for ERP software is massive and expanding. The market was valued at US$44.47 billion in 2022 and is projected to grow from US$46.86 billion in 2023 to US$71.34 billion by 2030.³ Two main factors have spurred this growth. The first is the continued evolution of ERP technologies. In particular, SAP, Oracle, Microsoft and other industry players are investing vast amounts in new capabilities, such as AI-based and cloud-based solutions. Accordingly, even companies with existing ERP systems are undertaking implementation projects to obtain compelling new ERP technologies and/or upgrade their existing systems.

Second, as global companies and their customers increasingly rely on integrated technologies and far-flung supply chains, ERP systems are as important as ever to manage and integrate a company’s business resources.

What are the typical reasons for failure?

ERP is different from “normal” software implementation. The powerful capabilities of ERP solutions—the ability to transform the way a company operates and integrate disparate systems and data spread throughout the company—make ERP notoriously challenging to implement. Yet, despite the importance of ERP projects, companies routinely underestimate the complexity and demands of ERP implementations. As a result, the vast majority of such projects have failed. The following are some of the most common reasons ERP projects fail:

• Lack of Clear Understanding of What the Company Wants to Achieve. Companies often have ambitious, lofty enterprise goals for ERP projects but fail to appreciate the need for specific objectives. For instance, companies often do not understand:
  • • What are the specific business drivers for implementing the new ERP system?
    • What business results must the ERP project achieve for it to be considered a success? For instance, what level of integration with other systems is required?
    • What legacy systems will be retired and existing interfaces replicated?
    • Which "current" processes will be replaced by the "out-of-the-box" capabilities of the new system, and what current processes will need to be built into the new system through customizations?
• Lack of a Detailed and Feasible Plan for Achieving What the Company Wants. Many of the other failure factors discussed below stem from the failure of the project team to follow a detailed plan for the ERP project. However, it is difficult to create such a plan without the company having done a detailed review of its current and future state processes and IT environments to identify gaps and how they will be handled, legacy systems to be retained or decommissioned, required integrations with the new system and other technical and business requirements.
• Inadequate Project Management. An experienced project manager can facilitate getting timely business decisions so that the ERP project continues without delay or added cost.
• Underestimating the Effort Required by the Company's Management and Personnel. As noted earlier, without doing a detailed review of current/future state, it is hard to make a detailed plan, and, without a detailed plan, it is hard to assess and line up the required company stakeholders and subject matter experts to participate in the project, at the times when they are needed, while simultaneously taking care to perform their assigned job functions so that normal business can continue. This often results in project delays, overworked staff and turnover (which drains the pool of personnel with knowledge of the company's requirements).
• Insufficient Training of Impacted Company Personnel. Bad training can make it difficult for users to understand and create resistance to adopting the new system.
• Insufficient Testing. This leads to quality problems and can mask problems in training and meeting company business requirements. Often insufficient testing is a symptom of lack of resources or planning.

Recommendations for Promoting Project Success

As noted above, a key reason for ERP project failures is a lack of clear and thorough project planning. Accordingly, fundamental to promoting project success is making an appropriate, up-front investment of time and attention to project planning, including understanding what the company wants to achieve, how the company will achieve what it wants, and the resources and commitments necessary to effectively implement the project plan, and to crafting a comprehensive contract to achieve these things.

Understand the Business Case and Baseline the Current State. Prior to embarking on any ERP implementation, it is essential for a company to understand the goals and objectives of the project and define what “success” means for the company. For example, the goals and objectives may revolve around improved performance levels of essential business systems, which may include improving the speed and efficiency of those systems. The company’s goals and objective may be the implementation of additional capabilities, features and functionality, which may include enhanced abilities to capture, use and analyze data across the company’s enterprise. Alternatively, the company may want greater uniformity of systems and processes across the enterprise with the goal of more efficiently managing the company’s technology needs, retiring legacy systems and reducing its application portfolio.

In conjunction with developing the goals and objectives of an ERP project, it is important to consider the functional areas of the company that will be within the scope of the project at a granular level. Often, ERP systems touch and integrate with many and far-reaching areas of the company—potentially a wide-range of systems, including order processing systems, employee self-service portals and time clocks. A detailed assessment and understanding of the company’s current systems and process (and possibly those of suppliers and customers) is vital for creating an effective project plan that accounts for the necessary interconnectivity, interfaces and data-flow requirements of the future state system. A failure to adequately assess and plan can not only result in errors in an ERP system interface, but could also have downstream impacts on many other functional areas of the company.

Once the goals and objectives are clearly defined, diligence is required to validate existing system metrics as a baseline for setting the specifications for the future state system. To the extent historical data is lacking, consideration should be given on how to track and obtain required data.

The contract should include, among other things, a statement of work that reflects an understanding of the business case for the project, and clearly describes what “success” means and the goals and objectives of the project and those goals and objectives will be achieved, and project scope (e.g., the ERP modules to be implemented, legacy systems to be decommissioned), as further described below.

Understand the Commitment of the Necessary Resources. A clear and thorough project plan requires an appreciation of the time commitment required of the company stakeholders and subject matter experts and the system implementor, in light of the overall complexity of ERP implementation projects.

• Company Staffing Requirements. Detailed staffing requirements will give the company a clear picture of how and at what time(s) their internal resources are needed to make business decisions, test the solution or train, and help avoid the common pitfall of company managers underappreciating the project burdens on their resources.

As an example, implementation of ERP software often requires a transformation of business processes, as well as the implementation of new technology. The out-of-the-box capabilities of the new system need to be mapped to a company’s current in-scope business processes, so that business decisions can be made about how gaps or differences will be handled and how future processes will look. This can be a time-consuming, painstaking process requiring participation by a broad audience of company stakeholders and SMEs making decisions on everything from how invoices are produced and what they look like to how product specifications are created and maintained.

• Allocation of Responsibilities. While, as noted above, company involvement and the commitment of company resources is essential for success; also critical is a clear articulation of the roles and responsibilities of the provider. Though the provider’s role and commitments may vary depending upon the chosen deal structure, as described below, in general it is important for the contract to include customary terms around key personnel, staffing plans, comprehensive service descriptions and carefully circumscribed excuse of performance. Nevertheless, the delineation of responsibilities between provider and customer is particularly challenging in ERP implementations due to the heavy reliance on the customer’s subject matter experts and decision making.

The provider will often seek to mitigate its responsibilities through a litany of assumptions, dependencies upon the company and other factors the provider claims to be outside of its control. For the reasons state above, this is particularly true in contracts for ERP implementations. A careful read through the list of such assumptions and dependencies is needed to (A) avoid the provider having an overly broad ability to claim it should be excused for non-performance if an assumption or dependency is not met, and (B) to address what the consequences are when an assumption is incorrect or a dependency is not met and, thereby, mitigate the risk of unexpected additional costs.

In ERP projects, the waters become further muddied where the activities of a system integrator may impact the warranted functionality and features of the ERP software itself. Due to the complexity and long duration of ERP projects, a major issue can be determining where fault lies for a problem—either in the ERP software or in way the software was implemented. To mitigate this risk, the contract should address the responsibility of the provider for ERP software issues, including escalating issues to the software provider and applying and incorporating into the ERP solution any patches released during the project.

• Feasible Project Planning. In developing the project plan, feasibility is important since a rationale schedule will be need to provide adequate time for review, testing and training, and that helps avoid quality problems. Speed should not come at the expense of quality. As noted above, it will be less difficult to develop a detailed plan if a company has already done the work to review existing processes, identify gaps and decide what future processes will look like.

A Clear Project Methodology. Each system implementor may have a different methodology that it uses to implement ERP systems. These methodologies are usually regimented and divided into phases, starting with a phase involving the creation of high-level requirements and deliverables and moving phases involving progressively more detailed specifications. A signoff at each phase moves to the next phase. The names of each phase may differ among methodologies, but, in general, the phases are designed to be “funnel-like”, with subsequent phases providing increasing detailed results as the project progresses. The contract needs to clearly set forth the purpose, objectives and deliverables of each phase and how the phases interrelate.

Using a funnel-like methodology means that addressing process gaps or other requirements discovered after the “discovery and mapping” phase may be costly and time-consuming, requiring redoing the design, coding and testing of prior deliverables. Thus, project planning is needed to mitigate the risk of missing requirements or changes to designs in the early phases to prevent such follow-on ripple effects. In addition, the contract should set forth a clear process for review and signoff of all deliverables from a given phase and responsibility for rework of previous deliverables if such review turns up problems.

Choosing a Deal Structure to Align Incentives. Choosing the right deal structure—assist, deliver or shared risk, is critical to appropriately aligning the incentives of the parties. Identifying possible deal structures often depends on a company’s risk tolerance, its in-house IT capabilities, and its understanding of its current processes, process gaps, what processes need to change and resource requirements. Even if all structures are possible, each has its own pros and cons, including the following:

• Assist. Under this structure, the company retains the primary responsibility for project implementation, and the provider assists. This structure allows a company to start the project quickly and make changes at its discretion. However, the company bears the entire risk of cost overruns. This may work well for companies that have completed detailed project preparation work and have substantial internal resources with ERP experience.
• Deliver. In this structure, the provider commits to work to a specified completion date for a fixed fee. This encourages the provider to do the work quickly and efficiently (i.e., using the lowest cost resources). However, if the contract fails to clearly and completely define desired outcomes, the company may be hit with change orders that increase costs and delay completion. These risks are heightened by the provider's underlying financial incentive to understate scope and price to win the deal.
• Shared Risk. This structure is designed to reduce overall risk by aligning incentives and creating a spirit of partnership. This is done by establishing a target budget with shared risks and rewards if the provider exceeds or stays within the budget. For instance, the provider's hourly rate may be progressively discounted or increased based on whether it is above or below budget. However, like the deliver structure, shared risk requires the parties to carefully define desired outcomes. In addition, this structure requires a more sophisticated contract to address how changes in scope or timing impact the target budget and incentives, including a consideration of what changes are and are not chargeable.

Conclusion

ERP projects promise compelling benefits for companies, but failure rates are high. The enormous complexity exceeds “typical” IT projects and is often underestimated by companies. Careful and detailed planning is key to reducing project risks. A contract can position the project for success by providing a detailed project plan and a deal structure that aligns incentives on quality, cost and duration.

 

---

 

¹ 2020 article by Patrick Thibodeau citing a Standish Group report in TechTarget.com. https://www.techtarget.com/searcherp/news/252477642/For-one-company-an-ERP-project-failure-is-now-a-court-battle?Offer=abt_pubpro_AI-Insider.

² “10 Famous ERP Disasters, Dustups and Disappointment,” March 24, 2009 CIO Feature by Thomas Wailgum.

³ Enterprise Resource Planning [ERP] Software Market Size, 2030 (fortunebusinessinsights.com/enterprise-resource-planning-erp-software-market-102498)