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

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

Câu hỏi mô tả một tổ chức đang áp dụng phương pháp hybrid delivery (kết hợp giữa cách tiếp cận dự đoán - predictive và linh hoạt - agile) cho một dự án phức tạp. Trong buổi iteration review (tương đương sprint review trong agile, nơi đội ngũ trình diễn sản phẩm tăng trưởng và thu thập phản hồi từ stakeholders), một chuyên gia chủ đề (SME) thông báo rằng sẽ có luật pháp mới được ban hành trong vài tháng tới.

🛠️ Vấn đề cốt lõi: Đây là thông tin về một thay đổi tiềm năng lớn (new legislation) có thể ảnh hưởng đến dự án về mặt tuân thủ pháp lý, rủi ro và phạm vi. Project manager cần quyết định hành động phù hợp nhất để xử lý thông tin này, đảm bảo nó được xem xét ở cấp độ lập kế hoạch đúng đắn trong môi trường hybrid. Theo PMBOK® Guide 7th Edition và Agile Practice Guide (cập nhật đến 2026), hybrid yêu cầu cân bằng giữa các sự kiện agile ngắn hạn (như daily standup, sprint planning) và lập kế hoạch dài hạn hơn (như release planning) để quản lý thay đổi chiến lược.

📘 Nguồn tham khảo:

• PMBOK® Guide – 7th Edition (2021), phần 4.5: Supporting Virtual Teams & Hybrid Approaches.
• Agile Practice Guide (PMI, 2017, cập nhật tích hợp PMBOK 7): Phần Hybrid Models & Release Planning.

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

Đáp án đúng: Discuss the change in the next release planning.
Lý do: Trong hybrid approach, release planning tập trung vào lập kế hoạch dài hạn (roadmap, các release lớn), phù hợp để thảo luận thay đổi có tác động vài tháng tới như luật mới. Điều này giúp đánh giá rủi ro, điều chỉnh backlog sản phẩm và đảm bảo tuân thủ mà không làm gián đoạn các hoạt động ngắn hạn. Đây là thực hành tốt nhất theo PMI Standards, ưu tiên quản lý thay đổi ở cấp độ chiến lược thay vì tactical (ngắn hạn). ✅

🔍 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 nguyên tắc hybrid PMP mới nhất:

• ❌ Ask the SME to provide details after the retrospective.
  Sai vì: Retrospective (họp cải thiện quy trình sau iteration) chỉ tập trung vào cải thiện đội ngũ và process nội bộ, không phải xử lý thay đổi bên ngoài như luật pháp. Hoãn đến sau retrospective sẽ trì hoãn đánh giá rủi ro quan trọng, vi phạm nguyên tắc timely change management trong PMBOK 7 (Principle 5: Stakeholders & Principle 9: Adaptability).

• ❌ Discuss the change in the next sprint planning.
  Sai vì: Sprint planning chỉ dành cho lập kế hoạch chi tiết sprint tiếp theo (2-4 tuần), quá ngắn hạn so với luật mới "vài tháng". Thảo luận ở đây sẽ làm lệch trọng tâm backlog sprint, gây lãng phí effort và không phù hợp hybrid (sprint cho tactical, release cho strategic) theo Agile Practice Guide.

• ✅ Discuss the change in the next release planning.
  Đúng vì: Như đã giải thích ở phần đáp án đúng. Release planning xem xét toàn bộ roadmap và các release lớn, lý tưởng cho thay đổi dài hạn, giúp tích hợp vào product backlog và quản lý rủi ro hiệu quả. Phù hợp PMBOK 7 Hybrid Models và SPM (Standard for Program Management).

• ❌ Ask the SME to provide details in the next daily standup.
  Sai vì: Daily standup (15 phút) chỉ cập nhật tiến độ hàng ngày, không dành cho thảo luận thay đổi lớn hoặc thu thập chi tiết từ SME. Điều này vi phạm quy tắc "no deep dives" trong Scrum Guide (tích hợp PMP), dẫn đến họp không hiệu quả và bỏ lỡ cơ hội lập kế hoạch đúng cấp.

🛠️ Kết luận: Project manager phải linh hoạt trong hybrid, ưu tiên release planning để cân bằng agile và predictive. Áp dụng ngay để tránh rủi ro tuân thủ! 📘

🧩 Phân tích chi tiết câu hỏi PMP về Quản lý Rủi ro

📖 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả một tình huống trong cuộc họp quản lý rủi ro của dự án, nơi hầu hết thành viên đội dự án sử dụng máy tính để lặp lại (iterate) mô hình phân tích rủi ro định lượng nhiều lần. Kết quả sẽ tạo ra phân phối xác suất tích lũy (cumulative probability distribution) dưới dạng đường cong S (S-curve), đại diện cho xác suất đạt được bất kỳ kết quả cụ thể nào (ví dụ: hoàn thành dự án trong thời gian hoặc ngân sách nhất định).

🛠️ Mục tiêu câu hỏi: Xác định phương pháp phù hợp nhất mà Project Manager (PM) nên sử dụng để đánh giá và quản lý rủi ro dự án, tập trung vào phân tích rủi ro định lượng (Quantitative Risk Analysis). Đây là kỹ thuật sử dụng dữ liệu số để mô phỏng và dự báo kết quả dự án, thường áp dụng khi rủi ro phức tạp và cần mô hình hóa xác suất.

✅ Đáp án đúng: Monte Carlo analysis
Lý do lựa chọn (theo PMBOK Guide phiên bản mới nhất):
Phương pháp Monte Carlo analysis là kỹ thuật mô phỏng (simulation) sử dụng máy tính để chạy mô hình rủi ro hàng nghìn lần với các đầu vào ngẫu nhiên (dựa trên phân phối xác suất của thời gian, chi phí, v.v.). Kết quả tạo ra S-curve chính xác mô tả phân phối tích lũy của các kết quả dự án (như tổng thời gian hoàn thành hoặc tổng chi phí). Điều này khớp hoàn hảo với mô tả: sử dụng máy tính lặp lại nhiều lần và tạo S-curve.
📘 Nguồn tham khảo: PMBOK® Guide 7th Edition (2021), phần Quantitative Risk Analysis trong Domain 4: Risk Management (Data Analysis techniques); cũng được củng cố trong PMBOK® Guide 6th Edition, Process 11.5: Perform Quantitative Risk Analysis. PMP Exam Content Outline 2021 (hiệu lực đến 2026) nhấn mạnh simulation techniques như Monte Carlo cho rủi ro định lượng.

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

Dưới đây là phân tích chi tiết từng lựa chọn. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, nhưng giải thích hoàn toàn bằng tiếng Việt dựa trên kiến thức PMP cập nhật:

• ❌ Influence diagrams
  Phương án này SAI vì Influence diagrams là công cụ phân tích định tính (qualitative), dùng để vẽ sơ đồ quan hệ nhân quả giữa các biến rủi ro (như sơ đồ mạng lưới). Nó không sử dụng máy tính lặp lại mô hình, không tạo S-curve, và chỉ hỗ trợ xác định rủi ro ban đầu chứ không phải phân tích định lượng với xác suất tích lũy.

• ❌ Sensitivity analysis
  Phương án này SAI vì Sensitivity analysis (phân tích độ nhạy) là kỹ thuật định lượng kiểm tra tác động của từng rủi ro riêng lẻ bằng cách thay đổi một biến tại một thời điểm (one-at-a-time), thường hiển thị dưới dạng tornado diagram. Nó không lặp lại mô hình nhiều lần toàn diện và không tạo S-curve tích lũy cho toàn bộ dự án.

• ❌ Decision tree analysis
  Phương án này SAI vì Decision tree analysis là công cụ định lượng sử dụng cây quyết định để mô hình hóa các lựa chọn và rủi ro với xác suất/emv (expected monetary value). Nó thực hiện thủ công hoặc đơn giản trên phần mềm, không yêu cầu lặp lại mô hình hàng nghìn lần bằng máy tính, và không sản sinh S-curve mà chỉ tính giá trị kỳ vọng tại các nút cuối.

• ✅ Monte Carlo analysis
  Phương án này ĐÚNG (như đã giải thích ở trên). Đây là kỹ thuật mô phỏng định lượng chuẩn trong PMP, lý tưởng cho tình huống mô tả, giúp dự báo rủi ro tổng thể với độ tin cậy cao nhờ S-curve.

💡 Lưu ý cuối cùng: Câu hỏi kiểm tra sự phân biệt giữa các kỹ thuật Quantitative Risk Analysis. Monte Carlo là lựa chọn duy nhất khớp với mô phỏng máy tính lặp lại và S-curve. Để ôn thi PMP, hãy thực hành với phần mềm như @Risk hoặc Crystal Ball! 🚀

🧩 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 quản lý dự án: Một thành viên đội ngũ dự án quan trọng gặp tai nạn và phải nằm viện ít nhất 2 tháng. Các hạng mục backlog (backlog items) mà thành viên này đang làm bị trì hoãn vì chỉ có người đó biết cách hoàn thành chúng. Đây là ví dụ điển hình về rủi ro "single point of failure" (điểm thất bại duy nhất) do phụ thuộc quá mức vào một cá nhân, thường gặp trong môi trường Agile/Scrum với backlog.

Câu hỏi yêu cầu: Project manager (PM) có thể làm gì để tránh tình huống này từ trước?
🛠️ Chủ đề liên quan đến Quản lý Tài nguyên (Resource Management), Quản lý Kiến thức (Knowledge Management) và Quản lý Rủi ro (Risk Management) theo PMBOK Guide 7th Edition (2021) và Agile Practice Guide. Tình huống nhấn mạnh nhu cầu chia sẻ kiến thức để tránh gián đoạn dự án do mất nhân sự bất ngờ.

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

Đáp án đúng: Developed a knowledge transfer plan
✅ Lý do: Việc phát triển kế hoạch chuyển giao kiến thức (knowledge transfer plan) là biện pháp trực tiếp và chủ động nhất để tránh tình trạng "chỉ một người biết". Kế hoạch này đảm bảo kiến thức chuyên môn được chia sẻ rộng rãi trong đội ngũ, giúp các thành viên khác có thể tiếp tục công việc mà không bị gián đoạn. Theo PMBOK 7th Edition, đây là phần cốt lõi của Knowledge Management và Develop Team process (Process 9.4), đặc biệt trong môi trường Agile nơi backlog cần tính linh hoạt cao. Nó giải quyết gốc rễ vấn đề phụ thuộc kiến thức cá nhân, ngăn chặn trì hoãn ngay cả khi có sự cố bất ngờ.

📋 Giải thí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, với 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 nguyên tắc PMP mới nhất (PMBOK 7th Edition & PMP Exam Content Outline 2021, cập nhật đến 2026).

• ❌ Identified this risk and defined a risk response plan
  Sai vì: Việc xác định rủi ro (risk identification) và lập kế hoạch ứng phó (risk response plan) là bước đầu tiên tốt theo Risk Management processes (Processes 11.2-11.5), nhưng không trực tiếp giải quyết vấn đề kiến thức độc quyền. Rủi ro "mất key member" có thể được xác định, nhưng kế hoạch ứng phó chung chung (như mitigation) chưa đảm bảo kiến thức được chuyển giao. Câu hỏi tập trung vào tránh tình huống "only person who knew", không phải chỉ quản lý rủi ro tổng quát.

• ❌ Assigned the backlog items to at least two of the team members
  Sai vì: Phân công backlog cho ít nhất hai người nghe có vẻ hợp lý để tránh single point of failure, nhưng không đảm bảo kiến thức được chia sẻ. Theo Agile Practice Guide, chỉ phân công nhiệm vụ mà không có training/transfer thì người thứ hai vẫn không biết cách làm, dẫn đến trì hoãn tương tự. Đây chỉ là cross-training cơ bản, không phải giải pháp gốc rễ cho vấn đề kiến thức độc quyền.

• ✅ Developed a knowledge transfer plan
  Đúng vì: Như đã giải thích ở trên, đây là biện pháp tối ưu và trực tiếp, thuộc Knowledge Management principles và Manage Team process. Nó chủ động xây dựng tư duy "no single point of knowledge", giúp đội ngũ tự chủ hơn, phù hợp với 12 Principles of PMBOK 7th (như Stewardship, Teamwork) và Agile values (collective ownership).

• ❌ Reserved a contingency budget for external consultants
  Sai vì: Dự phòng ngân sách dự phòng (contingency budget) cho consultant bên ngoài thuộc Cost Management và risk response strategy (transference/acceptance), nhưng chỉ giải quyết tạm thời sau sự cố, không tránh được trì hoãn ban đầu (2 tháng). Nó tốn kém, chậm trễ (tìm consultant), và không xây dựng năng lực nội bộ – trái với tinh thần team development trong PMBOK 7th.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Section 4.3 (Knowledge Management), Process 9.4 (Develop Team), Principle 9 (Teamwork).
• Agile Practice Guide (2017, tích hợp PMBOK 7th): Chapter 5 (Servant Leadership), nhấn mạnh knowledge sharing trong backlog grooming.
• PMP Exam Content Outline (PMI, 2021 - cập nhật 2026): Domain III (Business Environment) & IV (People) – 42% trọng số về team & knowledge.
• PMI Code of Ethics: Nhấn mạnh proactive risk & knowledge mitigation.

🛠️ Lời khuyên PMP: Luôn ưu tiên knowledge transfer trong onboarding và retrospectives để xây dựng đội ngũ resilient! Nếu cần ví dụ thực tế, hãy hỏi thêm.

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

Câu hỏi này thuộc phần Agile/Scrum trong PMP, mô tả tình huống một thành viên đội phát triển (development team member) phát hiện rằng một tính năng sản phẩm (product feature) đã được giao trong sprint trước có thể mang lại giá trị kinh doanh lớn hơn nếu thêm một cải tiến nhỏ (small enhancement). Câu hỏi yêu cầu hành động tiếp theo của Project Manager (PM) là gì?

🔍 Phân tích ngữ cảnh:

• Sprint trước đã kết thúc và feature đã được delivered (giao nộp), nên không thể thay đổi trực tiếp trong sprint đó (theo nguyên tắc Agile: sprint là time-boxed, không thay đổi scope trong sprint).
• Enhancement mới cần được thêm vào Product Backlog dưới dạng user story hoặc item mới, sau đó prioritize bởi Product Owner (PO) dựa trên giá trị kinh doanh.
• PM trong Agile đóng vai trò facilitator, hỗ trợ quy trình Scrum events để đảm bảo tính minh bạch và giá trị tối ưu (theo PMBOK® Guide 7th Edition và Agile Practice Guide).
• Mục tiêu: Xử lý feedback sau sprint một cách đúng quy trình, tránh gián đoạn sprint hiện tại.

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

Đáp án đúng: Discuss this feature in the next sprint planning meeting.

Lý do:
🛠️ Trong Scrum, mọi thay đổi hoặc enhancement phải được đưa vào Product Backlog và thảo luận tại Sprint Planning meeting tiếp theo (là sự kiện đầu tiên của sprint mới). Tại đây, Product Owner sẽ prioritize các item dựa trên giá trị kinh doanh, đội phát triển sẽ ước lượng và chọn vào Sprint Backlog. PM nên facilitate discussion để đảm bảo tính minh bạch, không tự ý thêm story mà bỏ qua PO. Điều này tuân thủ Scrum Guide 2020 (cập nhật đến 2025) và PMBOK® 7th Edition - Principle 5: Optimize Value, tránh thay đổi mid-sprint gây rối loạn flow. Đây là bước "next" hợp lý nhất sau khi feature đã delivered.

📋 Phân tích tất cả các phương án (đúng/sai)

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 tiếng Anh. Mỗi phương án được đánh giá dựa trên quy trình Agile/Scrum chuẩn PMP (PMBOK® 7th Edition, Agile Practice Guide 2021, Scrum Guide 2020-2025).

• ❌ Conduct another sprint planning meeting and add the necessary story.
  ❌ Sai vì: Việc tổ chức thêm Sprint Planning meeting ngay lập tức vi phạm nguyên tắc time-boxed sprint (sprint không thể bị gián đoạn). Sprint hiện tại (nếu đang chạy) hoặc sprint mới chưa bắt đầu không cho phép "another" planning. PM không được tự ý "add the necessary story" mà phải qua PO prioritize. Điều này có thể dẫn đến technical debt hoặc mất kiểm soát backlog (vi phạm Principle 9: Leadership trong PMBOK 7th).

• ✅ Discuss this feature in the next sprint planning meeting.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là Scrum event đúng chuẩn để review enhancement, refine backlog và quyết định prioritize. PM facilitate để đội và PO thảo luận giá trị kinh doanh, đảm bảo incremental value delivery (Agile Principle #1: Satisfy customer through early and continuous delivery).

• ❌ Discuss this feature during the upcoming retrospective meeting.
  ❌ Sai vì: Sprint Retrospective chỉ tập trung vào cải thiện quy trình đội ngũ (process improvement, như "làm việc hiệu quả hơn"), không phải thêm/chỉnh sửa feature hoặc backlog items. Retrospective dành cho reflection về sprint vừa qua (e.g., "cái gì tốt/xấu?"), không xử lý change request kinh doanh (Scrum Guide: Retrospective purpose là adapt cách làm việc, không phải content).

• ❌ Advise the team member to better prepare before sprint planning.
  ❌ Sai vì: Lời khuyên này mang tính trừng phạt (blame), không khuyến khích continuous improvement trong Agile. Team member phát hiện enhancement là positive feedback loop, PM nên hỗ trợ đưa vào quy trình thay vì trách móc "better prepare". Vi phạm Servant Leadership của PM (PMBOK 7th - Principle 10: Adaptability).

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Chương 5 (Tailoring) & Principle 5 (Value Optimization).
• Agile Practice Guide (2021): Section 4.3 (Scrum Events: Sprint Planning).
• Scrum Guide (2020, reaffirmed 2025): Trang 9-11 (Events: Sprint Planning & Backlog Refinement).
• Cập nhật đến 2026: Không thay đổi lớn về Scrum events (theo Scrum.org & PMI updates).

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é!

🧩 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ý dự án Agile trong PMP, tập trung vào việc áp dụng các thực hành Agile trong dự án phần mềm hàng không (aviation software project). Dự án được cấu trúc theo phương pháp Agile dựa trên chính sách mới của công ty, nhưng phải tuân thủ quy định ngành nghiêm ngặt (industry regulations), yêu cầu theo dõi chi tiết và lưu trữ (tracking and archival) các thay đổi sản phẩm.

📌 Vấn đề cốt lõi: Project Manager (PM) cần công cụ nào để hiểu rõ tác động của yêu cầu tuân thủ (compliance impact) lên dự án? Điều này đòi hỏi phải xác định các artifact Agile giúp quản lý và kiểm soát thay đổi sản phẩm một cách minh bạch, đảm bảo traceability (khả năng truy vết) – yếu tố quan trọng trong môi trường quy định cao như hàng không. Theo PMBOK® Guide 7th Edition và Agile Practice Guide (PMI, 2021), Agile không loại bỏ compliance mà tích hợp nó vào các quy trình linh hoạt.

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

Product backlog and definition of done (DoD)

🛠️ Lý do chi tiết:

• Product Backlog là danh sách toàn diện tất cả các yêu cầu dự án (bao gồm user stories, bugs, technical tasks, và các item compliance như tracking/archival changes). Nó giúp PM đánh giá tác động tổng thể của quy định lên scope, effort, và prioritization – ví dụ: thêm các backlog items dành riêng cho audit trails hoặc version control.
• Definition of Done (DoD) định nghĩa tiêu chí hoàn thành cho mỗi backlog item, bao gồm các kiểm soát compliance như "thay đổi đã được logged, archived, và verified theo quy định". DoD đảm bảo mọi thay đổi sản phẩm đều tuân thủ, giúp PM dự đoán rủi ro và điều chỉnh kế hoạch Agile.
• Kết hợp hai yếu tố này cho phép PM phân tích tác động compliance một cách động (iterative), phù hợp với dự án Agile quy định cao.
  Nguồn tham khảo: Agile Practice Guide (PMI, 2021) – Phần 4.2 Product Backlog & 5.3 DoD; PMBOK® Guide 7th Edition – Principle 5: Value & Hybrid Approaches (cập nhật đến 2026, nhấn mạnh compliance trong Agile).

📋 Phân tích tất cả các phương án (đúng/sai)

• ❌ User stories and release plan
  Sai vì: User stories chỉ là mô tả chi tiết một phần nhỏ của yêu cầu (từ góc nhìn user), không bao quát toàn bộ thay đổi sản phẩm hay compliance tracking. Release plan tập trung vào lịch phát hành, không trực tiếp phân tích tác động quy định (chỉ là high-level planning). Không đủ để hiểu compliance impact toàn diện.

• ✅ Product backlog and definition of done (DoD)
  Đúng vì: Như giải thích ở trên, đây là cặp artifact cốt lõi trong Agile/Scrum để quản lý và kiểm soát thay đổi sản phẩm, tích hợp compliance một cách traceable và iterative. Hoàn hảo cho dự án quy định cao.

• ❌ Scope of work and product backlog
  Sai vì: Scope of work là khái niệm truyền thống (Waterfall), định nghĩa scope ban đầu cố định, không linh hoạt cho Agile. Kết hợp với Product Backlog tạo sự không nhất quán (hybrid không phù hợp), và không giải quyết trực tiếp archival/tracking như DoD.

• ❌ Sprint retrospective and release plan
  Sai vì: Sprint retrospective là buổi review sau sprint để cải tiến process (lessons learned), không dùng để phân tích compliance impact upfront. Release plan chỉ là kế hoạch phát hành, thiếu chiều sâu về tracking thay đổi sản phẩm.

📘 Tài liệu tham khảo chính (cập nhật đến 2026)

• PMBOK® Guide – Seventh Edition (PMI, 2021): Principles & Performance Domains (Stakeholder, Uncertainty).
• Agile Practice Guide (PMI, 2021): Life Cycle và Disciplined Agile® Toolbox.
• Scrum Guide (2020, Scrum.org): Product Backlog & Definition of Done (khuyến nghị cho PMP Agile).
• PMI Standards Update 2025-2026: Nhấn mạnh "Regulatory Compliance in Agile" trong Portfolio Management Standard.

🧠 Kết luận: Câu hỏi kiểm tra khả năng áp dụng Agile artifacts cho môi trường regulated, giúp PM dự đoán và mitigate rủi ro compliance! Nếu cần ví dụ thực tế, hãy hỏi thêm nhé! 🚀

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

Câu hỏi mô tả tình huống một Project Manager (PM) đang dẫn dắt việc thực thi chương trình (program execution), gặp thách thức vì đội ngũ dự án (project team) luôn chờ đợi mọi quyết định từ PM. Điều này khiến tiến độ chậm lại, với PM trở thành điểm nghẽn (bottleneck). Sau khi đánh giá, PM nhận ra rằng các thành viên đội ngũ hoàn toàn có khả năng tự xử lý công việc.
🛠️ Vấn đề cốt lõi: Đây là tình huống điển hình về quản lý đội ngũ và trao quyền (team empowerment) trong PMP. PM cần hành động để giảm sự phụ thuộc vào bản thân, thúc đẩy sự tự chủ của đội ngũ, phù hợp với nguyên tắc Servant Leadership (Lãnh đạo phục vụ) và High-Performing Teams trong PMBOK® Guide 7th Edition (2021) và cập nhật PMP Exam Content Outline 2021 (vẫn áp dụng đến 2026). Không phải vấn đề về nguồn lực hay đào tạo, mà là rõ ràng hóa vai trò và trao quyền quyết định.

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

Đáp án đúng: Revise the roles and responsibilities and empower the team to make their own decisions.
Lý do:

• Theo PMBOK® Guide 7th Edition (Chapter 4: Team & Stakeholders), PM phải xác định và chỉnh sửa roles & responsibilities (sử dụng công cụ như RACI Matrix) để tránh chồng chéo và trao quyền (empower) cho đội ngũ.
• Empowerment giúp đội ngũ tự quyết định trong phạm vi trách nhiệm, giảm bottleneck, tăng tốc độ và hiệu suất – phù hợp Principle 9: Leadership và Value Delivery.
• Đây là hành động chủ động, trực tiếp từ PM, không cần can thiệp bên ngoài, thể hiện Servant Leader hỗ trợ đội ngũ phát triển.
  📘 Nguồn: PMBOK® Guide 7th Ed., p. 87-92 (Team Performance Domain); PMP Exam Content Outline, People Domain (Task 4: Empower team members).

📋 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 nội dung gốc bằng 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:

• ❌ [SAI] Raise a resource request to get complimentary training for the project manager and team members.
  Giải thích: Phương án này không phù hợp vì vấn đề không phải thiếu kỹ năng (PM đã đánh giá đội ngũ "can handle the work on their own"). Yêu cầu đào tạo bổ sung (complimentary training) chỉ làm chậm tiến độ hơn, lãng phí nguồn lực. PMP ưu tiên giải quyết gốc rễ (root cause) thay vì đào tạo không cần thiết (PMBOK® 7th Ed., Problem-Solving Principle). Không liên quan đến Resource Management ở đây.

• ❌ [SAI] Escalate the situation to the resource manager to ensure the team makes their own decisions.
  Giải thích: Escalation chỉ dùng cho vấn đề vượt quyền PM (như thiếu nguồn lực nghiêm trọng), không phải trường hợp PM có thể tự giải quyết bằng cách trao quyền. Điều này vi phạm PM Accountability (PMBOK® 7th Ed., p. 45), làm PM mất uy tín lãnh đạo và không khuyến khích team self-management. Resource manager không chịu trách nhiệm về quyết định nội bộ đội ngũ.

• ❌ [SAI] Gather feedback from all team members and define a process to handle the team requests.
  Giải thích: Việc thu thập feedback và định nghĩa quy trình (process) là gián tiếp, chậm chạp, không giải quyết ngay bottleneck. Nó có thể tạo thêm thủ tục rườm rà, làm tình hình tệ hơn. PMP nhấn mạnh empowerment trực tiếp thay vì bureaucracy (PMBOK® 7th Ed., Team Performance Domain; Agile Hybrid approaches ưu tiên autonomy hơn process-heavy).

• ✅ [ĐÚNG] Revise the roles and responsibilities and empower the team to make their own decisions.
  Giải thích: Như đã nêu ở phần đáp án đúng, đây là hành động tối ưu, trực tiếp chỉnh sửa roles & responsibilities (RACI/Responsibility Assignment Matrix) và empower đội ngũ. Tăng team maturity, giảm phụ thuộc PM, phù hợp 12 Principles of PMBOK® 7 (đặc biệt Leadership & Teamwork). Kết quả: Progress nhanh hơn, team high-performing.

🧩 Kết luận: Câu hỏi kiểm tra People Domain (35% PMP exam), nhấn mạnh lãnh đạo trao quyền thay vì kiểm soát micromanagement. Áp dụng ngay để đạt Value Delivery! 📘 Tài liệu tham khảo chính: PMBOK® Guide 7th Edition (PMI, 2021); PMP Exam Content Outline (PMI, 2021, cập nhật 2024).

🧩 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ý dự án theo PMP (Project Management Professional), cụ thể liên quan đến việc báo cáo tiến độ và công việc còn lại (work remaining) trong bối cảnh công ty đang thực hiện chương trình cắt giảm chi phí lớn (large cost-cutting initiative). Ban lãnh đạo cấp cao (senior management) yêu cầu project manager cung cấp báo cáo về công việc còn lại cho các dự án đang mở (outstanding projects).

📘 Bối cảnh PMP mới nhất (PMBOK 7th Edition & Agile Practice Guide, cập nhật đến 2026): Trong môi trường dự án hybrid hoặc Agile (phổ biến ngày càng tăng), việc theo dõi công việc còn lại là yếu tố then chốt để hỗ trợ quyết định cắt giảm chi phí, tối ưu tài nguyên. Câu hỏi nhấn mạnh nhu cầu một công cụ trực quan, đơn giản để hiển thị lượng công việc còn lại theo thời gian, giúp lãnh đạo nhanh chóng đánh giá rủi ro và ưu tiên.

🛠️ Mục tiêu chính: Project manager cần chọn tool phù hợp nhất để visualize work remaining, không phải phân tích chi phí sâu hay dự báo phức tạp.

✅ Đáp án đúng: Burndown chart

Lý do lựa chọn:

• Burndown chart là biểu đồ trực quan hiển thị lượng công việc còn lại (remaining work) theo trục thời gian (thường là sprint hoặc milestone), với đường "ideal" và đường thực tế. Nó giúp nhanh chóng thấy công việc còn bao nhiêu và dự kiến hoàn thành khi nào, lý tưởng cho báo cáo lãnh đạo trong tình huống cắt giảm chi phí.
• Trong PMBOK 7th Edition (2021) và Agile Practice Guide, burndown chart được khuyến nghị cho Agile/Scrum projects để theo dõi backlog và progress (Tool & Technique trong Manage Agile Teams). Phù hợp với các dự án outstanding cần báo cáo nhanh, hỗ trợ quyết định stop/reprioritize.
• ✅ Ưu điểm nổi bật: Đơn giản, trực quan (giảm từ trên xuống), dễ hiểu cho non-technical stakeholders như senior management.

🔍 Phân tích tất cả các phương án (Đúng/Sai)

Dưới đây là phân tích chi tiết từng lựa chọn theo kiến thức PMP cập nhật 2026 (dựa trên PMBOK 7th Edition, Process Groups: Monitoring & Controlling; Agile Hybrid Approaches). Tôi giữ nguyên văn bản phương án bằng tiếng Anh, nhưng giải thích hoàn toàn bằng tiếng Việt.

• ❌ [SAI] Forecast estimation
  Phương án này không phải là tool chuẩn trong PMP để báo cáo work remaining. Forecasting (như Estimate at Completion - EAC) dùng để dự báo tổng chi phí/tài nguyên cuối dự án (trong Earned Value Management - EVM, PMBOK 7.4 Manage Project Work). Nó tập trung vào dự đoán tương lai dựa trên dữ liệu hiện tại, không trực quan hóa công việc còn lại cụ thể cho outstanding projects. Không phù hợp cho báo cáo nhanh của senior management.

• ❌ [SAI] Earned Value (EV)
  Earned Value là metric chính trong EVM (PMBOK 7th: Measure performance objectively), tính giá trị kiếm được (EV = % complete x BAC) để đánh giá schedule/cost variance. Nó không trực tiếp hiển thị work remaining mà chỉ so sánh planned vs actual. Dùng EV cần phân tích sâu (CPI/SPI), không lý tưởng cho báo cáo tổng quan cắt giảm chi phí – quá phức tạp cho lãnh đạo.

• ❌ [SAI] Cumulative flow diagram
  Đây là tool Agile/Kanban (Agile Practice Guide) hiển thị luồng công việc tích lũy qua các cột (To Do, In Progress, Done), giúp phát hiện bottlenecks/WIP limits. Nó tốt cho workflow analysis, nhưng không tập trung trực tiếp vào work remaining theo thời gian như burndown. Phù hợp monitor team hơn là báo cáo cao cấp về outstanding projects.

• ✅ [ĐÚNG] Burndown chart
  Như đã giải thích ở trên: Hoàn hảo cho work remaining visualization. Đường chart giảm dần thể hiện backlog giảm, dễ dự báo nếu sẽ hoàn thành (PMBOK 7th: 6.7 Manage Project Knowledge; Agile tools). Trong bối cảnh cost-cutting, nó giúp lãnh đạo thấy rõ rủi ro delay mà không cần đào sâu dữ liệu.

📚 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021, PMI): Chương 4 (Project Performance Domains), Tool 4.6 Visual Information; Agile Practice Guide (Appendix).
• PMI Agile Certified Practitioner (PMI-ACP) Handbook (cập nhật 2024-2026): Burndown charts trong Sprint Review/Planning.
• The Standard for Project Management (2021): Hybrid models nhấn mạnh visual tools cho stakeholder reporting.
• Nguồn online: PMI.org (Exam Content Outline 2024, xác nhận burndown cho Agile metrics).

🧩 Kết luận: Câu hỏi kiểm tra khả năng chọn tool phù hợp context (cost-cutting + outstanding projects) theo PMP hybrid mindset. Burndown chart là lựa chọn tối ưu! Nếu cần ví dụ minh họa chart, hãy hỏi thêm nhé! 🚀

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

Câu hỏi mô tả tình huống một Project Manager (PM) được giao tiếp quản một dự án đang ở giai đoạn thực thi giữa chừng (halfway through execution). Project Sponsor yêu cầu PM đảm bảo rằng công việc đang thực hiện và sản phẩm đang tạo ra không lệch khỏi giá trị kinh doanh đã quy định (prescribed business value).

Mục tiêu chính là kiểm soát và duy trì sự phù hợp với giá trị kinh doanh (business value) – đây là yếu tố cốt lõi trong quản lý dự án hiện đại, nhấn mạnh vào việc dự án phải mang lại lợi ích kinh tế, chiến lược lâu dài thay vì chỉ hoàn thành công việc. Theo PMBOK 7th Edition (2021) và các cập nhật đến 2026, business value được liên kết chặt chẽ với việc thực hiện lợi ích (benefits realization), không chỉ dừng ở yêu cầu kỹ thuật hay chất lượng sản phẩm.

✅ Đáp án đúng: Review the benefits realization plan

Lý do chọn đáp án này:
Benefits realization plan là tài liệu chính thức mô tả cách thức đạt được lợi ích dự kiến từ dự án, bao gồm các chỉ số đo lường giá trị kinh doanh (business value), timeline thực hiện lợi ích, và trách nhiệm theo dõi. Khi dự án đang thực thi, PM cần xem xét kế hoạch này để đảm bảo công việc và sản phẩm không lệch khỏi mục tiêu giá trị kinh doanh. Điều này phù hợp với Process 4.7 Manage Project Knowledge và Principle 3: Value Focus trong PMBOK 7th, nơi nhấn mạnh việc liên tục đánh giá lợi ích để tránh "value drift" (sự lệch lạc giá trị). ✅ Hoàn hảo cho tình huống tiếp quản dự án đang chạy!

🛠️ 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 bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên PMBOK 7th Edition và các thực hành tốt nhất PMP cập nhật:

• Review the requirements management plan.
  ❌ Sai: Requirements management plan tập trung vào việc thu thập, phân tích, ưu tiên và theo dõi yêu cầu chức năng/non-chức năng (requirements), không trực tiếp liên kết với business value tổng thể. Nó giúp kiểm soát phạm vi kỹ thuật nhưng không đảm bảo sản phẩm mang lại lợi ích kinh doanh dài hạn. Trong PMBOK 7th (Section 4.1 Manage Project Requirements), đây chỉ là công cụ hỗ trợ, không phải trọng tâm cho "prescribed business value".

• Monitor the work breakdown structure (WBS).
  ❌ Sai: WBS là phân tích phân cấp công việc (decomposition of work), dùng để theo dõi tiến độ thực hiện công việc cụ thể (scope baseline). Việc monitor WBS giúp kiểm soát phạm vi và lịch trình (theo Process 5.5 Validate Scope), nhưng không đánh giá business value – nó chỉ đảm bảo "làm đúng việc" chứ không phải "việc đó có giá trị kinh doanh không".

• Carry out quality audits and failure analyses.
  ❌ Sai: Quality audits kiểm tra quy trình chất lượng, còn failure analyses (như root cause analysis) xử lý lỗi/sự cố. Đây thuộc Manage Quality process (8.2) trong PMBOK 7th, tập trung vào tiêu chuẩn chất lượng sản phẩm/quy trình, không liên quan trực tiếp đến business value kinh doanh. Nó có thể hỗ trợ gián tiếp nhưng không phải hành động chính để tránh lệch lạc giá trị.

• Review the benefits realization plan.
  ✅ Đúng: Như đã giải thích ở trên, đây là công cụ trực tiếp nhất để kiểm tra sự phù hợp với business value, theo Benefits Management Practice trong PMBOK 7th và PMI Standards đến 2026. Nó giúp PM xác định các metrics lợi ích và điều chỉnh kịp thời.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Principle 3 (Value), Benefits Realization Model (Appendix), và Process Groups tương tác.
• PMI Benefits Realization Management Practice Standard (2023 cập nhật): Chi tiết về benefits realization plan như công cụ theo dõi value delivery.
• The Standard for Project Management (2021): Nhấn mạnh value delivery trong dự án đang thực thi. (Nguồn chính thức từ PMI.org, kiến thức cập nhật đến 2026 không có thay đổi lớn về khái niệm này).

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ụ thực tế, hãy hỏi nhé!

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

Câu hỏi mô tả một tình huống trong dự án di chuyển máy tính (computer relocation project), nơi toàn bộ thành viên đội dự án đều có kinh nghiệm về di chuyển. Trong cuộc họp đội, mọi người đang chia sẻ rất nhiều ý tưởng, dẫn đến tình trạng quá tải thông tin và không thể kết luận được cách tiếp cận di chuyển (relocation approach).

📌 Vấn đề cốt lõi: Đội ngũ đang gặp khó khăn trong việc ra quyết định tập thể do sự đa dạng ý kiến, không phải thiếu kinh nghiệm hay năng lực. Project Manager (PM) cần can thiệp để hỗ trợ đội ngũ tự giải quyết, phù hợp với nguyên tắc Servant Leadership và Facilitation trong PMP (PMBOK 7th Edition, 2021 – cập nhật đến 2026 không thay đổi cơ bản). Mục tiêu là thúc đẩy sự đồng thuận (consensus), tận dụng kinh nghiệm nội bộ thay vì can thiệp từ bên ngoài.

🛠️ Bối cảnh PMP: Theo PMBOK 7th Edition (Principle 7: Foster a Collaborative Culture) và Agile Practice Guide, PM đóng vai trò người hỗ trợ (facilitator) giúp đội đạt consensus, tránh "decision paralysis" (tê liệt quyết định) do quá nhiều lựa chọn.

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

Đáp án đúng: Help the project team create consensus around the solutions.

Lý do (🧩 Phân tích sâu):

• Đội ngũ đã có kinh nghiệm và đang tích cực chia sẻ ý tưởng → PM không cần quyết định thay hay outsource, mà hỗ trợ tạo sự đồng thuận qua các kỹ thuật facilitation như brainstorming prioritization (ví dụ: dot voting, MoSCoW method) hoặc affinity diagramming.
• Điều này phù hợp Servant Leader model (PMBOK 7th, p. 42-43): PM empower đội nhưng hướng dẫn quy trình để tránh hỗn loạn. Kết quả: Tăng ownership, motivation và chất lượng quyết định.
• Nguồn tham khảo: PMBOK Guide 7th Edition (2021), Section 4.8 Facilitation & Models, Rules, and Tools (p. 128-130); PMP Exam Content Outline 2021 (Domain III: Business Environment, Task 4).

📋 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 giữ nguyên văn bản gốc bằng tiếng Anh, kèm giải thích tại sao đúng/sai dựa trên PMP mới nhất:

• [SAI] Employ a consulting company to offer best practice solutions.
  ❌ Lý do sai: Đội ngũ đã có kinh nghiệm (experienced with relocation), không cần thuê ngoài tốn kém và làm giảm ownership của đội. Điều này vi phạm Principle 10: Optimize Risk (PMBOK 7th) vì tạo dependency không cần thiết, làm chậm dự án. Thay vào đó, tận dụng nội lực (internal capability).

• [SAI] Seek management's decision for the best relocation approach.
  ❌ Lý do sai: Escalation lên management chỉ khi đội thiếu authority hoặc rủi ro cao, nhưng ở đây đội có kinh nghiệm và chỉ cần facilitation. PM phải empower đội (PMBOK 7th, Principle 2: Deliver Value), tránh micromanagement từ cấp trên, dẫn đến giảm team morale.

• [SAI] Empower the team members to make decision themselves.
  ❌ Lý do sai: Đội đã được empower (đang share ideas tự do), nhưng thiếu structure dẫn đến "analysis paralysis". Chỉ empower mà không facilitate sẽ làm tình hình tệ hơn (PMBOK 7th, Agile Principle: Facilitated decision-making). PM cần hướng dẫn quy trình, không phải "thả lỏng hoàn toàn".

• [ĐÚNG] Help the project team create consensus around the solutions.
  ✅ Lý do đúng: Hoàn hảo khớp với vai trò PM là facilitator giúp đội prioritize ý tưởng và đạt consensus (80% agreement theo best practice). Tăng collaboration, phù hợp Hybrid/Agile approach trong dự án nhỏ như relocation (PMBOK 7th, p. 129: Consensus-building techniques).

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

• PMBOK Guide 7th Edition (PMI, 2021) – Free resources tại pmi.org.
• PMP Exam Prep by Rita Mulcahy (8th Ed., cập nhật 2024).
• The Standard for Project Management (3rd Ed., 2021), Principle 7 & 12.

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é!

🧩 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ý Stakeholder (Stakeholder Management) và Chuyển đổi từ Predictive sang Agile trong PMP (theo PMBOK® Guide 7th Edition và Agile Practice Guide).

📖 Tình huống: Một tổ chức đang trải qua quá trình chuyển đổi lớn, chuyển hầu hết các dự án từ phương pháp Predictive (thuần túy truyền thống, kế hoạch chi tiết từ đầu) sang Agile (lặp lại, linh hoạt, tập trung vào giá trị khách hàng). Phó Giám đốc Marketing (Marketing VP) – một stakeholder chính – bày tỏ lo ngại về việc mất kiểm soát các tính năng (features) sẽ được triển khai trong dòng sản phẩm.

🛠️ Vấn đề cốt lõi: Stakeholder này sợ rằng Agile sẽ làm giảm khả năng kiểm soát, vì Agile không lập kế hoạch toàn bộ từ đầu mà sử dụng Product Backlog, Sprint Planning và Demo để ưu tiên features dựa trên feedback liên tục. Project Manager (PM) cần hành động phù hợp để giải quyết lo ngại, duy trì sự ủng hộ từ stakeholder, đảm bảo thành công chuyển đổi.

Mục tiêu PMP: Tăng cường sự tham gia của stakeholder thông qua giao tiếp hiệu quả, minh bạch, phù hợp với nguyên tắc Tailoring (tùy chỉnh cách tiếp cận) và Value Delivery trong PMBOK 7th.

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

Đáp án đúng: Schedule a meeting with the marketing VP to discuss and clarify the benefits of using an agile approach.

Lý do (theo PMBOK® Guide 7th Edition - Process: Manage Stakeholder Engagement & Agile Practice Guide):

• 🗣️ Trong Agile, giao tiếp trực tiếp và cá nhân hóa là chìa khóa để xây dựng lòng tin với stakeholder. Cuộc họp cho phép PM thảo luận hai chiều, giải thích lợi ích Agile như Product Backlog refinement, Sprint Review/Demo giúp stakeholder kiểm soát features qua feedback liên tục (không mất kiểm soát mà còn tăng tính minh bạch và thích ứng).
• ✅ Điều này phù hợp Stakeholder Engagement Assessment Matrix (hướng tới "Supportive" hoặc "Leading"), tránh hiểu lầm và thúc đẩy sự ủng hộ. Không hành động trực tiếp sẽ làm giảm engagement, ảnh hưởng đến dự án chuyển đổi.
• 📘 Nguồn tham khảo: PMBOK® 7th Ed., Principle 7: Engage Stakeholders; Agile Practice Guide, Ch. 3: Agile Team & Stakeholder.

📋 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:

• ❌ [SAI] Email the marketing VP with a cost-benefit analysis of the new model, detailing how the company will improve its products.
  Phân tích: Phương án này thiếu tính tương tác, chỉ gửi email một chiều với phân tích chi phí-lợi ích (CBA) chung chung, không giải quyết trực tiếp lo ngại về "mất kiểm soát features". Trong Agile, stakeholder cần demo thực tế hoặc thảo luận để hiểu rõ, email dễ bị bỏ qua hoặc hiểu sai. PMP nhấn mạnh High-bandwidth communication (trực tiếp > email). (PMBOK 7th, Tools: Data Gathering & Analysis).

• ✅ [ĐÚNG] Schedule a meeting with the marketing VP to discuss and clarify the benefits of using an agile approach.
  Phân tích: Như đã giải thích ở trên, đây là hành động tối ưu, thúc đẩy hai chiều giao tiếp, minh bạch hóa Agile (ví dụ: features được ưu tiên qua MoSCoW hoặc Value-based prioritization). Giúp chuyển stakeholder từ "Neutral/Resistant" sang "Supportive", hỗ trợ chuyển đổi tổ chức. Hoàn toàn phù hợp nguyên tắc Holistic & Servant Leadership của PM.

• ❌ [SAI] Apply influence with other key stakeholders to mitigate risks that may be generated by the marketing VP.
  Phân tích: Sai vì tránh né vấn đề gốc, coi VP Marketing như "rủi ro" cần "mitigate" qua ảnh hưởng người khác – vi phạm Stakeholder Engagement Plan. PMP yêu cầu giải quyết trực tiếp với cá nhân lo ngại, không dùng "chính trị nội bộ" làm giải pháp chính. Có thể làm giảm lòng tin tổng thể. (PMBOK 7th, Risk Management không áp dụng cho stakeholder nội bộ như vậy).

• ❌ [SAI] Review the issue with the marketing VP and request additional project funding for team training.
  Phân tích: Không liên quan, vì lo ngại là về "kiểm soát features" chứ không phải kỹ năng đội ngũ. Yêu cầu funding training là giả định sai vấn đề, có thể bị từ chối và làm stakeholder nghĩ PM né tránh. Tập trung vào engagement trước, sau mới xem xét resource nếu cần. (PMBOK 7th, Principle 9: Optimize Risk Responses).

🧠 Kết luận PMP: PM phải chủ động engage stakeholder để đảm bảo sự ủng hộ trong chuyển đổi Agile. Hành động đúng giúp dự án đạt Business Value cao hơn! 📘 Tài liệu chính: PMBOK® Guide 7th Edition (2021, vẫn chuẩn đến 2026), PMI Agile Certified Practitioner (PMI-ACP) Handbook.