Why Software Projects Fail
Brad Shuler has a theory on why software projects fail. The topic comes up from time to time during our conversations. It came up yesterday when we were commenting on a Robert Cringely article.
Here's the first few items on Brad's list:
- If the software is not the business of the company, the software is more likely to fail. (Think of a trucking company writing HR software, etc.)
- If the company won't go under should the project fail, the project is more likely to fail. (Diebold will not go under if its voting machine project fails.)
- A software project without true customer buy-in is more likely to fail. (True means customers are eager to have the software, even to the point of pushing for it.)
- A project where management doesn't know when to step aside and let the tech lead lead is more likely to fail.
Are you on one of these projects?
Re: Why Software Projects Fail
What about requirements?
I once was on a project that had literally 400 documented use cases, but no requirements. It failed.
Another project had no requirements other than "port our current software from the dark ages of green screens to the GUI realm". It succeeded..
How important are a well documented list of requirements? I am so sick and tired of having to write the requirements for the customer -- just so I can cover my bee-hind (three months later when I deliver and suddenly requirements are flowing like lava out of their ears..)