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.
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.
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. Don't worry, their stars will not shine as bright as those of hero developers working 12- to 16-hour days making mistakes. On failed projects, the heroes also get the blame.
4. Apathy and despair
In failed projects, at some point you realize that nothing you'll be allowed to do will change its course. This may come from a lack of empowerment, a lack of trust, a lack of resources, or a lack in yourself.
At this point, you stop trying to fix the problem and do what you're told. You are on the ship, you see the giant iceberg, but you don't care anymore. You're tired of the meetings, the recriminations, the accusations, the insinuations, the pressure, and the passing of the buck. Who cares whose fault it is? Let's come up with a solution. But you're past that. It's too late. You had that conversation. If they didn't listen then, why would they listen now? Sail on into the deep.
5. Delivery and failure
Remember the Obamacare website? Remember how people were baffled why they would release such a thing when they knew it wasn't going to work? I wasn't one of the people wondering. I've been on those projects where everyone knows it's not going to work but they've been told to do it anyway.
Mercifully, most failed projects get defunded, canceled, or deprioritized rather than delivered in a failed state.
After a failed project most people expect to experience more depression than that which actually comes. On any significant project, you've already experienced the depression, anxiety, and fear, so once the project actually fails and you're off the hook and you don't feel those things anymore. Oddly, the feeling you feel is one of relief.
Project failures tend to be from the top down. The underlying cause is almost always poor communication coupled with a lack of fundamental respect from members of the team. It's important for management to recognize these signs in order to avoid another disaster, but if the people on the project don't feel they can come to management, the failure will repeat itself, because no one in a position to make a difference knows what needs to be corrected.
This story, "7 stages of a failed software project" was originally published by InfoWorld.