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

🧩 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ý các bên liên quan (Stakeholder Management) trong PMP, cụ thể là tình huống xử lý yêu cầu từ project sponsor (nhà tài trợ dự án) – một bên liên quan cấp cao.

• Tình huống: Nhà tài trợ yêu cầu technical specifications (thông số kỹ thuật) cho một thành phần liên quan đến dự án. Tuy nhiên, sponsor không có quyền truy cập (authorization) vào thông tin này, nhưng vẫn khăng khăng đòi xem (insists on seeing them).
• Vấn đề cốt lõi: PM phải cân bằng giữa việc duy trì mối quan hệ tốt với sponsor (stakeholder quan trọng), tuân thủ quy định bảo mật/an ninh thông tin, và xử lý vấn đề một cách chuyên nghiệp. Đây là tình huống escalation tiềm ẩn nếu không xử lý kịp thời.
• Yêu cầu hành động đầu tiên (first): Nhấn mạnh vào hành động proactive, giao tiếp trực tiếp để tránh rủi ro như vi phạm chính sách, mất lòng tin, hoặc delay dự án.

Câu hỏi kiểm tra kiến thức PMP về quy trình Manage Stakeholder Engagement (PMBOK 7th Edition), nơi ưu tiên giao tiếp sớm và trực tiếp với stakeholder để quản lý kỳ vọng (manage expectations) và giải quyết issue.

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

• PMBOK® Guide 7th Edition: Domain 9 - Stakeholder (Section 4.6 Manage Stakeholder Engagement).
• PMP Exam Content Outline 2021 (cập nhật đến 2026): Task 13.2 (Engage stakeholders).

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

Đáp án đúng: Meet with the project sponsor as soon as possible to discuss the matter further.

Lý do 🛠️:

• Theo nguyên tắc PMP, hành động đầu tiên phải là giao tiếp trực tiếp và kịp thời với stakeholder cấp cao như sponsor để hiểu rõ nhu cầu, giải thích lý do từ chối, và đề xuất giải pháp thay thế (ví dụ: thông tin tóm tắt hoặc escalate lên cấp cao hơn). Điều này giúp quản lý kỳ vọng (manage expectations), tránh escalation không cần thiết, và duy trì mối quan hệ.
• PMBOK 7th nhấn mạnh "Engage stakeholders early and often" – gặp ngay lập tức là bước proactive nhất, phù hợp với Agile/Adaptive approach nếu dự án linh hoạt.
• Không cung cấp thông tin nhạy cảm trước khi thảo luận, tránh rủi ro pháp lý hoặc bảo mật.

🧩 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 văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên best practice PMP (PMBOK 7th Edition).

• ❌ Provide the specifications to the project sponsor with some information removed.
  Sai vì: Việc cung cấp thông tin (dù đã chỉnh sửa) vi phạm nguyên tắc bảo mật và authorization policy. PM không được tự ý "remove some information" vì có thể vẫn lộ thông tin nhạy cảm, dẫn đến rủi ro pháp lý hoặc mất uy tín. PMP yêu cầu tuân thủ governance trước khi chia sẻ, không phải "cắt xén" để chiều lòng sponsor.

• ❌ Update the issue log to make the project team aware and to develop a strategy.
  Sai vì: Update issue log là bước sau khi đã identify và discuss issue, không phải hành động đầu tiên. Issue log dùng để track, nhưng gặp sponsor trực tiếp mới là first response để giải quyết nhanh. Làm vậy có thể làm sponsor cảm thấy bị "bỏ qua", tăng tension không cần thiết.

• ❌ Create a stakeholder engagement plan to help the team formulate a response.
  Sai vì: Stakeholder engagement plan là planning process (thuộc Plan Stakeholder Engagement), không phải hành động first trong tình huống real-time. Plan này đã tồn tại từ đầu dự án; tạo mới sẽ delay response, không phù hợp với "as soon as possible". PMP ưu tiên execute engagement trước planning bổ sung.

• ✅ Meet with the project sponsor as soon as possible to discuss the matter further.
  Đúng vì: Như đã giải thích ở trên, đây là hành động đầu tiên lý tưởng – direct communication để clarify, negotiate, và resolve. Phù hợp 12 Principles of PMBOK 7th (Focus on Value, Engage Stakeholders), giúp de-escalate issue hiệu quả.

📘 Lời khuyên học PMP

• Key takeaway: Trong stakeholder issues, ALWAYS communicate first! Áp dụng Situational Leadership tùy theo power/influence của sponsor.
• Thực hành với PMP mocks từ Rita Mulcahy hoặc PMI official practice exams để quen pattern "first action".

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

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

Câu hỏi tập trung vào quản lý stakeholder trong dự án Agile, cụ thể là một stakeholder quan trọng (key stakeholder) đang bực tức vì thiếu minh bạch (transparency) trong các dự án IT trước đây. Họ từ chối lời mời tham gia họp dự án mới. Vai trò của Agile Project Manager là hành động gì để thu hút (engage) stakeholder này vào dự án?

📘 Bối cảnh PMP/Agile (theo PMBOK 7th Edition & Agile Practice Guide 2021, cập nhật đến 2026): Trong Agile, Stakeholder Engagement là nguyên tắc cốt lõi (Principle 11: Focus on Value; Principle 12: Optimize Rather Than Satisfy). Minh bạch (Transparency) là một trụ cột của Agile Manifesto và Scrum (Scrum Guide 2020). Agile PM cần xây dựng lòng tin qua delivery commitments, demo sessions (Sprint Review) để thu thập feedback và điều chỉnh mục tiêu, thay vì ép buộc tham gia ngay.

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

Đáp án đúng: Build trust with the stakeholder by keeping project commitments and use demo sessions to gather feedback and realign goals.

Lý do 🛠️:

• Phương án này phù hợp nhất với Agile vì xây dựng lòng tin (build trust) qua giữ cam kết dự án (keeping commitments) – đảm bảo transparency và predictability.
• Demo sessions (tương đương Sprint Review) cho phép stakeholder thấy sản phẩm thực tế, thu thập feedback, và realign goals – thúc đẩy inspect & adapt (kiểm tra và thích ứng).
• Giải quyết trực tiếp frustration về transparency bằng hành động thực tế, không ép buộc họp.
• Nguồn: Agile Practice Guide (PMI, 2021) phần 4.2 Stakeholder Engagement; PMBOK 7th Ed. Domain 3: Business Environment, Principle 5: Stakeholder Collaboration.

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

• ❌ [SAI] Introduce the stakeholder to the project team and invite them to the next iteration review meeting with the IT team.
  Giải thích: Phương án này chỉ giới thiệu và mời lại (invite lại), không giải quyết gốc rễ frustration về transparency. Stakeholder đã từ chối lời mời trước, nên hành động này mang tính ép buộc thụ động, không xây dựng lòng tin. Trong Agile, không nên "kéo" stakeholder mà cần thu hút qua giá trị thực (value demonstration). Không phải bước đầu tiên ưu tiên.

• ❌ [SAI] Use stakeholder mapping to document the level of influence and interest for the next iteration planning meeting.
  Giải thích: Stakeholder mapping là công cụ phân tích (analysis tool) trong Identify Stakeholders process (PMBOK 7th, Process 13.1), dùng để document influence/interest. Tuy nhiên, đây là hành động hậu thuẫn nội bộ, không trực tiếp engage stakeholder. Không giải quyết frustration ngay, chỉ lập kế hoạch cho iteration planning – thiếu tính tương tác Agile.

• ❌ [SAI] Present the project management plan to the stakeholder and reassure them that they will receive regular project updates.
  Giải thích: Phương án này theo cách truyền thống (predictive), trình bày project management plan và hứa hẹn updates – không phù hợp Agile (Agile ưu tiên working software over documentation). "Reassure" chỉ là lời nói suông, không build trust thực tế hay minh bạch. Trong Agile, stakeholder cần thấy demo thực tế, không phải plan giấy tờ.

• ✅ [ĐÚNG] Build trust with the stakeholder by keeping project commitments and use demo sessions to gather feedback and realign goals.
  Giải thích: Như đã nêu ở trên, đây là hành động Agile thuần túy: Giữ commitments → transparency; Demo sessions → feedback loop và alignment. Hoàn hảo cho key stakeholder frustrated, thúc đẩy engagement tự nhiên.

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

• PMBOK® Guide 7th Edition (PMI, 2021) – People Domain & Stakeholder Sphere.
• Agile Practice Guide (PMI, 2021) – Chapters 3 & 4.
• Scrum Guide (2020, cập nhật 2023) – Sprint Review events. (Kiến thức cập nhật đến 2026 không thay đổi core principles này theo PMI standards mới nhất).

Hy vọng phân tích giúp bạn ôn PMP hiệu quả! 🚀

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

📖 Nội dung câu hỏi:
Câu hỏi mô tả tình huống một Project Manager (PM) được giao dẫn dắt một dự án hybrid innovation (dự án kết hợp giữa phương pháp dự đoán - predictive và linh hoạt - agile, tập trung vào sáng tạo đổi mới). Trong cuộc họp với sponsor (nhà tài trợ) và các bên liên quan chính (major stakeholders), PM nhận ra rằng yêu cầu (requirements) chưa rõ ràng. Câu hỏi yêu cầu PM nên làm gì trong tình huống này.

🛠️ Bối cảnh PMP liên quan: Theo PMBOK® Guide 7th Edition và Agile Practice Guide (cập nhật mới nhất đến 2026), trong dự án hybrid innovation, requirements thường không cố định từ đầu mà cần được phát triển dần qua vision và collaboration. PM phải chủ động hỗ trợ làm rõ product vision để định hướng dự án, tránh lãng phí thời gian và tài nguyên. Đây thuộc Process Group: Initiating và principle: Stewardship, Team, Stakeholders trong Standard for Project Management (SPM).

✅ Đáp án đúng:
Help the sponsor and major stakeholders to craft the product vision.

📘 Lý do lựa chọn (theo PMP mới nhất):
Trong dự án hybrid innovation, requirements mơ hồ là phổ biến vì tính sáng tạo cao. PM không nên chờ thụ động mà phải chủ động hỗ trợ sponsor và stakeholders xây dựng product vision – đây là nền tảng để làm rõ requirements sau này. Theo Agile Practice Guide (PMBOK 7th), product vision giúp align kỳ vọng, tạo shared understanding và hướng dẫn backlog refinement. PM đóng vai trò facilitator, thúc đẩy collaboration ngay từ Initiating phase (Domain: People & Business Environment). Điều này phù hợp PMP Exam Content Outline 2021+ (cập nhật 2026), nhấn mạnh leadership trong hybrid contexts.

Nguồn tham khảo: PMBOK® Guide 7th Edition (Section 4.1 & Agile Hybrid), Agile Practice Guide (Chapter 2: Life Cycle Selection), PMI.org/PMP-EC-O.

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

✅ Help the sponsor and major stakeholders to craft the product vision.

• Đúng vì: Như đã giải thích, đây là hành động chủ động, phù hợp hybrid innovation. PM giúp tạo vision chung, dẫn đến elicitation requirements hiệu quả. ✅

❌ [SAI] Request that the sponsor meet with the product owner to address the issue.

• Sai vì: PM đang ở họp với sponsor/stakeholders, không nên đẩy trách nhiệm cho sponsor gặp product owner (có thể chưa tồn tại rõ ràng ở hybrid). PM phải facilitate trực tiếp thay vì delegate, vi phạm nguyên tắc leadership & collaboration (PMBOK 7th, Principle: Team). ❌

❌ [SAI] Add this to the risk register and monitor the risk until this becomes an issue.

• Sai vì: Unclear requirements là issue hiện tại (không phải risk tương lai), cần giải quyết ngay ở Initiating, không "monitor until becomes issue". Risk register dùng cho uncertainty tương lai (PMBOK 7th, Domain: Uncertainty). Hành động này thụ động, dẫn đến scope creep. ❌

❌ [SAI] Review lessons learned to see how sponsors deal with issues about unclear requirements.

• Sai vì: Lessons learned dùng cho closing/review sau dự án, không phải hành động khẩn cấp ở họp initiating. PM cần hành động hiện tại thay vì tra cứu lịch sử, bỏ lỡ cơ hội collaboration (SPM Principle: Learning). ❌

💡 Kết luận & Lời khuyên PMP: Hành động đúng nhấn mạnh vai trò PM là enabler trong hybrid projects. Thực hành qua progressive elaboration để refine vision thành requirements! 📘

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

Câu hỏi này thuộc chủ đề Quản lý Đội ngũ (Manage Team) trong PMP, đặc biệt trong ngữ cảnh dự án Agile/Scrum (với các thuật ngữ như "iterations", "daily standup meeting", "sprint review"). Tình huống mô tả: Một thành viên đội ngũ có hiệu suất thấp trong hai iterations gần nhất. Project Manager (PM) đã thực hiện hai buổi feedback trực tiếp với thành viên đó, đồng thời escalate vấn đề lên resource manager và project sponsor, nhưng không có sự cải thiện. Câu hỏi yêu cầu xác định hành động tiếp theo của PM để giải quyết vấn đề hiệu suất đội ngũ.

Mục tiêu chính là áp dụng nguyên tắc quản lý xung đột và hiệu suất đội ngũ theo PMBOK® Guide 7th Edition (2021) và Agile Practice Guide (cập nhật đến 2026, không thay đổi lớn ở phiên bản mới). Trong Agile, PM ưu tiên giải quyết vấn đề nhanh chóng để bảo vệ tiến độ sprint/iteration, sau khi đã thử các bước coaching và escalate cơ bản. 📘 Nguồn tham khảo: PMBOK® Guide 7th Ed., Principle 9: Team & Stakeholders; Process 4.6 Manage Project Team; Agile Practice Guide, Section 5.3 Servant Leadership & Team Performance.

✅ Đáp án đúng: Request a new resource to execute the activities.

Lý do lựa chọn:
Sau khi đã thực hiện đầy đủ các bước ban đầu (hai buổi feedback cá nhân hóa và escalate lên resource manager/sponsor), nhưng hiệu suất vẫn không cải thiện, PM cần thay thế tài nguyên để đảm bảo tiến độ dự án. Đây là bước escalation tiếp theo hợp lý trong quy trình quản lý đội ngũ Agile/PMP:

• Theo PMBOK® 7th, trong Manage Project Team, nếu coaching/feedback thất bại, PM có quyền request thay thế resource từ resource manager để giảm rủi ro dự án (Outcome: Optimized team performance).
• Trong Agile, Servant Leader (PM) bảo vệ đội ngũ bằng cách loại bỏ "obstacles" kéo dài, tránh ảnh hưởng đến velocity của iterations tiếp theo. 🛠️ Không chờ đợi thêm sẽ giúp duy trì flow và chất lượng sản phẩm.
  📘 Nguồn: PMBOK® 7th Ed., p. 128-130; Agile Practice Guide, p. 42-44 (Team Dynamics & Conflict Resolution).

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

• ✅ Request a new resource to execute the activities.
  Đúng 🏆: Như giải thích trên, đây là hành động chủ động và kịp thời sau khi các biện pháp coaching/escalate ban đầu thất bại. Giúp PM kiểm soát rủi ro đội ngũ, đảm bảo deliverables của iterations tiếp theo. Không làm vậy sẽ vi phạm nguyên tắc "Deliver Value" trong Agile.

• ❌ Review this obstacle during the daily standup meeting.
  Sai 🚫: Daily standup là họp ngắn (15 phút) để chia sẻ tiến độ cá nhân, blockers nhanh, không phải nơi thảo luận sâu vấn đề hiệu suất cá nhân. Việc review công khai có thể gây mất động lực đội ngũ (team morale), vi phạm nguyên tắc "Psychological Safety" trong Agile. Nên xử lý riêng tư trước (đã làm feedback rồi).

• ❌ Escalate the situation again to the project sponsor.
  Sai 🔄: PM đã escalate một lần đến sponsor và resource manager, lặp lại sẽ lãng phí thời gian mà không mang lại giá trị mới (no new info). PMP khuyến khích escalate có cấp độ (escalation matrix), ưu tiên hành động nội bộ như thay resource trước khi quay lại sponsor.

• ❌ Provide feedback to the resource at the sprint review.
  Sai ⏳: Sprint review là họp demo sản phẩm với stakeholders, tập trung vào "What went well/What to improve" ở mức đội ngũ/dự án, không phải feedback cá nhân. Làm vậy sẽ công khai vấn đề, ảnh hưởng đến retrospectives riêng và vi phạm "private coaching" trong Agile (feedback cá nhân nên ở 1:1 hoặc retrospective nội bộ).

🛡️ Lời khuyên PMP thực tiễn

Sử dụng RACI matrix để phân quyền thay resource, và ghi log vào Issue Log hoặc Team Performance Report. Trong phiên bản PMP 2021+, nhấn mạnh hybrid Agile – hành động này phù hợp cả predictive và adaptive. Nếu áp dụng, dự án sẽ tăng velocity ngay iterations sau! 🚀

📘 Tài liệu tham khảo bổ sung: PMI.org PMP Exam Content Outline 2021 (Domain IV: People, Task 7); Scrum Guide 2020 (Developer Accountability).

🧩 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) mới được giao quản lý một dự án đang ở giai đoạn Execution (Thực thi), gặp phải các roadblocks (rào cản) gây chậm trễ. Trong quá trình xem xét processes and procedures (quy trình và thủ tục), PM nhận thấy sự tương đồng với một dự án trước đó cũng gặp vấn đề tương tự. Kiểm tra task schedule (lịch trình nhiệm vụ) cho thấy một số nhiệm vụ chậm xa so với kỳ vọng. Khi trao đổi với project team (đội ngũ dự án), PM xác nhận rằng đội ngũ đang tuân thủ chính xác các quy trình.

Ý chính của câu hỏi: Vấn đề không nằm ở đội ngũ (họ làm đúng quy trình) hay lịch trình/schedule (chỉ là triệu chứng), mà có thể ở chính quy trình đang chứa các hoạt động không mang lại giá trị (non-value-adding activities). PM cần hành động root cause analysis (phân tích nguyên nhân gốc rễ) để cải thiện, phù hợp với nguyên tắc Value Delivery và Tailoring trong PMP mới nhất (PMBOK® Guide 7th Edition & PMP Exam Content Outline 2021, cập nhật đến 2026).

📘 Nguồn tham khảo:

• PMBOK® Guide – Seventh Edition (PMI, 2021), Principle 4: Optimize Value Delivery & Domain: Process.
• Agile Practice Guide (PMI), phần Lean Thinking: Eliminate Waste.

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

Đáp án đúng: Review and amend the processes to ensure only value-adding activities are present.

Lý do: 🛠️ Trong giai đoạn Execution, khi team tuân thủ đúng quy trình nhưng vẫn gặp roadblocks giống dự án trước (dấu hiệu của systemic issue - vấn đề hệ thống), PM phải review và amend processes (xem xét và sửa đổi quy trình) để loại bỏ waste (hoạt động lãng phí), chỉ giữ value-adding activities (hoạt động tạo giá trị). Đây là ứng dụng Lean principles và Tailoring (tùy chỉnh quy trình phù hợp dự án), giúp tối ưu hóa flow of value (luồng giá trị). Không fix quy trình thì vấn đề sẽ lặp lại, phù hợp PMP 2021+ nhấn mạnh holistic value delivery thay vì chỉ quản lý symptoms.

🧩 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, với ✅ đúng hoặc ❌ sai, dựa trên best practices PMP:

• ✅ Review and amend the processes to ensure only value-adding activities are present.
  🛠️ Đúng vì: Đây là hành động root cause-focused (tập trung nguyên nhân gốc). Team làm đúng quy trình nhưng chậm → quy trình có waste (non-value activities như redundant steps). Amend processes theo Kaizen/Continuous Improvement (PMBOK 7th, Principle 9: Optimize Flow) sẽ giải quyết triệt để, tránh lặp lại từ dự án cũ. PMP khuyến khích Tailor processes ở Execution để deliver value nhanh hơn.

• ❌ Review the resources allocated to the project and change accordingly.
  🚫 Sai vì: Không có bằng chứng thiếu resources (team đang follow processes exactly, chỉ chậm do roadblocks hệ thống). Thay resources chỉ là band-aid solution (giải pháp tạm bợ), không giải quyết root cause từ processes giống dự án trước. PMP ưu tiên analyze processes trước resources (Domain: Team & Uncertainty).

• ❌ Update the schedule to account for the unexpected delays in the project tasks.
  ⏰ Sai vì: Chỉ accept delays (chấp nhận chậm trễ) mà không fix cause, vi phạm Schedule Performance Index (SPI) và Earned Value Management (EVM). Đây là reactive measure (phản ứng) thay vì proactive tailoring. PMBOK 7th nhấn mạnh forecast & prevent thay vì update schedule làm baseline mới mà không cải thiện.

• ❌ Update the variation register to account for the extended project time.
  📋 Sai vì: Variation register (hay Change Register) dùng cho approved changes (thay đổi được phê duyệt) như scope/approved variations, không phải delays thông thường. Delays do processes không phải "variation" hợp lệ; update chỉ ghi nhận symptoms, không giải quyết roadblocks. Theo Integrated Change Control (PMBOK 6/7), phải analyze cause trước khi log.

Kết luận tổng quát 🎯: Câu hỏi kiểm tra Strategic Mindset của PM trong PMP mới (2021+), ưu tiên optimize processes để maximize value thay vì fix symptoms. Học viên PMP nên nhớ 12 Principles & 8 Domains để xử lý tình huống thực tế!

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

Câu hỏi này thuộc chủ đề Quản lý đội ngũ và Áp dụng Agile trong dự án theo PMP (Project Management Professional), dựa trên PMBOK Guide 7th Edition và Agile Practice Guide (cập nhật đến 2026).

📖 Tình huống mô tả: Một project manager (PM) mới đang khởi xướng dự án (initiating phase). Họ nhận thấy đội ngũ rất cứng nhắc (rigid), không muốn thay đổi, và liên tục khẳng định rằng họ đã chạy dự án thành công theo cách truyền thống trong nhiều năm. PM đánh giá rằng dự án sẽ gặp rủi ro cao nếu đội ngũ không áp dụng phương pháp Agile. Câu hỏi yêu cầu PM nên làm gì đầu tiên để giải quyết vấn đề này, nhấn mạnh vào kỹ năng lãnh đạo, giao tiếp và thúc đẩy sự thay đổi văn hóa đội ngũ hướng tới Agile.

🛠️ Mục tiêu chính: Kiểm tra khả năng của PM trong việc xử lý kháng cự thay đổi (resistance to change), xây dựng sự đồng thuận (buy-in) từ đội ngũ, và áp dụng nguyên tắc Servant Leadership (lãnh đạo phục vụ) – một yếu tố cốt lõi trong Agile. Không phải lúc nào cũng ép buộc từ trên xuống (top-down), mà cần engage trực tiếp với đội ngũ để giảm rủi ro dự án.

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

Đáp án đúng: Engage with the team to explain the risks of using the old approach and gain support for the agile process.

Lý do chọn (theo PMP mới nhất):

• PM cần giao tiếp trực tiếp (engage) với đội ngũ để giải thích rủi ro cụ thể của cách tiếp cận cũ (waterfall/traditional) so với Agile, giúp đội ngũ hiểu lợi ích và tự nguyện ủng hộ (gain support). Đây là ứng dụng nguyên tắc Servant Leadership và Stakeholder Engagement trong PMBOK 7th (Principle 7: Optimize Risk Responses & Principle 10: Lead with Values).
• Trong Agile Practice Guide, việc thúc đẩy sự thay đổi văn hóa bắt đầu từ bottom-up engagement, không chờ đợi tự nhiên hay can thiệp từ sponsor. Điều này giảm kháng cự, tăng tốc độ áp dụng Agile và bảo vệ dự án khỏi rủi ro. ✅ Hành động chủ động, đúng vai trò PM.

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

Dưới đây là phân tích từng phương án một, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên 12 Principles và 8 Performance Domains của PMBOK 7th Edition, kết hợp Agile mindset.

• [SAI] Realize the team is in the forming stage and that, as the team moves toward the performing stage, it will become agile.
  ❌ Sai vì: Phương án này nhầm lẫn Tuckman's stages of team development (Forming-Storming-Norming-Performing) với việc tự động trở nên Agile. Tuckman mô tả sự phát triển đội ngũ chung, không đảm bảo họ sẽ áp dụng Agile mà không có can thiệp. Đội ngũ đang kháng cự thay đổi (rigid), không phải chỉ ở forming stage. Theo PMBOK 7th (Team Domain), PM phải chủ động coach và mentor để thúc đẩy Agile, chứ không thụ động chờ đợi. 🕒 Rủi ro: Dự án chậm trễ, thất bại.

• [SAI] Schedule a meeting with the project sponsor to request that management support the team's adoption of agile.
  ❌ Sai vì: Đây là cách tiếp cận top-down (từ trên xuống), bỏ qua vai trò lãnh đạo trực tiếp của PM với đội ngũ. Theo Agile Practice Guide (Section 3.2), PM nên engage đội ngũ trước để xây dựng buy-in nội bộ, thay vì phụ thuộc sponsor ngay lập tức. PMBOK 7th (Stakeholder Domain) khuyến nghị escalate chỉ khi cần, ở đây PM có quyền hành động trực tiếp. 📞 Rủi ro: Tăng kháng cự từ đội ngũ, mất thời gian.

• [SAI] Recognize the team is historically successful and decide to allow the team to continue as they have for years.
  ❌ Sai vì: Phương án này bỏ qua rủi ro dự án mà PM đã nhận diện. Dù đội ngũ thành công trước đây, dự án mới có thể yêu cầu Agile để thích ứng (hybrid/agile mindset). PMBOK 7th (Uncertainty Domain) yêu cầu tailor approach phù hợp, không "status quo". Agile Practice Guide nhấn mạnh continuous improvement, không giữ nguyên cách cũ. 🏆 Rủi ro: Dự án thất bại do không agile hóa.

• [ĐÚNG] Engage with the team to explain the risks of using the old approach and gain support for the agile process.
  ✅ Đúng vì: Như đã giải thích ở phần đáp án đúng. Đây là hành động tối ưu nhất, phù hợp Value Delivery System trong PMBOK 7th và Agile Manifesto Principle 6 (Face-to-face conversation). PM làm gương lãnh đạo, giải thích rủi ro để thuyết phục, dẫn đến sự ủng hộ tự nguyện. 🎯 Lợi ích: Giảm rủi ro nhanh chóng, tăng hiệu suất đội ngũ.

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

• PMBOK Guide 7th Edition (2021, vẫn là chuẩn chính): Principles 5 (Stakeholder), 7 (Risk), 11 (Team); Domains: Team, Uncertainty, Stakeholder.
• Agile Practice Guide (2nd Edition, 2021): Chapter 3 (Lifecycle Selection), Section 4 (Implementing Agile: Culture & Mindset).
• PMP Exam Content Outline (2024-2026): 50% Agile/Hybrid, People Domain (42% trọng số).
• PMI Standards: Servant Leadership & Change Management (PMI.org/resources).

🛡️ Lời khuyên PMP: Luôn tailor approach dựa trên ngữ cảnh dự án, ưu tiên giao tiếp để vượt qua kháng cự! Nếu cần luyện thi, tập trung Agile transition scenarios.

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

Câu hỏi này thuộc chủ đề quản lý mốc thời gian (milestone management) và tương tác với stakeholders trong dự án PMP. Tình huống: Khách hàng (customer) muốn hiển thị kết quả hữu hình (tangible outcome) cho các bên liên quan (stakeholders) nhanh hơn, bằng cách đẩy nhanh một mốc quan trọng (advancing a milestone). Project manager cần chọn hai hành động phù hợp nhất để xử lý yêu cầu này.

🛠️ Phân tích tình huống chi tiết:

• Mục tiêu của khách hàng: Tạo giá trị nhanh (faster value delivery), thường thấy trong môi trường Agile/Hybrid, nơi ưu tiên MVP (Minimum Viable Product) hoặc deliverables sớm để lấy feedback.
• Thách thức cho PM: Phải cân bằng lịch trình, yêu cầu, chi phí mà không làm gián đoạn dự án. PM cần hợp tác (collaborative) với customer và team, thay vì áp đặt hoặc né tránh.
• Ngữ cảnh PMP (PMBOK 7th Edition & 2021): Nhấn mạnh Stakeholder Engagement (Quy trình 13.3), Tailoring (tùy chỉnh cách tiếp cận), và Value Delivery qua việc ưu tiên requirements. Không nên dùng quyền lực (authority) mà ưu tiên empowered decision-making.

✅ Đáp án đúng (Chọn hai)

Hai hành động đúng là:

1. Review the customer’s priorities regarding the desired requirements for the milestones.
2. Discuss which requirements can be delivered faster with the project team.

Lý do lựa chọn:

• Đây là cách tiếp cận hợp tác và chủ động, phù hợp nguyên tắc PMP: PM làm việc trực tiếp với stakeholders (customer) để hiểu ưu tiên (priorities), và với team để đánh giá khả năng thực hiện nhanh hơn. Giúp điều chỉnh milestone mà vẫn đảm bảo value, tránh rủi ro không cần thiết. Điều này hỗ trợ iterative delivery và prioritization (theo MoSCoW hoặc Kano model).

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết:

• ✅ Review the customer’s priorities regarding the desired requirements for the milestones.
  Đúng 🏆: Hành động này thể hiện quản lý stakeholder engagement hiệu quả. PM cần xác nhận lại ưu tiên của customer về requirements liên quan đến milestone, giúp làm rõ những gì thực sự cần thiết (essential vs. nice-to-have). Điều này hỗ trợ trade-off analysis và tailoring lịch trình, đảm bảo dự án deliver value nhanh mà không lãng phí.

• ❌ Convince the customer to keep the requirements as is and not move the milestone.
  Sai 🚫: Không hợp tác, mang tính áp đặt (persuasive) thay vì lắng nghe. PMP khuyến khích win-win solutions qua dialogue, không phải thuyết phục giữ nguyên kế hoạch cũ. Điều này có thể làm giảm trust và engagement của stakeholder.

• ✅ Discuss which requirements can be delivered faster with the project team.
  Đúng 🏆: PM phải hợp tác với team để đánh giá feasibility (khả thi), xác định requirements nào có thể accelerate (ví dụ: simplify scope, parallel work, hoặc dùng Agile sprints ngắn). Đây là thực hành team empowerment và risk-informed decisions, giúp realistic adjustment milestone.

• ❌ Inform the customer that moving the milestone has a very high impact on project cost.
  Sai 🚫: Chỉ thông báo tiêu cực mà không đề xuất giải pháp, tạo cảm giác fear-based thay vì proactive. PMP yêu cầu PM facilitate options và thảo luận trade-offs (scope-time-cost), không dùng cost impact để block yêu cầu mà không phân tích.

• ❌ Escalate the issue to senior management so they can impose a solution on the customer.
  Sai 🚫: Escalation chỉ dùng khi PM không thể giải quyết (per escalation matrix), không phải ngay lập tức. PM phải own the issue và giải quyết ở cấp thấp nhất (servant leadership). Giao cho senior management áp đặt sẽ làm giảm authority của PM và trust từ customer.

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

• PMBOK Guide 7th Edition (2021): Principle 4 (Collaborate), Principle 11 (Empower Team & Stakeholders); Process 4.7 Manage Project Changes; Section 4.6.2.3 Prioritization.
• Agile Practice Guide (2021): Chapter 5 (Delivering in Iterations), nhấn mạnh early deliverables và reprioritization.
• PMP Exam Content Outline (2021, hiệu lực đến 2026): Domain III: Business Environment (Stakeholder mgmt), Domain IV: Delivery (Milestone & value focus).
• Nguồn bổ sung: PMI.org – "Tailoring Considerations" và "Stakeholder Engagement Assessment Matrix".

🧠 Lời khuyên PMP: Luôn ưu tiên people over process, thảo luận mở để tạo shared understanding! Nếu cần thực hành thêm, hãy thử scenario tương tự trong PMI mocks.

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

Câu hỏi này thuộc chủ đề Quản lý rủi ro và Tuân thủ (Compliance) trong môi trường Agile theo PMP (Project Management Professional). Một đội Agile mới bắt đầu dự án cho tổ chức tài chính, và nhà tài trợ dự án (project sponsor) lo ngại rằng cách tiếp cận Agile có thể không hỗ trợ đủ các tiêu chuẩn tuân thủ (compliance standards) của tổ chức.

📌 Bối cảnh chính:

• Dự án liên quan đến lĩnh vực tài chính, nơi compliance rất nghiêm ngặt (ví dụ: quy định pháp lý, bảo mật dữ liệu như GDPR hoặc SOX).
• Rủi ro: Agile linh hoạt có thể bỏ qua các kiểm soát tuân thủ nếu không tích hợp đúng cách.
• Mục tiêu: Project Manager (PM) cần giảm thiểu rủi ro (mitigate risk) bằng hành động phù hợp, tránh vấn đề sau này, đồng thời giữ nguyên tinh thần Agile (iterative, collaborative).

🛠️ Kiến thức PMP liên quan (cập nhật PMBOK 7th Edition & Agile Practice Guide 2021, áp dụng đến 2026): Trong Agile, tuân thủ không phải là "thêm lớp" riêng mà cần nhúng (embed) vào quy trình cốt lõi như Definition of Done (DoD), để đảm bảo mọi user story đều đạt chuẩn chất lượng/compliance mà không làm chậm flow.

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

Đáp án đúng: Meet with the compliance team and make sure that their requirements are covered in the definition of done (DoD) for each story.

Lý do chi tiết:

• ✅ Tích hợp trực tiếp vào DoD: DoD là checklist chung cho toàn đội, định nghĩa "done" cho từng story/user story. Bằng cách họp với đội compliance và đưa yêu cầu của họ vào DoD, PM đảm bảo mọi story đều tự động kiểm tra compliance trước khi hoàn thành (increment). Điều này giảm rủi ro mà không phá vỡ Agile (không cần approval gate riêng).
• 🛡️ Phù hợp nguyên tắc Agile: Theo Agile Practice Guide, DoD giúp embed quality gates (bao gồm compliance) vào iterative process, khuyến khích collaboration giữa dev team và stakeholders.
• 📈 Hiệu quả mitigate risk: Tránh vấn đề bằng cách proactive, collaborative, thay vì reactive (kiểm tra cuối).
• Nguồn tham khảo: PMBOK® Guide 7th Edition (Section 4.5: Build Quality into Processes & Deliverables); Agile Practice Guide (p. 54-55: Definition of Done); Scrum Guide 2020 (DoD as enforceable transparency).

📋 Phân tích 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 giải thích rõ ràng bằng tiếng Việt:

• Ensure that the peer review process also covers compliance requirements, creating a second layer of security for the project.
  ❌ Sai: Peer review (code review) chỉ là kiểm tra kỹ thuật nội bộ, không đủ độ tin cậy cho compliance nghiêm ngặt (như tài chính). Nó tạo "lớp thứ hai" không chính thức, dễ bỏ sót, và không tích hợp sâu vào Agile flow. Không phải best practice cho risk mitigation.

• Meet with the compliance team and make sure that their requirements are covered in the definition of done (DoD) for each story.
  ✅ Đúng: Như đã giải thích ở trên. Cách tốt nhất để embed compliance vào core Agile process, đảm bảo tính nhất quán, collaboration, và kiểm soát rủi ro mà không làm chậm release cycle.

• Liaison with the compliance group, making them responsible for understanding the requirements and keeping them prioritized in the backlog.
  ❌ Sai: Đẩy trách nhiệm prioritization backlog cho compliance group là không phù hợp (họ không phải product owner). Agile yêu cầu Product Owner/team quản lý backlog; làm vậy tạo bottleneck và vi phạm nguyên tắc self-organizing team.

• Propose using a compliance review board that will be responsible for approving all product features prior to their release to the public.
  ❌ Sai: Tạo "hội đồng phê duyệt" là phong cách Waterfall, thêm gate cuối gây chậm trễ, giảm agility. Agile ưu tiên built-in quality thay vì external approval board, vi phạm principle "Deliver value incrementally".

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

• PMBOK® Guide – Seventh Edition (PMI, 2021): Chapter 4 (Project Delivery Principles), đặc biệt Agile Hybrid approaches.
• Agile Practice Guide (PMI, 2017/2021 update): Section on Managing Compliance in Agile (p. 52-56).
• Scrum Guide (2020, Ken Schwaber & Jeff Sutherland): Definition of Done.
• PMI Standards đến 2026: Không thay đổi core concepts này; cập nhật nhấn mạnh Outcome-based delivery với compliance embedded.

Hy vọng phân tích này giúp bạn ôn 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 tập trung vào quy trình quản lý rủi ro (Risk Management) trong dự án theo chuẩn PMP (PMBOK Guide 7th Edition, cập nhật đến 2026).
Tình huống: Quản lý dự án đang xem xét các rủi ro (risks) và vấn đề (issues) của chương trình với các bên liên quan chính. Một bên liên quan muốn hiểu khi nào rủi ro có thể trở thành vấn đề (when the risk may potentially become an issue).
Yêu cầu: Quản lý dự án cần chia sẻ artifact (tài liệu/sản phẩm) nào để giải đáp?
🛠️ Mục tiêu chính: Xác định artifact chứa thông tin về điều kiện kích hoạt (triggers) hoặc thời điểm rủi ro chuyển hóa thành issue thực tế, giúp dự đoán và theo dõi rủi ro hiệu quả.

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

Lý do lựa chọn:
Risk register là tài liệu cốt lõi chứa danh sách đầy đủ các rủi ro đã xác định, bao gồm triggers (điều kiện kích hoạt) – chính là yếu tố cho biết khi nào rủi ro có thể trở thành issue. Theo PMBOK 7th Edition (Section 4.6 Manage Risks), risk register cập nhật thông tin như xác suất, tác động, phản ứng rủi ro và triggers, giúp bên liên quan dự đoán thời điểm rủi ro "chín muồi" để can thiệp kịp thời. Đây là artifact phù hợp nhất để chia sẻ trực tiếp với stakeholder trong ngữ cảnh này!
📘 Dẫn nguồn: PMBOK Guide 7th Edition, trang 123-125 (Risk Register trong Manage Risks); PMI Risk Management Standard.

📋 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên vai trò artifact trong quản lý rủi ro PMP:

• ❌ Project management plan
  Sai vì: Đây là tài liệu tổng hợp toàn bộ kế hoạch dự án (bao gồm phụ lục như risk management plan), nhưng không chứa chi tiết cụ thể về triggers hoặc thời điểm rủi ro trở thành issue. Nó chỉ cung cấp khung tổng quát, không phù hợp để trả lời câu hỏi "khi nào" một cách chi tiết. (PMBOK 7th: Section 4.2 Develop Project Management Plan).

• ❌ Issue log
  Sai vì: Issue log chỉ ghi nhận các vấn đề đã xảy ra (actual issues), không phải rủi ro tiềm ẩn hay triggers dự đoán. Nó dùng để theo dõi và giải quyết issue hiện tại, không giúp hiểu "khi nào risk trở thành issue" vì issue đã là sự thật xảy ra rồi! (PMBOK 7th: Section 4.7 Manage Project Issues).

• ❌ Risk management plan
  Sai vì: Đây là tài liệu mô tả quy trình, phương pháp quản lý rủi ro tổng quát (như cách xác định, đánh giá, phản ứng), nhưng không chứa dữ liệu cụ thể về từng rủi ro hay triggers. Nó là "hướng dẫn chơi game", không phải "danh sách rủi ro thực tế". (PMBOK 7th: Section 4.5 Plan Risk Management).

• ✅ Risk register
  Đúng vì: Như đã giải thích ở trên, đây là artifact chứa chi tiết từng rủi ro, bao gồm triggers chính xác để dự đoán khi nào nó trở thành issue. Hoàn hảo cho stakeholder muốn thông tin cụ thể và cập nhật! (PMBOK 7th: Section 4.6 Manage Risks).

🏆 Kết luận & Lời khuyên PMP

Chọn Risk register giúp quản lý dự án minh bạch hóa rủi ro, tăng cường sự tham gia của stakeholder – nguyên tắc cốt lõi của Stakeholder Engagement (PMBOK 7th, Section 4.4). Hãy luôn cập nhật risk register định kỳ để tránh rủi ro "biến hình" thành issue lớn!
📘 Tài liệu tham khảo chính:

• PMBOK® Guide – 7th Edition (PMI, 2021, cập nhật 2026 qua Agile Practice Guide).
• The Standard for Risk Management in Portfolios, Programs, and Projects (PMI, 2019).
  Nếu cần ví dụ thực tế hoặc câu hỏi PMP khác, hãy hỏi nhé! 🚀

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

Câu hỏi mô tả một dự án xây dựng cơ sở lưu trữ và phân phối cho sản phẩm mới ra mắt vào cuối năm. Trong cuộc họp stakeholder hàng tháng, project manager (PM) phát hiện vị trí triển khai nằm trên khu đất thuộc sở hữu của chính phủ. 📍 Đây là tình huống bất ngờ, có thể dẫn đến rủi ro pháp lý, trì hoãn dự án hoặc chi phí phát sinh (như xin giấy phép, đàm phán hoặc thay đổi vị trí). Theo PMBOK® Guide 7th Edition (và cập nhật đến 2026 với PMBOK® 8th Draft), PM cần xử lý theo quy trình Monitor Risks (11.7) và Manage Project Knowledge, ưu tiên xác định và ghi nhận rủi ro trước khi hành động cụ thể để tránh leo thang không cần thiết. Câu hỏi tập trung vào hành động đầu tiên (first) của PM.

✅ Đáp án đúng: Update the risk register

Lý do lựa chọn:
Khi phát hiện thông tin mới về vị trí đất thuộc chính phủ, đây là một rủi ro đã được xác định (identified risk) – một sự kiện không chắc chắn có thể ảnh hưởng tiêu cực đến mục tiêu dự án (ví dụ: trì hoãn, chi phí pháp lý). Theo PMBOK® 7th Edition (Section 11.6 & 11.7), hành động đầu tiên là cập nhật Risk Register để ghi nhận rủi ro này, đánh giá xác suất/tác động, và lập kế hoạch ứng phó (như nghiên cứu quy định pháp lý). Điều này đảm bảo tính minh bạch, theo dõi liên tục, và tích hợp vào các quy trình dự án. Không nhảy ngay sang hành động khắc phục vì cần đánh giá đầy đủ trước! 🛡️️

📋 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 văn bản gốc bằng tiếng Anh:

• ✅ Update the risk register
  Đúng! Như đã giải thích, đây là bước đầu tiên theo quy trình Identify Risks và Monitor Risks (PMBOK® 7th, Process Group: Executing & Monitoring). Phát hiện mới cần ghi nhận vào Risk Register để phân tích (qualitative/quantitative) và ưu tiên, tránh bỏ sót. Emoji: 🎯 Chính xác!

• ❌ Update the issue log
  Sai! Issue Log dùng cho vấn đề đã xảy ra (issues) – tức là sự kiện chắc chắn đang cản trở dự án ngay lập tức (PMBOK® 7th, Section 4.6 Manage Project Knowledge). Ở đây, chỉ mới "phát hiện" (discovered), chưa có tác động thực tế (chưa bị cấm xây), nên chưa phải issue. Cập nhật sớm có thể gây nhầm lẫn và làm phức tạp hóa quản lý. 🚫

• ❌ Identify an alternative site
  Sai! Đây là hành động ứng phó rủi ro (risk response), nhưng chưa phải bước đầu tiên. PM cần đánh giá rủi ro đầy đủ (probability/impact) trước khi tìm site thay thế, tránh lãng phí tài nguyên nếu có thể xin phép chính phủ (PMBOK® 7th, 11.5 Plan Risk Responses). Hành động vội vàng có thể vi phạm nguyên tắc "tailoring". ⏭️ Quá sớm!

• ❌ Issue a change request
  Sai! Change Request dùng để thay đổi baseline (scope/schedule/cost) qua Perform Integrated Change Control (PMBOK® 7th, Process 4.6). Ở đây chưa có cơ sở thay đổi (chỉ mới phát hiện), cần update risk trước rồi mới xem xét escalate nếu rủi ro cao. Phát hành sớm sẽ bị từ chối và tốn thời gian phê duyệt. 🔄 Không phù hợp!

📘 Tài liệu tham khảo

• PMBOK® Guide – 7th Edition (PMI, 2021): Sections 11.2 Identify Risks, 11.7 Monitor Risks; Figure 11-1 Risk Management Flow.
• PMI Standards Update 2024-2026: Nhấn mạnh Hybrid/Agile approaches, vẫn giữ nguyên quy trình risk-first trong discovery phase (PMI.org updates).
• PMP Exam Content Outline 2021 (valid to 2026): Domain 4: Risk Management (24% questions).

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ỏi nhé!