How to Lie with Earned Value

How to Lie with Earned Value

Tristan Yates

Here’s a mystery for you. Every week in a certain company, every project manager turns in a chart for each of his or her projects.

The first thing management looks at when they see the chart is the small color-coded box in the corner that illustrates the overall project status. Each project is rated green, yellow, or red, depending upon the health of the project.

Nobody wants a yellow or red project. We used to say that yellow earned you a trip to the doghouse, and red earned you a trip to the woodshed.

Our director liked that joke so much that he included a slide with a red woodshed in his weekly PowerPoint.

The color of the box is the result of an earned value analysis calculation based upon the rate of cost and schedule performance compared to the baseline project plan.

Late or incomplete tasks and/or higher costs will push your project into yellow or red territory.

Once you’re there, completing other tasks more quickly and under budget will help return the project to a green status. (Here’s a sample earned value calculator.)

And now the mystery. In this company, a certain software development and integration project was coded green the first week, and green every week after that for the entire life of the project, a period of four months.

Yet, the project was a complete failure. It was late, it blew the budget, and nothing useable was ever delivered to the customer.

How did this happen? How did this disaster stay green for so long? Artful manipulation of the system.

Earned Value Cheat Sheet

The project manager knew how to beat the system. Here’s the playbook.

Pad the Schedule. It’s the oldest trick in the book. If a project looks like it will take three months, tell management it will take four. If things go wrong, the manager can still beat expectations or at least hide the problems for a while, keeping up appearances.

Push Problem Tasks Forward. Putting the easiest tasks at the beginning of the project and the hardest tasks at the end can keep a project green for a long time.

Bump the Task Completion Percentages. What’s the difference between a task that’s 20 percent complete and one that’s 80 percent complete? A project that’s red and a project that’s green. The longer the task, the larger the “benefit,” but changing the completion percentage of any subjective task will help the earned value numbers.

Re-Baseline the Project. The project manager waits until a scope change or other change request, and uses that as an excuse to redo the project schedule. The project instantly turns green because actual progress now matches expected progress.

Late Integration. Most problems with IT projects emerge during integration and testing. By putting these tasks at the end and then marking them as partially complete, technical problems were hidden for the entire life of the project.

The earned value scorecard that management put in place was designed to be a reliable indicator of project health. Unfortunately, it was no match for a determined project manager who had the ability to structure work and measure task completion and was willing to take whatever steps were necessary to keep it green.

Next Page: Whodunit?

What really went wrong with the project? Here is the history, according to the technical lead:

“We pitched the client an economy car, and they came back and asked us to build a stealth fighter in the same time frame. I said it was impossible, but my manager said to try anyway. And now here we are, with about 10 percent of the stealth fighter completed instead of 100 percent of the economy car.”

That eyewitness account is a lot more useful than a color code, right? Based on this, it looks like the project collapsed in the first month, during the design phase.

Yet, the project plan showed the design phase as successfully completed, and the earned value system had the project green for months afterward.

It sounds like the project manager should have called the design phase a failure and sent everyone back to the drawing board.

But before we point the finger, let’s think about what would have happened.

The project would have turned red barely three weeks out of the gate. It would have been the quickest trip to the woodshed in project management history.

This raises a very interesting possibility. We’ve already established that the project manager cheated the earned value system to make his project look better.

But did the earned value system actually encourage the PM to make bad decisions?

Could a simple scoring system designed to track project performance actually contribute to a major project failure?

Speed vs. Quality

Let’s say that we have two project managers, Jack and Jill. They are both experienced, but Jack has a tendency to cut corners on tasks and ignore potential problems, while Jill is extremely cautious and is very careful to check work quality and avoid risk. Who is the better project manager?

According to our earned value management scoring system, Jack is better.

He completes his tasks more quickly and at a lower cost. The system ignores the fact that Jill’s team consistently delivers higher quality work.

It’s not that earned value promotes poor quality—it is just blind to quality.

From the perspective of earned value, quality on all tasks and all projects is equal and absolute.

When a task is marked complete, the system assumes it will meet or exceed the required level of quality for the project.

This assumption is necessary in order for the earned value metrics to be used as common yardsticks.

However, it is obvious that there’s a relationship between cost, schedule and quality. We’ve all seen co-workers rush through tasks and cut corners in order to meet a deadline.

As a rule, rushed work is sloppy work. The problem is that earned value rewards the rush.

As project managers start to understand the system, they soon realize that they don’t get any points for “extra” quality.

They get credit for racing through tasks as quickly as possible, meeting only the minimum accepted level of quality. Any extra time spent on any single task threatens their earned-value metrics.

The conflict between our technical lead and the project manager now seems predictable.

The project manager’s evaluation depended on speed, but the technical lead was evaluated on design quality.

And because the project manager was the one with the power to decide when the task was complete and to move on, speed won over quality.

How this conflict is resolved in other organizations that rely on earned value depends upon the quality control procedures the organization has in place.

In the above case, an independent design review could have saved the project by sending it back to the drawing board right away.

Next Page: Better late than never.

Better Late Than Never

There are many reasons why technology projects fail. Requirements aren’t accurate, project scopes aren’t managed well, design flaws emerge, vendors don’t deliver, early estimates are poor, etc.

But all failed projects have one thing in common: At some point in the project, the team was spending time and money but not completing the tasks in front of them.

This lack of progress is exactly what an earned value calculation is designed to catch.

If progress indicators fall for two weeks in a row, it is likely that progress on the project has stalled.

At that point, management’s fear isn’t that the project is going to be delivered late.

Mathematically, it’s already going to be late. Management is frightened that nothing will ever be delivered to the customer at all.

An earned value system isn’t designed to punish people for being late. It’s designed to help management prevent a late project from becoming a failed project.

Our director was misusing the system by punishing people whose projects turned red.

Instead, he should have used the metrics to focus his attention on the right projects and provide assistance.

Being a project manager is a tough enough. The role generally has much more responsibility than actual authority.

And training is often minimal or nonexistent, leaving most of us to learn on the job from our own mistakes.

Project managers don’t need another reason to be punished; they need more support and mentorship.

Staving Off Disaster

About a month into the project, I called the project manager and actually suggested coding it yellow, as a warning to upper management.

I had discovered that a very similar project was having technical problems, and I had difficulty seeing how either project would be completed on time, given the obstacles.

“I’ll take any help that you can give me, but this project has to stay green,” he told me. “That’s straight from the top. It can never go yellow. This thing stays green, no matter what.”

I tried to argue the merits of turning it yellow, but he was adamant. “Tristan, this project will be green when they’re walking me out the door.”

And as the project progressed, I was actually proud of him. He was able to maintain his earned-value metrics for months, giving management exactly what they wanted. A green project.

In the end, he never got his trip to the woodshed. They just walked him out the door, as he had predicted. He had seen it coming of course, and had another job lined up.

In the absence of a final customer deliverable, he could have kept his project green for another year.

There was only way that management could have stopped this person from cheating was by removing the incentive to cheat.

The proper response by senior management to a project with deteriorating earned value metrics is assistance, not punishment.

Our director knew how to calculate the earned-value metric. He just didn’t know what to do with it.

Yates is an independent project management and project management office implementation consultant who works with commercial and government clients in the United States and Asia. He holds an PMP and MBA and has been a part of the industry for more than 15 years.

Copyright © 2005 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in CIO Insight.