Improving project stakeholders' commitment using earned value management
A project manager uses most of his time reporting the status of the project to the stakeholders. Most of the times these reports do not use any technique, are not common across the organization and, what's worst, they do not contain quantitative data. The result can be harmful to the organization, leading stakeholders to never have a real picture of project status. This paper aims to show how Earned Value Management technique can be easily used in order to report project status (schedule and cost), presenting quantitative data to stakeholders, and how this can lead project managers to increase project stakeholders' commitment to their projects.
The senior manager or the sponsor is always looking for the same information on project reports: “How is the project going? Are we on plan?”. Unfortunately what is seen in the organizartions is that, no matter how formal or informal they are, reports are filled with non-reliable information. Reports like “We are a little bit behind plan, but we can crash this, don't worry.” or “Everything is under control.” are part of the culture of the organization, making it blind enough to call this “project management tracking”. When there is a deep dive in report details, more unreliable data is provided to project stakeholders: “our design phase has taken more effort than planned” or “the integration phase has been showed completed and will take more time to be completed”. In the end, nobody in the organization really knows where the project is, and to where the project goes. Worse than that, this becomes a culture and in the short/mid term the stakeholders tend not to believe in the project reports anymore, asking more and more informal status, leading to a deadlock. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (PMI, 2004) presents, inside Project Integration Management knowledge area and Monitor and Control Project Work process group, the Earned Value Management as one technique to control schedule and cost for the project. This paper intents to show how this technique can easily be introduced in the daily PM activities, adding quantitative data in project reports, increasing their confidence level and finally making them the official source of project status, increasing the “buy-in” for all project stakeholders.
Least, this paper will use Microsoft® Project and Microsoft® Excel to conduct the examples, but any tracking tool can be used to achieve the same results.
Earned Value Management
According to the PMBOK® Guide, the EVM technique measures performance of the project as it moved from project initiation through project closure. Although it is not our intention to teach EVM technique here, it is important to go over some concepts to provide some background for the rest of this study. The PMI Practice Standard for Earned Value Management (PMI, 2005) is a complete handbook to study the EVM technique in details and explore all its potential.
Three concepts are the base for this analysis. In few words they are:
- Earned Value (EV): how much work has been really produced. It can be found as Budgeted Cost of Work Performed (BCWP).
- Planned Value (PV): how much work has been planned to be produced. It can be found as Budgeted Cost of Work Scheduled (BCWS).
- Actual Cost (AC): the actual cost of the work already produced. It can be found as the Actual Cost of Work Performed (ACWP).
The two base variables to be understood are the SPI (Schedule Performance Index) and CPI (Cost Performance Index). The first one, SPI, describes how the project is in terms of schedule and it is calculated by dividing the EV by the PV (translation: how much my project produced when compared against what has been planned). The second one, CPI, describes how much the tasks already completed have cost, and it is calculated by dividing the EV by the AC.
Now, let's see an example to help understanding this theory. The Exhibit below shows a schedule for a typical software development project. Let's assume that the cost here represents the number of hours worked by the engineers in the project (very common on budget-based organizations). To make it even simpler, 1 hour is equal to 1 dollar.
Assuming current date as 4/7, it is noticeable that Requirements and Design phase have been completed, and Code phase is on-going, but it was baselined to finish by 4/10. What are possible reports for this project? Maybe “code is on-going, on track”, “we are a little bit below schedule, but not that much” or a more detailed report would say “we will increase Alex allocation in code phase in order to put this project back on track”. Let's forget a little bit about all those reports and go back to Earned Value Analysis (EVA). For this project there is:
EV = $104.85
$30.00 (100% of the baselined Requirements task)
$60.00 (100% of the baselined Design task)
$14.85 (33% of total $45 baselined for Code task)
$3.8 (19% of total $8 baselined for User Manual task)
PV = ~$143
$30 (Requirements) + $60 (Design) + $8 (User Manual) – these tasks were planned to be completed by current date (4/7)
~$45 (Code phase was almost completed by Friday, 4/7. Actually it ends by next Monday morning)
AC = $119
$32 (value paid to complete the Requirements task)
$55 (value paid to complete the Design task)
$30 (value paid so far on Code Phase)
$02 (value paid so far on User Manual)
Now, with these three values it is easy to calculate the SPI and CPI:
SPI = EV / PV = 105/143 = 0.73%
CPI = EV / AC = 105/119 = 0.88%
This means that this schedule is 27% behind plan and 12% over cost. If there is a need to present this in hours (or $ in our case), the variance itself can be calculated as follows:
SV = EV – PV = 38 hours
CV = EV – AC = 14 hours
This means that the project is 38 hours behind plan, and to recover it there is still a need to add 38 hours in the schedule from now (4/7) until project completion (4/17). A look in the schedule details confirm this by seeing that although Design phase has been completed a little bit ahead of plan, there is a bad picture on the Code phase completion milestone.
On the other hand, this project has cost to the organization 14 hours more than what have been originally agreed upon project baseline (usually project charter signoff). Again, a schedule analysis show that Requirements and Code phase are really over budget.
It is not under the scope of this paper to present project management techniques to get a project back on track (e.g. crashing or resource leveling), but to show that EVM can help identifying and quantifying the issues with a project in terms of schedule and cost. Another important point to notice is that CPI and SPI provides a current view of project performance. For instance, it's possible to notice that the forecast for this project is even worse than the SV and CV presented on this example. If nothing is done, the CV will reach about 50 hours over budget. But this information can be used to predict what would be the project forecast if nothing is done to change the current trend. There are other variables on EVA that quantify this projection, such as Estimation At Completion (EAC) or Estimation To Completion (ETC).
Applying EVM to a project
Although the example above describes EVA as something really simple to understand (and this was the intention), there is a very complex set of calculations to be done and an automated procedure should be used to make this a reality to the project managers in a very practical sense. In this section, this paper will show how this can be done with Microsoft® Project and Microsoft® Excel help.
The most important thing to be done with the project is to set the baseline, after the planning phase has been completed. Two of the three EVM variables are based on the baseline data: PV is the planned value on baselined time, and the EV is also calculated based on what have been planned initially. With the following example this will become clearer to the reader.
After you complete your planning and save your baseline the project WBS will be like Exhibit 1, with the fields Baseline Work, Baseline Start and Baseline Finish populated. At this time, EVM data shall be also set by Microsoft® Project. To make sure everything is going fine, let's check the PV, AC and EV at Earned Value Table: menu View: Option Table: More Tables: Earned Value. The screen shall be like Exhibit 2.
As has been said in the last section, all EVA calculation is based on the monetary value of the project (cost). So, it is mandatory to make sure all the project costs are being set before the baseline is set, so the earned value data seen in Exhibit 2 can be set properly. In this example, the costs are all related to resource usage, and engineer hours usage will be reported to the upper management – this is what they care about in the end. So, Exhibit 3 shows how this is set on Resource Sheet view.
It's necessary to make sure all the actual data is updated, according to the project status received by the stakeholders. It is important to tell Microsoft® Project which is the date of this status. Using the same logic in the example of section 2, the date will be set to 4/7.
Now it is time to calculate the Earned Value data. Using the Analysis toolbar, select the Analyze Timescaled Data in Excel option.
Select the EVA variables discussed on step 2, as shown in Exhibit 6. Selecte also the Baseline Cost that is going to be explained next.
Exhibit 7 is the final output generated by Microsoft® Project, which will be the core input for the analysis on this section.
Applying the formulas, the values for SPI and CPI are:
- SPI = EV / PV = BCWP / BCWS = 110.30/144.80 = 0.76%
- CPI = EV / AC = 110.30/122.80 = 0.90%
The numbers are almost the same as the ones found applying the theory in previous chapter. As Microsoft® Project simulates the real world, with real resource allocations and real calendars, some small differences in the calculation may be found. If desired, the “Resource Usage” view can show details about how these numbers were calculated by the tool.
But the goal here is to have all the procedures automated, to make it feasible to be used in real world projects. Mathematical formulas, like the ones above, don't look good in project reports. Exhibit 8 shows an example of a report that will use the output shown on Exhibit 7 to create the SPI and CPI data.
Basically, this is a copy of the data generated on Total rows of Microsoft® Preport (Exhibit 7) pasted on Microsoft® Excel (rows 37:40 of Exhibit 8.). The CPI, SPI and the charts are updated automatically. The example shown here also included some calculation to predict the forecast of the project costs, based on actual project performance. Of course this will depend on each project and also will depend on the root cause responsible for the SPI and CPI variations continuing along the rest of the project. Furthermore, one can ask why not use Microsoft® Project to export the ETC and EAC data? The answer is very simple: this feature is not supported by Microsoft® Project (at least not until 2003 version).
The conclusion at the end of this section is that going from a basic schedule to an EVM report can be as simple as this. With very common project management tools and few steps, a quantitave report is introduced in your project report.
Some EVA interpretations
Once again, it is very important to the project manager to understand the data created by EVM techinique, and translate it to the project stakeholders. A couple of common situations are:
- SPI and CPI < 1: unfortunatelly this is the most common situation for a project. It is behind schedule and above cost.
- SPI < 1 and CPI > 1: the project is behind plan but it is not over cost. Some examples includes a project started after it was planned to start, or simple a resource could not work on the task as planned (poor resource allocation).
- SPI > 1 and CPI < 1: the project is ahead of plan, but it is over cost. This is not very common in the projects but it can happen. For instance, the sponsor asks to deliver the project ahead of plan and extra resources are added to the project.
- SPI > 1 and CPI > 1: the project is ahead of plan and under cost. The project manager usually starts thinking about a happy hour when this situation is reached.
For most of the cases, understanding the final numbers are just the first step of the analysis. The project manager will very often need to take the original report (Exhibit 7) and go deeper on specific tasks to realy understand which one is the root cause of the final deviations on CPI and SPI.
Adding Control Limits to the project
The CPI and SPI charts on Exhibit 8 have two yellow lines named USL (Upper Specification Limit) and LSL (Lower Specification Limit). It is not under the scope of this paper to go into control limit theory, but it is important to see that with EVM data it is possible to start looking into adding controls to the projects. For instance, the PMO can define that projects with SPI or CPI outside a 10% acceptable variance stripe shall trigger corrective actions to get these variables back on track: project is called out of control.
After a good number of projects have collected these data, a process control analysis can be conducted to analyze what is the capability of the project management process in the organization and define what are the organization's control limits for the projects it conducts. This is an example of merging the Six Sigma methodology with the project management processes. More detailed information about this can be found under (Six Sigma, 2006).
Another good application is to plan the management reserve for the projects. The historical data can tell the organization projects always runs 25% above planned costs (for instance due to a bad estimation process), so the PM can prepare a reserve before closing the project plans and prevent unsatisfying a sponsor or stakeholder later on.
These are some of the roads that are being opened to the PMs, leading them to a high mature project management organization.
Critical Path Analysis
Although the EVA shall be applied and analyzed to all project activities, the main importance shall be given to the activities on the critical path. This may be obvious, and problems on these activities will affect the final project results. For instance, a project may have a SPI less than 1 due to an activity not on critical path, and then the final milestone is not affected. Once again, it is not possible to say that if SPI is less than one the project is dalayed, but rather project activities are delayed.
So, in many case there have been seem a focus on EVA on Critical Path activities only, to reduce the effort on this analysis. Nevertheless this will depend on the project requirements. For instance, resources working on a non-critical path activity may be released to the organization on time, so the PM would care about these activities also. Another good example applies to organizations where the sponsor is very concerned about people motivation, so it would be important to look at the CPI for all the activities to find overtime issues.
Improving stakeholders' commitment with quantitative status reports
At this point two important subjects were discussed:
- What is the EVA and how to generate this data
- How to apply it in the project reports
The next step is to understand the benefits of doing this. One of the greatest benefits is that the speech will be different inside the project environment. Since the very beginning of the project, the SPI, CPI and forecasts shall be presented in a formal reports, available to all stakeholders. The several combinations will have a different meaning inside the project, and the project manager is the ultimate responsible to translate this into something that is tangible to the stakeholders. If the SPI is less than 1, the project manager shall quantify this in number of hours behind plan, which activities are the main responsibles for this delay and what are the action plan to recover these hours and get the activity back on track, what would be one of the project goals (on-time delivery). Most important, the project team shall capture that the project is really behind plan.
On the other hand, if it is impossible to imagine a project without the “informal” reports, they will now be sustained by a set of data available in the “formal” reports. The project manager can not say “We are on track boss, don't worry!” if the SPI is less than 1. Or the software developer will take care when saying to the project manager “Everything is going fine, I have delivered on-time everything I had committed to” when the project manager read a CPI less than 1, understanding that the delivery came as the result of overtime work that the upper management may not agree with.
But one of the most important points to highlight on this analysis is the project culture. The project management team shall work towards the implementation of this culture on all projects, so it is clear to all stakeholders what it is, what are the true benefits and, in the end, the results of this technique applied throughout the project life. This may probably start with a set of trainings and continue with continuous explanations along the projects, for instance, during the project weekly meetings.
Avoid the trap: that's about reporting, not people management
One common mistake that can happen is to give too much importance to this technique in the project. Altough this is a powerful technique strongly suggested to be used in projects, it is more important to understand that, most of the times, people are resposible to lead the project to its success. And the team should know that they are the most important piece in the project. So, if the project manager starts giving to much importance to EVA and to the data given by it, this can affect people motivation and the final consequence to the project can be a disaster. If a project manager listen some feedback like “This is not about numbers only!” or “We are not machines, accurate like numbers with 2 decimal places”, it is strongly recommended that this PM stop and step back on the importance given to this technique.
The intention of this paper was to introduce the earned value analysis to a project. Starting from the basic concepts, how to fit this on the project reports and in the end what are the benefits of doing so.
It is an easy to understand techinique, but hard to apply manually. By using the tools available in the market, the techinique can be easily put in place and, with few steps, the project can be updated to have consistent quantitative data about the project status (in terms of cost and schedule).
Finally, the discussion around the benefits for the entire organization – from the sponsor to stakeholders in all levels – of adding the quantitative data to sustain the reports, remove the informal and frequently inaccurate reporting, and have a very clear picture of the project status. Besides that, it helps to ensure that the organization is moving towards another group of organizations, the ones with mature, modern and competitive project management practices.
PMI (2004) A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition. Newtown Square, PA: Project Management Institute
PMI (2005) Pratice Standard for Earned Value Management Newtown Square, PA: Project Management Institute
iSix Sigma (2006) Six Sigma Quality Resources for Achieving Six Sigma Results Retrieved from www.isixsigma.com\
Motorola University (2006) Free Six Sigma Lessons Retrieved from http://www.motorola.com/content.jsp?globalObjectId=3069-5787
© 2006, Alexandre Novaes Olivieri
Originally published as a part of 2006 PMI Global Congress Proceedings – Santiago, Chile