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

📖 Phân tích câu hỏi trắc nghiệm PMP

🧩 Nội dung câu hỏi được giải thích chi tiết:
Câu hỏi mô tả một tổ chức đang khởi xướng một dự án sử dụng công nghệ mới, dẫn đến mức độ phức tạp cao và đòi hỏi kỹ năng kỹ thuật xuất sắc từ đội ngũ. Sau khi xem xét kế hoạch quản lý dự án đề xuất (proposed project management plan), nhà tài trợ dự án (project sponsor) yêu cầu các lựa chọn để giảm chi phí lao động (labor cost) mà không giới thiệu rủi ro cho việc giao hàng dự án (project delivery).
Câu hỏi tập trung vào hành động đầu tiên (first) mà quản lý dự án (project manager) nên thực hiện. Đây là tình huống thực tế trong quản lý chi phí dự án (Project Cost Management), nơi cần cân bằng giữa giảm chi phí và kiểm soát rủi ro, đặc biệt với dự án công nghệ mới (high complexity). Theo PMP, quản lý dự án phải tailoring kế hoạch để tối ưu hóa giá trị mà không ảnh hưởng đến mục tiêu chính (on-time, on-scope delivery). PMBOK nhấn mạnh việc phân tích gốc rễ vấn đề trước khi thay đổi tài nguyên hoặc kế hoạch.

✅ Đáp án đúng và lý do lựa chọn:
Đáp án đúng: Perform an analysis of the key cost drivers and present alternatives.
🛠️ Lý do: Đây là bước đầu tiên và logic nhất theo quy trình PMP. Trước khi đề xuất bất kỳ thay đổi nào, PM phải phân tích các yếu tố chi phí chính (key cost drivers) như tỷ lệ lương, giờ làm việc, kỹ năng yêu cầu, hoặc phân bổ công việc để xác định các lựa chọn thay thế (alternatives) giảm chi phí lao động mà không tăng rủi ro. Điều này phù hợp với nguyên tắc tối ưu hóa giá trị (Optimize Value) và quy trình Plan Cost Management/Control Costs trong PMBOK, giúp sponsor đưa ra quyết định dựa trên dữ liệu. Hành động này chủ động, dựa trên dữ liệu (data-driven) và tránh các thay đổi mù quáng có thể ảnh hưởng đến chất lượng kỹ thuật cao cần thiết cho dự án công nghệ mới.

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

• Review the risk register and assign functional managers as resources.
  ❌ Sai vì: Việc xem xét sổ đăng ký rủi ro (risk register) và chỉ định quản lý chức năng làm tài nguyên là không liên quan trực tiếp đến yêu cầu giảm chi phí lao động. Risk register dùng để quản lý rủi ro, không phải phân tích chi phí. Hơn nữa, assign functional managers có thể tăng rủi ro vì họ thường không có kỹ năng kỹ thuật chuyên sâu cho công nghệ mới, vi phạm yêu cầu "không giới thiệu rủi ro". Đây không phải bước đầu tiên; PM cần phân tích chi phí trước (theo Process 11.7 Monitor Risks & 9.1 Plan Resource Management).

• Perform an analysis of the key cost drivers and present alternatives.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là hành động đầu tiên chuyên nghiệp, tập trung vào phân tích gốc rễ chi phí (cost drivers analysis) để đề xuất alternatives an toàn, phù hợp với PMP Code of Ethics (Responsibility & Optimize) và Cost Management processes (Estimate Costs, Determine Budget).

• Analyze the resource pool and assign internal resources who participated in past projects.
  ❌ Sai vì: Phân tích hồ sơ tài nguyên và chỉ định nội bộ từ dự án cũ có thể giảm chi phí ngắn hạn nhưng tăng rủi ro cao vì dự án này dùng công nghệ mới đòi hỏi kỹ năng chuyên sâu – nhân sự cũ chưa chắc phù hợp, dẫn đến thiếu kỹ năng và chậm trễ delivery. Đây không phải bước đầu tiên; PM phải phân tích chi phí tổng thể trước khi assign (vi phạm tailoring trong Plan Resource Management).

• Review the work breakdown structure (WBS) to ensure there are adequate resources.
  ❌ Sai vì: Xem xét WBS để đảm bảo tài nguyên đầy đủ chỉ là kiểm tra cơ bản, không giải quyết giảm chi phí mà sponsor yêu cầu. WBS tập trung vào phân tích công việc (decomposition), không phải phân tích chi phí drivers. Hành động này thụ động và không đề xuất alternatives, có thể bỏ lỡ cơ hội tối ưu mà không cần xem xét rủi ro kỹ thuật (theo Create WBS process, nhưng không phải first step cho cost reduction).

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

• PMBOK Guide 7th Edition (2021, cập nhật đến 2026 qua PMI updates): Principles 3 (Optimize Resource Allocation), Process Groups: Planning (Cost & Resource Management), Domain: Cost.
• PMP Examination Content Outline (2021, hiệu lực đến 2026): Task 4.5 (Cost control), Task 8.1 (Manage project resources).
• PMI Code of Ethics & Professional Conduct: Trách nhiệm phân tích dữ liệu trước quyết định thay đổi.
  (Nguồn chính thức từ PMI.org; khuyến nghị thực hành với PMP prep như Rita Mulcahy hoặc PMI Authorized Training).

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

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

Câu hỏi này thuộc chủ đề Quản lý Backlog trong Agile theo phương pháp Scrum (một framework phổ biến trong Agile), liên quan đến phiên bản PMBOK Guide 7th Edition và Agile Practice Guide (cập nhật đến 2023, áp dụng ổn định đến 2026).

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

• Project manager đang sử dụng phương pháp Agile (cụ thể là Scrum với Sprint Planning Meeting).
• Product Owner (PO) đánh dấu một backlog item là high business value (giá trị kinh doanh cao) và easy to implement (dễ triển khai) → Ưu tiên cao cho sprint hiện tại.
• Tuy nhiên, các thành viên team khác phát hiện high dependency (phụ thuộc cao) giữa item này và một item khác được đánh dấu là low business value (giá trị kinh doanh thấp) và high complexity (phức tạp cao).
• Câu hỏi trọng tâm: Project manager nên làm gì để hỗ trợ prioritization backlog (ưu tiên backlog)?

🛠️ Mục tiêu chính: Trong Agile, backlog prioritization là trách nhiệm của PO, nhưng team phải hợp tác để xem xét tính khả thi, rủi ro (như dependencies) và cam kết thực tế. PM đóng vai trò facilitator (người hỗ trợ), không quyết định thay, nhằm đạt team agreement (thỏa thuận chung) để đảm bảo sprint goal khả thi và mang lại value tối ưu.

✅ Đáp án đúng

Facilitate the discussion until the team reaches an agreement about the two items.

Lý do lựa chọn:

• Trong Agile/Scrum, PM là servant leader (lãnh đạo phục vụ), phải facilitate discussion (hỗ trợ thảo luận) để team tự tổ chức (self-organizing team) và đạt consensus (đồng thuận).
• Dependencies là yếu tố quan trọng ảnh hưởng đến tính khả thi, nên không thể bỏ qua ý kiến team. Việc facilitate giúp cân bằng business value (từ PO) và technical risks/dependencies (từ team), đảm bảo backlog prioritization value-driven nhưng realistic.
• Theo PMBOK 7th Ed. (Process 7.1 Plan Stakeholder Engagement) và Agile Practice Guide (Sprint Planning): PM hỗ trợ collaboration, không impose quyết định.

📋 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. Tôi sử dụng ✅ cho đúng và ❌ cho sai, kèm giải thích rõ ràng:

• ❌ Support the team to move both items to the next sprint when the team will know more.
  Phương án này sai vì trì hoãn (defer) cả hai item mà không giải quyết dependency ngay, vi phạm nguyên tắc Agile: Sprint Planning phải cam kết clear backlog cho sprint hiện tại. Trì hoãn làm giảm velocity và bỏ lỡ cơ hội deliver value sớm (time-to-market). Không hỗ trợ prioritization mà né tránh vấn đề.

• ❌ Prioritize the item flagged as high business value and low complexity for this sprint.
  Phương án này sai vì PM không được tự quyết định prioritization (đó là trách nhiệm của PO), và bỏ qua high dependency sẽ tạo rủi ro lớn (item không hoàn thành độc lập, dẫn đến waste). Agile nhấn mạnh holistic view (xem toàn bộ), không chỉ value mà còn feasibility.

• ✅ Facilitate the discussion until the team reaches an agreement about the two items.
  Phương án này đúng vì PM phải facilitate để team collaborate, cân nhắc value + dependency + complexity. Đạt agreement đảm bảo shared understanding, tăng commitment và giảm rework. Phù hợp Scrum Guide 2020 (Sprint Planning) và PMBOK 7 (Tailoring Agile).

• ❌ Prioritize the item flagged as a dependency with low business value and high complexity.
  Phương án này sai vì ưu tiên item low value/high complexity vi phạm nguyên tắc value-based prioritization (PO quyết định dựa trên business value). Dependencies chỉ là input để discuss, không phải lý do đảo ngược priority mà không có consensus.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Section 4.5.2 (Team Performance Domain) – Nhấn mạnh facilitation và team agreement trong Agile.
• Agile Practice Guide (PMI, 2017/2021): Chapter 5.3 (Sprint Planning) – PO leads prioritization, team provides input on dependencies.
• Scrum Guide (2020, ổn định đến 2026): Sprint Planning yêu cầu collaboration giữa PO và Development Team.
• PMI Agile Certified Practitioner (PMI-ACP) Handbook: Servant leadership của PM trong backlog refinement.

Hy vọng phân tích này giúp bạn nắm vững kiến thức PMP Agile! 🚀 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ý thời gian dự án (Project Time Management) trong PMP, cụ thể liên quan đến các kỹ thuật ước lượng thời gian hoạt động (Estimate Activity Durations) theo PMBOK® Guide – Seventh Edition (và cập nhật đến 2026 từ PMI).

Tình huống: Quản lý dự án gặp gỡ đội ngũ phát triển để ước lượng thời gian hoàn thành một ứng dụng phần mềm. Điểm quan trọng là đội ngũ lập trình viên mới vào công ty và chưa từng phát triển ứng dụng tương tự. Điều này nhấn mạnh sự thiếu kinh nghiệm lịch sử (no historical data) và mức độ không chắc chắn cao (high uncertainty). Do đó, kỹ thuật ước lượng cần phù hợp với tình huống thiếu dữ liệu tham chiếu, tập trung vào việc xử lý rủi ro và biến động ước lượng từ đội ngũ hiện tại.

Mục tiêu: Chọn kỹ thuật ước lượng thời gian phù hợp nhất để khuyến nghị.

✅ Đáp án đúng: Three-point estimating

Lý do lựa chọn (theo PMBOK® Guide 7th Edition, Planning Performance Domain và kỹ thuật ước lượng trong Agile/Hybrid practices cập nhật):
🛠️ Kỹ thuật Three-point estimating (hay còn gọi là PERT - Program Evaluation and Review Technique) sử dụng ba giá trị ước lượng: Optimistic (O), Most Likely (M), và Pessimistic (P), với công thức tính giá trị mong đợi: (O + 4M + P)/6.
📈 Phương pháp này lý tưởng cho tình huống thiếu dữ liệu lịch sử và uncertainty cao, vì nó cho phép đội ngũ mới đánh giá phạm vi thời gian dựa trên kinh nghiệm cá nhân, giảm bias và cung cấp khoảng tin cậy (confidence interval). Trong bối cảnh đội ngũ mới chưa làm dự án tương tự, nó giúp quản lý dự án thu thập input từ team một cách khoa học, phù hợp với nguyên tắc data-driven estimation trong PMBOK 7th (Tool & Technique: Three-point estimation for handling variability).
Không có dữ liệu tương tự → tránh analogous/parametric; planning poker thiên về Agile sizing → Three-point linh hoạt hơn cho predictive/traditional projects.

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

• ❌ Analogous estimating
  Sai vì kỹ thuật này dựa trên dữ liệu lịch sử từ các dự án tương tự trước đó (top-down approach, sử dụng actual durations từ projects tương đồng). Trong trường hợp này, đội ngũ mới và chưa từng phát triển ứng dụng tương tự → không có dữ liệu lịch sử đáng tin cậy, dẫn đến ước lượng không chính xác và rủi ro cao (PMBOK 7th: Chỉ dùng khi có similarity cao).

• ❌ Parametric estimating
  Sai vì phương pháp này sử dụng mô hình toán học/thống kê dựa trên parameters (ví dụ: số dòng code/giờ từ dữ liệu ngành hoặc lịch sử). Với đội ngũ mới, thiếu dữ liệu tham số đáng tin cậy → không áp dụng được, dễ dẫn đến sai lệch (PMBOK 7th: Yêu cầu historical records hoặc industry benchmarks).

• ❌ Planning poker
  Sai vì đây là kỹ thuật Agile/Scrum dùng cho relative estimation (sử dụng Fibonacci sequence để team consensus story points). Phù hợp với backlog items đã quen thuộc, nhưng ở đây dự án chưa rõ tính tương tự và đội ngũ mới → không hiệu quả cho absolute time estimation ở giai đoạn đầu predictive projects (PMBOK 7th: Agile techniques, nhưng không ưu tiên khi thiếu familiarity).

• ✅ Three-point estimating
  Đúng (như đã giải thích ở trên). 🏆 Hoàn hảo cho high uncertainty, new team, giúp tạo baseline schedule đáng tin cậy.

📚 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, cập nhật PMI standards đến 2026): Planning Performance Domain (Estimation techniques), trang 142-145; Process 6.4 Estimate Activity Durations (từ PMBOK 6th, vẫn áp dụng hybrid).
• PMI Agile Practice Guide (2021): Phân biệt estimation techniques giữa Predictive vs. Adaptive.
• The Standard for Project Management (2021): Nhấn mạnh handling uncertainty với three-point.

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

📖 Nội dung câu hỏi:
Câu hỏi mô tả tình huống thực tế trong quản lý dự án: Người tài trợ dự án (project sponsor) kiên quyết yêu cầu phạm vi dự án (project scope) cho việc ra mắt sản phẩm mới phải bao gồm hai địa điểm địa lý. Tuy nhiên, sau phiên scoping (xác định phạm vi ban đầu), project charter (hiến chương dự án) đã được hoàn thành và phê duyệt chỉ với một địa điểm.
🛠️ Bối cảnh PMP: Theo quy trình PMP (PMBOK Guide 7th Edition và cập nhật đến 2026), project charter là tài liệu chính thức xác định phạm vi ban đầu, mục tiêu dự án và được phê duyệt bởi sponsor. Nó tạo thành baseline ban đầu cho phạm vi. Bất kỳ thay đổi nào sau khi phê duyệt đều phải tuân thủ quy trình kiểm soát thay đổi tích hợp (Integrated Change Control) để đánh giá tác động và phê duyệt chính thức, tránh rủi ro lệch hướng dự án.

📌 Đáp án đúng:
✅ Assess the impact to the scope and submit a change request for approval of the two locations before including them in the scope of the project.

Lý do chọn đáp án đúng (bằng tiếng Việt):
🟢 Đây là hành động chuẩn mực và chuyên nghiệp nhất theo PMP. Project manager (PM) phải đánh giá tác động (assess impact) đến phạm vi, thời gian, chi phí, rủi ro... trước khi thực hiện thay đổi. Sau đó, gửi yêu cầu thay đổi (change request) để hội đồng kiểm soát thay đổi (CCB) hoặc sponsor phê duyệt chính thức. Điều này đảm bảo tính minh bạch, kiểm soát baseline scope và tuân thủ quy trình Perform Integrated Change Control (4.6) trong PMBOK 7th Edition. Không tự ý thêm scope mà không phê duyệt sẽ vi phạm nguyên tắc quản lý thay đổi.

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

• ❌ Ask the sponsor to increase the budget and schedule of the project to accommodate the additional scope.
  ❌ Sai vì: Phương án này bỏ qua quy trình kiểm soát thay đổi chính thức. Sponsor không thể tự ý phê duyệt tăng ngân sách/lịch trình mà không qua đánh giá tác động đầy đủ. PM không được giả định thay đổi mà phải submit change request trước. Vi phạm ** nguyên tắc Integrated Change Control**, có thể dẫn đến scope creep (mở rộng phạm vi không kiểm soát).

• ✅ Assess the impact to the scope and submit a change request for approval of the two locations before including them in the scope of the project.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là bước tích hợp và chuyên nghiệp, tuân thủ Develop Project Charter (1.2) và Perform Integrated Change Control (4.6). PM chủ động đánh giá (scope, cost, schedule baseline) và yêu cầu phê duyệt, bảo vệ dự án khỏi thay đổi không mong muốn.

• ❌ Discuss with the sponsor that the project scope is approved and it is not possible to include two locations as it will affect the budget.
  ❌ Sai vì: Phương án này thiếu linh hoạt và hợp tác, từ chối yêu cầu sponsor mà không đánh giá tác động. PM có trách nhiệm facilitate change (hỗ trợ thay đổi hợp lý) theo PMBOK, không phải "đóng cửa" ngay lập tức. Điều này có thể làm mất lòng tin sponsor và vi phạm vai trò PM là facilitator trong stakeholder engagement.

• ❌ Encourage the sponsor to start another project for the additional location so that the current project is not impacted.
  ❌ Sai vì: Gợi ý khởi động dự án mới là tránh né vấn đề, không giải quyết yêu cầu hợp lý từ sponsor. Scope có thể điều chỉnh nếu phê duyệt đúng quy trình, không cần tách dự án ngay. Vi phạm Stakeholder Management (Manage Stakeholder Engagement - 13.3) và có thể tăng overhead quản lý dự án.

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

• PMBOK Guide 7th Edition (2021, với cập nhật Agile/ Hybrid 2025-2026): Chương 4 (Integration), Process 1.2 (Develop Project Charter) và 4.6 (Perform Integrated Change Control).
• PMI Agile Practice Guide (2025 update): Nhấn mạnh đánh giá tác động thay đổi trong môi trường hybrid.
• PMP Exam Content Outline (2024-2026): Domain 2: Process (30%), tập trung Change Control và Scope Management.
  🛠️ Nguồn chính thức: PMI.org, PMBOK 7th PDF (trang 77-81 về Charter & Change). Khuyến nghị thực hành qua PMI Authorized Training Partner (PMP prep 2026 syllabus).

Hy vọng phân tích này giúp bạn nắm vững quy trình PMP! 🚀 Nếu cần thêm ví dụ case study, hãy hỏi nhé!

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

Câu hỏi mô tả một tình huống thực tế trong dự án iterative (lặp lại theo vòng lặp), đang ở iteration thứ 5 trên tổng số 6 iteration – nghĩa là dự án gần hoàn thành (giai đoạn cuối). Bất ngờ, một thành viên đội ngũ rời khỏi công ty, gây ra rủi ro tiềm ẩn về tiến độ, chất lượng và nguồn lực.

Câu hỏi yêu cầu: Project Manager (PM) nên làm gì TIẾP THEO (next step) để xử lý tình huống này?
Đây là chủ đề liên quan đến quản lý rủi ro (Risk Management), quản lý stakeholder (Stakeholder Engagement) và quản lý đội ngũ (Team Management) trong môi trường Agile/Iterative (theo PMBOK® Guide 7th Edition và PMI Agile Practice Guide, cập nhật đến 2026 với PMBOK® 8th draft principles).
⚠️ Tập trung: Không phải xử lý ngay lập tức bằng cá nhân (hero mode), mà ưu tiên hợp tác, minh bạch và điều chỉnh kế hoạch để đảm bảo giá trị giao hàng (value delivery) ở giai đoạn cuối dự án.

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

Invite the stakeholders to discuss a mitigation plan.

Lý do:

• Trong dự án iterative gần kết thúc (iteration 5/6), việc mất thành viên là rủi ro/issue lớn, PM cần hợp tác với stakeholders để cùng xây dựng mitigation plan (kế hoạch giảm thiểu) – phù hợp nguyên tắc Stakeholder Engagement và Adaptive Planning (PMBOK® 7th, Principle 5: Stakeholders & Principle 12: Adaptability).
• Next step lý tưởng: Thảo luận chung để đánh giá tác động, ưu tiên backlog, tái phân bổ công việc hoặc điều chỉnh scope/timeline, tránh quyết định đơn lẻ.
• Emoji nhấn mạnh: 🛠️ Hành động hợp tác giúp dự án linh hoạt, tối ưu hóa giá trị mà không escalate sớm.

📘 Nguồn tham khảo:

• PMBOK® Guide 7th Edition (2021): Section 4.6 Manage Project Risks & Section 4.2 Engage Stakeholders.
• Agile Practice Guide (PMI, 2017+ updates to 2026): Emphasize collaborative retrospectives & iteration planning.
• PMP Exam Content Outline 2021 (Domain IV: People, Task 2: Manage & mentor team).

📋 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, với lý do đúng/sai dựa trên best practices PMP mới nhất:

• ✅ Invite the stakeholders to discuss a mitigation plan.
  Đúng vì: Như giải thích trên, ưu tiên engage stakeholders sớm để cùng mitigation, đặc biệt ở late-stage iteration. Tránh assume delay, tập trung giải pháp collaborative. 🏆 Hoàn hảo cho Agile mindset!

• ❌ Take on some of the necessary work to minimize the impact.
  Sai vì: PM không nên tự gánh việc (heroic management) – vi phạm nguyên tắc servant leadership (PMBOK® 7th, Principle 7: Leadership). Gây burnout, không sustainable, bỏ qua cơ hội phát triển team/stakeholders. Next step phải strategic, không tactical cá nhân. 🚫

• ❌ Detail the reason for the project delay in the status report.
  Sai vì: Chưa chắc chắn delay (có thể mitigate kịp), và status report không phải next step ngay lập tức – chỉ report sau khi assess. Vi phạm Monitor & Control flow (PMBOK® 7th, Section 4.8 Monitor & Control Project Work). Tập trung giải pháp trước báo cáo! 📤

• ❌ Register an issue and escalate it to the project sponsor.
  Sai vì: Escalate quá sớm mà chưa thử resolve internally hoặc với stakeholders. Issue log cần (PMBOK® 7th, Risk Register), nhưng next step là mitigate/discuss, không phải đẩy sponsor ngay (chỉ khi unresolvable). Phù hợp Escalation Threshold (Agile Practice Guide). ⏫

🧩 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 xây dựng: Một công ty xây dựng đang thực hiện hợp đồng thay thế các bộ phận nhất định của tòa nhà, với các mốc thời gian cố định (firm milestones). Trong quá trình thực hiện, khách hàng phàn nàn rằng các bộ phận mới không đáp ứng yêu cầu (requirements). 🛠️
Vấn đề cốt lõi: Project Manager (PM) cần làm gì trước đó để ngăn ngừa tình huống này xảy ra? Đây là câu hỏi kiểm tra kiến thức về Quản lý Chất lượng (Quality Management) trong PMP, nhấn mạnh việc lập kế hoạch và định nghĩa rõ ràng tiêu chí chấp nhận (acceptance criteria) từ đầu để tránh tranh chấp sau này. Theo PMBOK® Guide (phiên bản mới nhất), chất lượng phải được xây dựng vào dự án từ giai đoạn lập kế hoạch, không phải khắc phục sau.

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

Đáp án đúng: Defined acceptance criteria in a quality checklist agreed upon before starting the build phase

Lý do:
Để ngăn ngừa khiếu nại về chất lượng, PM phải định nghĩa rõ ràng tiêu chí chấp nhận (acceptance criteria) trong một bảng kiểm tra chất lượng (quality checklist) và đồng ý với khách hàng trước khi bắt đầu giai đoạn xây dựng. Điều này thuộc quy trình Plan Quality Management và Manage Quality (PMBOK® 7th Edition), đảm bảo mọi bên hiểu rõ "đáp ứng yêu cầu" nghĩa là gì. Bằng cách này, PM tránh được tranh chấp chủ quan, kiểm soát chất lượng từ đầu và tuân thủ nguyên tắc Quality Principle (chất lượng là trách nhiệm của mọi người). ✅ Đây là hành động phòng ngừa chủ động, phù hợp với tình huống có "firm milestones" cần kiểm soát chặt chẽ.

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

• Continuously communicated the changes in the work plan and the agreement to the client
  ❌ Sai: Phương án này giả định có "thay đổi (changes)" trong kế hoạch làm việc và thỏa thuận, nhưng câu hỏi không đề cập đến bất kỳ thay đổi nào – vấn đề là các bộ phận mới không đáp ứng yêu cầu ban đầu. Giao tiếp liên tục chỉ hữu ích cho thay đổi, không phải định nghĩa chất lượng từ đầu (Stakeholder Engagement Principle). Không ngăn ngừa được khiếu nại gốc rễ.

• Defined acceptance criteria in a quality checklist agreed upon before starting the build phase
  ✅ Đúng: Như đã giải thích ở trên, đây là biện pháp phòng ngừa chuẩn mực trong Quality Management Performance Domain. Checklist chất lượng với tiêu chí chấp nhận được đồng ý trước giúp xác định rõ "meet requirements" là gì, tránh hiểu lầm và đảm bảo kiểm tra tại milestones. Hoàn hảo cho dự án xây dựng với mốc cố định!

• Provided compensation for issues due to the variance in the agreed-upon requirements
  ❌ Sai: Đây là hành động khắc phục hậu quả (reactive) sau khi vấn đề xảy ra (variance), không phải ngăn ngừa trước. Bồi thường chỉ giải quyết tranh chấp, không ngăn chặn khiếu nại từ gốc (Procurement Management hoặc Contract Management). PMBOK nhấn mạnh preventive actions thay vì bồi thường.

• Approved a detailed change management process before starting the build phase
  ❌ Sai: Quy trình quản lý thay đổi (Change Control) chỉ áp dụng khi có yêu cầu thay đổi scope/baseline, nhưng vấn đề ở đây là không đáp ứng yêu cầu gốc, không phải thay đổi. Dù tốt để có quy trình, nó không trực tiếp định nghĩa chất lượng hay tiêu chí chấp nhận (Integrated Change Control process).

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, cập nhật đến 2026):
  • Quality Management Performance Domain (trang 83-87): Nhấn mạnh định nghĩa acceptance criteria và checklists để đo lường chất lượng.
  • Plan Quality Management (Process 8.1): Lập kế hoạch tiêu chí chất lượng trước thực hiện.
  • Manage Quality (Process 8.2): Sử dụng checklists để kiểm tra và đồng ý với stakeholder.
• PMP Examination Content Outline (2024 update): Domain III - Business Environment (Quality aspects), kiểm tra preventive quality actions.
• PMI Practice Standard for Quality Management: Khuyến nghị checklists agreed-upon cho acceptance testing.

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

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

Câu hỏi này thuộc lĩnh vực Quản lý Rủi ro (Project Risk Management) trong PMP, đặc biệt trong môi trường Agile.
📖 Tình huống: Một đội Agile đang ở giai đoạn đầu của chu kỳ phát triển dự án, nhưng đã bắt đầu giao chức năng cho khách hàng (phù hợp với Agile: early and continuous delivery). Đội đã xác định (identified) các rủi ro và đang phát triển chiến lược giảm thiểu (developing mitigation strategy).
❓ Câu hỏi: Project Manager nên làm gì tiếp theo?
🛠️ Bối cảnh PMP mới nhất (PMBOK 7th Edition & Agile Practice Guide 2021, cập nhật đến 2026): Trong Agile, quản lý rủi ro là iterative và liên tục, nhưng vẫn tuân thủ quy trình cơ bản: Identify Risks → Perform Qualitative Risk Analysis (prioritize) → Update Risk Register → Plan Risk Responses. Đội đã identify và đang develop responses, nên bước tiếp theo là cập nhật và ưu tiên rủi ro vào Risk Register trước khi triển khai.

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

Đáp án đúng: Incorporate and prioritize the risks in the risk register according to impact.
Lý do:
🧩 Sau khi xác định rủi ro, bước tiếp theo theo PMBOK 7th (Process 11.3: Perform Qualitative Risk Analysis) là cập nhật Risk Register bằng cách ưu tiên rủi ro dựa trên impact (xác suất x mức độ ảnh hưởng). Trong Agile, Risk Register được duy trì động (living document) để hỗ trợ decision-making nhanh chóng. Việc này đảm bảo rủi ro được theo dõi và quản lý có hệ thống trước khi phát triển hoặc triển khai mitigation strategy. Không làm bước này sẽ dẫn đến thiếu cơ sở dữ liệu để escalate hoặc implement.
📘 Nguồn: PMBOK® Guide 7th Edition (Section 11.2.2.2 Risk Register); Agile Practice Guide (Risk Management in Agile, p.45-47).

📋 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai) với lý do chi tiết bằng tiếng Việt:

• Escalate the risk to the project sponsor and steering committee.
  ❌ Sai: Việc escalate quá sớm vì rủi ro chưa được ưu tiên hoặc phân tích (qualitative/quantitative). Theo PMBOK 7th, chỉ escalate high-priority risks sau khi prioritize trong Risk Register. Trong Agile, PM giữ rủi ro ở mức đội ngũ trước khi cần hỗ trợ bên ngoài.
  📘 Nguồn: PMBOK® Guide 7th (11.7 Manage Project Risks); Agile Practice Guide (Escalation in Agile, p.52).

• Implement the risk mitigation strategy according to the highest impact.
  ❌ Sai: Chưa thể implement vì mitigation strategy đang đang phát triển (developing), chưa hoàn chỉnh và chưa được approve. PMBOK yêu cầu Plan Risk Responses trước (Process 11.5), và implement thuộc Monitor Risks (sau khi prioritize). Trong Agile, implement sớm có thể gây waste nếu rủi ro chưa được validate.
  📘 Nguồn: PMBOK® Guide 7th (11.5 Plan Risk Responses); Agile Practice Guide (Risk Response in Sprints, p.48).

• Incorporate and prioritize the risks in the risk register according to impact.
  ✅ Đúng: Như đã giải thích ở trên, đây là bước tiếp theo logic sau identify risks. Risk Register là công cụ trung tâm để track, prioritize (theo probability-impact matrix), hỗ trợ phát triển mitigation hiệu quả trong Agile.
  📘 Nguồn: PMBOK® Guide 7th (11.2 Identify Risks & 11.3 Perform Qualitative Risk Analysis).

• Determine if any of the new risks have any financial impact.
  ❌ Sai: Đây là phân tích định lượng (quantitative analysis) – bước sau qualitative prioritization. PMBOK 7th khuyến nghị qualitative trước (impact tổng quát), quantitative chỉ cho high-priority risks. Trong Agile early phase, tập trung prioritize nhanh thay vì deep financial dive.
  📘 Nguồn: PMBOK® Guide 7th (11.4 Perform Quantitative Risk Analysis); Agile Practice Guide (Quantitative in Agile, p.46).

🏆 Kết luận và lời khuyên PMP

🛠️ Trong Agile PMP, Project Manager đóng vai trò facilitator, đảm bảo quy trình risk management iterative nhưng có cấu trúc. Hãy luôn cập nhật Risk Register như một artifact sống để hỗ trợ Daily Stand-ups và Sprint Reviews!
📚 Tài liệu tham khảo chính:

• PMBOK® Guide – 7th Edition (PMI, 2021).
• Agile Practice Guide (PMI, 2021).
• PMP Exam Content Outline 2021 (cập nhật 2024-2026, Domain 4: Risk Management).
  Nếu cần ví dụ thực tế hoặc câu hỏi tương tự, hãy hỏi thêm 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ý Giao tiếp (Manage Communications) và Quản lý Các bên liên quan (Manage Stakeholder Engagement) trong PMP, theo PMBOK Guide 7th Edition (và cập nhật đến 2026 không thay đổi cơ bản).

📖 Tình huống mô tả: Một bên liên quan dự án (stakeholder) phàn nàn vì không nhận được một sản phẩm giao (deliverable) quan trọng theo đúng lịch trình (schedule). Thành viên đội ngũ chịu trách nhiệm cho sản phẩm đó giải thích rằng họ đã gửi email thông báo cho bên liên quan về việc chậm trễ (delay). Vấn đề cốt lõi là giao tiếp không hiệu quả: Email từ team member có thể không được nhận, không được đọc, hoặc không được coi là kênh giao tiếp chính thức. Câu hỏi tập trung vào hành động mà Quản lý dự án (Project Manager - PM) nên làm để tránh tình huống này xảy ra từ đầu, nhấn mạnh trách nhiệm của PM trong việc đảm bảo thông tin được truyền đạt đúng, kịp thời và được xác nhận (verified).

🛠️ Mục tiêu chính: PM phải chủ động kiểm soát giao tiếp để tránh hiểu lầm, đặc biệt với các thay đổi lịch trình ảnh hưởng đến stakeholder. Điều này liên quan đến các nguyên tắc như Tailoring Communications (tùy chỉnh giao tiếp theo nhu cầu stakeholder) và Escalation (nếu cần).

✅ Đáp án đúng: Confirmed that the stakeholder was made aware of the delivery delay.

Lý do lựa chọn (theo PMBOK 7th Edition, Section 4.5 Manage Communications & 4.6 Monitor Stakeholder Engagement):
PM có trách nhiệm xác nhận (confirm) rằng bên liên quan đã nhận thức đầy đủ về chậm trễ, thay vì chỉ dựa vào việc team member gửi email (có thể không đáng tin cậy). Việc "confirm" giúp tránh tình huống stakeholder bất ngờ phàn nàn, đảm bảo giao tiếp hai chiều (bidirectional). Đây là hành động phòng ngừa (preventive) tốt nhất, phù hợp với Project Management Principles như Stewardship (quản lý trách nhiệm) và Teamwork. Nếu PM đã confirm từ đầu (ví dụ: yêu cầu team member báo cáo sau gửi email, hoặc follow-up trực tiếp), tình huống sẽ không xảy ra.
📘 Tài liệu tham khảo: PMBOK Guide 7th Edition, trang 72-74 (Communications Management) & PMI Code of Ethics (trách nhiệm xác thực thông tin).

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

• Confirmed that the stakeholder was made aware of the delivery delay.
  ✅ Đúng. Như đã giải thích, đây là hành động chủ động của PM để xác thực hiệu quả giao tiếp, tránh rủi ro stakeholder không hay biết. PMBOK nhấn mạnh "confirmation of receipt" trong giao tiếp dự án để đảm bảo tính minh bạch.

• Communicated with the stakeholder directly regarding the delivery delay.
  ❌ Sai. Mặc dù giao tiếp trực tiếp là tốt (PM nên làm nếu cần escalate), nhưng đây là hành động phản ứng (reactive) sau sự cố, không phải để tránh tình huống từ đầu. Câu hỏi yêu cầu "to avoid this situation", và team member đã gửi email – PM cần confirm trước thay vì tự làm tất cả.

• Told the team member to send the unfinished deliverable to the stakeholder and finalize it later.
  ❌ Sai. Hành động này vi phạm Quality Management Principles (PMBOK Section 4.2) và Integrity trong PMI Code of Ethics. Gửi sản phẩm chưa hoàn thiện là rủi ro cao, có thể gây mất lòng tin và không tuân thủ Deliverable Acceptance Criteria. Không bao giờ chấp nhận "finalize later" mà không thông báo rõ ràng.

• Ensured that the team member did not communicate directly with the project stakeholder.
  ❌ Sai. Điều này trái với Stakeholder Engagement Plan (PMBOK 4.6), nơi giao tiếp có thể đa kênh tùy tailoring. Cấm team member giao tiếp trực tiếp sẽ làm chậm quy trình và không khuyến khích Team Collaboration. PM nên hướng dẫn kênh đúng, không cấm đoán.

🛠️ Bài học rút ra cho PMP: Luôn áp dụng RACI Matrix cho giao tiếp (PM chịu trách nhiệm Approve/Confirm) và sử dụng công cụ như Issue Log để theo dõi delay. Thực hành này giúp dự án tuân thủ Hybrid/Agile approaches trong PMBOK 7th!
📘 Nguồn chính: PMBOK Guide 7th Edition (2021, cập nhật không thay đổi đến 2026), PMI.org Practice Standard for Project Communications Management.

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

Câu hỏi này xoay quanh tình huống thực tế trong quản lý dự án PMP: Project Manager (PM) đã gửi lời mời họp on-site (tại chỗ) cho 7 người, bao gồm các bên liên quan chính (stakeholders), để tổ chức kick-off meeting (họp khởi động dự án). Tuy nhiên, một key stakeholder (bên liên quan chính) từ chối tham gia vì họ sẽ ở một địa điểm khác suốt phần còn lại của tháng.

🛠️ Mục tiêu câu hỏi: Kiểm tra khả năng của PM trong việc quản lý sự tham gia của stakeholders (Stakeholder Engagement), giao tiếp (Communications Management), và linh hoạt điều chỉnh mà không làm chậm tiến độ dự án. Kick-off meeting rất quan trọng để căn chỉnh kỳ vọng, vai trò, và cam kết từ tất cả stakeholders (theo PMBOK 7th Edition, phần 4.6 Develop Team & 13. Stakeholder Engagement). PM cần ưu tiên bao gồm key stakeholder mà không delay dự án, phù hợp với nguyên tắc Tailoring và Hybrid Approaches trong môi trường làm việc hiện đại (cập nhật đến 2026 với PMBOK 7th & updates).

✅ Đáp án đúng

Make arrangements for the stakeholder to join the kick-off meeting virtually.

Lý do lựa chọn 📘:
Đây là lựa chọn tối ưu vì PM chủ động hỗ trợ sự tham gia của key stakeholder qua hình thức virtual (trực tuyến), đảm bảo tất cả mọi người đều tham dự mà không thay đổi lịch họp gốc (tránh delay dự án). Điều này tuân thủ Stakeholder Engagement (PMBOK 7th Ed., Principle 7: Optimize Risk Responses & Process 13.3), nơi PM phải tối ưu hóa sự tham gia của stakeholders quan trọng. Virtual meeting là giải pháp hybrid linh hoạt, phổ biến post-COVID và được khuyến nghị trong PMI Standards 2021-2026 để duy trì value delivery nhanh chóng.

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

• ❌ Change the kick-off meeting to a virtual meeting so all can attend at the same time.
  Sai vì: Phương án này thay đổi toàn bộ hình thức họp từ on-site sang virtual, có thể không phù hợp nếu các stakeholders khác đã chuẩn bị cho họp tại chỗ (ví dụ: logistics, chi phí di chuyển). Nó bỏ qua nguyên tắc Tailoring (PMBOK 7th, Section 2.3), nơi PM chỉ điều chỉnh cần thiết cho cá nhân, không ảnh hưởng toàn bộ nhóm. Điều này có thể làm giảm hiệu quả tương tác on-site mong muốn cho kick-off.

• ❌ Hold the kick-off meeting with the rest of the stakeholders to tiến hành họp mà không có key stakeholder để tránh delay dự án.
  Sai vì: Loại trừ key stakeholder vi phạm Stakeholder Management cốt lõi (PMBOK 7th, Principle 12: Devote Resources & Process 13.1 Identify Stakeholders). Kick-off cần sự hiện diện của tất cả key stakeholders để đảm bảo alignment và buy-in. Delay nhỏ để include họ quan trọng hơn speed, tránh rủi ro thiếu cam kết sau này.

• ❌ Reschedule the kick-off meeting for the following month so all can attend on-site.
  Sai vì: Hoãn họp 1 tháng gây delay lớn cho dự án, vi phạm Principle 1: Be a Diligent Leader và Time Management (PMBOK 7th, Section 4.7 Manage Project Work). Kick-off phải diễn ra sớm để khởi động momentum; hoãn chỉ dùng khi buộc phải, không phải để ép on-site cứng nhắc trong hybrid era.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021, cập nhật PMI 2024-2026): Principle 10 (Stakeholders), Process 13.3 Manage Stakeholder Engagement; Section 2.4 Tailoring.
• PMI Agile Practice Guide (2021): Hybrid models cho meetings (Virtual/On-site).
• The Standard for Project Management (2021): 4.6.2 Kick-Off Activities – Emphasize inclusive participation.
• Nguồn trực tuyến: PMI.org (Stakeholder Sphere Model) & PMP Exam Content Outline 2021 (Domain IV: Stakeholder Management, 17%).

🛠️ Kết luận: PM phải proactive và inclusive để tối ưu stakeholder satisfaction mà giữ project velocity! 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ý Tài nguyên Dự án (Project Resource Management) trong PMP, cụ thể liên quan đến việc đánh giá hiệu suất (performance rating) của các thành viên đội dự án vào cuối dự án. Project manager (PM) được yêu cầu cung cấp đánh giá hiệu suất cho đội ngũ, và cần xác định tài liệu tham chiếu chính (mainly make reference to) để đảm bảo đánh giá công bằng, khách quan và dựa trên cơ sở đã thỏa thuận trước.
📌 Bối cảnh: Cuối dự án, đánh giá này thường dùng để cập nhật hồ sơ nhân sự (HR records), hỗ trợ phát triển đội ngũ, và tuân thủ các quy trình quản lý tài nguyên. Theo PMBOK® Guide 7th Edition, đánh giá hiệu suất phải dựa trên các chỉ số đo lường đã định trước để tránh chủ quan.

✅ Đáp án đúng: Agreed-upon key performance indicators (KPIs)

Lý do lựa chọn:
PM phải chủ yếu tham chiếu đến các chỉ số hiệu suất chính (KPIs) đã được thỏa thuận trước vì chúng là tiêu chí khách quan, đo lường được và được tất cả các bên liên quan đồng ý từ đầu dự án. Điều này đảm bảo đánh giá minh bạch, nhất quán, tránh thiên vị cá nhân. KPIs thường được định nghĩa trong kế hoạch quản lý tài nguyên dự án (Project Resource Management Plan) hoặc cơ sở đo lường hiệu suất (Performance Measurement Baseline).
🛠️ Ứng dụng thực tế: KPIs có thể bao gồm tiến độ công việc hoàn thành, chất lượng đầu ra, hiệu quả chi phí, hoặc kỹ năng phát triển – tất cả đều được theo dõi qua các công cụ như KPI dashboard trong phần Project Performance Domain.

📋 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, với nội dung gốc giữ nguyên bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên nguyên tắc PMP mới nhất (PMBOK® 7th Edition & 8th Edition previews đến 2026):

• ❌ Input from project stakeholders
  Sai vì: Ý kiến từ các bên liên quan (stakeholders) có thể chủ quan, đa dạng và không nhất quán, không phải là tài liệu tham chiếu chính cho đánh giá hiệu suất đội ngũ. Stakeholders cung cấp input cho các quyết định khác (như thay đổi phạm vi), nhưng không thay thế KPIs đã thỏa thuận. Sử dụng input này có thể dẫn đến tranh cãi hoặc thiên vị.

• ❌ Feedback from the project sponsor
  Sai vì: Phản hồi từ nhà tài trợ dự án (sponsor) chỉ là một nguồn ý kiến cá nhân, không đại diện cho đánh giá toàn diện. Sponsor tập trung vào lợi ích kinh doanh tổng thể, không phải hiệu suất chi tiết của từng thành viên đội ngũ. PMBOK nhấn mạnh tránh phụ thuộc vào feedback từ một cá nhân để đảm bảo tính công bằng.

• ✅ Agreed-upon key performance indicators (KPIs)
  Đúng vì: Như đã giải thích ở trên, đây là tiêu chí chính và khách quan nhất, được thỏa thuận từ đầu (trong Resource Management Plan hoặc Team Charter). PMBOK® 7th Edition (Performance Domain: Project Work & Resource) yêu cầu sử dụng KPIs để đo lường và đánh giá, hỗ trợ các hoạt động như Manage Project Resources và Develop Team.

• ❌ Competencies of team members
  Sai vì: Năng lực (competencies) của thành viên là yếu tố đánh giá tĩnh (dựa trên kỹ năng ban đầu), không phản ánh hiệu suất thực tế trong dự án. Đánh giá cuối dự án cần tập trung vào kết quả đạt được (output-based), không chỉ năng lực tiềm năng. Competencies dùng cho việc phân công vai trò, không phải rating hiệu suất.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021): Phần 4. Project Resource Management (trang 99-107), nhấn mạnh KPIs trong Manage Project Resources và Project Performance Domain.
• PMBOK® Guide – Sixth Edition (2017): Process 9.4 Manage Project Team (ITTO: Performance Appraisals dựa trên agreed criteria).
• PMI Agile Practice Guide (2021): KPIs trong Servant Leader Responsibilities cho đánh giá đội ngũ.
• Cập nhật đến 2026: PMI Standards+ (preview 2025-2026) tiếp tục ưu tiên outcome-based KPIs với tích hợp AI-driven performance metrics.

🧩 Kết luận: Câu hỏi kiểm tra khả năng áp dụng nguyên tắc khách quan hóa đánh giá trong PMP. Sử dụng KPIs giúp PM nâng cao hiệu quả đội ngũ cho các dự án tương lai! Nếu cần ví dụ case study, hãy hỏi thêm nhé. 🚀