Such a negative title: Why Software Projects Fail. And part 1, no less. Is this too depressing?
Don’t worry: there will be a corresponding series, Why Software Projects Succeed.
But for now, I actually do want to depress you. I’m not even going to quote figures on how many application development projects fail, though there are all kinds of numbers. If you’re involved in this business, you SHOULD worry about these issues.
Which brings me to Number One on the list of reasons that software projects fail:
1. Organizations should not be developing software if they are not primarily software development entities.
Sounds harsh, doesn’t it? As if I’m saying, run to some development house for every specialized piece of software you need? But no, that’s not it. Many organizations have strong Excel and Access talent, or decent web language skills. Small custom applications are totally appropriate for them to build in-house. And it’s utterly to be expected that these applications will sometimes be down, for hours or days, and it’s not that big of a deal.
What organizations like charities, schools, courts and government administration do NOT have is enterprise application development project management skills. If people are going to be making panicked phone calls if they can’t use their application, Mom and Pop should not develop it. If legislators are going to rely on it, agencies shouldn’t take a do-it-yourself approach.
Unfortunately, very, very often they do. From here the branches on the tree of disaster can go every direction, from the inherent risk of relying on the one “guy that does all that stuff” to the software and infrastructure failures that will dog every entity learning to manage IT.
Still, don’t take my word for it. I try not to grind people’s face in “I told you so.” But the process of a software project meltdown is too ugly, and I’ve seen it too many times.