Three reasons software implementation projects fail
Software implementations fail for three main reasons. Here’s an overview of each as well as a solid plan to combat them.
Stop us when this sounds familiar: You’re responsible for implementing your company’s most strategic and complex information system, and things aren’t going well. Your project team is missing critical dates, the system is underperforming, or even worse, not functioning — and your anxiety level is through the roof.
Three reasons software implementations fail
We’ve found that software implementations tend to fail for three reasons: (1) lack of effective project governance, planning, and reporting, (2) an inability to finalize and document system design requirements, and (3) lack of comprehensive testing and change management. Let’s examine these pitfalls one by one and then look at how to address them.
1. Lack of effective project governance, planning, and reporting
Effective project governance is paramount to the success of any complex project because it identifies critical participants, defines the project’s oversight and governing framework, and fosters buy-in from senior management. It also helps in securing the appropriate resources for the project and addressing obstacles that are beyond the project team’s authority.
Effective project governance is paramount to the success of any complex project.
In many instances, projects may lack sufficient definition and planning due to the lack of a project charter, project plan, and other vital plans. These projects tend to move forward in an uncoordinated, ineffective manner, showing little progress.
And then, there’s project reporting, which is essential for keeping all stakeholders abreast of a project’s actual status. Project reporting and its resulting actions may be hampered due to issues with project governance, communication, and project management. As a result, project sponsors, senior management, and key stakeholders may be unaware of critical information and feel frustrated when projects fail.
2. Inability to finalize and document system requirements
Project teams often have difficulty finalizing and documenting system design requirements. In some instances, clients end up in an endless cycle of designing and prototyping, which may negatively affect implementation schedules. Project teams will often strive to achieve a comprehensive design at the onset, without progressive steps, which may be unrealistic or overwhelming to the integrator, leading to project delays. These delays shorten the time to complete other critical activities, such as testing and change management.
3. Lack of comprehensive testing and change management
Software providers/integrators typically suggest minimal testing and change management to minimize costs during the bidding process. Vendors tend to focus on end-user testing, without having separate testing phases for unit, integration, and performance. And oftentimes, clients don’t sufficiently test applications before software release, resulting in adoption, solution performance, and data integrity issues. All of these combined are a recipe for failure.
Change management is defined as “a systematic approach to dealing with the transition or transformation of an organization’s goals, processes, or technologies.” A component of change management involves extensive training within new applications. Companies should conduct training on systems that are as close as possible to production versions to be effective. Such training is ineffective if systems aren’t functioning or training is insufficient.
So, what can you do to salvage failing project?
Here are a few ideas:
Establish effective project governance, planning, and reporting
The goal of establishing strong project governance is to allow critical organizational resources to become invested in the project, provide a platform to enable these resources for input and guidance, and to secure essential resources necessary to execute the plan and to help overcome obstacles. Every effort should be made to establish a robust and effective project governance structure that includes the following entities: project sponsors, project steering committee, project manager, core team, extended core team, technical team, and vendor implementation team.
The project team, which includes the project manager and core team, is instrumental in defining and executing the project plan and ensuring timely and accurate project reports. The project manager should be knowledgeable, credible, independent, and able to develop comprehensive project plans and synthesize information from different sources to accurately communicate project status, issues, actions and risks to all stakeholders — most importantly to the project steering committee and sponsors. The core team performs the day-to-day activities that keep the project progressing as planned. They’re also responsible for supplying the project manager with feedback on project status.
The project manager is ultimately responsible for reporting the genuine progress of the project to all critical stakeholders on a regular basis. When reporting to project sponsors, the project manager should streamline reporting and recommendations to allow the team to focus on those items that are most critical to the project’s progress or success.
System design and documentation
Driving to a consensus on system design and configuration is always one of the most challenging parts of a software implementation project. We subscribe to the philosophy that “less and sooner is better than more and later.” By having a functional baseline solution early in the implementation, the team can learn about the solution’s internal structure, capabilities, and limitations while conducting comprehensive testing.
Driving to a consensus on system design and configuration is always one of the most challenging parts of a software implementation project.
The key is to minimize the system design and configuration to support enough functionality to push data through the primary productive process (e.g., order to cash process). Once the baseline functionality is in place, the project team should undertake training and commence with comprehensive testing. With this knowledge gained from the baseline solution, they can more accurately define and prioritize future functional needs and development efforts.
Lastly, the project team should prepare just enough documentation to communicate critical requirements to software developers, but not so much that it drains project resources and impedes progress. It’s best to focus resources on solution development and not documentation efforts during the design and development phase.
Testing and change management
Testing should not be limited to end-user testing but should also include unit, integration, and performance testing. The migration to the cloud, SaaS development, and solution integration have made testing even more critical, requiring the project team to perform more testing and have better controls over issue resolution and the tracking of software releases. The project team should conduct the same tests after each design cycle to ensure code changes haven’t affected previous functionality. We recommend formalizing the testing process by developing baseline test scripts. These scripts can be used to develop operating procedures and training documentation to support change management.
Software implementations are complex, but avoiding these three pitfalls is a good first step toward success. If you’re undergoing a software implementation and have questions, please give us a call.