Getting Started with Work Breakdown Structures (WBS)

The Project Management Body of Knowledge, an internationally recognized collection of processes and knowledge areas accepted as best practice for the project management profession, defines the work breakdown structure as 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." With a WBS, you begin with the desired outcome or product, which you then break down or decompose into the smaller deliverables or tasks needed to create it.

In a WBS, the deliverable can be an object, a service, or an activity. By focusing on deliverables rather than methods — the what, not the how — a work breakdown structure helps eliminate unnecessary work to get the intended result. A well-thought-out WBS aids in scheduling, estimating costs, and determining risk. It is usually a visual chart or diagram that spells out a project's timeline and process while capturing each task, subtask, and deliverable that will be created and executed throughout. It’s often rendered as an outline, like a table of contents, but can be organized using tabs or other visual organizational systems.

Rod Baxter, co-founder of Value Generation Partners and author of the Project Management for Success Handbook, calls the WBS “a necessary element to the product management lifecycle. It takes skill and practice to create, but it is essential to help you meet release dates and become efficient.”

In 1957, the U.S. Navy’s Fleet Ballistic Missile (Polaris) Program was behind schedule and needed help resolving the delay. The team developed a formula to determine tasks and estimate effort needed for a project based on outcome, which became known as PERT (program evaluation and review technique).

With PERT as a model, the Department of Defense (DOD) and NASA published the first description of the work breakdown structure process in 1962, but the first reference by name didn’t come until 1968. The Work Breakdown Structures for Defense Materiel Items (MIL-STD-881) established work breakdown structures as a standard across the DOD, with templates published for specific military applications, such as aircraft or ships. Even civilian contractors working with the DOD must use the appropriate work breakdown structure template.

In 1987, the Project Management Institute, through PMBOK, established work breakdown structures as standard practice for a range of nonmilitary applications. The term “work breakdown structure” was introduced in 1993 for applications in corporate and other organizational projects.

In June 1999, the PMI Standards Program issued a project charter to develop the Work Breakdown Structure (WBS) Practice Standard. According to the PMI, the Planning Process Group begins with three essential steps: scope planning (3.2.2.2), scope definition (3.2.2.3), and work breakdown structure development (3.2.2.4).

Many organizations skip the step of creating a WBS plan, or dictionary, in the interests of nimbleness and agility — or because they are being asked to “build the plane while flying it.” While it’s possible to deliver a project without proper planning and visibility, it will likely take a toll on the team members and, potentially, the ultimately quality of the deliverables. Those risks aren’t sustainable over time, so using WBS when possible is always preferred.

As businesses amass and need to parse more data within every project as well as to anticipate how data will affect a project after it’s launched, it’s clear that the WBS and attentive planning will continue to be critical elements. Other variables on the horizon include globalization, currency fluctuations, political changes, and regulations — so a strong project needs advance planning to navigate these potential dependencies.

Good resources on WBS include “The ABC Basics of the WBS” by Paul Burek and “The Intelligent Structure of Work Breakdowns Is a Precursor to Effective Project Management,” Homer & Gunn, 1995.

Although often skipped in the planning process, a work breakdown structure or dictionary is a powerful tool for finishing projects efficiently and on time. Here are some of the advantages and benefits of creating a WBS:

• Provides a visual representation of all parts of a project
• Offers an ongoing view for management and team members into how the entire project is progressing
• Defines specific and measurable outcomes
• Breaks the work into manageable chunks
• Provides a way to make successful experiences repeatable
• Sets a foundation for estimating costs and allocating human and other resources
• Ensures no overlap and no gaps in responsibility or resources
• Minimizes the chance of adding items outside the scope of work or forgetting a critical deliverable

In addition, organizations have found other benefits in using work breakdown structures. These benefits can be realized through a specific project, but may also help improve the processes and culture of your whole organization. They include:

• By taking into account each project’s WBS, the organization can quickly calculate the budget for whole departments.
• Teams can determine project schedule and budget quickly.
• As the project progresses, teams can track specific sections of the work breakdown structure to determine project cost performance and flag issues and problem areas in the organization.

A well-crafted work breakdown structure can keep your team humming along like a well-oiled machine with these benefits:

• Improves productivity
• Helps project managers predict results based on various scenarios
• Helps with project organization
• Assists in describing the project scope to stakeholders
• Helps to distribute responsibilities
• Allows correct estimation of costs, risks, and time
• Increases communication
• Enables more creativity and brainstorming
• Focuses on end goals
• Organizes details
• Potentially prevents problems
• Addresses scheduling issues
• Helps manage risks
• Allocates tasks
• Gives teams flexibility
• Eliminates confusion
• Gives every team member clear task descriptions
• Helps write and support the statement of work
• Provides foundation for clear status report on project, since each work package is a measurable unit

The Visual Advantage of Work Breakdown Structures

The work breakdown structure chart or dictionary easily displays project details and status. To present your work, you have a few options. The classic WBS view is the tree structure diagram, but you can also use numbered lists or tables. An outline is one of the easiest ways to represent a work breakdown structure. Listed below are other types of formats that are useful for different types of projects.

During the project, the elements in the work breakdown structure can be color-coded to indicate work status: for example, on-target could be noted in green, late would be in red, at-risk shows up as yellow, and completed is signified by blue. Color coding can help you identify schedule risks at a glance.

A reliable, useful work breakdown structure or dictionary should gather the critical elements of a project, along with its timeline, cost, and resources. The most helpful WBS plans contain these components:

• Identification of which organization, department, or individual is responsible for each specific work piece
• The scheduled start and end dates
• Required resources
• Estimated cost of the project
• Charge numbers
• Contract details, requirements, and milestones
• Protocol for quality control, requirements, and standards
• Technical information and resources needed to achieve desired results

At a higher level, the WBS can also serve directional and organizational roles. A thorough WBS plan can act to:

• Help human resources manage team assignments
• Manage the schedule and determine the project timeline
• Manage and measure the quality
• Anticipate enterprise environmental factors
• Identify organizational process assets
• Track version history
• Establish dependencies
• Track the overall progress of a project

Business project managers use work breakdown structures to ensure an organized, visible view of their projects and their components. These teams can also benefit from using work breakdown structures:

• Client-Facing Groups: Account directors rely on work breakdown structures to demonstrate progress (or roadblocks) to their clients. A WBS creates a “north star” for a project’s deliverables and milestones, which in turn becomes a useful tool to show clients how things are going.
• Creative Groups: Everyone knows that designers, writers, content strategists, and other creatives need help in focusing their creativity. A work breakdown structure creates helpful guardrails to keep the ideas flowing in relevant, project-centric ways.
• Remote and Internal Projects Groups: The visibility of a WBS helps everyone involved, even tangentially, in understanding who’s doing what and when.
• Technical Groups: Technical teams can use a WBS as a roadmap for their development tasks. These teams often already are operating with visual “swimlane” or other architectural types of project management milestones.

In addition to agency and corporate settings, other fields rely on work breakdown structures:

• Commercial Project Planners: A WBS can capture all the moving pieces of a large commercial project — not just the main company’s projects and team members’ tasks, but those of vendors and subcontractors. It can also capture dependencies for getting necessary permits, tracking progress with governmental approvals, and more.
• Event Planners: A WBS breaks down a complex event into tasks and subtasks, and assigning them helps keeps multiple teams moving forward on tight deadlines.
• Residential and Construction Project Managers: In addition to the tasks and team members involved in a regular commercial project, construction project managers can use a WBS to track stages in utility work, zoning approvals, environmental approvals, and more.
• Scope Planning Managers: When an agency takes on a new client, the resource planners and directors need to have at least a rough view of the project timeline and resources needed before assigning a budget and scope to the project.
• Software Developers: Software developers often already break down their projects into phases or stages. A WBS that includes other organizational members helps developers stay on top of the most important deliverables first, while giving visibility to the rest of the team.
• System Engineers: System engineers are charged with owning the big picture of their setups and keeping them running and updated for optimal performance. A WBS gives them an organic document that captures the smallest details that map to bigger systems operations. Knowing they have that information at their fingertips can ease their minds by letting them focus on the larger operational questions.

Within an organization that already has a project plan or work breakdown plan in place over the long term, work breakdown structures are helpful for a predecessor on a project to see how the project has progressed during their absence. For successors on a project, the WBS helps them see both what worked and what did not in the project’s earlier days and to track dependencies and their outcomes. In short, anyone in an oversight role who needs to plan for the division of labor on a project can benefit from using a work breakdown structure.

Sometimes the terms “work breakdown structure” and "project breakdown structure” are used interchangeably. In fact, work breakdown structures are most commonly applied as a tool to manage projects, from beginning through closeout. But work breakdown structures can theoretically help manage subprojects, subtasks, vendor contributions, and other collections of related tasks that aren’t specifically related to the management of an entire project. Thus, a project breakdown is a work breakdown that maps completely to a single project.

What’s included in a work breakdown structure? The following are features created in the WBS process, as well as related terms.

• Terminal Elements (aka work packages): Terminal elements, usually referred to as work packages, are the lowest parts in a WBS, beyond which a deliverable cannot be decomposed further. Work packages should be independent of other tasks, and they should not be duplicated elsewhere in the project. You can also think of work packages as the smallest manageable task that can be executed by an individual or team. Break down the task any further, and you run the risk of micromanaging team members.
  
  Generally, work packages should provide assignments that can be completed by a team or team member within a reporting period. If you hold weekly status meetings, then the work must be completed within one week. Another way to determine effort is through the 8/80 rule, which states a subtask should not take less than 8 or more than 80 hours to complete.
  
  An effective work package defines the work, duration, and costs for the tasks required for each deliverable. Work packages should not exceed 10 days in duration. Work packages are independent of each other in the work stream, and they should be unique and not duplicated across the project.
• WBS Coding: Work breakdown structure elements are usually numbered in decimal sequence from top to bottom. For example, an item labeled “1.1.1.3” can be found on the fourth level of the hierarchy. With such numbering, it’s easier to identify the level of the task that the element represents when referring to it outside of the context of the WBS chart.
• WBS Dictionary: The WBS dictionary (see below) describes in detail each component or task in the WBS hierarchy. It can even link to documents that further define and support the element. The WBS dictionary supports the principle of mutual exclusivity of work — in other words, no overlap, because each deliverable and subdeliverable is so well defined that little duplication of work or responsibility is possible.
• Level of Effort: A level of effort (LOE) component of a project is an activity that supports the main functions of the project. This could include the administrative work of answering and routing clients’ phone calls.
• Result-Oriented Tree: This is a model that demonstrates desired outcomes as they flow out of project steps outlined in a WBS.
• Contract Work Breakdown Structure: This captures all the types of contract and vendor work to be done on the project.
• Project Summary Breakdown Structure: This outlines the summary of the project and subprojects so that other deliverables may map to it.
• Statement of Work: The statement of work (SOW) is the signed agreement that outlines exactly what the company will deliver to the client, including milestones, and the budget each party agreed to.
• Project Schedule: This is the schedule of all components of a project, whether they deliver sequentially or overlap. It includes milestones and deliverables, as well as the cost of resources in each component.
• Basis of Estimate: A basis of estimate (BOE) is a tool developed by project managers, executives, and financial leaders that takes into account the costs of labor and resources that may be needed in a project. Using the BOE, a company can estimate what it will cost to create and deliver a project to a client.
• Resource Breakdown Structure: This visually lists the hierarchy of resources needed and used throughout a project, including when they enter and exit the project, and spells out their roles.
• Risk Breakdown Structure: A good plan includes taking note of dependencies and risks. These include risks that can occur if the team is delayed or that lie outside the team’s control, such as natural disasters.
• Organization Breakdown Structure: The organization breakdown structure (OBS) is also known as an organizational chart. It lists project leads and spells out who is assisting whom and in what roles.

Several types of formats apply to work breakdown structure documents. They include:

• Chart Format: Emphasizes the visual view of the project.
• Chart Format: Emphasizes the visual view of the project.
• Hierarchical Structure: Brings the most important elements of a project to the top for greater visibility.
• Outline Structure: Presents a time frame, dependencies, or components of bigger elements of a project.
• Tabular View: Allows team members to easily navigate to the sections that are most relevant to them.

Not every project will require the same kind of format. That can and should be tailored to the type of project and the types of team members who need to access it.

Once the project scope is available, the WBS should be the first deliverable. With the WBS defined, it’s then possible to scope out other resources, including human resources, particular skill sets, material resources (such as equipment and space), and facilities. The team can then create the baseline schedule, draw up task lists, and provide assignments.

As you manage similar projects, the work breakdown structure gets easier and can become the basis for improved delivery management. For unique projects where you and the team have no previous experience, the work breakdown structure can aid the team to define exactly what deliverables and tasks are needed for the final product.

A work breakdown structure cannot be developed in isolation. Rarely can one person know everything required to complete a project, least of all a project manager, who may not be a subject matter expert. Creating the WBS is a team effort.

Misconceptions About Work Breakdown Structures

A WBS does not specify how or when tasks will be done. It’s not a plan or a schedule. It is not a list of all activities or responsibilities, nor is it a typical organization chart. Team leaders sometimes attempt to list all the tasks required for a project within the WBS. This could result in missed tasks, causing projects to run late.

Nor is the WBS a scratch document that may or may not be used for the project. It is an important part of your project management documents. You should note any changes to the planned deliverables in the WBS, which should be subject to your company’s change control process.

Drawing a work breakdown structure can be straightforward. But the following tips are design principles to help you achieve the best results.

Focus on deliverables, not methods. In other words, plan outcomes — not actions. Think about the what, not the how. The key purpose of a work breakdown structure is to define the main deliverable in terms of the small components that form it. If the deliverable is not a product, then it must provide a specific and measurable outcome. For example, if you’re creating a WBS for a professional service, define the products or outcomes from that service.

When you focus on a specific deliverable, no matter at what level of the breakdown, the team or individual responsible knows exactly what is expected and what a good job looks like. You are less prone to add items that are outside of the project scope, which can be the case when creating a list of tasks. When team members focus on a deliverable, rather than checking off to-do list items, they’re encouraged to use their initiative and problem-solving skills to foster innovation.

No overlap (aka mutual exclusivity). Make no tasks in your WBS overlap in scope definition. This could have two possible results: It would duplicate your team’s efforts and create confusion around responsibility, effort, and accounting. A WBS dictionary that describes each component in detail can help void mutual exclusivity.

Follow the 100 percent rule. To eliminate work that doesn’t contribute to the deliverable, ensure that the sum of all resources in WBS, whether time, money, or another element, adds up to 100 percent. In other words, the elements in level two total 100 percent, and the level three and lower elements roll up into the level two percentage. Your finished project should never total more or less than 100 percent.

Look at the level of detail. Generally, work packages should provide work that can be completed by a team or team member within a reporting period. If status meetings are weekly, then the work must be completed within one week. Another way to determine effort is through the 8/80 rule (noted above).

Here are other factors to consider in determining the level of detail in elements:

• If your team is less experienced and needs more oversight, make work packages smaller and shorter.
• If you have a deliverable that might take longer to complete or cost more than was budgeted, break the project into smaller deliverables with shorter work time. With a more frequent reporting and review time, you can surface problems and resolve them sooner.

Finally, consider these other important principles as you move forward:

• Make assignments at the beginning of a project, but allow for new assignments to be created if needed over the course of a project.
• Ensure every deliverable is consistent to norms.
• Don’t worry if your structure is not completely symmetrical or balanced; many tasks and deliverables will offer more details than others.
• Ensure that tasks are not listed sequentially.

If some deliverables are not known, you can enter as much information as you know currently, then update the document as you learn more details.

The first step to creating a work breakdown structure is to bring the team together. Whether your team is all working onsite or remotely, it is essential for the members to participate in identifying the subdeliverables. Rod Baxter says, “You don’t create a work breakdown structure without someone on your team who is a subject matter expert (SME). You need people on the team that really know what’s going on.” SMEs can help list all the tasks required in a WBS and identify overlapping responsibilities or gaps in the completed chart.

You will also need to assemble these key documents to begin development of the WBS: the project charter, the project problem statement or scope definition, all applicable contract and agreement documentation, and the existing project management practice processes at your organization.

An effective work breakdown structure should contain each of the following elements or components:

• A project vision statement
• Defined project phases that depend on the project size
• A list of tasks with deliverables

Dr. Larry Bennett, a Civil Engineer, Project Manager, and author of four books, sees at least two advantages when a work breakdown structure is created by the team: “There’s a potential for large amounts of input from varied viewpoints, and the ownership that results from participation.”  

Your tools for capturing information can be as simple as a stack of 5-by-3 cards or a pad of sticky notes that you use to write down the deliverables and related parts. Then you can arrange them on a whiteboard, cork board, or even a wall. Virtual teams can perform a similar activity through collaborative whiteboarding software.

To begin creating a WBS, define level one, the main deliverable of the project. Then add as much detail as possible to level two before moving to smaller chunks of work in level three and beyond, if needed. Always try to define what’s required in the previous level in as much detail as possible before moving to the next levels.

How to Create a WBS: The High-Level View

Before diving deep into the details of the work breakdown structure, it’s important to begin honing it at a high level. Take these important preliminary steps first:

1. Determine and describe the project statement
2. Highlight all the necessary phases of the project
3. Create and list the deliverables (as well as how success will be measured)
4. Divide the deliverables into manageable tasks
5. Assign every section and ensure each owner is empowered to deliver

Tools for Creating a WBS and Linkable Information

Although you can capture your WBS with index cards or pen and paper, electronic templates and tools make it easier to record, edit, and disseminate the chart to team members, then save it with document control settings so that updates are recorded through the change control process.

Templates simplify the job. Your team or company may already have a template. If not, you can create your own WBS or download one of the templates from the web and customize it. Look for these useful features in a template:

• WBS coding field
• Component label field
• Company logo block
• Space for the team name
• Section for the project manager’s name

The following information typically could be linked to each element in a WBS so that it’s even more useful, dynamic, and shareable to the team:

• WBS Number: This is the outline or index number assigned to each component or step in the process. For instance under the section you title “1,” tasks and deliverables that follow under that section or phase of a project would be named “1.1,” 1.2,” and so forth.
• Title of Each Element: This is the agreed-upon short name of each milestone or deliverable that is organized into and spelled out in the WBS.
• Definition: A short, catchy label is not useful if it’s unclear to your stakeholders, so it’s important to spell out — as briefly as possible — what each name means. For instance, you may need to clarify what “Project Closeout” means. Does it mean that final invoices are paid? That the final project, with supplemental detail, is delivered? If there is any chance anyone might be unclear on what any of the titles mean or if you tweak those for each WBS, spell it out.
• Stakeholder Names and Roles: List of the names of each stakeholder and designate his or her role (participant, accountable, keep in the loop, sign-off required, and so on).
• Activities and Tasks: Spell out the steps required to complete each milestone and to whom they are assigned, especially if these include contributors outside of your core team.
• Definition of “Done”:  Describe the requirements for completion of each task and milestone. How should it look, what should it contain, who should see it, and where does it go next?
• Deliverable Format: Describe what it will look like — for example, a Word document about 10 pages in length provided electronically, or a PDF or UX template delivered by email or as a shared document.
• Dependencies or Risks: Capture all the risks and dependencies that could affect the delivery of each milestone. These could be internal risks (a client seeking more rounds of review, for example) or external (a power outage that affects the delivery of certain components).
• Estimated Budget: This should take into account all the asks involved, the cost of staffing, hardware and software resources, and other factors.
• Project Phase or Lifecycle: This is optional, but it can be useful for longer or more complex projects. For certain deliverables, a phase or lifecycle can be built out in detail that is not needed for other components or milestones in the project.

While work breakdown structures are and should be flexible and tailored to each project, these tips will help project managers and organizations create the most useful WBS:

1. Organize a brainstorming session among the various departments involved with the project.
2. If desired, allow project teams to use low-tech tools like a whiteboard, note cards, or sticky notes to identify major deliverables, subdeliverables, and specific work packages.
3. Take advantage of tools that support mind mapping and brainstorming.
4. Adopt a standard structure for providing descriptive information for each WBS element in the WBS dictionary to ensure consistency.
5. Tailor the amount of detail. The level of detail provided should be less for WBS elements that are higher in the hierarchy and more detailed for lower-level elements.
6. Ensure frequent reviews. Because the WBS is an organic document, revisit its contents frequently and adjust accordingly to assure proper project performance and delivery.
7. Make sure to capture documentation and review cycles, and the time they take, as well as training at the beginning of the project and testing at the end.
8. Note the project management deliverables, including the production of a project plan. Delineate the deliverables that the customer or an external party must meet or deliver. Check the project approach outlined in the project charter for any activities that need to be included in the WBS.

An effective work breakdown structure cannot be slapped together overnight or by one person. To be truly effective, a WBS should:

• Spell out everything related to creating and delivering the project, including all deliverables and milestones.
• Be created by the project manager and others directly involved in the project and not, for example, handed to a project manager “from above” or from a client. This way, those who will be held accountable spell out what they will be doing, and they can buy in completely to what and how it will be delivered.
• Express all the information visually, so that the concepts are easily grasped and organized.
• Be a living document; dependencies and risks can affect timeline and/or scope, so the WBS needs to be treated as an organic guide, that operates as the “true north” of the project, while being adapted and modified as needed
• Be adaptable to any format or platform, so that team members can quickly access and act upon it, wherever they are, on any device

Download Work Breakdown Structure Dictionary Template

The WBS structure, or dictionary, is a fluid document, but will always include certain information. Here are the elements of a thorough, reliable WBS dictionary. Note that the elements that roll under each phase can be moved or adjusted as desired. Here is one example, involving the development of software, but notice that the project is not simply about the phases of software creation and testing.

1. The Title of the Project
2. Initiation
3. Development of project charter
   A - Deliverable: Submit the project charter
   B - Project sponsor reviews project charter
   C - Project charter is signed and approved
4. Planning
   A - Create the preliminary scope statement
   B - Determine the project team
   C - Project team kickoff meeting
5. The project plan
   A - Develop the project plan
   B - Submit the project plan
   C - Milestone: Project plan approval
6. Execution
   A - Project kickoff meeting
   B - Verify and validate user requirements
   C - Design the system
   D - Procure hardware and software
   E - Install development system
7. Testing phase
   A - Install live system
   B - Do user training
8. Go live
9. Control
10. Project management
    A - Project status meetings
    B - Update project management plan
    C - Risk management
11. Closeout
12. Audit procurement
13. Document lessons learned
14. Update files and records
15. Gain format acceptance
16. Archive files and all documentation

Additional dictionary items:

• Completion Date: The date when the WBS deliverable was handed off.
• Deliverable Status: This can be applied to individual deliverables or milestones within the project, or it can reflect the overall project deliverable status.
• Dependencies and Risks: Describe the dependencies that impact deliverable completion.
• Estimated Date to Completion: Date when you think it is reasonable for the work to be complete.
• Issue Log: List of problems that are currently impacting the deliverable (reactive engagement).
• Percent Complete to Date: The amount of deliverable completion expressed as a percentage on a particular date — for example, 20 percent as of Dec. 14, 2020.
• Progress Comments: A memo field that allows one to keep a daily/weekly log of progress.
• Responsible Person: This person is charged with completing the deliverable. This may not necessarily be the person or team doing the work, but could be a functional manager.
• Risk Log: List of possible elements or factors that could negatively impact the deliverable and planning alternatives (proactive engagement).
• Start Date: Specify when the project starts, which may be the date a scope of work is signed, and includes other “start dates,” like the creation of a project charter, formal work kickoff, etc.

How to Create a WBS in Microsoft Project

1. In Microsoft Project, add the name of the main deliverable in the Task Name field.
2. Add the list of subdeliverables in the Task Name field. To indent the subdeliverables, use the Project forward arrow key.
3. Continue adding and indenting list items until you reach the work package level.
4. Microsoft Project automatically adds the WBS codes, based on the outline structure of each task/activity. However, you can create specific codes by clicking the Project tab, choosing WBS from the menu bar, and clicking Define Code.

With the sensibility required to avoid to-do lists and keep work packages manageable, measurable, and deliverable-oriented, how does a new program manager or new work breakdown structure user gain competence?

Michelle Watkins, a solutions consultant for Smartsheet, has over 20 years’ experience in project management. “Start with templates,” she suggests. “Something with a baseline, and make your adjustments from there.”

Rod Baxter says, “You just keep practicing.” According to Baxter, a good project manager needs training and skill in risk management, communications management, and work breakdown structure. Project managers can gain confidence through mentoring newbies as they work their way through the ranks from such positions as project analyst to associate program manager.

Dr. Bennett echoes this notion that practice is the key to mastering work breakdown structures.

“How does one develop confidence in any new endeavor?” he asks. “There are no magic formulae. But confidence is built through a combination of study, getting close to those who are using the method successfully, watching, asking questions, doing it oneself, soliciting feedback, learning from that feedback, and doing it again.”

Bennett says the best way to learn is probably from finding out where and how the WBS was used to create a good result. This type of information probably isn’t in scholarly publications. “Look for ‘real world’ practitioners who discuss their experience at professional meetings,” he says.

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. 

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.