When do I need to escalate in an ERP project, and to whom?

You need to escalate as soon as a decision has been open longer than agreed, a risk threatens the deadline or the budget and can no longer be resolved within the project team, or promised results fail to appear twice in a row. The addressee is the steering committee, not the partner project manager. What matters is that these thresholds are agreed before the project starts. Where they are missing, escalation is experienced as personal conflict and therefore avoided.

Who actually steers the project: Who steers your project when it gets hard?

The warning signs before that: How do I recognise that my ERP project is failing?

The three thresholds for escalation

The first threshold is decision time. Agree before the project how long a decision may stay open, roughly five or ten working days depending on its weight. If that period is exceeded, the question automatically moves up a level. That is not a vote of no confidence but a mechanism, and that is exactly why it works.

The second threshold is a risk with an effect on schedule or budget that can no longer be resolved within the team. Typical cases are an interface whose counterpart does not deliver, data quality worse than assumed, or a requirement that turns out to be far larger than expected.

The third threshold is the repeated absence of promised results. Once can happen. Twice in a row is a pattern, and patterns do not resolve themselves. Waiting for improvement here costs exactly the time you will need later for the correction.

Who to escalate to

The addressee is the steering committee, where your management and the partner leadership sit. Not the partner project manager, who is usually already part of the situation and does not hold the authority now required.

The difference between informing and escalating matters. Informing means a situation is made known. Escalating means a decision is demanded. An escalation without a concrete decision paper creates unrest but no solution.

This includes escalating from your own organisation, not only through the service provider. If only the partner escalates, a distorted picture emerges in which your company merely takes note of the situation. Steering means naming yourself what is not working.

How an escalation should be structured

An effective escalation fits on one page and has four parts. First the facts in a few sentences, without assigning blame. Second the impact in dates and figures: what shifts, what does it cost, what is the latest possible moment for a decision?

Third, two or three options for action with their consequences, not just one proposal. Two people will read the situation differently anyway, and a committee decides more easily between options than about a single recommendation. Fourth a clear question: what exactly is to be decided, and by whom?

What does not belong in it are accusations and long chronicles. Both move attention from the decision to the past, and that is precisely what delays the solution.

Why escalation so rarely happens in time

The most common reason is the fear of appearing overwhelmed. Project managers want to solve problems, not report them, and in daily work that attitude is right. It becomes a risk when the problem lies outside their own authority.

The second reason is a status report that does not reflect reality. If everything is green for three months and then suddenly red, the situation did not change overnight. The report simply did not measure what counts. Status colours by gut feeling are the most reliable precursor of late escalations.

The third reason is lack of practice. A committee that only convenes when something burns experiences every escalation as a crisis. A committee that meets regularly and also takes small decisions treats an escalation as a normal event. That culture is built before the serious case, not during it.

What to agree before the project starts

Four points belong in the project agreement, and they cost almost no time. First the decision deadlines by weight. Second the escalation path with names, not roles: who exactly is informed, who decides?

Third a fixed meeting rhythm for the steering committee, even when things are going well. Fourth the rule that every escalation comes with a decision paper offering options. These four points turn escalation from a conflict into a procedure.

The benefit does not show in the first month but at the moment things get difficult. Projects with this mechanism correct earlier and in smaller steps. Projects without it correct late and expensively, if at all.