At this point in our project development we have determined the deliverables that are due to all the stakeholders. But we cannot plan the project from this list of deliverables. To plan the project we must convert these into individual pieces of work that must be done to complete the project. For this we need the ''work breakdown structure,'' or WBS.
The work breakdown structure is the most central item in the project plan. Without it we do not have a definition of the work that has to be done to complete the project. Without knowing the work that has to be done we cannot possibly determine the cost of the project or determine the schedule of the project.
Without knowing the cost or schedule of the project how will it be possible to control the project or determine how much should be spent to complete it? The amount of resources that must be used on the project and when they must be made available cannot be determined without knowing the schedule. Funding to do the project cannot be scheduled to be in place when the project needs it without a time-phased budget for the project. Without knowing the work to be performed on the project, risk management cannot be done in a satisfactory way. These things cannot be done without the work breakdown structure.
According to the Guide to the PMBOK, the definition of a work breakdown structure is:
A deliverable oriented grouping of project components that organizes and defines the total scope of the project. Each descending level represents an increasing detailed definition of the project work. The WBS is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables.
Work outside the WBS is outside the scope of the project. In this definition of the WBS, we are striving for a method to identify the work that is required to produce all of the deliverables of the project. As we will see, with many projects it will be possible to identify close to 95 percent of the work that must be done in the project.
To create a WBS is a simple task: The project is first broken down into a group of subprojects. Each of these subprojects can be broken down to sub-subprojects. The sub-subprojects can be broken down again and again until the desired level of detail is reached. The level of detail is termed the work package level. The work package is the lowest level of management that the project manager needs to manage. Below the work package other project team members may break down their parts of the project into additional levels.
The reason this technique is so effective is that it follows the principle of ''divide and conquer.'' If we were to hold a meeting and write down a list of all the things that had to be done to complete the project, the meeting would not produce a very good list. In a meeting of this type where there is little focus, attention will drift into one area and do a pretty good job of listing the work needed in that area and ignore other areas of the project.
A better way to do this is to break the project into smaller projects or products of the project. When we do this we can think of each one of these subprojects as producing one or more of the deliverables of the whole project. In this way we can also think of the WBS as a product-oriented breakdown as well. This allows project management to become a methodology that will work well on the largest of projects or programs as well as the smallest. At the top levels of the project, particularly large projects, think of these early levels of breakdown as product breakdowns. This is because on larger projects there can be a grouping of deliverables into large deliverables that might be called products.
So, initially the project is broken up into a group of subprojects. These subprojects are further broken down into sub-subprojects, and so on. In this way the largest project we can imagine could be broken down into subprojects. Since each of these subprojects could be considered to be a project in its own right, any large project can be thought of as a family of smaller projects that are interrelated.
A project can also be thought of as a microcosm or a macrocosm. At any level in the breakdown structure, from the standpoint of the manager in charge of a particular part of the project, there is a separate project for which he or she is responsible. All projects are part of some larger project, and all projects have subprojects within them. It is just a matter of perspective.
For example, in the 1960s the United States took on the challenge of getting a man to the moon and safely back to Earth. The resulting project was very large, employing many thousands of people. The project manager lived in Washington, D.C., and spent most of his time dealing with Congress and other parts of the government.
When the Apollo Program was in full swing in the 1960s, it was a very large project indeed. There were perhaps 40,000 people working on it at any given time. There was a project to develop the engines for the Saturn V booster, the first stage of the launch vehicle. This project had a project manager and many people involved. The engine development project had several locations and several hundred people working on it. Within this project there were other projects, such as engine testing, fuel systems, fuel delivery, cooling, and so on.
Although the engine development project for the Apollo program was a large effort, it was only a small part of the program. Depending on where you were in the hierarchy of the program, you might consider yourself as a program manager, a project manager, or even a subproject manager.
As a matter of practicality, it does not make sense for the top-level program manager or project manager to manage all of the details of the project. In fact it is not necessary for him or her to even know about them. So, we can see that extremely large projects result in smaller projects or subprojects. The subprojects are themselves projects in their own right and have their own work breakdown structures. Each project may be part of some bigger project or macrocosm, and each project may have smaller projects, or microcosms, within it.
The important thing about project management is that it is a powerful methodology that adapts to any size project or program. The tools and methodology that are used are similar in all projects. The WBS is the tool that allows all projects to be broken down into smaller, more manageable projects.
The end result of the WBS is a group of individual pieces of work defined. Each of these small individual pieces of work must be assigned to one person on the project team. The primary purpose of the WBS is to divide the project into subprojects until a point is reached where this assignment of the individual pieces of work can be made.
For a large project the WBS might stop at a rather high level. This may be the level of control for the project manager. As mentioned above, this level of the WBS is generally called the work package. It must be understood that at this high level other project managers will take the lowest level of the initial breakdown and further break it down until the individual piece of work is reached.
The bottom level of any project, then, must be the place where an individual piece of work that can be done by one person or a group is described. This person or group of persons is actually going to accomplish the work rather than manage the work. This level is considered to be the task or activity level.
There is a change in terminology in this area, and the Guide to the PMBOK is not entirely clear as to the terms used. The WBS breaks down the project into manageable pieces but stops at the work package level. The work package is the lowest level that the project manager would have under his or her direct control. It is then possible to break the work packages down further before the actual work assignments at the detail level are made. Work packages can be broken down into ''activities,'' and activities can be further broken down into ''tasks.''
The Guide to the PMBOK refers to the lowest level of the WBS as the work package level. Work package managers will further divide the work of the project into what they consider to be subprojects and work packages. Common usage has the task or activity at the lowest level of the ultimate WBS.
I recommend that the WBS be developed just for one purpose—to discover all of the work that must be done to complete the project. If an attempt is made to use the WBS to simultaneously produce an organization chart, a chart of accounts for the project, or any of the other organizational requirements of the project, it is likely that the attempt to discover all of the work to be done will fail. These items, the ''organizational breakdown structure'' (OBS) and the ''chart of accounts'' should be separate items from the WBS that are related through the lower level elements of the WBS.
At this point we have broken the project down into subprojects and continued this breakdown to the work package level. In smaller projects, the work package level may be the task or activity level where the work actually takes place. In larger projects it may be that the work package has a work package manager who continues to divide the work into lower levels until the task or activity level is reached.
It is extremely important that each of the lowest levels have only one person responsible for the work that is to be done to satisfy that work component, regardless of whether it is called work package, task, or activity.
What's next? We have identified all the work in the project. Our ability to do this, however, defines only about 90 percent of the work that is necessary. We would like to be able to more accurately identify more of the work that is required.
According to the systems management concept, all work is considered to be a system where the work is a process that converts inputs to outputs. Taking this concept to the project level, we can describe a project as a process that converts inputs, resources, money, and people's effort into outputs, the deliverables of the project.
If we apply this concept to our work breakdown structure, we could say that each task at the bottom level of our WBS is a process that converts inputs to outputs. The inputs are something that the task owner needs from some other part of the project or from somewhere external to the project. The outputs are items that are needed in some other part of the project or are items that represent all or part of a deliverable.
We can apply these ideas to our definition of project work. Each person responsible for a task looks to other tasks to find the items needed for a specific task. Each will also look for other parts of the project to deliver the outputs. In this way each person on the project team must look at each input and output at least two times. All inputs to a task must come from somewhere inside the project or from some external source. All outputs from a task must go to another task in the project or directly contribute to the delivery of a deliverable.
Input items that cannot be found externally or from outputs of other project tasks must be added to other project tasks. Output items that cannot be delivered to other parts of the project or to a deliverable can be considered extra work. In this way almost all of the additional work not already in the plan can be discovered. In addition, all of the work that has been developed in the project that can be considered ''creeping elegance'' can be dropped from the project plan.
Last of all, there is a good chance that duplicated work can be eliminated as well. When a task owner who is seeking input for the task work finds more than one task supplying the same or nearly the same input, one or the other may be eliminated.
The work breakdown structure dictionary is used to expand on the information for each of the elements in the WBS. For each element it should contain an elemental statement of work, schedule and duration, budget, all of the associated elements and activities related to it, the organization responsible, and the risks associated with it.
It is important to recognize that there are many other types of breakdowns used in projects. The WBS that we have been discussing must be used only to generate the individual pieces of work that must be done in the project. To try to use the WBS to develop anything else would confuse the effort and make the identification of work less effective.
Other breakdown structures that are used that should not be confused with the WBS are:
• Contractual WBS (CWBS). This breakdown is used to define the reporting information and the timeliness of information that a supplier will supply to the buyer. It is usually not as detailed as the WBS that is used to plan the work that is going to be done.
• Organizational Breakdown Structure (OBS). The main purpose of this structure is to show the organization of resources and of the people who will work on the project. In the OBS, the work components of the WBS are shown related to the groups of individuals and resources that will accomplish the work.
• Resource Breakdown Structure (RBS). This is a refinement of the OBS in that the detail of the RBS generally goes to the individual level.
• Bill of Material (BOM). The various product components are included in the BOM in a hierarchical way. Products produced, subassemblies, and lower level of assembly are shown as a ''goes into'' hierarchy.
• Risk Breakdown Structure (RBS). This is a hierarchical listing of the project risks according to the risk categories that were developed for this project.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.