The views and opinions expressed in this article are mine personally and are not necessarily representative of current or former employers. Objects in the mirror may be closer than they appear. MSRP excludes tax. Starting at price refers to the base model; a more expensive model may be shown.
Why the Healthcare.gov Website Reminds Me of a Big Hospital EMR Project
Despite the old adage that “there is no such thing as bad press,” I think all CIOs would agree keeping your IT project off the front page of the newspapers is a good thing. When the Gealthcare.gov website stuff made the news, it got me thinking that perhaps the project had some traits in common with large hospital EMR projects.
Then my family and friends outside of work — who only vaguely really understand what my job is, anyway — lumped the Healthcare.gov IT project into my past explanations of EMR projects and asked me for my opinion. I decided I might be on to something. Here are my top 10 reasons why the two initiatives could be the same.
10. Apparently, despite lots of dollars spent on IT, failure is an option. Over the years, is has amazed me how many people assume a big budget means success. While a big budget can mask many things, the core project still has to be sound.
9. Strong desires to get it done combined with an important mandate from the top really just creates a lot of pressure, not a sound strategy or rational tactics.
8. A short timeframe due to an artificial deadline (see #9) drives a go-live date. That go-live date will then be a function of the math. That does not mean you have the right go-live date — just that you can count days correctly on a calendar.
7. Slow response times will elicit feedback from everyone who has ever used a computer. Everyone will be an expert. Everyone will compare your slow site to ones that are fast (probably Amazon.com). The hardware and software just have to work. PERIOD.
6. What programmers think is clever does not mean end users will find it to be a good experience.
5. It is a simple order. Vary the steps and you will fail. First the goal, then the workflow, then the specs, then you build. Cheat the order and you run the risk of everyone who once used a computer explaining to you how and why you got it wrong (or why your project is not as good as Amazon.com.)
4. Testing. Do it. If you ran out of time in your project plan, then you missed your go-live date. It was not in the plan to represent make-up days.
3. Workflow, workflow, workflow. You need to configure or build an experience that matches how end users approach and think about their work. When you find your electronic experience intuitive, it is not because something radical was presented to you. It is because the experience followed what you were expecting. The workflow matched your work. It was intuitive.
2. If you stumble, listen to your users. Transparently explain the problem. Do not explain why you made the mistake. Engage your users and fix it. Don’t stop communicating.
1. Listen and involve the people who will use the system. Shadow their workflows and apply it to the new paradigm. Accept that Steve Jobs and Henry Ford were exceptions in not caring what the customer wanted. They knew better. The rest of us mere mortals simply need to listen to our customers.
The politics of Healthcare.gov aside, it broke a bunch of the top 10 reasons above. It was rushed to hit a date. It was not well tested, It experienced software and hardware bugs. Most importantly, it failed to deliver an expected workflow to participants, probably because the initial goals were not clearly defined.
Big EMR projects over the years (and some currently) continue to stumble with the same top 10. Big IT projects are complicated and always involve a lot of hard-working people behind the scenes scrambling to make it work. I’ve rarely observed the problem that the IT team did not work hard enough or care enough. It is everyone’s job to make sure the team is positioned to win, so follow the rules.