Removing impediments, obstacles and blockers for the team is a task PMI names in the People domain, and it occupies more of a project manager's week than any single technique does. An impediment is anything stopping work that the team cannot clear itself. Both halves of that definition matter. Work that is merely hard belongs to the team, and a problem the team can solve in an afternoon is the work itself.
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. The sections below describe what blockers are made of, the difference between removing one and causing it to be removed, how an escalation path is designed and why a log of blockers is worth keeping.
What blockers are 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 and a policy written for a different kind of work.
Almost all of those sit outside the team and most sit outside the project entirely. This is the whole reason clearing them is a distinct job, because the team can usually see the obstruction perfectly well and has no standing to move it.
An impediment is also different from a risk and from an issue, and the three travel to different places. A risk might happen. An issue has happened and belongs to the project to resolve. An impediment is stopping work now and usually belongs to somebody outside the project, so it needs a route out of the project, which is the reason the escalation path exists at all.
Removing a blocker and causing it to be removed
Before the route out is used, there is a distinction to draw between clearing an obstacle personally and causing it to be cleared. Only a minority are the project manager's 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, because the decision being waited for 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 and has not acted on it.
Escalation as a designed path
Causing removal often means going up, and escalation has 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, and a department name does not count. Each has a threshold, meaning how long the team waits before it goes up. Each has a route back, so whoever raised it hears the outcome.
Every arrow carries a threshold agreed before anybody needs it, so the decision to move an impediment up is made by the clock. 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.
The impediment log
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.
Each one is logged as it happens, with enough attached to it that somebody reading the list in three months can see a shape.
| What the log records | What it shows 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 the project's 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 |
The 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 and 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 blockers nobody raises
The log has one gap, which is the impediments 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 the team down that it has 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.