Software for the finest computer – The Mind

  • Tim’s YouTube Channel

  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 1,005 other followers

  • Categories

  • Fan Page

  • Since 1971:
    "Software for the finest computer - The Mind"

    Follow me on Twitter: @timbryce

  • Subscribe


Posted by Tim Bryce on June 6, 2012

– A lesson in how NOT to install a system.

To use this segment in a Radio broadcast or Podcast, send TIM a request.

As a systems man with over thirty years of experience, I always enjoy hearing embarrassing snafus costing millions of dollars. It is like reading a mystery thriller to discover “whodunit.” In the systems field it is typically a matter of bad planning, bad designs, lack of documentation, and poor project management resulting in overruns and slipped schedules; it can also be caused when the system implementation (aka, “start-up”) backfires. As to the latter, a doctor friend of mine recently told me about his experience with a new system at a local hospital. You may remember me briefly discussing this earlier, “Turning Everyone Into Data Entry Clerks.” It’s been three months since then, and my doctor friend brought me up to date regarding the massive system, which was used to accommodate all of the administrative needs of a hospital and intended to satisfy government requirements for managing patient records. Not surprising, the system appears to be designed more for the needs of bureaucrats as opposed to medical workers.

The system is a comprehensive soup-to-nuts approach for hospital administration. It is a “packaged solution” which means you are buying into another person’s interpretation of the problem which may or may not be the same as yours. Nonetheless, the system has been installed in other hospitals and tweaked to suit their particular nuances. It is a PC based client/server system and although it can be accessed remotely, it is not done so through a web browser. There is, of course, a login and password procedure which dictates access privileges, thereby prohibiting people from unauthorized use of the system.

There were two approaches for implementing the system, either phased in as a series of stages, or all at once. For some unknown reason, the hospital opted to use the brute force approach and ram it all in on a single start-up date in February. I believe the date will best be remembered as “bedlam” and it is interesting to see what went right and what went wrong.

Prior to the installation, there was a massive amount of training required to use the system. Some doctors and nurses took the training seriously, but others checked in and out of the classroom simply to get the credit. Regardless of how well the students studied, everybody experienced different levels of confusion as the system started up. Although is is very sophisticated in terms of its capabilities, the system is not intuitive to use and was obviously programmed more from a technician’s perspective as opposed to a medical worker. For example, there were no design standards implemented which are normally intended to simplify the “look and feel” of the system thereby making it easier to learn and use.

To assist in the initial start-up, a team of 100 geeks were stationed in a meeting room for two weeks where it came to resemble “Mission Control” in Houston. During start-up, it wasn’t uncommon to see 15 geeks at a time in front of a computer screen with a blank perplexed look about them. They neither exuded confidence about the system or communicated well with the medical staff.

Physicians and nurses complained about the rudimentary nature of the training. For example, there was no “hands-on” training whatsoever, nor was there any documentation such as manuals, reference cards, or even Help text. The system made extensive use of keywords, but unfortunately there was no reference materials to look up the proper codes which, again, were not intuitive. For example, instead of “Admit” (a patient), the proper keyword was “Register As” (???).

Even the most well trained medical personnel stumbled through system start-up. Not surprising, three months later, many are still learning it. So much so, nurses are spending more time on computers and substantially less time treating patients. According to my doctor friend, whereas it used to take him three hours to visit and treat twelve patients, under the new system, it now takes him nine hours to perform the same task. This is obviously a quantum leap backwards in terms of productivity. There was also a computer crash one night causing doctors to revert back to paper charts as opposed to waiting for the system. The harsh reality is that all of the medical providers are being held hostage to the system, thereby causing a significant decline in patient care.

Despite all of this, management appears to be satisfied with the system which is somewhat typical for companies and systems of this size. This is probably because they are not intimate with how the system works and how the medical staff likes the system. A simple survey of user satisfaction may prove enlightening to management.

Basically, the vendor botched the training and implementation of the system thereby nearly grasping defeat from the jaws of victory. So what could they have done better; what were the lessons learned from this experience?

First, the system should have been designed according to industry standards, not just the whims and peculiarities of the vendor, thereby making it easier to learn and use, not to mention more intuitive. For example, if the F1 key is the generally accepted standard to access Help text, provide an F1 Help key. If people understand “copy” and “paste” from a clipboard, be sure to give it to them.

Second, design the system with the end user in mind, not the programmer who will only do what is technically elegant as opposed to practical. To do so, involve the end user DURING design, not afterwards when it is too late and costly to make corrections. Designers should worry more about ergonomics and less about the technical details of the computer. Just remember, an elegant solution to the wrong problem solves nothing.

Third, provide suitable documentation, something the end user will comprehend and find useful, not some technical mumbo-jumbo. A user manual with overviews, step-by-step instructions, task lists, examples, and indices are extremely useful. Better yet, provide it all online in the form of Help text. In other words, have the answers for all of their questions at their fingertips.

Some would say the problems experienced with this system are unique to the medical community. This is simply not so, as you can find system snafus like this in any field. The medical community certainly doesn’t hold a monopoly over such problems.

As I said, I have loved reading about system snafus over the years. Interestingly, the system start-up problems being experienced in the 21st century are no different than those experienced in the 20th. However, you would think we would have learned a thing or two over the years. Evidently we haven’t.

P.S. – See my paper, “Evaluating Purchased Packages,” for selection guidelines.

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at

For Tim’s columns, see:

Like the article? TELL A FRIEND.

Copyright © 2012 by Tim Bryce. All rights reserved.

MALL MADNESS – Are they designed for men or women (or both?)


  1. Tim Bryce said

    A J.P. of Toronto, Ontario wrote…

    “There is or was a military anagram for this: SNAFU.”


  2. Tim Bryce said

    A J.S. of Skidway Lake, Michigan wrote…

    “You’ve got this right, Tim. This system needs to be focused on the simplest, most efficient way to manage information that may well save a person’s life. It’s so much more than codes and formatting in a health care setting!

    I think it’s essential to show the proposed screen format to the actual users to get their input. These folks are on the front lines daily and will be quick to point out which blank areas need to be larger or smaller and they will notice absences. “Where are the spaces for the ICD or CPT Codes?” for example, or placement of key information. Seconds can save lives. A bright banner area for allergies is one example.

    My most recent hospital stay, three days for brain tumor surgery, showed me some very impressive upgrades in heath care delivery and comfort. I also saw things that made me want to wail and gnash my teeth. I may write about them soon and post on Gather.”


  3. Robert said

    On a slightly different perspective i.e. Austrian Economics, read what an Austrian thinker and anesthesiologist says about “what is seen and what is unseen.” One must always consider the large scale system benefactors of these crappy systems (inefficient and marginally effective because of manipulated demand for non-value add features and functions); it is rarely those who are mentioned by the sellers or the installers, namely the customers. These systems fulfill a primary purpose for sellers and installers…make lots of money turning a quick trick by over promising and under delivering.

    Nice write up here:

    J.P. don’t forget that time tested military anagram “FUBAR” as well.


  4. Tim Bryce said

    As a follow-up, my Doctor friend recently told me:

    Tim: The saga continues; yesterday, the IT managers insisted that I input coding data for diagnoses ‘because the doctors are supposed to do it’. I told her that I was not paid to do the coding for billing and I had no knowledge of this duty that is customarily done by the ‘coding staff’. She offered to ‘help’. I walked away.


  5. Tim Bryce said

    An L.M. of Chicago, Illinois wrote…

    “Sounds like you peeked into my local hospital during my wife’s recent heart attack. She was unfortunate enough to suffer a heart attack and bypass surgery during the dreaded “change-over” to the new, computerized system. After a few attempts by staff to document and log EVERYTHING, the pda’s were discarded for the time being and information was logged the “analog” way. Things went smoothly and efficiently and no patients were inconvenienced. Later, some days later after the smoke cleared away, the experience was reconstructed with recollection and reminiscing about what happened. After a while, during her rehab, enough had been learned by the staff to use the new system with some greater confidence.

    Ah yes, progress. One step forward and two steps back!”


  6. […] have discussed the changing medical culture in the past; see (1), (2), (3), (4), (5). Herein I want to describe an actual experience I was involved with recently. […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

<span>%d</span> bloggers like this: