In this article, we will take a look at formulas and processes available to project teams using an Earned Value Management System (EVMS).
These formulas operate on the same principle as any such a system, vulnerable to a garbage in – garbage out weakness. This weakness, “GiGo”, is a feature whereby data analytics only provides accurate results when inputs are also accurate and relevant (Rose et al., 2011). In an EVMS, the two main data inputs are original estimate / budget / baseline data, and progress / update / actuals data. We will review these data points, and their resulting analysis that EVMS provides.
Common Earned Value Management Data Points
Budget at Completion – BAC
One of the foundational EVMS data points is the budget at completion. This represents the baseline or total estimate, sometimes referred to the original total planned value. This is a cost-based data point that equals the originally-estimated total cost for the portion of work being assessed. It can be all costs budgeted for an entire project, a work package, contract task, group of tasks, subset of tasks; any grouping you wish to assess. For example, if you want to track the task of painting a railing, you would include:
- the total painter contract budget / estimate ($5,000)
- the total (proportionate) management / overhead (indirects) budget / estimate ($300)
- the cost of any provided materials ($100)
- BAC = $5,400
Oftentimes in large projects, overhead and management (indirect) costs are not included, as it’s rightly assumed that managing the direct costs will control the indirect costs. More in this further on.
Actual Cost – AC
Another fundamental EVMS data point, actual costs, is one data point that at first seems straight forward, but it can have its own complexities during implementation. These complexities are best thought about before your project team gets too far into tracking your project, to avoid the GiGo effect. In essence, actual costs are a measure of what has been spent up to the current reporting date. For example, if you report monthly, the AC would represent what you’ve spent to the end of the previous monthly period. This alludes to two complications when determining AC.
The first of these complications involves these reporting periods. Unlike BAC, AC is defined by a point in time, and is often tied to partially-completed work. This means that the point in time must be well-defined, and the portion of the work partial payments cover are also well-defined. This is because, for example, if actual costs are delayed behind progress reports, you would end up reporting higher cost efficiency than is accurate. Conversely, if your actual costs include advance payments for work as yet to be completed, your cost efficiency would appear lower that is accurate. Therefore, the following guidelines should be followed to maintain accuracy, and to avoid GiGo:
- Align status dates / reporting dates with all period reporting measures in EVMS, including AC. This means that any agreed-upon payments, sometimes referred to as accruals, should match the progress that has been measured / scored. For example, if there is partial progress on a task within the month (and reporting is done monthly), then calculations must be done to align total spent and accrued costs with the progress. Let’s assume that progress for the month includes 4 of 10 roughly equal sections of railing painted, and the fixed price contract for this work has a BAC of $5,000, to be paid upon completion. We have 40% of the work completed, put we are not due to pay for the work until it is completed. However, for EVMS to work properly, we need to recognize 40% of the costs as set aside for competed work to date; we need to accrue it (AC = 40% x $5,000 = $2,000).
There are accounting reasons to do accruals as well (partially-completed work represents a liability until paid for), but we don’t want to contaminate each function (Project EVMS tracking and Corporate Accounting) with requirements of the other; there may be slightly different accrual rules or status dates that Corporate Accounting requires, that if implemented, would interfere in the accuracy of EVMS calculations (GiGo risks again). Perhaps some data and processes can be shared, yet project teams should endeavor to create their own EVMS tracking tools to preserve data accuracy. This isn’t to say project teams can’t share cost and progress data with accounting teams (they should); they just need to maintain control over how that data is used in the project’s EVMS system.
Planned Value – PV
Similar to AC, Planned Value (PV), refers to an item’s costs. When partially completed, it is often referred to more specifically as the Budgeted Cost of Work Performed (BCWP), a point-in-time measure, or Earned Value (EV). Again like AC, PV needs to be aligned with the reporting period in order to assist in determining EV / BCWP. PV is the data point used to determine a task’s (or project / task grouping’s) progress as measured against the total original budget (Budget at Completion – BAC) for that task or task grouping. For example, similar to the railing painting example above for AC, 40% work completion measured against the $5,000 planned contract budget results in a $2,000 PV (scored as EV / BCWP). The obvious question now is of course, how is PV different from AC.
PV is designed to always measure against the original planned budget for a task. However, AC can vary greatly. In the railing painting example above, we used a simple fixed-price contract to simplify the explanation of AC. Yet many contracts have variable costs, change orders, an other such levers that change costs, and benefit from an EVMS system that helps flag the impact of these changes to project teams. For example, let’s assume that the painter notes that they are catching up to the fabricators of the railing and are finding that they are often waiting idly, something the contract did not address. The painter submits a change order for the additional idle hours, which is then accepted by the project team as a reasonable accommodation. This change order represents an additional $400 in agreed-upon payments that must now be added to the AC. Therefore $2,000 of fixed costs plus $400 in change order costs now results in an AC of $2,400 to be reported this period. That said, the PV does not incorporate this $400 in delay charges; rather it is tied to the budget for the work and remains at $2,000.
Earned Value – EV
As seen above, simply put, Earned Value (EV) represents the amount of PV that has been scored as earned, or completed. It’s easiest to think of PV and EV as one and the same concept, with PV referring to the originally-estimated value, and EV referring to the portion of PV that has been scored as completed, or earned to date.
Project Change
Now that we have began to consider variable costs and project change, we can to see how important having a strategy to manage this change in an EVMS can be. Project changes and variable costs by their nature change AC. To what extent they change your project’s BAC or EV / PV data is a matter of some debate. For example, some teams prefer to manage change through a lens of approvals, or in an environment where changes in costs create blame and internal political struggles. Other teams prefer to manage change in their EVMS as a natural feature of projects, something to be expected and managed, not something to be feared and punished. We will view change in the latter manner, and the following is how such an EVMS system of change can operate.
When a change order is approved, those (usually increased) costs are to be accounted for in the schedule and cost plan, as part of the forecasted remaining work. Once the change order work has been completed, its costs will then be added to the AC. If the change order removes cost, then those costs are not added to the AC, but they are scored as earned in the EV / BCWP. This will show in the EVMS as an increase in cost efficiency, which is how removing unneeded scope or finding savings would be expected to show. If the change order adds costs, the AC is increased accordingly, but the EV / BCWP should not include the extras, only the originally-planned costs. This will then have the EVMS output a cost inefficiency, which is the correct usage of the system. This really only needs to be dispositioned by the project team; perhaps a risk item has been quantified as an issue, or some other explanation. There is no need to add approved changes to the EV or BCWPP; adding them to the forecast or schedule plan allows for tracking of approved change, without breaking he EVMS outputs.
As a side note, many project teams are motivated to add approved changes together and “re-baseline” the project, effectively resetting the EV and BCWP to the AC. This resets all EVMS indicators, and in many minds, shows that the sunk costs are now approved and accepted. However, this is not how EVMS is designed to work. Project teams may instead consider maintaining an approved forecast, as well as a pending or working forecast instead, to help illustrate the current status of the project budget. The EV and BCWP, however, work best with as much historical / statistical data included in them as possible, especially as they are applied to EVMS metrics and formulas.
Cost Performance Indicator – CPI
The main cost performance indicator in an EVMS is referred to as CPI, and it is calculated as the EV divided by the AC, at a specified point in time. For example, a $2,000 EV having cost $2,400 in AC to complete would result in a CPI of 2000 / 2400, or 0.83. Since the CPI is lower than 1, you can easily spot a few characteristics about this package of work. First, you know that something has cost more than initially planned; perhaps scope was added via change order, or perhaps there has been some risk item realized as an issue, or perhaps both. Second, you also get some sense as to the impact of the variance. At an 83% cost efficiency, you know this work has been completed to date with a near 20% efficiency loss compared to the original plan. The next steps here are important; EVMS is a tool, of which CPI is a sub-set, and it is only useful if used as part of a management effort. In other words, having this CPI is only useful if it triggers actions. Perhaps the project team requires written dispositions for CPI changes of more than 5%. Teams should also provide an assessment as to the impact of this CPI on the final forecast; is this 0.83 likely to continue? Is the issue over with, and a slightly better CPI is predicted in the forecast at completion? These assessments should be performed whenever a metric like CPI is updated. Simply reporting the CPI may spark conversation at meetings, but teams should have assessments and dispositions ready. This way the EVMS will promote management of the work and associated issues, not management of the metric itself.
Concluding Remarks
In the next article in this series, we will continue to look at EVMS tools and metrics, starting to look at perhaps the more controversial SPI, or Schedule Performance Index. However, we already have a good appreciation for different foundational features of an EVMS. Actual Costs need to be tied to work that has been completed, and this requires rigid accrual and period reporting processes in order to avoid data can easily contaminate EVMS metrics. The Planned Value for tasks needs to be easily segmented with rules that allow for Earned Value to be scored accurately. Finally, these values need to be considered properly when processing the inevitable changes a project goes through, to avoid employing and EVMS suffering from “GiGo”, that does not assist in managing work, instead having teams manage metrics. In a dashboard culture, modern project teams may need to spend time setting these expectations early with their reporting audiences, and having a good dispositioning and assessment process should help bring focus back to what’s important; solving problems to achieve the project goals.
References:
Rose, L.T. and Fischer, K.W., 2011. Garbage in, garbage out: Having useful data is everything. Measurement: Interdisciplinary Research & Perspective, 9(4), pp.222-226.