The following article appeared a day of so on the web. It contains some useful ideas but, as far as Health IT is concerned I suspect there are a few other factor that need to be considered.
================================================
http://www.cio.com.au/index.php?id=1952027913&eid=-601
Why Public Sector IT Projects Fail
Sue Bushell
03/10/2006 15:44:47
What makes big-ticket public sector IT projects so uniquely predisposed to fail? Two new recent reports from the UK highlight political expediency and the constant state of flux within governments and government departments as sharing a big part of the blame.
For instance, during the 10 years from 1995 to 2004, UK central government departments endured on average 16 reorganizations a year, including (counted as only one each), Scottish and Welsh devolution.
And while it's axiomatic that "events, dear boy, events" will change government policy, having large projects that spread across years only increase the chances of the project being affected by a change in Ministerial, governmental or a departmental reorganization, says Quocirca Principal Analyst Elaine Axby in a new opinion piece for Robin Bloor's IT-Director.com.
Axby points to the very nature of the public sector to pinpoint some of the other leading causes of failure. Looking at the key project management criteria of time, performance and cost, she says people in the public sector are not very driven by time. With a culture that offers little pressure to get a project out of the door by Christmas, or before a competitor does, public servants find it hard to accurately assess how long things will take.
Performance, or what the project should deliver, is often derailed by hastily introduced policies, and the very wide array of stakeholders who need input into most public sector projects.
"Given that the estimates of time and performance are not very good, then is it surprising that cost estimates are often wildly inaccurate?" she asks.
Moreover government IT projects struggle with the concept of ownership, and frequently do a poor job of managing stakeholders, Axby says.
Axby repeats the tired old line about good project management not being rocket science, and goes on to suggest that really embedding it in the public sector would make a big difference, as would getting proper business ownership and being able to manage scope creep. She also says smaller projects can help.
But she says while all of these measures can ensure public sector IT projects do better, it is the very nature of the business that government organization and priorities will change.
"I can't easily see any end to the stream of negative National Audit Office (NAO) reports - but really adhering to some of the basic principles of project management such as getting the business case right, clear ownership and better stakeholder management would be a big step forward," she concludes.
Meanwhile Butler Group senior research analyst Mike Davis asks: "If you know that your new computer system, designed to process many millions of pounds for hundreds of thousands of people has 52 critical defects, 14 of which cannot obviously be fixed, and that of the 40 previous audits during the development period, 70 percent had identified serious concerns, would you deploy? Well, of course, it depends on the risks vs the expected benefits. For, if even with the faults it is better than the previous system, then there may be an advantage to deployment.
. . . However, what if three years later your staff have to use 600 manual 'workarounds' to the system to get their job done, and productivity has fallen? Then, in my opinion, it wasn't fit for purpose."
That's not just Davis' opinion, he says, but also that of the NAO in its report about the development and implementation of the systems for the UK Child Support Agency (CSA), released in June 2006. The CSA systems were developed by EDS during a three-year period, and went live in March 2003, after getting the "green light" from the UK Treasury's "independent" Office of Government Commerce (OGC).
Davis says he is concerned by the apparent failing of the OGC to recommend the stopping of the project, and concludes it all demonstrates yet again that in public sector IT, project management disciplines are often rejected for political expediency.
================================================
The key point made is that managerial and organisational instability is a major cause of failure. I agree this is important, and indeed, when one reflects on the Public Health Sector it is really a relative rarity to have an Area Health Service CEO or CIO serve out their full five year contract. This flux is due, in part at least, to a combination of Government and Ministerial changes, changing policy priorities, some being perhaps promoted beyond their capabilities and the unexpected events that precipitate management change.
However there are a few others factors I would rate even more highly in Health IT.
First, especially in the public sector, there is often a disconnect between the managerial responsibility placed on a project manager and the freedom to act they are accorded. At times this leads to the “wrong” staff being retained in roles for which they are no longer suited to the detriment of the project as a whole. The disconnect (and budget inflexibility) also often leads to difficulty in attracting and retaining suitably skilled staff as well as excessive delay in staff acquisition. The other problem that is almost universally encountered in Hospital projects in my experience is the “drip feed” of funds and the difficulties in getting suppliers paid. More than once I have seen competent project managers just resign in disgust when they realise they have neither the spending authority, money or the staff to deliver the project they are required to make happen.
Second, because executive health-care management often have a degree of anxiety related to Health IT, often associated with a fairly limited understanding of what is required, at an executive level, for project success, the quality of project sponsorship and support is less than is needed. Senior executives, like everyone else, prefer to stay within their “comfort zone” and if the Health IT project is not within that zone real difficulties are almost inevitable. The project manager has a real responsibility to carry the project sponsor along on the journey, and to make it clear what they must do for the project to be a success on their watch!.
Third, clinicians inevitably see a new system as a very low priority in their “caring for their patients” activities. This will lead to all sorts of difficulties with change management, training and effective use of a new system, unless both executive management are fully committed and real “clinician” evangelists and enthusiasts are recruited to work with their peers.
Fourth, involvement of all relevant categories of clinicians in the selection and later configuration of systems is crucial. The clinicians really have to be confident the system will work for them and be convinced of its value and utility or the project will be at extreme risk before it even starts.
Fifth, there is a real tendency to underestimate the complexity of and the effort required to implement say a new laboratory or patient management system – to say nothing of clinician facing systems such as Computerised Physician Order Entry or Computerised Nursing Documentation which involve virtually all key staff changing the way they work. Careful planning and an really adequate emphasis on education are vital as is developing real clinician ownership of the project.
Lastly is it clear that all organisations need to develop organisational competence and teamwork with Health IT. I think the best way to do this is to choose one or two easily “doable” projects and get them done on time and within budget. Only once this capability is proven should an organisation try the larger and more complex implementations. Success, as they say, builds on success.
David.
No comments:
Post a Comment