“What is the biggest challenge you have experienced when asked to prepare a work breakdown structure (WBS) deliverable at the beginning of your project?” This a question I ask project teams when they engage my services to help them produce a WBS to manage the scope of their project and make project decisions. The typical answers I receive are:
- Our proposed schedules and budgets are always off because we don’t know enough about the project when we are asked to produce the WBS during the initiation phase
- We are asked to prepare our timelines before we have enough project background
- Many of our team members don’t have MS Project, so they don’t see the value of contributing information to a WBS
- We use an agile methodology so it is not relevant to create a WBS because it can change after each scrum cycle
- I use a WBS as an activity organization tool for myself, and don’t see how it would provide value to any other team members
The first thing I point out after receiving the above 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, resource assignments or dependency information. A work breakdown structure is a higher level project document that supports schedules and budgets. It provides a view of the total scope of the project represented in terms of project deliverables only. The WBS deliverables are those that make up the final product, service, or process that is being produced, as well as all intermediary project methodology outcomes required to manage the project. The WBS is a structured, graphical, and often hierarchical, representation of all of the deliverables to be produced by the project effort (A Guide to the Project Management Body of Knowledge [PMBOK® Guide]—Fourth edition, 2008, pp. 116). As such, the WBS is the foundation project stakeholders will use as a basis for creating schedules with project activities, network diagrams to sequence work, and budgets for projecting costs and resource assignments. When the project team creates their project schedule and/or budget without first creating a WBS, they increase the risk of producing inaccurate and unsubstantiated schedules and budgets and lack the information to make informed decisions on requirements.
The easiest way to ensure that the WBS is focused on deliverables to be produced rather than on activities, which are performed only to produce approved in scope deliverables, is to follow this simple rule: WBS = Nouns, Activities, and Schedules = Verbs. Deliverables in the WBS are always represented as nouns (i.e., objects); activities always start with verbs and describe work to be performed in order to produce a deliverable. Following this simple rule of “nouns not verbs in the WBS” will help stakeholders ensure their WBS includes only project outputs and does not include the activities that belong in the project’s schedule.
This paper focuses on techniques a project manager and project stakeholders can use to leverage progressive elaboration to create a comprehensive WBS at the onset before any substantial project work is completed. It demonstrates how the WBS leverages a wealth of information available in the project scope statement. I will explain the use of the scope statement documents (objectives, context diagram, project constraints, critical success factors, and project assumptions) as a source of information used to add deliverables to the WBS. Additionally, this paper illustrates why changes are required in the WBS as a result of modifying the project scope statement through the change management processes.
Leveraging Facilitated Meetings
The most complete and accurate WBS can only be created when the project manager includes input and ideas from as many of the impacted project stakeholder areas as possible. Engaging the stakeholders in the WBS activity is part of managing customer expectations. To overcome the challenge of soliciting and managing the appropriate level of stakeholder participation while creating the WBS, the use of facilitated meetings is invaluable. Facilitated JAD (joint application design) meetings have been shown to improve the quality of project deliverables. The PMBOK® Guide—Fourth Edition refers to a facilitated workshop as a tool that can be used during the Collect Requirements Process (PMBOK® Guide, 2008, pp. 105, 107). Facilitated meetings are most effective when led by a neutral facilitator (i.e., someone without a stake in the project outcome). The facilitated meetings are structured to engage all the appropriate stakeholders as participants and allowing them to collaboratively make decisions and interactively build their project deliverables (e.g., the WBS) during the meeting. It takes significantly less time to build the WBS in this manner and the result is a higher quality and more accurate and complete WBS; all of the participating stakeholders not only understand and buy into this but will also use it as their reference point for making all other scope-related project decisions throughout the project.
The Project Charter’s Influence on the WBS
Project stakeholders become smarter as their project progresses and decisions are made. Even at the onset of a project, when minimal work has been completed, there is still a significant source of information available to the project stakeholders to feed the creation of the WBS—the project charter. The key to using the project charter as a resource for building the WBS is to read through the charter and cull out all of the nouns it refers to. Remember, the WBS only contains nouns and represents the deliverables that will be produced as part of the project effort. We can look at a sample of a project charter for a home remodel project (as illustrated in Exhibit 1) to see what it tells the project stakeholders about the outcomes of a home remodel effort for which they need to create a WBS.
Upon examination of the project charter, the project stakeholders can extract many nouns that directly state or infer deliverables for the project’s WBS. They can interrogate action-oriented verb statements and answer the question “Why are these actions needed?” to infer the deliverables the actions will produce.
Project Charter nouns include:
- Kitchen remodel project
- Pool upgrade project
- Landscape update project
- Commercial-grade appliances
- Gardens and lawn
Project Charter verb phrases and their (inferred noun deliverables) include:
- Replace decking (decking)
- Dining and entertaining outside (entertainment area)
- Diving and lap activity (swimming pool)
- Entertain up to 12 people (entertainment area)
- Paying bills, doing homework without impacting meal preparation or eating (homework area, cooking space)
With this initial list of nouns, the project team is now able to begin constructing the project’s WBS by transferring the specific and the inferred nouns to the WBS document (as illustrated in Exhibit 2) When stakeholders work collaboratively to produce the WBS, their subject matter expertise and experience with similar types of projects will also drive the identification of more noun-based, end state deliverables they can add to the WBS. They may also start adding project management intermediary deliverables under the project management leg of the WBS, such as: budget, project requirements list, schedule, and so forth. The team quickly realizes that they know more about the scope of the project or can make decisions about the scope after reviewing the project charter and working collaboratively to build the WBS.
The Project Scope Statement’s Influence on the WBS
The project scope statement provides even more information for stakeholders to use as they identify content to be included in the WBS. The project scope statement contains these documents: objectives, context diagram (business processes and external entities), project constraints, critical success factors, and project assumptions. Not every statement included in these documents has a direct tie to the WBS, but there can be significant deliverable information the stakeholders can use to expand the WBS. We will look at each of these documents one at time.
The objectives document (business and project) provides high level scoping information, which clarifies the targeted future state business changes and boundaries of specific project efforts that will contribute toward achieving the business changes. Although the business objectives are broader in breadth than the boundaries of any specific project, there are often high level references to project specific deliverables, which can be included in the project’s WBS. The project objectives contain more distinct clues for stakeholders to use as they expand the content of their WBS. The examples: objectives for the home remodel (as illustrated in Exhibit 3) and WBS updated after objectives (as illustrated in Exhibit 4) demonstrate how the project stakeholders might update their WBS based on knowledge garnered from an objectives document.
Four of the objectives in the document, are business objectives, (OBJ-001, OBJ-002 and OBJ-004, OBJ-007) as indicated by the “B” designator. OBJ-001 does not provide any specific deliverable information for the end state of the remodel projects, but the team could infer that there will be a budget set for the projects based on the words: spending no more than US$90,000 on updates. A budget is a project management deliverable, which was already added to the WBS based on the project charter. OBJ-002 refers to “outdoor water,” which would lead the stakeholders to include a deliverable for an outdoor watering system in their WBS. OBJ-004 uses the nouns: landscape and yard, which are already represented by similar deliverables in the WBS (gardens and lawn). OBJ-007 communicates the desire to make a profit when the home is sold in the future. This information will likely influence other aspects of the project work, particularly related to the types of solutions that are chosen, but there are no additional nouns to trigger adding deliverables to the WBS.
The remaining objective statements are project objectives (OBJ-003, OBJ-005, OBJ-006), as indicated by the “P” designator. OBJ-003 includes references for an entertainment area, eating area, commercial appliances, and homework area. These deliverables would be added to the WBS, if the stakeholders had not already added them based on their prior knowledge of the project. OBJ-005 includes the nouns: landscape design and gardens. Gardens are already on the WBS, but landscape design is a new deliverable, which must be produced and is added to the
WBS. OBJ-006 is related to the pool upgrade project and offers more nouns and phrases: pool facilities, area for entertainment and preparing and eating meals, and the deck. Stakeholders add the associated deliverables in their WBS for these project concepts.
The context diagram is a high level, one-page, picture of the project scope and it clarifies the business processes, which will be affected by the project (added or modified functionality) and the external entities, which represent end state hand offs (i.e., interface points) to and from the business processes. While the work performed by external entities is outside the scope of the project, the elements that pass to and from the business processes are parts of the project and must be included in the WBS. Each business process is written in a verb/noun format because they describe a related set of functionality the project solution is going to provide. The business process nouns can be represented in the WBS as high level deliverables. The interface points between the external entities and the business processes, also described as nouns, should be looked at closely to determine if those nouns represent specific deliverables produced by the project or trigger ideas about additional deliverables that will support the interfaces.
A review of the business processes in the kitchen remodel context diagram (as illustrated in Exhibit 5) produces two additional deliverable elements the project stakeholders have added to the WBS. BP-001: Prepare food triggers the concept of a preparation area. BP-004: Store food and non-food items triggers the need for one or more forms of storage in the kitchen. As stakeholders think about the functionality of the future kitchen’s end state and the business processes that can be performed, they may be able to identify even more deliverables for the WBS.
Looking at the inputs and outputs on the context diagram, the arrows to and from the external entities, provide more information the stakeholders have used to expand on the deliverables on the home remodel project WBS. We can see that music and TV programs are being added to the kitchen as a result of the home entertainment system entity E-003. Stakeholders used this information to add music system and TV system on the WBS under the higher level deliverable of entertainment system. The inputs for E-001: Utility companies, triggers the addition of four WBS deliverables: electric service, water service, gas service, and communication service (as illustrated in Exhibit 6).
The project constraints are developed as part of the project scope statement to communicate the limitations imposed on either the project solution or on the way the project manager will manage the project effort. The information contained in these limitations has a direct impact on the scope of the project (expanding or reducing the scope) because they either require additional work to be done in a certain manner (e.g., obtain permits, follow regulations, execute the project within specified money and time limits, etc.) or they communicate what cannot be included as part of the solution (e.g., the new facility must be company owned versus a leased property, software provided by non-certified vendors cannot be implemented, etc.). Although every project constraint imposes a limitation on the project in some manner, not every constraint has a direct tie to the content of the WBS. Project stakeholders evaluate the project constraint statements, looking for nouns that represent deliverables to include or exclude from the WBS.
There are three project constraints (as illustrated in the example Project Constraints, Exhibit 7), which the project stakeholders used to expand the content of their WBS. CNST-001 is a legal constraint, imposed by an external regulatory body, and indicates that the project manager cannot run the remodel projects without having the proper permits in place. The noun phrase “building permits” should be added to the WBS. The project team may be familiar enough with the concept of permits to use their knowledge to trigger more detailed information about specific types of permits, adding these as sub-deliverables below building permit (as illustrated in Exhibit 8).
CNST-003 is a policy limitation, imposed by the homeowner, requiring that the remodeled kitchen have cooking mechanisms in place to allow the kids to cook meals without having to use the commercial stove or oven. Although the specific deliverables representing cooking mechanisms beside the commercial-grade stove and oven are not directly spelled out, this constraint triggers ideas about what those other cooking mechanisms could be (i.e., small appliances) . The project stakeholders use this inferred information to include the small appliance deliverable on the WBS (as illustrated in Exhibit 8).
CNST-002 also defines a limitation on the way the project is managed because it states how long the general contractor is available to work on the project. In essence, the project should not extend beyond this date because the general contractor will not be available. There is no specific deliverable related to the end product of a remodeled kitchen that CNST-002 refers to, however; the project schedule is a methodology deliverable for the project, so if the project team has not already included project schedule as a methodology deliverable, they would want to make sure they add it to the WBS at this point. Remember, the WBS must represent all the deliverables to be produced during the project—final deliverables that make up the end product or solution and intermediary deliverables, which are required as part of the project methodology or deliverables required to produce the final project deliverables (e.g., prototypes, sign off documents, test plans, etc.).
Critical Success Factors
Every project has critical success factors (CSFs), which document non-prescriptive expectations that must be met by the project team, or the project result will be considered a failure. Although CSFs do not dictate how the project solution and result should be obtained, they may contain references, via noun concepts, which are triggers to add deliverables to the WBS. The project stakeholders need to understand and evaluate what each CSF is requiring of the project team, and determine what deliverables, if any, tie back to the CSF expectations.
In the example of CSFs for the home remodel project (as illustrated in Exhibit 9), two critical success factors have been identified. CSF-001 pertains to a completion date for the kitchen remodel project, which must be achieved in order for the home owner to use their new kitchen for entertaining during the upcoming holiday season. The CSF does not prescribe how the project team achieves this completion date, but the project team can use this information when making decisions for the project—selecting options that will not delay the completion of the project beyond this date. Based on deliverables already included in the WBS (e.g., project schedule) up to this point, there are no additional deliverables that have been identified for the WBS.
CSF-002 sets the expectation that commercial grade major appliances will at least consist of a stove, ovens, refrigerator, and a dishwasher. There should not be any requirements defined in the CSF specifying the characteristics of these appliances, because these will be captured in the business requirements for the project. However; the project stakeholders will use the appliance nouns to expand the entry for Commercial Grade Appliances on the WBS (as illustrated in Exhibit 10). This change, to the WBS, substantiates what is now known about commercial grade appliances. Unless other requirements establish the need for more appliances, the four listed appliances sets the expectation that they are all of the commercial-grade appliances associated with the project.
The final scope statement document, project assumptions, provides information that almost always has a direct influence on the content of the WBS. The project assumptions represent decisions that are outside the control of the project team and, therefore, are the most volatile of the scope statement deliverable statements. They need to be reviewed frequently to identify changes for the WBS. Assumptions provide a mechanism for the project to move forward on work based on the decision represented in the assumption even though final decisions are not in place at the current time. Project assumptions typically identify scope which is excluded from the project. Scope included in the project is represented in other project documents (e.g., business and technical requirements, etc.).
In the example of project assumptions for the home remodel project (as illustrated in Exhibit 11), A-001 refers to a potential wood shortage that is not expected to impact the availability of cabinetry and shelving for the project. The project stakeholders use the reference to cabinetry and shelving to update the WBS with these two deliverables. A-002 assumes that the existing tile floor in kitchen will be able to be matched after expanding the kitchen footprint. The project stakeholders use this information to include tile floor deliverable information in the WBS. Even though the project assumption only references the noun phrases “tile flooring and kitchen floor,” the stakeholders may have enough familiarity installing tile floors to add other flooring details: tile, grout, and grout sealer (as illustrated in Exhibit 12)
Project assumption A-003 is assuming the existing kitchen window will not be blocked or require modifications caused by work associated with other home remodeling projects: Landscape update project and pool upgrade project. Based on this assumption, the project stakeholders can move forward with the project as if the window will not be moved or enhanced in any manner. Since no work is required for the kitchen window, it is left off of the WBS, which means no activities will be included in the schedule for the kitchen window. As the project progresses, if changes to the window are identified and approved to be in scope for the project, or A-003 proves to be invalid because the other projects will impact the window, then kitchen window will be added to the WBS as an output to be produced.
Summary – Leveraging the Knowledge Gained From the Project Scope Statement
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 these deliverables is to base them on knowledge of the deliverables that will be produced during the project. The product and project deliverables are the content represented in the project’s WBS. Although many project stakeholders assume that they don’t know enough about the project to create a WBS at the project inception, there is a wealth of deliverable information available to them early in the life cycle to create a robust WBS, as demonstrated in this paper. Through the use of progressive elaboration, as decisions are made on the project and documented in the project scope statement, this information becomes available to the project stakeholders. They use this new information to expand the high level framework of their WBS, created from information in the project charter into increasing more precise details of the deliverables, which make up the scope of the project.
Once the project scope has been approved as a baseline for the project, the project’s WBS represents all of the project- and product-related deliverables, which substantiate activities in the project schedule and projected costs in the project budget. At any point during the project, change management processes may result in approved changes to the scope of the project. When this occurs, the appropriate scope statement documents must be updated to reflect the approved change. Just as information in the original scope statement deliverables influenced the content of the WBS, an evaluation of the adjusted scope statement will likely provide new information regarding deliverables to add or removed from the WBS. Maintaining this symbiotic relationship between the project scope statement and the WBS ensures that the WBS always represents 100% of the work to be produced by the project.