Top 60 Oracle Blogs

Recent comments

Friday Philosophy – The One Absolute Requirement for System Success

Alternative title “The lady from Patient Admin – she says YEEESSSS!!!!!!”

What must you always achieve for an IT system to be a success?

  • Bug free? Never happens.
  • Within budget/time frame? That would be nice.
  • Includes critical business functionality? Please define critical.
  • Secure? Well, it’s important for many systems but then it is often lacking (even when it is important).
  • That it is to specification? Well we all know that’s wrong.

There is only one thing that an IT system must always achieve to be a success.

User Acceptance.

For an individual system other considerations may well be very important, but the user acceptance is, I think, non-negotiable.

The user must get enough out of using the system for it to be worth their while, otherwise at best they will resent using it and at worst… Well, at worst they will use it but will put in any old rubbish to fulfill the dictate that it be used. You would be better off if they did not use the system at all. Here are a couple of examples from my working past.

In the first one, I was involved in extending a hospital management system so that it kept track of the expected departure times for patients, allowing a predication of when beds would become available and calculation of expected occupancy rates. Yes, this was a while ago (maybe 1990) and on an a system that was old then. The information was needed by someone with the title “bed nurse” {or something similar} so that they could better prepare for bringing patients in and keeping a higher bed usage ratio. This was to make the hospital more efficient? No, it was to satisfy a politically demanded report to the NHS executive. Oh, the overall intention was to increase efficiency but the report soon became more important than the idea. So, we added columns in tables and field on screens and prompts for the ward staff to fill in the information. And they didn’t. The nurses were busy, they were pretty demoralized due to having recently been used by the government as a way to control public sector pay and they had nursing duties to do. They were not going to waste a couple of minutes trying to check when Mrs Jenkins was going to be sent home when Mrs Leonard needed a bed pan. The nursing staff were given a hospital-wide telling off, this information had to be entered. They put in the data – but guessed wildly. The design was fine, the report was logically accurate, only the correct staff could run it, but No User Acceptance and thus a failure.

So I added something else. It was a very crude screen that showed a “diagram” of the ward – Down the left and right side of a VT220 screen you saw little oblong boxes with a bed number, name in it, a consultant’s initials, a medical speciality code and the arrival and departure datetime. This was some information we already had plus the new information we wanted and something quite basic, limited and slow to draw. But it was useful to the ward staff. They could find any patient, they knew who to call if there was an emergency {not the actual consultant of course, but their secretary}, they could check when they were leaving, they could see what time someone was expected. From anywhere where there was a terminal, not just the entrance to the ward, they could see all this information. They used it.  They put in the expected departure time {sobering thought, this might not be expected leaving alive} and the bed nurse could plan and the report could be run.

Second example, different hospital. We were putting together a system to schedule outpatient clinics. We knew what we were doing, it’s pretty simple. You have some people (a consultant and probably a senior house officer), a period for the clinic (3 or 4 hours) and a set of people to see, say 40.  Give some flexibility in slot lengths (some people need 5 minutes, some 15) and allow the patients to be booked in. Check for and stop double booking. We did not go and ask the patient admin staff, we knocked up the design and the screens and asked them to test. After all, I was very experienced now, I’d been doing these systems for 3 years… They very quickly came back to us and said it was rubbish. Oh dear.

We went and saw them. I think it was a couple of us programmers, our development manager, the hospital liaison for the project and the patient admin staff. “What’s the problem?” There were a few but the main one was that you could not double book a slot. Why would you want to? Do two patients really want to be consulted at the same time with the same doctor?.
“Err, maybe, it might happen, can we just be able to double book?” OK, we could maybe alter things to allow two patients to be seen at the same time… The patient admin staff are not looking happy. The hospital liaison is looking confused – “You can’t do that! Patient confidentiality can’t be broken!” he says. It got worse. “We need to book all the patients into the first slot, with the consultant, so the letters go out to them saying come to see Mr Winders at 1pm”. The admin staff are now looking very shifty.

If any of you have worked in the health service you are probably way ahead of me. The admin staff needed to book all the patients in at this first slot so that they would all turn up, the consultant would see the two or three he was interested in - and then go and play golf. The SHO would then plough through the rest of the patients for the following three or four hours. If you have ever had to turn up at the start of a consultancy session and sat there for three hours, now you know why. You see, back then, the consultant was only a very small step away from deity level (and I leave it to you to decide if it was a step up or down). What they said went and if they wanted to go and play golf or store 200 medical records in the boot of their car or refuse to speak to “that stupid idiot in renal medicine” then you worked around it. {I’m assured that things are a lot better now, but I’d love to know how it really is}.

We had designed a sensible system, the users needed a non-sensible {to our mind} system. Even the NHS liaison chap had never appreciated exactly how much the consultants abused the system, he thought they just booked the people s(he) wanted at the start of the session, but no. The consultant decided that day who was interesting and as a result every patient had to be there at the start.

I count myself lucky that I learnt from direct experience so soon in my working life that (a) you have to deliver what the user will accept and (b) the only way to know what they want is to show them the system and talk with them.

{For those of you who do not understand the alternative title at the top, it is all about an old DelMOnte fruit juice advert which became a bit of a catchphrase at the time}

{And are you happy now Dom? :-) }