Skip to content Skip to navigation

Crows & Pajamas - Your Vendor Can't Always Troubleshoot Your Implementation

January 12, 2010
by Joe Bormel
| Reprints

Crows & Pajamas

Your Vendor Can’t Always Troubleshoot
Your Implementation (Part One)



There's often a flighty, Crow-like quality attributed to vendors. Pest-like, eating grain that's not theirs, feeding on carrion, even killing the weak to feed their own growth. The comparison can be very dark. Crows are well known to be at least a nuisance, and possibly a public health hazard. Such negative imagery has long been part of the rap on vendors. 



As we all know, identical language has been applied as a faceless generalization to consultants and, when seen as uncaring, hospitals and health systems. Ditto for doctors.

But crows are a necessary part of the ecosystem, demonstrate positive behaviors, and are only a menace when their behavior is exclusively self-serving. Again, just like people, organizations and that dreaded “V” word.

American Crows are very social, sometimes forming flocks in the millions. Inquisitive and sometimes mischievous, crows are good learners and problem-solvers, …. They’re also aggressive and often chase away larger [more evil] birds including hawks, owls and herons. ( reference)

There are some lessons that come out of this “Crow Stuff” that can help us all work more effectively and successfully together. It boils down to reasonable and shared expectations. The caw or crowing sound they make needs to be interpreted in context. Vendors do have important obligations to their clients. And when a vendor seems to disappoint with a hoarse, raucous caw, saying that they cannot help with an implementation challenge, it may be true. You need to plan accordingly, and well ahead of time. 



In 1981, I was a major account sales rep for an internationally recognized IT company serving, among others, our contract with a then business unit of Westinghouse. Prior to my arrival, my employer had sold and delivered a $35 million package of electronic measurement instruments and desktop computers to this customer. 



Westinghouse had sole sourced all that stuff, in part to end finger pointing if (or rather when) it didn't work. At the time, Westinghouse was building a radar jamming system for fighter and attack jets dubbed "Pajama Crow." Through the magic of the Internet, you can read about this system via its formal name, the Airborne Self Protection Jammer (ASPJ). I suspect the pajama reference came from the “PJ” in the acronym. 



The Pajama Crow


The idea was that ASPJ would "crow" specific useful radio noises that would confuse enemy radar systems in sophisticated ways. Being stealthy through silence was not an option. These well-trained crows allowed the pilot to “rest easy” because the system was successfully jamming enemy radar, or that a radar burned through the jamming and it was time for the pilot to shed his pajamas and suit up for defensive measures.

You might remember that this was the era where SAM (Surface-to-Air) and Air-to-Air missiles had proved to be remarkably effective shooting down our aircraft. Obviously, a serious problem for the Defense Department, and my company was selected as a subcontractor by Westinghouse to help deliver ASPJ. 



I appreciate that this is a subtle concept - a crow and its caw can be used to provide a measure of protection. In the ASPJ example, this crow contributed to creating misleading communication to the enemy radar systems.

I'd argue that, in this context, working effectively with a HCIT vendor involves a related clarity in communication and expectations. Knowing what’s effective and possible ahead of time to transition from their current state to a newly implemented system has many surprises as you all have experienced.

Knowing when, what and how to communicate on the path to a HCIT solution demands effective crowing, i.e. the right message at the right time. However, expecting vendors to independently diagnose and solve problems related to their systems may set-up an impossible situation, a negative outcome and a bad relationship. But I digress; back to my story. 



The implementation of ASPJ was problematic right from the start. My company’s instruments were not reliably talking to our own computers in what was the client’s unique business application. However, since Westinghouse had contracted for both instruments and computers from the same vendor, it was presumed by the customer that, of course, we could fix the problem. That assumption was dead wrong (I can almost hear you saying “shades of HCIT interoperability”).

Pages

Topics

Comments

Joe,
Good post, I agree with most of it, particularly the part that the vendor can't know the business as well as the customer (end user).

In my experience most vendors set themselves up for this 'failure' starting with the initial sales call. They present themselves and their wares as 'solutions', which by default communicates to the buyer that they must know and understand the users business and problems. Otherwise how could it be a solution?

The buyer then expects the vendor to do just that - solve my problem..hey I'm spending $10mill so you better!

When the vendor presents products as 'solutions' then he takes responsibility for the problems - they become his. And it all goes down hill from there!

Bottom line - if this is ever going to get 'fixed' it must start with the first sales call.

Dr. Bormel,
Thank you for your reply. I understand.

And Marc, you make some very good points I want to take under consideration, because our hospital does not have as much leverage as I'd like at present.

I can see that I should have started reviewing this blog some time ago. Now I have a lot of catching up to do.

Doc Benjamin

Dr. Bormel,
I have just recently "discovered" this blog site, and am quite impressed with the quality people who post their thoughts here. And I must admit, this is the first time I have ever commented to a blog online.

Some ten years or so ago, I was "dragged kicking and yelling" into the age of healthcare IT. Four years ago, I was asked to serve on our hospital's HCIT advisory board, which has considerable authority as a decision-making body. To say the least, it was bewildering at first.

Since then, I've tried to learn as much as possible within the time constraints of being a surgeon. I find healthcare informatics fascinating. Too bad my days of considering a new path down "the road not taken" have long since passed.

However, as is in medicine, I want to improve the quality of my participation in our advisory board to the point where I can take a more active role, rather than giving merely a "thumbs up or down" on the various proposals for improvement — and there are many — we face on an almost monthly basis. What I hope is that I've found someone in you to occasionally commiserate with and question, since we share being MDs and MPHs.

I found this post particularly interesting, and will take your suggestions for further reading. I have witnessed a certain, obvious degree of frustration, on the part of members of our vendor's implementation team. We have the same vendor for our clinical and financial system components.

It appears to me that our vendor has, to a degree, turned its back on our needs after the latest contracts were approved, yet our vendor's support people (often on-site) appear, to me, to be trying so very hard to satisfy the specifications outlined in our sole-supplier RFP. This is all quite maddening.

Therefore, my first question, and please excuse my sounding naive, is did we make a mistake by not employing an external consultant as an intermediary to act on our hospital's behalf with our vendor? And by the way, starting all over with a new vendor is not an option considering cost.

Further, whether we should be using a consultant or not, again also a financial consideration, how do we "burn through" the layers of bureaucracy at our vendor to get the company to recognize that there is a problem with its promises versus performance?

Mr. Rivera made a good point about hospitals needing to make "time" for these projects. I'm sure we can and should do better, and we do have a team, albeit relatively small, dedicated to implementing all the changes to create a viable EMR. But after more than three years, we are barely nudging Step 4 on the HIMSS scale. Do you have any suggestions?

Your comments concerning forcing a go-live were right on the mark, by the way. I'm afraid we have done that from time-to-time. Always with unfortunate results, from my point of view.

In closing, I think it would be interesting to learn more about your "caught-in-the-middle" position at the young age of 23. Could you elaborate? I believe that might also help my understanding of our situation. Thank you.

Doc Benjamin . . . you can call me Ben!

Marc,

Thanks for the kind words, and your insightful dissection of the AE communication ropes.

I think these issues will become more prominent as everyone has to add new functionality, and expose their development competence.

Doc Benjamin,

Thank you for your comment (and, as always thanks to Joe for a great post). Having spent time on both the client and vendor side of the software sales process, both pre- and post-contract close, I can advise that you fall back on the tried and true, carrot and the stick.

The truth of the matter is, as a client you will never be in a better negotiating position with your vendor then you are 24 to 48 hours before all of the signatures are inked on your first deal. Most AEs are comp'd more (either directly or indirectly) for new deals and all AEs know that it is much easier to upsell and cross-sell into an existing account than it is to break into a new account.

For better or worse, unless your hospital represents a fairly measurable chunk of revenues with your vendor, and/or an entre into a larger account base, it sounds like you don't have very much leverage. A threat to switch might motivate your AE, but it certainly won't motivate his/her management.

So, what I would recommend is to reset your power dynamic with your vendor. In order to do this you need to identify a new purchasing opportunity, call in all the vendors, including your existing vendor to do the "dpg-and-pony-show" and proof-of-concepts. It would be best if the new opportunity engaged a different AE within the vendor. Make sure the new AE understands that the failing performance of the implementation shepharded by the old AE is putting the new AE's new deal at risk. Pressue the AEs to go to their bosess to go to their bosses until you are far enough up the chain that you find the common boss for both AEs.

Make sure that everyone you speak with at the vendor understands that fixing the issues with your existing implementation are a pre-condition to closing on the new implemenation. Also make sure that they understand that if one of the competitors wins the new opportunity, it could be the beach head from which the entire current and struggling implemenation is replaced.

If after all of this your old vendor either can't or won't fix your problems (presuming that you have been and honest and industrious in working with them on the fix), maybe it is the right, even if expensive, business and clinical decision to switch to a vendor who's products work and who clearly values a working partnership rather than a one-sided power dynamic.

Joe,
Good post! It must have been difficult being in the middle of an ongoing mess. But your plight doesn't sound all that unusual.

Frank Poggio's comment is really on target. Too many vendors do set themselves up for failure. There are days, even entire weeks when I think to myself, "If I hear the word 'solution' one more time, I'm going to physically harm the perpetrator." That word has become so trite and meaningless in HCIT.

Tell me you have a specific product or system, what its capabilities and functionality are, how it applies to my problem, who your references are, and how much it costs. But don't try to blow smoke my way with the tired solution routine. And don't tell me whatever it is you're trying to sell will "allow" me to accomplish something . . . anything! It may enable me, it may empower me, but allowing me is an insult.

Can't wait for your next installment on this topic! You really got my attention with this one.

Jack

Joe, I can till you had fun with this one. Loved it!
The harsh reality is that when projects flounder or fail, the client wants to jump on the vendor (sometimes because of their own job security). How many time have you been involved with a large project and the client tells you that they really don't have "time" to dedicate to the project? Most of the time resources will be expected to continue their daily job functions.
This results in vendor frustration, unrealistic expectations from the client and the reason most projects take twice as long.

Thanks for your insight, Frank. I agree with you. Another related trap that I see over and over is a bizarre reliance on the product demo. As if, doing a product demo will magically create clarity on the problem, i.e. the client's problem, and the solution will be self-evident and done. This would be great, if it weren't for behaviors, incentives, process, training/skills, and product build work.

Ben,

Thanks for your comments and kind words.

Consultants and adequate consultation are both critical. Several reasons, but the biggest is that people dont know what they dont know.

The second biggie is, when planning or implementing an enterprise-class system, you really need a dispassionate, third-party to sort out the dramas and civil wars that unfold, when an implementation goes well.

Pete,

Thanks for your kind words.

As with chess, there are opening gambits, middle, and closing gambits in the vendor/hospital relationships of HCIT enterprise system. You hit on a very common, early-middle gambit. Let's call it project staffing.

Yes, like you, I frequently see planned implementation that doesn't get done because daily duties to a department or patient care need to take priority over the HCIT project. Compounding this, HCIT projects that span over a year can and do get their implementation budgets whacked.

Let's call the fall out the "Thens:"  Then, the A-players leave in frustration. Then, the CIO gets fired for a failing project, or, if lucky, is able to change the organizations IT focus. Then, the new CIO comes in and finds that the key personnel trained on building and rolling out the vendors product are gone. Then, few if anyone remembers what the product can do and what compromises were deliberately made during the initial decision and contracting.  Then, the user base, aka nurses and doctors, are asked to use the system, as if it is adequately built out for their daily use.  Then, they work-arounds ensue, including trying to fix things by doing unnatural things, and, of course, lots of printing.

How does a CIO avoid that scenario?
1) Awareness

2) Read my article, "Homework First" at this HCI site for clinical tips

3) Use carefully ed implementation consulting services (i.e. dont put your organizations resources on the critical path) -and/or-
4) Staff up with dedicated project staff, realizing that "good projects start at go-live, they dont end with go-live." Plan for 4 to 7 years to mature a good clinical system. That might be easier with ARRA's 2011, 2013, and 2015 rising expectations

5) Build buffering into your project plans

6) Dont force a go-live (or let one get forced) that your implementation work has not prepared you for.  Said differently, your implementation needs to be validated by your real audience (their true agents) prior to go live

Any other pearls, Pete?

Pages

Joe Bormel

Healthcare IT Consutant

Joe Bormel

@jbormel

...