How does earned value give a clearer picture of project schedule and cost status than a simple plan versus actual system?
One significant advantage that the earned value has is its ability to measure the work accomplished for money spent. The earned value actually gives a clear picture because of its incorporation of the time variable in the measurement of progress.
According to Lessard (2007), earned value compares the PLANNED amount of work with what has actually been COMPLETED, to determine if COST, SCHEDULE, and WORK ACCOMPLISHED are progressing as planned.
A simple plan versus actual systems are misleading and can lead to false conclusions to both management, the project managers, stakeholders when it comes to evaluating project performance and progress.
The Cost Variance (BCWP-ACWP) for example does not measure how much work was done for the money spent.
An example will suffice here:
Consider a Construction project of a five-star hotel in Aberdeen with a planned duration of 12months and a budgeted actual cost (BAC) of $6million. At the sixth month, the actual cost of work performed (ACWP) is $3.5million, while the budgeted cost of work scheduled (BCWS) is $3million.
With the information above, one may jump into conclusion that there is a cost overrun of $500,000.
That may not necessarily be the case. In fact, the 500,000 may have been used for the advance purchase of construction materials. Or the project may indeed have a cost overrun and maybe behind schedule. We cannot just be hasty in our judgements.
Let’s imagine another scenario. What if at the sixth month, ACWP is $2.5million and BCWS is $3.0million, does this then indicate that the project is coming under budget or better still is it behind schedule? Like the first scenario, there is no way to ascertain.
So the question is: how can be sure of accurate information?
Enter “The Earned Value method”. Like mentioned above the earned value keeps track of schedules and budget against time and, therefore, overcomes these problems. The Earned Value determines the current status of a project by using the three data: BCWS, BCWP ( budgeted cost of work performed ) and ACWP.
From these data, Schedule Variance and Cost Variance, Cost Performance Indicator and Schedule Peformance Indicator can be calculated.
A positive variance indicates a desirable condition; negative means there something wrong.
If the cost performance index (CPI) > 1 then the project is on schedule or ahead of schedule, otherwise, it's behind schedule.
If the schedule performance index (SPI) >1 then the project is on or ahead of schedule, otherwise it's behind schedule.
The important thing is that variations are per unit time. So we know exactly where we stand at any particular moment of the project.
Why is it important for project managers to resist changes to the project baseline?
Under what conditions would a project manager make changes to a baseline?
When would a project manager not allow changes to a baseline?
The Project baseline is the threshold for planning, controlling, measuring and evaluating the project's progress.
Furthermore, the Project baseline is a very important parameter in the EV cost/schedule system.
Changing the project baseline therefore changes other value such as the SV.
Constant changes can also hinder the proper monitoring for project progress and tracing of delays as at when due.
Changes in project baseline should then be limited to major changes in scope. For example when there is a design to improve a product, when the original baseline is poorly defined or when there is a change in customer requirement or government requirement. Environmental factors like natural disasters can also force a change in the project baseline.
In general, the project baseline should be only be changed if the project will FAIL if the change is not implemented.
The Project manager should not allow a baseline change to "improve poor performance" also known as "rubber base lining". The Project manager should have at the back of his mind that poor performance may be based on factors such as conflicts in than workplace rather than the baseline.
Price and Planning errors are also not enough reasons for the baseline to be changed. Ditto for some changes in cost (the Project Manager should rather rely on some contingency reserves before thinking of changing the project baseline).
References:
LESSARD, J., 2007. Project Management for Engineering Design. USA: Morgan and Claypool.
No comments:
Post a Comment