Hands Off My WBS!
In an integrated Earned Value Management System (EVMS), the contract Work Breakdown Structure (WBS) is the hub upon which all things depend. Some organizations new to Earned Value Management (EVM) have had to learn this fact the hard way after making arbitrary changes to their WBS, in the absence of process protocols. Come reporting time, it quickly becomes clear that portions of the project data have been eviscerated. In this article, we explore the importance of a stable WBS that is under tight change control. Failure to understand the importance of this will inevitably lead to chaos and the worst kind of WBS, namely the Woefully Broken System.
Any integrated business system requires a data key, a unique value that can be traced through all participating tools within the system. This is equally true for an integrated Earned Value Management System and almost without exception; the key value used is a code assigned to an element of the project’s WBS. This WBS code must be present at all times and once the project is baselined, it cannot be changed without rigorous adherence to process. Therefore, good WBS development and maintenance are essential.
First, the WBS should be developed at the earliest possible time and must contain all elements of the work scope for the project. Preferably, the structure should go down to at least the Control Account level, i.e. the point at which the WBS element meets the Organizational Breakdown Structure (OBS), but it can go lower if required.
In the figure above, a typical structure is illustrated. If multiple projects are anticipated, the WBS can start with a root element that represents the organization. The next level down is the project level, then the system it is to build. Below that, the sub-system elements are itemized and then the components that are to be built for the project are listed.
It is this Component level that often is a prime candidate for the Control Account level. Typically, this is the level at which a specialized team manages the work. That means that the manager of that team is often given the role of Control Account Manager (CAM), and is tasked with managing that portion of the budget.
It can be thought of as the summary level for that team. Work is typically broken out further into work packages and below the work packages are the tasks that will be performed to complete them. While the levels and complexity vary widely from project to project, this represents a reasonable example of common WBS practice. It’s wise to keep your Control Accounts at as high a level as possible within the WBS to reduce the burden of variance reporting downstream.
Once development is complete, the WBS must be maintained. The first step is the creation of a WBS Dictionary. This can be a simple spreadsheet that lists all the WBS elements. This typically includes a code column, a description, a budget column to record the planned hours or dollars, a Contract Line Item Number (CLIN) column, Control Account Manager (CAM) column, Organizational Breakdown Structure (OBS) column and a Statement Of Work (SOW) column that has a paragraph from, or reference number to a paragraph in the project’s SOW.
Once the WBS Dictionary is complete, the program manager should authorize it and then it falls under strict change control. The Performance Measurement Baseline (PMB) will be developed from the WBS Dictionary, which was in turn developed from the Statement Of Work.
Changing the WBS
Changes to the WBS should only be made using formal change control management procedures. When changes are made, they must then be executed with the full involvement of the project schedulers, the EVM system specialists, financial system specialists and any other project components that form part of the integrated system. Changes should preferably be in the form of adding elements to the WBS, not removing or renaming existing elements, particularly those that are in progress.
Changes in the WBS have ramifications to all the systems. If an element that was coded as 1.4.6.1 in the prior reporting cycle is changed, for example, to 1.4.7.0, without the support of formal update in all affected systems, the results are catastrophic. The system will treat the changed code as a new code. This severs the subsequent work from the prior history that has thus far accumulated. The EV data is compromised and the mess can be hard to clean up.
One of the least forgiving tools in this scenario is Deltek wInsight. This is not a fault of the tool; it is simply more sensitive to unexpected change because it is designed to report trends based upon history. By changing an in-progress WBS element code, one has effectively changed history and therefore broken wInsight’s linear path for that particular element.
A fundamental rule of Earned Value Management is that history should never be changed. Changing history can result in a sudden lack of trend data. Needless to say, this can quickly sabotage a government certification when the wInsight XML files are corrupted.
In short, if at all possible, don’t change your WBS; and if you must make a change, make sure your system specialists have authorizing paperwork with clear details about the change.