Resolving Cobb's Paradox

Cobb’s Paradox: “We know why projects fail; we know how to prevent their failure – so why do they still fail?”.

It may sound overly simple to say it, but the answer is right there in part B of the question, "we know how to prevent their failure". Quite simply, this equates to those who are accountable for the things we see will cause the project to fail, where the are solvable, are not making those responsible take the required action. So why do projects fail; there are simply too many reasons, but the key one is if we know how to prevent it - why is this not acted upon?

A project only truly fails if it doesn't achieve the intended benefits. If you are late, over budget, or scope / quality not as planned, but despite this the benefits are realised, then the project has succeeded though you as PM have failed in project delivery (covered a bit more here - How important is project success to you?).

To frame the discussion;
1. what is project delivery failure, such as those red traffic lights in your reports. Is this different to project failure?
2. exclude some unsolvable reasons impacting delivery or benefits realisation;
  • delivery disasters; some are risks you have to accept will impact the success of the initiative and are too unique to mitigate - i.e a vendor with a unique product or service goes belly up right at the point of implementation.
  • benefits realisation; regulation changes just before the conclusion of project delivery scything benefits and the sponsor proceeds with implementation.


PM's already have a great tool to mitigate decision avoidance by stakeholders and this is a comprehensive, accurate and validated RACI/RASCI, with the right people having appropriate responsibilities and accountabilities. When identifying and getting acceptance from stakeholders, explain clearly and without ambiguity the obligations their role entails. Outline the risks surrounding those management or delivery components for which they are assigned and those risks they own. Project involvement isn't just about being associated with success, and kudos when succesful.

Again, and most importantly, are they the right people for the job. I discuss in another post that many project stakeholders outside the delivery team come to their roles simply as a result of the organisation chart and many have woefully inadequate understanding of even the most elementary project related structures and functions. This should not be surprising, many functional management roles do not require project exposure, they succeed through operational improvement to operational KPI's - but it may certainly impact their suitability for key project roles.

So as roles became clear and assigned, did you communicate the full extent of the accountability they hold? Had you interviewed them to determine if they are the right person or constitute a risk to be closely monitored, and put in place preventions or plans to reduce the likelihood of them becoming an issue? This is  sensitive territory where soft skill expertise is vital and where your skills may become the differentiator between success and getting Cobbered.

So, with all the clashing priorities, staff movement, potential blame shifting and scapegoating that will begin when things start to go south, will these people for whom you may have no authority over respond to their obligations. This is where you're approach to compiling your RA(S)CI is key. If you've done it right, engaged, informed and got approval from stakeholders then you are able to present an objective and binding 'contract' to get engagement and action. You may not be able to resolve Cobb's paradox in all scenarios, just reduce the likelihood for those that can.





Popular posts from this blog

How to deliver successful projects

Image
Are you willing to say anything other than an obvious “it is everything and I’ll do whatever it takes to achieve it”. Admirable, but what does ‘whatever’ mean? Would you throw in some of your own money to get additional resources to meet an immovable deadline? You may be prepared to work 24×7, but unless the team who actually do the work can, will that help? Martyring yourself may be an instinctive rearguard action, but it will do little for your stakeholders. Have you thought that meeting timelines, budget and quality constraints may give you only part or none of the success? Meeting these constraints means successful delivery of what was planned, and the vehicle used to achieve this may function correctly - is that your job done? All your good intention is moot if your finely tuned vehicle arrives at the wrong destination. A hint from Peter Drucker; " There is nothing quite so useless as doing with great efficiency what shouldn't have been done at all! ".  Deli...
Continue reading »

Can PRINCE2 project management and Agile complement each other?

Image
Is PRINCE2 and iterative development (such as big 'A' Agile) friend or foe?   As a rule, opinions are generally polarised between those who have been sold Agile as the panacea that will inoculate projects from failure or those dismissing it as a dogmatic fad that is a recipe for chaos, cost overrun, flaky products and subsequent failure. You may have a positive view of Agile benefits but this agility, without more robust governance, may be a bridge too far for decision-makers accountable for funding. When evaluating a project approach, consider the benefits of the middle path - nobody need be right or wrong, why can't we all just get along! To start, think about the responsive and continuous improvement benefits of Agile coupled with the governance, greater predictability of scope, schedule and cost and risk management that are part of full scale project management? What gaps would exist in the rigour of your approach, and what problems exist with picking a ...
Continue reading »