The Standish Group’s 2015 Chaos Report

I am pouring over the Standish Group’s 2015 issue of The Chaos Report.  I really enjoy reading and that covers a variety of topics.   Reading makes it possible to see things you would not normally be able to see, a glimpse of other perspectives, and sometimes it confirms what your experience tells you, and occasionally it flies in the face of what you think.

Success, Challenged and Failed

The latest Standish Group report details the percent of projects that are successful, challenged and failed and this includes agile.  This distribution has changed only moderately over the last five years.  That is, there have not been great and sustainable improvements over that interval.  I am not cognizant of the details of the data acquisition, and presume the companies in the study from 2011 are not necessarily the same companies in the 2015 version of the report.  I say this, because the distribution remains relatively unchanged, that is percent successful has not improved over time.  Experience suggests a company would put actions in place to improve the probability of success and over five years we would like to see a positive sloping trend line indicating an improving project success rate.  That does not match the reported data. 

The graphic below illustrates this variation over the years from The Standish Group’s 2015 Chaos Report[1].

Success, Challenged and Failed Projects over the Years

Size Matters

The report also characterizes the performance of the project by sizes.  The results are interesting and mirror other articles and studies I have read in books that include software studies.  This also mirrors my personal experience as well.  There is an inverse relationship between the values provided by the project to the size of the project. Larger projects produce lower value.  This supports other studies and readings as well:

…research of many projects showed that 45% of features were not used – with an additional 19% rarely used[2]

Complexity also Matters

Larger projects, besides adding complexity add feature content and the value of that feature content for the customer is suspect when a feature is rarely used and an outright waste of effort for features that are never used.  I have worked for companies that would load up the project with all that can be attempted for a delivery.  Rather than do this, it would be better to prioritize the feature content based upon the value created.  Doing so for each feature allows the organization to apply resources to the best possible value for the customer and the organization.  This can have a significant positive impact on the company revenue since less, and on could argue, reckless spending on project attributes that bring no return.

Iterations

I have used agile within a company that employs a stage gate type of project management.  Sometimes this is referred to as waterfall, but I have never seen a waterfall that matches the description generally given of it. That is, that we do all of one step before we move on to the next. For example, we do all of the requirements collecting and specification writing before we do the next step. I have never seen what is often referred to as waterfall applied to that extreme.  Therefore, I prefer to refer to that approach as stage gate, iterative and incremental deliveries mapped to project phases.  The study compares project execution methods of agile and waterfall.  The graphic below[3] comes directly from The Standish Group’s Chaos Report 2015.  

Agile compared to Waterfall

I am not a person to advocate one method of execution over another. To me it is selecting the correct approach for the objective and resources at hand.  However, after reviewing this report and numerous other similar findings, it is passed time to consider how we can improve the success rates of our projects.  Though none of my conventional project experience suggests a waterfall approach means all of one step before the next, it does suggest prioritization of scope of the project often does not happen.  

No matter the approach, fundamental project management and business techniques of qualifying the scope of the project are necessary.  Conventional project management also counsels this as well.  Agile does this particularly well qualifying the individual pieces that comprise the prioritized product backlog. In fact the ability to quickly reap the benefits of the work, monetarily, is part of the product backlog prioritization, though that need not be exclusive to agile.