IT Success and Failure — the Standish Group CHAOS Report Success Factors

The Standish Group have been famously (notoriously) publishing their CHAOS Report with IT project success/failure/challenged rates since 1994. “XXX% of all IT projects fail!” headlines are doubtless responsible for their fortuitous fame but they have also attempted to analyse ‘success factors’ over the years:

1994 1999 2001 2004 2010, 2012
1. User Involvement
2. Executive Management Support
3. Clear Statement Of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision And Objectives
10. Hard-Working, Focused Staff
1. User Involvement
2. Executive Management Support
3. Smaller Project Milestones
4. Competent Staff
5. Ownership
1. Executive Management Support
2. User Involvement
3. Competent Staff
4. Smaller Project Milestones
5. Clear Vision And Objectives
1. User Involvement
2. Executive Management Support
3. Smaller Project Milestones
4. Hard-Working, Focused Staff
5. Clear Vision And Objectives
1. Executive Support
2. User Involvement
3. Clear Business Objectives
4. Emotional Maturity
5. Optimizing Scope
6. Agile Process
7. Project Management Expertise
8. Skilled Resources
9. Execution
10. Tools & Infrastructure

Little changes at the top. Executive support & user involvement were noted in the 1970s as 2 main success/fail factors. ‘Agile Process’ is an evolution of ‘Smaller Project Milestones’ (the bit of agile that’s actually about process is “deliver working software frequently”, which is “smaller project milestones” in olde 1990s language). ‘Clear Vision and Objectives’ is re-branded as ‘Clear Business Objectives’

But note the varying evaluation of the importance of the people. At one level technical stuff will get done if and only if you have competent people actually doing it — it’s make or break. But so are all the factors above “Skilled resource” or “Competent staff”, albeit less obviously so.

Emotional Maturity is new. The cynic may note that the Standish group will sell you an Emotional Maturity Test Kit (the less cynical may say Standish are attempting to address a problem). Actually their analysis of emotional maturity is largely about character and behaviour which may be a sign that the English word ’emotion’ has grown in what it means compared to 20 years ago. They include arrogance and fraudulence; I can see arrogance as a symptom of emotional immaturity, but fraudulence may mean “I’ve considered what counts as getting ahead in our society and it seems to me that taking the company for everything I can get before they take me for everything they can get is the way to go”. Fraudulence is wrong, but ain’t always emotional. I think “personal maturity” — or just maturity — is the idea they’re grasping at. It’s about having good people.

Scarcity of essential success factors

But the top factors are not prioritisable. I think they are all essential. Rating one above the other says more about relative scarcity than relative importance. When it’s really hard to get competent, skilled, hard-working staff then that will be your top success factor. As it is, good executive support is harder to come by than competent staff. Apparently.

I’d summarise as follows:

  • Good people
    • who know what they are trying to achieve
    • with good involvement & communication with who they’re achieving it for
    • when well-supported

will succeed, if success is possible.


More serious researchers point out all that is wrong with the Chaos report, most notably:

  • unlike published academic research, the data we’d need to evaluate the claims is kept private so we can’t verify their data or methods.
  • Their definition of success is very narrow and doesn’t mean success. It means “cost, time and content were accurately estimated up front”. Which isn’t at all the same as success except in areas which are so well understood that there really is nothing at all you can learn as you are doing it. That’s not so common in technology projects.

For an alternative and probably more balanced view of the ‘state of IT projects’ I’d look at Scott Ambler’s annnual surveys: http://www.ambysoft.com/surveys/

The Cloud defined in a sentence, 12 bullet points and 3 pictures

Kudos to someone at apps.gov or NIST for a great 2 minute summary of the cloud. My summary of the summary:

Cloud Computing Defined

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources e.g., networks, servers, storage, applications, and services that can be rapidly provisioned and released with minimal management effort.
Cloud computing - picture by http://cloudtimes.org

Five Characteristics of Cloud Computing

  • On-demand, self service
  • Wide network access
  • Resources dynamically shared and allocated across customers
  • Elastic rapid provision and release
  • Metered service

Three Main Layers of Service Provided by Cloud Computing

  • Saas: Software as a service, for end-user consumers
  • Paas: Platform as a service, for software developers
  • Iaas: Infrastructure as a service, for system administrators

Two Axes of Choice for Cloud Deployment

  • Public vs Private
  • Outsourced vs In-house

And finally a bonus:

A History of Cloud Computing in Three Sentences

  • It began life as “Grid Computing” – a technology to solve large problems with parallel computing on widely distributed resources.
  • Grid computing matured to be offered as a metered service known as “utility computing”.
  • This evolved via packaged solutions and self-service subscription over the internet into what is now known as Cloud Computing.

Condensed from http://info.apps.gov/content/what-cloud

Software Quality — the Whole not the Parts

Ben Higginbottom makes a significant point right at the top of this question about the Knight Capital fiasco:

Was the Knight Capital fiasco related to Release Management? On August 1, 2012, Knight Capital Group had a very bad day, losing $440 million in forty-five minutes. More than two weeks later, there has been no official detailed explanation of …

Ben Higginbottom: Nightmare scenarios like this are not the result in the failing in any one discrete components that can be ‘fixed’ simply and sweetly by improving the process, but by small failures in multiple domains (I’m kind of reminded of a fatal accident investigation). So coding error, gap in the unit testing, weak end to end testing and poor post release testing coupled with a lack of operational checks when live. I can understand the desire for a ‘silver bullet’ fix, but in any complex system I’ve never known them to exist.

Sometimes, it’s the whole, not the parts, that needs fixing.