PMP-ers: How does PMI recommend tracking of requirements through to project deliverables?

Question

Reading through PMI's PMBOK and Rita's exam prep guide this morning, I'm failing to see if and how they advocate requirements to be tracked through in project deliverables. How does a stakeholder know and verify that their requirement has been met? (or that the requirement was deferred from the project)

Mentioned is a "traceability matrix" that relates requirements to project business objectives and charter - but how are these requirements tracked in the deliverables - how does the WBS or WBS dictionary track the satisfaction of requirements?

~ Kevin

Answer 1

Tracking is not a separate exercise. It's is done through each of the Process Groups. That's why they were designed that way. Each Process Group repeats through each phase of the project, so with each new phase you go through the processes of initiate, plan, execute, close. So as you close one phase and initiate the next you should be reviewing work to date to verify not only adherence to the specs, but also the validity of the project itself. These phase changes are where you decide to continue, or kill, the project.

Answer 2

First and foremost, PMI does not recommend anything. The PMBoK is not a method, it is a body of knowledge. The how is up to us. However, it talks about techniques to capture requirements, the matrix to maintain requirements, the requirements management plan, and how all of these are inputs into the scope definition. The process of defining your scope is the WBS, which results in your deliverables. So everything should be linked.

But, how you choose to track and control is up to you. The PMBoK can definitely serve as an input, along with other sources, to help you develop your PM methods.

Answer 3

Making sure that deliverables are tracked is a universal thing, but how you do this should be tailored to your project's needs. Don't fall into the trap of using a one-size-fits-all approach.

For example, delivery and acceptance of a very complex/critical/expensive product obtained from a subcontractor will likely be documented through an exchange of formal, legal correspondence so that the contract can be closed and money paid. On the other end of the spectrum, this would be overly burdensome for delivery of a simple/non-critical/cheap internal product, which could be documented in a note in the project file.