PMP · Question #775
A project's customer is furious. When the customer arrived at the project site, they discovered that one of their requirements was not met. What should the project manager do?
The correct answer is B. Refer to the requirements traceability matrix and analyze the requirement. When a customer discovers a missing requirement, the project manager should first consult the requirements traceability matrix to objectively analyze and verify the requirement's status and history.
Question
Options
- ADiscuss and agree with the customer to implement the missing requirement
- BRefer to the requirements traceability matrix and analyze the requirement
- CConsult the scope management plan with the customer to understand the gap
- DAnalyze the benefits management plan and implement the needed change
How the community answered
(17 responses)- A6% (1)
- B76% (13)
- C6% (1)
- D12% (2)
Why each option
When a customer discovers a missing requirement, the project manager should first consult the requirements traceability matrix to objectively analyze and verify the requirement's status and history.
Immediately agreeing to implement a missing requirement without verifying its status in project documentation (like the RTM) can lead to unmanaged scope changes or addressing requirements that were never formally agreed upon.
When a customer reports a missing requirement, the project manager's first action should be to consult the requirements traceability matrix. This tool provides an objective record of all requirements, their status, and their lineage, helping to verify if the requirement was ever documented, approved, or removed, which is crucial for addressing the customer's concern accurately and professionally.
The scope management plan outlines how scope will be managed, not the specific details of individual requirements. While relevant, it is less direct than the requirements traceability matrix for analyzing a specific missing requirement.
The benefits management plan focuses on how project benefits will be realized, which is distinct from the detailed status of individual requirements. Analyzing it does not directly help resolve a specific missing requirement discovered by the customer.
Concept tested: Requirements management and scope control
Source: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok
Topics
Community Discussion
7The answer is B. When a customer is upset about a missing requirement, your first move is always to verify the facts before promising anything. The requirements traceability matrix is the single source of truth that shows whether the requirement was approved, how it was tracked, and whether it was actually part of the project scope. Option A is tempting because it feels like good customer service, but agreeing to implement something on the spot without checking your documentation can create scope creep and set the wrong precedent. Calmly pull up the matrix, walk through it together, and let the data guide the conversation.
B is right but the RTM only tells you if the requirement was documented, not whether it was actually delivered, so you may also need to check the accepted deliverables and validation results before having that conversation.
Confirmed B on my exam. Before you start promising fixes to an angry client, you check the requirements traceability matrix to see whether that requirement was actually approved and scoped, or just something they mentioned in passing.
Our group is landing on B. Before agreeing to any fix you need to check the requirements traceability matrix to confirm whether the requirement was actually approved and scoped, since the customer could be referencing something that never made it into the baseline.
B is correct. Before you negotiate or implement anything, you check the requirements traceability matrix to confirm whether that requirement was actually approved and scoped, or just something the customer assumed was included.
C. The scope management plan is where the process gap lives, and that cost me points first time.
B is correct, Wesley. The scenario is about a decomposition or definition issue, and that lives in the scope baseline, not the scope management plan which just describes the process for managing scope.