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 này thuộc Domain: People trong kỳ thi PMP (theo PMBOK® Guide 7th Edition và PMP Examination Content Outline 2021, cập nhật đến 2026). Nó mô tả tình huống: Một số thành viên dự án có kinh nghiệm cao (senior project team members) phàn nàn về Project Manager (PM) vì PM đang micromanaging (quản lý vi mô, can thiệp quá chi tiết) họ, dẫn đến cản trở việc hoàn thành công việc.

✅ Vấn đề cốt lõi: PM cần nhận thức và hành động để điều chỉnh phong cách lãnh đạo phù hợp với mức độ trưởng thành cao của đội ngũ senior (theo mô hình Situational Leadership của Hersey-Blanchard, được tích hợp trong PMBOK). Micromanaging phù hợp với đội ngũ mới, nhưng với senior cần trao quyền (empowerment) và tin tưởng (trust) để tăng hiệu suất. Hành động đúng phải giải quyết ngay lập tức và trực tiếp vấn đề này, tập trung vào quản lý xung đột (Manage Conflict) và lãnh đạo đội ngũ (Lead a Team).

📘 Nguồn tham khảo:

• PMBOK® Guide 7th Edition, Section 4.3 (Project Team) & Agile Practice Guide (Empowerment).
• PMP Exam Content Outline (2021+), People Domain: Task 5 (Mentor relevant individuals) & Task 9 (Manage conflict).

✅ Đáp án ĐÚNG: Adjust the project manager's management style to better fit senior team members.

Lý do lựa chọn 🛠️:
Đây là hành động tối ưu và phù hợp nhất vì PM phải thích ứng phong cách quản lý tình huống (situational leadership) theo mức độ kinh nghiệm của đội ngũ. Với senior members, PM nên chuyển từ directing/controlling sang delegating/empowering, giảm micromanaging để tăng động lực và hiệu quả. Điều này tuân thủ nguyên tắc Servant Leadership trong PMBOK 7th, giúp xây dựng lòng tin và giải quyết khiếu nại gốc rễ. Không hành động này sẽ dẫn đến giảm năng suất và turnover cao.

📋 Giải thích TẤT CẢ các phương án (Đúng & Sai)

• ✅ Adjust the project manager's management style to better fit senior team members.
  Đúng vì: 🏆 Hành động trực tiếp giải quyết vấn đề micromanaging bằng cách điều chỉnh theo Situational Leadership Model (PMBOK 7th, Principle 7: Optimize Risk Responses). Tăng empowerment cho senior, cải thiện hiệu suất ngay lập tức và bền vững.

• ❌ Set up a team building event to bring synergy back to the project team.
  Sai vì: 🧑‍🤝‍🧑 Hoạt động team building tốt cho synergy tổng thể nhưng không giải quyết trực tiếp micromanaging – có thể bị coi là né tránh vấn đề. PMBOK khuyến nghị xử lý conflict cá nhân hóa trước (People Domain, Task 9), không dùng event làm "băng cá nhân".

• ❌ Ask for advice on how to be a better mentor to these team members.
  Sai vì: 👨‍🏫 Việc hỏi lời khuyên mentoring là tích cực nhưng thụ động và gián tiếp, không phải hành động đầu tiên khi biết vấn đề. PM cần tự nhận thức và điều chỉnh ngay (Principle 10: Stakeholders), thay vì chờ feedback bên ngoài – có thể làm chậm trễ giải quyết.

• ❌ Meet daily with each senior team member to monitor project status.
  Sai vì: ⏰ Đây là làm tệ hơn vấn đề micromanaging, tăng gánh nặng và giảm lòng tin. PMBOK 7th (Section 4.6: Manage Project Communications) khuyên dùng status meetings hiệu quả (như agile stand-ups), không phải daily one-on-ones giám sát – vi phạm nguyên tắc holistic thinking và empowerment.

Kết luận 🚀: Câu hỏi kiểm tra khả năng lãnh đạo thích ứng của PM. Chọn đáp án đúng giúp dự án thành công theo 12 Principles of PMBOK 7th! Nếu cần thực hành thêm, tham khảo PMI.org cho Practice Exams.

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

Câu hỏi mô tả một tình huống thực tế trong dự án Agile (sử dụng sprint), nơi một resource quan trọng (critical resource) bị thay thế giữa chừng bởi một intern (thực tập sinh) thiếu kinh nghiệm. Để hỗ trợ intern nhanh chóng làm quen, project manager (PM) giao một senior engineer làm mentor. Tuy nhiên, hai tháng sau, dự án rơi vào tình trạng critical status (nghiêm trọng), dẫn đến trì hoãn milestone release (mốc phát hành) thêm một tháng.

Câu hỏi yêu cầu xác định hành động mà PM nên làm để tránh kịch bản này, nhấn mạnh vào việc quản lý rủi ro nhân sự, đặc biệt trong môi trường Agile nơi tính linh hoạt và hiệu suất đội ngũ rất quan trọng. Theo PMBOK® Guide 7th Edition (2021) và cập nhật đến 2026 (bao gồm Agile Practice Guide), vấn đề cốt lõi là rủi ro thay thế resource critical bằng người thiếu kinh nghiệm, ảnh hưởng đến team performance và sprint velocity. PM cần ưu tiên resource optimization và risk response thay vì chỉ hỗ trợ mentoring tạm thời. 📘 Nguồn: PMBOK® Guide 7th Ed., Principle 9: Optimize Risk Responses; Agile Practice Guide, Ch. 4: Servant Leadership & Team.

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

Đáp án đúng: Requested an experienced resource as a replacement
🛠️ Lý do: Trong quản lý dự án, đặc biệt với critical resource (nguồn lực then chốt quyết định thành công sprint/release), PM phải yêu cầu thay thế bằng resource có kinh nghiệm tương đương để giảm thiểu rủi ro gián đoạn. Việc dùng intern + mentoring chỉ là giải pháp ngắn hạn, không đảm bảo hiệu suất ngay lập tức, dẫn đến delay. Theo PMBOK® 7th Ed., Process 9.2: Manage Project Resources, PM cần acquire resources với competency phù hợp. Trong Agile, duy trì team stability là ưu tiên hàng đầu để tránh "truck factor" (rủi ro mất key member). Hành động này proactive risk mitigation, tránh tình trạng critical status. 📘 Nguồn: PMI Agile Certified Practitioner (PMI-ACP) Handbook 2023; The Standard for Project Management (2021).

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

Dưới đây là phân tích từng phương án, giữ nguyên nội dung tiếng Anh gốc. Mỗi phương án được đánh giá đúng/sai dựa trên nguyên tắc PMP/Agile mới nhất:

• Requested an experienced resource as a replacement
  ✅ Đúng: Như đã giải thích ở trên, đây là best practice để đảm bảo resource parity (sự tương đương nguồn lực), tránh rủi ro delay do thiếu kỹ năng. PM phải escalate yêu cầu với sponsor/stakeholder thay vì chấp nhận intern. 🛡️ Giảm rủi ro cao nhất theo Risk Register.

• Negotiated additional time to complete the project
  ❌ Sai: Việc đàm phán thêm thời gian chỉ là reactive measure (phản ứng sau sự cố), không ngăn ngừa vấn đề từ gốc rễ (thay thế kém). Trong Agile, timeboxing (sprint cố định) ưu tiên delivery nhanh, không nên dễ dàng extend mà không fix cause. Có thể vi phạm triple constraint (scope-time-cost). 📉 Không phù hợp Principle 4: Deliver Value Incrementally (PMBOK 7th).

• Allocated additional time for mentoring
  ❌ Sai: Mentoring là tốt cho knowledge transfer dài hạn, nhưng không hiệu quả cho critical path giữa sprint – intern cần thời gian dài để ramp up, dẫn đến velocity drop và delay (như tình huống). PMBOK khuyến nghị cross-training trước, không dùng làm replacement chính. ⏳ Tăng overhead, không scalable theo Agile metrics.

• Convinced the critical resource to remain on the project
  ❌ Sai: Đây là avoidance không thực tế, vì resource đã rời đi (midway). PM không kiểm soát retention hoàn toàn (thuộc HR/stakeholder). Thay vào đó, cần succession planning (kế hoạch thay thế sẵn). Trong thực tế, ép giữ có thể gây demotivation. 🚫 Không proactive, vi phạm Optimize Resource Allocation.

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

PM cần áp dụng Holistic Resource Management bằng cách identify critical resources sớm trong Develop Team và Plan Risk Responses. Sử dụng RACI matrix để escalate replacement. Trong Agile, ưu tiên pair programming thay vì mentoring đơn lẻ. Học thêm qua PMI.org hoặc PMI-ACP cert để cập nhật 2026! 🚀

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

Câu hỏi thuộc chủ đề Quản lý rủi ro (Uncertainty Domain) và Lập kế hoạch dự án (Planning Performance Domain) trong PMP theo PMBOK Guide 7th Edition (cập nhật đến 2026).

📖 Tình huống: Quản lý dự án (PM) tại một công ty game đang tạo Project Management Plan sau cuộc họp với stakeholders. PM phát hiện đối thủ cạnh tranh sắp ra sản phẩm tương tự, sử dụng công nghệ mới nhất và tốt hơn ở nhiều khía cạnh so với dự án của mình. PM lo ngại (fear) rằng sản phẩm dự án sẽ kém cạnh tranh.

🛠️ Vấn đề cốt lõi: Đây là rủi ro chiến lược bên ngoài (strategic external risk) – không phải rủi ro nội bộ kỹ thuật, mà là mối đe dọa từ thị trường/đối thủ, ảnh hưởng đến giá trị kinh doanh (business value) của sản phẩm. PM cần hành động ngay lập tức trong giai đoạn lập kế hoạch để đảm bảo dự án cạnh tranh và giao giá trị cao. Theo PMBOK 7th Edition (Section 4.6: Planning và Domain 5: Uncertainty), ưu tiên là hợp tác với đội ngũ dự án (project team) để xác định và lập kế hoạch ứng phó rủi ro, thay vì hành động cá nhân hoặc lệch hướng.

✅ Đáp án đúng

Meet with the project team to discuss the concerns and determine how to ensure the project's deliverable can compete with the competitor's.

Lý do chọn đáp án này (🟢 Đúng tuyệt đối):

• Theo PMBOK 7th Edition (Domain 2: Team & Domain 5: Uncertainty), PM phải hợp tác với project team để thảo luận rủi ro, brainstorm giải pháp và đảm bảo deliverable cạnh tranh. Điều này thúc đẩy quyết định dựa trên dữ liệu nhóm (team-based decisions), tận dụng kiến thức đa dạng từ team để điều chỉnh kế hoạch dự án kịp thời.
• Đây là hành động chủ động (proactive) trong Identify Risks & Plan Risk Responses, giúp tối ưu hóa giá trị sản phẩm mà không lệch khỏi phạm vi dự án.
• 📘 Nguồn: PMBOK Guide 7th Edition, p. 97-99 (Team Leadership) & p. 143-147 (Uncertainty); PMI's Agile Practice Guide (2021), nhấn mạnh adaptive planning với team.

📋 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 tiếng Anh. Mỗi phương án được đánh giá dựa trên best practice PMP mới nhất:

• ✅ [ĐÚNG] Meet with the project team to discuss the concerns and determine how to ensure the project's deliverable can compete with the competitor's.
🟢 Đúng vì: Hành động trực tiếp với project team – nhóm chịu trách nhiệm chính cho deliverable. Thảo luận concerns giúp xác định risk response (như innovate features) ngay trong planning phase, đảm bảo alignment với objectives. Đây là value-driven approach (PMBOK 7th, Principle 5: Think Holistically).

• ❌ [SAI] Note this concern in the risk register and meet with the sales team to identify mitigation options factoring in the competitor's offerings.
🔴 Sai vì: Ghi vào risk register là bước thụ động (reactive), không giải quyết ngay lập tức. Gặp sales team (ngoài project team) có thể dẫn đến scope creep hoặc lệch focus, vì sales không kiểm soát deliverable kỹ thuật. PMBOK 7th (Domain 5) yêu cầu team nội bộ dẫn dắt mitigation, không phải cross-functional ngay từ đầu.

• ❌ [SAI] Perform a Kano analysis factoring in the competitor's offering and present it to the stakeholders.
🔴 Sai vì: Kano analysis (phân tích nhu cầu khách hàng: basic/delighter) là công cụ customer-centric hữu ích ở Product Backlog refinement (Agile), nhưng không phải hành động đầu tiên ở đây. Nó tốn thời gian, thiếu team involvement, và trình bày stakeholders có thể gây stakeholder overload trước khi có giải pháp cụ thể. PMBOK 7th ưu tiên team discussion trước analysis chuyên sâu (p. 67, Stakeholder Engagement).

• ❌ [SAI] Meet with the development team to see what changes will improve the project compared to the competition's deliverable.
🔴 Sai vì: Chỉ gặp development team (dev team) là hẹp quá (subset của project team), bỏ qua các thành viên khác như QA, PMO hoặc business analysts. Điều này thiếu holistic view và có nguy cơ bias kỹ thuật. PMBOK 7th (Domain 2: Team) nhấn mạnh toàn project team để đảm bảo changes khả thi về time/cost/scope (Principle 10: Navigate Complexity).

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

Hành động đúng giúp PM chuyển rủi ro thành cơ hội cạnh tranh, phù hợp Outcome-focused mindset (PMBOK 7th Principles). Hãy luôn engage team sớm! Nếu thi PMP, nhớ process groups hybrid với domains (PDU credits đến 2026).

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

• PMBOK Guide 7th Edition (2021, PMI) – Uncertainty & Team Domains.
• The Standard for Project Management (2021).
• PMI Exam Content Outline (2024-2026 updates).

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

Câu hỏi mô tả một dự án dây chuyền sản xuất mới (manufacturing line project) được lập kế hoạch giao hàng theo các iterations (lặp lại, thường thấy trong phương pháp Agile/hybrid) cho giai đoạn lắp đặt thiết bị (equipment installation phase). Trong một iteration, nhà cung cấp (vendor) thông báo không thể giao một số thiết bị đúng hạn đã thỏa thuận (agreed dates).
Vấn đề cốt lõi: Project manager cần quyết định hành động tiếp theo (next step) để xử lý tình huống trì hoãn này một cách chuyên nghiệp, tuân thủ quy trình quản lý mua sắm (Procurement Management) trong PMP. Đây là tình huống kiểm tra khả năng xử lý rủi ro từ nhà cung cấp bên ngoài, ưu tiên các bước hợp đồng trước khi thay đổi kế hoạch dự án.

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

Đáp án đúng: Review the procurement agreements to address the situation.
Lý do: 🛠️ Trong PMP (phiên bản cập nhật 2021-2026), khi gặp vấn đề từ nhà cung cấp như trì hoãn giao hàng, bước đầu tiên phải xem xét lại các thỏa thuận mua sắm (procurement agreements, bao gồm hợp đồng, SOW - Statement of Work, điều khoản giao hàng). Điều này giúp xác định quyền lợi, nghĩa vụ, các biện pháp khắc phục (remedies như phạt chậm trễ, yêu cầu giao bổ sung, hoặc chấm dứt hợp đồng). Việc này thuộc Procurement Performance Domain và quy trình Control Procurements (trong PMBOK 7th Edition), đảm bảo tuân thủ pháp lý trước khi thực hiện hành động lớn hơn. Không xem hợp đồng trước có thể dẫn đến vi phạm hoặc mất quyền lợi dự án.

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên nguyên tắc PMP mới nhất:

• ❌ Find another vendor who can fulfill the delivery dates.
  Sai vì: 🛑 Đây là hành động vội vã, có thể vi phạm hợp đồng hiện tại (như điều khoản độc quyền hoặc phạt chấm dứt). PMP yêu cầu review agreements trước để đánh giá tính khả thi, tránh rủi ro pháp lý và chi phí cao (thay vendor mới cần thời gian tender, đàm phán). Không phải bước "next" ngay lập tức.

• ❌ Replan the remaining iterations according to the new installation dates.
  Sai vì: 🛑 Việc lập kế hoạch lại (replan) iterations còn lại giả định trì hoãn là chắc chắn, nhưng chưa xác nhận nguyên nhân hoặc quyền yêu cầu giao đúng hạn từ vendor. Theo Delivery Performance Domain (PMBOK 7th), phải kiểm soát procurement trước khi điều chỉnh lịch trình, tránh lãng phí nỗ lực nếu vấn đề có thể giải quyết qua hợp đồng.

• ❌ Update the product backlog in order to address the delays.
  Sai vì: ❌ Trong môi trường Agile/iterative (như đề cập iterations và product backlog), việc cập nhật backlog chỉ phù hợp với thay đổi nội bộ sản phẩm, không phải trì hoãn từ vendor bên ngoài. PMP phân biệt rõ: backlog dùng cho user stories/priorities, còn trì hoãn procurement cần Control Procurements trước, không phải chỉnh sửa backlog ngay (có thể làm lệch scope dự án).

• ✅ Review the procurement agreements to address the situation.
  Đúng vì: 🟢 Như đã giải thích ở phần đáp án đúng, đây là bước first response chuẩn mực theo PMBOK Guide 7th Edition (Procurement Performance Domain, trang 99-102) và PMI Agile Practice Guide (xử lý vendor trong hybrid projects). Nó đảm bảo value delivery và risk management mà không nhảy cóc quy trình.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021, cập nhật PMP đến 2026): Procurement Performance Domain (Section 3.5), nhấn mạnh "Review contracts and agreements" khi có deviations từ seller.
• PMI's Process Groups: A Practice Guide: Control Procurements (12.4 trong PMBOK 6th mapping to 7th).
• PMP Exam Content Outline 2021 (Task 4.5: Manage procurement): Prioritize contract review for vendor issues.
  Tài liệu có thể tải tại pmi.org. Nếu áp dụng thực tế, kết hợp công cụ như contract logs và issue logs! 🚀

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

Câu hỏi mô tả tình huống một Project Manager (PM) đang quản lý dự án xây dựng kỹ thuật (engineering construction project). Các kỹ sư tại công trường đang gửi câu hỏi liên quan đến việc thực hiện các hoạt động để đáp ứng thời hạn (timelines), nhưng những hoạt động này có thể ảnh hưởng đến an toàn của đội ngũ lao động (work crew's safety). Khi xem xét, PM nhận ra rằng các kỹ sư không cảm thấy được trao quyền (empowered) để tự đưa ra quyết định.

🛠️ Vấn đề cốt lõi: Đây là tình huống liên quan đến an toàn lao động (safety), trao quyền cho đội ngũ (empowerment), và cân bằng giữa thời gian dự án với giá trị cốt lõi của tổ chức. PM cần hành động để giải quyết, đảm bảo đội ngũ ưu tiên an toàn mà không hy sinh tiến độ, đồng thời khuyến khích họ tự quyết định. Chủ đề thuộc quản lý đội ngũ (team management), lãnh đạo (leadership), và quản lý rủi ro (risk management) theo PMP.

📘 Kiến thức PMP liên quan (cập nhật đến 2026): Dựa trên PMBOK® Guide – Seventh Edition (2021, vẫn là chuẩn mới nhất đến 2026 với các cập nhật PMI Agile Practice Guide và Process Groups), nhấn mạnh 12 Principles như:

• Stewardship: Bảo vệ lợi ích tổ chức và xã hội (an toàn là ưu tiên).
• Team: Xây dựng môi trường trao quyền, hỗ trợ đội ngũ.
• Value: Tối ưu hóa giá trị, không chỉ thời gian mà còn an toàn.
• Optimize Risk Approaches: Xử lý rủi ro an toàn trước tiến độ. Ngoài ra, The Standard for Project Management (2021) nhấn mạnh servant leadership để trao quyền và củng cố tầm nhìn tổ chức.

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

Đáp án đúng: Reinforce to all engineers the company vision of a safety-first approach to project activities.

Lý do 🏆:

• Hành động này củng cố tầm nhìn công ty (company vision) về "an toàn ưu tiên" (safety-first), giúp kỹ sư hiểu rõ giá trị cốt lõi, từ đó trao quyền tự quyết định mà không cần hỏi PM.
• Nó giải quyết gốc rễ vấn đề: Kỹ sư thiếu sự tự tin do chưa rõ ràng về ưu tiên an toàn so với thời hạn.
• Phù hợp Servant Leadership (PMBOK 7th, Principle 9: Leadership), khuyến khích đội ngũ hành động dựa trên giá trị tổ chức, giảm rủi ro an toàn và tăng hiệu quả.
• Không ép buộc thời hạn mà align đội ngũ với value delivery, tránh compromise safety.

🔍 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích lý do dựa trên PMP.

• Consult the previous project manager to discuss how they managed these questions.
  ❌ Sai vì: Phương án này trì hoãn hành động và phụ thuộc vào kinh nghiệm cá nhân của PM trước, không giải quyết gốc rễ (thiếu trao quyền và an toàn). PMP yêu cầu PM hiện tại chủ động lãnh đạo (PMBOK 7th, Principle 1: Be a diligent, respectful, and caring steward), không né tránh trách nhiệm bằng cách hỏi người khác. Điều này có thể dẫn đến lặp lại sai lầm nếu dự án trước không ưu tiên an toàn.

• Email the company vision to the engineers and tell them they need to meet deadlines.
  ❌ Sai vì: Chỉ gửi email tầm nhìn nhưng ép buộc meet deadlines, mâu thuẫn với safety-first, có thể khuyến khích compromise an toàn để kịp tiến độ. PMP nhấn mạnh giao tiếp hai chiều và trao quyền (Standard for Project Management, Engage Stakeholders), không dùng email một chiều để ra lệnh, dễ gây hiểu lầm và giảm động lực đội ngũ (Principle 10: Tailoring).

• Reinforce to all engineers the company vision of a safety-first approach to project activities.
  ✅ Đúng vì: Như đã giải thích ở trên, hành động này củng cố giá trị an toàn, trao quyền cho kỹ sư tự quyết định dựa trên tầm nhìn rõ ràng. Hỗ trợ team empowerment và risk optimization (PMBOK 7th, Principle 7: Optimize risk approaches), đảm bảo value delivery bền vững mà không ảnh hưởng timelines gián tiếp qua quyết định đúng đắn.

• Ensure all engineers are aware that questions should only be submitted in their weekly reports.
  ❌ Sai vì: Phương án này hạn chế giao tiếp (chỉ qua báo cáo hàng tuần), làm chậm phản hồi và tăng rủi ro an toàn khẩn cấp. PMP khuyến khích giao tiếp kịp thời và minh bạch (Project Communications Management, Principle 8: Communicate the value), đặc biệt trong construction nơi an toàn cần hành động ngay. Điều này làm đội ngũ cảm thấy kém trao quyền hơn.

📚 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (PMI, 2021): Principles 1, 7, 9, 10; Models for Team (Empowerment & Safety).
• The Standard for Project Management (PMI, 2021): Servant Leadership & Value Delivery System.
• PMI Code of Ethics & Professional Conduct (2022 cập nhật): Trách nhiệm bảo vệ an toàn (Responsibility standard).
• Tài liệu bổ sung: PMI Practice Standard for Project Configuration Management (safety integration).

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 chủ đề Hybrid Project Management trong PMP (Project Management Professional), tập trung vào sự chuyển đổi từ cách tiếp cận truyền thống (predictive) sang hybrid approach (kết hợp predictive và agile/hybrid).

📖 Tình huống chi tiết:

• Một công ty đang chuyển sang hybrid approach (kết hợp các phương pháp linh hoạt).
• Họ tổ chức capacity-building activities (hoạt động xây dựng năng lực) dành cho tất cả project managers (PM).
• Nội dung đào tạo tập trung vào agile approaches (các cách tiếp cận agile) và team facilitation skills (kỹ năng hỗ trợ/gia tăng hiệu suất đội nhóm).
• Tuy nhiên, khi bước vào implementation phase (giai đoạn thực thi), các PM gặp vấn đề trong việc motivate (động viên) newly hired agile staff (nhân viên agile mới tuyển dụng).

🛠️ Vấn đề cốt lõi: Tại sao PM lại gặp khó khăn trong việc động viên nhân viên agile? Câu hỏi kiểm tra sự hiểu biết về vai trò lãnh đạo trong agile, đặc biệt là sự khác biệt giữa lãnh đạo truyền thống (command-and-control) và lãnh đạo phục vụ (servant leadership), theo PMBOK Guide 7th Edition và Agile Practice Guide (cập nhật mới nhất đến 2026, dựa trên PMP Exam Content Outline 2021+).

✅ Đáp án đúng: The capacity building activities missed the servant leadership concept transfer.

Lý do lựa chọn:

• Trong môi trường hybrid/agile, PM cần chuyển đổi từ vai trò "lãnh đạo chỉ huy" sang servant leadership (lãnh đạo phục vụ) để hỗ trợ đội ngũ tự quản lý (self-organizing teams). Servant leadership nhấn mạnh việc phục vụ đội ngũ, loại bỏ trở ngại, và tạo động lực nội tại thay vì ra lệnh.
• Hoạt động capacity-building chỉ tập trung agile approaches và team facilitation skills, bỏ lỡ (missed) khái niệm servant leadership concept transfer (truyền đạt khái niệm lãnh đạo phục vụ). Do đó, PM chưa được trang bị kỹ năng động viên agile staff – những người quen với môi trường tự chủ, không thích bị "quản lý" theo kiểu truyền thống.
• Điều này phù hợp với 12 Principles of Agile và Servant Leader trong Agile Practice Guide, nơi lãnh đạo phải ưu tiên nhu cầu đội ngũ để tăng motivation.

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

• ❌ [SAI] Project managers are expected to become coaches in agile teams.
  Giải thích sai: Trong agile, coach là vai trò riêng (như Agile Coach), không phải kỳ vọng bắt buộc PM phải trở thành coach. PM trong hybrid chỉ cần hỗ trợ, không thay thế coach. Capacity-building đã bao gồm team facilitation (gần với coaching), nhưng vấn đề không phải ở đây. (Tham khảo: Agile Practice Guide, Principle 11 - Teams).

• ❌ [SAI] The agile staff is not used to being led by a project manager.
  Giải thích sai: Agile staff mới hire có thể quen tự quản lý, nhưng vấn đề gốc rễ là PM thiếu kỹ năng lãnh đạo phù hợp (servant leadership), không phải staff "không quen" với PM. Hybrid approach vẫn cần PM phối hợp, và staff agile có thể thích nghi nếu PM áp dụng đúng cách. Đây là lý do chung chung, không chỉ ra lỗ hổng đào tạo cụ thể.

• ✅ [ĐÚNG] The capacity building activities missed the servant leadership concept transfer.
  Giải thích đúng: Như đã phân tích ở trên, đào tạo bỏ sót servant leadership – yếu tố then chốt để PM motivate agile teams bằng cách phục vụ thay vì kiểm soát. Điều này trực tiếp giải thích vấn đề trong implementation phase. (Tham khảo: PMBOK 7th Ed., Section 4.6 - Leadership: Servant Leadership).

• ❌ [SAI] Transitional periods normally cause this type of problem.
  Giải thích sai: Thời kỳ chuyển tiếp (transitional periods) có thể gây vấn đề chung, nhưng câu hỏi chỉ rõ lý do cụ thể từ capacity-building thiếu nội dung. Đây là đáp án "mơ hồ", không tập trung vào nguyên nhân gốc (missed servant leadership), vi phạm nguyên tắc root cause analysis trong PMP.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Chương 4 (Team) và Appendix X (Agile Hybrid).
• Agile Practice Guide (2021): Phần Servant Leadership và Hybrid Approaches (PMI).
• PMP Examination Content Outline (2021, cập nhật 2026): Domain III - Business Environment (15%), Domain IV - Delivery (50%) – nhấn mạnh leadership trong agile/hybrid.
• Nguồn chính thức: PMI.org (Project Management Institute).

Hy vọng phân tích này giúp bạn ôn tập PMP hiệu quả! 🚀 Nếu cần thêm câu hỏi, 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 Project Manager nhận thấy đội ngũ bị quá tải bởi lượng email lớn hàng ngày, khiến họ không tập trung vào công việc dự án. Một thành viên đội ngũ bày tỏ mong muốn truy cập thông tin liên quan đến dự án khi cần thiết. Câu hỏi yêu cầu xác định loại hình giao tiếp (communication type) mà thành viên này đang đề cập đến.

🛠️ Bối cảnh PMP: Trong quản lý dự án theo PMBOK Guide (7th Edition), giao tiếp được phân loại dựa trên cách thức truyền tải và tiếp cận thông tin. Vấn đề ở đây là email đại diện cho giao tiếp "đẩy" (push), gây quá tải, và nhu cầu là một cách tiếp cận chủ động hơn từ phía người nhận – phù hợp với nguyên tắc Tailoring và Manage Communications (Process 10.2).

✅ Đáp án đúng: Pull communication

Lý do chọn đáp án này:
Thành viên đội ngũ muốn tự truy cập thông tin khi cần (access project-related information when needed), thay vì bị "ép" nhận thông tin qua email hàng loạt. Đây chính là đặc trưng của Pull communication – nơi thông tin được lưu trữ ở một nơi trung tâm (như project portal, intranet, SharePoint, hoặc hệ thống quản lý kiến thức), và người dùng kéo (pull) thông tin về khi họ cần. Điều này giúp giảm tải, tăng hiệu quả, phù hợp với Stakeholder Engagement và Agile/ Hybrid approaches trong PMP mới nhất (đến 2026, nhấn mạnh vào dữ liệu-driven communication).

📘 Tài liệu tham khảo: PMBOK® Guide – Seventh Edition (2021), trang 254-255 (Process 10.1 Plan Communications Management); PMI's Communication Models (Pull: Receiver retrieves information).

📋 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 giữ nguyên nội dung gốc bằng tiếng Anh và giải thích bằng tiếng Việt:

• ✅ Pull communication
  🟢 Đúng: Như đã giải thích, đây là loại giao tiếp cho phép người nhận chủ động truy cập thông tin từ kho lưu trữ (ví dụ: dashboard, wiki dự án). Giải quyết trực tiếp vấn đề quá tải email và nhu cầu "access when needed". Hoàn hảo cho môi trường dự án lớn với dữ liệu phong phú.

• ❌ Mass communication
  🔴 Sai: Đây không phải thuật ngữ chuẩn trong PMP (PMBOK 7th). "Mass" ám chỉ giao tiếp hàng loạt một chiều (như broadcast email hoặc thông báo đại trà), tương tự push nhưng rộng hơn, vẫn gây quá tải như email trong câu hỏi. Không đáp ứng nhu cầu truy cập cá nhân hóa.

• ❌ Interactive communication
  🔴 Sai: Loại này yêu cầu tương tác hai chiều thời gian thực (ví dụ: họp trực tiếp, video call, chat). Câu hỏi không đề cập đến trao đổi tương tác, mà chỉ là truy cập thông tin đơn phương khi cần, không phải thảo luận.

• ❌ Push communication
  🔴 Sai: Đây chính là vấn đề đang xảy ra – gửi thông tin trực tiếp đến người nhận (như email hàng ngày), khiến đội ngũ bị phân tâm. Thành viên muốn tránh loại này, chuyển sang tự truy cập thay vì bị "đẩy" thông tin.

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

Pull communication là giải pháp tối ưu để tối ưu hóa Communications Management Plan. Project Manager nên triển khai công cụ như Microsoft Teams, Jira Dashboard hoặc Confluence để hỗ trợ pull. Áp dụng Data Analysis (Stakeholder Register) để tailoring communication theo nhu cầu đội ngũ.

📘 Nguồn tham khảo bổ sung:

• PMBOK® Guide 7th Edition (PMI, 2021) – Chương 4: Project Communications.
• The Standard for Project Management (2021) – Section 4.6.2 Communication Types.
• PMI Agile Practice Guide (2017, cập nhật hybrid trong 7th Ed.) – Nhấn mạnh pull cho self-service info.

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 case study, 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 xác định rủi ro (Identify Risks) trong quản lý dự án, cụ thể là việc tổ chức một workshop rủi ro cho dự án xây dựng cầu qua sông. 🛤️ Dự án này có tính chất kỹ thuật cao, liên quan đến các rủi ro như địa chất sông ngòi, thời tiết, thiết kế cấu trúc, v.v. Nhóm dự án cần gửi lời mời tham gia workshop để thu thập ý kiến đa dạng, nhằm phát hiện và hiểu rõ rủi ro một cách toàn diện.

Theo PMBOK® Guide – Seventh Edition (2021) và các cập nhật PMP đến 2026 (bao gồm PMI's Risk Management Standard), workshop rủi ro là kỹ thuật brainstorming trong Uncertainty Performance Domain. Các bên tham gia phải bao gồm thành viên nhóm dự án (team members) để hiểu nội bộ, chuyên gia bên ngoài (subject matter experts - SMEs) để có kinh nghiệm chuyên môn, và các bên liên quan chính (stakeholders) như khách hàng (customer) để đảm bảo rủi ro phù hợp với kỳ vọng dự án. 📘 Mục tiêu là tạo danh sách phân phối (distribution list) phù hợp, tránh lãng phí thời gian với những người không liên quan trực tiếp.

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

Đáp án đúng: Team members, consultants from outside the project with experience in the field, and the customer

Lý do: Phương án này hoàn hảo vì bao quát đầy đủ các bên tham gia lý tưởng cho workshop Identify Risks:

• Team members: Cung cấp kiến thức nội bộ về dự án.
• Consultants from outside the project with experience in the field: Là SMEs (chuyên gia bên ngoài) có kinh nghiệm thực tế về xây dựng cầu sông, giúp phát hiện rủi ro chuyên sâu (ví dụ: địa chất, thủy lực).
• Customer: Là stakeholder chính, giúp ưu tiên rủi ro theo nhu cầu kinh doanh và đảm bảo tính khả thi. 🛠️ Theo PMBOK® 6th Ed., 11.2.2.1 và PMBOK® 7th Ed., Uncertainty Domain, đây chính là công thức chuẩn: "project team, subject matter experts, and key stakeholders".

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

• ✅ Team members, consultants from outside the project with experience in the field, and the customer
  Đúng vì: Như đã phân tích ở trên, đây là sự kết hợp lý tưởng giữa nội bộ, chuyên gia bên ngoài và stakeholder chính, đảm bảo workshop hiệu quả và toàn diện. Không thừa, không thiếu! 🎯 (Tham khảo: PMBOK® 7th Ed., Section 4.5.2.1 - Brainstorming techniques).

• ❌ Functional managers, team members, and external consultants with experience in the field
  Sai vì: Functional managers (quản lý chức năng) thường quản lý tài nguyên tổ chức, không tham gia trực tiếp identify risks của dự án cụ thể. Họ có thể hỗ trợ sau (như Acquire Resources), nhưng workshop cần SMEs và stakeholders thực tế hơn. Thiếu customer làm bỏ lỡ góc nhìn kinh doanh. 🧑‍💼 (PMBOK® 7th Ed. nhấn mạnh stakeholders > functional managers ở giai đoạn này).

• ❌ Weather experts, functional managers, and team members
  Sai vì: Weather experts có thể là SME hữu ích cho rủi ro thời tiết (liên quan sông ngòi), nhưng không đại diện toàn bộ rủi ro dự án (như thiết kế, chi phí). Functional managers lại không phù hợp như trên. Thiếu consultants tổng quát và customer, làm workshop quá hẹp và thiếu chiều sâu. 🌤️ (Không khớp với PMBOK® 6th Ed., 11.2.2 - cần diverse participants).

• ❌ Team members, engineers, and weather experts
  Sai vì: Engineers thường là team members rồi (trùng lặp), weather experts chỉ chuyên một khía cạnh (thời tiết), thiếu SMEs rộng (như consultants xây dựng cầu) và đặc biệt thiếu customer/stakeholders. Workshop sẽ thiên về kỹ thuật thuần túy, bỏ qua rủi ro kinh doanh/opportunities. 🔧 (PMBOK® 7th Ed. yêu cầu "broad representation" từ stakeholders).

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

• PMBOK® Guide – Seventh Edition (2021): Uncertainty Performance Domain (Section 4.5), Tools như Brainstorming & Workshops.
• PMBOK® Guide – Sixth Edition (2017): Process 11.2 Identify Risks, Inputs/Participants (11.2.2.1).
• PMI Risk Management Standard (updated 2022): Nhấn mạnh đa dạng participants cho risk workshops.
• Cập nhật PMP Exam Content Outline (2021-2026): 12% People Domain, 50% Process Domain bao gồm Risk Management.

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 nội dung câu hỏi

Câu hỏi này thuộc lĩnh vực Agile/Scrum trong PMP (Project Management Professional), tập trung vào quy trình Sprint Planning trong môi trường Scrum. 📘

• Bối cảnh: Một sales manager gửi yêu cầu tính năng mới cho Product Owner (PO), và nó đã được thêm vào Product Backlog. Trong Sprint Planning Meeting, đội ngũ phát triển (Development Team) gặp khó khăn khi quyết định thuật toán (algorithm) hiệu quả nhất để triển khai. Đội ngũ nhận thấy cần công việc phát triển (development work) để đánh giá và quyết định.
• Vấn đề cốt lõi: Project Manager (PM) cần hỗ trợ đội ngũ tự quản lý (self-organizing team) mà không can thiệp sai quy trình Scrum. Theo PMBOK Guide 7th Edition và Agile Practice Guide (cập nhật đến 2023, áp dụng đến 2026), trong Scrum, đội ngũ tự quyết định cách thực hiện công việc từ Product Backlog, và Sprint Planning là nơi phân tích User Story chi tiết, có thể tạo Spike (công việc nghiên cứu/phát triển thử nghiệm) để giải quyết uncertainty.
• Mục tiêu: PM phải thúc đẩy đội ngũ pull work vào Sprint Backlog một cách phù hợp, đảm bảo Sprint Goal đạt được mà không làm gián đoạn quy trình tự tổ chức. 🛠️

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

Đáp án đúng: Create a new item in the sprint backlog to determine the appropriate algorithm.

Lý do (theo Scrum Guide 2020 và Agile Practice Guide PMP):

• Trong Sprint Planning, đội ngũ tự quyết định Sprint Backlog bằng cách phân tích Product Backlog Items (PBIs). Nếu cần nghiên cứu kỹ thuật (như chọn algorithm), tạo Spike Task/Story (một item tạm thời trong Sprint Backlog) là cách chuẩn để đội ngũ tự thực hiện "development work" cần thiết.
• Điều này tuân thủ nguyên tắc self-organizing team (PMBOK 7th: Principle 4 - Team), giúp giải quyết uncertainty mà không cần external intervention. PM chỉ facilitate chứ không dictate.
• Spike giúp ước lượng tốt hơn cho tương lai, tránh "analysis paralysis" trong planning. 📈

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

Dưới đây là giải thích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên Scrum roles/responsibilities và PMP Agile domains (Team, Delivery, Uncertainty).

• Ask the scrum master to choose an algorithm based on the pros and cons of each option.
  ❌ Sai: Scrum Master (SM) là servant-leader và facilitator, không phải decision-maker về technical details như chọn algorithm (Scrum Guide: SM removes impediments, không assign technical choices). Việc PM giao SM quyết định vi phạm self-organizing team, có thể dẫn đến dependency và giảm team ownership (PMBOK 7th: Value - Optimize Risk Responses).

• Request a meeting with the product owner to help clarify the user story.
  ❌ Sai: Vấn đề không phải clarify User Story (đã ở Product Backlog và đang planning), mà là technical decision cần development work (algorithm efficiency). PO chịu trách nhiệm prioritize và clarify what, không phải how (technical implementation - Scrum Guide). Gặp PO thêm chỉ làm chậm Sprint Planning, không giải quyết root cause (Agile Principle: Working software over documentation).

• Invite the sales manager to the next sprint meeting to clarify requirements.
  ❌ Sai: Sales manager là external stakeholder, không tham gia Sprint Meetings (Daily Scrum là internal team - Scrum Guide). "Next sprint meeting" mơ hồ và không đúng lúc (Sprint Planning đang diễn ra). Clarify requirements thuộc PO responsibility, không phải sales manager xen vào team events, vi phạm protected team time (PMBOK 7th: Hybrid Delivery - Protect the Team).

• ✅ Create a new item in the sprint backlog to determine the appropriate algorithm.
  (Đã giải thích ở phần đáp án đúng).

📚 Tài liệu tham khảo

• Scrum Guide 2020 (Ken Schwaber & Jeff Sutherland): Phần Sprint Planning và Sprint Backlog (trang 9-11).
• PMBOK Guide 7th Edition (2021): Principle 4 (Team & Individuals), Agile Hybrid Approaches (Section 4.5).
• Agile Practice Guide (PMI, 2017 - cập nhật tích hợp PMBOK 7): Chapter 5 - Implementing Agile: Spikes & Technical Debt (trang 45-47).
• Kiến thức PMP mới nhất (2026): Không thay đổi cốt lõi Scrum, nhấn mạnh Outcome-focused và Adaptive Planning trong certification exams.

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 xoay quanh một dự án lai (hybrid project) mới bắt đầu, nhằm phát triển một công nghệ mới có tiềm năng phá vỡ thị trường nếu được công chúng chấp nhận. Sản phẩm cần giấy phép phê duyệt sức khỏe và an toàn từ chính phủ. Vì đây là giải pháp sáng tạo, nhà tài trợ (sponsor) và chủ sở hữu sản phẩm (product owner) không chắc chắn về mức độ chấp nhận từ công chúng.
📌 Mục tiêu chính: Xác định luồng phát triển sản phẩm phù hợp (appropriate flow for product development) trong bối cảnh hybrid, nơi kết hợp yếu tố dự đoán (predictive) và linh hoạt (adaptive/agile), đặc biệt với rủi ro cao về chấp nhận thị trường và yêu cầu quy định pháp lý.
🛠️ Theo PMBOK® Guide 7th Edition (2021) và Standard for Project Management (2021) cập nhật đến 2026, hybrid approach nhấn mạnh giao giá trị nhanh chóng (deliver value early), thử nghiệm thất bại nhanh (fail fast), và phản hồi sớm từ stakeholder để giảm thiểu rủi ro không chắc chắn (uncertainty), đặc biệt trong Tailoring (chọn phương pháp phù hợp theo ngữ cảnh dự án sáng tạo).

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

Đáp án đúng:
Complete development for the must-have functionalities only prior to demonstration in order to fail fast and get early feedback.

Lý do chi tiết:
🧩 Trong dự án hybrid với sản phẩm đổi mới cao và không chắc chắn về chấp nhận công chúng, cần áp dụng MVP (Minimum Viable Product) – chỉ phát triển chức năng thiết yếu (must-have) để demo sớm, nhằm thất bại nhanh (fail fast) và thu phản hồi sớm (early feedback) từ stakeholder bên ngoài. Điều này phù hợp với nguyên tắc Agile Hybrid trong PMBOK 7th: ưu tiên iterative development, customer collaboration, và experimental mindset để validate market fit trước khi đầu tư lớn. Việc sớm lấy feedback giúp điều chỉnh kịp thời, giảm rủi ro, đồng thời chuẩn bị cho phê duyệt chính phủ sau khi có dữ liệu thực tế.
📘 Nguồn tham khảo: PMBOK® Guide 7th Edition (Section 2.5 Tailoring & Section 4.6 Iterative Development); Agile Practice Guide (Principle 3: Deliver Value Incrementally & Principle 7: Optimize Flow).

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

• Complete development with all functionalities in perfect condition prior to demonstrating to stakeholders to ensure a great first impression.
  ❌ Sai: Phương án này theo waterfall thuần túy (big bang approach), hoàn thành toàn bộ chức năng "hoàn hảo" trước khi demo – trái ngược hybrid/agile. Nó tăng rủi ro chậm trễ giao giá trị, chi phí cao, và không fail fast khi uncertainty cao về thị trường. PMBOK 7th khuyến cáo tránh "perfect engineering" ở giai đoạn đầu để ưu tiên feedback sớm (Principle 10: Focus on Value).

• Complete development for the must-have functionalities only prior to demonstration in order to fail fast and get early feedback.
  ✅ Đúng: Như đã giải thích ở trên, đây là MVP approach lý tưởng cho hybrid project sáng tạo, thúc đẩy fail fast & early feedback từ public/stakeholder, giảm uncertainty và hỗ trợ iterative tailoring. Hoàn toàn phù hợp PMBOK 7th (Hybrid Delivery).

• Complete development for each sprint and demonstrate the product increment to internal stakeholders and the government, without engaging other external stakeholders.
  ❌ Sai: Mặc dù dùng sprint (agile), nhưng chỉ demo internal + government, bỏ qua external stakeholders (như public/focus group) – vi phạm Stakeholder Engagement toàn diện (PMBOK 7th, Domain 9). Dự án cần feedback thị trường sớm để validate acceptance, không chỉ nội bộ/quy định. Thiếu external engagement làm tăng rủi ro "build it and they will come" thất bại.

• Complete development for must-have functionalities only and demonstrate it to a focus group, but wait until all development is complete to demonstrate it to the government.
  ❌ Sai: MVP + focus group tốt cho feedback thị trường, nhưng chờ hoàn tất toàn bộ để demo chính phủ là sai lầm – làm chậm quy trình phê duyệt (regulatory approval cần sớm để tránh pivot lớn). Hybrid yêu cầu parallel processing (phát triển + validation song song), không sequential như vậy (PMBOK 7th, Principle 5: Holistic Thinking).

Kết luận tổng quát 🎯: Hybrid project ưu tiên experimental & iterative flow để quản lý uncertainty, đảm bảo value delivery và stakeholder collaboration từ sớm. Áp dụng kiến thức này giúp PMP pass exam dễ dàng! 🚀