While doing some research for a new engagement on a DoD program, I came across a paper on the Work Breakdown Structure from a PMI Global conference. Applying the Work Breakdown Structure to the Project Lifecycle. The paper provides a good overview of the WBS and its important to project success.
What was curious though was the complete lack of reference to MIL-HNDBK-881-A. This is THE reference for constructing a WBS.
First let's Look at a Bad WBS Example
PMI has a practice guide for building the WBS. Here's a clip from the guide.
This is why most software projects FAIL.
There is no description of what done looks like. Only the work activities - the functional areas of the project. This WBS lays the ground for "confusing effort with results." The is a really BAD example of a WBS for software development.
We see this all the time. It's the concrete and pipe view of a WBS. The Pharma example in the PMI guidance have the same feel. The WBS describes the "functions" and "roles" but never the outcomes or the deliverables, let alone the final Product or Service. Read MIL-HDBK-881A, learn that deliverables that compose the Products are the outcome of project. The structure of the WBS around the deliverables is the Product Breakdown Structure and the Services needed to produce those products. By services, 881 means the manufactuturing services.
Back to our Regularly Scheduled Program
The paper describes how PMBOK® suggests the development of the schedule from the WBS and the WBS Dictionary to Activities and Milestones. No mention of Project Deliverables, although the WBS is a Deliverables Based description fo the project's outcomes. Not just Milestones. Outcomes. Tangible, physical products. We all know the story of the milestone as a rock on the side of the road with the whooshing sound as we pass by.
The paper skips right to the activities and their sequencing. DO NOT do this, you'll create a schedule that describes the "effort" executed by the functional members of the project and not the "outcomes."
The picture belong is the structure that must be in place for the schedule to have any credibility.
This of course is the Integrated Master Plan / Integrated Master Schedule. It speaks about Accomplishments and the Criteria - the exit criteria - for the work performed to produce those Accomplishments. Then assess the maturity of the product - the planned maturity against the actual maturity - at planned points in time. This is the way you can tell if you're "on schedule."
The WBS Describes the Product Structure and the Associated Costs
The WBS is the Product Breakdown and the supporting Processes that produce the Product. Not the project management processes, but the fabrication processes. Machines needed, buildings required etc. But the Product Breakdown Structure is the heart of the Work Breakdown Structure.
Here's what 881 says:
The WBS is defined, developed, and maintained throughout the system life cycle based on disciplined application of the systems engineering process. Other attributes include:
- A product-oriented family tree composed of hardware, software, services, data, and facilities. The family tree results from systems engineering efforts during the acquisition of a defense materiel item.
- A WBS displays and defines the product(s) to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end product.
Design, Code, Test is NOT a WBS. It's roles and functions. No product description, no project success.
When we speak about the "work activities" for the Work Package in the Schedule, we must speak in a grammar that conveys "done."
This grammar is the language of "systems engineering." PMI fails to adopt this paradigm. This is the source of most program failures. They don't have a grammar and a document that descries DONE. Just the work efforts, the roles performing those work efforts, and a structure showing those work effort. No one knows what DONE looks like from those work efforts.
It's ONLY About Defining What Done Looks Like
Near the end of the paper, the notion of the WBS drives straight into the ditch. The example of construction of a house illustrates where most of the problems come from in projects:
- The WBS is NOT the schedule - the suggestion that the WBS elements and their dependencies are to be represented in the schedule - along with the dependencies - is seriously flawed. At this ppint of the project planning the WBS must be a Product decomposition and a Cost Structure. Not the basis of scheduling.
- The basis of scheduling is the Product Deliverables, and the Work Packages needed to produce those Product Deliverables as shown in the second picture of this post. That picture at the top of the page is NOT the WBS. It is the project architecture that produces the increasing maturity of the products.
- It is the case that the WBS describes the scope of the project. No work should be done that is not in the WBS. This is the "all in" notion. But the sequence in Exhibit is NOT a schedule.
The examples of a House are much to simple for practical use in IT, heavy construction, weapons systems, aircraft or any "system" based project. Move to "system of systems" and the WBS developed in this manner rapidly falls apart and actually creates confusion.
In our work-a-day world, we spend much of our time "undoing" WBS's built in the manner suggested in the paper and the PMI suggestions. Don't have a project where we come to do "triage." Build a credible WBS. Read 881-A to see how. Don't convert the WBS into a schedule, define the Work Packages at the end of the WBS tree and then sequence those Work Packages.
Here are the steps needed to Build a Credible Performance Measuement Baseline. Apply them to you project and use the WBS as intended - as one of many representations of the project.
