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ả một tình huống trong dự án Agile: Một đội ngũ dự án Agile nhận nhiệm vụ phát triển hệ thống công nghiệp kết nối với robot (interfaces with robots). Đội ngũ không có kinh nghiệm trước đó về loại công việc này. Các thành viên rất hào hứng học hỏi để có chuyên môn, nhưng điều này có thể gây chậm trễ dự án.
🛠️ Vấn đề cốt lõi: Làm thế nào để xử lý tình huống này mà vẫn tuân thủ nguyên tắc Agile (tập trung vào đội ngũ tự tổ chức, học hỏi liên tục, kiến thức chia sẻ nội bộ, và phát triển năng lực đội ngũ) theo PMBOK Guide 7th Edition (2021) và Agile Practice Guide? Không nên outsource để tránh mất kiểm soát và cơ hội phát triển đội ngũ.

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

Đáp án đúng: Add an experienced professional to the team to reinforce knowledge sharing and help grow team expertise in the new product.
Lý do:

• Trong Agile, đội ngũ cần cross-functional (đa kỹ năng) và tự phát triển thông qua knowledge sharing (chia sẻ kiến thức). Thêm chuyên gia vào đội ngũ giúp mentor (hướng dẫn) trực tiếp, xây dựng năng lực lâu dài mà không làm gián đoạn đội ngũ.
• Điều này phù hợp 12 Nguyên tắc Agile: "Build projects around motivated individuals. Give them the environment and support they need" và ưu tiên học hỏi nội bộ thay vì outsource.
• Theo PMBOK 7th Edition - Principle 9: Team và Developing the Team domain trong PMP Exam Content Outline 2021 (cập nhật đến 2026), khuyến khích coaching/mentoring để phát triển đội ngũ, giảm rủi ro chậm trễ lâu dài.
  📘 Nguồn tham khảo: PMBOK Guide 7th Edition (trang 47-50, Team Principle); Agile Practice Guide (Section 5.3, Team Formation).

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

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

• ❌ [SAI] Hire a consulting company to address the robotic interface questions, when necessary, and to help avoid delays and quality issues.
  Giải thích: Thuê công ty tư vấn bên ngoài (external consulting) làm giảm tính tự chủ của đội ngũ Agile, tạo phụ thuộc và chi phí cao. Agile ưu tiên nội bộ hóa kiến thức thay vì "khi cần" gọi bên ngoài, vì điều này cản trở phát triển đội ngũ và có thể gây chậm trễ do phối hợp. Không phù hợp Servant Leadership (hỗ trợ đội ngũ tự học).

• ✅ [ĐÚNG] Add an experienced professional to the team to reinforce knowledge sharing and help grow team expertise in the new product.
  Giải thích: Như đã nêu ở trên, đây là cách tối ưu để pairing/mentoring (làm việc đôi/hướng dẫn), giúp đội ngũ học nhanh, chia sẻ kiến thức thực tế và duy trì động lực. Hỗ trợ Experimentation & Adaptation trong Agile, giảm rủi ro delay mà vẫn xây dựng chuyên môn nội bộ.

• ❌ [SAI] Create a separate team with experienced members who understand the technology and split the product backlog according to team specialization.
  Giải thích: Tạo đội ngũ riêng và chia backlog vi phạm nguyên tắc một đội ngũ duy nhất (whole team approach) trong Agile, dẫn đến silos (khoảng cách), giao tiếp kém và phức tạp quản lý. Agile khuyến khích cross-functional team thay vì chuyên môn hóa riêng lẻ (PMBOK 7th - Holistic Thinking).

• ❌ [SAI] Use a robotics vendor company to develop the interfaces so the team will not be held back by a lack of expertise in this type of work.
  Giải thích: Outsource cho nhà cung cấp (vendor) làm mất cơ hội học hỏi của đội ngũ, tạo rủi ro tích hợp và phụ thuộc bên ngoài. Agile ưu tiên kiểm soát nội bộ và continuous improvement, không "tránh né" bằng cách giao phó (theo Scrum Guide 2020 & Agile Manifesto Value 1: Individuals over tools).

🛠️ Kết luận: Phương án đúng nhấn mạnh phát triển đội ngũ nội bộ, phù hợp xu hướng PMP 2021+ (50% Agile content), giúp dự án bền vững và thích ứng cao. Nếu áp dụng, theo dõi qua ** retrospectives** để đánh giá hiệu quả!
📘 Tài liệu chính: PMBOK Guide 7th Edition (2021), PMP Exam Content Outline (PMI.org, cập nhật 2024), Scrum Guide (2020).

🧩 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) đang họp với Project Sponsor về dự án mới. PM đề xuất gửi email hàng tuần theo Communications Management Plan để cập nhật tiến độ dự án, giúp sponsor nắm bắt tình hình. Tuy nhiên, sponsor từ chối vì họ chỉ muốn yêu cầu cập nhật khi cần thiết. Câu hỏi yêu cầu PM nên làm gì tiếp theo để xử lý tình huống này một cách chuyên nghiệp.
🛠️ Mục tiêu chính: Áp dụng quy trình Manage Communications (Quản lý Truyền thông) trong PMBOK® Guide 7th Edition, nhấn mạnh việc tùy chỉnh giao tiếp dựa trên nhu cầu của stakeholder (sponsor là stakeholder quan trọng nhất), đảm bảo thông tin phù hợp, kịp thời và hiệu quả, tránh lãng phí thời gian hoặc bỏ lỡ thông tin quan trọng.

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

Đáp án đúng: Ask the project sponsor what sort of information is needed and agree on a frequency for the communication.
Lý do: Theo PMBOK® 7th Edition (Process 10.2: Manage Communications), PM phải elicit (khai thác) nhu cầu thông tin từ stakeholder và thỏa thuận tần suất giao tiếp phù hợp, thay vì áp đặt kế hoạch một chiều. Điều này thể hiện nguyên tắc Tailoring (tùy chỉnh), Stakeholder Engagement (tương tác stakeholder), và Value Delivery (mang lại giá trị). Việc hỏi rõ loại thông tin cần và tần suất giúp xây dựng Communications Management Plan linh hoạt, tăng sự hài lòng của sponsor mà vẫn đảm bảo kiểm soát dự án. ✅ Hoàn hảo cho tình huống này!

📋 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 giá dựa trên PMBOK® 7th Edition (2021) và các nguyên tắc PMP mới nhất đến 2026 (vẫn dựa trên 7th Edition với các cập nhật hybrid/agile).

• ✅ Ask the project sponsor what sort of information is needed and agree on a frequency for the communication.
  Giải thích đúng: Phương án này proactive và hợp tác, phù hợp với Data Gathering (thu thập dữ liệu từ stakeholder) và Manage Stakeholder Engagement (Process 13.3). PM không loại bỏ giao tiếp mà tùy chỉnh để phù hợp nhu cầu, tránh rủi ro thiếu thông tin quan trọng. Đây là best practice để cập nhật Communications Management Plan (Output của Plan Communications Management - Process 10.1). 📘 Tham khảo: PMBOK® 7th Ed., Principle 6: Optimize Risk Responses & Principle 9: Leadership.

• ❌ Agree to the project sponsor’s request, but continue to copy them on the weekly email so they can be informed of progress in case it is needed.
  Giải thích sai: Phương án này không tôn trọng ý kiến sponsor, vi phạm nguyên tắc Stakeholder Engagement (xây dựng lòng tin). Việc "tiếp tục copy" có thể gây information overload (quá tải thông tin), làm giảm hiệu quả giao tiếp và lãng phí tài nguyên. PMBOK nhấn mạnh effective communication phải relevant và timely, không phải "just in case". 🛑 Rủi ro: Giảm sự hài lòng của sponsor.

• ❌ Tell the project sponsor that if they prefer to not receive the communication, there is no problem in removing them from the email distribution.
  Giải thích sai: Phương án này thụ động và rủi ro cao, vì sponsor có thể bỏ lỡ thông tin critical (như thay đổi scope, rủi ro lớn). Communications Management Plan yêu cầu all key stakeholders được thông tin hóa, đặc biệt sponsor (người phê duyệt). Việc loại bỏ hoàn toàn vi phạm Monitor Communications (Process 10.3) và Escalation Process. ❌ Không đảm bảo project governance!

• ❌ Advise the project sponsor to request a 15-minute meeting, whenever necessary, with prior notification.
  Giải thích sai: Phương án này không hiệu quả và thiếu chủ động, đẩy trách nhiệm hoàn toàn cho sponsor (pull communication thay vì push). PMBOK khuyến nghị hybrid approach nhưng phải agree on method & frequency trước, không phải để sponsor "yêu cầu khi cần". Điều này có thể gây delay trong decision-making, vi phạm Principle 4: Build a Team & Principle 10: Adaptability. 🕒 Tốn thời gian hơn email tùy chỉnh!

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (Project Management Institute, 2021): Chương 4 (Project Communications), Process 10.1-10.3 (Communications Management Knowledge Area).
• PMP Exam Content Outline (PMI, 2021 - cập nhật 2024): Domain III: Business Environment (Stakeholder Engagement), Domain IV: Deliver and Manage (Communications).
• The Standard for Project Management (PMBOK 7th): 12 Principles, đặc biệt Principle 9 (Leadership) và Principle 11 (Thinking Broadly).
  🛠️ Lời khuyên PMP: Luôn document thỏa thuận giao tiếp vào Issue Log hoặc Change Request để traceability. Nếu agile/hybrid, áp dụng Information Radiator thay thế email!

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

Câu hỏi mô tả tình huống trong giai đoạn thực thi (execution) của dự án, nơi có nhiều đội giao hàng (multiple delivery teams). Một team lead đang tự phát hành các báo cáo cập nhật tình trạng (status updates) mà không thảo luận trước với project manager (PM). Điều này gây lo ngại cho stakeholders vì thiếu sự đồng bộ (nonalignment), khi các đội khác không làm tương tự.
Câu hỏi yêu cầu: Project manager nên làm gì để xử lý tình huống này?
🛠️ Bối cảnh PMP (theo PMBOK 7th Edition, cập nhật đến 2026): Trong quản lý dự án hiện đại, PM cần ưu tiên nguyên tắc lãnh đạo phục vụ (servant leadership), hiểu vấn đề gốc rễ (root cause analysis), và quản lý giao tiếp (Manage Communications) theo Process Groups. Không nên hành động vội vã mà phải khuyến khích hợp tác, minh bạch từ đội ngũ.

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

Đáp án đúng: Discuss with the team lead to understand the reason for the report.

Lý do:
PM cần bắt đầu bằng đối thoại trực tiếp với team lead để hiểu lý do đằng sau hành động này (có thể là sáng kiến tốt, nhu cầu thực tế từ đội ngũ, hoặc vấn đề giao tiếp chưa rõ ràng). Điều này phù hợp với 12 nguyên tắc PMP (PMBOK 7th) như Team (hợp tác đội ngũ), Stakeholders (quản lý kỳ vọng), và Adaptability (linh hoạt). Hành động này giúp PM thu thập thông tin đầy đủ trước khi quyết định, tránh xung đột không cần thiết, và có thể tích hợp báo cáo vào kế hoạch giao tiếp chính thức. 📘 Nguồn: PMBOK Guide 7th Edition (2021), Principle 5: Team & Principle 9: Quality; Process: Manage Project Knowledge & Manage Communications.

📋 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) hoặc ❌ (sai), kèm lý do dựa trên thực tiễn PMP.

• Instruct the team lead to stop sending the update report.
  ❌ Sai: Lệnh dừng ngay lập tức thể hiện phong cách lãnh đạo chỉ huy (command-and-control), vi phạm nguyên tắc Value (tạo giá trị) và Leadership (khuyến khích sáng tạo). Báo cáo có thể mang lại lợi ích (như minh bạch nhanh), PM cần hiểu trước thay vì cấm đoán, tránh làm giảm động lực đội ngũ.

• Discuss with the team lead to understand the reason for the report.
  ✅ Đúng: Như đã giải thích ở trên. Đây là bước first response lý tưởng, thúc đẩy high-performing team qua giao tiếp hai chiều, giúp align với Stakeholder Engagement Plan. 🛠️ Hiệu quả cao trong môi trường Agile/hybrid.

• Examine the project reporting requirements with the stakeholders.
  ❌ Sai: Tập trung vào stakeholders trước bỏ qua nguồn gốc vấn đề từ team lead, có thể làm tình hình phức tạp hơn (stakeholders lo lắng thêm). PM phải proactive với đội ngũ trước, theo Tailoring (tùy chỉnh quy trình), không phải phản ứng thụ động.

• Tell the other team leads to provide similar update reports.
  ❌ Sai: Mở rộng vấn đề mà chưa xác minh giá trị của báo cáo gốc, dẫn đến scope creep trong giao tiếp hoặc lãng phí tài nguyên. Vi phạm Stewardship (quản lý trách nhiệm), PM cần đánh giá trước thay vì copy-paste hành động không được phê duyệt.

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

• PMBOK Guide 7th Edition (2021): Domain V: Project Communications (trang 89-102); Principles như Team, Stakeholders, Adaptability.
• PMI Agile Practice Guide (2021): Nhấn mạnh iterative communication và team empowerment.
• PMP Exam Content Outline (2021, cập nhật 2024-2026): Task 8.1 (Manage Communications) & Task 9.2 (Engage Stakeholders).
  🧩 Lời khuyên PMP: Luôn ưu tiên hiểu vấn đề trước hành động để xây dựng lòng tin và tối ưu hóa kết quả dự án!

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

Câu hỏi này thuộc chủ đề Quản lý Bên liên quan (Stakeholder Management) trong PMP, tập trung vào việc xử lý hiệu quả một lượng lớn bên liên quan (stakeholders) có mức độ tham gia khác nhau vào hệ thống dự án. Tình huống: Nhóm dự án tiếp xúc với nhiều bên liên quan sẽ vận hành hệ thống, nhưng cần giảm thiểu số lượng tương tác để đảm bảo hiệu quả, đồng thời giữ tinh thần hợp tác. Câu hỏi nhấn mạnh hành động đầu tiên (first) mà người quản lý dự án (PM) nên thực hiện.
Mục tiêu chính: Tối ưu hóa giao tiếp bằng cách phân loại và điều chỉnh mức độ tương tác phù hợp, tránh lãng phí thời gian với tất cả stakeholders một cách đồng đều. Đây là nguyên tắc cốt lõi trong Stakeholder Engagement theo PMBOK® Guide 7th Edition (2021) và các cập nhật PMP đến 2026, nơi ưu tiên phân tích để cá nhân hóa engagement thay vì tiếp cận đại trà.

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

Đáp án đúng: Perform a stakeholder analysis to define the level of engagement of each stakeholder and act accordingly.

Lý do:
🛠️ Theo PMBOK® Guide 7th Edition (Domain: Stakeholder), bước đầu tiên để quản lý stakeholders hiệu quả là thực hiện phân tích bên liên quan (Stakeholder Analysis). Phân tích này giúp phân loại stakeholders theo các tiêu chí như quyền lực (power), mức độ quan tâm (interest), ảnh hưởng (influence) và mức độ hỗ trợ (support), từ đó xác định mức độ tham gia (engagement level) phù hợp (ví dụ: Keep Satisfied, Manage Closely, Monitor...).
Điều này giảm thiểu tương tác không cần thiết (chỉ engage sâu với stakeholders quan trọng) mà vẫn duy trì tinh thần hợp tác bằng cách hành động phù hợp (act accordingly). Nếu bỏ qua bước này, PM sẽ lãng phí nguồn lực. Đây là nguyên tắc Tailor Engagement trong PMP Exam Content Outline 2021 (cập nhật 2026 không thay đổi cốt lõi).
📘 Nguồn tham khảo: PMBOK® Guide 7th Edition, trang 135-140 (Stakeholder Engagement); PMP Examination Content Outline, Domain 9: Engagement.

📋 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 dựa trên quy trình PMP chuẩn (ưu tiên hành động đầu tiên và hiệu quả).

• Perform a stakeholder analysis to define the level of engagement of each stakeholder and act accordingly.
  ✅ Đúng vì đây là bước đầu tiên và nền tảng trong quy trình Identify Stakeholders & Analyze (PMBOK® 7th). Nó cho phép PM phân loại nhanh chóng để giảm tương tác (ví dụ: chỉ meet sâu với high-power stakeholders), giữ hiệu quả và hợp tác. Không làm bước này trước sẽ dẫn đến tiếp cận sai lầm.

• Meet with the stakeholders, document their needs, and agree on the pace and channel of communication.
  ❌ Sai vì hành động này quá sớm và không hiệu quả với "large number of stakeholders". Gặp tất cả để document needs trước khi phân tích sẽ tăng tương tác không cần thiết, vi phạm nguyên tắc "minimize interactions". Nên làm sau stakeholder analysis (PMBOK® 7th, Prioritize Stakeholders).

• Host regular meetings with all stakeholders to keep them engaged and get their feedback.
  ❌ Sai vì tổ chức họp định kỳ với tất cả sẽ tăng gấp đôi tương tác, trái ngược mục tiêu "minimize the number of interactions". Đây là cách không hiệu quả cho stakeholders có engagement thấp (Monitor only), dễ gây mệt mỏi và lãng phí (Stakeholder Engagement Models, PMBOK® 7th).

• Meet with all of the stakeholders separately, build a relationship with them, and learn about their needs.
  ❌ Sai vì gặp riêng từng người với tất cả là tốn kém thời gian nhất, không khả thi với "large number". Xây dựng relationship là tốt nhưng phải sau phân loại; nếu không, PM sẽ kiệt sức và không giữ được collaborative spirit lâu dài (Efficiency Principle in Agile Hybrid, PMBOK® 7th).

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

🧩 Bài học chính: Luôn bắt đầu bằng Stakeholder Analysis để tailor engagement – đây là "first thing" trong mọi tình huống đa dạng stakeholders. Thực hành qua PMP mocks để nắm vững!
📘 Tài liệu bổ sung: The Standard for Project Management (Companion to PMBOK® 7th), Agile Practice Guide; PMI.org updates đến 2026.

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

Câu hỏi này xoay quanh tình huống thực tế trong quản lý dự án PMP: Một nhà cung cấp (supplier) được giao nhiệm vụ cung cấp linh kiện quan trọng cho dự án không thể giao hàng do vấn đề lao động quy mô lớn (large-scale labor problem). Đây là một vấn đề (issue) đang xảy ra thực tế, ảnh hưởng trực tiếp đến tiến độ dự án.

Project Manager (PM) cần cập nhật chi tiết vấn đề và giao tiếp với các bên liên quan (stakeholders) một cách chính thức. Theo PMBOK Guide (phiên bản 7th Edition và cập nhật đến 2026), đây thuộc quy trình Monitor and Control Project Work (giám sát và kiểm soát công việc dự án), nơi PM phải ghi nhận, theo dõi và báo cáo các vấn đề phát sinh để đảm bảo tính minh bạch và phối hợp hành động kịp thời. 🛠️ Vấn đề này không phải rủi ro tiềm ẩn mà là sự cố đã xảy ra, đòi hỏi công cụ phù hợp để log (ghi nhật ký) và communicate (giao tiếp).

✅ Đáp án đúng: Issue log

Lý do lựa chọn: Issue log là tài liệu chính thức dùng để ghi nhận, theo dõi, ưu tiên và giao tiếp các vấn đề (issues) đang ảnh hưởng đến dự án. Trong tình huống này, PM cập nhật chi tiết vấn đề (nguyên nhân: labor problem; tác động: chậm trễ linh kiện) vào Issue log, chỉ định owner chịu trách nhiệm giải quyết, và chia sẻ với stakeholders để phối hợp (ví dụ: tìm supplier thay thế). Điều này đảm bảo traceability (khả năng truy vết) và hỗ trợ ra quyết định nhanh chóng theo nguyên tắc value delivery trong PMBOK 7th. 📈

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

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

• ❌ Project schedule
  Phương án này sai vì Project schedule chỉ dùng để cập nhật thời gian, milestone và dependencies (lịch trình dự án), không phải để ghi chi tiết vấn đề cụ thể như nguyên nhân labor problem hay giao tiếp stakeholders. Nếu dùng schedule, chỉ cập nhật delay (trễ nãi) nhưng thiếu phần theo dõi giải quyết issue. 🕒

• ✅ Issue log
  Phương án này đúng như đã giải thích ở trên. Issue log bao gồm các trường: mô tả issue, tác động, owner, status, và resolution plan. Đây là công cụ chuẩn trong Project Issue Management để đảm bảo vấn đề được xử lý chủ động và minh bạch. 🗂️

• ❌ Risk register
  Phương án này sai vì Risk register dành cho rủi ro tiềm ẩn (risks) chưa xảy ra (pre-planned), với probability/impact analysis. Vấn đề labor problem đã xảy ra thực tế, nên không log vào đây mà chuyển thành realized risk thành issue. Sử dụng sai sẽ làm lẫn lộn giữa proactive risk management và reactive issue management. ⚠️

• ❌ Change request
  Phương án này sai vì Change request chỉ dùng để yêu cầu thay đổi chính thức (scope, schedule, cost) qua Perform Integrated Change Control. Ở đây, PM chưa cần thay đổi mà chỉ cập nhật và giao tiếp issue trước; change request sẽ được tạo sau nếu cần (ví dụ: approve supplier mới). 📝

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật PMI đến 2026): Phần Project Monitoring and Controlling (trang 127-130), Issue Log là công cụ trong Manage Project Knowledge và Monitor Risks/Projects.
• PMI Process Groups: A Practice Guide (2022): Nhấn mạnh Issue Log cho stakeholder communication trong agile/hybrid projects.
• PMP Exam Content Outline (2024-2026): Domain 3: Business Environment (15%), Domain 4: Delivery (50%) – Tập trung vào issue tracking để maintain value.

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ụ case study, hãy hỏi nhé!

🧩 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 phát triển phần mềm: Project manager đang quản lý dự án, một stakeholder quan trọng phàn nàn vì không nhận được báo cáo tình trạng kiểm thử chức năng (functionality test status reports). Khi project manager cung cấp báo cáo, stakeholder phát hiện ra rằng một chức năng quan trọng dành cho lĩnh vực của họ chưa được kiểm thử.
📌 Vấn đề cốt lõi: Project manager đã bỏ lỡ việc xác định và đáp ứng nhu cầu thông tin cụ thể của stakeholder, dẫn đến thiếu giao tiếp và kiểm soát phạm vi kiểm thử. Câu hỏi yêu cầu xác định công cụ (tool) nào project manager nên sử dụng để ngăn chặn tình huống này từ đầu, tập trung vào việc quản lý stakeholder và giao tiếp sớm.

✅ Đáp án đúng: Stakeholder register

Lý do lựa chọn:
Stakeholder register là công cụ chính để xác định, phân loại và ghi nhận thông tin chi tiết về tất cả stakeholders, bao gồm nhu cầu thông tin cụ thể (như báo cáo test status), mức độ quan tâm, ảnh hưởng, và yêu cầu giao tiếp (communication requirements). Nếu sử dụng từ đầu, project manager có thể:

• 🛠️ Xác định stakeholder này cần báo cáo chức năng cụ thể.
• 📊 Theo dõi và đảm bảo chức năng quan trọng được đưa vào kế hoạch kiểm thử (test plan).
• 🔄 Ngăn chặn khiếu nại bằng cách gửi báo cáo đúng hạn và đúng nội dung.
  Điều này phù hợp với quy trình Identify Stakeholders trong PMBOK, giúp tránh rủi ro từ sự thiếu đồng bộ giữa kỳ vọng stakeholder và thực tế 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 một cách logic, dựa trên PMBOK Guide 7th Edition (2021) và các cập nhật PMP đến 2026, nhấn mạnh vai trò của từng tool trong quản lý dự án. Lưu ý: Stakeholder register vẫn là khái niệm cốt lõi từ PMBOK 6th Edition (Section 13.1), được tích hợp vào Stakeholder Performance Domain trong 7th Edition.

• ❌ Issue log
  Phân tích sai: Issue log dùng để ghi nhận, theo dõi và giải quyết các vấn đề (issues) phát sinh trong dự án, như tranh chấp hoặc trở ngại đang xảy ra. Nó không dùng để ngăn ngừa từ đầu bằng cách xác định nhu cầu stakeholder hay báo cáo. Trong tình huống này, issue log chỉ hữu ích sau khi khiếu nại xảy ra (reactively), không phải proactive như cần thiết. (PMBOK 7th: Issue & impediment log trong Monitoring & Controlling).

• ❌ Project scope statement
  Phân tích sai: Project scope statement mô tả phạm vi dự án chi tiết, bao gồm deliverables, assumptions, constraints và exclusions. Nó giúp xác định chức năng nào cần test, nhưng không tập trung vào nhu cầu giao tiếp hay báo cáo của từng stakeholder cá nhân. Nếu thiếu test chức năng, vấn đề nằm ở scope baseline, nhưng khiếu nại về báo cáo là do giao tiếp kém, không phải scope statement. (PMBOK 7th: Planning Performance Domain, Section 5.3 Define Scope).

• ✅ Stakeholder register
  Phân tích đúng: Như đã giải thích ở trên, đây là công cụ toàn diện để quản lý stakeholder từ giai đoạn khởi đầu, ghi nhận thông tin như: tên, vai trò, nhu cầu (requirements), báo cáo mong muốn, và phương thức giao tiếp. Sử dụng nó giúp project manager liên kết kỳ vọng stakeholder với kế hoạch giao tiếp và kiểm thử, tránh bỏ sót chức năng quan trọng và đảm bảo báo cáo được gửi đúng. Đây là lựa chọn tối ưu để ngăn ngừa tình huống (proactive tool). (PMBOK 6th: Output of Identify Stakeholders; PMBOK 7th: Models như Stakeholder Engagement Assessment Matrix).

• ❌ Project charter
  Phân tích sai: Project charter là tài liệu khởi xướng dự án cấp cao, xác định mục tiêu, stakeholders chính, authority của PM, và high-level risks/requirements. Nó không chi tiết hóa nhu cầu báo cáo test status hay chức năng cụ thể của từng stakeholder, chỉ dùng ở giai đoạn Initiating. Không thể ngăn chặn vấn đề giao tiếp chi tiết trong Execution/Controlling. (PMBOK 7th: Section 2.2.1 Project Charter).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Stakeholder Performance Domain (trang 57-62), nhấn mạnh xác định và engage stakeholders sớm.
• PMBOK Guide 6th Edition (2017): Section 13.1 Identify Stakeholders (trang 506-512), định nghĩa rõ Stakeholder Register.
• PMP Exam Content Outline (2021, cập nhật 2024): Domain 8: Stakeholder (17% trọng số), People Domain.
• Tham khảo thêm: PMI.org Agile Practice Guide (2021) cho software projects, nhấn mạnh stakeholder collaboration.

Hy vọng phân tích này giúp bạn nắm vững kiến thức PMP! 🚀 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 Agile Project Management trong PMP (phiên bản PMBOK Guide 7th Edition và Agile Practice Guide cập nhật mới nhất đến 2026). Nó mô tả tình huống một đội ngũ Agile không hoàn thành công việc đã cam kết (not delivering the committed work). Cụ thể:

• Kanban board: Các thẻ công việc (cards) không di chuyển, cho thấy quy trình bị tắc nghẽn (bottleneck), thường do giới hạn công việc đang thực hiện (WIP - Work In Progress) quá cao so với năng lực đội ngũ.
• Burndown chart: Biểu đồ cho thấy tiến độ sprint chậm, nghĩa là lượng công việc còn lại không giảm như kế hoạch. 📌 Mục tiêu câu hỏi: Kiểm tra khả năng của Agile Project Manager (thường là Scrum Master hoặc Servant Leader) trong việc cải thiện quy trình làm việc thay vì đổ lỗi cá nhân hoặc leo thang vấn đề, phù hợp với nguyên tắc Agile: Tập trung vào flow of value, continuous improvement và empiricism (Scrum Guide 2020 & Kanban Guide for Scrum Teams).

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

Đáp án đúng: Change the work in progress (WIP) limit to reflect the team's velocity.
🛠️ Lý do: Trong Kanban và Agile (Scrum with Kanban), WIP limit là công cụ chính để kiểm soát dòng chảy công việc, tránh overload đội ngũ. Khi cards không move và burndown chậm, điều chỉnh WIP limit xuống để phù hợp với team's capacity/velocity (năng lực thực tế) sẽ giúp loại bỏ bottleneck, tăng throughput và cải thiện flow. Đây là hành động proactive process improvement, phù hợp với Agile Principle #12 (Reflect at regular intervals) và Kanban practices (Limit WIP). Không cần thay đổi metrics hay can thiệp cá nhân.

🧩 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên PMBOK 7th (Domain: Team & Uncertainty) và Agile Practice Guide (Kanban & Scrum):

• ❌ Consider the use of alternative performance metrics.
  Sai vì: Việc thay đổi metrics chỉ che giấu vấn đề thực tế (bottleneck và low velocity) thay vì giải quyết gốc rễ. Agile nhấn mạnh sử dụng metrics hiện có như burndown/Kanban flow để cải thiện, không phải "alternative" để tránh đối mặt vấn đề (vi phạm Principle of Transparency).

• ✅ Change the work in progress (WIP) limit to reflect the team's capacity.
  Đúng vì: Như đã giải thích ở trên, đây là best practice Kanban để match WIP với capacity thực tế, giúp cards di chuyển nhanh hơn, burndown cải thiện. Hỗ trợ self-organizing teams mà không micromanage (Scrum Guide: Events & Artifacts).

• ❌ Discuss the performance with senior leadership.
  Sai vì: Escalation lên lãnh đạo cấp cao là hành động cuối cùng, không phải đầu tiên trong Agile. Agile PM phải protect the team (Servant Leadership), giải quyết nội bộ trước qua retrospectives hoặc process tweaks, tránh làm đội ngũ mất động lực (PMBOK 7: Team Performance Domain).

• ❌ Meet with the project team members who are slow in delivering tasks.
  Sai vì: Tập trung vào cá nhân "slow" là blame culture, vi phạm Agile Manifesto (People over Processes) và Psychological Safety (Project Team Enablement). Vấn đề là systemic (WIP quá cao), không phải cá nhân; nên inspect process qua Retrospective thay vì gọi riêng (Agile Principle #6).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật 2026): Section 5.4 (Team Performance Domain), Agile Hybrid Approaches.
• Agile Practice Guide (PMI, 2017-2023 updates): Kanban chapter (Limit WIP), Metrics (Burndown/CFD).
• Scrum Guide (2020, Scrum.org): Sprint, Daily Scrum, WIP in Kanban for Scrum Teams.
• Kanban Guide for Scrum Teams (2021): Explicit WIP limits để manage flow.

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 PMP này thuộc miền People (Con người) trong PMBOK Guide 7th Edition (cập nhật đến 2026), tập trung vào kỹ năng quản lý xung đột (Conflict Management) trong dự án. Cụ thể:
Một Project Manager (PM) được yêu cầu đàm phán (negotiate) giữa hai thành viên đội ngũ thường xuyên hiểu lầm nhau, nhằm đạt được thỏa thuận tiến bộ dự án.
📌 Ý chính: PM cần hành động trực tiếp, hiệu quả để giải quyết xung đột đang diễn ra (ongoing conflict), không phải các biện pháp gián tiếp dài hạn. Điều này nhấn mạnh vai trò PM là facilitator, coach và mentor để xây dựng sự đồng thuận (consensus) và thúc đẩy dự án tiến triển nhanh chóng. Xung đột không được xử lý kịp thời có thể ảnh hưởng đến hiệu suất đội ngũ và deadline dự án.

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

Đáp án đúng: Coach and mentor the team members to build consensus and to resolve the ongoing conflict

🛠️ Lý do chi tiết:

• Theo PMBOK 7th Edition (Process 9.4: Manage Project Team và People Domain - Empower Team), PM phải chủ động coach (huấn luyện) và mentor (định hướng) thành viên để giải quyết xung đột trực tiếp và xây dựng consensus. Đây là kỹ thuật Collaborate/Problem-Solve hàng đầu trong 5 phương pháp giải quyết xung đột (Withdraw, Smooth, Compromise, Force, Collaborate).
• Hành động này phù hợp nhất với yêu cầu "negotiate to reach an agreement" vì nó giúp hai bên hiểu vấn đề, tìm điểm chung và thỏa thuận cụ thể, thúc đẩy dự án ngay lập tức.
• 📘 Nguồn tham khảo: PMBOK Guide 7th Edition, trang 282-285 (Conflict Resolution) & PMI Agile Practice Guide 2021 (Coach/Mentor trong Servant Leadership).

🧩 Phân tích tất cả các phương án (Đúng/Sai)

Dưới đây là phân tích từng lựa chọn một cách logic, dựa trên nguyên tắc PMP ưu tiên hành động trực tiếp, hiệu quả cao nhất cho xung đột đang cản trở dự án:

• Establish common ground through collaboration and understanding the team members’ needs
  ❌ Sai vì: Phương án này nghe hợp lý nhưng quá chung chung và thiếu vai trò lãnh đạo trực tiếp của PM. Nó mô tả một quá trình tự nhiên (collaboration), nhưng PM cần chủ động coach/mentor để dẫn dắt, không chỉ "hiểu needs". Trong PMBOK, đây chỉ là bước phụ, không phải hành động negotiate chính (thấp hơn Collaborate trong ma trận giải quyết xung đột).

• Organize a team-building event to improve the morale among team members
  ❌ Sai vì: Đây là biện pháp dài hạn, gián tiếp (team-building thuộc Develop Team process), không giải quyết xung đột ngay lập tức giữa chỉ hai người. Nó cải thiện morale chung nhưng không "negotiate to reach agreement" cho dự án cụ thể, có thể lãng phí thời gian nếu xung đột cấp bách (PMBOK cảnh báo tránh "Smooth/Accommodate" cho vấn đề quan trọng).

• Encourage a positive ongoing relationship between both of the team members
  ❌ Sai vì: Phương án này thụ động và mơ hồ (chỉ "encourage" - khuyến khích), không có hành động cụ thể như negotiate hay coach. Trong People Domain, PM phải intervene trực tiếp chứ không chờ "ongoing relationship" tự hình thành, vì xung đột lặp lại đang cản trở dự án (gần với "Smooth" - che lấp vấn đề, không khuyến khích trong PMP).

• Coach and mentor the team members to build consensus and to resolve the ongoing conflict
  ✅ Đúng vì: Như đã giải thích ở trên, đây là hành động trực tiếp, phù hợp nhất với vai trò PM làm negotiator/coach. Nó giải quyết gốc rễ xung đột, xây dựng consensus và đảm bảo dự án tiến bộ, phù hợp 100% với best practice PMP 2026.

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

• PMBOK Guide 7th Edition (2021, cập nhật 2026): Process 9.4 Manage Project Team; People Domain (Model the Way, Coach).
• PMI Code of Ethics & Professional Conduct: Trách nhiệm Resolve Conflicts hiệu quả.
• PMP Exam Content Outline 2021 (hiệu lực đến 2026): Domain III: People (26% câu hỏi về Conflict Mgmt).

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 mô tả tình huống một Project Manager (PM) đang làm việc cho một công ty startup. Công ty này đã ra mắt các mô-đun đào tạo agile project management và DevOps dựa trên nền tảng đám mây (cloud-based), hỗ trợ nhiều định dạng học tập tự paced và ảo (self-paced và virtual learning formats). Trong một sprint gần đây, đội ngũ Quality Assurance (QA) đã không kiểm tra kỹ lưỡng các mô-đun trước khi triển khai (deployment), dẫn đến trải nghiệm khách hàng kém (poor customer experience).

🛠️ Vấn đề cốt lõi: Đây là tình huống điển hình trong môi trường Agile/DevOps, nơi chất lượng bị ảnh hưởng do thiếu kiểm soát QA trước khi sản phẩm "escaped" ra production. PM cần xác định đúng loại vấn đề chất lượng đang gặp phải, dựa trên các khái niệm quản lý chất lượng trong PMP (PMBOK 7th Edition và Agile Practice Guide).

✅ Đáp án đúng: Escaped defect

Lý do lựa chọn:
Trong ngữ cảnh Agile/DevOps, một escaped defect là lỗi (defect) đã "thoát" qua các kiểm tra QA nội bộ và được triển khai đến khách hàng, gây ra vấn đề thực tế (ở đây là poor customer experience). Đội QA thất bại trong việc kiểm tra kỹ, nên defect không được phát hiện trước deployment. Khái niệm này được nhấn mạnh trong Quality Management của PMBOK 7th Edition (Domain: Uncertainty & Quality) và Agile Practice Guide (phần DevOps và Continuous Testing), nơi escaped defects là metric quan trọng để cải thiện quy trình QA. Đây chính xác khớp với tình huống: defect đã ra đến production và ảnh hưởng khách hàng.

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

• PMBOK® Guide – 7th Edition (2021), Section 4.5.2: Quality Metrics (Escaped Defects).
• Agile Practice Guide (PMI, 2017, cập nhật tích hợp PMBOK 7th): Phần Delivery & Continuous Improvement.
• PMI Standards đến 2026: Không thay đổi cốt lõi, vẫn ưu tiên metrics như Defect Escape Rate trong Agile.

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

• Nonconformance issue ❌ SAI
  Giải thích: Nonconformance issue đề cập đến việc không tuân thủ tiêu chuẩn quy trình hoặc spec (như vi phạm ISO hoặc quy trình nội bộ), thường được ghi nhận trong audit hoặc inspection. Ở đây, vấn đề không phải là vi phạm quy trình mà là defect thực tế đã escaped gây hại khách hàng, không chỉ là nonconformance trừu tượng. (PMBOK 7th: Distinguish từ Nonconformance vs. Defect).

• Escaped defect ✅ ĐÚNG
  Giải thích: Như đã phân tích ở trên, đây là defect đã qua mặt QA và đến tay khách hàng, khớp hoàn hảo với QA "failed to thoroughly inspect before deployment" dẫn đến poor experience. Metric này dùng để đo lường hiệu quả testing trong DevOps pipelines.

• Unmet planned-to-done ratio ❌ SAI
  Giải thích: Đây là metric Agile đo tỷ lệ công việc planned so với done trong sprint (liên quan velocity, burndown chart), phản ánh productivity chứ không phải chất lượng. Tình huống không đề cập đến việc không hoàn thành scope, mà tập trung vào quality failure post-deployment.

• Undetected error ❌ SAI
  Giải thích: Undetected error là lỗi chưa được phát hiện (vẫn ở giai đoạn internal), thường dùng trong testing phase. Ở đây, error đã escaped và detected bởi khách hàng, nên không phải "undetected" nữa. (Phân biệt rõ trong PMBOK 7th: Error vs. Defect vs. Escaped Defect).

🧩 Kết luận: Câu hỏi kiểm tra sự hiểu biết sâu về Quality Metrics trong Agile/DevOps. PM cần hành động như root cause analysis (ví dụ: retrospectives) để giảm escaped defects trong sprint sau! 🚀

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

Câu hỏi tập trung vào một thách thức lớn mà Project Manager (PM) đang gặp phải: thiếu kỷ luật từ các thành viên đội ngũ và không thể tập trung năng lượng để đạt mục tiêu dự án. Đây là vấn đề liên quan đến quản lý đội ngũ (Team Management) trong PMP, đặc biệt thuộc People Domain theo PMBOK Guide 7th Edition (2021) và cập nhật đến 2026. PM cần áp dụng lãnh đạo tình huống (Situational Leadership) để giải quyết, thay vì cách tiếp cận chung chung, nhằm khơi dậy động lực cá nhân và cải thiện hiệu suất. Vấn đề nhấn mạnh nhu cầu tiếp cận cá nhân hóa để khắc phục sự thiếu kỷ luật, phù hợp với nguyên tắc Value Delivery và Stakeholder Engagement mới nhất.

✅ Đáp án đúng

Meet with each team member separately and apply an appropriate approach with each one
Lý do chọn đáp án này: Đây là cách tiếp cận tối ưu và chuyên nghiệp nhất theo PMP. PM sử dụng Situational Leadership Model (Hersey-Blanchard), gặp riêng từng thành viên để đánh giá mức độ sẵn sàng (readiness) của họ (ví dụ: năng lực và động lực), rồi áp dụng phong cách lãnh đạo phù hợp (Directing, Coaching, Supporting, Delegating). Điều này giúp giải quyết gốc rễ vấn đề thiếu kỷ luật, khơi dậy năng lượng cá nhân, và xây dựng High-Performing Team. Theo PMBOK 7th, phần Manage Project Team và People Domain, PM chịu trách nhiệm trực tiếp lãnh đạo đội ngũ mà không né tránh.

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

• ✅ Meet with each team member separately and apply an appropriate approach with each one
  Giải thích đúng: Như trên, đây là best practice trong Team Leadership. PM chủ động xây dựng mối quan hệ cá nhân, áp dụng Tailored Leadership để khắc phục thiếu kỷ luật. Hiệu quả cao vì tập trung vào con người (People-Centric), phù hợp Agile Hybrid và PMBOK 7 (Tailoring Principle). 🛠️

• ❌ Assign multiple managers to the various teams and delegate all of the tasks to them
  Giải thích sai: Việc giao hết nhiệm vụ cho nhiều manager khác là trốn tránh trách nhiệm của PM. Theo PMBOK 7th (Project Manager Role), PM phải trực tiếp quản lý đội ngũ, không delegate toàn bộ. Điều này có thể gây nhầm lẫn quyền hạn (Authority Confusion) và làm tình hình tệ hơn, vi phạm Single Point of Accountability. 📉

• ❌ Explain to the team that the project manager is ultimately responsible for the delivery
  Giải thích sai: Chỉ giải thích trách nhiệm của PM không giải quyết vấn đề gốc (thiếu kỷ luật và năng lượng). Đây là cách thụ động, thiếu hành động, không khuyến khích đội ngũ. PMBOK 7 nhấn mạnh Inspire & Motivate thay vì đổ lỗi, và Accountability phải đi kèm Empowerment. Không hiệu quả cho Team Engagement. 😞

• ❌ Approach the project sponsor and request help in discussing the project deliverables with team members
  Giải thích sai: Kéo sponsor vào sớm là không phù hợp, vì PM phải tự giải quyết vấn đề đội ngũ trước (Escalation chỉ khi cần). Theo PMBOK 7 (Stakeholder Engagement) và RACI Matrix, sponsor không quản lý hàng ngày đội ngũ. Điều này làm PM mất uy tín và vi phạm Hierarchy of Needs trong lãnh đạo. 🚫

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): People Domain (Sections 4.2-4.6), Manage Project Team, Situational Leadership (Appendix).
• Agile Practice Guide (PMI, 2017 cập nhật): Servant Leadership & Team Empowerment.
• PMP Exam Content Outline (PMI, 2021-2026): Domain 2: People (28% trọng số), nhấn mạnh Individualized Approaches.
• PMI Code of Ethics (2022): Responsibility & Respect trong quản lý đội ngũ.

🛡️ Lời khuyên PMP: Luôn ưu tiên Proactive People Management để xây dựng đội ngũ mạnh mẽ! Nếu cần thực hành thêm, hãy thử simulation trên PMI.org.