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

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

Câu hỏi mô tả một dự án xây dựng cầu bị tạm dừng (paused) do thay đổi chính trị ở chính quyền địa phương, kéo dài gần 5 năm. Bây giờ, chính phủ mới muốn tiếp tục (resume) dự án và giao cho một project manager mới.
📌 Tình huống cốt lõi: Đây là dự án bị gián đoạn dài hạn, có thể dẫn đến thay đổi lớn về môi trường bên ngoài (chính trị, kinh tế, nhu cầu xã hội). Theo PMBOK® Guide 7th Edition (2021) và các cập nhật đến 2026 (bao gồm PMI Standards+), project manager phải ưu tiên xác nhận giá trị kinh doanh (business value) trước khi resume, vì dự án có thể không còn phù hợp sau thời gian dài.
🛠️ Mục tiêu câu hỏi: Kiểm tra kiến thức về Project Initiation hoặc Resume Project trong tình huống thay đổi lớn, nhấn mạnh việc đánh giá business case là bước đầu tiên để quyết định có tiếp tục không.

✅ Đáp án đúng: Examine the project's business case in order to resume the project.

Lý do lựa chọn:
Sau 5 năm tạm dừng, project manager phải kiểm tra business case đầu tiên để đánh giá xem dự án còn mang lại giá trị kinh doanh (business value), lợi ích kinh tế, và phù hợp với mục tiêu tổ chức hiện tại không. Business case là tài liệu nền tảng quyết định go/no-go cho dự án (PMBOK® 7th Ed., Section 1.2.4 & 2.1). Nếu business case không còn hợp lệ (do thay đổi chính trị/kinh tế), việc resume có thể lãng phí tài nguyên. Đây là bước tailoring phù hợp cho dự án resume dài hạn, ưu tiên value delivery trước các hoạt động khác.

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

Dưới đây là giải thí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 đánh dấu ✅ cho đúng, ❌ cho sai, kèm lý do dựa trên PMP mới nhất:

• ❌ Prepare an estimate of the time and cost to complete this project.
  Phương án này sai vì ước lượng thời gian/chi phí (estimating) chỉ thực hiện sau khi xác nhận dự án viable. Làm ngay sẽ lãng phí nếu business case không hợp lệ. Theo PMBOK® 7th Ed. (Process 7.1 & 7.2 - Planning), estimating thuộc giai đoạn lập kế hoạch, không phải bước đầu tiên khi resume.

• ❌ Study the project's lessons learned to understand why it was paused.
  Phương án này sai dù hữu ích, nhưng không phải ưu tiên đầu tiên. Lessons learned giúp cải thiện tương lai (PMBOK® 7th Ed., Section 4.7 - Lessons Learned), nhưng sau 5 năm, cần kiểm tra business case trước để quyết định resume. Nếu dự án không đáng làm, không cần nghiên cứu sâu lessons learned cũ.

• ❌ Meet the new stakeholders and understand their expectations.
  Phương án này sai vì gặp stakeholders là bước quan trọng (Stakeholder Engagement - PMBOK® 7th Ed., Principle 6), nhưng chưa xác nhận business case. Với chính phủ mới, kỳ vọng có thể thay đổi, nhưng project manager phải chứng minh giá trị kinh doanh trước khi cam kết gặp gỡ và thu thập input.

• ✅ Examine the project's business case in order to resume the project.
  Như đã giải thích ở trên, đây là bước đầu tiên logic và đúng chuẩn PMP. Business case giúp đánh giá portfolio alignment và benefits realization (PMBOK® 7th Ed., Section 1.2.4.2 & The Standard for Portfolio Management 4th Ed.).

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021): Section 1.2 (Business Documents), Principle 1 (Be a Diligent, Respectful, and Caring Steward) – Nhấn mạnh kiểm tra value trước resume.
• PMI Standards+ (cập nhật 2024-2026): Hướng dẫn resume projects trong "Project Recovery" toolkit, ưu tiên business case review.
• Practice Standard for Project Configuration Management: Khuyến nghị audit business case cho dự án paused >2 năm.
• Tham khảo thêm: PMI.org resources on "Project Resuscitation" (2023 webinar).

🛠️ Lời khuyên PMP: Trong kỳ thi PMP, luôn ưu tiên business justification ở giai đoạn đầu, đặc biệt với thay đổi lớn! Nếu bạn có câu hỏi khác, hãy hỏi nhé! 🚀

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

Câu hỏi này thuộc chủ đề Stakeholder Engagement trong dự án Agile theo khung PMP (PMBOK® Guide 7th Edition và Agile Practice Guide).

📖 Tình huống mô tả: Trong một dự án Agile, các bên liên quan (stakeholders) đang không hài lòng vì một số sản phẩm cuối cùng không đáp ứng kỳ vọng của họ. Khi Project Manager (PM) hỏi đội ngũ (team), họ chỉ biết đề cập đến mục tiêu dự án (project's objective) mà không nắm rõ kỳ vọng cụ thể của stakeholders.

🛠️ Vấn đề cốt lõi: Team thiếu công cụ hoặc kỹ thuật để nắm bắt và phân tích sâu kỳ vọng (expectations), lợi ích (interest), và ảnh hưởng (influence) của stakeholders. PM cần cải thiện bằng cách dạy team một kỹ thuật cụ thể, ngoài việc nhắc nhở về tầm quan trọng của các yếu tố stakeholder.

🎯 Mục tiêu câu hỏi: Kiểm tra kiến thức về các kỹ thuật Agile giúp team hiểu rõ nhu cầu người dùng cuối (end-users) và stakeholders, đặc biệt trong bối cảnh Agile nơi feedback liên tục là chìa khóa (theo Agile Principle: "Customer collaboration over contract negotiation").

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

Đáp án đúng: Teach the team how to use the user persona technique.

Lý do chi tiết 🧠:

• Trong Agile, user persona là kỹ thuật mạnh mẽ để hình dung và mô tả chi tiết người dùng cuối (end-users) dựa trên dữ liệu thực tế, giúp team nắm rõ kỳ vọng cụ thể thay vì chỉ mục tiêu chung chung. Nó bao gồm demographics, behaviors, goals, pain points, và expectations của stakeholders/users.
• Điều này trực tiếp giải quyết vấn đề: Team chỉ biết objective → Dạy user persona giúp họ phân tích sâu expectations và điều chỉnh sản phẩm phù hợp, tăng sự hài lòng của stakeholders.
• Theo Agile Practice Guide (PMI, 2021), user persona được khuyến nghị trong Product Backlog Refinement và Sprint Planning để đảm bảo sản phẩm đáp ứng nhu cầu thực tế (align with stakeholder expectations).
• Kiến thức cập nhật PMP đến 2026: Vẫn giữ nguyên trong PMBOK® 7th Ed. (Section 4.6 Stakeholder Engagement) và Agile Hybrid models.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên tính phù hợp với tình huống Agile và nguyên tắc PMP mới nhất.

• ❌ [SAI] Motivate the team to create and use an agile project charter.
  Giải thích sai: Agile không sử dụng "agile project charter" theo chuẩn (Agile ưu tiên Product Vision Statement ngắn gọn thay vì charter chi tiết như traditional PM). Charter đã được tạo ở đầu dự án (nếu có), và động viên tạo lúc này không giải quyết việc thiếu hiểu biết về expectations cụ thể. Nó chỉ nhắc lại objective chung, không giúp phân tích sâu stakeholder needs (PMBOK® 7th, Agile Practice Guide: Không đề cập agile charter làm công cụ chính).

• ❌ [SAI] Encourage the team to use an information radiator to analyze expectations.
  Giải thích sai: Information radiator (như task board, burndown chart) dùng để hiển thị tiến độ thực tế và minh bạch (visibility), không phải để phân tích expectations (analyze). Nó hỗ trợ theo dõi công việc hàng ngày chứ không capture chi tiết user/stakeholder needs. Sử dụng lúc này không cải thiện kiến thức của team về kỳ vọng (Agile Practice Guide: Information radiators thuộc "Team Workspace", không phải stakeholder analysis tool).

• ✅ [ĐÚNG] Teach the team how to use the user persona technique.
  Giải thích đúng (đã nêu ở trên): Kỹ thuật lý tưởng để team học cách mô hình hóa stakeholders/users, nắm expectations chi tiết, và tích hợp vào backlog/sprints. Giúp tránh sản phẩm lệch lạc, tăng collaboration (PMI Agile Practice Guide, p. 44-45: User personas trong "Tailoring Agile Approaches").

• ❌ [SAI] Remind the team that face-to-face communication is the best method.
  Giải thích sai: Face-to-face (hoặc daily stand-ups) là nguyên tắc Agile Manifesto (#1: "The most efficient and effective method of conveying information"), nhưng chỉ nhắc lại không dạy kỹ thuật cụ thể để hiểu expectations. Team đã giao tiếp nhưng vẫn thiếu insight → Cần tool như user persona, không chỉ communication method (PMBOK® 7th, 9.2.2: Communication ưu tiên nhưng phải kết hợp tools).

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Chương 4 (Stakeholder Engagement), Chương 9 (Project Communications).
• Agile Practice Guide (PMI, 2021): Phần "Stakeholder Engagement in Agile" và "Techniques like User Personas/User Stories" (p. 42-50).
• PMP Exam Content Outline (PMI, 2021 - cập nhật 2024/2025): Domain III: Business Environment (17%), Domain IV: Delivery (50%) – Agile stakeholder tools.
• Cập nhật đến 2026: Không thay đổi lớn, tập trung Hybrid/Agile (xem PMI.org cho Discipline-Specific Agile).

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ụ user persona, hãy hỏi nhé!

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

Nội dung câu hỏi:
Câu hỏi mô tả tình huống trong giai đoạn thực thi (Executing Process Group) của dự án, khi một quản lý dự án (PM) mới được giao thay thế người trước. PM mới phát hiện hiệu suất đội ngũ giảm sút đáng kể, dẫn đến ảnh hưởng tiêu cực đến các chỉ số hiệu suất chính (KPIs) của dự án. Tuy nhiên, đội ngũ này từng có hiệu suất tốt ở các dự án tương tự trước đây.

🛠️ Ý nghĩa tình huống: Đây là vấn đề đột ngột và bất thường trong quản lý đội ngũ (Team Management), không phải do thiếu kế hoạch ban đầu mà có thể do thay đổi lãnh đạo, động lực đội ngũ, giao tiếp kém, hoặc các yếu tố con người khác. Theo PMBOK Guide 7th Edition (2021) và cập nhật PMP đến 2026, PM cần áp dụng People Domain (quản lý con người) và Process 9.4: Manage Project Team để ưu tiên phân tích nguyên nhân gốc rễ (root cause analysis) trước khi hành động sửa chữa. Mục tiêu là cải thiện tình hình ngay lập tức bằng cách tập trung vào đội ngũ – yếu tố cốt lõi ảnh hưởng KPIs.

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

Đáp án đúng: Call for a team meeting to identify the root cause for the declining performance.

Lý do:
🧩 Trong giai đoạn thực thi, khi hiệu suất đội ngũ giảm (dù trước đây tốt), bước tiếp theo (next step) phải là tổ chức họp đội ngũ để xác định nguyên nhân gốc rễ. Điều này phù hợp với nguyên tắc Servant Leadership và Stakeholder Engagement trong PMP, giúp thu thập thông tin từ đội ngũ (nguồn gốc vấn đề), xây dựng lòng tin với PM mới, và thúc đẩy động lực. Theo PMBOK 7th Edition, quy trình Manage Team nhấn mạnh direct and manage team work qua giao tiếp trực tiếp, tránh hành động giả định. Điều này nhanh chóng, hiệu quả, và ngăn chặn vấn đề lan rộng, đặc biệt khi đội ngũ có kinh nghiệm trước đây. ✅ Hành động này trực tiếp giải quyết nguyên nhân con người – yếu tố chính gây suy giảm KPIs.

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên nội dung gốc tiếng Anh. Phần giải thích hoàn toàn bằng tiếng Việt:

• ❌ [SAI] Review the resource management plan and organizational assets.
  Giải thích sai: Kế hoạch quản lý nguồn lực (Resource Management Plan) và tài sản tổ chức (như templates, lessons learned) được lập ở giai đoạn Planning, không phải hành động tiếp theo khi đang thực thi và có vấn đề đột ngột. Việc review chỉ hữu ích nếu nghi ngờ thiếu kế hoạch ban đầu, nhưng câu hỏi nhấn mạnh đội ngũ từng làm tốt dự án tương tự → vấn đề là hiện tại (có thể do thay đổi PM), không phải kế hoạch. Hành động này chậm và gián tiếp, bỏ qua giao tiếp trực tiếp với đội ngũ (People Domain).

• ❌ [SAI] Estimate the baseline impacts and submit a change request.
  Giải thích sai: Việc ước lượng tác động đến baseline (schedule/cost/scope) và submit change request thuộc Perform Integrated Change Control (Process 4.6), chỉ áp dụng khi đã xác định vấn đề cụ thể ảnh hưởng baseline. Ở đây, chưa biết nguyên nhân suy giảm KPIs → hành động này vội vã, không dựa trên dữ liệu, có thể tạo thay đổi không cần thiết và làm phức tạp dự án hơn. PMP ưu tiên root cause trước khi change.

• ❌ [SAI] Implement compression techniques to bring the project back on track.
  Giải thích sai: Kỹ thuật nén (compression như crashing/fast-tracking) dùng cho Schedule Management khi dự án trễ hạn (Control Schedule process). Vấn đề ở đây là hiệu suất đội ngũ giảm, không phải trễ schedule rõ ràng → áp dụng compression sẽ tăng chi phí/rủi ro mà không giải quyết gốc rễ, có thể làm đội ngũ kiệt sức hơn. Không phù hợp next step trong Execute phase.

• ✅ [ĐÚNG] Call for a team meeting to identify the root cause for the declining performance.
  Giải thích đúng: (Như phần trên) Đây là hành động nhanh nhất, trực tiếp nhất, tuân thủ High-Performance Team principles trong PMP. Họp giúp observe team dynamics, thu thập feedback, và áp dụng data-driven decision (Agile/hybrid approach).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Section 4.7 Manage Project Team; People Domain (pp. 57-65); Agile Practice Guide (Team Performance).
• PMP Examination Content Outline (2021, cập nhật 2026): Domain III: People (Task 8: Manage conflict, Task 10: Engage/mentor/support team).
• PMI.org: Standards & Publications – Process Groups: Executing (Prioritize root cause in team issues).

🛠️ Lời khuyên PMP: Luôn ưu tiên con người trước quy trình khi KPIs bị ảnh hưởng bởi đội ngũ! Nếu cần đào sâu, áp dụng Fishbone Diagram hoặc 5 Whys trong họp.

🧩 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ý Backlog và Ưu tiên Công việc (Backlog Prioritization) trong phương pháp Agile, một phần quan trọng của PMP theo PMBOK® Guide 7th Edition và Agile Practice Guide.

• Bối cảnh: Quản lý dự án đang chủ trì cuộc họp ủy ban chỉ đạo dự án (project steering committee meeting), thảo luận về việc ưu tiên các hạng mục công việc trong backlog. Có sự xung đột từ các bên liên quan (stakeholders):

  • Engineering executive (Lãnh đạo kỹ thuật): Muốn ưu tiên theo mức độ nỗ lực (level of effort), làm các hạng mục nhỏ nhất trước (smallest items first) – tương tự nguyên tắc "quick wins" nhưng không phải ưu tiên chính.
  • Quality executive (Lãnh đạo chất lượng): Muốn làm các nhiệm vụ phức tạp nhất trước để có thời gian đảm bảo chất lượng sản phẩm.
  • Compliance officer (Chuyên viên tuân thủ): Muốn ưu tiên các hạng mục liên quan đến quy định pháp lý (regulatory components) vì chúng là yếu tố thiết yếu.

• Vấn đề cốt lõi: Quản lý dự án cần chọn cách ưu tiên phù hợp nhất để cân bằng lợi ích stakeholders, đảm bảo giá trị kinh doanh (business value) và nguyên tắc Agile. Trong PMP/Agile, ưu tiên không dựa trên effort, complexity hay chỉ compliance riêng lẻ, mà tập trung vào giá trị kinh doanh cao nhất (highest business value) và giao giá trị tăng dần (incrementally) để đáp ứng nhu cầu khách hàng/stakeholders.

🛠️ Mục tiêu câu hỏi: Kiểm tra kiến thức về Value-Driven Prioritization trong Agile, nơi backlog được sắp xếp theo giá trị kinh doanh (business value), sử dụng kỹ thuật như MoSCoW, Kano Model, WSJF (Weighted Shortest Job First), hoặc Value vs. Effort Matrix (theo PMBOK 7th & Agile Practice Guide).

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

Đáp án đúng: Ensure that the team assesses opportunities to deliver the highest business value items incrementally.

Lý do:

• Trong Agile và PMP (PMBOK 7th Edition, Principle 4: Collaborate with Customer/Stakeholder & Principle 10: Optimize Value Delivery), ưu tiên backlog phải dựa trên giá trị kinh doanh cao nhất (highest business value), không phải effort, complexity hay chỉ compliance.
• Việc "assess opportunities" nghĩa là đánh giá cơ hội để giao giá trị tăng dần (incrementally) qua các sprint/release, giúp giảm rủi ro, lấy feedback sớm và tối ưu hóa giá trị (value maximization).
• Điều này cân bằng các ý kiến stakeholders bằng cách tích hợp business value làm tiêu chí chính, nơi compliance có thể là "must-have" nhưng vẫn xếp theo value tổng thể. Không ưu tiên effort (small first) hay complexity (complex first) vì chúng có thể làm chậm delivery value.
• ✅ Phù hợp thực tiễn PMP 2026: Theo PMI's updated standards (PMBOK 7th & The Standard for Project Management, 2021+ updates), Agile ưu tiên "Deliver Value Incrementally" để adapt với thay đổi.

📋 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/sai. Sử dụng kiến thức PMP/Agile mới nhất.

• ❌ Phương án SAI: Ensure that the project value is within the quality guidelines by prioritizing and completing intricate tasks earlier in the project.
  Giải thích: Phương án này ưu tiên "intricate tasks" (nhiệm vụ phức tạp) trước để đảm bảo chất lượng, giống ý kiến quality executive. ❌ Sai vì PMP/Agile KHÔNG ưu tiên complexity/effort làm tiêu chí chính (PMBOK 7th, Agile Principle 2: Welcome Changing Requirements). Làm phức tạp trước có thể làm chậm delivery value, tăng rủi ro và không tối ưu business value. Quality được đảm bảo qua testing liên tục (CI/CD), không phải ưu tiên riêng.

• ❌ Phương án SAI: Complete tasks associated with regulatory components as the team cannot deliver business value that does not adhere to compliance regulations.
  Giải thích: Tập trung chỉ vào "regulatory components" (yếu tố quy định), giống ý kiến compliance officer. ❌ Sai vì dù compliance là "must-have" (non-negotiable), ưu tiên KHÔNG chỉ dựa vào một yếu tố mà phải theo business value tổng thể (PMBOK 7th, Section 4.5: Manage Project Compliance). Có thể làm chậm các item value cao khác; thay vào đó, tích hợp compliance vào value assessment (ví dụ: WSJF tính rủi ro/compliance như risk multiplier).

• ✅ Phương án ĐÚNG: Ensure that the team assesses opportunities to deliver the highest business value items incrementally.
  Giải thích: Yêu cầu team đánh giá cơ hội giao highest business value items incrementally. ✅ Đúng vì đây là nguyên tắc cốt lõi Agile/PMP: Prioritize backlog theo value (ROI, customer benefit), deliver increments để lấy feedback (Agile Manifesto: Working Software over Documentation). Cân bằng stakeholders bằng data-driven (value stream mapping), không bias effort/complexity.

• ❌ Phương án SAI: Complete the smaller tasks first to allow the team opportunities to prototype and evaluate development processes.
  Giải thích: Ưu tiên "smaller tasks first" để prototype, giống ý kiến engineering executive. ❌ Sai vì PMP/Agile cấm "minimize effort first" nếu không mang value cao (Little's Law & Agile Principle 3: Deliver Working Software Frequently). Small tasks có thể là "low-value busywork", làm chậm MVP (Minimum Viable Product). Thay vào đó, dùng WSJF: Value/Effort >1 cho high value low effort.

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

• PMBOK® Guide 7th Edition (2021, PMI updates 2024-2026): Principles 10 (Optimize Value), Agile Hybrid Approaches.
• Agile Practice Guide (PMI, 2017+ updates): Section 5.3 Backlog Prioritization; Tools: WSJF, Value-Based Prioritization.
• The Standard for Project Management (2021): Domain 3: Value Delivery.
• PMI.org resources: "Earning PDUs: Agile Prioritization Techniques" (2025 webinars); SAFe® 6.0 (Scaled Agile Framework, tích hợp PMP).
• Khuyến nghị: Thực hành qua PMI's PMP Exam Content Outline (2024 update), Domain IV: People (Stakeholder Engagement).

🛠️ Lời khuyên PMP: Trong thực tế, dùng Product Owner/Product Manager dẫn dắt prioritization meeting với stakeholders, kết hợp tools như Jira/ADO cho backlog refinement! Nếu cần ví dụ case study, hỏi thêm nhé! 🚀

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

Câu hỏi này thuộc lĩnh vực People Domain trong kỳ thi PMP (theo PMBOK Guide 7th Edition và PMP Exam Content Outline 2021 - cập nhật đến 2026). Nó mô tả tình huống một thành viên đội ngũ thường xuyên vắng mặt trong các cuộc họp đội ngũ, nhưng luôn hoàn thành nhiệm vụ đúng hạn. Các thành viên khác phàn nàn và mong muốn thành viên này tham gia họp. Project manager (PM) cần chọn hành động phù hợp nhất để xử lý vấn đề này.

🛠️ Mục tiêu chính: Xử lý xung đột đội ngũ, thúc đẩy sự hợp tác, giao tiếp và hiệu suất đội ngũ. PM phải ưu tiên thấu hiểu nguyên nhân gốc rễ (root cause), hỗ trợ cá nhân hóa (tailored approach), thay vì áp đặt quy tắc cứng nhắc hoặc bỏ qua nhu cầu đội ngũ. Điều này phù hợp với 12 nguyên tắc PMP như Stewardship (quản lý trách nhiệm), Teamwork, và Leadership (lãnh đạo hỗ trợ).

📘 Dẫn nguồn:

• PMBOK Guide 7th Edition: Principle 7 (Foster a Collaborative Team Environment) & Principle 9 (Optimize Risk Responses).
• PMP ECo 2021: Task 7 (Lead a team) & Task 9 (Mentor relevant stakeholders).

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

Đáp án đúng: Understand the reason for the team member’s absence and encourage them to attend future meetings.

Lý do 🧩:
Hành động này thể hiện lãnh đạo phục vụ (servant leadership) và quản lý đội ngũ hiệu quả (Manage Project Team). PM cần thấu hiểu lý do vắng mặt (có thể do lý do cá nhân, múi giờ, xung đột lịch trình) trước khi khuyến khích tham gia, giúp xây dựng lòng tin, thúc đẩy sự tham gia tự nguyện và giải quyết vấn đề gốc rễ. Điều này hỗ trợ hợp tác đội ngũ mà không làm giảm hiệu suất cá nhân (vì họ vẫn hoàn thành task). Phù hợp với Stakeholder Engagement và Team Performance Domain.

❌ 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 bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên nguyên tắc PMP mới nhất:

• Review and update the project ground rules to make meeting attendance mandatory.
  ❌ Sai: Việc cập nhật ground rules (quy tắc dự án) để bắt buộc tham gia là cách tiếp cận cứng nhắc, thiếu linh hoạt (command-and-control style), không giải quyết nguyên nhân gốc rễ. Có thể gây phản ứng tiêu cực, giảm động lực đội ngũ (disengagement). PMP khuyến nghị ground rules phải được đồng thuận từ đầu và chỉ cập nhật khi cần thiết, ưu tiên giao tiếp thay vì ép buộc (Principle 5: Value People).

• Assign this member to facilitate the next meeting to ensure project team collaboration.
  ❌ Sai: Giao vai trò facilitate (dẫn dắt họp) cho người thường vắng mặt là không thực tế và rủi ro cao, có thể làm gián đoạn họp và giảm hiệu quả hợp tác. PMP nhấn mạnh phân công dựa trên năng lực và sự sẵn sàng (competency matching), không dùng để "trừng phạt" hay ép buộc tham gia (Task 8: Support team performance).

• Understand the reason for the team member’s absence and encourage them to attend future meetings.
  ✅ Đúng: Như đã giải thích ở trên, đây là cách tối ưu nhất, tập trung vào root cause analysis và khuyến khích tự nguyện (motivation & coaching). Hỗ trợ hybrid/virtual team phổ biến post-2020, đảm bảo inclusivity mà không ảnh hưởng hiệu suất.

• Allow each team member to submit their required tasks on time and reduce the number of scheduled meetings.
  ❌ Sai: Cho phép "làm việc độc lập" và giảm họp bỏ qua nhu cầu hợp tác của đội ngũ (team complains), dẫn đến giảm synergy và morale. PMP ưu tiên effective communication (13% trọng số People Domain), họp là công cụ chính để chia sẻ kiến thức, không nên cắt giảm mà cần tối ưu hóa (Principle 10: Navigate Complexity).

🛠️ Kết luận: Câu hỏi kiểm tra khả năng lãnh đạo đội ngũ tinh tế thay vì quản lý hành chính. Hãy áp dụng trong thực tế để xây dựng high-performing team! 🚀

🧩 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 phát triển sản phẩm (product development project): Quản lý dự án (PM) đang làm việc trên dự án này, nhưng khi sản phẩm được giao (delivered), xuất hiện các vấn đề lớn (major issues) dẫn đến phải làm lại (rework) và làm chậm trễ việc phát triển tính năng mới (delay new feature development).
📌 Mục tiêu chính: PM cần chọn hành động phù hợp để giải quyết vấn đề chất lượng (resolve the quality issues). Đây là tình huống điển hình trong quản lý chất lượng dự án (Project Quality Management), đặc biệt trong môi trường Agile/DevOps, nơi chất lượng phải được đảm bảo liên tục để tránh rework tốn kém. Theo PMBOK® Guide 7th Edition (2021, cập nhật đến 2026), nguyên tắc cốt lõi là Quality Management Principle (Nguyên tắc Quản lý Chất lượng) nhấn mạnh việc xây dựng chất lượng từ đầu (build quality in), không phải kiểm tra sau (inspect in).

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

Đáp án đúng: Plan for continuous validation of the product.
🛠️ Lý do: Hành động này tập trung vào kiểm chứng liên tục (continuous validation), một thực hành tiên tiến trong Agile và DevOps (Shift-Left Quality, CI/CD pipeline). Thay vì phản ứng sau khi deliver (reactive), PM cần lập kế hoạch kiểm tra chất lượng xuyên suốt vòng đời dự án để phát hiện và khắc phục vấn đề sớm, giảm rework và duy trì dòng chảy giá trị (value stream). Điều này phù hợp với PMBOK® 7th Edition, Section 4.3 (Project Delivery Principles) và Agile Practice Guide, nơi khuyến nghị "continuous testing/validation" để đảm bảo sản phẩm đạt chất lượng mong đợi mà không làm gián đoạn phát triển mới.

📋 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 cho các phương án, chỉ giải thích bằng tiếng Việt với lý do đúng/sai dựa trên PMP mới nhất.

• ❌ [SAI] Discuss adding business scenario tests with the customer.
  🧐 Giải thích: Phương án này chỉ thảo luận thêm test kịch bản kinh doanh (business scenario tests) sau khi vấn đề đã xảy ra, mang tính phản ứng (reactive) và phụ thuộc vào khách hàng. Không giải quyết gốc rễ (root cause) chất lượng kém từ quy trình dự án. Theo PMBOK® 7th Edition, 8.1.2 (Quality Planning), chất lượng phải được lập kế hoạch từ đầu, không phải bổ sung muộn với bên ngoài.

• ❌ [SAI] Discuss adding additional test cases with the product owner.
  🧐 Giải thích: Tương tự, đây là hành động thảo luận thêm test cases sau deliver, chỉ tập trung vào product owner mà không thay đổi quy trình tổng thể. Nó không ngăn ngừa vấn đề lặp lại, dẫn đến rework liên tục. PMBOK® 7th Edition, Agile Hybrid Models nhấn mạnh cần validation sớm (early & continuous), không phải thêm test muộn gây delay.

• ❌ [SAI] Add more test scenarios based on the issues found.
  🧐 Giải thích: Phương án này thêm test scenarios dựa trên vấn đề đã tìm thấy, vẫn là phản ứng sau sự cố (post-defect testing), không đảm bảo chất lượng toàn diện. Nó có thể tăng test coverage tạm thời nhưng không giải quyết lỗ hổng quy trình, dễ gây delay feature mới. PMBOK® 7th Edition, 8.3 Manage Quality khuyến nghị "prevent defects" qua continuous practices, không phải "fix after".

• ✅ [ĐÚNG] Plan for continuous validation of the product.
  🛠️ Giải thích: Như đã nêu ở trên, đây là cách tiếp cận chủ động và bền vững (proactive & ongoing), tích hợp validation vào mọi giai đoạn (design, develop, deploy). Giảm rework bằng cách phát hiện sớm, phù hợp DevOps Value Stream trong PMBOK® 7th.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, PMI): Sections 4.3 (Delivery), 8.1-8.3 (Quality Management), nhấn mạnh continuous improvement và validation.
• Agile Practice Guide (PMI, 2017, cập nhật tích hợp 7th Ed.): Chương về Testing & Quality, khuyến nghị CI/CD và Shift-Left.
• The Standard for Project Management (2021): Principle 8 – Quality, ưu tiên build-in quality. (Nguồn chính thức PMI.org, cập nhật đến 2026 không thay đổi cốt lõi này).

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 xoay quanh tình huống trong quản lý dự án PMP: Một project sponsor yêu cầu project manager (PM) khám phá cách tiếp cận hybrid (kết hợp giữa predictive và agile/adaptive) cho một dự án mới. Đồng thời, product manager đã chuẩn bị một thông số kỹ thuật chi tiết (detailed specification) cho sản phẩm. Câu hỏi yêu cầu: PM nên làm gì để tiến hành lập project management plan (kế hoạch quản lý dự án)?

🛠️ Bối cảnh PMP (theo PMBOK 7th Edition, cập nhật đến 2026): Hybrid approach là sự kết hợp linh hoạt giữa các phương pháp dự đoán (predictive/waterfall) và thích ứng (agile/iterative), nhằm tối ưu hóa giá trị kinh doanh (business value). Với thông số chi tiết sẵn có (gợi ý tính ổn định), PM cần khám phá cơ hội hybrid thay vì áp đặt một cách tiếp cận duy nhất. Mục tiêu là phát triển project management plan (Process 4.5 trong PMBOK 7th), tập trung vào việc giao giá trị gia tăng dần dần (incremental value delivery) để tăng business value, phù hợp với nguyên tắc Agile Hybrid trong Agile Practice Guide (PMI, 2021 và cập nhật).

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

• PMBOK® Guide – 7th Edition (PMI, 2021): Chương 4 (Project Management Principles), Section 2.5 (Tailoring).
• Agile Practice Guide (PMI, 2021): Phần Hybrid Approaches, nhấn mạnh explore value opportunities trước khi quyết định.
• PMP Exam Content Outline (PMI, 2024-2026): Domain III: Business Environment (14%), Domain IV: Delivery (50%) – Tập trung hybrid tailoring.

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

Đáp án đúng: Explore with the product manager to determine if there are viable opportunities to deliver value incrementally and increase business value.

Lý do 🏆:
PM cần hợp tác ngay với product manager (người nắm spec chi tiết) để khám phá cơ hội giao giá trị từng phần (incrementally), giúp tăng business value – đây chính là bước đầu tiên lý tưởng cho hybrid approach. Điều này tuân thủ nguyên tắc tailoring (tùy chỉnh phương pháp) trong PMBOK 7th, ưu tiên value-driven delivery thay vì ép buộc predictive hoặc agile. Sponsor yêu cầu "explore hybrid", nên PM phải xác định viable opportunities trước khi lập plan, đảm bảo tính linh hoạt và tối ưu hóa giá trị. Đây là hành động chủ động, hợp tác phù hợp PMP People Domain (42%).

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên PMP best practices:

• Recommend to the project sponsor that a predictive approach is appropriate for the project due to the stable product requirements.
  ❌ Sai vì: Phương án này phản đối trực tiếp yêu cầu của sponsor (explore hybrid), thay vì khám phá hybrid như chỉ đạo. Dù spec ổn định gợi ý predictive, PMBOK 7th nhấn mạnh không nên loại bỏ hybrid ngay mà phải tailoring dựa trên value và context. Hành động này thiếu tính linh hoạt, có thể làm giảm business value nếu bỏ lỡ cơ hội incremental delivery (Agile Practice Guide, Hybrid section).

• Explore with the product manager to determine if there are viable opportunities to deliver value incrementally and increase business value.
  ✅ Đúng như đã giải thích ở trên: Hoàn hảo phù hợp tình huống, tập trung explore hybrid qua lăng kính value delivery – cốt lõi của PMP tailoring và hybrid approaches (PMBOK 7th, Principle 5: Value Optimization).

• Ask the product manager whether they are prepared to act as product owner for the project in order to participate in iterative planning and reviews.
  ❌ Sai vì: Quá sớm giả định chuyển sang agile thuần (iterative planning/reviews) mà chưa explore hybrid. Product manager không nhất thiết là product owner (vai trò agile cụ thể), và PMBOK khuyến nghị không ép buộc vai trò trước khi xác định viable opportunities. Điều này có thể gây nhầm lẫn, vi phạm nguyên tắc collaboration mà chưa tailoring (Domain II: Team, 42%).

• Ask the team to assess whether the product specification can be expressed in user stories to enable a Scrum or Kanban approach.
  ❌ Sai vì: Bỏ qua sponsor và product manager, nhảy thẳng sang team để chuyển spec thành user stories (agile artifact) – thiếu thứ tự logic. Trong hybrid, PM phải explore với stakeholders trước (như product manager nắm spec), sau mới involve team. Scrum/Kanban là adaptive thuần, không đảm bảo hybrid; có thể lãng phí nếu spec quá ổn định (PMBOK 7th, Section 4.6: Manage Project Work, tailoring sequence).

🧠 Kết luận PMP tips: Luôn ưu tiên stakeholder collaboration và value exploration khi tailoring hybrid. Thực hành này giúp PM đạt tỷ lệ pass cao ở exam PMP 2026! Nếu cần thêm 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 này thuộc chủ đề Quản lý dự án theo cách tiếp cận lai (Hybrid Approach) trong PMP, tập trung vào quy trình Sprint Retrospective trong môi trường Agile/Scrum tích hợp với dự án truyền thống.

• Bối cảnh dự án: Một công ty toàn cầu đang thực hiện dự án chiến lược nâng cấp hệ thống doanh nghiệp cũ (legacy enterprise system). Dự án sử dụng hybrid approach (kết hợp Predictive - Waterfall và Agile/Iterative), vừa hoàn thành sprint đầu tiên.
• Sự kiện chính: Trong sprint retrospective (họp đánh giá cuối sprint để phản ánh và cải thiện), một thành viên đội đưa ra ý tưởng cải thiện quy trình testing (quá trình kiểm thử).
• Câu hỏi trọng tâm: Bước tiếp theo của Project Manager (PM) là gì? Điều này kiểm tra kiến thức về chu kỳ Inspect and Adapt trong Agile, nơi retrospective không chỉ dừng ở thảo luận mà phải dẫn đến hành động cụ thể cho sprint tiếp theo.

Mục tiêu kiểm tra sự hiểu biết về quy trình liên tục cải tiến (Continuous Improvement) theo PMBOK® Guide 7th Edition và Agile Practice Guide (PMI, 2021), nhấn mạnh việc áp dụng lessons learned ngay lập tức trong môi trường hybrid.

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

• PMBOK® Guide – 7th Edition (2021): Principle 5 (Holistic Thinking) và Agile Hybrid Models (Project Delivery Section).
• Agile Practice Guide (PMI, 2021): Chapter 5 – Sprint Retrospective & Action Items.
• Scrum Guide (2020, cập nhật 2025): Sprint Retrospective dẫn đến actionable improvements cho Sprint tiếp theo.

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

Đáp án đúng: Document the lessons learned and implement improvements in the next sprint.

Lý do 🛠️:

• Trong Sprint Retrospective, mục tiêu là phản ánh (Inspect) và thích ứng (Adapt) bằng cách ghi chép lessons learned (bài học kinh nghiệm) vào lessons learned register hoặc backlog cải tiến, sau đó triển khai cải tiến ngay sprint tiếp theo.
• Đây là bước tiếp theo logic và chuẩn Agile trong hybrid approach: Không trì hoãn, mà hành động nhanh chóng để tăng hiệu quả (value delivery). PMBOK 7 nhấn mạnh Value Delivery qua iterative improvements, tránh lãng phí thời gian ở các bước không cần thiết ngay sau retrospective.

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

• ✅ Document the lessons learned and implement improvements in the next sprint.
  Đúng 🏆: Như đã giải thích, đây là hành động trực tiếp và chuẩn mực từ retrospective. Ghi chép lessons learned đảm bảo traceability (theo PMBOK 7, Models Section), và implement ở sprint sau thể hiện Kaizen/Continuous Improvement. Phù hợp hybrid: Kết hợp Agile inspect-adapt với Predictive documentation.

• ❌ Request that all team members think of ideas to improve processes.
  Sai 🚫: Retrospective đã diễn ra và đã có ý tưởng cụ thể từ một thành viên. Yêu cầu thêm ý tưởng từ tất cả sẽ lặp lại quy trình không cần thiết, làm chậm dự án và vi phạm nguyên tắc timely action (Agile Principle #12: Reflect at regular intervals). Không phải bước "tiếp theo" – retrospective chỉ cần action trên ý tưởng hiện có.

• ❌ Facilitate a daily standup with the team to track the implementation of changes.
  Sai ⚠️: Daily standup (Daily Scrum) dùng để track tiến độ hàng ngày, không phải theo dõi changes từ retrospective. Thay vào đó, changes được track qua Sprint Backlog hoặc improvement backlog trong sprint sau. Tổ chức standup đặc biệt sẽ phá vỡ cấu trúc Agile, gây confusion trong hybrid model (PMBOK 7 cảnh báo tránh over-process).

• ❌ Organize a demonstration of the changes in the enterprise system.
  Sai 🔄: Sprint Review/Demo dùng để demo product increment (kết quả sprint), không phải demo changes từ retrospective (cải tiến quy trình nội bộ như testing). Changes chưa implement, và demo hệ thống enterprise ở giai đoạn đầu sprint sẽ premature (chưa có gì để demo), vi phạm Sprint Goal alignment (Scrum Guide).

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

🧠 Câu hỏi nhấn mạnh vai trò PM trong Agile Hybrid: Là Servant Leader, PM phải facilitate action-oriented retrospectives để tối ưu hóa dự án chiến lược. Áp dụng ngay để đạt Stakeholder Value cao hơn.
Tips ôn thi PMP: Tập trung 12 Agile Principles và Hybrid tailoring (Exam Content Outline 2026). Thực hành qua PMI's PMP Exam Simulator!

Nếu cần thêm ví dụ thực tế hoặc câu hỏi khác, 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ý Đội ngũ (Team Management) trong PMP, cụ thể liên quan đến Develop Team process theo PMBOK® Guide – Seventh Edition (và cập nhật đến 2026 với PMI's The Standard for Project Management).

Tình huống chính: Quản lý dự án (PM) tuyển dụng một thành viên mới từ môi trường Agile (linh hoạt, lặp lại) để làm việc trong dự án Predictive (dự đoán, kế hoạch chi tiết theo giai đoạn). PM mong muốn tận dụng kinh nghiệm Agile của thành viên mới để chia sẻ với đội ngũ hiện tại (chạy theo predictive).

Mục tiêu: Tích hợp thành viên mới hiệu quả (effectively integrate), nghĩa là giúp họ nhanh chóng hòa nhập, đóng góp giá trị mà không gây gián đoạn. Thách thức nằm ở sự khác biệt văn hóa/methodology giữa Agile (tập trung collaboration, iteration) và Predictive (tập trung kế hoạch upfront, control). PM cần hành động chủ động, cá nhân hóa để leverage strengths (tận dụng điểm mạnh) thay vì coi là rủi ro.

Ý nghĩa PMP: Theo People Domain và Principle 5: Optimize Risk Responses/Uncertainty, PM phải xây dựng đội ngũ hybrid (kết hợp phương pháp), khuyến khích knowledge sharing giữa các background khác nhau. Không phải đào tạo lại hoàn toàn, mà set clear expectations để align với dự án hiện tại.

📘 Nguồn tham khảo:

• PMBOK® Guide – Seventh Edition (2021, cập nhật 2026 qua PMI updates): Section 4.5 Develop Team; People Domain.
• Agile Practice Guide (PMI): Hybrid approaches để leverage Agile in Predictive.
• PMP Exam Content Outline 2021 (vẫn áp dụng đến 2026): Task 9.1 Lead a team.

✅ Đáp án đúng: Set expectations with the new team member and explain what is needed.

Lý do lựa chọn:

• Đây là bước đầu tiên và hiệu quả nhất để tích hợp (integrate effectively). PM cần thiết lập kỳ vọng rõ ràng (set expectations) với cá nhân mới, giải thích yêu cầu cụ thể của dự án predictive (roles, deliverables, processes). Điều này giúp thành viên mới hiểu ngữ cảnh, align mindset, và leverage kinh nghiệm Agile (ví dụ: áp dụng retrospectives vào predictive reviews).
• Theo High-Performing Team characteristics (PMBOK 7th), giao tiếp cá nhân hóa xây dựng trust nhanh chóng, tránh xung đột văn hóa. Không chỉ train mà empower họ contribute ngay.
• Lợi ích: Giảm uncertainty, tăng engagement, hỗ trợ knowledge transfer với đội cũ mà không coi là "risk".

🛠️ Phân tích tất cả các phương án (Đúng & Sai)

• ✅ Set expectations with the new team member and explain what is needed.
  Giải thích đúng: Như trên, đây là hành động proactive và cá nhân hóa, phù hợp Manage Team process. Giúp thành viên mới adapt nhanh, tận dụng Agile experience để innovate trong predictive (ví dụ: daily stand-ups nhẹ). Tránh "one-size-fits-all" training.

• ❌ Acknowledge that hiring this new employee is a risk to the existing team.
  Giải thích sai: Sai vì coi việc tuyển dụng là rủi ro (risk) thay vì cơ hội (opportunity). PMBOK nhấn mạnh view diversity as strength (Principle 10: Stewardship), không "acknowledge risk" mà mitigate qua integration. Điều này tạo mindset tiêu cực, làm giảm morale đội ngũ.

• ❌ Train the new team member in the predictive project management approach.
  Giải thích sai: Có thể cần training sau, nhưng không phải ưu tiên đầu tiên để integrate effectively. PM mong leverage Agile experience, không "train lại từ đầu" (wipes out strengths). PMBOK 7th khuyến khích tailored development thay vì full retraining, tránh waste time/resources.

• ❌ Meet with all team members and explain the new employee's position.
  Giải thích sai: Chỉ giới thiệu chung (introduce), không giải quyết cá nhân hóa integration. Thiếu one-on-one với thành viên mới để set expectations, dẫn đến misalignment. PMBOK ưu tiên individual coaching trước team meetings để build high-performance.

Kết luận PMP: Luôn ưu tiên Stakeholder Engagement & Team Development qua communication rõ ràng. Áp dụng hybrid mindset để dự án linh hoạt hơn! 🚀 Nếu cần thêm ví dụ case study, hỏi nhé!

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

Câu hỏi này thuộc lĩnh vực Quản lý Thay đổi (Change Management) trong PMP, cụ thể là trong quá trình phân tích yêu cầu báo cáo để tạo thiết kế chức năng (functional design). 🛠️ Dự án đang ở giai đoạn lập kế hoạch hoặc thực hiện, khi đội ngũ dự án phát hiện nguồn thông tin (information source) không chính xác và cần điều chỉnh.

📘 Tình huống chi tiết:

• Đội ngũ đã phân tích yêu cầu (requirements analysis) để xây dựng thiết kế chức năng.
• Phát hiện vấn đề: Nguồn dữ liệu gốc sai sót, ảnh hưởng đến baseline của dự án (scope, design).
• Câu hỏi cốt lõi: Project Manager (PM) nên làm gì tiếp theo để xử lý?
  • Theo PMBOK® Guide (phiên bản 7th Edition, 2021, và cập nhật đến 2026 qua PMI Standards), đây là tình huống yêu cầu quy trình kiểm soát thay đổi tích hợp (Integrated Change Control) để bảo vệ baseline dự án, tránh rủi ro lệch hướng.

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

Đáp án đúng: Initiate a change request procedure.

🛠️ Lý do chi tiết:

• Khi phát hiện sai sót cần điều chỉnh nguồn thông tin (ảnh hưởng đến scope hoặc design baseline), PM phải khởi tạo Change Request (Yêu cầu thay đổi) ngay lập tức theo Process 4.6: Perform Integrated Change Control (PMBOK® 6th/7th Edition).
• Điều này đảm bảo thay đổi được đánh giá, phê duyệt chính thức bởi Change Control Board (CCB), tránh thay đổi không kiểm soát (scope creep).
• Trong PMBOK® 7th Edition, nguyên tắc Optimization và Change Control nhấn mạnh: Mọi thay đổi phải qua quy trình chính thức để cân bằng lợi ích dự án. Đây là hành động đầu tiên và bắt buộc của PM.

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

• ✅ [ĐÚNG] Initiate a change request procedure.
  🟢 Phương án này hoàn toàn đúng vì nó tuân thủ quy trình cốt lõi của PMP: Phát hiện vấn đề → Đề xuất thay đổi → Submit Change Request → Đánh giá & Phê duyệt. Không khởi tạo change request sẽ vi phạm baseline integrity, dẫn đến rủi ro dự án. Đây là bước mandatory theo PMBOK®.

• ❌ [SAI] Build a prototype to verify the information.
  🔴 Phương án này sai vì xây dựng prototype (nguyên mẫu) là công cụ trong Validate Scope hoặc Manage Quality, dùng để kiểm tra thiết kế sau khi baseline đã ổn định. Ở đây, vấn đề là nguồn gốc sai sót trước khi thiết kế, không phải verify mà là adjust baseline – prototype sẽ tốn kém và không giải quyết gốc rễ mà không có change approval.

• ❌ [SAI] Consult with subject matter experts (SMEs).
  🔴 Phương án này sai vì tư vấn SME (chuyên gia chủ đề) chỉ là hỗ trợ thu thập thông tin (trong Collect Requirements hoặc Expert Judgment), không thay thế quy trình change control. SME có thể xác nhận vấn đề nhưng không có quyền phê duyệt thay đổi baseline – PM vẫn phải dùng change request để chính thức hóa.

• ❌ [SAI] Review the statement of work (SOW).
  🔴 Phương án này sai vì review SOW (tuyên bố công việc, thường trong hợp đồng) chỉ giúp xác nhận yêu cầu ban đầu, nhưng nếu cần adjust thông tin source (đã là baseline), thì review thôi không đủ – vẫn phải initiate change request để cập nhật. SOW là tài liệu cố định, thay đổi nó yêu cầu negotiate hợp đồng riêng.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021, PMI): Chapter 4 (Project Integration Management), Principle 9: Optimization; Process 4.6 Perform Integrated Change Control.
• PMBOK® Guide – 6th Edition: Section 4.6.2 (Change Request Types).
• PMI Practice Standard for Change Management (cập nhật 2023-2026): Nhấn mạnh "Formal Change Requests" cho mọi deviation từ baseline.
• PMP Exam Content Outline (2024-2026): Domain III: Business Environment (15%), Domain IV: People (42%) – liên quan Change Control.

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