Massively complex technology solutions tend to fail more often than they succeed. Business Technology’s resident U.S. blogger Keil Hubert suggests that losing sight of the end users’ critical business processes inevitably leads to the development and deployment of IT solutions that make customers’ lives worse instead of better.
It’s all too easy for people to get confused about what the IT profession is all about. There’s a bloody good reason that we still call the field ‘Information Technology’, and not just ‘Technology’. The ‘I’ part is the part that matters the most. Lose sight of that, and you risk getting enraptured with your shiny toys and blinking lights – to the detriment of your customers.
To illustrate my point, let’s flash back to 1995. Back then, I was working for the US Army full-time as a medical operations officer. Through blind luck, I somehow managed to secure an invitation to an aeromedical evacuation conference down in San Antonio, Texas. All of the important people in my group who should have been attending the conference couldn’t, so I got to represent them.
I was searching for a hard-to-find conference room my first afternoon at the event when I stumbled onto the room where the conference’s sponsors were showing off their products. One booth in particular caught my attention, because it featured a gigantic Sun Microsystems workstation. In those early Windows 95 days, a big UNIX box was glamourous and exciting to a professional nerd, so I sauntered over to the booth and asked the sales weasel stationed there what he was trying to sell.
‘This is the ultimate situational awareness tool for battlefield casualty tracking!’ the bloke said.‘Here you have your scale-accurate tactical map…’ [click] ‘…which allows you to zoom in instantly to anywhere in the operational area…’ [click] ‘…and see all of your evacuation assets at once…’[click] ‘…or you can select any given ambulance…’ [click-click] ‘…and then you can drill down to how many casualties they currently have aboard…’ [click] ‘…along with all of the patients’ information including name…’ [click] ‘…blood type…’ [click] ‘…wound…’ [click] ‘…treatment performed…’ [click] ‘…unit of origin…’ [click] ‘…immunization records…’ [click] ‘…and you can even see when the ambulance had its last oil change!’ [click-click]
I nodded along with the fellow’s preso and confessed that I thought his system had tremendous potential to improve patient management… provided that all of the information that the system promised to make available was actually, well, available. ‘This may be a stupid question,’ I asked. ‘But how does all of that information get into your database to begin with?’
The sales weasel beamed. No problem! To make his solution work, the Army would need to outfit all 10,000 or so of our M997 field ambulances with his kit. These things were rather large, so the Army would need to replace one of the four casualty stations in each ambulance with a $100,000 SPARC computer.Surely the Army could afford to degrade its critical casualty evacuation fleet by 25 per cent of its capacity in order to achieve a Great Leap Forward in information superiority, right?
It took a great deal of effort, but I kept my poker face on. The sales guy’s proposal was utterly ludicrous. The cost was prohibitive to start out with, especially since we’d need to purchase hundreds more ambulances and recruit twice as many new drivers for them to make up for the lost casualty berths. Nonetheless, I nodded for the man to continue as if he wasn’t a complete nutter.
Next, the sales weasel went on without missing a beat, the medic who normally was expected to perform critical lifesaving care to the wounded soldiers in the back of the ambulance could, instead, spend the frantic off-road scramble from the front to the nearest hospital typing all of the patients’ data into the on-board data entry terminal. Of course, it was assumed that each patient would be able to recite his or her own complete medical history to the typist with pinpoint accuracy… in the dark… whilst bouncing around like a golf ball in a clothes dryer… after having been shot.
Having been both that medic and that casualty in the back of the ambulance, I recognized that this poor sales guy had no clue about how his supposed customer base actually performed their essential business functions. He had an awesome toy (and, to be fair, it was quite impressive), but he was critically hampered by the fact that he had no practical knowledge whatsoever about how his technological marvel would actually be used in an operational environment. The fellow had gotten so caught up in the cool aspects of his solution that he had lost sight of what it was supposed to actually do.
I told the sales weasel as politely as I could that (in my humble opinion) his shiny new solution would never be purchased, let alone used. I’d explained, from an end-user’s perspective, how his system simply couldn’t be used as-presented; speaking as a former infantry medic, there simply wasn’t time during an combat evacuation to muck around typing data into a PC… and without the manual data entry process, the entire solution was effectively useless. He didn’t get it. The weasel seemed so crestfallen as I walked away from the booth that I almost felt sorry for him. [1]
Could the big Solaris-based patient tracker system be useful in a hospital context? Absolutely. Some features of the fellow’s primordial patient information database concept made their way (directly or otherwise) into the Electronic Health Records that we know and love today. The idea of tracking patients via GPS is now pretty standard. Nowadays, we have dedicated specialists in the service whose job it is to operate these PC-based solutions. When they work, they’re kind of awesome.
The key word, there, is ‘when’. It’s been 20 years, but the same fundamental principle applies: the patient tracking solution is bloody useless (pun very much intended) if you don’t enter the right patient and wound information into the system in time enough for it to be acted on by the next healthcare delivery link in the chain. What I told the sales weasel in 1995 holds just as true today: if a critical user in the business process has the option to ignore the data entry phase and still carry out the rest of their part of the process, then the information system may as well not exist – it won’t be used enough to justify the cost of implementing and maintaining the solution.
I love laser barcode scanners and ruggedized tablets and satellite connections as much as the next nerd, because I’m endlessly fascinated by the technologies in and of themselves. I don’t, however, prefer to use highly-complex solutions when a simple fix will accomplish the desired result.
As an example, I was asked back in 2012 to significantly improve the efficiency of a different military healthcare service team. The organization’s key customers were dissatisfied with how long it was taking to process cases that might involve a soldier getting discharged or returned to full service. As a former customer of this outfit, I understood exactly what the key customers – the company commanders – were experiencing (because I’d experienced those same headaches myself). To get a handle on the problem, I mapped the existing records review process and realized that one of the key decision-making elements was completely missing from the workflow: at no point did the doctors, nurses, and techs ever prioritize their caseload. Each healthcare provider would process whatever came to him or her in order of appearance, not in order of relative importance.
To rectify the problem, I built an extremely simple prioritization tool in Microsoft Excel. It was a simple table listed each unit, the name and phone number of the unit’s commander, and the name of the solider that each commander considered his or her highest priority. When the staff came to work each day, they found that I’d posted the latest version of the patient priority list in their office. As paperwork came into the office to be processed, each section chief would skim the medical records for patients’ names and would move any file that appeared on the priority list to the top of the stack. At the end of the day, the same section chief would call or e-mail each commander whose number one case had experienced a change that day and would briefly describe what had happened.
The change in customer satisfaction was immediate and highly positive. For the first time in years, the healthcare group’s most important stakeholders were confident that their wishes were being acted on faithfully, and that they were being kept apprised in a timely manner. Complaints about poor service dropped in half within two months from the launch of the tracker. Given the staggering number of problems that the company commanders had to deal with, taking any high-visibility, highly-frustrating problem off of their plates was a huge relief.
More importantly, the solution was so simple that it was effectively impossible to ‘crash’. Any commander could change their number one priority case at any time; all they had to do was call or e-mail the healthcare team, and a clerk could manually update the tables in Excel and republish them – or even make a correction to the charts in seconds with a ballpoint pen. If the master file was lost or corrupted, the design was simple enough that a novice user could recreate it in five minutes. The solution’s only risk came from clinicians not abiding by the prioritization listing… This was effectively mitigated by the overall weight of compliance: every clerk bringing new files into an office for review knew about the priority listing, and pushed the next processor in line to get the top-rated issues dealt with first so that the key customers could be notified as swiftly as possible.
Would a cloud-enabled patient information portal be faster or offer a greater range of features? Sure. Or course it could. But it would then be subject to all of the problems that plague large IT solutions: over complexity, data processing errors, connectivity dependency, browser incompatibility, health information leak risk, cost overruns, and so on. Instead, a simple paper-based solution solved the core business problem swiftly, efficiently, and reliably.
I’d said as much to the sales weasel when he tried to pitch me on the godawful patient status tracker back in 1995: a good IT solution should solve a problem without introducing more risk to the core process than it resolves. A great IT solution should insinuate itself into an existing workflow so nonchalantly that it simply becomes an indispensible part of the process without adding unnecessary complexity. It doesn’t have to be sexy, or impressive, or comprehensive, or expensive; it just has to work. Watch how people actually perform a task and then find ways to help them do it more efficiently.
[1] As far as I know, my prediction was accurate. I never saw that system again in any form.
POC is Keil Hubert, keil.hubert@gmail.com
Follow him on twitter at @keilhubert.
You can buy his books on IT leadership and IT interviewing at the Amazon Kindle Store.
Keil Hubert is a retired U.S. Air Force ‘Cyberspace Operations’ officer, with over ten years of military command experience. He currently consults on business, security and technology issues in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo!, and helped to launch four small businesses (including his own).
Keil’s experience creating and leading IT teams in the defense, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employee development… This serves him well as Business Technology’s resident U.S. blogger.