The Cobb’s Paradox – Do we really know how to prevent project failure?

The dictionary defines a paradox as a statement or a group of statements that despite sound reasoning, leads to a conclusion that seems to defy logic or intuition. An example of a paradox is: “This statement is false”—if it is, it is not; and if it isn’t, it is.   

One of the most famous statements that embodies this is the Cobb’s paradox. It was 1995 when Martin Cobb, the CIO for the Secretariat of the Treasury Board of Canada, asked this famous question:

We know why projects fail; we know how to prevent their failure – so why do they still fail?

Why is the Cobb’s paradox still relevant?

For starters, why is it so hard to make sense of the Cobb’s paradox?

The reasons listed below can be of help in understanding why it’s still a topic of discussion.

• Every project is risky and some of those risks are unmanageable.

Uncertainty is built into every project. Each is unique, complex, and based on assumptions and dependencies. What we think we need to handle, isn’t necessarily what needs to be handled.

Risk management, while incredibly useful, is also not 100% effective. Following a formal process to ensure consistency and thoroughness can help with using its full potential.

• Innovation is built on failure.

When a project has a high level of innovation as one of its key building blocks – the chances of failure are usually pretty high. These projects are often regarded as “high risk – high gain” ventures and with them, there are no certainties.

While we can look back and learn from our experience, there is no guarantee that any other project in the future will be similar.

• Refusing or being unable to learn.

Examining past failures is a must if we want to learn lessons for future projects. We tend to repeat our mistakes too often, failing to learn. And this is where we come to Cobb’s mistake – he was wrong. We don’t always know why our project failed. Therefore we can’t learn how to prevent the same type of failure from happening in the future. Needless to say, we then fail again.

Did we really know how to prevent failure?

Project management best practices have gone through quite a transformation in the past few decades. What was once a gold standard, is now often seen as an archaic response to today’s ever-changing conditions.

In the 1960s, The Systems Development Life Cycle (SDLC) was introduced to meet the needs of the market at the time. It initially included Waterfall and Spiral methods and evolved over time to include Evolutionary, Incremental and Iterative builds (IEEE, 2006). Agile grew out of the latter in the 1990s.

Waterfall was embraced by many companies due to its strengths: very manageable, provides more control than earlier ad hoc/trial and error methods, as well as comprehensive documentation for future reference. As the adoption grew, it became apparent that Waterfall had its own new set of weaknesses. 

One of the main problems is that the scope of work is determined at the beginning of the project and those set requirements are cascaded throughout the life cycle. It did not accommodate the changing needs and priorities of the organization, which resulted in unmet business needs and cost and schedule overruns.

In the early 1990s, agile development methods gained significant momentum in response to their increased success rate over traditional methods. It encourages frequent communication between team members and those who will ultimately use the deliverable. Flexibility can be higher than traditional methods, meaning that changes (e.g. in prioritisation) can be introduced at almost any stage

Agile is simple to understand in principle but hard to do well in practice. It requires real commitment and first attempts aren’t likely to go very well, which discourages both teams and management. This is especially true for companies transferring from the traditional waterfall methods. 

Larger projects are also a challenge as there is less of a blueprint of the final deliverable and less documentation for future reference.

Where are we today with PM practices?

With all this in mind, it’s no wonder companies started looking for an alternative solution for their projects. For many, Hybrid project management became the go-to strategy. While the practices themselves have been around for some time, the name only recently started gaining popularity. 

By its definition, Hybrid combines the formal and Agile methods to create a new project management method. It employs the thoroughness of Work Breakdown Structure (WBS) with speed and lean benefits of Agile for a new project management method that is both detailed and fast.

Just what the companies need to deal with rising uncertainty, competitive markets and high client expectations.

Can we ever say we know exactly why projects fail?

A lot has changed since Martin Cobb made his famous statement. We’re faced with overwhelming uncertainty, projects are molded towards client’s wishes more than ever and we’ve come to embrace flexibility as a given.

So, can we truly say we knew how to prevent project failure back then? Or did we just disregard many of the things that were waiting ahead?

Looking back, the second seems more likely. And since past trends are the best predictor of what is to come, we can’t really say we have everything figured out now either. 

Looking at each project as an individual challenge, with all its risks and requirements objectively examined is our best bet moving forward.  Making sure we have an imaginary list of “must-have” steps all covered can take a back seat.