Earned Value Reporting – Cost Performance Index

We’ll continue our discussion of Earned Value Reporting by looking at Cost Performance Index in this article. The Cost Performance Index refers to how the project is performing based on the actual spending of the project budget.

Much of the following information came from Newell and Grashina’s book entitled “The Project Management Question and Answer Book.”

What is the cost performance index?

The cost performance index or CPI is a measure of how well the project is doing in terms of spending the project budget. It is a comparison of the actual expenditures to the work that was accomplished. The index is a value that allows projects of different sizes to be compared.

The cost performance index is like the cost variance discussed previously with one important difference. When we calculated the cost variance, the result was a figure in dollars. If the dollars were a negative number, the variance was considered bad, and if the dollars were positive, the variance was considered good. The problem with this method is that it is difficult to compare projects of different sizes to one another. It would be better to have a measure that gave the health of the project regardless of its size. For this purpose we will use indexes.

Instead of subtracting the actual cost of work performed from the budgeted cost of work performed as we did when we calculated the cost variance, we will divide the same two numbers.

CPI = BCWP / ACWP

CPI = EC / AC

We can see that if the project is following its plan, the amount of work accomplished and the amount of money spent to accomplish it are the same, and the resulting value will be one. So, an index of one means that the project is following its project plan.

If the actual cost is greater than what is being accomplished, the denominator in the fraction will be larger than the numerator, and the resulting value will be less than one. This is generally considered to be a bad condition. If the actual cost is less than what is being accomplished, the resulting number will be greater than one and this is considered to be good. Of course any deviation from the project plan is bad even if the deviation is considered favorable. We should investigate to determine why this condition exists.

Example:

Two projects have their cost performance index calculated. Both projects are 10 percent over budget at the time of the calculation. Project One has a budget of $1,000,000, and Project Two has a budget of $10,000. These budget figures are the amounts that should have been spent as of today’s date. We will assume that the project is on schedule at this point in time. What is the cost performance index for each?

Project One is over budget by 10 percent of its budget or $100,000.

Project Two is also over budget by 10 percent of its budget or $1,000.

CPI = BCWP / ACWP

The BCWP is $1,000,000 for Project One.

The ACWP is $1,100,000 for Project One ($1,000,000 + $100,000).

The BCWP is $10,000 for Project Two.

The ACWP is $11,000 for Project Two ($10,000 + $1,000).

CV = BCWP – ACWP

The cost variance for Project One is $1,000,000 ? $1,100,000 or ? $100,000. The cost variance for Project Two is $10,000 ? $11,000 or $1,000 The CPI for Project One is $1,000,000 / $1,100,000 or 0.909. The CPI for Project Two is $10,000 / $11,000 or 0.909.

Notice that the size of the project does not make any difference in the calculation of the index. Projects that are each behind 10 percent have the same value for their cost performance index. This makes assessing the health or sickness of projects of different sizes much easier.

Earned Value Reporting – Intro Part 2

In the previous Intro Part 1 article we began to look at Earned Value Reporting as described in Newell and Grashina’s book “The Project Management Question and Answer Book.” In this Intro Part 2 article, we’ll exam Cumulative Variance Reports before diving deepr into other EVR concepts and reporting mechanisms.

Cumulative Variance Reporting

Sometimes in very large projects there is a problem with representing the project plan and the other earned value factors on a cumulative basis. When the project budget is very large, the vertical scale of the report is so small that minor but important variations cannot be seen well. In this situation a variance reporting method can be used.

To plot the earned values on a variance chart as shown in Figure 2 we simply plot a horizontal line and label it zero. Now, instead of plotting the actual values of the BCWS, BCWP, and ACWP we plot the differences between the BCWS and the other two earned value reporting factors. When we do this, the vertical scale that we need is greatly reduced in size since we are concerned only with plotting the difference between the earned value factors and not the entire budget of the project.

FIGURE 2

The next one, the ACWP or AC, is pretty simple too. This stands for the actual cost of work performed. Like the BCWS it is a plot over time of expenditures. This time, instead of plotting the project’s planned expenditures we are plotting the project’s real expenditures over time. At the end of each reporting period, we take the total amount of money that was spent on the project during that period and plot it as an addition to the total amount of money that had been spent as of the last reporting period.

It is important that every expenditure that is made on the project be collected and be collected in a timely way. The timing of the collection of the actual cost of work performed must match the anticipated timing of the expenditures that were planned and plotted as the BCWS. This is terribly important since, if expenditures are collected early or late in the project in relation to the project plan, the earned value report will show a positive or negative variance when there may really be none.

The ACWP plot is a cumulative plot as well. If the project expenditures are actually what they were planned to be, then the ACWP and the BCWS lines will plot one on top of the other. If the lines do not coincide, there is something different from the plan taking place in the project. We are either spending too much or too fast or we are not spending enough or fast enough to meet our plan.

The next factor is the BCWP or EV. This is the only one that is a little tricky. BCWP stands for the budgeted cost of work performed. It is sometimes called the earned value as well. This is where we get the name of the earned value report. Like the BCWS and the ACWP, the BCWP is a plot of money over time. If you recall, we said earlier that each of the project tasks has a budget and schedule associated with it. The BCWP is a plot of the work that was actually accomplished. If we complete a task that had a budget of $1,000, then the BCWP for that task when it is completed is $1,000. We plot this on a cumulative basis as well. It does not matter whether we spend $1,000 or $2,000 or any other amount to accomplish this task, we earn and plot only the budgeted amount in the BCWP.

Like the ACWP, the BCWP should plot right on top of the BCWS line. If the plot of the BCWP is above or below the BCWS line, it means that the number of tasks that are being completed is greater than or less than the plan. This tells us that we are ahead of or behind schedule. If we have done all of the tasks that were supposed to be done at this point in time, the cumulative value of the BCWP will be precisely equal to the BCWS.

When we put all three of these plots together, we have the earned value report. The plots should plot right on top of one another if the project is being done on time and in accord with the budgeted amount that was in the project plan.

Example:

Suppose a project is in progress and as of today the planned expenditures for the project were to have been $500,000. Suppose also that there were five tasks and the tasks had budgets of $30,000, $100,000, $250,000, $100,000, and $20,000, respectively. The actual cost of each of the tasks that were worked on was $11,000, $120,000, $230,000, $105,000, and $20,000. Tasks 1, 2, 3, and 4 are complete.

What are the BCWS, ACWP, and BCWP (PV, AC, and EV)?

• BCWS is $500,000
• ACWP is $486,000
• BCWP is $480,000

From these figures we can see that the accomplishments of the project as of today are somewhat less than what was planned for. This is the difference between the earned value and the planned value to date. The planned value is the BCWS and the earned value is the BCWP. This means that we are $20,000 behind schedule.

We can also see that the actual cost is $14,000 less than the planned expenditures to date. This means that we are somewhat under budget. Unfortunately we are $14,000 under budget but also $20,000 behind schedule. If we add the $20,000 of work that should have been completed but was not, we find ourselves projecting a $6,000 over budget condition. It could be that things are actually worse than they appear at first glance. If the performance to date continues, the amount over budget will probably be even higher at the end of the project. This is usually considered a bad situation.

Defining Implementation Success or Failure

Sometimes indentifying whether your project or implementation was a success or failure is not as straightforward as just looking at the metrics involved with project management. It’s not always about on time and on budget. And it may not entirely be about customer satisfaction either.

In Henry Lucas’ book “Information Technology for Management” he defines first what an Implementation is and then looks at some of the possible criteria for determing that implementation’s relative success or failure factors.

What Is Implementation?

Implementation is part of the process of designing a system and is a component of change. We develop a new information system to change existing information processing procedures and often to change the organization itself. Implementation refers to the design team’s strategy and actions for seeing that a system is successful and makes a contribution to the organization.

Our definition stresses the long-term nature of implementation. It is part of a process that begins with the very first idea for a system and the changes it will bring. Implementation terminates when the system is successfully integrated withthe operations of the organization. We expect most of implementation to be concerned with behavioral phenomena since people are expected to change their information processing activities. Implementation becomes more important and difficult as systems design becomes more radical. If a firm undertakes a maj or reengineering project, it should make major changes in tasks to reduce costs and improve productivity in the organization.

Success or Failure

How do we know that we have successfully implemented a system? Researchers do not agree on an absolute indicator for successful implementation. One appealing approach is a cost/benefit study. In this evaluation, one totals the costs of developing a system and compares them with the dollar benefits resulting from the system.

In theory, this sounds like a good indicator of success, but in practice it is difficult to provide meaningful estimates. Obtaining the cost side of the ratio is not too much of a problem if adequate records are kept during system development. However, an evaluation of the benefits of an information system has eluded most analysts. There are a number of categories into which we might classify the benefits or value provided by an application of technology. These categories include:

• Infrastructure
• Required applications
• Applications where technology was the only solution
• Applications providing a direct return
• Applications with indirect returns
• Technology initiatives that are a competitive necessity
• Strategic applications
• Transformational information technology

For only a few of these categories are we likely to be able to demonstrate a direct financial return, which makes it difficult to perform a cost/benefit analysis to determine the “success” of a system.

As an alternative, we can choose among several indicators of successful implementation for an individual application, depending on the type of system involved. In many instances, use of a system is voluntary. A manager or other user receives a report but does not have to use the information on it or even read the report. Systems that provide interactive retrieval of information from a database also can often be classified as voluntary. The use of such a system is frequently at the discretion of the user. A manager with a personal computer in his or her office is not required to use it. For the type of system in which use is voluntary, we shall adopt high levels of use as a sign of successful implementation. We can measure use by interviews with users, through questionnaires, or in some instances, by building a monitor into the system to record actual use.

For systems whose use is mandatory, such as a production control system or a computer that provides stock market quotations for a broker, we shall employ the user’s evaluation of the system as a measure of success. For example, onecan examine user satisfaction, although it will probably be necessary to measure several facets of satisfaction, such as quality of service, timeliness and accuracy of information, and quality of the schedule for operations. An evaluation might also involve a panel of information processing experts reviewing the design and operation of the system. We should also note that managers might well consider a system to be successful if it accomplishes its objectives. However, to accomplish its objectives, a system must be used. We would also hope that one objective of a system would be extensive use and a high degree of user satisfaction.

Finally, though it is difficult to do, we can try to estimate the impact of a system on individuals and the organization. How has a system affected personal productivity and output quality? Can the organization point to added sales or increased revenues from a competitive application? Can we show that IT has had an impact on performance, either for individuals or the organization?

The Project Change Order Request – Version 2

As promised – another version of the love-hate Change Order Request.  This is a cut/paste from a Word doc template that I would be happy to share.  The Word doc version looks much better, but this at least gives you an idea of the content that is being captured here for customer approval.

The main concept is to capture as much information about the proposed scope change as possible and estimate each task effort that it’s going to take to get there.  Once that effort and budget info is captured here, that information can easily be rolled into the project schedule to show your customer how the change order request is going to affect the overall project timeline.

I’ve been using this version – or at least some variation of it – for most of the past three years on projects and it’s served me very well.  The change order request is always a delicate subject for both the project manager and the customer so handling it carefully and in the greatest detail possible is critical to good decision-making and for on-going customer satisfaction since it usually results in the customer paying more on the project (but not always because even things that decrease the project scope and cost should be documented using this same process….it affects the project, too!).

Again, if you want a Word doc version of the template let me know.  And if you have a version you can share, I’d like to see it and share it with our PM Tips readers as well.

Project Transition to Production Support

As part of methodologies I’ve previously discussed, the final phase is something that I call the Post-Deployment phase.  Once the project is implemented – or deployed – the delivery team, the customer, and the project moves on into the Post-Deployment Phase.

The Post-Deployment Phase is the period of time when the delivery team remains as intact as possible to support the customer and the deployed solution before a final and formal transition to technical, or production support.  This post-deployment period is usually somewhere between 30 and 90 days in length (30 is more likely) and that time period is set either during the sales process (and becomes part of the statement of work) or during the kickoff session.

Upon satisfaction of the post-deployment timeframe, support formally moves over to the company’s techical or production support team.  The template I am unveiling here is a formal document to record that transition process, allowing the project delivery team to identify specific things about the project that the production support team will need to know.  While reviewing this document, keep in mind that there are really three very key pieces of information in here that the support team will need to know the most about:

• Schedule
• Communication
• Change Control Process

PROJECT TRANSITION TO PRODUCTION SUPPORT

[Save file name as: client name PRODUCTION SUPPORT yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work performed.

SCOPE

Describe the deliverables/actions to be supported. Provide additional documentation as appropriate.

SCHEDULE

Describe the timing for support activities to be performed. Provide additional documentation as appropriate.

COMMUNICATION

Describe all required communication needs for support – What to communicate, to whom, in what format, and when. Provide additional documentation as appropriate.

QUALITY ASSURANCE

Describe the Q/A processes to be performed. Provide additional documentation as appropriate.

COST

Describe the support costs estimated by the project. Provide additional documentation as appropriate.

CHANGE CONTROL PROCESS

Describe how changes to the Production Support process will be addressed. Provide additional documentation as appropriate.