LESSONS LEARNED FROM A GOVERNMENT ERP FAILURE

Transcription

1 LESSONS LEARNED FROM A GOVERNMENT ERP FAILURE Copyright 2012 Panorama Consulting Solutions All Rights Reserved Cherry Creek North Drive Suite 720 Denver, CO Panorama-Consulting.com

2 It s no secret that ERP implementations fail at an alarmingly high rate. In fact, according to Panorama s 2012 ERP Report (available at the majority of organizations spend more time and money than expected. Most also fail to realize the business benefits that they anticipated. While this is an unfortunate reality across all industry verticals, it is especially true in the government and public sector, where a host of high-profile ERP failures have received significant media attention across the globe in recent years. For instance, Marin County, California recently invested more than $30 million in a SAP implementation with very little to show for it. According to public filings, the county scrapped the implementation, accusing its system integrator of fraud and misrepresentation during the sales cycle, providing inexperienced implementation consultants, and suggesting that the software had a high error rate all of which allegedly contributed to the massive failure. As is the case with this and other ERP failures, these challenges could and should have been avoided prior to implementation. In another high-profile ERP failure, the UK s National Health System recently pulled the plug on a ten-year and $20 billion initiative to automate health records and other business processes that would have affected 60 million beneficiaries. Instead of migrating to a single, centralized enterprise software solution to manage these processes in a standardized fashion, local health trusts and hospitals now will continue to reinvest in disparate and inconsistent systems. The government agency cited overly ambitious goals as one of the key factors for pulling the plug on the project, along with changing system specifications and competing priorities between day-today governance and operations and the needs of the ERP project. Unfortunately, these are but two examples of the many recent failed ERP implementations in the government and public sector. Some of these are moderate failures that lead to project cancellation and wasted budgets, while others are more extreme failures that lead to high-profile lawsuits, such as the case of Marin County. Panorama Consulting is frequently called upon to provide expert witness testimony for the more extreme failures in both the government space and the private sector. Throughout the years, our team has provided insights and lessons learned to legal teams involved in some of the highestprofile lawsuits and other legal actions in our industry. Our software independence, hands-on implementation experience with a wide range of ERP systems, proprietary research, and understanding of ERP implementation best practices has made us the de facto choice for attorneys and legal teams across the globe. As a result, we have seen and analyzed more than our fair share of ERP implementation failures. Page 1 of 9

3 Diagnosing the Failure at a State Government Organization One of our recent cases involved a large State in the United States. This particular government entity was on the verge of filing a lawsuit against its Tier I software vendor and systems integrator when the State s legal counsel brought in our team to conduct an extensive analysis of its implementation. As part of our discovery and analysis, we reviewed thousands of pages of documents, including business requirement documentation, project s, presentations, status reports, project plans, and reams of other information. Although we cannot provide the name of the client or the exact details of the case due to the confidentiality and legal sensitivity of our findings, we can share some universal lessons evident in this particular case. 1. Lack of due diligence during the ERP software evaluation and decision phase. This particular government entity had its mind set on one particular ERP system before it even fully understood its own requirements. It had backed itself into a bit of a corner because it had already invested tens of millions of dollars in a failed Tier I ERP implementation several years earlier. As a result, it leaned heavily toward one of the few remaining Tier I options without fully defining its business needs. Unfortunately, the project team and its system integrator eventually identified more than 400 gaps between the State s needs and the out-of-the-box software functionality. To add insult, most of these gaps were not identified until nearly two years into the implementation. Had these needs been identified and documented in the evaluation and selection phase of the project, it is likely that the State would have purchased a different ERP system. In addition, and as discussed below, the tardy business requirements definition led to huge customizations and cost overruns over the course of the failed implementation. As we explicated in the 2012 ERP Report, The costs of customization often come as a shock to implementing companies. Those who perform their due diligence of blueprinting and requirements gathering on the front end, however, will frequently find that the software chosen is a much better fit and requires less customization (and build-ons) to start providing benefits. Because of the poor management of this process, the State found itself in the rarefied category of extreme customization a level only 5-percent of companies reach. One of the flaws with the government purchasing model is that agencies submit blind RFIs and RFPs for enterprise and financial system replacements without fully defining their business requirements. Most of the government RFIs and RFPs we see are overly focused on cost and the vendor s track record of implementing at government entities. This approach Page 2 of 9

4 is flawed because it does not take unique regulatory and operational accounts into consideration, leading the organization to blindly choose a software solution based on largely irrelevant criteria. 11% 5% 4% Minor customiza5on (1-10% of code modified) Some customiza5on (11-25% of code modified) 38% Significant customiza5on (26-50% of code modified) 12% No customiza5on Extremely customized (Over 50% of code modified) 32% Completely customized, In- House developed, or Best- of- Breed solu5on [Source: Panorama Consulting Solutions 2012 ERP Report] 2. Fixed-price contract. A common misconception in the public sector is that fixed-price contracts will mitigate risk and cost. While this may seem true on the surface, our State client found this to be problematic. In the State s case, it requested and accepted a fixed-bid proposal from its large system integrator. The contract specified which critical project activities were in the system integrator s scope, as well as those that were assumed to be conducted by State employees. However, lack of State employee bandwidth and expertise led some of these critical project activities to slip, leading to project milestone and budgetary overruns. Similar to many of our other public-sector clients, the State found that its fixed-bid contract created conflicting incentives between its system integrator and its customer. In these types of arrangements, the system integrator is financially incentivized to cut scope, accelerate activities at the compromise of quality, and provide lower-cost resources to the project. What is intended to be a mechanism to mitigate and control an organization s risk instead ends up creating more problems than it helps resolve. In addition, these types of contractual arrangements often cause less sophisticated government executives and managers to Page 3 of 9

5 assume that they have, in essence, outsourced their entire ERP implementation, without fully realizing the hidden costs and resource requirements associated with the contract. 3. Poor business requirements and system design. As mentioned previously, our State client identified more than 400 gaps between its business requirements and the capabilities of its chosen financial ERP system. This is partially due to the fact that it was trying to forcefit a solution that wasn t necessarily a good fit for the organization. Other contributing factors included organizational resistance to the functionality of the new software and the embedded business processes, as well as poor management of scope and project controls. These three factors led the State to customize more of the software than it should have. The end result of the poor business requirements and design is that the solution was a sort of moving target. Needs were defined and changed as the implementation progressed, leading to massive cost and time overruns. In addition, while the State s chosen software vendor and system integrator had indicated that it could handle more than 90-percent of the State s needs (as outlined in the RFP) with little to no customization, the system turned out to need heavy customization as requirements became better defined. We find that most of our government clients wish to implement a vanilla, off-the-shelf ERP or financial system with very little to no customization. However, this task is impossible without a clear definition of an organization s detailed business requirements. In addition, we have found that complex government system implementations especially those with diverse business processes affecting large number of employees must conduct extensive business blueprinting in order for the project to succeed. Most RFIs and RFPs that we ve seen from government and public sector organizations inadequately define detailed business blueprinting and requirements, which leads to inaccurate or incomplete assumptions about scope, cost, time, and resource requirements. These deficiencies also tend to lead to software designs that are misaligned with the organization s operational and regulatory needs. 4. Inadequate project planning and controls. Project management is typically not a core competency of government organizations. However, strong project management, planning, governance, and controls are required to make any ERP implementation successful. Our State client began experiencing issues in this area when it established an unrealistic implementation timeline based on faulty assumptions, such as the number of resources required and how quickly State employees could help define and validate business requirements. These unrealistic expectations led to time and cost overruns from the start. The project also was not managed well once it was underway. Both the State and its system integrator failed to properly manage scope and milestones, and made choices to add the implementation of more modules to an already overly aggressive timeline and sign off on Page 4 of 9

6 extensive customization that was not necessarily required. In addition, the joint implementation team never established a formalized change control or sign-off process when team members wanted to change scope or customize the software, which led to scope creep outside the confines of the State s original RFP. Many of our government clients rightfully expect that their system integrators will ensure that the implementation contains proper project controls and governance. While this is true to some degree, organizations ultimately own their own ERP projects and have to recognize when there are breakdowns or shortcomings. They need to begin by first defining and validating a realistic project plan and monitoring the project timeline, scope and resources throughout the implementation. 5. Under-qualified project resources and poor project staffing. The effective implementation of financial and ERP systems at government entities requires a project staff with a strong set of tools, methodologies and experience to make the project successful. In its failed ERP implementation, our State client experienced problems with both its internal and external team resources. In the RFP response, the State s system integrator suggested that it would provide 60- to 70-percent of the total project resources required to make the implementation successful. This expectation was to mitigate the fact that the State s employees were not well-versed or experienced in ERP implementations, so would need to lean on their system integrator to provide the appropriate guidance and expertise. Once the implementation was underway, however, the system integrator staffed the project with half of the full-time equivalents (FTEs) outlined in the RFP response, while the State provided nearly twice as many staff members as had been recommended by the integrator. As discussed above, this was partially due to the perverse incentives of the fixed-cost arrangement between the State and its system integrator. The other contributing factor was that the system integrator sorely underestimated the resources required from the State s team. Instead of providing the 60- to 70-percent of the total project resources outlined in its RFP, the system integrator was providing just 12-percent by the final phase of the project. In addition to an understaffed project, the State also suffered from high turnover on the project team. The system integrator replaced several of its project managers throughout the project, some at the request of the State and others at the discretion of the integrator. In addition, several other team members turned over during the implementation, resulting in discontinuity, project delays, and ultimately cost and time overruns. We have found that finding and staffing the right project team is an extremely important and often underestimated activity, especially for government and public sector organizations. Page 5 of 9

7 However, many organizations don t focus enough on this critical success factor during the software selection and implementation planning phase and instead direct attention to finding the lowest cost software vendor with the most impressive overall track record in the public sector. While cost and track record are indeed important, they do little to ensure an effective implementation team with the right toolset, methodologies and experience to make the project successful. 6. Lack of attention to organizational change management. Change is hard for any organization, but especially so for employees in the government and public sector. Long employee tenures, outdated and well-entrenched legacy systems and business processes, and lack of employee incentive to embrace change are all factors that commonly increase a government organization s resistance to change. Without a clear and deliberate plan to help employees migrate from the as-is of their old processes and systems to their to-be, an ERP implementation literally has zero chance of succeeding. Even with the most perfectly designed, configured, and tested software solution, a government entity will not be successful if employees have not fully adopted and embraced the new ERP system and related business processes. There s no doubt that organizational change is hard and needs proper planning to address. Our 2012 ERP Report showed that 63-percent of companies experienced difficulty in addressing process and organizational change issues. 15% 13% 2% 48% Difficult Neutral Very Difficult Easy Very Easy 23% [Source: Panorama Consulting Solutions 2012 ERP Report] Page 6 of 9

8 In the case of our State client, it and its system integrator did not develop or execute a proper organizational change management, training and communications plan. Instead, the State relied heavily on canned and generic training materials provided by the system integrator, which did not take into account the State s unique business processes or software customizations. As a result, the training was largely irrelevant to the majority of the employees that were expected to use the new system. In addition, the State and its system integrator did not develop organizational change management activities outside of training. Although the changes associated with migrating from a mainframe-based legacy system to a fully modernized financial and ERP system were extreme, the project team did not communicate those changes until end-user training shortly before go-live. More specifically, the project team did not conduct a gap analysis between the as-is and to-be processes, develop a communication plan targeted for each of the impacted employee workgroups, create a benefits realization framework, or facilitate executive and stakeholder alignment, which all are critical to the success of an ERP implementation. The result of these oversights was extreme organizational resistance to the new system. Our experience and research shows that an effective organizational change management plan is of paramount importance to a government ERP software initiative. Unfortunately, most government buyers do not understand what organizational change management means or worse yet, don t consider this critical success factor at all during their RFP and evaluation process. Most often, the resulting outcome is that the government entity chooses a system integrator without considering its abilities to help in this area. Without a robust and effective organizational change management methodology, government ERP initiatives are destined to fail. Companies like Panorama that specialize in ERP and organizational change are depended on to provide effective organizational change management guidance to augment a system integrator s more technical and software competency. 7. Lack of independent verification and validation (IV&V) oversight. Government system implementations are typically very complex, costly and risky, which is often more than a single firm can effectively handle. As a result, most government entities leverage the services of independent verification and validation (IV&V) oversight experts to mitigate the risks discussed above. In this case, our State client did not leverage such assistance, which led to a host of problems, including mismanaged expectations, unrealistic plans, and several of the other issues previously discussed. The end result was a project that ran far over budget, took longer than expected, and fell very short of delivering the expected business benefits. In other words, the project failed. Had the State enacted services from an outside IV&V firm, it might not have experienced the issues it did. IV&V processes are typically the last line of defense to ensure that an Page 7 of 9

9 implementation project stays on track and protect it against failure. Even if the above six lessons had still occurred, an effective IV&V program would have identified and mitigated those risks as they developed. Using its proprietary implementation assessment and IV&V framework and methodology, Panorama often provides these services to its government and public sector clients (when we are not the prime project manager on their ERP or financial system implementations). Page 8 of 9

10 Conclusion At the end of the day, our State client did not fail in its financial ERP system implementation because of technological issues. Indeed, the chosen software had been successfully implemented at dozens of large government organizations in North America. It also chose a system integrator that had an attractive fixed-cost proposal and a strong track record at implementing at similar government organizations. The State failed because of issues related to people, business processes and project management. The seven lessons learned in this case can be used to ensure that a financial or ERP system implementation not only doesn t fail, but succeeds and delivers the anticipated business benefits within the expected budget and timeframe. About Panorama Consulting Solutions Panorama Consulting Solutions is an IT consulting firm specializing in the enterprise resource planning (ERP) market for mid- to large-sized organizations around the world. Independent of affiliation, Panorama facilitates the evaluation and selection of ERP software, manages ERP implementation, and expedites all related organizational change to ensure that each of its clients realize the full business benefits of their ERP systems. More information can be found on its website, Panorama-Consulting.com and Twitter feed, Twitter.com/PanoramaERP. Page 9 of 9