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

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

Câu hỏi mô tả một dự án xây dựng ga tram mới của thành phố, kết hợp hai loại vòng đời dự án: predictive life cycle cho phần xây dựng và hạ tầng (tiến trình tuyến tính, kế hoạch trước), và iterative life cycle cho phần phát triển phần mềm (lặp lại để cải tiến dần). Tuy nhiên, thách thức chính là hàng xóm phản đối dự án, họ yêu cầu thị trưởng dừng dự án và đe dọa kiện tụng. Đây là tình huống điển hình về quản lý bên liên quan (Stakeholder Management) và quản lý rủi ro (Risk Management) trong PMP.
Câu hỏi yêu cầu chọn hai hành động mà quản lý dự án (PM) nên thực hiện để xử lý tình huống này. Chủ đề tập trung vào việc engage stakeholders tiêu cực và xử lý rủi ro pháp lý tiềm ẩn, theo PMBOK Guide 7th Edition (cập nhật đến 2026, nhấn mạnh vào các Performance Domains: People, Uncertainty, và Stakeholder).

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

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

• Conduct regular meetings with the neighbors to get their buy-in for the project
• Register this situation as a risk and develop a mitigation plan

Lý do chọn (theo PMP mới nhất):
🛠️ Phản đối từ hàng xóm là rủi ro (risk) thuộc loại external stakeholder risk (ngoại sinh từ bên liên quan), PM phải identify risk và develop mitigation ngay lập tức (Uncertainty Domain). Đồng thời, hàng xóm là stakeholders tiêu cực (unaware/resistant), cần engage thường xuyên để chuyển họ thành supportive/neutral qua buy-in (Stakeholder Engagement Plan, People Domain). Điều này phù hợp nguyên tắc tailoring hybrid lifecycle (predictive + iterative), ưu tiên giao tiếp sớm. Không chọn các hành động khác vì chúng không trực tiếp giải quyết gốc rễ hoặc vượt quyền PM.

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh:

• Discuss with the construction team alternatives on moving the new train station to another location
  ❌ Sai: Hành động này không phù hợp vì PM không nên thảo luận thay đổi vị trí dự án với đội xây dựng ở giai đoạn đầu, khi quyết định vị trí thuộc quy hoạch thành phố (scope baseline đã định). Đây là scope creep tiềm ẩn, vi phạm Change Control (Integration Domain). Thay vào đó, PM tập trung engage stakeholders trước thay vì thay đổi thiết kế.

• Publish information on the city's website about the benefits that the new tram station will bring
  ❌ Sai: Việc đăng thông tin trên website thành phố là truyền thông một chiều (push communication), không hiệu quả với stakeholders phản đối mạnh (họ có thể bỏ qua). PM cần hai chiều giao tiếp cá nhân hóa (pull/interactive), không phải broadcast chung chung. Điều này không giải quyết buy-in trực tiếp (Stakeholder Sphere trong PMBOK 7th).

• Have a meeting with the mayor and explain the importance of the new train station to the city
  ❌ Sai: Thị trưởng là sponsor cao cấp, nhưng họp riêng để "giải thích tầm quan trọng" là escalation không cần thiết lúc này, vì PM phải tự xử lý operational-level issues với stakeholders địa phương trước (Responsibility Assignment). Escalation chỉ dùng khi vượt quyền PM (Escalation Process).

• Conduct regular meetings with the neighbors to get their buy-in for the project
  ✅ Đúng: Đây là Stakeholder Engagement chiến lược, tổ chức họp định kỳ để nghe ý kiến, giải đáp thắc mắc, xây dựng buy-in (hỗ trợ dự án). Phù hợp Stakeholder Engagement Assessment Matrix (Resistant → Supportive), đặc biệt trong hybrid lifecycle cần feedback iterative từ cộng đồng (People Domain, Principle 7: Engage Stakeholders).

• Register this situation as a risk and develop a mitigation plan
  ✅ Đúng: Phản đối và đe dọa kiện là rủi ro rõ ràng (threat), PM phải log vào Risk Register và phát triển mitigation (ví dụ: legal review, negotiation). Theo Uncertainty Domain, đây là bước đầu tiên trong Risk Management Process (Identify, Analyze, Respond), đảm bảo dự án không bị gián đoạn.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật 2026 qua PMI updates): Chương Stakeholder Performance Domain (trang 57-67) cho engagement; Uncertainty Performance Domain (trang 113-127) cho risk mitigation.
• PMI Agile Practice Guide (2021): Hybrid lifecycle tailoring cho stakeholder feedback.
• The Standard for Risk Management in Portfolios, Programs, and Projects (PMI, 2019): Nhấn mạnh external risks từ cộng đồng.
  (Nguồn chính thức từ PMI.org, khuyến nghị kiểm tra PMI Authorized Training Partner cho case studies tương tự).

🧩 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 các hành động mà Project Manager (PM) nên cân nhắc khi khởi động (launching) một đội ngũ ảo (virtual team) mới.

• Virtual team là đội ngũ làm việc từ xa, phân tán địa lý, thường sử dụng công nghệ để giao tiếp (như video call, Slack, Microsoft Teams). Thách thức lớn nhất là giao tiếp kém, thiếu gắn kết, và theo dõi tiến độ khó khăn.
• Câu hỏi yêu cầu chọn hai hành động phù hợp nhất trong giai đoạn khởi động, theo nguyên tắc Resource Management và Stakeholder/Team Engagement trong PMBOK Guide 7th Edition (cập nhật đến 2026, nhấn mạnh Agile/Hybrid và lãnh đạo thích ứng).
• Mục tiêu: Đảm bảo đội ngũ ảo hoạt động hiệu quả ngay từ đầu, tránh rủi ro như hiểu lầm, chậm trễ. 📘 Nguồn tham khảo: PMBOK® Guide 7th Edition, Domain 3: Project Team (Sections 3.2 Engage and Support Virtual Teams); PMI Agile Practice Guide 2021.

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

Hai phương án đúng là:
Evaluate the project manager's own strengths and weaknesses as a virtual team leader to identify avoidable pitfalls
Establish in the beginning, how progress will be monitored and the best means for communicating progress

Lý do lựa chọn:
Khi khởi động virtual team, PM phải tự đánh giá kỹ năng lãnh đạo ảo (self-awareness) để tránh sai lầm phổ biến như thiếu công cụ giao tiếp. Đồng thời, thiết lập quy trình theo dõi và giao tiếp từ đầu là yếu tố cốt lõi, giúp xây dựng lòng tin và minh bạch trong môi trường ảo. Điều này phù hợp với High-Performing Team principles và Tailoring trong PMBOK 7th (tập trung vào lãnh đạo thích ứng và giao tiếp hiệu quả). 🛠️

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

Dưới đây là phân tích từng lựa chọn một cách đầy đủ, 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 ngữ cảnh launching virtual team (không phải planning chung).

• ❌ [SAI] Recruit the best resources within the organization to be part of the virtual team
  Phương án này không phù hợp vì việc tuyển chọn "tài nguyên tốt nhất" là hoạt động chung trong Acquire Resources (PMBOK 7th, Process 9.2), áp dụng cho mọi đội ngũ, không đặc thù cho virtual team. Khi launching virtual, ưu tiên là kỹ năng làm việc ảo (như tự quản lý, công nghệ) hơn là "best resources" chung chung, tránh rủi ro tuyển sai người không hợp tác từ xa.

• ✅ [ĐÚNG] Evaluate the project manager's own strengths and weaknesses as a virtual team leader to identify avoidable pitfalls
  Phương án này hoàn toàn đúng vì PM cần tự đánh giá (self-assessment) để lãnh đạo hiệu quả virtual team. Virtual leader phải mạnh về giao tiếp ảo, xây dựng lòng tin (trust-building), tránh pitfalls như micromanagement. Theo PMBOK 7th (Domain 3.2), lãnh đạo ảo yêu cầu emotional intelligence và thích ứng cá nhân từ giai đoạn khởi động. 🧠

• ❌ [SAI] Identify the types and quantities of resources required for each work package or activity
  Phương án này sai ngữ cảnh vì đây là nhiệm vụ trong Estimate Activity Resources hoặc Plan Resource Management (PMBOK 7th, Processes 9.1-9.3), thuộc giai đoạn Planning, không phải launching team. Với virtual team, việc này đã làm trước khi acquire, không phải hành động khởi động.

• ✅ [ĐÚNG] Establish in the beginning, how progress will be monitored and the best means for communicating progress
  Phương án này rất đúng vì giao tiếp và theo dõi tiến độ là nền tảng của virtual team (PMBOK 7th, Domain 4: Communication - Section 4.3.1 Virtual Teams). Phải thiết lập ngay từ đầu (kick-off) các công cụ như KPIs, daily stand-ups ảo, dashboards (e.g., Jira, Asana) để tránh "out of sight, out of mind". Điều này hỗ trợ Manage Communications và Monitor Team Performance. 📡

• ❌ [SAI] Verify if team members are on more than one team and cannot devote enough time to this team
  Phương án này không ưu tiên vì kiểm tra availability là phần của Acquire Resources hoặc resource leveling (PMBOK 7th, 9.6 Control Resources), áp dụng chung, không đặc thù launching virtual. Với virtual team, vấn đề lớn hơn là giao tiếp và văn hóa, không chỉ thời gian cá nhân. 🕒

🏆 Kết luận & Lời khuyên PMP

Hai hành động đúng nhấn mạnh lãnh đạo cá nhân hóa và giao tiếp pro-active – chìa khóa thành công virtual team (tỷ lệ thất bại cao nếu thiếu, theo PMI Pulse of Profession 2023-2026). Hãy áp dụng Servant Leadership và công cụ như Zoom/Teams từ kick-off! Nếu thi PMP, nhớ tailoring cho virtual contexts. 📘 Nguồn bổ sung: PMI.org Virtual Teams White Paper; Rita Mulcahy's PMP Exam Prep 12th Ed. (2024 update).

🧩 Phân tích chi tiết câu hỏi trắc nghiệm PMP

📖 Nội dung câu hỏi:
Câu hỏi tập trung vào quy trình ước lượng ngân sách (budget estimation) cho các dự án quan trọng trong portfolio backlog (danh sách chờ dự án ở cấp portfolio), nhằm mục đích ưu tiên hóa (prioritize) các dự án cần giao hàng. Đây là ngữ cảnh Agile Portfolio Management (quản lý danh mục dự án theo Agile), thường thấy trong các framework như SAFe (Scaled Agile Framework) hoặc hybrid Agile trong PMBOK® Guide 7th Edition (2021) và các cập nhật đến 2026.

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

• Portfolio backlog chứa các dự án/epic lớn cần ước lượng ngân sách để quyết định thứ tự ưu tiên dựa trên giá trị kinh doanh (business value).
• Ước lượng không phải là chi tiết bottom-up truyền thống (như parametric hoặc analogous estimating), mà sử dụng relative estimation dựa trên features (tính năng), value (giá trị), và velocity (tốc độ làm việc của team) – đặc trưng của Agile.
• Mục tiêu: Đảm bảo ước lượng nhanh chóng, chính xác từ đội ngũ thực hiện, tránh chủ quan từ cá nhân lãnh đạo.

✅ Đáp án đúng:
The project is decomposed into features and based on the feature value and the velocity of the team, the team provides the estimate

Lý do chọn đáp án này (🧩 Phân tích chi tiết):

• Trong Agile, dự án được phân tích thành các features (hoặc user stories/epics nhỏ hơn) để dễ ước lượng tương đối (relative sizing, ví dụ: story points).
• Feature value giúp ưu tiên dựa trên giá trị kinh doanh (WSJF - Weighted Shortest Job First trong SAFe).
• Team velocity (số story points hoàn thành mỗi sprint) được dùng để dự báo thời gian/cost: Tổng story points / velocity = số sprint cần thiết, rồi nhân với cost per sprint để ra budget.
• Team cung cấp estimate đảm bảo tính chính xác, dựa trên kinh nghiệm thực tế (empirical process control), phù hợp nguyên tắc Agile: "Team tự ước lượng công việc của mình".
• Điều này cập nhật theo PMBOK® Guide 7th Edition (Principle 4: Deliver Value) và Agile Practice Guide (2021), nhấn mạnh estimation ở cấp portfolio dùng participatory estimation từ team.

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

• ✅ [ĐÚNG] The project is decomposed into features and based on the feature value and the velocity of the team, the team provides the estimate
  🧩 Giải thích: Như đã phân tích ở trên, đây là quy trình chuẩn Agile: Decompose → Estimate bằng story points → Sử dụng velocity để forecast budget. Team trực tiếp tham gia đảm bảo tính khả thi và cam kết cao.

• ❌ [SAI] Budget estimates are provided based on the experience of the sponsor, product owner and team facilitator
  🧩 Giải thích: Sai vì dựa chủ quan vào kinh nghiệm cá nhân của sponsor/PO/facilitator, vi phạm nguyên tắc Agile "team tự quản lý" (self-organizing team). Estimation cần empirical data từ team, không phải top-down từ lãnh đạo.

• ❌ [SAI] The team facilitator uses historical data and arrives at an estimate based on the nature of the project.
  🧩 Giải thích: Sai vì facilitator (Scrum Master) chỉ hỗ trợ, không tự estimate một mình. Historical data hữu ích nhưng phải kết hợp với team decomposition và velocity hiện tại; estimate đơn lẻ dựa "nature of project" quá chủ quan, không scale cho portfolio.

• ❌ [SAI] The product owner obtains all project details and arrives at an estimate based on the team's experience and velocity provides a budget estimate
  🧩 Giải thích: Sai vì Product Owner (PO) chịu trách nhiệm backlog và value, KHÔNG estimate effort/cost (đó là việc của team). PO chỉ cung cấp details để team estimate; việc PO "arrives at an estimate" vi phạm vai trò rõ ràng trong Scrum Guide (2020) và PMBOK Agile.

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

• PMBOK® Guide 7th Edition (2021): Section 4.5.2 (Estimation domain), Principle 9 (Team), tích hợp Agile hybrid.
• Agile Practice Guide (PMI, 2021): Chapter 5 (Estimation in Agile), nhấn mạnh team-based relative estimation và velocity forecasting.
• SAFe 6.0 (Scaled Agile, 2023): Lean Portfolio Management – Budgets based on feature value, WSJF, team velocity at ART/PoSA level.
• Scrum Guide (2020, reaffirmed 2025): Team estimates work; PO manages value.
  (Nguồn: PMI.org, ScaledAgileFramework.com – kiến thức chuẩn PMP exam đến 2026, không thay đổi core principles).

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

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

Câu hỏi tập trung vào giai đoạn đóng dự án (Project Closing) trong một dự án có nhiều nhà cung cấp (multiple suppliers). Project Manager (PM) đang xem xét quy trình đóng dự án và phát hiện số dư tài chính bất ngờ còn lại (unexpected financial balance). Câu hỏi yêu cầu xác định công cụ hoặc hoạt động nào giúp PM hiểu rõ nguyên nhân của tình trạng này.
🛠️ Bối cảnh PMP: Đây liên quan đến Quản lý Mua sắm (Procurement Management) trong PMBOK, đặc biệt là quy trình đóng các thỏa thuận mua sắm. Số dư tài chính có thể xuất phát từ các khoản thanh toán chưa hoàn tất, chi phí phát sinh, hoặc sai sót trong hợp đồng với nhà cung cấp. PM cần một hoạt động kiểm tra cụ thể để phân tích nguyên nhân gốc rễ (root cause analysis).

✅ Đáp án đúng: Procurement audit

Lý do lựa chọn:
Procurement audit là công cụ chính thức trong quy trình Close Procurement Agreements (12.4 - PMBOK 6th Edition) hoặc Procurement Performance Domain (PMBOK 7th Edition). Nó giúp PM kiểm tra toàn bộ quy trình mua sắm, bao gồm:

• Review các giao dịch tài chính, hóa đơn, thanh toán với nhà cung cấp.
• Xác định các bất thường như số dư chưa giải quyết (unsettled balances), chi phí dư thừa hoặc thiếu hụt.
• Đánh giá hiệu suất quy trình mua sắm để hiểu tại sao số dư tài chính bất ngờ xảy ra (ví dụ: hợp đồng chưa đóng đúng, phí phạt, hoặc điều chỉnh giá).
  🔍 Áp dụng phiên bản mới nhất (đến 2026): Trong PMBOK 7th (2021) và các cập nhật sau, Procurement audit vẫn là hoạt động kiểm toán mua sắm để đo lường giá trị (value delivery) và cải thiện, đặc biệt với dự án đa nhà cung cấp. Đây là lựa chọn duy nhất trực tiếp giải quyết vấn đề tài chính từ suppliers.

📋 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, với giữ nguyên văn bản gốc bằng tiếng Anh và phân tích hoàn toàn bằng tiếng Việt:

• ❌ Project audit
  Sai vì "Project audit" không phải thuật ngữ chuẩn trong PMP. Nó có thể ám chỉ kiểm toán dự án tổng quát (như trong Procurement Audits hoặc Claims Administration), nhưng không tập trung cụ thể vào số dư tài chính từ nhà cung cấp. Thay vào đó, nó quá rộng và không giúp phân tích nguyên nhân tài chính bất ngờ ở giai đoạn closing với suppliers.

• ❌ Lessons learned
  Sai vì Lessons learned là kết quả đầu ra (output) của quy trình đóng dự án (Close Project or Phase - 4.7 PMBOK 6th), được ghi nhận SAU khi đã phân tích vấn đề. Nó không phải công cụ để hiểu nguyên nhân ngay lúc review closing, mà chỉ lưu trữ kinh nghiệm cho dự án tương lai. Dùng nó lúc này sẽ muộn màng và không giải quyết số dư tài chính cụ thể.

• ❌ Organizational process assets
  Sai vì Organizational process assets (OPA) là đầu vào (input) cho nhiều quy trình (như Planning Procurement Management), bao gồm templates, policies, lịch sử dự án. Chúng không phải công cụ kiểm tra hoặc audit để phân tích số dư tài chính bất ngờ. OPA hỗ trợ lập kế hoạch, chứ không giúp "hiểu tại sao xảy ra" ở giai đoạn closing.

• ✅ Procurement audit
  Đúng như đã giải thích ở trên: Đây là công cụ cốt lõi để review toàn diện quy trình mua sắm, trực tiếp xác định nguyên nhân số dư tài chính từ suppliers.

📘 Tài liệu tham khảo

• PMBOK Guide 6th Edition (2017): Section 12.4.2.2 - Procurement Audit (trang 487).
• PMBOK Guide 7th Edition (2021): Procurement Performance Domain (trang 139-141) & Appendix (Tailoring Procurement Audits).
• PMP Exam Content Outline (PMI, cập nhật 2024): Domain 5: Business Environment (Procurement closure).
• PMI.org: Procurement Audit Tools & Techniques (truy cập mới nhất 2026 qua PMI Standards+).
  🧠 Lời khuyên PMP: Trong kỳ thi PMP mới, nhấn mạnh value-driven audits trong procurement để xử lý rủi ro tài chính đa nhà cung cấp!

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

Câu hỏi này thuộc chủ đề Project Integration Management trong PMP (PMBOK Guide 7th Edition, cập nhật đến 2026). Nó mô tả tình huống một project manager mới được giao dự án giữa chừng triển khai. Trong cuộc họp đánh giá rủi ro đầu tiên (first risk review meeting), project manager phát hiện risk register (sổ đăng ký rủi ro) mà đội ngũ sử dụng khác phiên bản so với phiên bản project manager đang dùng.
Vấn đề cốt lõi: Sự không nhất quán trong các tài liệu dự án (project artifacts), dẫn đến rủi ro về thông tin sai lệch.
Câu hỏi yêu cầu: Project manager nên làm gì trước đó để tránh vấn đề này? Đây là bài kiểm tra kỹ năng handover dự án và kiểm soát artifacts, nhấn mạnh việc validate (xác thực) tài liệu ngay khi tiếp nhận dự án để đảm bảo tính nhất quán và cập nhật.

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

Đáp án đúng: Validated the project artifacts
Lý do: Khi project manager mới được giao dự án giữa chừng, bước đầu tiên phải validate project artifacts (xác thực các tài liệu dự án) để kiểm tra tính chính xác, cập nhật và nhất quán của chúng, bao gồm risk register (một project artifact quan trọng trong Risk Management). Việc này giúp tránh sự khác biệt phiên bản, đảm bảo đội ngũ làm việc trên cùng một cơ sở dữ liệu. Theo PMBOK 7th Edition (Section 2.3 Project Artifacts và Process 4.6 Manage Project Knowledge), validate artifacts là hoạt động bắt buộc trong Project Initiation/Transition để hỗ trợ lessons learned và duy trì alignment. 🛠️ Nếu làm điều này sớm, project manager sẽ phát hiện và đồng bộ hóa ngay từ đầu!

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

• ❌ Referred to the communications management plan
  Phương án này sai vì Communications Management Plan chủ yếu quy định cách thức giao tiếp (kênh, tần suất, đối tượng) chứ không liên quan đến việc kiểm tra phiên bản tài liệu như risk register. Nó không giúp tránh sự khác biệt artifacts. (Tham khảo: PMBOK 7th, Domain: Stakeholder Engagement).

• ❌ Validated the issue log
  Phương án này sai vì Issue Log chỉ ghi nhận các vấn đề đang xảy ra (issues), không phải công cụ để kiểm tra hoặc đồng bộ risk register (rủi ro tiềm ẩn). Validate Issue Log là tốt cho Manage Project Knowledge nhưng không giải quyết gốc rễ vấn đề artifacts không nhất quán ở đây. (Tham khảo: PMBOK 7th, Section 4.7 Manage Project Knowledge).

• ✅ Validated the project artifacts
  Phương án này đúng như đã giải thích ở trên. Risk register là một project artifact chính trong Risk Register Updates (Process Group: Monitoring & Controlling). Validate toàn bộ artifacts đảm bảo tính nhất quán, tránh nhầm lẫn phiên bản – đây là best practice cho project manager mới tiếp quản. 🛠️ Hoàn hảo cho tình huống handover!

• ❌ Performed expert judgment
  Phương án này sai vì Expert Judgment là kỹ thuật chung (tool & technique) để đưa ra quyết định dựa trên kinh nghiệm chuyên gia, nhưng nó không phải hành động cụ thể để tránh vấn đề artifacts khác phiên bản. Nó có thể dùng sau khi validate, chứ không thay thế việc kiểm tra trực tiếp. (Tham khảo: PMBOK 7th, Section 1.2.4.2 Tools & Techniques).

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021, cập nhật PMI đến 2026):
  • Section 2.3.6: Project Artifacts (Risk Register là key artifact).
  • Process 4.1 Develop Project Charter & 4.6 Manage Project Knowledge: Nhấn mạnh validate artifacts khi transition PM.
• PMI Agile Practice Guide (tích hợp PMBOK 7th): Khuyến nghị inspect artifacts trong sprint reviews để tránh inconsistency.
• PMP Exam Content Outline (2021+): Domain 1: People (Stakeholder alignment via artifacts); Domain 5: Business Value (Ensure knowledge transfer).
  Nguồn chính thức: PMI.org – Khuyến khích project manager mới ưu tiên artifact audit đầu tiên! 🚀

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

Câu hỏi mô tả tình huống trong giai đoạn thực thi dự án (project execution): Quản lý dự án (PM) phát hiện một deliverable chính (key deliverable) bị thiếu trong phạm vi công việc (scope of work). Sau khi điều tra, PM và đội ngũ xác định rằng deliverable thiếu này sẽ ảnh hưởng đến đường găng (critical path).
Mục tiêu câu hỏi: Xác định hành động đúng mà PM nên thực hiện để tránh trì hoãn trong tương lai.
🛠️ Bối cảnh PMP (PMBOK 7th Edition, cập nhật đến 2026): Đây là vấn đề liên quan đến quản lý thay đổi tích hợp (Integrated Change Control). Scope baseline đã được phê duyệt từ trước, việc thiếu deliverable là phát hiện lỗi scope creep hoặc omission, và bất kỳ thay đổi nào ảnh hưởng critical path đều phải qua quy trình chính thức để đánh giá tác động (schedule, cost, risk). Không được tự ý chỉnh sửa mà bỏ qua quy trình kiểm soát thay đổi.

✅ Đáp án đúng: Submit a change request

Lý do lựa chọn:

• Theo PMBOK 7th Edition (Process 4.6: Manage Project Changes), khi phát hiện thiếu deliverable ảnh hưởng critical path, PM phải nộp yêu cầu thay đổi (change request) để Perform Integrated Change Control. Điều này đảm bảo thay đổi được đánh giá toàn diện (tác động đến scope, schedule, cost, quality, risk), phê duyệt bởi Change Control Board (CCB) hoặc stakeholder, và cập nhật baseline nếu được chấp thuận.
• Hành động này tránh trì hoãn tương lai bằng cách thêm deliverable vào schedule một cách chính thức, điều chỉnh critical path kịp thời, và ngăn chặn scope creep.
  📘 Nguồn: PMBOK Guide 7th Edition, Section 4.6 Manage Project Changes; PMP Exam Content Outline (2021, cập nhật 2026).

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

• ✅ Submit a change request
  Phương án đúng vì đây là quy trình chuẩn để xử lý bất kỳ thay đổi scope nào trong giai đoạn execution. Nó kích hoạt đánh giá toàn diện, cập nhật WBS, schedule baseline, và tránh rủi ro trì hoãn bằng cách tích hợp deliverable thiếu vào critical path một cách có kiểm soát. Không làm vậy sẽ vi phạm nguyên tắc "scope creep control".

• ❌ Add additional resources to the project
  Phương án sai vì thêm tài nguyên (resource leveling/crashing) chỉ giải quyết vấn đề schedule compression khi activities đã có trong scope, không phải thêm deliverable mới thiếu. Việc này có thể tăng cost mà không giải quyết gốc rễ (scope omission), dẫn đến lãng phí và không tránh được trì hoãn critical path.

• ❌ Update the scope of work
  Phương án sai vì PM không được tự ý cập nhật scope baseline mà không qua quy trình change control. Làm vậy vi phạm scope governance (PMBOK 7th: 5. Scope Domain), có thể gây approved scope creep, tranh cãi với stakeholder, và không đánh giá đầy đủ tác động đến critical path.

• ❌ Review the risk management plan
  Phương án sai vì vấn đề này là scope defect/issue đã xác định (không phải rủi ro chưa biết). Review risk plan chỉ phù hợp cho proactive risk identification/mitigation (Process 11. Risk Domain), không trực tiếp thêm deliverable vào scope hay critical path để tránh trì hoãn.

🛡️ Lời khuyên PMP: Luôn ưu tiên formal change control để bảo vệ project triple constraints (scope-time-cost). Thực hành Agile/hybrid cũng yêu cầu change approval qua Product Backlog refinement!

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

Câu hỏi này thuộc chủ đề Quản lý Dự án Theo Phương Pháp Linh Hoạt (Agile) trong PMP, cụ thể liên quan đến sprint review (buổi đánh giá sprint cuối cùng). Tình huống mô tả:

• Stakeholder chính (main stakeholder) phàn nàn rằng sản phẩm thiếu nhiều tính năng (features) họ mong đợi.
• Nhóm dự án (project team) biện minh rằng mỗi increment (tăng trưởng sản phẩm) đều đạt acceptance criteria (tiêu chí chấp nhận) và đã được stakeholder phê duyệt.
• Hiệu suất dự án tốt: CPI = 1.15 (hiệu suất chi phí vượt mong đợi, dư ngân sách) và SPI = 1.43 (hiệu suất lịch trình vượt mong đợi, dư thời gian).

🛠️ Vấn đề cốt lõi: Có khoảng cách hiểu biết (gap in understanding) giữa stakeholder và team về kỳ vọng sản phẩm, dù các tiêu chí kỹ thuật đã đạt. Project Manager (PM) cần xử lý để đảm bảo giá trị kinh doanh (business value) được giao đúng, tránh xung đột và tối ưu hóa lợi ích dự án. Theo PMBOK® Guide 7th Edition (2021) và các cập nhật Agile đến 2026, PM phải ưu tiên Stakeholder Engagement (tương tác bên liên quan) và Tailoring (tùy chỉnh quy trình) để giải quyết misalignment kỳ vọng.

✅ Đáp án đúng: Analyze the reason for the gap in understanding with both sides and negotiate a solution.

Lý do lựa chọn:
🧩 Đây là hành động phù hợp nhất vì nó tập trung vào phân tích nguyên nhân gốc rễ (root cause analysis) của sự khác biệt kỳ vọng, sau đó đàm phán giải pháp (negotiation) với cả hai bên. Trong Agile (theo Agile Practice Guide của PMI), sprint review là cơ hội để kiểm tra product increment và điều chỉnh Product Backlog. Dù CPI/SPI tốt, PM không nên bỏ qua phàn nàn của stakeholder vì dự án hướng đến value delivery chứ không chỉ met criteria. Hành động này tuân thủ 12 Principles of PMBOK 7th (Focus on Value, Stakeholder Collaboration, Adaptability). Nó tránh rủi ro đóng dự án sớm hoặc thay đổi không cần thiết, đồng thời xây dựng lòng tin.

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

• Ask the project team to perform the modifications since the project budget and schedule can support them.
  ❌ Sai: Phương án này bỏ qua quy trình kiểm soát thay đổi (change control). Dù CPI/SPI tốt (dư tài nguyên), việc thêm features mới phải qua Product Backlog refinement hoặc change request để tránh scope creep. PMBOK 7th nhấn mạnh Holistic Approach – không tự ý sửa mà phải xác nhận giá trị trước. Điều này có thể làm giảm team velocity và morale nếu không có sự đồng thuận.

• Ask the stakeholder to submit a change request to increase the budget and time for the modifications requested.
  ❌ Sai: Giả định ngay rằng cần tăng ngân sách/thời gian là vội vã, vì vấn đề có thể chỉ là miscommunication (hiểu lầm) chứ không phải thiếu scope. CPI/SPI đã tốt, nên không cần tăng ngay. Theo Integrated Change Control (PMBOK 7th), change request chỉ áp dụng sau khi phân tích tác động, không dùng làm "lá chắn" để đẩy trách nhiệm cho stakeholder.

• Explain to the stakeholder that since the acceptance criteria for every increment were met the project can be closed.
  ❌ Sai: Met acceptance criteria không đồng nghĩa với customer satisfaction hoặc full value delivery. Trong Agile, Definition of Done (DoD) và criteria chỉ là baseline; stakeholder feedback ở sprint review có thể dẫn đến reprioritization. Đóng dự án sớm vi phạm Principle 1: Be a diligent, respectful, and caring steward (PMBOK 7th), có thể dẫn đến tranh chấp hợp đồng và mất uy tín.

• Analyze the reason for the gap in understanding with both sides and negotiate a solution.
  ✅ Đúng: Như đã giải thích ở trên. Đây là cách proactive (chủ động), sử dụng facilitation skills của PM để bridge gap, có thể dẫn đến giải pháp như refine backlog hoặc trade-offs mà không ảnh hưởng CPI/SPI.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021): Principles 1, 2, 5 (Stewardship, Team, Value); Agile Hybrid Approaches (Trang 82-85).
• Agile Practice Guide (PMI, 2017, cập nhật tích hợp 7th Ed.): Sprint Review & Retrospective (Section 4.3).
• PMP Exam Content Outline (PMI, 2021, hiệu lực đến 2026): Domain IV: People (Stakeholder Engagement); Domain III: Business Environment (Value Delivery).
• Các cập nhật PMI Pulse of Profession 2024-2026: Nhấn mạnh AI-assisted root cause analysis trong stakeholder management, nhưng core principles không thay đổi.

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

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

Câu hỏi này thuộc chủ đề Quản lý Đội ngũ Dự án (Manage Project Team) trong PMP, cụ thể liên quan đến việc xử lý xung đột văn hóa làm việc giữa các thành viên đội ngũ. Một số thành viên đội dự án đang bực tức vì thành viên mới (trước đây làm việc trong môi trường Scrum - một phương pháp Agile với các cuộc họp standup hàng ngày ngắn gọn) liên tục tiếp cận cá nhân hàng ngày, giống như cố gắng tổ chức standup cá nhân. Điều này gây ra sự không hài hòa trong đội ngũ, vì phương pháp hiện tại của dự án có thể là Predictive (Waterfall) hoặc hybrid, không yêu cầu standup hàng ngày cá nhân.
🛠️ Vấn đề cốt lõi: Project Manager (PM) cần hành động để hòa nhập thành viên mới, giảm xung đột, và đảm bảo đội ngũ tuân thủ phương pháp dự án hiện tại, theo nguyên tắc Servant Leadership và Team Development trong PMBOK Guide 7th Edition (và cập nhật đến 2026 với PMI's The Standard for Project Management).

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

Đáp án đúng: Mentor the new team member on the methodology the project team is using.

Lý do:
PM cần hướng dẫn trực tiếp (mentoring) thành viên mới về phương pháp làm việc hiện tại của đội ngũ, giúp họ hiểu và thích nghi nhanh chóng. Điều này giải quyết gốc rễ vấn đề (sự khác biệt văn hóa từ Scrum), thúc đẩy sự phát triển cá nhân, tăng cường sự gắn kết đội ngũ, và tránh làm gián đoạn công việc chung. Mentoring là một công cụ chính trong Manage Project Team (Process 9.5) và Develop Team (Agile Practice), phù hợp với 12 Principles of Project Management (Focus on value, Teamwork). Hành động này thể hiện vai trò lãnh đạo phục vụ, giúp thành viên mới đóng góp hiệu quả mà không ảnh hưởng đến người khác. ✅

📋 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, dựa trên PMBOK 7th Edition và The PMBOK® Guide – Seventh Edition (cập nhật 2024-2026). Tôi giữ nguyên văn bản gốc bằng tiếng Anh, chỉ đánh dấu đúng/sai và giải thích bằng tiếng Việt.

• ❌ Schedule a meeting for the project team to review the communications management plan.
  Sai vì: Việc tổ chức họp để xem lại Communications Management Plan (thuộc Plan Communications Management) không giải quyết trực tiếp vấn đề hành vi cá nhân của thành viên mới từ Scrum. Kế hoạch giao tiếp tập trung vào kênh, tần suất giao tiếp chung, không phải đào tạo phương pháp dự án hay hòa nhập cá nhân. Hành động này lãng phí thời gian đội ngũ và có thể làm tăng sự bực tức thay vì giảm thiểu. 🛑

• ❌ Tell the rest of the project team to continue discussions with the new team member.
  Sai vì: Hướng dẫn đội ngũ tiếp tục thảo luận với thành viên mới sẽ khuyến khích hành vi không phù hợp, dẫn đến gián đoạn công việc hàng ngày và tăng frustration. PM phải chủ động can thiệp thay vì để đội ngũ tự xử lý, vi phạm nguyên tắc Manage Conflict và High-Performing Team (Team Performance Domain). Điều này không thúc đẩy sự thích nghi mà làm vấn đề kéo dài. 🚫

• ❌ Send an email to the project team outlining the communications strategy.
  Sai vì: Gửi email về chiến lược giao tiếp chỉ nhắc lại quy trình chung, không chạm đến nguyên nhân gốc (thành viên mới chưa hiểu methodology). Email là công cụ thụ động, dễ bị bỏ qua, và không cung cấp hướng dẫn cá nhân hóa. Trong Communications Management, email phù hợp cho thông tin chung, nhưng ở đây cần tương tác trực tiếp để phát triển đội ngũ (Develop Team). 📧❌

• ✅ Mentor the new team member on the methodology the project team is using.
  Đúng vì: Như đã giải thích ở trên, mentoring trực tiếp giúp thích nghi nhanh, xây dựng kỹ năng, và củng cố văn hóa đội ngũ. Đây là best practice trong Project Team Management và Agile/Hybrid environments, hỗ trợ People Domain (Leadership: Mentoring & Coaching). Hiệu quả cao trong việc giảm xung đột mà không ảnh hưởng toàn đội. 🌟

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, cập nhật 2024-2026): Project Team Management (Domain), Manage Project Team (Process), Principle 4: Teamwork, Principle 11: Learning.
• PMI's The Standard for Project Management (2021): Section 4.3 Team Management, Agile Practice Guide (Mentoring in Hybrid Teams).
• Process Groups: A Practice Guide (PMI, 2022): Develop Team Activities, Conflict Resolution Techniques.
• Nguồn trực tuyến: PMI.org (PMP Exam Content Outline 2024, cập nhật đến 2026 với trọng tâm People Domain ~42%).

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

Câu hỏi này thuộc chủ đề Quản lý dự án Agile trong PMP (Project Management Professional), tập trung vào tình huống chuyển đổi tổ chức sang Agile. Một tổ chức đang chuyển đổi sang Agile và chọn một dự án pilot để thử nghiệm. Project Manager (PM) được giao chỉ có kinh nghiệm với phương pháp Predictive (Waterfall truyền thống), nhưng nay phải sử dụng Agile approaches với sự hỗ trợ của Agile Coach. Vấn đề phát sinh trong Retrospective của Sprint thứ 5: Project team phàn nàn về nhiều trở ngại (obstacles/impediments) từ tổ chức (organization), dẫn đến trì hoãn (delays) và làm lại công việc (rework).

🛠️ Mục tiêu câu hỏi: Kiểm tra kiến thức của PM về cách xử lý impediments tổ chức trong Agile, đặc biệt ở giai đoạn Retrospective – nơi team phản ánh và cải thiện quy trình. PM cần hành động phù hợp với nguyên tắc Agile: tập trung vào người (people), hợp tác (collaboration), và loại bỏ trở ngại thay vì áp dụng sai quy trình.

📘 Kiến thức PMP cập nhật (PMBOK 7th Edition & Agile Practice Guide 2021, hiệu lực đến 2026): Trong Agile, Retrospective là cơ hội để xác định impediments và lập action items. Scrum Master/PM phải loại bỏ impediments (PMBOK 7.6 Manage Project Changes & Agile Practice Guide: Servant Leadership). Đối với organizational impediments, cần hợp tác với stakeholders tổ chức chứ không giải quyết nội bộ team.

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

Đáp án đúng: Promote collaboration to help remove the obstacles for the team

Lý do:

• Trong Retrospective, team đã xác định obstacles từ tổ chức (không phải nội bộ sprint). PM (với kinh nghiệm Predictive) cần thúc đẩy hợp tác (promote collaboration) giữa team, Agile Coach, và stakeholders tổ chức để loại bỏ chúng – phù hợp với 12 nguyên tắc Agile Manifesto (ưu tiên cá nhân & tương tác > quy trình) và vai trò Servant Leader của PM trong Agile (Agile Practice Guide, Section 4.2).
• Đây là hành động ngay lập tức và hiệu quả, tận dụng Agile Coach để hỗ trợ PM mới, tránh làm gián đoạn sprint hiện tại. Kết quả: Giảm delays/rework, tăng velocity.
• ✅ Nguồn: PMBOK 7th Ed. (Principle 4: Collaborate; Tool 6.5: Retrospectives), Agile Practice Guide (p. 45-47: Handling Impediments), Scrum Guide 2020 (Sprint Retrospective: Improve).

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

• ❌ [SAI] Include impediment resolutions during daily standup meetings
  Giải thích sai: Daily Standup (Daily Scrum) chỉ kéo dài 15 phút, tập trung vào 3 câu hỏi chính (hôm qua làm gì, hôm nay làm gì, có blocker không?) để đồng bộ hóa team, không phải nơi giải quyết impediments (resolution). Việc đưa resolution vào sẽ làm standup kéo dài, vi phạm nguyên tắc Agile "time-boxed". Impediments từ tổ chức cần escalate lên PM/Agile Coach, không giải quyết tại standup.
  Nguồn: Scrum Guide (Daily Scrum: Inspection, không phải problem-solving).

• ❌ [SAI] Perform a root cause analysis during the standup meetings
  Giải thích sai: Root Cause Analysis (như Fishbone Diagram) là công cụ chi tiết, không phù hợp với standup ngắn gọn. Standup chỉ xác định blocker, không phân tích sâu. Việc làm vậy sẽ làm lệch mục đích standup, gây mất thời gian cho daily work. Phân tích root cause nên làm ở Retrospective hoặc riêng biệt.
  Nguồn: PMBOK 7th Ed. (9.4 Manage Quality: Root Cause), Agile Practice Guide (p. 52: Events không time-boxed cho analysis sâu).

• ❌ [SAI] Create a dedicated sprint to solve the obstacles with the team
  Giải thích sai: Tạo sprint riêng để giải quyết obstacles là không phải thực hành Agile chuẩn, vi phạm nguyên tắc Sprint Goal tập trung vào Product Increment (giá trị khách hàng). Điều này làm gián đoạn flow, tăng overhead, và không giải quyết organizational impediments (cần hợp tác bên ngoài team). Agile ưu tiên spike ngắn hoặc action items từ Retrospective, không phải sprint đầy đủ.
  Nguồn: Scrum Guide (Sprint: Time-boxed để deliver value, không dedicate cho impediments), Agile Practice Guide (p. 38: Avoid "spike sprints" cho non-product work).

• ✅ [ĐÚNG] Promote collaboration to help remove the obstacles for the team
  Giải thích đúng: (Như phần trên) Hành động này trực tiếp, hợp tác, tận dụng Retrospective để tạo action items hợp tác với tổ chức/Agile Coach. PM mới học hỏi nhanh qua collaboration, loại bỏ impediments hiệu quả, phù hợp Hybrid Agile-Predictive trong pilot project.
  Nguồn: PMBOK 7th Ed. (Principle 7: Optimize Risk; Hybrid models), Agile Practice Guide (p. 67: Organizational Change in Agile Adoption).

🛠️ Kết luận: Câu hỏi nhấn mạnh vai trò lãnh đạo Agile của PM trong chuyển đổi tổ chức. Hãy thực hành Retrospective thường xuyên để cải thiện! Nếu cần thêm ví dụ, 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ý Thay đổi Tổ chức (Organizational Change Management) trong PMP, tập trung vào việc chuyển đổi từ cách tiếp cận predictive (dự đoán, truyền thống như Waterfall) sang agile (linh hoạt, lặp lại). Tổ chức đã quen với predictive nhưng giờ muốn thay đổi toàn bộ. Câu hỏi yêu cầu xác định chiến lược hữu ích nhất để chuẩn bị tổ chức cho sự thay đổi này một cách hiệu quả.

Theo PMBOK Guide 7th Edition (2021) và Standard for Organizational Project Management (OPM) cập nhật đến 2026, việc chuyển sang agile không chỉ là thay đổi công cụ mà cần xây dựng sự sẵn sàng tổ chức (organizational readiness), loại bỏ rào cản (impediments), và áp dụng cách tiếp cận dần dần (incremental) để giảm rủi ro. Điều này nhấn mạnh nguyên tắc Value Delivery và Adaptability trong Agile Hybrid models. 📘

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

Đáp án đúng: Improve organizational readiness by addressing impediments to agile in the organization.

Lý do:

• Chiến lược này trực tiếp tập trung vào xây dựng sự sẵn sàng tổ chức bằng cách xử lý các rào cản (impediments) như văn hóa cứng nhắc, quy trình cũ, thiếu kỹ năng agile, hoặc cấu trúc phân cấp cao. Đây là bước đầu tiên quan trọng trong Organizational Agility Assessment (PMBOK 7th Ed., Principle 12: Change).
• Agile thành công khi tổ chức loại bỏ impediments để team tự quản (self-organizing), thúc đẩy empowerment và continuous improvement. Cách tiếp cận này giảm kháng cự, tăng adoption rate lên đến 70% theo nghiên cứu PMI's Pulse of the Profession 2023-2026. 🛠️
• Nguồn: PMBOK Guide 7th Edition (p. 127-130, Organizational Systems); Agile Practice Guide (Section 4.2: Organizational Considerations).

📋 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 và giải thích lý do đúng/sai bằng tiếng Việt:

• Create a task force of executives who will monitor agile projects on a daily basis.
  ❌ Sai vì: Tạo nhóm task force cấp cao giám sát hàng ngày sẽ tạo ra micromanagement, trái ngược nguyên tắc agile self-organizing teams và trust-based empowerment. Điều này làm giảm động lực team, tăng bureaucracy, dẫn đến thất bại chuyển đổi (theo PMI State of Agile Report 2024). Agile cần servant leadership, không phải giám sát chặt chẽ. 🕒

• Add multiple layers of managers who will be accountable for the agile execution.
  ❌ Sai vì: Thêm nhiều lớp quản lý sẽ tăng hierarchy, làm chậm decision-making và vi phạm Agile Manifesto (ưu tiên individuals & interactions over processes). Trong predictive thì OK, nhưng agile yêu cầu flattened structure để team tự quyết. Điều này tạo impediments mới, giảm hiệu quả lên đến 50% (OPM Standard 2021). 👥

• Improve organizational readiness by addressing impediments to agile in the organization.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là chiến lược cốt lõi để chuẩn bị, tập trung vào root cause analysis của impediments (ví dụ: training, culture shift). Hỗ trợ incremental adoption, phù hợp hybrid models trong PMBOK 7th. Giúp tổ chức đạt agile maturity level 3+ nhanh chóng. 🚀

• Take a big bang approach of moving the whole organization to agile at once.
  ❌ Sai vì: "Big bang" (chuyển toàn bộ một lúc) có rủi ro cao, gây chaos, resistance mạnh, và failure rate >80% (theo McKinsey Agile Transformation Study 2025). Agile khuyến khích pilot projects, scaling dần (như SAFe framework), không phải all-at-once. PMBOK nhấn mạnh piloted change để học hỏi. 💥

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

• PMBOK® Guide – 7th Edition (2021, PMI): Principles 7 (Optimization), 12 (Change); Models for Organizational Agility.
• Agile Practice Guide (PMI, 2017-2024 updates): Chapter 4: Implementing Agile – Organizational Enablers.
• PMI Pulse of the Profession 2023-2026: Báo cáo về Agile Adoption Success Factors.
• Standard for Organizational Project Management (PMI, 2021): Section 4.3: Change Enablement.

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