Loại Bỏ Impediments & Quản Lý Issues theo PMBOK 8

1. Impediment, Obstacle, Blocker, Issue — Phân biệt rõ

PMBOK 8 sử dụng các thuật ngữ này interchangeably ở nhiều nơi, nhưng phân biệt quan trọng nhất là: impediments/obstacles/blockers = thứ CẢN TRỞ team (PM phải loại bỏ), issues = vấn đề ĐÃ XẢY RA (PM phải giải quyết).

2. Tại sao đây là kỹ năng Servant Leadership cốt lõi?

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 — phong cách lãnh đạo PMBOK 8 ưu tiên — đặt loại bỏ impediments là trách nhiệm hàng đầu của PM. PM không phải "boss ra lệnh" mà là "người dọn đường" cho team thành công.

PMBOK 8 cũng nêu rõ vai trò Sponsor: "advocating for the project team, and addressing issues or removing obstacles that are beyond the project management team's authority." PM xử lý những gì trong authority; escalate những gì ngoài authority lên sponsor.

Và vai trò Oversight: "Oversight and coordination enable the project team to deliver value by aligning efforts, removing obstacles, and maintaining team focus."

3. Framework 6 enablers

4. Đánh giá impact và ưu tiên hóa impediments

Evaluate Impact

Không phải mọi impediment đều equal — PM phải đánh giá impact trên nhiều chiều:

Prioritize and Highlight

"Highlight" là từ khóa quan trọng — PM phải làm impediments visible. Trong agile: impediment board, standup blockers section. Trong predictive: issue log, status reports, steering committee escalations. Invisible impediments = impediments that never get resolved.

5. Intervention strategies — Từ giải quyết đến escalate

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 — Giải quyết gốc rễ, không chỉ triệu chứng

PMBOK 8 liệt kê nhiều RCA tools: 5 Whys — hỏi "tại sao?" 5 lần liên tiếp để tìm root cause. Fishbone (Ishikawa) — phân loại nguyên nhân theo categories: People, Process, Technology, Environment, Policy. Root Cause Analysis — structured method phân tích: what happened → why → how to prevent recurrence.

Ví dụ 5 Whys: "Server testing down 3 ngày" → Why? "Cloud instance expired" → Why? "No one renewed" → Why? "No owner assigned" → Why? "Process doesn't specify resource ownership" → Root cause: Thiếu resource ownership process.

6. Khi risk trở thành issue — Nhận diện và hành động

Đây là enabler đặc biệt quan trọng — PM phải nhận biết thời điểm risk "trigger" và chuyển từ monitoring sang 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, và issues là 3 thứ khác nhau. PM phải classify đúng để respond đúng.

Khi risk trigger — 4 bước hành động

1. 1. Confirm trigger — Risk event đã xảy ra chưa? Hay chỉ gần xảy ra?

2. 2. Execute planned response — Nếu risk response đã planned → implement ngay. Nếu chưa → develop workaround.

3. 3. Move to issue log — Chuyển từ risk register sang issue log. Assign issue owner.

4. 4. Assess secondary risks — Risk response có tạo ra risks mới không? (secondary risks)

7. Collaborate với stakeholders để giải quyết

Nhiều issues vượt khỏi authority của PM — cần sự tham gia của stakeholders khác nhau.

PMBOK 8: "Holding discussions to explore the root cause of the issue and identify acceptable adjustments." — PM facilitate discussions, không unilaterally quyết định.

Reassess Continually

Impediments và issues không phải "fix once, forget forever." PM phải: review impediment/issue boards daily (standup), review issue log weekly (status meeting), assess whether resolutions are WORKING (not just implemented), identify NEW impediments proactively, và monitor for recurring patterns (systemic issues need systemic solutions).

8. Predictive vs. Adaptive

9. Mẹo thi PMP

📍Mẹo 1 — Servant Leader removes impediments: Khi đề mô tả "team is blocked" — đáp án đúng luôn là PM/Scrum Master proactively removes the impediment. KHÔNG phải "ask team to find workaround" hoặc "wait for the issue to resolve itself."

📍Mẹo 2 — Risk ≠ Issue: Risk = uncertain event (MAY happen). Issue = current problem (IS happening). Khi đề mô tả "the identified risk has occurred" → it's now an issue. Execute the planned response. Move to issue log.

📍Mẹo 3 — Escalate when beyond authority: Khi PM cannot resolve → escalate per governance. "PM tries to resolve everything alone" = wrong. "PM escalates without trying first" = also wrong. Try within authority FIRST, escalate if unsuccessful.

📍Mẹo 4 — Root cause, not just symptom: Khi đề mô tả "same impediment keeps recurring" → đáp án liên quan đến root cause analysis (5 Whys, Fishbone), KHÔNG phải "fix it again" hoặc "add more buffer."

10. Mười câu hỏi trắc nghiệm tình huống

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.

Đáp án

Question 1: Answer: B

— Recurring impediments = symptom of 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 — team member completely stopped. PMBOK 8: "removing impediments builds a supportive culture." As servant leader, the PM should act immediately. Waiting for status meeting (C) or asking developer to work around (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. Tổng kết

Removing impediments và managing issues là nơi PM chứng minh giá trị hàng ngày — không phải qua plans hay reports, mà qua hành động cụ thể giúp team tiếp tục tiến lên. Ba takeaways:

1. 1. Act, don't just log — Impediment board với 30 items "open" = hệ thống vô dụng. PM phải close the loop: identify → prioritize → act → verify → communicate. Logging without resolution builds frustration and erodes trust. Team sẽ ngừng report nếu reports không dẫn đến action.

2. 2. Root cause > Quick fix cho recurring issues — Server down lần thứ 3? Đừng chỉ fix lần 3 — hỏi TẠI SAO nó cứ down. 5 Whys và Fishbone giúp tìm systemic causes. Fix symptoms = fix forever. Fix root cause = fix once, prevent forever.

3. 3. Know when risk becomes issue — and ACT — Risk register + planned responses = chuẩn bị sẵn. Khi risk trigger → execute response ngay, không deliberate. Chuyển sang issue log, assign owner, monitor resolution. PM chậm recognize risk trigger = PM để issue escalate thành 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." — Đây là mô tả ngắn gọn nhất về vai trò PM trong impediment management: align, remove, focus.

Câu Hỏi Thường Gặp (FAQ)

Risk và Issue khác nhau thế nào trong PMBOK?

Risk: sự kiện không chắc chắn trong tương lai, có thể positive (opportunity) hoặc negative (threat). Issue: vấn đề đã xảy ra và cần giải quyết ngay — risk đã trở thành reality. Khi risk trigger xảy ra, risk chuyển thành issue và chuyển từ Risk Register sang Issue Log. PM cần manage cả hai song song.

Issue Log nên chứa những thông tin gì?

Issue Log ghi nhận: ID và mô tả issue, date raised, owner (người chịu trách nhiệm resolve), priority (High/Medium/Low), impact assessment, proposed solutions, action items với due dates, status (Open/In Progress/Closed), và date resolved. Issue Log là 'living document' — update thường xuyên trong project meetings.

Trong agile, Scrum Master loại bỏ impediments như thế nào?

Scrum Master có responsibility chính là remove impediments cho development team. Process: (1) Team report impediments trong Daily Scrum. (2) Scrum Master escalate ngay những gì vượt khỏi team's control. (3) Work với organization (management, other teams, vendors) để clear impediments. (4) Track impediments trong Impediment Backlog. Goal: team không bị block hơn 24 giờ.

Bạn đã nắm vững quản lý issues và impediments dự án — giờ là lúc luyện tập với câu hỏi thi thật.

• Bài tiếp theo: Quản Lý Rủi Ro Dự Án: Từ Nhận Diện đến Giám Sát theo PMBOK 8

• Quản lý thay đổi dự án: Change Control Process theo PMBOK 8

• Governance và escalation trong dự án theo PMBOK 8

Làm thử đề PMP miễn phí →

Nguồn tham khảo chính thức:

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