Today I was reading an article titled “Why Big Software Projects Fail: The 12 Key Questions” by Watts S. Humphrey. It was a very interesting read indeed and inspired me to follow up on the subject.
It is no secret that the history of software development is littered with colossal failures. Reasons and excuses are many and you can find them all over the place. Probably if you lift a rock in the desert you’ll find an excuse for a software development project failure underneath. There are cases where the excuses are valid but truth be told, in 99% of the cases the reason are simply human factors.
According to Watts S. Humphrey, the main problem with software development is managing visibility. In his own words:
Why Is Management Visibility a Problem for Software? The problem is that the manager cannot tell where the project stands. To manage modern large-scale technical work, you must know where the project stands, how rapidly the work is being done, and the quality of the products being produced. With earlier hardware-development projects, all of this information was more-or-less visible to the manager, while with modern software and systems projects it often is not.
Some people might argue that this is an overstatement and at some point it is. Managers usually have a rough idea of where a project stands although not with the precision required by large projects. With small sized projects this is tolerable and these kinds of projects are usually a success, however as Humphrey say: “… as projects get bigger and communications lines extend, precise status information becomes more important.”
Along the same line we can say that another big part of the problem is change management. When we go to a car dealer to buy a new car we can tell him the brand, the model and what accessories we want and he will probably give us exactly what we asked for. Lots of the stuff we buy in the real life is like this, we just acquire a product that someone else made for us to consume.
With custom software development, most of the times this is not true and we can’t apply the same rule. We have to think of a software project as a living entity that evolves and changes with time. What was right today might not be tomorrow, the requirements change as our clients’ business needs change. If we don’t take this into consideration most likely the project will fail.
So, if things are like this; if the statistics are against us and most of the projects fail, are we all doomed? Should we pack our bags, go home and forget about software? Sometimes I tempted to do so and open a grocery store in some tiny town in the country… but I digress.
The real question is what can we do to win this fight and deliver a successful software project? This might sound naïve but I think the answer to that question is with trust and a sense of community and collaboration. All the parties involved, including managers, developers and client all alike need to trust each other, stay in permanent communication and have a strong commitment towards a project success. If any of these conditions isn’t met the project will most likely fail.
In my next blog post I’ll talk the current trends in the software development to help avoid these common problems, live long and prosper in this business and don’t die of a heart attack when you turn 35.
- Pablo Bessone