It should be easy, but sometimes reporting IT problems – and getting the results you want from your IT support department – doesn’t seem to be as straightforward as it should be.
You’ve explained the problem to them, but somehow they don’t seem to get it. As the journalist William Whyte observed, “The great enemy of communication is the illusion of it”, and sometimes (attempted) communication with IT folk just seems to underline that.
How not to do it
Consider Susan, who walks into the meeting room and notices one of the ceiling lights isn’t working. She contacts building maintenance and asks that they replace the bulb.
Later, she visits her GP and tells him that she cut her finger a week ago, but it’s still quite painful, and now a little red and swollen.
See the difference?
In the first case, she told the support organisation (building maintenance) what to do. In the second (her GP), she told him what problem she was trying to solve.
It’s a subtle difference, but it can have a huge impact. For a start, the first approach may not yield the results you’re looking for (there’s no guarantee that the light problem is caused by a faulty bulb).
More importantly, though, you aren’t getting the best from the support organisation if you tell them what to do. Whether they are building maintenance, a doctor or IT support staff, the chances are that they know more about their discipline than you do – that’s why you’re using them.
Four (and a half) steps
Here’s a really simple guide to reporting IT problems that will help both you and them get those problems resolved as soon as possible. Four items of information to report to your IT people, with an optional fifth if you want
What were you trying to achieve?
State the end result you are trying to achieve. Take care to define the problem rather than your chosen solution.
A good test is to take your definition and ask, “Why?”. The answer to that will usually tell you whether or not you’ve defined what you are trying to do rather than how you are trying to do it.
If the problem is intermittent, also give as accurately as possible the date and time your problem occurred.
- Good example: “I want to print a document I’ve written in Google Docs”
- Bad example: “Can you reboot the file server, please?”
What you did
Simply state what you’ve done so far. Don’t embellish it or add detail: this should be a factual account of actions taken.
- Good example: “I clicked on the “print” icon in the toolbar”.
- Bad example: “Marie said that we have to…”
What happened
The outcome was presumably not what you were expecting. This again is a factual description.
Avoid adding your interpretation of what is going on: just report what actually happened.
- Good example: “The print dialog appeared, and I clicked on OK. Nothing seemed to happen after that”.
- Bad example: “I got an error, and it looks like there’s a problem with DNS”
How what happened differed from what you expected
This is a natural follow-on to the previous question. Yet again a factual statement: what did you expect to happen?
The reason this is important is that sometimes what happened was exactly what should have happened, but it may not be what you want.
- Good example: “I expected the letter to print on the printer next to Marie’s desk”
- Bad example: “It should have just worked”.
Any Other Information
This is your opportunity to fill in any gaps and – if you want – suggest what the underlying problem might be.
There are no “bad” examples: you can say what want here.
Good examples:
- “My PC was rebuilt last Tuesday by Adam, and this problem has only happened since then”
- “The same problem seems to be affecting everyone in Accounts”
- “I think this is a DNS problem because …”
Let them help
Most IT people cite solving IT problems as one of the things they enjoy most about the job so, despite the impression you may get from time to time, they do want to help. Sometimes there’s a communication breakdown between users and support staff that leads to frustration on both sides. The guidelines above will help avoid that frustration.
If you’re not sure, ask your IT people if reporting problems in this way would be helpful.
Tell them what result you want, share with them the “why” rather than the “how”. Not only is that more likely to get the result you want, but it will also lead to a more productive relationship with the support person.