How to create a Work Breakdown Structure (WBS)

How to create a Work Breakdown Structure (WBS)

A well-crafted Work Breakdown Structure can be invaluable on a project. Follow this short step-by-step guide on how to create a basic Work Breakdown Structure for your next project.

I create a WBS as soon as possible, preferably while the sales team is still busy proposing the solution to a client. Using the approach I recommend below, the WBS clearly depicts the deliverables the project will produce, and the activities required to create those deliverables. This benefits everybody from your internal team members, to the customer and other vendors involved on your project. If the teams can visualize the actual deliverables, and how we are going to get there, we are one step closer to project success.

However, any WBS structure will not do. Creating a shopping list of 100’s of activities is just plain stupid. I have done this before and you end up spending all day trying to keep your schedule up-to-date instead of managing the team. A WBS should be kept simple, but have sufficient detail to provide accurate cost and schedule information.

So, how do we do this? Decompose a WBS by starting with your phases, then deliverables, then activities. Add milestones, throw in a splash of colour, and that’s it!

Download
Download this article as an eBook for easy future reference
Download the sample Microsoft Project schedule for a basic WBS

Step 1: Define your phases

Start by defining your project phases. This will most probably be very unique to your specific type of project. If you do not know where to start, use generic project phases such as:

  • Project Initiation
  • Project Planning
  • Project Execution
  • Project Closure

Alternatively, you can use the phases from a specific methodology or project approach. Let us look at an example by assuming that we are working on a software development project using the Microsoft Solutions Framework (MSF) approach. The phases are:

  • Envisioning
  • Planning
  • Developing
  • Stabilizing
  • Deploying

Step 2: Add deliverables

List the specific deliverables that each phase will produce. It is important to keep this limited to tangible deliverables such as documentation and services. The PMBOK® guide defines a deliverable as “Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project”. By adding deliverables, our WBS grows a bit.

  • Envisioning
    • Kick-off Workshop
    • Vision/Scope Document
    • Project Structure Document
    • Risk Assessment Document
  • Planning
  • Developing
  • Stabilizing
  • Deploying

Step 3: Add activities

Next, we add the activities required to produce the deliverables.

  • Envisioning
    • Kick-off Workshop
      • Prepare Workshop Materials
      • Conduct Workshop
  • Vision/Scope Document
    • Interview Stakeholders
    • Create Document
  • Project Structure Document
    • Create Document
  • Risk Assessment Document
    • Conduct Risk Identification Workshop
    • Create Document
    • Planning
    • Developing
    • Stabilizing
    • Deploying

Step 4: Colour Code

I am a bit of stickler for “making things pretty”, but adding a bit of colour to the WBS goes a long way to make large plans simpler to read and easier to navigate. I use the following colours:

  • Phases in Purple
  • Deliverables in Blue
  • Activities in Black (default)
  • Milestones in Green

The result is as follows:

Work Breakdown Structure

Step 5: Sanity Check

Next, make sure we are not mad. Review the WBS with your customer, the team, architects, developers, managers. Are the deliverables correct; is there anything missing; or are there deliverables that can be removed? Check the activities to ensure that they cover the major work required to create each of the deliverables.

In Review

What does this approach give you?

  • A simple breakdown of Phases, Deliverables, and Activities
  • The ability to manage deliverable expectations. With this approach, all project deliverables are explicit stated in a plain and clear manner. There are no assumed or implied deliverables.
  • A sound starting point for the next set WBS activities that cover duration and effort estimation, dependencies and resourcing.

In the next article, we’ll expand this WBS and start our schedule development. Tell me what you think about this how to article, the approach and the sample template. I would love to hear your feedback and comments!

Additional Resources

Looking for more?

Subscribe to Microsoft Project in Practice at http://shaundicker.com/blog for more “how to” guides, tutorials, free eBooks, downloadable templates and schedules on how to use Microsoft Project technologies in your day-to-day running of a project and a Project Management Office (PMO).

Published by

shaundicker

Shaun lives and works in Johannesburg, South Africa, as an experienced PMP certified project manager with over 21 years experience in the Microsoft IT field. Shaun is passionate about project management, enterprise content management, personal productivity, patisserie, fine dining at home, Alfa’s and computer games!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.