Whether you're working in maintenance, in testing or in support, as an IT consul tant you will often need to analyse errors.

Here's a few things to keep in mind regarding error analysis that I've learned from my own experience: I)What is the priority? When an error occurs, the first thing you have to estabilish is it's priority. S ince most of the time there are lots of errors waiting to be analysed and you ca n't do it all at the same time, you have to estabilish an order in which you sol ve them. When making this decision you have to take into consideration the follo wing factors: 1) The environment - If the error occurs in the Production environment for examp le then it must be treated before an error that occurs in one of the testing env ironments. That is because the enterprise loses money for everything that does n ot go right in the Production environment. Technically every problem was suppose d to be fixed by the time it got past the testing environments. 2) The severity - When you find an error, you must weigh the impact it has on th e system as a whole. If for instance every other part of the system depends on t he solving of that one error then it must be treated as soon as possible, and yo u should leave whatever you were already working on for another time. 3)The complexity - If you find that solving an error thoroughly will take too mu ch time, sometimes it is better to find a workaround to patch things up temporar ily, and deal with the problem later when all of the urgent stuff is out of the way. II)What is the overall situation? If you encounter an error, you have to make sure that you are first aware of the overall situation in order to avoid wasting precious time on something that cou ld have been obvious from the very beginning. Sometimes a problem cannot be fixe d, for the simple reason that the error that caused it is still in the process o f being fixed. For example, you can't run a process, no matter how hard you try if the server is down. Taking a bit of time to make a list of all the problems a nd their consequences may save you a lot of time in the long run. III)How far do you have to analyse? The second thing you have to keep in mind when you start analysing an error is h ow far you are in fact supposed to analyse by yourself, and when it is time to g ive your analysis to someone more specialised. If you manage to find the exact c ause of the problem, but you have to understand the code to be able to provide a solution, you might be tempted to read the code for yourself if you've done cod ing in that language before. If your job is only to identify the cause of the er ror however, it is not a good idea to start reading the actual code, not because you won't find the solution eventually, but because there are other people who actually worked with those scripts and will reach a conclusion much faster. IV)Will the problem repeat itself? When we solve an error we are often tempted to find an immediate fix to the prob lem and not investigate further. Even if investigating the actual cause of an er ror is most of the time lowest on the priority list when a temporary fix has alr eady been found, you must not forget that there is a possibility the problem wil l arise again in the future unless you find out the true root of it's cause. V) What were the steps of the investigation?

Even if the cause and the solution to the error you've encountered may seem easy to understand to you after hours spent with the investigation, there will most likely be other people you will need to report your results to, that did not spe nd any time whatsoever in analysing that specific error. It is very important to see all of the steps undergone to reach your conclusion clearly in your head, s o that you can explain the hours long process of analysing the error in a matter of minutes.