In my work I’m constantly bombarded with reports of problems. Given that a high percentage of these come in with an urgent tag attached, I decided some time ago that I needed to come up with a systematic approach to determining their true priority. After all, I’m only one man, and if I treated everyone’s problems as raging fires, I’d never get anything done. What I’ve come up with is the following three-pronged approach:
Clarify the scope
In my experience (and I’m sure that I’m not alone), problems tend to be described by end users in global terms: “the system is down”, “we cannot login”, etc. But in reality, the problem may be much smaller. I once had a user e-mail me directly (another no-no) stating “System X is down, I cannot login. Please fix immediately.” When I called the user and asked about whether others in his group were experiencing the same problem, he replied “Yeah, I think so. I didn’t ask.” When prodded to ask further, it was discovered that the problem was limited only to this one user, making it a far lower priority than the original message would have indicated.
What is the impact?
Ok, so you’ve established that there’s a problem, and you know it’s affecting an entire department. But what does the existence of the problem mean for business? Are operations at standstill? Are people being forced to sit at their computers and twiddle their thumbs? Or, on the other end of the spectrum, are people’s widgets not looking as pretty as they should be? I’ve found it helpful to evaluate technology problems in the context of how the functionality of a system is affected. There’s a huge difference between losing a minor feature of a program versus losing the core business requirements.
Is there a workaround?
In today’s world, technology is often about the automation of manual processes. If the automation fails, users can often revert to the (albeit slower, more painful) older methods of completing their work. If the problem has no workaround, however, you obviously have a bigger issue to contend with. Keep in mind though, workarounds are only as good as the user’s ability to carry them out. If your automated trading system goes down at 3:50PM, and no one remembers how to enter trades on the old green screen terminals, you might as well not have those terminals in the first place.