Cobb’s Paradox
Cobb’s Paradox: We know why projects fail, we know how to prevent their failure – so why do they still fail?
I was never a fan of The Standish Group’s CHAOS report. Ignoring some of the more specific complaints about the methodology, definitions, audience, etc., my biggest challenge is that it became ‘clickbait’, with many simply echoing the “70% of all projects fail” cry, with little to no understanding of the validity or support of that statement.
But the Standish work did provide some interesting insights, if you dig a bit deeper. One of those is Cobb’s Paradox (above), coined by Martin Cobb (Secretariat of the Treasury Board of Canada) at the first CHAOS University (1995) which was a working group to discuss the findings of the first CHAOS Report.
Another, almost completely ignored, aspect of the CHAOS Report is that Standish also identified the top 10 ‘causes of failure’.
(note: this is specific to those surveyed, and to IT projects only)
These 10 causes of failure are (in order of importance):
- User Involvement
- Executive Management Support
- Clear Statement of Requirements
- Proper Planning
- Realistic Expectation
- Smaller Project Milestones
- Competent Staff
- Ownership
- Clear Vision & Objectives
- Hard Working, Focused Staff
Now, here’s the interesting question –
How many of those causes are specific to the delivery approach used?
How many are specific to or under the PMs authority or control?
And where do those rank in importance?
And yet, as a profession/community where is most of our time and focus spent?
Which of these will ‘using AI’ solve?
So, back to Cobb’s Paradox –
We know why projects fail, we know how to prevent their failure – so why do projects still fail?
Because we’re not addressing the ‘causes of failure’. We’re (for the most part) addressing the easy stuff, the stuff that we can influence and control. But take a look at the list again. No matter what new delivery approach we come up with, or how good it looks, or how ‘strategic’ we think we are, or how ‘helpful’ AI is, those causes won’t be be improved.
(to be fair, PMI’s new M.O.R.E. idea does take a bigger swing at this)
And I’m sure there are any number of other causes you can identify (especially outside IT), but I think the same issue holds – are we identifying solutions to the causes, or just solutions that make it ‘look like’ we’re improving?
Originally published on LinkedIn