I think the most amazing thing about spectacular project failures is that they happen one day at a time. How do you get 170 million USD over budget? One day at a time.
Given the size of many of the largest failures (hundreds of staff members), there have had to be a number of people who recognized early on that the project was not going as it was supposed to. And still, someone made the decision to continue! In the FBI virtual case file project linked to above, the US Congress approved another $123.2 million for a project whose total cost would now be $581 million (instead of $458 million).
If the project is late and you are asking for, you know, a hundred and twenty million more, I would expect that someone would ask whether the whole project should be re-evaluated. But a re-evaluation didn’t happen until well over a year later. There is something patently absurd about that. Reminds me of Bil Dwyer’s fifteen wives clip on Comedy Central: “Imagine the nerve to look around at your fourteen wives and think to yourself … one more.” . A hundred million $ more, and were done.
Why does this happen?
I’d attribute the failure to re-evaluate the project to number of cognitive and organizational biases. Obviously, the cause of the failure itself may not be the biases, but rather the things that were done by those responsible for the project. But when you go over the budget and deadline and seem to be far away from achieving the original goals, why isn’t the project cancelled or re-chartered?
In an article (available here and also discussed here) Shore (2008) summarizes a number of cognitive biases as shown in the table below:
(Shore, B (2008). Project Management Journal, Volume 39, Issue 4 p. 5-16)
“We can still do this”
The specific bias are not as important as the overall dynamic that causes failed projects to continue. Whether it is sunk cost, conservatism or illusion of control, the bias cause those responsible for the project to believe that they can still salvage the project, that all is needed is a bit more time, resources or people.
Bringing about epic failure by avoiding the perception of failure
There is a good reason for this. Most people consider revising the project goals to be an admission of failure which reflects badly on their careers and competency, hence preferring to stick to their guns. This may work in some smaller cases of failure and in cases where it is possible to trade quality for productivity, such as “homework” -type written assignments. But for projects where the quality is discernible, the number of people involved is large and increasing the number of people makes the project less likely to succeed – such as IT/IS projects – doing more of the same (which is the first reaction) is just not the answer.
As Steve McConnell said about project recovery:
“Remember, the real problem at this stage is not developing the product in the shortest time possible or creating the best possible product: it’s completing the product at all. [...] If you’re caught in the middle of a political skirmish rather than a product development, the project-recovery plan [...] won’t be of much help, and you should choose your actions accordingly”.
Doing what can be done
Here is a brief four-step program for doing what can be done to rescue a failing project. More details can be found elsewhere!
- Reassess the overall situation and pinpoint obvious problems. Any 12-step program begins by recognizing the problem. Without that, one ends up doing exactly what McConnell said: chasing the fastest completion or the best product, both of which are unlikely to be accomplished.
- Revise your goals. Since you have shown that you cannot do what you attempted to do, revise what you are aiming to do so that at least something can come out of the project. Set your goals to something more achievable.
- Restore morale. A important point in failed projects is that you are likely to be facing a morale problem already. While the “official” recognition of failure is sudden, many people are already overworked and demoralized. Do what you can to fix the people problem before continuing.
- Track the project meticulously to avoid sliding back into the abyss. If you don’t get strict, you will continue to fail each day. As said earlier, spectacular failures result from day after day of slips. So stricter tracking of progress is the only way out of the abyss. Otherwise, the same slips that got the project here will continue.
There was an interesting quote on the “Diary of a Failed Startup“:
“How do you tell if you really are doomed?” – “If nobody cares about what you’re doing and nobody on your founding team cares enough to change that, then you’re probably in trouble.”