PMP · Question #1364
Toward the end of a project, the project manager did not receive approval from a key stakeholder because the necessary deliverables were not functioning as expected. What should the project manager do
The correct answer is B. Review the requirements traceability matrix.. A key stakeholder has not approved deliverables at project end because they are not functioning as expected.
Question
Toward the end of a project, the project manager did not receive approval from a key stakeholder because the necessary deliverables were not functioning as expected. What should the project manager do next?
Options
- AReview the stakeholder engagement plan.
- BReview the requirements traceability matrix.
- CReview the quality management plan.
- DReview the work breakdown structure (WBS).
How the community answered
(34 responses)- A3% (1)
- B82% (28)
- C12% (4)
- D3% (1)
Why each option
A key stakeholder has not approved deliverables at project end because they are not functioning as expected.
While stakeholder engagement is important, reviewing the plan primarily addresses communication and involvement, not the technical functionality of deliverables.
The requirements traceability matrix links requirements to test cases, design elements, and deliverables. If deliverables are not functioning as expected, reviewing the requirements traceability matrix would help the project manager verify that all specified requirements were indeed implemented, tested, and can be traced back to their origin, identifying any gaps or misinterpretations that led to the functionality issues.
The quality management plan outlines how quality will be assured and controlled, but the immediate problem is *why* the deliverables failed the expectation, which relates more directly to requirements fulfillment.
The Work Breakdown Structure (WBS) defines the scope by breaking down work, but it doesn't directly help in diagnosing *why* completed deliverables are not functioning as per stakeholder expectations.
Concept tested: Requirements validation and traceability
Source: https://www.projectmanagement.com/blog-post/10207/The-Requirements-Traceability-Matrix--Its-Purpose-and-Benefits
Topics
Community Discussion
6
Mateus R.Feb 9, 2026B is correct. Think of it like a builder handing over a house where the front door sticks: you don't start by re-reading the blueprint for the whole house, you grab the punch list that ties every requested feature back to the actual build and the final inspection. In PMP terms, that punch list is the requirements traceability matrix, which lets the PM trace each broken deliverable straight back to its original requirement to see where the work went off track.
Imani T.Feb 9, 2026Good analogy but the RTM traces requirements forward and backward through the lifecycle, so it also catches scope creep and unrequested features, not just broken deliverables.
Grace U.Mar 9, 2026B. Deliverables not working as expected means checking requirements traceability, not engagement.
Imani T.Feb 23, 2026B is the right call here because the RTB is what links each requirement to its deliverable and acceptance criteria, so you can verify the deliverables were actually built to spec before pointing fingers at the stakeholder. C is tempting since the deliverables arent functioning as expected, but the quality management plan tells you about process and standards, not whether the agreed requirements were met. If the requirements check out and the deliverable still doesnt perform, then youve got a quality issue to chase down. Has anyone run into a real scenario where the RTB was outdated or incomplete and you had to reconstruct
Toby R.Feb 6, 2026Got B on my exam last month, deliverables not functioning means check requirements traceability matrix.
Ingrid P.Mar 6, 2026B is correct because the requirements traceability matrix ties each requirement back to its deliverable and acceptance criteria, which is exactly what you check when a stakeholder says something is not functioning as expected. Worth a flashcard: stakeholder rejects deliverable for not meeting expectations = review the RTM first, not the quality plan. Anyone have a clean way to remember when to jump to the RTM versus the quality management plan in these end-of-project rejection scenarios?