For an overview to Earned Value Management, please refer to this article.
My company adopted Earned Value Management in earnest just as I moved into a mechanical engineering lead role, so I found myself in a position where I was being asked to give percent complete estimates of my teams’ many tasks. However, I commonly found the tasks I was asked about weren’t those we were actually working. To compensate, my team leads implemented a lot of hand waving and fuzzy accounting to produce numbers they could report to the program managers without getting asked a lot of difficult questions.
EVM is a textbook example of a “garbage in, garbage out” system. It heavily relies on its parameters being written correctly from the very beginning. Any inaccuracy at the start is magnified later. And unfortunately, the people determining those initial parameters sometimes don’t know what they’re doing, or more accurately, they know EVM but they do not know how to properly apply it to the work ahead.
Through several programs, I noted two main weaknesses in EVM. Unfortunately these weaknesses are also the main factors in its calculation.
EVM heavily relies on the master schedule.
The first weakness in estimating earned value is its reliance on the program’s integrated master schedule (IMS). The IMS lists your tasks, tells you when to start them, tells you when they should be complete, and the budget assigned to each task. All of which are vital to calculating earned value. As a result, if the schedule is garbage, your earned value will forever be inaccurate.
In many cases, the IMS is written well before the engineering team is in place, and even before the scope of the job is fully understood. Further complicating the matter, the schedule may not even be written by an engineer with familiarity of the hardware. This results in a schedule whose tasks don’t match what you end up designing, or the budget is weighted incorrectly, or tasks are in the wrong sequence or have incorrect or unnecessary prerequisite/successor links.
In fact, I wonder how they could have gotten it so wrong with most schedules I review. In some cases, if I catch the IMS errors early enough, the program manager will allow the necessary modifications. Other times, they determine a Baseline Change Request (BCR) is too much of a hassle, so the team is stuck performing to incorrect expectations.
Percent complete estimates are open to interpretation.
The second weakness is allowing human interpretation to estimate weekly percent completes of the tasks. Engineers are naturally conservative, and have a tendency to under report completeness. After all, they don’t want to report something as 50% complete and then be wrong later. This obviously can drive EV into the red over time, which is why many programs do not allow a true percent complete. You can only report 0/50/100 or 0/25/75/100, etc. It keeps engineers from taking weeks to go from 90% to 100%.
Knowing engineers are conservative, some team leads pad the numbers because they know the team is further along than what it reports. However, problems arise when a team lead gets too aggressive and reports a task is nearly complete when it isn’t because he/she is desperate to show progress.
While these practices may keep the spotlight off your team in the short-term, these are very dangerous games to play. Not only will they wreak havoc in the long run, they’re antithetical to the heart of EVM.
In a future article, I will discuss the tool I created and the checks I implement to ensure the earned value I report as a team lead is as accurate as possible.