I have sat through a few presentations with titles such as “What Went Wrong With Our CPOE Implementation.” A recurring theme in those powerpoint slides is a perceived “lack of strong senior managment support.” In my opinion, this is an incomplete analysis.

Is it really the case that senior leaders are too lazy or uncaring to champion these new information systems? I don’t think so. I think the trouble lies a little deeper. I suspect the scenario goes like this:

1. The project folks go to senior management to dsiscuss adoption problems with the hope that they will “force” the physicians to use the system.
2. The CEO or COO approach the top admitters to discuss the situation.
3. The physician responds by stating that the system sucks and s/he would rather practice at the competing hospital than use the system.

Is it really strong senior leadership that would turn away a significant amount of patient revenue and jeopardize the ability to fund the mission of the organization?

I think the real issue is that the planning and anlysis failed to ask some real hard questions about the risk of physician resistance and the limited options the organization may have in that event.

I also think that usability has to be a primary focus and it may be that most products are not to a state that they are easy to use.

Hospitals with hospitalists and teaching staff have an advantage. But even those will have a large number of physician customers that can take their business elsewhere.

I believe a key to a successful IT project is ensuring that it has a clear business purpose. In my opinion, this works best when the project is being lead by someone outside of IT that has a stake in the long term success. At Affinity we strive to assign a non-IT Project Champion to each project and make them accountable for the results.

In an earlier post regarding statements of work someone commented: “In my view a SOW included the commitments (read “promises”) that the internal personnel are making to each other. I submit that it is MUCH more important to make the promises to ourselves before we make them to vendors! “

This is my view too and I appreciate that I am not alone. The first draft of that internal agreement is developed by the Project Champion using our Project Champion Agreement.

Feel free to borrow from this liberally. Please tell me what you think.

Most managers think an IT project follows this sequence:

• Demonstrations
• Software Acquisition
• Implementation

We have to beat this out of them. OK, we need to educate them. But we need to beat the vendors who reinforce this mindset.

I go ballistic when I am invited (along with a list of others) to attend software demonstrations for the purpose of choosing some new computer system. To accomplish what? Much more time needs to be spent setting goals and criteria for choosing said system (if it is needed at all).

Just as importantly, we fail to spend time putting the plans together before the software is purchased. One can easily spend 6 months planning an average size IT project before the software even arrives. There are processes to re-design, interfaces to spec, conversion extracts to write, training plans to develop. Why start this after the software contract is signed? So the software can sit on the shelf and the vendors can spend our money while we do the prep work?

Every project is going to be different. But a better model is:

• Develop goals, success metrics and required features/functions to achieve the goals
• Demonstrations
• Software Selection
• Intense, detailed planning
• Acquisition
• Implementation
• Success

In my years as a consultant I observed that most projects failed to accomplish their business goals. As a CIO one of my most important charges is to keep projects from failing. My observation is that projects fail for two reasons.

Firstly, projects fail because they don’t have any clear business goals. These projects are easy to spot because they typically begin with someone coming to me and asking to buy a computer system. When the computer system is the focus, and not solving a particular business problem, then we are in trouble (see the Barbie Syndrome post).

But even when project goals are clearly defined and success measures are in place projects can fail. This typically happens when the project becomes so burdensome the focus changes to just getting the project done.

In my consulting engagements I remember attending meetings toward the end of a long project where the clients were trying to figure out what went wrong. Their observation was generally that over time they lost sight of the project goals because there was too much work.

I now realize that this is not something that happens gradually. Instead, there is a point in time when an in influential member of the project or senior management will state that it is OK to forget the goals and just get done. It turns out that this happens as fast as a “click.”

Of course the best way to guard against this is to develop plans that accurately estimate the resources and total effort. This is easier said than done. Most organizations are terrible project planners. There is always a push to buy the software and get started.

Today, If someone ever asserts that it is time to let go of the business goals I will say “click” . Most of the people here know what that means. If not, they will by the end of the meeting.

I know Cam Jansen does the “click” thing too, but I think I did it first.