Breaking the communication barrier with a WBS


Project Management in Action


Clayton W. Harrell

“I can't understand the project managers; they just don't talk my kind of language. Too much detail—too complicated.”

“I know George, it's been a long time since I had a chance to catch upon everything that's going on in the very technology that founded this company. It often gets confusing for me, and I'm the vice president for research and engineering.”

Often those responsible for complicated or state-of-the-art projects have a difficult time expressing themselves to “outsiders” who are not conversant with their project or the technology being used. According to PMNETwork's Olde Curmudgeon [1], “One of the critical skills that differentiate a (good) project manager from a technologist is the ability to communicate, both orally and in writing.” The conversation above is an example of poor communication between the project managers and their management. Again, to quote the Olde Curmudgeon, “the less you understand of the other person's vocabulary, the more likely you are to be ‘snowed’ and the less likely you are to gain the respect of that person.”


Clayton W. Harrell is president and founder of Rensselaer Learning Systems, Inc., a New York consulting corporation, with offices in Rochester New York. He is a consultant, lecturer, researcher, and educator who has written for several technical publications.

Dr. Harrell has over 25 years of project management, corporate and engineering management experience with several Fortune 500 companies prior to founding Rensselaer Learning Systems. He has managed international projects for the Xerox Corporation involving countries in Eorope, Asia, South America and Australia. Project sizes have ranged from small projects with only a few people to very large ones lasting several years. He was the chief planning engineer for the Grumman Corporation with a major responsibility for the planning of the Lunar Module of Project Apollo.

Dr. Harrell received his B.S. from Bryant College, M.B.A. from Hofstra University, and Ph.D. from the University of Rochester. He has been on the adjunct faculty of the Rochester


There is a basic project management tool that can be employed to help with communications with those outside the project team; the Work Breakdown Structure, or WBS. According to the new PMBOK document [2], “the WBS is an organized, hierarchical presentation of the products and services to be provided in a project. The WBS should include the full scope of the project.”

The purpose of a Work Breakdown Structure (WBS), as stated in PMBOK leaves the impression that it is a technique used only to describe the work elements of a project to ensure completeness. It has another purpose—to describe a complicated, technical, state-of-the-art project to users, management, investors, and team members who are from a different technological background. As an example, a blast furnace design project manager for ATSI (Buffalo, NY), showed an updated WBS for a new furnace to a foreign customer. The WBS had completed elements of work crossed out (with a date). They liked it so much, they requested that all monthly progress reports be submitted with an updated WBS. They found it aided in understanding the narrative reports they had been receiving. Later, AT SI added an estimate (percent) of completion on each low-level work block. The estimate was then rolled up by the computer through the tree to level zero; thereby providing a display of percent complete at any level of the WBS (see Figure 1).

To accomplish the roll-up, each work block had to have a budget, as well as the percent complete for the end of the reporting period. The client again exhibited their delight with the revised WBS status report and added a line item to their contract reimbursing ATSI for their inventiveness.

The usefulness of the WBS as a communications vehicle stems from its design, which, in varying levels of detail, starts with the product of the project at the top and goes down to define all work elements. Some people with whom the project manager communicates do not have to understand a project all the way down through the WBS to the detail work package level. Their only interest may be to understand the second or third level, as an overview of the project. Others may find it useful to inspect only specific domains of a project. For instance, fictional managers may only be interested in their part of the project and how it fits into the overall scheme of things.

The WBS allows people to ask questions intelligently, using it as a communication map, without appearing naive. If someone wants to know more about a high-level description, they only have to go to the next level of detail, or ask a question.

Early in my career at Grumman Engineering, as project administrator for the Orbiting Astronomical Observatory (OAO), a 3,600-pound space telescope, I showed the WBS to my boss one day. He was delighted with the display and how I had divided the project into branches of technology. Actually, the WBS had not been designed to do anything other than to define the scope of the project. I never thought of it as a display that would help everyone understand the project better. Soon my boss had my WBS hanging on his office wall. It a useful tool when he explained the project to other managers.

The usefulness of this WBS was clear when I discovered a copy of the WBS for the OAO taped on the wall of a church basement room that was last used for a meeting of the men's club. Someone else had stolen my thunder, and had recognized it was a useful communication tool. I found that management, familiar with aircraft design, was not sure what we “space folks” were doing. Again, the WBS helped to explain the components of work that had to be accomplished. Later, as chief planning engineer for Project Apollo's Lunar Module, and later for all the company's Research and Space projects, I used the WBS as a useful communication vehicle with our clients (NASA), visiting “firemen” politicians, and others not steeped in the technologies or an understanding of our projects. The WBS served many useful communication purposes in addition to defining the scope of the project.

Figure 1. Percent Complete of WBS

Percent Complete of WBS


The WBS starts at the top (level zero) with the name of the projector the current phase being defined. The next level, and all horizontal levels that follow, shows the decomposition of the block above it—its parent. The designer must ask the question about each parent's children, “Have I defined everything at this level that defines the parent?” In other words, as each level is decomposed, it represents the entire project at a new level of detail. This does not imply that some information will not be known at the time the WBS is originally designed. It does mean that some parts of the WBS will be defined in more detail (more levels) than others. It is common to find WBS displays for development projects showing the immediate work in low levels of detail; but for later work the details will not be shown. In other words, a team that has not yet designed the product, can hardly be specific about how it will be tested or integrated.

Just as there are informal guidelines concerning managerial span of control (no more than seven subordinate managers), another guideline says that there should be no more than seven subordinate work elements (children) for any parent. This guideline is used because of the mind's limited ability to visualize more than seven subordinate items, defining the decomposition of a work element. Violating it makes it difficult for the designer to visualize what has to be performed to fulfill the requirements of a work package.

Task lists of hundreds of activities are difficult to analyze. How do you examine a list of 150 things that have to be done and be able to evaluate what is missing or what is redundant? You can't, yet many project managers try, often using CPM, for example, to define a project module without first creating an organized WBS.

Another design problem that is often found on WBS graphics is the “hanging single.” A defined block of work (parent) at one level, cannot be defined as only a single element of work at the next (child) lower level. This is not decomposition; it is redefinition— and therefore not appropriate for a WBS. As a rule, every block of work must be defined at the next lower level with two or more blocks of decomposed work elements.

Still another problem for the designers of the WBS comes when there is an attempt to decompose every block of work down to the same level of detail as all the others. It is satisfactory to have work defined at different levels throughout the WBS. Keep in mind, that the end result of the lowest WBS level is a display of all the work packages that can be visualized by the team members at the current date. Also, as a guideline, a work package should take no longer than a few weeks to complete.

Project managers have been known to show some work elements by dotted lines on a WBS to indicate possible additional work. This is not a good practice. The WBS blocks are either in or they are out of the project baseline. If the project manager is using the WBS to model a change by identifying the effect of a proposed change, it is appropriate—all other uses of the dashed line are inappropriate. The cost, and responsibility to deliver the identified work is either in the baseline of the project, or it is not.


By using these simple rules, and having the WBS audited by the team and the functional supporting managers, the WBS becomes a complete display of what is anticipated for the project. The project manager should be in a position to defend the WBS display to stakeholders, as well as to use it as a presentation vehicle in explaining the project to anyone else. Again, the advantage of the WBS as a presentation tool is that each level presents more detail. If the audience only wants a cursory view of the project, the project manager needs only to explain the top two or three levels. If someone is interested in lower level detail, the framework is there to follow.

The WBS is designed to aid in the identification of work on a new project. It aids the design team by organizing work assignments in a visual form for the purpose of analyzing the plan for its completeness. It also helps management identify duplication of planned work assignments. Because it identifies the work to be done, it is used as a basis for understanding change (either generated from the team or from the customers). Naturally, the WBS can be used as a budgeting view, showing the planned effort for the project as well as the basis for work assignments (organization view), and for the project master plan.

Perhaps the greatest value of the WBS is as a useful communication tool. Project engineers and managers should use it as such, as well as for its originally intended purposes. The WBS is not a tool that is used just once in the life of the project. It should be revised every time a change is approved. Keeping it updated will help explain the work content of a project so that any change will have a technical baseline that is graphic. It helps everyone to understand complex projects. Remember: “A picture is worth ten thousand words.”


1. PMNETwork, March 1994.

2. Project Management Body of Knowledge. (Exposure Draft of the updated version scheduled for September publication.) img

PMNETwork • August 1994