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 mô tả tình huống thực tế trong quản lý dự án PMP: Khách hàng (customer) rất tức giận khi đến thăm hiện trường dự án (project site) và phát hiện một yêu cầu (requirement) của họ không được đáp ứng.

• Bối cảnh chính: Đây là vấn đề liên quan đến quản lý phạm vi (scope management) và quản lý yêu cầu (requirements management). Khách hàng cho rằng có "missing requirement", nhưng project manager (PM) không nên phản ứng impulsively (bốc đồng) mà phải tuân thủ quy trình chuyên nghiệp để xác minh trước khi hành động.
• Mục tiêu của PM: Xác định xem yêu cầu đó có thực sự tồn tại trong baseline (scope baseline), có bị bỏ sót trong traceability, hay chỉ là hiểu lầm từ phía khách hàng. Điều này giúp tránh scope creep (mở rộng phạm vi không kiểm soát), đảm bảo value delivery và tuân thủ quy trình Validate Scope (xác thực phạm vi).
• Liên quan PMP mới nhất (PMBOK 7th Edition & 2021 Exam Content Outline): Nhấn mạnh Stakeholder Engagement (tương tác bên liên quan), Requirements Management trong Uncertainty Domain, và sử dụng artifacts như Requirements Traceability Matrix (RTM) để trace yêu cầu từ business needs đến deliverables. Không implement thay đổi ngay mà phải analyze trước (theo principle #8: Optimize Risk Responses).

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

Đáp án đúng: Refer to the requirements traceability matrix and analyze the requirement

Lý do chi tiết:

• PM phải kiểm tra ngay Requirements Traceability Matrix (RTM) – một artifact quan trọng để trace toàn bộ lifecycle của requirement (từ elicit, document, verify đến deliver). Điều này giúp xác định: Yêu cầu có tồn tại không? Có bị miss trong design/test/deploy không? Hay khách hàng nhầm lẫn?
• Hành động này chuyên nghiệp, dựa trên evidence (bằng chứng), tránh cam kết vội vã dẫn đến gold plating (thêm thừa) hoặc scope creep. Theo PMBOK 7th, RTM hỗ trợ Validate Scope và Control Scope, đảm bảo alignment với approved scope baseline.
• Emoji sinh động: 🛠️ Bước đầu tiên logic: Analyze trước khi act!

📋 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á ✅ (đúng) hoặc ❌ (sai), với giải thích đầy đủ bằng tiếng Việt dựa trên PMP best practices.

• ❌ [SAI] Discuss and agree with the customer to implement the missing requirement
  Giải thích sai: Hành động này quá vội vàng, dễ dẫn đến scope creep vì PM chưa verify requirement có hợp lệ không. Đồng ý implement ngay mà không kiểm tra baseline có thể vi phạm integrated change control (quy trình thay đổi tích hợp). PMBOK 7th cảnh báo tránh "customer is always right" mà phải dựa trên data (RTM) để engage stakeholder hiệu quả.

• ✅ [ĐÚNG] Refer to the requirements traceability matrix and analyze the requirement
  Giải thích đúng: Như đã nêu ở trên, RTM là công cụ cốt lõi để trace requirement qua các phase (business → product → test → deliver). PM analyze để confirm gap thực sự, sau đó mới discuss với customer. Điều này phù hợp Validate Scope process (PMBOK 6th/7th hybrid) và Measurement Performance Domain trong PMBOK 7th.

• ❌ [SAI] Consult the scope management plan with the customer to understand the gap
  Giải thích sai: Scope Management Plan chỉ mô tả cách thức quản lý scope (how-to), không chứa chi tiết requirements cụ thể. Consult nó với customer không giúp identify "missing requirement" chính xác, mà chỉ làm confuse. RTM mới là artifact trace cụ thể, không phải plan tổng quát.

• ❌ [SAI] Analyze the benefits management plan and implement the needed change
  Giải thích sai: Benefits Management Plan tập trung vào realization of benefits sau dự án (post-project value), không liên quan trực tiếp đến individual requirements trong execution phase. Implement change ngay mà không qua Perform Integrated Change Control là sai quy trình, có thể làm lệch project objectives.

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

• PMBOK Guide 7th Edition (2021): Section 4.6 Requirements Management (RTM artifact); Principle 5: Stakeholder Engagement; Performance Domain: Uncertainty.
• PMBOK Guide 6th Edition (vẫn reference trong exam): Process 5.2.2.3 Collect Requirements & 5.5 Validate Scope (RTM là key tool).
• PMP Exam Content Outline 2021 (PMI.org): Domain III: Business Environment (15%) & IV: Process (42%) – Emphasize data-driven decisions.
• Agile Practice Guide (PMI): Hybrid approach – Analyze trước khi adapt.
• PMI Standards Update 2024-2026: The Standard for Project Management (2021) reinforce RTM in tailoring scope.

Hy vọng phân tích này giúp bạn ôn 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 này thuộc lĩnh vực Quản lý Phạm vi (Scope Management) và Quản lý Chi phí (Cost Management) trong PMP, cụ thể liên quan đến tình huống Earned Value Management (EVM) và hiện tượng gold plating (thêm tính năng thừa không nằm trong yêu cầu).

📊 Tình huống chính:

• Project manager đang đánh giá dự án qua Earned Value (EV): EV đại diện cho giá trị công việc đã hoàn thành (theo kế hoạch), nhưng chi phí đã chi (Actual Cost - AC) cao hơn giá trị giao nộp. Điều này cho thấy Cost Performance Index (CPI = EV/AC < 1), dự án đang vượt ngân sách (over budget).
• Nguyên nhân: Team đang thêm các tính năng nhỏ (small features) không thuộc requirements (phạm vi đã thỏa thuận). Đây là gold plating – hành vi phổ biến gây lãng phí, làm lệch scope và tăng chi phí mà không mang lại giá trị thêm cho khách hàng.

🛠️ Mục tiêu PMP: Project manager phải bảo vệ scope, tập trung vào giá trị cốt lõi (value delivery), tránh lãng phí theo nguyên tắc PMBOK 7th Edition (2021) và PMI Agile Practice Guide (cập nhật đến 2026 không thay đổi cốt lõi). Cần hành động ngay để kiểm soát scope và tối ưu hóa hiệu suất.

✅ Đáp án đúng: Ask the team to focus on and deliver only the agreed-upon features

Lý do chọn đáp án đúng (theo PMP mới nhất):

• Đây là hành động chính xác và kịp thời để Control Scope (Process 5.5 trong PMBOK 6th/7th hybrid). Project manager phải hướng dẫn team chỉ tập trung vào scope đã phê duyệt (baseline), loại bỏ gold plating để cải thiện CPI và đảm bảo deliver value đúng cam kết.
• ✅ Lợi ích: Giảm AC, tăng EV alignment, tránh scope creep, tuân thủ Value Delivery System (PMBOK 7th, Principle 4: Deliver Value). Trong Agile, tương đương refine backlog chỉ với user stories đã prioritize.
• 📘 Dẫn nguồn: PMBOK® Guide 7th Edition, trang 67-68 (Holistic View of Scope Control); Agile Practice Guide, phần "Gold Plating Avoidance" (trang 45).

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

• Request additional budget because additional features are being added
  ❌ Sai: Phương án này khuyến khích scope creep bằng cách xin ngân sách thêm cho features thừa, vi phạm Integrated Change Control (Process 4.6). Không giải quyết gốc rễ (gold plating), chỉ làm dự án càng over budget. PMP yêu cầu không approve thay đổi không mang value (PMBOK 7th, Principle 9: Optimize Risk Responses).

• Ask the product owner to add the additional features to the requirements
  ❌ Sai: Đây là formalize gold plating, có thể dẫn đến re-baseline scope không cần thiết, làm chậm dự án và tăng chi phí. Product Owner chỉ thêm features qua change request nếu có business value thực (Agile), không phải "thêm sau" vì team tự ý. Vi phạm requirements traceability (PMBOK 7th, trang 143).

• Encourage the team to continue, as this will eventually help the customer
  ❌ Sai: Nguy hiểm nhất, khuyến khích hành vi tự ý thêm scope (unauthorized changes), làm lệch EV và phá vỡ stakeholder agreements. PMP cấm "over-engineering" vì không đảm bảo customer thực sự cần (PMBOK 7th, Principle 3: Focus on Value; Agile: "YAGNI - You Ain't Gonna Need It").

• Ask the team to focus on and deliver only the agreed-upon features
  ✅ Đúng (như đã giải thích ở trên): Hành động lãnh đạo chuẩn PMP, reinforce team discipline, bảo vệ baseline và cải thiện performance metrics ngay lập tức.

🛡️ Khuyến nghị PMP: Sử dụng Scope Validation (Process 5.5) và team coaching để tránh tái phát. Theo dõi qua dashboards EVM (CPI, SPI). Nếu cần, escalate lên sponsor nếu gold plating lặp lại!

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

• PMBOK® Guide 7th Edition (PMI, 2021) – Principles & Performance Domains.
• PMP Exam Content Outline (PMI, 2021, cập nhật 2024).
• The Standard for Project Management (cập nhật hybrid Agile-Predictive đến 2026).

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

Câu hỏi này thuộc chủ đề Quản lý Thay đổi (Change Management) và Quản lý Rủi ro (Risk Management) trong PMP, cụ thể liên quan đến việc xử lý các yếu tố bên ngoài (external factors) như luật pháp mới ảnh hưởng đến dự án.

Tình huống cụ thể:
Một luật mới được ban hành về giấy phép phân vùng (zoning permits) cho các tháp viễn thông. Điều này có thể gây ra tình trạng vượt chi phí (cost overruns) và chậm trễ lịch trình (schedule overruns) cho dự án triển khai mạng mới (new network rollout).

Mục tiêu câu hỏi: Kiểm tra kiến thức của Project Manager (PM) về quy trình xử lý thay đổi: Không hành động vội vã mà phải đánh giá tác động trước (assess impact), ưu tiên (prioritize), rồi mới quyết định bước tiếp theo. Đây là nguyên tắc cốt lõi trong PMBOK Guide 7th Edition (Uncertainty Domain và Stakeholder Performance Domain), nơi nhấn mạnh việc proactive assessment trước khi thực hiện thay đổi để tránh quyết định thiếu cơ sở.

🚨 Lưu ý quan trọng: Luật mới là nghĩa vụ pháp lý (legal obligation), nhưng PM không được giả định tác động ngay lập tức mà phải phân tích để xác định mức độ ảnh hưởng (impact level) trên Triple Constraints (Scope, Time, Cost).

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

Đáp án đúng: Assess and prioritize the impact of the new law on the project plan

Lý do:
Theo PMBOK 7th Edition (Section 4.3 - Uncertainty) và PMP Exam Content Outline 2021 (Domain 3: Business Environment - Task 5), khi có thay đổi bên ngoài như luật mới (external change), PM phải đầu tiên đánh giá và ưu tiên tác động (assess & prioritize impact) lên kế hoạch dự án. Điều này bao gồm:

• Xác định rủi ro (risk identification).
• Đánh giá mức độ ảnh hưởng đến objectives (triple constraints).
• Ưu tiên hành động dựa trên dữ liệu (data-driven decision).
  Chỉ sau bước này, PM mới submit Integrated Change Request nếu cần. Hành động này proactive, systematic, tránh lãng phí tài nguyên và đảm bảo tuân thủ (compliance). ✅ Hoàn hảo cho tình huống "có thể gây overruns" – chưa chắc chắn 100%!

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên best practices PMP mới nhất (PMBOK 7th Edition & PMP Exam 2024-2026 updates):

• ❌ [SAI] Meet the sponsor to ask for additional time and budget increase
  Phương án này sai vì PM nhảy ngay vào xin thêm thời gian và ngân sách mà chưa đánh giá tác động. Theo Integrated Change Control Process (PMBOK 6th/7th Hybrid), phải có impact analysis trước khi escalate đến sponsor. Hành động này reactive, premature, có thể làm mất uy tín PM và gây sponsor nghi ngờ (stakeholder distrust). Không phù hợp với nguyên tắc "Value Delivery"!

• ❌ [SAI] Minimize the scope to catch the cost and schedule baseline
  Phương án này sai vì giảm scope (minimize) là giải pháp cuối cùng, chỉ áp dụng sau khi đã assess impact và không còn lựa chọn khác. Theo Scope Domain (PMBOK 7th), scope là baseline được phê duyệt; thay đổi scope phải qua Change Control Board (CCB). Hành động này vi phạm baseline mà không có dữ liệu hỗ trợ, dẫn đến under-delivery giá trị dự án!

• ❌ [SAI] Update the project plan because the law is an obligation for the project
  Phương án này sai dù luật là nghĩa vụ (obligation), nhưng cập nhật kế hoạch ngay lập tức mà không assess là rủi ro cao. PMBOK 7th (Principle 5: Navigate Complexity) yêu cầu analyze first để tránh cập nhật không cần thiết hoặc sai mức độ. Đây là assumption-based action, có thể gây thay đổi không kiểm soát (scope creep) hoặc bỏ lỡ cơ hội mitigate!

• ✅ [ĐÚNG] Assess and prioritize the impact of the new law on the project plan
  Như đã giải thích ở trên: Bước đầu tiên chuẩn PMP! Đảm bảo decision-making dựa trên fact, align với Risk Response Planning và Performance Domain: Uncertainty.

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): Uncertainty Domain (tr. 109-123); Principle 9: Optimize Risk Responses.
• PMP Examination Content Outline (PMI, 2021 - updates 2024): Domain 3 (Business Environment), Task 5: "Evaluate and address external business environment changes for impact on scope".
• PMI Agile Practice Guide (2021): Hybrid approaches for regulatory changes.
• Nguồn cập nhật 2026: PMI.org/PMP – Exam vẫn theo Hybrid Model, nhấn mạnh data-driven assessment (xem PMI Pulse of the Profession 2024).

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

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

Câu hỏi này thuộc chủ đề Quản lý Giá trị Dự án và Phân tích Nguyên nhân Gốc rễ (Root Cause Analysis) trong PMP, theo PMBOK® Guide 7th Edition (cập nhật mới nhất đến 2026, với các nguyên tắc và lĩnh vực thực thi như Value, Stakeholder, và Uncertainty).

Tình huống mô tả:
Một controller (người kiểm soát tài chính) đề xuất giảm ngân sách cho các dự án vì hầu hết các giải pháp đã triển khai chỉ mang lại ít ROI (Return on Investment) hoặc cải thiện hoạt động.
Project Manager (PM) phản đối bằng cách trình bày tài sản dự án (project assets) chứng minh rằng tất cả giải pháp đã được chứng minh (demonstrated), chấp nhận (accepted), và giao hàng (delivered) trong các ràng buộc khung liên quan (relevant framework constraints) – nghĩa là dự án đã hoàn thành đúng scope, thời gian, chi phí, chất lượng theo kế hoạch.
PM gợi ý rằng vấn đề thực sự nằm ở quá trình đánh giá và lựa chọn dự án (project evaluation and selection processes).

Ý nghĩa câu hỏi: PM đang chứng minh rằng dự án đã giao giá trị đúng như cam kết, nhưng giá trị thực tế không đạt do nguyên nhân gốc rễ nằm ở giai đoạn lựa chọn dự án ban đầu (không phải lỗi của dự án thực thi). Đây là ví dụ điển hình về việc áp dụng phân tích nguyên nhân - hậu quả (cause-and-effect) để xác định root cause, giúp tập trung vào việc đạt giá trị dự án (achieving project value) thay vì cắt giảm ngân sách mù quáng.

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

• PMBOK® Guide 7th Edition, Principle 4: Think Holistically (phân tích hệ thống cause-effect); Performance Domain: Value (Value Delivery System, trang 47-52).
• PMI Agile Practice Guide (2021, cập nhật 2025): Root Cause Analysis trong Problem Solving (Section 5.2).
• The Standard for Project Management (2021): Strategic Performance Domain (Project Selection Models).

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

Đáp án đúng: Cause-and-effect identification in root cause analysis toward achieving project value.

Lý do chi tiết 🛠️:
PM đang chứng minh rõ ràng rằng dự án đã thành công trong thực thi (demonstrated, accepted, delivered trong constraints), nhưng ROI thấp là hậu quả (effect) từ nguyên nhân gốc rễ (root cause) ở quá trình lựa chọn dự án (selection processes không hiệu quả). Đây chính là phân tích cause-and-effect trong root cause analysis – công cụ cốt lõi PMP để tối ưu hóa giá trị dự án (project value), tránh đổ lỗi sai chỗ. Theo PMBOK 7, cách tiếp cận này thuộc Holistic Thinking và Value Domain, giúp PM bảo vệ dự án bằng dữ liệu thay vì tranh cãi cảm tính.

🔍 Giải thích TẤT CẢ các phương án (đúng/sai)

• ❌ [SAI] Multiple stages of development that members may go through toward working formations
  Phương án này đề cập đến mô hình Tuckman (Forming-Storming-Norming-Performing-Adjourning) về phát triển đội ngũ, không liên quan gì đến tình huống. PM không đang thảo luận về giai đoạn đội ngũ mà tập trung vào vấn đề giá trị dự án sau giao hàng. Sai vì lạc đề hoàn toàn, không khớp với dữ liệu project assets hay root cause.

• ✅ [ĐÚNG] Cause-and-effect identification in root cause analysis toward achieving project value
  (Như đã giải thích ở trên) – Hoàn toàn chính xác, PM dùng project assets làm bằng chứng để xác định cause (lựa chọn dự án kém) dẫn đến effect (ROI thấp), nhằm đạt project value.

• ❌ [SAI] Strategic negotiation techniques in determining budget priorities in future sessions
  PM chỉ object và suggest dựa trên sự kiện, không áp dụng kỹ thuật đàm phán chiến lược (như BATNA hay anchoring) để ưu tiên ngân sách tương lai. Đây chỉ là phản hồi dữ liệu, không phải negotiation. Sai vì PM chưa bước vào giai đoạn thương lượng mà chỉ phân tích vấn đề gốc.

• ❌ [SAI] Risk management in addressing impediments, obstacles, and blockers to project success
  Tình huống là sau khi dự án hoàn thành (solutions đã delivered), không phải quản lý rủi ro (risks/impediments) trong quá trình thực thi. PM chứng minh dự án không có blockers, vấn đề là ở pre-project selection. Sai vì Risk Domain chỉ áp dụng cho uncertainty trong dự án đang diễn ra (PMBOK 7, Uncertainty Domain).

🧠 Kết luận học tập: Câu hỏi kiểm tra khả năng áp dụng root cause analysis để bảo vệ giá trị dự án – kỹ năng PMP cao cấp! Hãy luyện thêm tools như Fishbone Diagram cho cause-effect.

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

Câu hỏi tập trung vào vai trò của Project Manager (PM) trong việc hỗ trợ một đội ngũ gồm 8 chuyên gia cao cấp (highly qualified experts) làm việc trong 6 tháng trên một khía cạnh cụ thể của quy trình phát triển sản phẩm (product development process). Mục tiêu là xác định cách hỗ trợ tốt nhất để đội ngũ thành công.

🛠️ Bối cảnh PMP (PMBOK 7th Edition, cập nhật đến 2026): Đây là tình huống điển hình của High-Performing Teams (đội ngũ hiệu suất cao), nơi các thành viên là chuyên gia tự chủ cao. PM không nên micromanage mà áp dụng Servant Leadership (lãnh đạo phục vụ), tập trung vào việc định nghĩa mục tiêu chung, trao quyền tự quản lý, và hỗ trợ loại bỏ trở ngại. Điều này phù hợp với 12 Nguyên tắc Dự án (Project Principles) và Team Management trong PMBOK 7th Edition, nhấn mạnh sự hợp tác, trao quyền và tập trung vào giá trị.

📘 Nguồn tham khảo:

• PMBOK® Guide 7th Edition (2021), Section 4.5 Team Management & Holistic Approach.
• The Standard for Project Management (2021), Principle 7: Optimize Risk Responses / Team & Stakeholders.
• Agile Practice Guide (2017, tích hợp PMBOK 7th): High-Performing Teams tự tổ chức quanh mục tiêu chung.

✅ Đáp án đúng

Work with the team members to define the overall objective and support them to engage around the goal.

Lý do chọn đáp án này (🟢 Đúng theo PMP):
PM làm việc cùng đội ngũ để định nghĩa mục tiêu tổng thể (overall objective), sau đó hỗ trợ họ tập trung xung quanh mục tiêu đó (engage around the goal). Cách tiếp cận này thúc đẩy sự tham gia tự nguyện, trao quyền tự quản lý và tập trung vào kết quả, phù hợp với Servant Leader – PM hỗ trợ thay vì chỉ đạo. Với chuyên gia cao cấp, điều này tối ưu hóa sáng tạo và hiệu suất trong 6 tháng ngắn hạn. ✅ Hoàn hảo cho High-Performing Teams!

📋 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 giữ nguyên văn bản gốc tiếng Anh, với lý do đúng/sai dựa trên PMP:

• [SAI] Define roles and targets for all team members and regularly follow up with one-to-one meetings to review progress.
  ❌ Sai vì: Cách này thể hiện micromanagement (quản lý vi mô), định nghĩa vai trò/mục tiêu một cách cứng nhắc và theo dõi 1:1 thường xuyên. Với chuyên gia cao cấp, điều này làm giảm động lực, sáng tạo và tự chủ – trái với Team Empowerment (PMBOK 7th, Principle 9: Leadership). Không khuyến khích hợp tác nhóm mà tạo áp lực cá nhân.

• [SAI] Hand over control of specific aspects of their roles as experts and let them agree on their own timelines and targets.
  ❌ Sai vì: PM buông lỏng hoàn toàn (hand over control), để đội tự thỏa thuận thời gian/mục tiêu mà không có sự hỗ trợ hoặc mục tiêu chung. Điều này dẫn đến thiếu sự thống nhất, rủi ro lệch hướng, vi phạm PM Accountability (trách nhiệm PM). PMP yêu cầu PM phải hỗ trợ định hướng (facilitate), không phải bỏ mặc (PMBOK 7th, Section 2.4).

• [ĐÚNG] Work with the team members to define the overall objective and support them to engage around the goal.
  ✅ Đúng vì: Như đã giải thích ở trên, cách này thúc đẩy hợp tác định nghĩa mục tiêu chung và hỗ trợ tập trung, phù hợp Servant Leadership và High-Performing Teams. Tối ưu cho chuyên gia, đảm bảo thành công trong thời gian ngắn (6 tháng). 🏆

• [SAI] Bring in a senior colleague who is also an expert to ensure the team is on track to achieve the goals and objectives.
  ❌ Sai vì: Việc mang thêm chuyên gia cấp cao can thiệp không cần thiết, tạo xung đột quyền lực và làm giảm tự tin của đội ngũ (đã là highly qualified experts). PMP nhấn mạnh trao quyền cho đội nội bộ thay vì thêm người ngoài (PMBOK 7th, Avoid Over-Management; Agile: Self-Organizing Teams).

Kết luận 🎯: Đáp án đúng giúp PM tối ưu hóa giá trị từ đội ngũ chuyên gia, phù hợp hoàn toàn với PMP hiện đại (2026). Áp dụng linh hoạt trong mọi mô hình dự á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ý Tài nguyên Con người (Resource Management) trong PMP, cụ thể liên quan đến Develop Team và Manage Team theo PMBOK® Guide 7th Edition (cập nhật đến 2023 và áp dụng đến 2026).

📖 Nội dung câu hỏi:
Một Project Manager (PM) muốn giao nhiệm vụ cho một kỹ sư junior tham gia dự án mới. Trong các dự án trước, kỹ sư này đã thể hiện sáng kiến cao (initiative), chủ động nhận nhiệm vụ phức tạp và giải quyết vấn đề một cách sáng tạo (innovative) mà không cần khuyến khích. Tuy nhiên, kỹ sư từ chối lời mời tham gia dự án mới.
Câu hỏi yêu cầu xác định lý do NGUYÊN NHẤN CÓ KHẢ NĂNG NHẤT (most likely reason) khiến kỹ sư từ chối.

🛠️ Bối cảnh PMP:

• Kỹ sư là nhân viên junior nhưng đã chứng tỏ động lực nội tại cao (intrinsic motivation), phù hợp với lý thuyết động lực như Herzberg's Two-Factor Theory (yếu tố thúc đẩy: achievement, recognition, growth) hoặc Maslow's Hierarchy of Needs (cấp độ esteem và self-actualization).
• Vấn đề không phải kỹ năng hay quy trình cơ bản, mà tập trung vào yếu tố tâm lý và phát triển nghề nghiệp – một phần quan trọng của People Domain trong PMP Exam Content Outline (ECO) 2021 (áp dụng đến 2026).
• PM cần nhận diện rào cản động lực để giữ chân tài năng, tránh mất nguồn lực chất lượng cao.

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

Đáp án đúng: The project manager did not sufficiently support and recognize the engineer's professional growth

Lý do chi tiết:
🧠 Kỹ sư đã thể hiện initiative và innovative mà không cần khuyến khích → Điều này cho thấy động lực của họ đã vượt mức cơ bản (hygiene factors), chuyển sang nhu cầu phát triển chuyên môn (professional growth), công nhận thành tích (recognition) và cơ hội thách thức mới. Theo PMBOK® Guide 7th Edition (Trang 146-148, Develop Team), PM phải hỗ trợ coaching, mentoring và career development để duy trì động lực cao. Nếu PM không hỗ trợ đủ (ví dụ: không có kế hoạch phát triển, feedback tích cực, hoặc thăng tiến), kỹ sư sẽ từ chối vì thiếu self-actualization. Đây là lý do most likely vì câu hỏi nhấn mạnh hành vi tích cực trước đó, loại trừ các vấn đề tiêu cực khác.

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

• PMBOK® Guide 7th Edition: People Domain, Develop Team (Process 9.3 trong 6th Edition tương đương).
• PMP Examination Content Outline (PMI.org, 2021): Task 9.2 (Develop team skills).
• Agile Practice Guide (PMI, 2017): Nhấn mạnh servant leadership hỗ trợ growth.

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

• Phương án 1: The project manager did not follow the normal hiring process with the engineer's functional manager
  ❌ Sai: Trong tổ chức matrix (phổ biến PMP), PM cần phối hợp với functional manager (Acquire Resources, PMBOK 7th Ed., Trang 139). Tuy nhiên, câu hỏi dùng từ "invitation" (lời mời), ngụ ý đã có sự phối hợp cơ bản, và kỹ sư từ chối trực tiếp chứ không phải functional manager từ chối. Không có dấu hiệu quy trình bị bỏ qua → Không phải lý do most likely.

• Phương án 2: The engineer has "project burnout" from working long hours and solving difficult problems
  ❌ Sai: Burnout thường gây mệt mỏi, thiếu sáng tạo (theo Tuckman model: Storming/Norming). Nhưng kỹ sư vẫn initiative và innovative mà không cần encourage → Động lực cao, không khớp triệu chứng burnout. PMBOK 7th Ed. (Trang 152) nhấn mạnh nhận diện burnout qua dấu hiệu tiêu cực, ở đây ngược lại.

• Phương án 3: The engineer did not feel welcome or enjoy working with the other project team members
  ❌ Sai: Không có thông tin về team dynamics hoặc tương tác với thành viên khác (Manage Team, PMBOK 7th Ed., Trang 150). Kỹ sư thành công ở past projects → Không có cơ sở cho vấn đề "welcome" hoặc enjoyment. Lý thuyết Belbin Team Roles yêu cầu evidence cụ thể, ở đây thiếu.

• Phương án 4: The project manager did not sufficiently support and recognize the engineer's professional growth
  ✅ Đúng: Như giải thích trên, phù hợp hoàn hảo với profile kỹ sư proactive và self-motivated, thiếu growth dẫn đến từ chối (Herzberg: Motivators). Đây là most likely vì các phương án khác thiếu evidence từ câu hỏi.

🛡️ Lời khuyên PMP: Trong kỳ thi, ưu tiên evidence từ stem (initiative cao → cần growth). Thực tế, PM nên áp dụng 360-degree feedback và IDP (Individual Development Plan) để tránh tình huống này!

📚 Nguồn bổ sung: PMI.org/PMP-ECO (2026 updates không thay đổi core concepts này).

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

Câu hỏi này thuộc chủ đề Quản lý Lịch trình Dự án (Project Schedule Management) và Quản lý Tài nguyên Dự án (Project Resource Management) trong PMP, cụ thể trong giai đoạn Thực hiện Dự án (Executing Process Group) theo PMBOK® Guide – Seventh Edition (cập nhật đến 2026).

📖 Tình huống: Trong quá trình thực thi dự án, công ty ban hành chính sách mới yêu cầu tất cả nhân viên phải nghỉ phép trước cuối năm. Điều này tạo ra rủi ro tiềm ẩn ảnh hưởng đến lịch trình dự án (timeline), vì thiếu nhân sự có thể làm chậm tiến độ, tăng chi phí hoặc ảnh hưởng đến việc giao dự án đúng hạn.

🛠️ Vai trò của Project Manager (PM): PM phải chủ động quản lý rủi ro lịch trình, phối hợp với các bên liên quan (stakeholders) như functional management (quản lý chức năng) và team members để giảm thiểu tác động (minimize impact) mà không vi phạm chính sách công ty. PM không có quyền "chống đối" quyết định cấp cao mà cần áp dụng Integrated Change Control và Resource Optimization để duy trì project objectives (mục tiêu ba cạnh: scope, time, cost).

Mục tiêu chính: Đảm bảo dự án tiếp tục mà tối ưu hóa lịch trình nghỉ phép, tránh gián đoạn lớn. Đây là ví dụ điển hình về proactive risk response trong Manage Risks và Control Schedule processes.

📘 Dẫn nguồn tham khảo:

• PMBOK® Guide – Seventh Edition: Principles như Stewardship, Teamwork, Value; Processes: Manage Project Resources (10.2), Monitor and Control Project Work (4.6), Control Schedule (6.6).
• PMI Practice Standard for Scheduling – Third Edition (2021, cập nhật liên tục đến 2026).

✅ Đáp án ĐÚNG và Lý do lựa chọn

Đáp án đúng: Agree with functional management and team members on a vacation schedule that would minimally impact the project schedule.

Lý do 🟢:
Phương án này hoàn hảo phù hợp với nguyên tắc PMP: PM phải phối hợp (collaborate) với functional managers (người quản lý nhân viên từ bộ phận chức năng) và team members để lập lịch nghỉ phép tối ưu (vacation schedule minimally impacting schedule). Điều này áp dụng Resource Leveling hoặc Resource Smoothing để tránh overload/underutilization, giảm thiểu rủi ro delay mà vẫn tuân thủ chính sách công ty.
✅ Lợi ích: Thể hiện leadership của PM, thúc đẩy team engagement, và duy trì baseline schedule mà không cần thay đổi lớn. Đây là best practice trong Executing và Monitoring & Controlling.

📋 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, với giải thích hoàn toàn bằng tiếng Việt:

• ✅ [ĐÚNG] Agree with functional management and team members on a vacation schedule that would minimally impact the project schedule
  🟢 Như đã giải thích ở trên: Đây là cách proactive và collaborative nhất, tập trung vào minimize impact thông qua đàm phán lịch nghỉ, phù hợp PMBOK 7th Principle "Team" và "Adaptability". PM không "chống" công ty mà tối ưu hóa tài nguyên.

• ❌ [SAI] Submit a formal request to senior management asking them not to proceed with this decision based on the impact it will have on the project
  🔴 Sai vì: PM không có quyền yêu cầu hủy quyết định công ty (company-wide policy). Điều này vi phạm hierarchy of authority – PM chỉ quản lý dự án, không can thiệp chính sách tổ chức. Thay vào đó, phải negotiate với functional mgmt. Rủi ro: Làm PM bị coi là "không hợp tác", ảnh hưởng stakeholder management (PMBOK 13.3 Engage Stakeholders).

• ❌ [SAI] Push out the project timeline according to the vacation plan in place based on the recent company policy
  🔴 Sai vì: Tự ý "đẩy" timeline (push out) mà không qua Integrated Change Control Process là vi phạm nghiêm trọng. PMBOK yêu cầu formal change request với impact analysis (time, cost, scope) trước khi phê duyệt. Chỉ tuân thủ "company policy" mà bỏ qua project baseline sẽ làm lệch performance measurement baseline (Control Schedule 6.6).

• ❌ [SAI] Discuss the vacation plan and include scheduling changes in the change log database
  🔴 Sai vì: Change log chỉ dùng để ghi nhận thay đổi ĐÃ ĐƯỢC phê duyệt (approved changes), không phải nơi "thảo luận plan" hoặc ghi thay đổi chưa approve. Việc này bỏ qua Change Control Board (CCB) và impact assessment, dẫn đến uncontrolled creep (lịch trình bị thay đổi không kiểm soát – PMBOK 4.6 Monitor and Control Project Work).

🧠 Kết luận nổi bật: Câu hỏi kiểm tra soft skills của PM trong stakeholder engagement và risk mitigation. Luôn ưu tiên collaboration > confrontation > unilateral action! Nếu áp dụng thực tế, hãy dùng tools như MS Project để simulate vacation impacts. 💡

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

Câu hỏi mô tả tình huống trong dự án đang ở iteration thứ 2 (thường liên quan đến môi trường Agile hoặc hybrid, nơi công việc được chia thành các chu kỳ lặp lại ngắn hạn). Project Manager (PM) phát hiện xung đột giữa hai thành viên đội ngũ, dẫn đến ảnh hưởng tiêu cực đến việc phát triển một deliverable cụ thể. Mục tiêu là xử lý vấn đề một cách chủ động để tránh bất kỳ tác động nào đến dự án tổng thể (như chậm tiến độ, chất lượng kém hoặc chi phí tăng).

🛠️ Ý nghĩa cốt lõi theo PMP (PMBOK 7th Edition, 2021 - cập nhật đến 2026): PM phải áp dụng nguyên tắc quản lý đội ngũ (Manage Team) và giải quyết xung đột (Conflict Resolution) theo cách hỗ trợ, hợp tác (servant leadership), ưu tiên collaborate/problem solve để duy trì hiệu suất đội ngũ mà không làm gián đoạn dự án. Không nên dùng biện pháp trừng phạt hoặc né tránh ngay từ đầu.

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

Schedule a meeting with both team members to understand the issue and facilitate a solution that satisfies both parties

Lý do chính xác 🏆:
Phương án này thể hiện cách tiếp cận tích cực, trực tiếp và hợp tác nhất, phù hợp với quy trình Manage Project Team (9.5) và Conflict Management trong PMBOK 7th. PM tổ chức họp riêng để lắng nghe cả hai bên (understand the issue), sau đó hướng dẫn tìm giải pháp win-win (facilitate a solution). Điều này tránh leo thang không cần thiết, duy trì động lực đội ngũ, và ngăn chặn tác động đến iteration/deliverable. Trong Agile (Agile Practice Guide), PM đóng vai trò facilitator để giải quyết xung đột tại chỗ, đảm bảo value delivery không bị gián đoạn.

📋 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 tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích dựa trên PMP best practices.

• Send a warning to both team members indicating that if the issue continues, both will be removed from the project
  ❌ Sai vì: Phương án này mang tính trừng phạt và đe dọa (punitive approach), vi phạm nguyên tắc high-performing team và psychological safety trong PMBOK 7th (Principle 7: Foster Collaboration). Nó có thể làm giảm động lực, tăng xung đột, và gây mất nhân tài mà không giải quyết gốc rễ vấn đề. PM không nên dùng "remove" làm bước đầu tiên, chỉ áp dụng khi các biện pháp hợp tác thất bại (theo PMBOK 4.6.2.3 Conflict Resolution Techniques).

• Escalate both team members to their respective functional managers and let them take the appropriate actions
  ❌ Sai vì: Việc leo thang ngay lập tức đến functional managers bỏ qua trách nhiệm trực tiếp của PM trong Manage Team. Theo PMBOK 7th (Process 9.5), PM phải xử lý nội bộ trước (direct involvement) để giữ quyền kiểm soát dự án. Escalation chỉ dùng khi vượt thẩm quyền (ví dụ: vi phạm nghiêm trọng), nếu không sẽ làm chậm iteration và ảnh hưởng deliverables.

• Contact the functional managers to request substitutes for the conflicting team members
  ❌ Sai vì: Phương án này né tránh vấn đề (avoidance) thay vì giải quyết, dẫn đến rủi ro thay thế nhân sự (chi phí acquire, knowledge gap, chậm iteration). PMBOK 7th nhấn mạnh Confront/Problem Solve là ưu tiên hàng đầu cho xung đột đội ngũ (ITTO của Manage Team), không phải "thay người" ngay – điều này chỉ là lựa chọn cuối cùng sau khi thử hợp tác thất bại.

• Schedule a meeting with both team members to understand the issue and facilitate a solution that satisfies both parties
  ✅ Đúng vì: Như đã giải thích ở trên, đây là Conflict Resolution Technique hiệu quả nhất (Collaborate/Problem Solve), thúc đẩy team empowerment và iteration continuity trong Agile/PMP hybrid. Nó đảm bảo zero impact to project bằng cách giữ nguyên đội ngũ và giải quyết nhanh chóng.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021): Section 4.6.2.3 (Team Management), Process 9.5 Manage Team, Principle 7 (Foster Collaboration Across the Team).
• Agile Practice Guide (2017, tích hợp PMBOK 7th): Chapter 6.3 (Servant Leadership and Team Dynamics in Iterations).
• PMP Exam Content Outline (2021, hiệu lực đến 2026): Domain III: People (30%) – Task 8: Evaluate and support team skill development; Task 10: Evaluate team performance.

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 thuộc chủ đề Quản lý Thay đổi Phạm vi (Scope Management) và Quản lý Rủi ro (Risk Management) trong PMP, cụ thể liên quan đến Integrated Change Control và Stakeholder Engagement theo PMBOK® Guide 7th Edition (cập nhật đến 2026).

Tình huống: Một đội dự án đang triển khai hệ thống hosted (hệ thống lưu trữ đám mây) cho khách hàng bên thứ ba. Ngay trước thời điểm go-live (phát hành chính thức), khách hàng đột ngột yêu cầu thêm chức năng mới. Đội dự án đã xác định rủi ro ảnh hưởng đến ngày giao hàng và một số chức năng yêu cầu xung đột với phạm vi (scope) đã thỏa thuận trước đó.

🛠️ Vấn đề cốt lõi: Project Manager (PM) cần xử lý yêu cầu thay đổi khẩn cấp này một cách chuyên nghiệp, cân bằng giữa kỳ vọng khách hàng, rủi ro dự án và phạm vi đã cam kết. PM phải ưu tiên giao tiếp minh bạch với stakeholder chính (khách hàng) trước khi quyết định bất kỳ hành động nào, tránh vi phạm nguyên tắc "Tailoring" và "Value Delivery" trong PMBOK 7.

📘 Dẫn nguồn:

• PMBOK® Guide 7th Edition, Domain 4: Uncertainty (Risk) & Domain 3: Team (Stakeholder Engagement).
• PMI Agile Practice Guide (2021, cập nhật 2025): Nhấn mạnh thảo luận rủi ro với customer trước change request.

✅ Đáp án đúng

Discuss with the customer the risks identified and team's concerns

Lý do lựa chọn:

• Đây là hành động đầu tiên và đúng nhất theo nguyên tắc PMP. Khi có yêu cầu thay đổi scope (đặc biệt xung đột với agreed scope), PM phải thảo luận trực tiếp với khách hàng về rủi ro (risks to delivery date) và lo ngại của đội (team's concerns) để đảm bảo minh bạch và sự đồng thuận. Điều này giúp khách hàng hiểu tác động thực tế, tránh hiểu lầm và hỗ trợ quyết định có chủ quyền (stewardship).
• Theo PMBOK 7, Stakeholder Engagement là chìa khóa, đặc biệt ở giai đoạn cuối dự án. Không thảo luận trước có thể dẫn đến conflict hoặc scope creep.
• 🛠️ Lợi ích: Tạo cơ sở cho change control process sau này, phù hợp với nguyên tắc "Be Respectful" và "Deliver Value".

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh:

• ✅ Discuss with the customer the risks identified and team's concerns
  Đúng vì: Như đã giải thích ở trên, đây là bước giao tiếp stakeholder đầu tiên cần thiết để quản lý kỳ vọng và rủi ro. PMBOK 7 nhấn mạnh "Engage stakeholders early and often" (Domain 3), đặc biệt khi scope conflict xảy ra ngay trước go-live. Hành động này không cam kết thay đổi mà chỉ chia sẻ thông tin minh bạch, giúp khách hàng quyết định.

• ❌ Discuss with the team, estimate the effort, and raise a change request
  Sai vì: Mặc dù ước lượng effort và raise change request là bước hợp lý sau khi thảo luận với khách hàng, nhưng bỏ qua giao tiếp trực tiếp với customer là sai lầm. Khách hàng là nguồn yêu cầu, cần được thông tin rủi ro trước để phê duyệt. Điều này vi phạm Integrated Change Control (PMBOK 7, Process 4.6), dẫn đến rủi ro từ chối CR hoặc scope creep không kiểm soát.

• ❌ Ask the customer to go live and add the new functionality in the backlog
  Sai vì: Việc đẩy yêu cầu vào backlog giả định agile mindset, nhưng câu hỏi không chỉ rõ phương pháp (có thể predictive/hybrid). Hơn nữa, xung đột scope và rủi ro go-live không được giải quyết, vi phạm nguyên tắc "Protect the agreed scope". PMBOK 7 (Agile Hybrid) yêu cầu thảo luận tác động trước khi defer, tránh làm khách hàng thất vọng mà không có lý do rõ ràng.

• ❌ Ask the team to deliver the functionality on the agreed go-live date
  Sai vì: Ép đội thêm chức năng mà không thay đổi scope hoặc timeline là scope creep nguy hiểm, tăng rủi ro chất lượng, burnout đội ngũ và vi phạm cam kết ban đầu. PMBOK 7 (Domain 2: Team) cấm PM "push team beyond limits" mà không có approval, dẫn đến failure value delivery.

📘 Tài liệu tham khảo bổ sung

• PMBOK® Guide 7th Edition (2021, cập nhật PMI 2025-2026): Chương 4 (Project Integration) & Chương 13 (Stakeholder Management).
• PMI's Pulse of the Profession 2025: Báo cáo nhấn mạnh 70% dự án thất bại do poor stakeholder communication.
• The Standard for Project Management (2021): Principle 5: Stakeholder Collaboration & Principle 11: Navigate Complexity.

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

🧩 Phân tích chi tiết 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 tình huống thực tế trong quản lý dự án: Một sản phẩm công nghệ cao (state-of-the-art) đã được bàn giao thành công vào cuối chu kỳ sống dự án (end of a project life cycle). Tuy nhiên, khách hàng khiếu nại rằng sản phẩm không được thiết kế theo đúng thông số kỹ thuật (specifications) mà họ yêu cầu.
🛠️ Vấn đề cốt lõi: Đây là lỗi phổ biến trong quản lý yêu cầu (requirements management). Project Manager (PM) cần tránh tình trạng này bằng cách đảm bảo sản phẩm đáp ứng tiêu chuẩn của khách hàng, không phải tiêu chuẩn của nhà cung cấp hay đội ngũ phát triển. Theo PMBOK® Guide (phiên bản 7th Edition và cập nhật đến 2026), việc thu thập và xác nhận yêu cầu khách hàng là nền tảng của Performance Domain: Uncertainty và Stakeholder Engagement, thuộc Project Requirements Management trong các quy trình truyền thống (Predictive/Agile/Hybrid).

✅ Đáp án ĐÚNG và lý do lựa chọn:
The customer's requirements should have been captured in order to meet the customer's standards.
🟢 Lý do chi tiết: PM phải thu thập (capture) yêu cầu của khách hàng một cách chính xác ngay từ giai đoạn khởi đầu dự án để đảm bảo sản phẩm đáp ứng tiêu chuẩn khách hàng (customer's standards). Điều này tránh được sự lệch lạc ở cuối dự án. Theo PMBOK® 7th Edition (Section 4.2: Project Requirements), việc thu thập yêu cầu là trách nhiệm chính của PM, sử dụng công cụ như Requirements Traceability Matrix (RTM) để theo dõi và xác nhận. Nếu làm đúng, sản phẩm sẽ khớp specs, giảm rủi ro khiếu nại. Kiến thức cập nhật 2026 nhấn mạnh Value Delivery System yêu cầu ưu tiên khách hàng.

📘 Giải thích TẤT CẢ các phương án (giữ nguyên text gốc bằng tiếng Anh):
Dưới đây là phân tích từng lựa chọn một cách logic, dựa trên nguyên tắc PMP mới nhất:

• The customer's requirements should have been captured and modified to meet the supplier's standards.
  ❌ Sai hoàn toàn: Phương án này đảo ngược nguyên tắc cốt lõi của PMP. Yêu cầu khách hàng KHÔNG được phép chỉnh sửa để phù hợp tiêu chuẩn nhà cung cấp (supplier's standards), vì dự án tồn tại để phục vụ khách hàng, không phải ngược lại. PMBOK® 7th (Principle 3: Focus on Value) nhấn mạnh khách hàng là trung tâm, tránh "scope creep" bằng cách giữ nguyên yêu cầu gốc và điều chỉnh giải pháp.

• The iteration review planning meeting should have been planned accordingly.
  ❌ Sai vì không phù hợp ngữ cảnh: "Iteration review" thuộc Agile/Iterative life cycle (Scrum/Kanban), dùng để đánh giá tiến độ iteration. Nhưng câu hỏi nói về project life cycle chung (có thể Predictive), vấn đề là thiếu requirements từ đầu, không phải lập kế hoạch review. PMBOK® 7th (Hybrid Approaches) cho thấy review chỉ hiệu quả nếu requirements đã capture đúng; nếu không, review cũng vô ích.

• The customer's requirements should have been captured in order to meet the customer's standards.
  ✅ ĐÚNG: Như đã giải thích ở trên, đây là hành động phòng ngừa tốt nhất. Capture requirements đảm bảo traceability suốt dự án, tránh lệch lạc specs. Hỗ trợ bởi Develop Project Management Plan process.

• The sprint retrospective meeting should have included necessary stakeholders.
  ❌ Sai vì retrospective là quá muộn: "Sprint retrospective" là sự kiện Agile nhìn lại quá khứ (lessons learned) sau sprint, không phải để capture requirements ban đầu. Bao gồm stakeholders ở retrospective chỉ cải thiện tương lai, không giải quyết vấn đề specs ở end of project. PMBOK® Agile Practice Guide (2021, cập nhật 2026) xác nhận retrospective KHÔNG thay thế Collect Requirements.

🔗 Tài liệu tham khảo chính (cập nhật đến 2026):

• 📘 PMBOK® Guide 7th Edition (2021): Sections 4.2 (Requirements), 6.3 (Manage Stakeholder Engagement), Principle 9 (Optimize Risk Responses).
• 📘 PMBOK® Guide 8th Edition Draft (2026 previews): Nhấn mạnh Outcomes over Outputs, ưu tiên customer value.
• 🛠️ Agile Practice Guide (PMI, 2021): Phân biệt requirements gathering vs. retrospectives.
• ✅ PMI Standards: Process 5.2 Collect Requirements (Predictive focus).

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