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 chủ đề quản lý lịch trình dự án (Schedule Management) và quản lý rủi ro đội ngũ (Team Management) trong PMP, dựa trên PMBOK® Guide – Seventh Edition (cập nhật đến 2023 và áp dụng cho kỳ thi PMP đến 2026). Tình huống mô tả: Một số thành viên chính (key team members) đột ngột rời khỏi đội ngũ dự án. Các thành viên còn lại gặp khó khăn trong việc nắm bắt chi tiết công việc cũ, dẫn đến tiến độ chậm chạp và lịch trình dự án bị trì hoãn nghiêm trọng (seriously delayed).
📌 Mục tiêu câu hỏi: Kiểm tra khả năng của Project Manager (PM) trong việc xử lý vấn đề thực tế, ưu tiên điều chỉnh kế hoạch linh hoạt thay vì các giải pháp phản ứng vội vã. Theo nguyên tắc PMP mới, PM phải áp dụng Adaptive Planning (lập kế hoạch thích ứng) và Holistic Risk Management để đảm bảo giao giá trị (value delivery) mà không làm gián đoạn dự án.

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

Đáp án đúng: Review the issues and adjust the project plan to give a realistic schedule.

🛠️ Lý do chi tiết:

• PM cần đầu tiên đánh giá vấn đề (Review the issues) để hiểu rõ nguyên nhân gốc rễ (root cause), như kiến thức bị mất mát từ key members hoặc lỗ hổng training. Sau đó, điều chỉnh kế hoạch dự án (adjust the project plan) để tạo lịch trình thực tế (realistic schedule), có thể bằng cách sử dụng Crashing, Fast-Tracking hoặc re-baselining theo Process 6.5 Control Schedule (PMBOK 7).
• Điều này phù hợp với 12 Principles of PMP (Optimize Risk Responses & Think Integrally), nhấn mạnh việc chấp nhận thay đổi và điều chỉnh kế hoạch thay vì né tránh vấn đề. Nó đảm bảo dự án tiếp tục mà không cần tài nguyên mới ngay lập tức, tránh chi phí phát sinh.
  📘 Nguồn tham khảo: PMBOK® Guide 7th Edition, Domain 3: Project Work (Section 3.2.3 Manage Project Changes); PMP Exam Content Outline 2021 (Tasks 7.1-7.5 về Schedule Control).

📋 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 theo thứ tự, với lý do dựa trên best practices PMP. Tôi giữ nguyên văn bản gốc tiếng Anh, chỉ giải thích bằng tiếng Việt:

• ❌ Request additional resources to be incorporated to the project team.
  Sai vì: Việc yêu cầu tài nguyên mới (additional resources) là giải pháp phản ứng ngắn hạn, có thể dẫn đến chi phí tăng cao (cost overrun) và không giải quyết gốc rễ vấn đề kiến thức (knowledge gap). Theo PMBOK 7, PM phải đánh giá trước khi allocate resource (Resource Optimization Techniques), tránh Brooks' Law ("Adding manpower to a late software project makes it later").

• ❌ Observe the project team and give them time to catch up before escalating.
  Sai vì: Chỉ quan sát và chờ đợi (observe and give time) là thụ động (passive), làm trì hoãn thêm và vi phạm nguyên tắc Proactive Monitoring & Control. PMP yêu cầu PM can thiệp kịp thời (Timely Decision Making), không chờ đến khi escalate mới hành động, vì lịch trình đã "seriously delayed".

• ❌ Escalate to the project sponsor and seek alternatives to resolve the issue.
  Sai vì: Escalate ngay lập tức đến sponsor là tránh né trách nhiệm của PM. Theo Escalation Process trong PMBOK 7 (Stakeholder Engagement), chỉ escalate sau khi PM đã phân tích và đề xuất giải pháp (Issue Log Management). Điều này có thể làm mất lòng tin từ sponsor và không khuyến khích self-organization trong đội ngũ.

• ✅ Review the issues and adjust the project plan to give a realistic schedule.
  Đúng vì: Như đã giải thích ở trên, đây là cách tiếp cận tích hợp và thực tế nhất (Integrated Change Control), ưu tiên replan để align với thực tế (Earned Value Management adjustments). Nó thể hiện Tailoring (tùy chỉnh phương pháp) phù hợp với cả Predictive và Agile approaches trong PMP mới.

🧠 Kết luận & Lời khuyên PMP: Luôn ưu tiên Perform Integrated Change Control (Process 4.6) trước mọi quyết định lớn. Thực hành qua mock exams để nắm vững! 📘 Tài liệu bổ sung: Agile Practice Guide (PMI, 2017); The Standard for Project Management (2021).

🧩 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 trong PMP (phiên bản PMBOK Guide 7th Edition và Agile Practice Guide cập nhật đến 2026). Dự án đang ở giữa iteration thứ 5 (tương đương Sprint trong Scrum), nghĩa là đang thực hiện công việc theo chu kỳ lặp ngắn hạn. Bất ngờ xảy ra suy thoái kinh tế, dẫn đến doanh thu giảm mạnh và chiến lược công ty yêu cầu cắt giảm chi phí ngay lập tức. Đây là tình huống thay đổi ưu tiên chiến lược (strategic change), buộc project manager phải hành động nhanh chóng để cân bằng giá trị kinh doanh với ràng buộc tài chính. Câu hỏi tập trung vào hành động tiếp theo tốt nhất của project manager, nhấn mạnh vai trò phối hợp với các bên liên quan trong môi trường Agile, nơi tính linh hoạt và reprioritization là cốt lõi.

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

Đáp án đúng: Schedule a meeting with the product owner, discuss priorities and decide if anything from the backlog can be eliminated, based on current constraints.

Lý do: Trong Agile/Scrum, Product Owner (PO) chịu trách nhiệm chính về Product Backlog (danh sách công việc ưu tiên theo giá trị kinh doanh). Khi có thay đổi chiến lược như cắt giảm chi phí, project manager phải hợp tác ngay với PO để thảo luận ưu tiên, loại bỏ hoặc giảm items không cần thiết từ backlog, đảm bảo sprint hiện tại và tương lai phù hợp với ràng buộc mới. Điều này tuân thủ nguyên tắc Value-Driven Delivery (PMBOK 7th, Principle 1: Be a diligent, respectful, and caring steward) và Adaptive Planning (Agile Practice Guide). Hành động này nhanh chóng, tập trung vào giá trị, tránh lãng phí mà không gián đoạn sprint một cách không cần thiết.

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

• Continue the current sprint without interruption and address priorities in the upcoming product backlog grooming sessions.
  ❌ Sai: Phương án này bỏ qua thay đổi chiến lược khẩn cấp (cắt giảm chi phí ngay lập tức). Trong Agile, backlog grooming (refinement) chỉ diễn ra định kỳ, không phù hợp với tình huống đột xuất. Tiếp tục sprint mà không điều chỉnh sẽ dẫn đến lãng phí tài nguyên (waste), vi phạm nguyên tắc Optimize Value Delivery (Agile Practice Guide). Project manager phải hành động ngay lập tức, không chờ grooming.

• Meet with the sponsor for guidance on the best path forward before executing sprints.
  ❌ Sai: Sponsor (tài trợ viên) cung cấp hướng chiến lược cao cấp, nhưng trong Agile, quyết định chi tiết backlog thuộc PO, không phải sponsor. Việc gặp sponsor trước có thể chậm trễ và làm lệch vai trò (PMBOK 7th, Role of Sponsor vs. Product Owner). Scrum Guide nhấn mạnh PO là người đại diện giá trị kinh doanh, project manager nên ưu tiên phối hợp với PO để reprioritize nhanh chóng.

• Allow the project team to decide on the best path forward for the current sprint.
  ❌ Sai: Development Team chỉ thực hiện công việc (self-organizing), không quyết định ưu tiên giá trị kinh doanh hoặc backlog – đó là trách nhiệm của PO. Để team quyết định sẽ dẫn đến quyết định chủ quan, không phù hợp với thay đổi chiến lược công ty, vi phạm Scrum Roles (Scrum Guide 2020, cập nhật 2025: rõ ràng phân vai). Project manager phải hướng dẫn và phối hợp, không ủy quyền toàn bộ.

• Schedule a meeting with the product owner, discuss priorities and decide if anything from the backlog can be eliminated, based on current constraints.
  ✅ Đúng: Như đã giải thích ở trên, đây là hành động tối ưu nhất, tập trung vào reprioritization backlog với PO để đối phó ràng buộc chi phí. Hỗ trợ iteration review/adjustment linh hoạt (PMBOK 7th, Agile Hybrid Approaches).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật 2026): Principle 12 (Navigate Complexity) và Agile Chapter – Nhấn mạnh adaptive response to change.
• Agile Practice Guide (7th Edition): Section 4.2 Product Backlog Management và 6.3 Servant Leadership.
• Scrum Guide (2020, reaffirm 2025): Product Owner accountability for backlog và Scrum Events (Sprint Planning/Refinement).
• PMP Exam Content Outline (2024-2026): Domain III: Business Environment (27%) – Xử lý strategic changes trong Agile contexts.

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 trong một dự án Agile, nơi Project Manager (PM) thu thập thông tin, tổng hợp các chỉ số đo lường (metrics) như năng suất đội ngũ. PM phát hiện đội ngũ có slack (dư thừa thời gian, năng suất giảm), cụ thể số lượng items gửi đến development mỗi người giảm 10%. Sau khi áp dụng Root Cause Analysis (RCA), nguyên nhân gốc rễ là thiếu kiến thức về một framework dùng cho modeling.

Câu hỏi yêu cầu: PM nên làm gì tiếp theo để xử lý vấn đề này?
Đây là tình huống kiểm tra kiến thức PMP về quản lý đội ngũ Agile, tập trung vào nguyên tắc tối ưu hóa giá trị, phát triển đội ngũ nội bộ, theo PMBOK Guide 7th Edition và Agile Practice Guide (cập nhật mới nhất đến 2026, nhấn mạnh Servant Leadership, self-organizing teams và knowledge sharing thay vì giải pháp bên ngoài tốn kém).

📘 Nguồn tham khảo:

• PMBOK® Guide – Seventh Edition (Project Management Institute, 2021, vẫn là chuẩn mới nhất 2026).
• Agile Practice Guide (PMI, 2017, tích hợp PMBOK 7).
• PMP Examination Content Outline (Domain 4: People – Team Performance).

✅ Đáp án đúng: Foster knowledge sharing and coaching among team members

Lý do chọn đáp án này:
Trong môi trường Agile, khi RCA xác định vấn đề là thiếu kiến thức nội bộ, bước tiếp theo lý tưởng là thúc đẩy chia sẻ kiến thức và coaching giữa các thành viên đội ngũ 🛠️. Điều này phù hợp với nguyên tắc Agile: ưu tiên individuals and interactions (tương tác cá nhân), xây dựng đội ngũ tự quản (self-organizing), và Servant Leadership của PM – giúp đội ngũ tự giải quyết vấn đề mà không cần can thiệp bên ngoài. Hành động này tiết kiệm chi phí, nhanh chóng, tận dụng kiến thức sẵn có trong đội (có thể một số thành viên đã biết framework), đồng thời tăng cường team cohesion và productivity bền vững. Theo PMBOK 7 (Principle 9: Teamwork), coaching nội bộ là công cụ chính để cải thiện performance domain "Team".

📋 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 Agile best practices:

• Add new members for the underperforming team
  ❌ Sai: Việc thêm thành viên mới không giải quyết root cause (thiếu kiến thức framework), mà còn có thể làm gián đoạn đội ngũ Agile (tăng onboarding time, giảm velocity). Trong Agile, ưu tiên phát triển đội ngũ hiện tại thay vì thay thế (PMBOK 7: Avoid resource substitution in high-performing teams). Điều này vi phạm nguyên tắc optimize to value vì tốn kém và chậm trễ.

• Seek an external expert to review the framework
  ❌ Sai: Thuê chuyên gia bên ngoài là giải pháp tạm thời, chi phí cao, không khuyến khích đội ngũ tự học (self-sufficiency). Agile nhấn mạnh internal knowledge transfer thay vì dependency bên ngoài, đặc biệt khi lịch trình chặt chẽ. Theo Agile Practice Guide, external review chỉ dùng cho critical risks, không phải knowledge gap nội bộ.

• Arrange for external training amid the tight project schedules
  ❌ Sai: Tổ chức đào tạo bên ngoài không khả thi với tight schedules (có slack nhưng dự án Agile ưu tiên deliver value nhanh). Training external thường mất thời gian dài, gián đoạn sprint, và không đảm bảo retention kiến thức. PMBOK 7 (Model for Team Performance) ưu tiên on-the-job coaching hơn formal training cho vấn đề nhỏ như 10% giảm.

• Foster knowledge sharing and coaching among team members
  ✅ Đúng: Như đã giải thích ở trên, đây là bước next logic sau RCA, tận dụng nội lực đội ngũ, phù hợp 100% với Agile principles (Daily Stand-ups, Pair Programming, Retrospectives để share knowledge). Tăng team maturity level (Team Performance Domain).

🛠️ Khuyến nghị PMP: Trong thực tế, PM nên tổ chức retrospective hoặc workshop nội bộ ngay sprint tiếp theo để coaching, theo dõi metrics sau 1-2 sprint để verify cải thiện!

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

Câu hỏi mô tả một tình huống thực tế trong quản lý dự án liên quan đến đội ngũ hỗ trợ khách hàng (customer support team). Họ đã lập kế hoạch với các chu kỳ ngắn, lặp lại (short, iterative cycles) để xử lý các vấn đề do khách hàng báo cáo. Tuy nhiên, gần đây xảy ra sự gia tăng đột biến các vấn đề ưu tiên cao (surge of high-priority issues), dẫn đến gián đoạn kế hoạch gốc và khiến quản lý khó khăn trong việc theo dõi tiến độ (difficult to manage the progress).

🛠️ Vấn đề cốt lõi: Đây là môi trường làm việc liên tục (continuous flow) với công việc đến ngẫu nhiên, cần ưu tiên linh hoạt, xử lý thay đổi nhanh chóng mà không bị ràng buộc bởi lịch trình cố định. Project manager cần gợi ý phương pháp phù hợp để tối ưu hóa luồng công việc, giảm tắc nghẽn và dễ dàng quản lý tiến độ.

📘 Kiến thức PMP cập nhật (PMBOK 7th Edition & Agile Practice Guide 2021, hiệu lực đến 2026): Trong môi trường Agile/Hybrid, cần chọn phương pháp hỗ trợ pull-based system (kéo công việc khi sẵn sàng), giới hạn công việc đang làm (WIP limits), và visualize workflow để xử lý biến động cao.

✅ Đáp án đúng: Agile Kanban approach

Lý do lựa chọn:

• Kanban lý tưởng cho tình huống này vì nó không có chu kỳ thời gian cố định (no fixed iterations), cho phép đội ngũ kéo công việc (pull items) từ backlog dựa trên ưu tiên thực tế, dễ dàng xử lý surge of high-priority issues mà không gián đoạn toàn bộ kế hoạch.
• Các công cụ như Kanban board giúp visualize tiến độ, áp dụng WIP limits để tránh overload, và liên tục cải tiến (continuous improvement) qua metrics như lead time/cycle time.
• Phù hợp với operational/support teams như customer support, nơi công việc đến on-demand và cần flow efficiency cao.

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

• Agile Scrum approach ❌
  Sai vì: Scrum sử dụng sprint cố định (time-boxed iterations, thường 1-4 tuần), với planning, daily stand-up, review/retrospective. Khi có surge high-priority issues, việc thay đổi giữa sprint sẽ gây scope creep hoặc phải chờ sprint tiếp theo, làm khó quản lý tiến độ. Không linh hoạt cho flow liên tục như support team (theo Agile Practice Guide, Scrum phù hợp dự án có scope ổn định hơn).

• Agile Kanban approach ✅
  Đúng vì: Như đã giải thích ở trên, Kanban tập trung vào visualize workflow (Kanban board), WIP limits, và pull system, giúp xử lý biến động ưu tiên cao mà không cần reset chu kỳ. Hoàn hảo cho customer-reported issues liên tục (PMBOK 7.2.3 & Agile Practice Guide, Section 6.3).

• Spiral approach ❌
  Sai vì: Spiral là mô hình waterfall lai prototype risk-driven, với các vòng lặp tập trung quản lý rủi ro lớn qua planning-risk-analysis-prototype-evaluate. Không phù hợp cho support team với issues nhỏ, lặp lại; quá phức tạp và không agile cho surge issues hàng ngày (PMBOK 4.5, mô hình predictive).

• Rapid application development approach ❌
  Sai vì: RAD nhấn mạnh prototyping nhanh và user feedback để phát triển phần mềm nhanh chóng, với phases như requirements planning, user design, construction, cutover. Phù hợp phát triển ứng dụng mới, không phải xử lý issues hỗ trợ khách hàng liên tục; thiếu cơ chế flow management cho high-priority surge (PMBOK 2.3.2, mô hình adaptive cho dev projects).

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021): Chương 4 (Lifecycle) & Chương 9 (Project Agile) – Nhấn mạnh Kanban cho continuous delivery.
• Agile Practice Guide (2021): Section 6 (Kanban) & Section 4 (Lifecycle Selection) – Kanban vs. Scrum so sánh rõ ràng.
• PMI Standards đến 2026: Không thay đổi core concepts này trong các update gần nhất (xem PMI.org cho Process Groups mới nhất).

🛠️ Khuyến nghị PMP: Áp dụng Kanban để chuyển từ iterative sang flow-based, kết hợp metrics như throughput để manager dễ theo dõi!

📘 Phân tích chi tiết câu hỏi trắc nghiệm PMP về Agile Project Management

🧩 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 dự án Agile mới hình thành (newly formed agile project). Nhà tài trợ (sponsor) đang gặp khó khăn trong việc nắm bắt phạm vi dự án (scope) và xác định thời điểm các tính năng sản phẩm quan trọng (critical product features) sẵn sàng sử dụng. Đây là vấn đề phổ biến ở giai đoạn đầu Agile, khi chưa có tầm nhìn rõ ràng (vision), backlog chưa được phân tích và ưu tiên, dẫn đến thiếu thông tin về lộ trình phát hành (release plan). Project manager cần hành động phù hợp với nguyên tắc Agile: tập trung vào giao giá trị nhanh chóng, minh bạch và linh hoạt, thay vì lập kế hoạch chi tiết cứng nhắc như Waterfall. Theo PMBOK 7th Edition, điều này liên quan đến principle 1: Be a diligent, respectful, and caring steward và principle 12: Navigate complexity, kết hợp với Agile Practice Guide về lập Product Backlog và Release Planning.

✅ Đáp án đúng:
Establish the project vision, break down the mam features backlog, prioritize, and create an overall release plan.
(Lưu ý: Có lỗi chính tả nhỏ trong câu gốc "mam" có lẽ là "main").

Lý do lựa chọn: Phương án này trực tiếp giải quyết vấn đề cốt lõi của sponsor bằng cách xây dựng tầm nhìn dự án (project vision) để làm rõ scope tổng quát, phân tích backlog tính năng chính (break down main features backlog), ưu tiên (prioritize) theo giá trị kinh doanh (ví dụ: MoSCoW hoặc WSJF), và tạo kế hoạch phát hành tổng thể (overall release plan) để dự báo thời gian features sẵn sàng. Đây là các bước đầu tiên chuẩn trong Agile (theo Scrum/Kanban hybrid), giúp sponsor có cái nhìn chiến lược mà không làm gián đoạn team. Nó phù hợp với Product Roadmap và Release Planning trong Agile Practice Guide, đảm bảo minh bạch và giao giá trị liên tục (value delivery).

🛠️ Phân tích tất cả các phương án (dùng emoji để phân biệt đúng/sai):

• ❌ [SAI] Move the team’s kanban board to a more visible place to improve the communication with key stakeholders.
  Phương án này chỉ cải thiện hiển thị công việc hàng ngày (daily work visibility) qua Kanban board, nhưng không giải quyết vấn đề scope tổng thể hay timeline features lớn. Sponsor cần tầm nhìn chiến lược cao hơn, không phải chi tiết board (có thể gây nhiễu). Không phù hợp giai đoạn đầu dự án mới.

• ❌ [SAI] Create a detailed project management plan with all planned releases and the tasks needed to deliver them.
  Đây là cách tiếp cận Waterfall truyền thống (detailed plan với tasks cố định), trái ngược nguyên tắc Agile: "working software over comprehensive documentation". Dự án Agile tránh kế hoạch chi tiết upfront vì scope có thể thay đổi; thay vào đó dùng iterative planning. Vi phạm Agile Manifesto principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

• ✅ [ĐÚNG] Establish the project vision, break down the mam features backlog, prioritize, and create an overall release plan.
  Như đã giải thích ở trên: Hoàn hảo cho Agile, tập trung vào vision, backlog refinement, prioritization và high-level release plan để sponsor nắm scope & timeline mà không micromanage.

• ❌ [SAI] Invite the stakeholder to the project’s daily meetings, providing better visibility on what the team is working on.
  Mời sponsor vào daily standup (15 phút/ngày) chỉ cho visibility tactical ngắn hạn, không phù hợp với sponsor cấp cao (có thể làm team mất focus và vi phạm nguyên tắc "team self-organizing"). Sponsor nên tham gia Sprint Review/Planning hoặc stakeholder demos, không phải daily meetings.

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

• PMBOK® Guide – Seventh Edition (PMI, 2021): Phần Agile/Hybrid approaches, Principles 3 (Focus on value), 9 (Optimize risk), và Models như Product Backlog và Release Cadence (trang 77-92).
• Agile Practice Guide (PMI, 2021): Chương 3 (Life Cycle Selection), Chương 5 (Team & Organization), và Appendix về Release Planning/Product Vision (cập nhật không thay đổi lớn đến 2026 theo PMI standards).
• PMI Agile Certified Practitioner (PMI-ACP) Handbook: Nhấn mạnh backlog prioritization và vision statement ở dự án Agile mới.

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 nội dung câu hỏi

Câu hỏi này thuộc chủ đề Quản lý Rủi ro (Manage Risk) trong PMP, cụ thể là tình huống rủi ro đã xảy ra (risk realized) trong giai đoạn Khởi tạo dự án (Initiation).

• Tình huống chính: Một rủi ro được xác định ngay từ đầu dự án: Nhà cung cấp ngừng hỗ trợ phần mềm (software support) cho một input cần thiết của dự án.
• Hành động đã thực hiện: Project Manager (PM) đã lập ngân sách dự phòng (reserve budget) – đây là Contingency Reserve dành cho rủi ro đã biết (known risk), nhằm đảm bảo dự án có thể tiếp tục nếu rủi ro xảy ra.
• Câu hỏi yêu cầu: PM nên làm gì tiếp theo khi rủi ro này đã thực sự xảy ra (discontinued software support)?

Mục tiêu là chọn hành động phù hợp nhất theo PMBOK Guide 7th Edition (2021) và cập nhật PMP đến 2026, nhấn mạnh vào Performance Domain: Uncertainty (miền không chắc chắn), nơi PM phải invoke response plan (kích hoạt kế hoạch ứng phó), escalate (báo cáo leo thang) lên cấp cao hơn nếu cần quyết định lớn, và sử dụng reserve một cách có kiểm soát qua governance (quản trị dự án). Không hoảng loạn dừng dự án hay tự quyết định mà không thông báo.

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

• PMBOK® Guide 7th Edition, Section 4.6 Manage Project Risk (trang 91-93): Khi risk trigger, PM phải monitor, assess impact, và escalate nếu vượt quyền hạn.
• PMP Examination Content Outline (2021, cập nhật 2024): Domain IV. Business Environment (15%) & Domain V. Uncertainty (12%) – nhấn mạnh escalate realized risks to sponsor.

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

Đáp án đúng: Inform the sponsor that the risk has been realized and that a decision has to be made for the project to continue.

Lý do 🛠️:

• Rủi ro đã realized (xảy ra), PM cần escalate ngay lập tức lên Sponsor (người tài trợ) vì đây là quyết định chiến lược liên quan đến sử dụng reserve budget hoặc thay đổi kế hoạch dự án. Sponsor có thẩm quyền phê duyệt change request hoặc giải ngân reserve.
• PM đã chuẩn bị reserve, nhưng không tự ý sử dụng mà phải thông qua governance process để tránh scope creep hoặc lãng phí. Điều này tuân thủ nguyên tắc Stewardship và Stakeholders trong PMBOK 7th.
• Hành động này đảm bảo tiếp tục dự án một cách minh bạch, phù hợp với Risk Response Implementation (11.5 trong PMBOK 6th/7th hybrid).

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

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, chỉ phân tích bằng tiếng Việt:

• Tell the project team to stop work, as software support will be canceled and the project cannot continue.
  ❌ Sai hoàn toàn. Hành động này là hoảng loạn và tiêu cực, vi phạm nguyên tắc Value Delivery (giao giá trị). Dự án có reserve budget để tiếp tục, không nên dừng team ngay lập tức mà phải assess impact và escalate. Dừng công việc sẽ gây delay không cần thiết, lãng phí thời gian và tài nguyên (PMBOK 7th, 4.6.1).

• Advise the supplier that the sponsor will pay for software support as previously planned.
  ❌ Sai. PM không có quyền cam kết tài chính thay Sponsor, đặc biệt khi supplier đã discontinued support (ngừng chính thức). Đây là unauthorized commitment, vi phạm Procurement Management và nguyên tắc Responsibility. Phải escalate trước để Sponsor quyết định chi trả hay dùng reserve (PMBOK 7th, 4.7 Manage Project Change).

• Ask the supplier to continue providing software support until the end of the project.
  ❌ Sai. Supplier đã thông báo ngừng hỗ trợ, việc "xin" tiếp tục là không thực tế và thiếu chuyên nghiệp, có thể làm yếu vị thế đàm phán. PM phải theo response plan đã lập (reserve), không tự negotiate mà escalate để Sponsor xử lý hợp đồng nếu cần (PMBOK 7th, Uncertainty Domain: Avoid wishful thinking).

• Inform the sponsor that the risk has been realized and that a decision has to be made for the project to continue.
  ✅ Đúng. Như đã giải thích ở trên, đây là hành động escalate kịp thời, kích hoạt decision-making process từ Sponsor. Đảm bảo dự án tiếp tục với controlled reserve usage, tuân thủ holistic risk management (PMBOK 7th, trang 92).

🧠 Kết luận PMP: Luôn ưu tiên proactive escalation khi risk realized, đặc biệt ở Initiation phase, để bảo vệ project objectives! Nếu cần thực hành thêm, tham khảo PMI.org cho mock exams. 🚀

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

Câu hỏi tập trung vào cách tiếp cận ủy quyền (delegation) trong quản lý dự án, đặc biệt với một đội ngũ toàn cầu (global team) mà Project Manager (PM) đã làm việc trước đây, có mức độ tin cậy cao (high level of trust). Đội ngũ phân bố ở các quốc gia và múi giờ khác nhau, đòi hỏi quyết định kịp thời (timely decisions) để dự án diễn ra suôn sẻ.

🛠️ Bối cảnh chính:

• Đội ngũ quen thuộc → Tin tưởng cao → Phù hợp ủy quyền rộng rãi.
• Khác múi giờ → Không thể chờ PM quyết định mọi thứ → Cần trao quyền tự chủ cao để tránh trì hoãn.
• Mục tiêu: Đảm bảo dự án mượt mà → Áp dụng nguyên tắc Servant Leadership và Empowered Teams trong PMBOK® Guide 7th Edition, nhấn mạnh ủy quyền và chia sẻ thông tin để thúc đẩy quyết định nhanh chóng, minh bạch.

✅ Đáp án đúng

Delegate most authorities and share information to allow fair decision-making.

Lý do lựa chọn 📈:

• Với lòng tin cao và nhu cầu quyết định kịp thời, PM nên ủy quyền hầu hết các quyền hạn (delegate most authorities) để đội ngũ tự quyết định mà không cần chờ đợi, phù hợp với Agile principles và Hybrid approaches trong PMP mới nhất (2021-2026).
• Đồng thời chia sẻ thông tin (share information) để đảm bảo quyết định công bằng, minh bạch, tăng cường sự gắn kết đội ngũ toàn cầu.
• Điều này tránh bottleneck do múi giờ, thúc đẩy team empowerment – một trụ cột trong 12 Principles of Project Management (PMBOK 7th).

🔍 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên PMBOK® Guide 7th Edition và PMP Exam Content Outline 2021 (cập nhật đến 2026).

• ❌ [SAI] Delegate certain authorities and share information to allow fair decision-making.
  Phân tích: Phương án này chỉ ủy quyền một số quyền hạn hạn chế (certain authorities), dẫn đến đội ngũ vẫn phải chờ PM ở các quyết định quan trọng → Không giải quyết vấn đề múi giờ và quyết định kịp thời. Dù chia sẻ thông tin tốt, nhưng ủy quyền hạn chế làm giảm hiệu quả đội ngũ có lòng tin cao.

• ✅ [ĐÚNG] Delegate most authorities and share information to allow fair decision-making.
  Phân tích: Như đã giải thích ở trên, đây là cách tiếp cận tối ưu: Ủy quyền hầu hết (most authorities) + chia sẻ thông tin → Tăng tốc độ quyết định, tận dụng lòng tin, đảm bảo công bằng. Phù hợp Value Delivery System và Team Performance Domain trong PMBOK 7th.

• ❌ [SAI] Delegate most authorities and control the authority by withholding important information.
  Phân tích: Ủy quyền hầu hết là tốt, nhưng giữ lại thông tin quan trọng (withholding information) vi phạm nguyên tắc minh bạch và lòng tin → Làm quyết định không công bằng, giảm động lực đội ngũ, trái với Stakeholder Engagement và Leadership competencies (PMP Code of Ethics).

• ❌ [SAI] Delegate certain authorities and control the authority by withholding important information.
  Phân tích: Kết hợp hai sai lầm lớn: Ủy quyền hạn chế + giữ thông tin → Hoàn toàn không hiệu quả, tạo micromanagement, phá vỡ lòng tin cao sẵn có, dẫn đến trì hoãn và xung đột trong đội ngũ toàn cầu.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Chương Team Domain (trang 77-83) và 12 Project Management Principles (Stewardship, Team, Stakeholders) – Nhấn mạnh ủy quyền và chia sẻ thông tin cho đội ngũ tự chủ.
• PMP Exam Content Outline (PMI, 2021 – cập nhật 2026): Domain 4: Team (27%) – "Empower team members and stakeholders".
• Agile Practice Guide (PMI): Phần "Servant Leadership" khuyến khích delegate authority rộng với trust cao.
• PMI Code of Ethics & Professional Conduct: Trách nhiệm Responsibility và Respect – Minh bạch thông tin.

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 câu hỏi trắc nghiệm PMP

📖 Giải thích nội dung câu hỏi:
Câu hỏi mô tả tình huống trong dự án: đã có một thời gian, các bên liên quan (stakeholders) đang nghi ngờ và tranh cãi về ai chịu trách nhiệm chính để giao (deliver) một lợi ích chính (key benefit) của dự án. Đây là vấn đề phổ biến trong quản lý dự án, liên quan đến việc làm rõ vai trò và trách nhiệm (roles and responsibilities) để đảm bảo dự án đạt được giá trị (value delivery). Theo PMP (dựa trên PMBOK Guide 7th Edition và cập nhật đến 2026), project manager (PM) phải chủ động quản lý stakeholders để giải quyết xung đột hoặc mơ hồ như vậy, tránh ảnh hưởng đến việc thực hiện lợi ích dự án. Bước tiếp theo cần tập trung vào hành động trực tiếp, hợp tác thay vì né tránh hoặc leo thang ngay lập tức. 🛠️

✅ Đáp án đúng:
Meet with the stakeholders involved to clearly define their roles and responsibilities with regard to the benefit.

Lý do lựa chọn (theo PMP mới nhất):
Theo nguyên tắc Stakeholder Engagement Management trong PMBOK 7th Edition (Domain 4: Stakeholder), PM phải ưu tiên gặp gỡ các bên liên quan để làm rõ roles & responsibilities liên quan đến lợi ích dự án. Điều này giúp giải quyết gốc rễ vấn đề (root cause: thiếu rõ ràng), thúc đẩy sự hợp tác và đảm bảo benefits realization. Đây là bước first response phù hợp, tránh làm phức tạp hóa tình huống. PM đóng vai trò trung tâm trong việc facilitate collaboration (12 Principles of PMBOK 7). 📘

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

• ✅ Đúng - Meet with the stakeholders involved to clearly define their roles and responsibilities with regard to the benefit.
  Phương án này trực tiếp giải quyết vấn đề bằng cách tổ chức họp với tất cả stakeholders liên quan để định nghĩa rõ ràng trách nhiệm về lợi ích. Điều này phù hợp với Stakeholder Management Plan và RACI Matrix (Responsible, Accountable, Consulted, Informed), giúp tránh hiểu lầm và đảm bảo alignment. Trong PMBOK 7, PM phải optimize engagement để deliver value. 🏆

• ❌ Sai - Understand the context of the situation and escalate the problem to the steering committee.
  Việc hiểu ngữ cảnh và leo thang ngay đến steering committee là quá sớm và né tránh trách nhiệm của PM. PM phải tự xử lý trước (manage at project level), chỉ escalate khi vượt quyền hạn (PMBOK 7, Principle 11: Escalate, Remove, Transition). Điều này có thể làm chậm tiến độ và giảm uy tín PM. 🚫

• ❌ Sai - Document the risk in the risk register and generate the risk responses and their respective associated plans.
  Vấn đề này không phải rủi ro (risk - uncertainty về sự kiện tương lai) mà là vấn đề quản lý roles hiện tại (issue/clarity gap). Risk Register dùng cho uncertainty (PMBOK 7, Domain 3: Uncertainty), không phải ghi nhận tranh cãi trách nhiệm. Xử lý sai sẽ lãng phí thời gian thay vì hành động trực tiếp. ⚠️

• ❌ Sai - Meet with the customer to obtain consensus with the recipient of the benefit and determine a means to deliver the benefit.
  Phương án này hạn chế chỉ gặp customer, bỏ qua tất cả stakeholders liên quan (có thể bao gồm team, sponsors, vendors). PMP nhấn mạnh holistic stakeholder engagement (không chỉ customer), tránh thiên vị và đảm bảo toàn diện (PMBOK 7, Stakeholder Sphere of Influence). Có thể bỏ sót trách nhiệm thực tế. 👥

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

• PMBOK Guide 7th Edition (2021, vẫn là chuẩn chính): Chapter 4 (Stakeholder), Principle 5 (Stakeholders), Tools như RACI và Engagement Assessment Matrix.
• PMP Exam Content Outline (2024-2026): Domain IV (Stakeholder - 17%), People Domain (42%).
• The Standard for Project Management (PMI, 2021): Nhấn mạnh benefits management và role clarity cho 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 nội dung câu hỏi

Câu hỏi mô tả tình huống một Project Manager (PM) được giao quản lý một dự án mới. Văn phòng Quản lý Dự án (PMO) và PM đồng ý rằng đây là cơ hội tốt để áp dụng daily standup meetings (các cuộc họp đứng hàng ngày ngắn gọn, thường dùng trong Agile/Scrum để đồng bộ hóa đội ngũ). Tuy nhiên, đội ngũ dự án chưa từng sử dụng công cụ này, và một số thành viên đang thách thức quyết định (có sự kháng cự hoặc xung đột).

🛠️ Vấn đề cốt lõi: PM cần xử lý sự kháng cự từ đội ngũ khi giới thiệu thực hành mới (daily standup), thuộc lĩnh vực quản lý đội ngũ và xung đột trong PMP. Theo PMBOK® Guide 7th Edition, điều này liên quan đến Team Performance Domain (miền Hiệu suất Đội ngũ), nơi nhấn mạnh việc xây dựng môi trường hợp tác, quản lý xung đột và thiết lập quy tắc chung để hỗ trợ các thực hành lặp (iterative/Agile).

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

Đáp án đúng: Define the ground rules, responsibilities, and conflict management strategies

Lý do:
Khi đội ngũ kháng cự thay đổi (như daily standup), PM phải thiết lập nền tảng hợp tác bằng cách định nghĩa ground rules (quy tắc chung), responsibilities (trách nhiệm rõ ràng) và conflict management strategies (chiến lược xử lý xung đột). Điều này giúp giải quyết kháng cự, xây dựng sự đồng thuận và thúc đẩy văn hóa Agile. Theo PMBOK® Guide 7th Edition (Team Performance Domain, trang 89-92) và Agile Practice Guide (phần Servant Leadership & Team Dynamics), đây là bước đầu tiên để Manage Team hiệu quả, tránh leo thang xung đột và đảm bảo đội ngũ chấp nhận công cụ mới mà không cần thay đổi nhân sự hay lịch trình.

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

• ❌ Update the project schedule to consider a daily standup as part of the project design phase
  Sai vì: Việc cập nhật lịch trình chỉ là hành động kỹ thuật (thuộc Schedule Management), không giải quyết nguyên nhân gốc rễ là kháng cự từ đội ngũ. Daily standup có thể tích hợp vào bất kỳ giai đoạn nào (không chỉ design phase), nhưng bỏ qua xung đột sẽ làm giảm hiệu quả. PMBOK® 7th Edition nhấn mạnh ưu tiên Stakeholder Engagement trước khi điều chỉnh lịch (Project Schedule Domain).

• ❌ Engage an external vendor to perform the design phase under an iterative approach
  Sai vì: Thuê nhà cung cấp bên ngoài để làm design phase theo cách lặp (iterative) là tránh né vấn đề nội bộ, không liên quan trực tiếp đến daily standup hay kháng cự đội ngũ. Điều này có thể tăng chi phí và mất kiểm soát (Procurement Management Domain), trong khi PM nên tập trung xây dựng năng lực nội bộ theo nguyên tắc Self-Organizing Teams trong Agile Practice Guide.

• ❌ Request that new team members familiar with iterative approaches be assigned to this project
  Sai vì: Yêu cầu thay thế thành viên mới quen iterative chỉ là giải pháp tạm thời, không bền vững, bỏ qua đội ngũ hiện tại và có thể gây demotivation thêm. PMBOK® 7th Edition (Resource Management, trang 109) khuyến nghị phát triển đội ngũ hiện tại qua training/coaching thay vì thay người, đặc biệt khi vấn đề là xung đột chứ không phải thiếu kỹ năng cơ bản.

• ✅ Define the ground rules, responsibilities, and conflict management strategies
  Đúng vì: Như đã giải thích ở trên, đây là cách chủ động quản lý đội ngũ và xung đột (Conflict Resolution Techniques trong PMBOK® 7th Edition, Models 9.2.2.3), phù hợp với Hybrid/Agile approaches nơi daily standup là công cụ cốt lõi. Giúp chuyển hóa kháng cự thành cam kết.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (PMI, 2021): Team Performance Domain (trang 89-92), Resource Management (trang 107-113), Agile Hybrid Models.
• Agile Practice Guide (PMI, 2017, tích hợp PMBOK 7): Daily Standups (Scrum Events, trang 42-45), Servant Leadership & Conflict Management.
• PMP Examination Content Outline (PMI, 2021, cập nhật 2024): Domain III: Business Environment (15%), Domain IV: People (42%) – Nhấn mạnh quản lý đội ngũ và thay đổi.

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 nội dung câu hỏi

Câu hỏi này thuộc lĩnh vực Quản lý Chi phí (Cost Management) và Phân tích Giá trị Kinh doanh (Business Value Analysis) trong PMP, cụ thể liên quan đến việc xây dựng Business Case để đánh giá các lựa chọn thay thế (alternatives) cho dự án. Một ngân hàng đang cân nhắc mở chi nhánh mới ở một trong ba thành phố lân cận, với ba lựa chọn chính:

• Xây dựng chi nhánh mới (building a new branch).
• Thuê tòa nhà hiện có (renting an existing building).
• Không mở rộng gì cả (not expanding at all).

📋 Nhiệm vụ của Project Manager (PM): Chứng minh lợi ích (benefits) của từng lựa chọn ở mỗi địa điểm. Điều này đòi hỏi phải so sánh các lựa chọn một cách tài chính định lượng, tập trung vào giá trị dài hạn, rủi ro thời gian tiền tệ, và tính khả thi kinh tế để hỗ trợ quyết định chiến lược. Theo PMBOK® Guide 7th Edition (2021, cập nhật đến 2026 qua PMI Standards), PM cần sử dụng các công cụ định lượng như NPV để đo lường giá trị giao hàng (value delivery) và hỗ trợ ra quyết định dựa trên dữ liệu (data-driven decisions) trong giai đoạn Business Analysis và Strategic Planning.

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

Đáp án đúng: Calculate the costs for each option in each location and compare the net present value (NPV) for each.

🛠️ Lý do chi tiết:

• NPV (Net Present Value - Giá trị hiện tại ròng) là công cụ tài chính định lượng hàng đầu để đánh giá lợi ích của các lựa chọn thay thế bằng cách tính toán giá trị hiện tại của dòng tiền tương lai (cash flows) sau khi trừ chi phí, áp dụng tỷ lệ chiết khấu (discount rate) để phản ánh giá trị thời gian của tiền tệ (time value of money).
• Phương pháp này bao quát đầy đủ ba lựa chọn (xây mới, thuê, không làm gì) ở mỗi địa điểm, giúp so sánh lợi ích ròng một cách khách quan, hỗ trợ xây dựng Business Case vững chắc.
• Theo PMBOK® Guide 7th Edition (Domain: Uncertainty, Section 4.6 Decision Making) và PMI's The Standard for Project Management (2021), NPV được khuyến nghị cho việc đánh giá dự án đầu tư vì nó xem xét toàn bộ vòng đời dự án, rủi ro, và lợi ích dài hạn – phù hợp nhất với yêu cầu "demonstrating the benefits".
• ✅ Ưu điểm nổi bật: Toàn diện, định lượng, dễ so sánh (lựa chọn có NPV cao nhất là tốt 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 phương án một cách chi tiết, dựa trên nguyên tắc PMP mới nhất (PMBOK® 7th Edition & Agile Practice Guide 2021, cập nhật 2026). Mỗi phương án được giữ nguyên văn bản gốc tiếng Anh, kèm đánh giá đúng/sai và lý do bằng tiếng Việt.

• Perform a gap analysis on renting in each of the locations.
  ❌ Sai: Gap analysis (phân tích khoảng cách) dùng để xác định khoảng trống giữa tình trạng hiện tại và mong muốn trong yêu cầu dự án hoặc quy trình (PMBOK® 7th, Domain: Planning, Section 5.3). Nó không tập trung vào lợi ích tài chính mà chỉ xem xét thuê ở mỗi địa điểm, bỏ qua xây mới và không mở rộng, không chứng minh được "benefits" một cách định lượng. Không phù hợp cho so sánh kinh tế.

• Calculate the costs for each option in each location and compare the net present value (NPV) for each.
  ✅ Đúng: Như đã giải thích ở trên, đây là phương pháp tối ưu để định lượng lợi ích, bao quát tất cả lựa chọn và địa điểm. NPV vượt trội vì tính đến dòng tiền dài hạn và rủi ro lạm phát, hỗ trợ Strategic Alignment (PMBOK® 7th, Principle 5: Optimize Risk Responses).

• Perform a Kano analysis on building a new branch versus renting in each of the locations.
  ❌ Sai: Kano analysis (phân tích Kano) là công cụ phân loại nhu cầu khách hàng thành basic/performance/excitement (từ mô hình Kano Model, tích hợp trong PMBOK® 7th, Domain: Stakeholder). Nó chỉ so sánh xây mới vs. thuê, bỏ qua "không mở rộng", và tập trung vào sự hài lòng khách hàng chứ không phải lợi ích tài chính định lượng. Không chứng minh được "benefits" kinh tế.

• Calculate the payback period (PBP) for building a new branch in each location versus renting an existing building.
  ❌ Sai: Payback Period (PBP - thời gian hoàn vốn) chỉ tính thời gian thu hồi chi phí ban đầu, bỏ qua dòng tiền sau điểm hòa vốn và không áp dụng giá trị thời gian tiền tệ đầy đủ (PMBOK® 7th, Tools for Cost Estimating). Nó bỏ qua lựa chọn "không mở rộng" và kém chính xác hơn NPV cho đánh giá dài hạn. Phù hợp cho dự án rủi ro cao ngắn hạn, nhưng không phải ở đây.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (PMI, 2021): Sections 4.6 (Decision Making), 7.3 (Project Cost Control), Principle 9 (Focus on Value).
• The Standard for Project Program and Portfolio Management (PMI, 2022): Business Case Development.
• PMI Practice Standard for Project Estimating (2021): NPV vs. PBP comparisons.
• Cập nhật 2026: Không thay đổi cốt lõi, nhấn mạnh hybrid approaches với data analytics cho NPV (PMI Digital Tools).

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ụ tính NPV, hãy hỏi nhé!