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 chủ đề Quản lý Hiệu suất Dự án (Project Performance Management) trong PMP, cụ thể là giai đoạn Thực thi (Executing) của dự án. Dự án đang nằm trong một chương trình chuyển đổi lớn (transformation program), nơi Project Manager (PM) báo cáo trực tiếp cho Program Manager và đồng thời là trưởng Steering Committee (SC) của dự án. Cuộc họp SC sắp diễn ra trong 2 tuần tới, và PM cần trình bày cách tiếp cận đo lường hiệu suất lịch trình (schedule performance) của dự án từ đầu đến nay.

📌 Điểm mấu chốt: Câu hỏi tập trung vào schedule performance metrics chuẩn theo Earned Value Management (EVM), không phải chi phí, lợi ích kinh doanh hay phương pháp Agile (vì dự án không được mô tả là Agile). PM cần chuẩn bị giải thích các chỉ số đã và đang sử dụng để đo lường tiến độ thời gian, phù hợp với nguyên tắc Monitor and Control Project Work trong PMBOK® Guide 7th Edition.

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

Đáp án đúng: Prepare to explain that the schedule performance index (SPI), schedule variance (SV), and other performance metrics are being used.

Lý do: Theo PMBOK® Guide 7th Edition (và vẫn áp dụng đến 2026), SPI (Schedule Performance Index) và SV (Schedule Variance) là các chỉ số cốt lõi trong EVM để đo lường hiệu suất lịch trình. SPI = EV/PV (EV: Earned Value, PV: Planned Value), nếu >1 thì tiến độ nhanh hơn kế hoạch. SV = EV - PV, nếu >0 thì vượt tiến độ. PM cần giải thích các metrics này đang được sử dụng (không phải cập nhật mới), vì câu hỏi nhấn mạnh "approach to measure... thus far" (cách đo lường đến nay). Điều này phù hợp với vai trò PM trong SC, đảm bảo minh bạch và kiểm soát hiệu suất. 🛠️

📋 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 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 PMBOK® Guide 7th Edition, Process Groups và EVM Metrics (Section 4.6 Manage Project Knowledge & 7th Ed. Tools & Techniques).

• ❌ Phương án SAI: Prepare to demonstrate the cost-benefit ratio, business value, and return on investment (ROI) as the schedule performance metrics.
  Giải thích: Các chỉ số này (cost-benefit ratio, business value, ROI) thuộc về lợi ích kinh doanh và giá trị tổng thể (benefits realization), không phải metrics đo lường schedule performance. Chúng dùng cho Portfolio/Program level hoặc giai đoạn Closing, không phù hợp trình bày trong SC về tiến độ thời gian. Sử dụng chúng sẽ lệch lạc, vi phạm nguyên tắc Tailor Performance Metrics theo ngữ cảnh dự án.

• ❌ Phương án SAI: Update the cost performance index (CPI) and schedule performance index (SPI) to measure the performance of the project.
  Giải thích: Phương án này lẫn lộn cost (CPI = EV/AC) với schedule (SPI), trong khi câu hỏi chỉ yêu cầu schedule performance. Hơn nữa, PM không cần "update" (cập nhật mới) mà chỉ "present the approach" (trình bày cách đo lường đến nay). Việc chỉ dùng CPI/SPI cũng thiếu SV và "other metrics" cần thiết cho báo cáo toàn diện.

• ✅ Phương án ĐÚNG: Prepare to explain that the schedule performance index (SPI), schedule variance (SV), and other performance metrics are being used.
  Giải thích: Đây là lựa chọn chính xác vì trực tiếp đề cập SPI và SV – hai metrics chuẩn cho schedule trong EVM (PMBOK® 7th Ed., Principle 9: Optimize Risk Responses & Measure Outcomes). Cụm "other performance metrics" bao quát các chỉ số bổ sung như To-Complete Schedule Performance Index (TCPI), phù hợp với dự án đang thực thi và báo cáo cho SC/Program Manager.

• ❌ Phương án SAI: Inform the program manager that the project is using an agile approach and schedule performance metrics are not applicable.
  Giải thích: Câu hỏi không đề cập dự án dùng Agile (chỉ là "execution phase" trong chương trình lớn, ngụ ý predictive/hybrid). Trong Agile, vẫn có metrics như Velocity hoặc Burndown Chart, nhưng schedule metrics như SPI/SV vẫn áp dụng ở hybrid hoặc program level (Agile Practice Guide). Từ chối metrics là không chuyên nghiệp, vi phạm Stewardship Principle.

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (2021, PMI): Section 4.5 Develop Schedule & 6.7 Control Schedule; Tools: Earned Value Analysis (EVA).
• Agile Practice Guide (PMI, 2017): Metrics in Agile (Velocity, nhưng không loại bỏ EVM).
• PMP Exam Content Outline (2024-2026): Domain III: Business Environment (15%) & Domain IV: Deliverables (30%) – nhấn mạnh performance measurement.
  🔗 Nguồn chính thức: PMI.org (kiến thức cập nhật đến 2026 không thay đổi cốt lõi EVM).

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é.

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

Câu hỏi mô tả tình huống một Project Manager (PM) đang dẫn dắt một dự án kéo dài nhiều năm (multiyear project). Gần cuối năm đầu tiên, PM kiểm tra và nhận thấy ngân sách phân bổ cho năm nay có thể không sử dụng hết. Lý do là một số tính năng (features) được thêm vào muộn trong năm qua change requests, sử dụng ngân sách năm nay nhưng chưa sẵn sàng hoàn thành trước cuối năm.

🛠️ Vấn đề cốt lõi: PM cần quyết định hành động phù hợp để xử lý ngân sách chưa dùng hết, đảm bảo tuân thủ nguyên tắc quản lý dự án như kiểm soát chi phí (Cost Control), quản lý thay đổi (Change Control) và báo cáo cho stakeholders (Stakeholder Engagement). Theo PMBOK® Guide 7th Edition (2021, cập nhật đến 2026), trong dự án dài hạn, PM phải minh bạch về tiến độ timeline và chi phí, tránh các hành động rủi ro như thanh toán sớm hoặc thay đổi hợp đồng không chính thức.

📘 Nguồn tham khảo:

• PMBOK® Guide 7th Edition, Principle 5: Optimize Risk Responses & Domain: Measurement (Tracking progress).
• Practice Standard for Project Estimating (2021): Nhấn mạnh forecasting và updates định kỳ cho financial stakeholders.

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

Đáp án đúng: Provide an update to the financial department regarding the status of the time line of the project.

Lý do:

• PM cần cung cấp cập nhật minh bạch về tình trạng timeline dự án cho bộ phận tài chính, giúp họ hiểu lý do ngân sách chưa dùng hết (do features chưa sẵn sàng dù đã approve change requests). Điều này tuân thủ Stakeholder Engagement và Performance Reporting trong PMBOK 7th, đảm bảo dự báo chi phí chính xác (forecasting) và tránh hiểu lầm. Trong dự án đa năm, cập nhật timeline giúp điều chỉnh ngân sách năm sau nếu cần, mà không vi phạm quy trình kiểm soát thay đổi.
• ✅ Lợi ích: Giảm rủi ro tài chính, duy trì lòng tin stakeholders, phù hợp với Value Delivery System.

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

• ❌ Ask the team to test partially ready features and check if payment can be authorized with a signed formal acceptance.
  Phương án này sai vì ép đội ngũ test các tính năng chưa sẵn sàng (partially ready) vi phạm Quality Management (PMBOK 7th, Domain: Uncertainty) và nguyên tắc "Deliver value only when ready". Thanh toán dựa trên acceptance giả tạo có thể dẫn đến rủi ro pháp lý, không đúng quy trình Validate Scope & Control Procurements. Không giải quyết gốc rễ vấn đề ngân sách.

• ❌ Authorize payment for the features ready this year and for the features planned for the following year that are now ready.
  Phương án này sai vì PM không có quyền tự authorize payment cho features vượt ngân sách năm nay hoặc lẫn lộn năm sau, vi phạm Integrated Change Control và Cost Baseline. Theo PMBOK 7th (Principle 3: Focus on Value), thanh toán phải dựa trên Earned Value (EV) thực tế, không phải "now ready" tùy tiện, dễ gây tranh chấp tài chính.

• ❌ Approach the product owner and the financial department to create a new nonbinding contract without fixed deliverables.
  Phương án này sai vì tạo hợp đồng không ràng buộc (nonbinding) với deliverables không cố định là hành động không chuyên nghiệp, vi phạm Procurement Management và Contract Principles (PMBOK 7th, Models/Tools/Techniques). Change requests đã approve rồi, không cần hợp đồng mới; điều này tăng rủi ro pháp lý và làm phức tạp governance.

• ✅ Provide an update to the financial department regarding the status of the time line of the project.
  Như đã giải thích ở trên: Đúng vì ưu tiên transparency và reporting, phù hợp với Project Reporting và Tailoring trong dự án đa năm. Giúp financial department lập kế hoạch rollover budget nếu cần.

🛠️ Kết luận: Hành động đúng tập trung vào giao tiếp và báo cáo thay vì "lách luật" ngân sách, đảm bảo dự án bền vững theo PMP 7th Edition! Nếu cần ví dụ thực tế, hãy hỏi thêm 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ý Thay đổi (Change Management) và Quản lý Dự án Tổng thể (Project Integration Management) trong PMP, cụ thể liên quan đến việc xử lý tình huống thiếu nguồn lực tài chính do thay đổi môi trường bên ngoài (external environment changes).

• Bối cảnh: Một công ty đang gặp khó khăn đang thực hiện một dự án quan trọng (critical project). Tuy nhiên, do các yếu tố bên ngoài thay đổi (như suy thoái kinh tế, biến động thị trường), ngân sách không đủ để hoàn thành dự án.
• Yêu cầu hành động đầu tiên: Project Manager (PM) cần quyết định bước đầu tiên nên làm gì để xử lý vấn đề này một cách chuyên nghiệp, tuân thủ nguyên tắc PMP.
• Mục tiêu kiểm tra kiến thức: Kiểm tra sự hiểu biết về quy trình xử lý thay đổi dự án theo PMBOK® Guide (phiên bản 7th Edition, cập nhật đến 2026), nhấn mạnh rằng PM phải đánh giá tác động trước khi thực hiện bất kỳ thay đổi nào, thay vì hành động impulsively.

🛠️ Nguyên tắc PMP cốt lõi: Theo PMBOK® 7th Edition, bất kỳ thay đổi nào (bao gồm thiếu funding) đều phải qua Integrated Change Control Process (Quy trình Kiểm soát Thay đổi Tích hợp). Bước đầu tiên là Assess the impact (Đánh giá tác động) và Evaluate alternatives (Đánh giá các lựa chọn thay thế) để đảm bảo quyết định dựa trên dữ liệu, không ảnh hưởng tiêu cực đến mục tiêu dự án (scope, time, cost, quality, risks).

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

Đáp án đúng: Assess the impact and evaluate alternatives to accommodate the change.

Lý do:

• Đây là bước đầu tiên và bắt buộc theo quy trình PMP khi phát hiện thay đổi (change request). PM phải phân tích tác động (impact assessment) đến các yếu tố như scope, schedule, cost, quality, risks, stakeholders, và đánh giá các lựa chọn thay thế (options analysis) trước khi đề xuất giải pháp cụ thể.
• Việc này đảm bảo tính holistic (toàn diện), hỗ trợ value delivery và adaptive planning trong môi trường VUCA (Volatility, Uncertainty, Complexity, Ambiguity).
• Nếu bỏ qua bước này, PM có nguy cơ vi phạm nguyên tắc Preventive Action và Earned Value Management (EVM), dẫn đến quyết định kém hiệu quả.
• ✅ Lợi ích: Giúp PM thu thập dữ liệu chính xác, trình bày cho sponsor/steering committee để phê duyệt, tránh rủi ro pháp lý hoặc mất lòng tin stakeholders.

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

Dưới đây là phân tích từng phương án một cách chi tiết. Tôi giữ nguyên văn bản gốc tiếng Anh của phương án, chỉ giải thích bằng tiếng Việt lý do đúng/sai dựa trên PMP 7th Edition.

• ❌ [SAI] Reduce the scope of the project to match the available funds.
  Phương án này sai vì giảm scope ngay lập tức mà không đánh giá tác động là vi phạm Scope Management Baseline. Scope là nền tảng dự án (triple constraint), chỉ thay đổi sau khi có Change Control Board (CCB) phê duyệt. Hành động này có thể làm mất giá trị dự án (value), tăng rủi ro, và không giải quyết gốc rễ vấn đề external changes. PM không được tự ý "cắt xén" mà phải assess trước.

• ❌ [SAI] Park the project until the external environment is favorable.
  Phương án này sai vì tạm dừng dự án (parking) là quyết định chiến lược, thuộc thẩm quyền Program/Portfolio Manager hoặc Sponsor, không phải PM. Nó bỏ qua Continuous Improvement và Agile Principles (nếu hybrid), có thể dẫn đến mất momentum, tăng cost sunk, và vi phạm Project Charter. PM phải assess impact trước khi đề xuất "pause".

• ❌ [SAI] Ask the project sponsor to look for additional funding.
  Phương án này sai vì yêu cầu sponsor tìm funding thêm là bước sau assess impact, không phải đầu tiên. PM phải cung cấp data-driven recommendation (dữ liệu đánh giá tác động + alternatives) để sponsor quyết định, tránh làm sponsor "chịu trách nhiệm mù quáng". Theo Stakeholder Engagement, PM là người chủ động phân tích trước khi escalate.

• ✅ [ĐÚNG] Assess the impact and evaluate alternatives to accommodate the change.
  Như đã giải thích ở phần đáp án đúng, đây là bước 1 chuẩn PMP trong Perform Integrated Change Control (ITTO: Inputs như Change Request → Tools: Impact Analysis → Outputs: Change Log). Nó đảm bảo risk-informed decisions và phù hợp với Hybrid Delivery trong PMBOK 7th.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, cập nhật PMI đến 2026): Chương 4 (Project Integration), Section 4.6 Manage Project Changes; Chương 7 (Project Scope); Chương 11 (Project Procurement & Risk).
• PMI Agile Practice Guide (2021): Nhấn mạnh Iterative Assessment trong thay đổi external.
• The Standard for Project Management (2021): Principle 5: Stakeholder Engagement; Principle 9: Adaptability.
• Process Groups: A Practice Guide (2022): Predictive & Agile approaches cho Change Control.

🛠️ Lời khuyên PMP: Luôn ưu tiên Data over Assumption (Dữ liệu hơn giả định) để trở thành PM xuất sắc! Nếu thi PMP, hãy nhớ ITTO của Integrated Change Control.

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

Câu hỏi mô tả tình huống: Quản lý dự án đang xem xét tài liệu để đóng giai đoạn (closing a phase), lúc này khách hàng gọi điện và cho biết dự án không tạo ra giá trị nào cho công ty. Đây là vấn đề phổ biến trong giai đoạn đóng dự án theo PMBOK® Guide 7th Edition (2021, cập nhật đến 2026 không thay đổi cơ bản), nơi quản lý dự án phải đảm bảo giá trị giao hàng (value delivery) và xác nhận kết quả (outcomes) phù hợp với kỳ vọng.

🛠️ Mục tiêu câu hỏi: Kiểm tra kỹ năng của PMP trong quản lý kỳ vọng khách hàng (stakeholder engagement) và đóng dự án (Close Project or Phase - Process 4.7). Thay vì vội đóng hoặc phân tích chi phí, PM cần xác thực ngay lập tức để tránh rủi ro pháp lý, hợp đồng hoặc mất uy tín. Điều này liên quan đến nguyên tắc Value (Giá trị) và Stakeholder (Lợi ích liên quan) trong PMBOK 7.

📘 Nguồn tham khảo:

• PMBOK® Guide 7th Edition, Section 4.7 Close Project or Phase; Principle 4: Optimize Risk; Principle 7: Value.
• PMP Exam Content Outline 2021 (PMI.org, cập nhật 2026): Domain III: Business Environment (17%) & Domain IV: Closing (8%).

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

Đáp án đúng: Validate the project scope, objectives, and outcomes with the customer.

Lý do:

• Trong giai đoạn đóng phase, PM phải xác nhận (validate) scope, objectives và outcomes với khách hàng để đảm bảo alignment với kỳ vọng ban đầu (baseline). Khách hàng phàn nàn về "value" có thể do hiểu lầm hoặc lệch lạc, nên bước đầu tiên là họp/discuss trực tiếp để clarify.
• Điều này tuân thủ Stakeholder Engagement (PMBOK 7, p. 56-58) và Verify Deliverables trước khi close. Nếu không validate, dự án có thể bị từ chối nghiệm thu, dẫn đến tranh chấp.
• ✅ Hành động kịp thời, tập trung vào giá trị thực tế mà không trì hoãn đóng 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 nội dung gốc bằng tiếng Anh, đánh dấu ✅/❌ và giải thích bằng tiếng Việt:

• Validate the project scope, objectives, and outcomes with the customer.
  ✅ Đúng (như đã giải thích ở trên). Đây là bước bắt buộc đầu tiên để tái xác nhận giá trị giao hàng, tránh hiểu lầm và đảm bảo close phase hợp lệ theo Process 4.7 PMBOK 7.

• Wait to close the project until the customer is satisfied.
  ❌ Sai. Việc chờ đợi không phải quy trình chuẩn; closing phase phải theo lịch trình (schedule) và hợp đồng, không phụ thuộc cảm xúc khách hàng. Có thể dẫn đến scope creep hoặc chi phí phát sinh. PMBOK 7 nhấn mạnh timely closure (p. 74), không delay vô thời hạn.

• Analyze which activities will generate the most value for the project.
  ❌ Sai. Phân tích hoạt động (activities) là cho giai đoạn Planning/Executing (Value Maximization Analysis), không phù hợp lúc closing phase. Dự án đã hoàn thành, không nên quay lại optimize activities – sẽ vi phạm nguyên tắc Holistic View (PMBOK 7, Principle 13).

• Perform a cost-benefit analysis for the project.
  ❌ Sai. Phân tích chi phí-lợi ích (CBA) dùng ở Initiate hoặc Business Case (PMBOK 7, p. 42), không phải closing. Lúc này dự án đã deliver, CBA muộn màng và không giải quyết trực tiếp phàn nàn của khách hàng về value hiện tại.

🛠️ Kết luận PMP: Luôn ưu tiên engagement với stakeholder để validate value trước khi close. Thực hành này giúp đạt 70-80% tỷ lệ thành công dự án theo PMI Pulse of the Profession 2023-2026! Nếu gặp tình huống thực tế, ghi log vào Issue Log và escalate nếu cần.

🧩 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ý Nguồn lực Con người (People Domain) trong PMP, cụ thể liên quan đến quy trình Develop Team (theo PMBOK® Guide 7th Edition, cập nhật đến năm 2026). Tình huống mô tả: Trong giai đoạn thực thi dự án (Project Execution), nhà thầu (contractor) đã tự đề xuất và thực hiện site acceptance tests (kiểm tra chấp nhận tại chỗ) và pre-implementation technical training (đào tạo kỹ thuật trước triển khai). Tuy nhiên, đến giai đoạn triển khai (implementation phase), project manager (PM) phát hiện đội ngũ dự án thiếu năng lực (competence gap) trong việc tuân thủ các yêu cầu kỹ thuật.

🛠️ Vấn đề cốt lõi: PM đã để nhà thầu tự quyết định nội dung đào tạo mà không chủ động đánh giá nhu cầu đào tạo của đội ngũ trước đó, dẫn đến đào tạo không phù hợp, gây ra khoảng trống năng lực. Theo nguyên tắc Stewardship và Team trong PMBOK® 7th, PM phải chịu trách nhiệm chính trong việc phát triển năng lực đội ngũ, không thể giao phó hoàn toàn cho nhà thầu.

📘 Dẫn nguồn:

• PMBOK® Guide – Seventh Edition (2021, vẫn là phiên bản chuẩn đến 2026): Phần Manage Project Resources (trang 157-160) và Develop Team (Process 9.4 trong PMBOK® 6th hybrid).
• PMI's The Standard for Project Management (2021): Nhấn mạnh Training Needs Assessment là bước đầu tiên để xác định gap kỹ năng.

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

Performed a proper training needs assessment

🧩 Lý do chi tiết: PM nên thực hiện đánh giá nhu cầu đào tạo đúng đắn (training needs assessment) trước khi nhà thầu đề xuất hoặc thực hiện bất kỳ đào tạo nào. Bước này giúp xác định chính xác khoảng trống năng lực (skill gaps) của đội ngũ dự án so với yêu cầu kỹ thuật, đảm bảo đào tạo được thiết kế phù hợp, tránh tình trạng "đào tạo không hiệu quả" dẫn đến gap trong implementation. Đây là hoạt động proactive theo People Domain, giúp PM kiểm soát rủi ro nhân sự từ đầu dự án. Nếu làm đúng, PM có thể từ chối hoặc điều chỉnh đề xuất của nhà thầu để phù hợp needs thực tế.

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

• Ensured the training conducted by the contractor used standard methods
  ❌ Sai vì: Việc đảm bảo đào tạo của nhà thầu sử dụng phương pháp chuẩn chỉ là kiểm soát cách thức thực hiện (how), không giải quyết gốc rễ vấn đề nhu cầu thực tế (what). Nếu needs chưa được assess, ngay cả phương pháp chuẩn cũng có thể đào tạo sai nội dung, dẫn đến gap competence. Đây chỉ là biện pháp bổ sung, không phải hành động tránh tình huống từ đầu.

• Reviewed the proposed training with the contractor
  ❌ Sai vì: Review đề xuất đào tạo chỉ là kiểm tra thụ động sau khi nhà thầu đã đề xuất, không đảm bảo nội dung phù hợp với needs của đội ngũ dự án. PM có thể reject, nhưng nếu chưa biết chính xác gaps qua assessment, review vẫn không hiệu quả, dễ bỏ lỡ rủi ro. PMBOK® nhấn mạnh assessment phải trước bất kỳ training plan nào.

• Performed a proper training needs assessment
  ✅ Đúng vì: Như đã giải thích ở trên, đây là bước cơ bản và proactive nhất để tránh gap, xác định exactly những kỹ năng cần đào tạo dựa trên requirements kỹ thuật và competence hiện tại của team.

• Prepared proper training outcome measurements
  ❌ Sai vì: Chuẩn bị đo lường kết quả đào tạo (như KPI, post-training evaluation) chỉ diễn ra sau đào tạo để kiểm tra hiệu quả, không ngăn ngừa gap từ đầu. Nếu needs chưa assess, measurements cũng vô nghĩa vì đào tạo sai hướng rồi. Đây thuộc Manage Quality hoặc Control Resources, không phải avoid situation.

🛠️ Bài học PMP: Luôn ưu tiên proactive assessment trong quản lý đội ngũ để tuân thủ Value Delivery System (PMBOK® 7th). Nếu áp dụng, PM có thể tích hợp vào Resource Management Plan từ Planning phase! 🚀

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

Câu hỏi mô tả tình huống thực tế trong quản lý dự án PMP: Quản lý dự án (Project Manager - PM) nhận được khiếu nại (claim) từ khách hàng (client) vì sản phẩm bàn giao (deliverable) không hoạt động đúng như mong đợi. Sau khi điều tra, PM phát hiện nguyên nhân là deliverable này được giao khoán (outsourced) cho nhà cung cấp bên ngoài (external provider), nhưng PM không hề được thông báo (not made aware).

🛠️ Mục tiêu chính của câu hỏi: Xác định công cụ chính (primary tool) trong PMP có thể giúp PM phát hiện sớm tình huống này, tránh được vấn đề thiếu thông tin giao tiếp nội bộ hoặc với bên ngoài. Đây là vấn đề liên quan đến quản lý giao tiếp (Communications Management), nơi thông tin về quyết định outsourcing cần được truyền đạt kịp thời đến PM để giám sát.

📘 Kiến thức PMP cập nhật (PMBOK 7th Edition, 2021 & PMP Exam Content Outline 2024): Theo PMBOK 7th, Communications là một trong 8 Performance Domains (Domain 4: Project Communications), nhấn mạnh việc lập kế hoạch giao tiếp để đảm bảo thông tin chảy đúng người, đúng lúc. Quy trình Plan Communications Management (từ PMBOK 6th, vẫn áp dụng) giúp xác định "ai giao tiếp gì, với ai, khi nào".

✅ Đáp án đúng: Communications management plan

Lý do lựa chọn:
Kế hoạch quản lý giao tiếp (Communications management plan) là công cụ cốt lõi giúp PM xác định các kênh, phương thức và trách nhiệm giao tiếp trong dự án. Trong tình huống này, quyết định outsourcing deliverable cần được thông báo rõ ràng qua các cuộc họp, báo cáo định kỳ hoặc escalation process được quy định trong kế hoạch này. Nếu có kế hoạch giao tiếp hiệu quả, PM sẽ được "made aware" kịp thời về việc giao khoán, tránh claim từ client.
🧩 Liên kết PMP: Theo PMBOK 7th (Section 4.2), kế hoạch này bao gồm stakeholder communication requirements, giúp phát hiện lỗ hổng thông tin với external providers. Đây là primary tool vì vấn đề gốc rễ là thiếu nhận thức (not made aware) do giao tiếp kém.

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

• ✅ Communications management plan
  Đúng vì: Đây là công cụ chính quy định flow thông tin dự án, bao gồm thông báo về thay đổi như outsourcing. Nếu áp dụng, PM sẽ nhận được update từ team/stakeholder về external provider, ngăn chặn tình huống "không biết". (Tham khảo: PMBOK 7th Edition, Principle 4 & Process 10.1).

• ❌ Scope baseline
  Sai vì: Scope baseline (bao gồm scope statement, WBS, WBS dictionary) chỉ định nghĩa phạm vi công việc (what), không quy định ai thực hiện (who) hoặc cách thông báo outsourcing. Nó không giúp PM "made aware" về external provider, mà chỉ kiểm tra deliverable có đúng scope không sau khi issue xảy ra.

• ❌ Risk register
  Sai vì: Risk register ghi nhận rủi ro tiềm ẩn (như rủi ro outsourcing), nhưng không phải công cụ để thông báo sự kiện đã xảy ra (deliverable đã outsourced). Nó dùng để theo dõi/mitigate rủi ro trước, không phát hiện thiếu giao tiếp realtime.

• ❌ Stakeholder register
  Sai vì: Stakeholder register liệt kê danh sách stakeholder (influence, interest), có thể bao gồm external provider, nhưng không quy định kế hoạch giao tiếp cụ thể với họ. Nó chỉ là input, không phải tool primary để đảm bảo PM được thông báo về outsourcing.

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

• PMBOK® Guide 7th Edition (PMI, 2021) - Chapter 4: Project Communications.
• PMP Examination Content Outline (PMI, 2024) - Domain IV: People (Communications).
• Agile Practice Guide (PMI) - Nhấn mạnh transparent communication trong outsourcing.

💡 Lời khuyên PMP: Luôn ưu tiên lập Communications Management Plan sớm trong Planning Process Group để tránh "blind spots" như outsourcing ẩn! 🚀

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

Câu hỏi này thuộc chủ đề quản lý rủi ro trong môi trường Agile theo chuẩn PMP (Project Management Professional). 📘

• Tình huống: Một Project Manager (PM) đang dẫn dắt một đội ngũ mới làm quen với Agile. Trong buổi kickoff meeting (họp khởi động dự án), một thành viên đội hỏi về cách quản lý rủi ro (risks) sử dụng các phương pháp Agile.
• Mục tiêu: PM cần trả lời chính xác, phù hợp với nguyên tắc Agile, nhấn mạnh sự khác biệt so với cách tiếp cận truyền thống (Waterfall). Trong Agile (theo PMBOK® Guide – 7th Edition và Agile Practice Guide – PMI, cập nhật đến 2026), quản lý rủi ro không phải là hoạt động một lần mà là liên tục, hợp tác và tích hợp vào từng iteration/sprint. 🛠️
• Ý nghĩa: Câu hỏi kiểm tra sự hiểu biết về tính iterative và collaborative của Agile, nơi rủi ro được xác định, đánh giá và xử lý hàng ngày (daily stand-up), trong planning, review và retrospective.

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

Đáp án đúng: Risk management is a collaborative effort and will be managed during each iteration.
Lý do:

• Trong Agile, quản lý rủi ro là nỗ lực hợp tác (collaborative) của toàn đội, không phải trách nhiệm riêng của PM. 🧑‍🤝‍🧑
• Rủi ro được quản lý liên tục trong từng iteration/sprint (qua daily stand-up, sprint planning, backlog refinement), giúp phát hiện sớm và điều chỉnh nhanh. Điều này phù hợp với 12 nguyên tắc Agile Manifesto (nguyên tắc 6: "The most efficient method of conveying information is face-to-face conversation") và PMBOK® 7th Edition (Principle 5: Team).
• Trả lời này khuyến khích đội ngũ mới, xây dựng văn hóa Agile ngay từ kickoff.

Nguồn tham khảo:

• 📘 PMBOK® Guide – 7th Edition (2021, cập nhật 2026): Section 4.5 (Uncertainty Management), Agile Hybrid Approaches.
• 📘 Agile Practice Guide – PMI (2017, tích hợp PMBOK 7): Chapter 5.3 (Risk Management in Agile).
• PMI.org: "Implementing Agile: Risk Management" (2023 updates).

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

Dưới đây là phân tích chi tiết từng lựa chọn giữ nguyên văn bản gốc bằng tiếng Anh, kèm giải thích bằng tiếng Việt tại sao đúng/sai. Sử dụng kiến thức PMP Agile mới nhất (tập trung vào iterative, empirical process control).

• Risk management is a collaborative effort and will be managed during each iteration.
  ✅ Đúng vì: Đây là mô tả chính xác nhất về Agile. Quản lý rủi ro là hợp tác toàn đội, diễn ra liên tục qua từng iteration (sprint planning, daily scrum, backlog grooming). Không có giai đoạn riêng biệt, giúp giảm thiểu rủi ro empiric (dựa trên feedback thực tế). Phù hợp Scrum Guide 2020 (cập nhật 2025) và PMBOK 7.

• Risks are managed by the project manager and forecasted at the beginning of each project.
  ❌ Sai vì: Agile không giao trách nhiệm quản lý rủi ro chỉ cho PM (đội tự quản - self-organizing), và không forecast toàn bộ ở đầu dự án (đây là đặc trưng Waterfall). Agile dùng empirical approach (inspect-adapt), rủi ro được cập nhật động. Vi phạm Agile Principle 11 (self-organizing teams).

• Risks will be managed during a retrospective session with all of the team members.
  ❌ Sai vì: Retrospective (họp cuối sprint) chỉ phân tích rủi ro quá khứ để cải thiện (lessons learned), không phải nơi quản lý rủi ro chính. Quản lý rủi ro diễn ra toàn bộ iteration, không giới hạn ở retrospective. Theo Scrum Guide: Retrospective là cho process improvement, không phải risk handling.

• Risks are managed by the team and they will be analyzed during risk management kickoff.
  ❌ Sai vì: Agile không có "risk management kickoff" riêng biệt (khác Waterfall với risk register ban đầu). Đội quản lý rủi ro đúng, nhưng phân tích liên tục qua iteration, không phải kickoff một lần. Điều này tạo ảo tưởng về hoạt động tĩnh, trái với Agile Practice Guide (ongoing risk identification).

Kết luận tổng quát 🎯: Câu hỏi nhấn mạnh sự chuyển đổi sang Agile mindset – hợp tác và iterative thay vì kế hoạch cứng nhắc. PM nên dùng câu trả lời đúng để giáo dục đội ngũ ngay từ đầu! Nếu cần ví dụ thực tế hoặc quiz thêm, hãy hỏi nhé. 🚀

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

Câu hỏi mô tả tình huống một Project Manager (PM) đang dẫn dắt một dự án IT ảo (virtual IT project) với đội ngũ làm việc từ xa (remote team). Một thành viên đội ngũ thông báo với PM rằng họ không chắc có thể hoàn thành đúng hạn (finish on time) vì không nắm được tiến độ của các thành viên khác (unaware of the other team members’ progress).

📌 Vấn đề cốt lõi: Đây là rào cản giao tiếp (communication barrier) điển hình trong môi trường làm việc từ xa, dẫn đến thiếu tầm nhìn chung (visibility) về tiến độ công việc. Theo PMBOK Guide 7th Edition (2021) và cập nhật đến 2024-2026 (bao gồm PMI Agile Practice Guide), PM cần ưu tiên quản lý giao tiếp (Manage Communications - Process 10.1) và quản lý đội ngũ (Manage Team - Process 9.5) để tăng cường sự minh bạch, đặc biệt trong virtual teams nơi công cụ số và họp định kỳ là chìa khóa. Mục tiêu là giải quyết "conflict" (thực chất là vấn đề phối hợp) bằng cách cải thiện sự phối hợp toàn đội (team-wide collaboration).

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

Đáp án đúng: Host weekly meetings with the entire team to improve communication.

Lý do: 🛠️ Phương án này trực tiếp giải quyết vấn đề thiếu thông tin tiến độ bằng cách tổ chức họp toàn đội hàng tuần, giúp mọi thành viên cập nhật tiến độ lẫn nhau (status updates), tăng sự gắn kết và minh bạch (transparency). Điều này phù hợp với best practices cho virtual teams trong PMBOK 7th (Section 9.5.2.3: Virtual Teams) và PMI's Pulse of the Profession 2023-2025 reports, nhấn mạnh regular team meetings để giảm rủi ro chậm trễ. Nó hiệu quả, tiết kiệm thời gian so với họp cá nhân, và hỗ trợ hybrid/agile approaches như sprint reviews hoặc stand-ups mở rộng.

📋 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. Tôi đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích bằng tiếng Việt dựa trên PMBOK 7th Edition và PMP Exam Content Outline 2021 (cập nhật 2026).

• ✅ [ĐÚNG] Host weekly meetings with the entire team to improve communication.
  🏆 Như đã giải thích ở trên, đây là giải pháp tối ưu vì tạo kênh giao tiếp đa hướng (multi-way communication), giúp toàn đội chia sẻ tiến độ thời gian thực, giảm hiểu lầm và tăng động lực. Nguồn: PMBOK 7th Ed., 10.1.2.1 (Communication Methods: Interactive) & Agile Practice Guide (Daily/Weekly Stand-ups).

• ❌ [SAI] Communicate by email with each team member to assign the tasks.
  📧 Phương án này không giải quyết gốc rễ vì email là giao tiếp một chiều (push communication), chỉ dùng để giao nhiệm vụ mới chứ không cung cấp tầm nhìn tiến độ của người khác. Nó còn làm tăng sự phân mảnh thông tin (information silos) trong remote teams, trái với nguyên tắc Bi-Directional Communication (PMBOK 7th, 10.1.2.2). Hơn nữa, vấn đề không phải assign tasks mà là theo dõi progress.

• ❌ [SAI] Ask the team that is having the problem to follow the project plan.
  🚫 Đây là cách tiếp cận thụ động và thiếu hỗ trợ, không address vấn đề giao tiếp cốt lõi. Theo PMBOK 7th (Section 4.6: Manage Project Knowledge), PM phải chủ động can thiệp (facilitate) thay vì chỉ yêu cầu tuân thủ kế hoạch. Nó bỏ qua root cause analysis (như trong Manage Team), có thể dẫn đến lặp lại vấn đề và giảm team morale trong virtual environment.

• ❌ [SAI] Schedule weekly meetings with each team member.
  ⏰ Phương án này không hiệu quả về thời gian (1-on-1 meetings nhân với số thành viên = tốn kém), và không tạo visibility toàn đội vì mỗi người chỉ cập nhật riêng lẻ với PM, không trực tiếp với nhau. PMBOK 7th (9.5.2.3) khuyến nghị group meetings cho virtual teams để tăng collaboration, thay vì micromanagement kiểu này, vốn phù hợp hơn cho coaching cá nhân hóa chứ không phải giải quyết progress visibility.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, PMI): Các process 9.5 (Manage Team), 10.1 (Manage Communications).
• PMI Agile Practice Guide (2017, cập nhật 2024): Virtual Teams & Communication in Hybrid Environments.
• PMP Exam Content Outline (2021, hiệu lực đến 2026): Domain III: Business Environment (Communication) & Domain IV: People (Team Management).
• PMI Pulse of the Profession 2024: Báo cáo nhấn mạnh 70% dự án remote thất bại do giao tiếp kém → ưu tiên meetings định kỳ.

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 mô tả tình huống một project lead (người dẫn dắt dự án) đang quản lý một dự án xây dựng ở vị trí hẻo lánh (isolated location). Dự án gặp trì hoãn (delays) do điều kiện làm việc khó khăn, cụ thể bao gồm bệnh tật của đội ngũ (team sickness) và vắng mặt (absences). Mục tiêu là tìm cách quản lý các vấn đề này để đưa dự án trở lại đúng tiến độ (get the project back on track).

🛠️ Bối cảnh PMP: Đây là tình huống điển hình trong quản lý vấn đề (issue management) và giải quyết vấn đề (problem-solving) theo PMBOK Guide 7th Edition (2021) và cập nhật đến 2026. Project lead cần áp dụng nguyên tắc tối ưu hóa rủi ro (Optimize Risk Responses - Principle 5), quản lý thay đổi (Manage Project Changes), và phân tích nguyên nhân gốc rễ (root cause analysis) để tránh các giải pháp ngắn hạn gây hậu quả lâu dài. Không nên vội vàng thay đổi scope, ngân sách hay nhân sự mà không hiểu rõ nguyên nhân.

✅ Đáp án đúng

Identify the causes of the issues in order to find a suitable solution.

Lý do lựa chọn:

• Đây là bước đầu tiên và đúng đắn nhất trong quy trình giải quyết vấn đề theo PMP. Việc xác định nguyên nhân (identify causes) giúp áp dụng phân tích nguyên nhân gốc rễ (root cause analysis) như Ishikawa Diagram hoặc 5 Whys, từ đó tìm giải pháp phù hợp (suitable solution) bền vững.
• Trong dự án xây dựng hẻo lánh, vấn đề có thể do môi trường (khí hậu, dinh dưỡng kém) chứ không chỉ cá nhân, nên giải pháp như cải thiện điều kiện làm việc sẽ hiệu quả hơn thay thế nhân sự.
• Điều này phù hợp với Hybrid/Agile approaches trong PMBOK 7, nhấn mạnh iteration và adaptation để đưa dự án back on track mà không vi phạm Triple Constraint (Scope-Time-Cost).

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

• Ask for additional budget because the project end will be delayed.
  ❌ Sai: Phương án này chấp nhận trì hoãn mà không phân tích, chỉ yêu cầu thêm ngân sách (additional budget) để bù đắp, vi phạm nguyên tắc giá trị tối ưu (Deliver Value - Principle 2). Trong PMP, phải kiểm soát chi phí (Control Costs process) và chỉ xin thay đổi baseline sau khi có dữ liệu rõ ràng, tránh "scope creep" hoặc lãng phí.

• Identify the causes of the issues in order to find a suitable solution.
  ✅ Đúng: Như đã giải thích ở trên, đây là root cause analysis cốt lõi trong Manage Quality và Monitor Risks processes. Giúp tìm giải pháp targeted, tiết kiệm chi phí và thời gian, phù hợp với PMBOK 7 Value Delivery System.

• Review the project scope in order to simplify it and shorten project duration.
  ❌ Sai: Thay đổi scope (review and simplify) là integrated change control chỉ áp dụng khi vấn đề liên quan trực tiếp đến scope, không phải do điều kiện bên ngoài như bệnh tật. Điều này có thể làm giảm giá trị dự án (gold plating ngược), vi phạm Stakeholder Engagement Principle (Principle 13) và cần phê duyệt Change Control Board (CCB).

• Ask human resources (HR) to find individuals to replace team members.
  ❌ Sai: Thay thế nhân sự ngay lập tức bỏ qua Acquire Resources và Develop Team processes. Ở vị trí hẻo lánh, việc tuyển mới khó khăn, tốn kém (onboarding, đào tạo), và có thể không giải quyết nguyên nhân gốc (ví dụ: điều kiện sức khỏe chung). PMP khuyến nghị manage team performance trước khi thay thế.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021, PMI): Principles 2 (Deliver Value), 5 (Optimize Risk), Section 4.5 (Problem Solving), và Domain 5: Uncertainty.
• PMBOK® Guide 6th Edition (cập nhật Hybrid): Processes 9.4 (Control Procurements), 11.7 (Control Resources), nhấn mạnh root cause trước action.
• PMI Agile Practice Guide (2021): Iteration planning và daily stand-ups để identify issues sớm.
• Cập nhật 2026: The Standard for Project Management (2025 draft) tiếp tục nhấn mạnh outcome-based risk management thay vì reactive fixes.

🛠️ Lời khuyên PMP: Luôn bắt đầu bằng data-driven decisions để tránh escalation không cần thiết! Nếu cần công cụ, dùng Issue Log để track và resolve.

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

Câu hỏi mô tả tình huống một Project Manager (PM) đang ở giai đoạn Initiating (Khởi tạo dự án) cho một dự án phát triển dịch vụ hoàn toàn mới, chưa từng thực hiện trong tổ chức. PM gặp khó khăn trong việc xác định tài nguyên cần thiết cho đội ngũ dự án vì có xung đột yêu cầu tài nguyên từ các bên: team dự án, sponsor, và key stakeholders. Câu hỏi yêu cầu xác định hành động tiếp theo mà PM nên thực hiện.

🛠️ Bối cảnh PMP (theo PMBOK® Guide 7th Edition - cập nhật đến 2026): Trong quy trình 1.2 Develop Project Charter và 9.1 Plan Resource Management, đặc biệt với dự án sáng tạo/highly uncertain (dự án mới lạ), PM cần thu thập thông tin chính xác từ chuyên gia để giải quyết xung đột và xây dựng baseline tài nguyên. Không nên vội quyết định mà phải ưu tiên expert judgment để đảm bảo tính khả thi.

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

Đáp án đúng: Determine if there is a subject matter expert (SME) who has expertise in the new service to assist with resource requirements.

Lý do: 📘 Trong PMBOK® 7th Edition (Section 4.1 Develop Project Charter & Tool: Expert Judgment - trang 77), với dự án mới chưa từng làm, PM phải sử dụng Subject Matter Expert (SME) để hỗ trợ xác định yêu cầu tài nguyên chính xác, giải quyết xung đột từ các bên. Đây là bước tiếp theo logic ở giai đoạn Initiating, giúp xây dựng Project Charter vững chắc trước khi tiến hành planning chi tiết. Hành động này tuân thủ nguyên tắc Value Delivery System và Uncertainty Management (PMBOK 7th, Principle 5: Optimize Resource Allocation).

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

Dưới đây là phân tích chi tiết từng lựa chọn. Tôi giữ nguyên nội dung văn bản gốc bằng tiếng Anh, chỉ giải thích lý do đúng/sai bằng tiếng Việt để đảm bảo tính chính xác PMP:

• ❌ [SAI] Identify the resources that are agreed upon to initiate the project and request additional resources later.
  🧨 Phương án này không phù hợp vì bỏ qua xung đột cốt lõi, chỉ dùng phần "đồng thuận" để khởi động dự án, dẫn đến rủi ro thiếu tài nguyên từ đầu. PMBOK 7th (Section 9.2 Estimate Activity Resources) nhấn mạnh phải giải quyết đầy đủ yêu cầu trước khi initiate, tránh "scope creep" sau này. Đây là cách tiếp cận rủi ro cao, không phải bước tiếp theo.

• ✅ [ĐÚNG] Determine if there is a subject matter expert (SME) who has expertise in the new service to assist with resource requirements.
  🏆 Như đã giải thích ở trên, đây là hành động tối ưu sử dụng Expert Judgment (PMBOK 7th, Tool & Technique phổ biến ở Initiating). Với dịch vụ mới, SME giúp làm rõ requirements, hòa giải xung đột, đảm bảo charter khả thi. PMI khuyến nghị trong Process Groups: Initiating (PMI.org/PMP Exam Content Outline 2021+).

• ❌ [SAI] Evaluate and prioritize the resource requests from the project's key stakeholders.
  🚫 Phương án này quá sớm và chủ quan, vì PM chưa có dữ liệu chuyên sâu để đánh giá/ưu tiên (chỉ dựa vào requests xung đột). PMBOK 7th (Section 13.1 Identify Risks) yêu cầu data gathering từ SME trước khi prioritize. Làm vậy có thể thiên vị, vi phạm Stakeholder Engagement (Principle 10).

• ❌ [SAI] Evaluate the resource options and propose alternatives to the project team for their approval.
  ⚠️ Sai vì team chưa phải là bên phê duyệt chính ở Initiating (thuộc sponsor/stakeholders). Hơn nữa, evaluate options cần dữ liệu đầy đủ từ SME trước (PMBOK 7th, Section 9.3 Acquire Resources). Đề xuất alternatives lúc này có thể làm phức tạp hóa charter mà không giải quyết gốc rễ xung đột.

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, cập nhật PMI 2024-2026): Sections 1.2, 4.1, 9.1; Tools: Expert Judgment (trang 50-77).
• PMI Exam Content Outline (ECO) 2021+: Domain I: People (18%) & II: Process (50%) – Tập trung Initiating & Resource Management.
• PMI.org: Agile Practice Guide (cho dự án mới lạ, nhấn mạnh SME trong Uncertainty).
• Tham khảo thêm: Rita Mulcahy PMP Exam Prep (11th Ed.) – Chương 1 & 9 về Initiating conflicts.

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