Think of a support call as a very small project. When you have to place a support call, you’re the project manager. Think like a project manager, and you’ll have better results and finish faster.
The Beatles Call Support
A support call has a Deliverable Date, just like a project: there’s a ballpark expectation of when the support call needs to be finished. Sometimes, for urgent calls, it’s ASAP, but for long-term nagging issues, it may go on for weeks. Knowing the severity and urgency of the issue helps to determine the deliverable date, and that impacts how aggressively the project manager works on the project. Some projects must be worked 24/7 until completion, while others can be pursued more slowly. Approach every support call with the same urgency, and pretty soon everyone will start reacting to you with the same level of urgency – a shrug of indifference.
Like a project, a support call involves Resources: things that can help finish the project. The more valuable the resource, the more difficult they are to get, and the less time is available from them. In general terms, IT support resources consist of:
- Support. These people talk to a lot of customers, and they can quickly recognize common symptoms. There’s a couple levels of support, and the first level of support exists because some users don’t read the manual, don’t search the web, and don’t reboot. They pick up the phone and scream every time they see a popup dialog box. They aren’t qualified to do their jobs, and you’d fire them in a heartbeat if they worked for you, but not everybody is as qualified, well-trained, and attractive as you. (That’s a great-looking shirt, by the way.) Unfortunately, these kinds of users sound exactly the same on the phone as you do, so we have to treat everybody the same initially. You might go through a couple/few levels of support depending on the size of the company.
- Escalations. As the Special Forces of support, Escalation people are called in when the problem is intricate or may take days to replicate. Every weel or two, an Escalations person contacts me for help writing a T-SQL script or figuring out how to set something up in the lab. Last week, the question was about how to build a 500gb database across several drives as fast as possible using just T-SQL. (Good Escalations people know that if you can replicate something purely with T-SQL, then you can hand it to any developer anywhere in the world and say, “Here’s how to see the problem on your machine without installing anything.”) Escalations people may work on the same problem for days, because they have to be able to hand it to a developer and say, “Here’s how to duplicate the problem in a few minutes. Now look at the code and see what it’s doing there.”
- Quality Assurance. Ah, you didn’t think about them, did you? QA gets involved sometimes because they have an extensive lab with lots of hardware and software configurations. They’re responsible for banging on the software before it goes out, and they do the same types of tests over and over with every version. As a result, they’re familiar with a lot of really obscure configurations, and sometimes they can duplicate problems very quickly with gear they’ve already got set up.
- Developers. Mad scientists who build cool stuff while shooting Nerf guns and drinking energy beverages. As good as they are at building things, they aren’t necessarily good at public relations or dealing with customers. They hate conference calls, hate meetings, and they don’t want to stop coding because they’re already on a tight deadline to build the next version of something.
- Salespeople. They’re great at public relations and dealing with customers, love conference calls, love meetings, and they’re waiting for your call right now.
Understanding what each resource does will help you get the right one. If you’ve got a problem and you ask for developers to get on the call, you’re going to be even less satisfied than if you asked salespeople to get on the call. At least salespeople will give you a free t-shirt – developers are just going to give you a Nerf arrow to the head. (And if a vendor offers to get a developer on the phone for you every time you call, stop to think about how much “development” that person’s really doing if every customer has that capability.)
I’ve worked with some amazing project managers who could listen to a problem in a meeting and say, “It sounds like we need to get Jim involved, because this is a network question, right?” They picked up on terms and phrases, learned what problems lived in what domains, and knew who to grab. I’ve also worked with boneheads who knew just enough to be dangerous and said things like, “The production server needs more cores! Schedule a meeting with the network team! All hands on deck!” Don’t be that guy.
Resources are more than just people. A common troubleshooting resource for a SQL Server problem is to have a spare server that can be used to duplicate the problem from production. This resource is helpful to repeatedly test suggested fixes that might require reboots or configuration changes that would not be desirable in a production environment. Not everyone can afford a resource like this, but depending on the severity of the support call – aka our project – we may have an easier time procuring this resource.
A support call has Deliverables, and the more clearly defined, the better your odds are of getting exactly what you want quickly. Project managers struggle with this because deliverables start out sounding like:
Build us a new office in Washington, DC.
The first phase of the project will be building a better set of deliverables to identify how many people will be in the office, what kinds of infrastructure the office needs, whether to put bars in the conference rooms (I’ve seen that), and so on. Similarly, support call projects start out sounding like this:
The network connection keeps dropping.
Over time, it starts to sound more like this:
When I run v3.5 of the network card teaming drivers on a 64-bit OS, and one network connection goes down, the second network connection doesn’t automatically take over. It does work with v3.4, but not with v3.5 on the same hardware. We’ve tried three different servers with the same network card models. v3.5 does handle the failover on 32-bit OS’s, but not on our 64-bit boxes. We’ve verified that we’re running the 64-bit versions of the driver, build 957.
As the project manager, you have to decide when to call in more resources. Do you do it right away, when you just have a five-word deliverable? Or do you identify one or two small key resources who can help you build a better deliverable first, and then marshall all of your available resources? It’s up to you, Project Manager. Good luck!
