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

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

Câu hỏi mô tả tình huống một Project Manager (PM) đang quản lý dự án Agile trong 6 tháng, báo cáo dự án luôn "on track" hàng tuần. Tuy nhiên, ngay tuần cuối trước khi phát hành sản phẩm cuối cùng, đội ngũ phát hiện một trở ngại kỹ thuật (technical impediment) bất ngờ, khiến việc giao dự án gặp nguy cơ lớn chỉ sau một đêm.
🛠️ Câu hỏi yêu cầu: PM nên làm gì trước đó để ngăn chặn tình huống này? Đây là chủ đề liên quan đến quản lý rủi ro (Risk Management) và thực hành Agile, nhấn mạnh việc dự đoán và xử lý các mối đe dọa tiềm ẩn trong môi trường Agile nơi thay đổi nhanh chóng và impediments có thể xảy ra đột ngột. Trong PMP (PMBOK 7th Edition & Agile Practice Guide), dự án Agile không loại trừ quản lý rủi ro chủ động, mà cần tích hợp vào các sự kiện như Daily Stand-up, Sprint Review để phát hiện sớm.

✅ Đáp án đúng

Developed a risk response plan that would have provided options and strategies regarding project risk exposure
Lý do lựa chọn: Trong môi trường Agile, PM phải phát triển Risk Response Plan ngay từ đầu để xác định rủi ro (như technical impediments), đánh giá mức độ ảnh hưởng và chuẩn bị các chiến lược ứng phó (mitigate, avoid, transfer, accept, escalate). Điều này giúp tránh "surprise" phút chót bằng cách có sẵn các tùy chọn (contingency plans). PMBOK 7th nhấn mạnh Uncertainty Domain yêu cầu lập kế hoạch rủi ro liên tục, không chỉ báo cáo "on track" mà phải chủ động quản lý exposure. Nếu có kế hoạch này, PM có thể trigger response sớm qua retrospectives hoặc risk reviews, ngăn chặn jeopardy.

📋 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 nội dung gốc giữ nguyên tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên nguyên tắc PMP/Agile mới nhất (PMBOK 7th Edition 2021, cập nhật đến 2026 qua PMI Standards+).

• ❌ [SAI] Considered historical data from previous projects with similar impediments to help identify the possible solutions
  Giải thích: Phương án này chỉ tập trung vào sử dụng dữ liệu lịch sử để tìm giải pháp sau khi impediments xảy ra, không phải để ngăn chặn trước. Trong Agile, dữ liệu lịch sử hữu ích cho estimation (như Planning Poker) hoặc retrospectives, nhưng không thay thế risk planning chủ động. PMBOK khuyến khích Data Analysis (historical data) trong Identify Risks, nhưng đây không phải hành động cốt lõi để prevent situation – nó chỉ là công cụ hỗ trợ, không đảm bảo options sẵn sàng.

• ❌ [SAI] Sought and implemented alternative ways to track progress and impediments to identify potential threats
  Giải thích: Phương án đề xuất cách theo dõi tiến độ và impediments thay thế để phát hiện threats sớm – nghe có lý trong Agile (như Burndown Charts, Impediment Boards). Tuy nhiên, nó chỉ giải quyết monitoring (theo dõi), không phải planning responses trước. Trong PMP, tracking (Monitor Risks process) là bước sau Identify & Plan Risks; nếu thiếu response plan, ngay cả tracking tốt cũng không có strategies để hành động kịp thời, dẫn đến jeopardy phút chót.

• ❌ [SAI] Provided technical training to the team in advance to ensure the team had high-level technical skills
  Giải thích: Đây là biện pháp phát triển đội ngũ (team development) qua training, phù hợp với Stakeholder Engagement Domain và Agile (cross-training trong T-Shaped skills). Nhưng nó không trực tiếp prevent technical impediments – training nâng cao skills chung, không dự đoán rủi ro cụ thể như impediment bất ngờ. PMBOK 7th coi training là phần Acquire Resources/Develop Team, không thay thế Risk Response Plan chuyên biệt cho exposure.

• ✅ [ĐÚNG] Developed a risk response plan that would have provided options and strategies regarding project risk exposure
  (Đã giải thích chi tiết ở phần trên): Đây là hành động chủ động và toàn diện nhất, phù hợp nguyên tắc proactive risk management trong Agile hybrid (Scrum/Kanban + PMBOK).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, PMI): Uncertainty Domain (Section 4.3), Risk Management Principles.
• Agile Practice Guide (PMI, 2017 cập nhật): Chương 5 - Implementing Agile: Risk Management in Agile Contexts (tích hợp risks vào iterations).
• PMI Standards+ (cập nhật 2026): Nhấn mạnh Tailored Risk Approaches cho Agile, với tools như Risk Register và Response Strategies.
• The Standard for Risk Management in Portfolios, Programs, and Projects (PMI, 2019): Chi tiết Risk Response Planning (Section 6).

💡 Lời khuyên PMP: Trong Agile, hãy tích hợp risk reviews vào Sprint Planning/Retrospectives để tránh "last-minute surprises"! Nếu cần ví dụ thực tế, PM có thể dùng Risk Burn-up Charts.

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

Câu hỏi mô tả một dự án lớn (multimillion-dollar) đang ở giai đoạn thực thi (execution phase). Bất ngờ, cơ quan quản lý địa phương (local regulatory authority) công bố thay đổi yêu cầu (changes to the requirements), và những thay đổi này phải được triển khai trong 6 tháng, tức là trước khi kết thúc giai đoạn thực thi.

🛠️ Mục tiêu chính: Kiểm tra kiến thức của Project Manager (PM) về quy trình quản lý thay đổi (Change Management Process) trong PMP. Dự án đang chạy, thay đổi từ bên ngoài (regulatory) là bắt buộc về mặt pháp lý, nhưng PM không được tự ý hành động mà phải tuân thủ quy trình chính thức để tránh rủi ro như vượt ngân sách, trễ tiến độ hoặc vi phạm hợp đồng. Câu hỏi nhấn mạnh hành động tiếp theo (next) mà PM nên làm, dựa trên nguyên tắc Integrated Change Control (theo PMBOK Guide).

✅ Đáp án đúng

Review the new requirements with the compliance department to determine if a change request is needed

Lý do lựa chọn (theo PMBOK® Guide 7th Edition và PMI's Practice Standard for Project Configuration Management):
Đây là bước đúng đắn và đầu tiên vì thay đổi từ cơ quan quản lý là rủi ro tuân thủ (compliance risk). PM phải phối hợp với bộ phận tuân thủ (compliance department) để đánh giá tác động (impact assessment) trước khi quyết định. Nếu cần, tạo Change Request (Yêu cầu thay đổi) qua Perform Integrated Change Control (Process Group: Monitoring & Controlling). Điều này đảm bảo thay đổi được phê duyệt chính thức, cập nhật Scope Baseline, Schedule, Cost Baseline và các tài liệu liên quan. Việc trì hoãn 6 tháng cho phép thời gian đánh giá mà không ảnh hưởng ngay lập tức. ✅ Tuân thủ nguyên tắc Value Delivery và Stakeholder Engagement trong PMBOK 7th.

📋 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 ✅ đúng hoặc ❌ sai, dựa trên nguyên tắc PMP mới nhất (PMBOK® Guide 7th Edition, 2021, và cập nhật đến 2026 qua PMI Standards).

• ✅ Review the new requirements with the compliance department to determine if a change request is needed
  🛠️ Đúng vì: Đây là bước chủ động, chuyên nghiệp để đánh giá tính khả thi và tác động pháp lý. PM không tự quyết định mà thu thập input từ chuyên gia tuân thủ, sau đó khởi xướng Change Control Board (CCB) nếu cần. Tránh "scope creep" và đảm bảo compliance-first approach. Phù hợp với Domain 3: Business Environment và Domain 5: Planning trong PMP Exam Content Outline 2021+.

• ❌ Proceed with the defined project requirements and delay implementing the new requirements
  🧩 Sai vì: Mặc dù có 6 tháng, việc bỏ qua đánh giá và "delay" có thể vi phạm regulatory compliance, dẫn đến legal penalties hoặc dự án bị hủy. PMBOK yêu cầu proactive risk response cho external changes; không được "proceed as is" mà phải analyze first (PMBOK 7th, Principle 6: Optimize Risk Responses).

• ❌ Add the new requirements to the project scope immediately since they are mandatory changes
  🛠️ Sai vì: Tự ý thêm scope (immediate addition) là scope creep nghiêm trọng, vi phạm Scope Management Plan. Dù mandatory, vẫn phải qua formal change process để cập nhật WBS, baselines và phê duyệt. PMBOK 7th nhấn mạnh no changes without approval (Domain 4: Uncertainty).

• ❌ Ignore the new requirements as the current budget and schedule do not allow for any changes
  ❌ Sai nặng nhất vì: Bỏ qua hoàn toàn (ignore) là unprofessional và rủi ro cao, có thể dẫn đến non-compliance fines, kiện tụng hoặc dự án thất bại. PMBOK cấm hành vi này; thay vào đó, phải escalate và manage trade-offs qua Earned Value Management hoặc Agile adjustments nếu áp dụng Hybrid.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021): Chương 4 (Project Integration), Principle 9 (Tailor Based on Context), và Domain 4 (Uncertainty).
• PMI's Practice Standard for Change Management: Nhấn mạnh "Assess → Request → Approve → Implement".
• PMP Examination Content Outline (2021, cập nhật 2026): 50% People Domain, bao gồm Change Control.
• PMI Code of Ethics & Professional Conduct: Rule 2.2.1 – Tuân thủ pháp luật và quy đị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ụ case study, hãy hỏi nhé!

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

Câu hỏi này thuộc chủ đề Quản lý Rủi ro (Risk Management) trong môi trường Agile, một phần quan trọng của PMP theo PMBOK® Guide 7th Edition và Agile Practice Guide (cập nhật đến 2026).

Tình huống cụ thể:
Một Project Sponsor (nhà tài trợ dự án) yêu cầu phân tích xu hướng (trend analysis) về tất cả các rủi ro (risks) mà dự án đã theo dõi (monitored) trong 12 tháng qua. Agile Project Manager cần hành động phù hợp nhất.

Mục tiêu chính:

• Trend analysis là kỹ thuật phân tích dữ liệu lịch sử để xác định xu hướng rủi ro (ví dụ: loại rủi ro nào lặp lại, tần suất, tác động tăng/giảm).
• Trong Agile, quản lý rủi ro linh hoạt, liên tục theo dõi qua các công cụ như Risk Register (danh sách rủi ro) và Issues Log (nhật ký vấn đề).
• Agile PM phải phản hồi nhanh chóng, dựa trên dữ liệu thực tế, không phải họp hành hay tài liệu chung chung.

📘 Dẫn chứng: PMBOK® 7th Edition (Domain: Uncertainty), Principle 9: Optimize Risk Responses; Agile Practice Guide (Section: Risk Management in Agile).

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

Đáp án đúng: Extract this from the project risk register tracking tool and issues log

Lý do:
🛠️ Risk Register là công cụ chính lưu trữ toàn bộ dữ liệu rủi ro đã theo dõi (identified, assessed, responded, monitored), bao gồm lịch sử 12 tháng. Issues Log bổ sung dữ liệu về các vấn đề thực tế phát sinh từ rủi ro.

• Agile PM có thể trích xuất dữ liệu (extract) nhanh chóng từ tracking tool để tạo trend analysis (ví dụ: biểu đồ Pareto, đường xu hướng).
• Đây là hành động hiệu quả nhất, tuân thủ nguyên tắc Agile: Data-driven, iterative, và đáp ứng nhu cầu sponsor ngay lập tức.
  ✅ Phù hợp PMP 2026: Nhấn mạnh sử dụng artifacts như Risk Register cho monitoring & reporting (PMBOK 7th, Table 4-1: Risk Register Contents).

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

• Extract this from the project risk register tracking tool and issues log
  ✅ Đúng: Như đã giải thích, đây là nguồn dữ liệu trực tiếp, đầy đủ cho trend analysis lịch sử. Hành động nhanh, chính xác, không cần thêm tài nguyên thừa.

• Refer the sponsor to the contract document
  ❌ Sai: Hợp đồng (contract) chỉ quy định phạm vi, điều khoản pháp lý, không chứa dữ liệu rủi ro cụ thể hay lịch sử theo dõi. Điều này né tránh trách nhiệm PM và không đáp ứng yêu cầu phân tích xu hướng.

• Organize a stakeholder meeting to brainstorm on general project risks
  ❌ Sai: Brainstorm là để xác định rủi ro mới (identify risks), không phải phân tích xu hướng lịch sử 12 tháng. Tổ chức họp tốn thời gian, không dựa trên dữ liệu thực tế – trái với Agile (favor working data over meetings).

• Share the annual report with the sponsor
  ❌ Sai: Báo cáo hàng năm (annual report) là tài liệu tổng hợp cấp cao, không chi tiết về rủi ro theo dõi 12 tháng hay trend analysis cụ thể. Sponsor cần dữ liệu chuyên sâu, không phải báo cáo chung chung.

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

• PMBOK® Guide 7th Edition (2021, cập nhật 2026): Chapter 4: Project Risk Management; Models, Methods & Artifacts (Risk Register, Trend Analysis).
• Agile Practice Guide (2017, tích hợp PMI 2026): Section 5.3: Risk Management in Agile Projects.
• PMP Exam Content Outline (2021+): Domain IV: People (Stakeholder Engagement); Domain V: Business Environment (Risk Monitoring).

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

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

Câu hỏi này thuộc chủ đề Quản lý Rủi ro (Risk Management) trong PMP, cụ thể liên quan đến việc ghi nhận và theo dõi các mối lo ngại tiềm ẩn trong giai đoạn Thực hiện (Execution) của dự án.

• Bối cảnh dự án: Một dự án xây dựng trại cá (fish hatchery) đang ở giai đoạn thực hiện. Nhóm vận hành (operations group) thông báo cho Quản lý dự án (project manager) về một mối lo ngại (concern) có thể trở thành vấn đề tiềm năng (might turn into a potential issue). Tuy nhiên, mối lo ngại này chưa thể giải quyết ngay (could not be addressed).
• Yêu cầu chính: Quản lý dự án cần ghi nhận mối lo ngại này vào tài liệu dự án nào (project document) để theo dõi phù hợp.
• Mục tiêu kiểm tra kiến thức: Phân biệt giữa rủi ro (risk) – là sự kiện tiềm năng chưa xảy ra – và vấn đề (issue) – là sự kiện đã xảy ra và cần xử lý ngay. Theo PMBOK® Guide (phiên bản 7th Edition, 2021 và các cập nhật đến 2026 qua PMI Standards), các mối lo ngại tiềm năng phải được ghi vào tài liệu chuyên biệt để phân tích và giám sát.

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

• PMBOK® Guide – Seventh Edition (2021), Section 11: Project Risk Management (Identify Risks, Risk Register).
• PMI's Practice Standard for Project Risk Management (cập nhật 2023).
• PMP Exam Content Outline (2024-2026): Domain IV - Risk Management (20-25% trọng số).

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

Lý do lựa chọn:

• Mối lo ngại được mô tả là "concern that might turn into a potential issue" và "could not be addressed" (chưa thể giải quyết), nghĩa là đây là một rủi ro tiềm năng (potential risk) chưa xảy ra.
• Theo quy trình Identify Risks, Risk Register là tài liệu chính để ghi nhận tất cả các rủi ro đã xác định, bao gồm mô tả, nguyên nhân, tác động tiềm năng, và kế hoạch ứng phó. Việc ghi nhận sớm giúp dự án chủ động phân tích (qualitative/quantitative analysis) và theo dõi (Monitor Risks).
• 🛠️ Lợi ích: Cho phép PM lập kế hoạch ứng phó rủi ro (avoid, mitigate, transfer, accept) trước khi nó trở thành issue thực tế.

📋 Giải thích tất cả các phương án (từng cái một)

• Request for information ❌
  Sai vì: Tài liệu này dùng để yêu cầu thông tin bổ sung (RFI) từ nhà thầu, nhà cung cấp hoặc stakeholder khi cần làm rõ yêu cầu, hợp đồng hoặc thông số kỹ thuật (thường trong Procurement Management). Nó không phải là nơi ghi nhận rủi ro tiềm năng. Mối lo ngại ở đây không phải yêu cầu thông tin mà là theo dõi rủi ro.

• Scope statement ❌
  Sai vì: Scope statement là phần của Project Charter hoặc Project Management Plan, dùng để mô tả phạm vi dự án chi tiết (deliverables, boundaries, assumptions, constraints). Nó không dùng để ghi nhận rủi ro hoặc lo ngại động trong giai đoạn execution. Thay đổi scope phải qua Change Control, không liên quan đến risk tracking.

• Risk register ✅
  Đúng vì: Như đã giải thích ở trên, đây là tài liệu cốt lõi cho Project Risk Management. Nó bao gồm danh sách rủi ro, probability/impact, owners, và status. Cập nhật liên tục trong Identify Risks, Manage Risks, và Monitor Risks processes (PMBOK 7th Ed., Principle 7: Optimize Risk Responses).

• Issue log ❌
  Sai vì: Issue log dùng để ghi nhận các vấn đề đã xảy ra thực tế (actual issues) cần giải quyết ngay lập tức (raised, assigned, resolved, closed). Ở đây, concern chỉ là potential và chưa addressed, nên chưa phải issue. Nếu nó trở thành issue sau, mới chuyển sang Issue Log (Monitor Risks process).

🧩 Kết luận & Mẹo thi PMP: Luôn phân biệt Risk (tiềm năng, chưa xảy ra) vs Issue (đã xảy ra). Trong execution, ưu tiên cập nhật Risk Register để tránh escalation. Học thuộc các project documents qua Hybrid-Agile approach (PMBOK 7th)! 🚀

🧩 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 dự án lai (hybrid project) – kết hợp giữa phương pháp agile (phát triển sản phẩm linh hoạt) và predictive (phát triển chiến lược marketing theo kế hoạch truyền thống). Dự án đang gặp nhiều vấn đề ở cả hai khía cạnh này. Project manager (PM) cần nhận feedback từ stakeholders nằm ở các múi giờ khác nhau.

🛠️ Mục tiêu chính: Xác định hành động phù hợp nhất để thu thập phản hồi hiệu quả, xem xét thách thức về thời gian địa lý. Theo PMBOK® Guide 7th Edition (cập nhật đến 2026), trong dự án hybrid, giao tiếp phải linh hoạt, ưu tiên các phương tiện phù hợp với ngữ cảnh (tailored approaches), đặc biệt là Communications Management Plan để đảm bảo thông tin được trao đổi đúng lúc, đúng cách.

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

Đáp án đúng: Refer to the communications management plan.

📝 Lý do chi tiết:

• Communications Management Plan (Kế hoạch quản lý giao tiếp) là tài liệu cốt lõi quy định phương thức, thời gian, tần suất và công cụ giao tiếp phù hợp với từng stakeholder hoặc nhóm, đặc biệt trong trường hợp khác múi giờ. Nó giúp PM chọn phương pháp như video async (ghi hình phản hồi), công cụ collaboration (Slack/Teams với timestamp), surveys tự động hoặc virtual meetings linh hoạt để nhận feedback mà không bị ràng buộc thời gian thực.
• Trong dự án hybrid, plan này được tailor để hỗ trợ cả agile (feedback nhanh) và predictive (báo cáo định kỳ), đảm bảo hiệu quả cao nhất (PMBOK 7th: 8.1. Manage Communications).
• Hành động này chủ động, dựa trên quy trình chuẩn, tránh thử nghiệm ngẫu nhiên.

📋 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 bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên PMBOK 7th Edition và PMP Exam Content Outline 2021 (cập nhật 2026), nhấn mạnh People Domain (Stakeholder Engagement) và Process Domain (Communications).

• ❌ Send an email to all stakeholders.
  Sai vì: Email là phương tiện một chiều, chậm trễ và khó nhận feedback kịp thời từ stakeholders khác múi giờ (có thể mất ngày để phản hồi). Không phù hợp với nhu cầu tương tác nhanh trong dự án hybrid đang gặp vấn đề. PMBOK 7th khuyến nghị email chỉ cho thông tin không khẩn cấp, không phải công cụ chính cho feedback (8.1.2.3).

• ❌ Refer to the stakeholder engagement plan.
  Sai vì: Stakeholder Engagement Plan tập trung vào chiến lược tương tác tổng thể (như mức độ tham gia: unaware, resistant, neutral...), không quy định cụ thể phương thức giao tiếp hay xử lý khác múi giờ. Nó hỗ trợ "who" và "how to engage", nhưng không thay thế Communications Management Plan cho "what, when, how to communicate" (PMBOK 7th: 13.3 Manage Stakeholder Engagement).

• ❌ Set up a conference call for all stakeholders.
  Sai vì: Conference call (gọi hội nghị) yêu cầu thời gian thực, rất khó khăn với stakeholders khác múi giờ (ví dụ: chênh 12 giờ, ai đó phải thức khuya). Điều này có thể làm giảm sự tham gia và hiệu quả, vi phạm nguyên tắc inclusive communication trong hybrid projects. PMBOK 7th ưu tiên các phương pháp async (không đồng bộ) cho global teams (8.1.2.4).

• ✅ Refer to the communications management plan.
  Đúng vì: Như đã giải thích ở trên, đây là hành động chuẩn đầu tiên, đảm bảo phù hợp với quy trình dự án, hỗ trợ feedback hiệu quả qua các công cụ được định sẵn (ví dụ: polls, shared docs). Hoàn hảo cho hybrid context (PMBOK 7th: Tool & Techniques in Communications Management).

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, cập nhật PMI 2026): Chương 8 (Project Communications Management), Đặc biệt 8.1.2 (Communications Methods: Interactive, Push, Pull).
• PMP Examination Content Outline (2021): Domain 3 (Business Environment) & Domain 9 (Communications), nhấn mạnh "Tailoring communication based on stakeholder needs".
• PMI Agile Practice Guide (2021): Phần Hybrid Approaches, khuyến nghị async tools cho distributed teams.
• PMI.org (truy cập 2026): Standards+Tools cho Communications in Global Projects.

🧠 Lời khuyên PMP: Luôn ưu tiên tham khảo kế hoạch hiện có trước khi hành động ad-hoc để đảm bảo tính nhất quán và hiệu quả! Nếu cần thực hành thêm, hãy tập trung vào hybrid scenarios trong PMP mock exams.

🧩 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ý Lịch trình (Schedule Management) trong giai đoạn Planning của dự án, theo khung kiến thức PMP (PMBOK Guide).

📖 Tình huống cụ thể: Một đội dự án đang ở giai đoạn lập kế hoạch cho dự án di chuyển sản phẩm (product migration project). Quản lý dự án (PM) đã lên lịch họp với đội dự án (project team), đội viễn thông (telecommunications team), và các lãnh đạo bộ phận quản lý tài khoản sản phẩm nhóm (department leaders with group product accounts).

🎯 Mục đích cuộc họp: Xác định dòng thời gian dự án (project timeline) dựa trên:

• Lượng nội dung cần chuyển giao (transferred) hoặc tạo mới (created) trong hệ thống mới.
• Quy trình xử lý (processing procedures) và khung thời gian (time frames) liên quan.

🛠️ Vấn đề cần giải quyết: PM cần mời thêm ai vào cuộc họp để đảm bảo thông tin đầy đủ, chính xác cho việc ước lượng thời gian? Điều này nhấn mạnh nguyên tắc Stakeholder Engagement và Expert Judgment trong Develop Schedule (Quy trình 6.5 theo PMBOK 6th Ed., hoặc tương đương trong PMBOK 7th Ed. với Domain: Schedule).

Câu hỏi kiểm tra khả năng nhận diện stakeholder phù hợp nhất để hỗ trợ lập kế hoạch lịch trình, tránh rủi ro chậm trễ do thiếu input từ các bên liên quan trực tiếp đến quy trình triển khai nội dung và dịch vụ.

✅ Đáp án đúng: Representative from the provisioning team

Lý do lựa chọn (theo PMP mới nhất - PMBOK 7th Edition & 6th Edition):
Provisioning team chịu trách nhiệm cung cấp và kích hoạt dịch vụ (service provisioning), bao gồm thiết lập tài khoản, chuyển dữ liệu nội dung, và áp dụng quy trình xử lý thời gian thực tế trong hệ thống mới. Họ cung cấp expert judgment về thời lượng thực tế cho việc transfer/create content và processing procedures – yếu tố cốt lõi của cuộc họp. Không mời họ sẽ dẫn đến lịch trình không khả thi (unrealistic schedule).
🧩 Điều này phù hợp Plan Schedule Management (Process 6.1) và Estimate Activity Durations (6.4), nơi cần input từ các team operations để đảm bảo tính khả thi (feasibility).

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

• ✅ Representative from the provisioning team
  Đúng vì: Đây là bên trực tiếp xử lý quy trình provisioning (cung cấp dịch vụ), bao gồm chuyển nội dung, tạo dữ liệu mới và thời gian xử lý – khớp chính xác mục đích họp. Họ cung cấp dữ liệu thực tế để ước lượng timeline, tránh overestimate/underestimate durations (PMBOK 7th Ed., Principle: Optimize Risk Responses).

• ❌ Representative from the network team
  Sai vì: Network team chỉ tập trung vào hạ tầng mạng (network infrastructure), không liên quan trực tiếp đến nội dung chuyển giao hoặc quy trình xử lý sản phẩm. Họ có thể cần sau (execution), nhưng không phải cho planning content migration timeline.

• ❌ Representative from the reimbursement team
  Sai vì: Reimbursement team xử lý hoàn tiền/thanh toán (financial reimbursements), hoàn toàn không liên quan đến transfer content, tạo dữ liệu hay processing procedures của dự án migration. Đây là stakeholder ngoài phạm vi (out of scope).

• ❌ Representative from the service desk team
  Sai vì: Service desk team hỗ trợ người dùng cuối (end-user support) sau khi hệ thống live, không cung cấp input về thời gian transfer/create content hay quy trình planning. Họ phù hợp hơn cho Monitor and Control hoặc Close Project.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật đến 2026): Domain 3 - Project Schedule (Performance Domain), Principle 5: Optimize Risk Responses; Stakeholder Engagement (Ch. 4).
• PMBOK Guide 6th Edition: Processes 6.4-6.5 (Estimate Activity Durations & Develop Schedule), ITTO nhấn mạnh Expert Judgment từ operations teams như provisioning.
• PMP Exam Content Outline (2021): Task 5.2 (Develop schedule).
  (Nguồn: PMI.org, Agile Practice Guide tích hợp cho migration projects).

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

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

Câu hỏi PMP này tập trung vào quản lý xung đột liên quan đến rủi ro công nghệ mới trong dự án. Cụ thể:

• Project sponsor (nhà tài trợ dự án) đang thúc đẩy sử dụng một công nghệ mới chưa được phê duyệt (not yet approved). Công nghệ này hứa hẹn tiết kiệm chi phí (cost savings) và giao hàng sớm hơn lịch trình (delivery ahead of schedule).
• Tuy nhiên, tồn tại rủi ro lớn: Hỗ trợ vận hành sau khi dự án hoàn thành không chắc chắn (operational support uncertain), vì tổ chức dịch vụ (service organization) không thể hỗ trợ nếu chưa có phê duyệt.
• Xung đột cốt lõi: Lợi ích ngắn hạn (tiết kiệm, nhanh) vs. rủi ro dài hạn (không hỗ trợ vận hành, ảnh hưởng đến giá trị dự án cho khách hàng).
• Vai trò của Project Manager (PM): Phải giải quyết xung đột theo nguyên tắc Tailoring (tùy chỉnh cách tiếp cận), Risk Management (quản lý rủi ro), và Stakeholder Engagement (tương tác bên liên quan), ưu tiên lợi ích bền vững cho khách hàng (customer benefit).
  Mục tiêu: PM cần nhận diện vấn đề phê duyệt, tránh thúc đẩy mù quáng, và hướng tới giải pháp cân bằng. 🛠️

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

Đáp án đúng: Acknowledge the lack of approval and focus on a resolution that will benefit the customer.

Lý do chọn đáp án này (dựa trên PMBOK® Guide 7th Edition và PMP Exam Content Outline 2021, cập nhật đến 2026):

• PM phải thừa nhận thực tế thiếu phê duyệt (acknowledge the lack of approval) để tránh rủi ro handover dự án thất bại, phù hợp với Principle 4: Be a diligent, respectful, and caring steward (quản lý tận tụy, tôn trọng lợi ích tổ chức).
• Tập trung giải quyết xung đột hướng tới lợi ích khách hàng (resolution benefiting the customer) bao gồm cả vận hành dài hạn, không chỉ lợi ích ngắn hạn của sponsor. Điều này thể hiện Value Delivery (giao giá trị) và Risk Response (phản ứng rủi ro) trong Domain 2: Team và Domain 3: Business Value.
• Đây là cách tiếp cận proactive và holistic (chủ động, toàn diện), tránh bias từ sponsor. 📘

📋 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. 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 lý do đúng/sai dựa trên PMP mới nhất:

• Seek to understand the project stakeholders’ needs in an effort to support the new technology.
  ❌ Phương án SAI: Việc chỉ tìm hiểu nhu cầu stakeholders để hỗ trợ công nghệ mới (support the new technology) là thiên vị (biased), bỏ qua rủi ro phê duyệt và hỗ trợ vận hành. PMBOK 7th nhấn mạnh phải analyze objectively (phân tích khách quan), không ưu tiên sponsor mà bỏ qua customer tổng thể (Stakeholder Management - Process 13.3 Monitor Stakeholder Engagement).

• Communicate the project’s progress to the stakeholders and promote the new technology.
  ❌ Phương án SAI: Giao tiếp tiến độ và thúc đẩy công nghệ mới (promote the new technology) chỉ làm tăng xung đột, không giải quyết gốc rễ (lack of approval). PMP yêu cầu transparent communication nhưng phải address risks first (xử lý rủi ro trước), theo Domain 4: Uncertainty (quản lý không chắc chắn), tránh "selling" giải pháp chưa an toàn.

• Maintain and adhere to project plans to ensure the project delivers successful outcomes.
  ❌ Phương án SAI: Giữ nguyên kế hoạch dự án (maintain and adhere) nghe an toàn nhưng bị động, không giải quyết xung đột sponsor vs. support organization. PMBOK 7th Edition khuyến khích Adaptive Planning (lập kế hoạch thích ứng), PM phải escalate issues (leo thang vấn đề phê duyệt) để đảm bảo outcomes bền vững, không chỉ "stick to plan" mù quáng.

• Acknowledge the lack of approval and focus on a resolution that will benefit the customer.
  ✅ Phương án ĐÚNG: Như đã giải thích ở trên, đây là hành động chủ động, cân bằng, ưu tiên customer-centric resolution (giải pháp hướng khách hàng), phù hợp hoàn hảo với 12 Principles PMP (đặc biệt Principle 7: Optimize risk responses) và Performance Domain 1: Stakeholders.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, PMI): Chương 2 (Principles), Chương 4 (Performance Domains: Stakeholders, Uncertainty).
• PMP Examination Content Outline (2021, cập nhật 2024-2026): Domain 1 (People 42%), Domain 3 (Business Value 22%) – Cross-cutting skills: Conflict resolution, Risk prioritization.
• PMI Agile Practice Guide (tích hợp PMBOK 7th): Nhấn mạnh tailoring cho rủi ro công nghệ mới.
  Để ôn thi PMP, khuyến nghị thực hành qua PMI.org hoặc ứng dụng chính thức. Chúc bạn thành công! 🚀

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

📖 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả tình huống một Project Manager (PM) được giao quản lý một dự án đang gặp nhiều xung đột liên quan đến tình trạng dự án và việc tuân thủ các quy định quốc tế. Trong một cuộc họp định kỳ, Sponsor (nhà tài trợ) hỏi về tần suất (frequency) mà các rủi ro (risks) được xem xét lại. PM cần kiểm tra tài liệu nào trước tiên để trả lời câu hỏi này.
🛠️ Ý nghĩa chính: Đây là câu hỏi kiểm tra kiến thức về quy trình Quản lý Rủi ro (Risk Management) trong PMP, cụ thể là nơi lưu trữ thông tin về tần suất đánh giá rủi ro định kỳ. Theo PMBOK® Guide (phiên bản mới nhất 7th Edition và cập nhật Process 2.0 đến 2024-2026), tần suất này được định nghĩa trong kế hoạch quản lý rủi ro, giúp đảm bảo rủi ro được theo dõi liên tục.

✅ Đáp án đúng: Risk management plan
Lý do lựa chọn (chi tiết):
Risk Management Plan là tài liệu cốt lõi trong quy trình Plan Risk Management (PMBOK 6th Ed: 11.1; PMBOK 7th Ed: Risk Domain). Nó mô tả tần suất và thời điểm xem xét rủi ro (timing and frequency of risk reviews), bao gồm lịch họp đánh giá rủi ro định kỳ. PM phải kiểm tra tài liệu này trước tiên vì nó là nguồn gốc định nghĩa quy trình, giúp trả lời chính xác câu hỏi của Sponsor mà không cần tra cứu các tài liệu chi tiết khác. Điều này phù hợp với nguyên tắc "first thing to check" trong tình huống cần thông tin quy trình.

🔍 Phân tích tất cả các phương án trả lời

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 PMBOK® Guide mới nhất:

• ✅ Risk management plan
  Giải thích: Đây là đáp án đúng vì Risk Management Plan chứa thông tin chi tiết về phương pháp, vai trò, và đặc biệt là tần suất xem xét rủi ro định kỳ (frequency of risk reviews). Nó được tạo ở đầu quy trình Quản lý Rủi ro và là tài liệu tham chiếu đầu tiên cho bất kỳ câu hỏi về quy trình review nào. Sponsor hỏi "how frequently", nên PM ưu tiên kiểm tra kế hoạch này để xác nhận lịch trình.

• ❌ Risk register
  Giải thích: Risk Register là danh sách chi tiết các rủi ro đã xác định, phân tích, và theo dõi (chứa ID rủi ro, xác suất, tác động, response plans). Nó không chứa thông tin về tần suất review mà chỉ cập nhật status rủi ro sau mỗi lần review. Kiểm tra nó sẽ không trả lời trực tiếp câu hỏi về frequency.

• ❌ Issue log
  Giải thích: Issue Log ghi nhận và theo dõi các vấn đề (issues) đã xảy ra – những rủi ro đã trở thành hiện thực. Nó không liên quan đến rủi ro tiềm ẩn hoặc tần suất review rủi ro, mà tập trung vào việc giải quyết issues hiện tại. Sai hoàn toàn với ngữ cảnh câu hỏi về risks.

• ❌ Risk report
  Giải thích: Risk Report là báo cáo tổng hợp dành cho stakeholder, tóm tắt tình trạng rủi ro hiện tại (identified risks, overall risk exposure). Nó không định nghĩa tần suất review mà chỉ phản ánh kết quả sau review. Kiểm tra nó có thể cho status gần nhất nhưng không phải nguồn gốc frequency.

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

• PMBOK® Guide 7th Edition (2021) & Process 2.0 updates (2024): Risk Management Domain, trang 263-270: Risk Management Plan components bao gồm "Risk process frequency".
• PMBOK® Guide 6th Edition (lưu trữ chuẩn): Section 11.2.2.1 – Risk Management Plan explicitly lists "timing and frequency".
• PMI Agile Practice Guide (2021): Nhấn mạnh iterative risk reviews trong hybrid projects.
  (Nguồn chính thức từ PMI.org, khuyến nghị kiểm tra PMP Exam Content Outline 2024 cho câu hỏi tương tự).

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

Câu hỏi này thuộc chủ đề Quản lý Mua sắm (Procurement Management) trong PMP, cụ thể ở giai đoạn khởi tạo dự án (initial phase) của một dự án tư vấn quản trị (governance consulting project). 🛠️ Project manager (PM) được giao nhiệm vụ đánh giá hoạt động tìm kiếm nhà cung cấp (supplier search activity). Có nhiều ứng viên quan tâm, bao gồm các nhà cung cấp cũ (former suppliers) và những nhà cung cấp được tài trợ viên (sponsor) giới thiệu.

Câu hỏi đặt ra tình huống: PM nên làm gì trong tình huống này? Mục tiêu là kiểm tra khả năng áp dụng nguyên tắc khách quan, công bằng trong đánh giá nhà cung cấp, tránh thiên vị cá nhân, mối quan hệ cũ hoặc ảnh hưởng từ sponsor, nhằm chọn nhà cung cấp phù hợp nhất với nhu cầu dự án. Điều này liên quan đến quy trình Plan Procurement Management và Conduct Procurements, nhấn mạnh việc sử dụng tiêu chí đánh giá khách quan dựa trên năng lực liên quan đến dự án.

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

Đáp án đúng: Evaluate the suppliers based on their experience and skills in similar projects

Lý do: Theo PMBOK® Guide 7th Edition (Process 10.1 - Plan Procurement Management), PM phải xây dựng và áp dụng tiêu chí đánh giá khách quan (objective evaluation criteria) để chọn nhà cung cấp, tập trung vào kinh nghiệm và kỹ năng liên quan trực tiếp đến dự án tương tự (similar projects). 🏆 Việc này đảm bảo tính minh bạch, giảm rủi ro, tối ưu hóa giá trị dự án và tuân thủ nguyên tắc Tailoring cũng như Value Delivery System. Không nên ưu tiên mối quan hệ cũ hoặc khuyến nghị cá nhân, vì có thể dẫn đến bias và thất bại dự án.

📋 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 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 bằng tiếng Việt:

• ❌ Evaluate suppliers who have worked successfully with the company before
  Phương án này sai vì chỉ tập trung vào lịch sử làm việc thành công với công ty trước đây, bỏ qua tính phù hợp với dự án hiện tại. 🧨 Theo PMBOK® 7th Edition (Procurement Principles), đánh giá phải dựa trên tiêu chí dự án cụ thể, không phải mối quan hệ quá khứ, để tránh rủi ro performance kém hoặc chi phí cao hơn.

• ❌ Request the contracting area take charge of the supplier evaluation process
  Phương án này sai vì PM chịu trách nhiệm chính trong quản lý mua sắm (PM's accountability in Procurement Performance Domain). 📛 PMBOK® 7th Edition nhấn mạnh PM phải tích cực tham gia đánh giá (Stakeholder Engagement), không nên giao hết cho bộ phận contracting mà không giám sát, dẫn đến mất kiểm soát và chậm trễ ở giai đoạn initial.

• ❌ Prioritize evaluation of the suppliers recommended by the sponsor
  Phương án này sai vì ưu tiên khuyến nghị của sponsor tạo thiên vị (bias), vi phạm nguyên tắc fairness và integrity trong Code of Ethics & Professional Conduct (EC.1.3). 🚫 PMBOK® 7th Edition (Leadership Domain) yêu cầu quyết định dựa trên dữ liệu khách quan, không phải ảnh hưởng cá nhân, để bảo vệ lợi ích dự án và tổ chức.

• ✅ Evaluate the suppliers based on their experience and skills in similar projects
  Như đã giải thích ở trên, đây là cách tiếp cận đúng đắn, phù hợp với source selection criteria (PMBOK® 7th Edition, Section 10.2), đảm bảo chọn nhà cung cấp có năng lực cao nhất cho dự án governance consulting.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021): Procurement Management (Pages 139-143), Plan Procurement Management, source selection analysis. ✅
• PMI Code of Ethics & Professional Conduct (updated 2022): Responsibility & Respect principles.
• PMP Exam Content Outline (2021, valid to 2026): Domain 5: Business Environment (15%), Process 10 - Procurement Management.
• Các cập nhật mới nhất đến 2026 từ PMI.org: Nhấn mạnh Agile Hybrid trong procurement, vẫn ưu tiên objective criteria (xem PMI Standards+).

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 mô tả một dự án phát triển công cụ mới cho công ty vận tải, nhằm cải thiện quy trình giao hàng. Dự án đang áp dụng phương pháp Agile (vì đề cập đến sprint two - sprint thứ hai). Khi sprint 2 vừa bắt đầu, executive steering committee (ban điều hành cấp cao) yêu cầu thêm tính năng mới: what-if analysis (phân tích tình huống giả định) dựa trên nhu cầu và dự báo khách hàng. Đây là một thay đổi phạm vi (scope change) đột ngột từ cấp cao.

🛠️ Vấn đề cốt lõi: Project manager (PM) cần quyết định bước tiếp theo để xử lý yêu cầu này một cách chuyên nghiệp, đảm bảo tuân thủ quy trình quản lý thay đổi (change management) trong PMP. Theo PMBOK Guide 7th Edition (2021) và cập nhật đến 2026 (bao gồm Agile Practice Guide), trong môi trường Agile/hybrid, PM phải đánh giá tác động (impact assessment) trước khi quyết định thêm scope, tránh ảnh hưởng đến sprint hiện tại, lịch trình, ngân sách và giá trị dự án.

📘 Dẫn nguồn:

• PMBOK® Guide 7th Edition, Domain 4: Project Change (Principle 9: Optimize Risk Responses; Process: Manage Project Changes).
• Agile Practice Guide (PMI, 2017-2023 updates): Xử lý backlog changes qua refinement, nhưng yêu cầu từ stakeholder cao cấp cần impact analysis trước (Sprint Goal protection).

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

Đáp án đúng: Perform an impact analysis on the schedule and budget based on the additional scope.

Lý do 🧩:

• Đây là bước đầu tiên và bắt buộc trong quy trình quản lý thay đổi (Change Control Process). PM phải phân tích tác động (impact analysis) đến lịch trình (schedule), ngân sách (budget), tài nguyên, rủi ro và sprint hiện tại trước khi phê duyệt hoặc từ chối.
• Trong Agile, sprint đang diễn ra (sprint two began) nên không thể thay đổi scope ngay lập tức (theo Scrum Guide: Sprint Goal immutable). Impact analysis giúp PM thu thập dữ liệu để trình ban điều hành, đảm bảo quyết định dựa trên dữ liệu (data-driven).
• Điều này phù hợp Principle 11: Holistic Thinking (PMBOK 7) và Tailoring cho Agile-hybrid projects.

🔍 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 tiếng Anh, chỉ giải thích bằng tiếng Việt với lý do rõ ràng:

• ❌ Revise the project schedule and budget based on the additional scope, and review with the team.
  Sai vì: Phương án này giả định thay đổi đã được phê duyệt và chỉnh sửa lịch trình/ngân sách ngay lập tức, bỏ qua bước impact analysis bắt buộc. Điều này vi phạm quy trình change control (PMBOK 7, 4.7), có thể dẫn đến scope creep, làm gián đoạn sprint đang chạy và tăng rủi ro (Risk Domain). PM không được "revise" mà chưa đánh giá tác động đầy đủ.

• ❌ Include the new capability to the product backlog and continue activities based on the current plan.
  Sai vì: Thêm trực tiếp vào product backlog mà không đánh giá tác động là rủi ro cao trong Agile. Backlog cần refinement (PO responsibility), nhưng yêu cầu từ executive cần integrated change control (PMBOK 7). Tiếp tục "current plan" có thể làm backlog bùng nổ (backlog explosion), ảnh hưởng sprint goal và velocity. Không phù hợp vì sprint đã bắt đầu.

• ✅ Perform an impact analysis on the schedule and budget based on the additional scope.
  Đúng vì: Như đã giải thích ở trên, đây là bước next logical (tiếp theo hợp lý). PM thực hiện phân tích tác động để định lượng ảnh hưởng đến schedule/budget/rủi ro, sau đó escalate lên CCB (Change Control Board) hoặc steering committee. Hỗ trợ Stakeholder Engagement Domain và Agile value (Respond to Change).

• ❌ Analyze and negotiate with the executive steering committee regarding this new request.
  Sai vì: "Analyze" ở đây mơ hồ, không cụ thể impact trên schedule/budget như đáp án đúng. Negotiate ngay lập tức là chủ quan, thiếu dữ liệu (data), có thể dẫn đến conflict với stakeholder cao cấp. PMBOK 7 yêu cầu formal impact assessment trước negotiate (Principle 4: Stakeholder Collaboration), tránh "negotiate blind".

🛠️ Kết luận & Lời khuyên PMP: Luôn ưu tiên impact analysis cho mọi change request để bảo vệ dự án. Trong Agile, phối hợp với Product Owner (PO) cho backlog, nhưng PM dẫn dắt change control. Thực hành này giúp đạt 90% success rate trong projects (PMI Pulse of Profession 2023-2026). Nếu cần mock exam thêm, hãy hỏi nhé! 🚀