Securing knowledge transfer

[Burki]

Hi everybody!

In Incident and Problem Management work arounds are developed by support groups and SHOULD - according to ITIL - be made available to SD staff. When incidents occur, the SD staff searches the knowledge DB for work arounds, finds the work around and solves the incident.

Now let's suppose we have people that don't like writing detailed solutions on how to fix an incident. When an incident is assigned to them, they just solve it and write "It works again" in the incident record.

How do you make people write better descriptions on how they solved their incidents and what steps other people have to take in order to do the same??

Thanks in advance for your advice!

BR,
Burki

[Marcel]

First, approach the support groups as a whole and emphasize and explain the importance of complete, accurate, and understandable tickets. Make clear what your expectations are regarding the tickets. What things should be addressed? What level of detail is required? And most of all: why should we do this? (answer: to support collaboration, reuse of knowledge, and for accountability) Also, show them examples of good and bad tickets.

Then monitor your tickets for a while. Take samples. Based on your findings, approach individuals who are still doing a lousy job. Explain the whole thing to them again. Let them see what it would mean to them if they were looking for a solution and only find tickets that say 'issue fixed'.

Continue to monitor ticket quality and bring it up in job evaluations with the individual employees. Both to praise the good folks, as well as to identify the people who are still underperforming. For the latter, make sure to make clear that ticket creation will be an item for their next job evaluation as well. That way they know they're being 'watched'.

[Burki]

Hi Marcel,

thanks a lot for your reply. It helps a lot!

BR,
Burki

[fighter]

Burki,

Also please consider there would be few incidents for which the Technical Support would have provided workaround/solutions earlier. In these cases it would be of help if there is a way for your SD to relate the incident tickets with one another.

I completely agree with Marcel's solution.

This is what we are doing in our organisation and results are starting to show up..

Cheers

Vimzie

[wkstan2001]

Burki,

During our implementation of Incident & Problem mgmt in my organization, we do experience similar issue with some analyst/engineer not providing sufficient information about their finding. As a result we've introduce Kepner Tregoe methodology to all our analyst/engineer and also design a set of question that they need to answer before opening/closing the incident/problem ticket. This will help to keep value information during the root cause analyst and also provide a clear understand the root cause/solution before closing the incident/problem ticket. Hope this help you with your ITIL implementation.

[winz]

Hi Burki,

During our implementation of Incident Management, we faced a similar issue with the team members. Hence, we brought out a quality check into picture which covers every aspect - for example: documentation, priority, frequency of updating tickets, resolution, etc..

We also used to conduct weekly meetings to discuss the process violations happening.

There was a good amount of resistance from the people initially, but with proper training and making the team understand the inmportance and value of this objective - we finally achieved what we were looking for.

Hope this helps.

Cheers
winz
_________________
"Look at Frustration as a positive thing. It is the frustration that drives you to improve"