Home » News » Currently Reading:

Being Ricky Roma, or Tales from the Dark Side, Episode V – The Empire Strikes Gold

March 23, 2009 News 19 Comments

Today’s posting is all about gold. After my last note, someone had posted a suggestion that all negotiations should follow The Golden Rule. I agree that “doing unto others” serves all people well, both professionally and personally. Yet this note will be about the other golden rule, the one which brings order to the Dark Side: he who has the gold makes the rules.

In our HIS universe, The Dark Side’s source of power is actually derived from HIS executives who control the allocation of countless bags of gold. As a hospital IS exec who has this gold, you bear a fiduciary duty to your organization to impose your rules when setting out on a process that ends with dispersing cash to deserving (or undeserving) vendors. After my last post, another reader astutely noted that this duty is shirked in “three out of every four projects,” lending much cred to my assertion that “you (collectively) don’t know the power of the Dark Side”. 

Most research on this topic concludes that today’s software project failure rate is around 66%. We on the Dark Side know this. We earn BILLIONS of dollars selling you $3 worth of software or services to deliver $1 worth of value. This 3:1 cycle powers the Dark Side. 

We pay good sales people hundreds of thousands of dollars. We employ armies of storm troopers who are better paid, better trained, and often better looking than their opposite number at the hospital in order to keep this so. We build illusionary demos that touch upon your deepest desires. We learn which ones of you can be taught, fought, or bought. Right before HIMSS, we do things like send Mephisto shoes to all the Ingas in our sales forecast. And occasionally, when we sense that one of your best staff have enough midichlorians, we purchase their soul and lure them away to join us. 

As compensation for all these efforts, you continue to pay us $3 for every $1 of delivered value. We sell you software that doesn’t work and you keep coming back for more. This is power!

Can you just image Jacques Cousteau narrating a documentary on this unique ecosystem? “‘ere we see zee energetic ZIO, bizily darting in en out among zee magnifizent coralz near zee ocean floor, building and rebuilding two of heez three nests, over and over again; blissfully unzaweare of zee predators stealing heez eggs right in front of heem… What vill become of zis endearing creature?”

In real life, you need look no further than the musings of this HIStalk post over the past several weeks for some outstanding examples of where HIS vendors are putting the golden rule into solid practice. HIStalk readers were more than a little upset to learn that Allscripts CEO Glen Tullman was whispering in the ear of our new president to “help” to determine where the billions of dollars of federal stimulus funds ought to be deposited (I wonder if he mentioned the 3:1 ratio? “um, Barack, Mr. President, Sir … we’re actually going to need more like $6B for this thing. $4B will be for projects that we already know aren’t going to work out…”).

Our new Healthcare Czar, Kathleen Sebelius, is/was on the Board of the very architects of the Death Star itself. And now, right after the passing of the stimulus bill and just before HIMSS, there is indignation that Wal-Mart is entering the EMR market with eClinicalWorks (did anyone really think Girish was sitting idly by while Glen had his feet up on the table in the Roosevelt Room?) I, for one, am anxiously awaiting Jonathan Bush’s raise in this particular hand!

As an industry, you have become adept at giving away your power. The gold starts with you, but you are not using it to make the rules. 

Don’t agree? A month from now, you are going to let an actor, Dennis Quaid, who recently suffered through the scare of all scares, tell you how to do a better job in delivering safer healthcare. I recall being at Mardi Gras one year when Mr. Quaid was King of the Bacchus Krewe, throwing beads to half-naked women. That seemed at the time to be a position of pretty high authority. He does have quite a lot of gold as well. These credentials obviously give him the power to start making some healthcare rules. I hope he says to buy more software …

What is the answer? Just like it was for the fictional Luke Skywalker, it is to look within. "Do, or do not; there is no try," Luke was told. Your Board, CEO, VP, and general public should be asking the same thing of you. Why is it acceptable to you that two out of every three of your projects fail?  Why is it OK that you give away 66% of your gold in exchange for something that did not achieve its goals? Why do you and your staff forego the diligence that you would invest in your own personal spending when buying HIS software based on a sales demo and a visit to a showcase site? Why do you keep paying for, and keep buying, s@#! that don’t work? 

Are we on the Dark Side that good?

Ricky Roma is a vendor sales guy who understands that only one thing counts in this world: get them to sign on the line which is dotted.

View/Print Text Only View/Print Text Only

HIStalk Featured Sponsors


Currently there are "19 comments" on this Article:

  1. How about a link to the study that says 2/3 of I.S. projects fail? I don’t believe that number — prove me wrong. What’s the definition of project failure? How often does a project fail because of the vendor or the customer. Projects can fail for lack of staffing, lack of support, organizational roadblocks, etc. Software not working is not the problem in 2/3 installs.

    While I know there are poor vendors out there and salespeople that will out and out lie, I do think they are generally the exception and I don’t appreciate Ricky’s broad brush.

  2. Let’s get very real. Vendors’ products may or may not be good. Their sales culture may or may not be sleazy. At the end of the day, the most important factors in a successful implementation relate to the buyer’s clear objectives, clinician involvement from the get-go and commitment. I’ve seen some pretty crappy software deliver value when these elements are in place. Can we stop the madness and get to the real issues??? Interoperability is key (yes, some vendors are really delivering, others just “talk the walk”). This isn’t for the feint of heart. Step up or step out.

  3. I am surprised that you feel that all EHR vendors have the same Ricky Roma attitude. Shame on you, there are actually companies that have built their business on customer satisfaction. When their customers have problems they do too.

  4. That is F – U – N – N – Y- !

    I can’t wait to read the comments left by the “dark side” to deny and bury the truth behind the humor!

    I’ll just step aside, sit back, and enjoy the avalanche of comments I expect this article to generate.


  5. Oh… this was good reading! Thank you RR for coming up with an analogy that most geeks will understand and most users know all too well. And while it is silly to try and defend the analogy for all the people, all the time – it has enough meat on its bones to make both vendors and buyers things. Vendors- what will you do when the rebel forces attack? Do you truly think you can withstand them – the smaller companies, lighter, quicker… you were once one of them… or maybe it will come from a direction you don’t even understand right now. And buyers- and by that I mean non-IT hospital executives, how much longer will you put up with getting bullied around by your IT staff – who are in league with the dark force. When will you sit up and remember you have a brain and a heart – use them and question those that consipire to sell…. OK, I’ve officially used up my share of analogies.

  6. Having lived both sides of this Good and Evil…I don’t believe all vendors are sleazy. They are just misaligned. The publicly traded companies are the worst. They are beheld to the ‘shareholder’ and SEC revenue recognition.

    It is almost impossible to align the vendor with your goals. Try to get a vendor to allow payment milestone to be completion of one of your strategic objectives, or take tie that milestone to a quality initiative. They will act like they don’t want your business.

    Back to the point about sleazy. Some vendors are just transactional. Several hardware vendors come to mind…and a storage vendor in particular. They just are so quarterly driven they can’t focus on your needs…just the funnel and the pipeline.

    It has been eye opening on this side of the force. Very rewarding, and really, I feel as though the force IS with us…

    At the end of the day…these are just tools to enhance a business process…most vendors think Go Live is the end game. In an IT Project it is…but these are not just IT Projects…

  7. 66 percent fail? We’d be out of business.

    How about 100 percent of 2007-2008 clients say they were 100 percent satisfied with their implementation? We can do it. If it wasn’t for a clearly anti-interoperability stance by some of the major vendors in healthcare IT, the market would have put them out of business already. Do you belong to one of those vendors?

  8. The 66% project failure rate is something I’ve seen before in old project manegement literature — a supposedly common failure rate for ALL IT projects, (not just those in Healthcare IT). So, us greedy bastard HIS vendors must not be any worse than those greedy bastard manufacturing, banking, defense, and other software vendors!

    I’ve been a vendor project manager for years and have certainly seen my fair share of project failures, but 66%? No. Not even close.

    But one thing I’ve seen repeated time and again– sell and install the exact same software using the same vendor sales & implementation teams at two different customer healthcare organizations. One organization is wildly successful. The other is a complete failure. Hmm, why is that?

    You’ve hit the nail on the head– until organizations begin looking within and embracing a performance-driven culture that thrives on change, the majority of their projects will continue to fail.

  9. I agree with the above comments. It does take a consorted effort amongst clinicians, IT and vendor to launch a sucessfull implementation. I would offer this as food for thought; when CIOs and IT vendors are drinking the same Koolaid, regardless of what is best for patient safety and clinical workflow, a project’s success/failure hangs in the balance.

    I have witnessed many a time where the mentality of “If xxx vendor makes it, I will buy it” without taking into consideration what is best for patients and clinicians. Ease of integration and the blind loyalty to a software vendor take a front seat. (Translated CYA). Very few CIOs want to tell their board they made a wrong decision in vendor selection or there are better/safer options available.

    The old mentality of “It may not be the best solution but it will work” will end up harming a patient eventually due to a lack of end user compliance fostered by a sub-standard solution.

    Think about your patients and clinicians, and stop taking the easy/cheap way out. The end result may just be healthier patients and happier employees.

  10. Re: Skeptical. For prove me wrong detail, I would recommend starting with this Journal of American Medical Informatics Association article published online on March 4, 2009: http://www.jamia.org/cgi/reprint/M2997v1 (warning, pdf). It is healthcare specific and neatly summarizes a large body of work in this area. Then for even more background, research the 78 additional studies which are cited.

    Is the 67% failure rate sacrosanct? No. Is an actual figure generally agreed to be an abysmal number? Yes.

    Does it really matter to, say a hospital’s board of directors, whether HIS projects fail because of staffing, lack of support, organizational roadblocks, or software not working? These failures are not necessarily always about Dark Side sales people lying or being sleazy, they are about HIS management not using their gold to set their own rules for being successful. Instead, they let us set these rules.

    For suggestions on setting your own rules, see my last note.

  11. Much research has been conducted to understand why IT projects fail or fail to deliver expected results. First, there must be an understanding of the word failure. Project failure in a practical sense has the following qualities (Stellman & Greene, 2007):
    The project costs a lot more than it should.
    It takes a lot longer than anyone expected.
    The product doesn’t do what it was supposed to.
    Nobody is happy about it.

    With no significant changes in the way projects have been managed, The Standish Group (1995) published their findings pertaining to IT project failures.
    31.1% of projects will be cancelled before they ever get completed
    52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars.

    The Standish Group estimated an additional $59 billion for software projects that will be completed, but will exceed their original time estimates the the cost of canceled projects to be $81 billion.

    On the success side (Roop, 2007)
    16.2% for software projects that are completed ontime and on-budget.
    In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements.
    Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions.
    Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.

    There’s a myriad of reasons for project performance issues. For ease of discussion we’ll use Stellman’s classifications.

    ď‚«Things the boss does
    This covers all leadership levels.
    It is not just project leadership that significantly affects project success. It is key for both executive leadership and frontline leadership to buy in and understand the project. There must be project champions are all levels of leadership. Lack of leadership dooms projects.
    Clear goals and success criteria.
    Often there is not a clear understanding at all levels of what the project goals are and how success is measured. This muddies the communication efforts and can fragment leadership and learner groups. The lack of success criteria can water down a clear understanding of what was achieved.

    Also changing goals or competing projects can water down the success of a project.

    Assembling the right mix of skill and talent.
    Leadership must understand the skill mix needed to reach success. This skill mix may require training current staff or augmentation by experienced contract help. Contract labor must be chosen carefully, more “not rightly skilled” folks will not get you any closer to success. Understanding the skill mix needed allows organizations to spend their consulting dollars on the skills they need.

    Understanding the words “estimate” and “plan” goes a long way.
    Often once a project is scoped and a plan is written, leadership takes that plan as a set-in-stone standard instead of a fluid document. Depending on the experience of the project manager and the openness of leadership, you may need to revisit this. Many times project plans are written to arbitrary dates without real consideration of cost and time.

    Performing a lessons-learned session as the organization moves forward can prevent the same type of missteps in the future.
    The deliberate synthesis of past performance and errors can result in future success. Soliciting feedback from all stakeholders can forge alliances and solidify future support for projects because input is acknowleged and acted upon. This is a risky move because it may actually force an organization to reconsider active projects (timing, budget, resources).

    Things the software does (or doesn’t do)
    If installing an off-the shelf product it may not match the business process of your particular group.
    If customizing software, failing to involve users at all levels will result in a product that does not quite meet the needs of the people you built it for.
    Including business process redesign and change management considerations on the front end of a project can prevent this misstep. The inclusion of stakeholders in both the custom design aspects and the business process impact can provide vital information to a successful project.

    Things the team should’ve done
    Skill mix in the project team is crucial to success.
    Organizations have inexperience staff who need to be paired with experienced staff so that the organization as a whole can be more successful over time with projects.
    Staffing models must be scrutinized in light of skill mix and project milestones.
    Lean staffing for the sake of saving money will not get you closer to success if you are overstretching staff. Investing significant dollars in consulting resources that duplicate efforts also will not achieve success. Again, more people is not always the best solution, but staff augmentation resources that are skilled and experience can provide respite and refocus for staff.
    Communicate Communicate Communicate.
    It cannot be underestimated the value of messaging and timely communication throughout the organization. The thrust of communication efforts should be to touch each level of the organization with accurate information the connects all stakeholders to the reason for and success of the project. It is not technology for technology’s sake.

    The WIIFM’s (what’s in it for me) contribute to project buy in and software adoption. Projects need to deliberately include resources for change management and business process input and management. A detailed plan keeps the project succcess forefront and manages and mitigates resistance and obstacles along the way.

    Things that could have been caught but weren’t until it was way too late
    There are several reasons things might not get caught in a timely fashion
    Project plan that is inadequate
    Project team that does not reflect all stakeholders
    Inexperienced team who could not foresee difficulties
    Corporate culture that minimizes difficulty, pressures to meet deadlines or sets unrealistic deadlines
    Dissenting voices being silenced to keep the status quo
    IT culture that ignores the end user. Often IT professionals are very disconnected from the user of the technology and see no value in understanding how the technology is implemented.

    To be successful, organizations must embark upon a project with eyes open to the potential but also to the pitfalls. Here are some basic requirements for project success:
    Leadership at all levels must understand the business case for the project. They must be the champions of the project goals and wins for the organization.
    There must be a defined plan for continuous communication to all areas within the organization and key stakeholders. Information brings power and buy in. The effect of change and change resistance must not be underestimated.
    Skill mix of resources must be analyzed to appropriately use current active staff and to wisely use consultant dollars.
    End Users must be included from the very beginning. Failing projects assume that once the technology is in place, people will naturally and automatically use the software and will adopt it fully into work practice. Overlooking end user involvement in the development and implementation process can spell disaster. If there is no incentive to change, end users will not (The Glue, August).

    Humphrey, W. (2002, May 20). Five Reasons Why Software Implementations Fail. ComputerWorld , pp. 22-23.
    Lewis, K. (2003). Eight Reasons Why Software Implementations Fail. Houston, Texas, United States of America.
    Neimat, A. (2005). Why IT Projects Fail. Project Perfect.
    Roop, E. S. (2007, September 4). Gone to Pieces. For the Record , p. 16.
    Stellman, A., & Greene, J. (2007, June). Why Projects Fail. New York, New York, United States of America.
    The Glue. (August, 4 2008). Top 10 Reasons Strategies Fail to be Executed.

  12. As a vendor I am more than willing to be held to my promises of successful payback, however I am surprised how payback does not seem to be a compelling argument for customers. Is it because no one believes it? Is it lack of follow-up studies? I constantly wonder.

  13. Hey Anthony…this is a blog, not a classroom. Lots of good info, but summarize better and leave links. No one has all day to find your point of view.

    Meanwhile, RR has given us great food for thought…and discussion. The high “failure rate” of course depends on the definition of “failure”. Anthony did shed some light on that.

    One definition of “successful EMR implementation” that is in use in the ambulatory EMR industry is “Is the EMR being used on at least 80% of all patients seen at the end of six months?”. If yes, then the term “success” is attributable to the installation. Is the six months right? Most practices would hope so, but the reality is otherwise. By this definition, one industry pundit puts the “success rate” as well under 50%.

    Will it take longer for a 20 physician practice than a single doc practice? Definitely, because I’ve yet to find a practice where all providers in a larger practice agree on the urgency of EMR…or agree to use it if it is deployed.

    But the failure rate of a big number like 67%, certainly by that standard, is pretty-well established in the ambulatory practice market. Not all for vendor reasons, as RR implies. With involvement in dozens of EMR implementations, I see basically four principal reasons why EMR failure causality can fall on the practice side, rather than the vendor. I’ll only mention two here because these two are pretty pervasive…and I don’t want to be long-winded after letting Anthony have it.

    First, for many practices, the EMR product is a lot harder to use than they thought. Templates are not included in the out-of-the-box product. Too much customization is needed to get it working. Discrete data collection is a mass of nested pull-down menus and screens. Resulting chart notes are “robotic” and hard to customize. Training provided is FAR from adequate enough to allow doc’s to confidently begin charting electronically. Cost for “add-ons”and additional training adds up to big numbers. Practices quit using the system in a short while.

    Second, even for many practices who DO get implemented and commit to seeing patients using the new EMR, it just slows them down so much, they can’t see as many patients or have to stay extraordinary hours afterwards “catching up”. It’s a drastic change from the way they have conducted exams in the past. Technically competent docs even have issues here, let alone those who aren’t. Revenues are lost and/or hours are added on at the end of the day. The expected ROI is a long time in coming. All the money saved by vendor claims of cutting out transcription, lost charts and illegible writing is very elusive.

    So, the two common reasons why EMR failure are PHYSICIAN-based…really comes back to the vendor products…they just plain are not designed to make it easy for docs use, maintain productivity and practice medicine the way they want to.

    There are only two paths out of this conundrum, as Government incentives are put into play next year for EMR deployment: Physicians have to bite the bullet, learn the EMR’s and accept the issues that come with it….OR…EMR’s have to change to emulate the way PHYSICIANS practice now, and not slow them down. That’s called hybrid EMR. Not as much discrete data collection in the exam, but complete digitization of the office. Extremely high deployment success rate. Made for high-volume practices. Which way will the market go?

  14. today i got ENHANCED death star software to play with. in the parlance of our times i will call it…death vader.
    /cerner shop
    //shoot me now…

  15. RR, thanks for the link and the ‘clarification’ that you didn’t blame 66% of project failures on the vendor… but you did. How else were we supposed to interpret your last paragraph? Your final sentence says it all:

    “Why do you keep paying for, and keep buying, s@#! that don’t work?”

    Listen, maybe your experience was selling s@#!, maybe you feel like s@#! for all those BS demos you did, but don’t assume we were all like you and don’t BS us when you ‘clarify’ now that you didn’t mean the 66% failure rate wasn’t all the s@#! software’s fault.

    If you want to write a column on how projects can be more successful, that’s a good topic. If you want to write a column about some bad vendors, that’s fine too. But quit the broad brush that HIS vendors are lying sacks of s@#!. We’re not all like your employer.

  16. I’m reminded of a concept I learned in evolution called “gambler’s ruin”. The basic concept is that anything that sticks around long enough will eventually fail/die/collapse, because success doesn’t guarantee permanent success, and failure is a one-way sort of thing.

    Health IT projects are some of the longest IT projects around, with EMR installs taking 3-5 years, and even longer if you measure from point of conception to goal achievement. That’s longer than the lifespan of the average hospital CIO (actually 2 lifespans!). Everything people say is needed is obviously needed to make these succeed, the problem is that there are way to many chances for the project to fail due to calamities outside its control over such a long period of time (budget, change of priorities, loss of champions, change of business needs, vendor or product issues, general mismanagement, etc.). Until you can get the systems good enough that you can do these quickly and without years of configuration (seriously, are all hospitals/clinics _that_ different?), this will never change because the healthcare market isn’t exactly getting any more politically or financially stable.

  17. Reefdiver gets it right – clunky EMR products slow down physicians too much. If products were intuitive and fast, adoption levels would be much higher. Also, it only takes one or two episodes of unplanned downtime to make the entire project fail.

    What is needed goes beyond a “hybrid EMR” – it’s a Virtual Care Plan. Let all products support the patient’s care plan in a virtual space, from every perspective.

  18. What DrM is referring to is extremely important. Medicine is a constantly changing thing, and the regulations around it (and semi-regulations, think Joint Comission) are changing even more rapidly. So if you are at a (typically big) company with multi-year software builds, by the time the software is done it is already out of date, and your implementation staff is already figuring work-arounds for the current environment, and the software is not even live.

    Smaller, more agile companies move with the environment, which aligns the clinicans “what’s in it for me” with the current regulatory, risk, and financial incentives.

    John Glaser made some very good comments the other day about the solution to an HIS department becoming more agile, in order to bring more value to the clinicans, patients, and administration at a hospital. How are you going to achieve this with a product from the dark side on a 3 year release cycle?

    As a clinician I’m looking at the rapidly changing healthcare regulatory environment and changes that the new balance in congress is likely to make, and I’m not looking to the death star for answers.

Subscribe to Updates



Text Ads

Report News and Rumors

No title

Anonymous online form
Rumor line: 801.HIT.NEWS



Founding Sponsors


Platinum Sponsors



























































Gold Sponsors
















Reader Comments

  • Vaporware?: Secretary Shulkin: "the American healthcare system hasn’t yet figured out interoperability, but the VA can lead the wa...
  • Justa CIO: The reported go live date for McLaren Oakland is wrong. There are no dates set for activations for any locations. Post...
  • Brian Too: I admit I am partial to the quoted ICD-10-CM of "S07.9XXA Crushing injury of head, part unspecified, initial encounter.â...
  • Cosmos: As others in the comments section have pointed out before, GE's EMR for athletes is ironically a health record for the h...
  • HIT MD: I appreciate the thoughtful postings on this topic, particularly those by Ross Martin and LMNOP. I've never participate...
  • My Two Cents: Re: I wish we could all just get along and put the patient at the center of what we do. Yep, I get more and more disc...
  • bbc: Did you take the Hippocratic Oath in Med school? does the slightest thought of helping your patients concern you at all...
  • My Two Cents: I have a few concerns about the article Mr. Crane wrote on Drug Pricing Transparency and respectfully disagree and quest...
  • Brian Too: Aha! That makes more sense now. Thank you for clarifying....
  • So.....: Why not embed this functionality in to the patient portal and let the patient take on the leg work and the extra clicks?...

Sponsor Quick Links