Why Software Projects Fail, part 3

Reason Number 3: Most organizations do not have the skills to properly scope an application project.

I won’t single out the entities that I’ve seen declare the “scope” of a project in a series of vaguely worded requirements – inevitably subject to endless veto as developers trot out one pony after another. Projects go wildly over budget and years past deadline. Everyone ends up hating everyone. And all the money spent is simply wasted.

A properly scoped project discusses data requirements in advance, including user interfaces and permissions. The project will also demand a data manager, someone who can keep users from deciding to split the number from the street in address columns, six months into creating user interfaces. Someone who works hard to pin down what data will be collected, then works hard to keep people from capriciously changing that specification.

That’s what change orders are for. That’s why they cost a lost. That’s why they always should.

Enough for now; I look forward to discussing over-complexification and following fads in upcoming parts.

Why Software Projects Fail, part 2

Reason Number 2: Most organizations utterly fail to understand the complexity of developing enterprise software applications.

I watch this kind of meltdown happen with depressing frequency. “We can do it in ninety days!” is inevitably the tolling of the death knell.

Let me be clear about what I’m discussing: I’m talking about applications with a broad audience, for instance web sites holding State databases, accessed by hundreds or thousands of users with accounts. Anyone who has managed an enterprise directory knows this involves serious architecture. This is what distinguishes enterprise applications: they have a much larger scope.

It’s not just the complexities of authentication and authorization that make this job tough. It’s requirements like availability, redundancy and failover. And coding for security, and dealing with the inevitable attacks. And coding to standards, so teams can work together. And unit testing, and integration testing. Would you like me to go on? Because this is a huge list, and organizations that don’t know this are doomed to ugly, ugly failures.

Why Software Projects Fail, part 1

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.