When It’s Sink or Swim

November 3, 2014
273 Views

sink-or-swim

The project was 90% there – but somehow still had 90% to go.

The company was a go-to contractor for collecting and transporting x-rays, charts and other private patient information between hospitals, specialists and doctors’ offices.


sink-or-swim

The project was 90% there – but somehow still had 90% to go.

The company was a go-to contractor for collecting and transporting x-rays, charts and other private patient information between hospitals, specialists and doctors’ offices.

But the healthcare industry was – and remains – in massive, mandated transition. To secure its future, the company needed to innovate its service offering, making the switch from transporting physical records to transmitting electronic ones.

It needed to stop being Blockbuster (sink) and become Netflix (swim.)

Fast-forward 18 months, and the company was not quite having the Netflix success story it had envisioned.

The new system had been reported as “nearly complete” for quite some time, but it just wouldn’t work. As one issue got crossed off the list, another was added or reappeared, and the finish line kept drifting further and further back.

We got the call to help stand up what the company thought was a viable solution that just needed fresh eyes to fix a few stubborn problems.

So we quickly learned the system, methodically addressing issues and drilling deep into trouble areas. We recognized early that the system was overly complex and not likely to launch successfully any time soon. Building blocks selected at the start had unfortunate limitations, forcing custom workarounds that introduced unnecessary complication – and most of the troubles.

Tension was high on all sides. The company had invested nearly two years and hundreds of thousands of dollars, yet had nothing to show but an unstable system, a vanishing finish line, and increasingly dubious customers. And we were trying, but failing, to fix a clunker that just wouldn’t hold together.

So over one weekend, we took a break and stood up a proof-of-concept on an alternate platform. We had been researching options since the beginning, and the leading authority on communication protocols for encrypted health information suggested this platform was the way to go. As a bonus, it matched the company’s core technology stack.

We presented our alternate solution to the company.

Now they had a difficult choice to make.

They could stick with the approach their whole organization had been pursuing with fierce resolve, and which seemed tantalizingly close at hand. Or they could switch horses.

Walking away from a two-year project that’s at 200% of budget, yet seems 2% away from the finish line, is a tough call to make and is no small admission of misspent resources. But, even worse, what if the new approach were to fail at its own 95% point? What then?

The company weighed the risk factors of each choice, gave us leash to further prove our new technology stack, and made the decision to switch platforms. Ultimately, time was the enemy posing the greatest threat, and they had to stand up a robust product soon.

Fast-forward eight weeks and finally they had their “Netflix” platform, a stable, fully functioning health information exchange. Two weeks later their first customer, a major hospital, was up and running, with others close behind.

Swim Lessons:

  • Seek failure first. With so much at stake, it’s imperative to identify and address potential points of failure. Assume failure is lurking. Your job is to push it into the light early, or prove its absence.
  • Prepare Plan B. Be prepared with alternate approaches, whether it be path, technology or partner. At least run the thought experiment with yourself for each critical factor: What will we do if this piece fails?
  • Leverage your strengths. The company’s technology team was unfamiliar with the initial development platform, leaving them dependent on their vendor. Switching to a familiar platform allowed them to make their own critical project assessments.
  • Own your project. The company relied on its initial vendor for major platform and design decisions. (See “Seek failure first” above.) If unable to vet an approach yourself, bring in resources to challenge the plan for weakness.
  • Cut your losses. Once the company recognized a clear Plan B and stopped trying to plug holes in the doomed project, attention and resources were freed that quickly built a new, successful system.

In the end, we didn’t even write that much code. We had spent most of our time trying to fix a product that would never launch. When we determined it was a lost cause, we regrouped, identified a promising Plan B, tested critical potential failure points, then completed the system with confidence. The company heaved a sigh of relief and now is executing fully on its bet for the future.