Work Breakdown Structure
Jul 20, 2012 4:32 PM,
By Bradley A. Malone, PMP
In the 1950s, the U.S. Department of Defense came up with a common-sense project management concept that AV companies should use today. Back then, according to the Journal of Defense Software Engineering, the Navy began using something called the “Program Evaluation and Review Technique (PERT)” in support of the Polaris missile program. Though it was codified in later years and is currently used primarily as an estimating technique, PERT is considered the starting point for the work breakdown structure philosophy.
The work breakdown structure (WBS) is a deliverable-oriented grouping of project components that helps organize and define a project’s total scope of work. Effectively, the WBS describes a project’s product or service through a what-goes-into-what process. It also relates each of the deliverable work components to one another and to the total product or service as a whole.
This interrelationship between components facilitates the definition of the project’s scope and begins to reveal potential complexities. As when AV companies detail a project’s assumptions and risks, the WBS helps create common sense among stakeholders (client, sales, project managers, technicians, vendors, general contractors, etc.). And once developed, a WBS can be used as a template for similar projects, with the benefit of developing a common language and thought structure.
The Roots of the Project
In the beginning, a WBS does not address the project’s who, when, how, or how many. These are addressed later, as the project moves through the planning processes. The WBS is a noun-based thought process, not a verb or activity-based schedule—although it will ultimately help the AV team formulate a schedule of activities and the associated effort required to fulfill each deliverable.
As a project-management document, a well-composed WBS is essential because it serves as a foundation for initiating and planning the project. It’s best to think of the WBS as the roots of a tree, where the tree is your project. For a tree to bear fruit, its roots must be deep, wide, and exhaustive. And just as roots become finer as they descend into soil, the WBS should define the project’s deliverables and list supporting documentation in greater detail as it goes on to address the subcomponents of every deliverable.
Three to five levels of what is known as “decomposition” are usually sufficient to describe most AV projects through a work breakdown structure. The roots of the WBS may include product components, functions (for software deliverables), or process steps (for business process-engineering projects).
The WBS serves many critical purposes, the most important of which is defining the work to be performed and breaking it into manageable components. Developing a work breakdown structure generates a number of other planning benefits, such as a greater ability to determine the types of resources needed; a better comprehension of their roles; and a more accurate understanding of the skill levels required to manage the pieces of the project.
Creating a detailed WBS also improves an account manager’s and/or project manager’s ability to define, quantify, measure, and estimate the costs and effort required to deliver each component of the project. Doing so also enables you to better identify, document, and control changes.
A well-crafted WBS also helps a project manager define the performance-measurement baseline from which he or she can judge a project’s status. When the status of the project is asked at its summary level (“How’s project XYZ going?”), we often hear answers such as “Fine”, “Great”, and “Moving along.” However, when the project’s status is judged at the third or fourth level of the WBS—instead of at the summary level — the judgment will likely be far more accurate because the questions are more binary in nature. When asked at a finer level of the WBS root system, the question may be, “Is the podium installed?” While someone could answer, “Almost,” the real answer is either “Yes” or “No.”
Details of the Work Breakdown Structure
The purpose, as described at the top of the WBS, is the “why” of your project. Sales should enter it in operational terms, as viewed from the customer’s perspective. In the case of a product-oriented classroom installation, for instance, you might describe the purpose as: “A flexible, multipurpose, multimedia classroom that enables participants to engage interactively in an adult-learning environment. Equipment and furniture need to be durable and easy to maintain and reposition.”
From there, sales and the client would define in greater detail each of the measurable parameters (flexible, durable, etc.). Without a purpose statement, the big picture will be unclear and the project implementation (and service) team might lose sight of the customer’s ultimate requirements.
As employees of an AV company, you’ll learn that there is no perfect WBS. That said, you should strive to create one that is both exhaustive and exclusive. Exhaustive in that it contains all the components and details necessary to satisfy the customer’s operational objectives; exclusive in that an item is entered into the WBS exactly and only where it fits, and is not forcibly duplicated elsewhere. In our example of a product-oriented WBS, the cabling would not be entered under each of the pieces of equipment, because cabling will be part of the facilities and will serve the entire room configuration.
It’s important to build a WBS in a team setting because different project participants might use different words to define the same components, or the same words to define different components. For example, are cabling, conduit, electrical, wire, etc., synonymous, or do they describe different objects that perform different functions? To eliminate potential confusion, the AV team must facilitate communication and agreement instead of having several versions of the same work breakdown structure done by different departments or individuals, each with their own vocabulary.
A well-crafted WBS also helps identify how a change in one aspect ripples across the product and project. In the absence of a WBS, change notification is typically limited to those who deal with the particular piece or part of the project that’s being changed. A WBS visually demonstrates the product and project-wide ramifications of making a change in one component and therefore gives the project’s stakeholders a more global understanding of the interrelationships among all components.
Bradley A. Malone, PMP, is an InfoComm University senior instructor and president of Twin Star Consulting, an organizational excellence and program management consulting company serving multiple industries. He holds the Project Management Professional (PMP) designation from the Project Management Institute (PMI) and is one of PMI’s highest-rated instructors. To read our full report on Work Breakdown Structures, visit infocomm.org.
