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

🧩 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, tập trung vào tình huống xử lý impediment (chướng ngại vật) trong Daily Standup Meeting (họp đứng hàng ngày).

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

• Một lập trình viên (developer) thông báo trong Daily Standup rằng một backlog item (mục trong sprint backlog) không thể hoàn thành vì họ phải nghỉ đột xuất vài ngày.
• Backlog item này là prerequisite (điều kiện tiên quyết) cho một feature mà người dùng mong đợi trong sprint review tiếp theo.
• Vai trò của project lead (có thể là Scrum Master hoặc lead developer): Phải xử lý nhanh chóng để bảo vệ sprint goal, duy trì tính minh bạch và linh hoạt theo nguyên tắc Agile.

🛠️ Mục tiêu chính: Xác định hành động phù hợp nhất theo Scrum framework, nơi ưu tiên tái ưu tiên backlog thay vì ép buộc cá nhân hoặc thông báo trực tiếp khách hàng, nhằm giữ value delivery cao nhất có thể.

✅ Đáp án đúng: Work with the product owner to change the priorities in the sprint backlog.

Lý do lựa chọn (theo PMBOK 7th Edition & Scrum Guide mới nhất 2023, áp dụng đến 2026):

• Trong Agile, Daily Scrum dùng để phát hiện impediment. Project lead phối hợp với Product Owner (PO) để repioritize sprint backlog – đây là quyền hạn chính của PO (theo Scrum Guide: PO quản lý Product Backlog và quyết định thứ tự).
• Hành động này tối ưu hóa giá trị, có thể swap item khác thay thế prerequisite, tránh ảnh hưởng sprint goal mà không vi phạm self-organizing team.
• ✅ Hợp lý nhất: Giữ tính minh bạch, trao quyền cho PO, phù hợp 12 nguyên tắc Agile (hợp tác chặt chẽ với customer qua PO).

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

• ✅ Work with the product owner to change the priorities in the sprint backlog.
  Đúng vì: Như phân tích trên, đây là cách chuẩn Agile để xử lý impediment, PO quyết định priorities để đảm bảo sprint goal. Không ai khác (kể cả project lead) được tự thay đổi backlog. (Scrum Guide 2023: "The Product Owner is accountable for effective Product Backlog management.")

• ❌ Work with the product owner to inform the users that the feature is delayed.
  Sai vì: Thông báo delay cho users không phải ưu tiên ngay, mà phải giải quyết nội bộ trước (repioritize). PO mới chịu trách nhiệm stakeholder communication ở Sprint Review, không phải Daily Standup. Hành động này bỏ qua cơ hội mitigate risk kịp thời, vi phạm Agile Principle: Deliver working software frequently.

• ❌ Ask the development manager to provide a replacement for a couple of days.
  Sai vì: Agile nhấn mạnh self-organizing team, không phụ thuộc hierarchy (dev manager). Việc tìm replacement ngắn hạn không khả thi (kiến thức chuyên môn cá nhân hóa), có thể tạo overhead và vi phạm cross-functional team. Scrum khuyến khích swarm nội bộ thay vì external help.

• ❌ Ask the developer to postpone the leave until the backlog item is delivered.
  Sai vì: Vi phạm nguyên tắc work-life balance và empower team members (Agile Manifesto: Motivated individuals). Ép nghỉ phép là command-and-control, trái Scrum (team tự quản lý capacity). Có thể dẫn đến burnout, không khuyến khích trong PMP Hybrid/Agile (PMBOK 7: Respect team dynamics).

📘 Tài liệu tham khảo

• Scrum Guide 2023 (Scrum.org): Phần Daily Scrum & Product Owner responsibilities.
• PMBOK Guide 7th Edition (2021) + Agile Practice Guide: Domain "Team" & "Planning" – xử lý impediments qua reprioritization.
• PMP Exam Content Outline 2021 (cập nhật 2024-2026): 50% Agile/Hybrid, nhấn mạnh servant leadership trong standups.

🛠️ Kết luận: Hành động đúng giúp dự án linh hoạt và bền vững, phù hợp PMP mindset mới nhất! Nếu cần ví dụ thực tế, hỏi thêm nhé! 🚀

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

Câu hỏi này thuộc chủ đề Agile Project Management trong PMP (phiên bản PMBOK® Guide 7th Edition và Agile Practice Guide, cập nhật đến 2026). Tình huống mô tả một tổ chức đang chuyển đổi sang agile delivery (giao hàng linh hoạt), với một team mới được thành lập. Dự án gặp vấn đề: variation of team velocity rất cao (tốc độ làm việc của team biến động mạnh) và mỗi sprint chỉ deliver ít hơn cam kết (giao ít hơn những gì đã commit). Một project lead mới có nền tảng kỹ thuật mạnh được giao nhiệm vụ.

Vấn đề cốt lõi:

• Velocity biến động cao thường do estimation không chính xác hoặc team chưa quen thuộc (team mới).
• Under-delivery lặp lại cho thấy quy trình sprint planning và estimation cần cải thiện.
• Project lead cần hành động phù hợp với nguyên tắc Agile: Tập trung vào cải tiến liên tục (continuous improvement) qua retrospective, tôn trọng self-organizing team, và tránh can thiệp trực tiếp từ cá nhân (dù có background mạnh).

Mục tiêu: Chọn hành động tốt nhất để giải quyết gốc rễ vấn đề mà không vi phạm Agile principles. 🛠️

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

Đáp án đúng: Recommend a different estimation method in the retrospective.

Lý do:

• Trong Agile/Scrum, retrospective là sự kiện cuối sprint để team tự đánh giá và cải thiện quy trình (Inspect & Adapt). Velocity biến động cao thường do estimation method không phù hợp (ví dụ: dùng hour-based thay vì story points với Planning Poker).
• Project lead nên khuyến nghị thay đổi method (như chuyển sang relative sizing, T-shirt sizing) trong retrospective, khuyến khích team tự quyết định – phù hợp với Servant Leadership và empowered team.
• Điều này giải quyết gốc rễ (estimation inaccuracy) một cách hợp tác, giúp velocity ổn định dần. Theo PMBOK 7th (Domain: Team & Agile), ưu tiên retrospective cho process improvement. 📈

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

• ❌ [SAI] Ask that estimations be provided only by senior developers.
  Giải thích: Phương án này vi phạm nguyên tắc whole team involvement trong Agile estimation (wideband Delphi hoặc Planning Poker yêu cầu tất cả thành viên tham gia, không chỉ senior). Nó tạo hierarchy (phân cấp), làm giảm team ownership và cross-functional collaboration. Với team mới, cần xây dựng shared understanding chứ không tập trung quyền lực vào cá nhân, dù project lead có background mạnh. (Agile Manifesto: "Individuals and interactions over processes and tools").

• ✅ [ĐÚNG] Recommend a different estimation method in the retrospective.
  Giải thích: Như đã nêu ở trên, đây là hành động tối ưu vì tận dụng retrospective để cải tiến estimation method (ví dụ: từ ideal hours sang story points). Giúp giảm variation velocity, tăng predictability. Phù hợp Scrum Guide 2020 (Sprint Retrospective: "team discusses improvements").

• ❌ [SAI] Allocate more time for estimation in the sprint planning.
  Giải thích: Chỉ tăng thời gian không giải quyết chất lượng estimation (vấn đề là method sai, không phải thời gian thiếu). Sprint planning nên time-boxed (4-8 giờ cho 4 tuần sprint), tránh kéo dài làm giảm hiệu quả. Không khuyến khích root cause analysis – chỉ là symptom fixing. (PMBOK Agile Practice Guide: Focus on value delivery, not extended planning).

• ❌ [SAI] Review and update the estimations in the daily standup.
  Giải thích: Daily standup (15 phút time-boxed) chỉ dùng để sync progress (What did I do? What will I do? Impediments?), không phải re-estimate backlog items. Việc này làm standup mất focus, vi phạm Scrum events purpose. Estimation thuộc Sprint Planning hoặc Backlog Refinement, không phải daily. (Scrum Guide: Daily Scrum is not for problem-solving).

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021): Agile Hybrid Approaches (Section 4.5), Team Performance Domain.
• Agile Practice Guide (PMI, 2017 - cập nhật 2023): Chapter 5: Implementing Agile – Estimation Techniques & Velocity.
• Scrum Guide (2020, Scrum.org): Sprint Retrospective & Events.
• PMI Standards đến 2026: Nhấn mạnh Value Delivery System và continuous improvement trong Agile transitions.

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

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

Câu hỏi này thuộc chủ đề Quản lý Tài nguyên Dự án (Resource Management) trong PMP, cụ thể liên quan đến việc xử lý tình huống khẩn cấp khi một công cụ thiết yếu (phần mềm tính toán) hết hạn giấy phép, dẫn đến đội ngũ không thể tiếp tục công việc. 🛠️

Tình huống mô tả: Một thành viên đội dự án thông báo cho Quản lý Dự án (PM) rằng giấy phép phần mềm dùng để tính toán đã hết hạn, khiến toàn bộ đội ngũ bị chặn công việc. Câu hỏi yêu cầu hành động ĐẦU TIÊN (first) mà PM nên thực hiện.

Điều này kiểm tra kiến thức PMP về quy trình giải quyết vấn đề (Problem Solving), lãnh đạo phục vụ (Servant Leadership), và quản lý trở ngại (Impediment Removal) theo PMBOK® Guide – Seventh Edition (2021) và cập nhật PMP Exam Content Outline 2021 (vẫn áp dụng đến 2026). PM cần ưu tiên xác định và giải quyết nhanh chóng trở ngại để giảm thiểu rủi ro trì hoãn dự án, thay vì né tránh hoặc leo thang không cần thiết. 📘

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

Đáp án đúng: Meet with the IT team to evaluate how fast the software license can be renewed.

Lý do:

• Đây là hành động đầu tiên và trực tiếp nhất để giải quyết gốc rễ vấn đề (root cause: hết hạn giấy phép). PM cần phối hợp với bộ phận IT (chịu trách nhiệm về công cụ kỹ thuật số) để đánh giá thời gian gia hạn, đảm bảo đội ngũ nhanh chóng tiếp tục công việc mà không gián đoạn lớn.
• Theo Process 9.4.2 Manage Project Resources (PMBOK 7th), PM phải chủ động đảm bảo tài nguyên sẵn sàng bằng cách liên hệ với các bên hỗ trợ nội bộ như IT. Trong môi trường Agile/Hybrid (PMP 2021+), việc loại bỏ trở ngại nhanh chóng là ưu tiên hàng đầu của PM (Scrum Master-like role).
• Hành động này thể hiện Tailored Approach: Phù hợp với dự án cần tính toán chính xác, tránh workaround tạm thời có thể gây lỗi. ✅

📋 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 bằng tiếng Anh. Tôi đánh dấu ✅ cho đúng và ❌ cho sai, kèm giải thích chi tiết bằng tiếng Việt dựa trên nguyên tắc PMP mới nhất.

• Issue a formal complaint to the project sponsor claiming a lack of proper tools.
  ❌ Sai: Đây là hành động leo thang không cần thiết và quá sớm. PM chưa cố gắng giải quyết nội bộ (như liên hệ IT), mà đã khiếu nại nhà tài trợ – vi phạm nguyên tắc Escalation Management (PMBOK 7th, 4.6). Sponsor chỉ can thiệp khi nội bộ thất bại, tránh làm mất uy tín PM và gây chậm trễ thêm.

• Ask the team members to find an alternative way to perform calculations.
  ❌ Sai: Yêu cầu đội ngũ tự tìm giải pháp thay thế là workaround tạm thời, không giải quyết gốc rễ (hết hạn license). Điều này có thể dẫn đến rủi ro chất lượng (sai sót tính toán) và tăng gánh nặng cho đội ngũ, trái với Servant Leadership (hỗ trợ đội ngũ thay vì đẩy trách nhiệm). Theo 9.2.3 Develop Team, PM phải cung cấp tài nguyên đúng đắn, không để đội tự xoay sở.

• Ask the team to fast-track the project and perform tasks that do not require calculations.
  ❌ Sai: Fast-track (làm song song hoặc ưu tiên nhiệm vụ khác) là kỹ thuật nén lịch trình (Schedule Compression – PMBOK 6.5.2.4), nhưng không phải hành động đầu tiên cho trở ngại này. Nó né tránh vấn đề cốt lõi, có thể gây rủi ro phụ thuộc nhiệm vụ (dependencies) và tăng chi phí, vi phạm Value Delivery trong PMBOK 7th Principle 5 (Optimize Resource Allocation).

• Meet with the IT team to evaluate how fast the software license can be renewed.
  ✅ Đúng: Như đã giải thích ở trên, đây là bước chủ động, hiệu quả và phù hợp nhất để khôi phục tài nguyên nhanh chóng. 📘

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (PMI, 2021): Domain 3: Project Resource Management (Processes 9.1-9.6); Principle 3: Focus on Value; Principle 9: Optimize Risk Responses.
• PMP Examination Content Outline 2021 (PMI, cập nhật đến 2026): Task 8.1 (Manage/Lead Project Team), Task 9.2 (Resolve Impediments).
• PMI Agile Practice Guide (2021): Nhấn mạnh Impediment Removal trong Daily Stand-ups và Scrum Events.
• Truy cập: www.pmi.org để cập nhật mới nhất.

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 câu hỏi, hãy 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ý Chất lượng (Manage Quality) và Quản lý Đội ngũ (Manage Team) trong PMP, theo PMBOK® Guide 7th Edition (cập nhật đến 2026).
Trong một cuộc họp đánh giá hàng tháng, một thành viên đội ngũ hiệu suất cao (high-performing team member) bày tỏ lo ngại về cơ chế phản hồi chất lượng (quality feedback mechanism). Họ cho biết không thể cung cấp đầu ra chất lượng cao (not able to deliver high-quality output).
📌 Vấn đề cốt lõi: Đây là tín hiệu từ nội bộ đội ngũ về quy trình chất lượng chưa hiệu quả, đòi hỏi Project Manager (PM) phải hành động đầu tiên (first) theo nguyên tắc Servant Leadership – lắng nghe, hỗ trợ đội ngũ và cải thiện quy trình. PM cần ưu tiên phân tích nguyên nhân gốc rễ (root cause analysis) thay vì hành động vội vã bên ngoài.
🛠️ Ngữ cảnh PMP: Theo PMBOK 7th Ed., PM phải engage stakeholders (team members là stakeholder nội bộ), review processes trong Manage Quality (Process 8.2), và develop high-performing teams (Domain 9: Team).

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

Discuss this with the team and review the quality process.
✅ Lý do: Đây là hành động đầu tiên và phù hợp nhất vì PM cần thảo luận trực tiếp với đội ngũ để hiểu rõ vấn đề từ góc nhìn nội bộ, sau đó xem xét lại quy trình chất lượng (review the quality process) nhằm xác định lỗ hổng (gap) trong feedback mechanism. Điều này tuân thủ PDCA cycle (Plan-Do-Check-Act) trong Quality Management và high-performing team principles (PMBOK 7th Ed., Section 9.4.2.1). Bỏ qua bước này có thể dẫn đến giải pháp sai lầm.
📘 Nguồn: PMBOK® Guide 7th Edition, Principle 5: Think Integrally; Process 8.2 Manage Quality; Agile Practice Guide (Team self-management).

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

• ❌ [SAI] Request feedback from stakeholders about the quality delivery.
  Giải thích sai: Hành động này quá sớm và hướng ngoại, bỏ qua vấn đề nội bộ từ đội ngũ. Stakeholders bên ngoài (như khách hàng) chưa được đề cập, và PM cần ưu tiên root cause từ team trước khi thu thập feedback rộng (PMBOK 7th Ed., tránh "jumping to solutions"). Có thể làm phức tạp hóa vấn đề mà không giải quyết feedback mechanism nội bộ.

• ❌ [SAI] Assign the work in consultation with the functional manager.
  Giải thích sai: Việc phân công lại công việc với functional manager không giải quyết nguyên nhân gốc (quality feedback mechanism). Đây là hành động cấu trúc lại đội ngũ (restructuring), phù hợp với tình huống thiếu kỹ năng chứ không phải quy trình chất lượng. PMBOK nhấn mạnh address process issues first (Section 9.2.3 Manage Team), không phải reorganize ngay lập tức.

• ✅ [ĐÚNG] Discuss this with the team and review the quality process.
  Giải thích đúng: Như đã nêu ở phần đáp án, đây là bước đầu tiên lý tưởng – engage team để thu thập insight, review process để cải thiện feedback loop. Hỗ trợ high-performing team duy trì động lực và chất lượng bền vững (PMBOK 7th Ed., Model 4: High-Performing Team; Principle 9: Optimize Risk Responses).

• ❌ [SAI] Assign the work based on the skill sets of team members.
  Giải thích sai: Phân công dựa trên kỹ năng là tốt cho resource allocation (Acquire Resources, Process 9.2), nhưng không phải hành động đầu tiên ở đây vì vấn đề là feedback mechanism, không phải skill gap. Thành viên này là "high-performing", nên cần cải thiện quy trình thay vì redistribute work (tránh micromanagement, theo Agile values).

🏆 Kết luận và lưu ý PMP

✅ PM phải hành động nhanh chóng nhưng có hệ thống, ưu tiên đội ngũ nội bộ để xây dựng trust và continuous improvement. Thực hành này giúp đạt Project Success Measures (PMBOK 7th Ed.).
📚 Tài liệu tham khảo chính:

• PMBOK® Guide – Seventh Edition (2021, PMI).
• Agile Practice Guide (PMI, 2017 – tích hợp trong PMBOK 7).
• PMP Exam Content Outline (2024 update, Domain 2: Team & 3: Quality).
  Hãy thực hành thêm các case tương tự để ôn thi PMP! 🚀

🧩 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ũ Dự án (Manage Project Team) trong PMP, tập trung vào kỹ năng lãnh đạo và giải quyết xung đột trong các cuộc họp đội dự án. 📊

Tình huống cụ thể: Một thành viên đội dự án thường xuyên kéo dài các chủ đề thảo luận trong họp, dẫn đến mất nhiều thời gian hơn mức cần thiết. Điều này khiến các thành viên khác cảm thấy không được tôn trọng thời gian của họ. Vấn đề cốt lõi là cân bằng giữa khuyến khích thảo luận mở (open discussion) và duy trì hiệu quả họp (meeting efficiency), tránh xung đột nội bộ. 🕒

Project manager cần hành động chủ động, công bằng, sử dụng các công cụ như ground rules (quy tắc cơ bản cho họp) để hướng dẫn hành vi, theo nguyên tắc High-Performing Team trong PMBOK 7th Edition (2021) và PMP Exam Content Outline (2024 cập nhật đến 2026). 🎯

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

Đáp án đúng: Explain to the team that open discussions are needed but remind the team to follow the ground rules.

Lý do:

• Phương án này tích cực và cân bằng, thừa nhận giá trị của thảo luận mở (open discussions) để khuyến khích sáng tạo và hợp tác – phù hợp với nguyên tắc Servant Leadership và Team Empowerment trong PMP.
• Đồng thời, nhắc nhở toàn đội tuân thủ ground rules (quy tắc họp đã thống nhất từ đầu, như giới hạn thời gian chủ đề, giữ tập trung), giúp giải quyết vấn đề mà không chỉ trích cá nhân, tránh làm tổn thương động lực đội. 🛠️
• Đây là cách phòng ngừa xung đột hiệu quả, thúc đẩy team self-regulation theo PMBOK 7th Edition, phần Manage Team Domain (People Domain). Kết quả: Giữ hiệu quả họp mà vẫn duy trì môi trường tích cực. 👍

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

• ✅ Explain to the team that open discussions are needed but remind the team to follow the ground rules.
  Giải thích đúng: Như trên, phương án này hoàn hảo vì áp dụng ground rules – công cụ chuẩn trong Plan Communications Management và Manage Team (PMBOK 7th). Nó giải quyết gốc rễ vấn đề (hành vi lệch quy tắc) một cách công bằng với toàn đội, khuyến khích tuân thủ tự giác, phù hợp Agile/Adaptive practices cập nhật 2026. 📘

• ❌ Ask this member to only discuss the current topic to achieve team efficiency.
  Giải thích sai: Phương án này chỉ trích cá nhân trực tiếp, có thể gây xung đột cá nhân và làm giảm động lực của thành viên đó (vi phạm nguyên tắc Emotional Intelligence trong People Domain). Không khuyến khích thảo luận mở, dẫn đến team dysfunction thay vì giải quyết hệ thống qua ground rules. 🚫

• ❌ Ask the team to accept the input from this particular member as their input may be useful.
  Giải thích sai: Đây là cách thiên vị, ép đội chấp nhận hành vi tiêu cực chỉ vì "có thể hữu ích", bỏ qua cảm xúc của đa số và quyền lợi thời gian của họ. Không giải quyết vấn đề gốc, có thể dẫn đến team dissatisfaction và giảm hiệu suất tổng thể – trái với Stakeholder Engagement và công bằng lãnh đạo PMP. 😞

• ❌ Allow the self-organized team to discuss the situation among themselves and come to a resolution.
  Giải thích sai: Mặc dù ủng hộ self-organizing team (Agile principle), nhưng ở đây đội đã có xung đột rõ ràng (cảm thấy không tôn trọng), nên PM phải can thiệp chủ động theo Manage Conflicts process. Để tự giải quyết có thể làm vấn đề leo thang, vi phạm trách nhiệm lãnh đạo của PM trong Project Manager's Sphere of Influence. ⚠️

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Phần People Domain (trang 77-92), nhấn mạnh ground rules trong Manage Team và High-Performing Teams.
• PMP Examination Content Outline (2024, cập nhật 2026): Task 8.2 (Manage conflict), Task 9.1 (Build team).
• Agile Practice Guide (PMI, 2017 tích hợp PMBOK 7): Nhấn mạnh ground rules cho daily stand-ups và retrospectives.
• Process Groups: A Practice Guide (PMI, 2022): Executing process group, về meeting facilitation.

Phân tích này dựa trên kiến thức PMP chuẩn mới nhất, giúp thí sinh hiểu sâu để áp dụng thực tế! 🚀 Nếu cần thêm ví dụ, 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ủ đề lập lịch trình (Develop Schedule) trong PMP, cụ thể liên quan đến quản lý dự án Agile. Một project manager đang làm dự án phát triển phần mềm cho khách hàng ngành dầu khí (oil and gas), sử dụng phương pháp Agile. Vấn đề chính là gặp khó khăn khi lập lịch trình vì dự án có nhiều yếu tố không chắc chắn (various unknowns) – đây là đặc trưng điển hình của môi trường Agile, nơi yêu cầu thay đổi thường xuyên, công nghệ mới, hoặc rủi ro cao.

🛠️ Mục tiêu câu hỏi: Xác định phương pháp lập lịch phù hợp nhất để xử lý sự không chắc chắn trong Agile, thay vì các phương pháp truyền thống (predictive). Trong Agile, lịch trình không cố định mà được phát triển lặp lại để thích ứng dần dần với thông tin mới.

📘 Kiến thức PMP cập nhật (PMBOK® Guide 7th Edition & Agile Practice Guide 2021, áp dụng đến 2026): Agile khuyến khích iterative và incremental development, nơi lịch trình được xây dựng qua các vòng lặp (iterations/sprints), giúp quản lý unknowns bằng cách học hỏi liên tục (empirical process control).

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

Đáp án đúng: Iterative scheduling
🧩 Lý do: Trong môi trường Agile với nhiều unknowns, project manager nên sử dụng iterative scheduling để phát triển lịch trình qua các vòng lặp ngắn (iterations). Phương pháp này cho phép lập kế hoạch ban đầu đơn giản, sau đó tinh chỉnh dần dựa trên feedback thực tế, giảm rủi ro từ sự không chắc chắn. Điều này phù hợp với nguyên tắc Agile: "Responding to change over following a plan" (Agile Manifesto). Không dùng lịch trình cố định upfront vì unknowns sẽ làm nó không khả thi.

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

Dưới đây là phân tích từng phương án một cách chi tiết:

• Analogous scheduling ❌
  Sai vì: Phương pháp này dựa trên dữ liệu lịch sử từ dự án tương tự (top-down estimation), phù hợp với dự án predictive có ít unknowns và dữ liệu lịch sử phong phú. Trong Agile với nhiều unknowns và dự án phần mềm mới cho oil & gas (không lặp lại), không có cơ sở tương tự đáng tin cậy, dẫn đến lịch trình không chính xác.

• Three-point scheduling ❌
  Sai vì: Đây là kỹ thuật sử dụng ba ước lượng (optimistic, most likely, pessimistic) để tính trung bình (PERT), giúp xử lý uncertainties ở mức độ nhất định. Tuy nhiên, nó vẫn là phương pháp predictive, yêu cầu ước lượng upfront chính xác – không phù hợp với Agile nơi unknowns thay đổi động và cần học hỏi thực tế qua iterations, chứ không phải dự đoán thống kê.

• Iterative scheduling ✅
  Đúng vì: Như đã giải thích ở trên, phương pháp này xây dựng lịch trình lặp lại (iterative planning), chia nhỏ thành sprints/iterations, cập nhật liên tục dựa trên tiến độ thực tế. Hoàn hảo cho Agile với unknowns cao, hỗ trợ adaptive planning theo PMBOK 7th (Domain: Uncertainty).

• Parametric scheduling ❌
  Sai vì: Phương pháp này sử dụng mô hình toán học và tham số (parameters) như kích thước code, giờ lao động để tính lịch trình tự động. Nó đòi hỏi dữ liệu định lượng chính xác upfront và phù hợp dự án repetitive (như construction), không hiệu quả với unknowns lớn trong Agile phần mềm, nơi tham số thay đổi thường xuyên.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021): Section 4.5 Develop Schedule (Predictive & Adaptive Approaches); Agile Practice Guide – Iterative & Incremental Scheduling (p. 44-46).
• PMI Agile Certified Practitioner (PMI-ACP) Handbook (cập nhật 2023): Nhấn mạnh iterative planning trong Agile với high uncertainty.
• Process Groups: A Practice Guide (PMI, 2022): Hybrid/Agile scheduling methods.

🛠️ Lời khuyên PMP: Trong kỳ thi PMP mới (2026), ưu tiên Agile/Adaptive cho câu hỏi có "agile approach" + "unknowns". Thực hành qua PMI.org mock exams!

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

Câu hỏi này thuộc chủ đề chuyển đổi sang Agile trong quản lý dự án, theo PMBOK® Guide 7th Edition và Agile Practice Guide (cập nhật mới nhất đến 2026 từ PMI). 📘
Một công ty mới áp dụng Agile cho các dự án đổi mới (innovation projects). Project manager (PM) gặp vấn đề: một số thành viên đội ngũ coi các Agile ceremonies (như Daily Stand-up, Sprint Planning, Retrospective...) là không cần thiết.
🛠️ Vấn đề cốt lõi: Đội ngũ thiếu sự hiểu biết hoặc cam kết với Agile practices, dẫn đến kháng cự. Câu hỏi yêu cầu hành động PM nên làm TRƯỚC KHI BẮT ĐẦU dự án để tránh vấn đề này. Điều này liên quan đến Develop Team (trong Agile: Servant Leadership, Coaching) và Stakeholder Engagement để xây dựng sự đồng thuận từ đầu.

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

Đáp án đúng: Prepared an inception deck and clearly explained the purpose of agile ceremonies and their benefits to the project.

Lý do: 🏆 Trong Agile (đặc biệt Scrum/Kanban hybrid cho innovation projects), inception deck (hay Vision Deck/Kick-off Deck) là công cụ chuẩn để giáo dục và align đội ngũ ngay từ đầu. PM đóng vai trò Servant Leader phải giải thích rõ ràng mục đích và lợi ích của ceremonies (ví dụ: Daily Scrum giúp phát hiện impediments sớm, Retrospective cải thiện liên tục). Điều này xây dựng shared understanding và commitment, tránh kháng cự sau này. Theo Agile Practice Guide (PMI, 2021-2026), bước "Initiate" yêu cầu team education trước sprint đầu tiên. Đây là proactive approach, phù hợp nguyên tắc "People over Processes" trong Agile Manifesto.

📋 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 bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên PMBOK® 7th (Principle 4: Build a Team, Principle 10: Lead to Value) và Scrum Guide 2025 (Ken Schwaber & Jeff Sutherland).

• ✅ Prepared an inception deck and clearly explained the purpose of agile ceremonies and their benefits to the project.
  Đúng vì: Như đã giải thích ở trên, đây là hành động chủ động giáo dục đội ngũ (team enablement), giúp mọi người hiểu value của ceremonies (ví dụ: tăng transparency, faster feedback). PM tự chịu trách nhiệm, không đẩy cho người khác. Nguồn: Agile Practice Guide - Section 3.2 "Lifecycle Phases" (Inception/Start-up); PMBOK® 7th - Hybrid Approaches. 🛡️ Proactive & hiệu quả nhất!

• ❌ Discussed with the project sponsor about convincing the team to adopt the agile ceremonies as part of their routine.
  Sai vì: Sponsor chỉ hỗ trợ strategic alignment (ngân sách, ưu tiên), không phải convince hoặc enforce ceremonies – điều này vi phạm Servant Leadership (PM phải tự coach team). Ép buộc từ sponsor tạo resistance lớn hơn, không khuyến khích self-organizing team trong Agile. Nguồn: PMBOK® 7th - Principle 9: Optimize Risk Responses (tránh escalate không cần thiết).

• ❌ Discussed with the product owner and requested assistance by requiring the adoption of agile ceremonies.
  Sai vì: Product Owner (PO) chịu trách nhiệm product backlog & value delivery, không phải enforce ceremonies (đó là trách nhiệm Scrum Master/PM). "Requiring" tạo cảm giác ép buộc, trái với empowerment và psychological safety trong Agile. PM phải tự handle team dynamics. Nguồn: Scrum Guide 2025 - Roles (PO không quản lý process).

• ❌ Conducted a survey to determine if the team was willing to adopt agile ceremonies on the current project.
  Sai vì: Survey chỉ đo willingness, không xây dựng understanding hay commitment. Agile yêu cầu full adoption của framework (không customize ceremonies cơ bản), và survey có thể dẫn đến partial adoption hoặc bỏ qua, vi phạm "Agree to Scrum as defined" (Scrum Guide). Với công ty mới adopt Agile, cần training, không phải vote. Nguồn: Agile Manifesto - "Responding to Change over Following a Plan" nhưng vẫn cần discipline.

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

✅ Hành động đúng nhấn mạnh education & communication đầu dự án để prevent issues. Trong thực tế 2026, với hybrid Agile phổ biến, PM nên dùng tools như Miro/Jamboard cho inception deck. Tài liệu tham khảo chính:

• 📘 PMBOK® Guide 7th Edition (2021, updates 2025) - Chapters 4 & 6 (Team & Stakeholders).
• 📘 Agile Practice Guide (PMI, 2021-2026) - Life Cycles.
• 📘 Scrum Guide (2025) - Scrum Events.
  Áp dụng ngay để dự án innovation thành công! 🚀

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

Câu hỏi mô tả tình huống một công ty thường xuyên outsource (thuê ngoài) nguồn lực cho các hoạt động cốt lõi của dự án. Bất ngờ xảy ra một rủi ro không lường trước, buộc tất cả thành viên đội ngũ phải làm việc từ xa (remote), bao gồm cả những người từ nhà cung cấp outsourced. Thách thức chính: Làm thế nào để project manager (PM) giải quyết vấn đề này nhằm đảm bảo các nhà cung cấp outsourced vẫn giao hàng đúng hạn và chất lượng?

🛠️ Phân tích ngữ cảnh PMP (theo PMBOK 7th Edition & cập nhật đến 2026): Trong môi trường dự án hiện đại, outsourcing là phổ biến (Procurement Management Performance Domain). Làm việc remote đột ngột (do rủi ro như đại dịch hoặc sự cố) ảnh hưởng đến communication, coordination và resource management (Team & Stakeholders Performance Domains). PM cần tập trung vào adaptive response để duy trì delivery, thay vì chỉ review kế hoạch cũ hoặc tăng ngân sách.

✅ Đáp án đúng

Develop a new strategy for communication and management of resources.

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

• Tình huống là thay đổi đột ngột sang remote work, làm gián đoạn cách thức giao tiếp và quản lý nguồn lực outsourced. PM cần phát triển chiến lược mới (new strategy) tập trung vào communication (như công cụ Zoom, Slack, agile daily stand-ups) và management of resources (tracking progress qua tools như Jira, MS Teams).
• Điều này phù hợp với PMBOK 7th Edition (2021, cập nhật 2026): Trong Team Performance Domain (Manage Team) và Stakeholders Performance Domain (Engage Stakeholders), PM phải adapt strategies để đảm bảo vendors deliver. Không chỉ review mà cần action proactive để duy trì hiệu suất outsourcing (Procurement Performance Domain).

🔍 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. Tôi đánh dấu ✅ đúng và ❌ sai, kèm lý do dựa trên nguyên tắc PMP:

• ✅ Develop a new strategy for communication and management of resources.
  Đúng vì: Chiến lược mới trực tiếp giải quyết thách thức remote work, đảm bảo vendors outsourced vẫn collaborate hiệu quả. Đây là best practice trong Universal Project Management Principles (PMBOK 7th: Optimize Risk Responses & Engage Stakeholders), giúp duy trì delivery mà không cần thay đổi hợp đồng lớn.

• ❌ Review the risk management plan for the mitigation activities.
  Sai vì: Rủi ro đã xảy ra (unforeseen risk), nên không chỉ review mitigation (trong Uncertainty Performance Domain) mà cần immediate response/action. Review kế hoạch cũ không đảm bảo vendors deliver ngay, chỉ là bước đầu chứ không phải giải pháp chính (PMBOK 7th: Risk responses phải adaptive sau sự cố).

• ❌ Review the coordination and communication costs with the supplier.
  Sai vì: Tập trung vào chi phí (Cost Performance Domain) không giải quyết vấn đề cốt lõi là delivery của vendors trong remote. Review chi phí có thể cần sau, nhưng không phải hành động đầu tiên để "assure deliver" (PMBOK 7th: Procurement Management ưu tiên performance trước cost review).

• ❌ Submit a change request to increase the contingency budget.
  Sai vì: Contingency budget dành cho rủi ro đã biết (Reserve Management), chưa chắc đã cần tăng ngay mà chưa đánh giá tác động. Điều này thuộc Change Control Process (Integration Performance Domain), nhưng không trực tiếp address communication/resource issues với vendors (PMBOK 7th: Tránh change không cần thiết, ưu tiên strategy trước budget).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, PMI - cập nhật Hybrid/Agile đến 2026): Team Performance Domain (Section 3.3), Procurement Performance Domain (Section 3.11), Uncertainty Performance Domain (Section 4.2).
• PMI Agile Practice Guide (2021): Adaptive communication strategies cho remote teams.
• The Standard for Project Management (2021): Principle 7 (Optimize Risk Responses) & Principle 12 (Navigate Complexity).
• Nguồn trực tuyến: PMI.org (PMP Exam Content Outline 2024-2026, nhấn mạnh remote/outsourced management post-COVID).

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 dự án đang ở iteration thứ 2 trong tổng số 6 iteration (gợi ý đây là dự án theo cách tiếp cận lặp lại hoặc Agile/hybrid), đội ngũ phát hiện ra rằng một key deliverable (sản phẩm chính) sẽ phụ thuộc vào việc mua sắm một thiết bị mới. Điều này tạo ra một rủi ro tiềm ẩn (risk) vì việc thu mua có thể gây chậm trễ, chi phí bất ngờ hoặc cần phê duyệt từ cấp cao hơn.

Câu hỏi yêu cầu: Project Manager (PM) nên làm gì ngay lúc này để xử lý tình huống? Đây là tình huống kiểm tra kiến thức về quản lý rủi ro (Risk Management) trong PMP, nhấn mạnh vào việc nhận diện và xử lý rủi ro sớm trong dự án iterative, tránh để nó trở thành vấn đề (issue). Theo PMBOK® Guide 7th Edition (2021) và cập nhật đến 2026 (PMI Agile Practice Guide), PM phải chủ động đăng ký rủi ro và escalate nếu vượt quyền hạn, đặc biệt khi liên quan đến acquisition (cần budget hoặc procurement approval).

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

Đáp án đúng: Register a risk and escalate it to the project sponsor.

Lý do:

• Đây là rủi ro mới được nhận diện (new risk identification) vì key deliverable phụ thuộc vào thiết bị chưa có. PM phải đăng ký rủi ro vào Risk Register (theo process Identify Risks và Manage Risks trong PMBOK 7th).
• Việc escalate lên project sponsor là đúng vì acquisition thiết bị mới thường cần phê duyệt ngân sách, hợp đồng hoặc quyết định chiến lược từ sponsor (PM không tự quyết nếu vượt quyền). Trong iterative project, escalate sớm giúp điều chỉnh sprint/iteration kịp thời, tránh tích tụ debt.
• 🛠️ Điều này phù hợp nguyên tắc proactive risk management và escalation threshold (PMBOK 7th, Section 4.6 & Agile Practice Guide).

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

• ❌ [SAI] Invite the stakeholders to discuss prioritization of a new deliverable.
  Lý do sai: Đây không phải là deliverable mới (new deliverable), mà là key deliverable hiện có bị phụ thuộc thiết bị. Việc mời stakeholders thảo luận ưu tiên là quá sớm và không tập trung, có thể gây confuse backlog hoặc sprint planning. Thay vào đó, PM phải xử lý rủi ro trước (risk first), không phải stakeholder meeting ngay lập tức (PMBOK 7th, Stakeholder Engagement quá muộn ở giai đoạn này).

• ❌ [SAI] Detail the reason for the deliverable delay in the status report.
  Lý do sai: Chưa có delay thực tế xảy ra (chỉ "will depend" – phụ thuộc tương lai), nên không nên báo cáo như delay đã xảy ra. Điều này vi phạm Manage Communications (chỉ report facts, không speculate). Risk phải được đăng ký trước khi report status để tránh báo cáo sai lệch (PMBOK 7th, Section 4.7 & Iteration Review principles).

• ✅ [ĐÚNG] Register a risk and escalate it to the project sponsor.
  Lý do đúng: Như đã giải thích ở trên, đây là hành động chuẩn xác và kịp thời theo Risk Management Framework. Đăng ký risk giúp track/mitigate, escalate đảm bảo sponsor hỗ trợ (budget/procurement). Hoàn hảo cho iterative project để tránh iteration slip (PMBOK 7th, Process Groups: Executing & Monitoring).

• ❌ [SAI] Include the responsibility for acquisition with the core team.
  Lý do sai: Core team (development team) không chịu trách nhiệm acquisition thiết bị mới, vì đây thường thuộc procurement management hoặc cần sponsor approve (không giao trách nhiệm ngoài RACI matrix). PM phải escalate thay vì assign sai vai trò, tránh overload team và vi phạm team accountability trong Agile (PMBOK 7th, Section 4.5 & Agile Practice Guide: Servant Leadership).

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Sections 4.6 (Uncertainty/Risk), 4.7 (Measurement), 9.3 (Procure Resources). PMI updates đến 2026 nhấn mạnh hybrid/Agile risk handling.
• Agile Practice Guide (2017, aligned 7th Ed.): Risk in Iterations (p. 44-46), Escalation in Servant Leader role.
• PMP Exam Content Outline (2021+): Domain III: Business Environment (15%), Domain IV: People (42%) – Risk proactive.
• Nguồn chính thức: PMI.org – Risk Register Template & Escalation Guidelines.

🛠️ Kết luận: Câu hỏi kiểm tra kỹ năng Risk-First Mindset của PM trong dự án iterative. Luôn identify-escalate trước khi act!

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

Câu hỏi này thuộc lĩnh vực Quản lý Chi phí (Project Cost Management) và Quản lý Thay đổi Tích hợp (Integrated Change Control) trong PMP, theo PMBOK Guide 7th Edition (cập nhật đến 2026, nhấn mạnh vào nguyên tắc quản lý giá trị và quy trình hybrid).

Tình huống cụ thể:
Một Project Manager (PM) đang làm việc trong tổ chức matrix (ma trận), quản lý dự án phát triển phần mềm nội bộ nhằm giảm xung đột trong hệ thống theo dõi nội bộ của công ty. Trong quá trình phát triển, có thay đổi bất ngờ từ quy định kế toán chính phủ (government accounting requirements). Nhóm phát triển đã xử lý thay đổi này không tốn thêm chi phí, nhưng PM nhận thấy chi phí kiểm thử (testing costs) đang vượt ngân sách kiểm thử.

Vấn đề cốt lõi: Đây là thay đổi phạm vi (scope change) do yếu tố bên ngoài (quy định pháp lý), dẫn đến chi phí kiểm thử tăng. PM cần hành động đúng quy trình để xử lý vượt ngân sách mà không vi phạm baseline chi phí (cost baseline). Trong tổ chức matrix, PM có quyền hạn hạn chế, nên phải tuân thủ quy trình quản trị (governance process) để phê duyệt thay đổi.

📘 Nguồn tham khảo: PMBOK® Guide 7th Edition (2021, cập nhật 2026 qua PMI Standards+): Domain 4 - Measurement (Cost), Principle 9 - Optimize Risk Responses; PMBOK 6th Edition Process 7.5 Control Costs & 4.6 Perform Integrated Change Control.

✅ Đáp án đúng: Submit a change request to the cost baseline through the governance process to fund the additional testing.

Lý do lựa chọn:
Thay đổi quy định chính phủ là thay đổi phạm vi ngoài dự kiến, làm tăng chi phí kiểm thử (một phần của baseline chi phí). Theo quy trình PMP, bất kỳ thay đổi nào ảnh hưởng đến baseline phải được phê duyệt qua Change Control Board (CCB) hoặc governance process trước khi phân bổ nguồn lực. Việc submit change request là bước đầu tiên đúng đắn, đảm bảo tính minh bạch, kiểm soát rủi ro và tuân thủ nguyên tắc stewardship (quản lý bền vững). Không tự ý sử dụng quỹ dự phòng hoặc điều chỉnh mà không phê duyệt sẽ vi phạm quy trình.

🛠️ Hành động lý tưởng: PM thu thập dữ liệu (toàn bộ tác động), submit form change request → CCB phê duyệt → Cập nhật baseline nếu approved.

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

• Ask the project sponsor to allocate funds from the contingency reserve to fund the additional testing.
  ❌ Sai: Contingency reserve chỉ dành cho rủi ro đã biết (known risks) đã được xác định trong Risk Register và Management Reserve cho unknown risks. Thay đổi quy định chính phủ là scope creep/external change, không phải rủi ro dự phòng. PM không được "xin" sponsor tự ý phân bổ vì vi phạm Control Costs process và nguyên tắc governance. Sponsor chỉ phê duyệt change request chính thức.

• Conduct a cost-benefit analysis to determine if the funds can be reallocated from the development team.
  ❌ Sai: Việc phân tích cost-benefit là công cụ tốt (Earned Value Analysis hoặc To-Complete Performance Index), nhưng không thay thế quy trình change control. Reallocate từ dev team (vốn không tốn thêm) có thể khả thi, nhưng phải qua integrated change control để tránh làm lệch baseline. Làm vậy tự ý sẽ gây thiếu minh bạch và không tuân thủ PMBOK Principle 11 - Ensure Value.

• Submit a change request to the cost baseline through the governance process to fund the additional testing.
  ✅ Đúng: Như đã giải thích ở trên. Đây là best practice theo Perform Integrated Change Control (Process 4.6), áp dụng cho mọi thay đổi baseline (scope, cost, schedule). Governance process đảm bảo phê duyệt đa bên (stakeholders, CCB), phù hợp tổ chức matrix.

• Update the basis of estimates and the cost management plan to track the additional funding required for testing.
  ❌ Sai: Không được cập nhật plan/baseline trước khi có phê duyệt chính thức. Basis of estimates và Cost Management Plan chỉ cập nhật sau khi change request được approved (trong Direct & Manage Project Work hoặc Monitor & Control). Làm vậy là "chữa cháy" tự ý, vi phạm nguyên tắc predictive/agile tailoring và có thể dẫn đến audit failure.

🧩 Kết luận & Lời khuyên PMP: Trong thực tế, PM nên sử dụng Issue Log để ghi nhận vấn đề ngay lập tức, sau đó submit change request với dữ liệu đầy đủ (impact analysis). Điều này củng cố leadership và teamwork theo 12 Principles PMBOK 7th. Thực hành qua PMI mock exams để nắm vững! 🚀