The aspect of my job that I enjoy the most is troubleshooting. Every project and every deployment will have something that needs troubleshooting eventually and I always try to be the first one in line for the job. Functional design, developing, training are all areas of my job that I enjoy - but troubleshooting is easily at the top of the list.

During the course of this week I began to really ponder what it is about troubleshooting issues that is so appealing to me. I've come to the conclusion that for me, there are two rewards for tracking down an issue. First is the aspect of meeting a need, secondly and most importantly is the experience that I have gained in the process. This experience is one of the most valuable tools that I have for solving the next issue that is sent to my queue.

The problem with experience is that it is limited to the involved individuals. This is an obvious statement, but the inverse should also be considered. Each member of a team is limited by their own experience when it comes to problem solving. This limitation is most apparent during troubleshooting in a high stress situation.

What if you were not limited by your own experience? When working on a team, it is possible to discuss the issue you are troubleshooting with team members to try and utilize their experience but this requires explaining all of the circumstances, and listing failed attempts. This process could be lengthy and occupies each resource pulled in to consult on the issue.

Alternate solutions include developing a knowledge base, and creating how to documents. These solutions provide some level of disseminating information; however they can often be to formal or problem specific to be useful with troubleshooting an issue that has not yet been encountered.

What I would like to propose is the compilation of personal experience on a regular basis by all team members actively involved on a project. This process should be frequent enough that most experiences gained are captured, but not so frequently that it taxes the timeline of the project. These entries may include items such as the following:

· Anything new learned in the development process while developing a solution to a functional requirement.
· A discovered feature in an application used by all team members.
· A particular system reaction based upon a repeatable series of events. Sometimes just knowing that someone else has encountered the same system reaction can help with the beginning of the investigation.
· How a problem was discovered and solved. Not necessarily what the problem was and what the solution was, but what was the discovery path. This will allow problems that are similar and not identical to still be built from the same experience.
· Diagnostic steps that the developer uses to troubleshoot the code they are developing during development.
· All useful knowledge sources that were used for development or during troubleshooting.

As this information is slowly gathered, members of the team will begin to check this growing repository of experience before they search out a solution for their current problem. This will enable the team to benefit from the gained experience of the group and provide new members of the team with an additional resource beyond the existing formal documentation.