Product Management Is Broken

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.

# Factor %
1 Incomplete requirements 13.1
2 Lack of user involvement 12.4
3 Lack of resources 10.6
4 Unrealistic expectations 9.9
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
10 Technology illiteracy 4.3
Other 9.9

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.

AdobeStock_199105875.jpeg

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.