Section 5.2. Why Software Projects Fail | Java for ColdFusion Developers

5.2 Why Software Projects Fail

Seventy percent of software projects fail. Seventy. There are a number of reasons for this. Some of these reasons are just as insidious in Web application projects. Understanding and avoiding these pitfalls is crucial to the success of your project.

5.2.1 Inadequate Gathering of Requirements

Gathering requirements is very important to a project. Because it sounds almost too obvious to state, many programmers even overlook this stage for smaller projects. In my view, conducting smart interviews of the important players in the problem domain in order to arrive at the true requirements for a system is the key to a successful project. The inability to gain access to these players is a major reason why software projects fail. It can be perceived that a program is being written, so shouldn't the programmer have everything she needs to get the job done? Executives, bank tellers, teachers , consultants , janitors, baseball fans ”whoever is of central importance to the project must be included in this discovery phase. Find out who they are. Write down a list of questions specific to their role in the problem space. Write down their answers. Compile all of this information to help you when you start writing use cases, scenarios, and planning your program's structure.

This can be a painful stage in the project. People who are non-programmers, but who are a key part of the problem domain, can find it difficult to describe their goals, their role, or the forms they use clearly and precisely enough for you to easily translate these into facets of the program. Interviewing people in groups often gets everyone (but you, the programmer) involved in a hot and heavy debate about company policies; this is a terrible waste of time (imagine a Dilbert cartoon). On the other hand, interviewing players separately can create confusion about system dependencies and interoperability. This may mean that you end up hearing a lot of redundant information and have trouble circling in on certain issues. One way to solve this is to locate certain areas of the project, and interview a couple of the players in those areas of the problem domain. Then go back and write up what you've found out in ways that we will describe below. Go back to your interviewees and have them look at it. Have them tell you if it is accurate in describing the interaction. Generally this will prompt one or two things that were forgotten or glossed over to get teased into the foreground. Then perform this process for the remaining areas of the project. Meet with a couple of key people once it is written up to get sign-off on the project requirements. The "requirements of a project" is another way to talk about the "project scope": the number and complexity of requirements indicate its scope. This brings us to reason number two that software projects fail.

5.2.2 Scope Creep

You must be vigilant and protect your project and define clearly and specifically what exactly the project will entail. That means that you decide what a person is within the scope of your application, and present this material to the client for sign-off. If the client agrees that a person (within the world of your application) does not need to have a middle name , but only a middle initial, and then wants to change this later, you need to rewrite the definition of the database, the code that accesses the data, and the business logic that goes along with it, and then probably the code that presents it. This happens with frequency, and is a vexing issue in Web and software development. It is vexing because it is rather unreasonable and most likely unprofitable to try to define such minutiae before the contract is even signed or the project bid is won. Dealing with these issues is not particular to Java to be sure, or even software development. And while this lack of definition is no one's "fault" and can draw out the project, it is not scope creep. Scope creep is the demon child of this lack of definition and the developer allowing the client to drive the project.

Scope creep is the phenomenon in software development when the scope of the project gradually becomes larger and larger than was originally envisioned . Generally clients are responsible for trying to sneak in seemingly innocuous features that leave developers trying to please the client or to finally just get the project done. It can happen because a new version of some highly anticipated software was just released, and your team wants to incorporate the snazzy new features that the product makes available, or (usually) just does in a different way.

5.2.3 "Wouldn't it Be Cool if We "

You have no doubt heard someone, at some time, say, "Wouldn't it be cool if we did X," where X represents some smooth new thing the program should do (if it's a Web project, it might involve Flash or XML). Though related to scope creep, this phenomenon is different ”and even more deadly to your projects. "Wouldn't it Be Cool if We " is a killer.

"Wouldn't it Be Cool if We " is a frequent reason that software projects fail. It means a number of things. It means that your scope creeps. Your timeline increases . Your costs increase. Your code bloats. You run serious risks of breaking good, working code ”because generally what would be cool is something new that the programmer has little experience in.

The client never cares. The client, 9 times out of 10, could not care less if you parse XML with SAX or DOM. And SAX is not cooler than DOM. Or vice-versa. It doesn't matter.

The reason the client doesn't care is because she generally doesn't even know. In my experience it is rarely the client and almost always the programmers who invite themselves into more work, more confusion, and more problems with "Wouldn't it Be Cool if We ." Clients rarely pay for, appreciate, or even know about "Wouldn't it Be Cool if We ." However, somebody is paying for your time ”whether or not you're making money.

In American business, the average employee costs a company twice his salary to employ . That is, if your salary is $25 per hour, it costs your company $50 per hour for you to work at that company. They have to pay for janitorial services, air conditioning, 401(k), lights, insurance, and so forth. "Wouldn't it Be Cool if We " not only hurts projects and clients, it hurts companies. When a company has too many "cool" projects that aren't profitable, it goes out of business.

If there's something really cool that you want to do ("Flash MX now allows us to use embedded video "), then suggest it at the first definition meeting. If you haven't decided on it by then, wait until next time. If there is a "good reason" that you need to do something cool halfway through a project, here's a test: If what you want to do is actually worth doing, then you should be able to explain to the client what you want to do and why it is worth changing horses in midstream. If clients think it is cool too, they will pay for it to be done the cool way. If the client won't pay for it, why should your boss?

Of course, none of these problems stated above suggest a direct development methodology. They simply illustrate the need for having a plan and sticking to it.

Top