Go-No Go | Bobbie Byrne, M.D. | Healthcare Blogs Skip to content Skip to navigation

Go-No Go

April 18, 2011
| Reprints
Why my hospital chose to indefinitely postpone an EHR implementation at the last minute

To call me a bad project manager would be an understatement. My brain just does not think logically in that manner, and I bristle under the process. In fact, I would rather stick little needles in my eyes than PM a project. Of course, my own inadequacies make me respect the skills in others even more. Great project managers (just like great bedside nurses) have saved me from myself many times.

In our EHR implementation project plan, we had built in a specific “go-no go” decision point. This decision point was scheduled prior to the start of training as, once we were scheduled to begin training, it would mean the expenditure of a whole lot of time, energy and cash. Prior to the “go-no go date,” IT owners meet with all the business owners, review the current module and issues and obtain physical sign-off. This is an actual John-Hancock-on-the-paper, come-to-Jesus type of meeting, but in most projects, it is a formality. Most sign easily, though occasionally, I have had business owners just refuse to sign.

But most recently, they all signed…and then several picked up the phone to call me. The conversations all went something like this:

“I just signed off on the project but I am nervous about it. If I am the only one who feels this way, then I will work through it. We can add some staff maybe or just train really carefully…But Bobbie, there are a lot of work-arounds. It might not be safe, I am just not sure. It is going to be really tough.”

In other words, the proverbial death by a thousand paper cuts.

The project managers started to put all the “show-stoppers” on the wall on flip-charts. Some teams had no issues, especially the financial teams who were working on a more mature code set. The clinical teams, on the new code, had a lot of issues. Before too long, the flip-chart paper was covering the entire wall surface. It was clear to us four days before the start of training that class would be cancelled.

After extensive discussion, we decided not to simply push back the date once again. There were broad concerns that we needed to take a look at our enterprise vendor strategy comprehensively. We had been with the same vendor for a long time. A lot has changed in the last 15 months in healthcare, much less the last 15 years.

Much of the organization called IT and the Executive Team brave for pulling up so long into the project. I do agree that in some ways it would have been much easier to move forward; I'm just not sure it was all together fearless. We just followed the process.



Frank, I agree that what works for a pediatric practice will not work for an OBGYN. But when you first install a system, Work Flow Adaptability can quickly become Customization Paralysis. I see this happen with EMR installs that do not have firm scope and change management processes. Everyone gets a vote and the cost of the implementations goes out of budget. The vendor is then asked why their system costs so much to install.
You train first in the basic configuration, get users familiar with features and functions, then introduce the ability to change templates and work-flow forms post-install. Otherwise, triple your estimated cost of implementation because you will have to create separate documentation, training materials, support manuals, and testing sceneries for each new workflow.

As you can see by the number of enthusiastic responses you've received, this is exactly the type of story we need to hear more of in our HCI online community. Thanks so much for sharing it, and I hope you will continue to provide your from-the-trenches perspective with as much detail as you can share with our readership as your organization moves forward.

There were a few people who asked..hopefully joking..."who is going to get fired over this?" In reality, it is not the culture at Edward to "fix the blame". I inherited this project, but I have no quarrel with my predecessor. You make the best decision you can at the time with the information you have.

Sometimes when you know differently, you do differently. Sometimes not.

Very interesting and informative post. Particularly in light of the HiTech Policy Committee meeting of 4/21 this week. The big discussion was on 'usability'. As we all know there are many ways to define usabilty but one way, as Edwards found out, is 'how many work arounds will it take to do it 'our way', how many are too many'?

This underlies a big problem with almost all the systems developed more than a few years ago. Non-existent or limited work flow adaptability. In my experience when the user has to adapt to hard coded system flow, more so than the other way around, it's a workflow issue not a data of lack of information problem. The data is in the system it just doesn't show up at the right place and time.

I have written more on this at: http://kelzongroup.com/workflow.html

Do you think this was part of the issue at Edwards?

Frank Poggio
The Kelzon Group

Bobbie, Great post! It is that "Group Think" process that kicks in when people do not say what they believe and go along with everyone else. It is what contributed to the Challenger disaster and what still contributes to EMR disasters.

Good point. You sure don't want to get into a custom product. It really is a balancing act, somewhere there is a workable mid-point. I would never recommend 'unlimited' workflow adjustments, but trying to shoehorn a dermatologists workflow into a oncologists system is no good either. 75% is the same across practices /hospitals but it's that 25% that can kill you. Ignoring it won't work, and trying for perfection will banckrupt you.

David Raths nailed it when he commended the dialogue you've engendered. Managing a successful healthcare project, IT or otherwise, requires first-class PMP behaviors. Not mentioned above was the pre-commitment to a written project charter.

Without this, there is no boundary on customization and workflow redesign. By definition, a great project is never done. It is the attempt to squeeze in everyone's mutually incompatible wish list by a given date that contributes to the drama.

JQPoint's observation about incentive alignment is exactly counter to best practice for pilot go live, described and referenced here: http://bit.ly/LionsTigersBetas .

In my experience, those kinds of incentives inexorably lead to objectively unusable implementations being forced on clinicians. Limited resources and time pressures preclude adequate build and feedback every time.

If, down the road, we are going to need to be intolerant of non-use (of a usable system), a project charter is critical. It will clarify what homework needs to be done (e.g. proposed workflow and customization), and, a pre-understanding and agreement on fairness. For more on this framework, continue here: http://bit.ly/HomeworkFirst .

This is as true in the era of Meaningful Use as it was in the past. The stakes, however, are much higher in multiple dimensions.

The easier way to do this is to ask the CMIO, CTO, CEO, CIO, CFO and any other C*O to bond themselves to the amount equal to project cost divided by the number of heads, so that they have a painful share in failure or a sweet share in success of the project. If the project comes out a winner, reward them appropriately. This would make them do their homework..

Agree. We also experienced some of the down-side of our normally collaborative culture. Everyone wanted to "take one for the team".

AMEN, Bobbie, AMEN! Having the courage to choose wisely even after the flight plan had been filed!!!

Good project management and assessing risks / mitigation actions (Go / No-Go), which is a critical part of PM, is as important if not more so than the picking of a product to deploy!

Thanks for another timely post. Did the project plan have explicit attention to learning post go live?

For example, Was it made "... clear that compensation and performance reviews are not based on a successful outcome ..." of the go live?