WIREDGOV

Blog posted by: David Hamilton, 29 May 2020.

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 by signing up for free to APM's Power of Projects Takeover, the virtual event taking place from 1-12 June. #powerofprojects

You may also be interested in 

• What is governance?
• What is risk management?
• Systematic review on behavioural decision making in projects

About the Author

David is the Managing Director of the project management firm Projecting which specialises in financial services projects and has offices in Edinburgh, London, and Madrid. He started the company in 2013 after 14 years in project management in various project, programme, and Head of Project roles. David has been involved with APM for several years, including as a former branch committee member and organiser of the Scottish Conference, as well as running project management seminars and writing articles within the sector.

David is a trustee of the Royal Botanic Garden Edinburgh – a non-departmental public body and home to Scotland’s national collection of plant species and specimens – and sits on the programme board for their £70m Edinburgh Biomes project. He is also a Board member, and former chair, of the Scottish youth homelessness charity The Rock Trust.