This article is by Richard Fulford, Senior Lecturer at Edith Cowan University. It originally appeared on The Conversation.
analysis 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. 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.
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.
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.
Gee we go in cycles. Nice in theory. been there before…
I remember being the internal change manager responsible for specifying and contract managing all non-technology related aspects of one of the largest software/IT projects in queensland in the 1990s. This was due to previous failed IT projects – the response was to make the supplier responsible for everything that way surely the change management should stick and you would get the business improvements you sought. My brief summary – not sure it worked as well as it was meant to – even though ultimately the project was deemed a success – the change management and business improvement was brought back in half way through because perhaps there are somethings you should really own and do yourself. And to get any real substantial outcomes one has to know your business better than you would otherwise – and by the time you have learnt that and then have to specify it all out so you can make someone else accountable for doing it you may as well have done it yourself – because afterall its your organisation!
re “IT contracts often obscure objectives…”
I disagree. – IT contracts ALWAYS obscure objectives.
IT contracts are written around requirements. Requirements describe (for better or worse) solutions, not objectives.
That means someone in the public service has decided what the solution should be and have tried to describe it. Most of the time, other than for very simple projects, they get it totally wrong.
The whole government procurement process is fundamentally flawed because of this separation of objectives and solution. And it’s the fault of the government procurement process. Because of probity the government has to describe exactly what it wants to buy so that all potential vendors will be on a level playing field.
Unfortunately that level playing field has unclear boundaries and is full of unseen potholes.
The alternative is to do projects in two phases
1. Address the problem and identify the requirements
2. Issue an RFT based on these requirements.
Unfortunately, because of probity, any vendor who does 1) is usually excluded from 2)
As there is more money in 2) the very vendors who may have the skills in problem solving as well as in solution implementation don’t go for 1). Those who do have little experience in solution implementation and often make a mess of it.
The system is set up for failure. Just don’t blame the vendors.
Robert X Cringely commented on IBM’s role in the Queensland Health IT failure
http://www.cringely.com/2013/08/07/fulfilling-customer-requirements-is-a-weapon-at-ibm/
“The Australian IT project debacle is a classic example of IBM’s unique way of managing projects. The core of project management is “documented deniability.” They will do exactly what you tell them. They will document it. They will work against the documented requirements. When done, you have to pay them because they did exactly what you told them. The key problem to this approach is “does it work?”
The ultimate goal of every project is to build something that produces value or income. A factory makes products. A bridge assists transportation. In IBM’s project management IBM does not care about the ultimate goal. That is their customers concern, not IBM’s. This is very important for IBM’s customers to understand. It is the reason so many big IBM projects are failing.
This is the way IBM historically does its business, even in better times. Remember the mantra has always been to fulfill customer requirements. But somewhere along the line the whole idea went horribly, horribly wrong.”
“ERG Ltd, the technology company tasked to develop it, had not deployed such a project previously” – didn’t they deliver the Hong Kong MTR smart-card system? Hugely successful.
This report also misses a major reason these projects fail and that is the resume’, not the suppliers resume or the system resume but the resume of the hierarchy that really needs a big product/system name on it to get that next higher position. If you as an IT professional argues the point for an actual relevant system and supplier then the result is that you are no longer needed. By the way it is not the MP’s fault, not labour or liberal but the public servants, but that is O.K. they will just blame a contractor after all that is what they are there for.
Comments are closed.