Reports earlier this year that the HSE’s €60m Integrated Patient Management System (IPMS) has been beset with problems was unlikely to have surprised a public now largely desensitised to mistakes made by our health service. However, despite the HSE’s shortcomings, experts say failed ICT projects are a common occurrence in all sectors and industries, public and private.
According to Dr Michael McDonnell, lecturer at UCD’s Department of Management Information Systems, a significant contributor to these failures is the unwillingness for companies and contractors to talk openly about past mistakes.
“One cultural issue to point out is the reluctance to discuss failure; which is how you learn,” he says. “There are statistics that say that two-thirds of all projects fail and that’s probably higher in some areas, so if people won’t discuss failures then how do you improve that rate?
“You get very few case studies on why a project failed and the lessons learned because people obviously want to run away from it and blame someone else.”
The IT Capability Maturity Framework
Find a way to overcome this and other problems is proving to be heavy work. NUI Maynooth and Intel are already investing in an attempt to identify reasons for project failure amongst other things, creating the IT Capability Maturity Framework (IT-CMF) to help businesses make better decisions about any significant IT projects they may have planned. So far, this framework has been adopted by 250 CIOs and IT executives across the world.
Martin Curley, professor at Maynooth and global director of IT innovation at Intel echoes the point that analysis of all completed projects – be they a success or failure – is important in lowering error rates in subsequent undertakings.
“It is always very valuable to do a post-mortem on successful and failed projects,” he says. “It’s a sign of a mature organisation when they are able to learn from everything they do.”
Pre-emptive analysis is probably even more important, however, as companies that rush into the technical side of a project without giving their aims proper thought are bound to end up with an inferior result. Giving this extra time to analysis not only means that targets are based on more considered and realistic calculations, it also leaves the contractor in no doubt about what is expected of them.
Such research may also show up good examples of similar projects elsewhere in the industry or wider business world. Better yet, it might even lead companies to find existing software that only needs to be tweaked to fit their needs, which can prove much more efficient and cheap than re-inventing the wheel.
Using consultants
However, assuming the company is starting from scratch, a clear vision of what is needed is extremely important, specifically where consultants are employed to draw up a specification. Otherwise, there is the risk of the brief being pushed away from the client’s original outline to something more suited to the consultancy’s creative abilities.
The solution to this? More consultants, says McDonnell: “I’m being a little bit flippant in saying that but the thing that that points to is that whoever is paying ultimately has authority and should construct contracts effectively.”
In other words, the company in question should be sure to keep charge of their project and not let the likes of consultants push them in a direction they do not want to go in.
An extremely definite set of requirements can also give companies the option of creating a target-led contract rather than one based around a deadline or budget. This type of contract requires a very specific set of specification which has no room for differing interpretation but is quite beneficial where possible.
“Projects fail because requirements are wrong,” says Curley, who adds that a clear management structure is a good way to cut out any kind of project creep. “Sometimes, there are too many cooks but sometimes there aren’t enough or maybe IT is doing a solo run on something. There needs to be more accountability with the buck stopping at project managers so there’s no placing blame elsewhere.”
One of the biggest issues the HSE had with its IPMS was its disjointed implementation nationwide. While the software was originally designed to become a networked, national platform for patient information it was implemented and used in very different ways depending on the hospital in question.
This is because of the different work practices that existed in different health boards in the past and shows that a project’s success can hinge on the ability to change staff habits as much as anything else.
“There have been cases of people buying software and then finding it takes two-three years to implement because they need to change their organisation and how it works to use it properly,” says McDonnell. “There are competitive arguments for [changing an organisation] though… researching how other people do it and finding best practice is very necessary.”
Pulling the plug on a project
While both McDonnell and Curley believe project failure can be minimised it is to be expected that it will always exist to some degree. In these inevitable cases the important thing is to be able to pull the plug early, rather than spend good money after bad to salvage something of little value in the end.
“Sometimes, the kinder thing to do is to kill a project even after it’s failed,” says McDonnell, citing the example of Dyson which scrapped its washing machine product in favour of investing more money in the hope of future profitability. “You can see very early on when a project is going badly so there should be metrics and indicators as something is going on so if it gets worse you should be able to question it. From that it might become apparent that it’s time for you to shoot it in the head rather than sit and wait for the inevitable to happen.”
Being able to make that call may be easier said than done, however.
By Adam Maguire
