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

🧩 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: Nhóm dự án mạnh mẽ khuyến khích project manager (PM) mua một ứng dụng phần mềm để giảm đáng kể thời gian làm việc, giúp tránh nguy cơ trễ hạn deadline. Tuy nhiên, việc mua ứng dụng này sẽ tăng chi phí dự án (impact project cost). Sponsor (người bảo trợ dự án) muốn khám phá các lựa chọn rẻ hơn nhưng vẫn tiết kiệm thời gian cho đội ngũ.
🛠️ Vấn đề cốt lõi: PM cần quyết định hành động phù hợp để cân bằng giữa thời gian (schedule) và chi phí (cost), đồng thời đáp ứng mong muốn của sponsor về việc đánh giá các alternative options (lựa chọn thay thế). Đây là tình huống điển hình về decision making trong quản lý dự án, liên quan đến trade-off giữa các ràng buộc (constraints) theo PMBOK Guide.

✅ Đáp án đúng: Create a decision tree.
Lý do lựa chọn (theo PMP phiên bản mới nhất - PMBOK 7th Edition & updates đến 2026):
Decision tree là công cụ phân tích dữ liệu định lượng (data analysis) mạnh mẽ để đánh giá các lựa chọn thay thế với xác suất thành công và giá trị mong đợi (Expected Monetary Value - EMV). Nó giúp PM hình dung các nhánh quyết định: mua app đắt ❌ (tăng cost, giảm risk trễ hạn), mua app rẻ ✅ (tiết kiệm cost, vẫn giảm thời gian), hoặc không mua ❌ (rủi ro trễ hạn cao). Điều này trực tiếp đáp ứng yêu cầu "explore a less expensive application" của sponsor, hỗ trợ principle Optimize Risk Responses và Holistic Risk Management (PMBOK 7th). Không thay đổi baseline ngay, mà phân tích trước để quyết định sáng suốt.
📘 Nguồn tham khảo: PMBOK Guide 7th Edition (2021, updates 2024-2026 qua PMI Standards+), Section 4.6.2.5 Data Analysis (Decision Trees trong Alternatives Analysis); Process Models trong Risk Management (12.3 Plan Risk Responses).

🔍 Giải thích tất cả các phương án (giữ nguyên text gốc bằng tiếng Anh)

• ❌ Raise a change request.
  Phương án này sai vì việc nâng change request (theo Integrated Change Control process) chỉ áp dụng khi đã quyết định thay đổi baseline (cost/schedule) và cần phê duyệt chính thức. Ở đây, chưa có quyết định cuối cùng, sponsor còn muốn explore alternatives, nên chưa đến lúc submit change request. Làm vậy sẽ bỏ qua bước phân tích, có thể dẫn đến thay đổi không cần thiết (PMBOK 7th, Principle 9: Navigate Complexity).

• ✅ Create a decision tree.
  Phương án này đúng như đã giải thích ở trên. Nó là best practice để quantitative analysis các options, tính EMV cho từng nhánh (ví dụ: Probability of missing deadline x Impact), giúp PM và sponsor chọn lựa tối ưu mà không vội thay đổi. Phù hợp với Tailoring trong môi trường agile/hybrid (PMBOK 7th updates).

• ❌ Purchase the application.
  Phương án này sai vì mua ngay ứng dụng đắt tiền sẽ vi phạm yêu cầu của sponsor (không explore less expensive option), dẫn đến cost overrun không được phê duyệt và có thể gây conflict với stakeholder. PM không được hành động độc lập mà phải tuân thủ governance (PMBOK 7th, Principle 5: Stakeholders & 7: Value).

• ❌ Analyze assumptions and constraints.
  Phương án này sai (dù nghe hợp lý) vì phân tích assumptions/constraints là hoạt động liên tục trong Monitor Risks hoặc Collect Requirements, nhưng không trực tiếp giải quyết vấn đề decision making giữa các alternatives cụ thể. Nó quá chung chung, không giúp "explore" options rẻ hơn như sponsor mong muốn. Decision tree mới là công cụ chuyên sâu hơn (PMBOK 7th, Section 4.5 Build a Team & 4.8 Deliver Value).

🛡️ Lời khuyên PMP: Trong thực tế, luôn ưu tiên data-driven decisions với tools như decision tree để tối ưu hóa trade-offs, tránh rủi ro không cần thiết! Nếu thi PMP, nhớ áp dụng Three Domains (People, Process, Business Environment) từ Exam Content Outline 2021+.

🧩 Giải thích nội dung câu hỏi một cách chi tiết

Câu hỏi mô tả tình huống một Project Manager (PM) đang dẫn dắt dự án kỹ thuật (engineering project). Dự án cần hoàn thành các chứng nhận (certifications) trước khi bắt đầu sản xuất hàng loạt (mass production), dự kiến trong 3 tháng tới. Tuy nhiên, quy trình chứng nhận yêu cầu ít nhất 6 tháng, dẫn đến xung đột lịch trình nghiêm trọng (schedule constraint).
Câu hỏi yêu cầu: "What should the project manager do next?" (PM nên làm gì tiếp theo?).
📘 Liên quan đến PMP (PMBOK 7th Edition, 2021 & cập nhật đến 2026): Đây là tình huống quản lý rủi ro lịch trình (schedule risk) và xử lý vấn đề (issue management) trong Project Schedule Management và Risk Management. PM cần tuân thủ nguyên tắc tư duy hệ thống (systems thinking) và đánh giá tình huống (assessment) trước khi thực hiện hành động lớn như thay đổi timeline hoặc escalate.

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

Đáp án đúng: Assess and evaluate the certification process and understand the best and worst case scenarios.

Lý do:
🛠️ Theo PMBOK 7th Edition (Domain: Uncertainty - Risk Management), bước đầu tiên khi đối mặt với rủi ro hoặc vấn đề tiềm ẩn là đánh giá và phân tích (assess & evaluate) để hiểu rõ tình hình, bao gồm best-case và worst-case scenarios (kịch bản tốt nhất và xấu nhất). Điều này giúp PM thu thập dữ liệu chính xác, xác định rủi ro thực tế, và xây dựng kế hoạch ứng phó (response plan) dựa trên dữ liệu, tránh hành động vội vã. Đây là bước proactive phù hợp với 12 Principles of PMP (Principle 3: Focus on value; Principle 9: Navigate complexity).
Nguồn: PMBOK Guide 7th Ed., Section 4.5 (Uncertainty) & PMP Exam Content Outline 2021 (updated 2026).

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

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

• ✅ Assess and evaluate the certification process and understand the best and worst case scenarios.
  🟢 Đúng vì: Đây là bước logical next step trong quy trình quản lý dự án. PM cần thu thập thông tin chi tiết về quy trình chứng nhận (ví dụ: các bước cụ thể, thời gian thực tế, yếu tố có thể rút ngắn) trước khi quyết định. Việc hiểu best/worst scenarios giúp xây dựng monte carlo simulation hoặc risk register, đảm bảo quyết định dựa trên dữ liệu. Phù hợp Agile/ Hybrid approach trong PMP mới.

• ❌ Discuss extending the mass production timeline by 3 months with the project sponsor.
  🔴 Sai vì: Việc thảo luận thay đổi timeline ngay lập tức với sponsor là premature (quá sớm), bỏ qua bước đánh giá. PMBOK nhấn mạnh không escalate trước khi analyze root cause. Có thể timeline không cần thay đổi nếu đánh giá phát hiện cơ hội rút ngắn.

• ❌ Engage a consultant to shorten the certification process to meet the schedule requirement.
  🔴 Sai vì: Thuê consultant là hành động tốn kém và chưa được đánh giá, có thể dẫn đến scope creep hoặc lãng phí nếu không cần thiết. PMP yêu cầu assess trước (Principle 7: Optimize risk responses), không "jump to solution" mà không hiểu vấn đề đầy đủ.

• ❌ Meet with senior management to discuss the possibility of an extension to the project timeline.
  🔴 Sai vì: Escalate lên senior management quá sớm, vi phạm chain of command và governance structure. PM phải handle at project level trước (PMBOK 7th Ed., Section 2.4: Stewardship). Chỉ escalate sau khi có dữ liệu đầy đủ từ assessment.

Tóm tắt takeaway 🎯: Trong PMP, Assess first - Act later là chìa khóa để quản lý rủi ro hiệu quả! Tham khảo thêm: PMI.org PMP Exam Prep & PMBOK 7th Ed. (2021, valid to 2026).

🧩 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ý Bên liên quan (Stakeholder Management) trong PMP, cụ thể là trong giai đoạn Thực hiện (Executing Process Group) của một dự án lớn. Tình huống mô tả:

• Dự án đang ở giữa giai đoạn thực hiện.
• Một bên liên quan mới (new stakeholder) tham gia vào hội đồng quản trị (board of directors), người này không quen thuộc với dự án (unfamiliar with the project).
• Người này đang ảnh hưởng đến các quyết định dự án và gây tác động tiêu cực đến tiến độ (impacting the project's progress).

📌 Câu hỏi yêu cầu: Project Manager (PM) nên làm gì đầu tiên (first) để xử lý tình huống này?
Mục tiêu chính là giảm thiểu tác động từ sự thiếu hiểu biết của stakeholder mới, đảm bảo sự align và hỗ trợ từ họ, theo nguyên tắc Stakeholder Engagement trong PMBOK® Guide 7th Edition (và các cập nhật đến 2026, nhấn mạnh vào value delivery và adaptive practices).

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

Đáp án đúng: Present the project to the stakeholder.

🛠️ Lý do chi tiết:

• Theo PMBOK® Guide 7th Edition (Section 4.6 - Manage Stakeholder Engagement) và Stakeholder Engagement Principle, khi một stakeholder mới tham gia và gây ảnh hưởng tiêu cực do thiếu kiến thức, hành động đầu tiên của PM phải là tăng cường sự tham gia (engage) bằng cách trình bày thông tin dự án để họ hiểu rõ mục tiêu, phạm vi, tiến độ và lợi ích.
• Điều này giúp xây dựng sự đồng thuận (alignment), giảm rủi ro từ quyết định thiếu cơ sở, và chuyển stakeholder từ "unaware" sang "supportive" theo Stakeholder Engagement Assessment Matrix.
• Không phải lúc nào cũng cần cập nhật risk hoặc schedule ngay, vì vấn đề cốt lõi là thiếu thông tin – presenting project là bước proactive và đầu tiên để educate và manage expectation.
  📘 Nguồn tham khảo: PMBOK® Guide 7th Edition (trang 124-126, Principle 7: Optimize Risk Responses & Engage Stakeholders); PMP Exam Content Outline 2021 (Domain IV: People - Task 5).

📋 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, dựa trên quy trình PMP mới nhất:

• Phương án SAI: Inform the client about the change.
  ❌ Lý do sai: Client (khách hàng) không phải là đối tượng đầu tiên cần thông báo ở đây. Vấn đề chính là stakeholder mới (board member) đang thiếu hiểu biết và ảnh hưởng trực tiếp. Theo Integrated Change Control, thông báo client chỉ cần khi có thay đổi chính thức (formal change), không phải "first action". Hành động này bỏ qua root cause (thiếu kiến thức của stakeholder), có thể làm phức tạp hóa mà không giải quyết vấn đề gốc.

• Phương án SAI: Update the risk register with a new risk.
  ❌ Lý do sai: Mặc dù có thể coi đây là rủi ro (stakeholder influence risk), nhưng updating Risk Register thuộc Monitor Risks process (Monitoring & Controlling), không phải hành động đầu tiên trong Executing. PMBOK® 7th nhấn mạnh identify và assess trước khi update, và ở đây cần engage stakeholder trước để mitigate, chứ không chỉ ghi nhận rủi ro (có thể làm stakeholder cảm thấy bị "đối đầu").

• Phương án ĐÚNG: Present the project to the stakeholder.
  ✅ Lý do đúng (như đã giải thích ở trên): Đây là bước first response trong Manage Stakeholder Engagement, giúp educate, build trust và align decisions. Hiệu quả cao trong tình huống "new unfamiliar stakeholder influencing negatively".

• Phương án SAI: Revise the project schedule.
  ❌ Lý do sai: Việc sửa lịch trình (schedule) là phản ứng reactive với tác động (impact), thuộc Control Schedule process, nhưng không giải quyết nguyên nhân gốc (stakeholder thiếu hiểu biết). Theo Change Control, revise schedule cần approved change request sau khi đánh giá, không phải "first thing". Có thể dẫn đến scope creep nếu không engage stakeholder trước.

🏆 Kết luận và lời khuyên PMP

✅ Hành động đầu tiên luôn ưu tiên Engage & Communicate với stakeholder để đảm bảo project success. Trong PMP exam (2021+), các câu hỏi tương tự kiểm tra proactive stakeholder management thay vì reactive fixes.
📘 Tài liệu tham khảo bổ sung:

• PMBOK® Guide 7th Edition (2021) & PMI's Process Groups: A Practice Guide (2022).
• Rita Mulcahy's PMP Exam Prep (14th Ed., cập nhật 2024).
  Hãy thực hành thêm các scenario Executing phase để nắm vững! 🚀

🧩 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 trong PMP (Project Management Professional), cụ thể liên quan đến quy trình iteration review (phiên đánh giá lặp lại, thường gọi là Sprint Review trong Scrum). Tình huống mô tả: Trong phiên đánh giá iteration, một số tính năng sản phẩm (product features) đang gặp rủi ro bị hủy bỏ vì chi phí vận hành cao khi đưa vào môi trường sản xuất (production environment). Câu hỏi yêu cầu xác định loại phân tích mà project lead (người dẫn dắt dự án) nên thực hiện trước đó để tránh tình huống này.

📘 Bối cảnh PMP mới nhất (PMBOK® 7th Edition & Agile Practice Guide, cập nhật đến 2026): Trong môi trường Agile/hybrid, việc đánh giá rủi ro sớm giúp ưu tiên backlog, tránh lãng phí tài nguyên vào các tính năng không khả thi về chi phí dài hạn. Chi phí vận hành cao là một rủi ro tài chính/vận hành điển hình, cần được xác định qua quản lý rủi ro để điều chỉnh kế hoạch kịp thời.

✅ Đáp án đúng: "Risk analysis"

Lý do chọn đáp án đúng:
Project lead cần thực hiện Risk analysis (phân tích rủi ro) để xác định sớm các rủi ro tiềm ẩn như chi phí vận hành cao khi triển khai sản xuất. Trong Agile, phân tích rủi ro giúp đánh giá tác động (impact) và xác suất (probability) của rủi ro, từ đó ưu tiên hoặc loại bỏ tính năng khỏi product backlog trước khi phát triển. Điều này tránh tình trạng phát hiện muộn trong iteration review, tiết kiệm chi phí và thời gian.
🛠️ Áp dụng PMP: Theo PMBOK® 7th Edition (Process 4.5: Manage Risks) và Agile Practice Guide, risk analysis là công cụ cốt lõi trong Iteration Planning và Backlog Refinement để dự đoán rủi ro vận hành (operational risks).

📋 Phân tí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 bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên ngữ cảnh câu hỏi và kiến thức PMP mới nhất:

• ❌ Benefits analysis
  Sai vì: Phân tích lợi ích (benefits analysis) tập trung vào việc đánh giá giá trị kinh doanh và lợi ích dài hạn của tính năng (như ROI - Return on Investment), chứ không phải dự đoán rủi ro chi phí vận hành. Nó hữu ích cho việc ưu tiên tính năng dựa trên lợi ích, nhưng không giúp tránh rủi ro hủy bỏ do chi phí cao. Trong PMBOK® 7th (Principle 5: Optimize Resource Allocation), benefits analysis không thay thế cho risk management.

• ✅ Risk analysis
  Đúng vì: Như đã giải thích ở trên, đây là phân tích trực tiếp xác định và đánh giá rủi ro (ví dụ: chi phí vận hành vượt ngân sách), giúp project lead điều chỉnh sớm trong Agile ceremonies như Backlog Refinement hoặc Iteration Planning. Tránh tình huống "phát hiện muộn" trong review.
  📘 Nguồn: PMBOK® Guide – Seventh Edition (2021), trang 139-142 (Manage Risks); Agile Practice Guide (PMI, 2017, cập nhật 2023), phần Risk Management in Agile.

• ❌ Capacity analysis
  Sai vì: Phân tích năng lực (capacity analysis) đánh giá khả năng đội ngũ (team velocity) hoặc tài nguyên hiện tại để hoàn thành công việc trong iteration, không liên quan đến chi phí vận hành tương lai sau khi sản xuất. Nó chỉ giúp ước lượng workload, không dự đoán rủi ro tài chính dài hạn.
  🛠️ Áp dụng PMP: PMBOK® 7th (Model 10: Capacity & Demand), dùng cho resource planning, không phải operational costs.

• ❌ Gap analysis
  Sai vì: Phân tích khoảng trống (gap analysis) so sánh trạng thái hiện tại với trạng thái mong muốn (current vs. future state), thường dùng để xác định thiếu hụt kỹ năng hoặc yêu cầu. Nó không tập trung vào rủi ro chi phí vận hành, mà chỉ giúp lập kế hoạch lấp khoảng trống, không tránh được hủy tính năng do chi phí.
  📘 Nguồn: PMBOK® 7th Edition, phần Business Analysis (trang 75-80), gap analysis thuộc Requirements Management, không phải Risk.

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

✅ Sử dụng Risk analysis sớm trong Agile sẽ giúp dự án linh hoạt hơn, giảm lãng phí (theo Lean-Agile principles). Project lead nên tích hợp công cụ như Risk Register hoặc Probability-Impact Matrix trong mọi iteration.
📚 Tài liệu tham khảo chính:

• PMBOK® Guide – Seventh Edition (PMI, 2021).
• Agile Practice Guide (PMI, 2017, cập nhật 2023).
• PMP Exam Content Outline (PMI, 2021, hiệu lực đến 2026).

Nếu cần ví dụ thực tế hoặc câu hỏi PMP khác, hãy cho tôi biết! 🚀

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

Câu hỏi này thuộc chủ đề Quản lý Bên liên quan (Stakeholder Management) trong PMP, theo PMBOK Guide 7th Edition (2021) và các cập nhật mới nhất đến 2026. Tình huống mô tả một dự án xây dựng nhà máy năng lượng đã hoàn thành, nhưng ngay trước khi vận hành, cộng đồng địa phương (một bên liên quan quan trọng) phản đối và chặn lối vào. Lý do họ đưa ra là dự án ảnh hưởng đến khu bảo tồn tự nhiên và thiếu tư vấn trước đó từ đội ngũ dự án.

📌 Vấn đề cốt lõi: Đây là hậu quả của việc quản lý bên liên quan kém, dẫn đến xung đột bất ngờ sau khi dự án kết thúc (closing phase). Project manager cần xác minh (verify) đầu tiên tài liệu nào để đánh giá và khắc phục nhanh chóng, tập trung vào nguyên nhân gốc rễ từ quy trình lập kế hoạch và tương tác với bên liên quan. Điều này nhấn mạnh nguyên tắc Stakeholder Engagement trong People Domain và Stakeholder Performance Domain của PMBOK 7th.

✅ Đáp án đúng: Stakeholder engagement plan

Lý do lựa chọn:

• Theo PMBOK 7th Edition (Section 4.6 Manage Stakeholder Engagement), Stakeholder engagement plan là tài liệu cốt lõi định nghĩa chiến lược tương tác, tư vấn và quản lý kỳ vọng của các bên liên quan (bao gồm cộng đồng địa phương). Trong tình huống này, cộng đồng là bên liên quan bị ảnh hưởng trực tiếp (impacted stakeholder), và vấn đề rõ ràng xuất phát từ thiếu "prior consultation" (tư vấn trước). Project manager phải verify kế hoạch này đầu tiên để kiểm tra xem có thực hiện đúng các hoạt động engagement (như họp cộng đồng, thu thập ý kiến) hay không. Việc này giúp xác định lỗ hổng và kích hoạt các biện pháp khắc phục khẩn cấp như đàm phán hoặc cập nhật engagement strategies.
• 🛠️ Hành động ưu tiên: Verify giúp PM nhanh chóng đánh giá mức độ engagement hiện tại (unaware, resistant, neutral, supportive, leading) và điều chỉnh để giảm thiểu rủi ro vận hành.
• Nguồn tham khảo: PMBOK Guide 7th Edition (p. 107-110, Stakeholder Engagement); PMI's Process Groups: A Practice Guide (2022 update).

📋 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, với giữ nguyên văn bản gốc bằng tiếng Anh và giải thích chi tiết bằng tiếng Việt:

• Stakeholder engagement plan ✅
  Đúng vì: Đây là tài liệu trực tiếp liên quan đến vấn đề phản đối từ cộng đồng (stakeholder). Kế hoạch này quy định các hoạt động tư vấn, giao tiếp và quản lý kỳ vọng. Verify đầu tiên giúp PM xác nhận xem có bỏ sót engagement với bên liên quan địa phương hay không, phù hợp với nguyên tắc "Tailor engagement to stakeholder needs" trong PMBOK 7th. Không verify cái này trước sẽ làm chậm trễ giải quyết khủng hoảng.

• Cost-benefit analysis ❌
  Sai vì: Phân tích chi phí-lợi ích dùng để đánh giá tính khả thi tài chính của dự án ở giai đoạn khởi tạo (Initiation), không liên quan đến xung đột cộng đồng sau hoàn thành. Vấn đề ở đây là engagement, không phải lợi ích kinh tế. Verify cái này sẽ lạc hướng và không giải quyết được protest ngay lập tức (PMBOK 7th, Business Analysis Domain).

• Business case ❌
  Sai vì: Business case là tài liệu biện minh cho sự tồn tại của dự án, tập trung vào giá trị kinh doanh và ROI ở giai đoạn đầu. Nó không đề cập đến tư vấn cộng đồng hay tác động môi trường cụ thể. Verify nó không giúp xử lý khủng hoảng stakeholder hiện tại, vốn đã qua giai đoạn phê duyệt (PMBOK 7th, p. 33-35, Strategic Mindset).

• Risk management plan ❌
  Sai vì: Kế hoạch quản lý rủi ro xác định, phân tích và ứng phó rủi ro dự án (như delay, budget overrun), nhưng phản đối cộng đồng là vấn đề stakeholder cụ thể, không phải rủi ro kỹ thuật. Mặc dù có thể coi là "stakeholder risk", nhưng verify Stakeholder engagement plan ưu tiên hơn vì nó trực tiếp xử lý nguyên nhân (thiếu consultation). Risk plan chỉ là bước thứ hai nếu cần escalate (PMBOK 7th, Uncertainty Domain, p. 117).

🛠️ Kết luận và lời khuyên PMP

Tình huống nhấn mạnh tầm quan trọng của việc quản lý bên liên quan xuyên suốt vòng đời dự án (từ Planning đến Closing). Theo PMP Exam Content Outline 2021 (cập nhật 2024-2026), Stakeholder chiếm 10-15% câu hỏi. Luôn ưu tiên verify kế hoạch engagement khi có xung đột bất ngờ từ bên ngoài!

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

• PMBOK Guide 7th Edition (PMI, 2021).
• The Standard for Project Management (PMI, 2021).
• PMI Blog: "Stakeholder Engagement in Practice" (2023 update).
• Practice Standard for Project Configuration Management (PMI, 2023).

Nếu cần ví dụ case study thực tế hoặc câu hỏi luyện tập thêm, hãy cho tôi biết! 🚀

🧩 Phân tích 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: Project manager đang sử dụng nhà thầu phụ (subcontractor) để phát triển ứng dụng di động. Khi đội ngũ dự án kiểm tra (test) ứng dụng, họ phát hiện ứng dụng không tuân thủ các tiêu chuẩn giao diện người dùng mới của công ty (new company user-interface standards). Quan trọng là các tiêu chuẩn này KHÔNG được đề cập trong Statement of Work (SOW) – tài liệu hợp đồng chính quy định phạm vi công việc. Dù vậy, nhà thầu phụ đồng ý thực hiện thêm scope (thêm công việc) với điều kiện trả tiền ngay lập tức cho phần công việc bổ sung này.

Câu hỏi yêu cầu: Project manager nên làm gì tiếp theo?
🛠️ Bối cảnh PMP: Đây là trường hợp thay đổi phạm vi (scope change) không dự đoán trước, liên quan đến quản lý hợp đồng (Procurement Management) và quy trình kiểm soát thay đổi (Change Control Process). Theo PMBOK Guide 7th Edition (2021, cập nhật PMP đến 2026), mọi thay đổi phải qua quy trình chính thức để tránh rủi ro pháp lý, tài chính và đảm bảo giá trị dự án.

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

Đáp án đúng: Initiate a change request and review the contract to evaluate the payment options before responding.

Lý do:
🧩 Theo nguyên tắc PMP, project manager PHẢI khởi xướng Change Request (Yêu cầu thay đổi) để xử lý thêm scope mới (UI standards), vì đây là thay đổi chính thức dù không có trong SOW ban đầu. Đồng thời, xem xét lại hợp đồng (review the contract) để đánh giá các lựa chọn thanh toán (payment options) trước khi phản hồi nhà thầu phụ. Điều này đảm bảo tuân thủ Integrated Change Control (Process 4.6 trong PMBOK 7), tránh cam kết miệng dẫn đến tranh chấp. Không trả tiền ngay để tránh vi phạm điều khoản hợp đồng hiện tại.
📘 Nguồn: PMBOK Guide 7th Edition, Domain 4: Project Change (trang 127-130); Procurement Management Principles (Appendix).

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

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

• Negotiate new pricing based on the revised estimations from the subcontractor that reflect the new work.
  ❌ [SAI]: Phương án này bỏ qua quy trình chính thức, dẫn đến đàm phán không kiểm soát (uncontrolled negotiation). PMP yêu cầu change request trước để đánh giá tác động toàn diện (scope, cost, schedule), không chỉ dựa vào ước tính từ nhà thầu phụ. Có nguy cơ overpay hoặc tranh chấp sau.
  🛠️ Lý do sai: Vi phạm nguyên tắc "formal change control" (PMBOK 7, Principle 12: Optimize Risk Responses).

• Initiate a change request and review the contract to evaluate the payment options before responding.
  ✅ [ĐÚNG]: Như đã giải thích ở trên, đây là hành động chuẩn mực: Khởi xướng change request để phê duyệt thêm scope, và review contract để kiểm tra điều khoản thanh toán hợp pháp. Đảm bảo dự án tuân thủ governance và bảo vệ lợi ích công ty.
  📘 Nguồn: PMBOK Guide 7th Edition, 4.6 Manage Project Changes; Contract Administration Guidelines.

• Deny the subcontractor's payment request, because the product does not comply with the project needs and close the project.
  ❌ [SAI]: Phương án cực đoan, không hợp lý vì sản phẩm đã gần hoàn thành và nhà thầu phụ sẵn sàng sửa. Đóng dự án (close project) chỉ áp dụng khi không thể khắc phục, vi phạm Stakeholder Engagement và có thể dẫn đến kiện tụng (dispute). SOW không có UI standards nên không phải vi phạm hợp đồng.
  🛠️ Lý do sai: Không tuân thủ Tailoring Approach (PMBOK 7, trang 23) và Procurement Closure chỉ sau khi hoàn tất.

• Initiate a change to incorporate an immediate payment milestone in the contract as per the subcontractor's request.
  ❌ [SAI]: Dù khởi xướng change, phương án này chấp nhận ngay yêu cầu milestone thanh toán của nhà thầu phụ mà không đánh giá rủi ro (risk như cash flow, performance). PMP yêu cầu phân tích đầy đủ trước khi approve, không "as per request" để tránh thiên vị nhà thầu.
  🛠️ Lý do sai: Bỏ qua Impact Analysis trong Change Control (PMBOK 7, Domain 3: Uncertainty).

Tóm tắt PMP takeaway 🎯: Luôn ưu tiên quy trình kiểm soát thay đổi chính thức để bảo vệ dự án, đặc biệt với nhà thầu phụ!

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

Câu hỏi PMP này tập trung vào quy trình thu thập và xác định các yêu cầu (requirements) trong một dự án công cộng lớn, có tác động cao đến cư dân thị trấn. 📍 Bối cảnh chính: Dự án liên quan đến nhiều bên liên quan (stakeholders) đa dạng, bao gồm cư dân, chính quyền địa phương và các nhóm cộng đồng. Project manager cần xác định các yêu cầu khác nhau một cách hiệu quả để đảm bảo dự án đáp ứng kỳ vọng, giảm thiểu rủi ro xung đột và tối ưu hóa giá trị.

🛠️ Mục tiêu câu hỏi: Kiểm tra kiến thức về Stakeholder Management trong PMBOK® Guide 7th Edition (2021, cập nhật đến 2026 qua PMI Standards), đặc biệt là việc phân tích stakeholders (Stakeholder Analysis) để thu thập requirements toàn diện. Không chỉ liệt kê yêu cầu mà phải ưu tiên dựa trên ảnh hưởng (influence) và lợi ích (interests) của họ, phù hợp với nguyên tắc Tailoring và Stakeholder Engagement trong dự án công cộng có tác động xã hội cao.

📘 Dẫn nguồn:

• PMBOK® Guide 7th Edition, Section 4.6 Stakeholder Management Performance Domain & Tools như Power/Interest Grid, Stakeholder Register.
• Process Group: Planning - Collect Requirements (từ PMBOK 6th, chuyển sang Models/Methods trong 7th).
• PMI's Stakeholder Engagement Practice Guide (2020).

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

Đáp án đúng: Analyze the interests and influence of stakeholders and evaluate their requirements.

Lý do chi tiết:

• Trong dự án công cộng lớn với tác động cao đến cư dân, project manager phải thực hiện Stakeholder Analysis đầu tiên để phân loại stakeholders theo influence (ảnh hưởng) và interests (lợi ích). Điều này giúp đánh giá (evaluate) requirements một cách ưu tiên, tránh bỏ sót nhu cầu quan trọng từ các nhóm có ảnh hưởng cao (ví dụ: cư dân bị ảnh hưởng trực tiếp).
• 🧩 Phù hợp PMP mới nhất (7th Ed.): Sử dụng công cụ như Power/Interest Grid hoặc Salience Model để phân tích, sau đó thu thập requirements từ Stakeholder Register. Đây là bước cốt lõi trong Requirements Management, đảm bảo dự án value-driven và holistic (toàn diện), giảm rủi ro scope creep hoặc xung đột cộng đồng.
• Nếu bỏ qua, dự án có thể thất bại do thiếu sự ủng hộ từ stakeholders chính.

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

• ✅ Analyze the interests and influence of stakeholders and evaluate their requirements.
  Đúng vì đây là quy trình chuẩn PMP: Phân tích interests/influence giúp ưu tiên requirements từ các stakeholders đa dạng, đặc biệt trong dự án công cộng. Đảm bảo inclusive approach (bao quát), phù hợp PMBOK 7th Ed. (Stakeholder Engagement Domain). 🏆

• ❌ Include only the key requirements and keep the stakeholders informed about scope decisions.
  Sai vì cách tiếp cận này thiên vị và không toàn diện, chỉ chọn "key requirements" chủ quan mà không phân tích stakeholders trước. Nó bỏ qua engagement sớm, dẫn đến rủi ro phản đối từ cư dân. PMBOK nhấn mạnh collect ALL potential requirements trước khi ưu tiên (Elicitation Techniques), không phải "inform sau".

• ❌ Add only the opinions of the team, because they know the objectives of the project.
  Sai vì bỏ qua stakeholders bên ngoài (cư dân thị trấn), chỉ dựa vào team nội bộ là internal bias, vi phạm nguyên tắc Stakeholder-Centric trong PMP. Team biết objectives nhưng không đại diện cho impacts xã hội. PMBOK 7th yêu cầu external stakeholder input cho dự án công cộng (Risk Management Domain).

• ❌ Include only the common requirements of each stakeholder group in the project goals.
  Sai vì hạn chế ở common requirements sẽ loại bỏ các nhu cầu độc đáo (unique needs) từ nhóm thiểu số, dẫn đến unfair outcomes và rủi ro pháp lý/xã hội. PMP yêu cầu evaluate ALL requirements qua analysis, không chỉ "common" (Prioritization Models như MoSCoW chỉ dùng SAU khi đã collect đầy đủ).

🛡️ Kết luận PMP: Luôn ưu tiên Stakeholder Analysis để định nghĩa requirements trong dự án high-impact. Áp dụng hybrid approach nếu cần Agile cho feedback loops! Nếu cần ví dụ case study, hãy hỏi thêm. 🚀

🧩 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ý Lịch trình Dự án (Project Schedule Management) và Quản lý Phạm vi Dự án (Project Scope Management) theo PMBOK® Guide 7th Edition (cập nhật đến 2026). Tình huống mô tả: Một project manager (PM) được giao dự án quy định pháp lý cho quốc gia của mình, với thời hạn giao kết quả tuân thủ luật mới rất gấp (tight deadline), và chưa phân công thành viên đội ngũ. Đồng nghiệp thông báo có dự án cùng phạm vi (same scope) cho quốc gia khác đã hoàn thành cách đây 1 năm. Câu hỏi yêu cầu hành động đầu tiên (first) mà PM nên làm.

🛠️ Mục tiêu chính: Trong tình huống khẩn cấp với deadline chặt chẽ và thiếu đội ngũ, PM cần ưu tiên thu thập thông tin lịch sử từ dự án tương tự để ước lượng nhanh chóng (không phải lập kế hoạch chi tiết từ đầu), giúp xây dựng lịch trình khả thi ngay lập tức. Điều này phù hợp với nguyên tắc Value Delivery và Estimation Techniques trong PMBOK® 7th Edition.

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

• PMBOK® Guide 7th Edition: Phần 4.5 (Project Schedule) và 6.4 (Estimate Activity Durations – sử dụng Analogous Estimating từ OPAs).
• PMBOK® Guide 6th Edition (vẫn áp dụng cho processes): 6.4.2.3 Analogous Estimating và 2.3.2 Organizational Process Assets (OPAs).

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

Đáp án đúng: Review organizational process assets (OPAs) and perform analogous estimating.

Lý do:

• Đây là hành động đầu tiên và hiệu quả nhất vì dự án tương tự (same scope, completed 1 year ago) là nguồn dữ liệu lịch sử rất gần (historical data), thuộc OPAs (như lessons learned, baselines từ dự án trước).
• Analogous estimating (ước lượng tương tự) là kỹ thuật top-down, nhanh chóng (top-level estimate), phù hợp khi deadline gấp, team chưa assign, và cần estimate schedule/cost sớm để lập kế hoạch.
• Theo PMBOK® 7th: OPAs cung cấp dữ liệu thực tế từ dự án tương đương, giúp PM giảm uncertainty và tăng độ chính xác ban đầu (accuracy: -25% to +75%). Không cần chi tiết hoạt động ngay.

🧩 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. Tôi giữ nguyên văn bản gốc tiếng Anh của phương án, chỉ giải thích hoàn toàn bằng tiếng Việt với lý do đúng/sai dựa trên quy trình PMP.

• ✅ [ĐÚNG] Review organizational process assets (OPAs) and perform analogous estimating.
  🛠️ Giải thích đúng: Như trên, OPAs chứa dữ liệu dự án tương tự (historical info, lessons learned). Analogous estimating dùng chính dữ liệu này để estimate nhanh (dựa trên project tương đương), là bước Initiate/Plan đầu tiên phù hợp tight deadline. Hiệu quả cao vì scope giống, thời gian gần (1 năm), giúp PM lập baseline schedule ngay mà không chờ team.

• ❌ [SAI] Register a new risk in the risk management plan.
  🛠️ Giải thích sai: Chưa có risk cụ thể được identify (chỉ tight deadline chung chung). Theo Identify Risks process (PMBOK® 7th, 11.2), phải analyze trước mới register vào risk register (không phải risk management plan). Hành động này quá sớm, bỏ qua cơ hội dùng dữ liệu lịch sử để mitigate rủi ro deadline.

• ❌ [SAI] Ask for additional resources and review the project estimate.
  🛠️ Giải thích sai: Chưa có estimate nào để review (team chưa assign, chưa có data). Acquire Resources (9.2) và resource estimation cần sau khi có activity durations. Asking resources premature, có thể dẫn đến over-allocation. PMBOK® nhấn mạnh estimate trước khi request resources.

• ❌ [SAI] Complete a bottom-up estimation for the project activities.
  🛠️ Giải thích sai: Bottom-up estimating yêu cầu chi tiết WBS, activities đầy đủ và team input (expert judgment từ resources đã assign), rất tốn thời gian (accuracy: -5% to +20%). Với deadline gấp và team chưa có, đây là lựa chọn tồi tệ nhất – trái ngược nguyên tắc "estimate nhanh cho early planning" trong PMBOK® 7th.

🛡️ Kết luận PMP: Luôn ưu tiên leverage OPAs cho dự án lặp lại/tương tự để tối ưu hóa value delivery trong tình huống khẩn cấp! Nếu cần thực hành thêm, tham khảo PMI.org cho case studies 2026. 🚀

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

Câu hỏi này thuộc lĩnh vực Quản lý Đội ngũ (Manage Team) và Quản lý Stakeholder trong PMP (PMBOK® Guide 7th Edition và các nguyên tắc Agile Hybrid). Tình huống: Trưởng nhóm dự án (team lead) đã rời tổ chức. Ban quản lý (management) quyết định thăng chức cho kỹ sư A (engineer A) vào vị trí này. Quản lý dự án (project manager - PM) tin rằng việc chọn A sẽ gây thêm vấn đề cho dự án, và kỹ sư B (engineer B) phù hợp hơn. PM đã trình bày tất cả lập luận với ban quản lý, nhưng quyết định của họ vẫn không thay đổi. Câu hỏi yêu cầu hành động tiếp theo phù hợp nhất của PM để đảm bảo dự án thành công, tuân thủ quyền hạn tổ chức và duy trì động lực đội ngũ.

🔑 Mục tiêu chính: PM phải tôn trọng quyết định của cấp trên (stakeholders), hỗ trợ người được chọn, tránh xung đột nội bộ, và tập trung vào giá trị dự án (value delivery) theo nguyên tắc Servant Leadership (Lãnh đạo Phục vụ) trong PMBOK® 7th Edition.

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

• PMBOK® Guide 7th Edition: Principle 5 (Team), Principle 9 (Leadership), Process 9.5 Manage Team.
• PMI Code of Ethics & Professional Conduct: Trách nhiệm tôn trọng quyết định tổ chức (Respect & Responsibility).
• Agile Practice Guide: Empowering the team và hỗ trợ động lực cá nhân.

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

Đáp án đúng: Help engineer A to become familiar with this new role and ensure engineer B stays motivated.

Lý do (🛠️ Giải thích chi tiết):

• PM không có quyền phủ quyết quyết định của management (họ là senior stakeholders). Thay vào đó, PM phải hỗ trợ chuyển giao vai trò mượt mà (support transition) cho engineer A bằng cách giúp A làm quen (onboarding, training), đồng thời duy trì động lực cho engineer B để tránh mất mát tài năng (retain talent).
• Điều này phù hợp với Servant Leadership: PM phục vụ đội ngũ bằng cách xây dựng năng lực và giữ tinh thần cao, đảm bảo dự án tiếp tục mà không gián đoạn.
• Theo PMBOK® 7th (Principle 9): Tập trung vào leadership để adapt thay vì resist. Kết quả: Tối ưu hóa hiệu suất đội ngũ, giảm rủi ro nhân sự. ✅

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

• Promote engineer B instead since the project manager has the authority to make this decision.
  ❌ Sai: PM không có quyền tự ý thăng chức engineer B, vì quyết định nhân sự cấp cao thuộc management (organizational authority). Hành động này vi phạm hierarchical structure và PMI Code of Ethics (Respect - không lật ngược quyết định stakeholder). Sẽ gây xung đột nội bộ, mất lòng tin, và rủi ro dự án cao hơn. PMBOK® 7th nhấn mạnh PM chỉ manage team trong khuôn khổ phê duyệt.

• Help engineer A to become familiar with this new role and ensure engineer B stays motivated.
  ✅ Đúng: Như đã giải thích ở trên. Đây là cách proactive và tích cực nhất, hỗ trợ cá nhân hóa (individual development) và team motivation, phù hợp với Manage Team process (training, mentoring). Đảm bảo continuity và high performance. 🏆

• Coach engineer B to be prepared to perform this role if and when engineer A fails.
  ❌ Sai: Hành động này thể hiện thiếu tin tưởng công khai vào engineer A (undermining), có thể làm giảm động lực của A ngay từ đầu và tạo không khí tiêu cực. PMBOK® 7th (Team Principle) yêu cầu xây dựng lòng tin, không chuẩn bị "kế hoạch B công khai" gây phân tâm. Nên focus vào hỗ trợ hiện tại thay vì dự đoán thất bại.

• Request management approval that engineer B will be promoted if engineer A fails in this role.
  ❌ Sai: Yêu cầu này tiếp tục thách thức quyết định management, thể hiện resistance thay vì acceptance. Nó tạo áp lực không cần thiết lên A (fear of failure) và không hiệu quả vì management đã từ chối ý kiến PM. Theo PMI Ethics (Responsibility), PM phải implement quyết định và monitor performance, không negotiate contingency nhân sự ở giai đoạn này. 📉

🛡️ Lời khuyên PMP: Trong thực tế (updates đến 2026), PM nên document discussion, escalate nếu rủi ro cao (Risk Register), và measure outcomes qua retrospectives. Điều này giúp dự án resilient! 🚀

🧩 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ả tình huống một Project Manager (PM) được giao quản lý một dự án mới, sẽ được thực hiện theo khung Agile. Sponsor (nhà tài trợ) yêu cầu ước lượng chi phí (cost estimation) để xây dựng business case (hồ sơ kinh doanh). Đây là giai đoạn sớm nhất của dự án, khi chưa có backlog chi tiết hay team đầy đủ. Trong Agile (theo PMBOK 7th Edition và Agile Practice Guide), ước lượng chi phí ban đầu thường sử dụng phương pháp tương tự (analogous estimating) dựa trên dữ liệu lịch sử từ dự án tương đương, vì Agile nhấn mạnh tính linh hoạt và iterative, không cần chi tiết ngay từ đầu. Mục tiêu là cung cấp estimate thô để sponsor quyết định đầu tư.

✅ Đáp án đúng: Review the completion costs of similar projects.
Lý do lựa chọn (theo PMP mới nhất đến 2026 - PMBOK 7th Edition & Agile Practice Guide):
Trong giai đoạn khởi tạo dự án Agile, để xây dựng business case, PM nên xem xét chi phí hoàn thành (completion costs) của các dự án tương tự trước đây. Đây chính là phương pháp Analogous Estimating (ước lượng tương tự), được khuyến nghị cho high-level estimate sớm, dựa trên dữ liệu thực tế (actual costs) từ dự án lịch sử. Agile ưu tiên dữ liệu thực tế này để tránh over- hoặc under-estimating, giúp sponsor nhanh chóng có cái nhìn tổng quan về chi phí tiềm năng mà không cần chi tiết phức tạp. Điều này phù hợp với nguyên tắc Value Delivery trong Agile (PMBOK 7, trang 47-50).

🛠️ Phân tích chi tiết 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. Tôi đánh dấu ✅ cho đúng và ❌ cho sai, kèm lý do dựa trên PMBOK 7th Edition (2021, cập nhật không thay đổi đến 2026) và Agile Practice Guide (2017, tích hợp PMBOK 7).

• ❌ Ensure the client representative is involved in the estimation.
  Phương án này sai vì ở giai đoạn đầu dự án Agile mới, chưa có client representative (đại diện khách hàng) chính thức tham gia estimation. Trong Agile, Product Owner (PO) sẽ đại diện stakeholder sau, nhưng business case ban đầu do PM và sponsor xử lý với dữ liệu lịch sử. Việc ép buộc client rep tham gia sớm có thể làm chậm quá trình và không phù hợp với high-level estimate (PMBOK 7, 6.4 Estimate Costs: Nhấn mạnh expert judgment & historical info trước collaborative estimation).

• ❌ Ensure that a 20% contingency is included in the estimation.
  Phương án này sai vì không có quy định cố định 20% contingency trong PMP/Agile. Contingency reserve được xác định dựa trên risk analysis cụ thể (qualitative/quantitative), không phải con số arbitrary. Trong Agile, reserve linh hoạt qua iterations, và thêm 20% blind có thể làm business case kém thuyết phục (PMBOK 7, 7.5 Plan Risk Responses & 7.1 Plan Cost Management: Contingency phải data-driven).

• ✅ Review the completion costs of similar projects.
  Phương án này đúng (như đã giải thích ở trên). Đây là analogous estimating lý tưởng cho dự án Agile mới, sử dụng actual completion costs từ dự án tương tự để dự báo nhanh, chính xác cao ở early stage. Hỗ trợ sponsor xây business case hiệu quả (Agile Practice Guide, phần Estimation: Historical data là baseline cho story points/velocity sau này).

• ❌ Review the lessons learned from similar projects.
  Phương án này sai vì lessons learned tập trung vào bài học kinh nghiệm về processes, risks, improvements (không phải chi phí cụ thể). Nó hữu ích cho planning sau (như retrospective), nhưng không trực tiếp cung cấp cost data cho business case. PM cần costs thực tế, không phải qualitative lessons (PMBOK 7, 4.7 Manage Project Knowledge: Lessons learned hỗ trợ knowledge management, không thay thế parametric/analogous estimating).

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

• PMBOK Guide 7th Edition (2021): Domain 5 - Measurement (Estimate Costs), trang 137-140; Agile Hybrid approaches.
• Agile Practice Guide (PMI, 2017): Chapter 4 - Implementing Agile: Estimation Techniques (Historical Velocity & Analogous).
• Cập nhật PMP Exam Content Outline 2021 (hiệu lực đến 2026): Task 5.1 Estimate project costs using duration, budget, parametric, bottom-up techniques (analogous là top choice cho early 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ụ, hãy hỏi nhé!