The Standish (Chaos) report has been published for a number of years now and it is always a sobering read for those involved in project management and in particular, projects involving computer technology. Of particular note is that there has been no significant change in the statistics quoted below since the mid 90’s.
For those who just want the head lines, the 2015 report indicated that ” a staggering 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars. One just has to look to the City of Denver to realise the extent of this problem. The failure to produce reliable software to handle baggage at the new Denver airport is costing the city $1.1 million per day. Based on this research, The Standish Group estimates that in (1995) American companies and government agencies will spend $81 billion for cancelled software projects. These same organisations will pay an additional $59 billion for software projects that will be completed, but will exceed their original time estimates. Risk is always a factor when pushing the technology envelope, but many of these projects were as mundane as a drivers license database, a new accounting package, or an order entry system. On the success side, the average is only 16.2% for software projects that are completed on- time and on-budget.”
If you want access to the full report, you will find it here
So what’s new? Well, what I found particularly interesting was that the report provides a list of factors that survey participants considered to be the causes of project failure (the report uses the terms such as ‘impaired’ and ‘challenged’ rather than failure).
The more I looked at these causes, the more I became suspicious. Why were there so many (13 after removing duplication’s) and was it possible that the root cause was hidden amongst those quoted or was it something entirely different?
I decided to check it out and to do so, I used the Theory of Constraints thinking process tool – Current Reality Tree (CRT) to help.
For many this tree (see below) will be unfamiliar, but a quick review will suggest to you that it is describing a number of statements and their relationship to each other. The boxes with a yellow background correspond to the ’causes’ noted by the Standish report and the other boxes represent my additions in order to create the required logical links tying everything together .
I won’t get in to the detail of how to create or read the tree but, readers should note the following:
a) None of the ’causes’ that the Standish report provided from those surveyed appear to be the root cause. ie. they appear to be symptoms often linked to each other and providing no real insight into the real root cause.
b) The root cause proposed by this exercise is ‘(1) The organisation do not know why changing the traditional project evaluation method/s is necessary ‘. This cause was not mentioned in the report
c) All the causes point to a failure of the current project evaluation methods suggesting that the failure rates are a function of poor selection rather than poor project management
Does this sound right to you? If you follow the arrows you will see how I developed the logic to justify this root cause however because I documented it in this way, it is transparent and available for others to scrutinize.
What’s so different about this approach?
a) It makes the logic of individuals visible and available to everyone to scrutinize and validate (isn’t this exactly how Wikipedia became such a definitive reference?
b) In its final form, it demonstrates that valid causes can be found without significant effort and expense being applied to data validation and mining (correlation is not causation).Sure data will help but now we have a context for where and what to look for
c) It provides significant insight into where management should focus their attention rather than fighting fires that only address the symptoms
d) Conversations need not jump down rabbit holes based on personal opinions. If others want to contribute to the debate, the method encourages those people to add, modify or delete the existing logic so that any proposed changes need to provided with the same rigor as shown in the tree
For those who want to know more how to create such a tree , send a note via Linkedin and I will respond.
Also note that the journey doesn’t stop here. Some of you would be questioning why this cause persists in organisations and what can be done to address it.
I will explain what this means in my next post