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

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

Câu hỏi mô tả tình huống một project manager (PM) mới tiếp quản một dự án đang diễn ra. Theo thông tin từ PM cũ, dự án đang đúng tiến độ (on track) và trong ngân sách (within budget). Tuy nhiên, stakeholders lại không hài lòng với báo cáo tiến độ gần đây, vì các metrics (chỉ số đo lường) cho thấy dự án bị chậm trễ (delayed) và chi phí cao hơn dự kiến (cost higher than expected).

📈 Vấn đề cốt lõi: Có sự mâu thuẫn giữa thông tin chủ quan từ PM cũ và dữ liệu khách quan từ metrics. PM mới cần hành động đầu tiên và phù hợp nhất để xác định tình trạng thực tế của dự án, tránh dựa vào báo cáo chủ quan, nhằm hỗ trợ ra quyết định chính xác trong quá trình Monitoring and Controlling. Đây là tình huống điển hình trong PMP, nhấn mạnh vai trò của dữ liệu đo lường hiệu suất dự án (project performance measurement).

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

Conduct an earned value analysis (EVA).

🛠️ Lý do chi tiết:

• EVA là công cụ phân tích hiệu suất dự án chuẩn mực trong PMP, sử dụng ba chỉ số chính: Earned Value (EV - giá trị kiếm được), Planned Value (PV - giá trị kế hoạch), và Actual Cost (AC - chi phí thực tế) để tính toán Schedule Performance Index (SPI) và Cost Performance Index (CPI).
• Điều này giúp PM mới xác định chính xác tình trạng chậm trễ và vượt ngân sách dựa trên dữ liệu khách quan, thay vì tranh cãi chủ quan giữa PM cũ và stakeholders.
• Đây là bước đầu tiên logic trong quy trình Manage Project Work hoặc Monitor Project Work (PMBOK® 7th Edition), trước khi thực hiện corrective actions. EVA phù hợp với nguyên tắc data-driven decision making trong môi trường dự án hybrid hoặc predictive.

📘 Dẫn nguồn: PMBOK® Guide – Seventh Edition (2021), phần Project Performance Measurement (trang 147-150, Tools & Techniques); cũng được cập nhật trong PMI Standards & Publications đến 2026 với tích hợp AI-driven analytics cho EVA.

🔍 Phân tí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. Mỗi phương án được đánh giá dựa trên Process Groups (Monitoring & Controlling) và best practices PMP mới nhất:

• Schedule a meeting with the previous project manager.
  ❌ Sai vì: Việc họp với PM cũ chỉ mang tính chủ quan, có thể dẫn đến tranh cãi hoặc thông tin không đáng tin cậy (như PM cũ bảo vệ báo cáo của mình). PM mới cần dữ liệu định lượng độc lập từ metrics, không phải thảo luận cá nhân. Điều này vi phạm nguyên tắc lessons learned – không giải quyết vấn đề gốc rễ mà chỉ "đào sâu" vào quá khứ.

• Submit a change request to the change control board (CCB).
  ❌ Sai vì: Change request chỉ được submit sau khi xác định vấn đề cụ thể và đề xuất giải pháp (qua Integrated Change Control process). Lúc này, PM mới chưa có phân tích sâu, submit sớm sẽ không hiệu quả và có thể bị từ chối. CCB dành cho thay đổi scope/baseline, không phải đánh giá tình trạng hiện tại.

• Schedule training for project team members.
  ❌ Sai vì: Training là hoạt động phát triển nguồn lực (Develop Team process), phù hợp khi có vấn đề về kỹ năng đội ngũ. Nhưng ở đây, vấn đề là metrics tổng thể về tiến độ/chi phí, không liên quan đến đào tạo. Hành động này lãng phí thời gian và không giải quyết mâu thuẫn dữ liệu ngay lập tức.

• Conduct an earned value analysis (EVA).
  ✅ Đúng vì: Như đã giải thích ở trên, EVA cung cấp hình ảnh rõ ràng, định lượng về hiệu suất dự án (SPI < 1 cho chậm trễ, CPI < 1 cho vượt chi phí). Đây là hành động ưu tiên cao nhất cho PM mới, hỗ trợ forecasting (EAC, VAC) và stakeholder communication. Hoàn toàn phù hợp với PMP 2026 updates nhấn mạnh metrics-based monitoring trong agile/hybrid projects.

🌟 Kết luận: Câu hỏi kiểm tra kỹ năng phân tích dữ liệu hiệu suất của PM, ưu tiên EVA để xây dựng nền tảng quyết định vững chắc! Nếu áp dụng, PM có thể cập nhật baseline và giao tiếp minh bạch với stakeholders. 📚

🧩 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ý Con người (People Domain) trong PMP, cụ thể là tình huống xử lý xung đột nội bộ đội ngũ trong giai đoạn Thực thi (Execution) của dự án đã kéo dài 1 năm.
📝 Tình huống chi tiết:

• Một thành viên đội ngũ có kinh nghiệm, hiệu suất làm việc tốt (performing well).
• Tuy nhiên, thành viên này thường bất đồng ý (disagrees) với Quyết định của Quản lý dự án (Project Manager - PM) và từ chối thực hiện (refuses to implement).
• Phân hóa đội ngũ: Một phần đội ngũ ủng hộ hành vi "phản kháng" của thành viên này, phần còn lại không ủng hộ.
  🎯 Mục tiêu: PM cần chọn hành động phù hợp nhất để giải quyết xung đột, duy trì sự gắn kết đội ngũ, đảm bảo dự án tiến triển mà không làm giảm động lực làm việc.
  🛠️ Bối cảnh PMP (PMBOK 7th Edition & cập nhật 2026): Trong môi trường dự án hiện đại (hybrid/agile/hybrid), PM đóng vai trò Lãnh đạo phục vụ (Servant Leader), ưu tiên hiểu và giải quyết gốc rễ xung đột (root cause of conflict) thay vì áp đặt quyền lực. Điều này nằm trong Develop Team và Manage Conflict processes.

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

Đáp án đúng: Understand what the team member wants and find possible opportunities to address it.

Lý do chi tiết:

• 🧠 Hành động này thể hiện nguyên tắc Servant Leadership và Emotional Intelligence trong PMP: PM cần lắng nghe (understand) nhu cầu/cảm xúc của thành viên để xác định gốc rễ vấn đề (root cause), sau đó tìm cơ hội giải quyết (opportunities) phù hợp.
• Điều này giúp xây dựng lòng tin (trust), giảm phân hóa đội ngũ, và chuyển hóa xung đột thành động lực tích cực.
• Trong PMBOK 7th Edition (2021, cập nhật 2026), People Domain nhấn mạnh Foster a Collaborative Team Environment bằng cách address concerns cá nhân trước khi áp đặt quyết định. Nếu không hiểu "team member wants gì", các hành động khác chỉ là bề mặt và có thể làm xung đột leo thang.
• 📈 Kết quả mong đợi: Duy trì hiệu suất cao của thành viên kinh nghiệm, thống nhất đội ngũ, đảm bảo value delivery.

❌ 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 theo thứ tự, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phân tích giải thích rõ tại sao đúng/sai dựa trên nguyên tắc PMP mới nhất:

• Phương án 1: Conduct a performance review and define and document the goals for the team member.
  ❌ Sai vì: Hành động này mang tính trừng phạt/formal (performance review), chỉ phù hợp khi hiệu suất kém (underperforming), nhưng câu hỏi nêu rõ thành viên "performing well". Việc định mục tiêu mới có thể bị coi là ép buộc, làm tăng bất mãn và phân hóa đội ngũ. PMP ưu tiên informal resolution trước (PMBOK 7: Manage Conflict - Collaborate/Problem Solve đầu tiên).

• Phương án 2: Remove existing ground rules and create new ground rules that support the project manager.
  ❌ Sai vì: Đây là hành động lạm quyền (authoritative), phá hủy ground rules hiện có (đã được đội ngũ đồng thuận ban đầu). PMBOK 7 cấm "ground rules hỗ trợ cá nhân PM" vì vi phạm Team Charter và High-Performing Team principles. Kết quả: Giảm lòng tin, tăng xung đột thay vì giải quyết.

• Phương án 3: Clarify decisions and request that the project team follows the project manager's decisions.
  ❌ Sai vì: Chỉ làm rõ và yêu cầu tuân thủ (clarify & request follow) là cách tiếp cận quyền lực vị trí (positional power), bỏ qua gốc rễ bất đồng. Trong execution phase, nếu đội ngũ đã phân hóa, điều này sẽ thất bại (như Tuckman Model: Storming phase cần collaboration). PMBOK 7 khuyến nghị Engage Stakeholders và Address Concerns trước khi enforce.

• Phương án 4 (Đúng): Understand what the team member wants and find possible opportunities to address it.
  ✅ Đúng vì: Như đã giải thích ở trên, phù hợp hoàn hảo với 12 Principles of PMBOK 7 (Focus on Value, Build Teams, Address Complexities) và Manage Project Team ITTOs. Đây là bước đầu tiên trong Conflict Resolution Techniques: Collaborate/Understand.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, PMI - cập nhật 2026): Section 4.5 Develop Team, 4.6 Manage Team, People Domain (pages 100-120).
• PMP Exam Content Outline (2024-2026): Domain III: People (28% questions) - Task 8: Manage conflict.
• Agile Practice Guide (PMI): Servant Leadership & Conflict Management.
• Tham khảo thêm: PMI.org resources on Emotional Intelligence in Project Management (2025 updates).

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

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

Câu hỏi tập trung vào tình huống một Project Manager (PM) đang quản lý dự án lớn ở nước ngoài, phát hiện ra rằng chỉ một vài thành viên team đang tham gia vào tất cả các bản phát hành (releases). Vấn đề cốt lõi là sự phụ thuộc quá mức vào một số cá nhân, dẫn đến rủi ro bottleneck, thiếu tính bền vững đội nhóm và dễ bị ảnh hưởng bởi nghỉ việc hoặc quá tải.

Mục tiêu hành động là ngăn ngừa vấn đề này trong tương lai (prevent in the future), không phải giải quyết vấn đề hiện tại. Theo PMBOK® Guide 7th Edition (2021) và các cập nhật PMP đến 2026 (bao gồm Agile Hybrid practices), PM cần tập trung vào quản lý đội ngũ (Manage Team) và xây dựng team hiệu quả bằng cách phân bổ vai trò rõ ràng, thúc đẩy cross-training để đảm bảo kiến thức và trách nhiệm được chia sẻ rộng rãi. Điều này liên quan đến Team Charter – tài liệu định nghĩa roles, responsibilities, và ground rules cho team.

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

Đáp án đúng: Review user roles and update the team charter.
🛠️ Lý do:

• "Review user roles" giúp PM kiểm tra và điều chỉnh các vai trò liên quan đến user (end-user roles) trong releases, đảm bảo không chỉ vài người xử lý tất cả.
• "Update the team charter" là hành động trực tiếp để cập nhật định nghĩa roles & responsibilities của team, thúc đẩy phân bổ công việc đa dạng, cross-functional teams – phù hợp với nguyên tắc High-Performing Teams trong PMBOK 7th (Section 4.6 Manage Team).
• Điều này ngăn ngừa tương lai bằng cách thiết lập quy tắc rõ ràng, tránh phụ thuộc cá nhân. Đây là best practice trong môi trường Agile/DevOps cho large projects với multiple releases.

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

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

• ❌ Speak to the customer and add the issue to the issue log.
  🛠️ Sai vì: Issue log dùng để ghi nhận và theo dõi vấn đề hiện tại (issues), không phải prevent future. Nói với customer (stakeholder bên ngoài) không giải quyết gốc rễ nội bộ team, có thể làm phức tạp hóa mà không mang lại giá trị. Theo PMBOK 7th (Section 4.5 Manage Project Issues), issue log chỉ reactive, không proactive như câu hỏi yêu cầu.

• ❌ Document the risk register in the project charter.
  🛠️ Sai vì: Project Charter là tài liệu ban đầu (high-level), không dùng để document chi tiết Risk Register (được tạo riêng trong Identify Risks process). Thứ tự sai logic: Risk Register là output của Risk Management, không "document into" Charter. PMBOK 7th (Section 4.3 Manage Risks) nhấn mạnh Risk Register độc lập, không liên quan trực tiếp đến team roles.

• ✅ Review user roles and update the team charter.
  🛠️ Đúng vì: Như đã giải thích ở trên, đây là hành động proactive để review roles (user/team) và cập nhật Team Charter – tài liệu cốt lõi định nghĩa team agreements, roles, decision-making (PMBOK 7th, Section 12.2.2 & Agile Practice Guide). Giúp phân bổ releases đa dạng, xây dựng resilient team cho dự án quốc tế lớn.

• ❌ Involve the product owner to rewrite the user stories.
  🛠️ Sai vì: Product Owner chịu trách nhiệm product backlog và user stories (value-focused), không phải assignment team resources hay roles. Rewrite user stories chỉ ảnh hưởng nội dung features, không giải quyết vấn đề team participation trong releases. Theo Agile Practice Guide (PMP 2021+), đây thuộc trách nhiệm Scrum Master/PM về team dynamics, không phải PO.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021): Sections 4.6 (Manage Team), 12.2 (Develop Team), Team Charter template (Appendix).
• Agile Practice Guide (PMI, 2021): High-Performing Teams & Cross-Functional Teams.
• PMP Exam Content Outline (PMI, 2021-2026): Domain III: Business Environment (15%) & Domain IV: Deliver Value (50%) – nhấn mạnh team management.
• Cập nhật 2026: PMI tiếp tục tích hợp Hybrid/Agile, ưu tiên Team Charter trong large-scale projects (xem PMI.org updates).

Hy vọng phân tích này giúp bạn ôn 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 tập trung vào giai đoạn Thực thi (Executing Process Group) trong quản lý dự án theo PMP (PMBOK® Guide). Project Manager (PM) đang xem xét Issue Log (nhật ký vấn đề) và phát hiện có các vấn đề ưu tiên cao (high-priority issues) vẫn đang mở (outstanding/open). Đa số các vấn đề này yêu cầu nỗ lực từ các chuyên gia lĩnh vực bên ngoài (external domain experts), những người không thuộc đội ngũ dự án (not on the project team).

🛠️ Tình huống cốt lõi: PM cần xử lý các vấn đề này một cách chuyên nghiệp, đảm bảo dự án tiến triển mà không vi phạm quy trình kiểm soát thay đổi (Change Control). Theo PMBOK® Guide 7th Edition (và cập nhật đến 2026), Issue Log là công cụ quan trọng trong Monitor and Control Project Work và Manage Project Knowledge, nơi PM phải theo dõi, ưu tiên và giải quyết issues để giảm thiểu rủi ro. Việc cần external experts cho thấy dự án có thể thiếu nguồn lực nội bộ, đòi hỏi hành động chính thức qua Integrated Change Control để cập nhật kế hoạch nguồn lực (Resource Management).

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

• PMBOK® Guide 7th Edition: Principle 5 (Value) & Principle 9 (Team), Process 4.6 Manage Project Resources; 4.7 Implement Risk Responses.
• PMP Exam Content Outline 2021 (cập nhật): Domain IV - People (19%) & Domain III - Business Environment (8%), nhấn mạnh xử lý issues và acquire resources.

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

Đáp án đúng: Review the open issues with the issue reporter and issue a change request to hire an external domain expert.

Lý do 🧩:

• PM phải xem xét lại issues với người báo cáo (issue reporter) để xác nhận tính chính xác, ưu tiên và tác động (best practice theo Manage Quality & Control Procurements).
• Sau đó, phát hành Change Request (Yêu cầu thay đổi) để thuê external expert là hành động phù hợp nhất, vì điều này ảnh hưởng đến nguồn lực dự án (Acquire Resources process). Change Request sẽ được xem xét qua Perform Integrated Change Control để phê duyệt ngân sách/thời gian, đảm bảo tuân thủ quy trình dự án.
• Điều này phù hợp với PMBOK® 7th: Tập trung vào Stakeholder Engagement (hợp tác với reporter) và Tailoring (điều chỉnh nguồn lực bên ngoài khi cần). Không tự ý hành động mà phải qua CCB (Change Control Board) để tránh scope creep.

📋 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, với giải thích hoàn toàn bằng tiếng Việt sử dụng emoji để nổi bật:

• ❌ [SAI] Request that the project team members learn the required domain knowledge and resolve the open issues in a short time.
  Lý do sai 🚫: Yêu cầu đội ngũ học kiến thức chuyên môn mới trong thời gian ngắn là không thực tế và rủi ro cao, vi phạm Develop Team (không dành cho high-priority issues khẩn cấp). Đội ngũ không phải chuyên gia, dẫn đến chất lượng kém, chậm trễ dự án. PMBOK® nhấn mạnh không ép buộc upskill đột ngột mà phải dùng external nếu thiếu (Principle 9: Team).

• ✅ [ĐÚNG] Review the open issues with the issue reporter and issue a change request to hire an external domain expert.
  Lý do đúng 🌟: Như đã giải thích ở trên, đây là quy trình chuẩn: Hợp tác với reporter để validate, rồi Change Request để bổ sung nguồn lực. Đảm bảo traceability, kiểm soát thay đổi và giảm thiểu rủi ro (PMBOK® 7th: 4.5 Manage Communications & 4.3 Project Work).

• ❌ [SAI] Ask the issue reporter to close the issues, because there are no project team members who have the required domain knowledge.
  Lý do sai ❌: Không thể yêu cầu reporter tự đóng issues chỉ vì thiếu kiến thức nội bộ – điều này bỏ qua trách nhiệm PM trong giám sát issues (Monitor Risks). Làm vậy che giấu vấn đề, vi phạm transparency (Principle 3: Stewardship) và có thể dẫn đến thất bại dự án.

• ❌ [SAI] Reduce the project scope to ensure that the project team has the knowledge to deliver the system on schedule.
  Lý do sai 🔒: Giảm scope là thay đổi lớn, chỉ dùng khi cần thiết qua formal change process, không phải giải pháp nhanh cho issues. Nó có thể làm mất giá trị dự án (Principle 1: Be a diligent, respectful, and caring steward), và không giải quyết gốc rễ (thiếu expert). PMBOK® cấm arbitrary scope reduction mà không phê duyệt.

🛡️ Kết luận PMP best practice: PM luôn ưu tiên quy trình chính thức (Change Control) cho high-priority issues liên quan external resources, đảm bảo dự án bền vững! Nếu cần đào sâu, tham khảo PMP Exam Prep của Rita Mulcahy hoặc chính thức PMI.org.

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

Câu hỏi mô tả tình huống một Project Manager (PM) ở một quốc gia đang báo cáo cho Lead Project Manager ở quốc gia khác trong dự án phát triển phần mềm mới. Lead PM thường xuyên yêu cầu cập nhật, thậm chí sử dụng nhiều kênh giao tiếp (như email, chat, gọi điện) nếu PM không phản hồi trong vài phút. Điểm quan trọng: Cả hai đều ngang hàng về thâm niên (seniority) và cùng báo cáo cho một Functional Manager chung.

🛠️ Vấn đề cốt lõi: Đây là xung đột về quản lý giao tiếp (Communications Management), cụ thể là tần suất và thời gian phản hồi quá cao, gây áp lực không cần thiết. Theo PMBOK Guide 7th Edition (2021, cập nhật đến 2026), giao tiếp phải hiệu quả, phù hợp với nhu cầu bên liên quan (stakeholders), và ưu tiên giải quyết trực tiếp qua đàm phán để xây dựng mối quan hệ hợp tác. Không nên leo thang ngay mà cần thỏa thuận chung trước.

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

• PMBOK® Guide 7th Edition, Section 4.5: Project Communications & Process 10.2: Manage Communications (nhấn mạnh thỏa thuận về chu kỳ giao tiếp và kênh phù hợp).
• Process 13.3: Manage Stakeholder Engagement (xử lý nhu cầu giao tiếp của stakeholders nội bộ).
• PMI Code of Ethics & Professional Conduct (ưu tiên giải quyết xung đột trực tiếp, tôn trọng).

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

Đáp án đúng: Negotiate a mutually agreeable feedback cycle with acceptable timelines.

Lý do:

• 🧩 Trong PMP, khi có xung đột giao tiếp giữa hai bên ngang hàng, bước đầu tiên là đàm phán trực tiếp để đạt thỏa thuận chung về chu kỳ phản hồi (feedback cycle) và thời gian chấp nhận được (timelines). Điều này phù hợp với nguyên tắc Tailoring (tùy chỉnh) trong PMBOK 7th, giúp tối ưu hóa giao tiếp mà không làm gián đoạn công việc.
• ✅ Hành động này thúc đẩy hợp tác (collaboration), giảm áp lực, và xây dựng lòng tin – phù hợp với 12 Project Management Principles (stewardship, teamwork). Không leo thang ngay vì cả hai cùng cấp, tránh làm phức tạp hóa mối quan hệ.

❌ 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 quy trình PMP mới nhất:

• [SAI] Refer the lead project manager to the communications management plan.
  ❌ Sai vì: Chỉ trích dẫn kế hoạch giao tiếp (Communications Management Plan) mà không thảo luận sẽ bị coi là thụ động và thiếu hợp tác. Kế hoạch này đã tồn tại (theo ngữ cảnh), nhưng lead PM có thể không tuân thủ hoặc có nhu cầu khác. PMP khuyến nghị đàm phán điều chỉnh thay vì chỉ "chỉ tay vào quy định" (PMBOK 10.1 Plan Communications Management).

• [ĐÚNG] Negotiate a mutually agreeable feedback cycle with acceptable timelines.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là cách chủ động và chuyên nghiệp nhất, tập trung vào giải quyết gốc rễ qua thỏa thuận hai bên cùng có lợi. Phù hợp với Conflict Resolution Techniques (Collaborate/Problem Solve) trong PMBOK 7th.

• [SAI] Update the communications management plan and the stakeholder engagement plan.
  ❌ Sai vì: Cập nhật kế hoạch (Communications Management Plan & Stakeholder Engagement Plan) cần thay đổi chính thức qua Integrated Change Control (Process 4.6), không phải hành động cá nhân. Hơn nữa, PM không có thẩm quyền đơn phương thay đổi mà chưa đàm phán với lead PM – vi phạm nguyên tắc stewardship (PMBOK 4.7 Monitor and Control Project Work).

• [SAI] Escalate the issue to the functional manager and explain the situation to them.
  ❌ Sai vì: Leo thang (escalate) chỉ dùng khi đàm phán thất bại hoặc vấn đề nghiêm trọng ảnh hưởng dự án (PMBOK Ethics: Escalate only if necessary). Ở đây, cả hai ngang hàng, nên ưu tiên giải quyết trực tiếp để tránh làm xấu mối quan hệ và mất thời gian. Leo thang sớm thể hiện thiếu kỹ năng lãnh đạo (Teamwork Principle).

🛠️ Kết luận khuyến nghị: PM nên sắp xếp họp trực tiếp hoặc gọi video với lead PM để đàm phán, ghi chép thỏa thuận vào kế hoạch giao tiếp nếu cần. Điều này đảm bảo dự án suôn sẻ theo PMP best practices! 🚀

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

Câu hỏi mô tả tình huống trong môi trường Agile/Scrum (vì đề cập đến "sprint" và "impediments" – các trở ngại cản trở team). Project manager (PM) và team đã thành công đưa dự án trở lại đúng tiến độ bằng cách mapping và loại bỏ các impediments trước đó. Tuy nhiên, trong sprint hiện tại, một impediment cũ (gây delay lớn trước đây) quay trở lại. Team đã thử áp dụng các mitigation tasks giống hệt lần trước, nhưng không đạt kết quả tương tự.

Câu hỏi tập trung vào hành động tiếp theo phù hợp nhất cho PM, nhấn mạnh vào quy trình giám sát và kiểm soát (Monitoring and Controlling) trong PMP. Đây là tình huống điển hình khi giải pháp cũ không còn hiệu quả, đòi hỏi PM phải đánh giá lại vấn đề thay vì lặp lại hành động cũ hoặc leo thang vội vã. Chủ đề liên quan đến quản lý impediments trong Agile, theo PMBOK® Guide 7th Edition và Agile Practice Guide (cập nhật đến 2026, không thay đổi lớn ở phiên bản mới).

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

Đáp án đúng: Reassess the issue as part of monitoring and controlling.

Lý do:
🛠️ Trong process group Monitoring and Controlling (PMBOK® 7th Edition, Domain 5: Measurement), PM phải liên tục giám sát, đánh giá lại (reassess) các vấn đề, đặc biệt khi tình huống thay đổi (impediment tái phát và mitigation cũ thất bại). Trong Agile, đây là phần của Daily Stand-up, Sprint Review/Retrospective, nơi team inspect & adapt (kiểm tra và điều chỉnh). Việc reassess giúp xác định root cause mới, cập nhật lessons learned, và điều chỉnh kế hoạch mà không cần leo thang ngay. Đây là hành động chủ động, hiệu quả nhất đầu tiên, phù hợp nguyên tắc value-driven và holistic monitoring trong PMP mới.

📘 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 phương á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 (PMBOK® 7th Edition, Agile Practice Guide):

• Escalate the issue with an impediment to the project sponsor.
  ❌ Sai. Leo thang ngay đến sponsor chỉ phù hợp khi PM/team không thể giải quyết nội bộ hoặc ảnh hưởng nghiêm trọng đến project objectives (ví dụ: scope/thời gian vượt quá quyền hạn). Ở đây, team vẫn đang trong sprint, chưa thử reassess đầy đủ, nên escalate là quá sớm, vi phạm nguyên tắc servant leadership của PM Agile (empower team tự xử lý impediments trước). Escalation nằm ở escalation threshold trong governance, không phải bước đầu.

• Implement the mitigation plans listed in the organizational process assets (OPAs).
  ❌ Sai. OPAs (Organizational Process Assets) chứa best practices/templates lịch sử, nhưng câu hỏi rõ ràng cho thấy mitigation cũ đã thất bại (không có kết quả tương tự). Áp dụng mù quáng OPAs mà không tailor theo context hiện tại vi phạm principle 2: Stewardship (quản lý phù hợp) và tailoring trong PMBOK® 7th. Phải reassess trước khi dùng OPAs mới.

• Use the contingency budget to implement schedule compression.
  ❌ Sai. Contingency budget dành cho known risks (trong Risk Management Reserve), không phải impediments Agile (thường xử lý bằng team velocity/adjust backlog). Schedule compression (crashing/fast-tracking) là kỹ thuật không khuyến khích đầu tiên vì tăng chi phí/rủi ro, chỉ dùng khi approved change request. Ở đây chưa có cơ sở reassess, nên dùng budget là lãng phí, trái principle 11: Optimization (optimize resources).

• Reassess the issue as part of monitoring and controlling.
  ✅ Đúng. Như đã giải thích ở trên, đây là hành động cốt lõi của Monitoring & Controlling, đặc biệt trong iterative Agile (sprint monitoring). Giúp uncover new insights, cập nhật Issue Log và Backlog, đảm bảo continuous improvement. Hoàn toàn phù hợp PMP 2026 (Hybrid/Agile focus).

📚 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, PMI): Sections 4.5 Monitoring and Controlling, Principle 9: Leadership; Agile Hybrid models.
• Agile Practice Guide (PMI, 2017/updated integrations): Chapter 5: Implementing Scrum – Impediments Management.
• PMP Exam Content Outline (2021+, valid to 2026): Domain V: Measurement (17%), Task 6: Monitor project performance.
• PMI.org resources: "Handling Impediments in Agile" whitepapers (no major changes post-2021).

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 tập trung vào quy trình giao tiếp và báo cáo trong quản lý dự án PMP, cụ thể là khi senior management (lãnh đạo cấp cao) yêu cầu thông tin dự án để phân tích dữ liệu và đưa ra quyết định dự án. Họ cần một cái nhìn tổng quan rộng lớn (broader view) về dự án, không phải chi tiết kỹ thuật sâu.

📌 Bối cảnh PMP (theo PMBOK® Guide 7th Edition và cập nhật đến 2026): Trong Project Monitoring and Controlling và Stakeholder Engagement, project manager phải cung cấp thông tin phù hợp với nhu cầu của các bên liên quan. Senior management thường quan tâm đến tiến độ tổng thể, mốc quan trọng (milestones) để đánh giá hiệu suất dự án mà không bị lạc vào chi tiết. Điều này hỗ trợ decision-making ở mức chiến lược, phù hợp với nguyên tắc Tailoring và Value Delivery trong PMBOK 7.

✅ Đáp án đúng: Milestones status report

Lý do chọn đáp án đúng 🛠️:
Báo cáo trạng thái các mốc quan trọng (Milestones status report) cung cấp cái nhìn tổng quan rộng (broader view) về tiến độ dự án, bao gồm các sự kiện then chốt như hoàn thành giai đoạn, đạt mục tiêu lớn. Điều này giúp senior management nhanh chóng nắm bắt tình hình dự án, dự báo rủi ro chiến lược và đưa ra quyết định mà không cần chi tiết hoạt động hàng ngày. Theo PMBOK® 7th Edition (Domain: Measurement), milestones là công cụ chính để communicate project health với executives.

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

• ❌ Higher-level activities completed
  Phương án này sai vì chỉ liệt kê các hoạt động cấp cao đã hoàn thành, mang tính chi tiết hoạt động (activity-level) chứ không cung cấp cái nhìn tổng quan rộng. Senior management không cần danh sách hoạt động mà cần tóm tắt tiến độ chiến lược. (PMBOK® 7: Activities thuộc Schedule Management, quá cụ thể cho executives).

• ✅ Milestones status report
  Phương án này đúng như đã giải thích ở trên. Nó tập trung vào high-level progress indicators, phù hợp với nhu cầu "broader view" và hỗ trợ executive dashboards trong thực tiễn Agile/Hybrid (PMP 2021+ updates).

• ❌ Risk register information
  Phương án này sai vì Risk Register chứa danh sách rủi ro chi tiết, xác suất, tác động (từ Identify Risks process). Đây là thông tin chuyên sâu cho project team/risk owners, không phải tổng quan dự án cho senior management. (PMBOK® 7: Risk Domain – chỉ chia sẻ summary nếu cần, không phải full register).

• ❌ Resource breakdown structure (RBS)
  Phương án này sai vì RBS là cấu trúc phân cấp tài nguyên (nhân sự, vật tư) dùng trong Resource Management để phân bổ. Nó mang tính tĩnh và chi tiết, không phản ánh tiến độ hay trạng thái dự án tổng quan. (PMBOK® 7: Resource Domain – phù hợp cho planning, không phải reporting cho executives).

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021, cập nhật PMI đến 2026): Chương 4 (Measurement), Chương 3 (Project Work), và Appendix X4 (Tailoring). Milestones được nhấn mạnh trong Work Performance Reports.
• PMI Agile Practice Guide (2021): Phần Reporting với executives qua milestone burn-up charts.
• PMP Exam Content Outline (2021+): Domain 3 (Business Environment) & Domain 4 (Delivery) – Emphasize high-level communication.

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 lĩnh vực Quản lý Dự án (Project Management) theo chuẩn PMP (Project Management Professional), tập trung vào quy trình xử lý rủi ro và thay đổi dự án, cũng như quản lý kỳ vọng của bên liên quan (stakeholders).

📖 Tình huống cụ thể:

• Quản lý dự án (Project Manager - PM) phát hiện một vấn đề bất ngờ (unexpected issue) ở giữa dự án của khách hàng (halfway through a customer's project).
• Sau khi phân tích, đội ngũ dự án (project team) xác định rằng vấn đề này sẽ ảnh hưởng đến thời gian hoàn thành (timeline) trừ khi phân bổ thêm nguồn lực (more resources).
• Thách thức cốt lõi: Dự án phải cân bằng giữa chi phí (cost) và thời gian (timeline) – đây là trade-off điển hình trong Triple Constraint (Scope, Time, Cost) theo PMBOK® Guide.

🛠️ Mục tiêu PMP ở đây: PM phải tuân thủ Nguyên tắc 3: Engage Stakeholders (Tương tác với bên liên quan) và Quy trình 13.3: Manage Stakeholder Engagement (PMBOK® Guide – 7th Edition, cập nhật đến 2026). Khách hàng là stakeholder chính (key stakeholder), nên PM không tự quyết định thay đổi mà phải thông tin minh bạch và thảo luận để họ quyết định trade-off.

✅ Đáp án đúng

Inform the customer of the issue and discuss the options so that they are able to make a decision on cost versus timeline.

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

• Đây là hành động chuẩn mực và chuyên nghiệp nhất theo PMP. PM phải thông báo kịp thời (inform promptly) về vấn đề, sau đó thảo luận các lựa chọn (discuss options) để khách hàng tự quyết định ưu tiên giữa chi phí thêm (cho resources) và kéo dài timeline.
• Điều này thể hiện Stewardship (Trách nhiệm), Transparency (Minh bạch) và Value Delivery (Tạo giá trị) – các nguyên tắc cốt lõi PMBOK® 7th Edition.
• Tránh rủi ro pháp lý hoặc hợp đồng bằng cách không tự thay đổi scope/cost/time mà không có sự đồng ý của khách hàng.

📘 Nguồn tham khảo:

• PMBOK® Guide – 7th Edition (2021, cập nhật Hybrid 2026): Principle 3 – Engage Stakeholders; Section 4.6 – Project Reporting.
• PMI Code of Ethics & Professional Conduct: Rule 3.2 – Report issues transparently.

🔍 Phân tí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, 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 (PMBOK® 7th Edition & Agile Hybrid):

• Absorb the additional cost for the additional resources internally so that the project completes within the timeline.
  ❌ Sai. Phương án này vi phạm quy trình Change Control (Integrated Change Control – 4.6 PMBOK® 6th/7th) vì PM không được tự chịu chi phí thêm mà không có phê duyệt từ khách hàng hoặc ban lãnh đạo tổ chức. Điều này có thể dẫn đến lỗ lã tài chính, mất lòng tin stakeholder, và không tuân thủ Tailoring (Tùy chỉnh dự án). Trong thực tế, "absorb internally" chỉ áp dụng nếu hợp đồng fixed-price và dự án nội bộ, không phải dự án khách hàng.

• Meet with the project team to discuss internally whether they think cost is more important to the customer than the timeline.
  ❌ Sai. Thảo luận nội bộ với team là tốt cho team building, nhưng không giải quyết gốc rễ vì team không đại diện cho khách hàng. PMBOK® nhấn mạnh Stakeholder Engagement phải trực tiếp với owner (khách hàng), không đoán mò ưu tiên. Điều này có thể gây chậm trễ và sai lầm chiến lược.

• Adjust the timeline since, in the past, the customer would not pay any additional costs, then inform the customer of the change.
  ❌ Sai. Dựa vào kinh nghiệm quá khứ (past behavior) để tự điều chỉnh timeline là rủi ro cao, vi phạm Risk Management (Identify & Respond to Risks – Principle 10) và Contract Management. PMBOK® yêu cầu Integrated Change Control với formal approval từ khách hàng trước khi thay đổi bất kỳ constraint nào (time/cost). "Inform after adjust" là reactive thay vì proactive, có thể dẫn đến tranh chấp hợp đồng.

• Inform the customer of the issue and discuss the options so that they are able to make a decision on cost versus timeline.
  ✅ Đúng. Như đã giải thích ở trên, đây là best practice hoàn hảo, thúc đẩy collaborative decision-making và customer-centric approach theo PMBOK® 7th Edition.

💡 Lời khuyên PMP thực tiễn: Trong tình huống tương tự, PM nên sử dụng Issue Log để ghi nhận, Escalate nếu cần, và thu thập feedback để cải thiện dự án tương lai. Luôn ưu tiên Value over Constraints! 🚀

🧩 Phân tích 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ả: Trong một cuộc họp của dự án Agile (có lẽ là Sprint Review hoặc Retrospective), Project Manager (PM) thông báo rằng sprint goals không đạt được. Product Owner (PO) rời họp sớm, trong khi team thảo luận và bối rối vì:

• Không có defects (lỗi) cho các user stories mới.
• Không có yêu cầu mới được thảo luận.

🛠️ Vấn đề cốt lõi: Team nghĩ công việc "done" vì không lỗi và không thay đổi yêu cầu, nhưng sprint goals vẫn fail. Điều này chỉ ra sự không đồng nhất về tiêu chí "done" giữa team và PO. PM cần hành động phòng ngừa để tránh lặp lại, tập trung vào việc align kỳ vọng trong Agile.

✅ Đáp án đúng: Review the definition of done (DoD) with the product owner.

Lý do chọn đáp án này (dựa trên Agile Practice Guide và Scrum Guide 2020+ cập nhật):
Trong Agile, Definition of Done (DoD) là bộ tiêu chí chung (shared understanding) để xác định một user story hoặc increment hoàn toàn hoàn thành, bao gồm test, integration, documentation, v.v. – không chỉ "no defects". Sprint goals fail dù team thấy "done" vì PO có thể có kỳ vọng DoD cao hơn (ví dụ: acceptance criteria chưa đạt, performance chưa đủ). Việc review DoD với PO trước sprint giúp align, tránh hiểu lầm. Đây là best practice ở Sprint Planning hoặc Refinement để phòng ngừa.
✅ Hiệu quả: Giảm confusion, tăng transparency (Principle 1: Stewardship; Value: Customer Focus).

📋 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. Mỗi phương án được đánh giá đúng/sai với lý do dựa trên PMBOK 7/Agile.

• ✅ Review the definition of done (DoD) with the product owner.
  Đúng 🏆: Như giải thích trên, DoD là "kim chỉ nam" chung cho "done" trong Agile. Review định kỳ với PO đảm bảo mọi người hiểu thống nhất, tránh tình huống PO bỏ họp vì bất đồng. Đây là action chủ động ở Product Backlog Refinement hoặc Sprint Retrospective (Agile Principle: Optimize Risk).

• ❌ Get approval from the product owner on the user stories.
  Sai: User stories đã được PO approve ở Backlog Refinement trước sprint (PO chịu trách nhiệm prioritize và accept). Vấn đề không phải approval ban đầu mà là thực thi "done" trong sprint. Lặp lại approval chỉ tốn thời gian, không giải quyết root cause (không align DoD).

• ❌ Create better plans to ta.st the functionality in more detail.
  Sai: (Lưu ý: "ta.st" có lẽ lỗi chính tả của "test"). Testing chi tiết hơn chỉ fix symptoms (defects), nhưng team đã "no defects" mà sprint goals vẫn fail → vấn đề không phải test plan mà là định nghĩa "done" rộng hơn (ví dụ: usability, compliance). Tăng test plan vi phạm Agile principle: Deliver Value Incrementally, dễ over-engineering.

• ❌ Include previous sprint defects and close them in the actual sprint.
  Sai: Agile cấm "carry-over defects" từ sprint trước vào sprint hiện tại (Sprint Goal phải tự chứa, time-boxed). Điều này phá vỡ incremental delivery và DoD (defects cũ phải fix ở sprint sau hoặc hotfix). Team confused vì "no new defects", nên focus future prevention chứ không phải "đào bới quá khứ".

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật 2026): Section 4.5 (Agile/DevOps), nhấn mạnh shared DoD cho Predictable Teams.
• Agile Practice Guide (PMI, 2017+ updates): Chapter 5.3 (Sprint Planning), "Definition of Done ensures quality".
• Scrum Guide (2020, reaffirm 2025): "The Definition of Done is a formal description of the state of the Increment".
• PMI.org/PMP Exam Content Outline (2024+): Domain III: Business Environment (Agile alignment).

🛠️ Khuyến nghị PMP: Luôn review DoD ở Retrospective để continuous improvement! Nếu cần practice thêm, tham khảo PMI Agile Certified Practitioner (PMI-ACP).

🧩 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ý Xung đột trong Nhóm Dự án (Conflict Management) trong giai đoạn Planning của một dự án triển khai phần mềm. Cụ thể, hai thành viên đội ngũ đang tranh luận gay gắt về cách tiếp cận đào tạo người dùng cuối (end-user training), và họ không thể đạt được sự đồng thuận. 📘 Project Manager (PM) cần quyết định hành động tiếp theo để giải quyết tình huống này một cách hiệu quả, phù hợp với nguyên tắc PMP.

🛠️ Bối cảnh PMP (theo PMBOK® Guide 7th Edition, cập nhật đến 2026): Trong giai đoạn Planning, PM phải thúc đẩy sự hợp tác (collaboration) để xây dựng consensus, vì xung đột ở giai đoạn sớm có thể ảnh hưởng đến kế hoạch tổng thể. Các kỹ thuật giải quyết xung đột ưu tiên là Collaborate/Problem Solve (hợp tác giải quyết vấn đề) để đạt kết quả tốt nhất lâu dài, thay vì áp đặt hoặc loại bỏ thành viên.

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

Đáp án đúng: Consider the view of each team member about the issue in order to reach consensus.

Lý do:

• Đây là cách tiếp cận hợp tác (Collaborate) hàng đầu theo PMP, giúp PM xem xét quan điểm của từng thành viên để xây dựng sự đồng thuận (consensus). 🧩 Điều này khuyến khích sáng tạo, tăng cam kết từ đội ngũ và giảm rủi ro xung đột tái diễn. Trong giai đoạn Planning, việc đạt consensus đảm bảo kế hoạch đào tạo end-user được tối ưu, phù hợp với Project Team Performance Domain (PMBOK 7th Ed.).
• Nguồn tham khảo: PMBOK® Guide 7th Edition, trang 258-260 (Conflict Resolution Strategies); PMP Examination Content Outline 2021 (Domain IV: People, Task 6: Conflict resolution).

📋 Phân tích tất cả các phương án trả lời

Dưới đây là phân tích chi tiết từng phương án, với nội dung gốc giữ nguyên tiếng Anh. Mỗi phương án được đánh giá đúng/sai kèm lý do cụ thể theo PMP:

• Consider the view of each team member about the issue in order to reach consensus.
  ✅ Đúng 🏆. Phương án này áp dụng kỹ thuật Collaborate/Problem Solve – phương pháp ưu tiên nhất trong 5 kỹ thuật giải quyết xung đột PMP (Collaborate > Compromise > Force > Smooth > Withdraw). PM lắng nghe cả hai bên để đạt consensus, thúc đẩy sự sở hữu chung và hiệu suất đội ngũ cao hơn, đặc biệt ở giai đoạn Planning nơi ý kiến chuyên môn từ đội ngũ rất quý giá.

• Make a decision based on expert judgment as a project manager.
  ❌ Sai 🚫. Phương án này tương đương kỹ thuật Force/Direct (áp đặt quyết định dựa trên phán đoán chuyên gia của PM), chỉ dùng khi cần quyết định nhanh hoặc có rủi ro cao, không phải "hành động tiếp theo" ở tình huống tranh luận ý kiến. Nó có thể làm giảm động lực đội ngũ và bỏ lỡ ý tưởng tốt từ thành viên. Theo PMP, Force chỉ là lựa chọn cuối cùng.

• Remove both team members since they are not productively adding to the team.
  ❌ Sai ⚠️. Loại bỏ cả hai thành viên là hành động cực đoan, vi phạm nguyên tắc Value Delivery và Team Management (PMBOK 7th). Xung đột lành mạnh (healthy conflict) là cơ hội cải thiện; loại bỏ sẽ mất kiến thức chuyên môn, tăng chi phí tuyển dụng và làm suy yếu đội ngũ. PMP ưu tiên giải quyết thay vì trừng phạt.

• Remove one or the team members from the project to improve team dynamics.
  ❌ Sai 🔄. Tương tự phương án trên, loại một thành viên là Withdrawing hoặc Avoiding, chỉ tạm thời và không giải quyết gốc rễ vấn đề. Nó phá hoại Team Performance Domain, tăng rủi ro dự án (như thiếu kỹ năng training). PMP khuyến cáo giữ nguyên đội ngũ và giải quyết xung đột qua đối thoại để xây dựng đội ngũ mạnh mẽ hơn.

Kết luận PMP 🎯: Hành động tốt nhất là thúc đẩy consensus để biến xung đột thành cơ hội hợp tác, đảm bảo dự án thành công. Nếu áp dụng thực tế, PM nên ghi chép vào Issue Log và theo dõi sau. Tài liệu tham khảo chính: PMBOK® Guide 7th Edition (2021, không thay đổi lớn đến 2026); Agile Practice Guide (cho hybrid projects).