There has been a lot written over the years concerning the humble Work Breakdown Structure (WBS) and its value at the centre of any planning/pricing operations. Producing an agreed hierarchy of the project work allows for greater confidence in a full coverage of the project deliverables and the Statement of Work (SoW). It also forms the basis of the project reporting and project management structure by allowing for the definition of control accounts. Finally, the WBS facilitates the assignment of responsible persons, thereby ensuring that every every activity, and indeed every high level rollup, has an owner and nothing gets neglected.
Many people differ over the methodology behind the WBS, some opt for a deliverables based approach, some for a Product Breakdown Structure type hierarchy, while others prefer a discipline based breakdown (Systems Engineering, Hardware Engineering etc). More often than not, though, it is a combination of the above, usually defined by the nature of the project, and indeed that of the organisation. For this reason, I would never recommend being too overly prescriptive with WBS best practice; a simple WBS template with some accompanying guidance is often sufficient.
What is far more important, and what often gets neglected when forming a WBS, is the definition and supprting info behind each work package.
Far too often when I ask to see a project's WBS I am presented with the usual WBS numbering breakdown with a list of work package titles. If I'm lucky, there is an Organisation Breakdown Structure with a Responsibility Assignment Matrix (RAM) showing the responsible parties for each area of the work. But a WBS does not end there. A Work Breakdown Structure, without a WBS dictionary, is incomplete.
WBS Dictionary
In essence a WBS Dictionary is a core planning document wich documents all the relevant information that is required to plan, implement and monitor each work package. This should include, but not necessarily be limited to:
Booking Codes
Scheduled Start and Finish Dates ("Period of Performance")
Responsible Person(s) (Output from RAM)
Resource Requirements
Budget
Basis of Estimate
Requirements/SoW mapping
Task objectives
Definition of work (what work is, and is not, included)
Key external dependencies (techincal info, supplier deliveries, customer furnished equipment)
Quality Control information
The WBS should be at the heart of any planning operation, at all stages in a project's lifecycle. During a proposal/bid process, the WBS Dictionary will likely be developed at a higher level (due to the relative lack of definition at this stage), but is no less crucial for it. The dictionary gives confidence that all elements of work have been included in the proposal and supports all estimates by documenting the assumptions made within the basis of estimate.
Once work commences and the usual project analysis systems are put in place, the dictionary is an invaluable tool to support this. Taking schedule status and calculating/assessing earned value is made much easier if 'task completion' is well defined and individual work package budgets are available.
The WBS dictionary is an essential element of a Project Management Plan, so don't leave home without one!
..unless it needs to be protectively marked, in which case you should probably keep it locked in a draw or something, you know the drill...
PM SHED
