This article is reprinted with permission from InfoComm International and originally appeared here.

This is the eighth in an ongoing series of organizational project management articles by InfoComm University senior instructor Brad Malone. To read the seventh installment, “Creating Common Sense, Communicating Assumptions and Risks,” click here.

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 (see the previous article in our project management series), 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’s, when’s, how’s, or how many’s. 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 addresses 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). Refer to the graphic below as we discuss the essential elements of an effective WBS.

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. It is always easier and more accurate to perform these tasks at a lower level of decomposition. 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 the 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.

Although changes are often made at the component level, based on their technological efficacy, they should be assessed and approved at the project level and in consideration of the project’s purpose. Consider, for example, the classroom project. Just because a new type of cabling is less expensive and could possibly provide better performance, it does not necessarily mean that the new cabling is appropriate for the project, nor does it mean that it will save the project money or enhance the client’s ability to achieve their purpose requirements. In fact, changing the cabling may actually require changes to multiple components or control panels.

Managing the WBS

Once a work breakdown structure has been developed, a numbering system can be created to identify and position each level and/or component. This numbering system can be used in conjunction with both the organization’s project management tool — Microsoft Project, for example — and its cost accounting system. Tracking the costs and effort required at a lower level allows an AV company to validate its estimation process and manage risk – similar deliverables will have estimates with narrower ranges, more unique deliverables will have estimates with wider ranges. Using WBS templates and tracking appropriately can help close the loop among sales, estimation and implementation teams, allowing for the regular refinement of estimates and their assumptions.

During the implementation phase of a project, the project manager typically manages down to the third or fourth level of a project’s WBS. These are usually the levels at which components are more standard across projects. (Most organizations deliver projects composed of standard components structured into somewhat unique configurations.) The project manager shouldn’t manage components below a level at which they’re standard. In our sample WBS, “projectors” represent a component at or below a standard level. If, by some chance, the projector for a given project is being configured in a unique fashion, or must interface with other equipment in a unique configuration, then the project manager should manage down to a lower level.

At the end of the day, a deliverable-oriented work breakdown structure is a powerful planning, estimating, learning, communicating, status-reporting and change-controlling tool. Every project should have one. And the good thing is, once a company has built one, it has a template for future similar projects, which ultimately saves time and helps avoid potential mistakes and oversights.

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. Please share your thoughts with him at brad@twinstarconsulting.com