Software Engineering, Project Management, and Effectiveness
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:
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.
I would definately be interestedin more details about your approach, especially with some "real world" data sets using Microsoft Team Foundation Server.
@ 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.