One of the things we did was we took a couple steps to formalize how people access the IT help desk. Nothing fancy or new, just a simple policy. One of the keys to me though was asking users to set a priority for the ticket; High, Medium or Low. I defined these terms in the policy something like;
- High= interrupts business for multiple people, impacts finance, etc.
- Med= interrupts your ability to work, no work-around, etc.
- Low= everything else
I also asked for any associated deadlines, details, screenshots, etc.
But here is where things got interesting quick. And before I say anything else, I am not trying to say anything bad about our staff. This just seems to be human nature.
Requests came in, but the priority seemed to be driven by when they needed it done, not by the impact or importance. Because things get more important when you are faced with urgency. I need this by 1pm today, I am working on something for a Board Member that is going to be here in 30 minutes....
This is not a big deal when it is the occasional request, which is true for my org. They are typically good about leaving time and being purposeful. But this really got me thinking about the difference between urgency and priority.
The trick is that if you have too many urgencies, you can get to the priorities. This is where a help desk process can really help.
Track IT! If you are tracking all of your requests and work, you can look for these trends. You can see repeat requests each month at a deadline and anticipate them. Then make a change to your technology to address it. Automate the report.... Follow up with that department, ask them to request earlier... Simplify the tool to allow self help....
Expectations! Setting expectations in your help desk process will help drive the change needed. Tied to the priorities in our help desk process was a service level agreement. We plainly tell our users how quickly to expect support based on the priority of the ticket. The service level agreements will range from org to org based on available resources. And we told the why, to allow us to balance projects with big impact with the daily urgencies.
Definition! Taking time to write a policy, enforce it and define all terminology is not easy or fun. But is important. Simple definitions and ongoing conversations have a real, lasting impact on culture.
Address the problem, not the symptom. Not a new idea. Focusing on urgency will keep you focused on the symptoms.
We are also looking to formalize our tech project request, our tech project steps, data governance, business process documentation and so much more. We have to shift from urgency to priority to allow for impact.
My question is why aren't more topics like this at the forefront of our technology conferences, blog posts, webinars, etc? Basic technology support is still important.
5 comments:
Great post, and it is an important topic, and if anyone is planning on doing a session on it at 14NTC, I'm happy to help out.
Prioritization is a word that has to be rise to the top of any discussion about help desk, be it a one on one between the IT Director and her or his tech support staffer, or the people submitting the tickets. Two things that I see regularly that simply destroy the effectiveness of a help desk:
1. Help desk technicians that can't prioritize. If you treat everything like an emergency, nothing is an emergency, and you run yourself ragged. You alienate the users, who, when the request is something absolutely not dire, like "I get an annoying error that pops up every time I log on that I need to clear. can you remove it?", do not want to stress you out or throw your workload off course. So, the next time they have an annoying, but not critical issue, they're likely to not report it. Over time, that leaves them unhappy with the technology and the support.
2. Staff that don't prioritize properly, as you've discussed here. This might be controversial, but I'm not in favor of detailed SLA's. I think there need to be SLA's, or, more importantly, a confidence among the staff that technical issues are addressed in a timely fashion. But I think that the time frame can be set dynamically by the tech, as long as they are in good conversation with the user regarding it. And this is another place where I differ with you: I don;t press people to gve me all the details in their initial ticket submission. In fact, I tell them, if the ticket (which, in our Spiceworks system, is created by an email submission) is just addressed to helpdesk with the subject line "HELP!", that's sufficient. Because the primary requirement of the initial request is to create the ticket and identify the user. Triage can be the next step, and that can take place by email, phone or in person, based primarily on the help desk tech's understanding of how this particular user will best communicate.
What's important to me is that the ticket is in our system. Everything beyond that is about relationships. And my techs are instructed to prioritize based on true urgency: I can't work until this is resolved; multiple users are affected; the Board member is in the elevator. They can collaborate/reason with staff on priority in non-urgent situations. I will back them up if they say to my CEO "I'll get to your issue with receiving that spam email this afternoon; right now I have two people in HR who can't get logged into their systems".
So, key technician skill: prioritizing. Key strategy for prioritization: focus on communication and relationships, not automated procedures.
Peter, thanks so much for the very thoughtful comment! Glad to hear you find it important also.
And I totally agree with your "what is important to me is that the ticket is in our system." That was the first thing I focused on when I started at The Cara Program. Everything goes through the Help Desk.
Someone should run a session on setting priorities in supporting the tech in your org.
Great discussion and a topic I think everyone who works in nptech has probably struggled with at some level.
I'd add that for smaller nonprofits where the "help desk" is often just a tacked on responsibility to someone's already full time job, this gets even more complicated (and more critical to manage well) when there are longer term projects competing for time with the more immediate help desk needs.
Karl, you are so right about smaller staff sizes. Many don't even see the need to formalize their help desk and IT support. But it is a big mistake. If you don't formalize it, you may never be able to be proactive in your tech projects. You will spend all day treating symptoms and not knowing where you are spending your resources (time, money, attention, opportunity and expertise).
This is a great topic, perhaps we can create a panel discussion during 14NTC.
Our staff don't generally make unreasonable requests, but we're struggling on the development side as we grow. We're now formalizing a process that still starts with a Spiceworks ticket. If it becomes a project we move it to a different system (JIRA) for tracking and details.
As Peter mentioned, the communications is crucial. I keep the 4 quadrants model (see http://bit.ly/16GbJ9Q) taped to my monitor as a reminder of how to priortize what I and my staff are doing.
The guidelines suggested above about the "relative" importance or urgency of a request are 100% important, and different in any organization.
One of our methods of prioritizing larger projects is a team that reviews our list every 2-4 weeks so that we're meeting organizational needs properly.
My first helpdesk system was one I wrote in FileMaker Pro 20 years ago. In those days I was left to figure out whether a given request was urgent or not. Examples might help an nptech, and perhaps that is an idea we could offer during curbside consulting!
Post a Comment