From Confusion to Clarity (part 2)
How to Create a Work Breakdown Structure
“Creating a WBS must be done with care, completeness, and concern. [If you don’t]—well, you’ve failed from the start.” — Pam Gretchen
In the realm of project management, one crucial thing stands out as the foundation for success: the Work Breakdown Structure (WBS). As we discussed in a previous article on the What and Why of WBS, this key document enables project managers to define, plan, organize, and execute a project. Without a complete and accurate WBS, however, we cannot even know what we’re to create, let alone put a plan together to create it. In this post, we’ll dive into the “How” of creating a WBS, offering a simple framework to create a robust WBS that fully defines the scope, helps align stakeholders, mitigates risks, and improves the chance of project success.
The How:
Creating a complete and accurate WBS is straightforward—but not necessarily easy. It takes time, systematic thought, and discipline. Here are the three key steps to creating a WBS for your project:
1. Identify Scope
The first step in creating a WBS is to identify the scope of the project. This involves obtaining a clear understanding of the project's desired outcome & deliverables (and associated requirements), which will be assembled into a comprehensive work breakdown structure. To do this:
Start with the Mission Statement and High-Level Objectives. Begin by reviewing the project's mission, aim, and high-level goals. Excellent projects always have a mission statement, which typically outlines a broad overview of the project's purpose, objectives, and overall vision for success. If you don’t have one of these critical documents, then go write one (see this post here). You cannot understand “what” your project is supposed to create (i.e., its scope) unless you’ve first defined it’s “why.” A mission statement serves as a source document for identifying the key deliverables that need to be included in the WBS.
Brainstorm with the Team and Stakeholders. Don’t create a WBS by yourself. Engage the project team and relevant stakeholders to identify the scope of the project. There are many ways to do this, but one effective method is via a series of brainstorming sessions. Encourage everyone to share their ideas, perspectives, and knowledge related to the project. This collaborative approach helps to ensure that all important aspects and potential deliverables are considered. Also consider speaking with participants of other, similar projects; their experiences can provide valuable insights and help identify any common elements that should be included in your WBS. Remember that scope means deliverables, not activities (which belong in a schedule, not a WBS). Deliverables are the tangible elements of the project that need to be produced, achieved, or provided. They typically fall into one of three categories: products, results, or services. These are the deliverables that literally define what project success looks like. When brainstorming to capture all aspects of the project scope, use visual aids such as whiteboards, sticky notes, or mind-mapping software. Begin with the high-level element, the final "big-picture" deliverable and then fill in details on components, and subcomponents, and so forth. For instance, if the project centers on building a bicycle, the assembled and tested bike serves as the top-level deliverable. Below this, list major components like frame, seat, handlebars, wheels & tires, and pedals. If there are subcomponents, such as spokes, ensure they are connected to their respective parent elements. You might also have major branches for things like user documentation, packaging materials, and so on. Regardless, and although it's natural to consider lower-level scope, strive to adopt a top-down approach initially. Yes, absolutely write and capture the lower-level scope as it occurs to you, but to ensure you capture everything, it’s useful to think “top-down” and not “bottom-up” at first.
Progressive Elaboration. As stated above, adopt a progressive elaboration approach when creating the WBS. Start with the high-level deliverables of the project and gradually add more detail as you proceed. This allows for flexibility and refinement as the project scope becomes clearer with time. A common mistake of a new project manager is to try to capture everything at once. More experienced PMs start with the big picture deliverables and then progressively and iteratively add detail with time.
Gather Acceptance Requirements and Other Notable Information. While collecting the scope, you should also gather acceptance requirements and any other notable related information. For instance, while you’re identifying scope, it’s common to think of additional information that, while not appropriate to include in the WBS itself, still needs to be captured. Typically, this information ends up in a “WBS dictionary,” which, as its name implies, describes and details the particulars of every element of the WBS. It can include things like high-level key performance parameters (KPPs) and other acceptance requirements that define the criteria that must be met for each deliverable to be considered complete and acceptable. It may include specific constraints, dependencies, risks, or critical information that may impact the project's scope. The bottom line is every element of scope will have details and information and requirements tied to it; write these things down as they occur to you—or risk forgetting them.
2. Organize & Document the Scope in a WBS
After gathering the scope for your project, the next step is to organize it in a structured manner. This involves creating a hierarchical Work Breakdown Structure (WBS) and aligning it in a logical set of categories. The goal of this step is a clear, complete, accurate organization of the scope that maintains an appropriate balance between complexity and simplicity. Here are the key points to emphasize during this step:
Document in Hierarchical Work Breakdown Structure (WBS). Document the gathered scope in a hierarchical Work Breakdown Structure (WBS). Remember, the WBS is just a structured a list of deliverables (i.e., nouns). It can be text-based or graphical, creating a visual representation that breaks down the project scope into manageable “chunks” that are arranged in “parent-children” branches. The WBS organizes the project's deliverables, sub-deliverables, and work packages in a structured format, providing a clear understanding of the project's scope and its hierarchical relationships. I’m a big fan of mind mapping software for this step, as it’s easy to drag scope elements around into unique structures and categories to “see what fits” for your project needs.
Align/Organize WBS via Acquisitions Approach (“Deliveries”). There are many ways to organize a WBS, such as by phase of work, funding sources, etc. Personally, however, I’ve found the most use in aligning and organizing the WBS elements via the assumed acquisitions approaches. Think in terms of procured or created "deliveries" or outcomes at each level of the WBS. It helps ensure that the WBS reflects the way the project will be acquired or accomplished, making it easier to manage and track progress.
Establish Control Accounts (“Ownership & Tracking”). While you’re organizing the WBS, it’s also helpful to establish Control Accounts within the WBS. Control Accounts represent major management points where performance measurement and tracking take place. They provide a means of assigning ownership and responsibility for specific areas of the project scope. Control Accounts are typically associated with a specific level of the WBS and act as monitoring points to track progress and manage resources effectively. Traditionally, Control Accounts occur where your WBS aligns with the Organizational Breakdown Structure (OBS). The areas where they overlap are where you will formally track, measure, compare, manage, and report progress within the project. For example, if you use earned value on your project, this is where the reportable variances will be established.
Lowest Level = Work Packages (scheduled with activities, costed). At the lowest level of the WBS on any of its branches are the Work Packages. Work Packages are the smallest components of the WBS, representing a discrete unit of deliverable. They are typically further broken down in the schedule, with a series of specific activities that result in their creation or provision. The WPs are also where we perform bottom-up costing on the project. When distinguishing between the WBS and the project schedule, the key question to ask is whether an item is a deliverable or an activity. Deliverables fall into three primary categories: Products, Services, and Results. These tangible outcomes are written as nouns, representing the literal things stakeholders expect us to provide in exchange for their funding. In contrast, Schedule Activities, denoted by verbs, represent the actions required to create those deliverables. Clarifying this distinction is vital to maintaining a clear and effective WBS; all too often, inexperienced PMs co-mingle activities and deliverables in their WBSs. Don’t be one of these people!
Keep the WBS Simple (but not too simple!). Strive to keep the WBS both clear and comprehensive. Avoid unnecessary complexity or excessive detail that may hinder understanding or usability. However, ensure that the WBS captures all the deliverables, sub-deliverables, and work packages required to complete the project successfully. Organizing the WBS, keep simple structures that comprise standalone deliverables, without interdependencies, especially at the lower levels of the WBS. Think in terms of acquiring and developing standalone and verifiable units that can be designed, built, tested, and delivered within distinct areas of the WBS. At the higher-levels of the WBS are where these elements typically come together as a collective whole. Mind mapping can be a useful technique here too, allowing you to easily rearrange elements and explore various layouts.
3. Review, Modify, & Formalize the WBS
Once you have created the Work Breakdown Structure (WBS), the last step is to review and check it for accuracy and completeness. This ensures that all aspects of the project scope are accounted for and that the WBS accurately represents the project's complete list of deliverables in a logical organization. By following these key points, you can conduct a thorough review and check of the WBS, verify its accuracy and completeness, involve stakeholders, and make necessary modifications to ensure the WBS is a reliable representation of the project's scope and deliverables. Here are the key points to emphasize during this step:
Verify all Scope Is Accounted For—and Don't Double-Count. Thoroughly verify that all elements of the project scope are accounted for in the WBS. Double-check to ensure that no deliverables or work packages are missed or duplicated. This step helps in identifying any gaps or overlaps, ensuring that the WBS comprehensively covers the entire scope without redundancy. Regularly check your WBS using the "100% Rules" to guarantee its completeness and accuracy. First, ensure that the entire WBS represents 100% of what the customer expects to receive from the project—neither more nor less. Second, confirm that each parent element in the WBS is composed of 100% of its direct children elements. Ensure that scope appears once and only once in the WBS; a/k/a the "mutual exclusivity rule." Adhering to these rules safeguards against scope gaps or redundancies, minimizing the risk of incomplete deliverables.
Scrub out Scope Creep. Another thing to check for is extra scope that isn’t needed. Circle back to the mission statement frequently during the WBS development process to ensure you’re staying on track, and then take a thorough pass through it at the end, looking for unneeded products, results, or services. It’s common during the WBS development process to experience this kind of “scope creep” in which unneeded and superfluous scope is added by enthusiastic team members and stakeholders. Be ruthless and scrub out those elements. They are, by definition, not needed on the project and are, therefore, and again by definition, something that can only harm your project, not help it. (For more on this topic, see this post here.)
Review and Verify WBS with Stakeholders. Engage your key stakeholders in the review process to validate the WBS. Collaborate with them to ensure that their perspectives and insights are considered, and that the WBS accurately reflects their view of the project's requirements and objectives. Incorporate their feedback and address any concerns or discrepancies identified during the review. Once you have created a complete draft version of the WBS, schedule a formal review session with the key stakeholder(s). During this session, walk them through each element of the WBS, discussing the purposeful exclusions and the rationale behind them. Seek agreement and understanding from the stakeholders.
Modify, Iterate, and Elaborate as Required. Based on the feedback received during the review process, make all necessary modifications to the WBS. Iteratively refine and elaborate the structure to enhance clarity and accuracy. Ensure that any changes align with the project's goals and objectives. This iterative approach allows for continuous improvement of the WBS, ensuring its effectiveness in guiding project execution.
Add WBS Tier Numbering as Late as Reasonable. Add tier numbering to the WBS, but it is advisable to do so as late as reasonably possible. Adding tier numbering typically impacts many downstream project documents, such as schedules, budgets, and various project documents. By delaying the addition of tier numbering until most of the other project planning elements are in place, you can minimize the need for extensive revisions. Numbering the WBS elements is a crucial step in organizing and referencing project documentation. However, it is best to put it off until you have reached a stage of relative stability and finality in the WBS. Once numbered, making changes becomes more challenging and can cause inconsistencies across related project documents. Exercise caution and wait until the WBS structure has matured before assigning numbers to elements.
Configuration-Control the WBS. Implement configuration control on the WBS to manage any future changes or updates. Establish a process to review and approve modifications to the WBS, ensuring that any alterations are carefully evaluated and authorized. Further, get your key stakeholder to formally sign off. This entire formalization step helps maintain consistency and traceability throughout the project lifecycle. Remember, the WBS lists exactly what you’re going to strive to create on the project, so getting it locked down at the beginning of a project is vital to planning and execution. Trying to manage a project with “moving goal posts” is next to impossible; configuration control is the antidote to that problem.
"Publish" the WBS Somewhere Publicly Visible. Finally, once finished and signed off, the formal WBS should be made easily accessible and visible to all project stakeholders. Consider publishing it on a shared platform, such as a project website or document repository, ensuring that everyone has access to the agreed-upon WBS. This visibility helps prevent misunderstandings about the project's scope and provides a clear and agreed-upon target for all stakeholders to aim for during project execution. It also helps with the aforementioned scope creep concern, and will facilitate change control later on during the project execution.
Caveats and Cautions:
There are a few key things to keep in mind when creating a Work Breakdown Structure (WBS):
Scope Creep: This was mentioned before, but it’s worth mentioning again: be vigilant about scope creep, which refers to the uncontrolled expansion of project scope beyond its original boundaries. While the WBS helps define project scope, stakeholders may introduce new requirements or changes during the project lifecycle. Regularly assess and manage scope changes to ensure they align with project objectives and do not disrupt the WBS structure.
Overcomplicating the WBS: Strive for simplicity and clarity when organizing the WBS. While hierarchies and subcomponents can add structure, excessive levels of detail can lead to confusion and hamper effective management. Balance providing sufficient granularity and maintaining a manageable structure that aligns with the project's complexity.
Balancing Flexibility and Stability: The WBS is configuration controlled, but rarely remains static throughout the life of the project. Change will happen, and the WBS may evolve as the project progresses. However, excessive changes to the WBS structure can create confusion and impede progress. Maintain a balance between allowing for necessary adjustments and avoiding frequent modifications that disrupt project momentum.
Effective Communication: The WBS is a primary project document, and it is essential to ensure that stakeholders understand its content, purpose, significance. Clearly explain the WBS and its benefits, encouraging open dialogue and active participation during the review process. Misinterpretation or lack of stakeholder engagement can undermine the effectiveness of the WBS.
Limited Organizational Buy-In: In larger organizations, getting buy-in from various departments or teams can be challenging. Lack of alignment between the WBS and the organizational structure (OBS) can lead to coordination issues and hinder project success. Seek input from relevant stakeholders across the organization to ensure the WBS reflects the collective understanding and agreement of all key parties.
Iterative Development / Progressive Elaboration: Remember that creating a WBS is a process of iteration and progressive elaboration. It is unlikely that you will capture all scope details in the first pass. Embrace an iterative approach, taking enough time and successive passes through the WBS to add more detail and refine its structure. Regularly revisit and update the WBS to incorporate new insights or changes.
The Bottom Line:
A robust and well-structured Work Breakdown Structure (WBS) is a fundamental tool for project success. By following a systematic approach and involving your key stakeholders throughout the process, you can create an effective document that captures all project scope and aligns with stakeholder expectations. Remember, the WBS literally represents your project's definition of success. Take the time to create a complete and accurate WBS at the beginning of a project, and you will establish a solid foundation to build that success upon.