Skip to content
Our website will be unavailable from 17:00 GMT Wednesday 20 November until 9:00 GMT Monday 25 November while we carry out important upgrades.

If you plan to update your membership, book an event or access APM Learning, APM Community or use other resources, please do this outside of these dates.

The 15 November Chartered Project Professional submission date is unaffected.

Thank you for your patience.

Why is escalation the last resort?

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content
David Hamilton escalate.jpg

Escalation should never be a threat or a punishment; escalation should be for the benefit of the organisation, says David Hamilton

Have you ever looked at a project or a workstream that is not going anywhere and thought to yourself, ‘why hasn’t this been escalated?’ We all know that, sometimes, projects need to be escalated to a senior level to get decisions made or things unblocked. Yet, escalation often seems to be the route of last resort and can happen weeks or months after it should have.

It is easy to understand why. If you are the project manager or workstream lead, you might worry that you’ll be getting someone into trouble, you might damage an ongoing working relationship, or you might be concerned that people think you weren’t up to the job of delivery. We can’t pretend that there is no risk in escalation because it doesn’t always go smoothly, but in almost all scenarios appropriate and managed escalation is a much better solution for the project than just giving someone their fourteenth last chance to get their actions completed.

I’ve known (and know) some excellent project managers who take such personal responsibility that they see the need to escalate as an admission of failure. They will explore every avenue and give every opportunity for tasks to be completed. It is in our nature to give people the benefit of the doubt and to be sympathetic to the other work pressures that someone might be under. Particularly if we like them.

The challenge of escalation is threefold; when to escalate, who to escalate to, and how to escalate effectively. Escalation should resolve the issue being raised, and if it can’t be resolved then at least it is noted and accepted.

The ‘when’ is sometimes about how many chances you give someone, let’s call him Bob, to complete the activities or make the decisions that he has been promising you for days/weeks/months. The assessment you have to make is when non-delivery will start to impact the project – and then you need to escalate early enough for the issue to be resolved before it has any consequences. Waiting a little too long, and probably increasing your own stress level in the process, can limit your options. If you miss the window for timely escalation, then your best option might be to hope that Bob pulls through for you. If he doesn’t, the question you’ll be asked changes to ‘why didn’t you escalate this when you knew it was a problem?’

The ‘who’ depends on your project structure. You might be a workstream lead escalating to a project manager or a project manager escalating to a programme manager. You may have to escalate to a sponsor, a project committee, or a line manager. The escalation route that you take will be determined by the person or committee that can resolve the issue. Sometimes you won’t know the answer to that until you escalate and then discover that a different escalation route is required. Even if you are unsure, that should not prevent you from taking initial steps in escalating or having exploratory conversations with those that you would escalate too (which in itself might help resolve the issue you want to escalate).

The ‘how’ should be done objectively, with evidence, and with sensitivity. When you escalate you need to articulate the problem, the proposed solution, and how you will execute that solution (assuming there is one). It can be the case that escalation is focused on a particular individual or team. Before you escalate anything, I would always advise that you speak to those who may be impacted, explain the rationale for escalation, and be clear on the outcomes you want to achieve. Escalation should never come as a surprise and, ideally, it should be seen positively as a solution to an ongoing issue. You might even find that people are keen for you to escalate as it relieves the pressure they have been under.

Last, but definitely not least, escalation should never be a threat, nor should it be a punishment. Escalation should be for the benefit of the organisation, the project, and the project team. It should be done for the right reasons and with the right intent. Threatening to escalate and then not, or escalating too readily, can be damaging to both projects and relationships. The culture of an organisation is important here. Anyone who is escalating has to feel safe in doing so and feel confident that there will be an appropriate response. Having an agreed policy or approach to escalation within an organisation can help with this.

That is not to say that an escalation may not lead to some probing or difficult questions, but those escalated to need to have the right intent as well.

Hear more from David: APM's Power of Projects Takeover

You may also be interested in 

Image: Gubin Yury/Shutterstock

0 comments

Join the conversation!

Log in to post a comment, or create an account if you don't have one already.