Fear of premature escalation (FPE): Diagnose and treat this silent ERP program killer

Every best practice paper I’ve read and conference I’ve attended has identified having a solid project risk and issue management process as a critical ERP program success factor. So why is it that major problems in ERP programs, whether they are technical, process or resource allocation related, surface too late or not at all?

I think that a root cause is a project team affliction which I identify as Fear of Premature Escalation or FPE. FPE can be isolated to a single team member or be systemic throughout the entire project team. It can afflict internal teams, system integrators, software providers and independent consultants alike. The symptoms are difficult to detect but the affliction can be deadly for an ERP project.

Without proper treatment FPE can lead to:

Cost overruns

Limited escalations suggest that all issues are being handled by the internal project team. With all major programs you expect issues to surface that need to be resolved outside the control of a local or sub-team. If a team is solving all the issues from within, it is typically spending too much time and money.

Schedule delays

When issues are escalated too late (without enough time to resolve properly), you will incur schedule delays. Schedule delays typically come with increased cost and a decrease in the overall credibility of the team. This makes it difficult to plan future activities.

Inferior designs or process performance

If design issues or process performance problems are not raised, then sub-optimal solutions are typically adopted. These will compromise the overall business case and ultimately harm the transformational results expected.

There are a number of factors that contribute to the onset of FPE:

Personal ego

Highly technical people are typically reluctant to escalate problems because they often feel they are on the verge of a breakthrough. To these individuals, escalation is a sign of weakness or incompetence.

Cultural conditioning

Whether it is company or geographic culture, in most environments we are taught to minimize escalations. Systems are put in place to reward those that limit escalation and penalize those that escalate often. Think about it, did you have a high opinion of your childhood neighbor who always ran back to Mom or Dad to solve their problems for them?

Relationship preservation

Escalation often involves calling out the fact that someone has not done their job. Odds are these individuals are going to have to work together in the future and nobody wants to be branded the “tattle tale”. After all, while the project is only going to last a year or two, the parties in question might have to work together for the next twenty years.

Lack of procedural understanding

Sometimes there is just a plain lack of understanding of the escalation process. On a typical ERP program there may be internal project escalation, ERP software provider escalation, system integrator escalation, financial escalation, audit and compliance escalation. Without a basic understanding of the escalation paths available and the procedures to engage, team members can understandably (if mistakenly), assume they are responsible for resolution.

Issue environmental awareness

On a large program, a significant portion of the project team tends to lack understanding about the impacts an issue can have on overall schedule execution. They tend to think of each issue in isolation. For example, I once brought in three highly sought-after consultants to conduct a workshop. The critical path of the program was highly dependent on the successful execution of this workshop. The day of, one of the consultant’s laptops would not operate as intended on our network. When we contacted the internal IT help desk, they refused to immediately escalate the problem because it was not directly impacting production or business performance. Clearly this was a shortsighted judgment of the seriousness of the issue.

So how can you diagnose whether or not your team members are afflicted with FPE?  Here are the telltale signs:

• Teams or groups that have a small issue deny any need to escalate.
• Teams are surfacing issues way too late to react.
• Your software provider or your system integrator has an empty issue list.
• Issues aligned with previously identified high potential risks are not surfacing.

Curing FPE is not easy. Almost all cures are rooted in implementing behavioral change which involves linking actions to both positive and negative consequences. There are a few remedies, however, that will help relieve FPE:

• Implement team management operating procedures in which managers/team leaders canvass the team at the beginning of each day to understand the critical issues and confirm they are all logged.
• Train team members on all available escalation procedures. Then track usage of each escalation procedure.
• Include any cross-reference numbers to project issues controlled outside of the project team. Issues escalated outside of the program issue log should be assigned the same status as external issues.
• Once an issue is logged, a target date for resolution or escalation should be set and tracked. If the escalation date is delayed, a reason needs to be noted.
• Establish team/project measurements on escalation that strike a balance between expected internal team resolution and escalation. Measure the teams against this metric and reward teams that are appropriately escalating and penalize teams that are not. What’s a good penalty? Reduce team size or change the management.
• Proactively work with all of your escalation channels to establish escalation criteria that are consistent with the magnitude of the project and the potential impact of a delay.

FPE can be a serious affliction that, if left untreated, can lead to significant program consequences. Recognizing the early warning signs and taking appropriate action can reduce the overall impact of this silent ERP program killer.