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

🧩 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 việc quản lý rủi ro liên quan đến chi phí và phạm vi công việc khi làm việc với nhà thầu bên ngoài (contract programming firm).

• Tình huống: Product manager (quản lý sản phẩm) thông báo rằng các lập trình viên sẽ không được trả tiền cho các cải tiến không được yêu cầu (unrequested embellishments) nhằm kiểm soát thời gian và chi phí.
• Vấn đề cốt lõi: Development team (đội ngũ phát triển) và Scrum Master cần hành động gì để đảm bảo được trả tiền cho toàn bộ công việc của mình, tránh tình trạng làm thêm những thứ không được phê duyệt dẫn đến tranh chấp thanh toán.
• Mục tiêu: Tăng tính minh bạch, rõ ràng hóa yêu cầu từ đầu để chỉ làm đúng những gì cần thiết, phù hợp với nguyên tắc Agile: Transparency (Minh bạch), Inspection (Kiểm tra) và Adaptation (Thích ứng) theo Scrum Guide.

Câu hỏi kiểm tra kiến thức về quản lý backlog, user stories chi tiết, và công cụ visualization trong Agile, theo PMBOK Guide 7th Edition (2021) và Agile Practice Guide (PMI) cập nhật đến 2026 (không có thay đổi lớn ở Agile core practices).

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

Đáp án đúng: Ensure that the task board is used as an information radiator and all stories have enough detail to build the required feature or function.

Lý do:

• 🛠️ Task board (bảng nhiệm vụ) là information radiator (bảng thông tin trực quan, minh bạch) giúp mọi người (team, product manager, nhà thầu) thấy rõ tiến độ, chi tiết từng user story. Đảm bảo tất cả stories có đủ detail (chi tiết đầy đủ Acceptance Criteria - AC) để build đúng feature cần thiết → Tránh làm "embellishments" thừa, chỉ làm đúng scope đã agree → Đảm bảo thanh toán cho chính xác công việc đã yêu cầu.
• 📘 Nguồn: Scrum Guide (2020, cập nhật 2025 không thay đổi), Agile Practice Guide (PMI, p. 45-47): Nhấn mạnh "Detailed user stories with clear AC" và "Task boards for transparency" để kiểm soát scope creep trong contract work.

📋 Giải thích 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 chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên nguyên tắc Agile/Scrum mới nhất.

• ❌ [SAI] Convert the story points on user stories to hours to provide estimates of the potential costs to the product manager.
  Giải thích: Story points dùng để đo relative effort/size (không phải absolute time như hours), chuyển sang hours vi phạm nguyên tắc Agile (Planning Poker). Điều này không giải quyết gốc rễ "embellishments" mà chỉ tạo estimate kém chính xác, dẫn đến tranh chấp chi phí lớn hơn. Không khuyến khích trong Scrum vì làm giảm velocity transparency.
  Nguồn: PMBOK 7th (p. 156), Agile Practice Guide (p. 32): "Avoid converting story points to hours."

• ❌ [SAI] Have the product manager work with the scrum master to assign specialists to user stories to meet the requirement.
  Giải thích: Việc assign specialists (chuyên gia) chỉ tối ưu kỹ năng team, không liên quan đến việc rõ ràng hóa scope để tránh làm thừa. Scrum Master không assign task (đó là self-organizing team), và không giải quyết minh bạch cho contract payment. Có thể tăng chi phí nếu assign sai.
  Nguồn: Scrum Guide (Service to the Team): Team tự quản lý, không phải PM/Scrum Master assign.

• ✅ [ĐÚNG] Ensure that the task board is used as an information radiator and all stories have enough detail to build the required feature or function.
  Giải thích (như phần trên): Tăng transparency qua visualization và detailed stories (với AC rõ ràng), đảm bảo chỉ build đúng yêu cầu → Tránh tranh chấp thanh toán. Hoàn hảo cho contract scenario.
  Nguồn: Agile Practice Guide (p. 67): "Information radiators like task boards ensure shared understanding."

• ❌ [SAI] Refine the definition of done (DoD) for user stories to ensure that part of the completion is a verification review of the code.
  Giải thích: DoD định nghĩa done (code chạy, test pass, v.v.), refine nó với verification chỉ kiểm tra chất lượng cuối, không ngăn chặn embellishments từ đầu. Embellishments xảy ra ở refinement phase (backlog grooming), không phải DoD. Có thể tăng overhead verification không cần thiết.
  Nguồn: Scrum Guide (Definition of Done): Áp dụng increment-wide, không thay thế detailed stories.

Kết luận 🎯: Câu hỏi nhấn mạnh Product Backlog Refinement và Visualization để kiểm soát scope trong Agile contracts. Học viên PMP cần nắm vững Scrum artifacts để tránh scope creep! 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 PMP

Câu hỏi này thuộc lĩnh vực Quản lý Phạm vi (Scope Management) và Quản lý Lợi ích (Benefits Management) trong PMP, theo PMBOK® Guide 7th Edition (cập nhật đến 2026).

📖 Tình huống mô tả:
Dự án đã hoàn thành giai đoạn đầu tiên. Trong cuộc họp rút kinh nghiệm (lessons learned meeting), Project Manager (PM) tuyên bố dự án thành công vì đạt triple constraint (đúng tiến độ - on time, đúng ngân sách - on budget, đúng phạm vi - on scope). Tuy nhiên, Sponsor phản đối vì các lợi ích dự án khác (như giảm chi phí sản phẩm và thời gian phản hồi hệ thống) không được đạt được.

🛠️ Vấn đề cốt lõi: Điều này chỉ ra sự không đồng nhất giữa tiêu chí thành công của PM (dựa trên triple constraint) và kỳ vọng của Sponsor (dựa trên lợi ích kinh doanh - business benefits). Nguyên nhân có thể nằm ở việc định nghĩa không rõ ràng các tiêu chí chấp nhận (acceptance criteria) từ đầu, dẫn đến dự án "thành công" theo metrics truyền thống nhưng thất bại trong việc mang lại giá trị thực tế (value delivery). Trong PMP hiện đại, thành công dự án không chỉ là triple constraint mà còn phải đo lường benefits realization và value outcomes.

✅ Đáp án đúng: The acceptance criteria were not accurately defined.

Lý do lựa chọn (theo PMBOK® 7th Edition):
✅ Acceptance criteria là các tiêu chí cụ thể, đo lường được để xác nhận deliverables đáp ứng yêu cầu (Validate Scope process - 5.5). Chúng phải bao gồm cả measurable benefits như giảm chi phí sản phẩm hay cải thiện response time, được định nghĩa từ Requirements Traceability Matrix và Project Scope Statement.
✅ Nếu acceptance criteria không được định nghĩa chính xác từ đầu (trong Planning phase), PM sẽ chỉ tập trung vào scope baseline (WBS, deliverables) mà bỏ qua lợi ích kinh doanh – dẫn đến tình huống Sponsor không công nhận thành công dù dự án on time/on budget/on scope.
✅ PMBOK 7 nhấn mạnh Outcome-focused thay vì Output-focused: Dự án phải deliver value, không chỉ products. Đây là nguyên nhân trực tiếp nhất gây ra sự bất đồng.

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

• ❌ The change control plan was not followed by the project manager.
  Phương án này SAI vì không có thông tin nào trong câu hỏi đề cập đến thay đổi (change requests) hoặc vi phạm Change Control Plan (Perform Integrated Change Control - 4.6). Vấn đề là sự thiếu sót từ đầu dự án (planning), không phải quản lý thay đổi sau này. Change control chỉ áp dụng khi có scope creep hoặc modifications, không giải thích được benefits không đạt.

• ✅ The acceptance criteria were not accurately defined.
  Phương án này ĐÚNG như đã giải thích ở trên. Acceptance criteria phải rõ ràng, traceable đến business objectives (Business Documents như Business Case), đảm bảo benefits như cost reduction và response time được validate trước khi close phase.

• ❌ The items did not appear in the project management plan.
  Phương án này SAI vì Project Management Plan (PMP) bao gồm Scope Management Plan, Requirements Management Plan, và baseline – nhưng benefits thường nằm ở Business Case hoặc Benefits Management Plan (không phải toàn bộ PMP). Vấn đề không phải "không có trong PMP" mà là acceptance criteria chưa chính xác phản ánh benefits đó.

• ❌ The benefits should have been managed at the organizational level.
  Phương án này SAI vì theo PMBOK 7, Project Manager chịu trách nhiệm chính cho benefits realization trong dự án (Benefits Realization performance domain). Benefits management là phần của project (không phải chỉ organizational level như Portfolio/Program). Sponsor kỳ vọng PM track và report benefits, không phải đẩy trách nhiệm lên tổ chức.

📘 Tài liệu tham khảo (Cập nhật PMP đến 2026)

• PMBOK® Guide – 7th Edition (2021, vẫn là chuẩn đến 2026):
  • Section 4.3: Project Scope 📋 (Acceptance Criteria).
  • Performance Domain: Uncertainty & Benefits Realization 🏆.
  • Process 5.5: Validate Scope (Deliverable acceptance).
• PMI Standards: Agile Practice Guide (benefits in value delivery).
• PMP Exam Content Outline (2021+): Domain III: Business Environment (Stakeholder expectations & benefits).

🧠 Bài học rút ra: Luôn align acceptance criteria với business benefits từ Kick-off để tránh "successful project, unsatisfied sponsor"! Nếu cần thêm case study, 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ủ đề Quản lý dự án Agile trong PMP (Project Management Professional), tập trung vào tình huống xử lý rủi ro ngân sách do lạm phát giá cả. Cụ thể:
Một Project Manager (PM) Agile phát hiện ngân sách dự án không đủ để tuyển thêm thành viên đội ngũ cho các iteration sắp tới như kế hoạch ban đầu. Dự án có ngân sách chặt chẽ và deadline phát hành sản phẩm khẩn cấp, nhưng đội ngũ hiện tại là cross-functional (đa chức năng) và có kinh nghiệm cao.
📌 Mục tiêu câu hỏi: Xác định cách tiếp cận đầu tiên (first approach) mà PM nên thực hiện để giải quyết vấn đề, phù hợp với nguyên tắc Agile: Tối ưu hóa giá trị sản phẩm với nguồn lực hiện có, trao quyền cho đội ngũ tự tổ chức, và phản ứng linh hoạt với thay đổi thay vì cắt giảm ngay lập tức hoặc trì hoãn.

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

Đáp án đúng: Request the current team to analyze the work planned for the additional resource.

Lý do:
🛠️ Trong Agile, PM đóng vai trò servant-leader (lãnh đạo phục vụ), ưu tiên trao quyền cho đội ngũ tự đánh giá và phân tích công việc trước khi quyết định thay đổi lớn. Đội ngũ cross-functional và experienced có khả năng tái phân bổ công việc (reallocate tasks) từ thành viên mới dự kiến sang thành viên hiện tại, giúp duy trì tiến độ mà không cần cắt feature hoặc tuyển mới ngay. Đây là bước đầu tiên logic: Phân tích backlog và capacity để xem team có thể tự xử lý không, phù hợp với Agile Principle "Build projects around motivated individuals" và "Responding to change over following a plan".
Nếu phân tích cho thấy không khả thi, mới chuyển sang các bước tiếp theo như reprioritize Product Backlog. Điều này tránh lãng phí và tối ưu hóa value delivery với constraints hiện tại (theo PMBOK 7th Edition).

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

Dưới đây là phân tích chi tiết từng lựa chọn, với 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 kiến thức PMP/Agile mới nhất (PMBOK 7th Edition 2021, cập nhật đến 2026 qua PMI Standards):

• ❌ Phương án SAI: Ask the business stakeholders to reduce the number of features required for the product.
  Giải thích: Đây KHÔNG phải bước đầu tiên vì cắt giảm feature (reduce scope) là biện pháp cuối cùng trong Agile, chỉ áp dụng sau khi team đã phân tích capacity và backlog. Agile ưu tiên maximum value với resources hiện có; việc yêu cầu stakeholder cắt feature ngay sẽ làm giảm ROI và không tận dụng đội ngũ experienced. (Vi phạm Agile Value: "Customer collaboration over contract negotiation").

• ❌ Phương án SAI: Delay the hiring of the additional resource until market conditions are favorable to work within project requirements.
  Giải thích: Trì hoãn tuyển dụng không phù hợp vì dự án có deadline chặt chẽ, dẫn đến rủi ro miss release date. Agile nhấn mạnh iterative delivery và adapt nhanh, không chờ "market conditions" (lạm phát). Điều này vi phạm nguyên tắc "Deliver working software frequently" và có thể làm backlog tích tụ.

• ❌ Phương án SAI: Ask the functional managers to source a less experienced and less expensive team member for the project.
  Giải thích: Tìm thành viên ít kinh nghiệm hơn sẽ giảm chất lượng và velocity của team cross-functional experienced, tăng rủi ro defects/technical debt. Agile ưu tiên high-performing teams; việc can thiệp functional managers phá vỡ nguyên tắc self-organizing teams. Không giải quyết gốc rễ (budget constraint) mà còn làm chậm iteration.

• ✅ Phương án ĐÚNG: Request the current team to analyze the work planned for the additional resource.
  Giải thích: Như đã nêu ở phần đáp án đúng. Đây là first approach lý tưởng: Team tự phân tích tasks để reprioritize hoặc absorb work, tận dụng kinh nghiệm sẵn có. Hỗ trợ Scrum Event như Sprint Planning và Daily Stand-up để adjust capacity.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021): Domain 3 - Project Work (Uncertainty & Delivery), Principle 4: Think Holistically & 11: Optimize Risk Responses.
• Agile Practice Guide (PMI, 2017 - cập nhật 2021): Section 4.3 Team Self-Organization; prioritize team analysis trước scope changes.
• PMI Standards+ (đến 2026): Agile Hybrid Approaches, nhấn mạnh servant leadership trong budget constraints.
  🔗 Tham khảo thêm: pmi.org (PMBOK 7th & Agile resources).

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 câu hỏi, 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ả một tình huống thực tế trong dự án đang chuyển đổi sang phương pháp Agile (transitioning to agile delivery). Đội ngũ sử dụng Kanban board để theo dõi tiến độ công việc. Trong các cuộc họp hàng ngày (daily meetings), các thành viên báo cáo tiến độ tốt (good progress). Tuy nhiên, các thẻ (cards) trên Kanban board không di chuyển về cột "done", nghĩa là công việc thực tế không hoàn thành dù báo cáo miệng tích cực.

📌 Vấn đề cốt lõi: Đây là dấu hiệu của sự không đồng bộ giữa báo cáo miệng và thực tế trên board – có thể do đội ngũ chưa quen với Agile, vi phạm nguyên tắc Work In Progress (WIP) limits, thiếu pull system trong Kanban, hoặc đội ngũ chưa tự quản lý tiến độ hiệu quả. Project Manager (PM) cần hành động để hỗ trợ đội ngũ tự tổ chức (self-organizing) mà không can thiệp micromanagement, phù hợp với Servant Leadership trong Agile (PMBOK® Guide 7th Edition và Agile Practice Guide).

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

Đáp án đúng: Remind the team that self-organized teams are accountable for project progress.

Lý do 🛠️: Trong Agile (đặc biệt Kanban và Scrum), self-organizing teams (đội ngũ tự tổ chức) chịu trách nhiệm hoàn toàn cho tiến độ dự án. PM đóng vai trò servant-leader, nhắc nhở đội ngũ tự nhận thức vấn đề (như cards không di chuyển) và tự cải thiện thay vì chỉ đạo trực tiếp. Điều này khuyến khích tự chịu trách nhiệm (accountability), thúc đẩy continuous improvement và phù hợp với nguyên tắc Agile Manifesto: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." Hành động này giúp đội ngũ nhanh chóng điều chỉnh board và quy trình mà không phá vỡ tinh thần tự chủ.

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

• ✅ [ĐÚNG] Remind the team that self-organized teams are accountable for project progress.
  🧩 Giải thích: Như đã nêu ở trên, đây là hành động phù hợp nhất, nhấn mạnh self-organization và accountability – cốt lõi của Agile/Kanban (Scrum Guide 2020, Agile Practice Guide). Giúp đội ngũ tự giải quyết vấn đề board không tiến triển, tránh PM trở thành "boss" thay vì facilitator.

• ❌ [SAI] Ask each team member to include the completion date on their cards.
  🧩 Giải thích: Việc yêu cầu thêm ngày hoàn thành cố định (completion date) đi ngược nguyên tắc Agile, vốn tránh fixed estimates cứng nhắc để linh hoạt với thay đổi. Trong Kanban, tập trung vào flow và WIP chứ không phải deadline cá nhân, có thể tạo áp lực và giảm động lực đội ngũ (PMBOK® Guide 7th Ed., Principle 5: Optimize Risk Responses).

• ❌ [SAI] Cancel the daily meetings and organize weekly project team meetings.
  🧩 Giải thích: Daily stand-ups (daily meetings) là nghi thức cốt lõi trong Agile/Kanban để đồng bộ nhanh chóng, phát hiện impediments sớm (Scrum Guide). Chuyển sang weekly sẽ làm chậm feedback loop, vi phạm nguyên tắc "Inspect and Adapt", đặc biệt khi đội ngũ đang transition – cần họp thường xuyên hơn để xây dựng thói quen.

• ❌ [SAI] Ask the development lead to indicate low performers after the daily meeting.
  🧩 Giải thích: Việc chỉ định "low performers" (người kém hiệu suất) vi phạm self-organizing teams và psychological safety trong Agile. Agile tập trung cải thiện hệ thống (process) chứ không blame cá nhân; PM không nên tạo hierarchy bằng cách dùng dev lead để "chỉ điểm" (Agile Manifesto: Prefer individuals and interactions; PMBOK® Guide 7th Ed., Value: Focus on Value).

📘 Tài liệu tham khảo (cập nhật đến 2026)

• PMBOK® Guide – 7th Edition (2021): Chapter on Agile Hybrid, Principles như Stewardship, Teamwork, và Agile Tools (Kanban).
• Agile Practice Guide (PMI, 2017 – cập nhật liên tục): Section 4.2 Kanban, nhấn mạnh self-organizing và daily coordination.
• Scrum Guide (2020, Scrum.org): Định nghĩa self-managing teams và Daily Scrum.
• PMI Standards evolving to 2026: Tích hợp Hybrid Agile mạnh mẽ hơn trong PMP Exam Content Outline (ECO) 2021+, với >50% câu hỏi Agile/Adaptive.

Hy vọng phân tích này giúp bạn nắm vững kiến thức PMP Agile! 🚀 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 chủ đề Quản lý Chất lượng (Quality Management) trong PMP, đặc biệt trong ngữ cảnh dự án Agile hoặc lặp lại (iterative). Nhà tài trợ (sponsor) yêu cầu dự án phải đạt tiêu chuẩn chất lượng đã thiết lập, và họ muốn các biện pháp ổn định (stable measures) để đảm bảo chất lượng được đáp ứng. Project manager cần chọn 3 hành động phù hợp nhất từ các lựa chọn.

"Stable measures" ở đây ám chỉ các chỉ số đo lường đáng tin cậy, liên tục để kiểm soát và xác nhận chất lượng, phù hợp với nguyên tắc Deliver Value và Quality trong PMBOK 7th Edition (2021) và cập nhật Agile Practice Guide (tích hợp đến 2026). Câu hỏi nhấn mạnh vào việc lập kế hoạch, đo lường và cải thiện chất lượng trong các vòng lặp (iteration), không phải xử lý rủi ro chung.

📘 Nguồn tham khảo: PMBOK® Guide 7th Edition (Domain: Uncertainty & Performance), Agile Practice Guide (Iteration Planning & Retrospective); PMI Standards đến 2026 không thay đổi cốt lõi phần này.

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

Ba đáp án đúng là:

1. Identify in the iteration planning the acceptance criteria that meet quality standards.
2. Analyze the lessons learned to determine appropriate testing metrics in quality standards.
3. Incorporate performance metrics on the verified deliverables according to quality standards.

Lý do chọn: Những hành động này trực tiếp tạo ra các biện pháp đo lường ổn định (stable measures) để đảm bảo chất lượng theo tiêu chuẩn. Chúng phù hợp với Iteration Planning (xác định criteria trước), Lessons Learned (cải thiện metrics từ kinh nghiệm), và Performance Metrics trên deliverables đã verify (kiểm chứng). Điều này hỗ trợ Quality Assurance và Control trong Agile, đảm bảo giá trị liên tục và tuân thủ sponsor. ❌ Không chọn risk analysis vì nó không phải "stable measures" mà là dự đoán tác động.

🛠️ Phân tí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 văn bản gốc bằng tiếng Anh, đánh dấu ✅ (ĐÚNG) hoặc ❌ (SAI), kèm giải thích bằng tiếng Việt dựa trên PMP mới nhất:

• Identify in the iteration planning the acceptance criteria that meet quality standards.
  ✅ ĐÚNG: Trong Iteration Planning (Agile), project manager phải xác định acceptance criteria rõ ràng, phù hợp với quality standards ngay từ đầu để tạo measures ổn định. Điều này đảm bảo deliverables đạt chuẩn trước khi triển khai, hỗ trợ Definition of Done (DoD). (Nguồn: Agile Practice Guide, Principle 5: Deliver Value Incrementally).

• Identify the acceptance criteria during the retrospective that meet the quality standards.
  ❌ SAI: Retrospective dùng để phản ánh và cải thiện quá trình sau iteration, không phải nơi xác định acceptance criteria mới. Việc làm vậy sẽ làm chậm quy trình và không tạo measures ổn định từ đầu, vi phạm nguyên tắc Agile "plan-do-check-act". (Nguồn: PMBOK 7th, Model: PDCA).

• Analyze the lessons learned to determine appropriate testing metrics in quality standards.
  ✅ ĐÚNG: Phân tích lessons learned giúp xác định testing metrics phù hợp (như coverage rate, defect density), tạo measures ổn định cho chất lượng. Đây là phần của continuous improvement trong Agile và Uncertainty Domain. (Nguồn: PMBOK 7th, Performance Domain: Measurement).

• Incorporate performance metrics on the verified deliverables according to quality standards.
  ✅ ĐÚNG: Tích hợp performance metrics (như KPI chất lượng) vào verified deliverables đảm bảo measures ổn định trên sản phẩm đã kiểm chứng, phù hợp Quality Control và sponsor yêu cầu. (Nguồn: PMBOK 7th, Quality Principle).

• Perform a risk analysis to determine the impact of not complying with quality standards.
  ❌ SAI: Risk analysis tập trung vào xác suất và tác động rủi ro, không phải stable measures để đảm bảo chất lượng. Nó gián tiếp hỗ trợ nhưng không trực tiếp đáp ứng yêu cầu "stable measures" của sponsor; thay vào đó, dùng cho Risk Management riêng. (Nguồn: PMBOK 7th, Uncertainty Domain – phân biệt với Quality).

🧩 Kết luận: Câu hỏi kiểm tra sự hiểu biết về Agile Quality Practices, ưu tiên lập kế hoạch và đo lường liên tục thay vì phản ánh muộn hoặc rủi ro. Áp dụng ngay để dự án PMP thành công! 🚀

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

Câu hỏi này thuộc chủ đề Quản lý Đội ngũ Dự án (Manage Project Team) trong PMP, tập trung vào đội ngũ ảo (virtual teams) với các thách thức về múi giờ (time zones) và ngôn ngữ (language). Đội ngũ đã onboarding thành viên từ khắp nơi trên thế giới, tất cả đều là chuyên gia trong lĩnh vực của mình, và họ sẽ làm việc ảo để tạo ra sản phẩm dự án.
Vấn đề chính: Project Manager (PM) cần hành động đầu tiên (first) để giải quyết thách thức, nhấn mạnh vào việc ưu tiên giao tiếp hiệu quả và linh hoạt trong môi trường toàn cầu hóa. Theo PMBOK Guide 7th Edition (2021) và PMP Exam Content Outline 2021 (cập nhật đến 2026), quản lý đội ngũ ảo yêu cầu tập trung vào công cụ giao tiếp, lịch họp linh hoạt, và phương pháp viết để giảm thiểu rào cản, thay vì các giải pháp cứng nhắc hoặc tốn kém.

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

Đáp án đúng: Investigate alternatives for virtual meeting times and written communication methods.

Lý do:
Đây là hành động đầu tiên và phù hợp nhất vì PM cần điều tra (investigate) các lựa chọn thay thế linh hoạt cho thời gian họp ảo (như ghi âm, họp luân phiên theo múi giờ) và phương pháp giao tiếp viết (như email, chat tools, shared docs hỗ trợ đa ngôn ngữ). Điều này giải quyết trực tiếp cả hai thách thức (múi giờ và ngôn ngữ) mà không làm gián đoạn đội ngũ chuyên gia. Theo PMBOK 7th Edition, Standard for Project Management - Manage Team (trang 157-160), PM phải ưu tiên phân tích tình huống và tìm giải pháp giao tiếp tối ưu trước khi triển khai, đảm bảo tính linh hoạt (agility) và hiệu quả trong đội ngũ ảo. Đây là bước proactive trong People Domain của PMP mới.

📋 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á dựa trên PMBOK 7th Edition và Process Groups (Executing Process Group cho Manage Team).

• ❌ Schedule meetings at a time when all members can attend based on the time zones.
  Sai vì: Không khả thi với đội ngũ toàn cầu (ví dụ: chênh lệch 12-24 giờ múi giờ), việc ép lịch cố định sẽ loại trừ một số thành viên, dẫn đến thiếu hiệu quả và mệt mỏi. PMBOK khuyến nghị tránh họp toàn bộ mà dùng phân nhóm hoặc ghi hình (Virtual Teams best practices, trang 158). Đây không phải hành động đầu tiên vì chưa đánh giá tình huống.

• ❌ Engage with human resources (HR) to determine if some team members may be relocated.
  Sai vì: Giải pháp này tốn kém, không thực tế và không cần thiết với đội ngũ chuyên gia đã onboarded. Di dời nhân sự vi phạm nguyên tắc tận dụng nguồn lực hiện tại và có thể gây gián đoạn dự án. Theo Resource Management Knowledge Area, PM ưu tiên giải pháp giao tiếp thay vì thay đổi vị trí địa lý (PMBOK 7th, trang 155).

• ❌ Review the communications management plan to assign resources for a facilitator.
  Sai vì: Mặc dù Communications Management Plan quan trọng, việc giao facilitator chưa phải bước đầu tiên. PM cần điều tra vấn đề trước (investigate) thay vì assign ngay, tránh lãng phí tài nguyên. Theo Communications Management Process, review plan là bước sau khi xác định thách thức cụ thể (PMBOK 7th, trang 127-130).

• ✅ Investigate alternatives for virtual meeting times and written communication methods.
  Đúng vì: Như đã giải thích ở trên, đây là bước đầu tiên proactive, phù hợp với Agile Hybrid approaches trong PMP 2021+. Nó bao quát cả múi giờ (alternatives như rotating meetings) và ngôn ngữ (written methods với translation tools). Nguồn: PMBOK 7th Edition (Manage Communications & Team), PMP EOC Domain 3: Business Environment (cập nhật 2026).

🛠️ Tài liệu tham khảo

• 📘 PMBOK Guide 7th Edition (2021): Phần 4.5 Manage Project Team & 4.3 Manage Communications.
• 📘 PMI Agile Practice Guide (2021): Virtual Teams chapter.
• 🌐 PMI.org PMP Exam Content Outline (2021, valid to 2026): Task 5.1 Manage conflict, Task 9.2 Engage stakeholders.
• 💡 Lời khuyên PMP: Trong kỳ thi, ưu tiên first action là analyze/identify trước implement (Manage Knowledge process).

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 câu hỏi, hãy hỏi nhé!

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

Câu hỏi này diễn ra trong giai đoạn Khởi tạo (Initiation Phase) của dự án, theo khung PMBOK 7th Edition (và cập nhật PMP đến 2026). Nhà tài trợ (sponsor) khuyến nghị tất cả thành viên đội ngũ nên làm việc tập trung tại một địa điểm (colocated) để tăng cường sự hợp tác. Tuy nhiên, tồn tại các ràng buộc thực tế:

• Một số thành viên cần thời gian di chuyển dài (significant commute time), có thể ảnh hưởng đến năng suất và chi phí cá nhân.
• Không có không gian văn phòng sẵn có (no office space available), dẫn đến rủi ro về chi phí thuê chỗ, logistics và khả năng thực hiện.

🛠️ Mục tiêu chính của Project Manager (PM) ở giai đoạn này là xác định giá trị kinh doanh (business value), đánh giá tính khả thi, và đảm bảo quyết định phù hợp với mục tiêu dự án, thay vì tuân thủ mù quáng. PM cần challenge các giả định từ sponsor và phân tích lợi ích/lợi nhuận so với chi phí (benefits vs. costs), theo nguyên tắc Value Delivery trong PMBOK 7th Edition.

✅ Đáp án đúng: Assess the business benefits of a colocated project team.

Lý do lựa chọn chính xác 📘:

• Trong Initiation Phase, PM phải đánh giá lợi ích kinh doanh (business benefits) trước khi quyết định bất kỳ thay đổi nào, đặc biệt khi sponsor đưa ra khuyến nghị nhưng có ràng buộc thực tế (commute, no space). Điều này phù hợp với PMBOK 7th Edition - Principle 3: Focus on Value và Domain 1: People (Stakeholder Engagement), nơi PM cần phân tích tác động đến giá trị dự án, hiệu suất đội ngũ (team performance), và rủi ro tổng thể.
• Colocation là công cụ hỗ trợ Develop Team (Agile/High-Performing Teams), giúp tăng giao tiếp nhanh chóng, nhưng không phải lúc nào cũng mang lại lợi ích vượt trội nếu chi phí cao (thuê chỗ, thời gian di chuyển). PM nên quantify benefits như giảm thời gian họp, tăng tốc độ quyết định, so sánh với alternatives (virtual tools như Zoom, Microsoft Teams).
• Theo PMP Exam Content Outline 2021 (cập nhật 2026), PM phải Manage Sponsor Expectations bằng cách cung cấp dữ liệu-based recommendations, tránh quyết định impulsively.
• Nguồn tham khảo: PMBOK Guide 7th Ed., trang 47-50 (Holistic View & Value); Agile Practice Guide, phần Colocation Benefits; Rita Mulcahy PMP Exam Prep (11th Ed.), chương Initiation.

📝 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 văn bản gốc bằng tiếng Anh, với đánh giá đúng/sai và lý do bằng tiếng Việt:

• ❌ [SAI] Log this as a risk, since colocating the team will require additional costs.
  Giải thích sai: Việc ghi nhận ngay thành rủi ro (risk log) là premature vì sponsor chỉ "recommend" (không phải mandate), và chưa đánh giá đầy đủ. Chi phí thêm (additional costs) có thể là rủi ro, nhưng PM cần assess benefits trước theo Risk Management Principle (PMBOK 7th). Log risk lúc này bỏ qua giá trị tiềm năng của colocation, vi phạm Be Proactive (Principle 5).

• ❌ [SAI] Colocate the project team because that is what the sponsor requested.
  Giải thích sai: PM không được tuân thủ mù quáng sponsor vì sponsor không phải là "boss" tuyệt đối. Theo Stakeholder Engagement (Domain 2: Team), PM phải challenge recommendations nếu không khả thi (no space, commute). Điều này có thể dẫn đến scope creep hoặc failure, vi phạm Tailor Approach (Principle 1).

• ✅ [ĐÚNG] Assess the business benefits of a colocated project team.
  Giải thích đúng (như phần trên): Đây là hành động tối ưu ở Initiation, tập trung vào business case analysis để quyết định data-driven, đảm bảo alignment với project objectives.

• ❌ [SAI] Colocate the project team because it will increase efficiency.
  Giải thích sai: Giả định colocation tự động tăng hiệu quả (efficiency) là unsubstantiated assumption, đặc biệt với ràng buộc commute/no space – có thể giảm productivity thay vì tăng. PMBOK 7th (Team Performance Domain) nhấn mạnh assess context trước khi áp dụng công cụ như colocation, tránh optimism bias.

🧠 Kết luận PMP: Hành động tốt nhất là assess trước, decide sau để tối ưu value. Nếu benefits > costs, thì proceed; ngược lại, propose virtual colocation hoặc hybrid! 💡
Tài liệu chính: PMBOK 7th Edition (2021), PMI.org/PMP-ECR-2021; Head First PMP 4th Ed. (2024 update).

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

Câu hỏi xoay quanh một chính sách tổ chức (organizational policy) yêu cầu các quản lý dự án (project managers) phải thực hiện hai cuộc kiểm toán (audits) mỗi tháng: một cuộc cho dự án của chính mình và một cuộc cho dự án của quản lý dự án khác. Sau một buổi rà soát kiểm toán gần đây (recent audit review), các thành viên đội ngũ (team members) phàn nàn rằng việc để các sản phẩm bàn giao (deliverables) của họ bị kiểm toán bởi đồng nghiệp (peer) là không công bằng (not fair).

📌 Vấn đề cốt lõi: Làm thế nào để quản lý dự án (project manager) tránh tình huống này (avoid this situation), tức là giảm thiểu sự bất mãn từ đội ngũ về việc kiểm toán chéo giữa các dự án, đồng thời vẫn tuân thủ chính sách tổ chức.
🛠️ Liên quan PMP (theo PMBOK® Guide 7th Edition, cập nhật đến 2026): Đây thuộc lĩnh vực Quản lý Chất lượng (Quality Management) và Quản lý Phạm vi (Scope Management), nơi kiểm toán (audits) thường là công cụ để đảm bảo chất lượng deliverables. Peer audits là hình thức kiểm tra chéo (peer review), nhưng cần được định nghĩa rõ ràng trong kế hoạch dự án để tránh xung đột. Không thể vi phạm chính sách tổ chức mà phải tích hợp vào tài liệu dự án.

✅ Đáp án đúng: Set up an audit policy in the scope management plan

Lý do lựa chọn:
🧩 Phương án này đúng vì quản lý dự án không thể thay đổi chính sách tổ chức, nhưng có thể tích hợp chính sách kiểm toán vào kế hoạch quản lý phạm vi dự án (scope management plan) – một phần của Project Management Plan (PMBOK® 7th Ed., Section 5.1 & 6.3). Scope management plan định nghĩa cách xác định, xác thực và kiểm soát phạm vi/deliverables, bao gồm các quy trình kiểm toán để đảm bảo chất lượng. Bằng cách thiết lập chính sách kiểm toán cụ thể (set up an audit policy) ở đây, PM làm rõ quy trình, tiêu chí công bằng (như luân phiên người kiểm toán, tiêu chuẩn đánh giá), giúp đội ngũ hiểu và chấp nhận, từ đó tránh tình huống phàn nàn. Điều này phù hợp với Performance Domain: Team và Quality, nhấn mạnh việc xây dựng quy trình minh bạch.

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

• PMBOK® Guide 7th Edition: Quality Management (pp. 263-271), Scope Management (pp. 137-149).
• Agile Practice Guide (PMI, 2021): Peer reviews trong Validate Scope.

📋 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 tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên nguyên tắc PMP, với lý do bằng tiếng Việt:

• Ask the organization to remind staff that audits are a requirement.
  ❌ Sai. Phương án này chỉ nhắc nhở bắt buộc (remind staff) mà không giải quyết gốc rễ sự bất mãn về tính công bằng (fairness issue) từ đội ngũ. Theo PMBOK® 7th (Stakeholder Engagement), PM phải chủ động quản lý kỳ vọng thay vì đẩy trách nhiệm lên tổ chức, dẫn đến tình huống lặp lại phàn nàn.

• Use casual meetings instead of audits.
  ❌ Sai. Thay thế kiểm toán bằng cuộc họp thân mật (casual meetings) vi phạm trực tiếp chính sách tổ chức yêu cầu audits chính thức. Audits cần cấu trúc để đảm bảo tính khách quan (PMBOK® 7th, Manage Quality: Audits phải tuân thủ tiêu chuẩn), không thể "nới lỏng" để tránh xung đột.

• Complete the audits less frequently.
  ❌ Sai. Giảm tần suất kiểm toán (less frequently) phá vỡ chính sách tổ chức (two audits per month), dẫn đến rủi ro không tuân thủ và trách nhiệm cá nhân cho PM. PMP nhấn mạnh tuân thủ governance (PMBOK® 7th, p. 47), không được tự ý thay đổi.

• Set up an audit policy in the scope management plan.
  ✅ Đúng (như đã giải thích ở trên). Đây là cách proactive tích hợp audits vào kế hoạch dự án, làm rõ quy trình để đội ngũ cảm thấy công bằng, phù hợp với Tailoring trong PMBOK® 7th (p. 61).

🛠️ Kết luận: Phương án đúng giúp PM chuyển từ phản ứng sang chủ động quản lý, đảm bảo dự án thành công mà không vi phạm policy. Nếu áp dụng thực tế, hãy cập nhật Change Log khi thay đổi kế hoạch! 🚀

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

Câu hỏi này thuộc chủ đề Quản lý Đội ngũ Dự án (Manage Project Team) trong PMP, tập trung vào việc xử lý các hành vi tiêu cực trong môi trường làm việc nhóm tích cực. 📘

• Tình huống mô tả: Quản lý dự án (PM) đang hài lòng với một đội ngũ động lực cao (motivated), tài năng xuất chúng (highly talented), và làm việc trong bầu không khí vui vẻ (cheerful atmosphere). Tuy nhiên, một số thành viên bị phân tâm bởi điện thoại trong cuộc họp, đến muộn, hoặc ngắt lời nhau bằng cách kể chuyện cười. 🛠️
• Vấn đề cốt lõi: Các hành vi này làm gián đoạn hiệu quả họp hành, dù đội ngũ tổng thể rất tốt. PM cần hành động đầu tiên (first) để khắc phục mà không làm giảm động lực đội ngũ.
• Mục tiêu PMP: Áp dụng nguyên tắc High-Performing Team từ PMBOK Guide 7th Edition (2021) và cập nhật PMI 2026, nhấn mạnh việc duy trì ground rules (quy tắc cơ bản) để thiết lập kỳ vọng hành vi, thúc đẩy trách nhiệm tập thể mà không dùng hình phạt cá nhân. Đây là phần của Process 9.5: Manage Team trong PMBOK 6th/7th, và Team Management trong Agile/Hybrid approaches.

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

Đáp án đúng: Remind the team of the ground rules in the next meeting.

Lý do (theo PMP mới nhất 2026):

• Đây là bước đầu tiên và hiệu quả nhất vì ground rules đã được thiết lập từ đầu dự án (trong Plan Team hoặc Develop Team), bao gồm quy định về giờ giấc, sử dụng thiết bị, và tôn trọng trong họp. Việc nhắc lại tập thể củng cố trách nhiệm chung, tránh làm mất tinh thần vui vẻ, và khuyến khích tự điều chỉnh mà không nhắm vào cá nhân. 🟢
• Phù hợp Servant Leadership và Value-Driven Management (PMBOK 7th), ưu tiên giao tiếp mở thay vì kỷ luật. Nếu ground rules chưa rõ, đây là cơ hội làm mới chúng. 📈
• Nguồn tham khảo: PMBOK Guide 7th Edition (p. 254-258, Manage Team); PMI Agile Practice Guide 2021 (Team Charters & Ground Rules); PMP Exam Content Outline 2021 (Domain 5: Business Environment, Task 2: Evaluate behavior).

📋 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 nội dung gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên best practice PMP (ưu tiên hành động đầu tiên, ít rủi ro nhất, phù hợp đội ngũ high-performing). ❌ cho sai, ✅ cho đúng.

• Incentivize the team members with a monetary punctuality reward.
  ❌ Sai: Phương án này dùng phần thưởng tiền bạc để khuyến khích đúng giờ, nhưng là hành động không phù hợp đầu tiên vì đội ngũ đã motivated cao, không cần extrinsic reward (có thể tạo competition tiêu cực, làm giảm intrinsic motivation). PMP ưu tiên positive reinforcement qua quy tắc chung trước khi dùng reward (PMBOK 7th, p. 256: Avoid over-reliance on rewards). Rủi ro: Tăng chi phí dự án không cần thiết. 🤑

• Speak separately to the team members causing the disruptions.
  ❌ Sai: Nói chuyện riêng lẻ với người gây rối là đối đầu cá nhân, có thể làm giảm động lực đội ngũ vui vẻ và tạo cảm giác bị giám sát. PMP khuyến cáo tránh coaching cá nhân đầu tiên nếu vấn đề là hành vi nhóm; ưu tiên nhắc ground rules tập thể để giữ unity (PMBOK 7th, Servant Leader principle). Chỉ dùng khi nhắc rules thất bại. 👥

• Remind the team of the ground rules in the next meeting.
  ✅ Đúng: Như đã giải thích ở trên, đây là bước đầu tiên lý tưởng – nhắc ground rules tập thể trong họp tiếp theo để tái khẳng định kỳ vọng, khuyến khích tự chịu trách nhiệm, và duy trì atmosphere tích cực. Hiệu quả cao với talented team (PMI 2026 updates nhấn mạnh Ground Rules trong Virtual/Remote Teams). 🎯

• Ask the team to discuss frustrating meeting experiences from past projects.
  ❌ Sai: Yêu cầu thảo luận kinh nghiệm họp tồi tệ từ dự án cũ là gián tiếp và mất thời gian, có thể khơi dậy negativity không cần thiết, làm giảm cheerful atmosphere. PMP ưu tiên direct reminder thay vì retrospective không liên quan (chỉ dùng trong Retrospectives của Agile, không phải first action). Rủi ro: Lãng phí thời gian họp. ⏳

Kết luận PMP: Hành động đầu tiên luôn là giao tiếp rõ ràng, tập thể để xây dựng văn hóa trách nhiệm. Áp dụng ngay để tránh escalation! 🚀 Nếu cần đào sâu, tham khảo PMI.org hoặc PMP Exam Prep 2024-2026 editions.

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

Câu hỏi này xoay quanh tình huống trong quản lý dự án PMP: Một báo cáo chất lượng mới đã được phân phối đến các bên liên quan sau khi nhà tài trợ (sponsor) phê duyệt. Bây giờ, một quản lý cấp cao yêu cầu thay đổi màu sắc và kích thước của một số biểu đồ trong báo cáo đó.
🛠️ Ý chính cần phân tích: Báo cáo đã được phê duyệt chính thức và phân phối, nên bất kỳ thay đổi nào cũng phải tuân thủ quy trình kiểm soát thay đổi tích hợp (Integrated Change Control) theo PMBOK Guide 7th Edition. Project Manager không được tự ý thay đổi mà phải hướng dẫn sử dụng Change Request để đánh giá tác động đến phạm vi, thời gian, chi phí, rủi ro và chất lượng dự án. Điều này đảm bảo tính minh bạch, kiểm soát và tránh lệch hướng dự án.

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

Đáp án đúng: Advise the manager to raise a change request.
Lý do: Theo nguyên tắc PMP (PMBOK 7th Edition, Process 4.6: Manage Project Changes), mọi yêu cầu thay đổi – dù nhỏ như chỉnh sửa biểu đồ – đều phải được ghi nhận qua Change Request để hội đồng kiểm soát thay đổi (CCB) đánh giá, phê duyệt hoặc từ chối. Project Manager đóng vai trò facilitator, hướng dẫn bên yêu cầu nộp form chính thức thay vì tự thực hiện, tránh rủi ro vi phạm baseline đã phê duyệt. Điều này duy trì tính chuyên nghiệp và tuân thủ governance.

📋 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 với lý do cụ thể dựa trên PMP mới nhất (PMBOK 7th Edition & PMP Exam Content Outline 2021, cập nhật đến 2026):

• ❌ Reject the change as the report was approved previously.
  Sai vì: Việc từ chối thẳng thừng mà không qua quy trình là không chuyên nghiệp. Báo cáo đã phê duyệt không có nghĩa là "đóng băng" hoàn toàn; thay đổi có thể hợp lý nếu được đánh giá (ví dụ: cải thiện khả năng đọc). PM yêu cầu xử lý qua Change Control để tránh thiên kiến cá nhân (PMBOK 7th: Principle 5 - Value; Process 4.5 Monitor and Control Project Work).

• ❌ Incorporate the change in a future report.
  Sai vì: Hoãn thay đổi sang báo cáo tương lai bỏ qua quy trình kiểm soát thay đổi hiện tại, có thể dẫn đến tích lũy thay đổi không kiểm soát (scope creep). Mọi thay đổi phải được phê duyệt ngay lập tức qua Change Request, không được "lách" bằng cách trì hoãn (PMBOK 7th: Domain 5 - Uncertainty; Process 7.4 Control Quality).

• ❌ Ask the team to make the manager's requested changes.
  Sai vì: Yêu cầu team thực hiện ngay mà không có phê duyệt là vi phạm Change Control System, có thể ảnh hưởng đến baseline chất lượng, lãng phí tài nguyên và tạo tiền lệ xấu. PM phải bảo vệ dự án khỏi thay đổi không được kiểm soát, đặc biệt từ "senior manager" (có thể là stakeholder quyền lực) (PMBOK 7th: Principle 3 - Leadership; Process 4.6 Manage Project Changes).

• ✅ Advise the manager to raise a change request.
  Đúng vì: Đây là hành động chuẩn mực, khuyến khích stakeholder sử dụng quy trình chính thức (Change Log, CCB). PM hỗ trợ nhưng không tự quyết, đảm bảo tính minh bạch và tuân thủ (PMP Exam Content Outline: People Domain 20%; PMBOK 7th: Principle 11 - Enable Change).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (PMI, 2021): Chương 4 (Project Integration) & Chương 8 (Project Quality Management) – Nhấn mạnh Integrated Change Control.
• PMP Examination Content Outline (PMI, 2021, cập nhật 2024-2026): Task 4.7 (Manage Project Changes).
• PMI Agile Practice Guide (2021): Khuyến khích change request ngay cả trong môi trường agile để kiểm soát product backlog.
• Nguồn bổ sung: PMI.org resources on Change Management (truy cập 2024).

💡 Lời khuyên PMP: Luôn ưu tiên quy trình để bảo vệ dự án! Nếu gặp tình huống thực tế, sử dụng template Change Request từ PMI.