The art of escalating well when a project stalls
Escalating means raising a problem to a higher level when the current one isn't solving it. Do it early, factually, and grounded in documentation. Always start at the team level, move higher only once the same problem recurs, and keep the focus on the issue and its consequences – never on blaming a person.
Escalating has picked up a negative connotation, as if it were a way of going behind someone’s back. In reality, it’s a normal and necessary part of steering a project. Escalation simply means raising a problem to a level that can solve it, when the current level isn’t doing so. The art lies in doing it early, factually, and without poisoning the collaboration.
The escalation ladder: from team to contract
The first mistake is jumping straight to the top. Emailing the CEO about a missed deadline before the project manager has even had a chance burns trust unnecessarily. A well-thought-out escalation follows a ladder, step by step.
A typical sequence looks like this:
- Team level. Raise the problem directly with whoever can fix it. Most issues stay and get resolved here.
- Project manager. If the problem recurs, or affects the plan and budget, it gets raised to whoever is responsible for delivery.
- Steering group or engagement owner. If it’s about priorities, resources, or money the team doesn’t control, it goes to the level that does.
- Contract level. Only when dialogue isn’t enough does what’s written in the contract come into play – liability, penalties, and how disputes are resolved.
The point of the ladder is that every step gets a real chance to solve the problem before the next one is taken. Agree on it already at project start, so you don’t have to improvise once things get tense.
The documentation that keeps you factual
An escalation is only as strong as the evidence behind it. The difference between “it feels like things are dragging” and “the last three sprints have delivered below plan, here are the numbers” is enormous. The first is a feeling that’s easy to dismiss; the second is hard to explain away.
You don’t need to build a court case, but ongoing notes will save you when it counts. Keep track of what was agreed, what actually happened, and what impact the deviation had. Meeting notes, a simple decision log, and saved written communication go a long way. With the evidence in hand, you can describe the problem factually, and a factual escalation is far harder to dismiss than a frustrated one.
Escalate problems – don’t blame people
This is where it’s decided whether the escalation builds or breaks something. A problem raised factually is seen as taking responsibility. The same problem framed as an accusation against a named person puts people on the defensive, and then they stop listening to the substance.
The difference lies in what you focus on. Compare “the developer is sloppy” with “we’ve had recurring errors in the same flow, what’s causing it, and how do we fix it?” The first looks for a scapegoat; the second looks for cause and solution. Keep the focus on the problem, the consequence, and the way forward.
A concrete example: deliveries have been delayed three sprints in a row. The blaming route is emailing the top boss that the team isn’t up to standard. The constructive route is to first take it to the project manager – “we’re behind plan, what’s needed to catch up?” – and, if that doesn’t help, raise it with the steering group backed by the numbers. Same level of seriousness, but the second route more often solves the problem and keeps a working collaboration intact.
It’s worth signaling before you go up a level. Saying “if we don’t move forward here, I’ll need to raise it with the steering group” isn’t a threat but an honest heads-up that gives the other party a last chance to act. No one likes being blindsided, and a pre-warned escalation feels fair.
How to build escalation in from the start
The best time to agree on escalation is before anything has gone wrong. Decide who the point of contact is at each level, how often you check in, and what counts as a deviation worth raising. That turns escalation into a routine, not a crisis.
At Weapp, we see that the projects that run most smoothly are the ones where problems get raised early and factually, long before they’ve had a chance to grow. Want a partner that builds in that openness from the start? Read more about our services or get in touch with a short description of your project.
Frequently asked questions
When is it too early to escalate?
It's too early if you haven't first raised the problem with whoever can actually solve it, usually the team or the project manager. A one-off issue that gets handled right away rarely needs escalating. Escalation is for problems that recur, don't get resolved, or threaten goals, budget, or schedule – not for venting individual frustration.
How do I escalate without damaging the relationship?
Keep it factual and predictable. Describe the problem, its consequence, and what you want to happen – not who's at fault. Signal in advance that you plan to raise the issue, so no one is caught off guard. An escalation done openly and with a focus on solutions is seen as taking responsibility, not as an attack.
What is an escalation ladder?
It's an agreed order for who a problem gets raised to, step by step. It starts at the team level, moves on to the project manager, then to the steering group or engagement owner, and finally to the contract level. Agreeing on the ladder in advance means you don't have to improvise once things are already on fire.
What documentation do I need?
Dates, what was agreed, what actually happened, and what impact it had. Meeting notes, a decision log, and written communication go a long way. The point isn't to build a court case but to be able to describe the problem factually rather than emotionally when you raise it.
What do I do if the escalation doesn't help?
Then you move on to the next step of the ladder and eventually to the contract level, where the agreement governs what applies. If that doesn't produce results either, a dispute or a change of vendor may become relevant. But most problems get resolved long before that, provided they're raised factually and in time.