Technology, Change and Wait – Project Failures

I’ve recently seen two major IT projects fail due to “lack of user interest”. In both cases, the IT people had put in a lot of hard work and had advanced technology but were left disappointed and bitter. In one case, the project was for digital entry of drug orders in a hospital. It decreased ‘defect’ rates but made the process run less lean. In the other, it was a web-based system to re-order third party supplies after surgery. There were more errors due to data entry and it ran less lean. The failures were not due to a lack of initiative or ingenuity but a failure to improve the process flow.

Whenever our clinic has a suggestion from IT we first put the change into a flow map of the overall process. The process is constructed from the patients’ perspective. Changes that we make to the process have to improve the quality of care or time it takes. If the change doesn’t accomplish either goal – there is no point to doing it. If the change doesn’t achieve both goals it will have an uphill battle.

That being said, sometimes you have to look hard to see the improvement.

Let’s look at two changes and how they affected process flow:



A suggestion to go to completely digital charts. A process flow map (see diagram for an example) showed that because we often see patients in rapid succession (with the nurse seeing them too) the steps of log-in, log-out and typing rather than writing slowed the process. The decision was made to continue with paper but certain aspects would be digitized. When we can have tablets with stable wireless networks at a reasonable cost the change will come.



We are a referral based specialty clinic so the acceptance of patients was usually done by phone or fax. There is a digital system to manage referrals. When we added email referrals as an option the system broke down due to entry errors, misfiling, etc… What we thought would improve flow actually hindered it. The process was reexamined and the software provider for the main patient database was involved. For a small cost, code was written such that emails are automatically brought into the system and when they’re reviewed by our booking staff (to contact the patient) an email is automatically sent back with details.

Our clinic invests heavily in IT infrastructure but the point is to improve access and care, not to “be digital”. I think it would help to have the IT people bedside for several days before starting any project. Have them come in and work a busy night in emergency or a lonely night on the wards. The point is not to generate empathy, but to help them construct a process flow map of how an IT project is going to be used.

In any process, improvement can be achieved in two ways. Either decreasing the error rate (or defect rate in six sigma terms) so that work doesn’t have to be repeated or increase efficiency (or in Lean terms to lean it down and decrease the variation). My experience is that the defect rate is the most often cited reason for IT changes whereas Lean changes are easier to ‘sell’ to the healthcare workers and to improve and control. Perspective is everything. Every project, big or small, needs to have a process flow map constructed to determine whether it’s really going to help the people for which it’s being designed. But in a healthcare, the patient is the metric that really counts so when a project is suggested construct the map from the perspective of the patient. Remembering that we are here to benefit patients is not just a "corporate goal" but a valuable tool in implementing new projects.