Basics of the Work Breakdown Structure (WBS)

I have a great fondness for the work breakdown structure (WBS). It was one of the first tools I used when moving into IT to help me gain an understanding of the work we needed to address to complete our project. If you don’t already use this tool, I’ll introduce you to the WBS and its benefits.

Using the WBS can help ensure that you are addressing all components of the project. The act of breaking down the work into smaller components, and then getting more detail about each of these components, helps you and the team work through the specifics needed.

The WBS is built early in the project and will serve as the basis of your schedule. It is important to get input and buy-in from team members via this document. You won’t create it alone. You can build as much as possible on your own, but then consult with the team for additional information or changes.

Getting Started
One of the easiest ways to build your WBS is to start with a template based on the project scope. If others in your organization have done this type of project before, use what they’ve already created as a starting point. If this does not exist – for example: you’re working for a start-up, no existing templates, you can’t reach out to friends to give you one – then begin by listing the high-level components in your scope and break it down from there. For example, if you are working on a software project, you already know many of the components involved: gathering requirements, writing code, testing, bug fixing, any go/no-go approvals needed, move to production, and transition to support/maintenance. There can be other components as well.

Building it Out
Take your high-level draft (or as detailed as you’ve been able to make it), and use it as a basis for conversations with different areas regarding what might be missing. Ask questions:
– Do we need new hardware?
– Are there security concerns?
– Are we using a third-party vendor?
– What’s missing?

Break the large components down to smaller pieces. Use these to get details on how long each activity will take, who is responsible, and dependencies between activities. Consider lead time needed also. For example, in my experience contract execution can take a bit of lead time before third-party work can begin.

Early in my career, I worked on an infrastructure project involving technologies with which I was unfamiliar. There was no previous documentation. I created a list of high level tasks, and in order to get more detail about it – to break down the work – I asked questions like “in order to complete this block of work, what tasks need to happen?” The team members were able to walk me through a breakdown and we created a clear WBS.

Simple Example
I’m going to use a very basic example of planning a party. Most people are familiar with this activity, so it will serve as a good illustration.
You know the following items need to be addressed:
• Infrastructure (location, seating, etc.)
• Food
• Music
• Guests
• Decorations

I break the big components down to smaller ones:

  • Infrastructure
    ◦ Location
    – determine location
    – secure date
    ◦ rent tables and seating (if not provided)
  • Food
    ◦ interview caterers
    ◦ select caterer – sign contract
    ◦ solidify menu
    ◦ secure tablecloths / linens
    ◦ serving dishes/utensils (if not provided by caterer)


There are many tools that can be used for creating the WBS/schedule. I know some simply use an Excel spreadsheet, while Microsoft project and other scheduling-specific tools are very popular.  When choosing a scheduling tool, consider if you have remote teams who will also need to have access to the schedule. For this example I’ll show you what it would look like in Excel:

Screen Shot 2016-02-11 at 6.03.28 AM


8/80 Rule: A common guiding principle is that no task should be less than 8 hours or more than 80 hours. If a task takes more than 80 hours, it should be broken down further.

Creating the Schedule
For each of the WBS items, you need to determine who is responsible for each, how long it will take, and any dependencies – which needs to come first before another can happen.  It is important to get this information from the individuals performing the work. Get time estimates on each task from the person doing the work. This serves several points:
• You get more accurate time estimates
• You get buy-in from the person doing the work

Once you build out your WBS and turn it into a schedule – with durations, dates, dependencies, task owners – use this as an opportunity to ensure that nothing has been missed. If you don’t “own” the resources, then the resource owners can clearly see where their resources are allocated, and when.

During your kickoff, you can use the schedule developed from the WBS to ensure that everyone is clear on what has been decided.


There are multiple benefits to starting with the WBS. In addition to those mentioned above, it can even help in creating the associated project budget. You can easily identify costs associated with each of the tasks and build your budget from this.

You can also see via dependencies where risks lie if any work falls behind. In the party example, if I fail to create my guest list, then the “mailing invitations” task is impacted. If you have a dependency between setting up a test server and user acceptance testing (UAT), then if the test server is not ready in time, UAT is impacted.

If you are doing an implementation that has components you are not familiar with, the WBS is a great tool to work from to gain a better understanding. Even if you are familiar with the work, it allows you to ensure that you’ve not missed anything and gain buy-in from the team.

Leave a Reply