Project Vision: The Ability to “See”
The fifth Project Management Principle is “Where there is no vision, projects struggle.” As good project managers, we need for stakeholders to “see” the project. One of the most effective tools for seeing is the Work Breakdown Structure (WBS).
The PMBOK® Guide defines the WBS as:
“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.”
An often overlooked aspect of the WBS is that it is ALL the work required to accomplish the scope of the project. That means that a good WBS supports Scope Management, Change Management, Risk Management, Requirements Management, Cost Management, Human Resource Management, Integration, and Acquisitions. It is the basis for doing good project management and if not conducted correctly or given the proper weight it deserves, detracts heavily from project success.
In my experience, the WBS has sometimes been relegated to a secondary process. For instance, you can use a scheduling tool to create the task list, logic, and schedule and a WBS can result from the scheduling exercise. WBS decomposition is automatically created as the schedule is created. Why build the WBS first when I can save time by combining it with building the schedule? There are several reasons to take building the WBS seriously.
1. The ability to “see” the work.
I suggest that the activity of building the WBS should be conducted by at least the project team and hopefully include as many key stakeholders as possible and with the technologically advanced sticky note. Sticky notes on the wall allow for instantaneous change and are alterable at will as discussions progress. They also require all to participate and not just everyone looking at the diagram I produced. When the picture is finally created, we can all stand back and “see” the work required to accomplish the scope of the project.
2. The interaction of the participants.
One of the great aspects of WBS building with sticky notes is that the team and stakeholders begin to coalesce around the project solution. They have to “rub shoulders” as part of the process and begin to know each other. Don’t overlook the support to communications and team building. Let me offer two suggestions to facilitate the process. First, it may be advantageous for the Project Manager (PM) to hire a facilitator to conduct the WBS building effort. This allows the PM to be a participant in the process and enjoy the camaraderie and team building. Second, you may wish to use the process called Affinity Diagramming, described in Michael Brassard’s book, Memory Jogger II. It will allow you to more quickly organize the thoughts of the participants into the WBS result.
3. Participant buy-in.
Once the WBS is built, all participant can stand back and “see” either their part or their organizations part in the solution. It describes individual effort, organizational effort, cooperation, and acquisitions needed to accomplish the scope of the project. Individual team members and key stakeholders begin to get the vision.
For Federal programs and projects there is additional guidance in MIL-STD 881C. It is a requirement for the DoD project manager, but it is also excellent guidance for any federal or private PM if adapted correctly. Following is an excerpt from the definitions section of MIL-STD 881C:
1.5.3 Work Breakdown Structure (WBS). This term is defined as:a. 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 material item.
b. A WBS displays and defines the product, or products, to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end product. In other words, the WBS is an organized method to breakdown a product into sub-products at lower levels of detail.
c. A WBS can be expressed to any level of detail. While the top three levels are the minimum required for reporting purposes on any program or contract, effective management of complex programs requires WBS definition at considerably lower levels. This is particularly true of items identified as high-cost, high-risk, or high technical interest. Under these circumstances, it is critical to define the product at a lower level of WBS detail. In this case, managers should distinguish between WBS definition and WBS reporting. The WBS should be defined at the level necessary to identify work progress and enable effective management, regardless of the WBS level reported to program oversight.
The standard is available to the public so I suggest you download it to your desktop and read it carefully. It just may assist you in creating a better WBS in either the Federal or Private sector.
The WBS assists the project manager in building the vision of the project. We all want to “see” not only the project result, but what it will take the get there. Don’t overlook the power of purposefully developing a WBS early in the project process.
