You may speak 'Project Management', but you still need a dictionary...

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

Why EVM Fails

Some recommended reading now for anybody attempting to instigate the use of Earned Value in their organisation. Follow the link below to a very candid paper on the pitfalls of poor EV managament and why it is important to get the foundation of processes and culture in place before EV could ever hope to be successful.

http://www.icoste.org/LukasPaper.pdf

Joseph makes a few great points, particular in the latter part of the paper in is 'Top Ten Mistake' section. I've seen all of these at some point in the past and I've seen first and what affect they have on the quality of EVM outputs.

I would also like to add my own 11th 'Top Mistake' which relates to granularity.

Break It Down

Even if you find yourself in the privileged position of having avoided Jospeh's 'Top Ten Mistakes', there is a further, less obvious mistake that can, at best, limit the value of the process and, at worst, mislead those reviewing the project into a false impression of project performance.

Successfully running Earned Value is only worth the effort if it is performed at a sufficient level of granularity. Obviously doing so requires an equal level of granularity in cost collection, which comes with its own cultural and procedural issues. Many companies shy away from more detailed cost collection because it increases the burden on direct bookers and increases the likelihood of misbookings.

But these reservations are minimal when compared to the resulting increase in Project control. The increased burden on bookers will be small providing the organisation has a well established and robust booking system integrated with its ERP software. The potential of reduced booking accuracy is a more serious one though and can only be mitigated via:

- Efficient lines of communication to ensure that project teams are aware of the correct booking numbers;

- A well designed booking process that encourages precision;

- Good shop-floor control by the PM and CAMs;

- and thorough analysis of recorded actuals to spot any errors, both with labour bookings and materials.

Once in place, a more broken-down EVM system will provide far better clarity of the condition of the project and will present Project Managers with greater precision of performance data.

This is important because progress on Work Packages (WPs) with smaller budgets will be open to scrutiny, rather than swallowed up in the figures of a much larger area of the WBS; particularly important where these smaller elements exist on the critical path or are otherwise subject to narrow constraints.