Impediment Removal & Issue Management: PMBOK 8 Guide

1. Impediment, Obstacle, Blocker, Issue — Clear Definitions

PMBOK 8 uses these terms interchangeably in many places, but the most important distinction is: impediments/obstacles/blockers = things that HINDER the team (the PM must remove them), issues = problems that HAVE OCCURRED (the PM must resolve them).

2. Why This Is a Core Servant Leadership Skill

PMBOK® 8, Section 2.6.2.4.2: "Supporting project team members through problem-solving and removing impediments builds a supportive culture and leads to a trusting and collaborative environment."

Servant Leadership — the leadership style PMBOK 8 prioritizes — places removing impediments as the PM's primary responsibility. The PM is not a "boss giving orders" but a "path-clearer" enabling the team to succeed.

PMBOK 8 also clarifies the Sponsor's role: "advocating for the project team, and addressing issues or removing obstacles that are beyond the project management team's authority." The PM handles what is within their authority; they escalate what falls outside it to the sponsor.

And on the Oversight role: "Oversight and coordination enable the project team to deliver value by aligning efforts, removing obstacles, and maintaining team focus."

3. Framework of 6 Enablers

4. Evaluating Impact and Prioritizing Impediments

Evaluate Impact

Not all impediments are equal — the PM must assess impact across multiple dimensions:

Prioritize and Highlight

"Highlight" is a key word — the PM must make impediments visible. In Agile: impediment board, standup blockers section. In Predictive: issue log, status reports, steering committee escalations. Invisible impediments are impediments that never get resolved.

5. Intervention Strategies — From Resolution to Escalation

5 Intervention Strategies

PMBOK® 8: "Escalation is often useful in hierarchical organizations where decision-making authority includes individuals outside of project team members, or in organizations where higher-ranking individuals have greater ability to remove persistent obstacles or resolve conflicts."

Root Cause Analysis — Solve the Root, Not Just the Symptom

PMBOK 8 lists several RCA tools: 5 Whys — ask "why?" five times in succession to find the root cause. Fishbone (Ishikawa) — categorize causes by type: People, Process, Technology, Environment, Policy. Root Cause Analysis — a structured method: what happened → why → how to prevent recurrence.

Example using 5 Whys: "Test server has been down for 3 days" → Why? "Cloud instance expired" → Why? "No one renewed it" → Why? "No owner was assigned" → Why? "The process doesn't specify resource ownership" → Root cause: Missing resource ownership process.

6. When a Risk Becomes an Issue — Recognize and Act

This is a particularly critical enabler — the PM must recognize the moment a risk "triggers" and shift from monitoring to action.

PMBOK® 8, Section 2.7.2.2: "The process of risk identification focuses on distinguishing genuine risks from nonrisks, such as concerns and issues." — Risks, concerns, and issues are three different things. The PM must classify them correctly to respond correctly.

When a Risk Triggers — 4 Steps to Take

1. 1. Confirm trigger — Has the risk event actually occurred? Or is it just approaching?

2. 2. Execute planned response — If a risk response was planned → implement it immediately. If not → develop a workaround.

3. 3. Move to issue log — Transfer from the risk register to the issue log. Assign an issue owner.

4. 4. Assess secondary risks — Does the risk response itself create new risks? (secondary risks)

7. Collaborate with Stakeholders to Resolve Issues

Many issues fall outside the PM's authority — they require the involvement of different stakeholders.

PMBOK 8: "Holding discussions to explore the root cause of the issue and identify acceptable adjustments." — The PM facilitates discussions; they do not make unilateral decisions.

Reassess Continually

Impediments and issues are not "fix once, forget forever." The PM must: review impediment/issue boards daily (standup), review the issue log weekly (status meeting), assess whether resolutions are actually WORKING (not just implemented), proactively identify NEW impediments, and monitor for recurring patterns (systemic issues need systemic solutions).

8. Predictive vs. Adaptive

9. PMP Exam Tips

📍Tip 1 — Servant Leader removes impediments: When a question describes a "team that is blocked" — the correct answer is always that the PM/Scrum Master proactively removes the impediment. NOT "ask the team to find a workaround" or "wait for the issue to resolve itself."

📍Tip 2 — Risk ≠ Issue: Risk = uncertain event (MAY happen). Issue = current problem (IS happening). When a question states "the identified risk has occurred" → it is now an issue. Execute the planned response. Move to the issue log.

📍Tip 3 — Escalate when beyond authority: When the PM cannot resolve it → escalate per governance. "PM tries to resolve everything alone" = wrong. "PM escalates without trying first" = also wrong. Try within authority FIRST, then escalate if unsuccessful.

📍Tip 4 — Root cause, not just symptom: When a question describes "the same impediment keeps recurring" → the correct answer involves root cause analysis (5 Whys, Fishbone), NOT "fix it again" or "add more buffer."

10. Ten Situational Practice Questions

Question 1

During the daily standup, a developer says: "I've been waiting 4 days for the database team to set up the test environment. I can't continue my work."

What should the PM do FIRST?

A. Ask the developer to work on other tasks while waiting.

B. Immediately contact the database team lead to understand the delay, assess the impact on the sprint goal, and work to resolve the blocker — this is a servant leadership responsibility.

C. Add the item to the issue log and review at the next status meeting.

D. Escalate to the sponsor.

Question 2

The same testing environment issue has occurred 3 times in the past 2 months. Each time, the PM contacts the database team and gets it fixed within a day.

What should the PM do differently?

A. Continue fixing it each time — the resolution is quick.

B. Conduct root cause analysis to understand WHY this keeps recurring and implement a systemic fix — recurring impediments indicate a process or structural issue, not just an operational one.

C. Create automated alerts for the database team.

D. Escalate to the database team's manager.

Question 3

Your risk register identified "key vendor may miss API delivery deadline" as a high-probability risk with a planned response of "use mock API for testing." The vendor just confirmed they will miss the deadline by 3 weeks.

What should you do?

A. Wait until the vendor delivers — 3 weeks is manageable.

B. The risk has materialized into an issue. Execute the planned response (mock API), move the risk to the issue log, assign an issue owner, communicate the impact to stakeholders, and monitor for secondary risks.

C. Submit a change request to extend the schedule by 3 weeks.

D. Find an alternative vendor.

Question 4

Your team identifies 8 impediments during the sprint retrospective. Resources are limited — you can't address all simultaneously.

How should you prioritize?

A. Address them in the order they were reported.

B. Evaluate each by impact (on schedule, quality, team productivity) and ease of resolution. Tackle high-impact/easy-to-resolve items first (quick wins), then plan strategies for high-impact/hard-to-resolve items. Low-impact items go to the backlog.

C. Let the team vote on which to address first.

D. Address all 8 equally by dividing resources.

Question 5

A team member escalates to you: "The compliance department takes 2 weeks to review our deliverables, but our sprints are 2 weeks. By the time they approve, we've already moved on."

What type of impediment is this, and how should you address it?

A. Accept it — compliance reviews can't be shortened.

B. This is a PROCESS impediment — the compliance review cycle doesn't align with the delivery cadence. Collaborate with the compliance team to find solutions: embedded compliance reviewer in the team, parallel reviews, automated compliance checks, or adjusted review schedule.

C. Extend sprints to 4 weeks to accommodate reviews.

D. Skip compliance reviews for non-critical deliverables.

Question 6

The project sponsor is supposed to make a go/no-go decision for Phase 2. It's been 3 weeks and the sponsor hasn't responded despite multiple emails. The team is idle, and costs are mounting.

What should you do?

A. Proceed to Phase 2 — the sponsor's silence implies approval.

B. Continue waiting and document the delay.

C. Escalate the urgency: request a face-to-face meeting with the sponsor, present the impact of delay (idle resources, cost, schedule), and if still unresolved, escalate to the steering committee per the governance framework.

D. Have the team work on other tasks while waiting.

Question 7

During a project, you notice that the team has developed a "workaround culture" — instead of reporting and resolving impediments, they quietly work around them. Velocity is stable but technical debt is accumulating.

What is the underlying issue?

A. The team is resourceful — this is a positive behavior.

B. The team doesn't feel safe reporting impediments — possibly because past reports weren't acted on, or they fear being seen as complainers. The PM needs to rebuild trust: demonstrate that reporting impediments leads to action, celebrate transparency, and create visible tracking.

C. The team needs training on impediment reporting processes.

D. Technical debt is a separate issue from impediment management.

Question 8

A vendor delivers a component that fails integration testing. The vendor claims their component meets specifications (true), but integration with your system fails due to an undocumented API behavior.

Is this a risk that became an issue, or a new issue?

A. This is a new issue — API behavior wasn't documented in specs.

B. Check the risk register. If "vendor integration challenges" was identified as a risk, this is a MATERIALIZED risk. Execute the planned response. If it wasn't identified, this is a new issue — log it, assess impact, develop resolution plan, and add "undocumented API dependencies" to risk register for remaining vendor work.

C. This is the vendor's problem — escalate to procurement.

D. Reject the deliverable and require the vendor to fix.

Question 9

Your agile team faces a blocker: a third-party API they depend on is experiencing outages 3-4 times per week, each lasting 2-3 hours. The third party says they're "working on it" but gives no timeline.

What intervention strategy should you apply?

A. Wait for the third party to fix their issues.

B. Apply a multi-pronged strategy: implement a workaround (local caching, mock service for development), negotiate specific commitments from the third party (SLA, timeline, escalation), explore alternative providers, and add the unreliability to the risk register for contingency planning.

C. Remove the dependency by rebuilding the functionality in-house.

D. Reduce sprint scope to account for the outages.

Question 10

At the end of each sprint, the team identifies impediments in retrospectives. The PM diligently logs them. After 6 sprints, the impediment log has 42 items — 30 are still "open" with no action taken.

What does this reveal?

A. The team is identifying too many impediments — they need to prioritize better.

B. The impediment management process is broken. Impediments are identified and logged but NOT resolved. The PM must: triage the 30 open items immediately, prioritize by impact, create action plans for top items, close irrelevant ones, and establish a cadence for impediment review and resolution — not just logging.

C. Some impediments are naturally unresolvable — accept them.

D. Delegate impediment management to the Scrum Master.

Answer Key

Question 1: Answer: B

— Recurring impediments = symptom of a deeper issue. PMBOK 8 Root Cause Analysis and 5 Whys are designed for exactly this. Fixing symptoms repeatedly wastes time and doesn't prevent recurrence. The root cause might be: no monitoring, unclear ownership, or infrastructure underinvestment.

Question 2: Answer: B

— Risk trigger has occurred = risk becomes issue. PMBOK 8: "Implement Risk Responses ensures that agreed-upon risk responses are executed as planned." The planned response (mock API) exists — implement it. Move to issue log. Assess whether the mock API fully mitigates the impact or if additional actions are needed.

Question 3: Answer: B

— The ECO requires "prioritize and highlight impediments." Impact × ease of resolution = prioritization framework. Quick wins (high impact, easy fix) first — they give the team immediate relief and build momentum. Hard problems need planned strategies. Team voting (C) may be useful but should be guided by impact assessment, not just preference.

Question 4: Answer: B

— This is a systemic impediment requiring collaboration. PMBOK 8: "Collaborate with relevant stakeholders on an approach to resolve the issues." The PM should work WITH compliance to find a solution that serves both agile delivery and compliance needs — not bypass compliance (D) or sacrifice agile cadence (C).

Question 5: Answer: C

— Silence ≠ approval. The PM must actively pursue resolution. PMBOK 8: "Escalation is useful when higher-ranking individuals have greater ability to remove persistent obstacles." After attempting direct contact, escalation to governance is appropriate. Proceeding without approval (A) violates governance. Waiting passively (B) wastes resources.

Question 6: Answer: B

— "Workaround culture" signals that the team doesn't believe impediments will be addressed. PMBOK 8: "Supporting project team members through problem-solving and removing impediments builds a TRUSTING environment." If the PM doesn't act on reported impediments, the team stops reporting — and problems go underground, accumulating as technical debt.

Question 7: Answer: B

— The answer depends on whether this was an identified risk. The ECO requires PMs to "recognize when a risk becomes an issue." If the risk was planned for, execute the response. If not, it's a new issue that also teaches a lesson: add similar risks for future vendor work. Blaming (C, D) without analysis doesn't solve the integration problem.

Question 8: Answer: B

— This is a BLOCKER — the team member has completely stopped. PMBOK 8: "removing impediments builds a supportive culture." As a servant leader, the PM should act immediately. Waiting for the status meeting (C) or asking the developer to work around it (A) doesn't address the blocker. Escalation (D) is premature before trying direct resolution.

Question 9: Answer: B

— PMBOK 8's holistic approach: don't rely on one strategy. Workaround provides immediate relief. Negotiation addresses the root source. Alternative exploration provides backup. Risk register ensures ongoing monitoring. Waiting (A) is passive. Rebuilding (C) may be disproportionate. Reducing scope (D) accepts the problem rather than solving it.

Question 10: Answer: B

— The ECO requires "reassess continually to help ensure impediments are being addressed." 30/42 unresolved = process failure. Logging without action = worse than not logging (creates frustration and learned helplessness). The PM must close the loop: identify → prioritize → act → verify → communicate. An impediment log without action plans is just a complaint board.

11. Conclusion

Removing impediments and managing issues is where the PM demonstrates daily value — not through plans or reports, but through concrete action that keeps the team moving forward. Three key takeaways:

1. 1. Act, don't just log — An impediment board with 30 "open" items is a useless system. The PM must close the loop: identify → prioritize → act → verify → communicate. Logging without resolution builds frustration and erodes trust. The team will stop reporting if reports don't lead to action.

2. 2. Root cause over quick fix for recurring issues — Server down for the third time? Don't just fix it again — ask WHY it keeps going down. 5 Whys and Fishbone help uncover systemic causes. Fix the symptom = fix forever. Fix the root cause = fix once, prevent forever.

3. 3. Know when a risk becomes an issue — and ACT — Risk register + planned responses = preparation in place. When a risk triggers → execute the response immediately, without deliberating. Move to the issue log, assign an owner, monitor resolution. A PM slow to recognize a risk trigger is a PM who lets an issue escalate into a crisis.

PMBOK® 8, Section 2.4.1: "Oversight and coordination enable the project team to deliver value by aligning efforts, removing obstacles, and maintaining team focus." — This is the most concise description of the PM's role in impediment management: align, remove, focus.

Frequently Asked Questions (FAQ)

How do risks and issues differ in PMBOK?

Risk: an uncertain future event that may be positive (opportunity) or negative (threat). Issue: a problem that has already occurred and requires immediate resolution — a risk that has become reality. When a risk trigger occurs, the risk becomes an issue and moves from the risk register to the issue log. The PM must manage both in parallel.

What information should an issue log contain?

The issue log records: ID and description of the issue, date raised, owner (the person responsible for resolution), priority (High/Medium/Low), impact assessment, proposed solutions, action items with due dates, status (Open/In Progress/Closed), and date resolved. The issue log is a "living document" — updated regularly during project meetings.

How does a Scrum Master remove impediments in an agile environment?

The Scrum Master's primary responsibility is to remove impediments for the development team. Process: (1) Team reports impediments during the Daily Scrum. (2) Scrum Master immediately escalates anything beyond the team's control. (3) Works with the organization (management, other teams, vendors) to clear impediments. (4) Tracks impediments in an Impediment Backlog. Goal: the team should never be blocked for more than 24 hours.

Now that you understand project issue and impediment management — it's time to put it into practice with real exam questions.

• Next article: Project Risk Management: From Identification to Comprehensive Monitoring according to PMBOK 8

• Project change management: Change Control Process according to PMBOK 8

• Governance and escalation in projects according to PMBOK 8

Try Free PMP Practice Questions →

Official References:

• PMBOK® Guide Standards — PMI (pmi.org)