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.