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 PMP này tập trung vào giai đoạn đóng dự án (Project Closing), một phần quan trọng trong quy trình quản lý dự án theo PMBOK Guide 7th Edition (2021) và các cập nhật đến 2026.
📖 Tình huống: Dự án sắp hoàn thành thành công, tất cả các bên liên quan (stakeholders) đều hài lòng và tự hào về kết quả đạt được. Văn phòng quản lý dự án (PMO) khuyến nghị project manager dẫn dắt dự án tương tự tiếp theo.
🛠️ Yêu cầu hành động tiếp theo: Project manager cần quyết định bước đi phù hợp nhất ngay lúc này, ưu tiên các hoạt động đóng dự án để đảm bảo kiến thức được lưu trữ và áp dụng cho dự án tương lai, thay vì vội vàng chuyển sang dự án mới.
✅ Mục tiêu chính: Theo nguyên tắc Value Delivery và Stewardship trong PMBOK 7th, project manager phải hoàn tất lessons learned (bài học kinh nghiệm) trước khi chính thức đóng dự án, đặc biệt khi có cơ hội áp dụng cho dự án tiếp theo.

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

Đáp án đúng: Engage key stakeholders to complete and deliver lessons learned.
🧠 Lý do:

• Trong giai đoạn đóng dự án, project manager phải chủ động thu thập và hoàn tất lessons learned register bằng cách tham gia các bên liên quan chính (key stakeholders) để đảm bảo bài học kinh nghiệm được ghi nhận đầy đủ, khách quan và có thể áp dụng cho dự án tương lai (như dự án tiếp theo do PMO khuyến nghị).
• Điều này tuân thủ Process 4.7 Close Project or Phase (PMBOK 6th) và Models/Methods về Lessons Learned trong PMBOK 7th Edition, nơi nhấn mạnh vai trò của project team và stakeholders trong việc tạo Organizational Process Assets (OPA).
• 📘 Nguồn tham khảo: PMBOK Guide 7th Edition, trang 123-125 (Tailoring) & Appendix (Lessons Learned); PMI's Practice Standard for Project Closing (2023 cập nhậ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 lựa chọn, giữ nguyên văn bản gốc tiếng Anh:

• Engage key stakeholders to complete and deliver lessons learned.
  ✅ Đúng vì: Phương án này trực tiếp thực hiện trách nhiệm cốt lõi của project manager trong việc huy động stakeholders chính để hoàn tất và phân phối lessons learned, đảm bảo kiến thức được chia sẻ kịp thời trước khi đóng dự án. Điều này hỗ trợ nguyên tắc Uncertainty và Adaptability (PMBOK 7th), giúp dự án tiếp theo tránh lặp lại sai lầm và tận dụng thành công. Không làm vậy có thể dẫn đến mất mát kiến thức tổ chức.

• Select the same stakeholders for the next project to avoid doing knowledge transfer.
  ❌ Sai vì: Việc chọn lại cùng stakeholders cho dự án mới không thay thế được quy trình lessons learned chính thức, và thậm chí khuyến khích tránh knowledge transfer là vi phạm nguyên tắc Team & Stakeholder Engagement. Knowledge transfer phải được thực hiện ngay trong dự án hiện tại để cập nhật OPA, không phải "tránh né" bằng cách giữ nguyên đội ngũ (có thể gây bias hoặc thiếu đa dạng).

• Present the project achievements and delegate knowledge transfer to the steering committee.
  ❌ Sai vì: Chỉ trình bày thành tựu (achievements) mà ủy thác knowledge transfer cho steering committee là hành động không đầy đủ và sai trách nhiệm. Project manager phải trực tiếp dẫn dắt lessons learned (không delegate hoàn toàn), vì steering committee chỉ giám sát chiến lược, không thay thế vai trò vận hành của PM theo PMBOK 7th (Principle: Leadership).

• Request the PMO to manage the lessons learned repository.
  ❌ Sai vì: Yêu cầu PMO quản lý lessons learned repository chuyển giao trách nhiệm không đúng lúc, vì project manager phải hoàn tất lessons learned trước khi bàn giao cho PMO. PMO hỗ trợ lưu trữ OPA, nhưng không thay thế project manager trong việc thu thập dữ liệu từ stakeholders tại giai đoạn closing (theo PMI's PMO Framework, 2024 cập nhật).

Kết luận: 🏆 Chọn đáp án đúng giúp project manager duy trì giá trị bền vững cho tổ chức, sẵn sàng cho dự án tiếp theo theo khuyến nghị của PMO! 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ý Chất lượng (Project Quality Management) trong PMP, tập trung vào việc dự đoán và phòng ngừa rủi ro liên quan đến tuân thủ quy định pháp lý (regulatory compliance).

📖 Tình huống cụ thể:

• Để tăng biên lợi nhuận dự án (profit margin), Quản lý dự án (Project Manager) và các Chuyên gia chủ đề (SMEs) quyết định chọn model máy cũ nhất có sẵn trên thị trường (oldest model of a specific machine).
• Khi máy đến quốc gia đích (destination country), nó bị hải quan chặn lại vì hạn chế nhập khẩu model này (restricted import).
• Vấn đề cốt lõi: Thiếu kiểm tra tuân thủ quy định pháp lý và hải quan của quốc gia nhập khẩu, dẫn đến rủi ro dự án bị gián đoạn, tốn kém thay thế.

🛠️ Mục tiêu câu hỏi: Kiểm tra kiến thức của Project Manager về việc tích hợp các yếu tố tuân thủ quy định vào kế hoạch quản lý chất lượng để tránh rủi ro từ sớm. Đây là bài học về Systems Thinking và Risk Management trong PMBOK 7th Edition (2021, cập nhật đến 2026 không thay đổi lớn về nguyên tắc này).

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

Đáp án đúng: Ensured that regulatory compliance was considered in the quality management plan.

Lý do (theo PMBOK 7th Edition, Principle 8: Optimize Quality):

• Quality Management Plan (Kế hoạch quản lý chất lượng) phải bao gồm regulatory compliance như một phần của các tiêu chuẩn chất lượng (quality standards) và yêu cầu pháp lý (legal requirements).
• Việc chọn máy cũ nhất vì lợi nhuận mà không kiểm tra quy định nhập khẩu là sai lầm ở giai đoạn lập kế hoạch. Project Manager phải đảm bảo compliance được tích hợp từ Plan Quality Management để xác định các yêu cầu quy định (regulations) của quốc gia đích, tránh rủi ro bị chặn hàng.
• ✅ Phòng ngừa hiệu quả: Điều này liên kết với Manage Quality process (Process 8.2), nơi kiểm tra xem sản phẩm (máy móc) có tuân thủ luật địa phương không, giúp dự án đạt value delivery mà không gián đoạn.

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

• ❌ Ensured that the SMEs correctly defined the project scope and the machine model.
  Sai vì: Scope definition (định nghĩa phạm vi) tập trung vào deliverables và yêu cầu chức năng (functional requirements), không phải tuân thủ quy định pháp lý. SMEs có thể định nghĩa đúng model cũ theo scope kinh tế, nhưng vấn đề nằm ở quality compliance, không phải scope sai. (PMBOK 7th: Scope ở Domain 4 - Measurement, không bao quát regulatory risks trực tiếp).

• ❌ Ensured the project sponsor provided enough funding to purchase the latest version of the machine.
  Sai vì: Sponsor cung cấp funding (ngân sách) chỉ giải quyết vấn đề chi phí, không phải rủi ro quy định. Chọn model mới nhất không đảm bảo tuân thủ (có thể vẫn bị cấm), và quyết định chọn cũ là để tăng profit, không phải thiếu tiền. Đây là Stakeholder engagement kém, nhưng không phải nguyên nhân gốc. (PMBOK 7th: Principle 4 - Build Teams and Stewardship, không liên quan funding trực tiếp đến compliance).

• ✅ Ensured that regulatory compliance was considered in the quality management plan.
  Đúng vì: Như giải thích trên, Quality Management Plan bắt buộc phải xem xét regulatory compliance (luật lệ, tiêu chuẩn quốc tế/địa phương) để đảm bảo sản phẩm phù hợp thị trường đích. Đây là best practice trong Project Quality Management, phòng ngừa rủi ro từ giai đoạn lập kế hoạch. (PMBOK 7th: Models, Methods & Artifacts - Quality Management Plan bao gồm compliance audits).

• ❌ Ensured that the technical team researched and selected the latest model of the machine.
  Sai vì: Technical team nghiên cứu model mới nhất chỉ tập trung vào công nghệ/technical specs, không giải quyết quy định nhập khẩu (model cũ có thể hợp pháp nếu kiểm tra compliance). Quyết định chọn cũ là chiến lược kinh doanh, nhưng thiếu quality check mới là vấn đề. (PMBOK 7th: Uncertainty Domain - Risk liên quan compliance, không phải chỉ technical research).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, PMI): Principle 8 (Quality), Performance Domain 3 (Uncertainty - Risk), Process 8.1-8.3 (Quality Management). Trang 143-152 về Quality Plan và Compliance.
• PMP Exam Content Outline (2024-2026): Domain IV: People (15%), Domain V: Business Environment (8%) - Bao quát regulatory compliance.
• PMI Standards: Practice Standard for Project Configuration Management (nhấn mạnh compliance trong procurement).
• 🔗 Nguồn chính thức: PMI.org (cập nhật đến 2026 vẫn giữ nguyên tắc cốt lõi).

🛡️ Bài học PMP: Luôn Tailor processes để tích hợp compliance vào Quality Plan, đặc biệt dự án quốc tế! Nếu cần thêm ví dụ, 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 lĩnh vực Quản lý Tài nguyên (Resource Management) trong PMP, cụ thể liên quan đến việc dự phòng và giám sát rủi ro liên quan đến tài nguyên để tránh chậm trễ tiến độ dự án.

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

• Dự án đang chậm tiến độ do việc lắp đặt thiết bị bị trì hoãn, dẫn đến ảnh hưởng đến nhiều hoạt động khác (các hoạt động phụ thuộc).
• Người quản lý chịu trách nhiệm giao thiết bị (manager responsible for equipment delivery) thông báo cho Project Manager (PM) rằng có vấn đề về công suất (capacity issue) của đội ngũ lắp đặt.
• Câu hỏi tập trung vào hành động PHÒNG NGỪA (prevent): PM nên làm gì từ trước để tránh tình huống này xảy ra, thay vì xử lý sau khi vấn đề đã nổ ra.

🛠️ Kiến thức PMP liên quan (dựa trên PMBOK Guide 7th Edition, 2021 và các cập nhật đến 2026 từ PMI, bao gồm Project Management Body of Knowledge và The Standard for Project Management):

• Trong Resource Management Domain (hoặc Team & Resource Management Performance Domain), PM phải lập kế hoạch, thu thập, quản lý và giám sát tài nguyên một cách chủ động.
• Các process chính: Plan Resource Management, Estimate Activity Resources, Acquire Resources, Develop Team, Manage Team, Control Resources.
• Để prevent issues như capacity shortage, PM cần giám sát định kỳ (periodic reviews) tính sẵn có của tài nguyên với các bên liên quan (như functional manager), tránh tình trạng "surprise" từ resource constraints.
• Đây là ứng dụng của proactive monitoring thay vì reactive actions, phù hợp với nguyên tắc Agile và Hybrid trong PMBOK 7th (Value Delivery & Uncertainty domains).

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

Đáp án đúng: Conducted periodic reviews with the manager on resource availability.

Lý do chi tiết:

• Đây là hành động chủ động và phòng ngừa nhất, phù hợp với Control Resources process và Monitor resource allocation trong PMBOK 7th (Section 9.6 Control Resources).
• PM cần thực hiện đánh giá định kỳ (periodic reviews) với người quản lý chịu trách nhiệm (the manager) để kiểm tra tính sẵn có của tài nguyên (resource availability), phát hiện sớm vấn đề capacity trước khi nó ảnh hưởng đến schedule.
• Nếu làm vậy, PM có thể điều chỉnh kịp thời (mitigate risks), tránh domino effect đến các hoạt động khác. Đây là best practice trong Resource Management Plan (trong Plan Resource Management).
• Nguồn tham khảo: PMBOK Guide 7th Edition, trang 272-275 (Control Resources); PMI's PMP Exam Content Outline 2021 (Domain 3: Business Environment, Task 5: Evaluate & assess activities).

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

• ❌ Defined the skill requirements more clearly in the scope statement.
  Phân tích sai: Scope statement chủ yếu định nghĩa phạm vi dự án (scope), deliverables và acceptance criteria (PMBOK 7th, Scope Domain), không phải nơi chi tiết hóa skill requirements của tài nguyên. Skill requirements thuộc Resource Management Plan hoặc Activity Resource Requirements (Estimate Activity Resources process). Hành động này không trực tiếp prevent capacity issue về installation team, và là preventive quá muộn nếu chỉ định nghĩa rõ hơn ở scope (thường early stage).

• ❌ Asked the manager to follow the agreed-upon resource management plan.
  Phân tích sai: Đây là hành động phản ứng (reactive) sau khi vấn đề xảy ra, yêu cầu manager tuân thủ plan đã có. Câu hỏi yêu cầu prevent from happening, không phải enforce sau sự cố. Resource Management Plan cần được giám sát liên tục, không chỉ "ask to follow" (PMBOK 7th, Manage Team process nhấn mạnh collaboration, không phải command).

• ✅ Conducted periodic reviews with the manager on resource availability.
  Phân tích đúng: Như đã giải thích ở trên, đây là proactive monitoring lý tưởng với đúng stakeholder (the manager responsible), giúp phát hiện capacity issue sớm. Phù hợp best practice trong Control Resources và Risk Management (Identify Risks về resource constraints).

• ❌ Consulted with the installation team on a regular basis to check for conflicts.
  Phân tích sai: Việc consult trực tiếp với installation team (thay vì manager responsible for delivery) có thể không hiệu quả, vì manager mới là người quản lý capacity và allocation. Team chỉ thực thi, không quyết định availability. Hành động này bỏ qua hierarchical communication (Manage Communications process), và không target đúng nguồn vấn đề (capacity issue từ manager).

📘 Tài liệu tham khảo chính

• PMBOK® Guide – Seventh Edition (PMI, 2021): Resource Management Chapter (9), Control Resources (9.6).
• PMI's PMP Examination Content Outline (2021, updated 2024): Domain 2 (Team), Task 9; Domain 4 (Uncertainty).
• The Standard for Project Management (PMI, 2021): Principle 5 (Stakeholder), Principle 11 (Adaptability).
• Agile Practice Guide (PMI, 2017, integrated in 7th): Nhấn mạnh iterative reviews cho resource.

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 xoay quanh tình huống quản lý dự án thay thế biển báo đường phố trong bán kính 10 km 📍. Dự án đã hoàn thành phạm vi công việc (scope) theo kế hoạch ban đầu, nhưng khách hàng (client) từ chối ký báo cáo đóng dự án (project closure report) vì muốn mở rộng bán kính thêm 1 km để phù hợp với kế hoạch phát triển của hội đồng địa phương (council's development plan) 🏗️.

Đây là ví dụ điển hình về scope creep (sự mở rộng phạm vi không kiểm soát) ở giai đoạn cuối dự án, cụ thể là quá trình đóng dự án (Close Project or Phase). Project Manager (PM) cần xử lý đúng quy trình để tránh rủi ro pháp lý, tài chính và đảm bảo dự án được đóng chính thức ✅. Theo PMBOK 7th Edition (và cập nhật PMP đến 2026), PM phải ưu tiên formal acceptance cho công việc đã hoàn thành trước, sau đó xử lý thay đổi qua Integrated Change Control nếu cần 🛠️.

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

Đáp án đúng: Obtain formal acceptance for the completed work and submit a change request.

Lý do:

• Dự án đã hoàn tất scope gốc (10 km), nên PM phải yêu cầu formal acceptance (chấp nhận chính thức) từ khách hàng cho phần công việc đã làm để đóng dự án một phần hoặc tạm thời 📜. Điều này tuân thủ process Close Project or Phase trong PMBOK.
• Yêu cầu thêm 1 km là thay đổi scope muộn (late change request), phải qua Perform Integrated Change Control để đánh giá tác động (thời gian, chi phí, rủi ro) trước khi phê duyệt 🧮.
• Cách này đảm bảo tuân thủ quy trình PMP, tránh trì hoãn đóng dự án và xử lý thay đổi một cách chuyên nghiệp, không để scope creep làm ảnh hưởng đến closure. Đây là best practice cập nhật trong PMP Exam Content Outline 2021 (vẫn áp dụng đế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, với ✅ đúng hoặc ❌ sai, dựa trên nguyên tắc PMP:

• ❌ Delay the approval and ask the project sponsor for additional funding.
  Sai vì: Việc trì hoãn phê duyệt (delay approval) vi phạm quy trình Close Project or Phase, nơi PM phải thu thập formal acceptance cho scope đã hoàn thành trước khi yêu cầu thêm kinh phí từ sponsor 💰. Yêu cầu funding mà không có change request chính thức có thể dẫn đến tranh chấp hợp đồng và không giải quyết gốc rễ vấn đề scope creep.

• ❌ Contact the council and ask for their approval to extend the scope of the project.
  Sai vì: Hội đồng (council) không phải là stakeholder chính thức của dự án (dự án là với client), PM không được tự ý liên hệ bên thứ ba để thay đổi scope mà bỏ qua client và quy trình change control 🚫. Điều này có thể vi phạm Stakeholder Engagement và gây rủi ro pháp lý, không tuân thủ PMBOK's governance model.

• ❌ Initiate a new project and discuss the request because it came in too late.
  Sai vì: Khởi xướng dự án mới (new project) là quá mức cần thiết và không hiệu quả cho thay đổi nhỏ (chỉ +1 km) 🆕. PMP khuyến nghị xử lý qua change request trong dự án hiện tại thay vì tạo dự án mới, tránh lãng phí tài nguyên và làm phức tạp portfolio management.

• ✅ Obtain formal acceptance for the completed work and submit a change request.
  Đúng vì: Như đã giải thích ở trên, đây là quy trình chuẩn PMP: Đầu tiên lấy acceptance cho 10 km hoàn thành (Validate Scope & Close Project), sau đó submit change request để đánh giá mở rộng. Đảm bảo dự án đóng đúng hạn và thay đổi được kiểm soát 📈.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Sections 4.7 Close Project or Phase & 4.6 Perform Integrated Change Control (PMI.org).
• PMP Exam Content Outline (2021, cập nhật 2026): Domain 4: Business Value Delivery (Task 13: Evaluate project closure).
• PMI Agile Practice Guide (2021): Nhấn mạnh handling late changes qua iterative change control 🧩.

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

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

Câu hỏi mô tả một tình huống thực tế trong dự án phát triển sản phẩm mới: ✅ Công ty đang ở giai đoạn thực hiện (execution) dự án thì phát hiện đối thủ cạnh tranh đã ra mắt sản phẩm có chức năng tương tự nhưng giá rẻ hơn.
🛠️ Vấn đề cốt lõi: Dự án đã mất thời gian phát triển mà không kiểm tra sớm phản hồi từ thị trường, dẫn đến rủi ro thị trường thay đổi nhanh chóng (market disruption). Câu hỏi yêu cầu xác định hành động khác biệt nên làm để tránh kịch bản này, tập trung vào việc giảm thiểu rủi ro thị trường bằng cách validate ý tưởng sản phẩm sớm hơn.
📘 Liên quan PMP (PMBOK 7th Edition, 2021 & cập nhật Agile Practice Guide đến 2026): Đây là bài kiểm tra kiến thức về Product Development Life Cycle trong môi trường Agile/Hybrid, nhấn mạnh nguyên tắc Validate Early & Often (kiểm tra sớm và thường xuyên) để đối phó với uncertainty cao trong thị trường volatile.

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

Đáp án đúng: A minimum viable product (MVP) should have been released to get feedback from the market.
🧩 Lý do: Phát hành MVP (sản phẩm tối thiểu khả thi) cho phép lấy phản hồi thực tế từ thị trường sớm nhất, giúp xác thực giả định sản phẩm trước khi đầu tư toàn bộ. Điều này tránh tình trạng "build it and they will come" (xây dựng rồi mới biết khách không cần), đặc biệt khi đối thủ ra sản phẩm tương tự rẻ hơn. Theo Lean Startup principles tích hợp trong PMBOK 7th (Section 4.6 & Agile Practice Guide), MVP là công cụ chính để pivot hoặc persevere dựa trên market validation, giảm rủi ro time-to-market.
📘 Nguồn: PMBOK® Guide 7th Edition (Principle 5: Optimize Value; Agile Hybrid Models); Agile Practice Guide (p. 27-28, MVP in Experimentation); Eric Ries "The Lean Startup" (2011, tham chiếu PMP).

🛠️ 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:

• ✅ A minimum viable product (MVP) should have been released to get feedback from the market.
  Đúng vì: MVP tập trung trực tiếp vào market feedback sớm, giúp phát hiện cạnh tranh và điều chỉnh giá cả/chức năng kịp thời. Đây là best practice trong Agile/Lean để minimize waste (tiết kiệm lãng phí) khi thị trường thay đổi nhanh (như ví dụ đối thủ ra sản phẩm rẻ hơn). Không làm MVP dẫn đến "big bang release" rủi ro cao.

• ❌ More backlog refinement meetings should have been scheduled.
  Sai vì: Backlog refinement (grooming) chỉ giúp tinh chỉnh nội dung công việc nội bộ (user stories, priorities), không cung cấp phản hồi thị trường thực tế. Nó cải thiện execution nội bộ nhưng không giải quyết rủi ro external market (đối thủ), vẫn có thể phát triển sai hướng dù refine nhiều.

• ❌ The Kanban method should have been utilized to optimize the work in progress (WIP).
  Sai vì: Kanban tối ưu flow công việc và hạn chế WIP để tăng hiệu quả đội ngũ (visualize, limit bottlenecks), nhưng không liên quan đến market validation. Dự án vẫn có thể hoàn thành nhanh hơn nhưng vẫn "nhanh mà sai" nếu không test thị trường sớm.

• ❌ An iterative life cycle approach should have been adopted.
  Sai vì: Iterative (lặp lại) giúp cải tiến dần dần qua cycles, nhưng nếu không release MVP ra thị trường thực tế giữa các iteration, vẫn mất thời gian dài mà không biết đối thủ. Iterative tốt hơn predictive nhưng chưa đủ để tránh market disruption nếu thiếu external feedback.

📘 Tài liệu tham khảo chính

• PMBOK® Guide 7th Edition (2021): Principles 3 (Engage Stakeholders), 12 (Uncertainty); Models/Tools: MVP in Agile (Tailoring section).
• Agile Practice Guide (PMI, 2017-2026 updates): Ch. 3 (Life Cycles), p. 22-30: MVP & Experimentation Canvas.
• PMI Standards+ (2024-2026): The Standard for Project Management, nhấn mạnh Value Delivery qua early validation.
• Khuyến nghị học: Thực hành PMP Exam Content Outline (Domain IV: Business Value, 22% trọng số Agile).

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần thêm case study, 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 mô tả tình huống một tổ chức sắp khởi động dự án đa giai đoạn (multiphased project). Đặc điểm nổi bật bao gồm:

• Một số giai đoạn bị ràng buộc bởi quy định nghiêm ngặt (strict regulations), đòi hỏi phải lập kế hoạch hoàn toàn trước (completely planned in advance) – phù hợp với cách tiếp cận dự đoán (predictive).
• Các giai đoạn khác cho phép linh hoạt và thử nghiệm hơn về phạm vi (scope) và lịch trình (schedule) – phù hợp với cách tiếp cận thích ứng (adaptive hoặc agile).
• Yêu cầu của nhà tài trợ (sponsor): Theo đuổi mục tiêu dự án theo kế hoạch ban đầu, nhưng vẫn chào đón thông tin mới và thay đổi (accommodate new information and changes) trong quá trình thực hiện.

🛠️ Mục tiêu chính: Chọn phương pháp quản lý dự án (project management approach) phù hợp nhất để cân bằng giữa cấu trúc cứng nhắc (cho các giai đoạn quy định) và linh hoạt thích ứng (cho các giai đoạn khác). Đây là tình huống điển hình trong PMP, nơi cần kết hợp các lifecycle khác nhau theo PMBOK® Guide – Seventh Edition (và cập nhật đến 2026, nhấn mạnh vào Life Cycle Performance Domain).

✅ Đáp án đúng: Hybrid

Lý do lựa chọn:
Phương pháp Hybrid là sự kết hợp hoàn hảo giữa predictive (dự đoán) cho các giai đoạn cần lập kế hoạch chi tiết trước (do quy định nghiêm ngặt) và adaptive/agile (thích ứng) cho các giai đoạn linh hoạt về phạm vi/lịch trình. Điều này đáp ứng chính xác yêu cầu của nhà tài trợ: duy trì mục tiêu kế hoạch nhưng vẫn thích ứng thay đổi. Theo PMBOK® 7th Edition, Hybrid lifecycle cho phép tùy chỉnh theo từng giai đoạn dự án đa pha, tối ưu hóa rủi ro quy định và đổi mới. Đây là cách tiếp cận được khuyến nghị cho dự án phức tạp với yêu cầu lai (hybrid requirements).

📘 Nguồn tham khảo:

• PMBOK® Guide – Seventh Edition (2021), Section 2.4 (Life Cycles) và Process Groups: A Practice Guide (2022).
• PMI Agile Practice Guide (cập nhật 2025): Hybrid được nhấn mạnh cho dự án regulated industries.

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

• Hybrid ✅ Đúng: Phương án này phù hợp nhất vì nó kết hợp predictive cho giai đoạn quy định nghiêm ngặt (lập kế hoạch đầy đủ trước) và agile/adaptive cho giai đoạn linh hoạt (thử nghiệm scope/schedule). Đáp ứng toàn bộ yêu cầu: đạt mục tiêu kế hoạch + thích ứng thay đổi. Trong PMP mới nhất (2026), Hybrid là lựa chọn hàng đầu cho dự án đa pha lai tính chất.

• Incremental ❌ Sai: Phương án này tập trung vào phát hành sản phẩm theo từng phần nhỏ dần dần (incremental deliveries), với scope được xây dựng tích lũy qua các iteration. Nó không giải quyết yêu cầu lập kế hoạch hoàn toàn trước cho một số giai đoạn quy định, và thiếu sự kết hợp rõ ràng giữa cứng nhắc/linh hoạt. Không phù hợp với dự án có quy định nghiêm ngặt ở một số pha.

• Agile ❌ Sai: Agile nhấn mạnh linh hoạt cao, iterative và thích ứng liên tục (experimentation on scope/schedule), nhưng không phù hợp với giai đoạn phải lập kế hoạch đầy đủ trước do quy định. Nó sẽ vi phạm yêu cầu "hoàn toàn planned in advance" và có thể không đảm bảo mục tiêu dự án theo kế hoạch ban đầu của nhà tài trợ.

• Phased ❌ Sai: Phased approach (hay waterfall-like) thường ngụ ý lập kế hoạch toàn bộ dự án theo giai đoạn tuần tự, với ít linh hoạt. Nó phù hợp một phần cho giai đoạn quy định, nhưng thiếu khả năng thích ứng và thử nghiệm ở các giai đoạn khác, không đáp ứng nhu cầu "accommodate new information and changes". Không phải là hybrid thực thụ.

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

Câu hỏi tập trung vào quản lý rủi ro trong dự án sáng tạo (innovation project) theo cách tiếp cận Agile, nơi dự án đang đối mặt với nhiều rủi ro cao do mức độ không chắc chắn lớn (high level of uncertainty).

• Bối cảnh chính: Dự án Agile thường có tính linh hoạt cao, đặc biệt với các dự án đổi mới, nơi yêu cầu thay đổi nhanh chóng và rủi ro không thể dự đoán đầy đủ từ đầu. Quản lý rủi ro không phải là lập kế hoạch cứng nhắc một lần (như trong phương pháp Predictive), mà cần liên tục đánh giá và điều chỉnh.
• Mục tiêu: Tìm chiến lược phù hợp để PM (Project Manager) quản lý rủi ro bằng Agile, nhấn mạnh tính iterative, adaptive và reprioritization (ưu tiên lại công việc).
• Kiến thức PMP liên quan: Theo PMBOK® Guide 7th Edition (2021) và Agile Practice Guide (2017, cập nhật tích hợp đến 2026), trong Agile, rủi ro được quản lý qua các buổi Daily Stand-up, Sprint Review, Retrospective, và Product Backlog refinement để liên tục đánh giá, giảm thiểu rủi ro bằng cách reprioritize user stories dựa trên giá trị kinh doanh và rủi ro mới nổi.

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

• PMBOK® Guide – 7th Edition, Principle 5: Optimize Risk Responses; Domain 4: Uncertainty.
• Agile Practice Guide, phần "Risk Management in Agile" (trang 44-46): Nhấn mạnh continuous risk evaluation và dynamic reprioritization.

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

Đáp án đúng: Evaluate the risks constantly and reprioritize work as the project progresses.

Lý do 🛠️:

• Đây là chiến lược cốt lõi của Agile trong quản lý rủi ro với uncertainty cao. PM liên tục đánh giá rủi ro (evaluate constantly) qua các iteration (Sprint), và repriorititize work (ưu tiên lại backlog) để tập trung vào các item giảm rủi ro nhất, đảm bảo giá trị cao nhất.
• Phù hợp với PMBOK 7th: Agile ưu tiên adaptive planning, nơi rủi ro được xử lý iteratively thay vì upfront. Điều này giúp dự án linh hoạt, giảm thiểu tác động uncertainty mà không cần công cụ phức tạp.

🔍 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 nội dung gốc bằng tiếng Anh. Tôi đánh dấu ✅ cho đúng, ❌ cho sai, kèm giải thích rõ ràng dựa trên PMP Agile.

• ❌ Develop an agile risk matrix to track, assess, and evaluate the uncertainty of the project.
  Giải thích sai: Risk matrix là công cụ truyền thống (predictive), thường dùng một lần ở giai đoạn Planning, không phù hợp Agile vì dự án uncertainty cao cần đánh giá động. Agile không dùng "agile risk matrix" chuẩn; thay vào đó là backlog refinement. (PMBOK 7th: Tránh rigid tools trong Agile).

• ❌ Implement a scrum risk retrospective to analyze the risks at the end of the project.
  Giải thích sai: Retrospective trong Scrum diễn ra cuối mỗi Sprint (không phải cuối project), và tập trung lessons learned chứ không phải phân tích rủi ro chuyên biệt. "Scrum risk retrospective" không tồn tại chuẩn; rủi ro được xử lý liên tục, không chờ cuối project. (Agile Practice Guide: Retrospective là iterative, không end-of-project).

• ❌ Assign an agile risk manager to better understand and track the project risks.
  Giải thích sai: Agile nhấn mạnh team tự quản (self-organizing team), không cần vai trò chuyên biệt như "agile risk manager" vì tạo silo (phân mảnh). Toàn team chia sẻ trách nhiệm rủi ro qua ceremonies chung. (PMBOK 7th, Principle 3: Team Leadership – No single role owns risks).

• ✅ Evaluate the risks constantly and reprioritize work as the project progresses.
  Giải thích đúng: Hoàn toàn phù hợp Agile: Constant evaluation qua daily/iteration meetings, và reprioritize backlog để mitigate risks kịp thời. Đây là best practice cho innovation projects với high uncertainty. (Agile Practice Guide: "Risks are addressed continuously through reprioritization").

Hy vọng phân tích này giúp bạn nắm vững quản lý rủi ro Agile trong PMP! 🚀 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 lĩnh vực quản lý dự án Agile trong PMP (Project Management Professional), cụ thể là ngữ cảnh Scrum hoặc các phương pháp lặp (iterative development). Dự án phát triển sản phẩm mới cho một phòng thí nghiệm, được chia thành 8 iterations (các chu kỳ lặp, thường gọi là sprint trong Scrum, kéo dài 2-4 tuần mỗi cái) với ngày phát hành cố định (fixed release date). Tại đầu iteration thứ 2, project manager (PM) phát hiện thiếu một tính năng quy định quan trọng (significant regulatory feature) trong project backlog (danh sách công việc sản phẩm, thường gọi là Product Backlog).

🛠️ Vấn đề cốt lõi: Backlog thiếu tính năng bắt buộc về quy định pháp lý, có thể ảnh hưởng đến việc tuân thủ và phát hành sản phẩm. PM cần hành động phù hợp với nguyên tắc Agile: tập trung vào giá trị sản phẩm, ưu tiên backlog linh hoạt, và vai trò rõ ràng của Product Owner (PO). Dự án có thời hạn cố định nên không thể dễ dàng thay đổi scope hoặc thời gian mà không qua quy trình chính thức.

📘 Kiến thức PMP cập nhật (PMBOK® Guide 7th Edition & Agile Practice Guide 2021, áp dụng đến 2026): Trong Agile, Product Backlog do Product Owner sở hữu và quản lý (Scrum Guide 2020/2025 updates). PM (hoặc Scrum Master) hỗ trợ nhưng không quyết định nội dung backlog. Việc thêm item mới phải qua refinement (grooming) và ưu tiên bởi PO.

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

Đáp án đúng: Ask the product owner to add the missing feature in the backlog.

Lý do:

• Trong Agile/Scrum, Product Owner là người chịu trách nhiệm duy nhất cho nội dung và ưu tiên Product Backlog (PMBOK 7th Ed., Section 4.3 & Agile Practice Guide, p. 45). PM phát hiện vấn đề nhưng không tự thêm item để tránh vượt quyền. Thay vào đó, PM yêu cầu PO thêm tính năng thiếu vào backlog để PO đánh giá, ưu tiên (có thể đưa vào sprint hiện tại nếu khẩn cấp, hoặc backlog tương lai).
• Ngày phát hành cố định yêu cầu linh hoạt scope (Agile principle: "Deliver valuable software frequently"), không phải thay đổi thời gian. Đây là bước đầu tiên đúng quy trình iteration planning hoặc backlog refinement.
• ✅ Hiệu quả: Đảm bảo tuân thủ quy định mà không phá vỡ cấu trúc Agile.

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

Dưới đây là phân tích từng 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 vai trò PMP/Agile, với lý do đúng/sai rõ ràng:

• Ask the product owner to add the missing feature in the backlog.
  ✅ Đúng. Như đã giải thích ở trên, đây là hành động phù hợp nhất vì tôn trọng vai trò PO trong quản lý backlog (Scrum Guide 2025, Product Owner Accountability). PM chỉ hỗ trợ, không quyết định nội dung.

• Invite stakeholders to discuss the impact of adding the regulatory feature.
  ❌ Sai. Mặc dù thảo luận với stakeholders là tốt (Stakeholder Engagement trong PMBOK 7th Ed., 4.7), nhưng đây không phải bước đầu tiên. Nên ưu tiên PO trước để refinement backlog, tránh họp lớn làm chậm iteration. Chỉ mời stakeholders nếu PO cần input sau.

• Estimate the related cost and ask for a project extension.
  ❌ Sai. Dự án có fixed release date, việc ước lượng chi phí và yêu cầu gia hạn vi phạm nguyên tắc Agile time-boxed iterations (Agile Practice Guide, p. 32). Agile ưu tiên điều chỉnh scope thay vì thời gian; extension cần change control board, không linh hoạt.

• Increase the capacity of the team to include the missed feature.
  ❌ Sai. Tăng capacity (thêm người) thường gây giảm hiệu suất (Brooks' Law: adding manpower to late software project makes it later). Agile nhấn mạnh team ổn định, velocity tự nhiên (PMBOK 7th Ed., 6.4.2); không giải quyết gốc rễ thiếu sót ở backlog mà chỉ che đậy vấn đề.

📚 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021): Chapter 4 (Project Delivery Principles), đặc biệt Agile Hybrid approaches.
• Agile Practice Guide (2021): Sections on Product Backlog và Iteration Planning (PMI).
• Scrum Guide (2020/2025 updates): Product Owner responsibilities (scrumguides.org).
• PMP Exam Content Outline (2024-2026): Domain III (Business Environment) & IV (Delivery), 50% Agile/Hybrid questions.

🧩 Kết luận: Hành động đúng giúp dự án tuân thủ quy định mà vẫn giữ Agile mindset: adapt nhanh, ưu tiên giá trị! 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 xoay quanh vai trò của Project Manager (PM) như một servant leader (lãnh đạo phục vụ) trong bối cảnh chuyển đổi sang Agile teams. Cụ thể:

• Một Senior Vice President (SVP) yêu cầu tạo thêm các agile teams để quản lý song song nhiều dự án có độ dài và độ phức tạp khác nhau.
• Điều này dẫn đến giảm thời gian PM dành cho từng dự án (PM thường chỉ dành 50% thời gian cho dự án, bất kể độ phức tạp).
• Thách thức chính: Tăng tải công việc cho PM, nhưng cần hỗ trợ transformation (chuyển đổi) sang mô hình Agile hiệu quả.
  Mục tiêu: PM phải hành động như servant leader – tập trung vào việc hỗ trợ đội ngũ tự chủ, phát triển kỹ năng, thay vì kiểm soát trực tiếp (theo nguyên tắc Agile trong PMBOK® Guide 7th Edition và Agile Practice Guide).

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

Đáp án đúng: Empower the team to develop the necessary skills to move the project forward independently.

🛠️ Lý do chi tiết:

• Trong vai trò servant leader, PM không nên "làm thay" mà trao quyền (empower) cho đội ngũ Agile tự phát triển kỹ năng để tiến bộ độc lập. Điều này phù hợp với transformation sang Agile, giúp giảm phụ thuộc vào PM và tối ưu hóa thời gian hạn chế (chỉ 50%).
• Agile nhấn mạnh self-organizing teams (đội ngũ tự tổ chức), nơi PM hỗ trợ phát triển năng lực thay vì micromanage. Hành động này trực tiếp giải quyết vấn đề tải công việc bằng cách tăng tính tự chủ của team, thúc đẩy hiệu quả song song nhiều dự án.
• Theo PMBOK® 7th Edition (Principle 9: Leadership) và Agile Practice Guide, servant leadership ưu tiên empower team để đạt giá trị cao hơn.

📋 Phân tí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 nguyên tắc Servant Leadership và Agile Transformation (cập nhật đến PMBOK® 7th Edition 2021 và các hướng dẫn Agile đến 2026).

• ❌ Review the organizational process assets (OPAs) to evaluate mitigation plans for similar risks.
  🛠️ Giải thích sai: Phương án này tập trung vào quản lý rủi ro truyền thống (xem xét OPAs để tìm kế hoạch giảm thiểu rủi ro tương tự). Tuy nhiên, đây không phải hành động của servant leader trong Agile – nó mang tính hành chính thụ động, không trao quyền cho team hay hỗ trợ transformation. Rủi ro ở đây là về năng lực PM, không phải rủi ro dự án cần OPAs.

• ❌ Create a risk entry regarding the project manager's capacity and develop a mitigation plan.
  🛠️ Giải thích sai: Tạo rủi ro về năng lực PM và lập kế hoạch giảm thiểu là cách tiếp cận risk management (Process 11.7 trong PMBOK® 6th, nhưng ít phù hợp Agile). Servant leader không nên tự "ghi rủi ro cá nhân" mà phải hỗ trợ team tự giải quyết, tránh mindset "victim" thay vì empower.

• ✅ Empower the team to develop the necessary skills to move the project forward independently.
  🛠️ Giải thích đúng: Như đã phân tích ở trên, đây là hành động cốt lõi của servant leader – trao quyền phát triển kỹ năng độc lập, giúp team Agile tự quản lý dự án song song, giảm tải cho PM. Hoàn hảo cho transformation!

• ❌ Issue a change request to hire additional project managers based on the increased workload.
  🛠️ Giải thích sai: Đề xuất change request tuyển thêm PM là giải pháp tăng nguồn lực truyền thống (Integrated Change Control), nhưng trái với tinh thần Agile/servant leader – vốn ưu tiên tối ưu hóa team hiện tại thay vì mở rộng PM. Điều này không hỗ trợ tự chủ mà tạo phụ thuộc lâu dài.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Principle 9 (Leadership) & Section 4.6 (Team Management) – Nhấn mạnh servant leadership và empower teams.
• Agile Practice Guide (2017, cập nhật PMI 2023-2026): Chương 3 (Servant Leadership) & Chương 5 (Team Self-Organization).
• PMI Code of Ethics (2022): Trách nhiệm lãnh đạo phục vụ và hỗ trợ transformation.
  (Nguồn chính thức từ PMI.org, kiến thức cập nhật đến 2026 qua các webinar PMI Agile Certified Practitioner).

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

🧩 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 làm việc trong đội ngũ Agile cross-functional (đội ngũ đa chức năng linh hoạt). Dự án phát triển phần mềm có nhiều tính năng (features), ước tính mất khoảng 1 năm để hoàn thành toàn bộ. Tuy nhiên, CEO yêu cầu giải pháp phải đạt mục tiêu kinh doanh (business goals) vào cuối năm, chỉ còn 6 tháng nữa.

🛠️ Vấn đề cốt lõi: PM cần cân bằng nhu cầu và kỳ vọng của các bên liên quan (stakeholders), đặc biệt trong môi trường Agile nơi dự án có thể linh hoạt deliver giá trị theo từng iteration/release. Câu hỏi tập trung vào quy trình align stakeholders theo nguyên tắc Agile hybrid trong PMP, nhấn mạnh việc ưu tiên giá trị kinh doanh cao trước, thay vì cố gắng hoàn thành toàn bộ scope trong thời hạn ngắn.

📘 Kiến thức PMP liên quan (cập nhật PMBOK 7th Edition 2021 & Agile Practice Guide 2021, hiệu lực đến 2026): Trong Agile, PM sử dụng Product Backlog được ưu tiên (prioritized) dựa trên value (ví dụ MoSCoW, WSJF) và Release Roadmap để lập kế hoạch releases định kỳ, giúp align stakeholders với Minimum Viable Product (MVP) hoặc Minimum Business Increment (MBI) trong 6 tháng đầu.

✅ Đáp án đúng & Lý do lựa chọn

Đáp án đúng: Work with the stakeholders to create a prioritized backlog and release a roadmap.

Lý do:
✅ Phương án này hoàn hảo align với nguyên tắc Agile trong PMP. PM hợp tác với stakeholders để tạo Product Backlog được ưu tiên (dựa trên business value, risk, dependencies), sau đó xây dựng Release Roadmap (lộ trình phát hành theo sprint/release cycles). Điều này cho phép deliver high-value features trong 6 tháng đầu để đáp ứng CEO, đồng thời quản lý kỳ vọng cho phần còn lại. Không thay đổi scope cứng nhắc mà tối ưu hóa value delivery.
🛠️ Lợi ích: Tăng transparency, adaptability, và stakeholder satisfaction (theo Agile Principle #1: Satisfy customer through early and continuous delivery).

📘 Nguồn: PMBOK 7th Ed. (Section 4.5.1 Product Backlog; Agile Practice Guide p. 46-48 Release Planning; Scrum Guide 2020: Product Backlog Refinement).

📋 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 với lý do cụ thể dựa trên PMP Agile:

• Work with the stakeholders to create a prioritized backlog and release a roadmap.
  ✅ ĐÚNG (như đã giải thích ở trên). 🏆 Đây là best practice Agile để align expectations qua prioritization và roadmap, tránh overcommitment.

• Modify the requirements to those that can be completed in 6 months.
  ❌ SAI. Việc thay đổi requirements một cách tùy tiện (chỉ chọn những gì fit 6 tháng) vi phạm nguyên tắc Agile về emergent requirements và stakeholder collaboration. Có thể bỏ lỡ high-value items hoặc gây scope creep sau này. Thay vào đó, phải prioritize backlog thay vì "cắt xén" scope.
  📘 Nguồn: PMBOK 7th (6.2.3.2 Prioritization Techniques; Agile Practice Guide p. 32: Avoid Scope Reduction without Value Assessment).

• Implement fast-tracking and crashing activities to complete the project in 6 months.
  ❌ SAI. Fast-tracking (làm song song tasks) và crashing (thêm resources để rút ngắn) là kỹ thuật Predictive/Waterfall (Schedule Compression), không phù hợp Agile team cross-functional. Agile ưu tiên sustainable pace, không rush có thể tăng risk/technical debt. Dự án 1 năm cần iterative delivery, không "ép" hoàn thành sớm.
  📘 Nguồn: PMBOK 7th (Section 6.5 Schedule Compression; Agile Practice Guide p. 67: Reject Waterfall Tactics in Agile Contexts).

• Include all stakeholders in daily scrum meetings to keep them informed.
  ❌ SAI. Daily Scrum dành riêng cho Development Team (max 10 người, 15 phút) để inspect/adapt work, không phải nơi inform stakeholders. Stakeholders tham gia Sprint Review/Refinement hoặc Backlog Grooming, tránh làm gián đoạn team flow và vi phạm Agile ceremonies. Có thể gây overload và giảm productivity.
  📘 Nguồn: Scrum Guide 2020 (Daily Scrum section); PMBOK 7th (Section 4.6 Agile Ceremonies: Stakeholder roles in Review, not Daily).

🧩 Kết luận: Phương án đúng thúc đẩy value-driven Agile delivery, giúp PM align CEO với business goals mà không hy sinh chất lượng. Áp dụng ngay trong thực tế PMP! 🚀