Work breakdown structure – HOW?

I have written before about the need for project managers and project team members to have excellent questioning skills.

This aspect comes into its own during the session when I explain the concept of work breakdown structure (WBS). I describe what it is, its importance and how to develop a WBS. Once I have demonstrated with the group how to produce a WBS; it’s activity time.

A feature for project teams we have worked with is the lack of detail in projects. During the activity I usually challenge people to breakdown the activity even more – more detail I cry. I explain that when we have worked with project teams we discover that the plan is often based on too little detail; more is needed.

During the activity groups get stuck; they struggle to create more activities to put onto post it notes. How they ask, can we create more activities?

So, what’s the question to ask?

I introduce them to a key question to ask during the development of a WBS.

HOW is that question.

Let me explain. Let’s imagine you are creating a WBS for a wedding. ‘Purchasing flowers’ is identified as a task. But, it is too high a level of detail; it can be broken down into many ‘sub’ tasks.  The danger is that in simply having purchasing flowers as a stand-alone activity, some of the activities to do this will not be built into the final project plan.

Using the HOW question produces a more detailed list of project activities. When I mention the use of this question there is a flurry of activity with more post it notes written. In this example:

  1. chose colours for flowers
  2. identify who flowers are for (all guests or wedding party only?)
  3. look on line at companies supplying flowers
  4. get recommendations from friends/relatives
  5. check for allergies to any specific flower wearers
  6. create a budget
  7. identify where we want flowers – wedding ceremony, reception etc.
  8. visit wedding fares
  9. visit actual wedding to view flowers ‘on show’

The above list could be endless. The HOW question energises groups, develops more activities and produces a more realistic list of activities needed for the project.

During reviews of this important activity, groups consistently say that the HOW question is essential and often missing from their WBS activity.

Those who come along to our project management training courses recognise that in the past they have not generated sufficient detail in their own projects and the sheer number of activities increases dramatically using this question.

So, HOW good are your questioning skills in developing a WBS?

This entry was posted in project management training and tagged , , , , . Bookmark the permalink.

4 Responses to Work breakdown structure – HOW?

  1. Stephan says:

    I prefer to focus on the WHAT first. In my experience, developing the HOW too early in te process tends to divert from defining scope. I’m from the school that keeps the WBS deliverable-oriented. Defining activities is the next step, and is part of the activity plan. No tasks in my WBS.
    People, certainly in a group while having fun, want to DO things, realise things. So I believe it is easy to understand while they always wish to define activities as soon as possible. But by doing that, the WHAT is not properly defined, with lots of issues later on in the project.

    • Ron Rosenhead says:

      Hi Stephan thanks for your interesting comments.

      In course we run we develop the scope and deliverables before we even talk about WBS. ‘What’ in project management is essential. You may well have come across the term DONE. I often ask what does done look like? It is only after DONE has been described and in some detail – including deliverables that you can start to work on the WBS.

      I agree with you that all WBS’s must be deliverable focussed. If not, what is the purpose of identifying the deliverables?

      Thanks again Stephan

  2. Great points Ron. I use a slightly different approach but it’s very close to the same method you describe.

    A key point when you get down into defining tasks is to make sure everyone knows that this level of detail isn’t necessarily where we will end up tracking cost and schedule. Otherwise, people can get gun shy very quickly and be pre-occupied with thinking about how they will be required to report progress, dreading a micromanaging level of detail.

    Stephan’s comment describes my approach as well, and what I teach. What Stephen called an ‘activity plan’ is what I call a Basis of Estimates (BOE) — this is where we start decomposing deliverables into tasks, and where the power of HOW comes into play. I know there are many other ways to go about it:

    -Some use a Product Breakdown Structure (PBS) for defining deliverables, and then their WBS is task-based
    -Some put everything into a single WBS, with deliverables defined and then decomposed into tasks right on the WBS
    -Some keep deliverables separate and use a list or other format to document them, and the WBS is primarily about task decomposition

    What I’ve found is that a clear delineation between deliverables definition/decomposition first (focus on the WHAT), followed by defining tasks (focus on the HOW) works best. I use a WBS and BOE for these planning activities. The BOE also includes documenting assumptions (good to capture when you are focused on the HOW), sometimes listing the skills required to perform the task (in the form of labor categories, etc.) and finally the effort estimates.

    When this is all done, we can go through the BOE and decide at what level (for each specific WBS branch) will be the best to track actual hours. Personally, if you go down to a level lower than about 2 weeks or so you start losing value because:

    -Time tracking becomes too cumbersome for team members – data becomes less accurate anyway.
    -Team members get disgusted with the low level of tracking. It’s micromanaging!
    -Variance analysis becomes too cumbersome for the project manager – you’ll spend all your time as a bean counter. Better to spend more time communicating with your team and removing obstacles for them.
    -You can’t do anything useful with variance analysis at such a low level anyway. Some project managers think they can, but they can’t. Ask yourself “If we keep track at this level, how will we use the data in our next project planning effort?”

    The best part to me is using Kanban during implementation, without trying to track hours spent on each individual feature. This allows for maximum visibility and ease of managing workflow while being confident you’ve made an excellent effort at thinking through your scope up-front. Because you are tracking at a reasonably high level, your team can respond to changes in the plan as they come. No plan survives contact with the enemy, and if we try to manage work at the smallest level of detail we are shooting ourselves in the foot from the standpoint of effective project management.

    Thanks Ron, great article and discussion!

    Josh Nankivel

    • Ron Rosenhead says:

      Josh, appreciate your time responding to this.

      Both responses; from you and from Stephan remind me of the time when i was working with 2 other consultants discussing this very issue. they had 2 (slightly) different approaches to developing a WBS. We discussed this and came to the conclusion that if we each took a project and then set up 3 teams to do a WBS we would come up with something pretty similar.

      I also remember a blog – rant actually by my good friend Mike Clayton – worth a read as there may well be a few linguistic issues here…

      Thanks again Josh

Leave a Reply

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