“Surprise” is a four-letter word to a support organization– not the surprises that keep one’s job interesting, but the surprises that make one’s job lousy: budget busters, deadline destroyers, and coworker contention.
To keep surprises to a minimum when dealing with support, it helps to understand the three steps of support and to communicate appropriately at each stage. The steps are:
- Pre-investigation (setting the stage)
- Investigation (troubleshooting)
- Resolution (implementation)
Each step is essential and cannot be skipped, though we often don’t distinguish between them because we work through them quickly. With complicated issues, however, their distinction becomes more important.
The operative word above is “complicated,” not “complex.” Regardless of the skill levels of the problem solvers involved in the resolution of a complex issue, surprises – complications – that affect the organization, such as political dynamics, timeline, and budget can kill a good solution.
The goal is to put the support issue to rest, in peace (pun intended), meaning with as little emotional and financial collateral damage (surprises) as possible. Often, the temptation is to cut corners by skipping straight from symptom (support issue as reported) to treatment (resolution) without a proper examination or diagnosis (pre-investigation and investigation) due to a desire to avoid surprises. Sometimes we get lucky and this approach works … until it doesn’t, and when it fails, it can do so catastrophically.
There’s a better – more solid, more consistent – way. It consists of following the three steps: pre-investigation, investigation, and resolution, and communicating about findings and making recommendations and decisions at each step.
(We list them backward, because R.I.P. makes for a better acronym than P.I.R. ????)
P = Pre-Investigation
Pre-investigation is setting the scene by reproducing the issue in an accessible development environment.
This is, perhaps, the least understood and most abused and neglected step in the issue resolution process.
Some might think that having access to a development environment for working an issue would be a no-brainer, but it’s more “complicated” than that. Not everyone responsible for issue resolution within a client organization has the knowledge nor access needed to appropriately reproduce an issue. Sometimes they haven’t actually seen the issue in action themselves. Without setting that scene first themselves or delegating the issue to someone that can, there is no way to effectively pass it off to the support organization.
Say, for example, that an analyst reports an issue that only happens in the live production environment. If the support person were to respond with “OK, then let’s start debugging in that environment,” the client may want to do this:
Because this is what their boss would want to do to them for messing with real people’s data:
But in order to appropriately address an issue, it must be reproducible in a safe environment, otherwise there is no way to test and know whether the issue has actually been resolved. (Remember the temptation to jump straight from symptom to treatment?)
Many issues, when pre-investigated properly, die at this step for reasons such as inability to
- Reproduce the issue in an environment available for debugging:
“It only happens in the live production environment.”
- Reproduce the issue at all:
“It happened once [under these obscure / undefined circumstances] and we haven’t seen it since.”
- Agree on what the actual issue is:
“Jane says that it happens only with full-time employee info, but I swear that I’ve seen it happen with volunteers, part-timers, and temp workers as well.”
If an issue is environmental or points to a faulty business process, then it is unlikely that the support personnel will be able do anything about it anyway (outside of making suggestions) because they lack proper access, tools, or authority to make decisions about business process changes.
“Access” doesn’t have to mean that the support person can get into an environment unaided. It may be as simple as a screenshare, with someone on-site reproducing the issue and making any code changes themselves, guided by the support person.
It can be especially tricky for the support person to try to provide an estimate before pre-investigation is done, because they are still far removed from even the symptoms of the issue, let alone an understanding of the actual issue obtained through investigation (the next step). Guessing at this point can create false expectations — the kind of expectations that can cause serious misunderstandings.
This part can be frustrating for the analyst, as they want to know what they’re getting themselves into, but without proper pre-investigation and investigation, resolution time cannot possibly be known. It could be a 40-hour issue or a 40-minute issue.
Because of that, the more pre-investigation that analysts can do for themselves, the better. It can save time and money, and the analyst is typically the best person equipped to do complete pre-investigation anyway.
If the support person helps with pre-investigation, their involvement and time commitments should be understood ahead of time, as there is a risk of the analyst feeling that their issue isn’t being addressed.
In a way, they’re right. Though pre-investigation is necessary, it is still a precursor to actual investigation and resolution. That’s why it’s called pre-investigation.
Pre-investigation is 75% of the battle. Without it, there can be no investigation.
Communication at the end of the pre-investigation step consists mainly of a hand-off of knowledge and access needed for investigation.
I = Investigation
Investigation simply consists of discovering and identifying the problem.
Of course, the methods and means for this vary from problem to problem, product to product, user to user, etc. But the outcome should always be the same:
Identify what the actual problem is.
Often, when the problem is defined and clarified, the resolution becomes obvious.
For example, a problem may be as simple as switching a greater-than (>) symbol to a less-than (<) symbol within a formula.
If the problem is more complex, however, then effective communication becomes imperative before moving to resolution. Different solutions have different consequences, so it is important for the analyst to make decisions about how to proceed.
If substantial testing has been done in a particular area, for example, a less clean and less impactful solution may be desirable to minimize retesting. Conversely, if a particular area is known to be problematic, a redesign of that area of the solution may be desirable. It’s the application owner’s call, but support personnel should make reasonable suggestions for resolution after investigating.
Estimates after a proper investigation will likely be more accurate and relevant than they are during or before investigation (especially during or before pre-investigation).
Investigation may only be 20% of the overall issue resolution process, but when it results in a proper diagnosis, it greatly reduces the amount of resources needed for actual resolution of the issue.
R = Resolution
After the needed pre-investigation and investigation with their respective communications and decisions, resolution is typically straight forward. It may make up only 5% of the overall support process, dependent upon the extent of the resolution option adopted.
In summary, all three steps of the support process, pre-investigation (stage setting), investigation (troubleshooting), and resolution (implementation) require proper attention. Transfer of knowledge and communication about options should mark each transition point. The more pre-investigation that an analyst can do for themselves, the better. Estimation accuracy of the time for resolution directly reflects where the issue is in the process.
When the three parts of the support process are given their due attention, they can result in the following:
while avoiding the following:
Here’s to long, healthy support organization / application owner relationships. Happy issue resolving!
