The Summertime Blues

You'll love those lazy hazy crazy days of summer - those days of hot dogs and pretzels and beer... remember that old tune? I can remember listening to it on the radio as we drove to the Catskills in my Dad's old Dodge. But vacations are different now - everywhere I'm reading articles about how we Americans don't really get away from our work anymore when we go on holiday. We go loaded with smartphone and laptop and a plan to get six weeks of special projects done during six days on the beach. I know that's how I made my last trip miserable. But I don't think we should get too new-agey about this one. For the techie in the non-profit or association space, taking a guilt- and anxiety-free vacation is not about state of mind, but about preparation. It's about making sure your organization, your clients, your users, really will be OK during your absence. Its a sort of preparation you need to be thinking about in one way or another before any absence - whether its a day off to paint your kitchen or a month-long trip through India. Prepare your users. Your users depend on you on a daily basis for solutions, for advice, for troubleshooting. The longer your absence is going to be, the earlier you need to let people know about it. Make sure all your key users understand when and for how long you will be out, and give them a good understanding of the limits on your availability during your vacation. Encourage them to think now about needs that might emerge during your time off. Make sure they factor your absence into their timeframes for special projects! And let them know where to turn for help while you are gone. Prepare your backup. The folks who are going to be filling in for you during your vacation need to know exactly where your major projects are at, how to find the information they might need, and who they can turn to for further help. Make sure they know exactly how and when they can contact you, and when you be unavailable. What should you prepare them for? Look through your last years log of issues you've had to resolve. And be careful: documenting your network is useless if you have not made sure the right people know where to find that document. Don't have a backup person? - no wonder you and your coworkers are anxious! Take care of this first. If its not someone on your staff, make arrangements with a consultant. Prepare yourself. Your work pattern needs to change as you get ready to leave. We did a project several years ago for Deutsche Bank in Frankfurt. Frequently our partner Jochen would fly there for meetings. Pressed by the users to make enhancements to the application on a short time frame, he'd crank out code in his hotel room in the evening and install it the next day. Then he'd get on a plane to come back to D.C. Inevitably the user would have some huge issue with what he had done while he was on his seven-hour flight home. None of us back in the office had a clue what the requirements were or what the discussion had been. We've identified this as the Friday Install problem. Now we know to wait until we are in a position to support before we change. When your absence is going to be longer than seven hours, this issue becomes much more sensitive. Make sure you are not adding to the support burden in the days before you leave. And send me a postcard!

Systematizing User Support

When I started this "Help-Desk" series I wrote: "A great step forward for your informal user support desk is to provide them with a few procedures and tools that can help them be effective and efficient in this function." But so far all I've talked about is the toolkit: putting a ticketing system in place. What about those improved procedures? Actually, for our little company developing a ticketing system proved to be the key to process improvement: the system made it easier for us to describe, refine, and enforce our approach to support. Turns out it's easier to think calmly and rationally about tickets than about this crisis or that. The key was the Status field in each the ticket. I know this sounds obvious, but it took us a while to realize it: giving each ticket a well-defined status makes the status if each ticket clear. So as we have made improvements in our process, we've added, removed, or renamed statuses, and made changes to the rules governing status change. In the early days of our company, we had a customer support process that Jochen Heyland, our CTO, jokingly describes like this. "When a ticket comes in, determine if it is urgent or not. If it is urgent, panic. Drop everything else and address it immediately. If it is not urgent, just forget about it." I still see this panic-driven approach in play at numerous small non-profits. It arises when no other process is defined and you need to think about how to handle each request as it comes over the transom. How do you improve this? We've moved to a system where any defect reported by a user -- if all goes well -- will pass through 9 statuses. These are Submitted, In review, Approved for action, In progress, Ready to test, In testing, Ready to install, Client testing, Completed. We will also decide if it has Urgent or Normal priority. You might come up with a different process path. That's fine. But having clear terminology for each step helps make the entire process repeatable and controllable. For example, we used to mark an item Completed once we'd tested it and made it available to the user. But we realized that at that point we were still waiting for the user's final words that a problem had indeed been corrected. So we added the Client Testing status. When items languish in this status for too long, we can take action - like calling to see if the problem has indeed been corrected. You also need to define the steps on various side paths. For example a defect report might end up with the status Cannot Replicate. Or a request for consultation or training might need to go through Needs Estimate, Estimate Ready, Estimate Pending Client Approval before it gets to Approved. With this in place, a great deal of your internal administrative work can be accomplished just by calling up a list of items with a particular status. You can sit down as a team and do this. Check what is in progress and see how they are coming along. See what has been approved but not tackled yet -- and find out why. Look for items witht he priority urgent and make sure they jump to the top of the queue. Voila: Order out of chaos.

Turning Help Desk Tickets into Business Intelligence

I was claiming that getting your informal help desk operation organized with a ticketing system does more than streamline that operation - it provides information that can increase your organization's effectiveness. It can have a real impact on mission. So what information do you want to track in your help desk ticketing system? Of course you need to know who reported it, how they described it, when it came in, who worked on it, and how it was resolved. But the key is to know what type of requests you are getting, and how much time you spend on each. The values you allow for request type, and whether you allow for a single type or multiple tags, depend on the knowledge you hope to gain. You are trying to partition your universe here, so that you can learn how many and what kinds of problems each area spawns. You might begin for example with a very simple set of issues. Networking and Hardware Issues. Office Suite Issues. CRM and Database Issues Website Issues Then break out areas you have specific questions about. For instance, if you are trying to verify that you spend far to much time on new user setups, you might want to break that out on its own. Or if you feel you are inadequately protected against vius and malware attack, add malware protection and recovery to the list. Maybe you want to distinguish between problems that had to be resolved by a vendor (like software bugs) and which you could resolve in house. Which types of problems you worked on gains more meaning if you log the amount of time you spent in each ticket. Then you know things like: in the first quarter I spent 10 hours helping people search for documents they misfiled, for a cost to the organization of $400.00 of my time and an estimated additional equal amount in lost productivity. So finding a tool that helps with this problem could be worth up to $3,200 a year to us. Of course you won't know today what questions you want to ask of your data six months from now. So you really ought to allow for multiple topic tags. For example, if a user reports a problem with scanning credit cards, you may want to tag the request with numerous related terms - Point of Sale, Credit Card, Payment Processing, and Accounting. And you probably want to allow for a full text search of the description, in case you are looking for a term you had not thought to use at the time. Now you are really set to answer questions about the support your IT infrastructure has required. Next we'll look at how the ticketing system can help you deliver that support most effectively.

The Non-Profit Help Desk.

Every organization -- no matter how small - needs to have an IT Help Desk of some sort. Actually, every organization already has one, because everyone on staff has figured out "Who ya gonna call?" when hardware or software refuses to behave. A great step forward for your informal user support desk is to provide them with a few procedures and tools that can help them be effective and efficient in this function. I'm not saying your help desk needs more technical skill. Not at all. As the Wizard of Oz might say, "The non-profit sector is full of help desks that have no more technical skill than yours has. But what they do have that you do not is a Ticketing System. It's remarkable what even the simplest ticketing system for tracking user requests will do for your informal help desk operation. The users benefit because their requests are less likely to slip through the cracks. Having a formal queue of requests reduces the panic element in support, and this immediately makes the system more efficient. for the entire organization. But it's the knowledge you gain over time from the ticketing system that is the real benefit. A ticketing system lets your organization track what kinds of support requests are coming in and who submits them. It allows them to know how much time is spent in the aggregate, and on specific types of support. This information provides real business intelligence pointing towards I.T. improvements that you know in advance will save staff time and thus have a positive impact on mission. What should a Ticket include? More coming up.

Medieval Help Desk

For all of us who help users.... I love how both the techy and the new user struggle to control their irritation and keep a friendly tone.