An impediment is anything stopping work that the team cannot clear itself. Both halves of that matter. Work that is merely hard belongs to the team, and a problem it can solve in an afternoon is the work rather than an obstruction to it.
The definition rules out a good deal of what gets raised as a blocker, and it rules in things that rarely get raised at all, such as a tool nobody has approved, an approval sitting with a manager for a fortnight, or a specification that two teams read differently and neither has noticed.
What blockers are actually made of
Very few are technical. The recurring ones are an environment shared with another programme, a decision waiting on somebody who is on leave, a supplier contract that has not been signed, a person allocated to three projects and therefore available to none, or a policy written for a different kind of work.
Almost all of those sit outside the team and most sit outside the project entirely. That is the whole reason the work of clearing them is a distinct job, because the team can usually see the obstruction perfectly well and has no standing to move it.
It is worth separating an impediment from a risk and from an issue, since the three travel to different places. A risk might happen, an issue has happened and belongs to the project to resolve, and an impediment is stopping work now and usually belongs to somebody outside it. The last of those needs a route out of the project, which is the reason the escalation path exists at all.
Removing it and causing it to be removed
The useful distinction is between clearing an obstacle yourself and causing it to be cleared. Only a minority are yours to fix directly, and a project manager who tries to fix everything personally becomes a constraint, with the work queuing behind one person's calendar.
Causing it to be removed means finding whoever owns the thing, understanding what they are protecting, and giving them a reason to act. Sometimes it means changing the plan so the obstacle no longer sits on the path. Sometimes it means accepting a slower route and saying so openly rather than waiting for a decision that is not coming.
The failure at the other end is treating everything as somebody else's to solve. A manager who logs an impediment, assigns it to a name and reports it as handled has recorded the problem rather than acted on it.
Escalation as a designed path
Escalation earns a bad reputation because it usually looks like a favour called in. Somebody who knows somebody sends a message and the obstruction moves, which works exactly once and only for the person with the contacts.
A designed path has three properties. Each level has a named owner rather than a department. Each has a threshold, meaning how long the team waits before it goes up. And each has a route back, so whoever raised it hears the outcome.
Every arrow carries a threshold agreed before anybody needs it, so a decision to move an impediment up is made by the clock instead of by nerve. The dashed line is the part most escalation paths leave out, and its absence is the reason teams stop raising things.
The thresholds are the part worth arguing about while nothing is on fire. Two working days on a decision suits most projects and would be reckless on an outage, so a project where an hour of downtime carries a cost writes a second column of thresholds for incidents and agrees who may invoke it.
Agreeing all that before it is needed is what makes it usable. In the middle of an outage nobody is negotiating who decides, and the difference between a project that escalates well and one that does not is almost entirely whether the conversation happened in advance.
Escalating on schedule is the relationship working as designed. A team told that escalation is a last resort will sit on an impediment for a week, and the week is spent inventing workarounds rather than waiting politely.
Tracking makes the pattern visible
Handled one at a time, blockers are a series of unrelated bad days. The fourth delay caused by the same shared environment feels like bad luck right up until somebody notices it is the fourth.
Log each one as it happens, with enough attached to it that somebody reading the list in three months can see a shape rather than a run of anecdotes.
| What the log records | What it lets you say three months later |
|---|---|
| What was blocked | Which piece of work stopped, so the cost has something attached to it |
| What caused it | Whether four separate bad weeks were one cause in four disguises |
| Who owned the resolution | Which queue outside the project is absorbing your schedule |
| The date raised and the date cleared | The number of days waited, which is the figure that changes conversations |
| How it was cleared in the end | Whether the designed path worked, or somebody spent a favour |
That fourth row is the one that earns the log. A fortnight of accumulated waiting on a single approval queue is an argument with a number attached, and a complaint about slow approvals is an opinion.
What the log exposes is the difference between an incident and a system. Incidents get resolved, whereas systems get redesigned, and the redesign might be a dedicated environment, a standing delegation, or a rule that an approval not answered within three days is treated as given.
The ones nobody raises
The dangerous impediments are the ones that stopped being reported. A team that has raised the same one repeatedly without result works around it instead, which looks like resilience and is actually the project quietly absorbing a cost nobody can see any more.
Asking what is slowing you down that you have stopped mentioning is a different question from asking whether there are any blockers, and it reliably gets a different answer. A retrospective is a good place for it, and a one to one is usually better, because the workaround somebody invented is easier to admit to without an audience.