A futile Queensland Health blame game

Read the original article on The Australian

Read the article below

The Royal Commission of Inquiry’s findings on the Queensland Health payroll upgrade debacle has laid bare the sheer ineptitude of all the parties involved and set in motion a process of recrimination which ultimately serves no one.

State premier Campbell Newman has accused IBM of taking the state of Queensland for a rather expensive ride, $1.2 billion for a project that was expected to cost much less and a further $5 million for an inquiry that leaves us with more questions than answers.

For its part, the global tech giant has maintained that it’s not solely responsible for the fiasco, with successful delivery of the project “rendered near impossible by the State failing to properly articulate its requirements or commit to a fixed scope.”

All of this is cold comfort to those affected by the bungle but this by no means an isolated occurrence. The inner workings of government department IT projects are a hot bed of desultory decision making and the Queensland Health bungle is the latest manifestation of how to get things done the wrong way.

A futile blame game

The inquiry results highlight key factors that led to the failure, but the finger pointing may be misplaced. The question that should have been asked of the Department appears to have been missed or lost in the haze. To put some of the blame on public servants is reasonable, but were the right public servants put in the spotlight?

Australian governments have a poor record with large projects involving system replacement or upgrade. The fact that Victoria (Myki) and Queensland (Health payroll upgrade) have had large project failures in recent years has highlighted there is a larger problem. The perennial leader in this regard is Defence – year after year we learn of yet another procurement disaster, particularly related to replacement or upgrade systems.

The relationship between key stakeholders is often extremely complicated and it’s vital that all stakeholders have the opportunity to participate throughout the project, be heard and have their concerns addressed.

This means there must be systems in place to facilitate the key stakeholder interaction that draws together elements of the project cycle. The weak link in project cycle management has always been managing performance and technical risk. Without adequate systems, project teams will often muddle through, but every so often there will be a spectacular project failure.

Textbook failure

The Queensland Health payroll upgrade project should have been completed successfully, but it has become a textbook failure and the inquiry has provided evidence of this.

Projects should be fully specified and component parts simplified so that information flows can be fully identified and understood. It’s vital that the project specifications are complete before the project development commences.

Often it’s necessary to finalise the project specifications after the project development has commenced so there’s a need to identify key performance criteria for performance early which will assist with understanding the technical risk of project specification decisions that have been left until later.

Often projects have key technical requirements that may at first glance appear easy to implement but will often have a small but cumulative negative effect on other parts of the project until eventually becoming a terminal problem. The bigger they get the greater the need for the project deliverable to be broken up into smaller and smaller deliverables. 

The project development cycle needs to be an iterative process.

Changes to the project scope after the project development has commenced should be resolved down to the affected subsystems and iterative development of small subsystems should permit the project scope changes to be incorporated without putting the entire project at risk.

Key stakeholder engagement – reinventing the wheel

Key stakeholder engagement can be tricky but having key personnel in the client project team is vital. It’s particularly important that the project leadership team includes people with prior expertise. Finding the right partner organisation that will build the project deliverable is equally important.

If the project includes a deliverable that is new to the partner then there should be a pilot project identified that should be completed before the partner is accepted for the full project.

One factor often overlooked is the need for sufficient technically qualified people to be involved throughout the project and to be adequately represented on both the client and partner leadership teams. The project performance management and technical risk systems must be integrated with asset and project management systems – it’s not acceptable to manage for time and cost only.

Don’t be afraid to use an auditor

Using one or more independent auditors throughout the project can often bring bad news to the surface early. Early warning will permit problems to be dealt with before the issue becomes critical and threatens project success. So don’t be afraid to use auditors and ensure that technical specialist auditors are in the mix.

Relying on the project leadership team to find and identify all critical issues can be problematic, if for no other reason than the leadership team will be working closely with the partner organisation and human factors can lead to misunderstandings and potential communication errors.

Blacklisting IBM may provide the Queensland government some closure but pinning the blame solely on IT suppliers and vendors is a fool’s errand.  Ensuring successful implementation is a two way street, project governance isn’t easy but it doesn’t need to be rocket science either.