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 miền kiến thức People (Con người) trong PMP, tập trung vào việc xây dựng mối quan hệ thành công với đội ngũ dự án mới khi Project Manager (PM) lần đầu làm việc với họ. PM nhận thấy đội ngũ là sự kết hợp giữa senior (có kinh nghiệm cao) và junior (mới vào nghề), điều này đòi hỏi PM phải linh hoạt trong phong cách lãnh đạo (situational leadership). Mục tiêu là bắt đầu thiết lập mối quan hệ ngay từ đầu, nhấn mạnh vào việc hiểu rõ cá nhân từng thành viên để tạo sự tin tưởng, động lực và hợp tác hiệu quả. Theo PMBOK® Guide 7th Edition (2021) và các cập nhật PMP đến 2026, việc xây dựng đội ngũ bắt đầu từ servant leadership và high-performing team principles, ưu tiên lắng nghe nhu cầu cá nhân trước khi áp đặt quy tắc.

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

• PMBOK® Guide 7th Edition: People Domain (trang 57-77), đặc biệt "Build a Team" và "Lead a Team".
• PMP Exam Content Outline (2021, cập nhật 2024-2026): Task 4.1 (Manage conflict), Task 9.1 (Mentor relevant stakeholders).
• Agile Practice Guide: Servant Leadership và Team Empowerment.

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

Đáp án đúng: Start speaking with each team member separately to understand their needs and personal goals to determine a leadership style.

Lý do 🛠️:
Đây là bước đầu tiên lý tưởng để xây dựng mối quan hệ cá nhân hóa, giúp PM nắm bắt nhu cầu (needs), mục tiêu cá nhân (personal goals) của từng thành viên – đặc biệt quan trọng với đội ngũ hỗn hợp senior/junior. Từ đó, PM có thể xác định phong cách lãnh đạo phù hợp (ví dụ: directing cho junior, delegating cho senior theo Situational Leadership Model). Phương pháp này thúc đẩy tin tưởng lẫn nhau, động lực nội tại và tránh sai lầm khi áp đặt một cách máy móc. Hoàn toàn phù hợp với nguyên tắc People First trong PMBOK 7th, ưu tiên empowerment và engagement.

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

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

• ❌ Schedule one-on-one meetings with the project team members to coach them on how to do their work better based upon previous experience.
  Giải thích sai 🚫: Phương án này quá vội vàng và tự cho mình là chuyên gia. PM chưa quen biết đội ngũ, việc "coach dựa trên kinh nghiệm trước" có thể bị coi là kiêu ngạo, không tôn trọng kinh nghiệm của senior và làm junior cảm thấy bị áp đặt. PMP nhấn mạnh hai chiều lắng nghe trước khi coach (Mentoring sau khi build trust), tránh assumptions (PMBOK 7th, Principle 3: Focus on Value).

• ✅ Start speaking with each team member separately to understand their needs and personal goals to determine a leadership style.
  Giải thích đúng 🏆: Như đã phân tích ở trên, đây là bước khởi đầu hoàn hảo để hiểu rõ cá nhân, xây dựng mối quan hệ bền vững và điều chỉnh leadership style linh hoạt. Hỗ trợ trực tiếp High-Performing Team model trong PMBOK 7th.

• ❌ Establish authority in the team by setting ground rules and key performance indicators (KPIs).
  Giải thích sai ⚠️: Quá cứng nhắc và mang tính áp đặt, dễ tạo sự chống đối từ senior (họ mong đợi tham gia quyết định). Ground rules và KPIs là cần thiết nhưng KHÔNG phải bước đầu tiên để "establish relationship" – phải build trust trước (PMBOK 7th, Team Charter sau giai đoạn forming). Điều này vi phạm Stakeholder Engagement principles.

• ❌ Schedule a team-building activity and start meeting personally with the project team members.
  Giải thích sai 🔄: Tuy team-building tốt cho tinh thần nhóm, nhưng với đội ngũ mới và hỗn hợp, nó chưa giải quyết nhu cầu cá nhân (senior có thể thấy lãng phí thời gian). "Meeting personally" mơ hồ và không tập trung vào needs/goals như đáp án đúng. PMP ưu tiên one-on-one trước group activities (Agile Practice Guide, Servant Leader starts with individuals).

Kết luận tổng quát 🌟: Câu hỏi kiểm tra khả năng servant leadership và emotional intelligence của PM. Chọn đúng giúp dự án khởi đầu suôn sẻ, giảm rủi ro conflict! Nếu thi PMP, hãy nhớ People Domain chiếm 42% exam (cập nhật 2026).

🧩 Phân tích chi tiết 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 đảm bảo các tiêu chí chấp nhận dự án (project acceptance criteria) được đáp ứng cho tất cả các sản phẩm bàn giao (deliverables).

✅ Mục tiêu chính: PM cần hành động cụ thể để xác thực phạm vi (Validate Scope), đảm bảo deliverables phù hợp với kỳ vọng và nhu cầu đã thỏa thuận, tránh tình trạng rework hoặc từ chối bàn giao. Điều này thuộc quá trình Quản lý Phạm vi Dự án (Project Scope Management) trong PMBOK Guide, đặc biệt là Process 5.5: Validate Scope (PMBOK 7th Edition, 2021 – cập nhật đến 2026 vẫn giữ nguyên khung). Acceptance criteria được định nghĩa rõ ràng từ giai đoạn Planning dựa trên requirements từ stakeholders, giúp đo lường chất lượng deliverables trước khi bàn giao chính thức.

🛠️ Bối cảnh PMP mới nhất: Theo PMBOK 7th Edition và PMP Exam Content Outline 2021 (PMI, hiệu lực đến 2026), PM phải ưu tiên Stakeholder Engagement và Value Delivery bằng cách tích hợp kỳ vọng stakeholders vào acceptance criteria ngay từ Develop Project Management Plan và Collect Requirements.

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

• PMBOK Guide 7th Edition: Section 5.5 Validate Scope & 4.7 Manage Project Knowledge.
• PMI's Agile Practice Guide (2021): Nhấn mạnh iterative validation với stakeholder feedback.
• PMP Exam Content Outline (2021): Domain 2: Process (22%) & Domain 3: Business Environment (22%).

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

Đáp án đúng: Include project stakeholder expectations and needs while creating project acceptance criteria.

Lý do 🟢:

• Acceptance criteria phải được xây dựng dựa trên kỳ vọng và nhu cầu của stakeholders (stakeholder expectations and needs) để đảm bảo tính chính xác và khả thi. Điều này xảy ra trong Plan Scope Management và Define Scope, giúp PM sử dụng criteria làm baseline kiểm tra deliverables trong Validate Scope. Nếu criteria không phản ánh đúng nhu cầu, deliverables sẽ không được chấp nhận dù "hoàn hảo" về mặt kỹ thuật. Đây là best practice cốt lõi, đảm bảo alignment với value (PMBOK 7th Ed., Principle 5: Optimize Risk Responses & Domain: Stakeholder).

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

• Create a statement of work (SOW) and ensure it remains unchanged during the project life cycle.
  ❌ Sai vì: SOW là tài liệu hợp đồng dành cho nhà cung cấp bên ngoài (external seller), mô tả công việc cần làm chứ không phải tiêu chí chấp nhận nội bộ cho deliverables. Giữ SOW "không thay đổi" vi phạm nguyên tắc Adaptive Planning (PMBOK 7th: Projects thay đổi theo change control). Acceptance criteria thuộc Project Scope Statement, không phải SOW. Hành động này không trực tiếp ensure criteria met mà có thể gây scope creep nếu không flexible.

• Include project stakeholder expectations and needs while creating project acceptance criteria.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là bước then chốt để criteria trở thành measurable standards phản ánh true value. PM thu thập từ Identify Stakeholders và Collect Requirements (ITTO: Stakeholder Register, Requirements Documentation). Trong Agile/hybrid, dùng Definition of Done (DoD) tương tự. Đảm bảo 100% alignment, giảm rejection rate (PMI Pulse of Profession 2023).

• Schedule regular meetings with project stakeholders to make sure they are satisfied.
  ❌ Sai vì: Các cuộc họp định kỳ thuộc Manage Communications và Monitor Stakeholder Engagement, giúp theo dõi satisfaction nhưng không tạo hoặc ensure acceptance criteria. Satisfaction là outcome, không phải criteria itself. Có thể dẫn đến subjective judgment thay vì objective validation (ví dụ: stakeholder "thích" nhưng không meet criteria → vẫn reject).

• Discuss project acceptance criteria with the project sponsor before the execution phase.
  ❌ Sai vì: Sponsor chỉ là một stakeholder quan trọng, không đại diện tất cả (ví dụ: end-users, customers). Thảo luận "trước execution" (cuối Planning) là muộn; criteria cần finalize từ Initiating/Planning với full stakeholder input qua workshops/requirements traceability matrix (RTM). Không bao quát toàn bộ, dễ miss needs khác (PMBOK 7th: 13.3 Manage Stakeholder Engagement).

🛠️ Kết luận & Best Practice: PM nên sử dụng Requirements Traceability Matrix (RTM) để link requirements → criteria → deliverables → verification results. Trong exam PMP 2026, ưu tiên proactive planning với stakeholders để "ensure met criteria"! Nếu thực tế, integrate tools như Jira/ MS Project cho tracking.

🧩 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 chi tiết:
Câu hỏi mô tả một tình huống thực tế trong quản lý dự án: Một thành viên đội ngũ dự án không nộp báo cáo tình trạng dự án (project status report) đúng hạn. Thành viên này đang bực tức vì cho rằng báo cáo không phản ánh đúng thực tế dự án, quá dài (too many pages), và không được các bên liên quan (stakeholders) đọc. Đây là vấn đề phổ biến liên quan đến quản lý đội ngũ (Team Management) và quản lý giao tiếp (Manage Communications) trong PMP. Project Manager (PM) cần xử lý để đảm bảo tuân thủ quy trình báo cáo, đồng thời giải quyết sự không hài lòng của thành viên đội ngũ, tránh ảnh hưởng đến động lực làm việc và hiệu suất dự án. Theo PMBOK Guide 7th Edition (và cập nhật đến 2026), PM phải áp dụng nguyên tắc lãnh đạo phục vụ (Servant Leadership), tập trung vào root cause analysis thay vì trừng phạt ngay lập tức.

✅ Đáp Án Đúng Và Lý Do Lựa Chọn

Đáp án đúng: Review the requirements of the report with the team member to redefine its purpose.
🛠️ Lý do chọn đáp án này (theo PMP mới nhất):
Phương án này phù hợp nhất vì PM nên thảo luận trực tiếp với thành viên đội ngũ để xem xét lại yêu cầu báo cáo (requirements) và định nghĩa lại mục đích (redefine purpose). Điều này giúp:

• Xác định nguyên nhân gốc rễ (root cause) của sự chậm trễ và frustration (ví dụ: báo cáo không hiệu quả, không phù hợp với thực tế).
• Cải thiện quy trình báo cáo, tăng giá trị (value) cho stakeholders theo Principle 2: Focus on Value (PMBOK 7th).
• Thể hiện Stakeholder Engagement và Team Leadership trong People Domain, khuyến khích giao tiếp hai chiều, xây dựng lòng tin, và điều chỉnh work products để phù hợp hơn.
  Nếu không giải quyết root cause, vấn đề sẽ lặp lại với người khác. Đây là cách proactive và collaborative, tránh demotivate đội ngũ.

🧩 Phân Tí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, chỉ giải thích bằng tiếng Việt:

• [ĐÚNG] Review the requirements of the report with the team member to redefine its purpose.
  ✅ Phân tích đúng: Phương án này khuyến khích PM hợp tác với thành viên để đánh giá và cải thiện báo cáo, phù hợp với Manage Team Performance và Develop Team trong People Domain (PMBOK 7th). Nó giải quyết frustration bằng cách tái định nghĩa mục đích, đảm bảo báo cáo phản ánh thực tế và có giá trị, tăng động lực đội ngũ mà không bỏ qua quy trình.

• [SAI] Instruct the team member to provide the report and document this in the performance review.
  ❌ Phân tích sai: Phương án này chỉ ra lệnh nộp báo cáo và ghi vào đánh giá hiệu suất (performance review), mang tính trừng phạt (punitive), không giải quyết root cause như frustration về nội dung báo cáo. Theo PMP, PM phải ưu tiên coaching và mentoring trước khi kỷ luật (PMBOK 7th, Principle 9: Leadership), tránh làm giảm động lực đội ngũ và có thể vi phạm High-Performing Team principles.

• [SAI] Reassign the report to another team member to prepare and submit it as requested.
  ❌ Phân tích sai: Việc chuyển giao báo cáo cho người khác chỉ là giải pháp tạm thời, tránh né vấn đề gốc (báo cáo không hiệu quả). Điều này vi phạm Holistic Thinking (PMBOK 7th, Principle 5), không cải thiện quy trình, và có thể gây bất công trong đội ngũ, dẫn đến low team morale. PM nên fix process thay vì reshuffle tasks.

• [SAI] Escalate to the team member's functional manager that the report was not submitted as requested.
  ❌ Phân tích sai: Báo cáo lên cấp trên chức năng (functional manager) là escalation không cần thiết ở giai đoạn đầu, bỏ qua direct communication với thành viên. PMP nhấn mạnh first-line management qua giao tiếp (Communications Management, PMBOK 7th), chỉ escalate khi đã thử các bước nội bộ. Điều này có thể làm hỏng mối quan hệ đội ngũ và vi phạm Team Principle.

📘 Tài Liệu Tham Khảo

• PMBOK Guide 7th Edition (2021, cập nhật đến 2026): People Domain (Ch. 3), Principles như Focus on Value, Leadership, Team; Work Domain cho Manage Communications & Project Work.
• PMI Agile Practice Guide (tích hợp PMP 2021+): Nhấn mạnh adaptive reporting và team collaboration.
• PMP Exam Content Outline (2024-2026): 42% People (Team Management), ưu tiên root cause resolution.
  Nguồn chính thức: PMI.org – Tải PMBOK 7th tại đây để verify! 🚀

🧩 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: Một project manager (PM) được giao quản lý dự án mới. Trong đội ngũ, có một thành viên im lặng hoàn toàn trong các cuộc họp (không phát biểu gì), nhưng sau họp lại gửi email chi tiết với các gợi ý rất tốt, giúp ích cho việc thực thi dự án. Vấn đề cốt lõi là làm thế nào PM nên hướng dẫn các thành viên đội ngũ để khắc phục tình trạng này, nhằm tăng cường sự tham gia tích cực, cải thiện giao tiếp nhóm và tối ưu hóa hiệu suất dự án.

🛠️ Bối cảnh PMP (theo PMBOK 7th Edition, cập nhật đến 2026): Đây thuộc People Domain (Lĩnh vực Con người), tập trung vào Manage the Team (Quản lý đội ngũ). PM cần áp dụng nguyên tắc high-performing team (đội ngũ hiệu suất cao), khuyến khích sự tham gia đa dạng (bao gồm cả thành viên hướng nội), xây dựng môi trường tin cậy để mọi người tự do chia sẻ ý tưởng ngay trong họp, thay vì chỉ qua email. Điều này giúp giảm độ trễ thông tin, tăng collaboration (hợp tác) và hỗ trợ Agile/hybrid practices.

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

• PMBOK Guide 7th Edition: Section 4.3 Manage Team (trang 87-92), nhấn mạnh motivation và engagement.
• PMI Agile Practice Guide: Servant Leadership – PM khuyến khích voice của mọi thành viên.
• The Standard for Project Management (2021): Principle 7: Optimize Risk Responses & Principle 10: Stakeholder Engagement.

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

Đáp án đúng: Motivate the team members to speak freely in the meeting.

Lý do (🧩 Phân tích sâu):

• Hành động này trực tiếp giải quyết vấn đề gốc: Thành viên có ý tưởng tốt nhưng ngại nói trong họp → PM cần khích lệ (motivate) họ nói tự do (speak freely) để chia sẻ ngay lập tức, tăng giá trị họp và hiệu quả dự án.
• Theo People Domain, PM đóng vai trò servant leader (lãnh đạo phục vụ), sử dụng công cụ như recognition & rewards, coaching để xây dựng psychological safety (an toàn tâm lý), giúp mọi người tham gia mà không sợ bị phán xét.
• Lợi ích: Giảm rủi ro thông tin muộn (email sau họp), tăng team engagement và phù hợp với hybrid models (2021-2026 updates).

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

• [SAI] Remind the team members to follow the team charter.
  ❌ Sai vì: Team charter (hiến chương đội ngũ) chủ yếu định nghĩa mục tiêu, vai trò, quy tắc chung (PMBOK 4.1 Develop Team), không quy định cụ thể "phải nói trong họp". Nhắc nhở này mang tính cưỡng chế, có thể làm thành viên ngại hơn, vi phạm nguyên tắc optimize engagement thay vì motivate tự nhiên.

• [SAI] Arrange a team-building activity to involve all team members.
  ❌ Sai vì: Team-building (xây dựng đội ngũ) hữu ích cho trust-building (xây dựng lòng tin) tổng quát (PMBOK 4.2 Manage Team), nhưng không trực tiếp giải quyết vấn đề im lặng trong họp cụ thể. Đây là giải pháp gián tiếp, tốn thời gian, có thể không hiệu quả với thành viên hướng nội – PM cần action nhanh, targeted hơn.

• [ĐÚNG] Motivate the team members to speak freely in the meeting.
  ✅ Đúng vì: Như phân tích trên, đây là hành động tối ưu nhất, phù hợp Develop Team process, khuyến khích freely speaking để khai thác ý tưởng ngay lập tức, hỗ trợ high-value delivery trong dự án.

• [SAI] Review the communications management plan with the team members.
  ❌ Sai vì: Communications Management Plan (Kế hoạch quản lý giao tiếp, PMBOK 10.1) định nghĩa channels (kênh như email, họp), tần suất, không giải quyết hành vi cá nhân (ngại nói). Review chỉ hữu ích nếu plan sai, nhưng ở đây vấn đề là engagement, không phải plan – sẽ lãng phí thời gian và không motivate được thành viên.

🛠️ Khuyến nghị thực tiễn: PM nên kết hợp 1:1 coaching với thành viên này (ví dụ: "Tôi đánh giá cao email của bạn, hãy thử chia sẻ trong họp nhé?"), theo PMI Code of Ethics (2021 update).

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

Câu hỏi tập trung vào tình huống quản lý dự án high-risk (dự án có rủi ro cao), nơi Project Manager (PM) lo ngại về schedule delay (trì hoãn lịch trình) có thể dẫn đến việc phải dời go-live date (ngày triển khai chính thức). Đây là vấn đề thuộc quy trình Quản lý Rủi ro (Risk Management) trong PMP, cụ thể là giai đoạn nhận diện và theo dõi rủi ro trước khi nó trở thành vấn đề (issue). PM cần hành động tiếp theo phù hợp nhất theo nguyên tắc proactive risk management (quản lý rủi ro chủ động), tránh các hành động vội vã như thay đổi phạm vi hoặc yêu cầu tài nguyên mà chưa xác định rõ.
📘 Nguồn tham khảo: PMBOK® Guide 7th Edition (2021, cập nhật đến 2026 qua các Agile Practice Guide và Process Groups mới), Principle 7: Optimize Risk Responses; Performance Domain: Uncertainty. Risk Register là công cụ chính trong Identify Risks (PMBOK 6th) và Manage Risks (PMBOK 7th).

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

Đáp án đúng: Capture the risk in the risk register and monitor it to prevent it from becoming an issue by taking the proper response action.

Lý do:
🛠️ Trong dự án high-risk, trì hoãn lịch trình là một rủi ro tiềm ẩn (potential risk) chưa xảy ra, nên bước đầu tiên và đúng đắn nhất là ghi nhận (capture) rủi ro vào Risk Register để theo dõi và thực hiện response action phù hợp (như tránh, giảm thiểu, chấp nhận...). Điều này tuân thủ quy trình Identify Risks và Monitor Risks, giúp PM chủ động ngăn chặn rủi ro trở thành issue thực tế. Hành động này proactive, không thay đổi baseline mà chỉ monitor và respond timely. Đây là best practice PMP, tránh "firefighting" (xử lý chữa cháy).
📘 Nguồn: PMBOK® Guide 7th Ed., Section 4.5 Uncertainty Performance Domain; PMBOK® 6th Ed., 11.2.2.1 Risk Register.

🔍 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 nội dung gốc bằng tiếng Anh. Phân tích sử dụng tiêu chí PMP mới nhất (PMBOK 7th: nhấn mạnh nguyên tắc tối ưu hóa rủi ro thay vì process cứng nhắc).

• Capture the risk in the risk register and monitor it to prevent it from becoming an issue by taking the proper response action.
  ✅ Đúng 🏆: Như đã giải thích ở trên, đây là bước next logical action trong Risk Management. Risk Register là nơi document, assess, và track rủi ro (probability x impact cao ở dự án high-risk). PM phải monitor continuously và chọn response strategy (Avoid, Mitigate, Transfer, Accept) để tránh delay go-live. Không cần change request ngay vì rủi ro chưa là issue.

• Raise a change request to the change control board (CCB) to ask for funds to onboard new resources to expedite the project.
  ❌ Sai 🚫: Hành động này premature (vội vã), vì rủi ro chỉ là threat tiềm năng, chưa confirmed delay thực tế. Change Request chỉ dùng cho approved changes ảnh hưởng baseline (scope/time/cost), không phải để "expedite" (tăng tốc) mà chưa assess rủi ro đầy đủ. Vi phạm Integrated Change Control (PMBOK 7th Principle 9: Optimize Risk Responses trước khi thay đổi).

• Ensure that the project meets the committed time lines as this is the core objective and purpose of the project.
  ❌ Sai ⚠️: Đây là mindset sai lầm, coi timeline là "core objective" tuyệt đối, bỏ qua triple constraint (scope/time/cost/quality) và value delivery (PMBOK 7th: Focus on Value). PM không thể "ensure" (đảm bảo) mà không có action cụ thể; đây chỉ là statement mơ hồ, không phải bước "next" actionable. High-risk project cần risk response thay vì ép buộc timeline.

• Ask the sponsor to start a new project to support the existing project and help it meet the original time line.
  ❌ Sai 🔄: Hoàn toàn không phù hợp, vì tạo new project là scope creep lớn, tăng complexity và rủi ro (vi phạm Stewardship Principle). Sponsor không phải "fixer"; PM phải tự manage rủi ro nội bộ trước. Điều này có thể dẫn đến resource conflict và không giải quyết root cause delay. PMBOK 7th khuyến nghị holistic risk management trong một project duy nhất.

🏅 Kết luận PMP Best Practice

Trong tình huống này, Risk Management là priority số 1 cho high-risk project. Luôn Identify → Assess → Respond → Monitor theo chu kỳ. Áp dụng PMP 2026 updates: Tích hợp AI tools cho risk simulation nếu cần, nhưng cơ bản vẫn là Risk Register! Nếu thi PMP, chọn proactive risk action để score cao. 📘 Tài liệu bổ sung: PMI.org Risk Management Standard (2022 update).

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

Câu hỏi mô tả tình huống: Một luật bảo mật mới (privacy law) sẽ có hiệu lực vào đầu năm dương lịch tiếp theo. Quản lý dự án (Project Manager - PM) nhận ra rằng dự án cần phải tuân thủ (compliant) luật mới này. Đây là một ràng buộc bên ngoài (external constraint) đột ngột xuất hiện, có thể ảnh hưởng đến phạm vi dự án (scope), thời gian, chi phí hoặc rủi ro. 🛡️️

Câu hỏi yêu cầu: "What should the project manager do next?" (PM nên làm gì tiếp theo?).
Theo PMBOK® Guide 7th Edition (cập nhật mới nhất đến 2026, kết hợp với PMI's Agile Practice Guide), PM phải xử lý thay đổi theo nguyên tắc Stewardship (quản lý trách nhiệm) và Performance Domain: Uncertainty (quản lý bất định). Bước đầu tiên là escalate (báo cáo lên cấp cao) để đánh giá tác động, thay vì tự quyết định thay đổi scope hoặc tiếp tục mà không điều chỉnh. 📘

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

Đáp án đúng: Inform the project steering committee of this constraint.
Lý do: Steering committee (ủy ban chỉ đạo dự án) là cơ quan quản trị (governance body) chịu trách nhiệm phê duyệt các thay đổi lớn, đặc biệt là ràng buộc pháp lý bên ngoài ảnh hưởng đến dự án. PM cần thông báo ngay về constraint này để committee đánh giá, quyết định cập nhật scope baseline, phân bổ tài nguyên hoặc điều chỉnh kế hoạch. Điều này tuân thủ Process: Manage Project Changes (4.6 trong PMBOK 7th) và Principle 9: Optimize Risk Responses, tránh rủi ro pháp lý. Không escalate có thể dẫn đến non-compliance, phạt nặng. 🏆

📋 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 một cách chi tiết. Tôi giữ nguyên nội dung gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt. Sử dụng ✅ cho đúng, ❌ cho sai.

• ✅ Inform the project steering committee of this constraint.
  Giải thích đúng: Đây là bước tiếp theo logic nhất. Steering committee có thẩm quyền quyết định thay đổi dự án do ràng buộc pháp lý (legal constraint). PM chỉ thông báo (inform) để nhận hướng dẫn, không tự cam kết thay đổi. Phù hợp với PMBOK 7th: Governance Performance Domain và Change Control Board (CCB). 🛡️️

• ❌ Inform the legal department that the project scope will be updated.
  Giải thích sai: PM chưa có quyền tự quyết định cập nhật scope (scope will be updated) mà không qua phê duyệt. Thông báo cho legal department là hợp lý sau này để tư vấn, nhưng "next step" phải escalate lên governance trước. Điều này vi phạm Integrated Change Control, có thể dẫn đến thay đổi không được phê duyệt. 🚫

• ❌ Inform the product owner that the project will continue as planned.
  Giải thích sai: Tiếp tục như kế hoạch (continue as planned) sẽ làm dự án không tuân thủ luật mới, tăng rủi ro pháp lý nghiêm trọng. Product owner (thường trong Agile) không phải người quyết định constraint bên ngoài; PM phải đánh giá tác động trước khi thông báo. Vi phạm Principle 12: Navigate Complexity. ⚠️

• ❌ Inform the project team and create a spike for the next iteration.
  Giải thích sai: Spike (công cụ Agile để nghiên cứu rủi ro) là tốt cho investigation, nhưng không phải bước đầu tiên. PM chưa nên giao việc cho team mà phải escalate lên steering committee để approve trước. Điều này bỏ qua governance, chỉ phù hợp sau khi có quyết định chính thức (Agile Practice Guide: Spike dùng cho uncertainty nội bộ, không thay thế CCB). ⏭️

📚 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, cập nhật 2026): Chương 4 (Project Performance Domains), Principle 3 (Focus on Value) & 9 (Optimize Risk Responses).
• PMI's Agile Practice Guide (2017, tích hợp PMBOK 7th): Phần Change in Agile Environments.
• The Standard for Project Management (2021): Governance và Constraints Management.
  Nguồn chính thức: pmi.org. Nếu cần, PM có thể dùng công cụ Expert Judgment từ legal/stakeholder để hỗ trợ. 🔍

🧩 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ý stakeholder và thực hành Agile trong PMP (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 stakeholder khách hàng quan trọng yêu cầu thêm nhiệm vụ mới vào backlog, bắt đầu phân tích các yêu cầu mới ngay lập tức, mong muốn kết quả nhanh chóng nhất có thể, và gây áp lực cho team bằng cách bắt tham gia các cuộc họp không quan trọng. Kết quả là team cảm thấy thất vọng và bực tức.
📌 Vấn đề cốt lõi: Project manager cần xử lý sự can thiệp trực tiếp của stakeholder vào team, đảm bảo quy trình Agile được tuân thủ (như vai trò rõ ràng của Product Owner), giảm frustration cho team, và duy trì focus vào giá trị cao nhất. Đây là tình huống điển hình trong môi trường hybrid hoặc Agile, nơi stakeholder cần được hướng dẫn đúng kênh để tránh làm gián đoạn sprint hoặc workflow.

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

Đáp án đúng: Ask the customer to work with the product owner to prioritize all requests.
🛠️ Lý do: Trong Agile (Scrum framework), Product Owner (PO) là người chịu trách nhiệm chính cho product backlog, bao gồm việc prioritize các yêu cầu mới từ stakeholder (theo Scrum Guide 2020 và Agile Practice Guide - PMI). Project manager (thường kiêm Scrum Master) phải bảo vệ team bằng cách hướng stakeholder làm việc qua PO để đánh giá, prioritize dựa trên value, effort và roadmap. Cách này giải quyết gốc rễ (áp lực trực tiếp), giảm frustration cho team, và đảm bảo quy trình minh bạch. Không làm vậy sẽ vi phạm nguyên tắc self-organizing team và time-boxing (PMBOK 7th, Principle 5: Stewardship & Principle 9: Team).

📋 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/Agile mới nhất:

• ❌ [SAI] Work with the team to receive customer directions and improve the process.
  Phương án này sai vì team không phải là người nhận hướng dẫn trực tiếp từ customer/stakeholder để thay đổi backlog hoặc process. Trong Agile, team chỉ pull work từ backlog đã prioritize sẵn (theo Definition of Done). Làm vậy sẽ làm team mất focus, tăng frustration thêm, và vi phạm vai trò rõ ràng (PO prioritize, team execute). Không giải quyết gốc rễ là customer bypass PO (PMBOK 7th, Domain: Stakeholder, Agile Principle: Collaboration qua đúng kênh).

• ✅ [ĐÚNG] Ask the customer to work with the product owner to prioritize all requests.
  Như đã giải thích ở trên: Đây là cách tối ưu, enforce single source of truth (backlog qua PO), bảo vệ team khỏi pressure, và align với value-driven delivery. Hỗ trợ nguyên tắc optimize flow và stakeholder engagement (Scrum Guide & PMI Agile Practice Guide).

• ❌ [SAI] Call for an internal team retrospective and create an improvement action plan.
  Phương án này chỉ tập trung internal team (retrospective là ceremony cuối sprint để improve process nội bộ), nhưng không giải quyết customer pressure trực tiếp. Team vẫn bị distract bởi meetings không critical, và backlog bị rối. Retrospective hữu ích nhưng không phải approach đầu tiên cho tình huống stakeholder-driven (PMBOK 7th, Process: Manage Team & Agile Principle: Reflect & Adapt - nhưng sau khi stabilize external factors).

• ❌ [SAI] Understand the customer's perspective and provide mentoring on agile mindsets.
  Phương án này có phần đúng về empathy (Stakeholder Engagement), nhưng mentoring agile mindset không phải hành động ngay lập tức hoặc chính yếu. Nó có thể làm stakeholder phòng thủ, và bỏ qua enforce roles (PO prioritize). Mentoring nên là long-term, không thay thế việc redirect qua đúng kênh (PMBOK 7th, Principle 11: Leadership & Agile Practice Guide: Servant Leadership).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021): People Domain (Stakeholder & Team), Delivery Domain (Agile workflows).
• Agile Practice Guide (PMI, 2017 - cập nhật tích hợp PMBOK 7): Vai trò Product Owner & backlog management.
• Scrum Guide (2020, Scrum.org): Product Owner responsibilities & protecting the team.
• PMP Exam Content Outline (2024-2026, PMI): Task 8.2 (Manage conflict), 9.1 (Engage stakeholders in Agile).

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

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

Câu hỏi mô tả một tình huống trong dự án Agile (cụ thể là Scrum với "sprint đầu tiên"), nơi Giám đốc vận hành (operations director) phàn nàn với Giám đốc điều hành (CEO) về kết quả sprint đầu tiên. Lý do là bộ phận vận hành không thể hỗ trợ sản phẩm mới do các chỉ số hiệu suất (performance indicators) kém. Người hỗ trợ đội dự án (project team facilitator - thường là Scrum Master) thu thập phản hồi từ đội ngũ và biết rằng thông tin hiệu suất có sẵn trong log máy chủ ứng dụng (application server log).

🛠️ Vấn đề cốt lõi: Đây là xung đột giữa đội phát triển và bộ phận vận hành (operations), thiếu sự phối hợp và xác thực (validation) sớm. Câu hỏi yêu cầu cách xử lý khiếu nại (complaint) hiệu quả nhất, phù hợp với nguyên tắc Agile: tăng cường hợp tác (collaboration), liên quan stakeholders (stakeholders involvement), và cải tiến liên tục (continuous improvement) theo PMBOK 7th Edition và Agile Practice Guide.

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

Invite a member of the operations team to be part of the validation and sprint meetings.

Lý do: Phương án này thúc đẩy sự tham gia trực tiếp của stakeholders (operations team) vào các cuộc họp validation (kiểm tra sản phẩm) và sprint meetings (như daily scrum, sprint review), giúp phát hiện vấn đề sớm, cải thiện chất lượng và đảm bảo sản phẩm phù hợp với nhu cầu vận hành. Điều này tuân thủ nguyên tắc Agile: "Customer collaboration over contract negotiation" và Stakeholder Engagement trong PMBOK 7th (Section 4.7), đồng thời khuyến khích cross-functional teams để giảm rủi ro và tăng giá trị sản phẩm. Việc chỉ dựa vào log không đủ; cần feedback thực tế từ operations để điều chỉnh kịp thời.

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

Dưới đây là phân tích chi tiết từng lựa chọn, với nội dung gốc giữ nguyên tiếng Anh. Mỗi phương án được đánh giá dựa trên nguyên tắc Agile/Scrum và quản lý dự án theo PMBOK 7th Edition (2021) cập nhật đến 2026.

• Request that the issue be included in the next board of directors meeting to explain all of the needs.
  ❌ Sai: Phương án này leo thang vấn đề lên cấp cao (board of directors) quá sớm, gây chậm trễ và không giải quyết gốc rễ tại cấp đội ngũ. Agile ưu tiên giải quyết nhanh chóng tại chỗ (just-in-time feedback) thay vì họp hội đồng dài dòng, vi phạm nguyên tắc "Working software over comprehensive documentation" (Agile Manifesto) và Issue Management trong PMBOK (Section 4.6).

• Add the complaint to the product backlog to be addressed in the next sprint.
  ❌ Sai: Việc thêm khiếu nại vào product backlog chỉ là deferred action (hoãn lại), không giải quyết ngay lập tức và bỏ qua sprint review/retrospective để cải tiến ngay. Operations cần tham gia sớm hơn backlog grooming; điều này trái với Daily Stand-up và Sprint Review trong Scrum Guide (2020) và Iterative Development trong Agile Practice Guide.

• Invite a member of the operations team to be part of the validation and sprint meetings.
  ✅ Đúng: Như đã giải thích ở trên, phương án này tăng cường collaboration và stakeholder engagement, phù hợp nhất với cross-functional participation và validation loops trong Agile. Giúp truy cập log hiệu suất thực tế và điều chỉnh kịp thời, giảm rủi ro sản phẩm không hỗ trợ được operations.

• Ask the operations director to define the acceptance criteria to make clear the delivery is correct.
  ❌ Sai: Yêu cầu định nghĩa acceptance criteria từ operations director là tốt, nhưng chỉ làm một lần mà không mời tham gia liên tục sẽ thiếu feedback động. Agile nhấn mạnh liên tục refine criteria qua meetings, không phải "one-off" request, vi phạm Definition of Done (DoD) và Product Owner collaboration trong Scrum Guide.

📘 Tài liệu tham khảo

• PMBOK® Guide 7th Edition (2021): Section 3.2 (Agile Principles), Section 4.7 (Stakeholder Engagement), Section 6.4 (Team Performance).
• Agile Practice Guide (PMI, 2017 - cập nhật tích hợp PMBOK 7): Chương 4 (Implementing Agile: Creating People and Teams), nhấn mạnh stakeholder involvement trong sprints.
• Scrum Guide (2020, Scrum.org): Sprint Review và Daily Scrum để thu thập feedback từ stakeholders.
• PMP Exam Content Outline (PMI, 2021 - hiệu lực đến 2026): Domain III: Business Environment (Stakeholder mgmt.), Domain IV: Agile Practices.

🛠️ Kết luận: Trong Agile, hợp tác sớm và thường xuyên là chìa khóa để xử lý complaint, giúp dự án thành công! Nếu cần ví dụ thực tế hoặc câu hỏi 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 tình huống thực tế trong quản lý dự án PMP: Một Project Manager (PM) được giao quản lý một dự án kéo dài 1 năm. Trước khi bắt đầu giai đoạn thiết kế (design phase), đối thủ cạnh tranh công bố sẽ ra mắt sản phẩm/dịch vụ tương tự chỉ trong 8 tháng, nhưng với ít tính năng và chức năng hơn.
📌 Ý nghĩa chính: Đây là rủi ro bên ngoài (external risk) từ thị trường, có thể ảnh hưởng đến giá trị kinh doanh, thời gian ra mắt và lợi thế cạnh tranh của dự án. PM cần hành động tiếp theo (next actions) để xử lý, chọn hai hành động phù hợp nhất.
🛠️ Liên quan đến PMP (PMBOK 7th Edition & cập nhật đến 2026): Tập trung vào Quản lý rủi ro (Manage Risks - Domain 4), Stakeholder Engagement (Domain 1), và Uncertainty Management. PM không nên thay đổi ngay mà cần đánh giá tác động và tham khảo stakeholder cấp cao trước khi quyết định.

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

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

1. Discuss and review this external risk with the project sponsor.
   🧠 Lý do: Đây là rủi ro chiến lược (strategic risk) ảnh hưởng đến mục tiêu kinh doanh. PM phải thảo luận và xem xét ngay với Project Sponsor (người bảo trợ dự án) để nhận hướng dẫn, vì sponsor có quyền quyết định cao nhất về thay đổi chiến lược (theo PMBOK 7th, 4. - Stakeholder Sphere & 11.7 Monitor Risks).

2. Evaluate the impact of incremental deliverables.
   🧠 Lý do: Cần đánh giá tác động của việc phân phối sản phẩm theo cách tăng dần (incremental) để cạnh tranh kịp thời (ra mắt sớm hơn đối thủ). Điều này phù hợp với Value Delivery System trong PMBOK 7th (Principle 5: Optimize Risk Responses), giúp linh hoạt điều chỉnh mà không giảm scope ngay lập tứ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 phương án một, 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 chi tiết bằng tiếng Việt dựa trên PMP mới nhất:

• Modify the project management plan with an incremental approach.
  ❌ Sai: Không nên sửa đổi kế hoạch quản lý dự án ngay lập tức theo cách tiếp cận tăng dần. PM cần đánh giá rủi ro và tác động trước (preliminary assessment), tránh thay đổi plan mà chưa có sự đồng thuận từ sponsor hoặc team (PMBOK 7th, 4.6 Manage Project Changes: Phải qua change control process).

• Discuss and review this external risk with the project sponsor.
  ✅ Đúng: Như đã giải thích ở trên. Thảo luận rủi ro bên ngoài với sponsor là bước đầu tiên để escalate issue chiến lược, đảm bảo alignment với business objectives (PMBOK 7th, 4.2 Engage Stakeholders & Risk Register Update).

• Update the project artifacts to include this issue.
  ❌ Sai: Cập nhật các artifacts dự án (như Risk Register, Issue Log) là cần thiết nhưng KHÔNG phải hành động tiếp theo ngay. Phải discuss với sponsor trước để quyết định cách ghi nhận, tránh cập nhật vội vàng gây hoang mang team (PMBOK 7th, 11.7 Monitor Risks: Update sau khi assess).

• Evaluate the impact of incremental deliverables.
  ✅ Đúng: Như đã giải thích. Đánh giá tác động của deliverables tăng dần giúp xem xét các lựa chọn như Agile/hybrid để ra mắt sớm, tối ưu hóa value delivery (PMBOK 7th, Principle 3: Focus on Value & 7.3 Delivery WIP).

• Reduce the scope items of the final deliverable.
  ❌ Sai: Giảm scope của sản phẩm cuối là hành động tiêu cực, không phù hợp vì đối thủ chỉ có ít features hơn – dự án có thể giữ scope đầy đủ nhưng điều chỉnh timeline. Điều này vi phạm Principle 12: Think Quantitatively (phải evaluate trước khi cắt scope, theo PMBOK 7th, 5.6 Control Scope).

📘 Tài liệu tham khảo

• PMBOK Guide 7th Edition (2021, cập nhật PMI Standards đến 2026): Domains 1 (Stakeholder), 4 (Uncertainty/Risks), Principle 5 (Risk Optimization).
• PMI Agile Practice Guide (2021): Hỗ trợ incremental delivery cho market risks.
• The Standard for Project Management (2021): Nhấn mạnh escalate external risks với sponsor trước change.
  🔗 Nguồn chính thức: PMI.org – Khuyến nghị kiểm tra PMP Exam Content Outline 2024+ cho situational questions tương tự.

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

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

Câu hỏi mô tả một tình huống thực tế trong dự án xây dựng đang gặp phải rủi ro cung ứng vật liệu do khủng hoảng dầu mỏ toàn cầu, dẫn đến vật liệu thô không được giao đúng hạn và giai đoạn hiện tại đã trễ kế hoạch ban đầu. 🛠️ Mục tiêu là xác định hành động đầu tiên mà project manager (PM) nên thực hiện để ngăn dự án lệch hướng thêm (prevent going further off track).

Đây là tình huống điển hình trong quản lý rủi ro dự án (Project Risk Management) theo PMBOK® Guide 7th Edition (và cập nhật đến 2026), nơi một rủi ro đã xảy ra (realized risk hoặc issue) cần được xử lý kịp thời. PM phải ưu tiên đánh giá rủi ro trước khi áp dụng các biện pháp cụ thể, nhằm tránh hành động vội vã dẫn đến lãng phí tài nguyên hoặc bỏ lỡ cơ hội. 🔍 Câu hỏi kiểm tra kiến thức về quy trình Manage Risks trong Project Management Principles & Performance Domains.

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

Đáp án đúng: Perform a risk assessment and define a risk response action plan.

Lý do: 🏆 Theo PMBOK® 7th Edition (Domain: Uncertainty), khi dự án gặp sự cố rủi ro (như gián đoạn chuỗi cung ứng), bước đầu tiên là thực hiện risk assessment (bao gồm Identify Risks và Assess Risks) để xác định đầy đủ tác động, xác suất, và ưu tiên rủi ro. Sau đó, mới định nghĩa risk response action plan (Plan Risk Responses) phù hợp, chẳng hạn như chấp nhận, giảm thiểu, chuyển giao, hoặc khai thác. Điều này đảm bảo hành động dựa trên dữ liệu, tránh quyết định cảm tính và tối ưu hóa giá trị dự án. Nếu bỏ qua bước này, PM có thể chọn sai response, dẫn đến dự án lệch hướng nghiêm trọng hơn. Đây chính là nguyên tắc proactive risk management trong PMP hiện đại.

📋 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 phương án, với giữ nguyên văn bản gốc bằng tiếng Anh. Tôi đánh dấu ✅ cho đúng và ❌ cho sai, kèm giải thích rõ ràng dựa trên PMBOK® 7th Edition.

• Propose a pause in this phase to save labor costs and asset depreciation.
  ❌ Sai. Việc đề xuất tạm dừng giai đoạn chỉ là một risk response cụ thể (mitigate hoặc avoid), nhưng không phải bước đầu tiên. PM cần đánh giá rủi ro toàn diện trước để xác định tạm dừng có thực sự hiệu quả hay không (có thể gây tốn kém hơn do chi phí khởi động lại). Hành động này bỏ qua quy trình Identify & Assess Risks, vi phạm nguyên tắc Tailored Approach trong PMBOK®.

• Proceed with the project using management reserves to cover any delays or losses.
  ❌ Sai. Management reserves dành cho unknown-unknown risks (rủi ro chưa biết), không phải rủi ro đã xảy ra như ở đây (supply disruption là known risk). Sử dụng reserves ngay lập tức mà chưa assess tác động có thể làm cạn kiệt ngân sách dự phòng, dẫn đến không kiểm soát được. PMBOK® nhấn mạnh phải monitor reserves sau risk assessment, không dùng "bừa".

• Establish new partnerships with other suppliers in anticipation of any delays.
  ❌ Sai. Việc tìm đối tác mới là risk response (mitigate hoặc transfer), nhưng chưa assess rủi ro đầy đủ nên có thể dẫn đến rủi ro mới (như chất lượng kém, chi phí cao hơn). Đây là hành động reactive chưa có cơ sở dữ liệu, vi phạm Uncertainty Domain – PM phải ưu tiên risk assessment trước khi thay đổi nhà cung cấp để đảm bảo tính khả thi.

• Perform a risk assessment and define a risk response action plan.
  ✅ Đúng. Như đã giải thích ở trên, đây là bước đầu tiên chuẩn theo quy trình Manage Risks (Identify → Assess → Plan Responses). Nó giúp PM hiểu rõ vấn đề, ưu tiên hành động, và tích hợp vào dự án mà không gây lệch hướng thêm. Hoàn hảo cho tình huống crisis như vậy! 🎯

📘 Tài liệu tham khảo

• PMBOK® Guide – Seventh Edition (2021, cập nhật đến 2026): Chương Uncertainty Performance Domain (trang 133-143) và Project Risk Management (Process 11.1-11.7).
• PMI Agile Practice Guide (2021): Nhấn mạnh iterative risk assessment trong môi trường volatile.
• The Standard for Risk Management in Portfolios, Programs, and Projects (2019): Xác nhận "Perform a risk assessment" là bước khởi đầu cho realized risks.
• Tài liệu PMP Exam Content Outline (2021, hiệu lực đến 2026): Domain 4 – Manage Project Changes (Risks as changes).

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