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.
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.
Delegate, record, do revisited