How to Assess a System Implementation Failure - To Salvage, or Rip & Replace?

This week I taught the AIIM Modern Records Management Master Class in Washington, DC. As with previous classes, there was a question that generated significant discussion among the students.

In this instance, the question was about a system implementation that was not successful:

“When you have a failed implementation, should you stick with it and try to make it work, or should you replace it with a better system?”

First, Determine if the Technology is Really the Issue

In our training courses, we teach that many implementations fail to meet organizations’ expectations, especially when it comes to user acceptance and uptake. There are many reasons for this, but the technology failing to meet business and functional requirements is almost never the issue. Rather, the problems generally stem from one or more of the following:

• Failure to Select the Correct Solution Based on Business Requirements. This *is* a technology issue and generally stems from a solution being procured by IT or even the business without consulting with other stakeholders like records management or legal. But almost all information management solutions can be made to meet most, if not all, business requirements for a particular type of solution or process. According to an IDC study, technology only accounts for 3% of all project failures.
• Lack of Senior Management Support: If management doesn’t support the initiative and the solution, neither will users.
• Failure to Define the Expected Outcome: In other words, many information management initiatives start with a technology solution, but without any real understanding of the expected outcomes, either from the technology or from the overall initiative. Related: even when those outcomes are defined as part of a business case, many organizations don’t follow through on those outcomes by measuring progress and taking corrective action.
• Failure to Plan: Effective project management is more than just Gantt charts and timelines. Rather, it’s the thinking that goes into creating the project plan, including identifying potential issues with timelines, resources, budgets, etc. Prior proper planning really does prevent poor performance.
• Failure to Provide Sufficient Resources: This could be insufficient staffing for the solution, not acquiring all of the modules or capabilities required, or even not acquiring enough licenses to go around.
• Failure to Get Users Involved: Users know their jobs and what needs to happen to get them done. This does not mean that there is never any room for improvement. However, users know the nuances of what is required to meet their specific requirements. Involving them early and often will help to get their buy-in and a sense of ownership, and generally results in an implementation that is more efficient, more effective, and more aligned to the needs of the organization. The opposite is also true.
• Failure to Take Change Management Requirements into Account: Too many organizations operate in a sort of command-and-control, top-down environment and assume that they can simply force a new solution and new way of working on their employees. This is not true; moreover, the organization cannot fire everyone – and the staff knows this.

There are other reasons, but these are some of the most significant ones.

Then, Consider the Following Observations

1. As noted in the first bullet point, technology is almost never the issue.
   
   
2. If the current system is “bad” because of all the other issues identified above, why would ANY new system be expected to be any better?

Determine if Change is Needed

There are any number of good reasons to change to a newer system: the technology is no longer supported by the provider, the organization is moving in a different strategic direction, the solution has become too expensive, etc. But changing because users don’t like the current system is not a good choice, because it will likely suffer from the same challenges and end up in the same place.

Conclusion

So the consensus from the class was to take a look at all those other things first. Assess the system and get information from users and stakeholders about why it’s so “bad.” Perhaps there are changes that can be made to the system configuration.

From a change management perspective, users can (and should!) be provided training, including regular refresher training. Management needs to set appropriate expectations and hold staff accountable; at the same time, staff needs to have their concerns heard and understood. And management needs to communicate those expectations, including the benefits and value of the system, on an ongoing basis.

By making these changes, the organization may determine that the incumbent solution really does, or can, meet its business needs, thereby saving significant amounts of time, money, and resources. And if the organization determines that a change *is* needed, making these changes will help to ensure that the new solution doesn’t suffer the same fate.