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

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

Câu hỏi này xoay quanh tình huống trong một cuộc kiểm toán tài liệu (documentation audit) tại công ty quốc tế, phát hiện rằng phiên bản lịch dự án (project schedule) mới nhất chỉ từ 1 tháng trước, dù quản lý dự án (project manager - PM) biết rằng nó đã được cập nhật gần đây. Vấn đề cốt lõi là tài liệu dự án không được cập nhật và chia sẻ đúng cách, dẫn đến sự không đồng bộ giữa thực tế cập nhật và phiên bản lưu trữ chính thức.

🛠️ Mục tiêu câu hỏi: Kiểm tra kiến thức PMP về quản lý tài liệu dự án theo PMBOK Guide 7th Edition (2021) và các cập nhật đến 2026, nhấn mạnh vào việc sử dụng hệ thống thông tin quản lý dự án (Project Management Information System - PMIS) để đảm bảo tài liệu được lưu trữ, cập nhật và chia sẻ kịp thời, minh bạch với các bên liên quan (stakeholders). Điều này thuộc Process Group: Executing & Monitoring & Controlling, cụ thể là Manage Project Knowledge và Manage Communications (Domain: Team & Stakeholders trong 7th Edition).

📘 Nguồn tham khảo:

• PMBOK Guide 7th Edition, phần Project Management Information System (PMIS) (trang 57, Models, Methods, & Artifacts).
• PMBOK Guide 6th Edition, §4.4.2.1 Manage Project Knowledge: Outputs (PMIS đảm bảo tài liệu cập nhật thực thời).

✅ Đáp án đúng

Kept documentation in the project management information system (PMIS), and shared it with appropriate stakeholders

Lý do chọn đáp án này 🏆:
PM phải lưu trữ toàn bộ tài liệu dự án (bao gồm project schedule) trong PMIS – một hệ thống tích hợp (hardware, software, quy trình) để cập nhật tự động, truy cập dễ dàng và chia sẻ an toàn với các bên liên quan phù hợp. Trong tình huống kiểm toán, vấn đề xảy ra vì tài liệu không được cập nhật vào PMIS kịp thời, dù PM đã chỉnh sửa ở nơi khác. PMIS đảm bảo tính nhất quán, traceability và tuân thủ (compliance), đặc biệt với dự án quốc tế. Đây là best practice theo PMBOK 7th Edition, giúp tránh rủi ro kiểm toán và hỗ trợ quyết định dựa trên dữ liệu thực thời (real-time data).

📋 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. Phân tích dựa trên nguyên tắc PMP mới nhất (7th Edition & Agile Hybrid practices đến 2026), tập trung vào trách nhiệm của PM và vai trò PMIS.

• ❌ Updated the project management plan regularly and had it securely shared with all stakeholders
  Sai vì: Phương án này chỉ đề cập đến Project Management Plan (PMP) – một tài liệu tổng hợp cấp cao, không phải project schedule cụ thể (schedule là artifact riêng biệt). Việc cập nhật PMP định kỳ là đúng nhưng không giải quyết vấn đề lịch trình lạc hậu trong kiểm toán. Hơn nữa, chia sẻ với tất cả stakeholders có thể vi phạm nguyên tắc "appropriate stakeholders" (chỉ chia sẻ cần thiết để tránh rò rỉ thông tin nhạy cảm). PMBOK 7th yêu cầu PMIS cho tất cả artifacts, không chỉ PMP.

• ❌ Assigned a project team member to ensure all project documentation was updated
  Sai vì: PM chịu trách nhiệm chính (accountable) cho quản lý tài liệu, không nên ủy quyền hoàn toàn cho thành viên đội ngũ (team member). Đây chỉ là biện pháp hỗ trợ, không phải cách xử lý chuẩn. PMBOK 7th Edition (§People Domain) nhấn mạnh PM phải quản lý trực tiếp qua PMIS, tránh tình trạng "single point of failure" nếu team member bỏ sót. Delegating như vậy không đảm bảo tuân thủ kiểm toán.

• ❌ Reviewed the risk register to identify a response plan for the audit
  Sai vì: Kiểm toán (audit) không phải rủi ro dự án điển hình cần ghi vào Risk Register (chỉ dành cho uncertainty ảnh hưởng mục tiêu dự án). Đây là vấn đề quy trình nội bộ, không phải risk cần response plan. PMBOK 7th (§Uncertainty Domain) phân biệt rõ: Audit thuộc compliance/governance, xử lý qua PMIS và audits process, không phải risk management.

• ✅ Kept documentation in the project management information system (PMIS), and shared it with appropriate stakeholders
  Đúng vì: Như giải thích ở trên, PMIS là công cụ cốt lõi để lưu trữ, cập nhật và chia sẻ tài liệu thực thời, an toàn với stakeholders phù hợp (right information to right people). Điều này trực tiếp giải quyết vấn đề lịch trình "mất tích" trong kiểm toán, đảm bảo traceability và hiệu quả dự án. Hoàn toàn phù hợp PMBOK 7th Edition & PMI updates 2026 (tích hợp AI/cloud cho PMIS).

🛡️ Lời khuyên PMP: Luôn ưu tiên PMIS để tránh các vấn đề tương tự, kết hợp với lessons learned register từ audits trước! Nếu cần đào sâu, tham khảo PMI.org cho exam prep 2026.

🧩 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ý thay đổi dự án (Change Management) trong PMP, cụ thể liên quan đến cách tiếp cận lặp (iterative approach) – một phần của phương pháp Agile hoặc Hybrid.

• Tình huống: Dự án đang ở giai đoạn hoàn thành phase 2 (giai đoạn thứ hai), và đang theo mô hình lặp, nghĩa là dự án phát triển dần dần qua các vòng lặp (iterations), tập trung vào việc giao giá trị liên tục.
• Sự kiện mới: Một quy định mới (new regulation) đã được phê duyệt, ảnh hưởng đến deliverables (sản phẩm giao) ở phase 4 (giai đoạn thứ tư).
• Câu hỏi cốt lõi: Project Manager (PM) nên làm gì tiếp theo (What should the project manager do next?) để xử lý thay đổi này một cách đúng đắn.

🛠️ Nguyên tắc PMP áp dụng: Theo PMBOK® Guide – Seventh Edition (2021) và cập nhật đến 2026, trong dự án iterative, khi có thay đổi bên ngoài (như quy định pháp lý), PM phải đánh giá tác động (impact assessment) trước tiên để hiểu rõ ảnh hưởng đến mục tiêu dự án (objectives), scope, schedule, cost, quality, v.v. Không nhảy ngay vào phê duyệt ngân sách hoặc ngoại lệ mà chưa phân tích. Điều này nằm trong Principle 11: Optimize Risk Responses / Holistic Risk Management và Process: Manage Project Changes (trang 135-137, PMBOK 7th).

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

• PMBOK® Guide – Seventh Edition (PMI, 2021), Domain: Uncertainty & Project Changes.
• Agile Practice Guide (PMI, 2017, tích hợp vào PMBOK 7): Nhấn mạnh "Assess Impact" trong iterative development trước khi quyết định change.

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

Đáp án đúng: Meet with subject matter experts (SMEs) to access the impact to objectives

Lý do:

• Đây là bước đầu tiên và đúng đắn nhất trong quy trình quản lý thay đổi. PM cần gặp chuyên gia chủ đề (SMEs) để đánh giá tác động (assess impact) đến mục tiêu dự án (objectives) – bao gồm value delivery, benefits, và các yếu tố khác.
• Trong iterative approach, phase 4 chưa bắt đầu, nên cần đánh giá sớm để tránh lãng phí, đảm bảo tuân thủ quy định mà không làm lệch hướng dự án.
• Lưu ý nhỏ: "Access" có thể là lỗi đánh máy của "assess" (đánh giá). Điều này phù hợp 100% với Change Control Process ở PMBOK 7th: Impact Analysis trước Approve/Reject.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Tôi sử dụng ✅ cho đúng và ❌ cho sai, kèm lý do dựa trên PMP mới nhất.

• ✅ Meet with subject matter experts (SMEs) to access the impact to objectives
  Giải thích đúng: Phương án này ưu tiên đánh giá tác động – bước cốt lõi trong quản lý thay đổi iterative. SMEs giúp PM hiểu rõ quy định mới ảnh hưởng thế nào đến objectives (mục tiêu như business value, compliance), trước khi quyết định scope creep hoặc điều chỉnh. Điều này tuân thủ PMBOK 7th Principle 4: Build a Team (hợp tác với experts) và Agile Manifesto: Responding to Change. Không hành động vội vã, tránh rủi ro không cần thiết. (Nguồn: PMBOK 7th, trang 141: "Evaluate the impact on project baselines").

• ❌ Consult with the project sponsor to discuss a cost increase
  Giải thích sai: Giả định ngay tăng chi phí (cost increase) mà chưa đánh giá tác động là sai lầm. Sponsor chỉ tham gia sau khi có dữ liệu impact analysis đầy đủ. Điều này vi phạm integrated change control, có thể dẫn đến phê duyệt không chính xác. Trong iterative, ưu tiên dữ liệu trước escalate. (Nguồn: PMBOK 7th, Process 4.7: "Do not approve changes without impact assessment").

• ❌ Acquire approval for an exception to the implementation of the new regulation
  Giải thích sai: Xin ngoại lệ (exception) cho quy định mới là hành động rủi ro cao và không chuyên nghiệp, vì quy định pháp lý thường bắt buộc tuân thủ (compliance). PM chưa assess impact, không biết ngoại lệ có khả thi hay không. Iterative approach khuyến khích adapt thay vì tránh né. (Nguồn: PMI Code of Ethics: "We do not engage in dishonest behavior"; PMBOK 7th, Principle 12: Stakeholders).

• ❌ Get approval for the additional budget from the steering committee
  Giải thích sai: Yêu cầu ngân sách bổ sung (additional budget) từ steering committee mà không có evidence từ impact assessment là premature (quá sớm). Có thể không cần thêm budget nếu thay đổi chỉ ảnh hưởng nhỏ. Trong PMP, change board chỉ approve sau khi có full analysis. (Nguồn: PMBOK 7th, trang 137: "Integrated Change Control requires impact data before funding requests").

🧠 Kết luận nổi bật: Câu hỏi kiểm tra khả năng tư duy hệ thống (holistic thinking) của PM trong môi trường thay đổi nhanh (iterative). Luôn assess trước, act sau để tối ưu value! Nếu áp dụng thực tế, hãy dùng tools như Impact Matrix hoặc MoSCoW prioritization. 🚀

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

Câu hỏi thuộc chủ đề quản lý dự án Agile (theo PMI - Project Management Professional), tập trung vào việc ưu tiên product backlog trong một dự án linh hoạt. Hình ảnh đính kèm bao gồm hai bảng dữ liệu chính:

• Bảng Requirements (Yêu cầu):

  • Requirement 1: Priority 1, ROI = $10,000 ✅ (Giá trị đầu tư cao).
  • Requirement 2: Priority 1, ROI = $8,000 ✅ (Giá trị thấp hơn).
  • Requirement 3: Priority 1, ROI = $25,000 ✅ (Giá trị đầu tư cao nhất).

• Bảng Risks (Rủi ro):

  • Risk 1: Impact = $5,000, Probability = 75% → EMV (Expected Monetary Value) = 5,000 × 0.75 = $3,750 🛠️ (Rủi ro cao nhất về xác suất).
  • Risk 2: Impact = $4,000, Probability = 50% → EMV = 4,000 × 0.50 = $2,000 (Rủi ro thấp nhất).
  • Risk 3: Impact = $20,000, Probability = 45% → EMV = 20,000 × 0.45 = $9,000 (Rủi ro cao nhất về giá trị mong đợi).

Mục tiêu câu hỏi: Xác định thứ tự ưu tiên trong product backlog theo nguyên tắc Agile (PMBOK 7th Edition & Agile Practice Guide). Trong Agile, backlog được ưu tiên dựa trên:

• Business Value (ROI): Ưu tiên cao cho yêu cầu mang lại giá trị kinh doanh lớn nhất trước (giảm dần ROI) 📈.
• Risk Mitigation: Xử lý rủi ro sớm bằng cách tính EMV (giá trị rủi ro mong đợi), ưu tiên rủi ro cao nhất sau các yêu cầu giá trị cao để cân bằng value‑risk (giảm dần EMV) ⚠️.
• Chiến lược tổng thể: High‑value requirements trước → High‑risk mitigations tiếp theo → Low‑value/low‑risk sau. Điều này phù hợp với WSJF (Weighted Shortest Job First) hoặc Risk‑Adjusted Prioritization trong PMI Agile (cập nhật đến 2026, không thay đổi cơ bản từ PMBOK 7).

Lưu ý: Tất cả requirements có Priority 1 (bằng nhau), nên sắp xếp theo ROI giảm dần. Risks được coi như backlog items để mitigate sớm.

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

Đáp án đúng: Requirement 3, Requirement 1, Risk 3, Requirement 2, Risk 1, Risk 2

Lý do chi tiết 🏆:

• Bước 1: Ưu tiên Requirements theo ROI giảm dần → Req3 ($25k) > Req1 ($10k) > Req2 ($8k) 📊.
• Bước 2: Chèn Risks theo EMV giảm dần → Risk3 ($9k) > Risk1 ($3.75k) > Risk2 ($2k) ⚠️, nhưng sau các high‑ROI req để đảm bảo deliver value nhanh, sau đó mitigate risk lớn (Risk3 có EMV cao hơn ROI của Req2 nên xếp trước Req2).
• Kết quả: Req3 (highest value) → Req1 (next value) → Risk3 (highest risk, EMV > Req2 ROI) → Req2 → Risk1 → Risk2. Điều này tuân thủ Agile prioritization matrix (value first, risk‑adjusted), giảm thiểu rủi ro sớm mà không hy sinh ROI cao.

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

• Risk 3, Risk 1, Risk 2, Requirement 3, Requirement 1, Requirement 2
  ❌ Sai: Ưu tiên risks trước requirements vi phạm nguyên tắc Agile (deliver value sớm). Phải làm high‑ROI (Req3) trước để ROI nhanh, không “risk‑first” thuần túy.

• Requirement 3, Risk 3, Requirement 1, Requirement 2, Risk 2
  ❌ Sai: Thứ tự ROI không đúng (Req1 $10k > Req2 $8k, nhưng Req1 xếp sau Req2). Thiếu Risk 1 (EMV cao thứ 2), bỏ qua risk mitigation đầy đủ → backlog không cân bằng.

• Requirement 3, Requirement 1, Requirement 2
  ❌ Sai: Bỏ qua toàn bộ risks! Agile yêu cầu tích hợp risk items vào backlog để mitigate sớm (PMBOK 7: Risk‑Adjusted Backlog). Không xử lý EMV cao như Risk 3 ($9k) dẫn đến dự án dễ thất bại.

• Requirement 3, Requirement 1, Risk 3, Requirement 2, Risk 1, Risk 2
  ✅ Đúng: Hoàn hảo cân bằng high ROI trước (Req3, Req1) → high EMV risk (Risk3 trước Req2 vì $9k > $8k) → low items. Tối ưu value delivery + risk control theo PMI Agile best practices.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, valid to 2026): Chapter 4 & Agile Practice Guide – Backlog Prioritization (p. 72‑75) 🛠️.
• PMI Agile Certified Practitioner (PMI‑ACP) Handbook (2024 updates): Risk‑Adjusted Prioritization using EMV/WSJF.
• PMI Risk Management Framework: Các nguyên tắc tích hợp rủi ro vào backlog và ưu tiên dựa trên EMV.
• Nguồn hình ảnh: Tài liệu mô phỏng câu hỏi PMP Agile (không liên quan tới dịch vụ đám mây).

Hy vọng phân tích này giúp bạn nắm vững Agile backlog grooming! 🚀

🧩 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 (Risk Management) và Quản lý Lịch trình (Schedule Management) trong PMP, cụ thể liên quan đến tình huống khẩn cấp khi một đầu vào chính (main input) cho sản phẩm giao (deliverable) bị thiếu do sự cố giao tiếp sai sót (miscommunication) giữa nhà cung cấp (vendor) và Quản lý dự án (Project Manager - PM). Hậu quả là đường găng (critical path) bị kéo dài, ảnh hưởng nghiêm trọng đến lịch trình dự án.

Câu hỏi yêu cầu xác định hành động tiếp theo (next step) mà PM nên làm ngay lập tức để xử lý vấn đề. Theo nguyên tắc PMP (PMBOK 7th Edition), ưu tiên là thực thi kế hoạch dự phòng (contingency plan) nếu rủi ro đã được xác định trước đó, vì đây là rủi ro đã xảy ra (realized risk) và đang tác động trực tiếp đến critical path. Không nên mất thời gian vào các hoạt động phân tích sau (post-analysis) khi cần hành động khẩn cấp để giảm thiểu tác động.

📘 Dẫn nguồn tham khảo:

• PMBOK® Guide – Seventh Edition (2021), phần Manage Risks (trang 127-132): Nhấn mạnh "Execute the response plan" cho rủi ro đã xảy ra.
• PMI's Practice Standard for Project Risk Management (cập nhật 2022): Contingency plans phải được kích hoạt ngay khi trigger xảy ra.

✅ Đáp án đúng: Execute a contingency plan to address the issue with the vendor

Lý do lựa chọn:

• 🛠️ Đây là hành động tiếp theo đúng đắn nhất vì rủi ro (miscommunication dẫn đến missing deliverable) đã xảy ra và ảnh hưởng critical path. PM phải thực thi ngay kế hoạch dự phòng (contingency plan) đã lập sẵn trong Risk Response Plan để giảm thiểu tác động, thay vì chờ đợi hoặc phân tích thêm.
• Theo PMBOK 7th, quy trình Implement Risk Responses yêu cầu kích hoạt contingency response ngay lập tức khi rủi ro thực hiện (realized), giúp dự án quay lại track nhanh chóng.
• Các hành động khác (audit, review lessons, analysis) là hậu kiểm (after-action), không phải "next" – chúng có thể làm sau khi ổn định tình hình.

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

• ✅ Execute a contingency plan to address the issue with the vendor
  Đúng vì: 🟢 Hành động ưu tiên hàng đầu trong Manage Risks. Contingency plan được thiết kế chính để xử lý tình huống này (vendor-related risk), giúp khắc phục missing input và rút ngắn critical path mà không làm gián đoạn thêm. Đây là best practice để "respond promptly" theo PMBOK 7th.

• ❌ Start an audit of the vendor's processes and procedures
  Sai vì: 🔴 Audit là hoạt động kiểm toán sâu (audit) thuộc Procurements Management hoặc Quality Management, mất thời gian dài và không giải quyết vấn đề ngay lập tức. Next step phải là hành động khắc phục (mitigate), không phải điều tra – audit chỉ làm sau khi contingency plan đã chạy.

• ❌ Review lessons learned from previous projects with this vendor
  Sai vì: 🟡 Review lessons learned thuộc Lessons Learned Register (Project Closure hoặc Control Processes), là hoạt động học hỏi quá khứ để cải thiện tương lai. Không phải "next" vì nó không fix missing deliverable hiện tại; chỉ hữu ích cho preventive measures sau này.

• ❌ Make a detailed analysis on vendor issues during the project
  Sai vì: 🟠 Phân tích chi tiết (detailed analysis) là root cause analysis (như Ishikawa hoặc 5 Whys) thuộc Issue Log hoặc Lessons Learned, thuộc Monitor Risks. Nó chậm trễ và không thay thế contingency plan – PM cần hành động trước, phân tích sau để tránh extend critical path thêm.

Kết luận 💡: Trong PMP, "next step" luôn ưu tiên hành động giảm thiểu rủi ro ngay lập tức (Execute Contingency) để bảo vệ dự án, đặc biệt với critical path. Áp dụng nguyên tắc Proactive Risk Management từ PMBOK 7th để đạt hiệu quả cao nhất! 🚀

🧩 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ý Lịch trình (Schedule Management) và Quản lý Chi phí (Cost Management) trong PMP, cụ thể sử dụng các chỉ số Earned Value Management (EVM).

• Bối cảnh: Trong giai đoạn thiết kế (design phase) của dự án, Project Manager (PM) phát hiện SPI = 1.8 (chỉ số hiệu suất lịch trình cao hơn 1, nghĩa là dự án đang tiến độ nhanh hơn kế hoạch khoảng 80%) và CPI = 0.1 (chỉ số hiệu suất chi phí rất thấp dưới 1, nghĩa là dự án vượt ngân sách nghiêm trọng, chỉ đạt 10% giá trị so với chi phí thực tế).
• Sự kiện: Trong cuộc họp hàng tuần với ban lãnh đạo cấp cao, PM báo cáo lo ngại về các chỉ số này. Người lo lắng nhất là Project Sponsor, người đe dọa sẽ đóng dự án sớm nếu xu hướng tiếp tục.
• Yêu cầu hành động: PM cần quyết định hành động phù hợp nhất để xử lý tình huống, tập trung vào việc quản lý rủi ro từ sponsor và cải thiện hiệu suất dự án.

Vấn đề cốt lõi 📈: SPI tốt (dự án nhanh), nhưng CPI cực kỳ kém (chi phí "bùng nổ") – điều này có thể do sử dụng quá nhiều tài nguyên để đẩy nhanh tiến độ (như crashing), dẫn đến rủi ro cao từ sponsor. Theo PMBOK 7th Edition (2021, cập nhật đến 2026 qua các hướng dẫn PMI mới), PM phải ưu tiên quản lý stakeholder (đặc biệt sponsor) và điều chỉnh kế hoạch tài nguyên để cân bằng hiệu suất.

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

Đáp án đúng: Manage the project sponsor closely and revise the project's resource management plan to improve indicators

Lý do 🛠️:

• Quản lý sponsor chặt chẽ (Manage the project sponsor closely): Sponsor là stakeholder quan trọng nhất, có quyền quyết định đóng dự án. PM cần áp dụng Stakeholder Engagement (PMBOK 7th: Domain 5 - Stakeholder) để giao tiếp, giảm lo ngại và duy trì hỗ trợ.
• Sửa kế hoạch quản lý tài nguyên (Revise resource management plan): CPI thấp do tài nguyên kém hiệu quả (có thể quá tải để đạt SPI cao). Điều chỉnh kế hoạch này (PMBOK 7th: Develop Team & Manage Resources) sẽ cải thiện cả SPI và CPI, giải quyết gốc rễ vấn đề.
• Đây là hành động toàn diện và chủ động, phù hợp nguyên tắc proactive management trong Agile/Hybrid (PMP 2021+).

❌ 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:

• [SAI] Monitor the project sponsor, but understand that it is normal to spend more money in the design phase of a project
  ❌ Sai vì: Chỉ "giám sát" (monitor) sponsor là thụ động, không giải quyết lo ngại của họ (có thể dẫn đến đóng dự án). CPI=0.1 không phải bình thường ở bất kỳ giai đoạn nào, kể cả design phase – đây là dấu hiệu khủng hoảng chi phí nghiêm trọng (PMBOK 7th: Cost Management, EVM thresholds). Không hành động cải thiện chỉ số là vi phạm nguyên tắc forecasting và corrective action.

• [SAI] Stop crashing the schedule
  ❌ Sai vì: Không có bằng chứng dự án đang "crashing" (thuật ngữ Schedule Compression để rút ngắn lịch bằng tăng chi phí). SPI=1.8 cho thấy tiến độ tốt, nhưng dừng crashing đột ngột có thể làm chậm dự án mà không cải thiện CPI. Đây là hành động giả định sai (PMBOK 7th: Schedule Compression techniques chỉ dùng khi cần).

• [ĐÚNG] Manage the project sponsor closely and revise the project's resource management plan to improve indicators
  ✅ Đúng vì: Như giải thích ở trên, kết hợp Stakeholder Management (giảm rủi ro đóng dự án) và Resource Management (cải thiện EVM indicators). Đây là best practice trong PMP, ưu tiên con người và kế hoạch linh hoạt (PMBOK 7th: Domains 3 - Team & 4 - Resource).

• [SAI] Use a resource-leveling technique
  ❌ Sai vì: Resource leveling dùng để cân bằng tài nguyên quá tải, thường kéo dài lịch trình (làm giảm SPI). Nhưng SPI=1.8 đã tốt, vấn đề chính là CPI – leveling không giải quyết chi phí và bỏ qua sponsor. Không phù hợp tình huống (PMBOK 7th: Resource Optimization, chỉ dùng khi over-allocation gây vấn đề lịch trình).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Section 4.5 (Project Performance Measurement - EVM), Domain 5 (Stakeholder), Domain 4 (Resource Management). Cập nhật 2026 qua PMI Handbook vẫn giữ nguyên EVM core.
• PMI Agile Practice Guide (2021): Nhấn mạnh proactive stakeholder & resource adjustment trong hybrid projects.
• PMP Exam Content Outline (2021): Tasks như "Manage conflicts" & "Optimize resource allocation" (35-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 nội dung câu hỏi

Câu hỏi này tập trung vào bước đầu tiên mà một project manager (PM) mới cần thực hiện để thu thập yêu cầu từ khách hàng (customer requirements) trong dự án bảo mật thông tin (information security project) cho một công ty hoạt động ở nhiều quốc gia khác nhau.

📌 Chi tiết câu hỏi:

• Bối cảnh: PM mới, dự án liên quan đến bảo mật thông tin, công ty đa quốc gia → Có sự khác biệt về chính sách khu vực (regional policies), luật pháp, văn hóa, và nhu cầu địa phương có thể ảnh hưởng lớn đến yêu cầu dự án.
• Mục tiêu: Xác định first step để gather customer requirements (thu thập yêu cầu khách hàng). Trong PMP (PMBOK® Guide 7th Edition và cập nhật đến 2026), việc thu thập requirements là phần của Planning Performance Domain và Stakeholder Performance Domain, nhưng phải bắt đầu từ việc identify và phân tích stakeholders để hiểu rõ ai là "customer" và nhu cầu của họ, đặc biệt trong môi trường phức tạp đa quốc gia.
• Tầm quan trọng: Với dự án security đa quốc gia, regional policies (như GDPR ở EU, CCPA ở Mỹ, hoặc luật địa phương khác) có thể thay đổi requirements, nên cần phân tích sớm để tránh rủi ro.

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

Đáp án đúng: Conduct a stakeholder analysis to identify how regional policies may influence needs

Lý do 🛠️:

• Theo PMBOK® Guide 7th Edition (Stakeholder Performance Domain), bước đầu tiên để thu thập requirements là Conduct Stakeholder Analysis (thực hiện phân tích bên liên quan). Điều này giúp PM identify các stakeholders chính (bao gồm customers), phân loại họ theo quyền lực, lợi ích, và ảnh hưởng (power/interest grid hoặc salience model).
• Trong bối cảnh đa quốc gia, phân tích này đặc biệt cần thiết để xác định cách regional policies (chính sách khu vực) ảnh hưởng đến needs (nhu cầu), tránh bỏ sót requirements pháp lý hoặc văn hóa.
• Đây là first step vì chưa thể thu thập requirements nếu chưa biết "ai cần gì và tại sao". Các tài liệu cập nhật PMP 2024-2026 (PMI Agile Practice Guide) cũng nhấn mạnh Stakeholder Engagement sớm trong planning để tailor requirements.

📋 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên PMP best practices:

• ✅ Conduct a stakeholder analysis to identify how regional policies may influence needs
  Đúng 🏆: Như đã giải thích ở trên, đây là bước đầu tiên logic và bắt buộc. Phân tích stakeholders giúp map ra influences từ regional policies (ví dụ: luật bảo mật khác nhau giữa châu Á và châu Âu), từ đó elicit requirements hiệu quả. Nguồn: PMBOK® Guide 7th Ed., Section 4.5 (Stakeholder Management) & PMI's Stakeholder Engagement Standard (2021).

• ❌ Request relevant stakeholders to conduct an analysis and reach consensus independently
  Sai 🚫: PM không nên delegate (giao phó) trách nhiệm phân tích cho stakeholders một cách độc lập, vì PM phải lead và own quá trình (leadership responsibility). Stakeholders có thể thiếu kỹ năng hoặc có xung đột lợi ích, dẫn đến consensus không khách quan hoặc chậm trễ. Nguồn: PMBOK® Guide 7th Ed., Team Performance Domain – PM phải facilitate, không outsource core planning.

• ❌ Conduct a project scope review workshop with relevant stakeholders
  Sai ⚠️: Workshop review scope là hoạt động sau khi đã có draft scope và identified stakeholders rõ ràng (thuộc Collect Requirements process). Làm workshop ngay từ đầu mà chưa phân tích stakeholders sẽ bỏ sót người tham gia quan trọng, đặc biệt đa quốc gia. Đây không phải "first step". Nguồn: PMBOK® Guide 7th Ed., Planning Performance Domain – Scope management theo sau Stakeholder ID.

• ❌ Conduct project planning meetings in one location with relevant stakeholders
  Sai 🌍: Với công ty đa quốc gia, họp một địa điểm duy nhất không khả thi (chi phí cao, múi giờ khác biệt, di chuyển khó khăn). Đây vi phạm nguyên tắc inclusive engagement và có thể loại trừ stakeholders khu vực. Planning meetings nên dùng virtual tools (Zoom/Teams). Nguồn: PMBOK® Guide 7th Ed., Uncertainty & Complexity Domain – Adapt to global/virtual teams (cập nhật hybrid work post-2020).

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

• PMBOK® Guide – 7th Edition (2021) & Process Groups: A Practice Guide (2022): Nền tảng cho Stakeholder Analysis trong Planning.
• PMI Stakeholder Engagement Practice Standard (2021): Chi tiết về first steps trong multi-stakeholder environments.
• PMP Exam Content Outline (2024-2026): Domain III (Business Environment) nhấn mạnh regional influences in global projects.
• PMI.org resources: Agile Hybrid approaches for security projects (updates 2025).

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

🧩 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ý Dự án Thích ứng (Adaptive Project Management) trong PMP, theo PMBOK® Guide 7th Edition (và cập nhật đến 2026 với các nguyên tắc Hybrid/Agile).

📖 Tình huống chính:
Văn phòng Quản lý Dự án (PMO) của công ty đang nỗ lực triển khai phương pháp thích ứng (adaptive approach) vào khung quản lý dự án. Quản lý dự án (Project Manager - PM) được yêu cầu sử dụng công cụ thích ứng (adaptive tools) cho dự án tiếp theo. Đây không phải lần đầu, vì dự án trước đã thất bại khi áp dụng các công cụ này.

🛠️ Vấn đề cốt lõi: PM cần quyết định hành động phù hợp để xử lý yêu cầu từ PMO, tránh lặp lại thất bại trước đó. Điều này kiểm tra kiến thức về quản lý bên liên quan (Stakeholder Management), quản lý giao tiếp (Communications Management), và triển khai Agile/Adaptive trong môi trường tổ chức thay đổi.

Mục tiêu: PM phải xác định nguyên nhân thất bại trước (có thể do thiếu sự đồng thuận từ bên liên quan) và xây dựng nền tảng giao tiếp vững chắc trước khi áp dụng adaptive tools, phù hợp với Nguyên tắc 5: Tư duy và Hành động theo Giá trị (Value) và Domain Quản lý Bên liên quan trong PMBOK 7.

✅ Đáp án đúng

Conduct individual interviews with key stakeholders in order to understand all concerns, then prepare a communications management plan

Lý do lựa chọn 🏆:

• Đây là hành động tối ưu và chủ động nhất, tuân thủ Process 13.1 Plan Stakeholder Engagement và Process 10.1 Plan Communications Management (PMBOK 7).
• Lần trước thất bại → PM cần phỏng vấn cá nhân (individual interviews) để hiểu rõ lo ngại (concerns) của key stakeholders (bao gồm PMO, team, sponsors), tránh rủi ro kháng cự thay đổi.
• Sau đó, xây dựng Kế hoạch Quản lý Giao tiếp (Communications Management Plan) để đảm bảo thông tin minh bạch, phù hợp adaptive approach (Agile Manifesto nhấn mạnh "individuals and interactions").
• Điều này hỗ trợ Tailoring (tùy chỉnh phương pháp) theo PMBOK 7, chuẩn bị nền tảng cho hybrid/adaptive mà không vội vàng thay đổi lớn.

📘 Dẫn nguồn:

• PMBOK® Guide 7th Edition, Section 4.6.2 Stakeholder Engagement; Agile Practice Guide, Ch. 3 (Tailoring).
• PMI Standards đến 2026: Nhấn mạnh Stakeholder-Centric trong adaptive projects.

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

• Prepare a change request and seek approval from the steering committee regarding the new project framework
  ❌ Sai: Phương án này thiếu cơ sở dữ liệu, vì chưa phân tích nguyên nhân thất bại trước hoặc thu thập ý kiến stakeholders. Change request (theo Process 7.5 Control Changes) cần evidence mạnh mẽ, không nên dùng để "xin phê duyệt khung mới" mà chưa hiểu vấn đề. Sẽ gây chậm trễ và rủi ro từ chối từ steering committee.

• Conduct individual interviews with key stakeholders in order to understand all concerns, then prepare a communications management plan
  ✅ Đúng: Như giải thích trên, đây là bước logic đầu tiên để xây dựng sự đồng thuận, giải quyết concerns, và lập kế hoạch giao tiếp – nền tảng cho adaptive success.

• Bring in a third party company to develop and implement a hybrid framework for this specific project
  ❌ Sai: Quá tốn kém và phức tạp cho giai đoạn đầu. PMBOK 7 khuyến khích internal tailoring trước khi dùng external consultants (Principle 9: Optimize Risk Responses). Chưa xác định nguyên nhân thất bại → thuê bên thứ ba chỉ làm phức tạp thêm, không giải quyết gốc rễ như kháng cự tổ chức.

• Recommend to the PMO that it is not the right time to start implementing adaptive tools in projects
  ❌ Sai: Tiêu cực và né tránh trách nhiệm. PMO đã kiên trì yêu cầu → PM nên hỗ trợ thay đổi (Principle 3: Focus on Value), không từ chối mà hướng dẫn qua data-driven approach. Điều này vi phạm PM's authority trong adaptive (self-organizing teams).

🧠 Kết luận: Câu hỏi kiểm tra Stakeholder Engagement trước Adaptive Implementation. Áp dụng ✅ đáp án đúng giúp dự án thành công bền vững! 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ý Chi phí (Cost Management) trong PMP, cụ thể liên quan đến quy trình Estimate Costs (Ước lượng Chi phí) và Determine Budget (Xác định Ngân sách) theo PMBOK Guide 7th Edition (cập nhật đến 2026).

• Tình huống: Quản lý dự án (PM) đang ước lượng chi phí cho một dự án mới tương tự dự án năm ngoái. PM đã áp dụng kỹ thuật Analogous Estimating (Ước lượng tương tự) kết hợp Three-Point Estimating (Ước lượng ba điểm) với nhóm chuyên gia từ dự án cũ – đây là phương pháp phù hợp cho giai đoạn đầu dự án, khi chưa có dữ liệu chi tiết (theo PMBOK 7.3 Estimate Costs).
• Vấn đề: Ngân sách ước tính đã được nộp cho Project Sponsor (nhà tài trợ dự án mới vào công ty), và sponsor lo lắng vì vượt kỳ vọng.
• Câu hỏi cốt lõi: PM nên làm gì để xử lý mối lo ngại này một cách chuyên nghiệp? Mục tiêu là justify (chứng minh tính hợp lý) cho ngân sách dựa trên dữ liệu thực tế, tránh thay đổi không cần thiết hoặc thuyết phục chủ quan.

📘 Nguồn tham khảo: PMBOK Guide 7th Edition, Section 7.3 Estimate Costs & 7.4 Determine Budget; PMP Exam Content Outline 2021 (Domain 5: Business Environment, Task 2: Demonstrate leadership skills...); Agile Practice Guide (Historical data usage).

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

Review the historical information and lessons learned from last year's project to justify the new budget estimate

Lý do:

• Đây là hành động tối ưu và chuyên nghiệp nhất vì dự án mới dựa trên dự án tương tự, nên sử dụng historical information (thông tin lịch sử) và lessons learned (bài học kinh nghiệm) từ dự án cũ để chứng minh tính chính xác của ước lượng.
• Theo PMBOK 7th, Data Analysis trong Estimate Costs ưu tiên historical records để hỗ trợ Analogous/Parametric estimating. Điều này giúp sponsor (mới) hiểu rõ cơ sở dữ liệu thực tế, xây dựng lòng tin mà không cần thay đổi estimate.
• 🛠️ Hiệu quả cao: Giúp tránh tranh cãi, tập trung vào value delivery thay vì cảm tính.

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

• ❌ [SAI] Review the organizational process assessment to determine if a contingency reserve was considered in the budget estimate
  Phân tích: Phương án này không phù hợp vì organizational process assessment (đánh giá quy trình tổ chức) không phải công cụ trực tiếp để justify estimate. Contingency reserve (dự phòng rủi ro) là phần của management reserve trong Determine Budget, nhưng vấn đề ở đây là sponsor lo về tổng ngân sách, không phải reserve cụ thể. Việc kiểm tra assessment chỉ làm phức tạp hóa, không giải quyết gốc rễ (historical justification). Theo PMBOK 7th, reserve được thêm sau estimate, không dùng để biện minh ban đầu.

• ✅ [ĐÚNG] Review the historical information and lessons learned from last year's project to justify the new budget estimate
  Phân tích: Như đã giải thích ở trên, đây là lựa chọn tốt nhất vì tận dụng data-driven approach (cách tiếp cận dựa trên dữ liệu) từ dự án tương tự. PMBOK nhấn mạnh lessons learned repository (kho lưu trữ bài học) là input chính cho Estimate Costs, giúp sponsor thấy estimate dựa trên evidence thực tế, không phải đoán mò. Hoàn hảo cho sponsor mới thiếu context!

• ❌ [SAI] Change the budgeting technique to a more accurate, bottom-up cost estimation
  Phân tích: Bottom-up estimating (ước lượng từ dưới lên) chi tiết hơn (dựa trên WBS), nhưng không cần thiết và không hiệu quả ở giai đoạn này – dự án mới chưa có WBS đầy đủ, và analogous + three-point đã phù hợp cho early stage (PMBOK 7th: dùng khi data hạn chế). Thay đổi sẽ tốn thời gian, chi phí cao hơn, và không giải quyết lo ngại của sponsor ngay lập tức. Đây là overkill (làm quá)!

• ❌ [SAI] Use soft skills to convince the project sponsor to approve the new budget estimate
  Phân tích: Sử dụng soft skills (kỹ năng mềm) để "thuyết phục" nghe giống manipulation (thao túng), không chuyên nghiệp trong PMP. PMBOK 7th (Domain 9: Leadership) nhấn mạnh stakeholder engagement dựa trên data và transparency, không phải convince chủ quan. Với sponsor mới, thiếu data sẽ làm mất lòng tin lâu dài!

🛠️ Kết luận & Mẹo PMP: Luôn ưu tiên evidence-based decisions từ historical data để manage stakeholder expectations. Thực hành với PMP mocks để nắm PMBOK 7th! 🚀

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

Câu hỏi mô tả tình huống mà Quản lý dự án (Project Manager) đang gặp khó khăn trong việc lấy sự chấp thuận cho yêu cầu dự án (project requirements) do các bên liên quan (stakeholders) bất đồng ý kiến. Vấn đề này đang đe dọa lịch trình dự án (project schedule).
📌 Mục tiêu chính: Xác định hành động đầu tiên (first) mà Project Manager nên thực hiện để thúc đẩy việc phê duyệt yêu cầu dự án.
🛠️ Bối cảnh PMP (theo PMBOK® Guide 7th Edition & PMP Exam Content Outline 2021, cập nhật đến 2026): Đây là vấn đề thuộc quy trình Quản lý sự tham gia của các bên liên quan (Manage Stakeholder Engagement - Process 13.3) và xử lý xung đột (Conflict Management) trong People Domain. Khi có bất đồng giữa stakeholders, cần ưu tiên phân tích nguyên nhân gốc rễ (root cause analysis) để giải quyết hiệu quả, tránh làm chậm tiến độ dự án.

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

Đáp án đúng: Identify the source of the disagreement
Lý do:
🧠 Theo nguyên tắc PMP, khi gặp xung đột giữa stakeholders về yêu cầu dự án, bước đầu tiên phải là xác định nguồn gốc bất đồng (identify the source) để hiểu rõ vấn đề cốt lõi (root cause). Điều này thuộc Data Analysis trong Manage Stakeholder Engagement, giúp Project Manager tập trung giải quyết đúng vấn đề, tránh lãng phí thời gian vào các hành động không liên quan. Việc này trực tiếp hỗ trợ phê duyệt yêu cầu và bảo vệ lịch trình dự án.
📘 Nguồn tham khảo: PMBOK® Guide 7th Edition (trang 304-306, Section 13.3.2.2 Data Analysis); PMP Exam Content Outline (Domain 2: People, Task 5: Conflict Management).

❌ 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ự, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên logic PMP và thứ tự ưu tiên hành động đầu tiên.

• Review the project charter
  ❌ Sai: Project Charter đã được phê duyệt ở giai đoạn khởi tạo dự án và chỉ chứa thông tin cấp cao (high-level objectives, authority). Việc xem lại không giải quyết trực tiếp bất đồng về chi tiết yêu cầu dự án (requirements), vốn thuộc giai đoạn Planning (Collect Requirements). Đây không phải hành động đầu tiên vì không xác định được nguồn gốc xung đột.
  📘 Nguồn: PMBOK® Guide 7th Edition (Section 2.3 Develop Project Charter).

• Perform a stakeholder analysis
  ❌ Sai: Phân tích stakeholders (Stakeholder Analysis) thường được thực hiện sớm ở giai đoạn Planning (Identify Stakeholders - Process 13.1). Lúc này, stakeholders đã tồn tại và đang bất đồng, nên việc phân tích lại không phải ưu tiên đầu tiên. Thay vào đó, cần tập trung vào nguồn gốc bất đồng hiện tại trước khi điều chỉnh chiến lược engagement.
  📘 Nguồn: PMBOK® Guide 7th Edition (Section 13.1.2.2 Data Analysis - Stakeholder Analysis).

• Identify the source of the disagreement
  ✅ Đúng (như đã giải thích ở trên): Đây là hành động đầu tiên và logic nhất, áp dụng Root Cause Analysis để hiểu rõ xung đột, từ đó triển khai các bước tiếp theo như facilitation meeting hoặc adjustment strategies. Giúp giảm rủi ro lịch trình nhanh chóng.

• Hold a team-building event
  ❌ Sai: Team-building nhằm cải thiện mối quan hệ nội bộ đội ngũ dự án (team), không phải để giải quyết bất đồng giữa stakeholders bên ngoài về yêu cầu dự án. Hành động này không liên quan trực tiếp và có thể làm chậm lịch trình hơn nếu không giải quyết vấn đề gốc rễ.
  📘 Nguồn: PMBOK® Guide 7th Edition (Section 9.2 Manage Team - Develop Team, không áp dụng cho stakeholders).

🛡️ Lời khuyên PMP: Trong thực tế, luôn ưu tiên hiểu vấn đề trước khi hành động (First Things First từ Agile Principles & PMBOK 7). Nếu áp dụng, Project Manager có thể dùng công cụ như Fishbone Diagram hoặc 5 Whys để identify source!

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

Câu hỏi này thuộc chủ đề Project Scope Management và Integrated Change Control trong PMP (theo PMBOK Guide 7th Edition, 2021 - phiên bản mới nhất áp dụng đến 2026).

📖 Tình huống: Quản lý dự án (PM) được giao dự án và nhận Project Charter từ PMO (Project Management Office). Project Charter rất rõ ràng về yêu cầu khách hàng. Tuy nhiên, trong quá trình Project Scope Management (quản lý phạm vi dự án), một số requirements (yêu cầu) dường như khác biệt so với những gì được ghi trong Project Charter.

🛠️ Vấn đề cốt lõi: Project Charter là tài liệu phê duyệt ban đầu, định hướng cao cấp cho dự án (bao gồm mục tiêu, phạm vi sơ bộ). Nhưng trong giai đoạn thu thập và xác định requirements chi tiết (như Collect Requirements), nếu phát hiện sự khác biệt, PM KHÔNG ĐƯỢC tự ý thay đổi mà phải tuân thủ quy trình kiểm soát thay đổi chính thức. Điều này đảm bảo tính toàn vẹn của baseline (điểm chuẩn) dự án, tránh rủi ro lệch hướng schedule, cost và chất lượng.

Mục tiêu câu hỏi: Kiểm tra kiến thức về cách xử lý scope creep (mở rộng phạm vi không kiểm soát) và quy trình Perform Integrated Change Control (Quy trình 4.6 trong PMBOK 7th).

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

Đáp án đúng: Register the changes in the configuration management plan and send it to the change control board (CCB)

Lý do chọn đáp án này 🏆:

• Theo PMBOK Guide 7th Edition (Section 4.6 Perform Integrated Change Control), mọi thay đổi đối với scope (kể cả requirements khác biệt so với charter) phải được ghi nhận chính thức vào Configuration Management Plan (kế hoạch quản lý cấu hình - một phần của Change Management Plan) và gửi đến CCB (Change Control Board) để đánh giá, phê duyệt.
• Project Charter chỉ là baseline sơ bộ; requirements chi tiết có thể tinh chỉnh nhưng PHẢI QUA QUY TRÌNH THAY ĐỔI để tránh vi phạm baseline đã phê duyệt.
• Hành động này đảm bảo tính minh bạch, kiểm soát rủi ro và tuân thủ nguyên tắc Value Delivery trong PMBOK 7th (tập trung vào lợi ích dự án).
• Nguồn tham khảo: PMBOK Guide 7th Edition, trang 87-89 (Integrated Change Control); PMBOK 6th Edition, 4.6.2.1 (tương tự).

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

Dưới đây là phân tích từng lựa chọn giữ nguyên văn bản gốc bằng tiếng Anh, kèm giải thích chi tiết bằng tiếng Việt tại sao đúng hoặc sai. Sử dụng ✅ cho đúng, ❌ cho sai.

• ❌ Modify the baseline of the project for minor impact changes to the project scope
  Phân tích sai: Phương án này vi phạm nguyên tắc baseline control. Baseline scope chỉ được thay đổi SAU KHI được CCB phê duyệt chính thức (không tự ý modify dù "minor impact"). Làm vậy sẽ gây scope creep, ảnh hưởng đến toàn bộ dự án. PMBOK 7th cấm PM tự thay đổi baseline mà không qua change control (Section 5.5 Validate Scope).

• ❌ Use a focus group and brainstorming sessions to gather more details about the project scope
  Phân tích sai: Đây là công cụ thu thập requirements ban đầu (trong Collect Requirements - 5.2 PMBOK 7th), KHÔNG PHÙ HỢP khi đã có Project Charter rõ ràng và phát hiện khác biệt. Thay vì "gather more details", cần xử lý thay đổi chính thức qua CCB, tránh làm phức tạp hóa scope mà không kiểm soát.

• ✅ Register the changes in the configuration management plan and send it to the change control board (CCB)
  Phân tích đúng (như đã giải thích ở trên): Đây là bước chuẩn xác theo quy trình Integrated Change Control. Configuration Management Plan theo dõi thay đổi cấu hình (bao gồm scope), và CCB quyết định phê duyệt. Đảm bảo dự án tuân thủ governance (Section 4.6 PMBOK 7th).

• ❌ Explain to the sponsor that these requests could endanger the schedule and cost of the project
  Phân tích sai: PM KHÔNG NÊN chỉ "giải thích" với sponsor mà bỏ qua quy trình chính thức. Sponsor không phải là CCB duy nhất; cần submit change request để đánh giá đầy đủ tác động (triple constraint: scope-time-cost). Hành động này có thể bỏ lỡ cơ hội phê duyệt thay đổi hợp lý (PMBOK 7th, Principle 5: Optimize Risk Responses).

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

• PMBOK Guide 7th Edition (2021): Các domain Knowledge (Scope, Integration); Process Groups (Executing, Monitoring & Controlling).
• PMBOK Guide 6th Edition (2017): Quy trình 5.6 Control Scope & 4.6 Perform Integrated Change Control (cơ sở tương thích với 7th).
• PMP Exam Content Outline (2024-2026): People 42%, Process 50%, Business Environment 8% - Tập trung Process như Change Control.
• Agile Practice Guide (PMI): Tương tự, khuyến nghị Change Canvas cho 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ụ case study, hãy hỏi nhé!