The Standish Group has published an annual report on the state of software development since 1994. It is often cited as a key metric for the industry’s performance and progress. The 2017 report shows that almost a quarter (23%) of projects are cancelled before they are finished and around half (48%) of projects are challenged (“challenged” being defined as not meeting expected scope, time and/or budget expectations).
The Standish Group interviews IT executives to provide more information about the survey results. The reasons for failure are revealing. By far the biggest reasons for failure are non-technical issues such as incomplete requirements, changing requirements and unrealistic expectations. In fact, technical problems such as technology illiteracy or technology incompetence are seen as the cause for less than 10% of project failures.
The tables below show the full list of reasons and the percentage of responses for each. The bold lines are concerns of product management.
|2||Lack of user involvement||12.4|
|3||Lack of resources||10.6|
|5||Lack of executive support||9.3|
|6||Changing requirements & specifications||8.7|
|7||Lack of planning||8.1|
|8||Didn’t need it any longer||7.5|
|9||Lack of IT management||6.2|
60% of the reasons cited are product management issues.
Let that sink in. 71% of software projects fail. 60% of those failures are attributable to product management issues.
Houston, we have a problem!
So where to from here?
Those in charge of the way organisations and functions are structured need to grok that software products are fundamentally different from traditional products and understand and learn from these differences.
With a view encouraging such improvement in understanding, later posts in this blog will explore some of the ways software product management is different and what can be done about it. Some key areas of discovery to help illustrate how software products are different will include business models, types of innovation, organisation maturity, complexity and risk, among other things.
Only once we dive deeper to understand why software products are different can we begin charting a clearer path forward, and the impact this will have on software organisations.