Reason 4: Complete Inability to Define Requirements

OUR SCENE:

A conference room; several people seated, a whiteboard on one wall.

[Programmer:] Okay, let’s map out a couple of these workflows.

[Stakeholder 1: a high-level member of one division:] So we’re going with blue as the theme?

[Stakeholder 2: Stakeholder 1’s opposite number from a different division, which is at war with the other division:] No, I thought it was the coyote.

[Administrator of the agency handling a large contract funded by both divisions:] Don’t worry, it can be both ….

[Programmer:] Let’s think about how we register trainers. What information do we want from them when they apply?

[Stakeholder 2:] As long as we can make those menus that jump out have rounded corners, it’s okay.

[Programmer:] And we’re going to have to make them create an account to get to the application form anyway, or the whole internet will be spamming us. So that means a whole authentication and login operation.

[Administrator, recalling bitter experience:] Oh no, we can’t do that again!

[Stakeholder 1:] Do what? Round corners?

[Programmer:] No, he means the security issue.

[Stakeholder 2:] The menus are a security issue? How can that be?

[Programmer:] They’re not, don’t worry. But what fields do we need for the trainer application? First and last name, address, city, state, zip, of course. Phone number? Or two? Email, gotta have that….

[Stakeholder 2, stiffly:] Well, if we can’t have a modern site why bother.

[Administrator:] Why don’t we just work up a draft and you can tell us what to change?

[Programmer, dubious:] I kind of need more to go on, like isn’t there some kind of license number or credentials or something? I mean, I have to build data tables….

[Stakeholder 1:] Well, if you’re going to insist on those jumpy menus I have to insist on the blue theme.

[Stakeholder 2, refusing to look at Stakeholder 1:] I guess that’s all we can do today. [Starts gathering her things.]

[Programmer:] Wait, don’t we want some kind of approval process? I mean, who are we sending these applications to, anyway?

[Administrator, giving Programmer a hard look:] Don’t worry, the contract, I mean the web site is just fine, we’ll give you a call to look at a draft Friday.

[Programmer, in dismay:] Friday? Wait, it’s Wednesday! We don’t even have a site layout yet, I can’t get login accounts implemented and a trainer application working in two days!

[Stakeholder 1, coldly:] I thought you said you guys could build this thing yourselves?

[Administrator:] Oh no! It’s not a problem! We’ll figure it out and work it up.

[Stakeholders 1 and 2 depart.]

[Programmer:] Hoo boy, talk about set up to fail!

[Administrator:] If you don’t like it I have a stack of applications THIS BIG [indicates a height of about two feet with his hands] from people who want your job! [Walks out.]

[Programmer, going to white board:] Holy s***, what do we gotta have here? At least two login groups, trainers and admins…..

[Trails off muttering to himself. Administrator looks back in and nods in satisfaction: the contract is working just fine.]

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.

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.

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.