Project Management Monitoring and Controlling Tools & Techniques

Monitoring and Controlling a project is the process or activities whereby the project manager tracks, reviews and revises the project activities in order to ensure the project creates the deliverables in accordance with the project objectives. Because of the unique and temporary nature of projects, they require active control. Unlike a process where the same set of activities have been performed repeatedly so that habits and expectations are stable, a project is inherently unstable. The activities are unique to the project or the sequence of activities and resources are only temporarily assigned and associated with the project and are redeployed when the project completes. Habits and patterns are not established before everything changes.

The primary results of the Monitoring and Controlling processes are the project performance reports and implementing project changes. The focus for project management is the analysis of project performance to determine whether a change is needed in the plan for the remaining project activities to achieve the project goals. In my experience, almost every project will require a change to the plan at some point in time. Traditional projects are the most stable projects because the requirements and the activities are clear and well understood. Adaptive and Extreme projects are the least stable. They require very close control and will require numerous changes - if for no other reason the project manager will need to refine the activities of later phases based upon the results of early activities.

Tools and techniques that are used by project managers to conduct the Monitoring and Controlling of a project fall into one of four general categories. The first is the collection of project performance information. Techniques supporting this category are Pulse Meetings, Variance Reports, and Program Reviews. The second category is the analysis of the project performance to determine whether a project change is needed. Techniques that are used in this category are Technical Reviews, Project Forecasting and Problem Solving. The third category is reporting on project performance. Techniques that support this activity include the use of a Project Management Information System, Management Reviews, and Dashboards. The final category is the management of project change. The technique I commonly use in this category is the maintenance of a Change Management Log. There are two areas of project management tools and techniques that closely support the Monitoring and Controlling process but are also used more broadly throughout the project lifecycle. These are important enough to justify their own page.

Project Communication Tools and Techniques

Earned Value Analysis

Pulse Meetings

Pulse meetings are short team status meetings where the project management team is able to gather project performance information about the activities that are underway. These meetings should occur frequently and can either be face-to-face or virtual. Normally they are only a few minutes in duration. During the meeting, the beginning and completion of project activities is reported. In addition, the status of any activities that are underway is communicated to the rest of the project management team. Issues on any of the ongoing activities are identified, however, the issue resolution occurs at a separate meeting with the appropriate individuals present. The issue resolution meeting may immediately follow the Pulse meeting, but it is clearly a separate meeting and those project team members who are not needed for issue resolution do not need to attend. The frequency of the Pulse meeting is determined based upon the status of the project. When in an Extreme mode, the Pulse meeting may be happening several times a day. Projects that are running smoothly may only need to have a Pulse meeting once a week.

Variance Reports

Variance reports are formal reports generated by the PMIS, by the Earned Value Management System, one of the other business management systems - such as the quality control system, or by a project supplier. Variance reports compare what has actually happened on a project against what was expected to have happened on the project. A variance report typically indicates both the absolute value of the difference and a percentage representation of the difference.

The actual performance achieved on a project activity (such as cost or duration) seldom precisely matches the estimated performance set at the time of project planning. The page on Estimating explains why project estimates are seldom precisely accurate. However, since the estimates often aren't accurate, it is imperative for the project management team to identify the variances in order to know what is actually happening on the project. The variances can uncover both positive and negative project risk.

Project variance reports often are expressed with two references. The first reference is what was supposed to have happened since the last reporting cycle. This is often called the "Current Period" variance. It is an indication of how well the project resources were able to conduct project activities in accordance with the project plan in the recent past. The second reference is what was supposed to have been done on the project since it started. This is often called the "Cumulative" variance. It is an indication of how well the project resources have been able to conduct project activities throughout the project lifecycle. The cumulative variance will have embedded in it any previous variances - either positive or negative. The current period variance provides a clear representation of what is happening right now on the project. The cumulative variance eliminates the effects of any short term conditions, either good or bad, that effected the project during the most recent reporting period. Both variances provide useful information.

Program Reviews

Program Reviews are meetings with the project team members and sub-project leaders that review the current status of the program as compared to the original program plan. These are most often used on Full-scale and Complex projects. Unlike the Pulse Meetings which focus on day-to-day activities, the Program Reviews focus on the big picture and emphasize the integration between activities and between sub-projects encompassed within the program. The question being asked is whether the program activities and the sub-projects are likely to interfere with each other. In addition, when I have a supplier who is a major contributor on the program and is performing customized work on this program, I will conduct Program Reviews with the supplier for their portion of the program. Program Reviews are sometimes combined with Management Reviews. I do not recommend this approach. The danger with this approach is that key stakeholders and managers may intimidate some project team members from providing a frank and honest appraisal of the status of program work.

Technical Reviews

Technical Reviews are formal meetings conducted with subject matter experts who are not members of the proejct team. These are in-depth reviews focused upon a technical aspect of the project. Examples would be Desgin Reviews, Code Reviews, Security Reviews, or Production Readiness Reviews. The reviewers should perform an in-depth analysis of the project deliverables and activities to determine whether the project work has been accomplished completely and correctly. These reviews will normally generate a list of actions that must be completed. These actions may require additional testing or analysis. In some cases it may even require redesigns of systems, software, processes or products. The results of these reveiws are normally reported to senior management at the next Management Review. In many cases, the technical review must be completed before a project can proceed to a toll-gate meeting. When the Technical Review is linked to a toll-gate meeting, the action items do not need to be completed prior to the toll-gate. However, any open action item is listed on the risk register and the plan for resolving that action item is included in the project plan for the next phase.

Project Forecasting

Project Forecasting consists of taking the project status information and extrapolating the current project performance to the end of the project. Forecasts can be made with respect to project duration, overall project cost, performance/quality level of project deliverables, or any combination of these. A key element in forecasting is to review the risk events that occurred and the remaining risk triggers. A deeper discussion of this is found on the Project Risk Management page. A caution when doing forecasting, ensure you have adequate information to realistically forecast performance. My personal rule of thumb is that I wait until an activity, phase, or deliverable is at least 25% complete before I try to forecast. Prior to that point I stick with the original estimate, modified by any appropriate risk mitigation activities that have occurred.

When forecasting project duration, the key is to understand the schedule performance and schedule risk of the activities on the critical path. Those activities will be the ones that drive the project completion date. On a resource constrained project, or a project with unpredictable resource availability, this can be very difficult because the lack of resources causes the critical path to vary. I have not found a good robust tool for forecasting schedule in this condition. It generally comes down to expert judgment and gut feel. When it is vital for the project to complete by a certain date, I often will convert my schedule tracking to a countdown mode where everything is measured in terms of how many days before project completion. Also, I will Pulse the project more frequently in order to quickly assess when I believe we are falling behind. If that sounds like micro-management it is because that is micro-management.

When forecasting total project cost, I prefer to use the forecasting methods that are embedded in the Earned Value Management system. Unfortunately, many organizations do not have the financial systems in place that enable earned value management. When that is the case, I am forced to rely on trend forecasting - which is sometimes called "straight-line" forecasting. Trend forecasting takes the current project spending and extrapolates that rate of spending until the end of the project. This provides a rough forecast, but it does not take into account the effect that different activities may require resources that spend at different levels. The resources that perform the remaining activities may be higher or lower cost than the preceding resources. Also, it does not take into account that the project may be ahead or behind schedule. If the project is ahead of schedule, the spending done to achieve that condition inflates the extrapolated value of the project final cost. If the project is behind schedule, the lack of spending creates an extrapolated value of total project cost that is too low.

When forecasting the performance or quality of project deliverables, I rely heavily on prototypes and preliminary analysis. When the project does not have these, the risk that the project will not achieve the desired performance or quality established at the time of project planning is higher. If performance is the most important attribute of the project deliverables, then the risk of missing the forecast project duration or cost is much higher. The principle involved is the "Rule of Ten's." According to this principle, the cost to correct a technical issue goes up by a factor of 10 as the project moves from one phase to the next. Therefore it is imperative that performance issues be identified as early as possible.

Problem Solving 

Problem Solving is a very broad topic. There are dozens of approaches to problem solving. My rule of thumb with respect to this technique is that if you have a process that works for you, use it! I recommend you have an agreement with your project core team members or key project stakeholder concerning the problem solving process that will be used. Will it be team-based or individually driven? Will you use a process that relies on data from past projects or only on data from this project? Once a root cause is determined, how will recovery actions be identified and approved? As I said, there are many problem solving methods and their answer for these questions and others is different. From my standpoint, the most important point is that you have a process to address issues, rather than jumping to conclusions or worse yet, ignoring the problem until it is a crisis.

If you don't already have a problem solving process, may I suggest this one that I refer to as CIV2:

1. Clarify: Clarify the problem. In which part of the project did it occur? Who was involved? When did it happen?

2. Investigate: Investigate the details about what happened. Gather data from both the project activity and the surrounding environment. Determine the root cause(s) of the problem.

3. EValuate: Evaluate the options to address the problem. Consider the impact on the project objectives that each potential solution would likely have. What new risks are associated with each potential solution.

4. Choose: Choose among the viable solution/recovery paths. If necessary, coordinate the decision with key stakeholders. This must be done whenever the solution will impact a boundary condition of the project.

5. Implement: Implement the selected solution/recovery path. Modify the project plan with respect to any changes in scope, resources, or scheduled dates of any activities. Update the risk register.

6. Validate: Validate that the solution/recovery path is achieving the desired results.

Project Management Information System

The Project Management Information System (PMIS) was discussed in detail on the Executing Tools and Techniques page. The PMIS is the set of communicating methods used by the project team to share plans and results of project activities. The PMIS can either be a physical system or an electronic system. Either way, the PMIS is used as the clearing house of information on the project including; project plans, project status, project risks, project changes, project meetings, and any other information that project management team believes is relevant to the project team.

Management Reviews

Project Management Reviews are formal documented meetings with the project team and key stakeholders that review the current status of the project as compared to the original project plan. Unlike the Pulse Meetings and Program Reviews which are data gathering meetings that focus on understanding the current status of the project, the Management Reviews are with key stakeholders with the emphasis being on whether the project performance is adequate for the project to deliver on the overall project objectives. Often if the project has encountered issues, such as resource constraints or scope creep, the stakeholders conducting the review are able to provide assistance to the project team to overcome these issues.

The format for these reviews is usually set by the stakeholders and addresses the topics that are most important to them. The review may be a formal stand-up meeting, it may be an informal discussion setting, a written report, or an update to an electronic dashboard. Regardless of the method used, these are formal status reporting meetings and need to be treated as such. The project manager should keep an Action Item list or Stakeholder Issue log for any questions that arise in these reviews. Also minutes from these meetings should be maintained as part of the project records.

Project Dashboards

Dashboards have proliferated as more organizations start to manage projects within the context of a portfolio of projects. A dashboard is a great method for capturing a snapshot of a project and presenting that to stakeholders. Dashboards contain a small subset of project status information that is used as indicators of whether the entire project is on track. The dashboard information is used to make decisions concerning changes to projects or to the project portfoliio.

Within a project team, Dashboards were used by project managers to focus the project team on the few key items that would drive project performance. Therefore the current critical path activity is tracked for schedule status, the current activity with the most uncertainty in resource requirements is tracked for cost status, and the most challenging activities are tracked for project performance/quality. This is an excellent use of dashboards, especially when working with a virtual project team.

As more organizations decided to manage their projects as a portfolio of projects, they have recognized the need to have a means of measuring the projects in the portfolio both against each other and with respect to their objectives. The dashboard offers that mechanism as each of the projects report on key metrics that are used by the senior management or Project Management Office to check the status of the projects. Often the dashboard measures the status through the "Red light - Green light" method. This type of scoring uses colors to indicate project status on the key measures. A "Green light" indicates that everything on the project is going according to plan. A "Yellow light" indicates that there are some problems, but the project team is working the situation and should be able to contain the problem. A "Red light" indicates that the problem is so severe, the project team cannot resolve the problem and achieve the project objectives without help from the stakeholders. The senior management team and PMO use the Dashboard to make resource allocation decisions and to call special Project Management Reviews.

Change Management Log

This tool is very straight-forward. The need for it increases as the project complexity increases. I can't imagine running a Complex project without one, but I have never used one on a Simple project. The necessity on a Complex project is because these projects are managed as a set of Focused and Full-scale sub-projects. The boundaries between these sub-projects will inevitably need to change as projects progress. Sometimes the changes are due to shifting milestones. Sometimes the changes are the result of activity deliverables that are passed between the projects. In any case, the changes in one sub-project cascades into changes in another sub-project. The Change Management Log tracks the implementation of the change across the sub-projects. It can also track the implementation of the change within a project, especially if the project activities are conducted in multiple locations or if there are multiple phases underway at one time. Using the Change Management Log is similar to using an action item list. Each item is tracked to ensure it has been completed.

Earned Value Analysis

The fundamnetal characteristics of all business financial transactions are the amount of the transaction and the date of the transaction. These two components are equally important in financial planning and tracking systems. Traditional financial planning and tracking systems are not compatible with the project environment.

Traditional financial planning and tracking tools do not fit the project context. For instance, the traditional financial planning tools are tied to annual budgeting cycles not project schedules. Also, traditional financial planning tools assume the business will be in the mode of continuous operation so if activity slows in one area, the resources will be shifted to another and the expenditures will stay constant. This levels out the resource requirements and eliminates spikes and valleys in resource needs. However, projects often don't operate in that fashion. Projects activities are planned with start and stop dates and resources are assigned and removed from the project plan throughout the project life-cycle. Therefore some of the major assumptions on which financial planning tools are based are invalid in the project planning environment.

Further, traditional financial accounting systems make some assumptions when tracking costs that are not valid in the project control environment. For instance, the tracking cycle used in financial systems is based upon calendar events such as end of month, end of quarter, or end of year because these are major reporting points to taxing authorities and investors. However, the significant project reporting points are the project milestones; which seldom precisely align with finanical calendar dates. An additional assumption in the financial systems is that the business is on-schedule - again because of the financial planning calendar it is impossible for the business to get behind schedule. There is no such thing as stretching December out to have 37 or 38 days. The financial control system assumes the project is always on schedule, so any over-spending or under-spending during a time period is a true over-run or under-run on the project. However, a project is seldom precisely on schedule, and over-spending in one month may be the result of activities being delayed or accelerated and do not necessarily indicate the final project spending will be over-run.

The Earned Value Analysis (EVA) technique takes into consideration the project context for the planned and actual expenditures and integrates the project scope, schedule, and resource characteristics into a comprehensive set of measurements. This page will outline the use of Earned Value Analysis by addressing Financial Databases for EVA, Earned Value Definitions, Establishing Earned Value Budgets, Determining Earned Value, Variance Analysis, and Forecasting.

The Earned Value technique allows for the temporary and intermittent nature of project work by scheduling the expenditures based upon the project plan, including the spikes and valleys in resources requirements. Further, Earned Value tracks how much money has been spent on the project in relation to how much project work has been accomplished. This takes into consideration all that has happened on the project such as schedule delays or acceleration. The variances that have occurred can then be separated into those due to timing, either ahead or behind schedule; and those due to mis-estimating the work; true under-runs or over-runs. Finally, the indices and variances generated by the Earned Value technique will aid the project management team in forecasting the financial conditions at project completion.

Financial Databases for EVA

The EVA techniques manipulate information gleaned from three essentially independent sources of financial data. Each of these are a cost baseline for the project. Each looks at the project from a different perspective.

The planned project expenditures (Planned Value) from project start until the present time. This is established at the time the project was initially planned and represents the original intent of the project team. It is developed by summing up all of the project task estimates and time-phasing them based upon the project schedule.

The actual project expenditures (Actual Cost) as of the present time. This is collected by the business financial cost accounting systems. These are all the costs associated with the work that has been completed on the project up through the present instant in time.

The actual project progress (Earned Value) which is the originally planned expenditures for the work that has been accomplished up to this time. This is determined by the tasks that are completed or the progress made on the tasks that are underway. The key to this measurement is that the values for each task are based upon the originally estimated values for the task. Each task is assigned a "value" that is embodied in the original task estimate. When the task is completed, the estimated value represents the value earned by completing the work on the project task - regardless of how much that work actually cost.

Earned Value Definitions

EVA is known for its acronyms. This table shows the acronym, using both the old naming convention and the new naming convention. Each of the acronyms is defined in more detail below.

Planned Value (PV) is developed by first determining all of the work, or tasks, that must be accomplished for a successful project result. The work within each of the tasks, whether done internally or outsourced, is estimated. That estimate is converted into a monetary value which represents the dollar portion of "planned value" of the task, essentially saying that the task has that worth to the business. This value is then scheduled to occur based upon when the task is scheduled to occur within the project plan. Once the amount and timing is established, the PV for the task or activity is set. It can only be changed by implementing a project change.

Actual Cost (AC) is the number that finance often is most concerned about because this represents the actual cash that the business has had to expend on the project. The AC is determined based upon the accounting system's method for cost accumulation. Where possible, it is most helpful to collect the costs based upon a project charge number or account number that is associated with the costs. This number may change every day based upon whether project work was conducted upon that day.

The Earned Value (EV) comes from an assessment by the project management team as to the amount of progress they have made on each task in the project. Often this is difficult to measure precisely and is based upon a judgment call by appropriate individuals within the project. Tasks that are completed have earned the entire value for that task. Tasks that have not been started have not earned any value for that task. Tasks that are partially complete may have earned some value for the work that has been done. The total amount of value available for a task to earn is the value assigned to that task at the time of project planning--in other words, the Planned Value for that task. It is easy to determine EV for tasks that have been completed (EV is the task PV) and for tasks that have not started (EV is zero). The difficulty comes when estimating the EV for a task that is underway. Suffice it to say, most organizations have set some specific ground rules in this area to ensure the EV is not under-stated or over-stated. Methods for determining EV are discussed below.

The remaining acronyms will be explained in more detail as variances and forecasting are discussed later on this page.

Establishing Earned Value Budgets

EVA is based upon task or activity planning data and therefore requires that a relatively rigorous planning approach is used, often using the bottom-up estimating rather than top-down. The project PV at any point in time is determined by summing the task-level budgets for the time period in question. Accuracy in the task level budgets is required both in the amount of effort estimated for the task but also in the timing of when those efforts will be expended. The key here is that we want to estimate the project task timing in the same way that the financial system will record the AC for the task. In most businesses, the personnel costs are collected and analyzed either weekly or biweekly because of the need to run payroll. Therefore I recommend that the in-house labor in a task should be spread evenly during the task duration, which is called "level-loading," while tasks that have external expenses often are recorded in a lump sum based upon when the supplier submits an invoice. For instance, an invoice received from a testing service would come in as a charge on one day although the testing may have occurred over a period of several months. In those cases it is often better to "event-load" based upon the expected timing of the receipt of the invoice. It is even possible to use a combination of timing approaches when estimating the PV for a task.

Selecting the appropriate timing is important so as not to create confusion later when we determine variances. A variance due to planning the timing of a task expense differently than the time when the expenses actually occurs, even though the amount is accurate, still generates the need for a variance report. Creating a task-level budget that accurately reflects the timing of expenses will reduce the need for a variance report for timing reasons. Variance reports will focus on true under-runs or over-runs.

Determining the Earned Value

Determining the EV for a partially completed task is at the heart of EVA. Therefore it is important that the EV be as accurate as possible. However, EV is a judgment call while a task is underway. If the project management team under-states or over-states the EV, they can change whether a project is perceived to be running well or in significant trouble. Over time some approaches have been developed for estimating EV. These provide guidance to the project management team and can improve the accuracy of the EV.

The best approach is to have detailed tasks planning with a percentage of PV assigned to each item or interim milestone within the task. Then as soon as that item is complete, that amount of EV has been earned. However, this does require very detailed task planning and often that planning has not been done, either to save time or because there are no obvious interim steps within the task.

Another technique is the "0-100" technique. In this approach, no EV credit is allowed for a task until the task is completed. This is a good approach for short, discrete tasks, such as "Place Purchase Order."

The "50-50" technique is also commonly used. In this approach half of the EV is credited to a task once the task is started and the other half is credited once the task is complete. This is usually done when the task is relatively long and will span multiple reporting periods. This emphasizes the start of tasks and encourages tasks leaders to begin work as soon as possible on a task.

My personal favorite of the quick estimates is the "30-70" technique. In this approach 30% of the EV is credited to a task at the time of the task start and the remaining 70% is credited when the task ends. This is a good approach to use when a task has an uncertain estimate, such as software debugging. There is the recognition that work is underway, but the emphasis is on completing the task.

Earned Value Variance Analysis

EVA provides excellent insight into project variances. Through EVA a project manager can understand how schedule variances are impacting cost variances and vice versa. Without EVA, the project manager is at a disadvantage when trying to explain to finance why the expenditures were other than expected.

Once we have the PV, AC, and EV for a project, we can begin to calculate project variances and determine the current status of the project. The first variance I will discuss is Cost Variance (CV). This is the amount of under-run or over-run the project has experienced. As with all of the measurements, I can address the Current CV, which is the variance this month, or the Cumulative CV which is the variance since the project started.

CV = EV - AC

In EVA, a negative CV is an over-run and a positive CV is an under-run.

With the Earned Value technique, the CV is calculated by subtracting the AC from the EV. This is essentially asking, "How close am I to what I thought it would cost do the work I have accomplished as compared to what it actually cost to do the work that is accomplished." Because both EV and AC are only considering the work that is actually accomplished, the errors due to schedule variance are removed. The first set of figures shows how a project that is on schedule, but is either in an under-run or over-run condition, would be reflected in both a Gantt chart and with EVA data. The task is a two week task that started one week ago. The task is on schedule, meaning it is 50% complete and therefore the EV is the PV. In the top case, the task is on budget so AC = EV and the CV is zero. In the second case, the AC is $6,500 but the EV is only $5,000 so the CV is -$1,500 and the project is over-run. The third case shows that the AC is $3,500 and the EV is $5,000 so the CV is +$1,500 under-run.

Next we will consider Schedule Variance (SV). This is the amount ahead of schedule or behind schedule the project is currently experiencing. An interesting point about SV is that it is measuring schedule but the units are dollars. SV measures the VALUE of the work that is ahead or behind schedule, not the number of days or weeks. As with all of our measurements, we can address the Current SV, which is the variance this month, or the Cumulative SV which is the variance since project start.

SV = EV - PV

In the Earned Value technique, a negative SV is a behind-schedule condition and a positive SV is an ahead-of-schedule condition.

When considering the value of work that is ahead or behind schedule, the value of any under-runs or over-runs needs to be excluded. The Earned Value technique compensates for this. With the Earned Value technique, the SV is calculated by subtracting the PV from the EV. This is essentially saying, "The value of the work that I have completed minus the value of the work that I had planned to have completed by this time." Because both EV and PV are only considering the work using the originally estimated value of the work, the errors due to cost variance are removed and variances are due only to timing.

The next set of figures shows how a project that is behind schedule, and is either in an under-run or over-run condition, would be reflected in both a Gantt chart and with EVA data. The task is a two week task that started one week ago. The task is behind schedule, it should be 50% complete but it is only 30% complete and therefore SV is -$2,000 in all three cases shown. In the top case, the task is on budget since the AC of $3,000 matches the EV for the work that is done. In the second case, the AC is $4,500 but the EV is only $3,000 so the CV is -$1,500 and the project is over-run. Notice, that the project is not over spent at this point. Without the EVA analysis, the project team could be fooled into thinking they are in an under-run condition. In actuality they are over-run and behind schedule. The third case shows that the AC is just $1,500 and the EV is $3,000 so the CV is +$1,500.

A project may have spent the exact amount of money up to a point in time that had been budgeted for that time period. However, if only half of the work had been accomplished, the EV would be one half of the PV. This would indicate a significant behind schedule condition and a significant over-run, even though the money that had been spent was exactly what had been in the plan for spending up to that point. The problem is that now there is no money budgeted to do the work that was scheduled to have been done but has not been completed.

The final set of figures shows how a project that is ahead of schedule, and is either in an under-run or over-run condition, would be reflected in both a Gantt chart and with EVA data. The task is a two week task that started one week ago. The task is ahead of schedule, it should be 50% complete but it is already 70% complete and therefore SV is +$2,000 in all three cases shown. In the top case, the task is on budget since the AC of $7,000 matches the EV for the work that is done. In the second case, the AC is $8,500 but the EV is only $7,000 so the CV is -$1,500 and the project is over-run. The third case shows that the AC is just $5,500 and the EV is $7,000 so the CV is +$1,500. In this case, without the EVA analysis the project team could be fooled into thinking they are over-run since they had spent more than the $5,000 that was budgeted to be spent at this time. In actuality they are under-run since they have completed 70% of the task and not just the 50% in the plan.

The SV and CV variances are sometimes provided in percentage form rather than in actual value.

Forecasting Using Earned Value

The variance calculations for SV and CV give us specific values of under-run/over-run. We can also calculate indices that give us trends and that can assist in the estimating of final project cost. The two indices generated in the Earned Value technique are the Schedule Performance Index (SPI) and the Cost Performance Index (CPI).

SPI = EV / PV

The SPI is the ratio of Earned Value over Planned Value. When the EV is greater than the PV, we are doing more work than scheduled and the project is accelerating. The SPI will be greater than 1 in that case. When EV is less than PV, we are doing less work than scheduled and the project is being delayed. The SPI will be less than 1.

CPI = EV / AC

The CPI is the ratio of Earned Value over Actual Cost. When the EV is greater than the AC, we are completing the work for less than the estimate and the project is under-running. In that case the CPI is greater than 1. When the EV is less than the AC, then the cost to complete the work was greater than the initial estimate, or value, of the work. In this case we are over-running and the CPI is less than 1.

A question frequently asked of project management is, "How much will this project really cost to complete it?" At the beginning of the project an estimate is made. This estimate is normally set as the project budget and is referred to as the Budget at Completion (BAC). This is also the final PV for the project when the project plan is created. But the BAC contains many assumptions and is seldom realized precisely. Therefore, the question is a legitimate one. As the project progresses and we learn more, the assumptions are proved true or discredited.

Project management is then called upon to make a new estimate of the final cost to accomplish the project. This estimate takes into consideration the current business conditions and the relevant project experience to date. It is referred to as the Estimate at Completion (EAC). The EAC is the answer to the original question. It includes all of the money spent so far on the project and an estimate of what must still be spent to complete the project work.

EAC = AC + ETC

The Earned Value technique uses the variances and indices to calculate an EAC. This is done by taking the results of what has been spent already on the project, the AC, and adding to that an estimate of the cost to do the remaining open work on the project. This estimate for the remaining work is referred to as the Estimate to Completion (ETC).

It is obvious that in order to have an accurate estimate for the final project cost, the EAC, we need to calculate the ETC. There are several methods. These four are the most widely accepted.

Method 1. In this case I consider that whatever cost variance that has occurred on completed tasks is an isolated event. I do not think it is a trend and therefore the original estimate for the cost to complete the remaining work is unchanged. In this case the ETC is the value of all the work on the project that has not been done yet. It is determined by taking the total value of the work on the project (BAC) less the work that has been completed (EV).

ETC1 = BAC - EV

Method 2. In this case we consider that whatever cost variance that has occurred is a good indicator of what we can expect in the future, so we will extrapolate the trend through to the end of the project. This is done by determining the remaining work on the project (see Method 1) and dividing that by the CPI; which indicates the trend of under-run or over-run.

ETC2 = (BAC - EV) / CPI

Method 3. In this case we assume that there is a need to complete the project on time. Therefore, if the project is behind schedule, an effort will be made to accelerate the remaining tasks. This acceleration will cost money so the remaining work is also divided by the SPI; which indicates the trend of schedule variance that must be overcome to complete on time. Normally when this method is used, the estimate for the remaining work is based upon the Method 2 approach of considering any over-run or under-run trend.

ETC3 = (BAC - EV) / (CPI * SPI)

Method 4. At times we become convinced that the original estimate is so far off, or that the variances are neither isolated or clear trends, that we create a new estimate for the remaining work. This is often done when schedule acceleration techniques such as crashing or fast-tracking are used.

ETC4 = New estimate for the remaining work

The project management team uses whichever method they believe is the most accurate way to estimate the cost of the remaining work. Ultimately this is a judgment call based upon their understanding of the project.