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

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

Câu hỏi tập trung vào quy trình Agile trong quản lý dự án, cụ thể là cách một Agile Project Manager xử lý tài liệu yêu cầu (requirements document) bằng việc phân tích nó thành các cấp độ phân cấp: epics (các sử dụng lớn), capabilities (khả năng hoặc chủ đề lớn), features (tính năng), và stories (user stories). 🏗️

Sau khi phân tích phân cấp này (thường thuộc giai đoạn Product Backlog Refinement hoặc Backlog Grooming theo Agile Practice Guide), câu hỏi hỏi về số lượng iterations (vòng lặp/sprint) cần thiết để ước lượng thời lượng story (estimate the story duration) – tức là ước tính effort hoặc story points cho từng user story.

📌 Bối cảnh PMP mới nhất (PMBOK® Guide 7th Edition & Agile Practice Guide 2021, cập nhật đến 2026): Trong Agile/Scrum/SAFe, việc ước lượng story points được thực hiện tập trung trong một phiên họp duy nhất (như Planning Poker trong Sprint Planning hoặc Refinement Meeting), không kéo dài qua nhiều iterations. Breakdown hierarchical (epics → capabilities → features → stories) là progressive elaboration, nhưng estimation cho stories là atomic và nhanh chóng trong một iteration để tránh overhead và duy trì velocity. Không cần nhiều iterations vì Agile ưu tiên just-in-time estimation để linh hoạt với thay đổi.

✅ Đáp án đúng: One iteration

Lý do lựa chọn: Theo nguyên tắc Agile, sau khi phân tích requirements thành stories, Project Manager chỉ cần một iteration duy nhất để estimate story duration (thường qua kỹ thuật Planning Poker hoặc T-shirt sizing). Việc này diễn ra trong Backlog Refinement hoặc Sprint Planning của iteration đầu tiên, giúp team nhanh chóng commit vào Sprint Backlog. Nếu làm qua nhiều iterations, sẽ vi phạm nguyên tắc iterative nhưng không lặp lại không cần thiết, dẫn đến waste (lãng phí). Điều này phù hợp với 12 Agile Principles (PMBOK 7th) và SAFe 6.0 (cập nhật 2023-2026), nơi estimation là collaborative và one-shot per refinement cycle. 🏆

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

• ✅ One iteration
  Đúng vì estimation story duration là hoạt động collaborative trong một phiên họp duy nhất (Refinement hoặc Planning Meeting) của một iteration. Agile ưu tiên simplicity và flow, tránh phân tán effort qua nhiều vòng. Điều này giúp team nhanh chóng baseline velocity và start delivering value. (Tham PMBOK 7th, Section 4.5 & Agile Practice Guide, Ch. 5.3).

• ❌ Four iterations
  Sai vì có 4 cấp độ phân cấp (epics, capabilities, features, stories), nhưng estimation stories không map 1:1 với số cấp độ. Làm qua 4 iterations sẽ tạo waste, delay delivery và vi phạm Agile Manifesto Principle 6 (face-to-face conversation ưu tiên estimation nhanh). Không có quy trình PMP/Agile nào yêu cầu vậy.

• ❌ Two iterations
  Sai vì không có cơ sở chia estimation thành 2 iterations. Estimation là empirical và iterative trong refinement ongoing, nhưng cho stories cụ thể chỉ cần one iteration để team consensus. Làm 2 iterations sẽ làm phức tạp hóa, trái với Scrum Guide 2020 (Refinement là single activity).

• ❌ Three iterations
  Sai tương tự, không khớp với bất kỳ framework Agile nào (Scrum, Kanban, SAFe). Số 3 có thể ám chỉ gì đó không chuẩn (như 3 estimates in Planning Poker), nhưng câu hỏi rõ ràng về iterations cho toàn bộ story estimation – phải là one để maintain cadence. Vi phạm Principle of Flow trong Disciplined Agile (DA 2.0).

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

• PMBOK® Guide 7th Edition (2021): Hybrid/Agile sections (4.7, 6.4) về Backlog Refinement & Estimation.
• Agile Practice Guide (PMI, 2021): Chapter 5 (Value-Driven Delivery) & Chapter 7 (Team Performance).
• Scrum Guide (2020, Scrum.org): Sprint Planning & Refinement.
• SAFe 6.0 (Scaled Agile, 2023): PI Planning & Story Estimation (one ART iteration).
• PMI-ACP Exam Content Outline (2024): Domain III (Agile Principles & Mindset).

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 case study, hỏi nhé!

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

Câu hỏi thuộc chủ đề Quản lý dự án Agile trong PMP (Project Management Professional), tập trung vào tình huống xử lý thay đổi bên ngoài (new competitor) trong một dự án Agile đang ở iteration thứ 5/8.

• Bối cảnh: Dự án đang thực hiện iteration thứ 5 (sprint) trong tổng số 8 iteration. Sau buổi iteration planning (lập kế hoạch sprint), đội ngũ được thông báo có đối thủ cạnh tranh mới trên thị trường, yêu cầu tăng tốc độ để tránh mất thị phần (market share).
• Vấn đề cốt lõi: Project Manager (PM) cần quyết định hành động phù hợp với nguyên tắc Agile: tập trung vào giá trị khách hàng, linh hoạt thích ứng, trao quyền cho đội ngũ (empowerment), và tối ưu hóa quy trình mà không làm gián đoạn sprint hiện tại.
• Mục tiêu: Launch sản phẩm sớm nhất có thể (as soon as possible), nhưng phải tuân thủ Agile Manifesto (ưu tiên cá nhân và tương tác hơn quy trình, hợp tác với khách hàng hơn đàm phán hợp đồng) và Scrum Guide (iteration-based delivery với inspect & adapt).

Câu hỏi kiểm tra kiến thức về Servant Leadership của PM trong Agile: Hỗ trợ đội ngũ tự cải thiện thay vì ra lệnh hoặc thay đổi scope đột ngột.

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

Đáp án đúng: Help the team to find a new approach to launch the product as soon as possible

Lý do 🛠️:

• Trong Agile (theo PMBOK 7th Edition và Agile Practice Guide), PM đóng vai trò Servant Leader (người phục vụ), giúp đội ngũ inspect & adapt (kiểm tra và điều chỉnh) để tìm cách tiếp cận mới (new approach), như rút ngắn cycle time, ưu tiên MVP (Minimum Viable Product), hoặc tinh chỉnh quy trình release.
• Điều này tránh scope creep, duy trì velocity bền vững, và khuyến khích self-organizing team (đội ngũ tự tổ chức). Không ép buộc thay đổi mà hỗ trợ đội ngũ sáng tạo giải pháp nhanh hơn để launch sớm, phù hợp với tình huống khẩn cấp từ competitor.
• Kiến thức cập nhật 2026: Agile Practice Guide (2021, tích hợp PMBOK 7) nhấn mạnh value delivery qua adaptation, không phải tăng resource hay scope.

📋 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) hoặc ❌ (sai), kèm giải thích dựa trên nguyên tắc PMP/Agile mới nhất.

• Add the competitor's functionalities to the product backlog to improve the product ❌
  Sai vì: Việc thêm tính năng của competitor vào product backlog sẽ gây scope creep (mở rộng phạm vi đột ngột), làm gián đoạn iteration hiện tại (đang ở iteration 5/8). Agile ưu tiên refinement backlog qua Product Owner, nhưng không nên thay đổi mid-sprint. Thay vào đó, cần prioritize existing backlog để launch nhanh, không "cải thiện sản phẩm" bằng cách copy competitor ngay lập tức (vi phạm nguyên tắc focus on value).

• Ask the sponsor to add more people to the team ❌
  Sai vì: Thêm người vào đội ngũ mid-project vi phạm Brooks' Law ("Adding manpower to a late software project makes it later") và nguyên tắc Agile: Đội ngũ cross-functional, stable (ổn định). Scrum Guide cấm thay đổi team composition trong sprint; sponsor không can thiệp trực tiếp. PM phải optimize team capacity nội tại thay vì scale up resource (theo PMBOK 7: Hybrid/Agile domains nhấn mạnh team empowerment).

• Help the team to find a new approach to launch the product as soon as possible ✅
  Đúng vì: Như đã giải thích ở trên. PM coach đội ngũ tìm new approach (ví dụ: spike stories, technical debt reduction, early release gates), thúc đẩy continuous improvement qua retrospectives. Phù hợp 12 nguyên tắc Agile (hợp tác, phản hồi nhanh) và Scrum Events (Daily Scrum để adapt).

• Ask the team to increase the velocity to launch the product as soon as possible ❌
  Sai vì: Velocity (tốc độ hoàn thành story points) phải dự báo dựa trên lịch sử, không thể "ép tăng" đột ngột vì dẫn đến burnout, quality drop, unsustainable pace (Agile Principle 8: Sustainable development). PM không "ask to increase" mà hỗ trợ cải thiện process; ép velocity vi phạm Scrum Guide (team tự commit capacity).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Section on Agile/Hybrid Approaches, Servant Leadership (p. 55-60).
• Agile Practice Guide (2021, PMI): Chapters 3-4 (Lifecycle, Team), nhấn mạnh inspect & adapt, velocity sustainability.
• Scrum Guide (2020, cập nhật 2025): Sprint commitments, self-organizing teams (scrumguides.org).
• Kiến thức cập nhật 2026: PMI không thay đổi cốt lõi Agile từ 2021, nhưng tích hợp AI/DevOps trong training PMP mới (xem pmi.org cho updates).

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

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

Câu hỏi mô tả tình huống trong giai đoạn phát triển sản phẩm (product development), project manager quan sát thấy xung đột giữa các bên liên quan (stakeholders), dẫn đến trì hoãn việc phê duyệt deliverables và outputs. Câu hỏi yêu cầu xác định lĩnh vực nào mà project manager nên tập trung để giải quyết vấn đề gốc rễ.

🔍 Chi tiết tình huống:

• Xung đột stakeholders là nguyên nhân chính gây delay phê duyệt (không phải vấn đề kỹ thuật hay thời gian).
• Theo PMBOK® Guide 7th Edition (2021, vẫn là phiên bản chuẩn cho PMP đến 2026), đây liên quan đến Stakeholder Performance Domain và process Manage Stakeholder Engagement, nơi cần ưu tiên quản lý kỳ vọng, giao tiếp và engagement để giảm xung đột.

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

Đáp án đúng: Revisiting the stakeholder engagement plan, focusing on specific overlooked stakeholders

Lý do: 🛠️ Project manager cần tập trung vào Stakeholder Engagement Plan (kế hoạch tương tác bên liên quan) để xác định và ưu tiên các stakeholders bị bỏ qua (overlooked), từ đó giải quyết xung đột gốc rễ. Theo Stakeholder Performance Domain (PMBOK 7th Ed., trang 57-60), xung đột thường xuất phát từ engagement kém, nên revisit plan giúp điều chỉnh chiến lược giao tiếp, phân tích power/interest, và tăng cường involvement. Điều này trực tiếp khắc phục delay phê duyệt, phù hợp với nguyên tắc Optimize Risk Responses và Stakeholder Engagement.

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

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

• ❌ Revisiting the project management plan to ensure deliverables are on time
  Sai vì: Phương án này chỉ tập trung vào project management plan tổng quát để đảm bảo thời gian deliverables, nhưng bỏ qua nguyên nhân gốc là xung đột stakeholders. Theo PMBOK 7th Ed. (Project Delivery Performance Domain, trang 47), revisit plan tổng quát không giải quyết engagement, có thể dẫn đến lãng phí nỗ lực mà không giảm delay phê duyệt.

• ❌ Increasing the frequency of project update meetings to keep stakeholders informed
  Sai vì: Tăng tần suất họp update chỉ là biện pháp giao tiếp ngắn hạn, không giải quyết xung đột sâu hoặc stakeholders bị overlooked. PMBOK 7th Ed. (Uncertainty Performance Domain, trang 65) nhấn mạnh giao tiếp phải dựa trên engagement plan, không phải "tăng họp" mù quáng, dễ gây overload và không hiệu quả.

• ✅ Revisiting the stakeholder engagement plan, focusing on specific overlooked stakeholders
  Đúng vì: Như đã giải thích ở trên, đây là hành động trực tiếp nhắm vào nguyên nhân gốc (conflicts do overlooked stakeholders). Theo Stakeholder Engagement Assessment Matrix (PMBOK 7th Ed., trang 258-260), revisit plan giúp điều chỉnh current vs. planned engagement, ưu tiên high-power stakeholders để nhanh chóng phê duyệt deliverables.

• ❌ Reviewing the business case and identifying gaps within scope
  Sai vì: Review business case và scope gaps chỉ phù hợp nếu vấn đề là misalignment chiến lược hoặc scope creep, không phải xung đột stakeholders. PMBOK 7th Ed. (Measurement Performance Domain, trang 71) cho thấy cách này gián tiếp và không ưu tiên, có thể làm chậm dự án thêm.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Stakeholder Performance Domain (Ch. 2.5), Manage Stakeholder Engagement (Ch. 4.6). PMI.org cập nhật đến 2026 vẫn dựa trên edition này cho PMP exam.
• PMI Agile Practice Guide (2021): Nhấn mạnh stakeholder collaboration trong product development.
• PMP Exam Content Outline (2021): 17% câu hỏi về People Domain, bao gồm conflict resolution qua engagement.

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 thuộc chủ đề Quản lý Thay đổi Tích hợp (Integrated Change Control) và Kiểm soát Phạm vi (Control Scope) trong PMP, xảy ra ở giai đoạn Thực hiện (Executing) của dự án. Cụ thể:

• Dự án đang nằm trong hàm chức năng hoạt động (operations function), nghĩa là nó liên quan đến các hoạt động vận hành liên tục, không phải dự án thuần túy độc lập.
• Project Manager gặp phải thay đổi phạm vi (scope changes) và trì hoãn giao critical tasks (delay in delivery of critical tasks).
• Câu hỏi yêu cầu cách xử lý tình huống này một cách đúng đắn nhất, nhấn mạnh quy trình chính thức để tránh rủi ro lan tỏa đến lịch trình, chi phí, chất lượng.
  📘 Theo PMBOK Guide 7th Edition (2021, cập nhật đến 2026): Bất kỳ thay đổi nào về scope hoặc schedule đều phải qua quy trình Perform Integrated Change Control (4.6), bao gồm phân tích tác động (impact analysis) trước khi phê duyệt bởi Change Control Board (CCB) hoặc steering committee.

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

Đáp án đúng: Conduct an impact analysis and present the results to the steering committee for approval
🛠️ Lý do:

• Đây là bước chuẩn PMP trong Integrated Change Control: Trước tiên, PM phải thực hiện phân tích tác động (impact analysis) để đánh giá ảnh hưởng đến triple constraints (scope, time, cost) và các yếu tố khác (risk, quality, resources).
• Sau đó, trình bày kết quả cho steering committee (CCB) để phê duyệt chính thức, đảm bảo thay đổi được kiểm soát và không tự ý thực hiện.
• Trong operations function, steering committee thường là cơ quan phê duyệt cao cấp, phù hợp với nguyên tắc governance của PMBOK 7th. Không làm vậy có thể dẫn đến scope creep hoặc schedule slippage.
  📘 Nguồn: PMBOK 7th Edition, Principle 5: Optimization, Process 4.6: Perform Integrated Change Control; PMP Exam Content Outline 2021 (Domain 5: Business Environment).

📋 Phân tí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 ✅ đúng hoặc ❌ sai, giữ nguyên văn bản gốc tiếng Anh:

• Communicate the concerns to the project management office (PMO) during the weekly project reports
  ❌ Sai vì: Đây chỉ là báo cáo định kỳ (status reporting), thuộc Monitor and Control Project Work, không giải quyết gốc rễ vấn đề thay đổi. PMO có thể hỗ trợ, nhưng không thay thế quy trình phê duyệt chính thức. Việc chỉ "giao tiếp lo ngại" không dẫn đến hành động cụ thể, dễ gây chậm trễ thêm. (PMBOK 7th: Reporting ≠ Change Control).

• Call for a team meeting to decide if the changes should be included
  ❌ Sai vì: Team không có quyền phê duyệt thay đổi scope/schedule; chỉ PM và CCB mới quyết định. Họp team chỉ phù hợp cho brainstorming hoặc team decisions nhỏ, không phải scope change – vi phạm authority levels và nguyên tắc segregation of duties. Dẫn đến unofficial changes (scope creep). (PMBOK 7th: 9.2 Manage Team, không áp dụng cho change approval).

• Initiate the change request to modify the scope and adjust the timelines
  ❌ Sai vì: PM chỉ initiate (khởi tạo) change request, nhưng không tự approve hoặc thực hiện thay đổi ngay. Phải qua impact analysis + approval trước; nếu không, vi phạm control mechanisms. "Initiate" ở đây ngụ ý hành động trực tiếp mà bỏ qua bước phân tích. (PMBOK 7th: Change Request phải được approved qua CCB trước khi baseline thay đổi).

• Conduct an impact analysis and present the results to the steering committee for approval
  ✅ Đúng vì: Hoàn toàn khớp quy trình 4.6 Perform Integrated Change Control: Impact analysis đánh giá đầy đủ (scope, schedule, cost, risk), sau đó submit cho steering committee phê duyệt. Đây là best practice để đảm bảo thay đổi có kiểm soát, đặc biệt trong operations project. (PMBOK 7th: Tools & Techniques: Expert Judgment, Data Analysis cho impact).

🧩 Kết luận: Câu hỏi kiểm tra kiến thức về formal change control process, tránh các hành động impulsively. Áp dụng đúng giúp dự án optimized theo PMBOK principles!
📘 Tài liệu tham khảo thêm:

• PMBOK Guide 7th Edition (PMI, 2021).
• PMP Examination Content Outline (PMI, 2021, cập nhật 2024).
• Agile Practice Guide (tích hợp hybrid cho operations projects).

🧩 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ý Dự án Linh hoạt (Agile Project Management) trong PMP, cụ thể liên quan đến Scrum hoặc các phương pháp Agile nơi velocity (tốc độ dự án) được đo lường bằng số lượng story points hoàn thành mỗi sprint.

• Tình huống: Velocity của dự án gần đây giảm sút (slipped), dẫn đến quyết định bỏ qua testing (skip testing) để tăng đà phát triển (momentum) và đưa dự án trở lại đúng tiến độ (bring the project back on track – lưu ý: "bong" có thể là lỗi chính tả của "bring").
• Câu hỏi tập trung: Quản lý dự án (PM) cần chú trọng vào yếu tố nào sau quyết định này?
• Bối cảnh PMP mới nhất (PMBOK 7th Edition & Agile Practice Guide 2021, cập nhật đến 2026): Trong Agile, bỏ qua testing là hành vi phổ biến gây technical debt (nợ kỹ thuật), làm tích tụ lỗi, rủi ro chất lượng và tăng công việc refactor sau này. Điều này vi phạm nguyên tắc Sustainable Pace và Definition of Done (DoD) trong Scrum Guide 2020 (vẫn áp dụng 2026).

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

• PMBOK® Guide 7th Edition (Domain: Uncertainty & Measurement).
• Agile Practice Guide (PMI, 2021): Phần Technical Debt trong Agile Metrics.
• Scrum Guide (2020): Velocity & DoD.

✅ Đáp án đúng: Increased technical debt

Lý do lựa chọn:

• Việc bỏ qua testing để "tăng velocity" ngắn hạn sẽ tạo ra nợ kỹ thuật (technical debt) – tức là codebase chất lượng kém, đầy lỗi tiềm ẩn, phải trả giá bằng thời gian/công sức fix sau. PM cần theo dõi và quản lý technical debt để tránh làm chậm dự án dài hạn, đảm bảo Value Delivery theo PMBOK 7th.
• Đây là rủi ro chính trong Agile: Velocity tăng giả tạo nhưng sustainability giảm (Scrum Guide).

🛠️ 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 dựa trên PMP/Agile:

• ❌ Increased bum rate
  Sai vì: "Bum rate" có lẽ là lỗi chính tả của "burn rate" (tốc độ đốt ngân sách). Bỏ testing giảm chi phí ngắn hạn (ít nhân sự test), không tăng burn rate. PMBOK 7th (Measurement Indicators) nhấn mạnh burn rate liên quan chi phí, không phải chất lượng code.

• ❌ Increased cost
  Sai vì: Ngắn hạn, skip testing giảm cost (tiết kiệm thời gian test). Chi phí chỉ tăng dài hạn do fix lỗi từ technical debt, nhưng câu hỏi hỏi "as a result of this decision" (kết quả trực tiếp), không phải hậu quả gián tiếp. Agile Practice Guide khuyên theo dõi cost variance, không áp dụng trực tiếp ở đây.

• ✅ Increased technical debt
  Đúng vì: Skip testing trực tiếp tạo technical debt – code chưa hoàn thiện, tích tụ rủi ro chất lượng. PM phải focus vào debt repayment (refactor) để duy trì velocity bền vững. Đây là khái niệm cốt lõi trong Agile Metrics (PMBOK 7th & Scrum Guide).

• ❌ Decreased efficiency
  Sai vì: Ngắn hạn, skip testing tăng efficiency (velocity cao hơn do hoàn thành features nhanh). Efficiency dài hạn mới giảm do debt, nhưng quyết định nhằm "increase momentum", nên không phải focus ngay. PMBOK 7th định nghĩa efficiency qua throughput, không phải giảm ngay lập tức.

🧠 Kết luận PMP: PM cần proactively manage technical debt qua burndown charts hoặc debt ratio để cân bằng speed & quality (Principle 5: Optimize Resource Allocation). Tránh lặp lại bằng cách enforce DoD nghiêm ngặt!

🧩 Giải thích nội dung câu hỏi một cách chi tiết và rõ ràng

Câu hỏi này thuộc chủ đề quản lý dự án thực thi (Project Execution) trong PMP, tập trung vào tình huống xử lý sự cố chậm trễ đột ngột do yếu tố bên ngoài. Cụ thể:

• Trong giai đoạn thực thi dự án, project manager (PM) phát hiện work performance reports (báo cáo hiệu suất công việc) suy giảm nghiêm trọng chỉ trong dưới 2 tuần.
• Nguyên nhân: Đội ngũ ở country A phàn nàn về chậm trễ do kỳ nghỉ lễ ở country B ảnh hưởng đến đội ngũ dự án của họ (có thể là dự án đa quốc gia, nơi kỳ nghỉ văn hóa ở một nước làm gián đoạn công việc phụ thuộc).
  🛠️ Mục tiêu câu hỏi: Kiểm tra khả năng xử lý rủi ro kịp thời của PM, thay vì áp dụng ngay các biện pháp khắc phục lịch trình hoặc xung đột nội bộ. Đây là tình huống rủi ro đã biết hoặc có thể dự đoán (như holidays quốc tế), cần tuân thủ quy trình Risk Management theo PMBOK® Guide 7th Edition (2021, cập nhật đến 2026 với PMP Exam Content Outline 2024).

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

Đáp án đúng: Review the risk management plan to evaluate the probability and impact of these delays.

Lý do:

• Đây là bước đầu tiên và phù hợp nhất theo Risk Management Process (PMBOK® 7th Edition, Domain 5: Risk Management). Kỳ nghỉ ở country B là rủi ro bên ngoài (external risk) có thể đã được xác định trong Identify Risks hoặc Perform Qualitative/Quantitative Risk Analysis. PM cần review risk management plan để đánh giá xác suất (probability) và tác động (impact) của delay, từ đó quyết định response strategy (tránh, giảm thiểu, chấp nhận, chuyển giao).
• Việc báo cáo hiệu suất xấu đi nhanh chóng cho thấy cần monitor risks liên tục, không nhảy ngay vào crashing/fast-tracking (chỉ dùng khi schedule baseline đã bị ảnh hưởng nghiêm trọng).
• Emoji nhấn mạnh: 📈 Phù hợp nguyên tắc "Proactive Risk Management" – dự đoán và đánh giá trước hành động.

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

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á dựa trên PMBOK® 7th Edition và PMP Exam Content Outline 2024 (Performance Domain: Uncertainty domain cho rủi ro).

• ❌ Implement crashing to compress the schedule and improve the schedule performance index (SRI).
  Sai vì: Crashing là kỹ thuật schedule compression (tăng tài nguyên để rút ngắn duration, tăng chi phí), chỉ áp dụng khi schedule variance (SV) đã âm lớn và baseline cần điều chỉnh (Control Schedule process). Ở đây, delay mới xảy ra <2 tuần do holidays (rủi ro chưa được xác nhận impact đầy đủ), chưa có dữ liệu SRI/SPI chính xác. Áp dụng ngay sẽ lãng phí chi phí mà không đánh giá rủi ro gốc (holidays có thể lặp lại). 🛑 Không phải bước đầu tiên.

• ❌ Implement fast-tracking to compress the schedule and improve the SPI.
  Sai vì: Fast-tracking là thực hiện song song các hoạt động (tăng rủi ro rework), dùng cho compression sau khi Develop Schedule bị delay. Tình huống này là rủi ro bất ngờ từ bên ngoài (holidays country B), không phải vấn đề nội tại lịch trình. SPI (Schedule Performance Index) chưa được xác định rõ, và fast-tracking có thể làm tình hình tệ hơn nếu không review rủi ro trước. 🚫 Quá vội vàng, vi phạm nguyên tắc "Tailor to Context".

• ❌ Perform conflict management using the project's resource management plan.
  Sai vì: Conflict management thuộc Manage Team process (Resource Management domain), dùng cho xung đột nội bộ đội ngũ (như tranh chấp nhiệm vụ). Đây không phải xung đột mà là delay do yếu tố bên ngoài (holidays), không liên quan resource management plan (chỉ quản lý phân bổ nguồn lực). Phàn nàn từ country A chỉ là triệu chứng, không phải xung đột cá nhân. ⚠️ Nhầm lẫn process group: Execution vs. Team Management.

• ✅ Review the risk management plan to evaluate the probability and impact of these delays.
  Đúng vì: Như đã giải thích ở trên, đây là Monitor Risks process (Risk Management domain). Holidays đa quốc gia là rủi ro lịch trình (schedule risk) phổ biến trong dự án toàn cầu, cần đánh giá probability/impact matrix để chọn response (ví dụ: contingency plan như buffer). Phù hợp 12 Principles of PMBOK® 7 (Principle 9: Optimize Risk Responses). 🎯 Bước logic đầu tiên để tránh escalation.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Section 4.5 Risk Management, Tools & Techniques (Risk Register, Probability-Impact Matrix).
• PMP Exam Content Outline 2024 (PMI.org): Domain 5: Uncertainty (25% exam), People Domain cho team issues.
• Agile Practice Guide (integrated in PMBOK® 7): Nhấn mạnh risk-based retrospectives cho dự án hybrid/multinational.
• Cập nhật 2026: PMI xác nhận không thay đổi core Risk processes (dựa trên PDU updates).

🛠️ Lời khuyên PMP: Luôn scan môi trường bên ngoài (holidays, cultural factors) trong Plan Risk Management để tránh tình huống này! Nếu cần thực hành thêm, tham khảo PMI mock exams.

🧩 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ý Đội ngũ (Manage Team) và Giao tiếp trong Dự án (Project Communications Management) theo PMBOK Guide 7th Edition (cập nhật đến 2026, với các nguyên tắc Agile và Hybrid). Tình huống mô tả:
Trong các cuộc gọi hàng ngày (daily calls, thường theo Scrum/Agile), các thành viên đội ngũ chia sẻ tiến độ công việc. Tuy nhiên, một thành viên không chia sẻ nhiều chi tiết và đang đảm nhận các nhiệm vụ quan trọng (critical tasks) sắp bắt đầu. Toàn bộ đội ngũ phân bố ở các quốc gia khác nhau (distributed team, virtual team).
Mục tiêu của Project Manager (PM): Chọn hai lựa chọn giúp cải thiện tình hình, đảm bảo giao tiếp hiệu quả, tăng sự tham gia (engagement) và giảm rủi ro cho critical work.
🛠️ Vấn đề cốt lõi: Thiếu chi tiết từ một thành viên có thể dẫn đến rủi ro dự án (risk), đặc biệt với công việc critical ở môi trường phân tán. PM cần áp dụng servant leadership để hỗ trợ đội ngũ, không phải trừng phạt.

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

• Encourage all team members to use a virtual workspace
• Talk to the team member about their engagement and take appropriate action.

Lý do lựa chọn: Hai lựa chọn này phù hợp với Nguyên tắc 9: Teamwork và Process 9.4: Manage Project Team (PMBOK 7th). Chúng thúc đẩy công cụ hỗ trợ giao tiếp liên tục cho virtual team và đối thoại cá nhân hóa để giải quyết vấn đề engagement, giúp PM kiểm soát rủi ro mà không làm gián đoạn đội ngũ. 📘 Nguồn: PMBOK 7th Edition, Section 4.6.2.3 (Virtual Teams) & Agile Practice Guide (Daily Stand-ups & Tools like Jira/Slack).

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

• ✅ Encourage all team members to use a virtual workspace
  Phương án này ĐÚNG vì khuyến khích sử dụng không gian làm việc ảo (như Microsoft Teams, Jira, Asana, Trello) giúp đội ngũ phân tán chia sẻ tiến độ thời gian thực (real-time updates), tài liệu, task tracking mà không phụ thuộc hoàn toàn vào daily calls. Điều này đặc biệt hiệu quả cho critical tasks sắp bắt đầu, giảm rủi ro thiếu thông tin. Theo PMBOK 7th, virtual tools là best practice cho distributed teams, tăng collaboration và engagement toàn đội. 🛠️ Không chỉ giải quyết vấn đề một cá nhân mà nâng cao hiệu suất chung.

• ❌ Ask the team to send emails with detailed task progress
  Phương án này SAI vì email là giao tiếp không đồng bộ, dễ bị bỏ lỡ và tạo overhead hành chính cho daily progress. Với critical work và virtual team, email không thay thế được tools tương tác (interactive tools). PMBOK 7th khuyến nghị pull communication (như workspace) thay vì push như email, tránh làm chậm dự án. 📘 Nguồn: PMBOK 7th, 9.2.3 (Communication Methods).

• ✅ Talk to the team member about their engagement and take appropriate action.
  Phương án này ĐÚNG vì PM phải thực hiện high-performance conversations (đối thoại hiệu suất cao) để hiểu nguyên nhân (có thể do múi giờ, kỹ năng, động lực). Sau đó, hành động phù hợp như coaching, training hoặc điều chỉnh. Đây là servant leadership cốt lõi, phù hợp Agile (1-on-1 retrospectives). Giúp giữ chân tài năng và giải quyết gốc rễ vấn đề mà không escalate sớm. 🧩 Nguồn: PMBOK 7th, 9.4.2.1 (Develop Team) & Standard for Project Management (Team Engagement Models).

• ❌ Reassign the work to a resource who participates in the daily calls
  Phương án này SAI vì chuyển giao công việc (reassign) không giải quyết nguyên nhân thiếu engagement, có thể gây demotivate đội ngũ, tăng rủi ro knowledge loss với critical tasks. PMBOK ưu tiên phát triển đội ngũ thay vì thay thế, trừ khi là last resort. Với virtual team, reassignment còn phức tạp hóa logistics. ❌ Nguồn: PMBOK 7th, 9.4.3 (Manage Team - Avoid Punitive Actions).

• ❌ Report the team member's poor performance to the functional manager
  Phương án này SAI vì escalate ngay lập tức bỏ qua trách nhiệm Manage Team của PM. PM phải tự giải quyết qua coaching trước khi báo cáo (formal escalation). Điều này vi phạm value-driven management, có thể làm giảm trust trong đội ngũ. 📘 Nguồn: PMBOK 7th, 4.7 (Project Team Management) & Ethics Code (Respect & Responsibility).

Kết luận 🔥: Hai đáp án đúng tập trung vào hỗ trợ và giao tiếp chủ động, phù hợp PMP 2026 với emphasis trên Agile/Hybrid. Áp dụng sẽ giúp dự án smooth! 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 chủ đề Quản lý Bên liên quan (Stakeholder Management) và Quản lý Sự thay đổi (Change Management) trong PMP, theo PMBOK Guide 7th Edition (và các cập nhật đến 2026).

📖 Tình huống: Quản lý dự án đang triển khai hệ thống phần mềm mới. Một số nhân viên bộ phận đang kháng cự sự thay đổi (resistance to change), vì họ nghi ngờ tính cần thiết của hệ thống mới và lo ngại nó sẽ cản trở quy trình hiện tại.
❓ Vấn đề cốt lõi: Câu hỏi hỏi về hành động mà quản lý dự án nên làm ngay từ đầu dự án (at the start of the project) để ngăn chặn (prevent) sự kháng cự này.
🛠️ Mục tiêu: Nhấn mạnh việc tham gia bên liên quan sớm để xây dựng sự hiểu biết chung, giảm thiểu rủi ro kháng cự – một nguyên nhân phổ biến của thất bại dự án (theo nghiên cứu PMI, lên đến 30% dự án thất bại do vấn đề stakeholder).

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

Đáp án đúng: Involved stakeholders from all levels of the company so everyone understands the change

Lý do 🏆:
Theo PMBOK 7th Edition (Domain 4: Stakeholder Performance Domain), việc tham gia bên liên quan từ mọi cấp độ ngay từ đầu dự án là bước quan trọng nhất để xác định (Identify Stakeholders), lập kế hoạch tham gia (Plan Stakeholder Engagement) và quản lý sự tham gia (Manage Stakeholder Engagement). Điều này giúp:

• Mọi người hiểu rõ lợi ích thay đổi, giảm nghi ngờ.
• Xây dựng sự ủng hộ từ sớm, tránh kháng cự sau này.
• Đảm bảo "everyone understands the change" – phù hợp với nguyên tắc Value Delivery và Adaptive Practices trong môi trường Agile/Hybrid.
  Nếu làm từ đầu, kháng cự sẽ được giảm thiểu tối đa! 🚀

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

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

• Created a communications management plan that outlined the method of communicating to stakeholders
  ❌ Sai: Kế hoạch truyền thông (Communications Management Plan) rất quan trọng (PMBOK 7th, Domain 3: Uncertainty), nhưng nó chỉ tập trung vào "phương thức truyền thông" chứ không đảm bảo sự tham gia hai chiều để xây dựng sự hiểu biết. Truyền thông một chiều không ngăn chặn kháng cự nếu stakeholder không được involve từ đầu. Đây chỉ là công cụ hỗ trợ, không phải giải pháp cốt lõi từ "start of the project".

• Ensured that the company culture encourages changes before accepting the project
  ❌ Sai: Văn hóa tổ chức (Organizational Culture) thuộc trách nhiệm lãnh đạo cấp cao, không phải quản lý dự án (PM theo PMBOK 7th không kiểm soát culture trước khi accept project). Hơn nữa, thay đổi văn hóa là dài hạn, không phải hành động cụ thể "at the start". Điều này vượt quá phạm vi vai trò PM và không trực tiếp giải quyết kháng cự từ nhân viên bộ phận.

• Encouraged leadership to discuss the change with departments that are typically resistant to change
  ❌ Sai: Việc khuyến khích lãnh đạo thảo luận chỉ là biện pháp ứng phó sau (reactive), không phải từ "start of the project". PMBOK 7th nhấn mạnh proactive engagement với tất cả stakeholder, không chỉ "departments typically resistant". Cách này có thể bỏ sót các bên khác và không xây dựng sự hiểu biết toàn diện.

• Involved stakeholders from all levels of the company so everyone understands the change
  ✅ Đúng: Như đã giải thích ở trên. Đây là best practice theo Stakeholder Engagement Assessment Matrix (PMBOK 7th, Figure 13-9), đảm bảo C1-C5 levels (Unaware đến Leading) từ sớm, giảm resistance hiệu quả nhất.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật PMI đến 2026): Chương 4 (Stakeholder Performance Domain), Chương 13 (Stakeholder Management) – Nhấn mạnh "Engage Stakeholders Early".
• PMI Pulse of the Profession 2023-2026: Báo cáo cho thấy 48% dự án thành công nhờ stakeholder involvement từ initiating phase.
• The Standard for Project Management (2021): Principle 11 – Engage Stakeholders.
  Tham khảo thêm tại pmi.org cho Agile Practice Guide (Hybrid approaches for software projects).

Hy vọng phân tích này giúp bạn ôn PMP hiệu quả! 💪 Nếu cần 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 tập trung vào vai trò của Project Manager (PM) trong việc công nhận và động viên thành viên đội ngũ theo nguyên tắc quản lý con người (People Domain) trong PMP.

• Tình huống: Một thành viên đội ngũ đang liên tục cải thiện bản thân (continuously improving), đồng thời là mô hình mẫu mực và mentor cho người khác trong tổ chức (role model and mentor). Điều này thể hiện sự cam kết cao (commitment) với sự phát triển cá nhân và hỗ trợ đội ngũ.
• Câu hỏi chính: PM nên công nhận sự cam kết này như thế nào (acknowledge this team member's commitment)?
• Mục tiêu: Kiểm tra kiến thức về công nhận kịp thời và liên tục (timely recognition) để duy trì động lực, phù hợp với PMBOK 7th Edition (2021) và các cập nhật đến 2026, nhấn mạnh vào nguyên tắc hỗ trợ đội ngũ (Support Team Members) và quá trình Develop Team trong Agile/Hybrid approaches.

🛠️ Nguyên tắc PMP liên quan: Theo PMBOK 7th, PM phải công nhận thành tích ngay lập tức và xuyên suốt vòng đời dự án (throughout the project life cycle) để khuyến khích hành vi tích cực, tránh trì hoãn (delayed recognition) có thể làm giảm động lực.

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

Đáp án đúng: Appreciate this team member's performance throughout the project life cycle

Lý do (🧩 Phân tích chi tiết):

• Việc công nhận hiệu suất xuyên suốt vòng đời dự án là cách kịp thời, liên tục và phù hợp nhất, giúp củng cố hành vi cải thiện và mentor ngay lập tức.
• Điều này phù hợp với People Domain (PMBOK 7th): PM cần động viên thường xuyên (ongoing appreciation) để xây dựng văn hóa hỗ trợ, tăng cường sự gắn kết đội ngũ (team engagement).
• Tránh các hành động muộn màng hoặc không liên quan, đảm bảo giá trị gia tăng ngay trong dự án hiện tại (value delivery in current project).

📋 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 tiếng Anh. Mỗi phương án được đánh giá ✅ (Đúng) hoặc ❌ (Sai), kèm lý do dựa trên PMP mới nhất:

• Appreciate this team member's performance throughout the project life cycle
  ✅ ĐÚNG 🏆: Như đã giải thích, đây là cách tối ưu để công nhận kịp thời, khuyến khích sự cải thiện liên tục và vai trò mentor. Theo PMBOK 7th (Section 4.2 Develop Team), recognition phải ongoing để hỗ trợ động lực đội ngũ, không chờ đợi sự kiện cụ thể.

• Send this person to a meeting to negotiate the scope with the client
  ❌ SAI 🚫: Hành động này không liên quan đến sự cải thiện cá nhân hay mentor nội bộ. Nó có thể là phần thưởng không phù hợp (unrelated reward), làm phân tán trọng tâm đội ngũ và vi phạm nguyên tắc Stakeholder Engagement (chỉ giao nhiệm vụ phù hợp kỹ năng).

• Promote this team member to a coaching role after this project is completed
  ❌ SAI ⏳: Quá muộn (after project completion), không công nhận ngay lập tức trong dự án hiện tại. Promotion là quyết định ngoài phạm vi PM (HR responsibility), có thể gây áp lực không cần thiết và không đảm bảo Develop Team xuyên suốt project life cycle.

• Document it in the team member's end of year performance review
  ❌ SAI 📝: Trì hoãn quá lâu (end of year), làm mất giá trị động viên ngay lập tức. PMBOK 7th nhấn mạnh real-time feedback thay vì chỉ ghi chép hành chính (administrative documentation), vì delayed recognition giảm hiệu quả team motivation.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, PMI): People Domain (Trang 37-49), Principle 9: Optimize Risk? Không, cụ thể Value Principle: Support Team & Develop Team activities (Recognition & Rewards, Trang 4.2).
• PMI Agile Practice Guide (2021): Servant Leadership – Ongoing appreciation trong retrospectives.
• Cập nhật PMP Exam Content Outline 2021 (hiệu lực đến 2026): Domain III: People (27% trọng số), Task 6: "Support and motivate team members".
• The Standard for Project Management (2021): Section 3.1.5: Foster team performance qua continuous recognition.

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

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

Câu hỏi tập trung vào giai đoạn lập kế hoạch dự án (Planning Process Group) theo PMBOK Guide 7th Edition. Project Manager (PM) nhận thấy cách tiếp cận tham gia bên liên quan (Stakeholder Engagement) tiêu chuẩn không đủ hiệu quả. Cụ thể, có một đại diện khách hàng (client representative) không phải là người ra quyết định chính (not a key decision maker), nhưng lại rất hay đưa ý kiến mạnh mẽ (extremely opinionated) và có uy quyền cảm nhận cao (perceived level of authority) trong các cuộc họp. Điều này có thể gây trở ngại cho tiến độ dự án (roadblock to progress).

Câu hỏi yêu cầu PM xử lý tình huống này như thế nào từ nay trở đi (moving forward), nhấn mạnh vào việc quản lý bên liên quan chủ động, phù hợp với Stakeholder Engagement Plan và nguyên tắc Tailor Your Approach trong PMBOK 7th Edition (đến năm 2026 vẫn áp dụng phiên bản này với các cập nhật nhỏ qua Agile Practice Guide và Process Guidelines).

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

Đáp án đúng: Allocate time to gain buy-in from the stakeholder prior to key decision meetings.

Lý do: Phương án này thể hiện cách tiếp cận chủ động và phù hợp (proactive stakeholder management) theo PMBOK 7th Edition. Thay vì tránh né hoặc chỉ ghi nhận rủi ro, PM cần xây dựng sự ủng hộ (gain buy-in) từ bên liên quan này trước các cuộc họp quyết định chính (prior to key decision meetings). Điều này giúp giảm thiểu ảnh hưởng tiêu cực từ "uy quyền cảm nhận", tăng cường sự đồng thuận và tránh roadblock. Đây là ứng dụng trực tiếp của Manage Stakeholder Engagement process (trong Stakeholder Performance Domain), nơi ưu tiên engage early với các bên có ảnh hưởng tiềm ẩn cao dù không phải power chính thức.

🛠️ 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 đánh giá đúng/sai dựa trên thực tiễn PMP mới nhất:

• ❌ [SAI] Ask that only key decision makers attend the project meetings.
  Phương án này không đúng vì vi phạm nguyên tắc bao quát tất cả bên liên quan (engage all stakeholders) trong Stakeholder Engagement Plan (PMBOK 7th, Section 4.6). Việc loại trừ bên này có thể làm tăng rủi ro bất mãn (resistance), bỏ lỡ cơ hội thu thập insight và làm giảm tính minh bạch. Stakeholder này dù không phải key decision maker nhưng có ảnh hưởng cảm nhận, nên cần engage chứ không loại trừ.

• ❌ [SAI] Update the project schedule to cater to this particular stakeholder.
  Phương án này không phù hợp vì thay đổi lịch trình dự án chỉ để chiều theo một bên liên quan cá nhân sẽ làm phá vỡ nguyên tắc tối ưu hóa giá trị (optimize value delivery) và có thể gây delay không cần thiết (PMBOK 7th, Uncertainty Domain). Stakeholder Engagement không yêu cầu điều chỉnh schedule toàn bộ dự án; thay vào đó, cần các biện pháp engage linh hoạt mà không ảnh hưởng timeline chính.

• ✅ [ĐÚNG] Allocate time to gain buy-in from the stakeholder prior to key decision meetings.
  Như đã giải thích ở phần đáp án đúng, đây là cách tối ưu và chủ động nhất, phù hợp với Power/Interest Grid (stakeholder có Interest cao nhưng Power thấp → Manage Closely qua build support). Giúp chuyển hóa từ roadblock tiềm ẩn thành supporter, hỗ trợ Decision-Making và Progress.

• ❌ [SAI] Update the risk register to consider the possible project impacts.
  Phương án này chỉ đúng một phần nhưng không phải giải pháp chính (reactive thay vì proactive). Việc cập nhật Risk Register (theo Manage Risks process, Uncertainty Domain) là cần thiết để ghi nhận rủi ro từ stakeholder này, nhưng câu hỏi hỏi về "handle this moving forward" → cần hành động engage cụ thể chứ không chỉ log rủi ro. Nếu chỉ dừng ở risk register mà không mitigate qua engagement, roadblock vẫn tồn tại.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật đến 2026):
  • Stakeholder Performance Domain (Section 4.6): Nhấn mạnh Engage Stakeholders proactively, đặc biệt với "supportive" hoặc "unaware" types.
  • Principle 12: Navigate Complexity (tailor engagement cho perceived authority).
  • Manage Stakeholder Engagement: Sử dụng techniques như one-on-one sessions để gain buy-in.
• PMP Exam Content Outline (2024-2026): 18% câu hỏi về People Domain, ưu tiên stakeholder strategies.
• Agile Practice Guide (integrated với PMBOK 7th): Khuyến khích early feedback loops để tránh impediments từ vocal stakeholders.

Phân tích này giúp bạn nắm vững cách áp dụng PMP trong thực tế! 🚀