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

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

Câu hỏi thuộc lĩnh vực quản lý dự án Agile/Scrum trong PMP (Project Management Professional), tập trung vào cách xử lý tình huống user stories bị chậm trễ trong một dự án dài hạn (multiyear business initiative) sử dụng phương pháp prototyping.

• Bối cảnh: Nhóm sản phẩm (product team) đang phát triển prototype để giao giá trị kinh doanh lớn. Một số user stories (các yêu cầu chức năng nhỏ, có thể ước lượng) đang mất thời gian lâu hơn dự kiến.
• Vấn đề cốt lõi: Project manager cần hành động chủ động, phù hợp với Agile để giải quyết nguyên nhân gốc rễ (root cause), thay vì chỉ phản ứng thụ động. Trong Agile, delay thường do dependencies chéo (cross-dependencies) giữa các user stories hoặc uncertainty (sự không chắc chắn) về kỹ thuật/prototype.
• Mục tiêu: Chọn hành động tối ưu ngay lập tức để duy trì tiến độ sprint và backlog, theo nguyên tắc iterative development và empirical process control (Scrum framework).

Câu hỏi kiểm tra kiến thức về Agile tools như spike (nghiên cứu ngắn hạn để giảm rủi ro uncertainty) và quản lý dependencies trong PMBOK 7th Edition (2021) + Agile Practice Guide (cập nhật đến 2026, không thay đổi lớn).

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

Đáp án đúng: Determine cross-dependencies and plan a spike in the next sprint.

Lý do (🛠️ Phân tích chi tiết):

• Trong Agile, delay user stories thường do cross-dependencies (phụ thuộc lẫn nhau giữa các stories/items), đặc biệt ở prototyping multiyear nơi kiến trúc phức tạp. Project manager phải xác định dependencies trước để tránh bottleneck.
• Spike là kỹ thuật Agile lý tưởng: Một user story nghiên cứu ngắn (time-boxed, thường 1-2 ngày) để khám phá uncertainty, prototype proof-of-concept, và chia nhỏ stories lớn. Lập kế hoạch spike trong sprint tiếp theo giúp giải quyết nhanh, không làm gián đoạn sprint hiện tại.
• Hành động này chủ động, dữ liệu-driven, phù hợp Scrum Events và Product Backlog Refinement. Theo PMBOK 7, hỗ trợ Deliver Value Incrementally (Domain: Uncertainty).

📋 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 chi tiế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 dựa trên PMP/Agile best practices.

• E ❌ Phương án SAI: Determine the risks and identify a resolution during the retrospective meeting.
  Giải thích: Retrospective chỉ diễn ra cuối sprint để review quá khứ và cải thiện process, không phải nơi giải quyết risks ngay lập tức. Delay đang xảy ra trong sprint hiện tại, cần hành động proactive (như spike) chứ không chờ retrospective. Điều này vi phạm timely response trong Agile (Scrum Guide 2020).

• E ❌ Phương án SAI: Inform stakeholders about the delay during project updates.
  Giải thích: Chỉ báo cáo delay là hành động thụ động, không giải quyết root cause. PMP yêu cầu project manager quản lý thay đổi (Change Control) và giảm impediments trước khi escalate. Reporting chỉ là communication, không tạo value (vi phạm Stakeholder Engagement domain).

• E ❌ Phương án SAI: Discover the gaps in the communications management plan and address them accordingly.
  Giải thích: Delay user stories không liên quan đến communications plan (kế hoạch giao tiếp). Vấn đề là technical/prototyping dependencies, không phải gap giao tiếp. Áp dụng sai Communications Management process group, lãng phí thời gian (PMBOK 7: Tailor processes phù hợp context).

• A ✅ Phương án ĐÚNG: Determine cross-dependencies and plan a spike in the next sprint.
  Giải thích (🛠️ Bổ sung): Như đã nêu ở phần đáp án đúng. Đây là best practice Agile để handle uncertainty trong prototyping, đảm bảo flow hiệu quả và sustainable pace. Spike giúp refine estimates và break down stories phức tạp.

📘 Tài liệu tham khảo (Cập nhật PMP 2026)

• PMBOK Guide 7th Edition (2021): Chapter 4 (Project Delivery Principles), Agile Hybrid Approaches; Domain 3: Uncertainty.
• Agile Practice Guide (PMI, 2017 - tích hợp PMBOK 7): Spike & Dependencies (p. 42-45, Scrum section); Scrum Guide 2020 (Ken Schwaber/Jeff Sutherland) - Spike as investigation story.
• PMI Standards+ (2024-2026 updates): Nhấn mạnh tailored Agile cho long-term initiatives, không thay đổi core Agile tools.
• Nguồn khuyến nghị: PMI.org PMP Exam Content Outline (2024), xác nhận trọng tâm Agile (50% exam).

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

🧩 Giải thí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 PMP: Project manager (PM) đã quản lý dự án được vài tháng, đột ngột xuất hiện một vấn đề (issue) chưa từng được đăng ký trong danh sách rủi ro (risk register). Vấn đề này có thể gây tác động lớn đến dự án. Câu hỏi yêu cầu xác định hành động đầu tiên và phù hợp nhất mà PM nên thực hiện.

🛠️ Kiến thức PMP liên quan (cập nhật đến 2026 - dựa trên PMBOK® Guide 7th Edition và PMBOK® Guide 8th Edition dự kiến):

• Issue là vấn đề đã xảy ra (current problem), khác với risk (rủi ro tiềm ẩn trong tương lai). Issue không nằm trong risk register ban đầu nhưng vẫn phải được quản lý ngay lập tức qua Issue Log (nhật ký vấn đề).
• PMBOK 7th nhấn mạnh 12 nguyên tắc dự án (Project Principles), đặc biệt Principle 10: Optimize Risk Responses và Principle 7: Engage Stakeholders – yêu cầu hợp tác với team và stakeholders để xử lý issue một cách chủ động, linh hoạt (Tailoring).
• Không có quy trình cứng nhắc như PMBOK 6th (Manage Risks), mà dùng models, methods & artifacts như họp (Meetings), brainstorming để đồng thuận giải pháp. Issue cần workaround (giải pháp tạm thời) nếu là unidentified risk/issue.
• Mục tiêu: Giảm thiểu tác động, không né tránh hoặc trì hoãn.

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

Đáp án đúng: Hold a meeting with the project team and relevant stakeholders to agree on the best way to manage the issue.

Lý do:

• Đây là hành động chủ động, hợp tác phù hợp nhất theo PMP. PM cần engage stakeholders và team để phân tích issue, đồng thuận giải pháp (best way to manage), cập nhật Issue Log và điều chỉnh kế hoạch (Change Request nếu cần).
• Thể hiện leadership (Principle 1: Be a diligent, respectful, and caring steward) và teamwork (Principle 9: Build a team environment). Tránh hành động cá nhân hóa, ưu tiên collaborative decision-making.
• Hiệu quả cao vì issue có impact lớn, cần input từ các bên liên quan để tailor response nhanh chó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 giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm lý do dựa trên PMP:

• Avoid managing the issue as it was not registered as a risk for the project and there is no planned response to it.
  ❌ Sai: Không được bỏ qua issue chỉ vì chưa đăng ký risk. PMP yêu cầu quản lý mọi issue ngay lập tức qua Issue Log, dù là unidentified risk. Né tránh vi phạm Principle 10 (Optimize Risk Responses) và có thể dẫn đến dự án thất bại. Đây là tư duy thụ động, trái với proactive risk/issue management.

• Hold a meeting with the project team and relevant stakeholders to agree on the best way to manage the issue.
  ✅ Đúng: Như đã giải thích ở trên. Hành động này tối ưu, sử dụng meeting (một artifact phổ biến trong PMBOK 7th) để engage team/stakeholders, brainstorm giải pháp và cập nhật baseline. Phù hợp 100% với tình huống issue bất ngờ có impact lớn.

• Delay the project until the issue is addressed and no longer presents as a risk to the project.
  ❌ Sai: Trì hoãn dự án là giải pháp kém hiệu quả, vi phạm Principle 3: Focus on value và time management. PMP khuyến khích workarounds song song với tiến độ, không dừng dự án. Delay chỉ dùng khi không còn lựa chọn, và phải qua Integrated Change Control.

• Inform the sponsor that the issue has arisen and that the project's success may be uncertain.
  ❌ Sai: Chỉ thông báo sponsor là bị động, chưa hành động cụ thể. PMP yêu cầu PM chịu trách nhiệm chính (ownership), không đẩy trách nhiệm lên sponsor ngay. Nên escalate sau khi đã họp team và có kế hoạch rõ ràng (theo Stakeholder Engagement Plan).

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021): Phần Project Issue Management (trang 135-137), Artifacts: Issue Log; Principle 7 & 10.
• PMBOK® Guide – Sixth Edition (để so sánh): 11.7 Manage Project Knowledge & Risk Response (Workarounds for unidentified risks).
• PMI Agile Practice Guide (2021): Nhấn mạnh daily stand-ups/meetings cho issue resolution.
• PMP Exam Content Outline (2021, cập nhật 2024): Domain III: Business Environment (15%) & Domain IV: People (42%) – tập trung stakeholder collaboration.
  (Nguồn: PMI.org – kiến thức chuẩn đến 2026, không thay đổi lớn ở PMBOK 8th draft).

🛠️ Lời khuyên PMP: Luôn ưu tiên họp team cho issue lớn để đảm bảo transparency và shared ownership! Nếu cần thực hành, hãy thử PMP mock exams trên PMI.

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

Câu hỏi này thuộc quá trình Đóng Dự án (Closing Process Group) trong PMP, cụ thể liên quan đến các hoạt động ưu tiên khi một dự án R&D (nghiên cứu và phát triển) kéo dài 2 năm đang kết thúc. 📘

• Bối cảnh: Đội ngũ đang hoàn tất sáng kiến 2 năm, và Quản lý Dự án (PM) đang tập trung vào closing activities (các hoạt động đóng dự án).
• Yêu cầu chính: Xác định hoạt động ưu tiên (priority activity) trong giai đoạn đóng dự án.
  Theo PMBOK Guide 7th Edition (2021) và các cập nhật PMP đến 2026 (PMP Exam Content Outline 2021+), giai đoạn đóng dự án nhấn mạnh vào việc xác nhận giá trị giao (value delivery), chuyển giao kiến thức (knowledge transfer), giải phóng tài nguyên, và thu thập bài học kinh nghiệm (lessons learned) để hỗ trợ các dự án tương lai. Đặc biệt với dự án R&D, kiến thức chuyên môn từ đội ngũ là tài sản quý giá, cần được bảo tồn trước khi giải tán đội ngũ. 🛠️

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

Đáp án đúng: Ensure that knowledge transfer activities are executed as planned.
Lý do:

• Trong Process 4.7: Close Project or Phase (PMBOK 7th Edition), việc chuyển giao kiến thức là hoạt động cốt lõi và ưu tiên cao để đảm bảo kiến thức dự án (lessons learned, best practices) được lưu trữ và chia sẻ, tránh mất mát tri thức khi đội ngũ giải tán.
• Với dự án R&D dài hạn, kiến thức kỹ thuật là tài sản chiến lược, phải thực hiện as planned (theo kế hoạch) trước các hoạt động khác như giải phóng tài nguyên. Điều này phù hợp với Knowledge Management Domain trong PMP (12% trọng số thi).
• Tài liệu tham khảo: PMBOK 7th Edition, Section 4.7.2 (Obtain Acceptance, Lessons Learned); PMI's Pulse of the Profession 2023 (nhấn mạnh knowledge transfer giảm rủi ro 20-30% cho dự án tương lai).

📋 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. Mỗi phương án được đánh giá dựa trên ưu tiên trong closing phase (knowledge trước, administrative sau).

• ❌ [SAI] Release the resources and plan for a project completion celebration.
  Giải thích sai: Giải phóng tài nguyên (release resources) là hoạt động closing nhưng KHÔNG phải ưu tiên hàng đầu. Celebration chỉ mang tính tinh thần, không tạo giá trị bền vững. Theo PMBOK 7, phải hoàn tất knowledge transfer TRƯỚC khi release để tránh mất kiến thức. Làm sớm có thể dẫn đến rủi ro mất mát tri thức ở dự án R&D.

• ✅ [ĐÚNG] Ensure that knowledge transfer activities are executed as planned.
  Giải thích đúng: Như đã phân tích ở trên, đây là ưu tiên số 1 vì đảm bảo kiến thức được chuyển giao đầy đủ theo kế hoạch, hỗ trợ organizational process assets và dự án tương lai. Phù hợp hoàn hảo với bối cảnh R&D (kiến thức cao).

• ❌ [SAI] Hold a steering committee meeting to inform them of the project completion.
  Giải thích sai: Cuộc họp steering committee là administrative closure (thông báo hoàn thành), nhưng KHÔNG ưu tiên so với knowledge transfer. PMBOK 7 khuyến nghị họp này SAU khi có acceptance và lessons learned. Với dự án 2 năm, thông báo có thể làm sau.

• ❌ [SAI] Mark the product backlog completion status and update the communications management plan.
  Giải thích sai: Đây là hoạt động Agile/hybrid (product backlog thuộc Scrum), nhưng KHÔNG phù hợp closing truyền thống của dự án R&D. Communications plan đã hoàn tất ở giai đoạn trước (Monitor & Control). PMBOK 7 ưu tiên value confirmation trước backlog marking; cập nhật plan lúc này là muộn và không ưu tiên.

Kết luận nổi bật: 🏆 Tập trung knowledge transfer giúp dự án đạt benefits realization tối ưu. Khuyến nghị ôn Closing Domain (8%) trong PMP thi mới nhất! 📚

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

Câu hỏi này thuộc chủ đề Quản lý Chất lượng (Manage Quality) trong môi trường Agile theo PMP (PMBOK® Guide 7th Edition và Agile Practice Guide).

✅ Tình huống: Một đội ngũ dự án Agile đang muốn phát triển các tiêu chuẩn chất lượng cho dự án. Vai trò của Project Manager là huấn luyện (coach) đội ngũ như thế nào?

🛠️ Mục tiêu chính: Trong Agile, chất lượng không phải là giai đoạn cuối cùng mà được tích hợp xuyên suốt (continuous quality). Project Manager cần hướng dẫn đội ngũ chọn công cụ phù hợp, nhấn mạnh testing sớm và liên tục để đảm bảo sản phẩm đạt chuẩn Definition of Done (DoD) và phù hợp với nguyên tắc Agile: "Working software over comprehensive documentation" và "Responding to change over following a plan".

📘 Kiến thức liên quan: Theo PMP Exam Content Outline (2021, cập nhật đến 2026), Agile ưu tiên tự tổ chức đội ngũ (self-organizing teams), testing liên tục (shift-left testing), và DoD làm tiêu chuẩn chất lượng chung.

✅ Đáp án đúng

Determine the tools and techniques suitable for the project and ensure that testing is done early and continuously.

Lý do lựa chọn:
🛠️ Phương án này phù hợp nhất vì Project Manager trong Agile đóng vai trò huấn luyện viên (servant leader), giúp đội ngũ chọn công cụ/thuật ngữ phù hợp với dự án cụ thể (tailoring), và nhấn mạnh testing sớm + liên tục (early and continuous testing). Điều này tuân thủ nguyên tắc Agile: chất lượng được xây dựng từ đầu (build quality in), tránh "big bang testing" ở cuối dự án. Theo Agile Practice Guide (PMI, 2017, tích hợp PMBOK 7), testing là phần của mọi iteration/sprint, đảm bảo Definition of Done (DoD) được đạt qua CI/CD và feedback loops.

Dẫn nguồn: PMBOK® Guide 7th Ed., Domain: Uncertainty & Delivery Quality (Section 4.6); Agile Practice Guide, p. 52-54 (Quality in Agile).

📋 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, với giữ nguyên văn bản gốc tiếng Anh. Tôi đánh dấu ✅ đúng và ❌ sai, kèm giải thích bằng tiếng Việt rõ ràng:

• ✅ Determine the tools and techniques suitable for the project and ensure that testing is done early and continuously.
  🛠️ Đúng vì: Như đã giải thích ở trên, đây là cách coach linh hoạt, phù hợp Agile (tailoring tools, continuous testing). Tránh áp đặt cứng nhắc, khuyến khích đội ngũ tự quyết định dựa trên ngữ cảnh dự án.

• ❌ Ensure that the definition of done (DoD) is provided when the product owner agrees that all acceptance criteria have been met for the user story.
  ❌ Sai vì: DoD là tiêu chuẩn chất lượng chung cho toàn đội ngũ và dự án, được định nghĩa từ đầu sprint/release, không phụ thuộc vào sự đồng ý của Product Owner (PO) cho từng user story. Acceptance criteria là cho user story cụ thể, PO xác nhận qua demo/review. Phương án này đảo ngược thứ tự, làm DoD trở thành "phụ thuộc" thay vì dẫn dắt chất lượng.

• ❌ Insist that test-driven development is implemented along with the automated testing.
  ❌ Sai vì: Agile không bắt buộc (insist) TDD (Test-Driven Development) hay automated testing; đây chỉ là các thực hành tốt (practices) tùy chọn, tùy thuộc đội ngũ. Project Manager phải coach linh hoạt (empower team), không áp đặt để tránh chống lại nguyên tắc tự tổ chức (self-organizing). Automated testing khuyến khích nhưng không phải tiêu chuẩn bắt buộc cho mọi dự án Agile.

• ❌ Inform the team that user acceptance testing is required to ensure that the product owner accepts the solution.
  ❌ Sai vì: Trong Agile thuần túy, UAT (User Acceptance Testing) không phải bắt buộc riêng lẻ; PO chấp nhận qua Sprint Review/Demo và DoD + acceptance criteria. UAT có thể dùng ở hybrid nhưng phương án này làm Agile giống Waterfall (giai đoạn cuối), vi phạm "continuous delivery" và vai trò coach không phải "ra lệnh (inform)" mà là hướng dẫn.

Tài liệu tham khảo tổng hợp:
📘 PMBOK® Guide 7th Edition (2021), Agile Practice Guide (PMI); PMP Examination Content Outline (2024 update); Scrum Guide (2020, tích hợp PMP Agile). Kiến thức cập nhật đến 2026 không thay đổi cốt lõi về Agile quality.

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

Câu hỏi gốc:
Due to delays on some activities, one of the project team members has increased the scope without any approval. What should the project manager do next?

🛠️ Giải thích câu hỏi một cách chi tiết và rõ ràng:
Câu hỏi này mô tả tình huống khẩn cấp trong dự án: Do một số hoạt động bị chậm trễ (delays), một thành viên đội ngũ dự án đã tự ý tăng phạm vi (scope) mà không có sự phê duyệt chính thức. Điều này vi phạm nguyên tắc quản lý thay đổi tích hợp (Integrated Change Control) trong PMP. Project Manager (PM) cần hành động bước tiếp theo ngay lập tức để xử lý thay đổi không được kiểm soát này. Chủ đề chính thuộc Process Group: Monitoring and Controlling (theo PMBOK 6th Edition) hoặc Performance Domain: Uncertainty và Change (PMBOK 7th Edition, cập nhật đến 2026). Mục tiêu là đảm bảo dự án tuân thủ baseline scope, đánh giá rủi ro trước khi quyết định, tránh "scope creep" (sự mở rộng phạm vi không kiểm soát).

📘 Dẫn nguồn tham khảo:

• PMBOK® Guide 7th Edition (2021, vẫn là phiên bản mới nhất đến 2026): Section 4.3 (Change Activities), nhấn mạnh "Evaluate change requests" trước khi phê duyệt.
• PMBOK® Guide 6th Edition: Process 4.6 Perform Integrated Change Control – Bước đầu tiên là analyze impact của thay đổi.
• PMI Agile Practice Guide: Nhấn mạnh đánh giá tác động thay đổi trong môi trường linh hoạt.

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

Đáp án đúng: Evaluate the impacts of the changes that were made to the project.

Lý do chi tiết (theo PMP mới nhất):
🧩 Theo quy trình Perform Integrated Change Control, bước đầu tiên khi phát hiện thay đổi không phê duyệt là đánh giá tác động (evaluate impacts) đến các yếu tố như scope, schedule, cost, quality, risk, và resources. Không nên hành động vội vã (như loại bỏ ngay hoặc chấp nhận ngay) mà phải thu thập dữ liệu để trình CCB (Change Control Board) phê duyệt. Điều này phù hợp PMBOK 7th: "Understand the change" trước "Decide on the change". Hành động này giúp PM kiểm soát dự án hiệu quả, tránh quyết định cảm tính do áp lực chậm trễ. ✅ Hoàn hảo cho tình huống scope creep không phê duyệt!

📋 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, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phân tích giải thích vì sao đúng/sai dựa trên PMP standards:

• ❌ Phương án SAI: Remove the changes to match the original requirements.
  🛠️ Giải thích sai: Việc loại bỏ ngay thay đổi để quay về baseline scope là hành động vội vã, thiếu đánh giá. PMBOK yêu cầu phải evaluate impacts trước (cost-benefit analysis), vì thay đổi có thể mang lại lợi ích (ví dụ: cải thiện chất lượng dù chậm). Nếu loại bỏ mà không phân tích, PM có thể bỏ lỡ cơ hội giá trị hoặc gây xung đột đội ngũ. Không phù hợp nguyên tắc "data-driven decision".

• ❌ Phương án SAI: Add team members to the project to avoid more schedule delays.
  🛠️ Giải thích sai: Thêm nhân sự chỉ giải quyết triệu chứng chậm trễ (schedule delays), không xử lý nguyên nhân gốc: scope tăng không phê duyệt. Đây là "resource leveling" sai thời điểm, có thể tăng cost và rủi ro (theo PMBOK 7th: Uncertainty Domain). PM phải ưu tiên kiểm soát scope trước, tránh "throwing resources at problems" mà không đánh giá.

• ❌ Phương án SAI: Update project documentation with the new scope.
  🛠️ Giải thích sai: Cập nhật tài liệu ngay lập tức là chấp nhận thay đổi không phê duyệt, dẫn đến scope creep nghiêm trọng. PMBOK 6th/7th cấm điều này: Phải qua formal change request process và phê duyệt từ CCB/stakeholders trước khi update baseline (Project Management Plan). Hành động này vi phạm tính toàn vẹn dự án!

• ✅ Phương án ĐÚNG: Evaluate the impacts of the changes that were made to the project.
  🛠️ Giải thích đúng: Như đã nêu, đây là bước next logic nhất theo Integrated Change Control. Đánh giá tác động toàn diện (triple constraint + risks) giúp PM quyết định approve/reject/integrate một cách có cơ sở. PMBOK 7th nhấn mạnh "holistic evaluation" để tối ưu giá trị dự án. Hoàn toàn phù hợp tình huống! 🚀

Kết luận PMP: Luôn Control First, Act Second! Nếu áp dụng đúng, dự án sẽ tránh rủi ro lớn. Nếu bạn có câu hỏi PMP khác, hãy hỏi nhé! 📘

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

📖 Mô tả câu hỏi:
Câu hỏi xoay quanh một dự án thay thế hệ thống thanh toán tại chuỗi bán lẻ đa địa điểm. Dự án không đạt ngưỡng tài chính (financial threshold), nhưng mang lại lợi ích chiến lược như tăng thị phần (market share), cải thiện dịch vụ khách hàng (customer services), và giữ chân khách hàng nhiều hơn (retain more customers). Dự án được lập kế hoạch triển khai theo giai đoạn (phased implementation), tận dụng bài học từ retrospectives (họp hồi cứu) ở mỗi giai đoạn.

🎯 Mục tiêu câu hỏi: Hỏi về cách tăng giá trị dự án (increase the value of the project) trong bối cảnh PMP. Theo PMBOK® Guide 7th Edition (2021) và cập nhật đến 2026 (bao gồm Agile Practice Guide và Process Groups: A Practice Guide), trọng tâm là quản lý lợi ích (benefits management) để cân bằng lợi ích tài chính tangible (có thể đo lường) và intangible (không đo lường trực tiếp như sự hài lòng khách hàng). Dự án mang tính hybrid (kết hợp predictive và agile), cần tối ưu hóa giá trị thông qua kế hoạch lợi ích rõ ràng cho từng giai đoạn.

✅ Đáp án đúng:
Quantify the expected tangible and intangible benefits in the benefits management plan for each phase.

🔍 Lý do chọn đáp án đúng (theo PMP mới nhất):

• Benefits Management Plan là tài liệu cốt lõi trong PMBOK® 7th Edition (Section 2.5 & 4.1), giúp định lượng (quantify) lợi ích tangible (ví dụ: doanh thu tăng từ thị phần) và intangible (ví dụ: chỉ số hài lòng khách hàng - CSAT). Việc làm này cho từng phase phù hợp với triển khai phased và retrospectives, giúp tăng giá trị dự án bằng cách làm rõ ROI tổng thể, thuyết phục stakeholders vượt ngưỡng tài chính.
• Điều này hỗ trợ Value Delivery System (PMBOK® 7), nơi lợi ích intangible được chuyển hóa thành metrics đo lường để ưu tiên dự án.
  📘 Tài liệu tham khảo: PMBOK® Guide 7th Ed., trang 47-50 (Benefits Management); The Standard for Project Management, Principle 5: Value.

🛠️ 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. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với lý do đúng/sai dựa trên PMP.

• ❌ [SAI] Ask the benefits owner to reassess the identified risks that are impacting the outcomes of the financial benefits.
  Phương án này tập trung vào đánh giá lại rủi ro (reassess risks) ảnh hưởng lợi ích tài chính, nhưng không trực tiếp tăng giá trị dự án. Rủi ro chỉ là yếu tố tiêu cực; PMP nhấn mạnh benefits realization (PMBOK® 7, Section 4.7) cần chủ động định lượng lợi ích tích cực trước, không phải chỉ fix rủi ro. Không phù hợp với phased approach.

• ❌ [SAI] Use a fishbone diagram to find the root cause of the lower financial benefits with the benefits owner.
  Fishbone diagram (Ishikawa) là công cụ root cause analysis trong Manage Quality (PMBOK® 7, Tool 8.2), dùng cho vấn đề chất lượng hoặc quy trình. Ở đây, vấn đề là lợi ích tài chính thấp, nhưng dự án có lợi ích intangible mạnh – phương án này không giải quyết tăng value tổng thể, chỉ đào sâu nguyên nhân tài chính, bỏ qua phased benefits.

• ❌ [SAI] Consult with experts on methods to reduce costs and increase the financial value of the project.
  Tư vấn chuyên gia để giảm chi phí (reduce costs) chỉ cải thiện financial value, nhưng bỏ qua intangible benefits như thị phần và dịch vụ khách hàng. PMP khuyến nghị holistic value (PMBOK® 7, Principle 1: Stewardship), không chỉ tối ưu chi phí mà cần quantify toàn bộ benefits trong kế hoạch.

• ✅ [ĐÚNG] Quantify the expected tangible and intangible benefits in the benefits management plan for each phase.
  Như đã giải thích ở trên, đây là cách tối ưu nhất để tăng giá trị, phù hợp benefits management plan per phase (PMBOK® 7 & Agile Practice Guide, Iterative Development). Giúp đo lường tiến độ qua retrospectives, thuyết phục portfolio approval.

💡 Kết luận: Câu hỏi kiểm tra kiến thức benefits management trong môi trường hybrid. Áp dụng ngay để dự án vượt ngưỡng! 📘 Nguồn bổ sung: PMI.org - Benefits Management White Paper (2023 update).

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

Câu hỏi mô tả tình huống trong giai đoạn thực hiện (implementation phase) của một dự án xây dựng. Khách hàng yêu cầu nhà thầu phụ chính (key subcontractor) giao một work package sớm hơn thời hạn dự kiến. Nhà thầu phụ chưa chuẩn bị sẵn sàng và yêu cầu ngân sách bổ sung từ project manager (PM).

🛠️ Vấn đề cốt lõi: Đây là yêu cầu thay đổi từ khách hàng, ảnh hưởng đến lịch trình (schedule) và ngân sách (budget). Theo PMBOK Guide 7th Edition (2021, cập nhật đến 2026), PM phải tuân thủ quy trình Perform Integrated Change Control (8.1.6) để xử lý thay đổi chính thức. Hành động đầu tiên (first) phải là submit change request để đánh giá tác động toàn diện (scope, schedule, cost, risk), tránh thay đổi không kiểm soát dẫn đến scope creep hoặc vượt ngân sách.

📈 Bối cảnh PMP: Trong dự án xây dựng, work package là đơn vị công việc nhỏ trong WBS (Work Breakdown Structure). Yêu cầu accelerate (tăng tốc) thường cần phê duyệt để tránh rủi ro chất lượng hoặc chi phí tăng vọt.

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

Đáp án đúng: Submit a change request to accelerate the project as requested.

Lý do:

• Đây là hành động đầu tiên và đúng quy trình theo PMBOK 7th Edition. PM không được tự ý thay đổi budget/schedule mà phải submit change request (Yêu cầu thay đổi tích hợp) để CCB (Change Control Board) hoặc stakeholder phê duyệt.
• Yêu cầu từ khách hàng là chính thức, nhưng cần đánh giá tác động (impact analysis) trước khi thực hiện. Điều này đảm bảo dự án tuân thủ triple constraint (scope-time-cost) và tránh vi phạm baseline.
• 🏆 Ưu tiên: "First" nhấn mạnh quy trình change control trước mọi hành động khác.

📋 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, giữ nguyên văn bản gốc bằng tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do dựa trên nguyên tắc PMP mới nhất.

• ❌ Update the risk register and project log, and manage the budget closely.
  Phương án này sai vì bỏ qua quy trình change control chính thức. Cập nhật risk register/project log chỉ là bước sau khi change request được phê duyệt. Quản lý budget "closely" không giải quyết gốc rễ (yêu cầu accelerate từ khách hàng), có thể dẫn đến sử dụng contingency reserve sai cách mà không có phê duyệt (PMBOK 7th: 7.3.2 Cost Management).

• ❌ Revise the project scope accordingly to cope with the budget changes.
  Phương án này sai vì PM không được tự ý revise scope mà không qua change control. Scope baseline chỉ thay đổi sau phê duyệt change request. Việc này vi phạm scope creep và nguyên tắc "no changes without approval" (PMBOK 7th: 5.6 Control Scope & 8.1.6 Integrated Change Control).

• ✅ Submit a change request to accelerate the project as requested.
  Phương án này đúng như đã giải thích ở trên. Đây là bước first action để khởi động quy trình phê duyệt, đánh giá đầy đủ tác động đến project management plan (schedule, cost, procurement với subcontractor). Tuân thủ 100% PMBOK 7th Edition.

• ❌ Ask upper management for more funds, and update the project budget.
  Phương án này sai vì PM không được tự quyết định thêm funds hoặc update budget mà bỏ qua change control. "Upper management" chỉ tham gia sau impact analysis. Hành động này có thể dẫn đến unauthorized funding, vi phạm governance và cost baseline (PMBOK 7th: 4.6.3.3 Management Reserve & 7.1 Plan Cost Management).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, PMI): Process 8.1.6 Perform Integrated Change Control (trang 143-145); Principle 5: Optimize Risk Responses; Domain 5: Uncertainty.
• PMP Exam Content Outline (2024-2026, PMI): Task 4.7 Evaluate change request; Task 4.8 Approve/Release change.
• Agile Practice Guide (PMI): Hybrid approach cho construction projects, nhấn mạnh change requests trong execution phase.
  🔗 Nguồn chính thức: pmi.org/pmbok-guide-standards (cập nhật mới nhất đến 2026 không thay đổi core process này).

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

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

Câu hỏi này thuộc chủ đề Agile Project Management trong PMP (phiên bản PMBOK Guide 7th Edition và Agile Practice Guide, cập nhật đến 2026). Trong một dự án Agile, đội ngũ đang thực hiện các hoạt động để định nghĩa Minimum Viable Product (MVP) – sản phẩm khả thi tối thiểu, tập trung vào các tính năng cốt lõi để nhanh chóng đưa ra thị trường và thu thập phản hồi.

📌 Tình huống cụ thể: Project Manager (PM) phát hiện ra các quy định bắt buộc (mandatory regulations), ví dụ như quy định pháp lý, an toàn, tuân thủ tiêu chuẩn ngành (compliance). Tuy nhiên, không có sự đồng thuận từ đội ngũ để đưa chúng vào MVP vì lo ngại sẽ kéo dài thời gian dự án (extend the duration).

🛠️ Thách thức chính: PM phải cân bằng giữa tốc độ phát triển Agile (focus on value delivery nhanh) và tuân thủ bắt buộc (non-negotiable requirements). Trong Agile, MVP không được bỏ qua các yếu tố compliance vì rủi ro pháp lý cao hơn lợi ích thời gian.

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

Đáp án đúng: Get commitment from the team to include all of the required regulations.

Lý do chi tiết (theo PMBOK 7th Ed., Principle 5: Stewardship & Principle 9: Leadership):

• Trong Agile, quy định bắt buộc là "must-have" requirements, không thể loại trừ khỏi MVP vì chúng liên quan đến tuân thủ pháp lý và rủi ro dự án. PM phải lãnh đạo đội ngũ để đạt sự cam kết (commitment) từ team, đảm bảo mọi người hiểu và ưu tiên chúng.
• Điều này phù hợp với Agile Manifesto (ưu tiên con người và tương tác) và Scrum Values (Commitment, Focus), giúp team tự nguyện điều chỉnh backlog để bao gồm regulations mà không làm gián đoạn flow.
• Kết quả: MVP vẫn "minimum" nhưng an toàn và tuân thủ, tránh rework sau này.
  📘 Nguồn: PMBOK Guide 7th Edition (Section 4.5: Product Delivery), Agile Practice Guide (p. 45-47: MVP Definition & Compliance).

📋 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. Tôi giữ nguyên văn bản gốc tiếng Anh của phương án, đánh dấu ✅/❌, và giải thích hoàn toàn bằng tiếng Việt dựa trên nguyên tắc PMP Agile mới nhất.

• ❌ Ask the project sponsor to add more time to the project.
  Sai vì: Phương án này phụ thuộc vào sponsor để thay đổi thời gian, vi phạm nguyên tắc self-organizing team trong Agile (PMBOK 7th, Principle 10: Adaptation). Agile ưu tiên điều chỉnh nội bộ (như reprioritize backlog) thay vì mở rộng scope/time ngay lập tức. Điều này có thể làm chậm sprint và không giải quyết gốc rễ thiếu consensus.

• ✅ Get commitment from the team to include all of the required regulations.
  Đúng vì: Như đã giải thích ở trên, PM lãnh đạo để lấy cam kết từ team, đảm bảo tuân thủ bắt buộc trong MVP. Phù hợp Daily Scrum/Refinement để team tự nguyện include regulations vào Definition of Done (DoD). Tránh rủi ro pháp lý và duy trì velocity Agile.
  📘 Nguồn: Scrum Guide 2020 (Commitment Value), PMBOK 7th (Tool: Team Chartering).

• ❌ Share with the participants the need to focus only on product functionality.
  Sai vì: Tập trung chỉ vào chức năng sản phẩm (functionality) sẽ bỏ qua compliance, vi phạm Holistic Value Delivery (PMBOK 7th, Principle 2). Regulations không phải "nice-to-have" mà là rủi ro cao, dẫn đến dự án thất bại nếu vi phạm pháp lý. Agile yêu cầu cân bằng, không "only functionality".

• ❌ Train the team on the new regulations as requested by management.
  Sai vì: Đào tạo chỉ là hoạt động hỗ trợ, không giải quyết thiếu consensus để include vào MVP. Nó không đảm bảo team cam kết đưa vào product backlog, và "as requested by management" cho thấy PM đẩy từ trên xuống thay vì empower team (Agile Principle: Motivated individuals). Có thể tốn thời gian mà không thay đổi kết quả.
  📘 Nguồn: Agile Practice Guide (p. 62: Training vs. Commitment in Agile Teams).

🧠 Kết luận PMP: PM phải ưu tiên compliance như non-negotiable item trong MVP, sử dụng kỹ năng lãnh đạo để lấy consensus từ team. Điều này giúp dự án Agile thành công bền vững! 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 tập trung vào quy trình lập kế hoạch Sprint (Sprint Planning) trong phương pháp Agile/Scrum, một phần quan trọng của PMP theo PMBOK Guide 7th Edition (và cập nhật đến 2026 với Agile Hybrid approaches).

• Bối cảnh: Đội ngũ dự án vừa hoàn thành Sprint đầu tiên cho hệ thống payroll tự động. Project Manager (PM) tổ chức Sprint Planning meeting với Product Owner (PO) và thành viên đội để thảo luận tính năng nào sẽ làm tiếp theo (Sprint thứ 2).
• Mục tiêu câu hỏi: Xác định hai thông tin cần thiết (inputs) để cuộc họp hiệu quả và năng suất, giúp đội chọn features phù hợp từ backlog, định hướng mục tiêu Sprint, đảm bảo alignment với giá trị sản phẩm.
• Liên quan PMP: Theo Scrum Guide 2023 và PMBOK 7th (Principle 3: Focus on Value, Agile Practice), Sprint Planning cần inputs chính từ Product Backlog (prioritized items) và định hướng Sprint Goal để tạo Sprint Backlog. Cuộc họp này thường kéo dài 4-8 giờ, tập trung "What" (features) và "How" (plan).

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

Sprint goal và Product backlog.

Lý do lựa chọn:
🛠️ Product backlog là danh sách các tính năng/user stories được PO ưu tiên (prioritized), là nguồn chính để đội chọn items cho Sprint mới, đảm bảo giá trị cao nhất. Không có nó, không thể thảo luận "features nào next".
🛠️ Sprint goal cung cấp mục tiêu rõ ràng, ngắn gọn cho Sprint (SMART: Specific, Measurable,...), giúp đội align và quyết định features phù hợp, tránh scope creep. Dù Sprint Goal thường được tinh chỉnh trong meeting, nó cần được thảo luận từ đầu để productive.
Hai yếu tố này làm cuộc họp hiệu quả: Chọn items từ Backlog để đạt Goal, tạo output Sprint Backlog.

📋 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 tiếng Anh, đánh dấu đúng/sai và giải thích bằng tiếng Việt:

• ❌ Company mission and vision
  Phương án này sai vì mission/vision là tầm nhìn chiến lược cấp cao của công ty (từ Project Charter), không phải input trực tiếp cho Sprint Planning. Chúng ảnh hưởng gián tiếp đến Product Vision/Goal, nhưng không giúp thảo luận cụ thể "features next" trong Sprint ngắn hạn (2-4 tuần). Sử dụng sẽ làm họp lan man, mất focus.

• ✅ Sprint goal
  Phương án này đúng vì Sprint Goal là mục tiêu cốt lõi của Sprint (một câu ngắn gọn định hướng giá trị), cần thảo luận ngay đầu meeting để đội chọn features phù hợp từ Backlog. Theo Scrum, nó đảm bảo đội hiểu "tại sao" làm features đó, tăng productivity và alignment.

• ❌ Sprint charter
  Phương án này sai vì không tồn tại "Sprint charter" trong Scrum/Agile (chỉ có Project Charter ở cấp dự án). Sprint được định nghĩa bằng Goal + Backlog, không cần charter riêng. Nếu dùng, sẽ confuse và không hỗ trợ chọn features hiệu quả.

• ✅ Product backlog
  Phương án này đúng vì đây là input chính (prioritized list của PO), chứa tất cả features/user stories có thể làm. Đội xem xét top items để pull vào Sprint, đảm bảo họp productive bằng cách focus vào high-value work.

• ❌ Burndown chart
  Phương án này sai vì Burndown chart là tool theo dõi tiến độ Sprint hiện tại (daily/iteration), dùng trong Sprint Review/Retrospective hoặc Daily Scrum. Sau Sprint 1 hoàn thành, nó hữu ích cho lesson learned, nhưng không cần cho planning Sprint mới (chọn features next).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật Agile đến 2026): Section 4.5 Develop Team & 6.4 Manage Project Changes; Agile Hybrid: Inputs cho Sprint Planning (Product Backlog, Capacity).
• Scrum Guide 2020/2023 (Scrum.org): "Sprint Planning" events – Inputs: Product Backlog; Outputs: Sprint Goal, Sprint Backlog.
• PMP Exam Content Outline (PMI, 2024): Domain III: Business Environment (Agile); Domain IV: Delivery (Sprint ceremonies).
• Thực hành tốt nhất: Agile Practice Guide (PMI Companion to PMBOK 7th).

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 câu hỏi, 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ủ đề Hybrid Approaches trong PMP (kết hợp Predictive và Agile), theo PMBOK Guide 7th Edition và Agile Practice Guide (cập nhật đến 2023, vẫn áp dụng đến 2026).

• Bối cảnh dự án: Quản lý dự án (PM) chịu trách nhiệm xây dựng một cây cầu (bridge). Các yếu tố cấp cao (high-level elements) được xử lý bằng phương pháp Predictive (tiếp cận truyền thống, lập kế hoạch chi tiết từ đầu, phù hợp với xây dựng cầu cần độ ổn định cao).
• Phần Agile: Phần phần mềm điều khiển cầu rút (retracting the bridge) được phát triển theo nguyên tắc Agile (linh hoạt, lặp lại).
• Vấn đề chính: Trong quá trình phát triển phần mềm, luồng công việc (workflow) thường bị gián đoạn bởi các trì hoãn hoặc trở ngại (delays/impediments) do thiếu thông tin (lack of information).
• Mục tiêu: PM cần xử lý tình huống này để cải thiện flow, giảm impediments – một thách thức phổ biến trong môi trường Hybrid/Agile.

🛠️ Mục đích câu hỏi: Kiểm tra kiến thức về công cụ Agile giúp làm rõ ràng công việc (make work visible) và xác định trở ngại nhanh chóng, đặc biệt trong Kanban – phương pháp lý tưởng cho workflow liên tục bị gián đoạn.

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

Đáp án đúng: Make work visible using Kanban boards.

Lý do chi tiết (theo PMBOK 7th Ed., Principle 5: Optimize Flow & Agile Practice Guide):

• Trong Agile/Kanban, Kanban boards (bảng Kanban) là công cụ trực quan hóa công việc (visualize work), giúp hiển thị toàn bộ workflow (To Do → In Progress → Done), làm rõ bottlenecks và impediments do thiếu thông tin.
• Điều này cho phép đội ngũ nhanh chóng xác định và giải quyết delays (ví dụ: ai đang block thông tin?), cải thiện flow mà không thay đổi cấu trúc dự án Hybrid.
• Phù hợp hoàn hảo với tình huống: Workflow Agile bị gián đoạn → Visualize để "pull" thông tin kịp thời, tăng transparency. Không cần thay đổi lớn như tăng retrospective hay áp dụng Lean toàn bộ.

📋 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 tiếng Anh, kèm giải thích sai/đúng bằng tiếng Việt dựa trên PMP mới nhất:

• Increase retrospectives to deliver results fast.
  ❌ Sai. Retrospective (hồi cứu) chỉ diễn ra cuối sprint/iteration để cải thiện quy trình dài hạn, không giải quyết impediments tức thời trong workflow hàng ngày. Tăng số lượng chỉ làm mệt đội ngũ, không làm rõ thông tin ngay lập tức (theo Agile Practice Guide: Retrospectives ≠ Daily Issue Resolution).

• Make work visible using Kanban boards.
  ✅ Đúng. Như đã giải thích: Kanban boards trực quan hóa work-in-progress (WIP), giúp phát hiện delays do thiếu info ngay lập tức, tối ưu flow trong Agile/Hybrid (PMBOK 7th: Tools for Flow Optimization).

• Incorporate small batches of work into the project.
  ❌ Sai. Small batches (lô nhỏ) giúp giảm risk và tăng feedback trong Agile, nhưng không trực tiếp giải quyết impediments do thiếu thông tin. Nó chỉ là kỹ thuật chung, không visualize workflow để fix delays (Scrum Guide: Batches hỗ trợ, nhưng cần visibility trước).

• Apply lean manufacturing to limit the team's work.
  ❌ Sai. Lean (giảm lãng phí) dùng WIP limits để giới hạn công việc, nhưng lean manufacturing là khái niệm sản xuất truyền thống, không phải Agile thuần túy. Áp dụng có thể overload đội ngũ thay vì fix lack of information; PMP ưu tiên Kanban trước Lean cho visualize (Lean-Agile chỉ là bổ sung, theo SAFe/PMBOK).

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021): Chương Hybrid Life Cycles & Principle 5 (Optimize Flow) – Nhấn mạnh visualization trong Agile tools.
• Agile Practice Guide (PMI, 2017-2023): Phần Kanban Practices – Visualize work để manage impediments.
• PMI Standards đến 2026: Không thay đổi cốt lõi Hybrid/Agile; cập nhật từ PMI.org (Project Management Body of Knowledge).

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