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.
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.
