A Maintenance Officer in 1970, just north of Da-nang was asked me "when is this aircraft going to fly?" Some weak answer came back about who hard everyone was working to get the aircraft fixed and back on flight status. The crisp and no-nonsense response was "I don't care about your efforts, I want results."
Never confuse effort with results
This confusion occurs all the time in project work. It starts with the development of the Work Breakdown Structure (WBS) that is functionally oriented.
This functional WBS describes all the efforts needed for the project but does not reveal what is actually being produced. What are the deliverables from this effort? Can't tell. Someone knows obviously, but in the absence of that "someone", we can't tell what is actually happening in the project. As well the schedule for the project probably uses the same wording at the top levels. This "do all work" approach is very common.
The WBS construction guides in MIL-HDBK-881 and EIA-632 (Processes for Engineering a System) strongly suggest that a Product oriented WBS be built. The PMBOK provides guidance that allows the creation of an arbitrary structure and content for the WBS. This is the likely source of the poorly defined WBS's, where effort is confused with the results. Use the MIL-HDBK 881 instead of PMBOK, it's simply more concise in its advice.
Product Oriented WBS
When a product oriented WBS is used, the deliverables of the project are made explicit. The work to produce these deliverables is explicitly attached to each deliverable. At the lowest level of the WBS - the Work Package - the work assigned to the deliverables has a one-to-one relationship with the deliverable. In the functional decomposition, there is no such relationship. It is not explicit what the work produces and the relationships can be one-to-many or even many-to-many.
These one-to-many and many-to-many relationship are bad news for building accountability and tracing physical percent complete of the project.
Getting Effort confused with Results starts with a poorly formed WBS.
Getting the WBS Right
This sounds like the most boring job on the planet - build the WBS. Yuck. But it turns out the effort invested in constructing the top three levels of a Product Oriented WBS pays offs in the end. It enables several things to happen that simply can't be done in the functional WBS.
- What does done look like in terms of products - delivered products or services?
- How much effort is assigned to each of these deliverables?
- What is the relationship between one deliverable and others?
One good approach to building a WBS is to describe what is NOT in the WBS. This is advice directly from MIL-HDBK-881
- Do not include elements which are not products
- Program phases are inappropriate
- Rework, retesting and refurbishing are not separate elements in a work breakdown structure
- Non-recurring and recurring classifications are not work breakdown structure elements
- Cost saving efforts such as total quality management initiatives could cost, and warranty are not part of the work breakdown structure
- Do not use the structure of the program office or the contractor's organization as the basis of a work breakdown structure
- Do not treat costs for meetings, travel, computer support, etc. as separate work breakdown structure elements
- Use actual system names and nomenclature. Generic terms are inappropriate in a work breakdown structure
- Treat tooling, tools, and their environments as a functional cost, not a work breakdown structure element
- Include software costs in the cost of the equipment. Even if the project builds the software. Focus on products, not the means to the product
These are strong suggestions in many environments, but this is how project WBS's are developed in many enterprise and mission critical project domains.
The Final Motivation for a Good WBS
If you don't have a good WBS you can't answer the question - What does done look like? If you can't answer that question is some form of a measurable outcome, you can't manage the project. Pure and simple. You're not a project manager. You might be something else, but not a project manager.