Yes -- Some IT Projects Fail. But Don't Throw The Baby Out With The Bathwater

There has been a lot of negative press and commentary regarding the recent Queensland Health Implementation of Continuity Project (SAP HR and Payroll), which recently experienced a very public failure as many employees were not paid due to multiple points of failure in the project. The recent Auditor-General's Report on the process is damning, spreading the blame across multiple agencies and the systems integration partner, IBM. I make no claims to be familiar with the intricate details of the process, but I have read the report and feel I have a clear understanding of the (many!)  points of failure. 

While this project did seem to be a monumental failure, I would suggest that we consider two important facts:

  • IT projects DO sometimes fail. 
  • Many of the points of failure highlighted by the auditor general would actually exist in MANY IT implementations -- it's just that most of the time we get by and work around problems.

Regarding IT project failures, the failures exist because there are humans in the process. And humans make mistakes, cut corners, and never have unlimited access to all the information they need at every step in the process to make a perfect decision. However, I would suggest that marketing projects fail too -- so do engineering projects, and projects to reduce costs or improve systems. Let's face it, governments manage the builds of roads, tunnels, military equipment, etc. that have been known to be massive failures, going sometimes $BILLIONS over budget. There are many recent examples of governments spending hundred of millions of dollars of taxpayers money only to then cancel the project and achieve absolutely nothing. While I don't want to make light of the fact that many people were not effectively paid in this recent bungle (as I do understand people have bills, mortgages, etc.), many of the health professionals are the same ones who do not wash their hands between assisting patients, causing secondary infections, and sometimes even resulting in the death of the patients (and where is the auditor-general's report into this?). I am not having a go at the doctors and other health professionals -- I just want to highlight the fact that whenever there are humans involved in a process there will be mistakes.

It is often people that save projects too (and people's lives in hospitals!). Many IT projects are poorly governed -- but individual contributors, or partners who have been compensated effectively, often go above and beyond the call of duty and the terms of the contract to work around issues and ensure that the project succeeds -- regardless of failures elsewhere in the system or process. This project once again highlights the effects of using specific pricing models -- a fixed price engagement was entered into by the Queensland government -- and often you get what you paid for. If IBM had been incented to ensure the project outcomes were met perhaps by sharing with them a proportion of the projected savings, there may have been the incentive for IBMers to go beyond their contracted role and ensure the project was delivered successfully? (Forrester has actually developed a tool to help you work out what the best pricing model is for your IT projects.)

The right thing to do when there are project or system failures is exactly what the Queensland government has done so far -- work out what went wrong, and put processes in place to ensure those problems do not happen again. The wrong thing to do when projects or systems fail is to do what the Queensland government is proposing, which is to scrap the whole approach to shared IT systems and start again. The Queensland government currently operates a shared services model for some of their IT services. There are many examples of successful shared services programs across government and the private sector. IT & BPO vendors have turned this into a multibillion-dollar industry and carry out shared services engagements across multiple clients, industries, and geographies as a core part of their business. A single project failure is not a valid reason to abandon the potential savings and efficiencies that shared services can provide to governments. To cost the taxpayer extra to run multiple systems across multiple agencies is not the right outcome when, in fact, the government did not effectively govern and manage their shared services capacity effectively in the first place. Yes -- maybe moving the entire health system to a single shared service payroll solution was a mistake -- but that does not mean that shared services will fail in every part of the government. Some agencies in the federal government sector are even examining the opportunity to share their IT services with similar government agencies across the world in order to cut costs and move funding to where it can make a real difference. 

One final comment: next time you get paid, get a check from the government, pay your car's registration online, or consume any other government service, think about the hugely complex IT systems behind them that DO work. While we are quick to point out failures we do not celebrate the victories. 

As written in a Forrester document in 2008, the common causes for project failures are:

  • Unresponsive governance, which leaves project decisions hanging.
  • Lack of communication from change management, which leads to false conclusions.
  • An unrealistic project plan, which dooms the best project.
  • First-number syndrome, which makes business execs forget it's an estimate.

These mirror some of the issues in the Queensland Health Implementation of Continuity Project (SAP HR and Payroll). So what should you do in order to ensure these types of failures do not happen in your IT projects? Here is some top-level advice:

  • Protect against unresponsive project governance.
  • Foster change management communications.
  • Guard against unrealistic project plans -- and make the rationale for changes visible.
  • Establish standards for estimates.

You can read more in the following Forrester reports:

The Three Basic Steps Toward Business Governance Of IT
Debunking IT Project Failure Myths

Measuring The Effectiveness Of Your PMO

Governance Communications: Measuring And Improving Governance With A Balanced Scorecard

IT Should Not Own IT Governance

IT Governance And Risk: Defining Your IT Risk Appetite And Risk Tolerance

What are your thoughts on this? Any recommendations on what can be done to avoid project failures? Hindsight is often a great thing, and is even better when shared, so feel free to share your comments below, and I'll do my best to ensure that as many people as possible don't make the same mistake.

Comments

Great article. It is a shame

Great article.
It is a shame that many big IT projects will be impacted by general negative perceptions from this project given the number and scale of the projects that touch the community. The impact it has done on the wider enterprise IT systems community is going to be felt for quite a while, certainly in Qld.

Though, I do struggle with the end of the article about the reaction regarding shared services. While some examples do exist of successful shared services, I struggle to name many particularly successful cases coming out of Qld's attempts at the model. A big change was required, though a complete scrapping was quite unexpected.

I agree with your Qld comment

Hi Brett,

I agree with your comment on great examples of shared services in QLD - although it is relatively early days still. I would suggest that the failure is the perfect example of why we have not seen hugely successful shared services initiatives in QLD - as the ability even to decide what services should be shared (i.e. the overall governance) seems to be flawed. However, I'd suggest that instead of axing the whole program, the QLD government should at least attempt to fix the governance of the shared services initiative first.

Good Stuff - IT Support Projects

IT projects tend to be so much more HIGH profile... then other disciplines particularly when there is a break down. IT, we tell our IT engineers are unfortunately viewed like a GOOD referee. If you notice the ref, he's not doing his job. If you notice the IT - it's NOT working. So in IT - it must be running. thx!