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

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

Câu hỏi xoay quanh một dự án Agile đã bắt đầu 6 tháng, nơi các thành viên đội ngũ có bất đồng về thời gian họp hàng ngày (daily meetings hoặc daily stand-ups) do một số người không thể tham gia cùng lúc. Quản lý dự án (PM) tin rằng đội ngũ Agile phải tự tổ chức (self-organizing), và thời gian họp nên do đội ngũ tự sắp xếp.
Vấn đề cốt lõi: Làm thế nào để PM hỗ trợ đội ngũ tự giải quyết xung đột mà không can thiệp trực tiếp, phù hợp với nguyên tắc Agile nơi đội ngũ tự quản lý nội bộ?
🛠️ Bối cảnh PMP/Agile (theo PMBOK 7th Edition & Agile Practice Guide 2021, cập nhật đến 2026): Trong Agile, daily stand-ups là sự kiện bắt buộc (Scrum Guide), nhưng thời gian linh hoạt do đội ngũ quyết định. PM đóng vai trò Servant Leader, hỗ trợ đội ngũ tự tổ chức thay vì chỉ đạo. Xung đột cần giải quyết qua các công cụ như Team Charter để xây dựng quy tắc chung.

✅ Đáp án đúng: Establish a team charter

Lý do lựa chọn:
Team Charter là tài liệu giúp đội ngũ định nghĩa rõ ràng các quy tắc, kỳ vọng, trách nhiệm và cách giải quyết xung đột (bao gồm thời gian họp). Nó trao quyền cho đội ngũ tự tổ chức mà không cần PM can thiệp trực tiếp, phù hợp với nguyên tắc Agile "Self-Organizing Teams" (PMBOK 7: Principle 7 - Optimize Risk Responses; Agile Practice Guide: Team Charter hỗ trợ High-Performing Teams).
📘 Dẫn nguồn:

• PMBOK® Guide 7th Edition (2021): Section 4.6 Team Charter trong Develop Team.
• Agile Practice Guide (PMI, 2021): p. 42-43, khuyến nghị Team Charter để giải quyết xung đột sớm.
• Scrum Guide (2020, cập nhật 2025): Teams tự quyết định events.

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

• Establish a team charter.
  ✅ Đúng: Phương án này trực tiếp hỗ trợ đội ngũ tự tổ chức bằng cách tạo tài liệu chung định nghĩa quy trình họp, giải quyết bất đồng. PM chỉ khởi xướng, đội ngũ sở hữu – phù hợp Servant Leadership trong Agile (PMBOK 7: Foster Collaboration Principle).

• Recognize the team's contributions.
  ❌ Sai: Việc công nhận đóng góp chỉ tạo động lực chung (motivation), không giải quyết gốc rễ bất đồng về thời gian họp. Đây là công cụ phát triển đội ngũ (Manage Team), nhưng không liên quan trực tiếp đến tự tổ chức daily meetings (Agile Practice Guide: Reward Recognition sau khi giải quyết issue).

• Assign a team leader.
  ❌ Sai: Agile chống lại việc chỉ định leader cố định vì đội ngũ phải tự tổ chức (self-organizing, cross-functional). Chỉ định leader sẽ phá vỡ nguyên tắc flat hierarchy (Scrum Guide: No hierarchies; PMBOK 7: Principle 10 - Leadership).

• Establish a project schedule.
  ❌ Sai: Lập lịch dự án tổng thể (schedule baseline) không giải quyết vấn đề nội bộ đội ngũ về thời gian họp hàng ngày. Daily stand-ups linh hoạt theo iteration/sprint, không cần schedule cứng nhắc (PMBOK 7: Iterative Scheduling in Hybrid/Agile).

🧠 Kết luận: Phương án đúng giúp PM tuân thủ Agile principles, tránh micromanagement, thúc đẩy đội ngũ trưởng thành. Nếu áp dụng thực tế, khuyến nghị workshop tạo Team Charter ngay! 🚀

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

Câu hỏi thuộc chủ đề Quản lý Đội ngũ (Team Management) trong PMP, cụ thể liên quan đến Performance Domain: Team theo PMBOK® Guide – Seventh Edition (2021, cập nhật đến 2026).

📖 Tình huống mô tả: Một đội ngũ đang thực hiện dự án với các giao hàng tăng dần (incremental deliveries) – thường thấy trong môi trường Agile hoặc Hybrid (theo Agile Practice Guide). Quản lý dự án (PM) nhận thấy một thành viên ít tham gia họp đội nhưng vẫn giao hàng đúng hạn. Khi thảo luận, thành viên tiết lộ nguyên nhân demotivation (mất động lực) là cảm thấy thiếu kỹ năng xử lý nhiệm vụ mới.

🛠️ Vấn đề cốt lõi: Đây là tình huống về phát triển cá nhân và động lực đội ngũ. PM cần áp dụng Servant Leadership (lãnh đạo phục vụ), coaching/mentoring để hỗ trợ thành viên phát triển, thay vì các biện pháp tiêu cực hoặc né tránh. Mục tiêu là xây dựng High-Performing Team bằng cách giải quyết gốc rễ (skill gap), thúc đẩy sự tham gia và động lực lâu dài.

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

Đáp án đúng: Discuss growth and development needs with the team member and provide learning opportunities accordingly.

Giải thích lý do 📘:

• Phương án này trực tiếp và phù hợp nhất với Team Performance Domain (PMBOK® 7th Ed., trang 77-80), nhấn mạnh phát triển cá nhân (develop individuals) qua thảo luận nhu cầu growth/development và cung cấp cơ hội học tập (learning opportunities như training, mentoring, on-the-job learning).
• Trong Agile/Hybrid (incremental deliveries), PM đóng vai coach/facilitator, giúp thành viên vượt qua skill gap để tăng engagement (tham gia họp) và động lực.
• ✅ Lợi ích: Xây dựng lòng tin, giữ chân nhân tài, thúc đẩy self-motivation lâu dài, phù hợp Universal Principle: Be a diligent, respectful, and caring steward (Principle 11, PMBOK® 7th).
• Dẫn chứng: PMBOK® Guide – Seventh Edition (Team models như Tuckman); Agile Practice Guide (Coaching for growth).

❌ Phân tích TẤT CẢ các phương án (Đúng/Sai)

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á dựa trên best practices PMP mới nhất (2026), tập trung vào hiệu quả, tính bền vững và nguyên tắc People-first.

• Phương án A: Replace the team member with a resource from another team who already has the requisite training and skills needed.
  ❌ SAI: Phương án này tiêu cực và không khuyến khích, vi phạm Build a Team (Team Domain, PMBOK® 7th, trang 78). Thay thế nhân sự gây mất động lực đội ngũ, tăng chi phí tuyển dụng/onboarding, và bỏ qua cơ hội phát triển nội bộ. PMP ưu tiên retain và develop thay vì "discard". Không giải quyết gốc rễ demotivation.

• Phương án B: Review which tasks the team member would feel more motivated to work on, then assign those tasks to the team member.
  ❌ SAI: Phương án né tránh vấn đề cốt lõi (skill gap với nhiệm vụ mới), chỉ tập trung động lực ngắn hạn. Trong incremental deliveries, đội cần linh hoạt xử lý tasks mới; assign tasks "dễ" làm giảm growth, vi phạm Foster Collaboration (Team Domain). PMP khuyến nghị confront challenges qua learning, không phải "cherry-pick" tasks (theo Process Assets trong Develop Team).

• Phương án C (Đúng – đã phân tích ở trên): Discuss growth and development needs with the team member and provide learning opportunities accordingly.
  ✅ ĐÚNG: Như giải thích chi tiết phần trên – holistic approach phù hợp Servant Leadership và coaching.

• Phương án D: Create a self-paced learning plan with the team member during working hours, with checkpoints on learning progress.
  ❌ SAI: Tuy nghe tích cực, nhưng thiếu bước đầu tiên: thảo luận nhu cầu growth/development trước khi tạo plan. Plan self-paced trong giờ làm có thể ảnh hưởng productivity đội (resource allocation), và checkpoints dễ thành micromanagement. PMBOK® 7th ưu tiên collaborative discussion trước (Develop Team), không phải tự áp đặt plan mà chưa align với needs cá nhân.

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

• PMBOK® Guide – Seventh Edition (PMI, 2021, cập nhật 2026): Team Performance Domain (Ch. 4), Principles 7 (Foster a Collaborative Culture) & 10 (Lead with Empathy).
• Agile Practice Guide (PMI, 2017, tích hợp PMBOK® 7th): Servant Leadership & Coaching (Section 3.2).
• PMP Exam Content Outline (2024-2026): Domain III: Business Environment (13%), nhưng chủ yếu Domain II: Process (Manage Project Team).

🛠️ Bài học PMP: Luôn ưu tiên phát triển con người để xây dựng đội ngũ bền vững! Nếu áp dụng, PM sẽ tăng team engagement lên 20-30% theo các case study PMI.

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

Câu hỏi này thuộc chủ đề quản lý dự án hybrid (kết hợp giữa phương pháp predictive - waterfall và agile), một mô hình phổ biến trong PMP theo PMBOK® Guide 7th Edition và các cập nhật đến 2026. Trong dự án hybrid, hợp đồng quy định rõ các deliverables theo từng quý, khách hàng muốn di chuyển milestone thứ hai vào quý đầu tiên để thể hiện kết quả hữu hình (tangible outcome) cho stakeholders sớm. Tuy nhiên, project manager (PM) đã giải thích rằng việc này không khả thi trừ khi thay đổi requirements của milestone thứ hai.

Tình huống cốt lõi: Khách hàng đang yêu cầu thay đổi lịch trình (schedule change), nhưng PM cần xử lý một cách hợp tác, linh hoạt (collaborative và value-driven), đặc biệt trong hybrid project nơi phần agile cho phép ưu tiên requirements. Câu hỏi yêu cầu chọn hai hành động mà PM nên thực hiện để giải quyết vấn đề, tập trung vào việc điều chỉnh requirements thay vì từ chối cứng nhắc hoặc leo thang.

Mục tiêu: PM phải tối ưu hóa giá trị cho khách hàng bằng cách thảo luận ưu tiên và khả thi kỹ thuật, phù hợp với nguyên tắc Stakeholder Engagement và Adaptive Planning trong PMBOK 7.

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

Hai đáp án đúng là:
Ask the customer for their priorities regarding the requirements for the second milestone.
Go back to the development team and discuss which second milestone requirements can be performed in the first quarter.

Lý do lựa chọn:
Trong dự án hybrid, PM cần áp dụng cách tiếp cận customer-centric và iterative 🛠️. Trước tiên, hỏi khách hàng về ưu tiên requirements để hiểu giá trị cốt lõi họ mong muốn (value prioritization), tránh thay đổi không cần thiết. Sau đó, thảo luận với development team để đánh giá khả thi thực tế (feasibility) – có thể một phần requirements milestone 2 có thể "slice" và di chuyển vào quý 1 mà không ảnh hưởng lớn. Điều này thể hiện Tailoring (tùy chỉnh phương pháp) và Team Collaboration theo PMBOK 7, giúp tạo ra tangible outcome mà vẫn kiểm soát rủi ro.

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

• ✅ Ask the customer for their priorities regarding the requirements for the second milestone.
  Đúng vì: Đây là bước đầu tiên trong Stakeholder Engagement và Product Backlog Refinement (hybrid/agile hybrid). PM cần làm rõ business value của từng requirement để ưu tiên (prioritization), giúp khách hàng quyết định thay đổi nào thực sự cần thiết. Tránh tình trạng "scope creep" không kiểm soát, đồng thời xây dựng lòng tin 📈.

• ❌ Escalate the issue to upper management to resolve the problem, and suggest a plan.
  Sai vì: PM là người chịu trách nhiệm chính cho dự án (Accountable Owner theo PMBOK 7). Leo thang ngay (escalate) chỉ dành cho trường hợp ngoài quyền hạn hoặc rủi ro cao, ở đây PM có thể tự xử lý qua thảo luận. Hành động này làm giảm uy tín PM và bỏ lỡ cơ hội collaborative problem-solving 👎.

• ❌ Convince the customer to leave the second milestone in place and not change it.
  Sai vì: Cách tiếp cận này cứng nhắc, thiếu linh hoạt (non-adaptive), trái với tinh thần hybrid project nơi cần negotiate và adapt dựa trên feedback. "Convince" mang tính ép buộc, có thể làm mất lòng tin khách hàng và bỏ qua cơ hội tạo giá trị sớm hơn ❌.

• ❌ Tell the customer that moving the milestone has a very high impact on the cost of the project.
  Sai vì: Chỉ nêu tác động tiêu cực (high impact on cost) mà không đề xuất giải pháp là fear-based communication, không khuyến khích đối thoại. PMBOK 7 nhấn mạnh transparent và solution-oriented communication; cần dữ liệu cụ thể (impact analysis) kèm lựa chọn thay thế thay vì "dọa" khách hàng 🚫.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021, cập nhật 2026 qua PMI Standards+): Domain Stakeholder (Engagement), Planning (Adaptive Strategies), và Project Work (Tailoring hybrid approaches).
• Agile Practice Guide (PMI, 2017, tích hợp PMBOK 7): Phần Hybrid Project Delivery, nhấn mạnh prioritization và team retrospectives cho feasibility.
• PMI Code of Ethics & Professional Conduct: Nguyên tắc Responsibility và Respect yêu cầu collaborative handling thay vì escalate hoặc convince.
  (Nguồn chính thức từ PMI.org, khuyến nghị kiểm tra phiên bản mới nhất qua PMI membership).

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 chủ đề quản lý dự án Agile/Scrum trong PMP (phiên bản PMBOK 7th Edition và Agile Practice Guide cập nhật đến 2026).
📖 Tình huống: Một đội dự án đang thực hiện sprint planning. Cuối sprint, product increment (sản phẩm tăng dần) phải được deploy lên site của khách hàng. Product Owner (PO) nhận email từ account manager thông báo rằng khách hàng có thể chưa sẵn sàng (not ready) để cài đặt phiên bản sản phẩm mới.
🛠️ Vấn đề cốt lõi: Project Manager (PM) cần hành động ngay để giảm thiểu rủi ro triển khai (deployment risk), đảm bảo stakeholder engagement và quản lý rủi ro (Risk Management). Trong Agile, PM (hoặc Scrum Master) phải chủ động phối hợp với các bên liên quan bên ngoài để tránh gián đoạn sprint goal và Definition of Done (DoD). Không hành động có thể dẫn đến backlog hoặc mất lòng tin từ khách hàng.

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

Đáp án đúng: Contact the customer's project manager.
📘 Lý do:

• Trong môi trường Agile/Scrum, PM cần trực tiếp liên hệ với stakeholder chính bên khách hàng để giải quyết vấn đề readiness triển khai. Customer's project manager là người chịu trách nhiệm tổng thể về dự án phía khách hàng, bao gồm phối hợp lịch trình, tài nguyên và readiness (sẵn sàng). Điều này phù hợp với nguyên tắc Manage Communications và Stakeholder Engagement (PMBOK 7th: Principle 5 - Optimize Risk Responses; Agile Practice Guide: Ch. 4 - Servant Leadership).
• Hành động này giúp thu thập thông tin chính xác, đàm phán timeline và điều chỉnh kế hoạch sprint kịp thời, tránh rủi ro deploy thất bại.
  ✅ Lợi ích: Tăng tính minh bạch, trách nhiệm và hiệu quả phối hợp giữa hai bên dự án.

🛠️ 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. Tôi giữ nguyên văn bản gốc tiếng Anh của phương án, đánh dấu ✅/❌ và giải thích hoàn toàn bằng tiếng Việt dựa trên PMP/Agile best practices.

• ❌ Ask the sales team to inform the customer.
  Sai vì: Sales team (đội ngũ bán hàng) chỉ tập trung vào hợp đồng và doanh số, không chịu trách nhiệm về technical readiness hoặc triển khai sản phẩm. Việc giao cho sales sẽ làm chậm trễ quy trình, thiếu chuyên môn dự án và có thể gây hiểu lầm thông tin (vi phạm nguyên tắc Direct and Manage Project Work - PMBOK 7th).

• ✅ Contact the customer's project manager.
  Đúng vì: Như đã giải thích ở trên, đây là stakeholder phù hợp nhất để xử lý vấn đề readiness tổng thể. PM chủ động liên hệ giúp quản lý rủi ro chủ động (Proactive Risk Management) và đảm bảo giá trị kinh doanh (Business Value Delivery) trong Agile.

• ❌ Ask the product owner to inform the customer.
  Sai vì: Product Owner đã nhận thông tin từ account manager và vai trò chính của PO là quản lý product backlog với đội phát triển nội bộ, không phải đại diện giao tiếp trực tiếp với khách hàng về readiness triển khai. PM phải chịu trách nhiệm phối hợp bên ngoài (Scrum Guide 2020: Scrum Master facilitates external communications).

• ❌ Contact the customer's technical lead.
  Sai vì: Technical lead chỉ xử lý khía cạnh kỹ thuật thuần túy (như code hoặc infrastructure), không quản lý readiness tổng thể (bao gồm lịch trình, phê duyệt, tài nguyên). Liên hệ sai người sẽ không giải quyết gốc rễ vấn đề dự án (vi phạm Tailoring Communications - Agile Practice Guide).

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021, cập nhật 2026): Principle 4 (Deliver Value), Domain 3 (Project Work - Risk Management), Domain 4 (Stakeholder Engagement).
• Agile Practice Guide (7th Edition): Ch. 3 (Lifecycle Selection), Ch. 6 (Implementing Agile - Sprint Planning & Deployment).
• Scrum Guide (2020, reaffirmed 2025): Scrum Master role in stakeholder collaboration và Product Increment DoD.
  🔗 Nguồn chính thức: PMI.org (Project Management Institute) và ScrumGuides.org.

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ả một tình huống thực tế trong dự án phát triển phần mềm với đội ngũ phân tán địa lý (distributed team) trên toàn thế giới. Một bản phát hành quan trọng bị trì hoãn do một lập trình viên không phản hồi kịp thời email được gửi đến toàn đội, vì anh ấy bỏ lỡ việc đọc email. Vấn đề cốt lõi là sự cố giao tiếp (communication failure) trong môi trường làm việc từ xa, dẫn đến rủi ro trì hoãn dự án.
📌 Mục tiêu câu hỏi: Kiểm tra kiến thức PMP về việc xác định kế hoạch quản lý phù hợp để khắc phục vấn đề giao tiếp, đặc biệt trong bối cảnh đội ngũ đa địa lý (theo PMBOK 7th Edition, giao tiếp là yếu tố then chốt trong môi trường hybrid/virtual teams).
🛠️ Bối cảnh PMP mới nhất (đến 2026): Theo PMBOK 7th Edition (2021) và các cập nhật PMI đến 2026, quản lý giao tiếp được nhấn mạnh trong Project Communications Management (Domain 5: Project Work), với trọng tâm vào các công cụ kỹ thuật số, kênh đa dạng và theo dõi hiệu quả giao tiếp để tránh "information gaps" ở đội ngũ toàn cầu.

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

Review the communications management plan.
✅ Lý do: Vấn đề trực tiếp xuất phát từ sự thất bại trong giao tiếp (email không được đọc kịp thời), đặc biệt với đội ngũ phân tán địa lý cần các kênh giao tiếp rõ ràng, kịp thời và đa dạng (như Slack, Teams, notifications). Việc xem xét lại Communications Management Plan (Quy trình 10.1 Plan Communications Management trong PMBOK 7th) sẽ giúp PM đánh giá và cải thiện:

• Các phương pháp giao tiếp (methods: push/pull/interactive).
• Tần suất, định dạng (email có thể không hiệu quả, cần thêm alerts).
• Công cụ hỗ trợ (virtual tools cho global teams).
• Theo dõi hiệu quả (feedback loops).
  Điều này trực tiếp giải quyết nguyên nhân gốc rễ, tránh lặp lại trì hoãn.

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

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 PMBOK 7th Edition và tình huống cụ thể:

• Review the stakeholder engagement plan.
  ❌ Sai vì: Kế hoạch này (Stakeholder Engagement Plan, Quy trình 13.3 Manage Stakeholder Engagement) tập trung vào việc tương tác, theo dõi mức độ tham gia của các bên liên quan bên ngoài/chiến lược (như khách hàng, nhà tài trợ), không phải giao tiếp nội bộ hàng ngày của đội ngũ dự án. Vấn đề ở đây là lập trình viên (thành viên đội ngũ nội bộ) bỏ lỡ email, không liên quan đến engagement của stakeholder.

• Review the resource management plan.
  ❌ Sai vì: Kế hoạch này (Resource Management Plan, Domain 4: Measurement, Quy trình 9.1 Plan Resource Management) quản lý phân bổ, phát triển nguồn lực con người (skills, training, allocation), không trực tiếp xử lý vấn đề giao tiếp hoặc email. Có thể gián tiếp liên quan nếu thiếu training về tools, nhưng không phải giải pháp chính cho sự cố "missed email".

• Review the risk management plan.
  ❌ Sai vì: Kế hoạch này (Risk Management Plan, Domain 4: Uncertainty) dùng để xác định, phân tích và ứng phó rủi ro dự án (như trì hoãn). Mặc dù sự cố này là một rủi ro giao tiếp, việc chỉ review plan không giải quyết ngay nguyên nhân (cách thức giao tiếp kém), mà cần cập nhật risk register trước. Không phải hành động trực tiếp nhất.

• Review the communications management plan.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là kế hoạch cốt lõi cho mọi vấn đề giao tiếp nội bộ/đội ngũ (Communications Management Plan, Domain 5: Project Work). Nó bao quát mô hình giao tiếp cho global teams, đảm bảo thông tin đến đúng người, đúng lúc, đúng cách – trực tiếp khắc phục "email missed" bằng cách tối ưu hóa channels và monitoring.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Section 4.5.1.1 Communications Management (trang 100-102), nhấn mạnh "effective communication in distributed teams". PMI.org/PMP-Updates.
• PMI Agile Practice Guide (2021): Chương về Virtual Teams & Communication Tools (cập nhật 2025-2026 qua PMI Standards Plus).
• Process Groups: A Practice Guide (2022): Monitoring & Controlling Processes cho Communications.

🛡️ Lời khuyên PMP: Trong thực tế, PM nên áp dụng Earned Value Management kết hợp với communication audits để dự phòng tình huống tương tự!

🧩 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 Agile/Scrum trong PMP (Project Management Professional), cụ thể là quản lý thay đổi trong một sprint. Tình huống: Trong quá trình thực hiện sprint, một thành viên đội ngũ phát hiện một vấn đề (issue). Theo đánh giá của thành viên đó và Product Owner (PO), vấn đề này có mức độ quan trọng cao hơn các tính năng (features) còn lại trong sprint, nhưng không phải là trở ngại (roadblock) ngăn cản hoàn thành sprint.
Câu hỏi yêu cầu: Project Lead (thường là Scrum Master hoặc người dẫn dắt đội ngũ) nên yêu cầu đội ngũ làm gì?
🛠️ Mục tiêu kiểm tra kiến thức: Kiểm tra nguyên tắc bảo vệ sprint scope (không thay đổi nội dung đã cam kết trong sprint), xử lý thay đổi qua Product Backlog, và tránh scope creep trong môi trường Agile. Theo PMBOK Guide 7th Edition (2021) và Scrum Guide 2023 (cập nhật mới nhất đến 2026), sprint là time-boxed (cố định thời gian và scope), chỉ thay đổi nếu có lý do khẩn cấp lớn; các issue mới phải ưu tiên lại ở backlog cho sprint sau.

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

Đáp án đúng: Follow the sprint plan by delivering the features established for the sprint and prioritize the issue in the backlog.

Lý do:

• Trong Scrum/Agile, đội ngũ phải tuân thủ Sprint Backlog đã cam kết (Sprint Goal và các items đã chọn từ Product Backlog). Không được thay đổi scope giữa sprint để tránh gián đoạn và mất ổn định (theo nguyên tắc "Protect the Sprint").
• Issue này không phải roadblock (không block tiến độ), nên không cần xử lý ngay. Thay vào đó, refine và ưu tiên nó trong Product Backlog để xem xét ở Sprint Planning tiếp theo.
• Điều này đảm bảo Deliverable đúng hạn và tối ưu hóa giá trị liên tục.
  📘 Nguồn tham khảo:
• Scrum Guide 2023 (Scrum.org): Phần "Sprint" và "Changes during the Sprint".
• PMBOK Guide 7th Edition, Domain 3: Project Life Cycle & Delivery (Agile Hybrid), Principle 5: Deliver Value Iteratively.

📋 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. Mỗi phương án được đánh giá dựa trên nguyên tắc Agile/Scrum mới nhất:

• ❌ [SAI] Avoid the temptation to make any changes and address the issue in the next sprint.
  Phương án này sai vì quá cứng nhắc và không linh hoạt. Mặc dù Scrum bảo vệ sprint, nhưng nếu issue thực sự critical (dù không block), đội ngũ có thể thảo luận trong Daily Scrum hoặc Sprint Review để refine backlog ngay. Chỉ "tránh thay đổi hoàn toàn và đẩy sang sprint sau" bỏ qua cơ hội cải tiến backlog kịp thời, vi phạm nguyên tắc Continuous Improvement (Kaizen trong Agile).

• ❌ [SAI] Submit the issue to the change control board (CCB) to evaluate and formally approve a plan to address it.
  Phương án này sai vì áp dụng quy trình Waterfall/Truyền thống (Change Control Board - CCB từ PMBOK Predictive), không phù hợp với Agile. Trong Scrum, không có CCB; thay đổi được xử lý qua Product Owner refine backlog, không cần phê duyệt chính thức giữa sprint. Sử dụng CCB sẽ làm chậm Agile (theo PMBOK 7th, Hybrid Approach chỉ dùng khi cần).

• ❌ [SAI] Address this issue only as it has a higher priority than the remaining features of the same sprint.
  Phương án này sai vì khuyến khích scope creep – thay đổi scope giữa sprint chỉ vì priority cao hơn. Scrum cấm điều này trừ trường hợp "major disruption" (Scrum Guide). Phải hoàn thành Sprint Goal trước, issue mới chỉ prioritize ở backlog, tránh rủi ro delay deliverable và mất team velocity.

• ✅ [ĐÚNG] Follow the sprint plan by delivering the features established for the sprint and prioritize the issue in the backlog.
  Như đã giải thích ở phần đáp án đúng: Hoàn hảo tuân thủ nguyên tắc Agile – bảo vệ sprint, deliver value, và refine backlog cho tương lai. Đảm bảo tính ổn định và focus cao.

🧠 Kết luận PMP: Câu hỏi nhấn mạnh Scrum Master/Project Lead phải hướng dẫn đội ngũ ưu tiên ổn định sprint hơn là reactive changes. Áp dụng thực tế để tăng team performance! Nếu cần ví dụ case study, hãy hỏi thêm. 🚀

🧩 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 (Manage Project Changes) và Quản lý bên liên quan (Stakeholder Engagement) trong PMP, theo PMBOK Guide 7th Edition (2021) và các cập nhật đến 2026.

Tình huống cụ thể:
Một project manager bên ngoài đang quản lý dự án xây dựng văn phòng mới cho một công ty lớn. Project management plan (kế hoạch quản lý dự án) quy định rõ ràng phải thuê một nguồn lực bên ngoài có chuyên môn cao để xem xét lại và xác thực (revise and validate) một thành phần quan trọng của dự án. Tuy nhiên, client (chủ đầu tư) từ chối thuê nguồn lực này vì chi phí cao, dù chi phí vẫn trong giới hạn ngân sách dự án (within the project budget).

Vấn đề cốt lõi: Project manager phải giải quyết mâu thuẫn giữa tuân thủ kế hoạch dự án (mandatory requirement) và sự phản đối từ client (stakeholder chính). Điều này kiểm tra kỹ năng đánh giá rủi ro, giao tiếp với bên liên quan, và quyết định dựa trên giá trị dự án mà không vi phạm quyền hạn của client. Project manager không có quyền tự quyết chi tiêu nếu client reject, dù trong budget.

📘 Nguồn tham khảo: PMBOK Guide 7th Edition - Domain 3: Business Environment (Stakeholder Engagement), Domain 4: Delivery (Manage Changes); PMP Exam Content Outline 2021 (Domain IV: People - Task 6: Engage stakeholders).

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

Đáp án đúng: Evaluate the consequences and meet with the client to explain the possible scenarios.

Lý do:
🛠️ Project manager cần đánh giá hậu quả (evaluate consequences) của việc không thực hiện yêu cầu trong kế hoạch (như rủi ro chất lượng, chậm trễ, hoặc thất bại dự án). Sau đó, gặp client để giải thích các kịch bản có thể xảy ra (possible scenarios), giúp client hiểu rủi ro và cùng quyết định thay đổi (change request). Điều này tuân thủ nguyên tắc quản lý rủi ro chủ động và tương tác bên liên quan (Stakeholder Engagement), thúc đẩy quyết định dựa trên dữ liệu. Không tự ý hành động mà phải hợp tác với client để đảm bảo giá trị dự án. Đây là cách tiếp cận hybrid agile-predictive khuyến khích trong PMP mới nhất (2021-2026).

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

• Try to accomplish the task internally by leveling resources from other projects.
  ❌ Sai: Phương án này vi phạm nguyên tắc quản lý nguồn lực (Resource Management). "Leveling resources" có nghĩa lấy nguồn lực từ dự án khác để làm nội bộ, nhưng kế hoạch yêu cầu nguồn lực bên ngoài chuyên môn cao, không thể thay thế dễ dàng. Hơn nữa, project manager bên ngoài không kiểm soát nguồn lực nội bộ client, dễ gây xung đột portfolio và tăng rủi ro chất lượng. Không đánh giá rủi ro trước, chỉ là giải pháp tạm bợ (workaround) không bền vững.
  📘 Tham khảo: PMBOK 7th - Domain 2: Team (Resource Optimization).

• Ask the client for a meeting and meet with the client to explain that the task will not be performed.
  ❌ Sai: Phương án này thụ động và tiêu cực, thông báo "không thực hiện" mà không đánh giá rủi ro hoặc đề xuất giải pháp. Vi phạm trách nhiệm project manager phải bảo vệ kế hoạch dự án và giá trị (value delivery). Client có thể chấp nhận, nhưng project manager phải chứng minh rủi ro để tránh trách nhiệm sau này (accountability). Không khuyến khích giao tiếp hai chiều.
  📘 Tham khảo: PMBOK 7th - Domain 5: Planning (Manage Communications).

• Evaluate the consequences and meet with the client to explain the possible scenarios.
  ✅ Đúng: Như đã giải thích ở trên, đây là cách chuyên nghiệp nhất: Đánh giá rủi ro → Giao tiếp minh bạch → Hợp tác quyết định. Hỗ trợ Integrated Change Control và Stakeholder Sphere of Influence.

• Hire the resource in order to achieve the project objectives.
  ❌ Sai: Vi phạm quyền hạn client (client là người phê duyệt chi tiêu, dù trong budget). Project manager không được tự ý thuê mà bỏ qua sự từ chối, có thể dẫn đến tranh chấp hợp đồng, mất lòng tin. PMP nhấn mạnh tuân thủ governance và không "đơn phương hành động" (unilateral decision).
  📘 Tham khảo: PMBOK 7th - Domain 1: Stakeholders (Prioritize Stakeholders); Code of Ethics & Professional Conduct (Respect - 2.2.1).

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

Câu hỏi gốc:
The project team is experiencing schedule delays due to issues arising with suppliers. Some of the tasks are on the critical path. What should the project manager do in this situation?

✅ Giải thích rõ ràng:
Câu hỏi mô tả tình huống dự án gặp chậm trễ lịch trình (schedule delays) do vấn đề từ nhà cung cấp (suppliers). Đặc biệt, một số nhiệm vụ nằm trên đường găng (critical path) – đây là chuỗi các hoạt động quan trọng nhất quyết định thời gian hoàn thành tổng thể dự án. Nếu critical path bị ảnh hưởng, toàn bộ dự án có nguy cơ trễ hạn lớn.
🛠️ Vai trò của Project Manager (PM): Theo PMBOK Guide (phiên bản 7th Edition và cập nhật đến 2026), PM phải chủ động quản lý rủi ro lịch trình, tương tác với stakeholders và điều chỉnh kế hoạch để đảm bảo giá trị giao hàng (value delivery). Không nên né tránh trách nhiệm mà cần đánh giá lại critical path để quyết định hành động như crash schedule (tăng tài nguyên), fast-tracking (làm song song nhiệm vụ), hoặc điều chỉnh ưu tiên.

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

Đáp án đúng: Review the critical path with the stakeholders to define next steps.

🧩 Lý do chi tiết:

• Vấn đề nằm trên critical path, đòi hỏi PM phải đánh giá lại (review) đường găng cùng stakeholders để xác định các bước tiếp theo (define next steps). Điều này phù hợp với Principle 7: Optimize Risk Responses và Stakeholder Engagement trong PMBOK 7th Edition.
• Stakeholders (như khách hàng, tài trợ, đội ngũ) cần tham gia để đồng thuận về thay đổi, tránh quyết định đơn phương dẫn đến xung đột. PM sử dụng công cụ như Critical Path Method (CPM) để cập nhật lịch trình và thảo luận các lựa chọn ứng phó (mitigate, accept, hoặc transfer risk liên quan supplier).
• Đây là hành động chủ động, hợp tác, giúp duy trì project performance domain (Schedule và Stakeholder domains), đảm bảo dự án không lệch hướng mà vẫn giao giá trị đúng hạn.

📋 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 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 quy trình PMP mới nhất (PMBOK 7th Edition, nhấn mạnh adaptive và hybrid approaches đến 2026).

• Discuss the critical path issues with the purchasing department.
  ❌ Sai vì: Phương án này chỉ tập trung vào phối hợp nội bộ với bộ phận mua sắm (purchasing department), nhưng bỏ qua stakeholders bên ngoài và không giải quyết gốc rễ critical path. Theo Procure Resources process, PM có thể làm vậy như một phần manage procurement, nhưng không phải hành động đầu tiên ưu tiên. Nó thiếu tính toàn diện và không định hướng next steps, có thể dẫn đến chậm trễ thêm.

• Review the critical path with the stakeholders to define next steps.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là hành động cốt lõi trong Monitor and Control Project Work và Manage Stakeholder Engagement. PM cần chia sẻ thông tin minh bạch về critical path để lấy ý kiến, điều chỉnh kế hoạch, phù hợp với Performance Domains: Planning, Uncertainty, và Stakeholder.

• Review the work breakdown structure (WBS) with the suppliers.
  ❌ Sai vì: WBS là cấu trúc phân tích công việc nội bộ dự án, không nên chia sẻ chi tiết với suppliers vì có thể tiết lộ thông tin nhạy cảm hoặc không liên quan. Suppliers chỉ cần biết requirements cụ thể (qua contract), không phải toàn bộ WBS. Điều này vi phạm Create WBS process và protect project information. Hành động đúng hơn là review contract obligations thay vì WBS.

• Escalate the supplier-related issues to the sponsor for resolution.
  ❌ Sai vì: Escalate chỉ dùng khi PM đã thử các biện pháp manage và vẫn thất bại (theo Escalation Process trong PMBOK). Ở đây, PM chưa phân tích đầy đủ critical path và có thể tự giải quyết qua procurement management (như negotiate với supplier). Sponsor chỉ can thiệp ở mức high-level decisions, không phải chi tiết vận hành, tránh làm PM mất quyền chủ động.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật PMI đến 2026): Chapter 4 (Performance Domains: Schedule, Uncertainty), Principle 9 (Holistic Thinking), và Appendix X6 (Critical Path Method).
• PMI Agile Practice Guide (2021): Nhấn mạnh stakeholder collaboration trong adaptive scheduling.
• PMP Exam Content Outline (2024-2026): Domain III: Business Environment (15%), Domain IV: People (42%) – ưu tiên stakeholder engagement.
  🛠️ Lời khuyên học PMP: Thực hành với công cụ như Primavera hoặc MS Project để simulate critical path adjustments!

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

Câu hỏi này thuộc chủ đề Quản lý đội ngũ và hỗ trợ con người (People Domain) trong PMP, đặc biệt liên quan đến Agile practices như daily standup meeting. Trong cuộc họp standup hàng ngày (một phần của Scrum hoặc các phương pháp Agile), thành viên đội ngũ báo cáo tiến độ theo 3 câu hỏi chính: "Hôm nay tôi làm gì?", "Hôm qua tôi làm gì?", và "Có trở ngại (impediment) nào không?".

📌 Tình huống cụ thể: Project Manager (PM) nhận thấy một thành viên đội ngũ báo cáo các nhiệm vụ chưa hoàn thành nhưng không đề cập đến bất kỳ trở ngại nào (no impediments). Đồng nghiệp thông báo rằng thành viên này đang gặp vấn đề cá nhân (personal issue), có thể ảnh hưởng đến hiệu suất công việc. Câu hỏi yêu cầu PM nên làm gì tiếp theo để xử lý tình huống này một cách phù hợp, tuân thủ nguyên tắc lãnh đạo phục vụ (Servant Leadership) và hỗ trợ đội ngũ theo PMBOK 7th Edition (2021) và các cập nhật Agile đến 2026.

Mục tiêu là hỗ trợ đội ngũ vượt qua trở ngại cá nhân mà không vi phạm quyền riêng tư, tránh can thiệp không cần thiết, và duy trì năng suất dự án. Đây là bài kiểm tra khả năng đồng cảm, hỗ trợ cá nhân hóa của PM theo 12 Principles of PMBOK 7th (Focus on value, Optimize risk, etc.) và Hybrid/Agile approaches.

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

Đáp án đúng: Understand the team member's personal issue and offer them support.

🛠️ Lý do chi tiết:

• Theo People Domain trong PMP (PMBOK 7th Edition), PM phải đóng vai trò Servant Leader, ưu tiên hiểu và hỗ trợ đội ngũ (Understand and support team members) để xây dựng lòng tin và động lực. Vấn đề cá nhân là một dạng impediment ngầm (hidden impediment), và PM cần tiếp cận trực tiếp, đồng cảm để nắm rõ tình hình trước khi hành động.
• Trong Agile Practice Guide (PMI, cập nhật 2023-2026), daily standup nhấn mạnh hỗ trợ nhanh chóng cho impediments, bao gồm cả cá nhân. Việc hiểu vấn đề và đề nghị hỗ trợ (offer support) giúp thành viên cảm thấy được quan tâm, khuyến khích họ chia sẻ cởi mở hơn, từ đó giải quyết gốc rễ thay vì triệu chứng.
• Không vi phạm quyền riêng tư vì PM tiếp cận trực tiếp (private conversation), phù hợp Ethical and Professional Conduct (Code of Ethics PMI).

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

🧩 Phân tích từng lựa chọn (giữ nguyên nội dung gốc bằng tiếng Anh, giải thích bằng tiếng Việt):

• ❌ Ask the human resources (HR) manager to speak with this team member.
  Sai vì: Việc đẩy ngay cho HR là tránh né trách nhiệm lãnh đạo của PM. Theo PMBOK 7th (People Domain), PM phải xử lý trực tiếp các vấn đề đội ngũ nhỏ trước khi escalate. HR chỉ can thiệp khi liên quan chính sách công ty hoặc vấn đề pháp lý nghiêm trọng. Điều này có thể làm mất lòng tin của thành viên, vi phạm nguyên tắc Build a team và Tailor leadership.

• ❌ Coach the team member on how to keep work and personal issues separate.
  Sai vì: Coaching kiểu này giả định và phán xét, không dựa trên sự hiểu biết thực tế. PMBOK 7th nhấn mạnh Holistic approach (xem xét toàn diện con người), không tách biệt work-life một cách máy móc. Nó bỏ qua đồng cảm (empathy), có thể làm tình hình tệ hơn, trái với Agile values như "Individuals and interactions over processes".

• ❌ Reallocate this team member's tasks to others for the immediate future.
  Sai vì: Đây là giải pháp ngắn hạn, thiếu hỗ trợ gốc rễ, có thể làm giảm động lực đội ngũ và tăng gánh nặng cho người khác. Theo Stakeholder Engagement và Team Performance Domain (PMBOK 7th), PM ưu tiên enable team self-management thay vì micromanage/reallocate. Nó bỏ qua impediment cá nhân, vi phạm Principle 5: Optimize risk responses (xử lý rủi ro con người).

• ✅ Understand the team member's personal issue and offer them support.
  Đúng vì: Như đã giải thích ở trên, phù hợp Servant Leadership và supportive coaching. PM tạo môi trường an toàn (psychological safety), khuyến khích chia sẻ, dẫn đến giải pháp bền vững. Hỗ trợ có thể là linh hoạt lịch làm việc, tài nguyên EAP (Employee Assistance Program), hoặc mentor.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, PMI): People Domain (Section 4), Principle 11: Focus on quality (including people support), Agile Hybrid models.
• Agile Practice Guide (PMI, 2017 - cập nhật 2023): Daily Scrum/Standup (Section 4.3), Servant Leadership.
• PMI Code of Ethics & Professional Conduct (2022): Responsibility và Respect standards.
• PMP Exam Content Outline (2024-2026): 42% People Domain, nhấn mạnh emotional intelligence và support.
• Tài liệu trực tuyến: PMI.org (kiến thức cập nhật đến 2026 qua ECO - Exam Content Outline).

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

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

Câu hỏi này thuộc chủ đề Quản lý dự án Agile/Scrum trong PMP (phiên bản mới nhất PMBOK Guide 7th Edition và Agile Practice Guide 2021, cập nhật đến 2026). Tình huống xảy ra trong Sprint Planning – một sự kiện quan trọng nơi Product Backlog được tinh chỉnh và Sprint Backlog được xây dựng.

• Product Owner (PO) muốn ưu tiên các Product Backlog Items (PBIs) có high business value để tối ưu hóa giá trị kinh doanh.
• Project team lo ngại về technical debt (nợ kỹ thuật – mã code kém chất lượng tích tụ) và infrastructure dependencies (phụ thuộc hạ tầng), có thể ảnh hưởng đến khả năng deliver value thực tế.

🛠️ Vấn đề cốt lõi: Xung đột giữa business value (từ PO) và khả năng thực hiện kỹ thuật (từ team). Project Manager (PM) cần xử lý để đảm bảo team collaboration, self-organizing team và value delivery bền vững, tránh quyết định một chiều.

📘 Kiến thức PMP liên quan:

• PM đóng vai trò servant-leader, hỗ trợ team đạt consensus (Agile Practice Guide, Principle 3: Team as High-Performing Team).
• Sprint Planning yêu cầu whole-team participation và công cụ như voting (dot voting, planning poker) để ưu tiên (Scrum Guide 2020, cập nhật 2023).

✅ Đáp án đúng

Support a voting exercise so all team members can express their opinion and the reason behind their vote.

Lý do lựa chọn:

• Đây là cách hợp tác và dân chủ nhất trong Agile, giúp cân bằng ý kiến PO (business value) và team (technical risks). Voting khuyến khích transparency, shared understanding và consensus-driven decisions (PMBOK 7th, 6.6 Manage Project Changes; Agile Practice Guide, Tools: Relative Prioritization).
• PM hỗ trợ self-organizing team, không áp đặt, đảm bảo Sprint Goal khả thi và giảm risks từ technical debt. Điều này phù hợp Hybrid/Agile approaches trong PMP mới nhất, nhấn mạnh stakeholder engagement toàn diện.

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

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

• ✅ Support a voting exercise so all team members can express their opinion and the reason behind their vote.
  Đúng vì: Phương án này thúc đẩy team empowerment và collaborative decision-making, giải quyết xung đột bằng dữ liệu từ tất cả bên (PO + team). Voting giúp prioritize dựa trên value vs. risk, tránh bias cá nhân (Scrum Guide: Sprint Planning collaborative; PMI Agile Certified Practitioner - PMI-ACP®).

• ❌ Support the project sponsor so the decision is made top-down and the team follows the provided direction.
  Sai vì: Agile chống lại top-down command-and-control, ưu tiên empowered teams. Sponsor can thiệp chỉ ở strategic level, không micromanage Sprint Planning (PMBOK 7th, Principle 11: Navigate Complexity – team tự quyết; vi phạm Agile Manifesto: Individuals over Processes).

• ❌ Support the product owner so only items with high business value are included in the next sprint.
  Sai vì: Bỏ qua team input về technical debt và dependencies, dẫn đến unrealistic commitments và failed sprints. PO quyết định priority nhưng team quyết feasibility (Definition of Done). Điều này vi phạm sustainable pace (Agile Principle 8).

• ❌ Support the project team so technical debt and infrastructure dependencies are included in the next sprint.
  Sai vì: Ưu tiên team concerns một chiều, bỏ qua business value từ PO, có thể làm lệch value delivery. Technical debt cần repay nhưng phải cân bằng, không phải dominate Sprint (PMBOK 7th, 4.7 Manage Project Delivery – balance value/risks).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Process 4.7 Deliver Value; Principles: Stewardship, Teamwork.
• Agile Practice Guide (PMI, 2021): Section 4.2 Sprint Planning; Tools: Voting Techniques.
• Scrum Guide (2020/2023): Sprint Planning – collaborative refinement.
• PMI-ACP Exam Content Outline (2026 updates): Domain III: Agile Principles & Mindset (25%).

🛠️ Lời khuyên PMP: Trong thực tế, PM nên facilitate refinement sessions định kỳ để giảm technical debt upfront! Nếu cần luyện thi, tập trung Agile Hybrid models.