Dooming public IT projects to failure

HealthSMART, myki, T-Card are all high profile public IT fiascos and the troubles start pretty much from the word go.

The Conversation

Governments have never been more keen to leverage information technology for public projects, but their track record isn’t particularly good. In Victoria, myki has been branded a “disaster from touch on to touch off”, and HealthSMART has been ditched. In NSW, the first transport card scheme, T-Card, became a legal saga before being canned.

Now David Glance says the federal government’s Personally Controlled Electronic Health Record project is unfixable.

Problems with public IT projects often start with the engagement process. Clients don’t understand the complexity of the technology required, and the providers often don’t understand the complexity of the business process they are working on.

The rush to sign

IT service providers spend a relatively short period of time understanding the broader business drivers and focus on existing processes to support the sales pitch. The client in turn spends little time understanding the complexities of the technology.

Often the technology and the provider are selected for their appeal and the glamour surrounding the sales process. Both parties are to blame for the project being more complex than expected, the contract not being fit for purpose and cost increases.

NSW was an early adopter of the smart card, of which the first troubled incarnation was the T-Card. The project should have been identified by NSW as high-risk due to the required level of innovation and because ERG Ltd, the technology company tasked to develop it, had not deployed such a project previously. ERG probably understood much of the complexities of the technology but – as seems apparent from press releases – not the broader requirements of data management and integration.

ERG delivered a largely functional application at the point of use, but there was a major question mark over its ability to deliver the necessary infrastructure. One of the biggest problems was that ERG signed contracts with clients around the world to work on similar initiatives at the same time. Rather than trying to develop a specific system to take to market globally, ERG endeavoured to supply different systems to different customers.

Why did this happen? Probably because ERG wouldn’t get paid until each system was operational, which put tremendous strain on its financial and technical resources. The NSW government abandoned the T-Card in 2008. Legal action around the project was settled out of court in 2012.

Misaligned expectations

And then there is the disconnect between the original expectations of the client and that of the provider. The understanding of the complexity of this early stage of a project is the responsibility of both parties.

Even after so many failed IT projects, it is notable that public servants commissioning this kind of work don’t spend more time aligning their expectations and the engineering activities in a way found in other complex innovation projects.

Evidence indicates that clients, in this case the government, identify a provider they can work with and a product that appears fit for the purpose. But providers often drive the implementation, without the inclusion of senior IT staff from the government, which results in cost overruns and a lack of benefits being delivered.

One solution would be for contracts to be signed on the basis of business process improvement. This would mean that engineering requirements become the specific responsibility of the provider and ensure that the provider diligently understood the requirements pre-contract.

Information systems projects are generally sanctioned either by capital expenditure requests, in the public sectors this a budgetary approval process, or by strategic initiatives.

Measuring benefits

The ones that support strategic initiatives are usually deemed more successful than the capital expenditure projects engaged for their return on investment. This is because the expectation is set against business improvement rather than tangible project by project benefit analysis.

The major issue with a tangible benefit analysis is that organisations underestimate cost and overestimate return. To some extent this is a human failing. When this happens a system is doomed to fail to meet expectations.

Information systems of today have such longevity that identifying returns over time is all but impossible. A reduction in cost five years after a system is implemented is difficult to relate to the IT initiative, particularly as other projects will be competing for recognition of that improvement.

A broader recognition of the enduring value of IT would change the emphasis from short term project goals to that of a long term business enabler. This in turn would reduce the short term focus on success or failure to the broader implications of innovative technology adoption.

An information system provider often sees project success as the implementation of IT on time and on budget. The client sees the project as a matter of business or process improvement. And almost all contracts relate to IT specifics rather than business specifics.

IT contracts often obscure objectives through technological jargon, man hours and deadlines. If business objectives and outcomes were better stated in contracts there would be clear and obvious accountability. When there is a common understanding of success the more likely are successful outcomes.

Richard Fulford does not work for, consult to, own shares in or receive funding from any company or organisation that would benefit from this article, and has no relevant affiliations. This article was originally published at The Conversation. Read the original article.

Related Articles