Achievement vs Activity

Ah, a new year, a fresh start, a clean slate! Welcome, 2016.

Now let the ranting begin, because I have observed something I don't like and reticence is so last year.

New Year's day I attended a party. At that party I met a number of fellow human beings and I struck up a conversation with one of them in the line for chili. As is its wont, the conversation turned to our professions: he a clinician and I a medical information systems specialist. After the initial explanation of what I _actually_ do (all of it--design, project management, coding, deployment, documentation, whatever is required), we ended up at the usual place: what sucks about Medical IT.

(Does this happen to smart phone people? I bet lots of people tell them how awesome smart phones are. No one ever tells me how awesome clinical information systems are.)

For a refreshing change, this clinician does not really care about HIPPA (as an ophthalmologist he is not under the kind of time pressure that, say ER folks are, so the additional security is not that big a deal), he finds the user interfaces adequate (although he could do without the mind-numbing repetition of drug warnings whenever he prescribes drugs) and he feels that the systems he uses are adequately powerful (however he did note that he sees fewer patients than he did 10 years ago and that he is almost certain that he is not delivering substantially better care to compensate for his lower productivity).

What did bother him is the fact that his practice has two full-time IT people for about 15 providers and that these two full-time IT people were overwhelmed, so really they might need to hire a third at some point.

I have no idea how good these two IT people are, or how efficient, or how productive. They are probably perfectly lovely people. This rant is not about them. This rant is about the understandable but regrettable use of activity as the measure of an IT group, instead of achievement.

I can see why people who are not IT experts use activity as a measure: activity is something one can often see, even if one does not understand what one is seeing. If you do not understand what an IT group does, then watching how they spend their time is probably a reasonable short cut.

But managers of IT groups should not be doing this: managers of IT groups should be tracking what gets done (achievement) and how many person hours it takes (productivity). This is why we have the concept of milestones, and why we have project plans.

I suppose that a technical support group can be managed merely by monitoring its activity, but without a concept of outcomes, you end up here:

http://dilbert.com/strip/1999-08-04

Worse, if you judge your IT folks by their activity alone, then staff who take a long time will seem better than staff who take a short time. In other words, you will select for being slow without any particular reason for being good. You will drive away talent and attract dead wood. Then you will find that you need ever more IT people but that your IT is ever less effective.


A concrete example may help:

We saw an organization invest in a super-duper printing system, because their execs work in offices and offices like to print and offices hate it when their print jobs fail. There was furious activity needed to get this system rolled out, with no discernible benefit since print jobs generally print even without massive and expensive printing systems.

Then the massive and expensive printing system's back end (printing) went down for six hours (which was theoretically impossible, but there you are) while the front end (accepting print jobs) stayed up. and clinical work had to go on, so paperwork and labels were done by hand as people had been trained to do long ago. Apps kept automatically queuing print jobs--admission reports, lab reports, patient ID labels, specimen container labels, etc--and people kept writing things down by hand.

Then the massive and expensive printing system came back up and did what it was born to do: printed those out-of-date print jobs. This amounted to a denial of service attack, as labels and paperwork which did not match the patients in front of them spewed out in front of clerks and nurses and PAs and doctors and lab techs. As they often say in clinical work: better never than late.

So  IT was scolded and in response a fail-safe was developed and deployed, essentially a way to shut off the massive and expensive printing system. This was another burst of furious activity, the net effect of which was to make it possible to emulate never having installed the printing system at all.

This was a huge amount of activity, for which the participants were lauded and rewarded. I question, however, how much of an achievement it was.

Keep your eyes on the prize and constantly renew your commitment to your goals or you will end up with too much going on and too little to show for it.