Breaking it down and getting it done

Somewhere in my many posts related to this must be the observation that the business of getting on an delivering anything has, thus far, been conspicuously absent. 


First, don't go looking too hard for activities related to delivery in the 'achieving quality' model. That's an abstraction focussed around meeting customer requirements. But then again - don't lose sight of that while getting on with the business of delivery.

Next, don't necessarily follow the steps above verbatim. You're almost certainly going to have to maintain a flexible footing, responding to the particular business needs you're facing. I'll offer this isn't a bad starting point however.



[If you want more detail on product or work breakdown structures see any number of other sources elsewhere. I can't add anything to the existing breadth of coverage.]


Step one above isn't something I'm going to dwell on too much at this point. Somewhere in the project mandate, brief, charter, PID, business case you'd better make sure there's a crystal clear vision of what the customer wants. If not, you'll need to lift whichever drains you have to in order to get that unequivocal vision of what is to be produced. 


I can think of one or two exceptions, but mostly the (PBS) should pretty much always come before the work breakdown structure (WBS). Define what you're going to do, then how you're going to do it. Scope definition can be a (very) big job in itself and if this is a self-contained stage in its own right, then you might have a WBS for which the output is a clear definition of scope (the PBS).


Be it PBS, WBS or any other type of work breakdown structure, the objective is 'compartmentalisation'.


The project plan is easily derived from the WBS. In fact, if you're using software to do your project planning (and you almost certainly are) then if you have the WBS, the project plan will almost write itself. The only substantive information you'll need to add are dependencies and lags (where applicable).


If you adopt this approach, i.e.WBS then the project plan, I'm convinced you'll rarely deviate. It has a number of advantages around scope definition, change control and taking some of the effort for the creation of the project plan away from the project planner. Conversely, I'm not convinced you can derive a complete WBS from the project plan, and developing the two in tandem is best avoided.


Finally, once you've got your project plan, you should be at the point where you can generate your resource plan. And, in fact, your project planning software will almost certainly do this for you.


There's quite a bit more ground to cover on this, specifically relating to 'progressive elaboration' to the appropriate level of detail. This will be the subject of future posts and will deal specifically with the WBS, the WBS dictionary, product descriptions and the generation of specific work packages. They'll be plenty of templates to get you started and save you time too.