Karl Gallagher (selenite) wrote,
Karl Gallagher

  • Mood:

The Fallacy of Earned Value, or "The Project has No Clothes"

My friend Gerry Tyra sent this to me, and I thought it should get wider distribution.

The concept of Earned Value is eminently reasonable, so long as you don’t look too deeply for too long.

The concept of Earned Value is beautiful in its simplicity: define what is to be done, provide a schedule and budget to do that task, and hold someone responsible for doing it. You have defined scope, a "reasonable" budget and schedule from the outset, and accountability for getting it done. Along the way, large tasks are sub-divided into smaller, more manageable sub-tasks. So the Work Breakdown Structure (WBS) is born.

There isn’t anything here that an MBA can’t love. And if the effort is small, not too complex or short lived, the MBAs have every right to love it. But all of this planning is the first order term (i.e., the linear part) of the effort. Getting from project start to completion is a straight line. Or to put it another way, Earned Value is a dragster, great on short straight-aways, but it doesn’t turn well.

As the size, complexity and duration increase, other, higher order terms start to make themselves apparent. It is at this point that the most basic assumptions of Earned Value start to break down.

The first assumption is that the task at hand is well defined. If you are in a manufacturing environment, and have a set of plans for a product, this may well be the case. But if you are in a development environment, it is probably not the case. Rather, you are working your way through the problem, discovering the real complexity of the task. At this point, may I recommend Dr. Fredrick Brooks’ The Mythical Man Month and the concept of "one to throw away."

The second assumption is that human behavior is a constant when confronted with a changing environment. This assumption shows up all too often and is expressed in some form of, "If we change this one thing, and everyone keeps doing everything else the same, we’ve solved the problem." But people are constantly trying to improve their condition. Hence they are constantly optimizing what they do given their current environment.

The failure of these two assumptions results in the higher order terms that impede, if not doom, any large program using Earned Value. As these higher order terms become more dominate, the road ahead starts to look like a mountain switch-back, and any missed turn goes over a cliff.

The Second Order Term: The children are fighting in the sand box, again!

The Work Breakdown Structure creates a hierarchical tree structure. Each leaf in the tree is a self contained task. Each node in the tree is a combination of all the leaves and nodes below it. So each manager at each leaf or node knows what their task is and what their resources are. And their next evaluation (read "raise" and/or "bonus") is tied to their performance at that task. This is a great way to get a manager to focus on the task at hand, and not let his/her attention wander.

At the same time, it instantly kills all cooperation among the managers. When managers are evaluated solely on accomplishing their own tasks, they have no vested interest in helping another manager, and hence, the program as a whole. There are no "gold stars" for being a "nice guy." If it isn’t in the manager’s task description, it doesn’t get done. Helping someone else diverts resources and causes delays, which costs the manager personally. Any manager who ignores this reality probably won’t be a manager for long.

Initially this shows up as reluctance to cooperate. As time passes, it becomes obstructionism, where the manager tries to hold other managers, who are required to supply something to them, to the absolute letter of the requirements.

After all, it isn’t my fault that I’m late. The other guy didn’t get his job done on time, and so I couldn’t do mine.

The fact that the person saying this could have accepted what was available and gotten the job done on time, is irrelevant as to do so would imply some risk to his budget and schedule. And that risk is translated directly into the manager’s next raise. Therefore, it is better to find a scapegoat.

This also accounts for the "stovepipe" mentality found in such projects. Each manager is only looking down at those tasks assigned directly below him or her. There is little, if any effort to look across to other activities and optimize their solution for the benefit of the program as a whole.

The Third Order Term: The inmates have taken over the asylum!

With all of these managers focused on their own tasks, who’s minding the store? In most engineering organizations, that is the Chief Engineer and the Systems Engineering group. Their task is to look across the entire program and initially define the overall solution. Then, as the program matures, they make sure that all the pieces are really coming together correctly, shifting the overall design and implementation as need arises.

It should be immediately obvious that all right-thinking managers would resist these troublemakers from Systems Engineering at every opportunity. After all, any time a Systems Engineer wants to optimize something, he is making a change. The manager should have already found the most efficient solution to his localized task. So, a change always costs time and budget, therefore it impacts the manager’s next raise.

Starting with line managers, up through the program manager, this problem recurs, since any problem at a lower level also impacts the program manager. The obvious solution is to remove the problem by reducing the authority of the Chief Engineer and the control of Systems Engineering.

So, all the parts work, but it never comes together right. (i.e., the operation was a success but the patient died).

And going back to the sand box: Sure the program failed, but I did MY job!

The Forth Order Term: But it’s the way Grandfather did it!

As risk aversion becomes an all consuming quest, innovation is left behind. If I have used the same tools before to produce a similar product, I have some basis on which to estimate a new task. But if new tools are involved, or the product is different, how do I estimate the time and budget accurately? If the estimate is too optimistic, the chance of failure goes up. If the estimate is too conservative, it is non-competitive.

So innovation is avoided unless it is a solid requirement. And even then, many a manager has danced around the edge of the innovation without actually embracing it. Working at the "bleeding edge" of any technology isn’t much fun if it is your blood that is being spilled.

As it becomes more obvious that various innovations are not making it into the normal flow of work, upper management starts to look at their investment into research. Why invest in research if it won’t be used? So, R&D budgets slowly slide downward.

But this doesn’t adversely affect the current project, so it is okay.


Look around you. Have you noticed any of the behaviors described? Perhaps you have noticed other effects. If so, consider why sane, intelligent people would behave in such a manner. Perhaps it is because they are sane and intelligent and they are coping with a system that leads to such behavior.
Tags: engineering
  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.