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”).



I was the (23-year old) account rep, and my job was to coordinate the fix. But none of my training had prepared me for the dysfunctional triad that ensued within my own company. The instrument division began pointing a finger at the computer division 25 miles down the road. They, in turn, reflexively pointed everywhere else including, but not limited to, the instrument accuser. My part of this triad was located 1,600 miles from them both. Corporate headquarters? You guessed it, 2,300 miles from my region. I was tasked to coordinate the fix, not an internal debacle that threatened the entire project!

In the end, the engineers at Westinghouse did the successful trouble shooting. Thoughtfully, they had specified in the acquisition contract that we would provide the schematics of all the hardware, which they used to provide the solution we ultimately used to fix the problem. My company was unable to develop a fix because after calling a multi-division truce, we were unable to reproduce the problem. We simply did not and could not understand our customer's business problem as well as the customer did.


Lessons:



1. Despite contracts, presumptions and expectations, sometimes the customer is the only party capable of diagnosing problems with a vendor's products as implemented. This needs to be a planning tactic (Assumption? Constraint?) for hospitals implementing HCIT, independent of the degree of outsourcing.



2. As a result of #1, you cannot outsource deep, internal analysis capability and knowhow. You must maintain this in-house, or an equivalent. Remember, no one who extensively uses software uses it " as designed!"



3. Despite #1 and #2, you often need the vendor to implement the fixes you've diagnosed. So, vendor relationships, contracts, and reciprocal talent on the vendor side (to your analysts) are still essential. For starters, you might consider ignoring my lead and not comparing vendors negatively to crows!



To riff on Mark Harvey's " Selling Your Soul" series, selling your soul probably won't work, even if you get a great price for it. The lessons of the crow’s behavior and the ASPJ Pajama Crow incident are clear. As my story illustrates, vendors cannot handle troubleshooting all the challenges of your implementation. Your mutual cawing with vendors needs to be based on expectations that recognize the challenges of HCIT and the limitations of vendors.