Software Project Management: Hall of Shame?
If one goes by the widely acclaimed Chaos reports released by the Standish Group, software projects seem to have a dubious record. In 1995, the report highlighted that only 16% of the IT projects were completed on time, within budget with original scope. In 2006, 12 years after the first report was published, another report indicated that the number of successful projects increased to 35%. In comparison, the number looks like a significant improvement but in absolute perspective, it means that two out of every three projects take longer than expected, cost more than estimated, lack required functionality or are never completed. While there has been some criticism of the Chaos report on the numbers published, the transparency of sampling methods followed. But, I am sure, most would agree to the key message behind the report that when it comes to software projects, it is more likely to fail in the areas of schedule and budget, than succeed.
One of the main reasons for failure is attributed to estimation failures. In his widely acclaimed book, The Mythical Man-Month, Frederick Brooks claims that most software projects have gone awry for lack of calendar time than for all causes combined. It is no surprise thus that the two most common reasons one hears of when a project fails are “The estimates were aggressive to start with” or “We messed up our estimates”. If we could lay hands on an estimation tool which is able to estimate accurately and we have the courage to stand by it, then our problems would be resolved. The solution looks simple and can be easily implemented, if only we did not have an impediment called the customer, who always forces us to accept aggressive timelines.
But wait, before we decide to surrender to this conflict forever, how do we know for sure that the reason for a software project failure is “inaccurate” or “unrealistic estimations”? When I ask this question, I get an interesting answer – the fact that we are delayed clearly proves that the initial schedules or estimations were not correct. This seems to be a trap of circular logic or as logicians would say a tautological argument error. It can also be that the time WASTED in a chain of predecessor activities could have been enough (if it was not wasted) to absorb the extra scope discovered in a task during execution. So there could be an alternative hypothesis that most projects are delayed because significant time is also wasted in most projects and there is nothing left to absorb the unavoidable uncertainties. If I ask a project manager, he will agree to the hypothesis of significant waste of time as long as we are referring to someone else’s project. In his projects, he will talk about how his resources are stretched beyond all limits. So where is the time actually wasted? It must be the erroneous estimations which lead to project schedule failures. I believe, this assumption is the only reason for the unending quest for an accurate estimation tool.
In the last few decades, many sizing and effort estimation methodologies and models have been invented, each one promising to be more accurate and more objective than before. Despite many approaches, there seems to a consensus that estimation based on past data is more objective than one based on individual’s perception. After all this effort, we are still at a level where significant projects are delayed. If we go back to the Chaos report again, we will notice that the improvement in performance is primarily due to the popularity of agile methodologies and hence many projects in the year 2006 were smaller in size as compared to the ones in 1994ii. Interestingly, the agile school of thought does not believe in upfront requirements freezing and predictability. Hence, I assume they are not so bothered with the problem of accurate estimation. They seem to have reconciled that it is impossible to bring about upfront predictability, so the key is to make workable software available to customer ASAP and keep on improving the software.
There are two conclusions which we can make
- All efforts of improving estimation seem to have not helped
- Agile techniques provide a way out to improve the situation
The key question is; can we implement the transparency required for agile implementation in all
Agile requires lot of trust between the development team and the customer. The customer has to be comfortable working without upfront predictability. He is getting some usable software much earlier than otherwise. But then how does the customer believe that the reason some features could be pushed out of the release schedule is due to real issues and not because of sloppy work of the developers? The distrust becomes significant, when there is a supplier- client relationship guided by a contract. Such relationships require upfront predictability, particularly in fixed priced projects. So the need for upfront predictability is required for software projects and the harsh reality is that we have not seen any improvement despite continuous efforts to improve on estimation techniques. We are still waiting for that silver bullet which will give us the “accurate forecasting” and solve the problem of predictability.
Before we go further, let us analyse the inherent problems with estimations.
If we look at all estimation methods, there are essentially the following steps
- Sizing of work (like function points or lines of codes) factored with an assumed level of complexity
- Derived calculation of effort required to complete the work (with assumed rate of past productivity)
- Calculate the overall timeline based on available manpower. ?4. Use personal judgement, negotiate and agree on a final number.
Let us analyse by answering a few fundamental questions.