Cobb’s Paradox is alive and well

In 1995, Martin Cobb worked for the Secretariat of the Treasury Board of Canada. He attended The Standish Group’s CHAOS University, where the year’s 10 most complex information technology (IT) projects are analysed. The high level of failure led Cobb to state his now famous paradox: “We know why projects fail; we know how to prevent their failure—so why do they still fail?”

In 2011, another report into the management of IT projects asks the same question! This time the report was prepared by the Victorian Government Ombudsman, in consultation with the Victorian Auditor-General, it documents another series of failures largely created by executive management decisions. The report entitled Own Motion Investigation into ICT – Enabled Projects, examines 10 major Victorian Government ICT projects that experienced difficulties such as budget and timeframe blowouts or failure to meet requirements.

Portfolio Management
Problems identified by the Ombudsman in the area of Portfolio management and governance include a lack of effective leadership, accountability and governance. He was particularly concerned about poor project governance, the lack of accountability of project stakeholders and a lack of leadership — a reluctance to take tough decisions.

These failures contributed to poor decision making, and an inability or reluctance to make difficult, but necessary decisions. Leaders lead and determine governance practices; the resources needed to implement these facets of effective Portfolio management are readily available including:

The Association for Project Management’s Directing Change, a guide to the governance of project management: Download the booklet

Project Definition
It is impossible to deliver a project successfully if the decision to proceed is based on inaccurate assessments in the business case. The Ombudsman commented on the inadequacy of business cases, the failure to fully define requirements for new systems, a general reluctance to change business processes to better fit with off the shelf products (to reduce cost and risk) and a ‘tick the box’ approach to risk management (ie, avoiding any real assessment of risks and opportunities).

Linked to this lack of definition major project funding decisions were announced publicly before the business case was fully developed (representing either wishful thinking or a wild guess?), and high risk decisions being made to only partially fund some projects.

The solution to these issues is a robust and independent PMO that has the skills and knowledge needed to validate business cased before they go forward to management for decisions. Many years ago, KPMG released a series of reports that highlighted the fact that organisations that failed to invest in effective PMOs were simply burning money! The Ombudsman’s report shows that ‘burning public money’ is still a popular pass time.

Risk Management
Many of the factors identified above and in my view the primary cause of most bad decisions is the abject failure of senior management to insist on a rigorous risk management process. Risk management is not about ‘ticking boxes’, it is about having the ethical courage to objectively explore the risks and then take appropriate actions to either mitigate the risk or provide adequate contingencies within the project budget. This failure was manifest by an inconsistent approach to contingency funding. There are many examples of high risk decisions being made without any contingency provisions:

The Myki ticketing system was let to an organisation that had never delivered a ticketing system before. No contingencies were made for this high risk decision and the project is years late, $millions over budget and will only deliver a small part of the original scope.

Agencies preferred to be on the leading edge rather than leveraging what had been done by others elsewhere. This may be justified but not without proper risk assessment, mitigation and contingency.

Government agencies are not alone in failing to effectively manage risk in ICT procurements. The same problem has been identified in major infrastructure projects, in a series of reports by Blake Dawson; see: Scope for improvement

There are always difficulties in transferring project risks to vendors, and dealing with large vendors who may be more experienced in contract negotiation than their agency counterparts. Whilst modern forms of contract provide opportunities to adopt innovative procurement processes that could significantly reduce project risks for vendors and customers these were not used.

As our paper, The Meaning of Risk in an Uncertain World and the Blake Dawson reports clearly demonstrate, not only is it impossible to transfer all of the project risk to a vendor, it is totally counterproductive to try! Organisations that try to transfer ‘all of the risk’ end up with a much poorer outcome than those organisations that actively manager the risks in conjunction with their vendors.

Large ICT projects are inherently complex and necessarily involve some significant risks. But these can be mitigated to some degree by taking heed of the Ombudsman’s observations, lessons learnt in other projects and the implementation of robust and independent systems.

Recommendations
The Ombudsman’s recommendations on how to address these issues can be applied to ICT and other projects undertaken by other state, local and Commonwealth government agencies, and in the private sector: Download the report.

In my opinion, the primary cause of these failings, referenced but not highlighted by the Ombudsman, is cultural. Executives and senior managers overtly preferring the status quo and the current power structures they have succeeded within over leading the implementation of change that will deliver improved outcomes for their organisations but make people more accountable and redistribute organisational power. This was the focus of my last posting; Culture eats strategy for breakfast 2!

As Martin Cobb observed in 1995, “We know why projects fail, we know how to prevent their failure — so why do they still fail?” Unfortunately this is still a valid question more that 15 years later and, without leadership from the very top, I expect the effect of this report will be little different to the dozens of similar reports generated over the years and we will still be asking the same question in 2020.

The answer is culture and leadership – to change the culture within senior management ranks, the owners of organisations need to take actions similar to the Australian Federal Government and mandate effective processes and then measure performance in their implementation and use. The implementation of the Gershon Report that is being forced through the federal government departments is a Cabinet level initiative. It is still too soon to judge wether the initiative will be successful, effective culture change takes years to embed in major organisations, but at least the push has started at the right level. My feeling is that if the pressure is maintained for another 3 or 4 years (the original report was released in 2008) there may be some real benefits. To avoid similar reports to this one in the future, the leaders of other organisations need to take similar robust, strategic action tailored to the needs of their organisation.

Project professionals can help by effectively communicating to your top-level executives the real benefits of effective project governance. For many ICT and other technical/engineering professionals this represents is a whole new set of skills to learn, my book Advising Upwards may help!

8 responses to “Cobb’s Paradox is alive and well”

I think projects often fail to meet their planned completion date is because that date is often unrealistic. And the reason that project plans are often unrealistic is that they are based upon deterministic estimates which are bound to be wrong. Murphy’s law is a bit extreme, but a more moderate version would state that if there are many things which could go wrong, at least one of them probably will. Every project should be subject to risk schedule analysis before it starts. Inexpensive software is available to do this. For example, in the Microsoft Project world there is Risk+ and my own Full Monte.

The reason that the project plan in unrealistic is not because whether or not using a software to work out the schedule – the issue remain in the person who prepare the schedule. ITC project normally do not have a real life scheduler to prepare / update / analysis the project plan – and that is the sole reason that it “plan” to fail!!

Project fails because of the wrong implimenttion of the scope, unrealistic deliverables should have been considered during the initiation and planning stage although risks and uncertainties might not be accurately forecast.