Performance Reporting

Control activities uncover important information about your project that you need to communicate to stakeholders. Performance reporting provides progress and forecast information on the project scope, schedule, cost, and quality. Risks or issues that that are jeopardizing the success of the project also need to be reported to the stakeholders.

Performance results should be distributed based on your communications plan for each stakeholder group . Performance reporting includes information on what has been accomplished to date and is typically stated in terms of what has been completed and what remains to be done.

A number of analytical tools can assist you in obtaining meaningful data to communicate project progress.

In addition to communicating project results and forecasts, performance reports often require action on the part of the stakeholder team.

Performance Reporting Tools and Techniques

A meaningful performance report needs to contain more specific information than simply stating whether the project is on schedule, over budget, or out of scope. Deviations have a wide range of impacts on the overall success of the project. As part of your performance report, you need to include an analysis of the problems to quantify the impact to the project.

Techniques that can be used to clarify the impacts of deviations from the plan include variance analysis, trend analysis, estimate at completion, and earned value.

Variance Analysis

Variance analysis is the comparison of planned project results with actual project results. Variance analysis is most frequently used on the project schedule and project budget.

Most project management software tools include a tracking feature that allows you to display the baseline schedule compared to the actual schedule. You can see which tasks took longer than predicted , as well as any impacts to project milestones. You can create views that show results down to the task level, or you can do a summary view that shows the overall results for a particular phase. This tracking feature also recalculates project end data based on any delays.

Project budget reports can be compared to the cost baseline to show how much has been spent compared to what was budgeted for the same period of time. These reports can also include a comparison of the hours expended on tasks by individual resources to the work effort estimate that was part of the cost baseline.

Percentages can be used to quantify variance. You may have seen performance reports stating that a major deliverable is 75 percent complete or a statement indicating that the project schedule is 50 percent complete and 35 percent of the budget has been spent.

Warning  

Exercise caution when using percent complete or percent of total budget. These numbers may be misinterpreted if they are used out of context. The budget needs to be looked at in terms of the work completed and the work remaining. Being on schedule and over budget is not a good thing, but being behind schedule and over budget should send up a big red flag.

Trend Analysis

Past performance may give you a clearer picture of what to expect from future performance. Trend analysis is based on mathematical calculations used to show whether performance is improving or declining over time.

These historical trends are used to forecast future project performance. Various formulas are used to calculate trends and predict future results. It is outside the scope of this book to go into this subject in detail.

Estimate at Completion

As your project progresses and you obtain your official budget reports, you will be asked to predict the total cost of the budget. An estimate at completion (EAC) is a forecast of the total cost of the project based on both current project performance and the remaining work. To understand how EAC works, you need to know a couple of other terms:

• Actual cost (AC) is the total amount spent on the project to date or through the end of a particular phase.

• Budget at completion (BAC) is the total amount of the project budget.

• Estimate to complete (ETC) is the cost estimate for the remaining project work.

EAC = AC + ETC A comparison of your EAC figure to your BAC figure provides you with a current estimate of any deviation from the original budget.

Note  

There are two other methods for calculating EAC. One uses actual spending to date plus remaining budget. The other method uses actual spending to date plus the remaining budget modified by a performance factor. It is beyond the scope of this book to go into detail on these methods . Further information can be found in A Guide to the PMBOK .

Earned Value

In your future, more advanced PM studies, you'll encounter some financial management variables that you may want to pay attention to- especially if your project is one that's massive and requires that you pay special attention to all the financial details.

Note  

Although Objective 3.10 only lists the three terms associated with estimate at completion, the intent of this section is to provide a broader explanation of financial management variables.

There are several variables, each of which could be easily calculated through spreadsheet or project management software calculations. We need to take some time to build some of the numbers that you'll use to calculate these variables, so we'll start with some basic definitions, then move into how they combine with each other in real use.

A Guide to the PMBOK has changed some of the earned value management terms. Both sets of terms are still in use, which can cause confusion if you do not realize that two terms are interchangeable. Table 9.2 lists both the current term and the term it replaces .

When you perform analysis on your project using the following formulas and variables, you're performing earned value analysis . When you perform assessment on a project's earned value , you're measuring how much of the budget you predict that you should have spent so far, given the amount of work already done on the task. You're calculating the budgeted cost of work performed (BCWP). (The terms earned value and BCWP can be used synonymously.) It's important to also understand that your pristine project starting point-nobody working on any tasks yet, no money spent-represents the baseline of the project. It's important to fully describe your project's beginning prior to calculating any financial management variables. Project management software allows you to save your work with a baseline before you start entering hours or materials costs.

TABLE 9.2 : Earned Value Terms

Current Term	Also Known As
Actual Cost (AC)	Actual Cost of Work Performed (ACWP)
Earned Value (EV)	Budgeted Cost of Work Performed (BCWP)
Planned Value (PV)	Budgeted Cost of Work Scheduled (BCWS)

Earned Value Basics

Start with a status date -simply, the date when you're going to take a measurement of how much has been spent on a specific task.

Next, you must understand several different ways of looking at a task's cost. The first way is the planned value (PV), also referred to as budgeted cost of work scheduled (BCWS). Generally, you apportion out a task's total cost evenly over the number of days that the task is scheduled to take. If a task is predicted to take 5 days and cost $100, for example, each day represents $20 of a task. You arrive at the BCWS by comparing the amount that's budgeted to be spent on a task between its start date and the status date (not necessarily the same as the end date). For example, if you have a 5-day task that's going to cost $250, then you can break the per-day cost out to $50 a day. If you set your status date to Thursday, for example, you've used 4 days of the 5 and your BCWS is $200. Figure 9.3 illustrates this concept.

FIGURE 9.3 Budgeted cost of work scheduled (BCWS) or planned value at status date

Another component of earned value is the actual cost of work performed (ACWP). This is the actual cost incurred for each day that you worked on a project within a given period. In our example in Figure 9.3, the project has a budgeted cost per day of $50, for a total of $250 for the task. But what if you spent only $45 on Monday, $30 on Tuesday, $45 on Wednesday, and $35 on Thursday? Then your ACWP for the 4 days would be $155, even though your BCWS is still $200. Figure 9.4 shows this relationship.

FIGURE 9.4 Actual cost of work performed or actual cost

Finally, you have another straightforward calculation you can make: budgeted cost of work performed (BCWP, as mentioned earlier). This figure represents the comparison of the percentage of work performed to the expected, budgeted amount. If by Wednesday you've met 75 percent of the task's budgeted work (even though you've got until Friday), then the work you've done was budgeted to cost $187.50 even though you've only really spent $120. You're comparing the amount you've actually spent to the amount you'd expect to have spent based on the percentage of work completed thus far. Figure 9.5 demonstrates this calculation.

FIGURE 9.5 Budgeted cost of work performed or earned value

Now that we know the differences in these earned value components , we can go forward and calculate some basic financial management variables. The BCWS, ACWP, and BCWP figures you have go into the remaining calculations.

The BAC and EAC acronyms that were described earlier in this chapter will also play into an index described later.

All these calculations deal with comparing the current status to the budget in some way. One group simply subtracts, producing a variance that is the difference between actual and budgeted; the second group, the indexes , divide to show you the ratios relative to those measurements. All these numbers might be useful to calculate, although in smaller IT projects not all of them will be necessary.

Variances

Variances show the difference between that which was budgeted and the actual costs expended. A positive variance shows that you've saved money or time and might be able to reapportion the savings elsewhere in the project. A negative variance states that you're either over budget or behind schedule for a given task-requiring that you take action.

Cost Variance The cost variance (CV) simply represents the difference between a task's estimated (budgeted) cost and its actual cost. The formula is CV = BCWP - ACWP.

Schedule Variance The schedule variance (SV) simply represents the difference between a task's progress as compared to its estimated progress and is represented in terms of cost. The formula is SV = BCWP - BCWS.

Indexes (Ratios)

Indexes are designed to show a ratio between one project budgetary component and another. The most common of these numbers are extremely useful, because they are simple to gauge: either greater than 1 or less than 1. If a ratio's value is greater than 1, the task is either ahead of schedule or under budget. A ratio less than 1 indicates that your task is behind schedule or over budget.

Note that ratios can also be expressed as percentages, which may be an easier way to think of the numbers. For example, if one of these indexes calculates to 0.971, you can multiply by 100 to state that index as 97.1 percent.

When you commit these formulas to memory and understand what they're representing, you can use earned value analysis to get a much better handle on where you're at with a given project. You can answer questions such as 'Is there enough money in the budget so that I can finish the project?' or 'Do I have enough time left to finish the project on time?' Again, you would use these calculations with very complex projects and probably wouldn't need them with simpler ones.

COST PERFORMANCE INDEX

The cost performance index (CPI) shows the ratio between a task's budgeted and actual costs. The formula is CPI = BCWP/ACWP.

A CPI of less than 1.0 means you're over budget; a value over 1.0 means you're spending less than you expected.

SCHEDULE PERFORMANCE INDEX

The schedule performance index (SPI) is a ratio of the work performed on a task versus the work scheduled. The formula is SPI = BCWP/BCWS.

An SPI of less than 1.0 means you're behind schedule; a value over 1.0 means you're taking less time than you expected.

TO-COMPLETE PERFORMANCE INDEX

The to-complete performance index (TCPI) is a ratio of remaining work compared to remaining budget and is represented as a percentage. It can be viewed as an efficiency formula where the higher the percentage, the more efficiency you're currently getting out of the task. A TCPI that is more than 20 percent higher or lower than the CPI means that the current EAC is not representative of past performance. Here is the TCPI formula:

TCPI = work remaining /funds remaining

where: work remaining = BAC - BCWP

funds remaining = BAC - ACWP

For example, given the following project numbers, here's how you'd calculate the TCPI:

BAC = 250,000

BCWP = 175,000

ACWP = 180,000

CPI = (175,000 / 180,000)

= 0.972 (or, as a percentage, 97.2%)

TCPI = (250,000 - 175,000) / (250,000 - 180,000)

= 75,000 / 70,000

= 1.071 (or, rendered as a percentage: 107.1%)

To compare TCPI to CPI, divide one into the other. If the result is between 1.2 and 0.8, then you're within the +/ ­  20% guideline:

TCPI / CPI = efficiency compared to past performance

1.071 / 0.972 = 1.102

In this case, a comparison of 1.1 means we're essentially on track in our project relative to past performance (provided, of course, that past performance was in line with our expectations).

The results of all this analysis may require decisions by the stakeholders on how (or if) the project will move forward.

Driving Stakeholder Action

During the project control phase many hard decisions regarding the future of the project are made. The project manager is responsible for communicating not only the nature of deviations from the project plan, but also the impact of these deviations and recommendations for moving forward. Trade-offs may be required in order to complete the project. In some cases, the project may no longer be viable and the stakeholders may be asked to officially cancel the project.

Communicating Performance Deviations

As you analyze progress throughout the life cycle of your project, it is important to keep stakeholders advised of any variance that could impact the outcome of the project. You may choose to supplement your project status report with charts or tables to clarify and summarize the results of your analysis. Several useful charts and reports can be produced using your project management software. For example, a tracking chart can be produced in Microsoft Project that displays the status of major deliverables or milestones compared to the schedule baseline. If you have loaded cost data into the software, other reports compare what was spent to what was budgeted.

Tip  

The key to success is to keep things as simple as possible. The point of using graphs or charts is to clarify how the project is performing compared to the plan. Avoid using acronyms or other analytical terms the stakeholders may not be familiar with. Translate your results into language everyone can understand.

Managing Trade-Offs

Early on in this book we mentioned that all projects share common constraints: scope, time, cost, and quality. If any one of these changes during the course of a project, it impacts at least one of the other three. Change of some form is inevitable in all projects; so don't think that you can keep all the variables stagnant.

As project manager, you need to communicate the trade-offs to the stakeholders if there is a change to one of the constraints. You should have an idea regarding the importance of the constraints from your planning meetings with the client, so that you can present the trade-offs based on the constraint the client does not want to change. Let's look at how changes in one area of the plan impact the others.

Scope Trade-Offs

A scope change request is often one of the easiest to deal with from a communications perspective, because your change control process includes an analysis of the impact of the proposed scope before the change is approved.

If your client wants a new feature added to the address validation project, you need to communicate the increased cost and/or increased time it will take to add that feature. Additional resources or team members with different skill sets may be required. Clients may often push back and want you to just do it all within the same time period with the money currently budgeted. The client needs to understand that the only way to accomplish that is to give up quality by eliminating or shortening test cycles.

When dealing with scope changes, look for alternate solutions that may be acceptable to the client. If a new feature cannot be added to the existing project without a schedule change, perhaps it can be looked at as a future enhancement. There may be other ways to obtain the result the client needs, so always ask questions to clarify what is behind the scope change request.

Schedule Trade-Offs

The importance of a schedule delay can run from an inconvenience to a disaster, so it is critical that you know and understand the relative importance of this constraint for your project. Let's look at a situation where your 10-month project is staying within budget and has not been subject to scope changes, but you need to obtain approval from your stakeholders to extend the project end date 3 weeks. On the surface this request seems reasonable; we all know that the estimates made during project planning are educated guesses. In many situations, the logical course of action may be to recommend delaying the end date rather than to add risk to the project by implementing crashing or fast tracking. However, if the project was designed to meet a regulatory action with a mandated implementation date, you would certainly lose credibility making a recommendation that would cause your organization to be in noncompliance and subject to fines or other legal action. You should always consider the priority of the target end date and the impacts of missing this date before you recommend a schedule delay.

If your actual results indicate that you are behind schedule in several areas, it is likely that the work effort was underestimated or the requirements did not communicate the true complexity of the project. Regardless of the reason, if you are behind schedule and see no viable means of catching up with the current resources, you need to present your stakeholder with options. Assuming the project delivery date is the highest priority, you need to assess how the date can be met. If your issue is resources, explain to the stakeholders the resources required and the estimated cost. If more resources will not impact the end date or if no funds can be secured, you should be prepared to discuss removing functionality from the project.

A Phased Delay

Telling your stakeholders that there will be a delay in the project delivery is no fun, but sometimes you just can't avoid it. It may even be a big delay. But don't make it worse by downplaying the length of the delay and crossing your fingers.

One of our early project experiences involved a new system application that was being developed for customer care representatives from two recently merged companies. Although the requirements and all of the major deliverables referenced one system, each company had separate backend systems to interface with the new customer care system. So in reality, the development team had twice the application interface work than had been planned.

Everyone on the team knew there was no way that the project would deliver as scheduled, and the development team completed a revised estimate that would delay the project by 6 months. Both the development manager and the project manager were afraid to go to the sponsor and the client with this news, so they communicated a 2-week delay and hoped for a miracle . The 2 weeks didn't change anything, so they communicated another 2-week delay. At this point the sponsor started asking a lot of questions, and the project manager had to admit that the best estimates of the additional work required indicated a 6-month delay. The sponsor was furious that she had not been told the truth from the beginning, and the credibility of the project manager was nonexistent. In fact, a new project manager was named shortly after this incident.

No one likes bad news, but you will be much better off if you take one big hit and present all the facts. Too many project managers try to sugarcoat project problems and convince themselves that the project will turn around-that rarely happens.

 

Schedule delays may be inevitable. If the original requirements were not clear or a required element was missed, the project may be more complex than anticipated. Work may have progressed beyond the point where functionality can be removed without creating rework . If there is no way to avoid moving out the schedule, and the project is still viable, you need to make sure that the new end date reflects all changes that have occurred since the project was planned.

Cost Trade-Offs

Cost overruns can be the result of inaccurate estimates, schedule delays, scope creep, or omission of critical items from the cost baseline. Because costs may increase from so many areas, it is important to track costs relative to the work that has been completed. What has been spent at a given point in time may be over budget, under budget, or right on track depending on what milestones have been reached. If you budgeted $50,000 for a project phase, have spent $50,000, and the phase is complete, you are right on track. However, if you have spent $50,000 and the phase is only 30 percent complete, you have a problem.

If the project budget is cast in stone and you are experiencing overruns, the only way to make up the difference is to shrink the project. The best way to accomplish this is to meet with the client and the sponsor to decrease the scope of the project that will allow the project to complete with fewer resources and stay within budget. If you find yourself in this situation, make sure you are fully aware of the work that remains. It will accomplish nothing if the client agrees to give up functionality that has already been delivered.

A sponsor or client may push to retain the current scope, and make up for the budget overrun by short cutting testing or other quality activities. If this happens you need to make sure they are willing to accept the consequences of defects that may not be found until the system is in production.

Negotiating project trade-offs may not always be the best solution. If there are no viable alternatives, you need to present a recommendation to cancel the project.

Canceling a Project

In some cases, the best solution for dealing with project variance may be a recommendation to cancel the project. It is better to cancel a project that cannot be adequately funded or staffed to produce the needed deliverables than to let it continue and fail. If a project was approved without adequate planning, you may find yourself in a situation in which there is no viable solution. If requirements are constantly changing, or the client expectation is totally out of synch with the plan, you need to ask the sponsor and the other stakeholders if the project is still viable. If it seems that everything needs to be changed, perhaps there has been a change to the business strategy and this project is no longer needed.

Recommending cancellation of a project does not mean that the project manager has failed, it means he/she is forcing the sponsor and the client to reassess the original objectives and determine if this project still makes good business sense.

Case Study: Chaptal Wineries-Intranet and Email

You've been evaluating the project for quality, budget, and timeliness.

Budget While the majority of the budget has gone well-there have not been huge budget shortfalls-you perform a quick estimate from the place where you've gotten hit the hardest- hardware. The result shows that you're almost $3,000 over budget, or about 3 percent of the overall $100,000 cost of the project.

Category	Actual	Estimated	Difference
Servers	79,124	80,000	$876.00
Network	21,478	20,000	$(1,478.00)
French E1	2,980	2,000	$(980.00)
Australia T1	2,480	2,000	$(480.00)
Chile T1	2,730	2,000	$(730.00)
California T1	1,990	2,000	$10.00
		Total	$(2,782.00)

Since you had not ascertained a predetermined variance number for the project, you decide to visit Kim Cox to see what she thinks about the overage. Kim tells you that she had in mind a +/- 5% variance, so she's OK with the fact that you're slightly over. However, just because you're within variance does not mean that you can call yourself overly successful with the project budget.

Quality The overall quality of the various elements of the project have, in your opinion, been high. Signal over the T1s is now good throughout-the Chilean telecommunications contractor was able to fix the problem easily (after Metor asked for a replacement from the first person who did the configuration). Customer response on the contractor's part was excellent and took no time at all to get going.

You're also especially pleased with your intranet developer, Susan Wilcox. She has produced high-quality pages at a rapid rate. While she'll use up every bit of the allotted time you've given her, she has committed to not going over and has made all of her deadlines so far. You're quite pleased with the responsiveness and completeness of the pages.

Timeliness With the exception of the 2 weeks wasted waiting on the Chilean telecommunications contractor to produce someone else who could figure out what was wrong with the T1 configuration, there have been no timeliness issues.