The Standish Report is raising its head again in the Agile presentations I've seen recently at conferences. Forgetting for the moment all the past "criticisms" of Standish...
- Standish Report
- Standish Report and Naive Statistics
- Finally a Challenge to the Standish Report
- The Non-Existent Software Crisis: Debunking the Standish Report
- The Bunk of Using decades-old report (1966) for basis of #NoEstimates conjectures
- "The Standish report: does it really describe a software crisis?" Robert L. Glass, Communications of the ACM, vol. 49, no. 8, pages 15-16, August 2006.
- "The Rise and Fall of the Chaos Report Figures," J. Laurens Eveleens and Chris Verhoef, IEEE Software, vol. 27, no. 1, Jan-Feb 2010, pages 30-36.
- Chaos Report Myth Busters,
The numbers in the report are still being used by "agile thought leaders" to establish the basis for their proffered solutions. Forgetting even more that "agile" is a bottom-up software development solution. And that most of the issues with large IT programs are leadership at the senior executive level, externalities from the market place at large, and general inability to connect the dots between business strategy and business execution.
And of late by the #NoEstimates thought leader to further their unsubstantiated conjecture that decisions can be made while spending other people's money in the presence of uncertainty.
Further is the complete lack of transparency in the statistical numbers. But here an alternative on how to report IT project success.
The definitions of "needs attention" and "significant concerns" is provided in terms of mission suitability rather than simple - and simple-minded cost and schedule.
So it's time once more to move beyond the worn out red herrings and start to address how to Increase the Probability of Project Success with processes and tools beyond just applying Scrum to the development team.
Willian pointed out the bands for measuring success. http://it.usaspending.gov/faq-agencies