Before Escalating: What Should a Project Manager Check First?

The issue has been open for three weeks. Two chasers have gone unanswered, the date you were protecting has now passed, and someone senior has started asking why the workstream has not moved. The message to the sponsor is half written.

Most of the guidance available at that moment deals with whether you are entitled to escalate. That is rarely the real difficulty. The harder question is whether the escalation will achieve anything, because an escalation that arrives without preparation usually comes back as a request for preparation. The sponsor asks who you have spoken to, what you have already tried, and what precisely you want them to do. If those answers are not ready, you have spent senior attention to buy yourself another week of delay, and you have spent a little of your own credibility with it.

None of this is an argument against escalating. Some things genuinely cannot be resolved at project level, and holding on to them is its own failure. The checks below are not obstacles placed in front of escalation. They are what makes escalation work when you use it.

Escalation moves a decision, not the accountability

There is a common misreading of escalation as a transfer of the problem. You raise it, someone more senior owns it, and your workstream is no longer stuck in your column. Projects where that belief takes hold tend to produce a lot of escalations and very few resolutions, because nobody upward has the context to act on what they have been sent.

Escalation moves a specific decision to someone with the authority or reach to make it. The framing, the options, the consequences and the follow-up all remain yours. This is what sits underneath Section 3.6 of The Standard for Project Management, which treats accountable leadership as a combination of responsibility, judgement and situational awareness. An accountable project leader addresses problems openly and chooses between coaching, deciding, facilitating and escalating according to what the situation actually needs.

Read that way, the checks stop looking like extra work. You are about to ask someone with far less context than you to make a call quickly. The quality of what you hand them determines whether they can.

The checks that belong before the message

Start with whether the request has actually been made. This one catches more delays than any of the others. A surprising number of blocked items turn out never to have been asked of a named individual with a specific ask and a date. Work has been mentioned in a stand-up, raised in a forum, sent to a shared mailbox or discussed with someone adjacent to the person who decides. Chasing a team is not the same as asking a person.

The second check is whether the obstacle is the one you have been told about. Most blockers reach a project manager second hand, and they arrive already interpreted. Someone says security is refusing, or estates will not release the room, or finance has rejected the code. Going directly to that person for ten minutes frequently changes the shape of the problem. Sometimes the refusal is a misunderstanding. Sometimes the real constraint is one nobody has mentioned yet, and it is larger than the one you were about to escalate.

Third, establish whether the decision genuinely sits outside your authority. Check what you are actually allowed to decide, what tolerance you hold, and what threshold triggers referral. Governance normally defines an escalation route and the points at which it applies, and part of the project manager's job is knowing where those lines fall. Escalating something you were empowered to settle trains people to treat you as a channel, and it slows the next thing you raise.

It is also worth asking whether the other party needs something from you. Requests stall in both directions. A security team may be waiting on a data classification, a supplier on a purchase order number, an estates manager on confirmation that a survey has been completed. Confirm that nothing on your side is the reason the other side has gone quiet, before you tell a sponsor that the other side has gone quiet.

Last, work out what continued delay actually costs. If you cannot describe the consequence in terms of a date, a cost, a dependency or a risk that is now materialising, the escalation has nothing to convey urgency with, and it will queue behind items that do. Working this out also tells you something useful about yourself. Occasionally the honest answer is that the delay costs very little, and the discomfort is impatience rather than impact.

A blocked approval that changed shape

A manufacturing organisation is replacing its quality management system across three sites. The supplier needs remote access to configure the new environment, and the project manager has been told for a fortnight that IT security is sitting on the approval. The delay has now consumed the float in front of the first site cutover, and the programme manager has asked why.

Rather than escalate, the project manager spends an hour on the checks. The request had been sent to a shared inbox with one section of the access form incomplete, so it had never entered the queue. That is the easy part. The more useful discovery is that the supplier's tool routes session data outside the organisation, which requires a data protection assessment that nobody has started and which the information governance lead says takes about three weeks under normal prioritisation.

So the escalation still happens, and it should. What changes is what it is about. Instead of reporting that security is unresponsive, the project manager takes a decision to the sponsor: prioritise the assessment ahead of two other items in the same queue, or configure the first site on site with the supplier at additional cost, with the consequences of each set out and the date after which the choice disappears. That is a message a sponsor can act on in ten minutes. The original one would have generated a meeting.

What a prepared escalation contains

Once the checks are done, the escalation almost writes itself. State the situation briefly, what has already been tried and by whom, the specific decision you need, who you believe can make it, the realistic options with their consequences, and the date beyond which the options narrow. Nothing in that list requires an escalation template. It requires the hour of work that produced it.

The route differs by approach, and this catches experienced people out on hybrid programmes. In a predictive environment the path is usually defined against tolerances and change control, so escalation follows a named threshold and lands in a scheduled forum. In an adaptive environment, impediments are normally raised inside the team's cadence first, and escalation applies when the team has genuinely tried and cannot clear the blocker itself. Where both are running at once, the frequent mistake is assuming that raising something in a delivery ceremony means governance has heard it. It usually has not.

For a PMP® candidate, this is one of the areas where the current examination content genuinely helps. The 2026 PMP Examination Content Outline puts removing impediments and managing issues in the Business Environment domain, which carries 26 per cent of the exam. That task covers weighing the impact of an impediment, prioritising it, choosing and applying an intervention, and working with the relevant people to resolve it. Escalation paths and thresholds appear in the same domain, under establishing project governance. Escalation is treated as one of a set of deliberate responses, not as an admission that project management has failed.

PMP preparation can sometimes leave candidates with the impression that escalation is a last resort and therefore nearly always the wrong option when it appears in a scenario. That is a preparation convention rather than a stated position, and it produces a habit of eliminating the escalate option on sight. The more reliable reading habit is to look at what the scenario has already told you: whether the request was made properly, whether the project manager holds the authority, whether the team has attempted the resolution, and whether the constraint is one the project can remove at all. To work through that kind of reading across a wider range of situations, PMP® Exam Preparation develops the same habit systematically rather than one scenario at a time.

On a real project, the value of these checks is not that they prevent escalation. It is that they change what you escalate about, and they make you someone whose escalations get attention. A project manager who raises three well-formed decisions a year is heard immediately. One who forwards every stalled item upward becomes background noise, and the genuinely serious issue arrives sounding like all the others.

There is a limit to this, and it is worth holding. The checks should take an hour, not a fortnight. Investigating thoroughly while a dependency quietly consumes the schedule is a different failure with the same result. If the checks are complete and the decision still sits above you, escalate that day, with everything you found.

Andre Malowney

Interested in going further?

Deciding what to check, what to resolve yourself and what genuinely belongs with a sponsor is judgement built through practice rather than through definitions, and it appears across the People and Business Environment content in different disguises. The Omega PMP® Exam Preparation course works through these situations in a structured instructor-led setting, so the reasoning becomes reliable rather than instinctive.

If you want to read more about how accountable leadership, governance and issue management fit together in the current standard, the PMBOK® Guide Eighth Edition is the source to sit alongside this.

Ad · Amazon affiliate link.

References

A043: When Should a Project Manager Escalate?
A038: Accountable Leadership: Leading Without Command and Control
A149: Coaching vs Directing: Choosing the Right Leadership Response
A039: Servant Leadership in PMP: When It Fits and When It Doesn’t
A044: Analyse Before You Act: A Better Way to Read PMP Scenarios

PMP and PMBOK are registered marks of the Project Management Institute, Inc.