I have seen many of the Hall of Fame baseball players, but one player I never had a chance to see was Yogi Berra. Yogi was most famous for his many sayings, one of which applies perfectly to this article on prioritizing user requests: “If you don’t know where you’re going, you could wind up somewhere else.” If you’re like most IS administrators, you’re bombarded by requests from users. Some requests are more important than others; some have little importance; some users just want to get their names on your list; and some requests have major impact on the bottom line of your business. Keeping track of those requests, prioritizing them correctly, visualizing the impact to the business, and alerting everyone of their status is important in running an IS shop. There are benefits to knowing what goes on:

• You know where you are.
• You know which requests are being worked on and in what order.
• You can report back to your users and tell them the status of their requests. Try to keep in mind that a user’s request is the most important thing in that user’s world. You don’t want to belittle your users or their requests, but you do need to keep them in context and have a plan of attack.

Tell Me Why

Why should you prioritize your user requests? A better question might be, why shouldn’t you prioritize your user requests? Well, look at what can happen if you don’t.

Without some kind of order to your user requests, how can you be sure the requests are handled in a timely manner? Taking care of requests in FIFO (First In First Out) order is a common practice. After all, it seems only fair that users get what they ask for as soon as they ask for it. Although this approach may be good for the user, it can be bad for your department. The problem is analogous to winning the battle but losing the war. Without a tracking mechanism, how can you be sure that you or your staff are making headway on all those requests? You can’t. You can’t track what you aren’t tracking already. Sounds like Yogi, doesn’t it?

The next biggest problem with not prioritizing user requests is that higher-priority issues may not be addressed in a timely manner. In baseball, managers always want batters

with the highest on-base percentage—whether they achieve that figure through base hits, walks, or being hit by pitched balls—batting first in the lineup. Then come the power hitters, whom managers rely on to bat that man around to score. You can’t score without first reaching base, so the theory behind this approach is to give your team the best chance to get on base and score as soon as possible in the game. Managing user requests is similar: Requests with bigger impact need to be addressed first.

I’ve found that those “little one-time reports” I am constantly asked for sometimes have the biggest impact on my business. I received one such request for an analysis of inventory receipts to verify safety stock (minimums) on certain items. By running a simple sort, list, and total report, I saved my company potential inventory carrying costs and having too much inventory on hand.

Also, don’t be fooled into thinking that only big, time-consuming requests are important. That isn’t always the case, but if you don’t track your requests, how will you know?

Users constantly ask me, “When will you get to my request?” Answering that question quickly and concisely earns your users’ respect. However, if you have more important tasks, let them know that. It’s also a good idea to explain why other jobs have higher priority. If you say, “Let’s see...I remember you bringing that to me...Well, I can’t find it right now,” your users will quickly lose respect for you. If emergencies arise, let them know the situation and reassure them that if the same emergency happened to them, you would prioritize their requests with the same urgency. When multiple requests mount from one user, you must be careful not to give an answer the user doesn’t want to hear. However, if you aren’t tracking requests, you’re up the proverbial creek without a paddle because you won’t know the status of a given project.

Without tracking and prioritization, you’re floating in a sea of requests without direction. When you’re asked about a request and you don’t have the answer, that sea tastes pretty salty. Having your users and supervisors lose faith in you because of your lack of direction is also something you don’t want to happen.

Everyone Has That One

Most shops have those users. You know the ones I’m talking about: the users who think the squeaky wheel gets the grease. They think that if they make enough noise, they’ll get what they want when they want it. When others are around, they talk about the “lack of significance” you seem to place on their requests. They even go to someone above you in the corporate chain with their squeaky wheel. You must stand firm in your priorities when dealing with these users. I’ve had one of them at every job I’ve had, and as soon as these squeaky wheels figure out that you stand firm, they don’t squeak as much the next time. The worst thing you can do is yield to them because once other users learn that you have, you’ll need to deal with more than just one squeaky wheel.

What Needs to Be Prioritized?

I wear many hats in my shop: programmer, analyst, problem solver, coach, teacher, cheerleader, trainer, and task manager. One operator works for me, handling day-to-day clerical duties and some system administration. Managing requests is essential for me. I can’t let requests be buried in that endless sea of issues. Anything that takes more then two dedicated hours from my time must be prioritized.

There have been times when I assured users that I could complete their requests that same day only to have one phone call or page change my priorities for the next several days. You must let your users know that you are working on their requests if they ask, but do not promise to have their requests completed by a certain time. This rule may differ in larger shops. Nonetheless, I follow this rule because I must be able to take care of emergencies when they occur. A PC may lock up; maintenance may work on something and disturb my cabling; power may interrupt users’ work, causing their UPSs to quit; or

the president of the company may say, “Drop everything; this goes at the top of your totem pole.” All these contingencies have happened to me and could happen to you.

Another consideration is whether a request involves programming. You may be asked to install or upgrade a PC software package. You may be asked to install a new PC or, worse yet, scratch install (reformat and reload your favorite operating system) on one that already exists. Too often, I consider only how long it takes to write a report or inquiry or modify some code that is already written. I write a monthly status report and make sure I set aside the time to do that.

Although it is not programming-related, reporting apparent bugs in a software package is also time-consuming. My shop uses Business Planning and Control System (BPCS) from System Software Associates as its application package and recently moved to a new Y2K-compliant release. As you probably know, activating a new release causes problems you don’t know you have. No matter how well you test a new release, there are always things you don’t know about. When scheduling time to work with a new release, be sure to schedule preparation time and time after activating it to respond to problems.

So How Do I Go About It?

In my shop, most new requests come to me. That way, I can determine whether the request requires an additional tool or can be handled with something my shop already has. Many times, users develop what they consider a new need, but someone else has already had a similar need. I have the best handle on those types of needs and can determine whether the new request is feasible. For example, someone recently asked me to change the item number field from 15 to 20 characters. Database changes are some of the most difficult changes to make, especially when dealing with a purchased application package. I gently told this user that completing the request was not possible with a staff of just one! However, adding a field to handle fax numbers for customers was possible, so I created another relational database that is tied to the customer master by a common key. When I need a fax number, I use the normal customer master file with the tag-along file for the fax. After filtering new requests, I next determine how long it takes to complete a request. In larger shops, people take lots of time to determine how long a request takes. They’re more concerned with blocking out the appropriate amount of time and adding some buffer to ensure they do not run over. I take a more seat-of-my-pants approach. If I were to do the entire analysis, I could already have the project completed before the analysis could be done. Don’t become caught up in measuring actual time against estimated time. That difference too often becomes the guiding factor, whereas the guiding factor should really be doing the best job you can on a request. Time slips one way or the other is not important but giving users something they can use is. When scheduling time for this kind of request, keep in mind the kind of testing needed after the request is made. Consider enlisting someone to test your request, possibly even the requester.

Having a prewritten application package poses interesting tactics for me. One thing I have to contend with is whether a request involves modifying the package. In my opinion, no prewritten package can suit every company and every need within a company. You must either modify or do without extra, and often times needed, functionality. However, you must be careful not to go wild modifying your package at every opportunity. Modify only when absolutely necessary. Mark modifications clearly, make them as small as possible, and use external program calls for the brunt of the work. Doing these things makes newer releases easier to implement.

After you determine that you do need to modify your software package (in my shop, I make that assessment), you must put in place a plan for test libraries and test data, which are often copies of live data. You need to involve users in prototyping or beta testing when you or your staff finish programming.

At this point in the process, I have accumulated a lot of data on requests. To evaluate requests, my company uses an IS steering committee, a subset of the senior staff

that prioritizes and sometimes rejects requests. The committee has someone from manufacturing, engineering, sales, accounting, and me. All departments are represented. Once I’ve determined that a request is valid, we prioritize requests as a committee. Everyone, including me, has input into the importance, or lack thereof, of the request. There is no bickering. We agree that the committee must serve the needs of the company. If those needs change, we adjust the priority of projects accordingly.

The committee assigns each request one of three priority codes: A, P, or R. A means an active request; P means pending and something on a request is lacking, and R indicates a rejected request. Once all the A’s are established, we rate them with a 1, 2, or 3, 1 being most important. For example, priority A1 is highest. Finally, we prioritize all A1 requests in order of highest need, A11 being highest of those. Once the A1s are completed, we start on the A2s, and so on all in the same manner.

In the past, either I or my supervisor and I would try to prioritize the work, which was not a good solution. I had my ideas about importance but did not always know what was best for the company, and some requests from my supervisor received more attention because he was my supervisor when, in retrospect, they should not have. IS/IT needs to work as a team, not as a group of renegades. IS/IT must also remember that, as Spock said in Star Trek II: The Wrath of Khan, “the needs of the many outweigh the needs of the few.”

Finally, I try to consider in my criteria whether the report needs to be written in DDS and RPG or whether query-type report or inquiry will do. I’ve found that, many times, a simple sort, total, and list report satisfies the need. In those instances, a query-type report usually does the trick. When it can’t handle the job, it’s up to DDS and RPG. Building a query-type report takes much less time, so I use it whenever I can. I used to think that using a query-type tool shortchanged the user. However, as long as users get their information, they really don’t care which method I use.

Almost the Top of the Totem Pole: MBO Objectives

MBO objectives (MBO means management by objectives, which is a bit redundant, but I have heard it widely used) is almost at the top of my priority totem pole. Any request that conflicts with completing an objective gets shuffled down. The reason is that, in our year- end reviews, we are measured by either how well or how fast we completed the objective. Almost everyone understands that because they, too, have objectives and are measured in the same way.

The Absolute Top if It’s Broken

Now, you’re at the top of my user request totem pole. If what you have is broken, your request is like those bubble sort programs I had to write in my first programming class: It bubbles to the top, and everything else bubbles down. Here’s the reason. If a user’s PC or terminal is broken or the user has limited or no use of it, the company loses money. Because of that user’s position and salary, the company may be losing money quickly. The company also loses money if a program is not responding the way it should. Money lost looks bad on any profit and loss statement, no matter the reason.

If two things are broken at the same time, things become hectic. Here, I determine which need carries more weight, and in my making that determination, someone else usually gets out of sorts. However, in my shop, I handle all problems. The biggest problem I face is a piece of broken code that requires my application software vendor to fix. If it’s something I wrote, I fix it immediately. Waiting for a software vendor can be frustrating but can also be unavoidable.

Do You Have a Staff?

I do not have a staff of programmers, but if you do, listen to their opinions. They are the ones on the front line who must deal with users directly. I feel it is up to the IS manager or

CIO to prioritize, but feedback from the staff is needed. You can’t act as if you were a bull in a fine china shop, prioritizing requests and running over whatever is in your way. Responsiveness is good for everyone. The occasional bending of rules and priorities is good. If your programmers can spend an hour making small modifications to a program, I feel they need the flexibility to do that. Granting them that leeway makes your users feel their requests do not go into a “black hole,” and sometimes, it’s good for your staff to get away from what they’re working on and work on something else. Change can do wonders.

Once assignments are made, a short (30 seconds or so) daily review is in order. A longer weekly or biweekly review needs to take place to ensure that tasks are moving along smoothly and being evenly assigned and that there are no stumbling blocks.

A Crescent Wrench or an Adjustable?

Different mechanics prefer different tools. For some, a 9-inch adjustable does the job; others need a specific wrench. IS managers are like mechanics in this respect. They all need some kind of tool to measure achieved requests and evaluate what is on the horizon. I’ve seen tools as ample as Microsoft Project and as simple as a spreadsheet to track user requests. The tool you use is not as important as making sure that you use one. The task manager in Microsoft Outlook serves my purposes. I just remap some of the field names and sort the ones I need to sort. In past lives, I’ve had an online, real-time request system with maintenance, reports, and inquiries. Only my programmer and I could perform the maintenance (I had a programmer then). Anyone could run a report or inquiry.

Prioritize It

I hope I’ve given you some food for thought on prioritizing user requests. This is not to say that mine is the only way, nor is it necessarily the right way. It’s just the way I do things, and it works for me. I leave with you with three ideas: prioritize, visualize, and distribute. Prioritize your requests so as to benefit the team best, and don’t let the loudest squeak get the grease. Visualize how the company can better itself by completing requests in a timely manner. Finally, distribute what you work on and what you complete to your users. You will definitely develop a better relationship with your users.