Why Software Projects Fail
There is a high risk of failure with any software implementation project. In my experience, there are two main reasons why software projects fail (there are plenty of other reasons as well, but these are the ones that seem most prevalent):
- No one "owns" the data: No one is responsible, as part of their job, for entering the data and keeping it up-to-date. Everyone wants the data; no one wants to put the data in. For every project, we need to be very careful to identify who is responsible for owning the data and making that explicit.
- The system takes too long to develop and is too complicated to maintain on an ongoing basis: This is probably the most crucial aspect of project failure. Many organizations are subject to a heavy dose of "feature creep." People get excited about a new system and imagine all the possibilities, which they identify as requirements. But all of these features are not all required for the system to do its intended job.
About each proposed feature we should be asking: Why is this needed? What problem are you trying to solve? Perhaps there is a simpler solution that the stakeholders haven't considered. I've often seen stakeholders get tangled up in how they are going to achieve something, when all they really need to define is what they are trying to achieve. The software developers provide the expertise in the how, and we should strive to look for the simplest, most direct way. That's where I find writing use cases to be really helpful in zeroing in on that simple solution.
In my experience, a simple system is more likely to be flexible and adaptable when change inevitably comes, and is more easily expanded or integrated with other systems. But even more important, when a set of requirements are simple, they are achievable in a shorter amount of time, people can start using the system sooner, and adoption will be higher. If stakeholders have to wait through a long development cycle, they lose interest, look for other solutions, or otherwise become negative about the system.
Of course, there are other reasons for failure, as I said, but I think they are mostly tied to these two. Some that I can think of right off:
- There is no executive sponsorship of the project. Employees take cues from their leadership, as they should; if something doesn't seem to matter to the leadership, then employees will resist.
- The user interface is not intuitive and does not match the user's workflow. Again, use cases can really help with this. We should strive for zero training required on all systems.
- The system does not integrate with the front-line workers' everyday jobs. Ideally, each new system should replace an old job responsibility or in some other way make peoples' jobs easier. Users will rebel every time if they see the system as something extra they have to do or something that doesn't directly benefit them. If users feel they have to maintain the system and a shadow system to achieve their goals, they will definitely reject the system in favor of their shadow methods.
I have learned a lot from developing systems that failed, probably more than I would have learned in a course on software development or even in designing successful systems. The primary thing that I have learned is that system development is not really about technology or specifications or requirements. It is about people. Understanding how people work, what they need and what they want is the key to developing a successful system. No matter how much training and marketing you provide, you will never be able to make people use a piece of software that they can't connect with in a basic way.