Effort, Impact, Risks, Workarounds

OK, your analysis is complete. Depending on your IT departmental procedures, you may be required to provide an effort and impact estimate of your proposed resolutions. Many times there will be multiple possible resolutions, with some being more or less desirable than others based on many factors. (Providing more than one possible resolution can sometimes help reinforce your position on recommending a particular one.) If your primary resolution is not just a cut-and-dried simple program change, then it may be a good idea to create an effort/impact document regardless of whether or not it is a requirement of your shop. In this document, list each possible resolution, along with all programs/processes/database/objects/files/whatever that require modification. Provide an estimate of the effort involved in each segment of the resolution. This effort estimate should include time for coding, creation and execution of test scripts, possible rework based on testing results, documentation, implementation, and possible post-implementation support and training. Overall impact to the entire system must also be documented, broken down by each individual proposed change (i.e., if you propose modifying five programs, what is the impact of changing each of those five programs to other system components?). List any and all known risks associated with each resolution. Risk assessment is another area that can prove challenging. I've heard risk defined as a combination of uncertainty and constraint. Risks applying to software application changes can include, but are certainly not limited to: time constraints, manpower constraints, cost constraints, or uncertainty that impact has been completely identified.

If your resolution has a large impact, there may be reasons that management won't want to forge ahead with it immediately. You could be at a critical point in the SDLC, perhaps attempting to baseline your application. In any event, it may be necessary for a workaround to be identified. Ideally, a workaround is a way that end users can avoid a known error condition by performing different steps or performing steps in a different order. If the error condition in question introduces "bad" data into your system, then you'd better have your "fix-it" script at the ready. Because invariably, no matter how good their intentions, your users will forget to follow the workaround steps and again encounter the error conditions. This is why a workaround should only be considered a temporary fix, and not remain in place for too long a period of time.

What It Means

Effective troubleshooting is one of the most key skills in the IT world, yet sadly many support personnel remain inadequate in this area. It can definitely minimize your turnaround time on issue resolutions, and help retain user confidence in your application and support staff. Given the proper amount of time, technique and information, virtually any error condition can be identified and resolved.

Dennis Jones is an IT professional working in the industry since 1989. He has served in many capacities from help desk and technical support, developer, DBA and technical manager. He is available for onsite consultation or speaking engagements.