PMP Impediments and Issues: Remove Blockers, Escalate and Resolve

An impediment (also called a blocker or obstacle) is anything that stops or slows the team from doing its work: a broken environment, a missing approval, a slow procurement step, an unavailable specialist, constant interruptions. An issue is a current condition or problem that is affecting the project's objectives and needs to be resolved. The two overlap heavily: agile teams tend to say "impediment", predictive teams tend to say "issue", and a blocker that threatens a goal is both.

The PMP Examination Content Outline frames this task as a cycle the project manager runs for the whole project, not a one-off fix:

1. Evaluate the impact of the impediment.
2. Prioritize and highlight it so the right people see it.
3. Determine and apply an intervention strategy to remove or minimize it.
4. Reassess continually until the work is actually moving again.

Alongside that cycle sit two issue skills: recognizing when a risk becomes an issue, and collaborating with the relevant stakeholders on how to resolve it. The mindset running through all of it is servant leadership: the project manager exists to keep the team's path clear, without taking over decisions the team or other stakeholders own.

The first move with any new impediment is to find out what it actually blocks: which stories, activities or deliverables, which goal or milestone they feed, for how long, and whether anything absorbs the delay. Acting before that analysis (escalating, removing scope, re-planning, announcing a slip) risks the wrong response at the wrong strength.

Useful questions:

• Which work items depend on the blocked resource, and when are they needed? An unavailable specialist matters only for the work that needs that person while they are away.
• Does it threaten the sprint goal, a committed release, or the critical path?
• Can the team keep working on something else meanwhile?
• In a predictive schedule, how does the delay compare with the activity's total float?

Float decides schedule impact

A delay on a critical-path activity (zero float) moves the end date day for day. A delay on a noncritical activity is absorbed only up to its float; anything beyond the float pushes that path past the critical path and becomes the new driver of the date. For example, a 6-day slip on an activity with 2 days of float pushes the end date out by 4 days, which is more than a 3-day slip on the original critical path would. Always recalculate rather than assume "critical path first".

When several delays hit parallel paths that feed the same milestone, the slips do not add up. The milestone moves by the largest net delay among the paths (each path's delay minus its float). That net figure is what you compare against any escalation threshold in the governance plan.

Impediments are ranked by their effect on value and commitments: first what blocks the sprint goal, a committed release or the critical path, then what costs the most delivery capacity. Size, age, how loudly it was raised, how many people mention it, or who raised it are not the ranking criteria. A tooling annoyance that wastes a little of everyone's time is real waste, but a blocker that stops the work the sprint goal depends on comes first. An old, unanswered request is not more urgent just because it is old.

Finding the vital few with data

When a team has logged many impediments over time, a Pareto chart (categories sorted by frequency or hours lost, with a cumulative line) shows the few categories that cause most of the loss, so effort can target them first. Know the neighbouring quality tools so you pick the right one:

Highlighting means making impediments visible, in priority order, to the people who can remove them, while there is still time to act. A blocker known only inside the team, or reported weeks later in a monthly steering pack, is a blocker nobody outside can help with.

• Impediment board or backlog: a visible list of open blockers with owner, date raised and status, kept in the team area or a shared online tool.
• Information radiators: big visible charts and boards that stakeholders can glance at without asking.
• Daily stand-up: where impediments are surfaced; the conversation about removing them usually happens straight afterwards with the people involved.
• Shared prioritized list for blockers that only managers outside the team can clear (releasing a specialist, approving a tool), visible to them daily rather than through a periodic report.

Private chat threads, long monthly reports and saving blockers for the retrospective all fail the same test: the person who could act sees the problem too late.

The intervention strategy depends on who can solve the impediment and whether it can be removed in time. Match the strength of the intervention to the situation, and step it up only as needed.

Servant leadership in practice

Shielding the team often means channelling, not blocking. If stakeholders keep pulling developers into ad hoc requests, route those requests through the product owner, who can weigh them against the backlog. Telling developers to refuse requests discards value; adding a permanent "interruption buffer" accepts the waste instead of fixing it.

Escalating the intervention step by step

When a self-organizing team is stuck on a decision it owns (two workable designs, no agreement), the project manager raises the strength of facilitation rather than taking the decision: for example, helping the team run a short, time-boxed spike or experiment that produces evidence to decide with. Picking the answer for the team, escalating a team-owned decision, or holding endless meetings in search of full consensus all fail in different ways.

Some impediments come from required controls: a regulatory approval, a policy-mandated review board, a quality sign-off. These cannot be skipped, but their effect can be reduced through legitimate means:

• Reorder the work so items that do not depend on the control carry on while it runs.
• Work with the process owner to agree a faster route that still meets the control's intent, for example a lighter path for low-risk changes agreed with the review board.
• Use the control's own rules, such as an authorized alternate or deputy approver named by the function that owns the control.

What fails: starting work on the assumption that approval will come, releasing first and informing the control owner afterwards, asking a sponsor to sign something they are not authorized to sign, or asking for an exemption simply because the control is slow. Equally, passively waiting and planning around a delay that the process itself could legitimately shorten leaves value on the table. The principle is to change or use the process with its owner, never to route around it.

Escalation is the right intervention when the impediment is outside the project manager's authority and direct collaboration with its owner has been tried and has failed. Talking to the impediment's owner comes first: a dependency held up by another group is first worked through with that group's owner, and only then taken higher if it stays blocked.

A good escalation:

• goes to the decision-maker the governance plan names for that kind of conflict (the role the plan assigns to that category of conflict), not to whoever seems most senior;
• states the impact (which goal or milestone, by how much) and the options with their trade-offs, so the decision can be made quickly;
• respects thresholds: if governance lets the project manager handle slips up to a set size, a correctly calculated slip within that limit is handled directly.

Two opposite mistakes are common: escalating before trying, and continuing to negotiate indefinitely after the owner has refused and a committed milestone is at risk. Quietly re-planning a committed milestone without a decision is not an option either.

Reassessment keeps impediments from going stale. An impediment is resolved when the blocked work is moving again, not when a request has been sent or a ticket closed. If developers say they are still waiting after a blocker was "cleared", the next step is to ask them what is stopping the work now.

Practices that keep the list honest:

• Review the impediment board with the team at a set, frequent cadence (agile teams often use the stand-up or straight after it), not just at release planning.
• Give every item an owner and an age, and keep it open until the team confirms it is cleared.
• Remove items that no longer matter, and re-rank as priorities change.

Recurring impediments need root cause work

When the same blocker comes back sprint after sprint (an environment that keeps breaking, an integration that fails at intervals), clearing it faster each time treats the symptom. Analyse the cause with the people who own the system and the team, agree a lasting fix, and track it to closure. Adding a permanent buffer to absorb the loss, or recording each occurrence without acting, accepts the waste. This links to continuous improvement, which is covered as its own task.

A risk is an uncertain event or condition that, if it occurs, would affect the project. An issue is something that has occurred or is now certain and is affecting the project. A risk becomes an issue at the moment the event happens or becomes certain: the event in the risk statement actually happens, or the outcome is confirmed rather than merely likely.

Things that are not the event itself leave it a risk: a trigger or warning sign (an early indicator that the event is approaching), a higher probability rating, or more worry. These raise the odds and may prompt you to prepare the response, but nothing has happened yet.

An identified risk occurs

• The risk owner executes the planned response (that is the point of planning it). No need to re-analyse or raise a change request for a new response.
• Its cost comes from the contingency reserve, which is inside the cost baseline and set aside for identified risks, as long as enough remains.
• Record it in the issue log with an owner and target date, and update the risk register entry to show the risk occurred. Do not simply delete it; the history feeds lessons learned.

An unidentified problem occurs

• There is no planned response, so log the issue and agree a workaround (an unplanned response to a problem that has occurred) with those affected, especially when it is on the critical path. Analysing its probability as if it were still a risk, or waiting for the next risk review, wastes time.
• Funding comes from the management reserve, which sits outside the cost baseline for unidentified work; using it needs approval from the sponsor or management and adds that amount to the cost baseline through change control. Unused contingency is not for problems that were never identified.

Identifying, analysing and planning responses to risks are covered in the separate risk-management task; this task is about the hand-over point when a risk turns real.

The issue log is the project document that records current problems, each with a description, an owner, a target resolution date, a status and the resolution. An issue that has been discussed for weeks but has no owner or date is a discussion topic, not a managed issue; assigning both is the fix. Keep the neighbouring documents distinct:

Collaborate on the resolution

Issues that cross boundaries are resolved with the stakeholders who own part of the problem or carry its impact, not by the project manager alone:

• When parties who each own part of a problem disagree about its cause, bring them together to analyse it jointly before deciding who fixes what.
• When the fix is a trade-off between workable options (delay, manual effort, fix after cutover), review the options with the people who would carry the impact and the decision-maker, such as the affected business manager and the sponsor.
• On agile work, when a production defect competes with sprint work, bring the facts (impact, effort) to the product owner, who decides its priority against the sprint goal.

Collaboration does not mean endless discussion: when the parties cannot agree and the decision is not the project manager's, the issue goes up the governance path with options.