5.4. Remove Impediments and Manage Issues
💡 First Principle: This task distinguishes a risk (something that might happen) from an issue (something that has happened) and from an impediment (something actively blocking progress right now) — the correct response and urgency differ for each, and recognizing which one you're facing is the tested skill.
Enablers: evaluate the impact of impediments, prioritize and highlight impediments, determine and apply an intervention strategy, continually reassess that impediments/obstacles/blockers are being addressed, recognize when a risk becomes an issue, and collaborate with stakeholders on resolving issues.
"Recognize when a risk becomes an issue" is the pivot point tested most often: once a previously-identified risk materializes, it moves out of the risk register's proactive planning and into active issue management — treating a materialized risk as still "just a risk to monitor" delays the response it now needs.
Four words that call for four different responses
| Term | What it is | What you do with it | Where it lives |
|---|---|---|---|
| Risk | A possible future event that might affect the project | Analyze, plan a response, monitor | Risk register |
| Issue | A risk or other problem that has already materialized | Resolve it, with an owner and a due date | Issue log |
| Impediment | Something actively blocking the team's progress right now | Remove or minimize it urgently | Impediment list or board, standup |
| Constraint | A known limiting factor that restricts your options | Work within it | Plan and baselines |
A build server that is down right now, stopping every developer from testing, is an impediment needing immediate intervention; an entry about "possible future server capacity constraints" stays a risk to monitor until it materializes. A fixed budget ceiling set at kickoff is not an impediment even when the team feels blocked by it — it is a constraint the plan must respect.
⚠️ Exam Trap: The first warning sign and the event itself are different moments. A vendor missing one milestone is a signal to act on the risk response; when the same vendor confirms it cannot deliver at all, the risk has become an issue, and continuing to "monitor" is the wrong answer.
From risk to issue
Once a license renewal is confirmed late and the team has lost access to a required tool, it is no longer a register entry. The issue goes into the issue log — the project document used to record, monitor and communicate issues — and follows a clear order:
Evaluate impact before you prioritize
Impact assessment comes first so that effort goes to the most damaging blocker, not the loudest or the most recently reported one. With three impediments in one sprint — a broken test environment blocking all QA, a minor UI inconsistency noticed by one stakeholder, and a slow approval for a low-priority design asset — the broken environment goes first because it stops the most valuable work. Priority follows actual impact, never report order or the seniority of whoever raised it. A PM who marks a new impediment as high priority on arrival and later finds it touched only a non-critical task skipped the evaluation step.
Choosing an intervention
Removing blockers is an active duty, consistent with the servant-leadership stance of adaptive delivery. When a team member has waited two weeks on another department's approval, you do not leave them to chase it alone; you follow up directly, escalate through governance channels, or set up an interim workaround.
Not every blocker needs you. Part of prioritizing is knowing which ones require PM-level authority and which the team resolves itself:
| Requires PM intervention | Team can usually self-resolve |
|---|---|
| A cross-departmental approval stalled for weeks | Two members double-booked on a meeting room |
| A vendor contract dispute blocking a critical component | Choosing between two similar internal documentation tools |
⚠️ Exam Trap: Answers in which the PM personally resolves every small team friction look diligent but undercut self-organization. Save PM intervention for blockers that need authority, cross-team leverage or contractual action.
Ownership and collaboration
An issue that falls between roles tends to sit untouched. The fix is to assign a clear owner and then work the resolution approach with the relevant stakeholders. When an issue spans your team and a partner organization, bring representatives of both together to assess it jointly and agree on a resolution each side can commit to — a fix imposed by one side rarely holds.
Reassess, and fix the pattern
Closed is not permanently closed. A blocker resolved two sprints ago can partially resurface, or a related obstacle can appear under changed conditions, so reassess continually. When the same impediment keeps recurring — another department's slow approvals, sprint after sprint — resolving each instance is treating symptoms; address the systemic cause, for example by negotiating a standing approval arrangement. And when a cross-team dependency has already caused three impediments, the proactive move is to coordinate that handoff or clarify ownership before the next sprint starts, rather than waiting for the fourth.
⚠️ Exam Trap: Continuing to "monitor" something in the scenario that has already clearly occurred. Once it's happened, it's an issue requiring resolution, not a risk requiring continued monitoring.
