How Do You Escalate a Risk Without It Feeling Like Failure?

There is a particular kind of silence that happens in a project team when someone has noticed something is wrong and hasn't said so yet. It isn't dramatic. Nobody is hiding anything. The risk sits in someone's notes, half formed, waiting for a version of itself that feels less like an admission.

Most project managers know this moment from the inside. A supplier has gone quiet for longer than usual. A dependency that looked solid three weeks ago now looks softer. A team member has raised the same concern twice, gently, and been told it's in hand. None of it is a crisis yet. All of it could become one. And the project manager sitting closest to it is doing the maths on whether raising it now, at this stage, in this steering group, will read as diligence or as a confession that they've let something slip.

This hesitation rarely comes from a lack of process. Most organisations running PRINCE2 or MoR-aligned governance already have the mechanics in place: a RAID log, tolerance thresholds, an exception process for anything that breaches them. On paper, escalation is simply what happens when a risk crosses a defined line. It isn't meant to be a judgement on the person reporting it. In practice, the mechanics rarely explain why the flag gets raised two weeks later than the threshold was actually crossed.

The gap sits somewhere less official than the framework. In a lot of organisations, retrospectives and post-project reviews ask a version of "who missed this" more often than "was the tolerance set correctly." A project manager who has sat through even one review like that learns the lesson quickly, even if nobody states it directly: the person who raises the risk becomes, in the room's memory, the person attached to the risk. Not the person who caught it early. The one who owns it.

One programme manager described watching this play out on a mid-sized infrastructure delivery. A subcontractor's design submission was drifting behind schedule, not dramatically, but consistently, week over week. The project manager on the ground had noted it in the risk log from the first missed interim date. It sat there, updated but unescalated, for the better part of a month, while she waited to see whether it would resolve on its own before it needed a steering group's attention. It didn't resolve. By the time it reached the board as an exception, the recovery options had narrowed considerably, and the conversation that followed spent more time on why it took so long to surface than on the design delay itself. Nobody had told her not to escalate earlier. She simply hadn't wanted to be the one holding a problem that might turn out to be nothing.

That instinct is understandable. It is also, on reflection, backwards. A tolerance threshold exists precisely so that the decision about whether to escalate doesn't have to rest on a project manager's private judgement about how it will be received. If a risk crosses the line that was agreed in advance, raising it is not an interpretation. It is following the system as designed. The sponsor's actual job, the reason the escalation route exists at all, is to hold a level of authority and a wider view that the project manager doesn't have from where they sit. Handing a decision upward, at the point where it genuinely belongs there, is not losing control of the project. It is recognising the shape of the role correctly.

There is a version of this that project managers who escalate well seem to understand instinctively, and it has less to do with courage than with framing. They don't present a risk as evidence that something has gone wrong under their watch. They present it as a decision that needs input beyond their own remit, supported by what has already been tried, what the options are, and what they'd recommend. The risk becomes a request for a decision, not an apology. Sponsors tend to respond to that framing very differently than they respond to a flag that arrives sounding like a confession, because it is, functionally, a different act. One is a project manager doing their job. The other reads, unfairly but predictably, like someone finally admitting a problem they should have caught sooner.

None of this removes the discomfort entirely. Raising a risk before it has fully proven itself still takes a kind of nerve, and there will always be a live possibility that it resolves quietly and the escalation looks, in hindsight, unnecessary. But an escalation route that only gets used once a risk has become undeniable isn't really an escalation route. It's a formality applied after the point where it could have changed anything. The system was built to catch problems while they still had several exits. Using it that way isn't the failure. Waiting until there's only one exit left, and calling that patience, is closer to the actual mistake. If you'd like to talk through how your organisation's escalation routes actually work in practice, not just on paper, get in touch about your project management training options.

Andre Malowney is a project management trainer accredited across PMI, APMG, APM and PeopleCert frameworks, working with both traditional plan-driven practitioners and Agile delivery teams. Find him on LinkedIn: www.linkedin.com/in/andremalowney.