Page 73 -

For example, consider a software project where the requirements phase of a project is sched-
uled to last for six weeks. Over the course of those 6 weeks, 2 software engineers are sched-
uled to work on the project at 75% allocation, for a total of 360 effort-hours (75% of a 40-
hour week is 30 person-hours per week per engineer, multiplied by 6 weeks). At the phase-
end review, the project manager finds that the phase actually took eight weeks, and the soft-
ware engineers put a total of 390 person-hours into the requirements phase. The earned
value for this phase is 360 – 390 = -30 person-hours. In other words, the project overran the
budget by 30 person-hours. The project manager can even calculate the actual cost (in dol-
lars) of the overrun by multiplying those 30 person-hours by the average cost per hour that
the organization pays their software engineers (plus the average overhead cost).

Another way earned value can be used is by generating the cost performance index (CPI) for
the project. CPI is calculated by dividing BCWS / ACWP and multiplying by 100 to express
it as a percentage. A CPI of 100% means that the estimated cost was exactly right and the
project came in exactly on budget. If it is under 100%, the work cost less effort than
planned; a CPI greater than 100% means that the estimate was not adequate for the work
involved. CPI can be used either to compare projects or phases within a project. For exam-
ple, if the programming tasks took twice as long as estimated but every other type of task
in the project took less time than estimated, the total variance for the project might still be
low. However, the problem can still be pinpointed by calculating the CPI for each phase of
development. If the CPI for the programming phase is well over 100% while the CPI for
all other phases is less than 100%, then the project manager should pay extra attention to
the estimates for the programming phase in future projects. It is also possible to compare
the overall CPI for various projects against one another to see if the CPI goes down over
multiple projects. If it does, that shows that the team’s estimation skills are improving.
CPI can also be used to find systemic process problems. For example, if, over the course of
many projects, the CPI in the coding phase is much lower than the CPI in the other
phases, it could mean that there are either problems with the way programming estimates
are generated or problems with the execution of the coding tasks. It may also mean that
there are uncontrolled changes, which are going unnoticed until the team begins coding.
The project manager should take this low CPI as a hint to look more closely at exactly
what is causing delays during the programming phase.

In the example given above, the CPI would be (360 / 390) * 100 = 92.3%. This means that
the team is only operating at 92.3% efficiency. Since the CPI is below 100%, the team did
not perform as efficiently as expected. Since these numbers were just for the requirements
phase, the low CPI could simply mean that the team underestimated the requirements
tasks. If the average CPI for the requirements phase in the team’s other projects is around
90%, then it means the team systematically underestimates requirements tasks. However,
if it is much closer to 100%, then there was a specific problem which caused the team to
lose effort in this particular project. The project manager can take appropriate action
depending on which of these cases is true.

PROJECT SCHEDULES 65