Notes on the Work Breakdown Structure
The WBS is a systematic way of decomposing a project into specific deliverables in order to establish a common understanding of project scope. It defines logical relationships between deliverables, and is normally depicted as a hierarchical or outline structure in order to make the relationships clear. It also allows traceability between the project scope statement and the project schedule and is therefore a key input into project time management activities (scheduling).
My rules for developing the WBS:
Nouns, not verbs - The WBS describes deliverables. It is results oriented, not activity oriented. The project scope statement or requirements document(s) define the project goals. Goals break down into deliverables which go into the WBS. Goals are nouns. Verbs are the activities needed to deliver the nouns. They go into the project schedule, not the WBS.
The 100% rule - The WBS contains 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 represents a cost and schedule risk.
Element isolation - There should be no duplication of elements of the WBS; otherwise you get duplication of work and confusion over responsibility. Individual work elements can serve multiple purposes, but the WBS should be structured such that the element only appears once in the WBS.
Level of detail - Work packages should be of sufficient detail that the deliverable cannot be logically decomposed any further, and can be reliably and accurately estimated. One work package = one deliverable. In a matrix organizational structure, a work package should be executed by only one resource group.
The 8/80 rule - The work package duration should be within defined limits, typically between 8 to 80 hours of work effort. You may need to come back and decompose the work package after receiving activity duration estimates, which is a later step in the planning process.
My rules for developing the WBS:
Nouns, not verbs - The WBS describes deliverables. It is results oriented, not activity oriented. The project scope statement or requirements document(s) define the project goals. Goals break down into deliverables which go into the WBS. Goals are nouns. Verbs are the activities needed to deliver the nouns. They go into the project schedule, not the WBS.
The 100% rule - The WBS contains 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 represents a cost and schedule risk.
Element isolation - There should be no duplication of elements of the WBS; otherwise you get duplication of work and confusion over responsibility. Individual work elements can serve multiple purposes, but the WBS should be structured such that the element only appears once in the WBS.
Level of detail - Work packages should be of sufficient detail that the deliverable cannot be logically decomposed any further, and can be reliably and accurately estimated. One work package = one deliverable. In a matrix organizational structure, a work package should be executed by only one resource group.
The 8/80 rule - The work package duration should be within defined limits, typically between 8 to 80 hours of work effort. You may need to come back and decompose the work package after receiving activity duration estimates, which is a later step in the planning process.
posted by michael at 9:24 PM
0 Comments:
Post a Comment
<< Home