Is it Plugged in?

There is no single solution for a technical services/operations group. Like most professional disciplines, there are basic fundamentals which in turn can be adapted to a particular situation. Unfortunately, there is an inconsistency in how (and if) these fundamentals are taught to technical staff. More often than not, it is the technical persons' own personality and initiative that determines their technical proficiency level. This makes it very hard for organizations to measure performance when evaluating or hiring new staff.

These core fundamentals are the basis for any technical professional to have although the implementation of theses will be different based on a persons skill and experience level. They do however provide the basis for where to start and what the key points in the methodology.

Fundementals:
o Know the system/environment that you are working in
o Identify and document the problems/symptoms (when possible distinguish between a problem and symptom) as they are reported
o Stop and think
o Identify what changes have made recently (there are always changes made - weather they are known or not)
o Look for obvious alerts and/or errors that may indicate the problem
o logs, alert messages, signals, external system failures, etc
o Identify/isolate the system(s) involved and each of their components
o Identify the process flow for the system(s) as it should occur
o Map the problem/symptom to the ‘working’ process flow to narrow down the point of failure
o Test each component of the system in the failure area, in the proper order of the process flow, to identify where the failure occurs
o utilize common tools or ‘specialized features’ of the system to test each step in the process flow
o Test the failed component/process to verify and identify the actual problem
o identify the input and compare the actual output verses expected output
o Once the problem is identified, develop a solution. This may include the following:
o Adjustment to the process or inputs
o Replacement of a failed component
o Putting a temporary workaround in place until a solution can be provided
o Test and verify the solution has resolved the problem
o Document the procedures to identify the problem, fix it, and verify the solution (so this procedure can be used again)


What happens without the fundamentals:
o Bias assumptions are made not based on facts
o Inadequate or limited knowledge of the system/process results in false conclusions (Treating symptoms as problems – miss-diagnosis or failure to resolve the true problem)
o Not fully utilizing tools and resources at hand to properly identify and resolve the issue and thus missing obvious indicators of the problem
o No documentation to support the identification/solution/fix to an issue (Unable to or accurately identify the same issue at a later date)
o Longer time to resolution (problem keeps coming back)
o Frustration on part of the technician/customer/management, etc
o Confidence and motivational drain on staff and customers (results in many false-positive solutions e.g. this might work)
o Lack of clear ownership and responsibility to the issue
o Technical Staff Under pressure to produce results quickly (Time/pressure limitations) thus rush and implement an inferior solution or fix


What happens with the fundamentals:
o Separates problems from symptoms
o Consistency in delivery (same or better procedure is used if the problem occurs again)
o Shorter time to resolution (fix it right the first time)
o Could result in a better re-design/implementation of the process/system
o Maintain/build customer trust and confidence
o Strengthens the personal and professional development of the technical staff/team as well as partner/vendor relationships


It is natural to look for the 'quick fix' to problems, but they will typically result in repeat problems and reduced customer confidence and satisfaction. Do your work upfront and you will save in the long run.