Ngân hàng đề — PMI Project Management Professional

🧩 Giải thích nội dung câu hỏi

Câu hỏi này thuộc chủ đề Quản lý Giao tiếp (Manage Communications) và Quản lý Lịch trình (Schedule Management) trong PMP, theo PMBOK® Guide – Seventh Edition (cập nhật đến 2026). Tình huống mô tả một dự án lai (hybrid project) trong nhà máy công nghiệp đang hoạt động liên tục:

• Thêm công suất bằng cách lắp đặt máy móc mới (sử dụng cách tiếp cận predictive – lập kế hoạch trước, tuyến tính).
• Cập nhật phần mềm sản xuất (sử dụng cách tiếp cận agile – lặp lại, linh hoạt để giảm rủi ro).
  Dự án diễn ra song song mà không làm gián đoạn sản xuất, đòi hỏi sự phối hợp chặt chẽ giữa hai phần (hardware predictive và software agile) để tích hợp và đảm bảo tiến độ.
  📌 Câu hỏi trọng tâm: Project Manager (PM) cần thiết kế loại giao tiếp nào vào schedule management plan (kế hoạch quản lý lịch trình) để theo dõi và kiểm soát tiến độ dự án hiệu quả?
  Điều này nhấn mạnh nhu cầu giao tiếp tần suất cao, trực tiếp tại chỗ để xử lý rủi ro thời gian thực, đặc biệt trong môi trường hybrid và nhà máy đang vận hành (theo nguyên tắc Tailoring trong PMBOK 7).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Weekly colocated meetings with the relevant stakeholders
🛠️ Lý do chi tiết:

• Dự án hybrid yêu cầu giao tiếp tần suất cao (hàng tuần) để đồng bộ hóa giữa phần agile (cần feedback nhanh, iterative) và predictive (cần milestone rõ ràng). "Weekly" phù hợp với cadence agile (gần với daily stand-up nhưng điều chỉnh cho hybrid).
• Colocated meetings (họp trực tiếp tại chỗ) là lý tưởng vì nhà máy đang hoạt động – cần quan sát thực tế, giải quyết vấn đề ngay lập tức (như tích hợp máy móc với phần mềm), giảm hiểu lầm so với remote. Điều này đảm bảo schedule adherence bằng cách phát hiện lệch tiến độ sớm.
• Theo PMBOK 7, trong hybrid environments, colocated meetings hỗ trợ high-velocity decision-making và integration (Agile Practice Guide, phần Hybrid Approaches). Đưa vào schedule management plan giúp lập lịch họp cố định, tránh trì hoãn.

📋 Giải thích tất cả các phương án (đúng và sai)

Dưới đây là phân tích từng lựa chọn theo thứ tự, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên tính phù hợp với dự án hybrid, tần suất, phương thức và nhu cầu đảm bảo tiến độ:

• ✅ Weekly colocated meetings with the relevant stakeholders
  Đúng vì: Phương án này cung cấp giao tiếp trực tiếp, hàng tuần – lý tưởng cho hybrid project trong nhà máy đang chạy. Colocated giúp phối hợp real-time giữa stakeholders (chủ nhà máy, đội agile, đội predictive), phát hiện rủi ro tích hợp sớm (ví dụ: máy móc không khớp phần mềm). Tần suất weekly cân bằng giữa agile (iterative) và predictive (milestone), dễ tích hợp vào schedule plan mà không làm gián đoạn sản xuất. (Tham khảo: PMBOK 7, Domain: Project Work 📘).

• ❌ Biweekly conference calls with the relevant stakeholders
  Sai vì: "Biweekly" (2 tuần/lần) quá thưa thớt cho dự án hybrid cần theo dõi liên tục – có thể bỏ lỡ lệch tiến độ giữa máy móc (predictive) và software (agile). Conference calls (gọi hội nghị từ xa) thiếu tương tác trực tiếp, kém hiệu quả trong môi trường nhà máy (cần quan sát vật lý). Không đủ để "ensure on schedule" (PMBOK 7 nhấn mạnh frequent communication cho ongoing operations).

• ❌ Weekly one-on-one meetings with each of the relevant stakeholders
  Sai vì: Mặc dù tần suất "weekly" tốt, nhưng one-on-one (họp cá nhân) không hiệu quả cho phối hợp nhóm trong hybrid project. Thiếu sự tham gia đồng thời của tất cả stakeholders dẫn đến silo thông tin, khó tích hợp hai phần dự án (máy + software). Tốn thời gian PM hơn họp nhóm colocated, không tối ưu cho schedule management (Process Groups Practice Guide khuyến nghị group meetings cho alignment 🛠️).

• ❌ Biweekly written status reports from the relevant stakeholders
  Sai vì: "Biweekly written reports" (báo cáo viết 2 tuần/lần) là thụ động, chậm – không phù hợp agile (cần interactive feedback) hay môi trường nhà máy real-time. Written reports dễ bị bỏ qua hoặc thiếu chi tiết, không giải quyết vấn đề ngay (ví dụ: delay lắp máy). PMBOK 7 ưu tiên interactive methods cho high-risk/hybrid projects thay vì passive reporting (Manage Communications: Models of Communication).

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, cập nhật 2026): Chương 4 (Project Communications Management), Tailoring for Hybrid; Domain 5: Project Work.
• Agile Practice Guide (2017, tích hợp PMBOK 7): Phần 4.4 Hybrid Life Cycles – nhấn mạnh colocated interactions.
• Process Groups: A Practice Guide (2022): Schedule Management trong hybrid contexts.
  Những tài liệu này xác nhận colocated weekly meetings là best practice cho tình huống này! 🚀

🧩 Giải thích nội dung câu hỏi

Câu hỏi này thuộc lĩnh vực Quản lý Phạm vi Dự án (Project Scope Management) và Quản lý Yêu cầu (Requirements Management) trong PMP. Trong quá trình xem xét danh sách các sản phẩm bàn giao (deliverables) của dự án, một bên liên quan (stakeholder) bày tỏ lo ngại rằng một yêu cầu (requirement) cụ thể sẽ không được đáp ứng. Project Manager cần hành động ngay lập tức để xác minh và giải quyết vấn đề này một cách chính xác, dựa trên các công cụ chuẩn mực của PMP.

Mục tiêu là kiểm tra mối liên hệ giữa yêu cầu và deliverables, tránh thay đổi phạm vi không cần thiết (scope creep) và đảm bảo tính toàn vẹn của dự án theo PMBOK Guide 7th Edition (cập nhật đến 2026, nhấn mạnh vào giá trị và traceability trong Agile/Hybrid). Đây là tình huống điển hình ở giai đoạn Monitor and Control Project Work hoặc Validate Scope, nơi cần sử dụng traceability để xác nhận.

✅ Đáp án đúng và lý do lựa chọn

Review the requirements traceability matrix with the concerned stakeholder
🛠️ Lý do: Đây là hành động tối ưu và đầu tiên theo PMP. Requirements Traceability Matrix (RTM) là công cụ cốt lõi để theo dõi và xác nhận rằng mọi yêu cầu đã được map (liên kết) với deliverables, thiết kế, test cases. Bằng cách xem xét RTM cùng stakeholder, PM có thể nhanh chóng kiểm tra xem yêu cầu đó có bị thiếu trace hay không, mà không cần thay đổi scope ngay lập tức. Điều này thúc đẩy giao tiếp minh bạch, giải quyết lo ngại dựa trên dữ liệu thực tế, phù hợp với nguyên tắc Value Delivery và Holistic Thinking trong PMBOK 7 (Process 5.5: Validate Scope & Tool: Data Analysis - RTM).

📋 Phân tích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên thực tiễn PMP mới nhất:

• ❌ [SAI] Check the approved list of requirements to see if there are any missing items
  🧐 Giải thích sai: Việc chỉ kiểm tra danh sách yêu cầu đã phê duyệt là không đủ và thụ động. Danh sách này không cho thấy mối liên kết trực tiếp với deliverables. PM cần công cụ traceability như RTM để xác nhận "yêu cầu có được thực hiện trong deliverables không?", thay vì chỉ tìm "missing items" – có thể dẫn đến hiểu lầm và scope creep không cần thiết (PMBOK 7: Tránh Data Inaccuracy).

• ❌ [SAI] Work with the stakeholder to improve the requirements' acceptance criteria
  🧐 Giải thích sai: Cải thiện tiêu chí chấp nhận (acceptance criteria) là hành động sau khi xác nhận vấn đề, không phải bước đầu. Lúc này, stakeholder chỉ lo ngại "yêu cầu không được addressed" trong deliverables, chưa rõ là do criteria kém hay thiếu trace. Hành động này có thể thay đổi scope mà chưa kiểm tra, vi phạm nguyên tắc Control Changes (PMBOK 7: Process 6.6: Control Procurements, ưu tiên Verify before Adjust).

• ✅ [ĐÚNG] Review the requirements traceability matrix with the concerned stakeholder
  🛠️ Giải thích đúng: Như đã nêu ở phần đáp án, RTM là công cụ chuẩn để trace từ yêu cầu gốc đến deliverables/test/results. Hành động này hợp tác, dựa trên dữ liệu, giúp PM và stakeholder cùng xác minh nhanh chóng, thúc đẩy Stakeholder Engagement (PMBOK 7: Domain VII & Tool in 8.2: Requirements Traceability Matrix). Đây là best practice trong cả Predictive và Agile (Product Backlog Traceability).

• ❌ [SAI] Discuss with the stakeholder which additional requirements should be added
  🧐 Giải thích sai: Thảo luận thêm yêu cầu mới là nguy cơ scope creep cao, giả định yêu cầu bị thiếu mà chưa kiểm tra. PM phải xác nhận trước qua RTM thay vì mở rộng scope ngay, tránh lãng phí tài nguyên và thay đổi baseline (PMBOK 7: Principle "Optimize Resource Allocation" & Process 4.6: Control Scope).

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021, cập nhật PMI đến 2026): Phần 4.3 Define Scope (RTM intro), 5.5 Validate Scope (Data Analysis: RTM), Domain IV: Project Scope (Traceability emphasis).
• PMI Agile Practice Guide (2021): Requirements Traceability in Adaptive Planning.
• PMP Exam Content Outline (2024+): Tasks như "Assess project performance using traceability matrix" (Scope Domain).
• Nguồn chính thức: PMI.org – Khuyến nghị thực hành RTM để giải quyết stakeholder concerns đầu tiên.

Hy vọng phân tích này giúp bạn ôn tập PMP hiệu quả! 🚀 Nếu cần thêm ví dụ, hãy hỏi nhé!

🧩 Phân tích nội dung câu hỏi

Câu hỏi này thuộc chủ đề quản lý đội ngũ dự án (Manage Project Team) trong giai đoạn thực thi dự án (Executing Process Group) theo PMBOK Guide 7th Edition (và cập nhật PMP đến 2026).

📖 Tình huống mô tả:

• Xung đột liên tục xảy ra giữa Project Manager (PM) và một thành viên đội ngũ tại mọi cuộc họp đội ngũ dự án.
• Xung đột này ngăn cản việc hoàn thành nhiệm vụ và sản phẩm bàn giao (tasks & deliverables).
• PM đang cân nhắc thay đổi phong cách lãnh đạo (leadership style).
  Câu hỏi yêu cầu hành động nên làm gì đầu tiên để giải quyết xung đột, đảm bảo dự án tiến triển.

🛠️ Bối cảnh PMP: Theo nguyên tắc lãnh đạo phục vụ (Servant Leadership) và quản lý xung đột (Conflict Management), PM phải chủ động giải quyết xung đột từ gốc rễ (root cause), ưu tiên làm rõ vai trò/trách nhiệm (roles & responsibilities) trước khi thay đổi phong cách lãnh đạo. Xung đột thường xuất phát từ sự không rõ ràng về trách nhiệm, không phải kỹ năng cá nhân hay leo thang ngay lập tức.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Review the set of responsibilities with the team member

Lý do chi tiết (theo PMBOK 7th Edition):

• Xung đột lặp lại tại họp đội ngũ thường do không rõ ràng về trách nhiệm (responsibilities), dẫn đến tranh chấp nhiệm vụ. PM cần xem xét lại (review) bộ trách nhiệm với thành viên cụ thể để làm rõ RACI (Responsible, Accountable, Consulted, Informed), giải quyết gốc rễ xung đột.
• Đây là bước đầu tiên và hiệu quả nhất trong quản lý đội ngũ (Manage Project Team - Process 9.4), phù hợp với nguyên tắc Tailoring và Value Delivery. Thay đổi leadership style chỉ là suy nghĩ, không phải hành động ưu tiên.
• Kết quả: Giảm xung đột, đảm bảo tasks/deliverables hoàn thành kịp thời.

📘 Dẫn nguồn:

• PMBOK® Guide 7th Edition, Section 4.5.2 Manage Team (Conflict Resolution) & Principle 5: Team.
• PMP Examination Content Outline 2021 (cập nhật 2026): Domain III - Business Environment (People: Manage Conflict - 10%).

📋 Phân tích tất cả các phương án

Dưới đây là phân tích từng phương án một cách chi tiết, đánh dấu ✅ (đúng) hoặc ❌ (sai), với lý do dựa trên thực tiễn PMP:

• Review the set of responsibilities with the team member
  ✅ Đúng - Như đã giải thích ở trên. Đây là hành động chủ động, trực tiếp giải quyết root cause (thiếu rõ ràng trách nhiệm), phù hợp Servant Leadership và High-Performing Teams. Giúp khôi phục tiến độ dự án nhanh chóng mà không cần can thiệp bên ngoài.

• Avoid the team member to prevent further conflicts
  ❌ Sai - Tránh né thành viên chỉ làm xung đột tích tụ, nhiệm vụ vẫn bị đình trệ. Vi phạm nguyên tắc Confronting/Collaborating trong quản lý xung đột (Thomas-Kilmann Model, PMBOK 7th). PM phải đối mặt vấn đề, không né tránh để duy trì đội ngũ hiệu suất cao.

• Escalate the situation to the project sponsor
  ❌ Sai - Leo thang lên sponsor quá sớm, khi PM chưa tự giải quyết (PM chịu trách nhiệm chính Manage Project Team). Chỉ escalate nếu xung đột vượt quyền hạn hoặc ảnh hưởng nghiêm trọng toàn dự án (ví dụ: rủi ro cao). Theo PMBOK, ưu tiên giải quyết nội bộ trước (Escalation chỉ là lựa chọn cuối).

• Review the personnel skill documents
  ❌ Sai - Xem tài liệu kỹ năng nhân sự (skills inventory) không trực tiếp giải quyết xung đột đang diễn ra. Có thể hữu ích cho resource management (Acquire Resources), nhưng xung đột ở đây từ trách nhiệm, không phải kỹ năng. Ưu tiên review responsibilities trước skills (theo thứ tự Manage Project Resources).

🏆 Kết luận và lời khuyên PMP

Hành động đúng giúp PM thể hiện lãnh đạo hiệu quả, xây dựng đội ngũ tin cậy. Trong kỳ thi PMP, luôn ưu tiên root cause analysis và collaborative approach! Nếu áp dụng thực tế, kết hợp công cụ như Responsibility Assignment Matrix (RAM) để tránh tái phát.

📚 Tài liệu tham khảo bổ sung:

• PMBOK® Guide 7th Edition (Project Management Institute, 2021).
• Agile Practice Guide (PMI, tích hợp PMBOK 7th).
• Rita Mulcahy's PMP Exam Prep (phiên bản mới nhất 2024-2026).

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này thuộc chủ đề Quản lý đội ngũ trong môi trường Agile theo PMP (Project Management Professional), tập trung vào cách xử lý tình huống đội ngũ đã quen thuộc với các thực hành Agile nhưng gặp vấn đề về động lực (boredom - sự nhàm chán) với các hoạt động hàng ngày như daily stand-up.

• Bối cảnh: Một đội ngũ mới hình thành (newly formed team) đã thích nghi tốt với Agile practices, đạt hiệu suất theo kỳ vọng (performing according to expectations). Tuy nhiên, project lead nhận thấy nhiều thành viên đang chán nản với các thực hành hàng ngày (daily team practices).
• Vấn đề cốt lõi: Làm thế nào để project lead tăng cường sự tự chủ và cải thiện động lực đội ngũ mà không can thiệp trực tiếp, phù hợp với nguyên tắc Agile nhấn mạnh self-organizing teams (đội ngũ tự tổ chức) và retrospective (họp hồi tưởng để tự cải thiện).
• Mục tiêu PMP: Áp dụng PMBOK 7th Edition (2021) và Agile Practice Guide, nhấn mạnh Servant Leadership (lãnh đạo phục vụ), trao quyền cho đội ngũ tự giải quyết vấn đề thay vì chỉ đạo từ trên xuống.

📘 Nguồn tham khảo:

• PMBOK® Guide 7th Edition, Domain: Team (Section 4.6 - High-Performing Teams).
• Agile Practice Guide (PMI, 2017, tích hợp PMBOK 7): Nhấn mạnh Retrospective và Self-Organizing Teams.
• Scrum Guide 2020 (Ken Schwaber & Jeff Sutherland): Retrospective là sự kiện bắt buộc để inspect & adapt.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Allow the team to self-organize and have them analyze the situation in their retrospective session and self correct.

Lý do 🛠️:

• Trong Agile/Scrum, retrospective là sự kiện quan trọng nhất để đội ngũ tự phân tích (analyze) vấn đề, xác định nguyên nhân gốc rễ (root cause) và tự cải thiện (self-correct). Project lead đóng vai trò facilitator (người hỗ trợ), không can thiệp trực tiếp, giúp đội ngũ tự tổ chức (self-organize) – phù hợp nguyên tắc Agile Manifesto: "Build projects around motivated individuals" và "The best architectures, requirements, and designs emerge from self-organizing teams".
• Điều này thúc đẩy sự gắn kết và động lực nội tại, tránh tình trạng boredom bằng cách để đội ngũ sở hữu giải pháp. PMP khuyến khích Servant Leader trao quyền, đặc biệt với đội đã quen Agile.

📋 Giải thích tất cả các phương án (đúng & sai)

Dưới đây là phân tích từng phương án một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên nguyên tắc PMP/Agile mới nhất (đến 2026, dựa PMBOK 7 & Scrum Guide).

• Phương án SAI: Challenge the team to find new ways to achieve higher levels of performance to improve the situation
  ❌ Lý do sai: Cách tiếp cận này mang tính chỉ đạo từ trên xuống (top-down directive), ép đội ngũ phải "challenge" để đạt performance cao hơn, có thể tăng áp lực và làm boredom tệ hơn. Agile ưu tiên pull-based improvement (cải thiện tự nguyện) qua retrospective, không phải "challenge" từ leader. Vi phạm Servant Leadership (PMBOK 7, Team Domain).

• Phương án SAI: Speak with individual team members to determine what they would like to do to improve the situation in the team
  ❌ Lý do sai: Việc nói chuyện cá nhân hóa (individual basis) phá vỡ nguyên tắc team-level accountability trong Agile. Đội ngũ self-organizing cần thảo luận tập thể tại retrospective để tránh thiên kiến cá nhân và đảm bảo giải pháp bền vững. PMP khuyến khích whole-team retrospectives thay vì micromanagement (Agile Practice Guide, Servant Leadership).

• Phương án SAI: Have the team inform senior management of the situation and ask for recommendations
  ❌ Lý do sai: Escalation lên senior management là hành động bypass đội ngũ tự chủ, trái với Agile nơi team chịu trách nhiệm hoàn toàn (Scrum Guide: Development Team tự quản lý công việc). Điều này làm giảm động lực, tạo dependency, không phù hợp high-maturity team đã quen Agile (PMBOK 7: Empower Team).

• Phương án ĐÚNG: Allow the team to self-organize and have them analyze the situation in their retrospective session and self correct
  ✅ Lý do đúng: Hoàn toàn phù hợp nguyên tắc cốt lõi Agile: Self-organizing + Retrospective (inspect & adapt). Project lead chỉ cho phép (allow), không can thiệp, giúp đội tự giải quyết boredom qua dữ liệu thực tế. Kết quả: Tăng performance bền vững, động lực cao (PMBOK 7: Optimize Team Performance; Scrum Guide: Sprint Retrospective).

🧠 Kết luận PMP: Câu hỏi kiểm tra khả năng áp dụng Servant Leadership trong Agile. Luôn ưu tiên empower team qua các sự kiện chuẩn như Retrospective để đạt High-Performing Team! 🚀

🧩 Phân tích nội dung câu hỏi

Câu hỏi này thuộc chủ đề Agile và Scrum trong PMP (Project Management Professional), cụ thể liên quan đến các thực hành quản lý dự án lặp lại (iterative) theo PMBOK Guide 7th Edition và Scrum Guide (phiên bản mới nhất 2020, cập nhật đến 2026).

📖 Tình huống mô tả: Một công ty mới bắt đầu triển khai Scrum (một framework Agile phổ biến). Đến khoảng giữa sprint đầu tiên (Sprint là khoảng thời gian cố định 1-4 tuần để hoàn thành các mục tiêu), xuất hiện vấn đề giao tiếp: Một số thành viên dự án (project team members) không đồng bộ (not in sync) với các thành viên khác. Câu hỏi yêu cầu xác định nguyên nhân chính gây ra khoảng trống giao tiếp (communication gap) này.

🛠️ Bối cảnh quan trọng: Trong Scrum, giao tiếp là yếu tố cốt lõi để đảm bảo tính minh bạch (transparency), kiểm tra (inspection) và thích ứng (adaptation). Vấn đề xảy ra nửa chừng sprint đầu tiên, nghĩa là team chưa quen thuộc, nên cần tập trung vào các sự kiện (events) bắt buộc của Scrum để sync hàng ngày.

✅ Đáp án đúng và lý do lựa chọn

Daily standup meetings were not held or enforced

Lý do chi tiết:
Trong Scrum, Daily Scrum (hay Daily Standup) là sự kiện hàng ngày bắt buộc (mandatory), kéo dài tối đa 15 phút, diễn ra cùng giờ cùng nơi để toàn bộ Development Team đồng bộ hóa tiến độ (synchronization), thảo luận những gì đã làm, đang làm, sẽ làm, và các trở ngại (impediments). Nếu không tổ chức hoặc không thực thi nghiêm ngặt, team sẽ thiếu cơ chế giao tiếp hàng ngày, dẫn đến tình trạng "not in sync" ngay giữa sprint. Đây là nguyên nhân trực tiếp nhất trong bối cảnh Scrum mới triển khai, vì Daily Scrum được thiết kế chính để giải quyết communication gap ở cấp độ team.

📘 Dẫn nguồn:

• Scrum Guide 2020 (Scrum.org): "The Daily Scrum is a 15-minute event for the Developers... to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, improving communications, identify impediments...".
• PMBOK Guide 7th Edition (PMI, 2021): Section 4.5.1.1 (Agile Principles) và Agile Practice Guide: Nhấn mạnh Daily Stand-up là công cụ cốt lõi cho team synchronization trong Scrum.

🔍 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn một cách logic, dựa trên Scrum framework. Tôi giữ nguyên văn bản gốc bằng tiếng Anh cho các phương án, nhưng giải thích hoàn toàn bằng tiếng Việt.

• ❌ The project sprint board has not been updated
  Phân tích sai: Sprint board (hay Scrum board/Task board) là công cụ trực quan hóa tiến độ (visualization tool), được cập nhật trong Sprint Review hoặc hàng ngày để minh bạch. Tuy nhiên, nó không phải cơ chế giao tiếp chính để sync team members. Vấn đề "not in sync" xảy ra do thiếu trao đổi trực tiếp, không phải board chưa update (có thể update mà vẫn thiếu thảo luận).

• ✅ Daily standup meetings were not held or enforced
  Phân tích đúng: Như đã giải thích ở trên, đây là sự kiện hàng ngày bắt buộc để inspect và adapt, trực tiếp giải quyết communication gap bằng cách sync tiến độ và impediments. Trong sprint đầu tiên, thiếu standup sẽ gây lệch pha nhanh chóng giữa team members.

• ❌ The project status dashboard has not been updated
  Phân tích sai: Status dashboard là công cụ báo cáo tổng quát (reporting tool), thường dùng ở cấp độ portfolio/program, không phải công cụ Scrum core cho giao tiếp nội bộ team. Trong Scrum, dashboard có thể hỗ trợ nhưng không thay thế Daily Scrum; thiếu nó không gây "not in sync" giữa team members ngay giữa sprint.

• ❌ The communications management plan has not been developed
  Phân tích sai: Communications Management Plan thuộc Predictive/Waterfall lifecycle (PMBOK Process Group 10), mô tả cách thức giao tiếp tổng thể dự án. Trong Agile/Scrum, giao tiếp được quản lý qua sự kiện Scrum (events) và nguyên tắc Agile (face-to-face ưu tiên), không cần plan riêng biệt. Vấn đề ở đây là sprint-specific, không phải thiếu plan dự án.

🏆 Kết luận và lưu ý PMP

Câu hỏi kiểm tra kiến thức Scrum Events so với các công cụ truyền thống, nhấn mạnh tailoring approach trong PMBOK 7th (chọn đúng công cụ theo lifecycle). Để tránh vấn đề tương tự, Scrum Master phải enforce Daily Scrum nghiêm ngặt.

📚 Tài liệu tham khảo bổ sung:

• PMI Agile Certified Practitioner (PMI-ACP) Handbook (cập nhật 2023).
• Scrum Guide 2020 (miễn phí tại scrumguides.org).
  Học viên PMP nên thực hành qua mock exams để nắm vững! 🚀

🧩 Phân tích nội dung câu hỏi

Câu hỏi mô tả một tình huống thực tế trong dự án PMP: Giám đốc trực tiếp của Project Manager (PM) đang giao tiếp trực tiếp với khách hàng (client) để phê duyệt các thay đổi (changes) mà không thông báo cho PM. Điều này dẫn đến sự nhầm lẫn trong đội ngũ dự án (project team) vì phạm vi dự án (scope) đang thay đổi "ngầm" (background), chỉ được đề cập muộn mốt trong các cuộc họp dự án.
📌 Vấn đề cốt lõi: Scope creep (mở rộng phạm vi không kiểm soát), vi phạm quy trình quản lý thay đổi (change control), và thiếu sự tham gia của các bên liên quan (stakeholders) theo đúng kế hoạch. PM cần xử lý để bảo vệ tính toàn vẹn của dự án, đảm bảo giao tiếp minh bạch và tuân thủ các kế hoạch quản lý theo PMBOK® Guide 7th Edition (và cập nhật đến 2026 với PMI Standards+).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Review the stakeholder engagement plan and put in place any existing actions accordingly.

Lý do:
🛠️ Theo PMBOK® 7th Edition (Domain: Stakeholder), Stakeholder Engagement Plan là tài liệu cốt lõi xác định chiến lược tương tác với từng stakeholder (bao gồm director và client), bao gồm các hành động cụ thể để xử lý rủi ro như giao tiếp trực tiếp (direct communication) hoặc bypass PM. Bước đầu tiên của PM là xem xét lại kế hoạch này để áp dụng các hành động sẵn có (existing actions), đảm bảo tuân thủ quy trình, tránh leo thang không cần thiết. Điều này phù hợp với nguyên tắc Tailoring (tùy chỉnh quy trình) và Effective Stakeholder Management, giúp giải quyết gốc rễ vấn đề mà không đối đầu trực tiếp.
📘 Nguồn tham khảo: PMBOK® Guide 7th Edition, Section 4.4 Stakeholder Engagement (Principle 9: Engage Stakeholders); The Standard for Project Management 3rd Edition.

📋 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên nội dung gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai kèm lý do dựa trên thực tiễn PMP mới nhất:

• ❌ [SAI] Communicate directly with the director and inform them of the communications management plan
  Lý do sai: Việc giao tiếp trực tiếp (communicate directly) với giám đốc mà không xem xét ngữ cảnh có thể bị coi là đối đầu (confrontational), vi phạm nguyên tắc Escalation Process trong Communications Management Plan. PMBOK® nhấn mạnh phải xem xét thứ bậc tổ chức (hierarchy) và Stakeholder Engagement Plan trước khi escalate. Hành động này bỏ qua Tailoring và có thể làm tình hình tệ hơn.

• ❌ [SAI] Communicate directly with the client stating that any scope changes must go through the project manager
  Lý do sai: PM không nên giao tiếp trực tiếp với client để "ra lệnh" (stating that...), vì client là stakeholder cấp cao. Điều này vi phạm authority levels và có thể gây mất lòng tin. Theo PMBOK® 7th (Domain: Uncertainty), thay đổi scope phải qua Integrated Change Control (Perform Integrated Change Control process), nhưng ưu tiên là engage stakeholder đúng cách, không phải "chặn" trực tiếp.

• ✅ [ĐÚNG] Review the stakeholder engagement plan and put in place any existing actions accordingly
  Lý do đúng: Như đã giải thích ở trên, đây là bước logic đầu tiên (first course of action) theo PMBOK®. Kế hoạch này đã dự phòng các tình huống như giao tiếp ngoài luồng, giúp PM engage hiệu quả mà không tự ý hành động. Phù hợp với 12 Principles of Project Management (Engage Stakeholders Effectively).

• ❌ [SAI] Discuss the issues with the project team and let them know that the project manager will handle scope changes
  Lý do sai: Thảo luận với team trước (discuss with the project team) chỉ làm tăng lo lắng và nhầm lẫn, vi phạm nguyên tắc Manage Team Knowledge (PMBOK® Domain: Team). PM phải giải quyết gốc rễ với stakeholders trước, không hứa suông "will handle" mà không có kế hoạch cụ thể. Điều này không giải quyết scope creep thực sự.

🏆 Kết luận và lời khuyên PMP

Hành động đúng giúp PM chủ động quản lý rủi ro stakeholder, duy trì project governance. Trong kỳ thi PMP 2021+ (Exam Content Outline), câu hỏi tương tự kiểm tra Stakeholder Sphere và People Domain.
📚 Tài liệu tham khảo bổ sung:

• PMBOK® Guide 7th Edition (PMI, 2021).
• PMI's Pulse of the Profession 2024-2026 Reports (cập nhật xu hướng stakeholder management).
  Hãy thực hành thêm với PMP Exam Prep của Rita Mulcahy hoặc David Francis để nắm vững! 🚀

🧩 Phân tích nội dung câu hỏi

Câu hỏi này thuộc chủ đề Quản lý Đội ngũ và Hiệu suất (Team Management and Performance) trong PMP, cụ thể liên quan đến các buổi Retrospective (hồi tưởng dự án) – một nghi thức quan trọng trong Agile và Hybrid approaches theo PMBOK Guide 7th Edition (và cập nhật PMP đến 2026).

Tình huống: Nhà tài trợ dự án (Project Sponsor) thường yêu cầu Project Manager bỏ qua Retrospective do hạn chế thời gian. Tuy nhiên, Project Manager vẫn kiên trì tổ chức bằng cách rút ngắn thời gian chuẩn bị (preparation) và thảo luận (discussion). Câu hỏi yêu cầu chọn hai vấn đề mà hành động này có thể gây ra.

Mục đích câu hỏi: Kiểm tra hiểu biết về rủi ro khi co lại Retrospective – một buổi quan trọng để đội ngũ phản ánh, học hỏi từ quá khứ, cải thiện tương lai (theo Agile Practice Guide, phần Sprint Retrospective). Rút ngắn thời gian có thể làm giảm chất lượng, dẫn đến thiếu chiều sâu phân tích và động lực đội ngũ.

📘 Tài liệu tham khảo:

• PMBOK® Guide 7th Edition: Domain 4 - Team (Section 4.7 - High-Performing Teams) & Agile Practice Guide (Sprint Retrospective).
• PMI Agile Certified Practitioner (PMI-ACP) & PMP Exam Content Outline 2021 (cập nhật 2026: Nhấn mạnh Adaptive Planning và Team Engagement).

✅ Đáp án đúng (Chọn hai)

Hai lựa chọn đúng là:

1. A lack of direction and motivation for the team in the workshop
2. A focus on the negative and a disinterest in further improvements

Lý do lựa chọn:
Khi rút ngắn thời gian chuẩn bị và thảo luận, Retrospective thiếu cấu trúc rõ ràng (direction) và không tạo động lực (motivation) cho đội ngũ, dẫn đến buổi họp kém hiệu quả. Đồng thời, đội ngũ chỉ kịp tập trung vào vấn đề tiêu cực (negative aspects) mà không có thời gian cân bằng với giải pháp tích cực, gây chán nản và mất hứng thú cải thiện liên tục (disinterest in improvements). Điều này vi phạm nguyên tắc Build a High-Performing Team trong PMBOK 7th, nơi Retrospective cần thời gian đầy đủ để tạo giá trị (value delivery).

🛠️ Giải thích chi tiết từng phương án

Dưới đây là phân tích tất cả các lựa chọn (giữ nguyên văn bản gốc tiếng Anh). Tôi đánh dấu ✅ cho đúng, ❌ cho sai, kèm lý do dựa trên PMP best practices:

• ❌ A lot of discussions that yield no results or possibly too many results
  Giải thích sai: Rút ngắn thời gian sẽ dẫn đến ít thảo luận hơn, không phải "a lot of discussions" (nhiều thảo luận). Kết quả không phải "no results or too many" mà là thiếu chiều sâu, không tạo ra insights chất lượng. Retrospective cần thời gian cân bằng để đạt kết quả actionable (hành động cụ thể), theo Agile Practice Guide.

• ✅ A lack of direction and motivation for the team in the workshop
  Giải thích đúng: Không chuẩn bị đầy đủ (reduced preparation) làm thiếu hướng dẫn rõ ràng (lack of direction), đội ngũ không biết tập trung vào đâu. Thảo luận ngắn (reduced discussion) làm giảm động lực tham gia (motivation), vi phạm nguyên tắc Psychological Safety và Team Engagement (PMBOK 7th, Domain 4). Dẫn đến buổi họp thiếu năng lượng và cam kết.

• ❌ Lessons learned from other teams to not be considered
  Giải thích sai: Retrospective thường tập trung vào đội ngũ nội bộ (internal team reflections), không nhất thiết bao gồm "lessons learned from other teams" (bài học từ đội khác). Hành động rút ngắn không trực tiếp ảnh hưởng đến việc chia sẻ cross-team, mà chủ yếu làm giảm chất lượng nội bộ. (Tham khảo: PMBOK 7th, Organizational Lessons Learned không phải trọng tâm Retrospective).

• ❌ Time management plan for the retrospective workshop to not be updated
  Giải thích sai: Time Management Plan thuộc Project Schedule (PMBOK Domain 3), không phải kế hoạch riêng cho Retrospective workshop. Rút ngắn thời gian là điều chỉnh linh hoạt (agile adaptation), không yêu cầu cập nhật formal plan. Vấn đề chính là chất lượng, không phải cập nhật tài liệu.

• ✅ A focus on the negative and a disinterest in further improvements
  Giải thích đúng: Thời gian ngắn khiến đội ngũ chỉ kịp liệt kê vấn đề (focus on negative) mà không thảo luận giải pháp, dẫn đến cảm giác tiêu cực và mất hứng thú (disinterest) với cải thiện tương lai. Retrospective lý tưởng cần cân bằng "What went well? What to improve? Action items?" (theo Agile Practice Guide), nhưng rút ngắn phá vỡ sự cân bằng này.

📘 Kết luận & Lời khuyên PMP

Hành động của PM tuy tốt ý (không bỏ Retrospective) nhưng rút ngắn thời gian có thể làm giảm giá trị, vi phạm Tailoring (tùy chỉnh quy trình theo ngữ cảnh - PMBOK 7th Principle 12). Best practice: Đàm phán với Sponsor để giữ thời gian đầy đủ hoặc dùng công cụ nhanh như Timeline Retrospective/4Ls (Liked, Learned, Lacked, Longed For). Chuẩn bị kỹ để đạt Continuous Improvement! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào quản lý các bên liên quan (Stakeholder Management) trong một dự án Agile diễn ra tại tổ chức ma trận (matrix organization). Trong mô hình tổ chức ma trận, quyền lực được phân bổ giữa các nhà quản lý chức năng (functional managers) và nhà quản lý dự án (project manager), dẫn đến nhiều góc nhìn khác nhau từ các bên liên quan chính (key stakeholders) từ các bộ phận khác nhau của tổ chức.

📍 Tình huống cụ thể: Nhà quản lý dự án (PM) đang làm việc tại chỗ (on-site) cùng các bên liên quan chính từ nhiều bộ phận. Điều này làm tăng nguy cơ xung đột lợi ích hoặc hướng dẫn trái chiều. Câu hỏi yêu cầu cách xử lý phù hợp để đảm bảo dự án thành công, phù hợp với nguyên tắc PMP mới nhất (PMBOK® Guide 7th Edition và Agile Practice Guide, cập nhật đến 2026).

🛠️ Mục tiêu chính: PM cần áp dụng cách tiếp cận tập trung vào giá trị (value-driven), ưu tiên phân tích để phân loại và tương tác (engage) hiệu quả với stakeholders, thay vì tuân thủ mù quáng theo hướng dẫn.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Because there are different perspectives, perform a stakeholder analysis and act based on the outcome.

Lý do chi tiết 🏆:

• Trong tổ chức ma trận và dự án Agile, các stakeholders có góc nhìn đa dạng (different perspectives) do quyền lực phân tán. PM phải thực hiện phân tích bên liên quan (stakeholder analysis) để đánh giá mức độ ảnh hưởng (power/interest grid), phân loại (unaware, resistant, neutral, supportive, leading), và lập kế hoạch tương tác phù hợp.
• Điều này tuân thủ Stakeholder Performance Domain trong PMBOK 7th Edition, nơi nhấn mạnh việc xác định (identify), phân tích (analyze), ưu tiên (prioritize), và tương tác (engage) dựa trên dữ liệu để giảm rủi ro và tối ưu hóa giá trị dự án.
• Trong Agile, stakeholder analysis hỗ trợ Product Backlog refinement và Sprint planning, đảm bảo feedback từ stakeholders được tích hợp linh hoạt mà không bị chi phối bởi bất kỳ bên nào.

📋 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng phương án một cách chi tiết, dựa trên nguyên tắc PMP:

• All stakeholders are important, so the project manager should follow directions provided by management and key stakeholders
  ❌ Sai: Phương án này bỏ qua việc ưu tiên và phân loại stakeholders. Tất cả stakeholders đều quan trọng, nhưng PM không thể tuân thủ mọi hướng dẫn (follow directions) mà không phân tích, dẫn đến xung đột trong matrix org và làm lệch hướng dự án Agile. PMBOK yêu cầu quyết định dựa trên dữ liệu (data-driven), không phải "làm theo số đông".

• Because there are different perspectives, perform a stakeholder analysis and act based on the outcome
  ✅ Đúng: Như đã giải thích ở trên, đây là cách tiếp cận chuẩn mực, giúp PM hành động dựa trên kết quả phân tích (act based on the outcome), đảm bảo tương tác hiệu quả và giảm thiểu rủi ro từ góc nhìn đa dạng.

• The project manager is working on the client's premises, so follow the directions of all the key stakeholders
  ❌ Sai: Việc làm việc tại chỗ khách hàng (client's premises) không có nghĩa PM phải tuân thủ mọi hướng dẫn từ key stakeholders. Điều này vi phạm nguyên tắc quyền hạn dự án (project authority) trong matrix và Agile, nơi PM chịu trách nhiệm tổng thể. Stakeholder analysis mới là chìa khóa, không phải vị trí địa lý.

• This is an agile project, so listen only to the directions of the project manager's supervisor and the functional managers of the organization
  ❌ Sai: Agile không loại trừ stakeholders bên ngoài; ngược lại, nó nhấn mạnh sự tham gia liên tục (continuous engagement) với tất cả stakeholders (theo Agile Practice Guide). Chỉ nghe supervisor và functional managers sẽ bỏ lỡ input từ key stakeholders khác, gây thất bại trong matrix org nơi quyền lực đa đầu.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021, cập nhật 2026): Stakeholder Performance Domain (Section 4.5-4.7); Tools & Techniques: Stakeholder Analysis, Engagement Assessment Matrix.
• Agile Practice Guide (PMI, 2017-2026): Chapter 5 - Implementing Agile: Stakeholder Engagement in Agile Environments.
• PMI Code of Ethics & Professional Conduct: Nhấn mạnh trách nhiệm chuyên nghiệp của PM trong quản lý xung đột lợi ích.

Hy vọng phân tích này giúp bạn nắm vững kiến thức PMP! 🚀 Nếu cần thêm ví dụ thực tế, hãy hỏi nhé!

🧩 Phân tích nội dung câu hỏi

Câu hỏi mô tả một Project Manager (PM) đang dẫn dắt một dự án nội bộ công ty ở giai đoạn rất đầu (very early stages). Dự án hiện tại tương tự một dự án khác đã kết thúc cách đây một năm. Nhiệm vụ là xác định hành động PM nên làm để phân tích các bên liên quan (stakeholders) tham gia.
✅ Mục tiêu chính: Xác định cách tiếp cận hiệu quả để xây dựng stakeholder register (danh sách bên liên quan) cho dự án mới, tận dụng kinh nghiệm từ dự án cũ nhưng phải phù hợp với bối cảnh hiện tại. Theo PMBOK 7th Edition (2021) và các cập nhật PMP đến 2026, việc quản lý bên liên quan (Stakeholder Engagement) bắt đầu từ Initiating Process Group, nhấn mạnh sử dụng lessons learned để hướng dẫn, không sao chép trực tiếp dữ liệu cũ vì stakeholders có thể thay đổi (ví dụ: nhân sự mới, nhu cầu khác).

✅ Đáp án đúng

Use lessons learned from the previous project as a guide for the current project's stakeholder register
Lý do chọn: Lessons learned từ dự án trước là nguồn tài nguyên quý giá trong Organizational Process Assets (OPA), giúp PM hướng dẫn xây dựng stakeholder register mới một cách chính xác, tránh lặp lại sai lầm. Điều này phù hợp với Stakeholder Identification trong PMBOK 7th (Domain: Stakeholder), khuyến khích sử dụng dữ liệu lịch sử để hướng dẫn (guide) chứ không copy trực tiếp, đảm bảo register hiện tại phản ánh đúng stakeholders mới. 🛠️ Đây là cách tiếp cận proactive và tailored ở giai đoạn đầu dự án.

📋 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn theo thứ tự, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên PMP mới nhất:

• Lower the priority of stakeholder engagement as the stakeholders already have knowledge of this kind of project
  ❌ Sai. Việc hạ thấp ưu tiên stakeholder engagement là rủi ro lớn, vì dù dự án tương tự, stakeholders vẫn có thể thay đổi (ví dụ: vai trò mới, kỳ vọng khác). PMBOK 7th nhấn mạnh Stakeholder Engagement Plan phải được ưu tiên cao từ đầu (High Power/Interest), không dựa vào "kiến thức cũ" để giảm nỗ lực – điều này vi phạm nguyên tắc Tailor to the Project.

• Use lessons learned from the previous project as a guide for the current project's stakeholder register
  ✅ Đúng (như đã giải thích ở trên). Lessons learned repository cung cấp insights thực tế (ví dụ: ai là stakeholder ảnh hưởng lớn, cách engage hiệu quả), giúp xây dựng register mới chính xác và hiệu quả. Đây là best practice trong Data Analysis tools của Identify Stakeholders process.

• Refer to the stakeholder register from the previous project as it was similar to the current project
  ❌ Sai. Stakeholder register cũ không nên dùng trực tiếp vì nó là historical data có thể lỗi thời (stakeholders thay đổi sau 1 năm: nghỉ việc, tổ chức mới). PMBOK 7th (Section 4.4) yêu cầu tạo register mới dựa trên phân tích hiện tại, chỉ dùng dữ liệu cũ làm reference hỗ trợ, không phải "refer to" như nguồn chính.

• Document in the risk register that the current project may have different stakeholders than the previous project
  ❌ Sai. Việc ghi vào risk register là phản ứng thụ động, không phải hành động chủ động phân tích stakeholders. Risk register dùng cho rủi ro (PMBOK Domain: Uncertainty), trong khi phân tích stakeholders thuộc Stakeholder Engagement riêng biệt. Nên xác định và engage ngay thay vì chỉ "document may have different".

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Chapter 4 (Project Stakeholder Management), Tools & Techniques cho Identify Stakeholders (Lessons Learned, Data Analysis).
• PMI's Process Groups: A Practice Guide (2022): Nhấn mạnh OPA bao gồm lessons learned cho Initiating.
• PMP Exam Content Outline (2021, cập nhật 2024-2026): Domain 2: Stakeholder (16%), ưu tiên lessons learned cho historical info.
  🛠️ Lời khuyên PMP: Luôn tailor dựa trên dự án tương tự, bắt đầu bằng Stakeholder Cube hoặc power/interest grid để phân tích!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này thuộc chủ đề Quản lý trở ngại (Impediments) trong môi trường Agile/Scrum theo PMP (Project Management Professional). Tình huống mô tả: Product Owner (PO) trình bày Product Backlog cho team, nhưng team lo ngại về việc triển khai một số features do các impediments (trở ngại, chướng ngại vật) đa dạng. Project Manager (PM) cần gợi ý PO làm gì tiếp theo để xử lý hiệu quả.

🛠️ Ý nghĩa chính:

• Trong Agile, Product Backlog được ưu tiên dựa trên giá trị kinh doanh cao nhất (highest value).
• Impediments có thể cản trở việc thực hiện features, nên cần capture (ghi nhận) và prioritize (ưu tiên) chúng theo thứ tự phù hợp với backlog.
• Vai trò PO: Quản lý và ưu tiên backlog để tối ưu hóa giá trị.
• Vai trò PM: Hỗ trợ PO bằng cách gợi ý hành động phù hợp, không trực tiếp can thiệp.
• Theo PMBOK 7th Edition và Agile Practice Guide (cập nhật đến 2026), xử lý impediments phải tập trung vào value-driven prioritization thay vì giải quyết ngẫu nhiên hoặc escalate ngay.

Mục tiêu câu hỏi kiểm tra: Khả năng áp dụng nguyên tắc Agile Hybrid trong quản lý trở ngại, ưu tiên theo value thay vì quick wins hoặc escalation.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Ensure that the impediments are captured and prioritized based upon the highest valued features.

Lý do:

• PO cần ghi nhận (capture) tất cả impediments và ưu tiên chúng dựa trên features có giá trị cao nhất trong backlog. Điều này đảm bảo các trở ngại ảnh hưởng đến items quan trọng nhất được xử lý ưu tiên, phù hợp với nguyên tắc value maximization trong Agile.
• Đây là bước next logical step sau khi team raise concerns: Không vội giải quyết mà prioritize để align với business value.
• Theo Scrum Guide 2020 (cập nhật liên tục đến 2026), PO chịu trách nhiệm refine backlog, bao gồm impediments liên quan đến features.

📋 Giải thích tất cả các phương án (đúng và sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh, với giải thích hoàn toàn bằng tiếng Việt:

✅ Ensure that the impediments are captured and prioritized based upon the highest valued features
Đúng vì: Đây là hành động phù hợp nhất với vai trò PO. Capture để theo dõi, prioritize theo highest valued features đảm bảo tập trung vào giá trị kinh doanh cao, tránh lãng phí effort vào low-value items. PM gợi ý điều này giúp backlog luôn optimized (PMBOK 7th: Principle 5 - Value).

❌ Estimate the financial impact of the impediments and request additional funding
Sai vì: PO không phải chuyên gia tài chính, việc estimate impact và request funding là escalation không cần thiết ở bước đầu. Next step phải là internal prioritization, không phải ngay lập tức xin ngân sách (trái với Agile: tự quản lý team trước).

❌ Begin to remove the impediments, starting with the easiest ones first, to foster team accomplishment
Sai vì: Việc remove impediments là trách nhiệm chính của Scrum Master (hoặc PM trong hybrid), không phải PO. Bắt đầu từ "easiest ones" là quick wins nhưng không align với value – có thể bỏ qua impediments critical cho high-value features (Scrum Guide: phân vai rõ ràng).

❌ Capture the impediments and inform management that their assistance is needed in resolving the impediments
Sai vì: Chỉ capture mà escalate ngay cho management là premature escalation, bỏ qua khả năng tự giải quyết trong team. Agile khuyến khích self-organizing teams prioritize và resolve internally trước (PMBOK 7th: Principle 9 - Team & Interactions).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật 2026): Domain 3 - Project Work (Stakeholder & Team Engagement); Principle 5 (Value).
• Agile Practice Guide (PMI, 2017-2026): Phần Handling Impediments in Agile.
• Scrum Guide (2020, phiên bản mới nhất 2025): Product Owner Responsibilities & Impediments.
• PMI Agile Certified Practitioner (PMI-ACP): Domains on Backlog Management & Prioritization.

Hy vọng phân tích này giúp bạn ôn thi PMP hiệu quả! 🚀 Nếu cần thêm ví dụ thực tế, hãy hỏi nhé!