Thomas Limoncelli - Time Management for System Administrators

If you are wasting time fretting about what to do next, stop. Make the decision simple and just start at the top of the list and work your way down, doing each item in order. In the time you might spend fretting, you would complete a couple of the smaller items. In addition, because of the way you move items you couldn't complete to the following day, it's common for older items to bubble to the top of the list. Getting these older items done is a great way to start a day.

Tip

One of my chores as a kid was to take out the trash every Monday and Thursday night. I hated it. I would complain and procrastinate and make all sorts of trouble trying to get out of the task. (I think I complained just because that's what kids do when faced with chores.) Though our house was a big, three-story Victorian, it couldn't have taken me more than 10 minutes to empty all the wastebaskets. But what was the fun in that? I had enough delay tactics to waste at least a half-hour before I even got started! There are many situations where just doing the task takes much less time than the efforts we make to avoid the work.

Doing your to do items in the order they appear is a great way to avoid procrastination. To quote the Nike slogan, "Just do it."

If your list is short enough that you can do all the items in one day, then this scheme makes even more sense. If it doesn't matter if a task gets done early in the day or late in the day, who cares in what order it's completed?

This is very much like network congestion. If a network is lightly loaded it's easy to do audio, video, telephony, or other time-critical services. However, with a congested network, these services work a lot better with some kind of sophisticated prioritization scheme, or quality of service (QoS) system. When the network load is light, any scheme will work. When the network load is heavy, we need something more structured. When our task list is simple, any prioritization scheme will work. When we are flooded with requests, we need something more sophisticated.

To extend my analogy a little further, did you know that QoS often isn't about treating some packets better? It's really about treating some packets worse! Technically, what's going on inside a QoS switch is very interesting. When there is no congestion, it operates the same as a non-QoS switch. Packets come in, packets go out. However, when congestion happens, a non-QoS switch simply drops the most recently arrived packet. In other words, there's no buffer space left for a new packet, so it ignores that packet. A QoS-enabled switch handles congestion differently. When the buffer is full, it doesn't drop the newly arrived packet; instead, it picks a lower-priority packet in the "middle" of the buffer to drop. In other words, when you pay an ISP for better QoS on certain traffic, you are really paying to not be dropped during congestion. You are literally bribing the ISP to drop someone else's packet when the network is congested!

Task prioritization is similar. We have a finite amount of time and resources. When we are overloaded, we have a tendency to growl at the next new request we get. In reality, we need a way to look at our current task list and decide if there are lower-priority items to delay or possibly drop. (Sadly, we can't take bribes!)

Prioritizing Based on Customer Expectations

Here's a little secret I picked up from Ralph Loura when he was my boss at Bell Labs. If you have a list of tasks, doing them in any order takes (approximately) the same amount of time. However, if you do them in an order that is based on customers' expectations, your customers will perceive you as working faster. Same amount of work for you, better perception from your customers. Pretty cool, huh?

What are your customer expectations? Sure, all customers would love all requests to be completed immediately, but, in reality, they do have some concept that things take time. It may be an unrealistic expectation, and certainly it is often based on a misunderstanding of technology, but we can place user expectations in a few broad categories:

Some requests should be quick. Examples include resetting a password, requests to allocate an IP address, and deleting a protected file. One thing these requests have in common is that they are often minor tasks that hold up a larger task. Imagine the frustration a user experiences when she can't do anything until a password is reset, but you take hours before doing it.

"Hurry up and wait" tasks will start soon. Tasks that are precursors to other tasks are expected to happen early on. For example, ordering a small hardware item usually involves a lot of work to push the order through purchasing, then a long wait for it to arrive. After that, the item can be installed. If the wait is going to be two weeks, there is an expectation that the ordering will happen quickly so that the two-week wait won't stretch into three weeks.

Some requests take a long time. Examples include installing a new PC, creating a service from scratch, or anything that requires a purchasing process. Even if the vendor offers overnight shipping, people accept that overnight is not right now.

All other work stops to fix an outage. The final category is outages. Not only is there an expectation that during an outage all other work will stop so the issue can be resolved, there is also an expectation that the entire team will work on the project. Customers generally do not know that there is a division of labor within an SA team.

Now that you understand your customers' expectations better, how can you put this to good use? Let's suppose you had the tasks in Figure 8-1 on your to do list.

Figure 8-1. Tasks that aren't prioritized by customer expectations

If you did the tasks in the order listed, you could be pretty satisfied with your performance. You did everything on the day it was requested—6.5 hours of solid work (plus one hour for lunch). Good for you.

However, you have not done a good job of meeting your customer's perception of how long things should have taken. The person who made request T7 had to wait all day for something he perceived should take two minutes. If I were that customer, I would be pretty upset. For the lack of an IP address, the installation of a new piece of lab equipment was delayed all day.

(Actually, what's more likely to happen is that the frustrated, impatient customer wouldn't wait all day. He'll ping IP addresses until he finds one that isn't in use—at that moment—and temporarily borrow that address. If this is your unlucky day, the address selected will conflict with something and cause an outage, which could ruin your entire day. But I digress....)

Let's reorder the tasks based on customer perception of how long things should take. Tasks that are perceived to take little time will be batched up and done early in the day. Other tasks will happen later. However, you will make one exception to the rule, as you'll soon see. Figure 8-2 shows the reordered tasks.

Figure 8-2. Tasks ordered based on customer expectations

You begin the day by doing the two tasks (T1 and T7) that customers expect to happen quickly and that most certainly will hold up other, larger projects. You succeed in meeting the perceived amount of time these tasks take.

The next task (T5) involves a "hurry up and wait" situation. No matter how quickly you order the item, it is going to take a day or two to arrive. Putting the order through sooner rather than later can prevent a lot of dissatisfaction on the other end.