What goes into the WBS Part I


Project Managers are sometimes confused on what deliverables to put into their WBS.

Is a test environment a deliverable? It seems obvious that yes, the test environment is a deliverable since we need to test, and for that we need a test environment.

What about status reports? Suddenly, we’re not sure. Do project planning and management artifacts go into the WBS?

See here for definitions of a deliverable:

You’ll notice these definitions repeat certain phrases: tangible, outcome, measurable, output, etc.

By this measure, a status report is a deliverable. But does it go into the WBS?

I wrote here about the WBS: “The WBS should contain 100% of the project scope. If it’s not in the WBS, it’s not in scope. Any expected deliverables that are not in the WBS represent a quality risk. Conversely, the WBS does not contain any extras. If it does not advance the project, it should not be in the WBS. Extras are wasteful and represent a cost and schedule risk.”

From project initiation all the way through to close, any deliverable necessary to successfully plan and execute the project should be captured in the WBS. This includes anything needed to meet your organizational requirements for project approval and execution.

In short: if you need it do get the project done then it’s a deliverable. All deliverables must be included in the WBS.

EDIT: See here for some examples of things that should not go into the WBS.

So yes, project planning and management artifacts — including status reports — are deliverables that should be captured in the WBS.