Jaa

Quick Tips on Work Breakdown Structures

  • Artikkeli

I’m a fan of Work Breakdown Structures (WBS) for project success.  For me, they’ve been the closest thing to a “Silver Bullet” when it comes to project management.

Early in the project, I like to co-create the Work Breakdown Structure for the overall project with the team, so everybody knows the landscape, has the balcony view, and can contribute their thinking to shape the path forward.

In my experience, work breakdown structures are a lost art.  The basic guidance I think is:

  • Focus on outcomes over activities
  • Have multiple views – be able to view by function or focus
  • Have cuttable scope, and know the impact (dependencies)
  • If you haven’t been down the road before, sanity check your Work Breakdown Structure with someone who’s “been there, done that.”  There’s no point in going to SKull Island from scratch, if somebody can share their insight and stories from the trenches.

The real point behind a great work breakdown structure is to have clarity of the work, share and show the scope, know the key risks, and estimate time.  When you can do this with skill, you can reduce your risks, see the 80/20 value, and have the right people working on the right things, at the right time, the right way.  How’s that for having know-how on your side?

Personally, I like to use a WBS at the project level, but then use user stories at the product level.

Comments

  • Anonymous
    June 21, 2011
    I would definately be interestedin more details about your approach, especially with some "real world" data sets using Microsoft Team Foundation Server.

  • Anonymous
    June 22, 2011
    @ David -- Unfortunately, I don't have much of this on the Web. I should write a brief guide someday, given how important clarity of work is.  You can usually trace success or failure of a project, right to the clarity of work. Here are a couple of examples that might help:

  • <a href="guidanceexplorer.codeplex.com/wikipage ">Guidance Explorer User Stories</a>

  • <a href="guidanceexplorer.codeplex.com/wikipage Stories for Cloud</a> On a good note, the book, "Secrets to Mastering the WBS in Real-World Projects" does a great job on this topic, and so far, it's been the only book I've found that actually matches how I do WBS, and how I think of project cycles vs. product cycles, etc.