Douglas Adams, English author and humorist, wrote, “So once you do know what the question actually is, you’ll know what the answer means.” While a funny sentiment, the thing about satire is there is always some basis in truth. One of the realities of software projects is that they unfortunately fail sometimes. Well, “sometimes” might be a bit disingenuous. Depending on what study you might be reading at the time you could see failure rates from 50 to 80 percent. The number of projects that fail is rather staggering.
Perhaps the reason for so many failures lie in the fact that we’re struggling with an answer when we didn’t even know what the question was. There are many questions that we could be trying to answer. Questions like, “How do we make this software more intuitive so it is easier to train new users?” Or, “What will we do when this hardware/software platform is no longer supported?” And possibly, “How do we do this cheaper…faster…better…more efficiently?”
The thing is, we might be able to boil all these questions down to what is the very most important question for every single software project: “Why?” The real question we MUST have an answer to is the question of why we are doing this software project.
A software project is costly, difficult, stressful, time-consuming, and at least a few other really unpleasant things. If your project includes upgrading or replacing existing legacy software, think about how long that software has been in place. Has it been 5 years? 10 years? 15 years? Or maybe longer? Even if you could turn this conversion project around in a couple months (which would be incredibly fast) the lasting effects of your decision to upgrade are not isolated to the period of time it takes to convert. Chances are the finished product will be around a long time after you have completed the upgrade. That’s just the nature of a mission-critical business application.
Once you can adequately answer the question why it becomes so much easier to obtain buy in. Buy in is critical to success of your project. Buy in is what will motivate your team past the unpleasant things like cost, stress, and the time-consuming nature of this endeavor. We know you don’t want your software project to fail. Nobody wants to be another statistic. We need to start by effectively answering the question of why. A clear answer to the question “why” is going to give you and your team a very clear vision for the future of your software application.