Early Warning Signs, Critical Issues, and Corrective Measures

This blog post is the second in a series on Troubled ERP Implementations. Follow us on LinkedIn to get notified of new posts.

In my previous article I discussed the 5 necessary steps in rescuing a troubled ERP implementation. This article discusses the early warning signs that indicate your implementation is headed for trouble and provides proactive solutions to avert disaster. It also discusses the late danger signs of critical issues that indicate the need for radical action.

Introduction

It may seem odd to have to explain how to know when you have failed, but people get so invested in getting a project over the finish line they often don’t even recognize when they have ceased making any progress. There comes a point where it no longer makes sense to continue doing the same thing, one must stop and consider an alternative course of action.

If your ERP implementation is experiencing trouble, you may be wondering if you are simply suffering from the common struggles of complex implementations or if your project is headed toward failure. This article explores some of the early warning signs of failure and discusses how to recognize if your implementation is beyond simple course correction and requires more serious intervention.

Early Warning Signs of a Troubled ERP Implementation

It is not uncommon for an ERP implementation to experience trouble. If caught soon enough, most projects can recover with small course corrections. However, early prevention is impossible if you don’t know what to look for. Here are some of the most common early warning signs that indicate an implementation project may be headed for more serious trouble, and the solutions needed to keep your project on track.

Disagreement on the Scope

One of the most common problems with ERP implementations is scope creep. If the project leadership and other stakeholders are not in agreement regarding what is in scope of the implementation, you are headed for trouble.

There is a simple fix for this problem: refer to the charter, resolve any disagreements, and update the charter to document the agreed upon scope.

Undefined Processes

The primary purpose for ERP software is to enable people to efficiently execute business processes. All ERP implementations should focus first on defining the business processes that are within the scope of the implementation. If consultants or IT staff are trying to gather business requirements without first having documentation of the business process in question, this is a warning sign that your business processes may not get properly implemented.

The course correction for this is to document your as-is processes. The process documentation needs to include the goal for the process, the process owner, the process participants, the steps necessary to complete the process, any pain points or known opportunities for improvement, and any non-negotiable requirements for the process.

Once the as-is process is documented, you can begin to focus on what changes can or should be made to the process and the requirements related to those changes. The final step is to document the to-be process complete with steps and requirements.

Undefined Requirements

I find it quite astounding how many times I have come into a troubled project and asked for the requirements, only to find out they either have no requirements or they have a spreadsheet with an outdated list nobody has referenced for months. Requirements gathering and analysis should occur from the very beginning of your ERP implementation and continue until late into the project. You should have a managed list of high-level requirements used for software selection that is continuously referenced and refined throughout the entire project.

You must have a formal requirements management plan that includes gathering, analyzing, approving, and testing throughout the project to have any significant chance for success. If you do not have a list of requirements and a formal means of managing them, you are headed for trouble.

Unexpected Gaps

It happens quite often. During the sales demos you see a great feature that will really meet your needs, but when it comes time to implement the software you find out the feature doesn’t actually exist. It was just some “smoke and mirrors” used by the sales rep to compensate for a gap in the software. Several of these things are “nice-to-have” but do not impact the usefulness of the system. At times however, these gaps can be quite significant.

If there are significant gaps in expected functionality, it is important to quickly assess the impact. It may mean simply removing a “nice-to-have” from scope, but it may also mean sizable customization or extensive manual work arounds.

We recommend a thorough gap analysis during the ERP selection process, and continuing the gap analysis during the process design and requirements analysis activities. It is critical to identify gaps as early as possible and determine the cost to fill or work around those gaps. If not addressed early, this can become a significant risk to the implementation.

Lack of Adequate Leadership

There are two levels of leadership that must be engaged for a successful ERP implementation: executive leadership and business process owners.

Executive Leadership

It is a well-documented fact[1] that executive leadership is crucial to ERP implementation success. This is an excepted best practice that should immediately raise a red flag as soon as the lack of executive involvement is recognized.

Here are some of the signs of a lack of executive leadership:

• Failure to define an executive sponsor for the project
• Lack of a steering committee
• Lack of participation with the steering committee
• Lack of knowledge regarding scope, expected outcomes, cost, or status of the project

Business Process Owner

Another level of leadership required for success is the business process owner (BPO). Often, the BPO is a mid-level manager who is responsible for defining processes. They may not be on the executive team, and they may not actually execute the processes. However, the BPO is critical to success because they are the ones to provide the vision for the “to-be” processes and make the decisions regarding scope and requirements priorities.

If the BPO is not involved in the process design, requirements evaluation, or solution design, this should be a warning sign. We recommend that the BPO even learn the software and demonstrate the approved process design and solution as part of the final sign-off on the solution design. This may not be feasible in some instances, but the BPO must provide a vision for the future of their area of responsibility, a clear understanding of the requirements, and a solid grasp of the proposed solutions to meet those requirements.

General Decision Making

Just because the executive sponsor and BPO are involved doesn’t mean there is adequate leadership. I have been involved in projects where the BPO is involved, the executives are involved, yet the project has several outstanding decisions that are holding up project progress.

This problem may exist for various reasons, but if the executive sponsor and BPO are involved yet decisions are not being made, this is usually due to “analysis paralysis.” The solution for “analysis paralysis” is what I refer to as “Current Best Approach” or CBA.

The basic theory of CBA is that we can never have perfect or complete information, yet decisions must be made to keep the project moving forward. With CBA, we make and document a decision, but everybody recognizes that it is our Current Best Approach and it may change if the information on which it was predicated changes. Usually, this gives people the comfort level to make a decision that allows things to move forward. If new information comes to light that impacts that decision, it can be revisited and potentially changed.

Another reason for a lack of decision-making may be a lack of empowerment. I have seen projects where the BPO makes decisions that are routinely overridden by executives. This usually indicates a lack of confidence in the BPO and often leads to the BPO no longer making decisions and simply waiting for the executive to weigh in and make the decision. This situation will lead to the executive becoming a bottleneck for decisions within the project. It may also result in poor decisions because the executive is not as close to the process as the BPO and may not have a full understanding of the requirements.

The solution to this problem is to ask the executive to either appoint another BPO (possibly himself) or agree to delegate decision-making authority to the BPO and stop overriding those decisions.

Lack of System Activity

It is important for the Subject Matter Experts (SMEs) and Business Process Owners (BPOs) to become system experts by using the system early and often. Most ERP implementations have various environments available for training, testing, and even simply “messing around” in the system. If your SMEs and BPOs are not actively in the system on a regular basis, it could be a sign of discomfort with the system or worse yet, a lack of interest.

To address this issue, insist on having SMEs and BPOs “drive” while demonstrating process solutions to other stakeholders. This will force the issue and the users will either become comfortable with the system or express the reason for their lack of system activity.  

Low Meeting Attendance

Some people hate meetings, however, due to the collaborative nature of an ERP implementation, it is important to have all relevant stakeholders attending and participating in project related meetings. If a project participant tends to miss meetings, however understandable the reason may be, it does not lend itself to the ERP implementation success, and they may be the wrong person for that role. They may have conflicting priorities, a lack of interest in the role, or simply a temperament that does not value team collaboration.

Whatever the case, this issue must be addressed early. Having an unengaged team member is like having a trick knee. You never know when it will fail you, but you will find yourself having to compensate for the inevitable collapse.

Lack of Companywide Project Communication

An ERP implementation is always disruptive to the entire enterprise. It may be a positive disruption, but it is disruptive nonetheless. Because of this reality, it is important for executive leadership to communicate early and often to the entire enterprise regarding the implementation. There should be communication regarding the vision for the new system, the impact of the new system, and the understandable impact of the disruptive nature of the implementation.

If there is little or no communication with the whole enterprise, there is a high probability that the system will not find acceptance when it is rolled out.

To address this risk, it is important for project leadership to engage in a robust Organizational Change Management program that enrolls the people throughout the enterprise in the vision of the ERP system.

Danger Signs of a Failing ERP Implementation

While some signs warn of potential danger ahead, others warn that you are already in a dangerous situation. With the warning signs above, you can take corrective action to avoid danger, while the signs below mean your ERP implementation is actively in danger of failing.

Part of the reason these signs are so dangerous is because they come later in the project, leaving less time to correct and recover from the trouble they indicate. Many of these problems could have been avoided if the early warning signs had been heeded and corrected.

Project Team Communication Problems

Because ERP implementation projects are complicated, they require stellar communication. It is difficult to succeed even when the project team is communicating well, but the danger level rises significantly when there are communication problems within the project team.

These problems often manifest themselves as disagreements about what has been completed, who is responsible for certain tasks, what is in scope, what decisions have been made, and the current status of the project. When you see these types of disagreements, your project is in serious trouble. This is a sign of poor project management or poor team dynamics. Both conditions can seriously jeopardize your project.

Thrashing

Thrash means to “move in a violent and convulsive way.” This is a great description of several danger signs of failing projects. Here are some of the ways ERP implementations experience thrashing.

Last minute requirement changes

I’ve seen this happen many times. The implementation is getting close to completion and is being tested. Someone–usually a manager who has not been very involved in the project–asks if the system can support a scenario that was never previously discussed or had previously been rejected. When the person is informed that the system will not support that scenario, they inform the project team that they can’t go live without that functionality.

This causes all kinds of problems and often adds significant cost and time to the project. In many cases the new requirement is not really a requirement. If none of the subject matter experts or business process owners identified it as required, if the company had not been able to perform this function previously, or a manual process had already been defined to support this capability, this is an unreasonable request to be made on a nearly complete project. This causes “violent” activity to the project and will add serious risk. I’ve seen multimillion dollar projects killed by this situation.

Never-Ending Backlog

If your project is using some sort of iterative methodology (which it should be), there is a backlog from which all the work for each iteration is derived. It is common for the backlog to grow early in the project. Unlike a waterfall methodology, iterative methodologies assume there will be new requirements discovered throughout the early iterations.

However, if the backlog never begins to be consumed, that is an indication that your project will never be completed. This is a form of thrashing because there is always “just one more thing” that “must” be done before the project is complete. The impact of adding “just one more thing” results in new rounds of testing which results in more thrashing.

One could argue that a backlog is not intended to be consumed, and this may be true for a development team that is building a commercial product that is intended to be continuously improved and updated.

However, for an ERP implementation, there must be a completion to the project and that requires predefined scope. If the project backlog is not being consumed, there will be no end to the project. Never-ending backlogs lead to never-ending projects which lead to killed projects.

Static Percent Complete

If you are tracking percent complete on the implementation[2] and you see the progress is stalled, that could be an indication of thrashing. The Pareto Principle, or the 80/20 rule, states that for many phenomena 80% of the result comes from 20% of the effort. The converse of that is that you spend 80% of the effort on 20% of the results.

This is what is commonly experienced by failing ERP implementations. The project appears to be 80% complete but progress seems to stall there. If your implementation team has been reporting that the project is around 80% complete for more than 50% of the project timeline, you are definitely in the danger zone.

Revisiting Foundational Decisions

It is important to be able to be flexible, dynamic, and agile with ERP implementation projects. There are certain decisions that need to be changed due to evolving circumstances and business objectives. However, there are many decisions that are foundational to the work being done to implement the ERP system. Some of the foundational decisions include chart of account structure, organizational structure, inventory costing methods and warehouse layout. These are just a few examples of foundational decisions that affect significant portions of the ERP implementation.

Changing foundational decisions reverses progress and can cause significant thrashing. If your project is late into the execution of the project and you are revisiting foundational decisions, your project is in danger.

Continuous Quality Issues

In addition to Thrashing, quality issues are often danger signs. I have seen projects that have such a serious quality issue, their bug list continued to grow even as their bug resolution rate increased. The more bugs they fixed, the more bugs they created. If your bug resolution efforts seem like a game of Whack-A-Mole, your project is in the danger zone.

Code bugs are not the only quality issues, however. Another danger sign is poor data quality.  If your project is in the late stages of testing and the primary issue you encounter is data quality, your data migration has likely placed your project in danger.

Unfortunately, these quality issues tend to be discovered towards the very end of the implementation. It is usually a sign of inadequate design reviews and data migration plans. The problems occurred upstream, but they are only being discovered late in the implementation because there were no effective plans to verify adequate quality early. 

Conclusion

ERP implementations are complex projects rife with risks and challenges. By keeping an eye out for these early warning signs, you will be prepared to course correct in time to avoid the symptoms of a failing implementation outlined above. If you find yourself in an implementation that’s exhibiting danger signs and you’re unsure of the steps needed to rescue it, schedule a 30-minute consultation with me ASAP. I would love to hear about your situation and provide some insights into how you can steer your project toward the finish line successfully.

Don’t wait until it’s too late. Take control of your project’s success and schedule a time on my calendar today.

You can read the next post in this series here.

[1] Fitz-Gerald, Lois, and Jennie Carroll. “The role of governance in ERP system implementation.” Proceedings of the 14th Australasian conference on information systems. 2003.

[2] I don’t necessarily recommend percent complete as a reliable performance indicator on ERP implementations because it is hard to measure and often subjective and inaccurate.

Are you struggling with your ERP implementation?

Let us get your project back on track.

Take control of your project’s success today and schedule a free 30-minute consultation with Tory Bjorklund, the founder and CEO of Victoria Fide. With our expertise, we can rescue your ERP implementation, saving you valuable time and money. Find the answers you seek by taking this crucial step toward a successful ERP implementation.

About the Author

Tory Bjorklund, a seasoned leader in the consulting, manufacturing, and software sectors, currently holds the position of CEO at Victoria Fide. With a remarkable career that spans roles such as CEO, CTO, CIO, and Chief Software Architect, Tory consistently demonstrates his bold and visionary thinking. His enthusiasm for harnessing technology to transform businesses is evident, and he fervently advocates for reshaping conventional norms in digital transformation through Making Change Positive. Connect with him on LinkedIn to follow his journey.