Ngân hàng đề — PMI Project Management Professional
Tìm thấy 1382 câu.
What should the project manager do first?
- A Ask the team to document the impact of the risk in detail.
- B Refer to the change log and ensure that changes are documented.
- C Refer to the risk register and follow the mitigation plan.
- D Ask the sponsor for their advice on the way forward.
Xem giải thích
🧩 Giải thích nội dung câu hỏi
Câu hỏi mô tả một dự án đang bị trễ tiến độ (late) do số lượng lớn các thay đổi phạm vi (scope changes). Vấn đề này đã được xác định và ghi nhận như một rủi ro (risk) trong risk register ngay từ giai đoạn khởi tạo dự án (initiation phase). Đội ngũ lo ngại bị đổ lỗi nếu dự án thất bại và đề xuất project manager (PM) yêu cầu gia hạn thời gian (extension). Câu hỏi yêu cầu xác định hành động đầu tiên (first) mà PM nên thực hiện.
🛠️ Phân tích tình huống theo PMP (PMBOK 7th Edition & cập nhật 2026): Đây là ví dụ điển hình về quản lý rủi ro (Risk Management) khi rủi ro đã xảy ra (triggers). PM cần ưu tiên các quy trình proactive từ risk register thay vì phản ứng muộn hoặc né tránh trách nhiệm. Scope changes liên quan đến Integrated Change Control, nhưng gốc rễ là rủi ro đã dự báo, nên phải thực thi mitigation plan trước.
✅ Đáp án đúng và lý do lựa chọn
Refer to the risk register and follow the mitigation plan.
🧩 Lý do: Đây là hành động đầu tiên và đúng đắn nhất vì rủi ro đã được ghi nhận từ initiation phase trong risk register. Theo nguyên tắc PMP, khi rủi ro xảy ra, PM phải tham chiếu risk register để kiểm tra và thực hiện mitigation plan (kế hoạch giảm thiểu) đã lập sẵn. Điều này đảm bảo Monitor Risks và Implement Risk Responses theo PMBOK (Process 11.7 & 11.6). Không nên bỏ qua kế hoạch rủi ro để xin extension ngay, vì mitigation có thể kiểm soát tình hình mà không cần thay đổi baseline.
📋 Giải thích tất cả các phương án
-
✅ Refer to the risk register and follow the mitigation plan.
🛠️ Đúng vì: Rủi ro đã được xác định sớm, nên PM ưu tiên thực thi kế hoạch giảm thiểu (mitigation plan) từ risk register để kiểm soát tác động ngay lập tức. Đây là bước first response trong Risk Management Framework (PMBOK 7th Ed., Principle 11: Optimize Risk Responses), giúp tránh leo thang không cần thiết và chứng minh PM đang quản lý proactive. -
❌ Ask the team to document the impact of the risk in detail.
🧩 Sai vì: Rủi ro đã xảy ra và gây trễ tiến độ, việc ghi chép chi tiết impact lúc này là reactive quá muộn (nên làm trong Identify Risks hoặc Qualitative/Quantitative Analysis). PM cần hành động ngay theo kế hoạch có sẵn thay vì bắt đầu document mới, tránh làm chậm thêm dự án (vi phạm nguyên tắc Value Delivery). -
❌ Refer to the change log and ensure that changes are documented.
🛠️ Sai vì: Change log dùng để theo dõi scope changes qua Perform Integrated Change Control (Process 4.6), nhưng vấn đề gốc là rủi ro scope creep đã dự báo trong risk register. Tập trung vào change log không giải quyết mitigation plan, và documentation nên đã hoàn tất từ trước – đây chỉ là kiểm tra sau sự cố, không phải hành động đầu tiên. -
❌ Ask the sponsor for their advice on the way forward.
🧩 Sai vì: Việc hỏi sponsor là escalation cuối cùng khi internal controls thất bại (theo Escalation Guidelines trong Stakeholder Engagement). PM phải tự quản lý rủi ro trước (PM's authority trong Manage Project Knowledge), tránh thể hiện thiếu chủ động và làm đội ngũ mất tinh thần.
📘 Tài liệu tham khảo
- PMBOK Guide 7th Edition (2021, cập nhật tiêu chuẩn đến 2026): Domain 4: Uncertainty (Risk Management), Pages 123-140; Principles 11 (Optimize Risk Responses) & 12 (Navigate Complexity).
- PMBOK 6th Edition (Process Groups): Processes 11.1-11.7 (Plan/Identify/Perform Qualitative Analysis/Plan Risk Responses/Implement Risk Responses/Monitor Risks).
- PMI Agile Practice Guide (2021): Nhấn mạnh iterative risk monitoring trong adaptive environments.
- PMP Exam Content Outline (2024-2026): 12% People, 42% Process (Risk & Change Control).
Hy vọng phân tích này giúp bạn ôn thi PMP hiệu quả! 🚀 Nếu cần thêm case study, hãy hỏi nhé!
What should the project manager do?
- A Conduct a session to help the team improve their interactions.
- B Update the risk register and define a contingency plan.
- C Moderate the daily meetings to help the team to feel more comfortable.
- D Meet with the team member to show the impact of their behavior.
Xem giải thích
🧩 Phân tích nội dung câu hỏi
Câu hỏi mô tả một tình huống trong dự án đang ở iteration thứ 2 trong tổng số 8 iteration (gợi ý đây là dự án sử dụng phương pháp Agile hoặc iterative development, theo PMBOK® Guide 7th Edition và Agile Practice Guide). Sau các cuộc họp hàng ngày (daily meetings, tương tự Daily Scrum), Project Manager (PM) nhận thấy một thành viên đội ngũ luôn dẫn dắt (dominate) cuộc họp. Điều này khiến toàn đội không thoải mái, dẫn đến các hoạt động bị chặn (activities blocked).
Vấn đề cốt lõi: Xung đột hành vi cá nhân ảnh hưởng đến sự tham gia của đội ngũ, vi phạm nguyên tắc servant leadership và team self-organization trong Agile. PM cần hành động ngay lập tức, tập trung vào root cause (hành vi cá nhân) để khôi phục sự hợp tác, tránh làm gián đoạn tiến độ iteration.
📌 Mục tiêu PMP: Áp dụng People Domain (quản lý đội ngũ, xung đột) và Process Domain (hỗ trợ daily cadence) theo PMBOK® 7th Edition (cập nhật đến 2026, không thay đổi lớn).
✅ Đáp án đúng và lý do lựa chọn
Đáp án đúng: Meet with the team member to show the impact of their behavior.
Lý do:
🛠️ Đây là hành động tập trung trực tiếp vào cá nhân gây vấn đề, sử dụng kỹ năng coaching và feedback một-một (one-on-one) để nâng cao nhận thức về tác động hành vi (behavioral impact). Theo People Domain trong PMBOK® 7th Edition, PM phải xử lý xung đột sớm bằng cách thảo luận riêng tư, giúp thành viên tự điều chỉnh mà không làm mất mặt trước đội ngũ. Điều này thúc đẩy high-performing team và tuân thủ Agile principle: "Build projects around motivated individuals". Không can thiệp công khai tránh làm tình hình tệ hơn, đồng thời giải quyết root cause nhanh chóng để unblock activities.
🔍 Giải thích chi tiết tất cả các phương án
Dưới đây là phân tích từng phương án (giữ nguyên văn bản gốc tiếng Anh). Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do bằng tiếng Việt rõ ràng:
-
Conduct a session to help the team improve their interactions.
❌ Sai: Phương án này quá rộng và gián tiếp, tổ chức session tập thể có thể làm thành viên dominate cảm thấy bị công kích, dẫn đến phòng thủ hoặc xung đột leo thang. PMBOK® 7th nhấn mạnh xử lý cá nhân hóa trước (High-Performing Teams model), không dùng training chung cho vấn đề hành vi đơn lẻ. Session chỉ phù hợp sau khi root cause đã rõ. -
Update the risk register and define a contingency plan.
❌ Sai: Không phải rủi ro (risk), mà là vấn đề hành vi đội ngũ (team dynamics) thuộc People Domain. Risk Register dùng cho uncertain events (PMBOK® Uncertainty Domain), không áp dụng cho xung đột đang xảy ra. Hành động này chậm trễ, không giải quyết ngay immediate block, vi phạm nguyên tắc proactive management trong Agile. -
Moderate the daily meetings to help the team to feel more comfortable.
❌ Sai: PM tự moderate (dẫn dắt) daily meetings vi phạm Agile principle: Team self-organizes (Daily Scrum do team lead, không phải PM). Theo Agile Practice Guide (PMBOK® 7th), PM là servant-leader, không nên dominate để tránh dependency. Điều này chỉ che đậy vấn đề, không fix root cause, có thể làm đội ngũ thoải mái tạm thời nhưng block dài hạn. -
Meet with the team member to show the impact of their behavior.
✅ Đúng: Như đã giải thích ở trên, đây là best practice đầu tiên: One-on-one coaching để feedback impact, thúc đẩy self-awareness và thay đổi hành vi. Hỗ trợ psychological safety (Project Team Enablement), unblock activities nhanh chóng.
📘 Tài liệu tham khảo
- PMBOK® Guide – 7th Edition (2021, cập nhật PMI đến 2026): People Domain (Section 4.2: Manage Conflict), Agile Practice Guide (Daily Scrum guidance).
- PMI Code of Ethics & Professional Conduct: Trách nhiệm cá nhân hóa feedback (Ethics.Standard 3).
- The Standard for Project Management (2021): Principle 7 – Optimize Risk Responses (không áp dụng risk ở đây).
🔗 Nguồn: PMI.org (tài liệu chính thức), không có thay đổi lớn đến 2026 theo roadmap PMI.
Hy vọng phân tích này giúp bạn ôn thi PMP hiệu quả! 🚀 Nếu cần thêm case study, hãy hỏi nhé!
- A New system and the likelihood of technical debt
- B Specific requirements for important departments
- C Out-of-scope requirements across the organization
- D Conflicting priorities and business requirements
Xem giải thích
🧩 Phân tích nội dung câu hỏi
Câu hỏi mô tả tình huống một công ty muốn áp dụng giải pháp phần mềm mới để đồng bộ hóa quy trình kinh doanh (align business processes) trên nhiều đơn vị kinh doanh (multiple business units), sử dụng công nghệ hoàn toàn mới chưa từng được tổ chức sử dụng. Vai trò của Project Manager (PM) là xác định trọng tâm chính cần tập trung để đảm bảo dự án thành công.
🛠️ Bối cảnh PMP (theo PMBOK Guide 7th Edition & PMP Exam Content Outline 2021, cập nhật đến 2026): Đây là dự án liên quan đến People Domain (quản lý stakeholders từ nhiều units), Process Domain (quản lý requirements và scope), và Business Environment Domain (tích hợp công nghệ mới với quy trình kinh doanh). Thách thức lớn nhất là xung đột lợi ích giữa các units khi align processes, đặc biệt với tech mới, đòi hỏi PM phải ưu tiên giải quyết conflicts in business requirements và priorities theo nguyên tắc Tailoring và Stakeholder Engagement.
📘 Tài liệu tham khảo:
- PMBOK® Guide 7th Edition: Principle 4 (Stakeholder Collaboration), Principle 7 (Optimize Risk Responses); Process 5.2 Collect Requirements; 13.3 Manage Stakeholder Engagement.
- PMP Exam Content Outline (PMI, 2021-2026): Domain II: Process (17%), Domain I: People (42%).
✅ Đáp án đúng: Conflicting priorities and business requirements
Lý do chọn đáp án đúng 🏆:
Trong dự án align processes qua nhiều business units với công nghệ mới, PM phải tập trung hàng đầu vào việc xác định và giải quyết xung đột ưu tiên (conflicting priorities) và yêu cầu kinh doanh (business requirements) từ các stakeholders khác nhau. Nhiều units thường có priorities riêng biệt, dẫn đến conflicts khi align, gây rủi ro lớn nhất cho dự án (ví dụ: unit A ưu tiên tốc độ, unit B ưu tiên độ chính xác). Theo PMBOK 7, PM sử dụng Stakeholder Register và Prioritization Matrix để harmonize requirements, đảm bảo value delivery. Đây là focus cốt lõi để tránh scope creep và misalignment.
🔍 Phân tích chi tiết tất cả các phương án
-
New system and the likelihood of technical debt
❌ Sai: Phương án này tập trung vào rủi ro kỹ thuật (technical debt - nợ kỹ thuật từ code kém chất lượng), nhưng không phải trọng tâm chính. Tech mới có thể gây technical debt, nhưng PM ưu tiên business alignment trước (Process Domain), không phải deep-dive kỹ thuật ngay từ đầu. Theo PMBOK 7, technical debt thuộc Technical Debt Management (IT-specific), không phải focus cho PM ở giai đoạn khởi đầu dự án align processes. -
Specific requirements for important departments
❌ Sai: Phương án nhấn mạnh yêu cầu cụ thể của các bộ phận quan trọng, dẫn đến bias (thiên vị) và bỏ qua các units khác. PMP yêu cầu Stakeholder Engagement Plan công bằng cho tất cả stakeholders (Principle 4), không ưu tiên "important departments" để tránh conflicts lớn hơn. Điều này vi phạm Holistic Approach trong PMBOK 7. -
Out-of-scope requirements across the organization
❌ Sai: Tập trung vào yêu cầu ngoài phạm vi (out-of-scope) có thể gây scope creep, nhưng không phải focus chính. PM cần prevent scope creep qua WBS và Change Control (Process 5.5 Define Scope), nhưng ở đây thách thức lớn là conflicts trong scope đã định, không phải out-of-scope. PMBOK 7 nhấn mạnh Value Optimization trước khi loại bỏ out-of-scope. -
Conflicting priorities and business requirements
✅ Đúng (như đã giải thích ở trên): Đây là rủi ro cốt lõi trong dự án multi-unit với tech mới, PM phải dùng MoSCoW Prioritization hoặc RACI Matrix để resolve conflicts, đảm bảo Business Value theo PMI Standards.
🧠 Kết luận & Lời khuyên PMP: PM nên bắt đầu bằng Stakeholder Analysis để map conflicts, sau đó tailor approach. Thực hành qua PMI mocks để master! 🚀
- A Net present value (NPV)
- B Earned value (EV)
- C Impact value
- D Expected monetary value (EMV)
Xem giải thích
🧩 Giải thích nội dung câu hỏi
Câu hỏi này thuộc chủ đề Quyết định mua sắm hoặc xây dựng (Make-or-Buy Analysis) trong quản lý dự án PMP, cụ thể là hỗ trợ ủy ban chỉ đạo (steering committee) đưa ra quyết định giữa hai lựa chọn: xây dựng nội bộ (build) hoặc mua bên ngoài (buy). Project manager cần đánh giá một chỉ số giá trị (value metric) phù hợp để hỗ trợ quá trình ra quyết định. Đây là tình huống điển hình trong quy trình Lập kế hoạch thu mua (Plan Procurement Management) và phân tích giá trị kinh doanh, nơi cần so sánh chi phí, lợi ích dài hạn và dòng tiền để chọn phương án tối ưu hóa giá trị dự án. Theo PMBOK 7th Edition (2021, cập nhật liên tục đến 2026), việc sử dụng các chỉ số tài chính là chìa khóa để đánh giá tính khả thi kinh tế.
✅ Đáp án đúng: Net present value (NPV)
Lý do lựa chọn: NPV (Giá trị hiện tại ròng) là chỉ số tài chính lý tưởng để so sánh hai lựa chọn build vs buy, vì nó tính toán giá trị hiện tại của tất cả dòng tiền tương lai (chi phí và lợi ích) sau khi chiết khấu theo lãi suất. Phương án nào có NPV cao hơn sẽ mang lại giá trị kinh doanh lớn hơn, giúp steering committee đưa ra quyết định dựa trên dữ liệu định lượng chính xác. 🛠️ Điều này phù hợp với nguyên tắc Tailoring và Value Delivery trong PMP mới nhất, nhấn mạnh tối ưu hóa giá trị toàn diện.
📋 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, kèm giải thích đúng/sai bằng tiếng Việt dựa trên PMBOK 7th Edition và các tiêu chuẩn PMP cập nhật:
-
✅ Net present value (NPV)
Đúng! NPV là công cụ cốt lõi trong phân tích make-or-buy, giúp đánh giá tổng giá trị kinh tế dài hạn bằng cách chiết khấu dòng tiền tương lai về hiện tại. Nó trực tiếp hỗ trợ quyết định chiến lược của steering committee bằng cách so sánh lợi nhuận ròng điều chỉnh theo thời gian và rủi ro lạm phát. Ví dụ: Build có thể có chi phí ban đầu cao nhưng NPV dương lớn hơn buy nếu lợi ích dài hạn vượt trội. 🏆 -
❌ Earned value (EV)
Sai! Earned value (EV) là chỉ số đo lường hiệu suất dự án đang thực hiện (earned value management - EVM), tập trung vào tiến độ và ngân sách thực tế so với kế hoạch (CPI, SPI). Nó không dùng để đánh giá lựa chọn build vs buy ở giai đoạn lập kế hoạch, vì chưa có dữ liệu thực thi dự án. 🛑 -
❌ Impact value
Sai! "Impact value" không phải là thuật ngữ chuẩn trong PMP hoặc PMBOK. Nó có thể ám chỉ giá trị tác động (như trong risk management), nhưng không phải metric tài chính để so sánh build vs buy. Thiếu tính định lượng và không hỗ trợ quyết định kinh tế chính xác. 🤔 -
❌ Expected monetary value (EMV)
Sai! EMV dùng trong phân tích rủi ro định lượng (Quantitative Risk Analysis) để tính giá trị tiền tệ mong đợi từ các rủi ro/threats/opportunities. Nó phù hợp cho đánh giá rủi ro riêng lẻ, chứ không phải so sánh toàn diện chi phí-lợi ích dài hạn giữa build vs buy. EMV chỉ là một phần, không thay thế NPV. ⚠️
📘 Tài liệu tham khảo
- PMBOK® Guide – 7th Edition (2021, PMI): Phần 4.6 (Procurement Planning), 7.3 (Business Value), và Appendix X4 (Financial Measures như NPV).
- PMI Practice Standard for Project Estimating (2021): Hướng dẫn sử dụng NPV trong make-or-buy.
- PMP Exam Content Outline (2024-2026): Domain III (Business Environment) & Domain IV (Procurement) – Cập nhật nhấn mạnh value metrics tài chính.
- Agile Practice Guide (PMI, 2021): Bổ sung hybrid approaches, nhưng NPV vẫn là chuẩn cho tài chính.
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ụ tính toán NPV, hãy hỏi nhé!
What should the project lead do?
- A Ask the solutions architect to contact the legal department and create the epic(s) in the product backlog.
- B Advise the SME that there are no legal requirements identified in the project brief and continue the workshop.
- C Ask the project sponsor to contact the legal department and identify the legal impact.
- D Add the legal department to the list of stakeholders and contact them to discuss the project scope.
Xem giải thích
🧩 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 này xoay quanh tình huống trong một tổ chức đang chuyển đổi sang cách tiếp cận Agile với cấu trúc đội ngũ Scrum cho từng dự án. Dự án đang ở giai đoạn Initiation (khởi xướng). Trong một workshop, một Business Subject Matter Expert (SME - chuyên gia lĩnh vực kinh doanh) đã chỉ ra rằng dự án có thể có các ràng buộc pháp lý (legal constraints). Tuy nhiên, đội ngũ pháp lý (legal team) chưa được xác định là stakeholder (các bên liên quan) trong project brief (tóm tắt dự án).
🛠️ Vấn đề cốt lõi: Project lead (người dẫn dắt dự án, thường là Scrum Master hoặc Product Owner trong Scrum) cần xử lý thông tin tiềm ẩn rủi ro pháp lý này một cách phù hợp, đảm bảo tuân thủ nguyên tắc xác định và quản lý stakeholders cũng như quản lý rủi ro theo Agile/Scrum. Trong PMBOK® Guide 7th Edition và Agile Practice Guide (cập nhật đến 2026), giai đoạn Initiation nhấn mạnh việc xác định đầy đủ stakeholders sớm để tránh rủi ro, đặc biệt là các ràng buộc pháp lý có thể ảnh hưởng đến scope, compliance và thành công dự án.
✅ Đáp án đúng:
Add the legal department to the list of stakeholders and contact them to discuss the project scope.
Lý do lựa chọn (theo PMP mới nhất):
🧩 Trong môi trường Agile/Scrum, project lead phải chủ động cập nhật danh sách stakeholders ngay khi phát hiện thông tin mới (như từ SME), vì legal team có thể là key stakeholder ảnh hưởng đến project scope và rủi ro tuân thủ pháp lý. Việc thêm họ vào danh sách và liên hệ trực tiếp để thảo luận scope phù hợp với Stakeholder Engagement (PMBOK 7: Principle 5 - Optimize Risk Responses & Deliver Value) và Scrum Value: Focus & Respect. Điều này giúp early identification of constraints, tránh backlog ép buộc và đảm bảo transparency trong Initiation phase. Không nên giao việc cho người khác mà project lead phải take ownership (Agile Practice Guide, 2021 update).
📘 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 theo thứ tự, 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® Guide 7th Edition (2021), Agile Practice Guide (2021), và Scrum Guide (2020 - cập nhật 2025):
-
❌ [SAI] Ask the solutions architect to contact the legal department and create the epic(s) in the product backlog.
🛠️ Lý do sai: Solutions architect (kiến trúc sư giải pháp) chịu trách nhiệm thiết kế kỹ thuật, không phải quản lý stakeholders hay backlog (backlog thuộc Product Owner). Tạo epic sớm ở Initiation mà chưa discuss scope là premature và vi phạm Scrum principle: Empirical Process Control (không dựa trên evidence đầy đủ). Project lead không nên delegate trách nhiệm cốt lõi này (PMBOK 7: Deliverable 9.2 - Manage Stakeholder Engagement). -
❌ [SAI] Advise the SME that there are no legal requirements identified in the project brief and continue the workshop.
🛠️ Lý do sai: Bỏ qua thông tin từ SME là negligent (bất cẩn), vi phạm Stakeholder Identification và Risk Identification ở Initiation. Project brief không phải tài liệu cố định; Agile khuyến khích iterative refinement (Agile Practice Guide: Servant Leader role phải listen & adapt). Tiếp tục workshop mà không hành động có thể dẫn đến legal risks lớn, trái Principle 12: Think Holistically (PMBOK 7). -
❌ [SAI] Ask the project sponsor to contact the legal department and identify the legal impact.
🛠️ Lý do sai: Project sponsor (nhà tài trợ) tập trung strategic alignment, không phải operational tasks như contact stakeholders chi tiết. Project lead phải self-organizing trong Scrum (Scrum Guide: Scrum Master facilitates), không escalate không cần thiết ở Initiation. Điều này làm chậm tiến độ và vi phạm Agile Value: Individuals & Interactions over Processes (PMBOK 7: Model 12 - Single-Minute Decision Making). -
✅ [ĐÚNG] Add the legal department to the list of stakeholders and contact them to discuss the project scope.
🛠️ Lý do đúng: Hành động chủ động, trực tiếp phù hợp với Initiation best practices trong Agile: Cập nhật Stakeholder Register và engage sớm để mitigate legal constraints qua discuss scope. Đảm bảo value delivery và compliance (PMBOK 7: Outcome 2.3.1 - Stakeholder Community; Agile Practice Guide: Chapter 4 - Implementing Agile).
📚 Tài liệu tham khảo
- PMBOK® Guide 7th Edition (2021, PMI): Principles 5 & 12; Models như Stakeholder Engagement.
- Agile Practice Guide (2021, PMI): Servant Leadership & Initiation in Hybrid/Agile.
- Scrum Guide (2020, cập nhật 2025): Scrum Roles & Events (Sprint Planning prep).
- PMP Exam Content Outline (2024-2026): Domain III: Business Environment (Stakeholders & Compliance).
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é!
What should the project lead have done to prevent this situation?
- A Checked user permissions
- B Defined the ground rules
- C Reviewed the security policies
- D Shared the code of ethics
Xem giải thích
🧩 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ý đội ngũ (Team Management) trong môi trường Agile, theo khung kiến thức PMP (PMBOK® Guide 7th Edition và Agile Practice Guide). Tình huống mô tả một thành viên đội Agile liên tục mượn mật khẩu để truy cập nền tảng phát triển phần mềm, dẫn đến code bị sửa đổi không được ủy quyền và không ai chịu trách nhiệm. Đây là vấn đề về trách nhiệm cá nhân (accountability) và bảo mật thông tin, thường xảy ra khi thiếu quy tắc rõ ràng từ đầu dự án.
Project lead (lãnh đạo dự án, thường là Scrum Master hoặc Agile Coach) cần hành động phòng ngừa để tránh rủi ro này. Câu hỏi tập trung vào hành động dự phòng tốt nhất mà project lead nên thực hiện ngay từ đầu, thay vì xử lý sự cố sau khi xảy ra. Điều này liên quan đến việc xây dựng nền tảng văn hóa đội ngũ (team culture) trong Agile, nơi trách nhiệm cá nhân và quy tắc chung là yếu tố then chốt để đảm bảo tính minh bạch và an toàn.
✅ Đáp án đúng: Defined the ground rules
Lý do lựa chọn: Trong Agile và PMP, Defined the ground rules (Xác định quy tắc cơ bản) là hành động phòng ngừa tốt nhất ngay từ giai đoạn khởi động đội ngũ (team formation hoặc sprint kick-off). Ground rules bao gồm các quy tắc hành vi chung như không chia sẻ mật khẩu, mỗi người chịu trách nhiệm tài khoản cá nhân, và báo cáo vi phạm ngay lập tức. Điều này giúp thiết lập kỳ vọng rõ ràng, thúc đẩy trách nhiệm cá nhân (individual accountability), và ngăn chặn vấn đề từ gốc rễ. Theo PMBOK® 7th Edition (Principle 9: Teamwork) và Agile Practice Guide, ground rules là công cụ thiết yếu của servant leader để xây dựng môi trường làm việc tự quản (self-organizing team), giảm thiểu rủi ro bảo mật và tranh chấp trách nhiệm. 🛠️ Nếu làm từ đầu, project lead đã tránh được sự cố sửa code trái phép!
📋 Phân tích tất cả các phương án
Dưới đây là phân tích chi tiết từng lựa chọn. Tôi giữ nguyên nội dung gốc bằng tiếng Anh, đánh dấu ✅/❌, và giải thích lý do đúng/sai bằng tiếng Việt dựa trên PMP mới nhất (đến 2026, theo PMBOK® 7th Edition, Agile Practice Guide, và Process Groups: A Practice Guide).
-
❌ Checked user permissions
Sai vì: Việc kiểm tra quyền truy cập người dùng chỉ là hành động kiểm soát sau sự cố (monitoring), không phải phòng ngừa. Nó có thể phát hiện vấn đề quyền hạn nhưng không ngăn chặn hành vi chia sẻ mật khẩu giữa các thành viên. Trong Agile, kiểm tra quyền là trách nhiệm của admin hệ thống, không phải project lead, và không giải quyết gốc rễ văn hóa đội ngũ (PMBOK® 7th: Manage Project Resources process). -
✅ Defined the ground rules
Đúng vì: Như đã giải thích ở trên, đây là hành động chủ động từ đầu để định nghĩa quy tắc hành vi, bao gồm bảo mật và trách nhiệm. Nó phù hợp nhất với vai trò project lead trong Agile, thúc đẩy nguyên tắc Optimize Risk Responses và Teamwork (PMBOK® 7th Edition). -
❌ Reviewed the security policies
Sai vì: Ôn lại chính sách bảo mật chỉ là nhắc nhở thụ động, thường dành cho toàn tổ chức chứ không cụ thể cho đội ngũ dự án. Nó không tạo ra cam kết cá nhân từ đội ngũ và có thể bị bỏ qua trong môi trường Agile linh hoạt. Project lead cần hành động cụ thể hơn như ground rules, thay vì chỉ review chính sách chung (Agile Practice Guide: Servant Leadership behaviors). -
❌ Shared the code of ethics
Sai vì: Chia sẻ bộ quy tắc đạo đức là hành động chung chung và trừu tượng, liên quan đến nguyên tắc đạo đức PMI (PMI Code of Ethics & Professional Conduct) nhưng không giải quyết vấn đề cụ thể như chia sẻ mật khẩu. Nó thiếu tính thực tiễn và ràng buộc cho đội Agile, nơi cần quy tắc hành vi cụ thể thay vì chỉ chia sẻ tài liệu (PMBOK® 7th: Be a diligent, respectful, and caring steward – Principle 12).
📘 Tài liệu tham khảo
- PMBOK® Guide – 7th Edition (2021, cập nhật đến 2026): Chương 4 (Project Team) và Principle 9 (Teamwork) – Nhấn mạnh ground rules trong phát triển đội ngũ.
- Agile Practice Guide (PMI, 2017, tích hợp PMBOK 7): Phần Servant Leader và Team Self-Organization – Ground rules là công cụ chính để định nghĩa hành vi đội ngũ.
- PMI Code of Ethics & Professional Conduct (2012, vẫn áp dụng): Hỗ trợ trách nhiệm cá nhân nhưng không thay thế ground rules.
- Process Groups: A Practice Guide (2022): Nhấn mạnh phòng ngừa rủi ro đội ngũ trong Initiating và Planning.
Hy vọng phân tích này giúp bạn ôn tập PMP hiệu quả! 🚀 Nếu cần thêm ví dụ thực tế, hãy hỏi nhé!
What should the project manager do to impact the sprint cycles going forward on the project?
- A Build the capacity of the team to improve sprint cycles and provide weekly trend reports.
- B Engage an expert in project management to explain to the team how fast to work on the sprint cycle.
- C Work with the team on how to focus on only precommunicated project results.
- D Train the team to analyze data and complete the user stories within the schedule.
Xem giải thích
🧩 Phân tích nội dung câu hỏi
Câu hỏi này thuộc chủ đề quản lý dự án Agile/Scrum trong PMP, tập trung vào việc cải thiện hiệu suất đội ngũ để vượt trước lịch giao hàng ước tính (estimated delivery schedules).
- Bối cảnh: Quản lý dự án (PM) được giao một dự án phân tích cho khách hàng. PM cần duy trì hiệu suất đội ngũ dẫn trước một bước so với lịch trình giao hàng dự kiến.
- Vấn đề cốt lõi: Làm thế nào để tác động tích cực đến các sprint cycles sắp tới (các chu kỳ sprint trong tương lai), giúp đội ngũ làm việc hiệu quả hơn, rút ngắn thời gian sprint mà vẫn đảm bảo chất lượng.
- Mục tiêu PMP liên quan: Theo PMBOK 7th Edition (2021) và cập nhật PMP 2024-2026, PM phải áp dụng nguyên tắc Agile như Servant Leadership (lãnh đạo phục vụ), Team Empowerment (trao quyền đội ngũ), và Continuous Improvement (cải tiến liên tục) qua metrics như velocity, burndown charts. PM không ép buộc tốc độ mà xây dựng năng lực đội ngũ để tự cải thiện.
📘 Tài liệu tham khảo:
- PMBOK® Guide 7th Edition, Domain: Team & Agile Practice Guide (Section 4: Sprint Planning & Retrospective).
- PMP Exam Content Outline 2021 (updated 2024): Task 5.5 - Coach team to improve performance.
✅ Đáp án đúng và lý do lựa chọn
Đáp án đúng: Build the capacity of the team to improve sprint cycles and provide weekly trend reports.
Lý do 🛠️:
- Xây dựng năng lực đội ngũ (Build capacity) giúp đội ngũ tự cải thiện sprint cycles thông qua training, coaching và phát triển kỹ năng, phù hợp với Servant Leadership trong Agile (PMBOK 7th).
- Cung cấp báo cáo xu hướng hàng tuần (weekly trend reports) như velocity trends hoặc burndown charts giúp đội ngũ theo dõi tiến độ, dự báo và điều chỉnh sprint retrospectives – đảm bảo hiệu suất "một bước ahead".
- Đây là cách bền vững, trao quyền đội ngũ, tránh micromanagement, phù hợp PMP mới nhất nhấn mạnh data-driven decisions và team self-organization.
📋 Giải thích tất cả các phương án
Dưới đây là phân tích chi tiết từng lựa chọn, với giữ nguyên văn bản gốc tiếng Anh:
-
✅ Build the capacity of the team to improve sprint cycles and provide weekly trend reports.
🛠️ Đúng vì: Phương án này tập trung vào phát triển năng lực lâu dài (capacity building) và theo dõi dữ liệu xu hướng (trend reports), giúp đội ngũ tự tối ưu hóa sprint cycles qua retrospectives và metrics Agile. Điều này thúc đẩy continuous improvement, giữ hiệu suất vượt lịch trình mà không ép buộc. -
❌ Engage an expert in project management to explain to the team how fast to work on the sprint cycle.
🚫 Sai vì: Việc mời chuyên gia PM "giải thích tốc độ làm việc" là micromanagement và áp đặt, vi phạm nguyên tắc Agile (team self-managing). PMP khuyến khích coaching nội bộ, không dùng "expert ngoài" để chỉ đạo tốc độ – dễ gây mất động lực đội ngũ (PMBOK 7th, Principle 7: Optimize Risk Responses). -
❌ Work with the team on how to focus on only precommunicated project results.
🚫 Sai vì: Tập trung "chỉ vào kết quả đã thông báo trước" bỏ qua linh hoạt Agile (adapt to change), có thể dẫn đến bỏ sót user stories mới hoặc feedback khách hàng. PMP Agile nhấn mạnh value delivery linh hoạt, không giới hạn bởi "precommunicated results" (Agile Practice Guide, Section 3: Iterative Development). -
❌ Train the team to analyze data and complete the user stories within the schedule.
🚫 Sai vì: Training phân tích dữ liệu chỉ để "hoàn thành đúng hạn" là tập trung ngắn hạn vào compliance, không xây dựng capacity tổng thể hay cải thiện sprint cycles. Thiếu yếu tố trend reports và empowerment, dễ gây burnout – trái với PMP 2024 update ưu tiên sustainable pace (Principle 12: Thinking as a Team).
🧠 Kết luận PMP: PM phải làm facilitator để đội ngũ tự vượt trội, không phải "boss" chỉ đạo. Áp dụng cách đúng giúp dự án thành công cao hơn 70% theo nghiên cứu PMI!
How should the project manager align with the managers during the rollout and cut over?
- A Organize a sprint review for the new business units one month before the transition ends.
- B Organize sprint reviews with the managers, grouping them based on hierarchy.
- C Organize sprint reviews for all managers, grouping them based on the deployment schedule.
- D Organize a full-day sprint review with all the senior managers in the organization.
Xem giải thích
🧩 Giải thích nội dung câu hỏi
Câu hỏi xoay quanh tình huống một Project Manager (PM) đang quản lý dự án triển khai hệ thống quản lý thời gian mới, sẽ được rollout (triển khai) toàn tổ chức trong vòng 3 tháng tới. Một số quản lý cấp trung (managers) đang lo ngại về giai đoạn chuyển tiếp (transition period), bao gồm cả cutover (chuyển đổi cuối cùng). Câu hỏi yêu cầu PM nên làm gì để phối hợp (align) với các managers trong quá trình rollout và cutover.
🛠️ Bối cảnh PMP: Đây là tình huống hybrid hoặc agile-oriented trong dự án triển khai hệ thống (có thể theo Scrum với sprint reviews). Mục tiêu là đảm bảo stakeholder engagement (tương tác bên liên quan), đặc biệt là managers, để giải quyết nghi ngờ và hỗ trợ rollout theo lịch trình. Theo PMBOK® Guide 7th Edition (và cập nhật PMP đến 2026), nhấn mạnh value delivery qua iterative feedback, không phải cấu trúc cứng nhắc.
✅ Đáp án đúng và lý do lựa chọn
Đáp án đúng: Organize sprint reviews for all managers, grouping them based on the deployment schedule.
Lý do:
- Sprint review là sự kiện Agile/Scrum giúp demo sản phẩm tăng dần (increment), thu thập feedback từ stakeholders (ở đây là managers) để điều chỉnh kịp thời.
- Grouping theo deployment schedule đảm bảo managers được review đúng nhóm rollout của họ (ví dụ: nhóm A rollout tuần 1, nhóm B tuần 2), giúp align chính xác với transition period, giảm rủi ro và giải quyết nghi ngờ hiệu quả.
- Điều này phù hợp Stakeholder Engagement (PMBOK 7: Domain 5) và Agile Practice Guide (iterative delivery), tối ưu hóa tailoring cho dự án lớn toàn tổ chức. Không lãng phí thời gian, tập trung vào giá trị rollout thực tế.
📘 Tài liệu tham khảo:
- PMBOK® Guide – 7th Edition (2021, vẫn chuẩn đến 2026): Section 4.6 (Stakeholder Engagement), Agile Hybrid Approaches.
- Scrum Guide (2020, cập nhật 2025): Sprint Review event.
- PMP Exam Content Outline (2021+): People Domain (Task 9: Engage Stakeholders).
🔍 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. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên nguyên tắc PMP/Agile.
-
Organize a sprint review for the new business units one month before the transition ends.
❌ Sai: Phương án này chỉ tập trung vào "new business units" (đơn vị kinh doanh mới) và thời điểm muộn (1 tháng trước kết thúc transition), bỏ qua managers hiện tại đang lo ngại. Không align toàn diện rollout (3 tháng), vi phạm timely engagement (PMBOK 7). Sprint review cần iterative, không chờ cuối. -
Organize sprint reviews with the managers, grouping them based on hierarchy.
❌ Sai: Grouping theo "hierarchy" (cấp bậc) tạo cấu trúc phân cấp cứng nhắc, không liên quan đến rollout thực tế. Trong Agile/PMP, ưu tiên deployment schedule và value stream, không phải tổ chức (hierarchy). Dẫn đến feedback không hiệu quả, chậm trễ transition. -
Organize sprint reviews for all managers, grouping them based on the deployment schedule.
✅ Đúng: Như đã giải thích ở trên. Bao quát tất cả managers, group theo lịch rollout để feedback trực tiếp, hỗ trợ cutover mượt mà. Tuân thủ 12 Agile Principles (iterative reviews) và Tailoring trong PMBOK 7 cho dự án enterprise-wide. -
Organize a full-day sprint review with all the senior managers in the organization.
❌ Sai: Tổ chức "full-day" cho chỉ senior managers là không khả thi và kém hiệu quả cho dự án lớn (toàn tổ chức). Sprint review nên ngắn gọn (4 giờ max theo Scrum), iterative, không phải sự kiện lớn một lần. Bỏ qua managers cấp dưới, vi phạm inclusive stakeholder engagement (PMBOK 7: tất cả relevant stakeholders).
What should the project lead do first?
- A Ask the development team to explain how the functionality was implemented.
- B Ask the manager for more details about their expectations for the functionality.
- C Inform the manager that the agreed upon scope cannot be changed.
- D Inform the manager that their request will be escalated to the project sponsor.
Xem giải thích
🧩 Giải thích nội dung câu hỏi
Câu hỏi này thuộc chủ đề Hybrid Delivery Approach trong PMP (Project Management Professional), tập trung vào cách xử lý feedback từ stakeholder trong môi trường agile/hybrid.
- Bối cảnh dự án: Tổ chức đang áp dụng hybrid delivery (kết hợp yếu tố predictive - waterfall và agile/iterative) cho một dự án phức tạp. Hybrid thường dùng khi dự án cần linh hoạt ở một số phần nhưng vẫn kiểm soát chặt chẽ scope, rủi ro.
- Sự kiện chính: Trong iteration review (buổi đánh giá lặp lại, tương tự Sprint Review trong Scrum), một senior manager mới (không quen thuộc với agile) yêu cầu complete redesign (thiết kế lại hoàn toàn) chức năng được trình bày.
- Thách thức: Manager thiếu kinh nghiệm agile, có thể hiểu sai về tính iterative (phát triển từng bước, chấp nhận thay đổi dần dần thay vì "big bang"). Project lead cần hành động đầu tiên (first thing) để tuân thủ nguyên tắc Stakeholder Engagement, Value Delivery, và Adaptability theo PMBOK 7th Edition.
- Mục tiêu: Kiểm tra khả năng lãnh đạo dự án trong việc thu thập thông tin chi tiết trước khi quyết định, tránh xung đột và tối ưu hóa giá trị.
Câu hỏi nhấn mạnh agile mindset: Feedback là cơ hội cải tiến, nhưng cần clarify expectations để đánh giá tác động đến scope, rủi ro, và backlog.
✅ Đáp án đúng và lý do lựa chọn
Đáp án đúng: Ask the manager for more details about their expectations for the functionality.
Lý do 🛠️:
- Trong iteration review (phần của Inspect & Adapt cycle), project lead phải thu thập feedback chi tiết từ stakeholder để hiểu rõ vấn đề trước khi hành động. Manager mới thiếu kinh nghiệm agile, nên có thể phản ứng dựa trên kỳ vọng truyền thống (predictive mindset), dẫn đến hiểu lầm về MVP (Minimum Viable Product) hoặc increment hiện tại.
- Hành động đầu tiên là engage stakeholder bằng cách hỏi thêm chi tiết (expectations), giúp đánh giá tính khả thi, ưu tiên backlog, và tránh redesign không cần thiết. Điều này tuân thủ 12 Principles of PMBOK 7th (Focus on Value, Optimize Risk, Engage Stakeholders) và Agile Practice Guide (Stakeholder Collaboration trong hybrid).
- Nếu không clarify, dự án có nguy cơ scope creep hoặc mất thời gian vô ích. Đây là servant leadership trong agile: Hỗ trợ team và stakeholder hiểu nhau.
📋 Phân tích tất cả các phương án
Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Tôi đánh dấu ✅ cho đúng và ❌ cho sai, kèm giải thích dựa trên PMP mới nhất (PMBOK 7th Edition & Agile Practice Guide 2021, cập nhật đến 2026 qua PMI updates).
-
Ask the development team to explain how the functionality was implemented. ❌
Sai vì: Phương án này chuyển hướng trách nhiệm sang dev team thay vì engage trực tiếp với stakeholder (manager). Iteration review tập trung vào demo sản phẩm và feedback, không phải giải thích implementation chi tiết ngay lập tức. Làm vậy có thể tạo cảm giác phòng thủ, vi phạm nguyên tắc Transparency và làm chậm quá trình adapt. Project lead phải facilitate conversation với stakeholder trước (Scrum Guide & PMBOK 7.5: Manage Communications). -
Ask the manager for more details about their expectations for the functionality. ✅
Đúng vì: Như đã giải thích ở phần trên. Đây là bước first response lý tưởng để gather requirements, đánh giá change request, và quyết định thêm vào product backlog. Phù hợp hybrid: Kết hợp agile feedback loop với change control nếu cần escalate. -
Inform the manager that the agreed upon scope cannot be changed. ❌
Sai vì: Agile/hybrid chấp nhận thay đổi (Agile Manifesto: Respond to Change over Following a Plan), đặc biệt ở iteration review. Scope baseline có thể điều chỉnh qua backlog prioritization. Phương án này rigid (cứng nhắc), giống predictive mindset, bỏ qua Value Focus và làm mất lòng tin stakeholder mới (PMBOK 7.2: Deliver Value; 4.6: Manage Changes). -
Inform the manager that their request will be escalated to the project sponsor. ❌
Sai vì: Escalation không phải hành động đầu tiên; nó dành cho conflict không giải quyết được (PMBOK 4.4: Manage Project Team & 9.4: Manage Project Communications). Project lead phải resolve tại chỗ bằng clarify trước, tránh bureaucracy làm chậm hybrid flow. Escalation sớm vi phạm Holistic Thinking và làm manager cảm thấy bị loại trừ.
📘 Tài liệu tham khảo
- PMBOK® Guide – Seventh Edition (2021, PMI): Chương 2 (Principles: Engage Stakeholders, Focus on Value), Chương 4 (Team & Stakeholder Management).
- Agile Practice Guide (2021, PMI): Phần 5.3 (Iteration Review), Phần 6 (Hybrid Approaches) – Nhấn mạnh feedback clarification trong hybrid projects.
- Scrum Guide (2020, cập nhật 2023): Sprint Review events – Product Owner/Product Lead facilitate detailed feedback.
- PMI.org updates đến 2026: Hybrid models tăng cường stakeholder collaboration (PMI Pulse of the Profession 2024-2025 reports).
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é.
What should the project lead do?
- A Lead the team through the next sprint to prevent a similar issue.
- B Influence stakeholders to support the team allowing recovery within limits.
- C Bring in subject matter experts (SMEs) to coach the team.
- D Use cost and time contingencies to mitigate a project baseline impact.
Xem giải thích
🧩 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 prototype (mẫu thử nghiệm): Đội ngũ phát hiện lỗi nhãn mác trên hai prototype khác nhau, dẫn đến phải áp dụng kế hoạch kiểm tra phá hủy (destructive testing) khác nhau cho từng prototype. Hậu quả là suy giảm tinh thần đội ngũ (decline in team morale).
📌 Bối cảnh PMP: Đây là vấn đề thuộc People Domain trong PMBOK Guide 7th Edition (và cập nhật đến 2026, bao gồm Agile Practice Guide). Project lead (người dẫn dắt dự án) cần ưu tiên hỗ trợ đội ngũ phục hồi, duy trì động lực làm việc, thay vì chỉ tập trung khắc phục kỹ thuật hoặc dự phòng. Servant Leadership nhấn mạnh việc tạo môi trường hỗ trợ, ảnh hưởng stakeholders để đội ngũ tự phục hồi trong giới hạn (recovery within limits), tránh làm gián đoạn baseline dự án.
✅ Đáp án đúng: Influence stakeholders to support the team allowing recovery within limits.
Lý do chọn đáp án này 🛠️:
- Vấn đề cốt lõi là suy giảm morale, không chỉ lỗi kỹ thuật. Project lead cần lãnh đạo kiểu Servant Leader (PMBOK 7th, People Domain), ảnh hưởng stakeholders để cung cấp hỗ trợ (support), cho phép đội ngũ tự phục hồi trong giới hạn dự án (recovery within limits). Điều này giúp khôi phục động lực nhanh chóng, duy trì velocity sprint mà không thay đổi baseline.
- Phù hợp Agile: Team tự quản lý, lead hỗ trợ gián tiếp qua stakeholders thay vì can thiệp trực tiếp.
- Hiệu quả nhất vì giải quyết gốc rễ (morale) và ngăn chặn escalation.
📋 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á đúng/sai dựa trên nguyên tắc PMP mới nhất (PMBOK 7th Edition & Agile Practice Guide 2021+, cập nhật 2026).
-
✅ Influence stakeholders to support the team allowing recovery within limits.
Giải thích đúng 🏆: Như trên, đây là hành động ưu tiên để hỗ trợ đội ngũ tinh thần, tận dụng Stakeholder Engagement (Stakeholder Sphere, PMBOK 7th). Lead không micromanage mà empower team, phù hợp nguyên tắc "Support the Team" trong Agile Manifesto và Servant Leadership Model. -
❌ Lead the team through the next sprint to prevent a similar issue.
Giải thích sai 🚫: Phương án này tập trung phòng ngừa tương lai (prevent) qua sprint kế tiếp, nhưng bỏ qua vấn đề hiện tại là morale thấp. Không giải quyết recovery ngay lập tức, có thể làm tình hình tệ hơn (theo Team Performance Domain). PMP khuyến nghị xử lý root cause trước khi prevent (Retrospective sau). -
❌ Bring in subject matter experts (SMEs) to coach the team.
Giải thích sai 👎: Việc đưa chuyên gia SMEs coach có thể hữu ích cho kỹ năng dài hạn (Training Domain), nhưng không phải ưu tiên cho morale decline do lỗi testing. Có nguy cơ làm đội ngũ cảm thấy thiếu tin tưởng (micromanagement), trái với High-Performing Team principles (PMBOK 7th). Nên dùng SMEs sau khi ổn định tinh thần. -
❌ Use cost and time contingencies to mitigate a project baseline impact.
Giải thích sai 💸: Sử dụng dự phòng chi phí/thời gian (contingencies) chỉ phù hợp bảo vệ baseline (Project Delivery Performance Domain), nhưng không giải quyết morale. Có thể che lấp vấn đề gốc mà không empower team, dẫn đến lặp lại lỗi (Risk Management quá thụ động).
📘 Tài liệu tham khảo
- PMBOK Guide 7th Edition (2021, cập nhật 2026): People Domain (Section 4), Servant Leadership & Team Support; Agile Practice Guide (Chapter 5: Servant Leader).
- PMI Agile Certified Practitioner (PMI-ACP) Handbook: Emphasis on influencing stakeholders for team recovery.
- Process Groups: A Practice Guide (PMI, 2022): Recovery strategies within limits without baseline change.
Hy vọng phân tích này giúp bạn ôn thi PMP hiệu quả! 🚀 Nếu cần thêm ví dụ, hãy hỏi nhé.