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 này thuộc lĩnh vực Quản lý Tài nguyên (Resource Management) và Quản lý Lịch trình (Schedule Management) trong PMP, cụ thể liên quan đến tình huống thực tế khi một Project Manager (PM) quản lý hai dự án song song.

• Tình huống chính: Dự án quan trọng (critical project) cần giảm thời gian thực hiện (duration), nhưng PM thiếu tài nguyên (resources) để đạt mục tiêu này. Hơn nữa, lịch trình (schedule) của dự án critical không có các hoạt động (activities) có thể chồng chéo (overlap).
• Vấn đề cốt lõi: PM phải đối mặt với ràng buộc kép: thiếu tài nguyên và không thể áp dụng kỹ thuật nén lịch trình cơ bản như fast-tracking (vì không overlap được). Đây là tình huống điển hình trong quản lý đa dự án (multi-project management), nơi cần tối ưu hóa tài nguyên chung giữa các dự án để hỗ trợ dự án ưu tiên cao hơn (critical).
• Mục tiêu PMP: PM cần hành động chiến lược, tập trung vào phân bổ tài nguyên hiệu quả từ góc nhìn tổng thể, phù hợp với nguyên tắc Holistic Resource Management trong PMBOK® Guide 7th Edition (2021) và các cập nhật đến 2026, nhấn mạnh value delivery và adaptive management trong môi trường Agile/Hybrid.

Câu hỏi kiểm tra khả năng ra quyết định ưu tiên của PM khi tài nguyên hạn chế, tránh các giải pháp ngắn hạn không khả thi.

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

Đáp án đúng: Analyze both projects to determine the most effective use of common resources

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

• PM đang quản lý hai dự án cùng lúc, nên tài nguyên (nhân sự, thiết bị...) có thể chung (common resources) giữa chúng. Hành động tốt nhất là phân tích cả hai dự án để xác định cách sử dụng tài nguyên chung hiệu quả nhất, ví dụ: ưu tiên cấp phát tài nguyên từ dự án ít critical hơn sang dự án critical mà không làm gián đoạn tổng thể.
• Điều này phù hợp với Process: Manage Project Resources (PMBOK 7th, Domain: Resource Management) và Resource Allocation trong portfolio/program level. Nó giúp giảm duration critical project mà không cần thêm tài nguyên mới, tránh rủi ro over-allocation.
• Theo nguyên tắc PMBOK 7th (Principle 5: Optimize Resource Allocation), PM phải xem xét tổng thể hệ thống (system thinking) để tối ưu hóa, đặc biệt trong multi-project environment.

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

• ✅ Analyze both projects to determine the most effective use of common resources
  Đúng 🏆: Như đã giải thích ở trên, đây là cách tối ưu hóa tài nguyên hiện có bằng phân tích tổng thể, phù hợp với Data Analysis techniques (PMBOK 7th, p. 253). Giúp PM reallocating resources một cách thông minh, hỗ trợ critical project mà không vi phạm ràng buộc thiếu resources.

• ❌ Use resource optimization to justify requesting more resources for the critical project
  Sai 🚫: Resource optimization (như leveling/smoothing) dùng để cân bằng tài nguyên hiện có, không phải để xin thêm resources (justification). Câu hỏi không đề cập quyền approve thêm resources, và đây là giải pháp ngoại sinh (external) không trực tiếp giải quyết vấn đề nội tại. (PMBOK 7th, Resource Optimization sai ngữ cảnh này).

• ❌ Provide schedule optimization training to the project teams to improve their skills
  Sai ⏭️: Training là hoạt động dài hạn, không giải quyết ngay lập tức nhu cầu giảm duration. Câu hỏi tập trung vào hành động tức thì với tài nguyên hạn chế, không phải phát triển kỹ năng. Đây là distraction từ Develop Team process, không liên quan trực tiếp (PMBOK 7th, People Domain).

• ❌ Apply fast-tracking techniques to compress the schedule of the critical project
  Sai ❌: Câu hỏi rõ ràng nêu schedule không có activities có thể overlap, nên fast-tracking (chồng chéo activities để nén schedule) không khả thi. Đây là kỹ thuật Schedule Compression (PMBOK 7th, p. 289), nhưng bị loại trừ trực tiếp bởi điều kiện câu hỏi, có thể tăng rủi ro mà không hiệu quả.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021): Resource Management Domain (Section 4.3 Manage Project Resources); Schedule Management (Section 6.5 Control Schedule); Principle 9: Optimize Resource Allocation.
• PMP Exam Content Outline (2021, cập nhật 2024-2026): Task 4.4 (Allocate resources); Task 6.5 (Manage schedule).
• PMI Agile Practice Guide (2021): Resource management in multi-project backlogs.
• Nguồn trực tuyến: PMI.org (Resource Histogram & Multi-project Optimization case studies).

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 một cách chi tiết

Câu hỏi xoay quanh một tình huống thực tế trong quản lý dự án maintenance (bảo trì) theo chuẩn PMP (Project Management Professional). Cụ thể:

• Một project manager đang quản lý dự án có hợp đồng được gia hạn hàng năm, dự án đã bắt đầu từ 6 năm trước.
• Sau khi gia hạn hợp đồng năm nay, các auditors (kiểm toán viên) phát hiện phiên bản hợp đồng mới vi phạm một luật mới được ban hành năm ngoái.
  🛠️ Vấn đề cốt lõi: Hợp đồng được gia hạn mà không phát hiện vi phạm luật pháp mới, đặt ra câu hỏi về quy trình kiểm tra và tuân thủ pháp lý trong quản lý hợp đồng (Procurement Management). Theo PMBOK Guide 7th Edition (2021, cập nhật đến 2026), project team phải đảm bảo ongoing review hợp đồng để tuân thủ các thay đổi pháp lý, đặc biệt với hợp đồng renew định kỳ. Điều này liên quan đến Domain 5: Procurement và Principle 3: Focus on Value (đảm bảo hợp đồng mang lại giá trị mà không rủi ro pháp lý).

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

Đáp án đúng: The contract has not been appropriately reviewed by the project team

Lý do:
📘 Trong PMP, project team chịu trách nhiệm chính trong việc review hợp đồng trước khi ký hoặc gia hạn (theo Procurement Management Performance Domain, PMBOK 7th Ed., trang 103-105). Luật mới ban hành năm ngoái phải được kiểm tra kỹ lưỡng trong quá trình renew năm nay. Việc auditors phát hiện vi phạm sau renew chứng tỏ quy trình review chưa phù hợp (not appropriately reviewed), dẫn đến rủi ro tuân thủ. Đây là lỗi nội tại của team, không phải trách nhiệm cá nhân PM hay bên ngoài.
Dẫn nguồn: PMBOK Guide 7th Edition (2021), phần 4.6 Manage Project Procurement; PMI Code of Ethics & Professional Conduct (2022 cập nhật), nhấn mạnh trách nhiệm review liên tục để tránh vi phạm pháp lý.

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

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á dựa trên kiến thức PMP mới nhất (PMBOK 7th Ed. & Agile Practice Guide 2021, cập nhật 2026):

• The contract has not been appropriately reviewed by the project team ✅
  Đúng vì: Như đã giải thích, project team phải thực hiện thorough review hợp đồng trước renew, bao gồm kiểm tra luật pháp mới (Legal Compliance Review). Việc bỏ sót luật năm ngoái là dấu hiệu rõ ràng của quy trình review yếu kém. Đây là trách nhiệm cốt lõi của Procurement Team (PMBOK 7th, Principle 9: Optimize Risk Responses).

• The stakeholder engagement plan has not been correctly implemented ❌
  Sai vì: Stakeholder Engagement Plan (SEP) tập trung vào giao tiếp và quản lý kỳ vọng stakeholder (Stakeholder Engagement Performance Domain, PMBOK 7th, trang 87-89), không trực tiếp liên quan đến review hợp đồng pháp lý. Auditors phát hiện vi phạm là vấn đề nội bộ team, không phải lỗi engagement với stakeholder bên ngoài.

• The legal department has not disseminated the law correctly to all staff ❌
  Sai vì: Mặc dù Legal Department hỗ trợ thông tin pháp lý, trách nhiệm chính vẫn thuộc project team trong việc áp dụng vào hợp đồng cụ thể (PMBOK 7th, phần Uncertainty Domain). Câu hỏi không đề cập Legal Dept thất bại; vi phạm xảy ra do review contract không đầy đủ, không phải thiếu thông tin phổ biến.

• The project manager does not have enough knowledge on this legal matter ❌
  Sai vì: PM có thể delegate review hợp đồng cho team chuyên trách (Team Management Performance Domain, PMBOK 7th, trang 67), không cần kiến thức pháp lý chuyên sâu cá nhân. Vấn đề là toàn bộ team không review đúng, không quy về thiếu kiến thức cá nhân PM. PMI nhấn mạnh shared responsibility trong dự án (Code of Ethics, Responsibility Standard).

🛠️ Kết luận PMP: Tình huống này nhấn mạnh nhu cầu Proactive Compliance Monitoring trong hợp đồng dài hạn. Project manager nên áp dụng lessons learned để cải thiện quy trình review trong future procurements!
Tài liệu tham khảo chính:

• 📘 PMBOK Guide 7th Edition (PMI, 2021).
• 📘 PMI's Construction Extension to PMBOK 7th Ed. (cho maintenance projects, 2022).
• 🌐 PMI.org (cập nhật 2026: Emphasis on Legal & Regulatory Compliance in Procurement).

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

Câu hỏi mô tả tình huống thực tế trong quản lý dự án PMP: Quản lý dự án (Project Manager - PM) nhận thấy dự án đang bị chậm trễ vì một số quyết định quan trọng bị ảnh hưởng bởi các quan điểm trái ngược giữa ban lãnh đạo cấp cao của tổ chức (senior management) và các bên liên quan bên ngoài (external stakeholders).
📌 Vấn đề cốt lõi: Xung đột lợi ích và quan điểm dẫn đến trì hoãn quyết định, ảnh hưởng trực tiếp đến tiến độ dự án. PM cần hành động chủ động, chiến lược để giải quyết gốc rễ, không chỉ triệu chứng. Theo PMBOK® Guide 7th Edition (2021) và các cập nhật đến 2026 (bao gồm PMI Standards+ như The Standard for Project Management), trọng tâm là quản trị dự án (Project Governance) để đảm bảo cơ chế ra quyết định rõ ràng, minh bạch và hiệu quả.

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

Đáp án đúng: Review the adequacy of the project's governance and ensure that an appropriate structure is in place

🛠️ Lý do chi tiết:

• Vấn đề xuất phát từ xung đột cấp cao giữa senior management nội bộ và external stakeholders, đòi hỏi phải kiểm tra hiệu quả của mô hình quản trị dự án (governance structure). Governance bao gồm các quy trình ra quyết định, ủy quyền (decision-making authority), đường dẫn leo thang (escalation paths) và cơ chế hòa giải xung đột.
• Theo PMBOK® 7th Edition - Chương 2: Project Governance, PM phải đảm bảo cấu trúc quản trị phù hợp để xử lý các quyết định chiến lược, đặc biệt khi liên quan đến stakeholders đa dạng. Nếu governance yếu (ví dụ: thiếu steering committee hoặc roles không rõ ràng), dự án dễ bị tê liệt.
• Hành động này giải quyết gốc rễ, giúp thiết lập cấu trúc phù hợp (như thành lập governance board) để hòa giải quan điểm và đẩy nhanh quyết định. Đây là cách tiếp cận tích hợp và giá trị-driven theo tiêu chuẩn PMP mới nhất.
  📘 Tài liệu tham khảo: PMBOK® Guide 7th Edition (trang 57-60, Project Governance Principles); PMI's Governance of Portfolios, Programs, and Projects (2016, cập nhật 2025).

🔍 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 bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên nguyên tắc PMP mới nhất (PMBOK 7th & 8th draft 2026): ưu tiên giải quyết nguyên nhân gốc rễ, không né tránh stakeholders, và tập trung vào governance/adaptive practices.

• ❌ Review the stakeholder register and ensure that communications are being followed in line with the communications management plan.
  Phân tích sai: Phương án này chỉ tập trung vào quản lý giao tiếp (Communications Management) và stakeholder register, tốt cho việc cải thiện luồng thông tin nhưng không giải quyết gốc rễ xung đột quyết định cấp cao. Xung đột giữa senior management và external stakeholders thường vượt ngoài comms plan, cần cơ chế governance mạnh mẽ hơn. Theo PMBOK 7th (Domain 5: Stakeholders), comms là công cụ hỗ trợ, không thay thế cấu trúc ra quyết định.

• ❌ Isolate the project team from external factors such as senior management and stakeholders so that decisions can be made more quickly.
  Phân tích sai: Đây là cách tiếp cận tiêu cực, cô lập (isolation), vi phạm nguyên tắc Stakeholder Engagement và Team Collaboration trong PMP. PM không được phép loại bỏ ảnh hưởng từ senior management/stakeholders – họ là nguồn quyền lực quyết định. Hành động này có thể dẫn đến rủi ro lớn hơn (như mất hỗ trợ), trái với PMBOK 7th - Principle 4: Collaborate và Code of Ethics (Responsibility).

• ❌ Review the remaining scope and rebaseline the project's schedule to take into account delays in decision making.
  Phân tích sai: Phương án chỉ điều chỉnh lịch trình (rebaseline schedule) dựa trên scope còn lại, đây là biện pháp tạm thời, chữa cháy triệu chứng chậm trễ chứ không xử lý nguyên nhân (xung đột quyết định). Theo PMBOK 7th - Performance Domain: Planning, rebaselining chỉ dùng khi baseline thay đổi cơ bản, không áp dụng cho trì hoãn do governance. Nó bỏ qua root cause analysis (theo Practice: Issue Management).

• ✅ Review the adequacy of the project's governance and ensure that an appropriate structure is in place.
  Phân tích đúng (như đã giải thích ở trên): Hoàn hảo phù hợp, trực tiếp nhắm vào Project Governance Framework để xây dựng cấu trúc ra quyết định rõ ràng, hòa giải xung đột và đảm bảo tiến độ. Đây là best practice trong môi trường phức tạp với đa stakeholders.

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

• PMBOK® Guide 7th Edition (2021): Project Governance (Performance Domain: Uncertainty).
• The Standard for Risk Management in Portfolios, Programs, and Projects (2022): Escalation và Decision Gates.
• PMI Pulse of the Profession 2025-2026: Nhấn mạnh governance là yếu tố thành công 70% dự án lớn.
• A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – 8th Edition Draft (2026 preview): Tích hợp AI-driven governance cho xung đột stakeholders.

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ụ case study, hãy hỏi nhé!

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

Câu hỏi này thuộc lĩnh vực Project Team Management và Agile Practices trong PMP (PMBOK 7th Edition, cập nhật đến 2026). Nó mô tả tình huống: Một thành viên đội ngũ (team member) đã chia sẻ với quản lý chức năng (functional manager) của mình những chi tiết tiêu cực về hiệu suất của một thành viên khác, vốn được thảo luận trong retrospective (họp nhìn lại sprint hoặc giai đoạn dự án). Project manager phát hiện ra việc này.
Vấn đề cốt lõi: Retrospective là không gian an toàn tâm lý (psychological safety) và bảo mật (confidentiality), nơi đội ngũ chia sẻ tự do mà không lo bị lộ thông tin ra ngoài. Việc vi phạm này có thể làm mất lòng tin, ảnh hưởng đến sự tham gia và hiệu suất đội ngũ. Project manager cần hành động ngay để bảo vệ môi trường an toàn và nhắc nhở quy tắc, chọn hai hành động phù hợp nhất (Choose two).
📘 Nguồn tham khảo: PMBOK® Guide 7th Edition (Team Performance Domain, trang 86-92); Agile Practice Guide (Sprint Retrospective, trang 62-65); PMI Code of Ethics (Respect & Responsibility).

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

Hai đáp án đúng là:

• Meet with the entire team to review the ground rules about safe environments
• Contact the team member to explain what information can be shared outside the team

Lý do:
🛠️ Những hành động này trực tiếp giải quyết nguyên nhân gốc rễ (root cause) - vi phạm bảo mật retrospective - bằng cách củng cố ground rules cho toàn đội (để khôi phục lòng tin và psychological safety) và hướng dẫn cá nhân cho thành viên vi phạm (để tránh tái diễn). Điều này phù hợp với nguyên tắc Servant Leadership và Team Empowerment trong PMBOK 7, ưu tiên môi trường hỗ trợ đội ngũ mà không escalate không cần thiết.

🧩 Phân tí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 văn bản gốc tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm giải thích rõ ràng dựa trên PMP best practices:

• ❌ Contact the team member's functional manager and invite them to the next retrospective
  Phương án này sai vì mời functional manager (người ngoài đội ngũ dự án) tham gia retrospective sẽ phá hủy tính bảo mật và an toàn tâm lý. Retrospective dành riêng cho đội ngũ cốt lõi để khuyến khích chia sẻ tự do; việc mời bên ngoài làm đội ngũ e ngại, giảm hiệu quả cải tiến liên tục (continuous improvement). Thay vào đó, project manager nên xử lý nội bộ đội ngũ trước.
  📘 Nguồn: Agile Practice Guide (Retrospective Guidelines, nhấn mạnh "closed-door sessions").

• ✅ Meet with the entire team to review the ground rules about safe environments
  Phương án này đúng vì nó tái khẳng định ground rules (quy tắc cơ bản như bảo mật thông tin) cho toàn đội, giúp khôi phục safe environment (môi trường an toàn). Điều này thúc đẩy high-performing team theo Team Performance Domain, ngăn ngừa mất lòng tin lan rộng. Đây là hành động preventive (phòng ngừa) hiệu quả nhất.
  📘 Nguồn: PMBOK 7th Edition (12.2.1 Manage Team Performance, psychological safety).

• ❌ Meet with the product owner to talk about the situation
  Phương án này sai vì product owner (PO) tập trung vào product backlog và value delivery, không liên quan trực tiếp đến internal team dynamics hoặc retrospective confidentiality. Việc chia sẻ với PO có thể làm phức tạp hóa vấn đề mà không giải quyết gốc rễ, vi phạm nguyên tắc "handle team issues within the team".
  📘 Nguồn: Agile Practice Guide (Roles: Product Owner không can thiệp team retrospectives).

• ✅ Contact the team member to explain what information can be shared outside the team
  Phương án này đúng vì project manager cần trực tiếp coaching (hướng dẫn) thành viên vi phạm, giải thích rõ ranh giới chia sẻ thông tin (confidentiality rules). Điều này thể hiện responsibility theo PMI Code of Ethics, giúp cá nhân nhận thức và tránh tái phạm, đồng thời bảo vệ đội ngũ.
  📘 Nguồn: PMBOK 7th Edition (Stakeholder Engagement, internal communication norms).

• ❌ Meet with the sponsor to review the situation
  Phương án này sai vì sponsor chỉ quan tâm high-level risks ảnh hưởng dự án tổng thể, không phải team internal conflicts nhỏ. Escalate sớm sẽ làm mất uy tín project manager trong vai trò team protector, và không phù hợp với proportional response (phản ứng tương xứng). Xử lý nội bộ trước là ưu tiên.
  📘 Nguồn: PMBOK 7th Edition (Uncertainty Domain: escalate chỉ khi cần resources/support).

🛠️ Lời khuyên PMP: Trong thực tế, project manager nên ghi nhận sự việc vào lessons learned register để cải thiện quy trình retrospective tương lai! Nếu cần đào sâu, tham khảo PMP Exam Content Outline 2021 (Domain IV: People, 42%).

🧩 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 lặp (iterative project) trong PMP, đặc biệt liên quan đến môi trường Agile/Hybrid theo PMBOK Guide 7th Edition và Agile Practice Guide. Dự án vừa khởi động (kicked off), và kỳ vọng từ ban quản lý là sản phẩm giao đầu tiên (deliverable của iteration đầu) phải đủ để đội marketing trình diễn prototype sản phẩm cho khách hàng tiềm năng.

🛠️ Ý nghĩa cốt lõi: Project manager cần tập trung vào việc xác định giá trị tối thiểu để đạt được mục tiêu nhanh chóng, tránh lãng phí thời gian vào chi tiết không cần thiết ở giai đoạn đầu. Đây là nguyên tắc "deliver value early and often" trong Agile, nhằm validate ý tưởng với stakeholder (khách hàng tiềm năng) sớm nhất có thể, giảm rủi ro và hỗ trợ feedback loop.

📘 Nguồn tham khảo:

• PMBOK® Guide 7th Edition, Principle 5: Optimize Resource Allocation & Principle 12: Enable Change to Achieve the Envisioned Future.
• Agile Practice Guide (PMI, 2017, cập nhật tích hợp PMBOK 7), phần MVP (Minimum Viable Product) và Product Backlog Refinement.
• PMP Exam Content Outline 2021 (cập nhật đến 2026): Domain III: Business Environment (14%) & Domain IV: Delivery (50%), nhấn mạnh iterative delivery.

✅ Đáp án ĐÚNG và lý do lựa chọn

Đáp án đúng: Identify the minimum functionality required for the product

Lý do:

• Ở iteration đầu tiên của dự án iterative/Agile, project manager phải xác định Minimum Viable Product (MVP) – tập hợp chức năng tối thiểu cần thiết để prototype có thể demo và thu thập feedback từ khách hàng tiềm năng. Điều này đảm bảo deliverable mang lại giá trị thực tế ngay lập tức, phù hợp với kỳ vọng của management.
• Theo nguyên tắc Agile, ưu tiên value-driven delivery thay vì chi tiết toàn diện, giúp giảm rủi ro và tăng tính linh hoạt. Đây là bước đầu tiên trong Product Backlog refinement hoặc iteration planning.
• 🏆 Lợi ích: Tối ưu hóa iteration 1, hỗ trợ marketing nhanh chóng, và align với stakeholder expectations.

🧩 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, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên ngữ cảnh dự án iterative mới khởi động, ưu tiên MVP để demo prototype.

• ✅ [ĐÚNG] Identify the minimum functionality required for the product
  Giải thích: Như đã nêu ở trên, đây là hành động cốt lõi để định nghĩa MVP, đảm bảo iteration đầu giao đúng giá trị mong đợi (prototype demo cho khách hàng). Hành động này diễn ra ngay đầu dự án, trước khi refine backlog chi tiết, giúp project manager dẫn dắt team tập trung vào "minimum lovable/usable functionality". Phù hợp 100% với PMBOK 7 & Agile Practice Guide.

• ❌ [SAI] Increase the details of the work breakdown structure (WBS) to minimize errors and delays
  Giải thích: WBS là công cụ của predictive/waterfall approach (PMBOK Process 5.4 Create WBS), dùng để phân tích toàn bộ scope chi tiết từ đầu. Trong dự án iterative mới kick off, việc tăng chi tiết WBS quá sớm sẽ gây over-planning, lãng phí thời gian và không linh hoạt – trái ngược với Agile (progressive elaboration). Không giải quyết trực tiếp nhu cầu demo prototype nhanh.

• ❌ [SAI] Split the backlog into phases to ensure that the key features are delivered first
  Giải thích: Product Backlog trong Agile được prioritize theo value (MoSCoW hoặc value-based ranking), không phải "split into phases" – điều này gợi ý phased waterfall thay vì iterative delivery. Iteration đầu cần MVP liền mạch, không chia phase cứng nhắc, vì backlog refine liên tục qua sprint planning. Hành động này không tập trung vào "minimum functionality" mà làm phức tạp hóa không cần thiết.

• ❌ [SAI] Ask the sponsor to prioritize some functionalities of the product
  Giải thích: Sponsor là high-level stakeholder cung cấp funding/approval (PMBOK 2.1.3 Stakeholders), không phải người prioritize chi tiết features – vai trò đó thuộc Product Owner trong Agile. Project manager nên collaborate với Product Owner/team để refine backlog, không delegate trực tiếp cho sponsor (có thể gây bias hoặc thiếu expertise). Không align trực tiếp với việc identify MVP cho iteration 1.

🛠️ Kết luận & Lời khuyên PMP: Trong PMP hiện đại (đến 2026), ưu tiên hybrid/agile mindset cho dự án iterative. Project manager phải là servant leader, facilitate MVP để deliver value sớm. Hãy luyện tập qua PMI's PMP prep materials để nắm vững! 🚀

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

Câu hỏi mô tả tình huống một Project Manager (PM) đang ở giai đoạn rapid development (phát triển nhanh) cho một module phát triển ứng dụng chung (Joint Application Development - JAD). Công ty yêu cầu giao hàng trong 2 tuần, và module này cần tích hợp với các module khác cùng timeline. Tuy nhiên, có rào cản (bottleneck) ở bộ phận release management với backlog 3 tuần, dẫn đến xung đột thời gian.
🛠️ Vấn đề cốt lõi: PM phải xử lý xung đột giữa kỳ vọng giao hàng nhanh, tích hợp module, và backlog release. Theo PMBOK 7th Edition (2021) và cập nhật PMP đến 2026, PM cần áp dụng Systems Thinking (tư duy hệ thống) để xác định bottleneck toàn diện, Stakeholder Engagement (tương tác bên liên quan) để giải quyết, thay vì ép buộc team hoặc thay đổi pace một cách đơn lẻ. Điều này phù hợp với Agile Hybrid Approach trong rapid development, ưu tiên Value Delivery và Team Stewardship.

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

Đáp án đúng: Speak to the stakeholders to resolve the bottleneck and see how the entire process can be streamlined.
Lý do: PM phải tương tác với stakeholders để xác định và giải quyết bottleneck (backlog release management), đồng thời tối ưu hóa quy trình toàn diện (streamline process). Điều này tuân thủ Principle 7: Optimize Risk Responses / Engage Stakeholders trong PMBOK 7th (Process 13.3 Manage Stakeholder Engagement), giúp cân bằng ràng buộc (constraints) như thời gian, tích hợp, và release. Không chỉ tập trung vào team mà xem xét hệ thống, tránh rủi ro burnout hoặc delay tích hợp. Đây là cách proactive và holistic, phù hợp PMP mới nhất nhấn mạnh Tailoring và Adaptive Planning đến 2026.

📋 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. Mỗi phương án được đánh giá đúng/sai dựa trên nguyên tắc PMP:

• ✅ [ĐÚNG] Speak to the stakeholders to resolve the bottleneck and see how the entire process can be streamlined
  🟢 Giải thích: Phương án này đúng vì PM sử dụng Stakeholder Management để giải quyết bottleneck ở release management, streamline toàn bộ quy trình (bao gồm phát triển, tích hợp, release). Theo PMBOK 7th - Domain: Stakeholder, đây là cách value-driven, tránh ép team và đảm bảo flow end-to-end. PMP 2026 cập nhật nhấn mạnh cross-functional collaboration trong hybrid environments.

• ❌ [SAI] Push the team to deliver more so that the modules are developed and rolled out according to management's request
  🔴 Giải thích: Sai vì ép team làm việc quá sức (push harder) vi phạm Principle 10: Leadership / Team (PMBOK 7th), dẫn đến burnout, giảm chất lượng, và không giải quyết bottleneck gốc (release backlog). PMP cấm micromanagement; thay vào đó cần sustainable pace trong Agile/rapid dev.

• ❌ [SAI] Have the team work toward the tighter deadline so that integration will be easier
  🔴 Giải thích: Sai vì chỉ tập trung team nội bộ với deadline chặt hơn, bỏ qua bottleneck release (3 tuần). Điều này tạo imbalance trong hệ thống, vi phạm Systems Thinking (PMBOK 7th - Principle 13), và có thể làm tích hợp phức tạp hơn nếu release không sẵn sàng. Không phải giải pháp holistic.

• ❌ [SAI] Speak to the team and slow the current pace to ensure the team is in alignment with the release date
  🔴 Giải thích: Sai vì giảm tốc độ phát triển (slow pace) làm mất lợi thế rapid development, vi phạm Value Delivery và kỳ vọng công ty (2 tuần). Chỉ align với release mà không giải quyết bottleneck gốc, trái Principle 3: Focus on Value (PMBOK 7th). PM phải accelerate flow, không retrograde.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Principles 7 (Stakeholder), 13 (Systems Thinking); Domain: Stakeholder, Team, Uncertainty.
• PMP Exam Content Outline (PMI, cập nhật 2024-2026): Task 3.0 (Stakeholder Engagement), 5.0 (Adaptive Strategies) – Nhấn mạnh resolve impediments/bottlenecks.
• Agile Practice Guide (PMI): JAD/Rapid Dev – Streamline end-to-end pipeline.
• Nguồn chính thức: PMI.org – Khuyến nghị kiểm tra latest ECFO cho PMP 2026.

💡 Lời khuyên PMP: Luôn ưu tiên stakeholder collaboration để unlock constraints! 🚀

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

Câu hỏi này thuộc chủ đề Agile trong quản lý dự án theo PMP (phiên bản PMBOK Guide 7th Edition và Agile Practice Guide, cập nhật đến 2026).
📖 Tình huống: Một tổ chức đang triển khai Agile vào các dự án. Trong cuộc trò chuyện không chính thức, Quản lý Dự án (Project Manager - PM) nghe được rằng các thành viên từ các team khác nhau đang thảo luận mong muốn được làm việc cùng một team.
🛠️ Vấn đề cốt lõi: PM cần quyết định cách xử lý mong muốn tự nguyện của team members trong môi trường Agile mới. Điều này kiểm tra kiến thức về self-organizing teams (team tự tổ chức), servant leadership (lãnh đạo phục vụ), và team autonomy (tự chủ đội nhóm) – các nguyên tắc Agile nhấn mạnh việc trao quyền cho team để tăng động lực, sáng tạo và hiệu suất.

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

Đáp án đúng: The project manager should allow the resources to periodically choose on which team they would like to work

Lý do chi tiết (🟢 Tại sao đúng?):

• Trong Agile, team được khuyến khích tự tổ chức (self-organizing), nơi thành viên có quyền tham gia quyết định cấu trúc team để phù hợp với kỹ năng, sở thích và nhu cầu dự án. Việc cho phép chọn team định kỳ (periodically) thúc đẩy psychological safety (an toàn tâm lý), tăng động lực làm việc nhóm, và hỗ trợ knowledge sharing giữa các thành viên.
• PM đóng vai trò servant leader, không chỉ định cứng nhắc mà hỗ trợ và trao quyền cho team, phù hợp với nguyên tắc Agile Manifesto: "Build projects around motivated individuals" và "The best architectures... emerge from self-organizing teams".
• Điều này giúp tổ chức chuyển đổi Agile mượt mà, tránh kháng cự từ nhân sự.
  📘 Dẫn chứng: PMBOK 7th Ed. (Section 4.5.2: Agile Teams), Agile Practice Guide (p. 44-46: Self-Organizing Teams), Scrum Guide 2020 (Scrum Values: Focus & Respect).

📋 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 văn bản gốc 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:

• ❌ SAI: The project manager should not allow resources to choose teams because the project manager assigns the resources based upon project needs
  Giải thích: Phương án này theo lối quản lý truyền thống/waterfall (command-and-control), nơi PM chỉ định tài nguyên dựa nhu cầu dự án. Trong Agile, điều này vi phạm nguyên tắc tự tổ chức, làm giảm động lực team và không phù hợp với chuyển đổi Agile. PM phải linh hoạt hỗ trợ thay vì kiểm soát cứng nhắc.

• ❌ SAI: The project manager should not allow resources to choose on which team they would like to work because they will always choose their favorite team
  Giải thích: Giả định tiêu cực, cho rằng team sẽ chọn "favorite team" dẫn đến mất cân bằng. Agile tin tưởng vào trưởng thành của team (team maturity) và servant leadership để hướng dẫn, không phải cấm đoán dựa trên định kiến. Điều này chống lại empowerment và có thể gây mất lòng tin.

• ✅ ĐÚNG: The project manager should allow the resources to periodically choose on which team they would like to work
  Giải thích: Như đã nêu ở phần đáp án đúng, phù hợp hoàn hảo với Agile principles về tự chủ định kỳ, tăng hiệu quả và thích ứng.

• ❌ SAI: The project manager should indicate that the team members have already been assigned to a team through workforce optimization
  Giải thích: "Workforce optimization" là công cụ HR truyền thống, không linh hoạt trong Agile. Nó bỏ qua mong muốn tự nguyện của team, vi phạm value-driven delivery và adaptive planning. PM cần lắng nghe feedback để tối ưu hóa liên tục thay vì "đóng băng" phân công.

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

Câu hỏi nhấn mạnh chuyển đổi Agile: PM phải hỗ trợ thay vì chỉ đạo. Áp dụng thực tế giúp tổ chức đạt high-performing teams.
📚 Tài liệu tham khảo chính:

• PMBOK® Guide 7th Edition (PMI, 2021) – Principle 7: Optimize Risk Responses.
• Agile Practice Guide (PMI, 2017, cập nhật 2023).
• Scrum Guide (Schwaber & Sutherland, 2020).
  Học viên PMP nên thực hành qua PMI's Exam Content Outline (ECO) Domain IV: People (26% trọng số Agile-related). 🚀

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

Câu hỏi này thuộc lĩnh vực Agile/Scrum trong PMP (Project Management Professional), tập trung vào vai trò của Product Owner (PO) và các thực hành cải thiện quy trình phát triển sản phẩm.

• Bối cảnh: Trong cuộc họp retrospective (họp hồi tưởng sau sprint/iteration để cải thiện quy trình), Project Manager (PM) nghe phản hồi rằng stakeholders liên tục phàn nàn tại iteration demos (demo sản phẩm cuối sprint, tương đương Sprint Review) vì các product features không được giao đúng như yêu cầu ban đầu.
• Vấn đề cốt lõi: Stakeholders cảm thấy sản phẩm không khớp mong đợi, dẫn đến dissatisfaction. PM cần đưa lời khuyên cho PO để đảm bảo features luôn được deliver đúng yêu cầu.
• Mục tiêu: Tìm cách phòng ngừa vấn đề từ sớm, thay vì chỉ sửa chữa sau (post-demo). Điều này liên quan đến Product Backlog Refinement (quá trình tinh chỉnh backlog), Acceptance Criteria (tiêu chí chấp nhận), và sự tham gia của stakeholders trong Agile.

Câu hỏi kiểm tra kiến thức PMP về nguyên tắc Agile (theo PMBOK® Guide 7th Edition và Agile Practice Guide 3rd Edition, cập nhật đến 2026): Nhấn mạnh collaboration, early validation, và tránh công cụ predictive không phù hợp với adaptive environments.

✅ Đáp án đúng: Validate acceptance criteria with stakeholders prior to backlog refinement

Lý do lựa chọn:

• Trong Agile/Scrum, Product Backlog Refinement (hay Backlog Grooming) là hoạt động then chốt nơi PO và team tinh chỉnh Product Backlog Items (PBIs), bao gồm định nghĩa rõ ràng Acceptance Criteria (tiêu chí chấp nhận cụ thể, measurable để xác định feature "done").
• Việc validate (xác thực) Acceptance Criteria với stakeholders TRƯỚC refinement đảm bảo sự đồng thuận sớm, tránh hiểu lầm về yêu cầu. Điều này giúp features được phát triển đúng kỳ vọng, giảm phàn nàn tại Sprint Review (iteration demos).
• Theo Scrum Guide 2020 (cập nhật 2025) và Agile Practice Guide, PO chịu trách nhiệm đại diện stakeholders, nhưng phải collaborate sớm để backlog "ready" (Definition of Ready). Retrospective là nơi phát hiện issue, và lời khuyên này trực tiếp giải quyết root cause: thiếu validation sớm.

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

🛠️ Phân tích từng lựa chọn (giữ nguyên văn bản gốc bằng tiếng Anh, giải thích bằng tiếng Việt):

• ❌ [SAI] Include stakeholders during daily standup meetings to monitor progress
  Giải thích sai: Daily Standup (Daily Scrum) là họp ngắn hàng ngày CHỈ dành cho Development Team (PO có thể tham gia nhưng không bắt buộc), nhằm tự quản lý tiến độ nội bộ (What did I do? What will I do? Impediments?). Việc kéo stakeholders vào daily standup để monitor sẽ làm gián đoạn flow, tăng overhead, vi phạm nguyên tắc self-organizing team (PMBOK 7th, §8.2). Stakeholders nên tham gia Sprint Review thay vì daily monitoring – không giải quyết root cause về yêu cầu không rõ.

• ✅ [ĐÚNG] Validate acceptance criteria with stakeholders prior to backlog refinement
  Giải thích đúng: Như đã phân tích ở trên. Đây là best practice Agile: Early & frequent feedback từ stakeholders trong refinement giúp PBIs có acceptance criteria rõ ràng, testable (e.g., Gherkin format: Given-When-Then). Đảm bảo value delivery đúng yêu cầu, giảm rework tại demo. Hỗ trợ 12 Principles of Agile Manifesto (Customer collaboration over contract negotiation).

• ❌ [SAI] Avoid including stakeholders in iteration reviews
  Giải thích sai: Hoàn toàn ngược lại! Iteration Reviews (Sprint Review) PHẢI bao gồm stakeholders để demo product increment, thu feedback, và adjust backlog (Scrum Guide: "inspect & adapt"). Tránh họ sẽ làm mất transparency, collaboration – nguyên nhân chính gây phàn nàn. Retrospective khuyến khích tăng engagement, không giảm.

• ❌ [SAI] Create a requirements traceability matrix and distribute it accordingly
  Giải thích sai: Requirements Traceability Matrix (RTM) là công cụ predictive/waterfall (PMBOK 7th, §5.3), dùng để trace requirements từ khởi đầu đến cuối dự án – không linh hoạt cho Agile (iterative changes). Agile ưu tiên user stories + acceptance criteria + Definition of Done thay vì heavy documentation. Tạo RTM sẽ tăng bureaucracy, chậm adaptation, không phù hợp hybrid/agile environments (Agile Practice Guide, §4.2).

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021, cập nhật 2026): §8 (Project Data), Agile Hybrid models; Process 8.2 (Manage Product Backlog).
• Agile Practice Guide (PMI, 3rd Ed. 2021): §4.3 (Refinement), §6.2 (Sprint Review & Retrospective).
• Scrum Guide (2020/2025): Product Owner responsibilities, Events (Refinement, Sprint Review).
• PMP Exam Content Outline (2024-2026): Domain IV: People (Stakeholder engagement), Domain V: Business Environment (Value delivery).

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 mô tả một dự án phát triển sản phẩm mới ở giai đoạn rất ban đầu (very initial stage), nơi các yêu cầu (requirements) đang không ngừng thay đổi và phát triển (evolving). Do cạnh tranh khốc liệt trên thị trường, khách hàng mong muốn ra mắt sản phẩm với phạm vi linh hoạt (keeping the scope flexible), cho phép điều chỉnh nhanh chóng. Đội ngũ dự án dự định bắt đầu công việc dựa trên dự báo (forecast) từ một dự án tương tự đã hoàn thành năm ngoái.

🛠️ Vấn đề cốt lõi: Cần chọn phương pháp tiếp cận dự án (project approach) phù hợp nhất, tập trung vào tính linh hoạt cao để xử lý sự không chắc chắn về yêu cầu và phạm vi, thay vì cách tiếp cận cứng nhắc. Theo PMBOK® Guide 7th Edition (2021) và Agile Practice Guide, đây là tình huống điển hình cho các phương pháp lặp lại và thích ứng (iterative and adaptive) như Agile, vì dự án ở giai đoạn đầu với yêu cầu chưa ổn định.

✅ Đáp án đúng: Execute it as a Scrum project

Lý do lựa chọn:
Scrum là một framework Agile lý tưởng cho kịch bản này vì nó hỗ trợ làm việc theo chu kỳ ngắn (sprints), cho phép điều chỉnh phạm vi linh hoạt dựa trên phản hồi liên tục từ khách hàng và thị trường. Dự án ở giai đoạn đầu với requirements evolving phù hợp với Scrum, nơi product backlog được tinh chỉnh dần dần thay vì định sẵn toàn bộ. Việc sử dụng forecast từ dự án tương tự có thể làm baseline cho velocity estimation trong Scrum, giúp khởi động nhanh. Điều này đảm bảo sản phẩm có thể launch sớm với MVP (Minimum Viable Product) để đáp ứng cạnh tranh, theo nguyên tắc Agile Manifesto: "Responding to change over following a plan".

🔍 Phân tích tất cả các phương án (đúng và sai)

• ✅ Execute it as a Scrum project
  Đúng vì: Scrum hỗ trợ hoàn hảo cho dự án với scope linh hoạt và requirements evolving, thông qua các sprint 1-4 tuần, daily scrum, sprint review để điều chỉnh nhanh chóng. Forecast từ dự án cũ có thể dùng để ước lượng story points ban đầu, phù hợp với PMBOK 7th (Section 4.5: Agile Approaches).

• ❌ Execute it as a predictive project
  Sai vì: Predictive (hay Waterfall) yêu cầu định nghĩa đầy đủ scope từ đầu và ít thay đổi, không phù hợp với requirements evolving và scope flexible. Nó sẽ dẫn đến rủi ro cao do cạnh tranh thị trường thay đổi nhanh, vi phạm nguyên tắc "Deliver value incrementally" trong Agile Practice Guide.

• ❌ Execute it using the same approach as the reference project
  Sai vì: Không có thông tin về phương pháp của dự án tham chiếu năm ngoái, và ngữ cảnh hiện tại khác biệt (cạnh tranh cao, scope flexible). Sao chép mù quáng có thể không hiệu quả, trái với PMBOK 7th (Section 2.3: Tailoring – cần tùy chỉnh approach dựa trên context hiện tại thay vì copy-paste).

• ❌ Execute it as a project with stage gates
  Sai vì: Stage gates (cổng giai đoạn) là đặc trưng của predictive/hybrid approaches, với phê duyệt nghiêm ngặt giữa các phase, làm chậm quá trình và khó linh hoạt với evolving requirements. Không phù hợp cho initial stage cần iteration nhanh, theo PMP Exam Content Outline (Domain IV: People – Agile/Adaptive Environments).

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021): Chương 4 (Models, Methods, and Artifacts), nhấn mạnh chọn predictive cho stable requirements vs. adaptive cho uncertain.
• Agile Practice Guide (2017, cập nhật với PMBOK 7): Phần Scrum framework và tailoring cho product development.
• PMP Examination Content Outline (2021, hiệu lực đến 2026): Domain II: Process (Tailoring approaches), Domain VI: Business Environment (Market competition).
• PMI.org resources: Scrum Guide 2020 (Scrum.org) – Định nghĩa Scrum cho flexible scope.

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ụ, 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ủ đề quản lý dự án Agile/Scrum hybrid trong PMP (phiên bản PMBOK Guide 7th Edition và Agile Practice Guide, cập nhật đến 2026). Nó mô tả tình huống: Một đội ngũ dự án đang gặp trì hoãn (delays) ở một nhiệm vụ (task) phức tạp hơn dự kiến ban đầu, và nhiệm vụ này là critical có thể ảnh hưởng đến mục tiêu iteration hiện tại (iteration goals, thường trong Scrum sprint). Câu hỏi yêu cầu chọn hai lựa chọn ban đầu (initially) để đội ngũ giải quyết trở ngại (address this obstacle).

📌 Điểm nhấn: Tập trung vào hành động ngay lập tức của đội ngũ tự quản (self-organizing team) theo nguyên tắc Agile, ưu tiên phân tích vấn đề gốc và điều chỉnh kế hoạch linh hoạt, thay vì leo thang hoặc hành động sau sự việc. Điều này phù hợp với 12 nguyên tắc Agile Manifesto (team tự quản lý và thích ứng) và Scrum Guide 2020+ (Daily Scrum để xử lý impediments).

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

Hai lựa chọn đúng là:
Review and update dependencies và Conduct a root cause analysis.

Lý do lựa chọn:
🛠️ Trong tình huống trì hoãn task critical ngay giữa iteration, đội ngũ cần hành động ban đầu nhanh chóng để xác định nguyên nhân và điều chỉnh. "Review and update dependencies" giúp kiểm tra các phụ thuộc (dependencies) có thể thay đổi, gây delay (theo PMBOK 7: Uncertainty Domain). "Conduct a root cause analysis" (phân tích nguyên nhân gốc, như 5 Whys hoặc Fishbone) là bước đầu tiên để hiểu vấn đề phức tạp hơn dự kiến (Agile Practice Guide: Problem Detection & Solving). Những hành động này trao quyền cho đội ngũ, duy trì velocity và đạt iteration goals mà không cần can thiệp bên ngoài ngay lập tức.

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

Dưới đây là giải thí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 PMP/Agile best practices:

• ❌ Escalate the issue to the project sponsor
  Sai: Leo thang ngay cho sponsor là hành động cuối cùng (last resort), không phải ban đầu. Đội ngũ Agile phải tự giải quyết impediments (Scrum Guide: Team tự quản). Escalate chỉ khi vượt khả năng đội ngũ, tránh làm gián đoạn flow và mất quyền tự chủ.

• ✅ Review and update dependencies
  Đúng: Hành động ban đầu lý tưởng vì task phức tạp có thể do dependencies thay đổi (ví dụ: task upstream delay). Review và update giúp điều chỉnh backlog hoặc sprint plan kịp thời (PMBOK 7: Planning Performance Domain), đảm bảo flow liên tục trong iteration.

• ❌ Schedule a retrospective
  Sai: Retrospective là hoạt động cuối iteration để học hỏi từ quá khứ, không dùng để giải quyết vấn đề ngay lập tức. Lên lịch retrospective lúc này sẽ trì hoãn thêm, không phù hợp với "initially address" (Agile Practice Guide: Inspect & Adapt cycle diễn ra sau sprint).

• ✅ Conduct a root cause analysis
  Đúng: Đây là bước đầu tiên thiết yếu để hiểu tại sao task phức tạp hơn (root cause như estimation sai hoặc hidden risks). Sử dụng công cụ như Ishikawa Diagram hoặc 5 Whys giúp đội ngũ hành động dựa trên dữ liệu, tăng hiệu quả iteration (PMBOK 7: Measurement Domain & Agile Problem-Solving techniques).

• ❌ Create a risk management plan
  Sai: Risk management plan phải tạo từ đầu dự án (PMBOK 7: Risk Domain), không phải lúc trì hoãn xảy ra. Tạo mới bây giờ là phản ứng muộn, đội ngũ nên dùng existing risk register hoặc nhanh chóng mitigate thay vì lập kế hoạch toàn bộ.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021, PMI): Uncertainty Domain (Ch. 4), Planning Performance Domain (Ch. 3).
• Agile Practice Guide (PMI, 2017+ updates): Ch. 5: Problem Detection and Solving; Ch. 6: Continuous Improvement.
• Scrum Guide (2020, Scrum.org): Sprint Events & Servant Leadership (impediments handling).
• Cập nhật 2026: PMI nhấn mạnh hybrid approaches với AI-assisted root cause (PMI Standards+).

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