The two variables that need to be closely monitored during the execution phase of the project are expenditure to date and work accomplished. These variables are fairly closely related, since any delays in completing the work will have the potential to increase the overall cost of the project. Progress is usually measured at each project milestone, providing a snapshot of the project’s status at that point in time. The actual performance at any given point in time can then be compared to the project baseline to determine whether or not there has been any significant slippage (or variance), and if necessary corrective action can be taken. Milestones are often set to mark the completion of a group of related work packages (the low-level activities derived from the work breakdown structure), collectively known as a control package. The control package itself is usually defined at some higher-level within the WBS hierarchy. The cost associated with each control package can be estimated simply by adding the individual cost of each work package within it. The time required to complete the control package is not so easy to derive, since it is possible that two or more work packages within a control package might be executed concurrently. Instead, the total work effort required (in terms of man-hours) is used.
The essence of project management is to try to ensure that, as far as possible, the project stays within budget and on schedule. The purpose of a project milestone is to represent a point in time at which progress can be measured, both in terms of the work accomplished and the costs incurred to date. These values can then be compared to the project baseline to determine whether or not there is any variance (positive or negative), and if so how large the variance is. The ability to measure progress in this way makes it possible to exercise control over the project by flagging up any problems that may be developing and doing something about them. One of the most commonly used techniques for measuring the progress of a project is called Earned Value Analysis (EVA). Some of the terminology used in EVA is explained below.
Variances in cost and schedule are used as the basis for reporting problems to various levels of management and other stakeholders. Thresholds can be set for both to determine if, when, and at what level a variance should be reported. Of course, the degree of variance that may be tolerated will depend on the nature of the project. The acceptable variance will tend to be lower for a well-defined and well-understood problem domain.
If the project involves research and development and there are many unknowns to contend with, much greater tolerances may be defined (although ultimately, the goal of the project manager should be to stay on schedule and within budget). The reporting of problems to higher levels of management on the basis of whether or not variance thresholds have been exceeded fits in well with the idea of management by exception, whereby senior levels of management do not directly intervene in a project unless they are required to do so by circumstances. Two commonly used formulae for calculating the variances are:
Cost variance = BCWP - ACWP
Schedule variance = BCWP - BCWS
Work in progress is evaluated for each control package at the end of each project monitoring period (for argument’s sake, this could be done on a monthly basis). The cumulative value of the work completed to date (its earned value) is calculated using the budgeted cost of carrying out the work. At the same time, the actual costs of carrying out the work are derived from various sources (supplier invoices, staff timesheets etc.) and can be compared with the budgeted costs. The earned value and actual cost can be plotted on a graph and compared to the BCWS curve, which represents planned performance in terms of cost and schedule.
The BCWS curve represents the project baseline. If the actual cost (represented by the ACWP curve) and the work performed (represented by the BCWP curve) match or closely follow the BCWS curve, it is an indication that all is well and that the project is on budget and on schedule. If the ACWP curve is significantly above the BCWS curve, a cost overrun is indicated. By the same token, if the BCWP curve is significantly below the BCWS curve, the project is behind schedule. The curves for a generic 12-month project with a projected cost of £250,000 are illustrated below.
It can be seen from the above that nine months into the project there is a cost overrun of £79,000, and the project is nearly a month behind schedule. The figures used for the example have been chosen to highlight the principle, but sadly many projects have fared as badly, if not worse. If problems are highlighted by the earned value analysis (sometimes called variance analysis), further investigation needs to be carried out to determine exactly where the problems are occurring. Each control package must be examined in order to pinpoint which are over budget or behind schedule. It should be relatively easy to identify which control packages (or individual work packages) are causing a problem by comparing their actual status with the detailed project plan.
Even if the variances are insignificant, it does not mean that there are no problems developing. This is particularly true for the project schedule, since although an acceptable schedule variance is obviously a favourable indicator it does not guarantee that activities that lie on the critical path are being completed on time. Additional checks and balances should be applied to ensure that there are no hidden problems developing. A secondary benefit of earned value analysis is that if the project is being undertaken for an external customer, and the customer is being invoiced at pre-defined intervals on the basis of work completed, earned value analysis can be used to calculate how much work should be invoiced out for a given accounting period.
This article was first published on the TechnologyUK.net website in January 2009.