How do you Cover for Specialists?

Some of you who follow me on Twitter may have seen that I worked late a couple of days last week as some sort of epidemic has swept the help desk area of our firm, leaving them quite short-handed. In fact, they were left with no one available between the regular folks who work there, and the couple of usual backups to cover the phones until 6PM each evening, which is the customary procedure. Not having any immediate plans after work, I stepped in and covered them.

While I was down there, another one of our IS folks and I were discussing how much tech support has changed. Time was when he, and everyone in the IT department where he worked, had the help desk line on their phones and we expected to answer it when the regular folks were tied up, but that was when all you had to support was PC hardware and maybe MS Office apps. Now, there are dozens of apps in use, in a variety of specialties, that he doesn't even know how to use, much less support.

As we talked, I realized how much that is true. The folks who were brought in as specialists, like for Networking, Telecommunications, and DBA, simply don't have the knowledge to do general end-user support. Our firm is a little luckier than most, because some of the other IT specialist positions are folks who started out working at the help desk, like myself, and can step in. On the other hand, it's only been a bit more than 2 years since I worked there fulltime, and there have been some applications added that I don't use, and couldn't possibly support. (Luckily no one called with a question about those while I was flying solo down there!) The others who've been away for even longer, have even more apps where that is the case.

We came to realize, not just that we really only had a limited number of people who could effective backup the help desk folks, but that we had very limited backup for any of our positions. When our telecomunications guy is on vacation, there is an official "backup" person, but what can be handled in his absence is very limited. A major telephone system meltdown during his vacation is going to result in a serious problem. Now with our Litigation Support Department consisting of me, and one other person working remotely 4 days a week, on that 5th day, if I get sick, and there's someone needing trial prep work done, there's no one to do it. Same goes for our one web developer. If something needs done, and she's not there to do it, what happens?

As more and more firms try to "do more with less" in this economy, how many IT people are having to be "on call" even when they're on vacation, or over weekends, or when they're sick, because they're the only one's who can handle some tasks? What does your organization do to try and prevent this, or do you simply require them to live with this expectation? Are your IT people expected to always be reachable? Are they therefore limited in where they can go on vacation, because of this expectation that they will always be able to log in remotely and work on something at a moment's notice? Is that really fair?

Personally, I don't think it is. More importantly, if there's only one person at your firm who can fix certain issues, what do you do when that person gets hit by a bus? Or leaves? Aren't you asking for trouble if you simply ignore the fact that skills and knowledge haven't been shared among the whole team and you've simply laid these expectations at the feet of your folks as your "solution"?

So as technology gets more specialized, and budgets get tighter, what do you do to have a backup plan?

Related articles by Zemanta

• Does Open Ticketing Solve Communication Problems? (mikemcbrideonline.com)
• Twitter Is My Help Desk (ducttapemarketing.com)
• Failure to Communicate (mikemcbrideonline.com)

Labels: HelpDesk, LitigationSupport, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:50 PM | 2 comments | Links to this post

 
Failure to Communicate

This is a bit of a follow up to a post a few days ago about whether having an open ticketing system would help with the communications between techs and the users they support.

As I mentioned there, and talked more about in the comments, when you have systemic failure to communicate, it's much more than a technical problem. It's a people problem, and in many cases, it a culture problem. If your organization sees their IT department as "those" people down in the basement, you are going to continue to have these issues with people not giving the techs enough information. Conversely, if your IT folks see the people they support as (l)users, you are going to continue to have issues with your techs no following up appropriately.

Worse yet, when these attitudes are displayed by the CEO, or the IT manager, there is no hope of it getting better, no matter what technology you put in place! If your IT department is in its own silo, you're going to have problems. If all the other departments are in their own silos, you're going to have problems that go well beyond tech support. From what I hear, this is actually pretty common in larger law firms, as each practice area tends to be in their own silo, not to mention staff departments, like IT, which exist even outside of those practice area silos!

As I've written elsewhere recently, there are some things you can do, even if you're not in management, that will help. First and foremost, do some internal networking. Get to know people in other areas, develop relationships outside of the silo. Learn about what is happening in other areas of the firm and try to find ways in which your talents, or technology, can assist them in accomplishing things that are important to them.

Don't wait for management to develop a plan to get rid of silos, do it yourself on whatever level you can. Go to lunch with someone in another area of the firm, offer to show them how to use some bit of technology during a brown bag lunch. I've had some success offering to show people how to setup an RSS reader, for example. It's not official firm-approved technology training, it's taking my own time to help teach someone how to use a technology that could help them, with their job, or with other interests.

One other area where I've only recently begun to consider is in the use of social networking tools. As I've been on Facebook for a little while now, I'm realizing just how much it's growing in use, even among the non-techie people I know. In some cases, they are joining up to keep an eye on their teenaged kids, and finding plenty of old friends/classmates on the service, or are using it to connect with family members who are far away, possibly as a way to share photos, an then finding plenty of other groups and activities they enjoy, etc. Lots of these folks are also listing their work information, including employer.

I can't help but wonder if "friending" some of these folks would help me to learn about their interests, and find common ground, or maybe increase the level of interaction with folks who I don't normally get to see on a regular basis. At this point I've only connected with a handful of folks that I work with on Facebook, and none on Twitter, but I'm wondering if I should spend some time tracking down more of them, and using the technology to develop better relationships across silos. (Doing so without coming across as creepy stalker guy from Lit Support might be a little difficult though..*L*)

To me, a lack of communication in any business is a sign of a lack of relationships within that organization. People who know each other, are familiar with each other, and heck maybe even like each other, are more likely to share important information. People who don't know each other, or who couldn't even tell you the name of the IT person who helped them, aren't.

Of course, since I met my wife at work 9 years ago, maybe my perspective on building relationships at work is a bit biased. I tend to think the better you know the people you work with, the better you are going to communicate with them, and they with you. It's worked that way for me with plenty of folks that I didn't wind up married to as well. :)

What do you guys think? Do you regularly connect with folks from within your organization outside of work? If you work in a law firm, what chance do you think an internal networking goal has of getting any sort of momentum with people who are ruled by billable hours? I will say, it's been easier to build relationships with other staff members than it has been with lawyers. That is one silo that is going to be difficult to reach across, it takes time, and that's time that isn't being billed! Share your own thoughts in the comments...

Labels: HelpDesk, LawFirms, LitigationSupport

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 4:41 PM | 0 comments | Links to this post

 
Does Open Ticketing Solve Communication Problems?

That's one of the recommendations Doug Cornelius makes in various discussions around the blogosphere about poor communication between "geeks" and "users". (Start here at 3 geeks and a Law Blog, which links to Jenn Steele's original post and read the comments on both for the background.)

Doug's claim that the problem with help desk tickets is that no one ever knows what happens and where they go, so opening it up so that he, as a user can log in and see what has been happening to resolve his issues, would solve the communication problem. I'm going to disagree.

Not because Doug's idea is a bad one, in fact I think that should be a requirement of any ticketing system. It certainly would help ease some of that black hole feeling, but I don't think it would put much of a dent in the real communication problem.

That's because, in my view, the lack of communication has little to do with users not being able to follow up for themselves, and everything to do with the fact that geeks are not given any reason to really communicate with users. Think about it, IT heads and organization's management teams demand those automated systems that allow a help desk tech to either fix the problem, or assign it to someone to fix, without ever leaving their desk. They connect remotely to a user's machine, make a small change, disconnect and call the ticket closed. There's no time spend building relationships with users, learning about what work they are trying to accomplish, talking to them about how they are working, looking for teachable moments where the tech could maybe help a user find a simpler way to do something etc. Those are the kinds of things that increase communication back and forth, not yet another piece of technology.

If you work at a help desk though, why woud you spend the time to do this? On one hand, you're probably working short staffed due to cutbacks, supporting a couple of hundred users with 1 or 2 front line techs, and what are you being evaluated on? The quality of relationships you've built, the follow up calls/visits to a user to make sure a fix is working, or how much you understand what your users are trying to do and how they could use technology to be more efficient? No, you're being evaluated on how many tickets you close.

Managers, remember you get the behavior you measure. If you measure closing tickets quickly and in large numbers, you'll get tickets closed quickly and in great quantity. When that results in poor communication between techs and users who don't know each other at all, I guess you better find a way to measure, and reward, behavior that improves those relationships. If you continue to only look at the bottom line expense of tech support, you'll get the bottom of tech support.

Labels: HelpDesk, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:40 PM | 4 comments | Links to this post

 
A Thought About Outliers and Burn Out

I recently finished reading Malcolm Gladwell's Outliers and it has been sparking a few thoughts that I want to turn into blog posts. The first one I've already written elsewhere, but this one is a perfect fit for this blog, because I've often talked about burnout as it relates to helpdesk work, and some of Gladwell's ideas and study have challenged my ideas.

One section of the book deals with the cultural differences between Western agricultural traditions, and rice paddy agriculture traditions, and how those traditions have been carried over into the educational theories. In typical corn/wheat agriculture, of course, you don't grow on the soil every year. you allow, every few years, the soil to rest and recover it's minerals. That's how it stays fertile. In the rice paddies, however, the soil actually become more fertile the more you grow on it.

Late 19th and early 20th century American educators wrote at great length about similar concepts when it came to teaching children. You wanted to make sure they got a break from the work, so that their minds could rest and be more fertile for learning when they came back from their breaks. (Hence the reason we have such a long Summer vacation compared to other countries.) Asian education has no such accommodations. You learn, and continue to learn as much as you possibly can. You work at things continuously because, like rice farming, the more work you put into it, the more rice you get out of it.

That got me thinking about the idea of job burn out. It's pretty commonly accepted knowledge that we all need a break every now and then, to do something different, to "blow off steam", or risk getting burned out, like soil that has been over farmed. I still stand by my theory that 95%, if not more, of the people who work in help desk environments will show significant signs of burn out within 3-5 years. It's the nature of the work, because it never ends, and it never changes a whole lot.

So, the question is, does burn out happen because we've been culturally trained that there is such a thing as burnout if you work too hard for too long at a task? And if so, can it be overcome by unlearning that tradition?

Or is it the case, which I tend to think is more likely, that Americans suffer burn out at their jobs more often because their jobs aren't meaningful? It's relatively easy to work harder at rice farming, because working harder increases the yield of your rice and increases your wealth. You don't suffer from burn out when there's a direct connection between working hard, and being successful. Does your job have that sort of connection and meaning?

More to the point, does working at a help desk provide meaningful work for most people who do it? I'd guess not. For most, it's a stepping stone to something else, and after 3-5 years, if you've not "stepped" up to something else, or if there's nothing else to step into, it loses it's meaning. Work without meaning leads to burn out.

Labels: Career, HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 8:42 PM | 0 comments | Links to this post

 
Further Thoughts on ILTA Survey

I briefly mentioned the woeful numbers when it comes to actually measuring the technical skills of law firm staff when I posted the link to the 2008 ILTA User Support survey.

Tonight, I'd like to dig into those thoughts a bit further. First, let's look at the top answers of some of the relevant questions to this post:

• Does your firm conduct skills assessment? 65% -No
• If your firm does skills assessment, who do you test? 59% -Prospective Staff
• Does your firm have any ongoing technical training requirements for attorneys? 87% - No
• Does your firm have any ongoing technical requirements for staff? 67% -No
• What incentives are offered at your firm to support training? 52% -Food at sessions
• Does your firm have an official budget for your training department? 62% -No

So, let's take those numbers and create a typical law firm staffer.

When you were hired, there's a less than 50% chance that anyone actually bothered to test your technical skills, other than looking at your resume, but there's a chance that someone would have, so let's suppose you do actually have all the requisite skills for your job, currently. Over the years, as technology changes at a great pace, you'll be given the opportunity to take some classes, mostly as part of large roll outs of new tools. There will be other opportunities for training, but no actual budget for it, and no one will be tracking whether you go to training or not. In fact, your skills will never actually be tested again, no matter how long you work with the firm. So long as you can continue to do the important stuff, you'll be fine. If, however, you decide you'd like to learn more about taking advantage of technology, and be more efficient through using it, you'll be richly rewarded, with a pastry.

Of course this is all different for the young associate attorney. For you, not only is your reward a lovely pastry, but you also get the lost hours of billable time that you'll need to make up, and, if you really learn a lot, you'll also be treated to missed billable hour minimums because your efficient use of technology allowed you to get work done quicker, and left you scrounging around for more work to make up your hours!

Which leads me to my last number:

• What are the biggest challenges facing training and user support efforts? 73% -Lawyer Participation

No kidding...

Next, some ideas on correcting this problem. In the meantime, I'd love to hear yours!

Labels: HelpDesk, LawFirms, LitigationSupport

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 6:43 PM | 1 comments | Links to this post

 
ILTA 2008 User Support Survey

The survey results are out, and there's a ton on information about how law firms are doing training and user support. I haven't had time to do more than give it a cursory glance, but there's definitely some interesting discussion points. Download a copy.

Also, there's a white paper available with some analysis of what these numbers might mean, and which I need to read through as well, before starting any blog posts discussing the numbers, though the fact that 65% of firms do no ongoing skills assessments, and 63% don't require ongoing technical training for staff (87% don't require it for attorneys) is a little bit mind-boggling. As much as technology changes, you don't have any requirements for people in your firms to continue learning anything technical?

It's no wonder clients think law firms are so behind the times.

Labels: HelpDesk, LawFirms, LitigationSupport

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 6:47 PM | 0 comments | Links to this post

 
Annual Exercise - Helpdesk Shift?

Today at work I was being helpful and covering the helpdesk for an hour so that our helpdesk folks could have a meeting with their manager. Being the always-on kind of guy, I posted to twitter from my phone about doing that and what it was like.

In fact, I mentioned that it was kind of like riding a bike, after a couple of phone calls, I fell right back into a groove with it, short-lived as it was.

Alas, that's not why I am writing this post. The inspiration for this post came from a reply I got on Twitter, from Tony Hartsfield:

@mikemac29 Wonder if a help desk stint shouldn't be a mandatory annual exercise.

The more I thought about it, the more I thought that might not be a bad idea, at least in some cases. Here's why I think it could be, because not all IT jobs have direct user contact, and sometimes, without that, it's easy to lose sight of why you are there.

Now, for myself, Lit Support has a ton of direct user contact, so I really don't need the reminder, but I know plenty of networking folks, or software developers, etc. that don't have much, if any, contact with end users. Sometimes that leads to seeing their role as something other than providing the technology support so that others can do their jobs. An occasional shift at the helpdesk would remind them that the core business of the organization isn't to have a server room, or cool tech tools. Those tools exist to help the people who are at the core of the business. In many cases, IT isn't there. It's an important part, but it's not the core.

Sometimes it helps to peek out of the server room and see how those tools are impacting the people who are out doing the organization's business.

Labels: HelpDesk, LawFirms, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:02 PM | 2 comments | Links to this post

 
Negative Attitudes in Tech Support

Jenn Steele, who writes a blog dedicated to discussing how to manage the IT department called Leading Geeks, has an interesting post today, On Attitude.

I find that geeks easily fall into sub-optimal attitudes, which usually fall into two categories. The first is what I call the "stupid user" category, where they develop the attitude that anyone who doesn't work in their department or on computers is too stupid to function. The other I call the "end of the world" category, where they develop a Chicken Little attitude about anything that goes wrong.

I know every one of you reading this has seen both of these, and probably suffered from them at times.

She goes one later in the post:

In my work environments, I watch for these attitudes and actively discourage them for several reasons. First, I really want to create a service organization inside my law firm. Second, it's just more fun to work around positive people. Finally, I want better work product from my geeks, and, since they're not attorneys, a positive attitude leads to better working results.

I find myself in agreement with what Jenn says, in theory. In practice, I wonder how many IT Departments don't have issues with bad attitudes?

Look, the Nick Burns SNL skits were funny because everyone who watched the show knew someone just like that. Yes, it's an exaggeration for comedy's sake, but it's funny because there's an inkling of truth to it. Not only that, but I'd hazard a guess that most people not only knew someone like that, they also expected to be treated like that by their IT support people. That's why people hate to call tech support! (I know, I'm one of those people who hates calling tech support!)

On the other hand, sometimes users actually do stupid things, and as a geek, you have to deal with those occurrences, every single day, one after the other. That's mind-numbing, and after a few years of this, it is really, really difficult to not fall into that attitude. It's especially difficult when that attitude is already present within the department when you get there. That, to me, is a large reason you have to stay diligent and look out for this attitude, because I don't think, once it's taken hold and been allowed to fester, you can ever get rid of it. (Barring a complete departmental overhaul, which is never good.)

So the question is, we know this attitude leads to poorer performance from your IT folks, we know it leads to disintegrating relationships between It and the rest of the organization, and we know that negative attitudes about the workplace lead to high turnover, so what do you do to prevent it? How do you recognize, and root out, poor attitudes BEFORE they become engrained to the job? On the flip side, what do you give your tech support staff to keep them happy, productive and on good terms with their users?

Personally, I'm not a manager, so I don't have answers. I'm betting some of you, who do manage IT people, have some ideas though. :)

And I'll be keeping an eye on Jenn's blog for more information on how she does it as well.

Labels: Career, HelpDesk, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:04 PM | 1 comments | Links to this post

 
Help Desk Talk Relaunched

Ian Landsman announced yesterday that he's rolling out the Help Desk Talk forums for another go 'round. I thought it was a great idea to have a board dedicated to help desk workers the first time he launched it, but it never really took off. Here's hoping this one finds it's wings.

Even though I don't work at the help desk any more, I still think it's a great idea, and plan to drop in from time to time to keep in touch with the end-user support community.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:30 PM | 1 comments | Links to this post

 
Burn out Rate

Many of you know, I've long believed there's a time limit for how long someone can work at a help desk before suffering burn out. (This is true for most people, maybe not all, but I'd put the percent of people that this is true of in the high 90's!)

Today, when walking to my car I saw a very disheveled middle-aged man, who obviously hadn't had a change of clothes or shower in a few days, and he was talking. At first I thought perhaps he was on a cell phone, maybe even using Bluetooth, since his hands were empty. As I got closer, however, I and the 3-4 other people waiting on the light to cross the street could clearly see that he did, in fact, not have any sort of Bluetooth device in his ear, he was simply talking to no one.

"Type back slash, then ssrn. Hit enter, then Left shift and enter two more times. Yes, three enters, then shift three times..." (I'm paraphrasing...)

Is this the next step past burn out? Do you just wander down the street giving out technical instructions to no one in particular? Or did he have some new-fangled Bluetooth device that I couldn't even see hidden in the part of his pants that was rolled up revealing his calf? :)

I wonder if anyone got video of him? Maybe I'll search YouTube...

Labels: Fun/Games, HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 11:11 PM | 3 comments | Links to this post

 
ABA Techshow Day 3 Session 1

Before I get started, I've got to say I had a good time meeting up with other bloggers last night. Kevin O'Keefe organized the event and picked up the tab, which was awesome. Got a chance to meet and chat with a few fellow bloggers, who I won't even try to link to, because I would undoubtedly leave someone out and I don't want to do that, but trust me when I say that I enjoyed meeting and chatting with all of you, and I'll be adding some new subscriptions to my Google Reader.

After spending some time there, I met up with Angela and walked up to Millennium Park, had dinner at Pizano's on Madison, and tried to take some interesting night time photos. We'll see how that worked out. :)

Just a couple of sessions this morning, then meeting back up with Angela for the St. Patrick's Day parade.

Session 1 Notes: Managing Email, Britt Lorish Knuttgen and Dan Pinnington

OHIO: Only Handle it Once
RAFT inbox: Refer/Read, Act, File, Toss
Flagging and/or folders as organizational tools. (We're already dealing with fallout of people filing things in folders and never deleting anything, we need to hit that concept hard before anything else!)

Are you doing work, or avoiding work by dealing with email? Turn off the new message "ding" and popup!

Speakers are suggesting using more than one email account, keeping various things out of your business email, like listserves, and personal email that you don't look at as often. (Since we block all outside email accounts, and web-based accounts, does it actually encourage people to use their work email address for everything? I think it does.) -Interesting live Twitter discussion about this idea, since I posted it there too, shows power of Twitter right there.

Lots of questions about problems with spam filters. Obviously, folks still have issues getting real email through spam filters. I am not surprised by that.

Uh-oh he's talking about Sent Items folder. As proud as I am of my clear inbox, I tend to keep a whole lot of Sent Items, too used to needing to CYA with emails I sent. ;)

One minute rule: decide what to do with a message within one minute, even if it's setting yourself a task to accomplish the more complicated task.

Use signature blocks like auto text. (I've been getting some good use out of this, learned it at the help desk, because we were getting many of the same questions through email, so we made the answers or common replies signature blocks. Now I use them for things like letting someone know when a Summation load is finished, for example)

I've never got the hang of search folders, why not actually use folders?

Britt is encouraging people to save client emails in the Doc or Practice management system so that it's attached to the client/matter instead of just sitting in someone's mailbox. YAY! I wonder if she'll come talk to some of our attorneys? :) (She demonstrated it with World Docs, didn't look much different than Worksite/Mailsite)

Labels: HelpDesk, LitigationSupport, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:26 AM | 1 comments | Links to this post

 
Free Tech Support

Phil Gerbyshak brought it to my attention, and I thought I'd certainly pass it along for those of you are running small businesses and might be looking for some remote support.

Friends,

Do you work from home and have the occasional annoying technical problem that you can't figure out, but you don't want to go in and pay the Geek Squad $50 or more an hour to do something you KNOW can't take more than 3 or 4 minutes?

Do you have a home PC that you're dying to set up with wireless, but your team of helpers consists of the 17 year old neighbor kid you know is setting up your network so he can surf the web without his parents knowing?

Do you need a little help getting your PC back on the automatic updates schedule it was a few months ago, but that you just haven't been able to make time for yet?

I've got a solution for you: MinuteFix. We can help you with any of your technical support issues on your computer, and we only charge you by the minute (hence the name, MinuteFix).

You might be a little concerned about how we're going to do this, what the caliber of our techs are, and if the support is really great. I know I would be asking those questions, and plenty more.

Instead of me telling you, I invite you to head over to MinuteFix and check us out. There's no cost until March 15th, so I'd bet you can get a few of your problems fixed, or at the least, you'd know that we are a great company and one you can count on to fix those annoying computer problems you've been having for years.

If you don't need this service for you, perhaps you know someone who does, and you could share MinuteFix with them.

If you're a blogger, I'd ask that you share this with all your readers, because many folks who only READ blogs aren't very technical, and could use some help. Or click below on the site and Stumble this so we can get the word out.

Free tech support until March 15th, 2008. Only from MinuteFix. Thanks!

I can't say I'm familiar with their work, but for free, it could be worth a shot for you to test them out. If you take advantage of the offer, be sure to come back and let us know how it worked out!

 

Labels: HelpDesk, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 7:13 PM | 0 comments | Links to this post

 
IT Workers at Home

I saw a conversation going around on Twitter this morning about working from home, and management's reluctance to allow their IT folks. I can't find any links for it now, but some of the ideas being tossed around were pretty interesting. Especially the idea that if your job can be done from outside the office, then it can be outsourced. In some sense that's true. I also saw mention of the fact that being in the same place as your internal customers helps in the interaction with them. I'd agree with that too.

When I think about our little IT Department, I think there are some things that could be done mostly from home, and some folks are allowed to work from home when necessary. That sort of thing works pretty well for our web developer, or database admin, but not so much for the support folks. Aside from the obvious need for someone to actually be there to replace hardware, support positions work much better when you know, and interact with the people you're supporting. Having your help desk staff be some random stranger on the phone is never as good. Cheaper, probably, but never as good as having someone you know and see on a regular basis on the other end of that phone.

Litigation Support, is more a mixed bag. Certainly, some of the work with data could be done from anywhere with access to the network, but being around to advise, and help the litigation process as it relates to technology isn't really something that you can do from home. It wouldn't be the same if you don't have a relationship with the attorneys.

Labels: HelpDesk, LitigationSupport

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:58 PM | 0 comments | Links to this post

 
Neat tools

All courtesy of the latest issue of Support Alert:

Free online media files converter, YouConvertIt.

A collection of more web browsers than I've ever heard of.

Decode those winmail.dat attachments you get from silly Outlook users.

Tech Repair Tools of the Week.

All worth a bookmark, in case you ever need them. ;)

Labels: HelpDesk, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:22 PM | 0 comments | Links to this post

 
How would you explain it?

OK so it's a simple concept to most of you guys, but obviously, our various users don't quite grasp this, and I'm wondering what the best way to explain it is. Here's the scenario:

User needs data copied to a laptop from the network so he can work on it offline from some other location that does not have internet access. The required "stuff" you've been asked to copy is 17GB worth of data, which then needs to be loaded into database program and configured correctly. User expects to be able to pick up laptop in an hour or so.

Now, most of us can imagine that copying 17GB of data off a network server, in the middle of the work day, simply takes some time! A lot of users though, just don't comprehend this. They don't understand the size of the data, how that translates to moving it, and what that means in terms of time.

So, IT folks, how do you explain it to folks who obviously don't get it?

Labels: HelpDesk, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:51 PM | 3 comments | Links to this post

 
WinXP News, now with Vista News too!

One of the better newsletters out there for those of us who wind up supporting users on Windows XP, is WinXP News, by Sunbelt Software. In tomorrow's edition, comes news that they'll be starting up a separate newsletter called Vista News, which I'm thinking wouldn't be a bad idea to get as well, because we'll be supporting users on Windows Vista soon enough, if not already!

Labels: HelpDesk, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 7:51 PM | 0 comments | Links to this post

 
New IT Policy -Humor

I can't take credit for this, but this afternoon I got the following email from our Helpdesk Manager:

1.  Before you go to a desk, send the attached file with instructions for the user not to open it until a helpdesk technician is at their desk.

2.  Go to the user's desk, put your hands on your hips and tell the user to open the attached file.

Link

I couldn't help but laugh, and promise to put it online.

 

Labels: Fun/Games, HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:24 PM | 0 comments | Links to this post

 
The Process, not the Results

One of the bigger adjustments from working tech support to working Litigation Support is the focus. When you're doing help desk stuff, the focus is on finding a solution, and getting folks back to work. When you're doing Litigation Support, especially when it's involves case work, it is all about following the process, and ignoring the results.

So, for example, when we're handling evidence, it's all about following the proper procedure. You cannot, ethically, be concerned about how this evidence affects the case, you just have to process it. (Most of the time, we don't really know enough about the case to be concerned, and we don't even look at it in any detail. We just follow the process.)

So, any work I do gets done the same way, every time. Even if we do all the work to prepare for trial, and the case settles out of court, we still do the work.  We still prepare as though they're all going to trial, even though a good percentage of the time, that work ends up being wasted. You just never know which case is going to settle, which is going to trial, which is going to get delayed, which will be appealed, etc.

So, the results vary, all the time, irregardless of the quality of our work, so you can't worry about them. you just follow the procedures, and let the attorney's worry about the results.

Labels: HelpDesk, LitigationSupport

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 8:58 PM | 0 comments | Links to this post

 
Where was this 2 years ago?

When I was switching jobs, leaving a place where I was the only IT person and trying to document everything I did and leave instructions about how to do it, I seriously could have used this Lifehack article about How to Give Instructions.

I can definitely attest to how difficult it is to put yourself in the place of someone coming in with no knowledge of how to do something, when you've been doing it for so many years. I especially like the idea of documenting not just the procedures but also what to anticipate when it succeeds and what it will look like when something goes wrong. So often when dealing with some task we have done for years, we don't think about how it looks when it fails, we just know the warning signs when we see them. That doesn't really help someone doing it for the first time.

As tech support professionals, we should be documenting not just how to do something, but how to tell if it's working, and what to do if it doesn't. Too often, that information doesn't get included, even though it sure would be helpful!

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:42 PM | 0 comments | Links to this post

 
Couldn't Agree More

Linda Marie:

First and foremost, if you do not have people skills, you should not look for a help desk position.

That's absolutely true. The other thing that IT people at all levels tend to forget is what their role in any organization is. There's a certain amount of power that goes with operating any technology infrastructure, but too many IT people lose sight of the fact that the infrastructure only exists to help other people get the actual work of the organization done. They are your customers, and even though some of them give us plenty of "stupid user" stories to laugh about, ultimately, you're there to serve them.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:19 PM | 0 comments | Links to this post

 
Ribbon-esque

I had the opportunity today to try and help someone use CT Summation over the phone. Even though I've been using the program pretty extensively for a couple of weeks, it wasn't until today that I made the connection to Office 2007.

You see, in Summation, your toolbars, and menus change based on what part of the database has "focus". There are certain features that are either not available at all, or located in a very different place if you aren't currently focused on the image, the OCR document, the Case Explorer, etc.

As I was trying to help someone do an OCR search, I realized just how difficult it can be to walk them through things because you can't see where the focus is. It then dawned on me that if we ever move to Office 2007, the users who have been using Summation will have one big advantage and be higher along the learning curve then those who haven't. On the other hand, I realized that doing phone support for folks is going to be a bit more complicated. You'll have to make sure you have the correct view as the first step before you start walking them through a solution, otherwise you may wind up giving instructions that the user can't follow.

Either way, I'm glad we won't be making that upgrade for a long time. :)

Labels: HelpDesk, LitigationSupport

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:48 PM | 0 comments | Links to this post

 
Swatting flies

I read with interest the post by Security Monkey today about swatting flies, not because I don't agree with him about his point, but his example really brought to mind another of my pet peeves about working in IT generally, but Help Desk specifically. Let's start with his example:

Your help desk reports to you (the local security monkey) that users are no longer able to browse the internet via your proxy server. The users say that they keep getting "Cannot load page" messages.

A quick test from your desk works just fine. Obviously the users are just doing something wrong, right? All 200 of them!

You check the proxy server, the authentication daemon, the internet connection and then read all 200 service tickets again.

"It must be a client configuration error. Call up all the users and walk them through configuring their browser to use the proxy."

Several hours later (and $X^100 of wasted staff salary) you strike up a conversation with one of the infrastructure network engineers. He mentions a recent struggle with running out of address space on a few of the user subnets and then mentions a change on the firewall which performs a dynamic network address translation function to make all the users appear to come from one reserved IP in the DMZ.

You nearly drop your coffee cup. Why?

You know that the proxy server is configured to only respond to private address space behind the firewall, not the firewall's actual IP address.

A quick dash to your desk and many minutes later you reconfigure the proxy and users start to gain internet access again.

In other words, the hours that you spent swatting at that fly with the flyswatter could have been saved if you just realized that the fly was buzzing around your head because your shampoo smelled like a rotting animal corpse.

Now when I read this example, my first thought was not that there was time wasted not looking deep enough into the problem. There was, no question, but even more aggravating, there was help desk and security pro's time wasted tracking down something that should have been documented and communicated throughout the IT department. It'd be nice if everyone was communicating about the infrastructure, and the network guy was aware that the proxy server would be affected by the firewall change, and communicated that to the appropriate folks, and the help desk was notified that there was a firewall configuration change made and to make note of any problems that resulted from the change. Surely a help desk guy who knows the networking folks made a firewall change, who suddenly sees 200 tickets relating to Internet access would connect the dots and hand it off to the networking folks who made the change to investigate instead of the security guy who hasn't made any changes to the proxy server, right?

Unfortunately, I know all to well that in the real world, this lack of documentation and communication is all too common.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 8:48 PM | 1 comments | Links to this post

 
Classic Mistake

Kevin Devin posted something today about his workplace, wondering if the snake of Corporate IT was eating it's own tail.

When I read his story, one part jumped out at me immediately. Here was a classic example of tech support folks not having the authority, or tools, to correct a problem for a user. If I were one of those help desk guys, I might have gone ahead and made the call, regardless of the time difference. If you want to keep the control and authority and don't want your front line support people to have the power to fix a problem, then you have to deal with the calls at all hours.

Maybe I'm just a bit jaded after working tech support for so long. ;)

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 6:56 PM | 0 comments | Links to this post

 
Proper information

One of the comments Phil made in the interview yesterday stuck out to me as I went back and read it again this evening:

I stress how important it is that we get all the documentation, that we get our Fact Sheet filled out so when people call about things, we can at least answer the basic questions

It struck me because I would guess it takes a whole lot of effort to get people to think about those sort of things up front. I know even within some IT Departments I'm familiar with that a project is usually in it's final stages, at best, before anyone even considers what sort of questions will be directed at the helpdesk because of this project and what information they will need to answer those questions. Sometimes the help desk staff has to go and find the information after the questions have already started coming in. That's got to be one of the biggest frustrations among help desk staff, and help desk managers alike.

The bottom line for you IT folks out there, remember to keep your front-line support techs in the loop. It will save you a ton of headaches, and negative feelings, later.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 8:10 PM | 1 comments | Links to this post

 
Interview with Phil Gerbyshak

A while back, you'll recall that Phil did an interview with me about working at the help desk. Since he's a help desk manager, I thought it would be interesting to get some input from him about the management side of things. He was kind enough to take the time and respond to my questions, which I am posting below.

BTW, you can learn more about Phil at his blog, Make it Great, where you can also find links to purchase his book, 10 Ways to Make it Great. He also wanted me to let folks know that he will be speaking at the upcoming Help Desk Institute's Annual Conference, so if you're attending, be sure to look him up and say hi!

Q: Tell me a little bit about how you became a help desk manager, how
you got started in IT, how you developed into a manager, and anything
else about Phil that relates.

A: I started out as a tech support guy in the Navy, way back in 1992. When I got out of the Navy in 1996, I wanted nothing to do with computers, so I went to school to be a teacher. While at college, I started designing websites and teaching people how to use the programs on their computer. I dropped out of college and went to work at a local ISP as a tech support specialist, taking many calls from people using our dial up ISP, so I learned fast how to troubleshoot things, how to say the same things 50 ways, and how to think on my feet. Eventually I moved to a help desk, offering internal tech support assistance. When my manager decided he loved the Marine Corps more than he loved his job, I was promoted to manager.

Q. Tell us a little something about the help desk you manage, how many people you manage, what kind of support they're giving.

A: We are an internal and external support team, supporting 2200+ internal associates, and all of our external clients (77000 are signed up for online access, with more signing up every day). We have 7 people plus me on the help desk, and we answer all sorts of questions, from hardware problems, to how to use the Microsoft Office suite to how to use a financial planning system, and everywhere in between. We close between 80 and 85 percent of all calls into the IT department, and we use the Single Point of Contact (SPOC) model for IT, so all calls and e-mails come through us.

Q. How do you measure success? How do you identify your top
performers, and how do you reward them?

A: Success is a measure of quality, and how satisfied our clients are with the service we provide. We focus on fixing the customer just as much as we focus on fixing the person. We measure this by the amount of positive e-mail responses we get back, how many "blue chips" (we're a financial services company, so these are our internal gratitude notes) one receives, how the rest of the team perceives your value with an associate of the month program, and also with the Big FISH! program, where others in IT can nominate someone to receive an award for displaying the FISH! philosophy traits.

We reward folks monthly with an associate of the month award, which is nominated by others on the Desk, monthly with a big FISH! award, nominated by others in IT, quarterly with a quarterly associate of the month award as determined by overall quality, and annually with a merit raise and merit bonus. These are our team measures of success.

From external clients, we get blue chips awarded monthly, and annually the top 2% of blue chip winners get recognized firm-wide with a trophy and a nice gift.

Q. What kind of qualities do you look for in new hires? In potential managers/supervisors?

A: In new hires, I look first for attitude. Is this person willing and able to work with people who may be less tech savvy than they are, and are they willing to do so without talking down to them.

Next, I look for demonstrated excellence. Has someone been associate of the month/quarter/year somewhere else. Have they made the Dean's list at college. Do they have e-mails from clients that state what a great job they've done.

I also look for communication skills. Can you communicate verbally and written, with me, and with customers. I ask folks to demonstrate their communication skills by walking me through something complex, and I evaluate their step by step communication abilities, as well as their temperament, because they need to be patient on the phone.

Technical aptitude is important too, but this is really a given. If someone gets past our recruiters, they have some experience on a Help Desk or in customer serivce. We can gauge this by certifications, degrees, and past experiences. I'll dig on this a bit, but the first 3 are FAR more important than the last one.

I don't hire managers or supervisors, so it's tough to answer this question. I think the answer to your next question will help you with finding out the qualities I think are necessary for management.

Q. What's the one biggest difference between working in IT, and being a manager?

A: Working in IT is a lot of troubleshooting, a lot of break/fix, and a lot of the same types of problems, every day. Basically, you get password resets, how-to questions, break/fix, and a few where you need to do a deep dive to find the answer. Granted, the how-to questions are not the same, and the people are different and respond differently every day, so there's plenty of opportunity for new learning.

As a manager, it's almost all deep dive into items, working with people to help them find fulfillment in solving problems. As a manager, I am responsible for many of the processes we use to solve things, or at least to find one way of doing things. I don't dictate anything, I suggest things as a possible solution, with the rare exception of policies that must be followed for the good of the team and the good of the firm. That's the management part.

I'm also a coach, working with my team to develop them as people, and to help them leverage their unique strengths the best way possible. Some folks are much more process driven, so I put them on documentation projects. Some like to see a finished product, so I put them on reporting projects. Some are people folks, so I have them do the tougher client call backs. Knowing and utilizing these strengths is a big part of what I do every day. I also take time to help my team write out their goals, what's important to them, where they want to be at the end of this year, 3 years, 5 years, or however far out they want to look, and help them find the intermediate steps necessary to get there. I often need to look at projects and how I can plug them into projects in meaningful ways.

The last part of my job as a manager is sales and PR. In projects, I am constantly selling the value of our team, and in how important it is that folks get us the documentation early so we can start testing an application before it goes firm-wide. I stress how important it is that we get all the documentation, that we get our Fact Sheet filled out so when people call about things, we can at least answer the basic questions. And the PR part is done when I handle escalatations, or I go to events, or I sit in projects, and people ask us what we do and how we do it, and I explain it in a way that helps them know why we're a key part of the entire process.

Q. Anything else that I'm missing? Any parting words of advice for those of us working the help desk in furthering our careers?

A: Don't be afraid to fail. Wayne Gretsky said you miss 100% of the shots you don't take, and on the Help Desk, you get the chance to take a LOT of shots. Take advantage of every opportunity presented to you, and learn from your mistakes.

Never stop learning, about yourself, about the business, about your customers, about yourself. Ask what's needed, and do it, and MORE. Technology changes, people changes, you change. Focus on learning as much about everything as you can, and you'll be invaluable to your firm. Many folks remember the technology side, but knowing the business is just as, and in many cases MORE important, than the tech side. As a Help Desk professional, if you're not an integral part of the business, you could get outsourced.

Don't take anything personally. People get frustrated with the technology because they don't understand it, and they take it out on you. Don't take it personally, because 99% of the time, they aren't mad at you.

Lastly, smile. All the time. Because there is no better feeling than knowing you helped someone get what they needed done, just in in the nick of time. You are more valuable than you'll ever know, so smile and know that.

--

Thanks Phil. I appreciate the insight you've provided in these answers. I'll have some more to say about them in future posts this week, but for now, let's hear your thoughts? What do you think about help desk management?

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 8:40 PM | 0 comments | Links to this post

 
A perfect example

I've mentioned before why I think measuring the effectiveness of your help desk folks by looking at the number of tickets they work alone is dumb. This week, I had a perfect example.

We had one of our pool laptops lose a hard drive this week. The replacement drive came in Thursday late in the day, so I set out Friday morning to swap the drive and start the process of installing Windows XP and all the various device drivers, getting all the updates, installing Office and all the other extraneous software (A-V, VPN, Adobe Reader, etc.) that our users might require when traveling with this laptop.

I also answered a few help desk calls/emails while this process was ongoing, but, obviously, not nearly as many as the other people working the help desk that day. If you pulled a report from our help desk software for that day, it'd look like maybe I didn't do as much work as the other folks, when, in fact, I probably did more. It just so happens that one of my tickets was an all-day project. If we were using number of tickets as an important metric, I wouldn't have focused on getting this laptop done, and available for our users, I would have focused on closing more tickets, because that's what I'm being measured by.

On the other hand, I know what was better use of my time in terms of providing support, and that wasn't worrying about the number of tickets I worked.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 2:18 AM | 3 comments | Links to this post

 
Might be time for an upgrade

We frequently do business with a firm that prepares reports for us, stuff like environmental impact studies, etc. that they in turn make available to us for download from their website. Since the clients want us to send them a CD copy of the report, and since most of our users don't have CD burners, we get the unique pleasure of grabbing these reports and burning them to CD.

Doesn't sound like a big deal, right? Only, it usually is. You see this firm, I'm guessing, uses this approach to all their work, and must have a whole lot of people trying to access their various reports at the same time. At least that's the only explanation I have for the ridiculously slow download speeds. The other day, I needed to grab a 9MB PDF from their site. It took me all afternoon. The first three attempts timed out at some point in the download. The 4th attempt completed in about 2 1/2 hours. Yes, I was getting a whopping 1.2 Kb/sec download speed. (That was the average, I actually saw it go as low as 897 bytes/sec. at one point.)

I'm not trying to tell anyone how to do business, and I'm certainly not trying to come off like more of a network guru than I am, but it seems like having some more pipe to your webserver, and maybe even some more processing power on that server, would save your customers some headaches, wouldn't it?

Labels: HelpDesk, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 1:42 AM | 0 comments | Links to this post

 
How much is too much?

I've always been of the belief that whenever you're dealing with end users, the more information you could give them and the more ways they could access knowledge, the better. A couple of things recently have me questioning that theory.

One was this whole DST mess. If there was one constant in all the things we did it was this. Every communication we sent to users in the hope of limiting some help desk calls by supplying information ahead of time, only resulted in more help desk calls. Instead of people reading the email, following the directions and going about their lives without the need to involve tech support folks, they called to ask questions about the email. Even people who didn't actually need to do anything different from what they always have been, called to make sure they didn't need to do anything. It seemed like the more we tried to educate people about the issue, and what to expect, the more it just confused them. A handful of people literally just took to ignoring any emails that came from the IS department, figuring we'd fix whatever needed to be fixed later for them.

Here was a case where our attempts at sharing information backfired completely. It illustrates to me that when it comes to technical information, there is a saturation point where users simply tune you out.

It was with this new illustration that I had in mind when I was spending some time looking over some helpdesk software. The front page of the software for an end user presented them with three options, submit a ticket, search the knowledge base, or post a question in the forums. My immediate thought was, for many people, this is one option too many, maybe even two options too many. Many of my users would never bother to post a forum question. Why would they when what they really want is someone in IT to fix something for them or show them how to do something? They already have the option to submit a question to IT where it will be assigned to someone to handle, why post it on a forum and wait for "someone" to answer? Perhaps other organizations would have a different expectation, but in terms of where I work, that's probably just going to confuse people about how to submit a question, which will prompt them to call. *L*

It also got me to thinking about all the different tools we have now to train users. We do screencasts, webinars, podcasts, classroom training, one on one training, printed materials, etc. At what point do we offer a user looking for training information too many options? Isn't there some point where a user goes to the training page on the intranet, is overwhelmed by the choices, and just says "nevermind"? I think there very well might be, but I also think that point is individual to each user, so how do you plan around it?

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 7:55 PM | 3 comments | Links to this post

 
OLK

You know what I really love about Office 2007? Microsoft finally got wise to the number of people who make changes to email attachments and lose them.

We don't use Office 2007 at work, and I can't tell you how many times we get phone calls at the helpdesk because someone opened a Word document from an email attachment, made changes to it, hit save, closed it, and couldn't find it again. No matter how many times we tell people that documents they get as attachments are not in our document management system, and that hitting save doesn't magically get them into our document management system, I still find myself navigating to someone's OLK"X" folder on their C drive remotely to grab the document they saved there once a week or so. (And yes, if you really want to have fun, try explaining to them how they could do that themselves the next time. Ever tried to navigate to your local OLK folder?)

When I open a Word attachment with 2007 and hit save, Word doesn't just save in the same place, it forces me to file it somewhere. It's about time!

Labels: HelpDesk, Microsoft

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:54 PM | 0 comments | Links to this post

 
One large file

Today at work someone brought me a DVD, asking if I could print out the drawings that were on it. I've done this sort of thing plenty of times before, our printer has 11X17 paper loaded so we get survey and blueprint drawings that need to be printed all the time. The one thing I couldn't figure out was why they bothered to put them on DVD.

When I opened it up, I saw exactly why these files were on DVD. Instead of the usual PDF or even CAD files, these suckers were TIF's. One of them, with 15 pages worth of drawings, weighed in at a nice 1.13GB. (That is not a typo, that's GIGAbyte.)

I had to print it one page at a time. At 75MB per page, the printer couldn't really handle much more than that. :)

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 8:44 PM | 0 comments | Links to this post

 
At least we hope so

Steven Vore was kind enough to pass along this Computerworld article to me today titled The Help Desk: Often the First Step in a Successful IT Career

Couldn't agree more with that they had to say. There's no doubt that you get exposed to all kinds of stuff, and definitely have to figure out how it all works to be good at this.

Thanks for passing it on Steven!

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 11:22 PM | 0 comments | Links to this post

 
Brilliant stuff

Yes, it's another post by Ziggi over at Help Desk Talk. This one about the help desk solution puzzle. This is exactly what I'm talking about when I talk about working in tech support being about so much more than tech skills. It's about knowing how to interact with people, read people, teach people, etc. Seriously, read what he says about it:

Some places that clients may come from-

Frustration with a situation they can not control.
Anxiety regarding the fix process.
Impatience to be up and running.
Fear of lost productivity or missing deadlines.
Anger at the situation in general.
Denial that they in anyway contributed to any of this.
Guilt that they may have contributed to this.
Impotence in not understanding any of this.
You can fill in the rest I’m sure.

Any two or three of these emotions would keep a shrink busy for at least 8 to 10 sessions but there is no shrink in sight so the Help Desk analyst is it.

If that's not convincing you that people skills are vital to doing the job well, I don't know what will!

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:39 PM | 0 comments | Links to this post

 
Manic Mondays

Is it just us, or does everyone wind up knee deep in returned pool equipment on Monday mornings? I spend so much time on a typical Monday checking in, cleaning and updating pool laptops that were out for the weekend or longer (especially the Monday after a patch Tuesday!)that it seems I don't do hardly anything else. Of course, the fact that one of them came back without our VPN software installed, and needed to go back out to another user today added a bit of urgency to the whole process! I should probably go back and figure out what happened to the VPN software tomorrow. It might be time to interrogate some people. :)

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 8:30 PM | 0 comments | Links to this post

 
Outsmarting the Helpdesk

When I read this story about someone outsmarting the help desk at their work, well, you all know I couldn't help but have something to say about it.

Go ahead and read the story, I'll wait.....

This story bothered me for one very large reason, and it's become something of a pet peeve of mine over the last year and a half of working at a help desk. Most people read that story and think "typical, help desk guy doesn't know anything, but good for you going around them and their processes!". And to some extent, you'd be right. In the larger picture though, this is an incomprehensible failure of management, not the help desk. How dare you put someone in the front lines of tech support and not inform them of an entire small network living in your building apart from the main one? You're setting up your support people for failure by not communicating with them and sharing all the information you have. I don't know if the "X" person is in IT management or not, but he is just as much to blame. If you work in IT and you are the only person who knows about a very large project that is going on (or an entire network!), and you don't bother to inform the folks doing front-line user support, shame on you. You are making your co-workers, your fellow team members, look bad, which only makes the overall impression of everyone in IT within the organization suffer.

Link originally seen at Help Desk Talk.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 8:43 PM | 2 comments | Links to this post

 
Bad IT Day

What's a bad IT day? How about a day where you have more servers being wonky than you have server admins available to deal with them? We had that one afternoon this week. A voice mail server off-line, a Blackberry Server running at about 30-40 minute delay, and a whole bunch of users have some sort of unidentified problem connecting to the SAN. Good times, good times. :)

Naturally, in the course of investigating the problems communicating with the SAN we're actually discovering a bunch of other issues that are causing similar symptoms but are not the same problem. Some folks have a delay opening programs or working with programs that have ties to their home drives. Unfortunately, a "slow" computer is a ridiculously difficult thing to troubleshoot, because of the number of different things that can cause that symptom. A bunch of folks getting the same problem in one week would seem to signify some sort of network issue, especially when the SAN is brand new, but the more people we look at in depth we just end up with a different problem for each of them! So while one was fixed by changing some applications settings to point the their C: drive instead of the home drive, another user had a voice recognition process that kept hanging up, while yet another had a rogue process being blocked by our firewall, but still tying up CPU cycles. That only leaves us with about 20 more people with slow computers to work on next week. :)

I was so glad to see this week end!

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 12:16 AM | 0 comments | Links to this post

 
Don't insult your users

The title of this post by Sherman Deforest got my attention right away, No One Needs To Feel Put Down By A Hired Expert. Obviously, no one needs to feel put down by their help desk either. :)

Here's my favorite part:

They are not stupid or senile. Their cultural background is different than mine. Almost certainly either of them can do many things that are well beyond my grasp. Further more, they are smart enough to know when to ask for help rather than giving up in frustration.

It reminds me of something we like to do around the help desk when we are tempted to put down one of our users, remind ourselves that, in many cases, they got through law school, they can't be just stupid. Stubborn, arrogant and argumentative? Sure, but not stupid, so don't treat them that way just because they don't know how to add rows to a table. It helps to remind myself just how much they do that I don't know how to do, whether it be a lawyer, secretary, file clerk, etc. Then it easier to see how showing them how to operate their PC is what I get paid for, and not be troubled when they don't seem to get it as quickly as I do.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:49 PM | 1 comments | Links to this post

 
Interview

Phil Gerbyshak E-mailed me a number of questions about working at a help desk, and is posting the interview as a series over on Help Desk Notes. Part 1 went up last night, I'll update this post with links to the other parts as he gets them posted. (Part 2 is up, as well as Part 3 and Part 4)

This was a very interesting process, Phil's questions made me really think about what I do, and how I do it. I'm actually going to return the favor here shortly and have Phil answer some questions from the perspective of a help desk manager. Should be an interesting exchange as well!

Labels: Blogging, HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 6:50 PM | 0 comments | Links to this post

 
One simple request

I know your keyboard needed to be cleaned, and as an IT guy I appreciate the fact that you were willing to clean it for yourself, but was it really necessary to do that while it was hooked up to a running PC? Are you really surprised that somewhere in this process you hit some keystrokes that messed up something and locked up your PC?

At least a reboot corrected whatever they had done, so it was simple enough to fix, but this whole call could have been avoided, really.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:44 PM | 0 comments | Links to this post

 
Maybe a bit too secure

You know I've always been a big advocate of finding that fine line with technology where it's secure, but still usable. Today at the office I think we found someone crossing that line a bit. We had a client laptop in our office. They needed to use our guest network to VPN to their network, which is completely common and no big deal really. We don't have a publicly available network in our office, you do have to call the help desk and we assign a username/password combo specific to you, so that way if someone's using the network to do something untoward, we can track down who it was.

Like most networks like ours, we redirect your browser when you first connect to our network to do the authorization before you can go anywhere else. Well, this laptop had proxy settings in the browser. It was trying to access a public proxy server, which of course it couldn't because it hadn't authenticated with the network yet, but the proxy was interfering with our redirect so nothing happened. So we disabled the proxy. We got a good connection, and the VPN wouldn't connect. Turns out that the VPN server on their network requires that all connections come through that proxy server. Not only does it not allow other connections, but it automatically disables the account of the person trying to sign in to the VPN.

Yes, it took numerous phone calls, and our network engineer to talk to their network engineer before we figured out how to work around this. (Disable the proxy, authenticate with our network, re-enable the proxy, THEN connect the VPN)

Seems to me that the usability factor had been lost in this equation. But maybe that's just me.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 11:14 PM | 2 comments | Links to this post

 
Thank you notes

I found this post over at the Manager Tools this morning about the practice of sending thank you notes dying and I had to say I was interested. I have to admit something. Before I met Angela, I never wrote thank you notes. Not for birthday gifts, or at Christmas, or for anything really. In fact, for many years I had a very difficult time expressing gratitude in any fashion. Of course, my wife wasn't going to stand for that so I've gotten quite good at making sure I send thank you notes to anyone who gives me a gift for my birthday, anniversary, holiday, etc. I've also discovered the pleasure that comes from being able to say "thank you" in a formal way when it's appropriate.

Ever since I read Mark's post this morning though, it's occurred to me that there are probably plenty of times outside of gift-giving that I need to be more aware showing gratitude to folks who have done me a favor. Maybe most of them don't necessarily need to have a hand-written note, but certainly an email, or even a more heart-felt thank you than the every day, emotionless "thanks" would do a world of good in making people feel appreciated, and that certainly makes it worth my efforts.

As a help desk worker, I know how much it means to me to get more than the cursory "thanks" for solving a problem, so I should be doing it more than anyone!

So with that, in mind. Thanks for reading, and commenting on the site. It makes all the writing worthwhile. :)

Labels: HelpDesk, Personal

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:54 PM | 2 comments | Links to this post

 
Help Desk Radio

Speaking of the drive down to Cincinnati, while scanning the dial this morning, I caught a few minutes of a show called "HelpDesk", on WMUB, a college radio/NPR station in Oxford, OH. Turns out that the call-in show is broadcast on-line on Tuesday mornings, and is also available as a podcast. Could be an interesting source of tech information. I might have to give it a listen.

Labels: HelpDesk, Tech

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:07 PM | 0 comments | Links to this post

 
One way to help burnout

After all that discussion about burnout among help desk folks, today I had the rare experience of getting to do something different. I spent most of the day driving down to our Cincinnati office to work on a couple of projects, and then driving back to cover the help desk through the end of the day, naturally.

It's not much, in fact the projects weren't even anything different than anything I typically do in our main office all the time, but it's something different, a way to break up the monotony of answering emails/calls all day long.

Now to convince management that this should be a more regular occurrence! Not necessarily driving down there, but having the opportunity to do something a little different every once in awhile. We'll see how far that goes.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:54 PM | 0 comments | Links to this post

 
A fifth cause of burnout

I was reminded today of a fifth reason people get burned out doing tech support. Unrealistic expectations. For example, when your users have a problem with technology that isn't something you support, but which they still expect you to take care of for them. In some cases that can be personal tech like an iPod or some other gadget that isn't part of their work, but which they still expect you to support, or in my favorite example people who call you from outside the office because they can't get an Internet connection to work. There's nothing like someone calling you from Starbucks 1000 miles away because their work-issued laptop didn't connect to the wireless network. Or calling you from a hotel asking which wireless network they should connect to. I've even had people call me from their own house when they have trouble connecting to the Internet.

The worst part is that these same people can grasp that when they have a client in our office who needs help connecting to our "guest" network, that we are the ones who can help them do that, but apparently there's a disconnect that occurs when they are at a remote location connecting to a remote network that causes them to assume we are the ones to do that as well.

Anyway, my ranting aside, I do believe that having a well-defined limit to what you'll provide support for helps your support folks not burn out quickly.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 9:38 PM | 2 comments | Links to this post

 
More on career options

An interesting, albeit anonymous, comment left on a previous post:

In my Firm’s IT group (3 techs and 3 application support/trainers) we don’t have people dedicated to help desk – it’s part of everyone’s job. We all do other admin, setup, and development work which constantly change with the Firm’s needs. The model provides great support by making experienced, knowledgeable people available to everyone in the Firm. Will this setup work forever? Likely not. Do I keep people beyond the five years you mention? Yes.

That doesn't surprise me actually. When I was a one-man shop I answered all the tech support requests, but I also wore the network and database admin hats, I worked there for almost 8 years and my leaving had nothing to do with being burned out from doing tech support. (I was burned out in many other ways in terms of dealing with the small office constraints, but not the work.)I do believe there are specific things about being responsible for just helpdesk stuff that causes the burn out.

1. The repitition: Let's face it, the phone never stops. It may stop for a few minutes and you may get to have a few minutes to talk with your peers but your existence every single day revolves around the next call, or the next email. They never stop coming in. In our office's case, we have a 14 person IS staff, 2 of whom do nothing but field support requests all day long. There are enough requests that come in that it's necessary to have that. The larger the firm, the more likely that is to be true.

2. The unpredictability: While it may seem like a contradiction of number 1, it's not just the fact that support requests never end, it's that you never know what the next one is going to be. You go to work each and every day not knowing what you'll be working on or what will be required of you. That can be stressful.

3. Not a "Finisher": Your job at the help desk is to resolve any issue as quickly as possible and get the person at the other end of the ticket back to doing productive work. That means your work involves finding quick workarounds, not polished solutions. In essence, when a more complex solution is needed, even if you're the one who suggested it, you're never the one to finish and implement the solution.

4. Lack of authority: Not only are you not around to finish off the nice solutions, most times you don't have the authority to do anything more than find work-arounds for people in the first place. It's my belief that the difference between a 5 year burn out and a less than 2 year burn out timeframe is how often a support person can clearly see that something needs to be changed but bang into a brick wall trying to get anyone with actual authority to do anything about it. Good managers take their front line support folks' recommendations seriously, bad ones don't, and tend to burn their folks out much quicker. Nothing is more frustrating than not being given the tools to do your job properly, no matter what your job is. Yet somehow, that's exactly what many tech support folks are stuck with, and also somehow, people are surprised that no one wants to do it for very long. It'd be like taking a construction job and being told that the foreman would prefer you not to do any hammering, but to find another way to get the project built. You wouldn't stay at that job very long, would you? It'd be beyond frustrating trying to get your work done, wouldn't it? Your help desk staff may feel the same way if you don't give them the freedom to support your users how they see fit.

I do believe the folks who don't burn out are folks who have the authority to implement solutons, who are supporting a very specific technology, and who get to work on things aside from closing tickets as quickly as possible. Some organizations can allow for that, some can't, or won't. But they shouldn't be surprised that they are always looking for a new help desk person either.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 8:44 PM | 0 comments | Links to this post

 
Long term career choice

A question we were discussing around the help desk the other day. Is working on a help desk a long term career choice? My own opinion is that there's about a 5 year shelf life. After 5 years, you simple have to do something besides spend your entire day answering user calls/emails and closing tickets. Much like working in a call center, whether it be tech or other customer service position, I believe there is very high burnout rate, and there are very, very few people who can do it long term.

I've been doing it for about a year and a half, and while I'm not burned out now, I know that I've only got a couple more years in me before I'm too cynical to be any good at it any longer.

So, if you're managing a help desk, do your long term plans include having to turnover all of your positions every 5 years, or finding some way to keep good talent by transitioning them to another position? Or am I just completely off base here?

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 7:46 PM | 3 comments | Links to this post

 
Working around the process

Ziggi, the writer over at Help Desk Talk posted a follow up to a comment I had left over there earlier in the day, and I had a few more thoughts on the subject on help desk folks working around a process that doesn't fit what we're trying to accomplish.

One, this is one of the obvious problems with having metrics to measure the "success" of your help desk that your help desk folks don't have input into. I've yet to find a ticketing system that accounts for all the work we do effectively. There are always projects or activities that don't have a corresponding "ticket". For example, something like getting a pool laptop patched takes time and resources, but since our ticketing system is based on "user" requests, it doesn't fit. So if they're using just tickets closed as the metric to measure help desk folks in our case, as the guy who's responsible to make sure our laptops get updates, they're missing a lot of the work I do.

The flip side of that, naturally, is that if someone were to decide to measure me solely on the number of tickets I close, guess what I'm not going to spend any time doing? Getting laptops updated, or any other project that keeps me away from working user issues that are documented.

Secondly are the processes we simply work around. Not necessarily things that don't fit the metrics, but cases where we do something contradictory to the established processes because the processes don't work. That's a problem that occurs in many places because, again, management decides what the correct process is to be, without ever asking their help desk folks whether the processes make sense. You've all seen those I'm sure, the cases where a user simply needs to do something, doesn't have rights, and the established process is to have them email the network admin explaining why they need those rights, so that he can check with the CTO as to whether to grant them and then get back to the user with a response, but the reality is that they just need those rights to do one simple thing that needs to be done right now, so your help desk folks just do it for them and don't document any of it.

Luckily, for me, we don't just use ticketing metrics to measure the work done by the help desk folks. Unluckily for me, there's no concrete measurement to know how I'm doing at any particular time. I really have to rely on management feedback to know. Depending on your manager, that could be problematic.

Some managers don't really know what goes on at their help desk. Some rely solely on user feedback to determine how their support folks are doing. That makes no sense. Users are always more likely to contact management to complain than to praise. That's just human nature. Plus, helping users is the job. Most users accept the help but feel no need to contact your manager when you "do your job" 100 times. But fail to satisfy them one time, and they sure will.

Really, my point here is that measuring the efficiency of internal help desk folks is very difficult. You need a ticketing system to get some, but not all, of an idea of what they're dealing with. You need to communicate with them about what processes make sense an which don't, you need to empower them to work around the things that don't make sense, you need to know the users as well as they do so you know what "complaints" are valid and which aren't, you need to give them ownership of the whole process, and you need to be acutely aware of not burning them out. (Which may be impossible, but is a subject for another post)

BTW, I haven't seen all of that in a job or manager yet. It may not exist.

Labels: HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 10:48 PM | 5 comments | Links to this post

 
Promising new blog

Ian Landsman tried to launch heldesktalk.com as a forum to discuss help desk issues, but when that proved to be too much of a challenge for the amount of time he had, he brought in his dad to turn it into a blog:

The site will be original writing, but will also link to ongoings in the help desk world as well as relevant articles which appear in the mainstream IT press.

I have to say, for a blog that's been in existence for two days, there's already some interesting, and thought-provoking stuff on there. Definitely worth a subscription for all you folks dealing with help desk stuff!

Labels: Blogging, HelpDesk

Digg this | Post to del.icio.us| FaceBook | Stumble Upon| Google Bookmark| 8:34 PM | 5 comments | Links to this post