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

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

Câu hỏi tập trung vào quy trình Quản lý Rủi ro (Risk Management) trong dự án phát triển phần mềm, nơi Quản lý Dự án (PM) đang đối mặt với nhiều rủi ro tài chính. PM cần thường xuyên kiểm tra sức mạnh và hiệu quả của quy trình quản lý rủi ro (frequently check the strength and efficiency of the risk management process).

📌 Mục tiêu chính: Xác định công cụ hoặc hoạt động phù hợp để giám sát và đánh giá hiệu suất quy trình quản lý rủi ro, không phải để xác định rủi ro mới hay quản lý các yếu tố khác. Theo PMBOK® Guide 7th Edition (2021) và các cập nhật PMP đến 2026, điều này thuộc Domain 4: Risk Management và Process 11.7: Monitor Risks, nơi nhấn mạnh việc kiểm tra định kỳ quy trình để đảm bảo nó hiệu quả.

✅ Đáp án đúng: Audit meeting

Lý do lựa chọn:
🛠️ Audit meeting (Cuộc họp kiểm toán rủi ro) là công cụ chính để PM kiểm tra sức mạnh và hiệu quả của toàn bộ quy trình quản lý rủi ro. Trong PMBOK® 7th Edition (Process 11.7: Monitor Risks), Risk Audit được mô tả là hoạt động đánh giá xem các quy trình Identify Risks, Analyze Risks, Plan Risk Responses, và Implement Risk Responses có đang được thực hiện đúng và hiệu quả không. Nó giúp phát hiện lỗ hổng, cải thiện quy trình, và đảm bảo tuân thủ kế hoạch. Cuộc họp này thường diễn ra định kỳ (frequently), phù hợp với ngữ cảnh câu hỏi.

📘 Nguồn tham khảo:

• PMBOK® Guide 7th Edition, trang 299-301 (Section 11.7 Monitor Risks).
• PMP Exam Content Outline 2021 (Domain 4, Task 5: Monitor risks).

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

• Audit meeting ✅
  🛠️ Đúng vì đây là hoạt động chuyên biệt để kiểm toán quy trình quản lý rủi ro, đánh giá hiệu quả thực thi (strength and efficiency). Nó bao gồm họp với team để review nhật ký rủi ro, xác nhận các hành động, và đề xuất cải tiến – chính xác khớp với nhu cầu "frequently check".

• Brainstorming session ❌
  🧠 Sai vì Brainstorming session chủ yếu dùng trong Identify Risks (Process 11.2) để phát hiện rủi ro mới thông qua thảo luận nhóm sáng tạo. Nó không tập trung vào việc kiểm tra hiệu quả quy trình hiện tại, mà chỉ là công cụ thu thập ý tưởng ban đầu.

• Stakeholder register ❌
  👥 Sai vì Stakeholder register là công cụ trong Stakeholder Management (Project Stakeholder Management), lưu trữ thông tin về stakeholders (như ảnh hưởng, lợi ích). Nó không liên quan đến việc kiểm tra quy trình rủi ro, dù stakeholders có thể tham gia quản lý rủi ro.

• Assumption log ❌
  📝 Sai vì Assumption log dùng để ghi nhận và theo dõi các giả định (assumptions) trong dự án, thường liên kết với Identify Risks để xác định rủi ro từ giả định. Nó là đầu vào cho Monitor Risks nhưng không phải công cụ để kiểm tra hiệu quả quy trình quản lý rủi ro.

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

✅ Audit meeting là lựa chọn tối ưu, giúp PM duy trì quy trình rủi ro mạnh mẽ, đặc biệt với rủi ro tài chính trong dự án phần mềm (dễ biến động). Hãy áp dụng định kỳ trong Monitor Risks để dự án thành công!

📚 Tài liệu tham khảo bổ sung:

• PMBOK® Guide 7th Edition (PMI, 2021).
• Agile Practice Guide (tích hợp với PMBOK 7th).
• PMP® Exam Prep by Rita Mulcahy (cập nhật 2024).

Nếu cần thêm ví dụ thực tế hoặc câu hỏi PMP khác, hãy hỏi nhé! 🚀

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

Câu hỏi mô tả tình huống một thành viên đội ngũ hiệu suất cao bất thường (atypically high-performing) đột ngột giảm hiệu suất và thể hiện hành vi hung hăng (aggressive behaviors) với các thành viên khác trong các cuộc họp. Quản lý dự án (project manager) đã làm việc với cá nhân này nhiều tháng trên dự án và chưa từng thấy hành vi này trước đây.
📌 Vấn đề cốt lõi: Đây là dấu hiệu bất thường cần xử lý kịp thời để duy trì hiệu suất đội ngũ, tránh ảnh hưởng lan tỏa. Theo PMP (PMBOK 7th Edition, People Domain), quản lý dự án phải quản lý đội ngũ (Manage Project Team) bằng cách xác định nguyên nhân gốc rễ (root cause) thông qua giao tiếp trực tiếp, áp dụng nguyên tắc Servant Leadership và Stakeholder Engagement để giải quyết xung đột sớm. Không nên vội vàng escalate mà chưa tìm hiểu từ nguồn gốc.

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

Đáp án đúng: Discuss the project manager's observations with the individual to determine why they are behaving this way

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

• Đây là bước đầu tiên và đúng đắn nhất theo quy trình PMP: Nói chuyện trực tiếp với cá nhân để thu thập thông tin từ nguồn chính, giúp xác định nguyên nhân (có thể do stress cá nhân, vấn đề sức khỏe, hoặc xung đột ẩn).
• Phù hợp với PMBOK 7th Edition (Process 9.5: Manage Team) và Code of Ethics & Professional Conduct (1.2.3: Respect): Ưu tiên giao tiếp riêng tư, tôn trọng cá nhân trước khi can thiệp sâu.
• Tránh hiểu lầm hoặc làm tình hình tệ hơn bằng cách xử lý riêng (one-on-one), thúc đẩy high-performing team bằng cách hỗ trợ kịp thời. Nếu cần, mới escalate sau.

📋 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, với nội dung gốc giữ nguyên tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do dựa trên PMP mới nhất (PMBOK 7th Edition 2021 & cập nhật 2026).

• ❌ Discuss the individual's behavior with the other team members to determine if they have noticed and know what is going on
  Phương án này sai vì vi phạm nguyên tắc bảo mật (confidentiality) và có thể tạo tin đồn (gossip), làm giảm lòng tin đội ngũ. Theo PMBOK 7th (Team Management Principles), không nên thảo luận vấn đề cá nhân với nhóm trước khi nói trực tiếp với người liên quan – điều này trái với Ethical Standards (1.4.1: Honesty) và có nguy cơ làm xung đột leo thang.

• ❌ Attend more team meetings to observe the team more closely to determine the root cause
  Phương án này sai vì chỉ quan sát thụ động không giải quyết gốc rễ, lãng phí thời gian và tạo cảm giác giám sát quá mức (micromanagement), giảm động lực đội ngũ. PMP nhấn mạnh proactive communication (PMBOK 7th, Model 4: High-Performing Team) thay vì "làm thám tử" – quan sát chỉ là bước phụ, không thay thế đối thoại trực tiếp.

• ✅ Discuss the project manager's observations with the individual to determine why they are behaving this way
  Như đã giải thích ở trên: Bước đúng chuẩn, tập trung root cause analysis qua giao tiếp cá nhân hóa, phù hợp Servant Leader role trong PMP.

• ❌ Discuss their performance with the team member's functional manager as well as human resources (HR) and discuss next steps
  Phương án này sai vì escalate quá sớm mà chưa thu thập thông tin từ cá nhân, vi phạm progressive discipline (kỷ luật dần dần). Theo PMBOK 7th (9.5 Manage Team) và HR Integration, chỉ escalate sau khi đã nói chuyện trực tiếp và ghi nhận (document). Làm vậy có thể bị coi là phân biệt đối xử nếu vấn đề chỉ tạm thời.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật 2026): Section 4.5 (Team Management), Process 9.5 (Manage Team), Principle 7 (Teamwork).
• PMI Code of Ethics (2022): Responsibility & Respect – Ưu tiên giao tiếp trực tiếp.
• PMP Exam Content Outline (2024-2026): Domain 3: Business Environment (People 50%), nhấn mạnh conflict resolution qua direct engagement.
  🔗 Tham khảo chính thức: PMI.org hoặc Agile Practice Guide (cho high-performing teams).

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

🧩 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ý Đội ngũ Dự án (Manage Project Team) trong PMP, tập trung vào People Domain theo PMBOK Guide 7th Edition (2021) và cập nhật đến 2026. Tình huống mô tả một đội dự án mới hình thành (newly formed project team), nơi một thành viên có kinh nghiệm bị choáng ngợp bởi độ phức tạp nhiệm vụ (overwhelmed by the complexity of the tasks) và không hài lòng với đội dự án (not happy with the project team). Đây là vấn đề phổ biến ở giai đoạn Forming của mô hình Tuckman (Forming-Storming-Norming-Performing-Adjourning), nơi thành viên chưa quen thuộc lẫn nhau, dẫn đến căng thẳng và giảm năng suất.
Project Manager (PM) cần áp dụng Servant Leadership (Lãnh đạo Phục vụ), Emotional Intelligence (Trí tuệ Cảm xúc) và kỹ năng Active Listening để hỗ trợ cá nhân hóa, xây dựng đội ngũ cao hiệu suất (high-performing teams). Mục tiêu là giải quyết gốc rễ vấn đề thay vì né tránh hoặc ép buộc. 📘
Nguồn tham khảo: PMBOK® Guide 7th Edition (Section 4.4. People, Section 6.5. Manage Project Team); PMP Exam Content Outline 2021 (Domain II: People, Task 3: Evaluate team performance).

✅ Đáp án đúng

Actively listen to the team member and identify ways to support their needs in completing the tasks
Lý do lựa chọn: Đây là hành động đúng nhất vì PM phải chủ động lắng nghe (actively listen) để hiểu nhu cầu cá nhân của thành viên, sau đó xác định cách hỗ trợ (identify ways to support) như phân tích nhiệm vụ, đào tạo, mentor hoặc điều chỉnh công việc. Điều này phù hợp với nguyên tắc Tailored Approach (Tiếp cận Phù hợp) và Value Delivery trong PMBOK 7, thúc đẩy động lực (motivation) và giảm rủi ro nhân sự. Không ép buộc mà tập trung vào empowerment (trao quyền). 🛠️
Nguồn: Agile Practice Guide (Section on Servant Leadership); PMI Code of Ethics & Professional Conduct (Responsibility: Enhance personal professional competence).

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

• Explain that the tasks are unavoidable and ask the team member to find a solution to overcome the challenges
  ❌ Sai: Phương án này thiếu hỗ trợ từ PM, chỉ đẩy trách nhiệm cho cá nhân (ask to find a solution), vi phạm Servant Leadership. Nó bỏ qua giai đoạn Forming của Tuckman, có thể làm tăng bất mãn và dẫn đến turnover. PMBOK 7 nhấn mạnh PM phải facilitate chứ không ép buộc. 🛑

• Set up team-building activities with the project team members to reduce tension
  ❌ Sai: Hoạt động team-building hữu ích cho toàn đội ở giai đoạn Storming, nhưng chưa phù hợp với vấn đề cá nhân (one team member overwhelmed). Nó không giải quyết gốc rễ (complexity of tasks), có thể lãng phí thời gian nếu chưa lắng nghe nhu cầu cụ thể. PMBOK khuyến nghị address individual needs first trước team activities. ⏭️

• Ask the team member to enter this potential schedule delay in the risk register
  ❌ Sai: Việc ghi nhận rủi ro (risk register) là đúng cho schedule risk, nhưng không phải ưu tiên đầu tiên. Nó bỏ qua human aspect (cảm xúc, hỗ trợ), biến vấn đề cá nhân thành rủi ro dự án mà không giải quyết. PMBOK 7 (Uncertainty Domain) yêu cầu proactive support trước khi escalate thành risk. 🚫

• Actively listen to the team member and identify ways to support their needs in completing the tasks
  ✅ Đúng: Như đã giải thích ở trên, đây là cách tiếp cận optimal theo Emotional Intelligence và High-Performing Servant Leader. Nó xây dựng trust, giảm overwhelm và đảm bảo project success. 💡

Kết luận: Câu hỏi kiểm tra khả năng support team members proactively thay vì reactive measures. Hãy áp dụng trong thực tế để đạt High-Performing Team! 🚀 Nguồn bổ sung: The PMP Examination Content Outline (2024 updates); Tuckman Model in PMBOK 7 (Appendix).

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

Câu hỏi tập trung vào tình huống quản lý dự án theo chuẩn PMP (Project Management Professional), cụ thể là xử lý sự cố chậm trễ dự án (delay) do lượng rework lớn gây ra từ vấn đề chất lượng (quality problem), và sự cố này ảnh hưởng trực tiếp đến đường găng (critical path).

• Bối cảnh chính: Rework là công việc lặp lại do lỗi chất lượng, dẫn đến mất thời gian và làm gián đoạn lịch trình dự án. Critical path là chuỗi hoạt động quan trọng nhất quyết định thời gian hoàn thành dự án, nên bất kỳ delay nào ở đây đều rủi ro cao, có thể làm thay đổi baseline lịch trình (schedule baseline).
• Mục tiêu hành động: Project Manager (PM) phải chủ động xử lý theo quy trình Integrated Change Control (quy trình 4.6 trong PMBOK 7th Edition), bao gồm báo cáo sự cố, đề xuất hành động khắc phục (rectifying actions) và xin phê duyệt thay đổi để tránh tự ý điều chỉnh baseline.
• Kiến thức cốt lõi: Theo PMBOK 7th Edition (và cập nhật PMP đến 2026), PM không được tự rebaseline mà phải qua Change Control Board (CCB) để đánh giá tác động (scope, schedule, cost, quality). Điều này đảm bảo tính minh bạch, kiểm soát rủi ro và tuân thủ nguyên tắc value delivery trong dự án.

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

Đáp án đúng: Report the delay with rectifying actions to the change control board (CCB) for review.

Lý do:

• Vấn đề quality gây rework ảnh hưởng critical path là thay đổi tiềm năng (potential change) đến schedule baseline, đòi hỏi phê duyệt chính thức từ CCB theo quy trình Perform Integrated Change Control (4.6).
• PM phải báo cáo delay kèm hành động khắc phục (như cải thiện quy trình chất lượng, thêm tài nguyên) để CCB xem xét tác động toàn diện (triple constraint: scope-time-cost).
• Hành động này phù hợp với PMP Exam Content Outline 2021+ (Domain 3: Business Environment, Task 6) và PMBOK 7th Principle 5: Optimization – tối ưu hóa bằng cách kiểm soát thay đổi một cách có hệ thống.
• ✅ Lợi ích: Đảm bảo dự án không lệch hướng, duy trì stakeholder alignment và hỗ trợ adaptive/planning approach trong hybrid projects.

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

• ❌ [SAI] Report the delay with rectifying actions to the project management office (PMO).
  Phương án này không đúng vì PMO chủ yếu hỗ trợ chuẩn hóa quy trình, đào tạo và metrics (theo PMBOK 2.2.2), chứ không có thẩm quyền phê duyệt thay đổi như CCB. Báo cáo cho PMO chỉ là hỗ trợ nội bộ, không giải quyết gốc rễ delay trên critical path mà không qua change control.

• ❌ [SAI] Rebaseline the project schedule to absorb the delay.
  Phương án này hoàn toàn sai vì rebaselining chỉ được thực hiện sau khi CCB phê duyệt (PMBOK 6.5.3.3 & 7th 4.6). Tự rebaseline để "hấp thụ" delay sẽ che giấu vấn đề chất lượng, vi phạm nguyên tắc transparency và làm lệch performance measurement baseline (PMB), dẫn đến EVM (Earned Value Management) sai lệch.

• ❌ [SAI] Notify the project steering committee about the cause of the delay.
  Phương án này không đủ vì chỉ thông báo (notify) nguyên nhân mà không kèm hành động khắc phục hoặc xin phê duyệt. Steering committee (hoặc steering group) giám sát cấp cao, nhưng quyết định thay đổi vẫn thuộc CCB (PMBOK 2.2.1). Điều này bỏ qua escalation process đúng và không giải quyết proactive.

• ✅ [ĐÚNG] Report the delay with rectifying actions to the change control board (CCB) for review.
  Như đã giải thích ở trên: Đây là hành động chuẩn mực, tuân thủ Integrated Change Control để đánh giá, phê duyệt và implement rectifying actions, đảm bảo dự án phục hồi critical path hiệu quả.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Sections 4.6 (Perform Integrated Change Control), 6.5 (Control Schedule), 8.3 (Control Quality); Principle 5: Optimization & Principle 9: Adaptability.
• PMP Examination Content Outline (2021, cập nhật 2026): Domain 2: Process (23%), Task 13: Evaluate change requests; Domain 4: People (42%).
• PMI Agile Practice Guide (integrated in PMBOK 7th): Nhấn mạnh retrospective cho quality issues trên critical path.
• Nguồn chính thức: PMI.org (Project Management Institute) – các case study về schedule variance do rework.

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 này thuộc chủ đề Quản lý Đội ngũ Dự án (Manage Team) trong PMP, đặc biệt liên quan đến môi trường Agile với dự án lớn (multi-million dollar). Một Project Manager (PM) giàu kinh nghiệm đã giao tiếp ground rules (các quy tắc cơ bản của dự án, như quy trình làm việc, chuẩn mực hành vi, cam kết hàng ngày) cho đội ngũ ngay từ đầu. Tuy nhiên, sau 12 iterations (12 chu kỳ lặp lại, thường là sprint trong Agile/Scrum), PM nhận thấy một số thành viên không tuân thủ. Câu hỏi yêu cầu hành động đầu tiên (first) để đảm bảo đội ngũ tuân thủ.

🛠️ Bối cảnh PMP (PMBOK 7th Edition, cập nhật đến 2026): Trong Agile, PM đóng vai trò Servant Leader (lãnh đạo phục vụ), ưu tiên giao tiếp nội bộ, huấn luyện đội ngũ và cải tiến liên tục qua các buổi họp như Retrospective. Không nên leo thang ngay lập tức (escalate) lên cấp cao hơn vì điều này có thể làm giảm tinh thần đội ngũ, vi phạm nguyên tắc High-Performing Team và Psychological Safety. Hành động đầu tiên phải là củng cố nội bộ để khuyến khích tuân thủ tự nguyện.

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

• PMBOK® Guide – Seventh Edition (2021, PMI): Principle 9 – Team & Stakeholders; Process: Manage Team (Domain: Team).
• Agile Practice Guide (PMI, 2017, tích hợp PMBOK 7th): Phần Servant Leadership & Team Self-Organization.
• PMP Exam Content Outline 2021 (hiệu lực đến 2026): Domain 4: People (Task 4.2: Evaluate team performance; 4.5: Empower team).

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

Schedule a meeting with the project team to reinforce the ground rules.

Lý do: Đây là hành động đầu tiên và phù hợp nhất trong Agile. PM nên tổ chức họp đội ngũ để nhắc lại và củng cố ground rules, khuyến khích thảo luận mở, xác định nguyên nhân không tuân thủ (có thể do mệt mỏi sau 12 iterations), và xây dựng cam kết chung. Điều này phù hợp Servant Leadership, thúc đẩy team self-organization và continuous improvement (qua Retrospective-like meeting). Leo thang ngay sẽ phá vỡ lòng tin, không phải cách "first" theo PMP.

📋 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. 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 mới nhất.

• Ask the functional manager to replace team members not following the ground rules.
  ❌ Sai: Thay thế thành viên qua functional manager là hành động cực đoan, không phải bước đầu tiên. Trong Agile, đội ngũ tự quản lý (self-organizing), PM ưu tiên huấn luyện/coaching trước. Việc này vi phạm Principle 9: Team (PMBOK 7th), có thể dẫn đến mất động lực đội ngũ và không giải quyết gốc rễ vấn đề.

• Schedule a meeting with the project team to reinforce the ground rules.
  ✅ Đúng: Như đã giải thích ở trên. Đây là best practice cho hành động đầu tiên, thúc đẩy giao tiếp trực tiếp, củng cố chuẩn mực và cải thiện hiệu suất đội ngũ mà không cần escalate.

• Notify the project sponsor about this behavior and ask the sponsor to take disciplinary action.
  ❌ Sai: Báo sponsor và yêu cầu kỷ luật là escalate không cần thiết ở bước đầu. Sponsor chỉ can thiệp chiến lược lớn, không phải quản lý hàng ngày. Điều này trái Stakeholder Engagement (PMBOK 7th) và làm giảm quyền tự chủ đội ngũ trong Agile.

• Contact human resources to request a written warning letter be sent to team members not following the ground rules.
  ❌ Sai: Liên hệ HR để gửi thư cảnh cáo là quy trình kỷ luật chính thức, không phù hợp làm first action. PMP khuyến nghị giải quyết nội bộ trước (Develop Team), tránh formal discipline sớm vì có thể tạo xung đột và giảm team cohesion. Chỉ dùng khi các bước nội bộ thất bại.

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

📖 Tóm tắt câu hỏi:
Câu hỏi mô tả tình huống một Project Manager (PM) được giao quản lý một dự án ưu tiên thấp (low-priority project), với đội ngũ bao gồm các thành viên mới hoàn toàn, chưa có kinh nghiệm dự án chính thức (new team members with no previous formal project experience). Đội ngũ đã yêu cầu gia hạn deadline cho increment phát triển đầu tiên đến 2 lần (requested deadline extensions for the first development increment twice already).

🛠️ Ý nghĩa tình huống:

• Dự án đang ở giai đoạn phát triển lặp (development increment), gợi ý cách tiếp cận lặp hoặc Agile (iterative/Agile).
• Vấn đề cốt lõi: Đội ngũ thiếu kinh nghiệm dẫn đến chậm trễ, cần hỗ trợ đội ngũ (support the team) thay vì chỉ xử lý triệu chứng như gia hạn deadline.
• PM cần hành động chủ động, hỗ trợ phát triển đội ngũ để cải thiện hiệu suất, phù hợp với Domain People trong PMP (PMBOK 7th Edition).
  Mục tiêu: Chọn hành động hỗ trợ đội ngũ tốt nhất ngay lúc này, không phải escalate hay thay đổi kế hoạch vội vã.

✅ Đáp án đúng: Provide feedback to the team using project performance evaluations.

📘 Lý do chọn đáp án đúng (theo PMP mới nhất - PMBOK 7th Edition & updates đến 2026):

• Đây là hành động hỗ trợ trực tiếp đội ngũ bằng cách cung cấp feedback dựa trên đánh giá hiệu suất dự án (project performance evaluations), giúp xác định vấn đề (như thiếu kỹ năng), coaching/mentoring để cải thiện.
• Với đội ngũ mới, PMBOK nhấn mạnh Develop Team (trong Project Team Management) qua feedback thường xuyên, đặc biệt ở dự án low-priority nơi cần xây dựng năng lực nội bộ trước khi escalate.
• Hỗ trợ tăng cường hiệu suất (performance improvement) mà không thay đổi baseline schedule/cost ngay lập tức.
• Nguồn tham khảo: PMBOK Guide 7th Edition, Section 4.5 (Project Performance Domain), Tool & Technique: Performance Reviews & Feedback; Agile Practice Guide (Sprint Reviews cho increments).

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

• ✅ Provide feedback to the team using project performance evaluations.
  Giải thích đúng: Phương án này tối ưu vì trực tiếp hỗ trợ đội ngũ thiếu kinh nghiệm bằng feedback từ đánh giá hiệu suất, giúp họ học hỏi, cải thiện kỹ năng và tuân thủ deadline tiếp theo. Phù hợp nguyên tắc People First trong PMP, ưu tiên phát triển con người trước khi thay đổi kế hoạch. Không tạo thêm rủi ro cho dự án low-priority.

• ❌ Include buffer time in the schedule to absorb future delays.
  Giải thích sai: Thêm buffer chỉ là quản lý rủi ro lịch trình (schedule risk management), không hỗ trợ đội ngũ cải thiện gốc rễ (root cause: thiếu kinh nghiệm). Buffer nên dùng từ đầu (pre-planned), không phải retrospective sau 2 lần delay. Vi phạm nguyên tắc proactive team development (PMBOK 7th, Schedule Domain).

• ❌ Escalate the impact on the schedule to the project sponsor.
  Giải thích sai: Escalate là bước cuối cùng khi PM không kiểm soát được, nhưng ở đây PM mới assign và vấn đề là đội ngũ mới – nên hỗ trợ nội bộ trước. Dự án low-priority, escalate sớm làm mất uy tín PM và không giải quyết vấn đề đội ngũ. Chỉ escalate nếu vượt threshold (PMBOK 7th, Stakeholder Engagement).

• ❌ Create a change request to extend the project's duration and costs.
  Giải thích sai: Tạo change request quá sớm và không cần thiết sau chỉ 1 increment đầu tiên (chưa ảnh hưởng toàn dự án). Thay đổi duration/costs cần formal approval và evidence, trong khi nên tập trung team performance trước. Vi phạm Integrated Change Control (PMBOK 7th, chỉ dùng khi baseline bị ảnh hưởng thực sự).

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

• PMBOK® Guide – Seventh Edition (2021, PMI), cập nhật Agile Hybrid đến 2026: Project Performance Domain & Team Management.
• PMI's PMP Exam Content Outline (2021+): 50% People Domain – Emphasize coaching new teams.
• Agile Practice Guide (PMI): Feedback loops in increments.

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é!

🧩 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ý Rủi ro (Project Risk Management) và Quản lý Kiến thức (Project Knowledge Management) trong PMP, theo PMBOK Guide 7th Edition (cập nhật đến 2026). Tình huống mô tả: Dự án đang nhận được phản hồi tích cực từ khách hàng (excellent feedback), nhưng một nguồn lực chính (key project resource) sắp rời công ty. Câu hỏi yêu cầu xác định biện pháp giảm thiểu (mitigate) tác động từ sự ra đi này.

🛠️ Phân tích tình huống:

• Đây là rủi ro mất nguồn lực quan trọng, có thể ảnh hưởng đến tiến độ, chất lượng dự án dù khách hàng hài lòng.
• Mitigate nghĩa là chủ động giảm tác động của rủi ro (theo PMBOK 7th, Risk Response Strategies: Avoid, Mitigate, Transfer, Accept, Escalate).
• Không phải retain (giữ chân), không phải chỉ identify/monitor (nhận diện), mà phải hành động proactive để bảo vệ dự án ngay lập tức.

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

• PMBOK Guide 7th Edition, Section 4.7 Manage Project Knowledge (tập trung knowledge sharing).
• PMBOK Guide 7th Edition, Domain 4: Risk Management (Mitigation strategies cho resource risk).
• PMI Agile Practice Guide (knowledge transfer trong môi trường agile/hybrid).

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

Đáp án đúng: Establish a proactive knowledge-sharing plan
🧩 Lý do: Biện pháp này chủ động giảm thiểu tác động bằng cách chuyển giao kiến thức từ nguồn lực sắp rời đi sang các thành viên khác ngay lập tức, tránh gián đoạn dự án. Đây là chiến lược mitigate chuẩn mực trong PMP, phù hợp với nguyên tắc Manage Project Knowledge (PMBOK 7th). Nó không chỉ giữ kiến thức dự án mà còn đảm bảo tính liên tục, đặc biệt khi dự án đang suôn sẻ (excellent feedback).

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

• ✅ Establish a proactive knowledge-sharing plan
  Đúng vì đây là biện pháp mitigate trực tiếp và hiệu quả nhất. Theo PMBOK 7th (Section 4.7), knowledge-sharing plan (như mentoring, documentation, cross-training) giúp chuyển giao kiến thức kịp thời, giảm rủi ro mất mát expertise. Nó proactive (chủ động), không chờ sự cố xảy ra, và phù hợp với mọi loại dự án (predictive, agile).

• ❌ Offer a new contract to the resource who is leaving
  Sai vì đây là chiến lược retain (giữ chân nhân sự), không phải mitigate impact. Nhân viên đã quyết định rời đi, việc offer contract có thể không hiệu quả và tốn kém (vi phạm nguyên tắc cost-effective response trong Risk Management). PMBOK 7th nhấn mạnh mitigate tập trung vào giảm tác động, không phải thay đổi quyết định cá nhân.

• ❌ Develop a contingency budget to replace the key resource
  Sai vì đây là contingency plan (kế hoạch dự phòng) cho việc thay thế sau khi rủi ro xảy ra, không phải mitigate trước và giảm tác động ngay. PMBOK 7th (Risk Response) phân biệt: contingency là accept + act if occurs, trong khi mitigate phải proactive giảm probability/impact. Budget này chỉ giải quyết hậu quả, không ngăn chặn gián đoạn kiến thức.

• ❌ Update the risk register and inform the customer
  Sai vì đây chỉ là identify và monitor rủi ro (Update Risk Register - Process 11.3 Manage Risks), không phải hành động mitigate. Thông báo khách hàng có thể làm mất lòng tin dù feedback đang tốt, vi phạm stakeholder engagement (PMBOK 7th, Domain 5). Mitigation yêu cầu response implementation, không dừng ở ghi nhận.

🛠️ Kết luận: Chọn knowledge-sharing để đảm bảo dự án bền vững, phù hợp với People Domain và Value Delivery System trong PMP 2021-2026! Nếu áp dụng thực tế, hãy lập plan ngay với tools như lessons learned repository. 📘

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

Câu hỏi thuộc lĩnh vực Quản lý Bên liên quan (Stakeholder Management) trong PMP, cụ thể liên quan đến quy trình Identify Stakeholders (Xác định các bên liên quan) hoặc Stakeholder Analysis trong bối cảnh chương trình (program).

• Bối cảnh: Quản lý dự án đang làm việc trên dự án ERP (Enterprise Resource Planning - hệ thống hoạch định nguồn lực doanh nghiệp) với các bên liên quan trải rộng qua nhiều dòng kinh doanh. Điều này nhấn mạnh sự phức tạp, đa dạng của stakeholders (có thể hàng trăm người từ các bộ phận khác nhau).
• Hoạt động chính: Quản lý dự án bắt đầu identify (xác định), evaluate (đánh giá), và categorize (phân loại) mối quan hệ của các bên liên quan với chương trình. Đây là các bước cốt lõi của quy trình 13.1 Identify Stakeholders trong PMBOK Guide 6th Edition (và vẫn áp dụng trong PMBOK 7th Edition dưới cách tiếp cận process-hybrid), hoặc Stakeholder Identification & Analysis trong Standard for Program Management (4th Edition).
• Câu hỏi trọng tâm: Mục đích (purpose) của quy trình này là gì? Quy trình này nhằm tạo ra Stakeholder Register (Danh sách bên liên quan), bao gồm thông tin về nhu cầu, ảnh hưởng, mối quan hệ, để hỗ trợ lập kế hoạch giao tiếp, tham gia và quản lý dự án/chương trình hiệu quả.

📘 Nguồn tham khảo:

• PMBOK® Guide 7th Edition (2021) - Domain: Stakeholder (Section 4.7).
• PMBOK® Guide 6th Edition - Process 13.1: Identify Stakeholders.
• The Standard for Program Management 4th Edition (2017) - Chapter 9: Program Stakeholder Engagement (cập nhật không thay đổi lớn đến 2026 theo PMI updates).

✅ Đáp án đúng: Incorporate the needs of all stakeholders into the communications management plan

Lý do lựa chọn 🛠️:

• Quy trình identify, evaluate, categorize stakeholder relationships tạo ra Stakeholder Register – output chính chứa đầy đủ nhu cầu (needs), kỳ vọng (expectations), ảnh hưởng (influence) của TẤT CẢ stakeholders (không phân biệt primary hay secondary).
• Stakeholder Register là input quan trọng cho Plan Communications Management (10.1), giúp tích hợp nhu cầu của tất cả stakeholders vào Communications Management Plan. Mục đích cuối cùng là đảm bảo giao tiếp hiệu quả, đáp ứng mọi bên liên quan, đặc biệt trong dự án ERP phức tạp với stakeholders đa dạng.
• Trong PMBOK 7th (Principle: Stakeholder Collaboration), nhấn mạnh việc incorporate needs để tối ưu hóa engagement qua comms. Đây là lựa chọn chính xác nhất, phù hợp với exam PMP mới nhất (2021+).

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

• [SAI] Identify all stakeholders who can positively affect the project
  ❌ Giải thích sai: Quy trình không chỉ giới hạn ở stakeholders có tác động tích cực. Identify Stakeholders nhằm xác định TẤT CẢ stakeholders (positive, negative, neutral), đánh giá toàn diện ảnh hưởng (power/interest grid). Chỉ tập trung positive sẽ bỏ sót rủi ro từ negative influencers, vi phạm nguyên tắc holistic analysis trong PMBOK.

• [SAI] Identify all stakeholders who can negatively affect the project
  ❌ Giải thích sai: Tương tự option A, quy trình không chỉ nhắm đến stakeholders tiêu cực. Mục đích là evaluate và categorize toàn bộ, bao gồm cả positive/negative để xây dựng chiến lược engagement cân bằng. Bỏ qua positive sẽ làm mất cơ hội hỗ trợ dự án (PMBOK 6th, 13.1.2.1).

• [ĐÚNG] Incorporate the needs of all stakeholders into the communications management plan
  ✅ Giải thích đúng (như phần trên): Đây là ứng dụng trực tiếp của output (Stakeholder Register) vào Plan Communications Management. Đảm bảo all stakeholders (không loại trừ ai) được tích hợp needs vào comms plan, hỗ trợ Manage Stakeholder Engagement (13.3).

• [SAI] Incorporate only primary stakeholders into the communications management plan
  ❌ Giải thích sai: Không đúng vì loại trừ secondary stakeholders. PMBOK yêu cầu all stakeholders (primary & secondary) phải được xem xét trong comms plan (10.1.2.3). Chỉ primary sẽ dẫn đến engagement kém, rủi ro cao ở dự án ERP đa dòng kinh doanh (Power/Interest Grid phân loại tất cả, không ưu tiên chỉ primary).

🧩 Kết luận nổi bật: Quy trình này là nền tảng cho Stakeholder Engagement toàn diện, đặc biệt trong program-level với ERP. Học viên PMP nên nhớ Stakeholder Register → Input cho Comms Plan để pass exam 2026! 📘

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

📖 Giải thích nội dung câu hỏi:
Câu hỏi tập trung vào tình huống một công ty mới chuyển sang cách tiếp cận agile để quản lý dự án, thay vì phương pháp truyền thống (predictive). Giám đốc quản lý (general manager) lo lắng về quá trình định nghĩa phạm vi dự án (scope definition) cho các dự án sắp tới, vì trong agile, scope không được "định nghĩa hoàn toàn" ngay từ đầu như predictive lifecycle. Câu hỏi yêu cầu project manager (PM) làm gì để đảm bảo scope được định nghĩa đầy đủ, phù hợp với nguyên tắc agile. Đây là chủ đề liên quan đến Project Scope Management và Agile Principles trong PMBOK® Guide 7th Edition (2021) và Agile Practice Guide, nhấn mạnh sự linh hoạt, iterative development, product vision thay vì scope cố định upfront. ✅ Mục tiêu là chọn hành động hỗ trợ agile thực sự, không quay về predictive.

✅ Đáp án đúng và lý do lựa chọn:
Đáp án đúng là: Help sponsors and stakeholders craft the product vision, and bring the team and product owner together to clarify expectations.
🛠️ Lý do: Trong agile (Scrum/Kanban), scope được quản lý qua product vision (tầm nhìn sản phẩm) được xây dựng chung bởi sponsors, stakeholders, product owner (PO) và team. Điều này giúp làm rõ kỳ vọng ban đầu, sau đó tinh chỉnh qua backlog refinement và sprint planning. Không cần scope "hoàn toàn định nghĩa" upfront, mà tập trung vào value delivery và adaptability. Hành động này phù hợp 12 Agile Principles (Agile Manifesto) và PMBOK 7 (Domain: Uncertainty), giúp giảm lo lắng của GM bằng cách minh bạch và collaborative approach. 📘 Nguồn: PMBOK® Guide 7th Ed., Section 4.2 (Tailoring) & Agile Practice Guide, p. 24-26 (Product Vision).

🔍 Giải thích tất cả các phương án (đúng/sai):
Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên nguyên tắc PMP/Agile mới nhất (PMBOK 7 & PMI Agile Certified Practitioner - PMI-ACP®).

• ❌ [SAI] Meet with the general manager and convince them to return to using predictive approaches to avoid any risk
  Phương án này sai vì khuyến khích quay ngược về predictive lifecycle (Waterfall), trái với quyết định chuyển sang agile của công ty. Agile chấp nhận risk qua iteration để deliver value nhanh, không phải tránh risk hoàn toàn. Điều này vi phạm principle of adaptability (PMBOK 7, p. 47). Không giải quyết gốc rễ mà phủ nhận agile. 📘 Nguồn: PMBOK 7, Hybrid Approaches (Section 2.3).

• ❌ [SAI] Ask the general manager to review every requirement to ensure all projects will deliver the requested products
  Phương án sai vì yêu cầu GM review từng requirement, tạo bottleneck và micromanagement – điều agile tránh để empower team/PO. Trong agile, requirements (user stories) được refine progressively, không cần review "mọi thứ" upfront. Điều này giống predictive, làm chậm adaptiveness. 🧩 Nguồn: Agile Practice Guide, p. 38 (Backlog Refinement); PMBOK 7, Stakeholder Engagement (Domain 8).

• ❌ [SAI] Ask for a budget increase to implement a double-check process to ensure every business need is included in the requirements
  Sai vì đề xuất tăng ngân sách cho double-check, tạo overhead không cần thiết và cố định requirements upfront – trái agile mindset (lean, minimize waste). Agile dùng inspection (reviews/sprints) thay vì double-check tốn kém, tập trung value-driven. ❌ Nguồn: PMBOK 7, Value Delivery System (Section 1.2); Lean Principles in Agile Practice Guide.

• ✅ [ĐÚNG] Help sponsors and stakeholders craft the product vision, and bring the team and product owner together to clarify expectations
  Đúng như đã giải thích ở trên: Xây dựng product vision chung và clarify expectations qua collaboration (team + PO), là bước đầu tiên trong agile để "định nghĩa scope" một cách linh hoạt. Hỗ trợ ongoing refinement, giảm lo lắng GM bằng transparency. 🛠️ Hoàn hảo cho agile transition! 📘 Nguồn: PMBOK 7, p. 64 (Team Domain); Scrum Guide 2020 (Product Vision Workshop).

💡 Kết luận & Lời khuyên PMP:
Câu hỏi kiểm tra sự hiểu biết về agile tailoring so với predictive. PM phải educate stakeholders về sự khác biệt để tránh resistance. Để học sâu hơn, tham khảo PMI.org (PMBOK 7 updates đến 2026 vẫn giữ core principles, với focus hybrid/agile). Nếu thi PMP, nhớ 50% câu hỏi về predictive/agile/hybrid! 🚀

🧩 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) được giao phát triển phần mềm lập kế hoạch bảo trì cho nhà máy điện. Có một dự án tương tự trước đây từ bộ phận khác trong tổ chức đã thất bại (đóng cửa do hiệu suất thấp). PM lo lắng về hiệu suất dự án và muốn hành động chủ động từ sớm để đảm bảo thành công.
🛠️ Mục tiêu chính: Xác định hành động phù hợp nhất theo nguyên tắc PMP, tập trung vào việc học hỏi từ quá khứ để tránh lặp lại sai lầm, thay vì phản ứng thụ động hoặc cực đoan. Đây là tình huống điển hình về quản lý kiến thức dự án và rủi ro từ bài học kinh nghiệm (lessons learned).

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

Đáp án đúng: Review the lessons learned on similar projects so that they do not fall back into the same pattern.
Lý do: Theo PMBOK® Guide 7th Edition (2021, cập nhật đến 2026 qua PMI Standards+), việc xem xét lessons learned từ dự án tương tự là hành động chủ động và hiệu quả nhất để xác định nguyên nhân thất bại trước đây (như quy trình kém, thiếu kỹ năng, hoặc vấn đề tổ chức), từ đó áp dụng cải tiến ngay từ đầu. Điều này thuộc Process 4.7: Manage Project Knowledge, giúp tái sử dụng organizational process assets (OPA), tránh "lặp lại mô hình thất bại" (fall back into the same pattern). Đây là best practice trong Strategic Performance Domain và Uncertainty Domain, ưu tiên học hỏi để tăng cơ hội thành công mà không cần thay đổi lớn.

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

• ❌ Phương án SAI: Continue executing the project as planned and add more resources if they are required.
  Giải thích: Hành động này thụ động và rủi ro cao, chỉ tiếp tục kế hoạch cũ mà không phân tích nguyên nhân thất bại dự án tương tự. Việc "thêm tài nguyên khi cần" vi phạm nguyên tắc Brooks' Law (thêm người vào dự án muộn thường làm chậm hơn), thuộc Team Domain (PMBOK 7). Không chủ động học hỏi, dễ lặp lại thất bại.

• ❌ Phương án SAI: Evaluate the project risk and add external experts to address the potential risks.
  Giải thích: Mặc dù quản lý rủi ro (Risk Management, Process Group) là cần thiết, nhưng phương án này không trực tiếp giải quyết vấn đề cốt lõi từ dự án tương tự (lessons learned). Thêm chuyên gia bên ngoài có thể tốn kém và không đảm bảo tránh sai lầm cũ nếu chưa review kiến thức nội bộ. Theo Uncertainty Domain, đây chỉ là biện pháp bổ sung, không phải hành động ưu tiên đầu tiên.

• ✅ Phương án ĐÚNG: Review the lessons learned on similar projects so that they do not fall back into the same pattern.
  Giải thích: Như đã nêu ở phần đáp án đúng, đây là hành động tối ưu, tận dụng lessons learned repository từ OPA để phân tích và áp dụng cải tiến (ví dụ: thay đổi quy trình, đào tạo). Hỗ trợ Measurement Domain qua việc theo dõi hiệu suất dựa trên dữ liệu quá khứ, đảm bảo dự án thành công mà không cần can thiệp lớn.

• ❌ Phương án SAI: Inform the project sponsor about the risk and try to convince them to withdraw from the project.
  Giải thích: Hành động này quá bi quan và thiếu trách nhiệm, vi phạm Stakeholder Domain (PMBOK 7) khi PM không cố gắng giảm thiểu rủi ro mà chỉ "báo động và rút lui". Sponsor cần được thông tin minh bạch, nhưng thuyết phục hủy dự án mà chưa hành động là không chuyên nghiệp, trái với Project Manager's primary responsibility là đảm bảo thành công.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (PMI, 2021, cập nhật Standards+ đến 2026): Chương 4.7 Manage Project Knowledge; Performance Domains (Strategic, Uncertainty, Team).
• PMI's Pulse of the Profession® Reports (2023-2025): Nhấn mạnh lessons learned giúp tăng tỷ lệ thành công dự án lên 20-30%.
• The Standard for Project Management (PMI, 2021): Organizational Process Assets (OPA) và Lessons Learned như input/output chính.

🛠️ Lời khuyên PMP: Luôn ưu tiên học hỏi từ quá khứ để dự đoán và ngăn ngừa vấn đề – đây là chìa khóa cho dự án thành công bền vững! Nếu cần thêm ví dụ thực tế, hãy hỏi nhé! 🚀