Dissecting a health care IT failure

A new report by IT failures expert and author, Phil Simon, takes a deep analytical dive into a failure at a major hospital system. It is currently available for free download.

Most writing on IT failures focuses on either detailed technical problems or high-level strategy and project management issues. As a result, we do not always see clear connections between strategy, culture, technology oversight, and failure.

A new Cutter Consortium report by IT failures expert and author, Phil Simon, fills this gap by taking a deep analytical dive into an IT failure at a major hospital system. Cutter is currently making the lengthy report, titled How Not to Run an IT Project: A Case Study, available free.

The report details how dysfunctional organizational culture, combined with poor strategic planning and decision-making, can lead to technical failure in areas such as data governance and quality. Perhaps most interesting, even these apparent technical problems are actually expressions of poor judgment and bad executive decisions.

Since the report is currently free, I suggest reading it. In the meantime, read a few quotes from the executive summary, starting with a statement of the bizarre culture:

I have never seen a CIO routinely make such spectacularly bad decisions on a project of such import.

Beyond fundamentally ignoring the natural issues caused by a new system implementation, [the hospital system] had long maintained a culture that accepted IT project failure. Long-time employees frequently remarked that all endeavors of this nature suffered from the same issues.

Senior management, and in particular the CIO, made one catastrophic mistake after another, routinely ignoring the advice of its project manager and senior consultants.

Holy cow, what can you say about that!

Here is an edited list of several lessons described in the report:

First, at a minimum, organizations need routine involvement from all functional leads, CXOs, and other heads of lines of business. Allowing them to remain uninvolved throughout a project is a recipe for disaster.

Second, never begin the next round of system testing with so many fundamental issues open, unresolved, or pending from the current or previous round. You may think that you're saving time; you're only postponing the inevitable.

Third, do not look at issues on an IT project in isolation and apart from one another.

Fourth, silencing your consultants robs them of their ability to stop you from making really bad decisions.Tread carefully here. You may just get what you wished for.

Fifth, data governance needs to be imbued in an organization's culture for it to work; it cannot be "crammed in" like a new application. Executives cannot one day embrace data governance and expect immediate results. At a bare minimum, organizations should have in place data quality measures before ripping out their back-office systems.

My take. Ignoring "obvious" causes of failure is a serious problem on many, if not most, projects. In effect, failure means paying insufficient attention to that which seems to be obvious.

This arrogance lies at the heart of many failures. However, the best leaders understand this and take active steps to deal with basic issues early in their project.

Is your organization a leader or follower in the world of IT failures?

[Image of dissection tools from iStockphoto. You would not believe the gross pictures that turn up on this topic!]