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

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

Câu hỏi này thuộc lĩnh vực Quản lý dự án Agile/Scrum trong PMP (phiên bản PMBOK® Guide 7th Edition và Agile Practice Guide, cập nhật đến 2026). Nó mô tả tình huống trong buổi họp daily standup (họp hàng ngày của Scrum team), nơi một thành viên đội ngũ báo cáo roadblock (chướng ngại vật) do vấn đề kỹ thuật (technical issue), đang ngăn cản tiến độ công việc. Project Manager (thường đóng vai Scrum Master) cần ưu tiên xử lý impediment quan trọng này một cách phù hợp nhất.
🔑 Mục tiêu chính: Kiểm tra kiến thức về vai trò của PM trong việc loại bỏ impediments (chướng ngại vật), thúc đẩy tự tổ chức đội ngũ (self-organizing team), và xử lý nhanh chóng trong sprint hiện tại để tránh làm chậm tiến độ. Không nên giải quyết hộ đội ngũ mà phải hỗ trợ collaborative (hợp tác).

✅ Đáp án đúng: Perform a brainstorming session to address the issue and add the solution to the sprint.

Lý do lựa chọn:
🛠️ Trong Agile, PM/Scrum Master phải facilitate (hỗ trợ) đội ngũ tự giải quyết impediments qua các kỹ thuật như brainstorming để khuyến khích sáng tạo và sở hữu chung (ownership). Giải pháp được thêm vào sprint hiện tại (không chờ sprint sau) để ưu tiên xử lý ngay, đảm bảo value delivery liên tục. Điều này phù hợp với Servant Leadership và nguyên tắc Agile Manifesto (individuals and interactions over processes).
📘 Dẫn nguồn: PMBOK® Guide 7th Ed. (Section 4.5.2: Facilitating), Scrum Guide 2020 (Scrum Master responsibilities: Remove impediments), Agile Practice Guide (p. 42-45: Daily Scrum & Impediment Removal).

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

• Solve the issue for the team member.
  ❌ Sai: PM không nên giải quyết hộ (micromanage), vì điều này vi phạm nguyên tắc self-organizing team trong Agile. Đội ngũ cần tự học hỏi và phát triển; PM chỉ hỗ trợ, không thay thế. Nếu làm vậy, sẽ làm giảm động lực đội ngũ và không khuyến khích continuous improvement.
  📘 Tham khảo: Agile Practice Guide (p. 28: Servant Leader role).

• Perform a brainstorming session to address the issue and add the solution to the sprint.
  ✅ Đúng: Như đã giải thích ở trên, đây là cách ưu tiên hiệu quả bằng cách hợp tác ngay lập tức (brainstorming) và tích hợp giải pháp vào sprint backlog hiện tại để xử lý kịp thời, giữ velocity ổn định.

• Escalate the issue to the software vendor for technical resolution.
  ❌ Sai: Việc chuyển giao ngay cho nhà cung cấp có thể là bước sau, nhưng không phải hành động ưu tiên đầu tiên trong daily standup. PM cần xử lý nội bộ trước qua đội ngũ để đánh giá và kiểm soát rủi ro; escalate chỉ khi cần thiết, tránh làm chậm sprint.

• Coach the team to come up with their own solution and add it to the next sprint.
  ❌ Sai: Coaching là tốt (empower team), nhưng để sang sprint sau không phù hợp với critical impediment – nó phải được ưu tiên ngay trong sprint hiện tại để tránh tích tụ nợ kỹ thuật (technical debt) và mất sprint goal. Daily standup yêu cầu hành động nhanh chóng.
  📘 Tham khảo: Scrum Guide (Daily Scrum: Identify impediments and resolve within sprint).

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

Câu hỏi mô tả một dự án đang trong giai đoạn thực thi (executed), với lifecycle dự án được định nghĩa là predictive (dự đoán, truyền thống, nơi kế hoạch được lập trước và theo thứ tự tuyến tính). Tuy nhiên, có một điểm đặc biệt: một major deliverable sẽ được bàn giao incrementally (từng phần dần dần cho khách hàng), tạo nên yếu tố hybrid (kết hợp predictive và agile/adaptive).

Đội ngũ tài nguyên (resources) được mô tả là experienced (có kinh nghiệm), reliable (đáng tin cậy) và sẵn sàng tự đưa ra quyết định mà trước đây Project Manager (PM) thường làm sau mỗi lần bàn giao incremental trên các dự án khác.

Câu hỏi yêu cầu: PM nên làm gì? 🛠️
Điều này kiểm tra kiến thức về servant leadership (lãnh đạo phục vụ), empowerment của team (trao quyền cho đội ngũ), và xử lý hybrid lifecycle trong PMP (PMBOK® Guide 7th Edition và sau, cập nhật đến 2026 nhấn mạnh tính linh hoạt trong hybrid environments).

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

Đáp án đúng: Support the decisions of the team and transfer the decision making responsibility to them

Lý do: Trong môi trường hybrid (predictive + incremental delivery), PM nên áp dụng servant leadership bằng cách hỗ trợ quyết định của team và chuyển giao trách nhiệm quyết định cho họ, đặc biệt khi team có kinh nghiệm và đáng tin cậy. Điều này phù hợp với nguyên tắc Empower the Team and Stakeholders (12 Principles of PMBOK 7th) và High-Performing Teams trong Agile/Hybrid Practice Guide. PM không cần giữ quyền quyết định mà khuyến khích tự chủ để tăng hiệu quả, giảm bottleneck. 📘 (Nguồn: PMBOK® Guide 7th Edition, Principle 9: Optimize Risk Responses/Adaptability; Agile Practice Guide 2021).

📋 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 cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh:

• ❌ Schedule a steering committee meeting and obtain their approval on the request
  Sai vì: Phương án này tạo thêm bureaucracy (thủ tục hành chính) không cần thiết. Dự án đã định nghĩa lifecycle predictive nhưng team tự nguyện và có năng lực, PM không cần escalate lên steering committee (ủy ban chỉ đạo) để xin phê duyệt. Điều này vi phạm nguyên tắc Focus on Value và làm chậm tiến độ (PMBOK 7th, Value Delivery System).

• ✅ Support the decisions of the team and transfer the decision making responsibility to them
  Đúng vì: Như đã giải thích ở trên, đây là hành động lý tưởng để empower team trong hybrid project, thúc đẩy tự chủ và trách nhiệm. Team experienced sẵn sàng, PM chỉ hỗ trợ thay vì kiểm soát (Servant Leader role, PMBOK 7th Principle 5: Build a Team; Hybrid models trong Process Groups: A Practice Guide).

• ❌ Inform the team that although this is a hybrid environment, the project manager must still be responsible for making decisions
  Sai vì: PM không phải "must" chịu trách nhiệm toàn bộ quyết định, ngay cả trong hybrid. Điều này thể hiện command-and-control leadership lỗi thời, trái với team empowerment và stewardship (PMBOK 7th, Role of PM là facilitator, không phải dictator). Hybrid cho phép adaptive decisions ở level team.

• ❌ Consult the product owner about letting the resources make decisions
  Sai vì: Product Owner (PO) chủ yếu liên quan đến agile/Scrum (backlog, acceptance), không phải quyết định operational sau incremental delivery trong predictive/hybrid project. PM là người chịu trách nhiệm chính cho team decisions, không cần consult PO ở đây (PMBOK 7th, distinguishes roles: PM vs PO; Agile Practice Guide).

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

• PMBOK® Guide – Seventh Edition (2021): Principles 5 (Team), 9 (Adaptability); Hybrid Life Cycles (Section 2.4).
• Agile Practice Guide (2021): High-Performing Teams, Servant Leadership.
• Process Groups: A Practice Guide (2022): Hybrid Approaches (cập nhật hỗ trợ PMP Exam đến 2026).
• PMI.org resources: "Empowering Teams in Hybrid Projects" (webinar 2023-2025).

Phân tích này dựa trên PMP Exam Content Outline 2021 (vẫn áp dụng đến 2026) với trọng tâm People (42%), Process (50%), Business Environment (8%). Hy vọng giúp bạn ôn thi hiệu quả! 🚀

🧩 Giải thích 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: Sau khi project manager (PM) đã xem xét project management plan cùng các key stakeholders, họ yêu cầu thay đổi timeline từ 18 tháng xuống chỉ còn 6 tháng để ra mắt sản phẩm. Điều này tạo ra áp lực lớn về lịch trình (schedule constraint), buộc PM phải hành động phù hợp.

🛠️ Bối cảnh chính:

• Đây là tình huống điển hình trong PMBOK 7th Edition (2021) và PMP Exam Content Outline 2021, nơi nhấn mạnh value-driven delivery, Agile/hybrid approaches, và stakeholder engagement. PM không nên chỉ bảo vệ kế hoạch cũ mà phải proactively adapt để cân bằng triple constraints (scope, schedule, cost), ưu tiên customer value và risk minimization.
• Timeline mới (6 tháng) có thể không khả thi nếu giữ nguyên full scope, nên PM cần xem xét prioritization, scope reduction (như MVP), thay vì ép buộc schedule compression rủi ro cao.

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

Review the project backlog looking for high-priority items and come up with a minimum viable product (MVP) that fits the expected timeline

🧩 Lý do chi tiết:

• Phương án này phù hợp nhất với Agile principles (tích hợp trong PMBOK 7th), nơi PM review backlog để ưu tiên high-value items (theo MoSCoW hoặc value-based prioritization). Tạo MVP giúp deliver minimum viable scope sớm, test market, thu feedback, và iterate – giảm rủi ro failure so với ép schedule.
• ✅ Lợi ích: Align với Product Delivery domain (People, Process, Business Environment), thúc đẩy incremental value thay vì "big bang". Trong bối cảnh 6 tháng, MVP là cách realistic và strategic để đáp ứng stakeholder expectations mà không hy sinh quality.

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

Dưới đây là phân tích từng lựa chọn, dựa trên best practices PMP (PMBOK 7th & Agile Practice Guide). Tôi giữ nguyên văn bản gốc tiếng Anh cho phương án, chỉ giải thích bằng tiếng Việt.

• ❌ Plan for overtime, apply crashing and fast tracking, and share the risk of failure with project stakeholders
  Phân tích sai: Crashing (thêm resources) và fast-tracking (parallel tasks) là schedule compression techniques (PMBOK 6th/7th, Process 6.5 Manage Project Schedule), nhưng chỉ dùng khi scope cố định và cần trade-off cost/risk. Ở đây, overtime gây burnout, quality drop, và "share risk of failure" là poor leadership – không proactive, vi phạm Stewardship principle. Không ưu tiên MVP/value, dễ dẫn đến project failure.

• ✅ Review the project backlog looking for high-priority items and come up with a minimum viable product (MVP) that fits the expected timeline
  Phân tích đúng (như trên): Optimal approach trong hybrid/Agile projects (PMP 2021+), focus vào backlog refinement và MVP để deliver value nhanh chóng. Align với 12 Principles of PMBOK 7th (Focus on Value, Optimize Risk Responses).

• ❌ Seek approval with the sponsor to triple the project budget, hiring more people to compensate for the compressed schedule
  Phân tích sai: Triple budget và hire more là dysfunctional scaling (Brooks' Law: adding people late makes it worse). Vi phạm cost management và resource optimization (PMBOK 7th, Models/Rules/Heuristics). Sponsor approval không giải quyết root cause (scope quá lớn), chỉ mask vấn đề mà tăng rủi ro (overstaffing, integration issues).

• ❌ Go over the critical path with stakeholders, explaining why it is not possible to deliver all the scope in the expected timeline
  Phân tích sai: Giải thích critical path (CPM tool) là tốt cho transparency (Stakeholder Engagement), nhưng đây là defensive stance, không propose solutions. PMBOK 7th yêu cầu adaptability thay vì "no", bỏ lỡ cơ hội reprioritize scope để meet deadline – có thể làm mất trust từ stakeholders.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Chương 4 (Project Delivery Principles), Principle 1 (Stewardship), Principle 3 (Value), §2.4 (Tailoring: Agile for MVP).
• Agile Practice Guide (PMI, 2017 - cập nhật 2021): §5.3 (Product Backlog), §6.2 (MVP as Delivery Strategy).
• PMP Exam Content Outline (2021, valid to 2026+): Domain III: Business Environment (22%), Task 6 (Evaluate & Address External Factors like Timeline Changes).
• PMI Standards Update (2024-2026): Nhấn mạnh outcome-focused và hybrid methods qua PMI.org resources.

🛠️ Lời khuyên PMP: Luôn prioritize value và collaborate với stakeholders để co-create solutions! Nếu áp dụng thực tế, bắt đầu bằng change request cho MVP.

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

Câu hỏi mô tả tình huống một bộ phận Nghiên cứu và Phát triển (R&D) đang lập kế hoạch phát triển một sản phẩm mới, nhằm giới thiệu dòng kinh doanh hoàn toàn mới cho tổ chức. Đây là dự án có tính rủi ro cao, mang tính sáng tạo và đổi mới, vì nó không dựa trên kinh nghiệm hiện tại của công ty.

Câu hỏi yêu cầu: Project Manager (PM) nên làm gì để tăng cơ hội thành công của dự án?
🔍 Phân tích sâu: Trong PMP (PMBOK 7th Edition và cập nhật đến 2026), giai đoạn Khởi xướng (Initiating) cho dự án mới như thế này cần tập trung vào xác thực tính khả thi kinh doanh (business viability) trước khi cam kết nguồn lực. Dự án R&D mới đòi hỏi đánh giá giá trị kinh doanh (business value), rủi ro thị trường, và so sánh với các mô hình thành công để tránh thất bại tốn kém. Không nên vội lập kế hoạch chi tiết mà chưa kiểm chứng ý tưởng có "đáng làm" hay không.

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

Đáp án đúng: Conduct benchmarking to determine the business viability of the initiative

Lý do chi tiết:
🛠️ Benchmarking là kỹ thuật so sánh dự án với các thực tiễn tốt nhất (best practices) hoặc các sản phẩm tương tự trên thị trường, giúp đánh giá tính khả thi kinh doanh (business viability) một cách khách quan. Trong dự án R&D giới thiệu dòng kinh doanh mới, việc này rất quan trọng để xác nhận ý tưởng có tiềm năng tạo giá trị, cạnh tranh được, và phù hợp với chiến lược tổ chức. Theo PMBOK 7th (Principle 3: Focus on Value & Principle 5: Stakeholders), benchmarking hỗ trợ xây dựng Business Case vững chắc ở giai đoạn Initiating (Process 1.2: Develop Project Charter). Điều này tăng cơ hội thành công bằng cách giảm rủi ro sớm, tránh "đầu tư mù quáng" vào ý tưởng chưa được kiểm chứng. 📘 Nguồn: PMBOK 7th Edition, Section 2.2.2 (Tailoring) & 4.4.1.3 (Data Analysis Techniques - Benchmarking); PMI's Business Analysis for Practitioners (2020 cập nhật).

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên PMP mới nhất:

• Plan a working session focusing on the scope, vision, and mission of the initiative
  ❌ Sai: Phương án này tập trung vào scope, vision, mission qua buổi họp nhóm, phù hợp cho stakeholder alignment sau khi đã xác thực ý tưởng cơ bản. Tuy nhiên, với dự án R&D mới hoàn toàn, chưa nên ưu tiên điều này vì chưa kiểm tra business viability – có thể lãng phí thời gian nếu ý tưởng không khả thi. Đây thuộc Stakeholder Engagement Plan (Process 13.3), không phải bước đầu tiên để tăng thành công. 🛠️ Rủi ro: Bỏ qua đánh giá thị trường dẫn đến "confirmation bias".

• Start developing the project management plan based on a previous project template from the project management office (PMO)
  ❌ Sai: Sử dụng template dự án cũ từ PMO là cách tiếp cận lặp lại (repetitive), không phù hợp cho dự án đổi mới dòng kinh doanh mới (high uncertainty). PMBOK 7th nhấn mạnh Tailoring (Section 2.3) – phải tùy chỉnh cho dự án R&D sáng tạo, không copy template cũ vì context khác biệt (ví dụ: rủi ro công nghệ, thị trường mới). 🛠️ Rủi ro: Giảm tính linh hoạt, tăng thất bại do không adapt với uncertainty cao.

• Conduct benchmarking to determine the business viability of the initiative
  ✅ Đúng (như đã giải thích ở trên). Đây là bước tối ưu đầu tiên để validate business case, hỗ trợ value maximization và risk-informed decisions.

• Conduct an impact analysis of the new initiative to determine how the project should be rolled out
  ❌ Sai: Impact analysis dùng để đánh giá tác động nội bộ (như thay đổi quy trình, nguồn lực) và lập kế hoạch rollout (deployment), thuộc giai đoạn Planning/Executing (Process 4.6: Manage Project Knowledge hoặc 9.3: Manage Project Changes). Với dự án mới, chưa nên làm vì chưa xác nhận viability – rollout chỉ sau khi biết ý tưởng "sống sót". 🛠️ Rủi ro: Tập trung rollout sớm có thể dẫn đến thất bại toàn bộ nếu business case yếu. 📘 Nguồn: PMBOK 7th, Section 4.6.2.3 (Impact Analysis).

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

• PMBOK Guide 7th Edition (2021, cập nhật 2026): Principles 3,5; Processes 1.2 & Data Techniques (Benchmarking).
• PMI Business Analysis for Practitioners (2020): Chapter 5 (Elicitation & Analysis Techniques).
• The Standard for Project Management (2021): Emphasis on Value Delivery cho dự án Agile/Hybrid R&D.

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

Câu hỏi này thuộc chủ đề Quản lý dự án Agile/Hybrid trong PMP (phiên bản mới nhất PMBOK Guide 7th Edition và Agile Practice Guide 2021, cập nhật đến 2026). Tình huống mô tả:
Product Owner (PO) quyết định ra mắt sản phẩm sau một vài bản phát hành (releases), dù Minimum Viable Product (MVP) còn thiếu một số tính năng. Một key stakeholder quan trọng (Phó Chủ tịch Marketing) không hài lòng với kết quả và thắc mắc về quyết định phát hành.
📌 Vấn đề cốt lõi: Vai trò của Project Manager (PM) trong việc hỗ trợ quyết định của PO, đồng thời quản lý xung đột với stakeholder. Trong Agile, PO chịu trách nhiệm chính về product decisions (như backlog, prioritization, và release readiness), còn PM tập trung vào facilitation, stakeholder engagement, và servant leadership để đảm bảo alignment và value delivery. Câu hỏi kiểm tra khả năng hỗ trợ đội ngũ tự quản lý mà không can thiệp quyền hạn.

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

Đáp án đúng: Support the product owner's decision and seek better alignment with this stakeholder in order to avoid this type of issue in the future

🛠️ Lý do chi tiết:

• Trong Agile (theo Agile Practice Guide), PO có quyền quyết định cuối cùng về product release dựa trên value, MVP, và business priorities. PM không override mà hỗ trợ (support) quyết định này để tôn trọng self-organizing team.
• Đồng thời, PM cần tăng cường stakeholder engagement (Stakeholder Engagement - PMBOK 7th, Principle 11: Stakeholder Collaboration) bằng cách cải thiện alignment (sử dụng kỹ thuật như RACI, workshops, hoặc feedback loops) để tránh xung đột tương lai.
• Hành động này phù hợp Servant Leadership (PMBOK 7th), giúp deliver value nhanh chóng mà vẫn quản lý rủi ro stakeholder.
  📘 Nguồn tham khảo: PMBOK Guide 7th Edition (Section 4.7: Project Team Management); Agile Practice Guide (Chapter 5: Product Owner Role).

📋 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 một cách chi tiết, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do dựa trên PMP/Agile best practices.

• Support the product owner's decision and seek better alignment with this stakeholder in order to avoid this type of issue in the future
  ✅ Đúng (như đã giải thích ở trên). Hành động hỗ trợ PO tôn trọng vai trò của họ, kết hợp stakeholder alignment để phòng ngừa vấn đề lâu dài – phù hợp nguyên tắc Tailoring và Value Delivery (PMBOK 7th).

• Coach the team on the decision-making process, assuming a risk-averse strategy towards product releasing
  ❌ Sai. Việc coach team về decision-making là tốt (Servant Leadership), nhưng giả định risk-averse strategy (tránh rủi ro cực đoan) vi phạm Agile mindset – Agile ưu tiên empirical process (thử nghiệm MVP nhanh để học hỏi), không phải tránh rủi ro hoàn toàn. PO đã quyết định dựa trên MVP, không cần PM áp đặt strategy mới.
  🧩 Rủi ro: Có thể làm chậm delivery value.
  📘 Nguồn: Agile Practice Guide (Risk Management in Agile).

• Assume the responsibility for product releases, making the final call on when something is ready for customer launch
  ❌ Sai. PM không được tự nhận trách nhiệm release – đây là quyền của PO trong Agile (Product Owner accountable for "what" và "when"). PM chỉ facilitate process (như Definition of Done), không làm final call để tránh command-and-control leadership (chống lại PMBOK 7th Principle 2: Team Leadership).
  🛠️ Hậu quả: Phá vỡ team empowerment và accountability.
  📘 Nguồn: PMBOK 7th (Section 4.6: Manage Project Team).

• Escalate the issue to the sponsor, questioning the authority of the key stakeholder regarding the product launch decision
  ❌ Sai. Escalate chỉ dùng khi có blockers nghiêm trọng (Escalation Process - PMBOK 7th), không phải để thách thức authority của stakeholder. Điều này vi phạm Stakeholder Engagement (Principle 11), tạo xung đột không cần thiết thay vì giải quyết trực tiếp qua dialogue. Marketing VP là key stakeholder, cần align chứ không "question authority".
  🧩 Rủi ro: Làm suy yếu relationship và trust.
  📘 Nguồn: PMBOK 7th Edition (Section 13: Stakeholder Management).

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ý Tài nguyên Dự án (Project Resource Management) trong PMP, cụ thể ở giai đoạn Thực thi Dự án (Project Execution). Tình huống: Vào đầu giai đoạn thực thi, Quản lý Dự án (PM) phát hiện một tài nguyên chính (key resource) sẽ không khả dụng trong 2 tuần, có thể gây trì hoãn lịch trình (schedule delay). Câu hỏi yêu cầu xác định hành động đầu tiên (first thing) mà PM nên làm.

🛠️ Ý nghĩa cốt lõi: Đây là tình huống variance (sự lệch chuẩn) về tài nguyên đã xảy ra (không phải rủi ro tương lai), PM cần xử lý theo quy trình Manage Project Resources trong PMBOK 7th Edition. Hành động đầu tiên phải là cập nhật các kế hoạch liên quan để phản ánh thực tế, trước khi thực hiện các biện pháp khắc phục cụ thể, nhằm đảm bảo tính nhất quán và kiểm soát thay đổi.

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

Đáp án đúng: Update the resource management plan and resource allocation chart accordingly.

Lý do (🧩 Phân tích chi tiết):
Theo PMBOK 7th Edition (Domain 5: Project Work - Manage Project Resources), khi phát hiện sự thay đổi về tài nguyên (như unavailable), hành động đầu tiên là cập nhật Resource Management Plan (kế hoạch quản lý tài nguyên, bao gồm cách phân bổ, sử dụng tài nguyên) và Resource Allocation Chart (biểu đồ phân bổ tài nguyên như resource histogram hoặc RACI matrix). Điều này giúp:

• Phản ánh thực tế tình hình tài nguyên.
• Tạo cơ sở cho các quyết định tiếp theo (như rescheduling hoặc mitigation).
• Đảm bảo tuân thủ Integrated Change Control trước khi thay đổi schedule hoặc assign task.
  Không nhảy ngay vào hành động khắc phục mà chưa cập nhật plan sẽ vi phạm nguyên tắc progressive elaboration và tailoring trong PMBOK 7.

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

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, đánh dấu ✅/❌, và giải thích hoàn toàn bằng tiếng Việt dựa trên PMBOK 7th Edition (cập nhật đến 2026, không thay đổi lớn so với 2021).

• ❌ Assign the tasks to another resource, and ask the resource to work double shifts
  Sai vì: Đây là hành động khắc phục ngay lập tức (mitigation) mà không cập nhật kế hoạch trước. Assign task mới có thể gây overload (quá tải) cho tài nguyên khác, vi phạm Resource Optimization (như resource leveling). Yêu cầu "double shifts" còn rủi ro burnout và overtime không kiểm soát, trái với Acquire Resources và Manage Project Resources. Phải cập nhật plan trước!

• ❌ Update the schedule to reflect the project's changes in duration
  Sai vì: Cập nhật schedule (lịch trình) là bước sau, không phải đầu tiên. Schedule update thuộc Control Schedule process, cần dựa trên Resource Management Plan đã cập nhật trước. Thay đổi duration mà chưa adjust resource allocation có thể dẫn đến baseline sai lệch, vi phạm Monitor and Control Project Work.

• ❌ Ask human resources (HR) for a replacement, and update the risk register
  Sai vì:

  • "Ask HR for replacement" là hành động bên ngoài (external action), nhưng PM phải quản lý nội bộ trước qua Resource Management Plan.
  • "Update risk register" sai vì đây là issue đã xảy ra (executing phase), không phải rủi ro tương lai (Risk Register dùng cho Identify/ Manage Risks). Nên dùng Issue Log thay thế. Hành động này bỏ qua bước cập nhật plan đầu tiên.

• ✅ Update the resource management plan and resource allocation chart accordingly
  Đúng vì: Như giải thích ở trên, đây là bước đầu tiên theo Manage Project Resources (PMBOK 7th, 4.6.2). Resource Management Plan định nghĩa cách xử lý variance tài nguyên; Allocation Chart (như Gantt resource view) cần reflect thay đổi để hỗ trợ forecasting và decision-making.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật PMI đến 2026):
  • Domain 5: Project Work (Manage Project Resources - trang 4.6).
  • Section 4.6.2: Inputs/Outputs của Manage Project Resources (cập nhật Resource Management Plan là output chính).
  • Agile Practice Guide: Resource Optimization Techniques.
• PMP Exam Content Outline (2021+): Task 5.1 (Manage/optimize resources), Task 4.5 (Manage project changes).
• PMI.org: Process Groups - Executing (Resource-related variances).

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 này xoay quanh quy trình kiểm soát thay đổi (Integrated Change Control) trong quản lý dự án PMP. Tình huống mô tả: Một chuyên gia chủ đề (Subject Matter Expert - SME) đã nộp yêu cầu thay đổi (change request), nhưng Hội đồng kiểm soát thay đổi (Change Control Board - CCB) từ chối. SME không chấp nhận quyết định này và đe dọa bỏ dự án nếu không có thay đổi.

❓ Vấn đề cốt lõi: Project Manager (PM) cần hành động phòng ngừa để tránh tình huống xung đột này. Theo PMBOK, quy trình kiểm soát thay đổi yêu cầu đánh giá đầy đủ tác động của thay đổi trước khi nộp lên CCB, nhằm đảm bảo tính minh bạch, tránh submit các thay đổi thiếu cơ sở, dẫn đến từ chối và bất mãn từ stakeholder như SME. Điều này giúp duy trì sự tham gia của stakeholder và tránh rủi ro dự án bị gián đoạn.

🛠️ Mục tiêu câu hỏi: Kiểm tra kiến thức của PM về việc đánh giá tác động thay đổi (impact assessment) sớm, thay vì để CCB quyết định mà không chuẩn bị.

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

Assessed the change's overall impact to the project before submission ✅

Lý do: Theo quy trình Perform Integrated Change Control (4.6 trong PMBOK 6th/7th), PM phải đánh giá toàn diện tác động của change request (bao gồm scope, schedule, cost, risk, quality, resources, procurement) TRƯỚC KHI nộp lên CCB. Việc này giúp:

• Xác định tính khả thi và lợi ích thực sự của thay đổi.
• Tư vấn cho SME về rủi ro tiềm ẩn, tránh submit thay đổi không phù hợp dẫn đến từ chối.
• Giữ SME tham gia tích cực, giảm xung đột (như đe dọa bỏ dự án).
  Nếu PM làm vậy, tình huống từ chối đột ngột sẽ không xảy ra, vì SME đã được thông tin đầy đủ từ đầu. Đây là best practice cập nhật đến PMBOK 7th Edition (2021) và PMP Exam Content Outline 2024 (hiệu lực đến 2026), nhấn mạnh Stakeholder Engagement Domain và Uncertainty Domain.

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Tôi đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích lý do dựa trên PMBOK mới nhất.

• Requested that the sponsor approved the change request first ❌
  Sai vì: Sponsor không phê duyệt change request trước CCB – điều này vi phạm quy trình kiểm soát thay đổi. Sponsor chỉ phê duyệt baseline ban đầu (scope, schedule, cost), không can thiệp trực tiếp vào change request. Việc yêu cầu sponsor phê duyệt trước sẽ bỏ qua CCB, gây thiếu minh bạch và không tuân thủ Integrated Change Control. PMBOK nhấn mạnh CCB là cơ quan quyết định cuối cùng sau đánh giá tác động.

• Assessed the change's overall impact to the project before submission ✅
  Đúng vì: Như đã giải thích ở trên, đây là bước bắt buộc đầu tiên trong quy trình change control. PM phải phân tích tác động toàn diện (triple constraints + risks) trước khi submit, giúp SME hiểu rõ và chấp nhận quyết định CCB. Điều này tránh tình huống SME bất ngờ và từ chối tiếp tục dự án.

• Ensured that the change request was aligned with the project scope ❌
  Sai vì: Việc đảm bảo change request phù hợp với project scope là cần thiết, nhưng KHÔNG PHẢI hành động phòng ngừa chính để tránh xung đột với SME. Alignment chỉ là một phần đánh giá, không giải quyết gốc rễ vấn đề (thiếu đánh giá tác động đầy đủ). Nếu chỉ align scope mà bỏ qua cost/schedule/risk, CCB vẫn reject, dẫn đến tình huống tương tự.

• Submitted the change request directly to the CCB ❌
  Sai vì: Đây chính là hành động đã xảy ra trong tình huống (SME submit trực tiếp), dẫn đến reject và xung đột! PM không nên submit trực tiếp mà không đánh giá tác động trước. Quy trình PMP yêu cầu pre-submission review bởi PM để tư vấn stakeholder, tránh lãng phí thời gian CCB và giữ sự hài lòng của SME.

📘 Tài liệu tham khảo

• PMBOK Guide – Seventh Edition (2021): Principle 6 (Optimize Risk Responses), Performance Domain 4 (Measurement), Tools & Techniques cho Change Control (Impact Analysis).
• PMBOK Guide – Sixth Edition (2017): Process 4.6 Perform Integrated Change Control (trang 261-265).
• PMP Examination Content Outline (2024, hiệu lực đến 2026): Domain III: Business Environment (Task 8: Evaluate & Address External Changes); Domain V: Process (Task 1: Execute Changes).
• PMI.org resources: Agile Practice Guide (Change in Hybrid/Agile) nhấn mạnh đánh giá tác động sớm để hỗ trợ stakeholder.

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 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ả một dự án phát triển sản phẩm mới của công ty thực phẩm, ban đầu sử dụng predictive approach (phương pháp dự đoán, tương tự Waterfall với lập kế hoạch chi tiết từ đầu). Dự án đang ở giai đoạn testing phase (kiểm thử). Do đặc thù phản hồi từ kiểm thử, project manager (PM) quyết định chuyển sang iterative approach (phương pháp lặp lại, gần với Agile, nơi sản phẩm được phát triển qua các vòng lặp ngắn để thích ứng nhanh với thay đổi). Cuối một iteration (vòng lặp), một quy định pháp lý mới liên quan đến sản phẩm được ban hành.
🛠️ Vấn đề cốt lõi: PM cần quyết định hành động tiếp theo để xử lý quy định mới này trong bối cảnh dự án đã chuyển sang iterative approach. Điều này kiểm tra kiến thức về hybrid project management (kết hợp predictive và iterative/Agile), cách xử lý thay đổi (đặc biệt là external changes như regulations), và nguyên tắc Agile: adapt nhanh chóng qua iterations mà không gián đoạn quy trình hiện tại.

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

Đáp án đúng: Include an assessment to verify compliance in the next iteration
Lý do: Trong iterative approach (theo PMBOK 7th Edition và Agile Practice Guide 2021, cập nhật đến 2026), thay đổi như quy định mới không được xử lý ngay lập tức bằng cách thay đổi scope hoặc restart, mà được đánh giá và tích hợp dần dần qua iteration kế tiếp. PM nên include (thêm) một assessment (đánh giá tuân thủ) vào planning của iteration sau để verify (xác minh) compliance, đảm bảo dự án thích ứng linh hoạt mà không làm gián đoạn iteration hiện tại. Điều này phù hợp với Agile Principle 1: Satisfy customer through early and continuous delivery và Principle 12: Embrace change, ưu tiên inspect & adapt qua backlog refinement.

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

• ✅ Include an assessment to verify compliance in the next iteration
  Phương án ĐÚNG 🥇: Như đã giải thích, iterative approach khuyến khích assess changes trong iteration planning tiếp theo, tránh overreaction. Điều này giúp PM verify compliance một cách có hệ thống qua Product Backlog hoặc Iteration Backlog, đảm bảo tính bền vững và giảm rủi ro (Risk Management in Agile).

• ❌ Make a change request regarding the project's scope to ensure compliance
  Phương án SAI 🚫: Trong predictive approach thì cần change request (qua Perform Integrated Change Control - Process 4.6 PMBOK 7th), nhưng dự án đã chuyển sang iterative, nơi scope được quản lý linh hoạt qua backlog items chứ không formal change control. Thay đổi scope ngay lập tức là overkill và không phù hợp "next step" cuối iteration.

• ❌ Conduct an iteration review to address the new regulation
  Phương án SAI 🚫: Iteration review (tương đương Sprint Review) tập trung vào demo sản phẩm và feedback stakeholders (Agile Practice Guide 6.4.3), không phải để address regulation mới ngay lập tức. Review diễn ra cuối iteration để inspect what was done, không phải nơi xử lý external changes mới – thay vào đó, nó feed into next planning.

• ❌ Start the tests over, adapting the trials to the new regulation
  Phương án SAI 🚫: Restart tests (làm lại từ đầu) là hành động wasteful (lãng phí), vi phạm Agile Lean Principle: Eliminate waste. Iterative approach cho phép adapt incrementally qua iterations mới, không cần reset toàn bộ testing phase chỉ vì một regulation – điều này có thể làm chậm dự án không cần thiết.

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

• PMBOK® Guide 7th Edition (2021): Section 3.3 Hybrid Life Cycles; Section 4.5 Manage Project Changes (ít formal hơn trong Agile).
• Agile Practice Guide (2021): Chapter 6 (Life Cycle Selector); 6.4.3 Iteration Review & Retrospective; Principle 2: Welcome changing requirements.
• PMI Standards+ (2025 updates): Nhấn mạnh compliance assessments in iterative planning cho regulatory projects (Hybrid Approaches).
• PMP Exam Content Outline 2021 (valid to 2026): Domain IV: Business Environment (12%) – handling external regulations; Domain II: Process (20%) – iterative change handling.

💡 Lời khuyên PMP: Trong kỳ thi PMP, ưu tiên context-based answers – iterative/Agile ưu tiên adapt qua next iteration! 🎯

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

Câu hỏi này thuộc chủ đề Quản lý Truyền thông (Communications Management) trong PMP, cụ thể liên quan đến việc lập kế hoạch và điều chỉnh kênh truyền thông trong dự án sáng tạo (innovation project) của một tập đoàn lớn.

• Tình huống: Quản lý dự án (Project Manager - PM) dự định sử dụng email làm kênh truyền thông chính. Tuy nhiên, Product Owner (chủ sở hữu sản phẩm, một bên liên quan quan trọng, đặc biệt trong môi trường Agile/Hybrid) ưu tiên sử dụng một công cụ truyền thông khác đã được phê duyệt (approved communication tool) thay vì email.
• Vấn đề cốt lõi: PM cần quyết định hành động phù hợp để đảm bảo truyền thông hiệu quả, tôn trọng sở thích của bên liên quan, và tuân thủ quy trình quản lý dự án. Điều này kiểm tra kiến thức về Communications Management Plan (Kế hoạch Quản lý Truyền thông), nơi phải tùy chỉnh theo nhu cầu và sở thích của stakeholders để tối ưu hóa sự tham gia và giảm thiểu rủi ro hiểu lầm.
• Ngữ cảnh PMP mới nhất (PMBOK 7th Edition & cập nhật đến 2026): Trong môi trường Agile/Hybrid, Product Owner là key stakeholder có quyền quyết định cao về sản phẩm. PM phải tailor (tùy chỉnh) kế hoạch truyền thông linh hoạt, ưu tiên sự đồng thuận và hiệu quả thay vì áp đặt (theo Principle 7: Optimize Risk Responses & Principle 11: Tailor Based on Context).

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

Đáp án đúng: Update the communications management plan based on the product owner's preferences and distribute to the team

Lý do 🛠️:

• Kế hoạch Quản lý Truyền thông là tài liệu sống (living document) phải được cập nhật dựa trên sở thích và nhu cầu của stakeholders (stakeholder preferences), đặc biệt Product Owner – người đại diện cho giá trị kinh doanh. Công cụ được "approved" nên an toàn và phù hợp.
• Hành động này tuân thủ quy trình Manage Communications và Monitor Communications (PMBOK 6th/7th), đảm bảo tất cả thành viên đội ngũ nhận được thông tin cập nhật qua distribute (phân phối), tránh xung đột và tăng hiệu quả truyền thông.
• Trong PMP 2026 (cập nhật Hybrid/Agile), ưu tiên stakeholder engagement qua việc điều chỉnh nhanh chóng mà không cần leo thang không cần thiết.

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

• Contact the sponsor to request direction regarding the communication tool to be used by the project team
  ❌ Sai vì: Việc liên hệ ngay sponsor (nhà tài trợ) để xin chỉ đạo là leo thang không cần thiết (escalation overuse). PM có thẩm quyền quản lý truyền thông hàng ngày và phải tự xử lý các vấn đề stakeholders nội bộ như Product Owner. Điều này vi phạm nguyên tắc PM empowerment (PMBOK 7th, Principle 3: Focus on Value), làm chậm trễ dự án và thể hiện thiếu chủ động.

• Update the communications management plan based on the product owner's preferences and distribute to the team
  ✅ Đúng như đã giải thích ở trên: Đây là hành động chuyên nghiệp, chủ động và phù hợp nhất, đảm bảo kế hoạch được cập nhật và chia sẻ đồng bộ, tôn trọng stakeholder mà không làm gián đoạn dự án.

• Suggest to the team to start using the communication tool suggested by the product owner
  ❌ Sai vì: Chỉ gợi ý (suggest) cho đội ngũ mà không cập nhật chính thức kế hoạch truyền thông có thể dẫn đến hỗn loạn (inconsistency), một số thành viên vẫn dùng email, gây nhầm lẫn. PMP yêu cầu formal update và approval cho thay đổi kế hoạch (PMBOK 7th, Models: Communications Models), không phải cách tiếp cận ad-hoc.

• Request the product owner to use email because using another tool will increase the workload
  ❌ Sai vì: Áp đặt (request/force) Product Owner dùng email là không tôn trọng stakeholder và vi phạm nguyên tắc Stakeholder Engagement (PMBOK 7th, Principle 10: Lead with Empathy). Lý do "tăng workload" là chủ quan, không dựa trên dữ liệu, và bỏ qua lợi ích của công cụ đã approved.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật 2026): Chapter 4: Project Integration Management (Tailoring Communications); The Team Playbook: Communications & Stakeholder Engagement.
• PMI Agile Practice Guide (2021): Section on Product Owner responsibilities và Daily Stand-ups/Communication Tools.
• PMP Exam Content Outline (2021+): Domain III: Business Environment (Stakeholder Management) & Domain IV: Delivery (Communications).
• Khuyến nghị: Tham khảo PMI.org cho Process Groups (Manage/Monitor Communications) để thực hành.

Hy vọng phân tích này giúp bạn ôn tập PMP hiệu quả! 🚀 Nếu cần thêm ví dụ, 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ủ đề Stakeholder Engagement trong PMP (Project Management Professional), tập trung vào giai đoạn Closing (Đóng dự án). Tình huống: Quản lý dự án của khách hàng (customer's project manager) thay đổi vào giai đoạn cuối cùng của dự án. Câu hỏi yêu cầu cách tốt nhất để quản lý dự án tránh trì hoãn việc đóng dự án (project closure delay).
✅ Mục tiêu chính: Đảm bảo sự chuyển giao suôn sẻ, phê duyệt cuối cùng và hoàn tất các hoạt động đóng dự án mà không bị gián đoạn do thay đổi nhân sự bên khách hàng. Theo PMBOK® Guide 7th Edition (và cập nhật đến 2026 theo PMI's The Standard for Project Management), việc thay đổi stakeholder (như project manager khách hàng) đòi hỏi hành động nhanh chóng để duy trì engagement, tránh rủi ro delay ở closure như phê duyệt tài liệu, nghiệm thu sản phẩm.

✅ Đáp án đúng: Update the stakeholder engagement plan

Lý do lựa chọn:
🛠️ Đây là hành động tối ưu và chủ động nhất theo nguyên tắc Manage Stakeholder Engagement (Process 13.3 trong PMBOK 6th, và Principle 5: Stakeholders trong 7th Edition). Khi stakeholder thay đổi (customer's PM mới), cần cập nhật ngay Stakeholder Engagement Plan để xác định thông tin liên lạc mới, mức độ engagement, và chiến lược tương tác (ví dụ: gửi giới thiệu, lịch họp handover). Điều này đảm bảo liên tục engagement, tránh delay ở closure (như ký acceptance, release resources). Không cập nhật có thể dẫn đến chậm trễ phê duyệt từ người mới.
📘 Nguồn tham khảo: PMBOK® Guide 7th Edition, trang 157-160 (Stakeholder Performance Domain); PMI's PMBOK® Guide – 6th Edition, 13.3.2.1.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên best practices PMP mới nhất:

• ✅ Update the stakeholder engagement plan
  🟢 Đúng vì: Như đã giải thích ở trên, đây là bước cốt lõi để điều chỉnh engagement với stakeholder mới, đảm bảo thông tin chảy đúng người, tránh delay closure. Hành động này phòng ngừa rủi ro và phù hợp với Tailoring trong dự án agile/hybrid.

• ❌ Review the latest project status report and update the stakeholders
  🔴 Sai vì: Việc xem báo cáo status mới nhất và cập nhật stakeholders là hoạt động thường quy (routine communication), không giải quyết cụ thể thay đổi PM khách hàng. Nó có thể hữu ích nhưng không tránh delay closure vì thiếu cập nhật plan engagement chính thức, dẫn đến người mới không được onboard đúng cách. Không phải hành động ưu tiên đầu tiên.

• ❌ Escalate the case to the customer's management team
  🔴 Sai vì: Escalate chỉ dùng khi có vấn đề lớn, xung đột (theo Escalate Issues process). Thay đổi PM là biến động bình thường, không cần escalate ngay – điều này có thể tạo xung đột không cần thiết, làm chậm closure hơn. Thay vào đó, nên xây dựng mối quan hệ với PM mới trước.

• ❌ Issue the project payment invoice to the customer in advance
  🔴 Sai vì: Phát hành hóa đơn thanh toán trước là hành động tài chính, không liên quan trực tiếp đến thay đổi PM hoặc closure delay. Nó có thể vi phạm contract terms (hợp đồng), gây tranh cãi pháp lý, và không giải quyết vấn đề engagement. Closure cần phê duyệt nghiệm thu trước khi invoice final.

🧠 Kết luận PMP: Trong giai đoạn cuối, ưu tiên Stakeholder Sphere để handover mượt mà. Áp dụng Earned Value Management hoặc lessons learned để kiểm tra delay risks nếu cần. Nếu bạn có thêm câu hỏi PMP, hãy hỏi nhé! 🚀