To view the steps, see http://www.projectserverhelp.com/Lists/Posts/Post.aspx?List=f884b43f-61db-4c4e-94a3-38f21a8efdad&ID=159

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!

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:

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

• Work breakdown structure at Wikipedia

  http://en.wikipedia.org/wiki/Work_breakdown_structure

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).

My nonprofessional definitions are summarized as follows, with examples below:

• Duration – the amount of time it takes to complete a task. Measured in days, from task start to task end. Can also be referred to as calendar time.
• Work – the amount of hours it takes to complete a task. Measured in hours, from task start to task end.
• Effort – the same as work.
• Hours – the same as work.
• Man-days – the same as work, but expressed in days instead of hours.

To illustrate, we will use a simple example: We need to build a wall.

Example 1: Duration

The wall will take one builder 10 working days to build. In Microsoft Project, this would be represented as follows:

• Duration is 10 days
• Work is 80 hours (Assuming the builder works 8 hours a day, that’s 10 x 8 = 80 hours)
• Effort is 80 hours
• Hours is 80 hours
• Man-days is 10 days. Be careful! Man-days is not the same as duration. See the next example.

Example 2: Man-days

The same wall will take two builders 5 working days to build.

• Duration is 5 days
• Work is still 80 hours (2 builders, each working 8 hours a day for 5 days)
• Effort is 80 hours
• Hours is 80 hours
• Man-days is 10 days

Example 3:

We have two builders, but the client will only allow us to work for 4 hours in the mornings. Thereafter, we need to leave the building site. The same wall will take the two builders 10 working days to build.

• Duration is 10 days
• Work is still 80 hours (2 builders, each working 4 hours a day for 10 days)
• Effort is 80 hours
• Hours is 80 hours
• Man-days is 10 days

In Summary:

When team members start using non-standard terminology, make sure that you understand exactly what they mean. When quoting customers on a time and materials basis, work is the only reliable source in the examples above, work remained at 80 hours regardless of how the work was resourced. Wherever possible, I always refer to Duration and Work. These are two “standards” that most other Microsoft Project users will be familiar with. Leave a comment and let me know if you found this useful.