Every best practice paper\u00a0I've\u00a0read and conference\u00a0I've\u00a0attended 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?\nI 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.\nWithout proper treatment FPE can lead to:\nCost overruns\nLimited 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.\nSchedule delays\nWhen 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.\nInferior designs or process performance\nIf 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.\nThere are a number of factors that contribute to the onset of FPE:\nPersonal ego\nHighly 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.\nCultural conditioning\nWhether 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?\nRelationship preservation\nEscalation 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 \u201ctattle tale\u201d. 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.\nLack of procedural understanding\nSometimes 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.\nIssue environmental awareness\nOn 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\u2019s 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.\nSo how can you diagnose whether or not your team members are afflicted with FPE?\u00a0 Here are the telltale signs:\n\nTeams or groups that have a small issue deny any need to escalate.\nTeams are surfacing issues way too late to react.\nYour software provider or your system integrator has an empty issue list.\nIssues aligned with previously identified high potential risks are not surfacing.\n\nCuring 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:\n\nImplement 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.\nTrain team members on all available escalation procedures. Then track usage of each escalation procedure.\nInclude 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.\nOnce 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.\nEstablish 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\u2019s a good penalty? Reduce team size or change the management.\nProactively 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.\n\nFPE 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.