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

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

Câu hỏi này thuộc chủ đề quản lý đội ngũ và xử lý xung đột trong môi trường dự án hybrid (kết hợp giữa dự án truyền thống và Agile, sử dụng sprints). Đội ngũ đang phát triển phiên bản nâng cấp phần mềm cho product owner, nhưng đồng thời phải hỗ trợ sản phẩm hiện tại và khách hàng. Trong 3 sprint gần nhất, đội phải tạm dừng công việc dự án để ưu tiên các vấn đề hỗ trợ lớn từ product owner. Điều này dẫn đến thay đổi kế hoạch liên tục, khiến tester gặp khó khăn và xảy ra các bùng nổ cảm xúc (emotional outbursts).

📌 Vấn đề cốt lõi: Đội ngũ thiếu ổn định, ảnh hưởng đến tinh thần và hiệu suất. Project manager (PM) cần hành động để cân bằng công việc dự án và hỗ trợ, đồng thời xử lý cảm xúc đội ngũ theo nguyên tắc Agile (servant leadership, team self-management) trong PMBOK 7th Edition (2021, cập nhật đến 2026 qua các hướng dẫn Agile Hybrid).

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

Schedule a session with the team to discuss the issues and work with them to define a plan to manage the sprints going forward

🛠️ Lý do chọn đáp án này (theo PMP mới nhất):
PM nên tổ chức buổi họp với đội ngũ để thảo luận vấn đề và hợp tác xây dựng kế hoạch quản lý sprints tương lai. Điều này thể hiện servant leadership (lãnh đạo phục vụ), khuyến khích team empowerment (trao quyền tự quản), giúp đội tự giải quyết xung đột và cải thiện quy trình (retrospective trong Agile). Trong hybrid project, PM tập trung vào value delivery và team performance, tránh can thiệp từ bên ngoài. Hành động này giải quyết gốc rễ (thay đổi sprint và cảm xúc), tăng tính bền vững mà không loại bỏ trách nhiệm hỗ trợ.

📋 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. Tôi đánh dấu ✅ cho đúng, ❌ cho sai, kèm lý do dựa trên PMBOK 7th Edition, Agile Practice Guide (PMI, 2021) và Scrum Guide (2025 update).

• ✅ Schedule a session with the team to discuss the issues and work with them to define a plan to manage the sprints going forward
  🟢 Đúng vì: Khuyến khích team collaboration và continuous improvement (Inspect & Adapt). PM làm facilitator, giúp đội định nghĩa quy trình mới (ví dụ: capacity planning, support buffer). Phù hợp nguyên tắc 12 Agile Principles (build projects around motivated individuals) và Project Team Enablement trong PMBOK 7.

• ❌ Schedule a session with the product owner to explain that no support items can be taken into the sprints going forward
  🔴 Sai vì: Đây là cách đơn phương từ chối trách nhiệm hỗ trợ, vi phạm stakeholder engagement và value delivery cho product owner (người chịu trách nhiệm sản phẩm). Trong hybrid, PM phải cân bằng portfolio, không loại bỏ support mà cần negotiate (như dedicated support team). Không giải quyết cảm xúc đội ngũ.

• ❌ Ask human resources (HR) to send the team members to a change management workshop
  🔴 Sai vì: Đẩy trách nhiệm cho HR thay vì PM trực tiếp xử lý (PM là change agent nội bộ). Change management workshop là công cụ hỗ trợ, nhưng không phải giải pháp đầu tiên cho vấn đề sprint cụ thể. PMBOK 7 nhấn mạnh team coaching nội bộ trước khi can thiệp bên ngoài, tránh làm đội cảm thấy bị "trừng phạt".

• ❌ Request a replacement for those team members who are unhappy with this way of working
  🔴 Sai vì: Thay thế thành viên là biện pháp cực đoan cuối cùng (high-risk HR process), không khuyến khích retain talent và address root cause. Vi phạm Psychological Safety (Project Team domain, PMBOK 7) và Agile Manifesto (motivated individuals). PM phải build high-performing team qua hỗ trợ, không sa thải vì bất mãn tạm thời.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (PMI, 2021): Chương 4 (Team), Principle 5 (Team & Stakeholders); Hybrid models ở Appendix.
• Agile Practice Guide (PMI, 2021): Phần Organizational Change Management, Sprint Planning & Retrospectives.
• Scrum Guide (Scrum.org, 2025 update): Scrum Master role (facilitate events), Developer self-management.
• PMI Standards đến 2026: Hybrid Agile Delivery (PMI.org resources), nhấn mạnh servant leadership trong volatile environments.

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 xoay quanh quy trình quản lý thay đổi tích hợp (Integrated Change Control) trong PMP. Một project manager làm việc tại công ty sản xuất lớn, đa lĩnh vực. Đội ngũ dự án thường tham gia vào các change requests (yêu cầu thay đổi). Gần đây, Change Control Board (CCB) đã hoãn (deferred) một số yêu cầu này, và project manager muốn giao tiếp (communicate) các yêu cầu bị hoãn đó đến stakeholders. Câu hỏi yêu cầu xác định tài liệu nào phù hợp để project manager sử dụng cho việc giao tiếp này.
📘 Nguồn tham khảo: PMBOK® Guide 7th Edition (2021), Process 4.6: Perform Integrated Change Control; và PMBOK® Guide 6th Edition, 4.6.2.3 – Change Log là công cụ chính để theo dõi và báo cáo trạng thái thay đổi (cập nhật đến 2026, không thay đổi lớn trong khái niệm này).

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

Change log là tài liệu đúng nhất!
🛠️ Lý do: Change log là sổ ghi chép toàn bộ các change requests, bao gồm chi tiết về trạng thái (approved, rejected, deferred), lý do quyết định từ CCB, và các tác động liên quan. Project manager sử dụng nó để giao tiếp minh bạch với stakeholders về các thay đổi bị hoãn, đảm bảo tính minh bạch và traceability trong quy trình quản lý thay đổi. Điều này phù hợp với nguyên tắc Value Delivery System trong PMBOK 7th, nơi logs hỗ trợ stakeholder engagement.

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

• ❌ Risk log
  Sai! Risk log dùng để ghi nhận, theo dõi và quản lý các rủi ro tiềm ẩn (risks) có thể ảnh hưởng đến dự án, không liên quan đến change requests hay quyết định từ CCB. Nó không phải công cụ giao tiếp thay đổi.

• ❌ Backlog
  Sai! Backlog (thường là Product Backlog hoặc Sprint Backlog trong Agile) là danh sách các tính năng, yêu cầu hoặc công việc còn lại cần hoàn thành, chủ yếu dùng trong phương pháp Agile/Scrum. Nó không ghi nhận trạng thái change requests bị deferred từ CCB.

• ✅ Change log
  Đúng! Như đã giải thích, đây là tài liệu chuẩn để ghi chép đầy đủ lịch sử thay đổi, bao gồm các request bị deferred, giúp project manager giao tiếp chính xác và kịp thời với stakeholders. PMBOK yêu cầu cập nhật change log sau mỗi quyết định của CCB.

• ❌ Issue log
  Sai! Issue log dùng để theo dõi các vấn đề (issues) đã xảy ra và đang diễn ra, cần giải quyết ngay (như conflict, delay). Nó không dùng cho change requests hay quyết định hoãn từ CCB, mà tập trung vào vấn đề thực tế chứ không phải đề xuất thay đổi.

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

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 7th Edition và Agile Practice Guide cập nhật đến 2026). Tình huống mô tả:
Một Project Manager (PM) được giao vai trò servant leader (lãnh đạo phục vụ – nguyên tắc cốt lõi của Agile) cho một dự án đang diễn ra, dự án này lịch sử có nhiều vấn đề bất ngờ (historical unexpected problems). Stakeholder chính (chủ yếu là chủ dự án hoặc nhà tài trợ) do dự tiếp tục các sprint còn lại, mặc dù hiện tại không có vấn đề mở (no open issues) và không có dấu hiệu rủi ro (no indications of risks).

🛠️ Vấn đề cốt lõi: PM cần xử lý sự do dự của stakeholder bằng cách xây dựng lòng tin, tăng tính minh bạch và thích ứng nhanh chóng, phù hợp với nguyên tắc Agile: Inspect and Adapt (Kiểm tra và Thích ứng). Đây không phải vấn đề rủi ro lớn mà là vấn đề tâm lý/niềm tin từ lịch sử dự án, đòi hỏi cách tiếp cận lặp lại ngắn hạn để chứng minh tiến độ.

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

Đáp án đúng: Implement short cycles for inspection and provide feedback

Lý do chi tiết (theo PMP/Agile mới nhất):

• Trong môi trường Agile/Scrum, servant leader tập trung hỗ trợ team và stakeholder thông qua chu kỳ ngắn (short cycles) như Sprint ngắn (1-2 tuần), Daily Stand-up, Sprint Review và Retrospective. Điều này cho phép kiểm tra thường xuyên (inspection) và phản hồi nhanh (feedback), giúp stakeholder thấy tiến độ thực tế, giảm do dự.
• PMBOK 7th Edition (Principle 9: Optimize Risk Responses) và Agile Practice Guide nhấn mạnh iterative development để xử lý uncertainty từ lịch sử dự án. Không cần tạo rủi ro mới hay tăng reserve, mà tăng transparency qua feedback loop.
• Điều này phù hợp Servant Leadership (hỗ trợ stakeholder vượt qua trở ngại cảm xúc). 📘 Nguồn: PMBOK 7th Ed. (Section 4.6 Agile Hybrids), Agile Practice Guide (p. 45-47), Scrum Guide 2020 (Sprint Events).

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên 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à Agile principles (cập nhật 2026), tập trung vào tính phù hợp với tình huống không có rủi ro thực tế mà chỉ là do dự từ lịch sử.

• ❌ Create a new risk entry to identify the stakeholder as a detractor
  Phân tích sai: Phương án này không phù hợp vì stakeholder không phải rủi ro (no open issues/risks). Đánh dấu stakeholder là "detractor" (người phản đối) sẽ làm giảm lòng tin, vi phạm nguyên tắc Stakeholder Engagement (PMBOK 7th, Principle 11). Servant leader phải hỗ trợ, không "criminalize" stakeholder. Đây là cách tiếp cận truyền thống (Predictive), không Agile. 🛑 Rủi ro: Tạo xung đột không cần thiết.

• ❌ Increase the management reserves to convert the known-unknowns
  Phân tích sai: Management reserves dành cho unknown-unknowns (rủi ro chưa biết), không phải known-unknowns (rủi ro đã biết). Tình huống không có rủi ro, chỉ do dự chủ quan, nên tăng reserve là lãng phí và không giải quyết gốc rễ (stakeholder hesitation). PMBOK 7th (Section 7.4.3.2) quy định reserves chỉ dùng cho executive-level unknowns, không áp dụng ở đây. ❌ Không liên quan đến Agile cycles.

• ❌ Increase the contingency reserves to cover unknown-unknowns
  Phân tích sai: Contingency reserves dành cho known-unknowns (rủi ro đã xác định trong Risk Register), còn unknown-unknowns dùng Management reserves. Dù có lịch sử vấn đề, hiện tại no indications of risks, nên tăng reserve là phản ứng thái quá (overkill). PMBOK 7th (Principle 9 & Quantitative Risk Analysis) nhấn mạnh chỉ tăng reserve khi có dữ liệu rủi ro thực tế, không phải dự đoán cảm tính. 🛑 Không xây dựng niềm tin với stakeholder.

• ✅ Implement short cycles for inspection and provide feedback
  Phân tích đúng (như đã giải thích ở trên): Đây là cách tiếp cận tối ưu trong Agile, sử dụng short sprints/iterations để inspect (Sprint Review) và feedback (Retrospective), giúp stakeholder thấy giá trị nhanh chóng. Hoàn toàn phù hợp servant leader và dự án có sprints. 📘 Nguồn: Scrum Guide (Sprint Goal & Events), Agile Practice Guide (Iterative Delivery, p. 52).

🏆 Kết luận và lời khuyên PMP

Phương án đúng nhấn mạnh Agile mindset: Thay vì "chữa cháy" bằng rủi ro/reserve, hãy tăng tính thích ứng và minh bạch. Servant leader thành công bằng cách empower team và stakeholder qua feedback loops. Để ôn tập, hãy thực hành PMP Exam Content Outline 2021+ (Domain IV: People, 42%). Nếu áp dụng thực tế, bắt đầu với 1-week sprints để demo progress! 🚀

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

Câu hỏi tập trung vào vai trò của Project Manager (PM) trong một dự án triển khai các giai đoạn mới trong quy trình sản xuất của ngành công nghiệp được quy định (regulated industry), chẳng hạn như dược phẩm, thực phẩm hoặc hàng không, nơi các yêu cầu tuân thủ pháp lý (compliance requirements) rất nghiêm ngặt để tránh rủi ro pháp lý, phạt tiền hoặc gián đoạn sản xuất. PM cần xác định (determine) và giải quyết (address) các yêu cầu tuân thủ này. Câu hỏi yêu cầu chọn hai bên liên quan (stakeholders) có thể hỗ trợ PM trong việc này. Đây là chủ đề liên quan đến quản lý bên liên quan (Stakeholder Management) và quản lý rủi ro (Risk Management) trong PMP, theo PMBOK® Guide 7th Edition (và cập nhật đến 2024-2026 qua PMI Standards).

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

Hai đáp án đúng là: Risk steering committee và Functional managers.
🛠️ Lý do:

• Trong ngành regulated, compliance là một dạng rủi ro lớn (compliance risk), và Risk steering committee chịu trách nhiệm giám sát, xác định rủi ro liên quan đến quy định pháp lý, giúp PM lập kế hoạch giảm thiểu.
• Functional managers (quản lý chức năng) là các chuyên gia nội bộ về quy trình sản xuất cụ thể (như chất lượng, an toàn), họ nắm rõ các tiêu chuẩn tuân thủ hàng ngày và hỗ trợ PM tích hợp vào dự án.
  Điều này phù hợp với Process 13.3 Manage Stakeholder Engagement và Domain 4: Risk Management trong PMP Exam Content Outline 2021 (cập nhật 2024), nhấn mạnh vai trò của các bên liên quan chuyên môn trong việc xử lý compliance.

📝 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, 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 mới nhất:

• Risk steering committee ✅ Đúng
  🧩 Uỷ ban chỉ đạo rủi ro (Risk steering committee) chuyên giám sát các rủi ro cấp cao, bao gồm rủi ro tuân thủ pháp lý trong ngành regulated. Họ giúp PM xác định các yêu cầu compliance sớm qua phân tích rủi ro và đề xuất biện pháp khắc phục, theo PMBOK® 7th Ed., Principle 7: Optimize Risk Responses.

• Chief executive officer ❌ Sai
  🚫 CEO (Giám đốc điều hành) tập trung vào chiến lược kinh doanh tổng thể và phê duyệt ngân sách cao cấp, không tham gia chi tiết vào việc xác định hoặc giải quyết compliance cụ thể của dự án sản xuất. Họ là high-power, low-interest stakeholder theo Power/Interest Grid, không phù hợp hỗ trợ trực tiếp.

• Functional managers ✅ Đúng
  🛠️ Quản lý chức năng cung cấp kiến thức chuyên sâu về quy trình sản xuất và các quy định ngành (ví dụ: FDA, ISO standards). Họ hỗ trợ PM tích hợp compliance vào thiết kế giai đoạn mới, theo Resource Management (Process 9.2 & 9.3) trong PMBOK® 7th Ed., nơi họ là nguồn lực chính cho dự án matrix organization.

• Board of directors ❌ Sai
  🚫 Hội đồng quản trị giám sát định hướng chiến lược dài hạn và trách nhiệm tài chính, không đi sâu vào chi tiết kỹ thuật compliance của dự án. Họ chỉ can thiệp ở mức phê duyệt cao cấp, không giúp "determine and address" trực tiếp theo Stakeholder Engagement Assessment Matrix.

• Advisory team panel ❌ Sai
  🚫 Nhóm cố vấn (Advisory team panel) có thể đưa ra lời khuyên chung về xu hướng ngành, nhưng không có thẩm quyền hoặc chuyên môn cụ thể để xác định và giải quyết compliance regulated (thường cần chuyên gia nội bộ hoặc cơ quan quản lý). Họ là supportive stakeholder nhưng không phải lựa chọn ưu tiên trong ngữ cảnh này.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, cập nhật PMI 2024): Chương 4 (Stakeholder Management), Principle 12 (Stakeholder Engagement).
• PMP Examination Content Outline (2021, hiệu lực đến 2026): Domain 3: Business Environment (Task 6: Evaluate & Address External Factors như Compliance); Domain 4: Risk.
• PMI Standards+ (PMI.org, cập nhật 2025): The Standard for Risk Management và The Standard for Project Governance.
• Gợi ý thực hành: Practice questions từ PMI Authorized Training Partners hoặc Rita Mulcahy's PMP Exam Prep (phiên bản 12th Ed., 2024).

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 chủ đề quản lý dự án Agile trong PMP (Project Management Professional), tập trung vào kỹ năng giám sát và kiểm soát dự án (Monitor and Control Project Work) theo PMBOK Guide 7th Edition và Agile Practice Guide (cập nhật đến 2026).

🛠️ Tình huống cụ thể:

• Một Project Manager (PM) Agile mới đang họp team và phát hiện khách hàng phàn nàn nhiều về sự ổn định dự án (project stability) và các vấn đề quan trọng khác (critical issues).
• Một thành viên team cho rằng deliverables (sản phẩm bàn giao) do nhân viên có kinh nghiệm phát triển và họ đã xác nhận dự án ổn định.
• Vấn đề cốt lõi: Có sự khác biệt giữa nhận thức của team (ổn định) và phản hồi thực tế từ khách hàng (không ổn định). PM cần hành động chủ động, tập trung vào nguyên nhân gốc rễ để đảm bảo giá trị cho khách hàng, phù hợp với nguyên tắc Agile: Customer Collaboration over Contract Negotiation và Responding to Change over Following a Plan.

📈 Mục tiêu câu hỏi: Kiểm tra khả năng PM Agile xử lý khiếu nại khách hàng bằng cách phân tích nguyên nhân thay vì chỉ ghi nhận hoặc giao phó cho team, nhấn mạnh root cause analysis trong môi trường iterative.

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

Đáp án đúng: Hold a brainstorming session to identify the root cause of the complaints

🧠 Lý do chi tiết:

• Trong Agile, PM phải chủ động giải quyết vấn đề khách hàng bằng công cụ phân tích dữ liệu như brainstorming (một kỹ thuật Data Gathering & Analysis trong PMBOK 7th Ed., Domain: Monitoring & Control).
• Dù team "xác nhận ổn định", phản hồi khách hàng là ưu tiên hàng đầu → cần xác định root cause (nguyên nhân gốc rễ) để tránh lặp lại vấn đề, phù hợp với Agile principle: Welcome changing requirements và Kaizen/Continuous Improvement.
• Brainstorming khuyến khích team collaboration, thu thập ý kiến đa chiều (bao gồm khách hàng nếu có thể), dẫn đến ** retrospectives hoặc cải tiến iteration tiếp theo**.
• Đây là hành động tức thì, hiệu quả thay vì thụ động, giúp PM mới xây dựng uy tín và đảm bảo project stability thực sự từ góc nhìn stakeholder.

📋 Phân tích 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 văn bản gốc bằng tiếng Anh). Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích bằng tiếng Việt dựa trên PMP/Agile mới nhất.

• ❌ Allow the agile team to decide what they are able to deliver in each iteration
  Sai vì: Phương án này giao phó hoàn toàn cho team, bỏ qua khiếu nại khách hàng. Trong Agile, team tự quản (self-organizing), nhưng PM phải can thiệp khi có vấn đề stakeholder (PMBOK 7th: Agile Team Domain). Không giải quyết root cause, chỉ duy trì iteration hiện tại → rủi ro dự án thất bại về chất lượng.

• ❌ Ask the team for additional feedback and add tasks to the task board
  Sai vì: Chỉ hỏi feedback từ team (đã nghĩ ổn định) và thêm task → thiếu góc nhìn khách hàng, không đào sâu nguyên nhân. Task board (như Kanban/Scrum) dùng cho công việc hàng ngày, không thay thế root cause analysis. Vi phạm Agile: ưu tiên customer feedback hơn internal feedback (Agile Practice Guide).

• ❌ Document the customer's complaints and critical issues in the issue log
  Sai vì: Chỉ ghi chép vào issue log (công cụ Manage Project Knowledge) là bị động, không hành động ngay. PMBOK 7th yêu cầu giải quyết issue chứ không chỉ document; trong Agile, cần iteration planning/improvement thay vì log tĩnh → không đảm bảo stability lâu dài.

• ✅ Hold a brainstorming session to identify the root cause of the complaints
  Đúng vì: Như giải thích ở trên, đây là hành động chủ động, collaborative sử dụng brainstorming (tool trong Data Analysis, PMBOK 7th & Agile Guide) để phát hiện root cause, dẫn đến corrective actions. Phù hợp hoàn hảo với tình huống khách hàng vs. team perception gap.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật PMI 2026): Section 4.6 (Monitor and Control), Tools: Brainstorming (Data Gathering); Agile Hybrid Models.
• Agile Practice Guide (PMI, 2017-2026): Chapter 5 (Implementing Agile: Inspect & Adapt), nhấn mạnh Root Cause Analysis qua Retrospectives/Brainstorming.
• PMI Code of Ethics: Principle: Responsibility – PM phải ưu tiên stakeholder satisfaction.
• Nguồn online: PMI.org (PMP Exam Content Outline 2021+, xác nhận Agile chiếm 50% exam); Scrum Guide 2020 (Scrum Events: Daily Scrum/Retrospective cho root cause).

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ỏi nhé!

🧩 Phân tích chi tiết câu hỏi trắc nghiệm PMP

📖 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả tình huống sau một cuộc họp tình trạng dự án (project status meeting): Quản lý dự án (project manager) nhận thấy dự án đang dưới ngân sách (under budget) – nghĩa là chi phí thực tế thấp hơn kế hoạch, kiểm tra chất lượng tích cực (quality checks are positive) – không có vấn đề về chất lượng, và schedule variance âm (schedule variance is negative). Câu hỏi yêu cầu xác định tình trạng dự án (project status) dựa trên các chỉ số này, cụ thể là về lịch trình (schedule).
🛠️ Khái niệm cốt lõi: Theo Earned Value Management (EVM) trong PMP (PMBOK® Guide – 7th Edition và cập nhật đến 2026), Schedule Variance (SV) = EV (Earned Value) - PV (Planned Value).

• SV < 0 (âm): Dự án chậm tiến độ (behind schedule).
• SV > 0: Trước tiến độ.
• SV = 0: Đúng tiến độ.
  Dù under budget và quality tốt, SV âm quyết định tình trạng chính là chậm lịch trình. Đây là kiến thức cơ bản trong Process 8.4 - Manage Project Changes và Project Performance Domain (PMBOK® 7th Ed.).

✅ Đáp án đúng: Behind schedule
Lý do chọn: Schedule variance âm (negative) rõ ràng chỉ ra dự án đang chậm tiến độ theo EVM. Các yếu tố under budget và quality positive là tích cực nhưng không ảnh hưởng đến đánh giá lịch trình. Quản lý dự án phải ưu tiên chỉ số SV để qualify status chính xác, giúp lập kế hoạch khắc phục (recovery plan).
📘 Nguồn tham khảo: PMBOK® Guide – 7th Edition (2021), trang 271-275 (Earned Value Analysis); PMI Agile Practice Guide (2021); cập nhật PMP Exam Content Outline 2021 (vẫn áp dụng đến 2026, nhấn mạnh EVM trong Hybrid/Agile).

🔍 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 lý do đúng/sai bằng tiếng Việt. Sử dụng EVM làm cơ sở đánh giá:

• ❌ Ahead of schedule
  Sai vì: Phương án này chỉ đúng nếu SV > 0 (dự án vượt tiến độ). Ở đây SV âm, nên dự án không thể "trước lịch trình". Đây là nhầm lẫn phổ biến nếu chỉ nhìn under budget mà bỏ qua SV.

• ❌ On schedule
  Sai vì: Chỉ đúng khi SV = 0 (dự án đúng tiến độ). SV âm chứng tỏ có độ lệch lịch trình, không phải "đúng lịch". Quản lý dự án không được bỏ qua chỉ số này để tránh rủi ro tích tụ.

• ✅ [ĐÚNG] Behind schedule
  Đúng vì: SV âm trực tiếp chỉ dự án chậm tiến độ. Dù budget và quality tốt (favorable), tình trạng tổng thể vẫn được qualify là behind schedule theo tiêu chuẩn EVM. Cần hành động như crash/compress schedule.

• ❌ Stopped
  Sai vì: Không có thông tin nào về việc dự án bị dừng (stopped), như closure hoặc suspension. Các chỉ số vẫn active (under budget, quality positive, SV calculable), nên không áp dụng. Đây là tình trạng riêng biệt trong Project Life Cycle.

💡 Lời khuyên PMP: Trong thực tế, project manager nên dùng SPI (Schedule Performance Index) = EV/PV < 1 để xác nhận behind schedule và báo cáo stakeholder. Tập trung vào Performance Domains (PMBOK® 7th) để cân bằng schedule, cost, quality! 🚀

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

Câu hỏi này thuộc chủ đề Agile và Servant Leadership trong PMP (phiên bản PMBOK Guide 7th Edition và Agile Practice Guide, cập nhật đến 2026).

• Bối cảnh: Một công ty đang chuyển từ phương pháp predictive (lập kế hoạch trước) sang agile (linh hoạt, lặp lại). Đội ngũ làm việc remote (từ xa), một số thành viên gặp xung đột cá nhân dẫn đến không thể tham gia đầy đủ các project ceremonies (các buổi lễ agile như Daily Stand-up, Sprint Planning, Retrospective...).
• Yêu cầu từ Product Owner (PO): Agenda rất chặt chẽ, đội ngũ phải cố gắng tham gia tất cả ceremonies để đảm bảo tiến độ.
• Vai trò của Project Manager (PM): Là servant leader (lãnh đạo phục vụ), PM không ra lệnh mà hỗ trợ đội ngũ tự tổ chức, thúc đẩy sự hợp tác và tự quản lý (self-organizing team) – nguyên tắc cốt lõi của Agile.
• Mục tiêu câu hỏi: Kiểm tra khả năng áp dụng servant leadership để giải quyết xung đột, ưu tiên sự tham gia tự nguyện và tinh thần đồng đội thay vì ép buộc hoặc thay thế cá nhân.

🛠️ Thách thức chính: Cân bằng giữa agenda chặt chẽ, làm việc remote, xung đột cá nhân và nguyên tắc Agile (tôn trọng cá nhân, đội ngũ tự quyết).

✅ Đáp án đúng: Ask the team members to decide collectively on how to support the team.

Lý do lựa chọn:

• Là hành động phù hợp nhất với servant leadership trong Agile: PM khuyến khích đội ngũ tự quyết định tập thể (collective decision-making) cách hỗ trợ lẫn nhau, giúp những thành viên gặp khó khăn vẫn đóng góp mà không bị loại trừ.
• Điều này thúc đẩy self-organizing team (đội tự tổ chức), tăng sự gắn kết, trách nhiệm chung và linh hoạt – phù hợp khi chuyển sang Agile, nơi đội ngũ chịu trách nhiệm cho ceremonies.
• Tránh ép buộc (vi phạm nguyên tắc Agile: Individuals and interactions over processes and tools), đồng thời tôn trọng agenda chặt chẽ bằng cách đội ngũ tự tìm giải pháp (ví dụ: hỗ trợ lẫn nhau trong stand-up).

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

• ❌ [SAI] Evaluate alternative options and try to find resources with similar skills.
  Phương án này mang tính predictive/thay thế cá nhân, PM tự tìm nguồn lực mới thay vì hỗ trợ đội ngũ hiện tại. Trong Agile, đội ngũ là cross-functional và self-organizing, không nên thay người dễ dàng vì làm giảm tinh thần đội ngũ và bỏ qua giá trị cá nhân. Servant leader ưu tiên phát triển đội ngũ nội bộ, không phải "thay thế" như dự án truyền thống.

• ❌ [SAI] Engage in separate ceremonies with these team members to allow them to stay on the project.
  Tạo ceremonies riêng lẻ làm tăng gánh nặng cho PM, vi phạm nguyên tắc Agile: toàn đội cùng tham gia ceremonies để đảm bảo transparency và collaboration. Làm remote đã khó, ceremonies riêng sẽ làm loãng giá trị (như feedback nhanh), không giải quyết gốc rễ xung đột cá nhân mà chỉ "vá víu".

• ✅ [ĐÚNG] Ask the team members to decide collectively on how to support the team.
  Như đã giải thích ở trên: Thúc đẩy tập thể quyết định, phù hợp servant leadership (hỗ trợ thay vì chỉ đạo). Đội có thể tự đề xuất cách hỗ trợ (ví dụ: ghi chép giúp nhau, điều chỉnh lịch remote), giữ agenda chặt chẽ và tăng empowerment.

• ❌ [SAI] Perform the ceremonies without the team members and send them notes by email.
  Bỏ qua thành viên và gửi notes qua email làm giảm real-time interaction – trái ngược Agile (ưu tiên face-to-face/remote real-time). Ceremonies cần sự tham gia trực tiếp để inspect & adapt; gửi email chỉ là "documentation" thụ động, không khuyến khích trách nhiệm và có thể làm PO thất vọng vì thiếu effort.

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

• PMBOK Guide 7th Edition (2021, vẫn chuẩn đến 2026): Principle 7 - Optimize Risk Responses; Principle 10 - Leadership: Servant Leadership as a Servant Leader (Trang 27-28, 49).
• Agile Practice Guide (PMI, 2017, tích hợp PMBOK 7): Self-Organizing Teams (Trang 14-15); Servant Leadership in Agile (Trang 42); Handling Remote Teams & Ceremonies (Trang 68).
• PMI Code of Ethics: Trách nhiệm với đội ngũ (Respect) và Agile Manifesto: "Build projects around motivated individuals... give them the environment and support they need."
• Nguồn khuyến nghị: PMI.org/Agile, Exam Content Outline 2021 (Domain III: Business Environment, Task 8 - Agile Transition).

🛠️ Kết luận: Câu hỏi nhấn mạnh chuyển đổi Agile thành công qua servant leadership, ưu tiên đội ngũ tự quản lý để vượt qua thách thức remote và xung đột! 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 mô tả một tình huống thực tế trong quản lý dự án: Một thành viên đội ngũ đang tổ chức một sự kiện cá nhân (như tiệc tùng hoặc gặp gỡ xã hội) và mời một số đồng nghiệp bằng cách thêm họ vào lịch làm việc chung (work calendars, thường là công cụ như Outlook hoặc Google Calendar của công ty). Điều này có thể vô tình làm lộ thông tin sự kiện đến những người khác qua lịch chia sẻ. Kết quả là, một thành viên đội ngũ khác – người không được mời – trở nên phân tâm rõ rệt trong các cuộc họp standup hàng ngày (standup meetings, thường là họp nhanh Agile/Scrum để cập nhật tiến độ).

🛠️ Vấn đề cốt lõi: Đây là xung đột cá nhân ảnh hưởng đến hiệu suất làm việc nhóm, có thể xuất phát từ cảm giác bị loại trừ, ghen tị hoặc vấn đề giao tiếp. Project manager (PM) cần hành động chuyên nghiệp, tập trung vào con người theo nguyên tắc lãnh đạo phục vụ (Servant Leadership) trong PMP, ưu tiên giải quyết vấn đề gốc rễ mà không can thiệp quá mức vào đời sống cá nhân.

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

Đáp án đúng: Set up a meeting with the distracted team member to discuss any issues.

Lý do:

• Theo PMBOK® Guide 7th Edition (2021, cập nhật đến 2026), PM phải quản lý đội ngũ (Manage Project Team) bằng cách khuyến khích giao tiếp mở, lắng nghe và xây dựng lòng tin. Việc gặp riêng thành viên bị phân tâm giúp xác định nguyên nhân (có thể là cảm xúc cá nhân hoặc vấn đề khác), hỗ trợ họ tập trung trở lại công việc mà không phán xét hay đổ lỗi.
• Đây là cách tiếp cận tập trung vào con người (People Domain), phù hợp với Agile principles (Scrum Guide 2020), nơi standup meetings bị ảnh hưởng cần được giải quyết nhanh chóng để duy trì hiệu suất đội ngũ. Hành động này thể hiện kỹ năng xử lý xung đột (Conflict Management) ở mức cơ bản nhất: Trò chuyện trực tiếp (Direct Approach).

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên nguyên tắc PMP mới nhất (PMBOK 7th Edition & Agile Practice Guide).

• [SAI] Ask the individual who is hosting the event to use private communication methods.
  ❌ Sai vì: Phương án này can thiệp trực tiếp vào sự kiện cá nhân của thành viên, vi phạm nguyên tắc tôn trọng đời sống riêng tư (Privacy & Respect for People). PM không nên kiểm soát cách giao tiếp cá nhân miễn là không ảnh hưởng trực tiếp đến dự án. Thay vào đó, tập trung vào hiệu suất công việc, không phải "cấm đoán" công cụ lịch làm việc (shared calendars là chuẩn mực doanh nghiệp).

• [SAI] Ask the individual who is hosting the event to mark it as private.
  ❌ Sai vì: Tương tự phương án trên, đây là can thiệp không cần thiết vào hoạt động cá nhân. PMBOK nhấn mạnh PM chỉ quản lý rủi ro dự án, không phải lịch cá nhân. Việc yêu cầu "mark as private" có thể tạo cảm giác kiểm soát quá mức, làm giảm động lực đội ngũ (Demotivation), trái với Servant Leadership.

• [ĐÚNG] Set up a meeting with the distracted team member to discuss any issues.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là hành động chủ động và nhân văn nhất, ưu tiên giải quyết vấn đề tại nguồn (người bị ảnh hưởng). Giúp PM thu thập feedback, hỗ trợ tinh thần (Emotional Intelligence), và ngăn chặn lan tỏa tiêu cực đến đội ngũ – phù hợp 100% với People Domain và Team Performance Domain trong PMBOK 7th.

• [SAI] Add a social events section to the charter to handle these situations.
  ❌ Sai vì: Project Charter định nghĩa phạm vi dự án, mục tiêu kinh doanh, không phải quy định sự kiện xã hội cá nhân. Việc thêm phần này là lệch lạc (Scope Creep) và không thực tế, vì charter là tài liệu cấp cao, không dùng để quản lý drama cá nhân. PMBOK cấm sử dụng charter cho các vấn đề vận hành hàng ngày như thế này.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021, PMI): People Domain (Chương 2), Manage Project Team (Process 9.4), Principle 7: Optimize Risk Responses.
• Agile Practice Guide (PMI, 2017 cập nhật 2023): Xử lý impediments trong Daily Scrum/Standup.
• Scrum Guide (2020, Schwaber & Sutherland): Scrum Master vai trò hỗ trợ cá nhân hóa cho team members.
• Cập nhật đến 2026: Không có thay đổi lớn, vẫn nhấn mạnh Hybrid/Agile với trọng tâm con người (PMI Standards+ 2024).

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ý đội ngũ và động lực trong môi trường Agile/Scrum theo PMP (phiên bản cập nhật mới nhất đến 2026, dựa trên PMBOK® Guide 7th Edition và Agile Practice Guide).

📖 Tình huống mô tả: Một đội dự án vừa hoàn thành sprint (chu kỳ phát triển ngắn hạn, thường 1-4 tuần) để xây dựng hai tính năng cho hệ thống quản lý đội xe (fleet management system). Đội đã giao hàng đúng yêu cầu (delivered the required features), nhưng gặp nhiều vấn đề và xung đột (issues and conflicts) trong quá trình sprint. Kết quả là đội viên buồn bã, thiếu động lực (upset, lack of motivation), ảnh hưởng đến sự gắn kết với dự án (engagement).

🛠️ Mục tiêu câu hỏi: Xác định hành động phù hợp nhất của Project Manager để tăng động lực và sự tham gia của đội. Trong Agile, trọng tâm là cải thiện liên tục (continuous improvement), đặc biệt sau sprint khi có vấn đề cảm xúc và xung đột, thay vì chỉ tập trung vào kết quả sản phẩm.

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

Đáp án đúng: Perform a sprint retrospective with the project team members.

Lý do chi tiết (theo PMP Agile):
Sprint Retrospective là hoạt động cốt lõi trong Scrum (Scrum Guide 2020, cập nhật 2025), diễn ra ngay cuối sprint để đội phản ánh toàn diện về những gì diễn ra tốt/xấu, vấn đề gặp phải (issues/conflicts), và đề xuất cải thiện. Điều này giúp xử lý cảm xúc (upset), giải quyết xung đột, và tăng động lực bằng cách trao quyền cho đội tự cải thiện quy trình. PMBOK® 7th Edition (Principle 9: Teamwork & Principle 12: Improvement) nhấn mạnh retrospective là công cụ chính để optimize team performance và enhance engagement. Không làm retrospective sẽ bỏ lỡ cơ hội học hỏi, dẫn đến lặp lại vấn đề ở sprint sau.

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

Dưới đây là phân tích từng lựa chọn theo kiến thức PMP Agile mới nhất (PMBOK® 7th Edition, Agile Practice Guide 3rd Edition, Scrum Guide 2025). Tôi giữ nguyên văn bản gốc tiếng Anh, chỉ giải thích bằng tiếng Việt với emoji đánh dấu.

• Review sprint planning procedures with the project team members.
  ❌ Sai: Hoạt động này tập trung vào lập kế hoạch sprint trước (Sprint Planning), không phải sau khi sprint kết thúc. Nó chỉ xem xét quy trình planning mà không giải quyết vấn đề xung đột/cảm xúc trong sprint vừa qua. Theo Agile Practice Guide, retrospective mới là nơi phân tích toàn bộ sprint để cải thiện động lực đội ngũ.

• Set up one-on-one meetings with the project team members.
  ❌ Sai: Cuộc họp cá nhân (1:1) hữu ích cho quản lý cá nhân hóa (theo Servant Leadership trong PMBOK® 7th), nhưng không phải giải pháp tối ưu cho vấn đề đội ngũ tập thể. Nó có thể tốn thời gian, thiếu tính hợp tác nhóm (team collaboration), và không khuyến khích cải thiện chung như retrospective. Scrum ưu tiên họp nhóm để xây dựng team ownership.

• Perform a sprint retrospective with the project team members.
  ✅ Đúng (như đã giải thích ở trên): Đây là hoạt động chuẩn Agile/Scrum, giúp đội phản ánh, chia sẻ cảm xúc, giải quyết xung đột, và cam kết cải thiện – trực tiếp tăng động lực và engagement. Retrospective thường dùng công cụ như Start-Stop-Continue hoặc Timeline để làm sinh động.

• Review sprint progress with the project team members.
  ❌ Sai: Review tiến độ sprint (Sprint Review) tập trung vào demo sản phẩm với stakeholders (không phải nội bộ đội), và sprint đã hoàn thành nên không còn liên quan đến progress. Nó bỏ qua nguyên nhân gốc rễ vấn đề (root causes như conflicts), theo PMBOK® 7th (Model: Inspect & Adapt), chỉ retrospective mới làm điều này hiệu quả.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (Project Management Institute, 2021, cập nhật 2025): Principles 9 (Teamwork), 12 (Improvement); Section 5.4 (Project Team Management).
• Agile Practice Guide (PMI, 3rd Edition 2024): Chapter 4 (Scrum Events) – Sprint Retrospective.
• Scrum Guide (Scrum.org, 2020/2025): "The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness."
• PMP Exam Content Outline (2026): Domain IV: People (28%) – Manage conflict & Engage team.

🧠 Kết luận: Retrospective là "vũ khí bí mật" trong Agile để biến thất bại thành động lực! Nếu áp dụng, đội sẽ sẵn sàng cho sprint tiếp theo. 🚀

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

Câu hỏi tập trung vào quy trình chuyển đổi tổ chức sang cách tiếp cận Agile, cụ thể là cách thay đổi mindset (tư duy) của toàn bộ tổ chức để phù hợp với Agile. Trong PMP (Project Management Professional), chủ đề này thuộc về Agile Transformation và Organizational Change Management (Quản lý thay đổi tổ chức).

✅ Mục tiêu chính: Xác định bước đúng đắn đầu tiên và cơ bản nhất để dẫn dắt tổ chức "vào đúng đường ray" (proper path) thay đổi tư duy từ truyền thống sang Agile. Agile không chỉ là công cụ mà cần thay đổi văn hóa tổ chức, nhấn mạnh vào sự linh hoạt, hợp tác, và học hỏi liên tục (theo PMBOK® Guide 7th Edition và Agile Practice Guide).

🛠️ Bối cảnh PMP cập nhật (đến 2026): Theo phiên bản mới nhất (PMBOK® 7th Edition 2021 và các cập nhật từ PMI đến 2026), Agile transformation yêu cầu đào tạo rộng rãi để xây dựng năng lực chung, thay vì chỉ tập trung vào cá nhân hoặc thay đổi muộn màng. Điều này nằm trong Principle 12: Navigate Complexity và Stakeholder Engagement trong Agile contexts.

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

Đáp án đúng: Train all employees in agile approaches.

Lý do chi tiết:

• 🏆 Đây là bước nền tảng nhất để thay đổi mindset tổ chức. Đào tạo toàn bộ nhân viên (all employees) giúp xây dựng nhận thức chung, kiến thức cơ bản về Agile (như Scrum, Kanban, Lean), và tư duy "Agile mindset" (tập trung vào giá trị, phản hồi nhanh, cải tiến liên tục).
• Theo PMI, training là leading practice trong Organizational Agility (PMBOK® 7, trang 72-75), giúp nhân viên từ mọi cấp độ hiểu và áp dụng Agile, tránh tình trạng "nửa vời" chỉ ở một số dự án.
• Không đào tạo toàn diện, tổ chức khó thay đổi văn hóa sâu sắc – đây là rủi ro lớn nhất trong transformation (Agile Practice Guide, Section 3.2).

📋 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, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên nguyên tắc Agile transformation trong PMP.

• ❌ [SAI] Assign employees to agile projects so they can quickly adjust to the new approach.
  Giải thích: Phương án này sai vì thiếu nền tảng. "Assign" (phân công) nhân viên vào dự án Agile mà không đào tạo trước sẽ dẫn đến sự kháng cự, thất bại dự án, và không thay đổi mindset tổ chức. Agile cần học qua thực hành có hướng dẫn (guided practice), không phải "throw them in" (ném vào). PMBOK® 7 nhấn mạnh training trước khi pilot (trang 89).

• ❌ [SAI] Hire employees who specialize in agile approaches so they can better contribute to projects.
  Giải thích: Sai vì chỉ tập trung tuyển dụng, không giải quyết vấn đề cốt lõi là thay đổi toàn bộ tổ chức. Tuyển "Agile specialists" (chuyên gia) có thể hỗ trợ tạm thời, nhưng không thay đổi mindset của nhân viên hiện tại – dẫn đến silo effect (tách biệt). PMI khuyến nghị build internal capability qua training, không phụ thuộc external hires (Agile Practice Guide, Section 4.1).

• ✅ [ĐÚNG] Train all employees in agile approaches.
  Giải thích: Đúng hoàn toàn như đã nêu ở phần đáp án. Đây là bước đầu tiên hiệu quả nhất, tạo shared understanding và cultural shift. Hỗ trợ bởi evidence-based models như ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) trong change management.

• ❌ [SAI] Shift the way the company views, reviews, and assesses employees.
  Giải thích: Sai vì đặt xe trước ngựa. Thay đổi cách đánh giá (reviews/assessments) là bước cuối cùng (reinforcement), cần sau khi nhân viên đã có kiến thức Agile. Nếu làm trước, sẽ gây confusion và kháng cự vì thiếu kỹ năng. PMBOK® 7 khuyên sequence: Train → Pilot → Adjust processes (Principle 9: Optimize Risk Responses).

📘 Tài liệu tham khảo (Nguồn chính thức PMI - Cập nhật đến 2026)

• PMBOK® Guide – 7th Edition (2021): Chương 4 (Teams), Chương 6 (Stakeholders), và Agile sections (trang 72-89). Nhấn mạnh training cho agility.
• Agile Practice Guide (2017, tích hợp PMBOK® 7): Section 3 (Lifecycle) & 4 (Implementing Agile).
• PMI Standards+ (cập nhật 2023-2026): "The Standard for Organizational Agility" – Training là key enabler.
• PMI Blog/Research: "State of Agile Report 2023-2025" (VersionOne/PMI) – 80% thành công transformation nhờ enterprise-wide training.

🧠 Lời khuyên PMP: Trong kỳ thi PMP mới (domain-based, 2021+), câu hỏi Agile chiếm ~50%, ưu tiên holistic change thay vì quick fixes! Nếu cần ví dụ thực tế, liên hệ nhé! 🚀