We got in to a “lively debate” at the office on the subject of when an incident requires a problem log.  When dealing with an incident what prompts the Service Desk analyst to create a problem log? We all agreed that problems should be initiated if there are several incidents raised for the same issue, or if there is one incident with a major business impact.

ITIL states that a problem is identified when “matching the process to existing Problems and Known Errors is not successful during the stage of Incident initial support and classification” this is when the debate started.

One side of the office (with me in it) felt that in the real world for the majority of real life problem teams this might create an administrative nightmare, with a high percent of incidents becoming problems.  Even in a mature system if you had a large number of different incidents occurring, you would always see a large percent of incidents creating a problem. This would surely take the focus away from resolving the underlying causes of incidents to building up a document repository.  In teams where Problem management is only one of their roles, the time they do give to problem management should be dealing with problems that are causing the business most pain.

Also if Service Desk operators are aware of a resolution why shouldn’t they be able to implement it straight away even if a known error log isn’t created – it isn’t always necessary to have all resolutions documented.

However, the opposing faction of the office believed this was the only way to ensure a consistent approach to incidents by Service Desk operators.  Flagging every incident that didn’t have a known error log would ensure that one was created and documented correctly.  Only by doing this would all operators give a uniformed response on the same incidents.  What's more without this in place Service Desk operators could perform fix’s that hadn’t been approved, leading to no accountability. With highly skilled Service Desk operators investigation would be performed by the operator: they would take the incident and check for a workaround, if none existed they would troubleshoot and investigate the issue and then create a problem/known error record.  If they were non-technical operators, you would not want them implementing any solutions that had not been technically signed off.

So the outcome of the debate? We decided that it depends on what the company’s objectives are for problem management, if they want a highly consistent approach to incidents and want a fully populated known error log authorised by qualified technicians then the process needs to be followed to the word.  However if they want to focus on solving underlying causes of only the incidents causing the most pain then they should agree what conditions an incident would trigger a problem, and what is considered a normal or standard incident which does not require problem management.