To WBS or not to WBS

To WBS or not to WBS, that is the question

Whether ‘tis nobler in the project to suffer

The slings and arrows of precise task tracking

Or does anyone really care…

First, my apologies to William Shakespeare.

In ‘traditional’ waterfall project management methodology a Work Breakdown Schedule (WBS) can be a valuable tool, it captures relationships between tasks and activities and can speed up work in finding a task in a big project.

But using a WBS is a “Tree in the Forest” sort of thing.  Over the years I’ve run into many project managers that always break every component of the project down into work packages. Creating project plans that are hundreds, and even thousands of lines long. They see the tree, and even the grass,  but may be missing the forest.

Why use a WBS? A good reason is that’s its organization of the project leads to better understanding of the critical path, how work is impacting other work.

But just because you can break an activity down into smaller steps  and work packages, should you?  Here’s a couple of cases where a high level estimate might be good enough:

 The activity is a ‘side task’ running in parallel effort to the major work of the project, with a predictable outcome and a low risk of slip.

Example: Sometime during design and build of a new application, the company needs to purchase and install a new server.  The IT hardware team does this work often (predictable outcome) and usually completes their work in a week (low risk of slip to the overall schedule).  Although we could break out all the steps of purchasing, site setup, testing, etc. into individual work packages.  We could also choose not to breakdown the activity and just list it as “purchase/install servers” on the plan with an overall estimate.

 Repetitive Activities.

Example: A project plan calls for testing the weapons system at many different operating temperatures.  The tests will be the same, just repeated many times.  No need to break out each test on the plan, break out the first and then time-box the same amount of time and resources to complete the remaining tests.

I’m sure there are many other examples; the key is to balance the amount of work breakdown against the likelihood that having more detail will impact the schedule.  Remembering that each WBS item at the lowest level will need to be estimated and tracked.

So before you break out every task in every corner of the project, ask yourself “to WBS or not to WBS?”