Section 8.1. Prioritizing Your To Do Lists

8.1. Prioritizing Your To Do Lists

There you are at your desk facing today's daily to do list. Dozens of items. How do you decide what to do first?

This section is about prioritizing these items. Different situations call for different schemes. In previous chapters, we used a very simple scheme: if it has to be done today, it's an A priority; if it has to be done soon (but not today), it's a B priority; and everything else is a C priority.

"So what do you do if all your items are A priorities?"

Read this chapter.

8.1.1. Doing Tasks in List Order

System administrators frequently tell me they spend a lot of time each day fretting about what to do next. I know that when I stare at my to do list, I can spend five or more minutes just reading the list, obsessing over which should be the next item to work on. Total up all the time spent wasted that way, and it's a lot of time.

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.

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!)

8.1.2. 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 requested6.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 useat that momentand 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.

Your next task (T4) is done in 30 minutes. Check.

Task T2 doesn't take very long, but the expectation for a new user account to be created is usually not measured in minutes and hours, but in deadlines. If the person's first day on the job is tomorrow, it is expected that her accounts will be created before she arrives, whether it takes one minute or one day, whether you do it early or late in the day. However, since the task is deadline driven, it is important that it gets done.

If there were an outage (caused, possibly, by two hosts being configured for the same IP address), and all work stops to fix an outage, the previously outlined schedule would be disrupted. However, I would still work to meet the expectation that the new account be created before the person arrived. Other tasks might be delayed for a day, which is understandable given the major outage. But for a task like creating an account, I would stay late rather than miss the deadline.

Installing a new server (T3) is one of those "black hole tasks." It should take a few minutes to mount the server in the rack, maybe an hour to load the operating system, a little longer to configure the system. At least vendors seem to think that's true. We system administrators know that it's never that easy. The first time you rack mount that particular product, it always takes hours to figure out the oddball mounting system the vendor has created. Server operating systems are often loaded, erased, loaded, erased, as you carefully adjust settings each time to get things just right. (This box is going to be around for years, so we might as well invest some time in getting things right.) Finally, configuration never goes as quickly as we hope it will. Therefore, we leave these black hole tasks until after we've completed the tasks that are expected to happen quickly.

We bent the prioritization rules for the last task (T6). Based on the expected time for completion, one would think I'd have done it earlier in the day, perhaps before or after T3. However, at every site I've worked at, Usenet NetNews is considered a low priority, recreational activity provided as a bonus to employees. (I've never worked at an ISP, where the situation may be different.) Thus, fixing a minor issue with it is a low priority and goes to the end of the list. The general rule is: when all parties agree that a task is low priority (or there is a management edict), move the task to the end of the list. Think of it this way: if someone complained that one of the other tasks wasn't completed, would you want to stand in front of your boss and explain that the customer's request was delayed because you were fixing a minor issue with Usenet? No, not at all.

Simple? Sure. It can take a little practice, but your customers will notice the difference.

8.1.2.1. Delegate, record, do revisited

When I explain this system to people, the main objection I hear from them is that their to do list is not static. They do not begin their day with a fixed list of things that need to be done. New items are added to their list all day.

That's why we use the delegate, record, do technique from Chapter 2 for dealing with interruptions. We can use our customers' expectations to influence which of these three actions we take.

A request for resetting a password should happen quickly because it's holding up other work. Therefore, it might be faster to do it than to delegate it to someone else. And you certainly don't want to record the task for later when it means delaying a person's entire schedule.

8.1.2.2. Mutual interruption shield revisited

Not only does this technique work for prioritizing your personal to do list, but you can use it to plan on a larger scale. Use it to organize your entire computer support department!

Remember the mutual interruption shield technique from Chapter 1? Essentially, you implement this system to make sure that people's expectations are matched. Your coworker catches all interrupts for half of the day so that you can get projects done, and you reverse roles for the other half of the day. What you're really doing is making sure that there is someone to do the tasks that customers expect will happen quickly.

Most helpdesks have Tier 1 members who answer the phone and only push an issue to the Tier 2 staff when they are stumped. This is, essentially, creating a mutual interruption shield for the entire team while providing response times that match customer expectations!

Prioritizing based on customer expectations and using the mutual interruption shield replicates the helpdesk tier system, which validates the combination. Or, one might say that the tier structure is validated by the fact that it aims to reach the goal of meeting customer expectations. Either way, it's pretty cool, huh?