Abstract
“What is the primary purpose of the Work Breakdown Structure (WBS) on a project?” This is a question I ask project teams when they engage my services to help them produce a WBS for their project. The typical answers I receive are:
- It's a schedule I‘m required to create at the beginning of my project –which I likely won't be able to meet without adjusting it multiple times
- To show the time estimates for all of the activities the project team will perform
- It is the deliverable we use to track progress on project team member's work assignments
- It has to be created so that I have estimates for time and costs for the project
The first thing I point out, after receiving these responses, is that the project stakeholders have misunderstood the purpose and content of the WBS. The WBS is not a scheduling or a budgeting deliverable; it does not contain project activities, cost estimates, resource assignments or activity dependency information. A Work Breakdown Structure is a higher level project artifact that supports the creation of schedules and budgets. The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables (PMI, 2013, p. 126). In other words, the WBS represents all of the deliverables to be produced by the project for which work activities will be defined, planned, and executed. The WBS provides a clear answer to the question: “What are we going to produce as a result of the project?” Answer: the WBS deliverables.
The WBS establishes the foundation that the project stakeholders use as the basis to creating their project schedule with project activities; network diagrams to sequence work; budgets for estimating and managing costs; and for making all decisions to objectively manage scope creep. The reason it is the foundation document is because it encompasses every deliverable for the final product, service, or process that is being produced and it also includes all intermediary project methodology outcomes required to manage the project effort. When the project team creates their project schedule and/or budget without first creating a WBS, they increase the risk of producing unsubstantiated and inaccurate schedules and budgets because they lack information about the product solution deliverables that will meet the objectives of the project.
This paper focuses on the underlying techniques that project stakeholders can use to create their project WBS and achieve an aligned understanding of every output the project will create. It will clarify the differences between the project WBS and the project schedule and illustrate the relationship between these two deliverables. The paper describes the characteristics common to every WBS and provides examples of three different types of WBS deliverables, and describes how a project team makes the transition from building a deliverables-based WBS to creating an activities-based Project Schedule.
Characteristics of the WBS
The hierarchical Work Breakdown Structure (WBS) represents all of the deliverables that make up the project solution. It doesn't matter if the project solution will produce a physical product, a service, or a process — all project outcomes can be defined from a deliverables perspective in the WBS. The WBS can also include project methodology deliverables required to manage and complete the project execution, but many times project stakeholders choose to depict these deliverables in a separate project methodology WBS that compliments the project outcome WBS. Because the WBS is a hierarchical document, it is built in layers of granularity with each successive layer in the WBS (child layers) clarifying the deliverables above them (parent level). Once the project WBS is base-lined, it establishes the agreement on the scope of what will be built and serves as the focal point and justification to defining the schedulable activities, which are part of the Define Activities process 6.2 outlined in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition (PMI , 2013, p 151) .
When the WBS is created from a hierarchical viewpoint (as illustrated in Exhibit 1) the stakeholders will be able to start visualizing the top level of the WBS, which includes the major deliverable components to be produced by the project. They will continue to decompose the WBS by drilling down through each higher level (parent) deliverable as they add the more detailed components that make up the parent deliverable. During the WBS decomposition activity, the project stakeholders look for completeness in the WBS. A way to determine if the WBS is complete is to ask the stakeholders if there is any project solution concept that could not be associated with one of the deliverables currently shown in the WBS. If the answer is yes and something is missing and can't be categorized under an existing deliverable, then this element most likely represents a new parent level deliverable. Likewise, if something is currently included in the WBS, but is not part of the intended project solution (i.e., the training wheels component, shown in Exhibit 1, is not a likely component of the mountain bike) then the deliverable component must be removed from the WBS because it is out of scope for the project. Looking at the project solution from this hierarchical view is a powerful way to achieve stakeholder alignment on everything that must be provided for by the project solution – long before any effort is spent designing and building a solution for the project.
Exhibit 1 – WBS for A Mountain Bike
Upon closer examination of the WBS, it becomes easier to understand how the WBS establishes a framework for organizing what is oftentimes a complex or overwhelming amount of project work into logical relationships of related outputs. The caveat when constructing the WBS is that there is no single “right way” to organize and depict the deliverables on the WBS, outside of following this simple guideline: the final WBS picture must make sense to and be agreed to by all of the project stakeholders and the WBS represents everything that must be built as part of the project solution.
While the WBS is the foundation for defining the project activities needed to build the deliverables, the WBS is not the Project Schedule (as illustrated in Exhibit 2). The WBS does not contain activities, tasks or milestones to be achieved and it doesn't contain any timing dependencies for performing activities. All of this important information is part of the Project Schedule and the Project Schedule is based on the WBS. In order to complete the planning of the project and manage the execution of the project, every deliverable on the WBS will ultimately be decomposed into a list of activities to be performed to produce each deliverable. Activities are the “How's” for producing project deliverables. Activities will be related to each other in network diagrams and have durations and resource assignments allocated to them in the Project Schedule and costs to complete them in the Project Budget. The WBS, on the other hand, is agnostic to timing, effort, and costs. It only represents what needs to be produced as a result of the project and it. The WBS is the blueprint and key project artifact to justify the schedule and budget.
Exhibit 2 – WBS Is Not the Project Schedule
A final version of the WBS is not required in order to produce an initial schedule or budget for the project. A high level WBS similar to the Mountain Bike WBS in Exhibit 1 can be produced early in scope elaboration, providing a high level understanding of the deliverables, which is often enough information to substantiate a ROM schedule and budget. When creating the WBS the focus must stay on deliverables. So how can the stakeholders keep the WBS focused only on the project deliverables and not activities? The simplest way to ensure the WBS is deliverables based rather than activities based is to make sure every element included in the WBS is represented as a noun phrase rather than a verb phrase. When creating the WBS, follow this simple rule:
WBS = Nouns
Schedule Activities = Verbs
When the WBS decomposition activity begins to evolve from stating more granular nouns to describing a parent deliverable to stating verb phrases which communicate how the deliverable will be produced, the WBS is at its lowest level of decomposition.
WBS – The Common Thread on All Types of Projects
The common thread across every type of project is that every project produces deliverables. Therefore, the WBS is applicable to and required for every project we work on because every project results in implementing changes to provide new or different outcomes for customers (internal or external customer). By tangible, I am referring to something the customer can see, touch, or feel as well as experience; therefore, project outcomes can be delivered as a product, service, or a process.
A project that produces a product for a customer will have a WBS documenting all of the components for the product. Examples of a project to produce a product might include creating: a bicycle, a software application, a building structure, an automobile, a training class, etc. A project to deliver a service will have a WBS documenting all of the components associated with the service offering a customer can experience. Service types of projects might produce outcomes such as: a wedding planning service, a cleaning service, an audit service, a repair service, and so forth. A project to define a process will have a WBS documenting all of the components of the process, which could be used many times to perform ongoing operations or execute specific types of projects such as a software development methodology or an office relocation process.
Knowing that there is no single correct way to organize or depict the deliverable hierarchy legs on the WBS, there are a lot of ineffective ways to represent the deliverables. These guidelines should be followed to produce an effective WBS for the project:
- Use nouns, not verbs, to keep the focus on deliverables versus activities to create the deliverables
- Use a hierarchy structure to illustrate the relationship of deliverable for the scope of the project
- Build the WBS collaboratively with the people who will ultimately produce the project deliverables
- Ensure each WBS leg contains deliverables that are unique from deliverables in another leg – we don't want to repeat the same deliverable in each column
- Never make assumptions that stakeholders will naturally know that a deliverable element is part of the project even if it is not included in the WBS.
- Follow the 100% rule when drilling down through the levels of the WBS. The 100% rule states that every level of decomposition in the WBS must contain all of the deliverable elements, which represent 100% of its parent deliverable.
Application of these guidelines for creating a WBS and understanding how the WBS is the common scope defining thread on all types of can best be represented by looking at the WBS for three types of projects: a project to create a product, a project to create a service, and a project to define a repeatable process.
Product WBS: Training Course
For a project initiated to create a new training course, for any topic, the resulting WBS would likely contain legs for at least these common categories of deliverables, which will be produced for the course:
- Training Materials
- Resources
- Advertising
- Logistics
- Training Administration
The starting point for the WBS is hierarchy level 1, which depicts the highest level grouping of the project deliverables for the course (as illustrated in Exhibit 4). In this example we can see that the project will produce training materials, logistics deliverables, resource deliverables, advertising deliverables and training administration deliverables. At this level we don't know what these encompass and it would ill-advised for any solution provider to build a course with just this limited amount of information.
Exhibit 4 – Training Course WBS – Level 1
Most WBS decomposition efforts will require the WBS to be drilled down to at least three levels, but more levels beyond three would only be added for specific deliverables that are very complex and need more clarification. WBS Level 2 shows the major deliverable components for each parent at the top of the hierarchy legs (as illustrated in Exhibit 5). For example, Training Materials are made up of Work Books and Content and the Logistics deliverables include Course Location Rooms, Parking logistics, and Computer Equipment deliverables. It is only necessary to decompose deliverables to WBS Level 3 and beyond (as illustrated in Exhibit 6) when more detail is needed to understand what will be produced for a parent deliverable. It might be beneficial to know there are multiple types of computer deliverables to support the delivery of a virtual training course, but probably too much information to list every computer component down to memory and drives and wiring, especially if the project effort involves buying this equipment versus manufacturing it. Keep in mind that it is always necessary to always apply the 100% rule when decomposing the WBS. Continue to answer the question: Does this new level of detail represent everything that makes up the parent deliverable above?
Exhibit 5 – Training Course WBS – Level 2
Exhibit 6 – Training Course WBS – Level 3
Service WBS: Wedding Planning Service
Projects that create a service as the final outcome also have deliverables that need to be included in a WBS. Although the essence of the project solution is to put in place the services to be performed, there are specific deliverables that are associated with, or the result of, performing the services that are included in the WBS. Think of this WBS as being used as a checklist of deliverables that could be provided to the customer to configure the service, or these could be interim deliverables associated with providing the services. There are seven categories of deliverables that are parts of the Wedding Planning Service (as illustrated in Exhibit 7). The highest level Wedding Planning Service deliverables (i.e., WBS Level 1) include:
- Attire for the Wedding Party
- Ceremony
- Reception
- Rehearsal Dinner
- Bridal Lunch
- Accommodations
- Transportation
For a wedding event, if the customer chooses to utilize all of the available services, the WBS deliverables associated with these services will be included in the schedule and the budget for the wedding. If the customer decides not to use some of the services (e.g., Bridal Lunch and the Transportation Service) the WBS deliverables associated with these services are removed from the WBS that is prepared for that wedding and also excluded from the project schedule and the budget. Notice that the WBS leg “Ceremony” has a deliverable called “Minister.” Deliverable categories may include people when these people are part of the service solution being provided (e.g., a minister may be needed to perform the wedding for the customer). If the “Minister” deliverable were to be left off of the WBS, it is possible that the activities for engaging a minister might be left out of the planning and budgeting for the wedding until the last minute. This oversight would likely drive the schedule and cost change requests on the wedding.
Exhibit 7 – Wedding Planning Service WBS
Process WBS: Workplace Relocation Project WBS
A Workplace Relocation Project is an example of a project that would use a pre-established WBS to represent a repeatable process or methodology (illustrated in Exhibit 8). While the outcome of the project will be relocated staff, which is not a tangible product, the project of relocating the staff will rely on including the tangible methodology deliverables to execute the move. A process WBS is a blueprint which ideally includes every type of deliverable that could be included when performing the process. The expectation is that for each project where the process is utilized, the scope of these projects will dictate which process deliverables are in scope and which are out of scope. This approach of customizing the WBS on a project by project basis reduces the likelihood of inadvertently overlooking a process deliverable and also encourages consistently performing the process between projects. The process of performing a workplace relocation includes deliverables categorized on the WBS Level 1 as:
- Current Location
- Target Site Location
- Relocation Staff
- Transition Plan
- Funding deliverables
Exhibit 8 – Workplace Relocation Project WBS
In this workplace relocation example, we can see that several of the WBS Level 2 deliverables have been decomposed to WBS Level 3, whereas others have not been drilled down this far. This is common to occur as a result of a brainstorm activity to decompose the WBS, where more complex or possibly troublesome deliverables come to mind early during the decomposition. Looking at the Workplace Relocation Project WBS example, it would be safe to assume that it is not a fully decomposed WBS because many of the other WBS Level 2 deliverables are too subjective in nature (e.g., what are the components that make up Packing Materials, Utilities, Transition Plan, Supplies, etc.).
While every WBS will include deliverable hierarchy legs for the final product, service, or process deliverables, they may also include hierarchy legs for project management deliverables. Some teams choose to represent the project management deliverables in a separate WBS from the project solution WBS. On the Workplace Relocation Project WBS we can see that it depicts two project management deliverables associated with Funding for the project: Budget and Budget Release Schedule. A common representation of project management deliverables crossing over from a separate WBS is the inclusion of milestone deliverables on the specific project WBS.
Transition from WBS to Project Schedule
Transitioning from WBS to Project Schedule is a logical continuation of the WBS decomposition activity (as illustrated in Exhibit 9). By following the 100% rule, the project stakeholders continue to decompose the deliverables in the WBS, using only nouns until they have a clear understanding of what needs to be produced. At some point during the decomposition the transition to activities occurs naturally, when the next level of WBS decomposition can only be stated in terms of a verb phrase that describes how the deliverable will be produced. At this point the team is ready to use the WBS deliverables as the focal point to describe how each deliverable will be produced, listing every activity that will be included in the Project Scheduling processes.
Exhibit 9 –Transition from WBS to Activities
We can see that for the deliverable Frame under “Frame Set” hierarchy leg that stakeholders were at the lowest level of detail needed to understand what was going to be produced and they began to list the activities for building the frame: Design Frame, Create Prototype, Finalize Design, Build Frame and Paint Frame. Every deliverable in the WBS must ultimately have activities defined for producing it and when this is not possible, it is either because the deliverable is still not clear or more likely that the deliverable is not relevant and not in scope for the project, which is why the stakeholders are not describing activities to produce the deliverable.
By creating the WBS from a deliverables perspective, listing all of the deliverables to be produced as part of the project effort, the project team has a basis to substantiate the activities included in the Project Schedule and the costs to produce the deliverables included in the Project Budget. The WBS supports the project team's underlying assumptions for the project schedule and the project budget because The WBS is an input to the Define Activities process of the project. If Change Management requests are approved to increase or decrease the scope of the project, the WBS deliverables will be updated to reflect the approved changes, adding or removing deliverables as needed, which in turn adds or removes activities and drives schedule and budget changes.
Summary
When project teams are asked to prepare their schedules and budgets at the initiation of a project — before any project work has been performed —the safest way to substantiate what is included in the schedule and budget is to base these deliverables on the stakeholder's knowledge of the deliverables that will be produced during the project. The WBS becomes the foundation project deliverable used to document and communicate all of the tangible project product, service, and process outcome components. Although the WBS deliverables will ultimately be expanded to a level that includes activities, durations, resources and costs required to produce the deliverables, these pieces of information are part of the WBS. They are part of other project deliverables, such as the Project Schedule, Network Diagrams, and Budget, which are based on the WBS.
The WBS is relevant to all project types: product, service, and process creation projects because each of these projects produces a set of deliverables as part of the project outcome. Once the project stakeholders have agreed on the “What's” for a project by decomposing the WBS into nouns representing all of the in scope deliverables, they are ready to make the transition from “What” to “How” and use the WBS as input to the Define Activities process, as well as the foundation for managing the project scope and ensuring only the approved WBS deliverables are delivered as part of the project effort.
