I am always amazed at how many software projects fail. Most of these projects have great people working on them, doing the right things, and yet the project still fails. Even if the overall project is successful, it has usually failed in some way: it’s late, it’s over budget, or it’s missing key features. It is almost impossible to find a software product that hasn’t failed in some way, large or small. And this all occurs even without the obvious reasons for failure such as bad management or bad execution.
Every once in a while all of us need to stop and ask ourselves why this occurs. Some of the greatest minds of our time have examined this question, but a high level of project failure still endures. And we certainly keep trying. Each day thousands of new projects are launched, despite the imposing odds of failure. We follow those who came before toward the edge of the cliff like lemmings, thinking that we know better.
Every project failure comes from a seemingly unique problem that couldn’t have been foreseen. Therefore it is hard to learn from that and transfer it to your next project, because that project will have a whole unique series of problems. The only way to gain traction is to step back from the individual problems and look for a common source. In my experience, for most software projects, the problems change but the source of those problems stays the same: an unwillingness (or inability) to adapt to a constantly-changing reality.
That is why planning and proper documentation of requirements is so critical. We shouldn’t document things and hope that they will not change. They will. Instead, we need to elicit and create requirements with an eye towards identifying when change is occurring so that proper adjustments can be made. Software requirements documentation provides an early-warning system for unexpected change, and it’s up to you to react appropriately. Once you have accurate requirements, the identification of problems and issues becomes obvious.
Agile development is an attempt to solve the problem of change, but it is not the entire solution. It is certainly helpful to have a more adaptable development process, but that doesn’t help if your business processes and strategy are not equally adaptable. It is like a strong link in a weak chain: the chain will still end up breaking when the pressure increases.
The solution is more a change of attitude than process. Be willing to abandon your most dearly held belief if it proves to be false. Do not hold fast to outdated information and goals. And most importantly, be on the lookout for changes occurring and quickly adapt. With complete, accurate software requirements, it’s much easier to identify the early impact of unforeseeable change. But it takes the right attitude to accept this new reality and find a way to adapt, before your project becomes extinct.
