When Should a Project Manager Escalate?

Most project managers carry two quiet worries about escalation. The first is going to the sponsor too early and looking like someone who cannot run their own project. The second is going too late, and having to explain why a problem that was visible for weeks arrived with only one option left attached to it. Both worries are reasonable. Both produce poor timing when they are allowed to make the decision.

The workable answer is narrower than most advice suggests. Escalation is appropriate when a decision no longer belongs at your level, or when waiting would remove options from the person it does belong to. Difficulty on its own is not a trigger. A hard problem that sits within your authority is yours to solve, while a modest one that crosses an agreed threshold, or touches safety, legality or ethics, is not yours to hold.

Escalation is a question of ownership, not difficulty

Escalation is often treated as a measure of severity: small problems stay with the team and large ones travel upwards. That model breaks quickly on a real project. A project manager may be fully entitled to absorb a significant supplier delay by resequencing work, yet have no authority to trade away a feature the business case depends on, even when that trade costs nothing on the schedule. The size of the problem matters far less than who owns the trade-off it creates.

Ownership is set by the governance around the project. Delegated authority, agreed tolerances on cost and schedule, change control arrangements and the product owner's remit together describe which decisions sit with the team, which sit with the project manager, and which sit with a sponsor, steering group or function outside the project. When a problem forces a choice beyond your delegated authority, raising it is not an admission of weakness. It is the correct routing of a decision.

Section 3.6 of The Standard for Project Management, in the Eighth Edition of the PMBOK® Guide, sets out being an accountable leader as one of the principles of project management, and it offers a useful way to frame this. Accountability is not the same as keeping every problem under your own control. It means accepting responsibility for decisions and their consequences, and part of that responsibility is recognising when a decision should be taken by someone else, then making sure it reaches them while it can still be taken well.

The same logic works in the other direction. Where the team holds the authority to resolve something, a project manager who lifts it out of their hands, or passes it upwards, has removed a decision from the people best placed to make it.

A small number of matters need no ownership test at all. Concerns about safety, legal or regulatory compliance, data protection, financial impropriety or ethical conduct should go through the appropriate route promptly, even where the project manager believes the problem could be settled quietly. The organisation has a legitimate interest in knowing, and the choice of response is rarely one a project should make on its own.

Too soon, too late and the space between

Premature escalation usually takes one of three forms. It passes upwards a decision the project manager is authorised and equipped to make; it raises a problem before anyone understands it, so the sponsor receives anxiety rather than information; or it bypasses the people closest to the work, who might have resolved the matter within a day. Each carries a cost beyond the conversation itself. Senior attention is limited, and a project manager who escalates too readily teaches sponsors to discount escalations, which is precisely the wrong lesson to teach before a serious one arrives.

Late escalation is harder to recognise because it resembles diligence. The project manager is working the problem, the team is optimistic, and the status report shows amber because the recovery plan might yet succeed. Meanwhile the options open to the decision-maker are narrowing. Extra funding might have bought recovery six weeks ago; now the only remaining choices are to move the date or reduce scope. An escalation that arrives with one option left is no longer a request for a decision. It has become a notification.

The practical test for timing, then, is not whether you are certain there is a problem. It is what waiting will cost the person who owns the decision. If another week of working it quietly would close off an option they would reasonably want to consider, the time to raise it is now, even with incomplete information.

Much of the tension between too early and too late eases once flagging is separated from escalating. Flagging tells the owner of a threshold that something is moving towards it and that you are dealing with it. Escalating asks them to decide. A project manager can flag early without surrendering control of the problem, and a sponsor who heard a fortnight ago that a supplier dependency looked fragile will receive the eventual escalation very differently from one hearing about it for the first time.

Consider a project manager leading the replacement of a regional publisher's content platform. Three weeks before go-live, the migration supplier reports that the archive carries metadata its tooling cannot map, and correcting it will add around four weeks to the archive migration. The team quickly finds a resequencing option: launch on the planned date with current content only, then migrate the archive over the following month. The go-live date, budget and supplier contract all stay intact.

On schedule and cost alone, that response sits comfortably within the project manager's authority. Resequencing, though, means editorial staff lose searchable access to the archive for a month, and the business case depends partly on that archive supporting a subscription offer planned for shortly after launch. That is a trade-off between launch timing and business value, and it belongs to the sponsor. The project manager's job is to understand the problem well enough to set out the options, recommend one, and raise it now, while paying for additional supplier capacity or moving go-live by a fortnight are still realistic alternatives. Holding it for a week in the hope that the supplier finds a faster fix would quietly remove both.

What triggered the escalation was neither the size of the delay, which the team could absorb, nor the difficulty of the technical problem. It was that the only workable response changed something the sponsor had committed to on behalf of the business.

How PMP scenarios frame the decision

PMP® preparation can leave candidates with the impression that escalation is nearly always the weaker answer, and that a capable project manager resolves everything at their own level first. There is a sound instinct underneath that impression. Many project problems are best understood with the people closest to the work before anyone else is involved, and a response that goes straight to the sponsor often skips analysis the situation plainly needs. Treated as a fixed rule, however, it misleads.

The 2026 PMP Examination Content Outline places escalation within the project manager's responsibilities rather than outside them. In the Business Environment domain, which accounts for 26 per cent of exam items, the task of defining and establishing project governance lists outlining governance escalation paths and thresholds among its enablers. The same domain's task on removing impediments and managing issues includes collaborating with relevant stakeholders on how issues should be resolved.

For a PMP candidate, the important distinction is between a scenario testing whether you will analyse before acting and one testing whether you recognise the limits of your authority. The useful exam-preparation habit is to ask the two questions a working project manager would ask: whose decision is this, and has anything happened that makes waiting costly? A problem within your remit, with no threshold at risk, generally calls for working it through with the team. A tolerance that has been breached or soon will be, a decision outside your authority, or a safety, legal or ethical concern points the other way.

That is less about memorising a preferred sequence of actions and more about reading what a situation reveals about authority and timing. If you want to build that habit across the full breadth of the syllabus, PMP® Exam Preparation works through it in a structured, instructor-led setting, alongside the leadership and governance judgement that surrounds it.

Setting the line before you reach it

The most reliable way to escalate well is to agree where the line sits before a problem reaches it. Thresholds decided in the middle of a difficulty tend to be negotiated under pressure, and they usually settle wherever everyone hoped the problem would stay.

In predictive delivery these lines are often explicit: variance tolerances on cost and schedule, a defined change authority, milestone commitments tied to contracts or regulatory dates. Mature governance usually defines them well. The discipline lies in forecasting against them honestly, so that a tolerance likely to be breached next month is flagged this month rather than reported once it has already gone.

In adaptive delivery the team owns more of its own decisions, and many impediments are resolved within an iteration without anyone outside the team becoming involved. The escalation question tends to concern what the team cannot control: a dependency on another team that keeps slipping, an organisational policy blocking a release, a product owner who is unavailable for prioritisation decisions, or evidence that a product goal is no longer achievable. The iteration cadence helps here, because it creates regular moments at which a pattern becomes visible, rather than leaving the team to judge from a single difficult week.

Hybrid delivery needs the most deliberate attention, because thresholds often differ on either side of an interface. An adaptive software workstream may absorb a change comfortably by reprioritising its backlog, while the same change pushes back an integration milestone that a predictive hardware workstream, a supplier and a go-live plan all depend on. Neither team has breached its own threshold, and the project still has a problem nobody has raised. Agreeing escalation triggers at those interfaces, not only within each workstream, is one of the most practical things a project manager can do early in a hybrid project.

Project managers who escalate well are not the ones who escalate least. They solve what is theirs to solve, leave the team to decide what belongs to the team, raise early signals without handing over control, and put decisions in front of the people who own them while those people still have choices. Sponsors tend to trust that kind of project manager more rather than less, because when an escalation does arrive, it carries weight.

Andre Malowney

Interested in going further?

Judging when a decision has moved beyond your authority means reading governance, stakeholders, team capability and timing together, usually with incomplete information. Structured PMP® preparation builds that judgement across a wide range of project situations, so the right response becomes something you recognise rather than something you guess.

The PMBOK® Guide Eighth Edition is the natural place to read the accountable leadership principle in its wider context, alongside the governance thinking that shapes escalation.

Ad · Amazon affiliate link.

References

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
A197: Before Escalating: What Should a Project Manager Check First?
A007: The Standard for Project Management vs the PMBOK Guide

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