Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

7 stages of a failed software project

Andrew C. Oliver | July 22, 2016
Know the signs! You might not be able to affect the outcome, but at least you'll recognize when to fasten your seatbelt and update your resume

7 stages of a failed software project

I've written a lot about how to avoid failure or how to pursue success. I've written a lot about what makes a successful project. But this article isn't about those topics.

This article is about what it feels like to be part of a project as it fails, when you realize you can't pull it out of a nosedive.

1. Optimism

A while back, NPR reported on a study of depression and found that optimism was a key part of depression. In order to have your hopes and dreams dashed, you must have them in the first place. To keep soldiering on, you have to believe it will get better even if you're headed in a different direction.

A failed project begins much the same way. A failed project begins with hope. A failed project begins with optimism. In fact, failed projects begin with more optimism than successful projects.

On a past project, I gave a rather pessimistic estimate based on the environment the project would be completed in. A project manager came in and slashed my estimates based on a technical analysis in Microsoft Project. The project ran over by almost exactly the amount of time he had slashed. He was optimistic and believed that the project could be completed in the same amount of time it took in other environments. I didn't agree.

2. Blame

At some point in a failing project, it becomes clear that things are not going well. Clearly, functional behavior in this situation is to identify the problems and come up with remediation. In most failed projects, however, more energy is spent on the dysfunctional impulse to blame.

This is not to say that people can't be the problem; they often are. But the process of assigning those people blame is more important than the faults those people may have. What exactly are you trying to correct and how are you going to correct it?
The thing about blame is that, in all but the smallest projects, everyone makes mistakes.

During the blame game, no logical analysis is done on whether someone writing a buggy query caused more problems than the week and a half of network or equipment outage. Besides, why didn't you tell us you needed the dev environment to work? You should have made that clearer.

3. The crazy mad coding session

On failing projects, there are always heroes. You can take that in a capability-maturity-model way: a lack of process that makes you depend on skilled people (yuck) instead of cheap labor. Or you can take it in a Marvel Comics way: Push people with extraordinary abilities and a high tolerance for pain to work crazy hours to make things what they should have been all along.


1  2  Next Page 

Sign up for CIO Asia eNewsletters.