When ERP projects go bad: Lessons for CFOs

Autopsies on government ERP project failures can uncover valuable insights for chief financial officers in the private sector, and a recent article from an industry consultant illuminates some of those lessons.

In a November article, Annalyn Evenstad of Denver IT consultant Panorama Consulting Solutions writes that few enterprise resource planning (ERP) system implementations are successful. She cites a Standish Group report that found only 6.4 percent of government and commercial IT projects with costs of at least $10 million were successful, with “successful” defined as being completed on time and on budget, and meeting user expectations.

Two examples of large IT project failures have helped shed light on ERP issues that other organizations may face, Evenstad writes. The U.S. Air Force abandoned an ERP implementation project called the Expeditionary Combat Support System in 2012, seven years and $1 billion after it began, because it would have had to spend billions more to make the system work. And in the United Kingdom in 2011, the National Health Service canceled its plan to provide electronic health records for every citizen, after nine years and $18.7 billion, because the health service judged the system unfit.

Evenstad makes several recommendations regarding ERP projects:

• Don’t let a software vendor select a pre-set configuration that doesn’t fit your organization, because “expensive customizations and modifications can occur,” she writes. Determine what’s best for your own unique requirements.
• Map out and understand your current processes before you select and configure the software. “Once you understand all of the current state processes, you can accept or modify these processes. After the processes are agreed upon, they create the foundation from which software is selected and drive software configuration.”
• Rework those processes with industry best practices in mind, but don’t treat the best practices as a cure-all for deep-rooted problems.
• Choose a project manager with proven project management experience rather than one who is an IT expert with no project management experience. Your project manager should have experience delivering projects on time and under budget. “While the project manager may not have adept IT skills, he or she knows how to recruit and leverage those who do,” writes Evenstad.
• When planning your ERP project, understand that it will take time, and push back if upper management requests an abbreviated implementation schedule.
• Use “organizational change management” and training to combat the lackadaisical attitudes of employees that most IT projects face. That includes setting the tone, factoring in user feedback as the initiative is designed and giving users a stake in the success of the ERP implementation. “Bringing users into the initiative, rather than foisting it upon them, allows for a smoother transition from status quo to the new processes.”
• Don’t shortchange your employee training, especially toward the end of the ERP implementation after so much energy has been devoted to making sure the software works. Even if the software is intuitive and similar to the old software, users need training. Competency exams can describe gaps between the current skills and the necessary skill level, helping training stay on point and relevant.

In a separate white paper, Panorama describes seven lessons learned from its analysis of an ERP implementation failure in a large U.S. state, which hired the consultant to examine the failure for a lawsuit it was preparing against a tier 1 software vendor and systems integrator. The consultant did not identify the state.

Panorama’s lessons learned were the following:

• Gaps between the state’s needs and the out-of-the-box software were not identified until after the ERP software evaluation and selection phase. Eventually, the project team and integrator identified more than 400 gaps, and most weren’t identified until nearly two years after implementation. That meant that more than 50 percent of the code had to be modified.
• The fixed-price contract created an incentive for the integrator to cut scope, speed up the work at the expense of quality and provide low-cost resources to the project.
• Because of poor business requirements and design, the state’s needs were defined and changed as the project progressed, creating a moving target along with massive cost and time overruns for unforeseen customization.
• Poor project planning and controls created an unrealistic implementation timeline, some unnecessary customization and scope creep.
• The project staff — both from the state and the integrator — was understaffed and under-qualified, with a high turnover rate. This led to a lack of continuity, delays and time and cost overruns.
• The project lacked a proper organizational change management plan to help the state’s employees move to the new ERP system from the old system and to embrace the change. Instead, canned training materials were used that were irrelevant for most of the employees.
• The state didn’t use an independent verification and validation consultant to ensure that the project stayed on track.