“How am I going to get all this done?”
The short answer: you can’t, as every IT manager knows.
So how do you decide what to do—or more importantly, what not to do? If you run a development team, you know the right answer: Make the clients tell you. That’s why organizations create development queues, so that internal clients can prioritize new custom application development.
However, what if you run an operational team and don’t publish a project queue? How can you get your internal clients to set priorities effectively? In this column, I’ll give you some suggestions, starting with a clever trick someone taught me a long time ago.
Triaging: Explicit and implicit
Let’s start with that trick. A long time ago, I worked in the telecom industry. At one company, the MIS director found a terrific way to reduce the number of reports his group had to generate and print for all departments.
This was back before PCs, and the company ran on Wang minicomputers and dumb terminals. All data requests took the form of report requests, which were processed in the data center, printed on reams of green-bar perforated paper by huge line printers, and distributed by the third-shift operations staff to the various departments.
Once, one of his graveyard operators was out for three or four weeks (he got called for jury duty, I think) and so the department was shorthanded. That being the case, the MIS director sent a memo to all department heads explaining the situation: While his group members would be able to run all the regular reporting, they wouldn’t be able to distribute the reports. Therefore, he asked that all the department heads send someone down to the data center every morning to pick up the reports that had been printed the night before.
I was in the data center a couple of weeks later and was amused that an empty cubicle had been filled halfway to the ceiling with reports that hadn’t been picked up.
I mentioned in passing to the MIS director that he must have been looking forward to getting his operator back so that he could get rid of all this paper. He just smiled.
The next week, the director sent out another memo, telling the department heads that while his operator was back on duty, the group was swamped trying to catch up. Could the department heads continue sending someone to pick up the reports?
This went on for five or six weeks. Then one happy Monday morning, the department heads came into their offices, only to find reams and reams of paper: all the unclaimed reports from their group. Attached to each stack was a listing of the reports and the dates they had been run. Also attached was a memo from the MIS director, stating that since these reports had not even been picked up for the past six weeks, obviously they were no longer needed and would be run only on a quarterly basis, if at all.
We wanted to protest, but how could we? (Did I mention that I was one of those department heads?) If the reports had been important to us, surely we would have sent someone to pick them up. The fact that we hadn’t bothered just proved his point.
It also illustrated the difference between explicit and implicit triaging of priorities. At this company, every quarter, the MIS director compiled a list of all the reports his group generated and asked all the department heads to affirm that they were still necessary. All of us dutifully sent back memos, explaining that, yes, each of the reports was vital to the functioning of our departments—indeed, that we couldn’t get by without them.
We weren’t bad people, forcing the MIS group to do useless work because we wanted them to sweat. Rather, given a choice between getting a marginally useful report and not getting that same report, most of the time, we opted for continuing to receive it, reasoning that if nothing else, the report was an insurance policy of sorts.
Besides, there was no direct cost to the department heads for continuing to ask for the reports. However, the minute there was such a cost (even something as trivial as asking someone to get out of their chair and walk down the hall to pick up the report), our behavior implicitly proved that at least some of the reports were no longer relevant.
So what do you do?
My point in telling this story is not to advocate that you find ways to trick your internal clients. On the contrary, I’m arguing that when it comes to triaging operational tasks, you need to look at both what your clients tell you and what they actually do. That is the difference between explicit and implicit triaging.
You have to start by explicitly asking the client. Lay out all the operational tasks your group performs on his or her behalf, and ask if any are no longer necessary. Even if your organization doesn’t do charge backs to internal clients, make sure that he or she knows how much each of these tasks costs your department. If clients want you to perform additional duties, ask them which of your existing tasks they would be willing to give up.
Once you get the explicit answers, spend some time looking at implicit behavior. When it comes to reports, for example, it isn’t too difficult to learn which files have never been accessed, how much time a remote office uses a leased line each month, or how long it has been since a particular application has been run.
Make sure you give the client the benefit of the doubt. For example, odds are the client just doesn’t understand how seldom a particular report is accessed. Confronted with hard data, most clients will be reasonable.
Letting the client decide
Will you utilize the ideas outlined in this article? Send us some mail or post a comment.