Yesterday I stumbled upon an article about why software projects fail. Though hardly you can find any surprising claim while reading, it is nonetheless a quick paper you can hand over to your colleagues and/or managers when trying to enhance the chances for a successful project.What I find quite interesting is the table near the beginning, the one titled “Project Challenged Factors”. What draw my attention is that the “other” item weights more than each other single entry in the top ten. In other words the causes for challenging projects are so widespread and so equally important that there is no a main culprit.
We programmers are working on a so complex and delicate mechanism that any one in hundreds of factors could drive the entire stuff crazy. On the other hand the number of variables involved is so high that it is not possible to shot at one target to likely ensure project reliability.
Take software requirements for example, (missing or incomplete accounts for a 12,3%), while I am not advocating about entering a project without them, it is clear that in some circumstances the lack of such documents is not dooming per se. Take for example an expert team that knows all the ins and outs of the domain and has a crystal clear idea of what is needed. In this case maybe the project could get along with no SRS.
So one might be tempted to strictly follow every “best practice” to minimize the risks of a failure. But this is not likely to work either – every practice has its cost and some practices (take the “code review”) are extremely daunting.
Therefore is all a matter of balancing, picking the right decisions, having good reflexes and willing to occasionally work harder to fix what has gone wrong.
Following this line of thought the best insurance you can have for your projects is an experienced and well jelled team with: a) an experienced leader, b) a good success history. This isn’t rocket science either, you can find similar assertions in many software project management books (Peopleware is the first coming to mind).
On the other hand projects keeps failing. This leads me to two considerations, first is that even with the best premises a challenging project could fail – we have to accept this for today’s projects and try to minimize the failure impact. Second how is changing the failure rate in time? The first study quoted in the article is more than 13 years old! That’s a huge time in software industry.