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

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

Câu hỏi tập trung vào tình huống một Project Manager (PM) được bổ nhiệm quản lý dự án hạ tầng đa quốc gia, trải rộng qua nhiều múi giờ khác nhau trong một tiểu vùng. Điểm nổi bật là hầu hết thành viên đội ngũ dự án sẽ không bao giờ gặp mặt trực tiếp, nhưng họ vẫn phải hợp tác chặt chẽ để đảm bảo hoàn thành các sản phẩm giao (deliverables).

📌 Mục tiêu chính: PM cần làm gì để đảm bảo sự hợp tác tốt (good collaboration) giữa các thành viên đội ngũ làm việc từ xa (remote/virtual team). Đây là thách thức phổ biến trong dự án phân tán địa lý (distributed projects), đặc biệt với sự khác biệt múi giờ, văn hóa và công nghệ. Theo PMP (PMBOK 7th Edition, 2021 - cập nhật đến 2026), quản lý đội ngũ ảo đòi hỏi tập trung vào Performance Domain: Team và Stakeholder Engagement, nhấn mạnh giao tiếp hiệu quả qua công cụ kỹ thuật số để xây dựng lòng tin và phối hợp.

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

Đáp án đúng: Plan a communication method and allow the project team members to virtually interact.

Lý do: 🛠️ Trong môi trường đội ngũ ảo, PM phải lập kế hoạch phương thức giao tiếp (communication method) phù hợp, bao gồm các công cụ ảo như video call, chat nhóm (e.g., Microsoft Teams, Zoom, Slack) để cho phép tương tác ảo (virtually interact). Điều này trực tiếp hỗ trợ Manage Communications (Process trong PMBOK 6th, nay tích hợp vào Team & Engagement Domains trong PMBOK 7th). Nó giúp vượt qua rào cản địa lý/múi giờ, thúc đẩy collaboration thực tế, xây dựng mối quan hệ và theo dõi tiến độ. Đây là hành động chủ động, phù hợp nhất với nguyên tắc Tailoring cho virtual teams.

📋 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 dựa trên thực tiễn PMP mới nhất:

• ❌ [SAI] Discuss the concerns with the project sponsor and modify the project charter to include more budget for interactions.
  🧨 Lý do sai: Việc thảo luận lo ngại với sponsor và sửa project charter để tăng ngân sách không phải giải pháp trực tiếp cho collaboration. Project charter là tài liệu ban đầu, cao cấp (PMBOK 7th, Develop Project Charter Process), chỉ định mục tiêu/số lượng, không dùng để chỉnh sửa chi tiết vận hành như giao tiếp. Tăng budget có thể hỗ trợ gián tiếp (e.g., mua tool), nhưng không giải quyết gốc rễ là phương thức giao tiếp. Đây là cách tiếp cận phản ứng, không hiệu quả cho virtual teams.

• ❌ [SAI] Create a social media group platform for the team to create a supportive environment.
  🚫 Lý do sai: Tạo nhóm mạng xã hội (social media) chỉ tạo môi trường hỗ trợ không chính thức, thiếu cấu trúc chuyên nghiệp cho dự án. PMP khuyến nghị công cụ giao tiếp dự án chuyên dụng (e.g., collaboration platforms như Jira, Asana), không phải social media thông thường (có rủi ro bảo mật, phân tâm). Theo Team Performance Domain (PMBOK 7th), cần formal communication để đảm bảo deliverables, không chỉ "supportive environment" mơ hồ.

• ❌ [SAI] Set the ground rules and identify a contingency plan in the risk register.
  ⚠️ Lý do sai: Đặt ground rules (quy tắc cơ bản) và lập contingency plan trong risk register là tốt cho team charter và quản lý rủi ro (Risk Management Domain), nhưng không tập trung vào collaboration remote. Ground rules hỗ trợ hành vi, contingency xử lý rủi ro (e.g., mất kết nối), nhưng bỏ qua công cụ giao tiếp cốt lõi. Đây là hành động bổ sung, không phải ưu tiên đầu tiên cho virtual interaction.

• ✅ [ĐÚNG] Plan a communication method and allow the project team members to virtually interact.
  🌟 Lý do đúng: Như đã giải thích ở trên, đây là hành động cốt lõi trong Plan Communications Management và Manage Communications (PMBOK 7th, Stakeholder Engagement Domain). Với đội ngũ đa múi giờ, PM cần phân tích nhu cầu giao tiếp (communication requirements), chọn method phù hợp (e.g., asynchronous tools như email/shared docs cho múi giờ khác), và thúc đẩy virtual interaction để xây dựng high-performing virtual team.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Team Performance Domain (Section 5.3 Virtual Teams), Stakeholder Engagement Domain (Section 4.7 Communication).
• PMP Exam Content Outline (PMI, 2021 - cập nhật 2026): Domain III: Business Environment (13%), Domain IV: People (42% - cao nhất, bao gồm virtual team mgmt).
• PMI Agile Practice Guide (2021): Hybrid/Virtual Teams - Nhấn mạnh digital collaboration tools.
• Nguồn bổ sung: PMI.org resources on "Managing Virtual Teams" (2023 updates).

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

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

📖 Nội dung câu hỏi:
Câu hỏi mô tả một dự án hybrid (kết hợp predictive cho giai đoạn thu thập yêu cầu và agile cho phát triển & kiểm thử). Đội ngũ mới được thành lập, nhưng không phải tất cả thành viên đều có kinh nghiệm agile. Kết quả là lịch trình bị trễ do cấu trúc agile phát triển không rõ ràng (unclear structure of the agile development approach).
Câu hỏi yêu cầu xác định hành động mà Project Manager (PM) nên thực hiện để tránh tình huống này, dựa trên nguyên tắc quản lý dự án hybrid, tập trung vào việc xây dựng đội ngũ hiệu suất cao và áp dụng agile đúng cách.
Vấn đề cốt lõi: Thiếu kinh nghiệm agile dẫn đến cấu trúc không rõ → trễ lịch. PM cần chủ động xây dựng năng lực đội ngũ từ đầu, thay vì chỉ theo dõi sau khi vấn đề xảy ra.
(Kiến thức PMP cập nhật: PMBOK® Guide 7th Edition & Agile Practice Guide 2021, nhấn mạnh Servant Leadership, Empower Teams, và High-Performance Teams trong môi trường hybrid.)

✅ Đáp án đúng:
Met with the team, allowed team members to make decisions about what to do, and established performance goals.

🛠️ Lý do chọn đáp án đúng (chi tiết):

• Hành động này thể hiện Servant Leadership (lãnh đạo phục vụ) – PM gặp đội ngũ, trao quyền tự quyết định (empower team members to make decisions), và đặt mục tiêu hiệu suất (performance goals).
• Trong agile/hybrid, đội ngũ tự quản (self-organizing teams) là chìa khóa để làm rõ cấu trúc (như định nghĩa quy trình sprint, roles). Điều này giúp đội ngũ thiếu kinh nghiệm học hỏi nhanh chóng, xây dựng sự rõ ràng từ bên trong, tránh trễ lịch.
• Phù hợp nguyên tắc Develop Team (ITTO của Process Develop Team trong PMBOK 6/7), và Agile Principle #5: Build projects around motivated individuals. Give them the environment and support they need.
• Nguồn tham khảo: PMBOK® Guide 7th Edition (Section 4.5.1 Develop Team, Principle 9: Leadership); Agile Practice Guide (Chapter 3.2 Servant Leadership & Team Empowerment).

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

• ❌ [SAI] Set up weekly status meetings to review team progress, prepared weekly status reports to track progress, and regularly escalated delays.
  Phương án này mang tính giám sát truyền thống (predictive) với họp hàng tuần và báo cáo/escalate delays – chỉ phản ứng sau vấn đề (reactive), không giải quyết gốc rễ thiếu kinh nghiệm agile hay unclear structure. Agile ưu tiên daily sync và self-management, không phải weekly reports nặng nề. Dẫn đến micromanagement, làm đội ngũ thiếu động lực.

• ❌ [SAI] Established daily standup meetings to track and report on team progress and escalated delays to stakeholders as they occurred.
  Daily standup là thực hành agile tốt (từ Scrum), nhưng chỉ track/escalate mà không empower đội ngũ tự quyết. Không giải quyết unclear structure hay đào tạo kinh nghiệm từ đầu – vẫn là giám sát (command-and-control), không khuyến khích self-organizing. PMBOK 7 cảnh báo: Agile cần team ownership, không chỉ meetings.

• ✅ [ĐÚNG] Met with the team, allowed team members to make decisions about what to do, and established performance goals.
  (Đã giải thích chi tiết ở trên – hoàn hảo cho tình huống hybrid, xây dựng đội ngũ high-performing ngay từ đầu).

• ❌ [SAI] Conducted routine meetings and identified team members who are under performing.
  Đây là micromanagement tiêu cực, chỉ chỉ trích cá nhân underperforming qua routine meetings – vi phạm Agile Manifesto (Principle #11: Self-organizing teams) và PMBOK 7 (tránh blame culture). Không xây dựng kỹ năng agile, làm giảm động lực đội ngũ, tệ hơn tình huống gốc.

🎯 Kết luận & bài học PMP:
Trong dự án hybrid, PM phải chủ động phát triển đội ngũ (Team Development) bằng cách empower và set goals, thay vì chỉ monitor/escalate. Áp dụng sớm tránh 80% rủi ro trễ lịch do nhân tố con người!
📘 Tài liệu tham khảo chính:

• PMBOK® Guide – 7th Edition (2021, PMI).
• Agile Practice Guide (2021, PMI).
• PMP Exam Content Outline (2024 update, hiệu lực đến 2026).

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

Câu hỏi mô tả một tình huống trong dự án hybrid (kết hợp giữa phương pháp dự án truyền thống - predictive và linh hoạt - agile). Đội ngũ dự án đang gặp khó khăn trong việc đạt được sự hài lòng của khách hàng (customer satisfaction). Cụ thể:

• Đội ngũ dự án cho rằng khách hàng liên tục thay đổi ưu tiên (priorities), dẫn đến khó khăn trong thực hiện.
• Khách hàng lại phản ánh rằng đội ngũ dự án không hiểu rõ nhu cầu của họ (needs).

📌 Vấn đề cốt lõi: Thiếu sự giao tiếp và hiểu biết lẫn nhau giữa các bên liên quan (stakeholders), dẫn đến xung đột và rủi ro về giá trị dự án. Project Manager (PM) cần hành động để giải quyết mâu thuẫn này một cách proactive, collaborative, phù hợp với nguyên tắc Stakeholder Engagement và Team Management trong PMP (PMBOK 7th Edition, 2021 và các cập nhật đến 2026 nhấn mạnh tính linh hoạt trong hybrid projects).

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

Đáp án đúng: Meet with the customer and the project team to understand the problem.

Lý do:
🛠️ PM nên tổ chức cuộc họp trực tiếp với cả khách hàng và đội ngũ dự án để hiểu rõ vấn đề gốc rễ (root cause). Điều này thúc đẩy giao tiếp hai chiều, xây dựng sự đồng thuận và cải thiện sự hiểu biết lẫn nhau – phù hợp với quy trình Manage Communications và Manage Stakeholder Engagement (PMBOK 7th Ed., Principle 5: Build a Team; Principle 11: Engage Stakeholders). Trong dự án hybrid, việc facilitate collaboration là chìa khóa để xử lý thay đổi ưu tiên và nhu cầu khách hàng, tránh leo thang không cần thiết. Hành động này tailored, value-driven và giúp dự án nhanh chóng trở lại quỹ đạo.

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm giải thích chi tiết bằng tiếng Việt dựa trên PMP mới nhất (PMBOK 7th Ed. & Agile Practice Guide, cập nhật đến 2026).

• Meet with the customer and the project team to understand the problem.
  ✅ Đúng – Như đã giải thích ở trên, đây là hành động first-line resolution hiệu quả nhất, thúc đẩy active listening và problem-solving collaborative. Giúp PM thu thập thông tin trực tiếp, xác định gaps trong communication mà không tốn kém hoặc phức tạp hóa vấn đề (Process 13.3: Manage Stakeholder Engagement).

• Hire an external organization to audit the project and deliverables.
  ❌ Sai – Việc thuê bên ngoài để audit là overkill và phản ứng thụ động, chỉ phù hợp khi có bằng chứng rõ ràng về noncompliance hoặc fraud (không phải trường hợp này). Nó làm chậm dự án hybrid, tăng chi phí và có thể làm giảm lòng tin stakeholders (PMBOK 7th Ed., Principle 9: Optimize Risk Responses – tránh escalate sớm).

• Ask the product owner to explain the customer needs to the project team.
  ❌ Sai – Dù Product Owner (PO) trong agile chịu trách nhiệm backlog và needs, việc chỉ giao PO giải thích là one-way communication, bỏ qua phản hồi từ đội ngũ và khách hàng. Không giải quyết xung đột gốc (team vs. customer), vi phạm Holistic Team Performance Domain (PMBOK 7th Ed., không khuyến khích delegate mà PM phải lead facilitation).

• Escalate to the project sponsor and request immediate intervention.
  ❌ Sai – Escalate chỉ dùng khi PM đã thử các biện pháp nội bộ thất bại hoặc vượt quyền hạn (Issue & Escalation Management). Ở đây, vấn đề là communication gap đơn giản, escalate sớm sẽ tạo bureaucracy, làm mất cơ hội tự giải quyết và giảm empowerment của PM/Team (PMBOK 7th Ed., Principle 3: Focus on Value – ưu tiên giải quyết tại chỗ trước).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, PMI): Performance Domains (Stakeholder, Team, Uncertainty); Principles 5, 11.
• Agile Practice Guide (PMI, tích hợp PMBOK 7): Hybrid Life Cycles – Nhấn mạnh continuous feedback loops.
• PMP Exam Content Outline (2024-2026 updates): 17% People Domain (team building, conflict mgmt.); 50% Process (stakeholder engagement).
  🛠️ Khuyến nghị thực hành: Sử dụng facilitation techniques như brainstorming hoặc RACI matrix trong cuộc họp để tối ưu kết quả. Nếu cần, tham khảo PMI.org cho case studies hybrid projects.

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

Câu hỏi mô tả một dự án xây dựng khu phức hợp sản xuất với ba giai đoạn rõ ràng: engineering (thiết kế kỹ thuật), procurement (mua sắm), và construction (xây dựng). Hiện tại, giai đoạn procurement đang ở giai đoạn khởi tạo (initiation). Nhà tài trợ dự án (project sponsor) muốn tuân thủ kế hoạch các giai đoạn đã định sẵn, nhưng đồng thời linh hoạt điều chỉnh dựa trên dữ liệu mới, phản hồi từ khách hàng (customer input), và các thay đổi phát sinh trong quá trình thực hiện.

🛠️ Mục tiêu chính: Project manager cần chọn cách tiếp cận phù hợp để cân bằng giữa cấu trúc cố định (predictive) cho các giai đoạn lớn và tính thích ứng (adaptive) để xử lý thay đổi. Đây là tình huống điển hình trong PMP, nơi dự án có yếu tố phased (chia giai đoạn) nhưng đòi hỏi sự linh hoạt, phù hợp với hybrid life cycle theo PMBOK® Guide 7th Edition (2021) và các cập nhật đến 2026.

✅ Đáp án đúng: Use a hybrid model to combine predictive and adaptive life cycles

Lý do lựa chọn:

• Dự án có cấu trúc giai đoạn rõ ràng (engineering → procurement → construction), phù hợp với predictive life cycle (tiếp cận truyền thống, kế hoạch chi tiết từ đầu).
• Tuy nhiên, sponsor yêu cầu điều chỉnh linh hoạt với dữ liệu mới và input khách hàng, đòi hỏi adaptive life cycle (agile-like, lặp lại và thích ứng).
• Hybrid model kết hợp cả hai: Sử dụng predictive cho các giai đoạn lớn (scope, schedule cố định), và adaptive trong từng giai đoạn (iterative feedback, thay đổi nhanh). Điều này đảm bảo tuân thủ kế hoạch tổng thể nhưng linh hoạt cục bộ, tối ưu hóa giá trị dự án theo nguyên tắc Value Delivery System trong PMBOK 7.

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

• ✅ Use a hybrid model to combine predictive and adaptive life cycles
  🟢 Đúng vì: Như phân tích trên, hybrid chính xác cân bằng yêu cầu "tuân thủ phase đã kế hoạch" (predictive) và "điều chỉnh thay đổi" (adaptive). PMBOK 7 định nghĩa hybrid là sự kết hợp linh hoạt giữa predictive (linear/sequential), adaptive (iterative/incremental), giúp xử lý dự án phức tạp như xây dựng với yếu tố không chắc chắn.

• ❌ Implement an adaptive project management approach
  🔴 Sai vì: Adaptive (agile thuần túy) tập trung hoàn toàn vào lặp lại, feedback liên tục và thay đổi scope, không phù hợp với yêu cầu "tuân thủ phase đã kế hoạch" cố định. Dự án có giai đoạn lớn rõ ràng, nếu chỉ adaptive sẽ thiếu cấu trúc tổng thể, dẫn đến rủi ro vượt ngân sách/thời gian.

• ❌ Evaluate and decide on a phased project management approach
  🔴 Sai vì: Phased approach chỉ là chia dự án thành các phase tuần tự (đã có sẵn: engineering, procurement, construction), nhưng không giải quyết yêu cầu linh hoạt điều chỉnh thay đổi. Đây chỉ là mô tả cấu trúc, không phải chiến lược tiếp cận toàn diện; sponsor đã muốn "pursue phases as planned" rồi, không cần "evaluate again".

• ❌ Apply a predictive project management approach
  🔴 Sai vì: Predictive (waterfall) yêu cầu kế hoạch chi tiết từ đầu, ít linh hoạt với thay đổi – trái ngược yêu cầu "accommodate new data, customer input, changes". Dự án sẽ gặp vấn đề nếu có biến động (ví dụ: thay đổi thiết kế từ customer), dẫn đến rework lớn.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021): Chương 2 (Life Cycle), Section 2.2.2 Hybrid Life Cycle; Chương 4 (Project Delivery Principles).
• Process Groups: A Practice Guide (2022): Phần Hybrid Approaches cho dự án phased với adaptive elements.
• PMI Agile Practice Guide (2017, cập nhật tích hợp PMBOK 7): Định nghĩa adaptive và hybrid cho dự án hybrid như construction.
• Cập nhật đến 2026: PMI Standards Plus™ xác nhận hybrid ngày càng phổ biến cho dự án lớn (theo PMI Pulse of the Profession 2024-2025).

🛠️ Khuyến nghị PMP: Áp dụng hybrid bằng cách dùng Predictive cho milestone giai đoạn (gates review) và Adaptive sprints/iterations trong từng phase để thu thập feedback. Project manager nên cập nhật Project Management Plan với Tailoring (PMBOK 7, Chương 3).

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

Câu hỏi tập trung vào một Project Manager theo phương pháp Agile đang đánh giá phương pháp hiển thị giá trị công việc đã thực hiện đến nay (value of the work performed to date) cho các stakeholder dự án. Trong môi trường Agile (như Scrum với các Sprint), mục tiêu là minh bạch hóa tiến độ giá trị giao cho khách hàng, không chỉ thời gian hay chi phí. Phương pháp phải trực quan, dễ hiểu, thể hiện sự tăng dần của giá trị hoàn thành so với kế hoạch tổng thể, giúp stakeholder dễ theo dõi scope đã hoàn thành theo thời gian (ví dụ: theo Sprint).

🛠️ Ngữ cảnh Agile (theo PMBOK® Guide 7th Edition & Agile Practice Guide): Agile ưu tiên các công cụ như Burndown/Burnup Chart để hiển thị velocity và value delivery, thay vì các chỉ số EVM truyền thống (Earned Value Management) từ Predictive/Waterfall. Câu hỏi nhấn mạnh "display to the project stakeholder" → cần chart đơn giản, tích cực, thể hiện tăng trưởng giá trị (từ dưới lên trên).

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

• PMBOK® Guide – 7th Edition (PMI, 2021): Section 6.4 & Agile Hybrid Approaches.
• Agile Practice Guide (PMI, 2017, cập nhật tích hợp PMBOK 7): Chapter 5 – Scrum Metrics (Burnup Chart p. 42).
• Scrum Guide 2020 (Scrum.org, cập nhật 2023): Sprint Burndown/Burnup cho transparency.

✅ Đáp án đúng: Phương án thứ 2 (Burnup Chart)

Nội dung phương án gốc (giữ nguyên tiếng Anh):
![Burnup Chart image]
(Hình vẽ đường cong xanh "Planned" tăng dần đại diện kế hoạch tổng scope; đường đỏ "Achieved" tăng dần đại diện giá trị đã hoàn thành qua 10 Sprint, từ 0 lên gần 500+.)

Lý do chọn đáp án này 🏆:
Burnup Chart là công cụ Agile chuẩn để hiển thị tổng giá trị công việc đã thực hiện đến nay một cách trực quan cho stakeholder. Nó thể hiện:

• Đường Planned: Tổng scope dự kiến (baseline).
• Đường Achieved: Giá trị thực tế hoàn thành (tăng dần theo Sprint).

✅ Ưu điểm: Minh bạch, tích cực (focus vào "đã làm được gì"), giúp stakeholder thấy value delivery tăng trưởng, dự báo hoàn thành dự án. Phù hợp Agile vì linh hoạt với scope thay đổi (scope có thể tăng). Không giống Burndown (giảm dần còn lại), Burnup nhấn mạnh progress tích lũy – lý tưởng cho "value performed to date".

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

• Phương án 1 (SAI):
  Nội dung phương án gốc:
  PV = SV / (SPI - 1)
  Planned Value Calculation
  (Công thức tính Planned Value dựa trên Schedule Performance Index.)

  Giải thích sai ❌: Đây là công thức Earned Value Management (EVM) từ Predictive lifecycle (PMBOK 7: Section 4.5). PV là giá trị kế hoạch theo thời gian, không phải value đã thực hiện. Agile tránh EVM phức tạp vì ưu tiên story points/velocity thay vì chi phí tài chính. Không phù hợp để hiển thị cho stakeholder Agile (quá kỹ thuật, không trực quan theo Sprint).

• Phương án 2 (ĐÚNG): (Đã giải thích chi tiết ở trên) ✅ Burnup Chart – hoàn hảo cho Agile value display!

• Phương án 3 (SAI):
  Nội dung phương án gốc:
  BCWP - BCWS = SV
  Schedule Variance Calculation
  (Công thức tính Schedule Variance: Budgeted Cost of Work Performed trừ Budgeted Cost of Work Scheduled.)

  Giải thích sai ❌: Đây là Schedule Variance (SV) trong EVM (PMBOK 7: Tool & Technique in Manage Project Work). Chỉ đo chênh lệch lịch trình, không hiển thị value performed. Agile không dùng BCWP/BCWS (dựa chi phí), mà dùng points. Không trực quan cho stakeholder, dễ gây nhầm lẫn với cost overrun thay vì value growth.

• Phương án 4 (SAI):
  Nội dung phương án gốc:
  | WBS | Perc Complete |
  |---------|---------------|
  | Story 1 | 100% |
  | Story 2 | 100% |
  | Story 3 | 80% |
  | ... | ... |

  (Bảng liệt kê WBS Stories với % Complete; nhãn "Work Breakdown Chart".)

  Giải thích sai ❌: Đây là WBS với % Complete (Work Breakdown Structure), công cụ lập kế hoạch (PMBOK 7: Section 5.3), không phải chart hiển thị value over time. Chỉ là snapshot tĩnh (không theo Sprint), thiếu đường cong tiến độ. Agile dùng Product Backlog/Item tracking, không gọi là "Work Breakdown Chart" (WBS là thuật ngữ Predictive). Không "display value to date" một cách trực quan cho stakeholder.

🧠 Kết luận: Burnup Chart là lựa chọn tối ưu trong Agile để tăng transparency và stakeholder satisfaction! Công cụ này có thể tích hợp dễ dàng với các nền tảng quản lý dự án phổ biến như Jira, Azure DevOps hoặc các bảng Kanban, giúp các nhóm Agile theo dõi và truyền đạt giá trị đã giao một cách rõ ràng.

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

Câu hỏi này thuộc chủ đề Agile/Scrum trong PMP, cụ thể là quy trình xử lý khi Product Owner (PO) không chấp nhận kết quả của Sprint Review đầu tiên trong một dự án đang chuyển đổi sang cách tiếp cận Agile.

📖 Chi tiết ngữ cảnh:

• Tổ chức đang chuyển đổi từ truyền thống sang Agile (transition to agile), nên có thể gặp thách thức ban đầu.
• Sprint Review là sự kiện cuối sprint nơi đội ngũ trình diễn Increment (sản phẩm hoàn thành), PO đánh giá và chấp nhận hoặc từ chối các Product Backlog Items (PBIs) dựa trên Definition of Done (DoD) và giá trị kinh doanh.
• PO không chấp nhận kết quả và bày tỏ một số lo ngại (concerns) – điều này phổ biến ở sprint đầu, có thể do hiểu lầm kỳ vọng, DoD chưa rõ ràng, hoặc vấn đề quy trình.
• Project Manager (PM) cần hành động phù hợp với nguyên tắc Agile: tập trung vào cải tiến liên tục (continuous improvement), hợp tác đội ngũ, và tự quản lý (self-organizing team) thay vì chỉ huy mệnh lệnh.

🛠️ Mục tiêu câu hỏi: Kiểm tra kiến thức về các sự kiện Scrum (Sprint Review vs. Sprint Retrospective) và cách PM hỗ trợ Agile mà không vi phạm vai trò (PM thường là Scrum Master hoặc facilitator trong Agile).

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

Đáp án đúng: Organize a sprint retrospective and discuss the issues and how they can be avoided in the next sprint.

Lý do (dựa trên PMBOK® Guide 7th Edition & Agile Practice Guide 2021, cập nhật đến 2026):

• Trong Scrum, sau Sprint Review, sự kiện tiếp theo là Sprint Retrospective – nơi đội ngũ (bao gồm PO, Scrum Master/PM, Development Team) phân tích vấn đề, xác định root cause của lo ngại từ PO, và lập kế hoạch cải thiện quy trình cho sprint sau (inspect & adapt).
• Điều này thúc đẩy Agile principles: cải tiến liên tục, phản hồi nhanh, và tránh lặp lại lỗi ở sprint đầu tiên (rất phổ biến khi transition).
• PM đóng vai trò facilitator, không ép buộc mà khuyến khích thảo luận mở để tăng sự hài lòng của PO và chất lượng Increment.

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

Dưới đây là phân tích từng lựa án (giữ nguyên văn bản tiếng Anh gốc). Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích chi tiết bằng tiếng Việt dựa trên Scrum Guide 2020 (cập nhật Scrum 2025) và PMI Agile Certified Practitioner (PMI-ACP).

• ❌ [SAI] Ask the project team to address the product owner’s issues since the product owner is responsible for the scope in agile.
  Giải thích sai: Phương án này ép đội ngũ sửa chữa ngay lập tức dựa trên lý do PO chịu trách nhiệm scope – đúng là PO quản lý Product Backlog và quyết định chấp nhận, nhưng không phải cách Agile xử lý. Nó bỏ qua Retrospective (sự kiện chính thức để cải thiện), có thể dẫn đến "firefighting" (xử lý chữa cháy) thay vì cải tiến bền vững. Trong transition Agile, cần ưu tiên học hỏi thay vì chỉ sửa scope.

• ❌ [SAI] Create a record in the issue register and escalate the issue to the project steering committee.
  Giải thích sai: Đây là cách tiếp cận Waterfall/Predictive (sử dụng Issue Log và escalate lên steering committee), không phù hợp Agile. Agile nhấn mạnh đội ngũ tự giải quyết (empowered team) qua các sự kiện nội bộ như Retrospective, tránh bureaucracy (hành chính rườm rà) để giữ tốc độ cao.

• ❌ [SAI] Ask the product owner to accept the outcome since the team delivered what was agreed in the sprint planning.
  Giải thích sai: Ép PO chấp nhận vì "đã agree trong Sprint Planning" vi phạm quyền của PO trong việc đánh giá giá trị kinh doanh và DoD. Sprint Planning chỉ cam kết effort, không phải "độc tài" – PO có quyền reject nếu không đạt kỳ vọng. Điều này phá vỡ hợp tác (collaboration) và có thể gây xung đột ở giai đoạn transition.

• ✅ [ĐÚNG] Organize a sprint retrospective and discuss the issues and how they can be avoided in the next sprint.
  Giải thích đúng: Như đã nêu ở phần đáp án, đây là sự kiện chuẩn Scrum ngay sau Review, tập trung thảo luận issues (lo ngại của PO) và kế hoạch tránh lặp lại. PM facilitate để đội ngũ tự cải thiện, phù hợp 12 Principles of Agile Manifesto (reflect at regular intervals).

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Chương 5 (Supports Agile), nhấn mạnh Retrospective cho continuous improvement.
• Agile Practice Guide (PMI, 2021): Phần 4.3 Sprint Events, mô tả Retrospective xử lý feedback từ Review.
• Scrum Guide (Scrum.org, 2020 – cập nhật 2025): "The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself" – bao gồm issues từ PO.
• PMI-ACP Exam Content Outline (2025): Domain 2 (Agile Principles & Mindset), ưu tiên inspect & adapt.

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ý Đội ngũ (Manage Team) và Quản lý Xung đột (Manage Conflict) trong PMP, theo PMBOK Guide 7th Edition (cập nhật đến 2026). Tình huống mô tả: Quản lý dự án (Project Manager - PM) nhận được khiếu nại nghiêm trọng từ quản lý chức năng (functional manager) về một thành viên đội ngũ. Câu hỏi yêu cầu xác định hành động đầu tiên và đúng đắn nhất mà PM nên thực hiện.

🛠️ Mục tiêu chính: PM phải xử lý khiếu nại một cách chuyên nghiệp, khách quan, ưu tiên thu thập thông tin đầy đủ trước khi quyết định, để tránh thiên vị, bảo vệ dự án và duy trì mối quan hệ với các bên liên quan. Điều này phù hợp với People Domain (lĩnh vực Con người) và nguyên tắc Tailoring trong PMBOK 7, nhấn mạnh giao tiếp hiệu quả và giải quyết vấn đề dựa trên dữ liệu.

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

Đáp án đúng: Discuss the issue with the functional manager to understand the reason for the complaint.

Lý do:

• Đây là bước đầu tiên trong quy trình quản lý đội ngũ và xung đột (Manage Team & Manage Conflict). PM cần thảo luận trực tiếp để hiểu rõ nguyên nhân (root cause), thu thập dữ liệu khách quan trước khi hành động.
• Theo PMBOK 7th Edition (Section 4.5 Manage Team) và PMP Exam Content Outline 2021 (People - Task 9), PM phải thu thập thông tin từ tất cả các bên để đánh giá vấn đề, tránh quyết định vội vã. Hành động này thúc đẩy giao tiếp hai chiều, xây dựng lòng tin và đảm bảo tính công bằng.
• 📘 Nguồn tham khảo: PMBOK Guide 7th Edition (trang 149-152, Manage Project Team); Agile Practice Guide (Conflict Resolution Models).

📋 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, đánh dấu ✅ đúng hoặc ❌ sai, dựa trên nguyên tắc PMP mới nhất:

• ❌ [SAI] Support the team member and provide documentation to the functional manager proving their performance.
  Phương án này sai vì PM thiên vị ngay lập tức bảo vệ thành viên đội ngũ mà không thu thập thông tin từ phía khiếu nại. Điều này vi phạm nguyên tắc khách quan (objectivity) trong Performance Appraisals và có thể làm leo thang xung đột, ảnh hưởng đến mối quan hệ chức năng-dự án. PMBOK 7 nhấn mạnh phải điều tra đầy đủ trước khi hỗ trợ (Develop Team process).

• ❌ [SAI] Replace the team member immediately to maintain a good relationship with the functional manager.
  Phương án này sai vì thay thế ngay lập tức là hành động vội vã, thiếu cơ sở, bỏ qua quy trình đánh giá hiệu suất (Manage Team). Điều này có thể vi phạm Resource Management Plan, gây rủi ro dự án (team disruption) và không giải quyết nguyên nhân gốc rễ. PMP yêu cầu phân tích trước khi thay đổi (Acquire Resources & Control Resources).

• ❌ [SAI] Protect the team member and ask the project sponsor to minimize any external interruptions.
  Phương án này sai vì PM bảo vệ mù quáng và trốn tránh vấn đề bằng cách nhờ sponsor can thiệp, thay vì giải quyết trực tiếp. Điều này vi phạm trách nhiệm của PM trong Stakeholder Engagement và Escalation Process (chỉ escalate sau khi cố gắng tự giải quyết). PMBOK 7 (Stakeholder Management) yêu cầu PM làm chủ xung đột nội bộ trước.

• ✅ [ĐÚNG] Discuss the issue with the functional manager to understand the reason for the complaint.
  Như đã giải thích ở phần đáp án đúng, đây là hành động tối ưu: Giao tiếp mở, thu thập dữ liệu, phù hợp với 12 Principles of PMBOK 7 (Focus on Value, Collaborate). Nó giúp PM đánh giá chính xác và quyết định tiếp theo (ví dụ: coaching, disciplinary action).

🛠️ Kết luận & Lời khuyên PMP: Trong thực tế, hãy áp dụng Conflict Resolution Techniques như Collaborating/Problem-Solving (hiệu quả nhất cho khiếu nại nghiêm trọng). Thực hành qua PMP Mock Exams để nắm vững! 📘 Tài liệu thêm: PMI.org - PMP Examination Content Outline (2024 update); Rita Mulcahy's PMP Exam Prep (12th Ed., tương thích PMBOK 7).

🛠️ Phân tích câu hỏi trắc nghiệm PMP: Xử lý vấn đề với khách hàng trong dự án xuất khẩu

📝 1. Giải thích nội dung câu hỏi một cách chi tiết và rõ ràng:
Câu hỏi mô tả một tình huống thực tế trong dự án logistics: Dự án cần xuất khẩu 150 gói hàng cho khách hàng, nhưng hiện chỉ có 30 gói được khách hàng phê duyệt (cleared) để vận chuyển. Quản lý logistics đã chủ động cung cấp thông tin chi tiết cho khách hàng 2 tuần trước và thiết lập cuộc gọi họp hàng tuần để giao tiếp hiệu quả. Tuy nhiên, khách hàng không tham gia các cuộc gọi này.
🧩 Vấn đề cốt lõi là sự chậm trễ trong phê duyệt từ khách hàng, dẫn đến rủi ro ảnh hưởng đến tiến độ dự án (schedule), chi phí (cost) và chất lượng giao hàng. Project Manager (PM) cần xử lý theo nguyên tắc PMP: Tập trung vào quản lý bên liên quan (Stakeholder Engagement), phân tích nguyên nhân gốc rễ (Root Cause Analysis) và giao tiếp hiệu quả để đảm bảo giá trị dự án (Value Delivery). Đây là tình huống điển hình trong Process Group: Executing và Stakeholder Management theo PMBOK 7th Edition (2021) và cập nhật PMP đến 2026, nhấn mạnh cách tiếp cận problem-solving thay vì hành động vội vã.

✅ 2. Đáp án đúng và lý do lựa chọn:
Đáp án đúng là: Find the root cause of the issue and discuss the customer's current engagement.
🧩 Lý do: Theo PMP mới nhất (PMBOK 7th Edition & Exam Content Outline 2021-2026), PM phải xác định nguyên nhân gốc rễ (root cause) trước khi hành động để tránh giải quyết triệu chứng. Đồng thời, thảo luận mức độ tham gia hiện tại của khách hàng (customer's engagement) phù hợp với Manage Stakeholder Engagement (Domain: Stakeholder). Điều này thúc đẩy giao tiếp hai chiều, xây dựng mối quan hệ và điều chỉnh kế hoạch mà không thay đổi hợp đồng hay đe dọa. Hành động này hỗ trợ Agile Principles (nếu hybrid) và Tailoring để tối ưu hóa dự án.

🧩 3. Giải thích tất cả các phương án (đúng và sai):
Dưới đây là phân tích chi tiết từng phương á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 cập nhật (PMBOK 7th, 8th Draft & PMI Standards 2026).

• Request a change in the contract to include the shipment in the project management plan.
  ❌ Sai: Phương án này vi phạm Integrated Change Control (Domain: Uncertainty). Thay đổi hợp đồng cần Change Request chính thức qua CCB (Change Control Board), không phải yêu cầu đơn phương từ PM. Hơn nữa, vấn đề là phê duyệt khách hàng, không phải thiếu shipment trong kế hoạch – hành động này leo thang không cần thiết và có thể làm hỏng mối quan hệ stakeholder.

• Find the root cause of the issue and discuss the customer's current engagement.
  ✅ Đúng: Như đã giải thích ở phần 2. Đây là cách tiếp cận proactive và value-driven, phù hợp Root Cause Analysis Tools (Fishbone Diagram, 5 Whys) trong Manage Quality và Stakeholder Engagement Assessment Matrix. PMBOK 7th nhấn mạnh "Engage stakeholders effectively" để giải quyết bottleneck mà không ảnh hưởng scope/baseline.

• Inform the customer that subsequent packages cannot be manufactured.
  ❌ Sai: Phương án tiêu cực, vi phạm Professional Responsibility (Code of Ethics) và Risk Management. Nó tạo rủi ro lớn hơn (dừng sản xuất) mà không phân tích nguyên nhân, có thể dẫn đến tranh chấp hợp đồng. PMP yêu cầu collaborative approach thay vì đe dọa, đặc biệt khi logistics đã cố gắng giao tiếp.

• Request a delivery date extension from the customer.
  ❌ Sai: Giả định vấn đề là schedule mà không xác định root cause, bỏ qua Schedule Baseline Control. Yêu cầu extension cần formal negotiation và evidence (như delay log), không phải hành động đầu tiên. Điều này có thể làm PM mất uy tín và không giải quyết engagement kém của khách hàng.

📘 4. Dẫn nguồn tài liệu tham khảo:

• PMBOK Guide 7th Edition (2021): Section 4.6 Manage Stakeholder Engagement; Principle 7: Optimize Risk Responses (Root Cause).
• PMP Exam Content Outline (2021, cập nhật 2026): Domain 2: Executing (23%), Task: Employ root cause analysis (Task 7.10).
• PMI Agile Practice Guide (2021): Emphasizes iterative communication và stakeholder collaboration.
• PMI Code of Ethics (2022): Responsibility to stakeholders qua transparent engagement.

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 nhóm dự án đang phát triển một sản phẩm được lập kế hoạch qua nhiều vòng lặp (multiple iterations), và họ đang cung cấp giá trị gia tăng dần dần (incremental value). Câu hỏi tập trung vào thời điểm nên thể hiện giá trị (demonstrate the value) đã tạo ra.
✅ Đây là tình huống điển hình trong phương pháp Agile hoặc Iterative Development theo PMP (PMBOK® Guide 7th Edition và các nguyên tắc Agile Hybrid). Mục tiêu là đảm bảo giá trị được kiểm tra, phản hồi và điều chỉnh liên tục để giảm rủi ro, tăng tính thích ứng và đáp ứng nhu cầu khách hàng nhanh chóng. Không chờ đến cuối dự án mới demo, vì điều này trái với tinh thần "delivering value early and often".

✅ Đáp án đúng: At the end of each and every iteration

Lý do lựa chọn:
🛠️ Trong Agile/Iterative approaches, giá trị phải được thể hiện ở cuối mỗi iteration (như Sprint Review trong Scrum) để stakeholders xem xét, cung cấp feedback kịp thời. Điều này đảm bảo sản phẩm luôn ở trạng thái "potentially shippable", phù hợp với nguyên tắc "Deliver value iteratively" (PMBOK® 7, Principle 4: Deliver Value Early and Often). Nếu chỉ demo ở một số thời điểm, sẽ mất cơ hội cải tiến liên tục và tăng rủi ro tích tụ. Kiến thức cập nhật đến 2026 (PMP Exam Content Outline 2021+, Agile Focus 50%) nhấn mạnh hybrid methods yêu cầu demo thường xuyên.

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

• ❌ [SAI] After full development is completed
  Phương án này sai vì nó theo Waterfall approach truyền thống, chờ hoàn thành toàn bộ mới demo. Trong dự án iterative với incremental value, điều này làm chậm feedback, tăng rủi ro và trái với Agile Manifesto ("Working software over comprehensive documentation"). Không phù hợp với multiple iterations.

• ❌ [SAI] When the sponsor approves the increment
  Phương án này sai vì phụ thuộc duy nhất vào sponsor, bỏ qua stakeholders rộng hơn (product owner, team, customers). Demo chỉ khi sponsor approve sẽ tạo bottleneck, không đảm bảo giá trị thực sự và feedback đa chiều. PMP khuyến nghị demo định kỳ, không phải approval-based.

• ❌ [SAI] When a major feature is completed
  Phương án này sai vì chỉ demo khi tính năng lớn hoàn thành, bỏ lỡ giá trị nhỏ từ các iteration. Iterative development yêu cầu demo toàn bộ increment (có thể chỉ minor features) ở mỗi cuối iteration để kiểm tra tích hợp sớm, tránh "big bang" integration risks.

• ✅ [ĐÚNG] At the end of each and every iteration
  (Như đã giải thích ở trên) 🏆 Đây là best practice chuẩn Agile/PMP.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021, vẫn chuẩn đến 2026): Section 2.5 Agile Hybrid, Principle 4 (Deliver Value Iteratively).
• PMI Agile Practice Guide (2017, tích hợp PMBOK 7): Chapter 3.3 Sprint Review/Demo.
• PMP Exam Content Outline (2021+): Domain III: Business Environment (Agile 50%+), Task 6: Demonstrate value delivery.
• Scrum Guide 2020 (tương thích PMP): Sprint Review ở cuối mỗi Sprint.

🧠 Lưu ý học PMP: Câu hỏi kiểm tra sự khác biệt Waterfall vs. Agile – hãy nhớ "iteration end demo" là key! Nếu thi, chọn luôn option nhấn mạnh "each iteration".

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

Câu hỏi này thuộc lĩnh vực Quản lý Phạm vi (Scope Management) và Quản lý Chất lượng (Quality Management) trong PMP, theo PMBOK Guide 7th Edition (cập nhật đến 2024 và áp dụng đến 2026). Tình huống mô tả: Vào cuối dự án (toward the end of a project), Quản lý dự án (project manager) không nhận được sự phê duyệt từ một stakeholder chính (key stakeholder) vì các sản phẩm bàn giao (deliverables) không hoạt động như mong đợi (not functioning as expected).

📌 Vấn đề cốt lõi: Deliverables không đáp ứng kỳ vọng, dẫn đến thiếu phê duyệt. PM cần hành động tiếp theo (next) để xác định nguyên nhân gốc rễ, thường liên quan đến việc kiểm tra xem deliverables có đáp ứng đầy đủ các yêu cầu (requirements) đã được xác định ban đầu hay không. Đây là tình huống phổ biến ở giai đoạn Validate Scope hoặc Close Project, nơi cần verify traceability từ requirements đến sản phẩm cuối cùng.

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

Đáp án đúng: Review the requirements traceability matrix.
🛠️ Lý do: Requirements Traceability Matrix (RTM) là công cụ chính để theo dõi và xác minh (trace and verify) rằng tất cả các yêu cầu (requirements) từ stakeholder đã được triển khai đúng vào deliverables. Khi deliverables không "functioning as expected", PM cần review RTM đầu tiên để kiểm tra sự liên kết giữa requirements ban đầu → design → implementation → test → deliverables. Nếu có khoảng trống (gap), PM có thể phát hiện vấn đề ngay, hỗ trợ điều chỉnh hoặc giải thích với stakeholder.
📘 Dẫn nguồn: PMBOK Guide 7th Edition, trang 139-141 (Scope Management), và PMI's Practice Standard for Requirements Management (2021), nhấn mạnh RTM là "best practice" cho validation ở cuối dự án.

🔍 Phân tí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. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với emoji để nổi bật:

• [SAI] Review the stakeholder engagement plan.
  ❌ Sai vì: Stakeholder Engagement Plan tập trung vào cách tương tác và quản lý kỳ vọng của stakeholder (engagement strategies), không trực tiếp kiểm tra chức năng của deliverables. Vấn đề ở đây là chất lượng chức năng (functioning), không phải engagement. Review plan này chỉ hữu ích nếu vấn đề là giao tiếp kém, nhưng câu hỏi nhấn mạnh "deliverables not functioning".

• [ĐÚNG] Review the requirements traceability matrix.
  ✅ Đúng vì: Như đã giải thích ở trên, RTM là công cụ traceability tối ưu để verify deliverables có khớp requirements không. Đây là bước next logical action ở cuối dự án, giúp PM nhanh chóng xác định gap và hỗ trợ phê duyệt. Phù hợp với nguyên tắc Verify Scope trong PMBOK 7th.

• [SAI] Review the quality management plan.
  ❌ Sai vì: Quality Management Plan mô tả cách đảm bảo chất lượng tổng thể (processes for quality assurance/control), nhưng không tập trung vào traceability của requirements. Vấn đề "not functioning as expected" có thể liên quan quality, tuy nhiên RTM ưu tiên hơn vì nó trực tiếp link đến kỳ vọng từ requirements. Quality plan chỉ là bước sau nếu RTM OK.

• [SAI] Review the work breakdown structure (WBS).
  ❌ Sai vì: WBS là phân tích cấu trúc công việc (hierarchical decomposition of scope), dùng ở giai đoạn lập kế hoạch để xác định tasks. Cuối dự án, review WBS không giúp kiểm tra chức năng deliverables (đã hoàn thành), mà chỉ xem work có đầy đủ không – không giải quyết "functioning as expected".

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

• PMBOK Guide 7th Edition (2021): Domain 3: Project Work (Scope & Quality), Tools như RTM (trang 139).
• PMI's Agile Practice Guide (2017, tích hợp 7th Ed.): Nhấn mạnh traceability trong validation.
• PMP Exam Content Outline (2021, cập nhật 2024): People Domain (Stakeholder) & Process Domain (Scope Validation).
• Process Groups: A Practice Guide (2022): Closing Process Group – Verify & Validate.

🧠 Lời khuyên PMP: Luôn ưu tiên root cause analysis qua traceability trước khi blame quality hoặc engagement! Nếu thi PMP, nhớ RTM là "go-to" tool cho scope issues.