When to open Problem Ticket after incident occurred ?

General discussion on all aspects of the IT Infrastructure Library (ITIL)
Post Reply
Posts: 1
Joined: Wed Nov 11, 2020 11:07 am

Wed Nov 11, 2020 11:57 am


When should we open a problem ticket after an incident ?
1. Just after incident restored , to request for a root cause ?
2. Restore the incident, organize an incident analysis meeting to find the root cause and if it is not found , then open a problem ticket ?
3. What is the procedure with ITL ?


User avatar
Corde Wagner
Senior Itiler
Senior Itiler
Posts: 56
Joined: Fri Nov 10, 2006 7:00 pm
Location: El Dorado Hills, California

Tue Nov 17, 2020 8:36 pm


Problem investigations require the time of your most valuable people resources (technical teams and managers). Experience shows that the constraints of people and their time is the biggest factor in the organizations ability to work on or not work on problem resolution. For this reason, only allow the problem management team to make problem tickets and do not allow a problem ticket for every incident or anything someone thinks is a “problem”.

Some thoughts related to your questions:
1. Not all incidents are a problem nor will all incidents warrant a problem investigation. For example:
> incidents where the cause is known, and that cause doesn’t warrant an investigation. In other words, sometimes the cause is not known, but the impact to the business is negligible and would not warrant a problem ticket for the one incident.
> A single and low level (impact and severity) incident that a cause cannot be determined, may not warrant the time and resources required to investigate. Multiple incidents of the same symptoms, if disruptive enough, can warrant a ticket to be created and the problem team can prioritize the problem against all others.

2. I recommend that only the problem management team can create a problem record. If someone wants a problem created, they can submit a request ticket for that purpose. If the request is not valid, the problem management team can simple deny that request ticket. It’s easier than having to close an invalid problem ticket.

3. I also highly recommend that the guidelines for the problem management process be well documented and include the following as a good practice for when a problem record can/should be created:

> Notification from the service desk that they have identified a problem that the problem manager should consider.
> All major incidents (even with a identified root cause) will result in a Problem Record being created and reviewed by the problem management team. If specific criteria is met, then a root cause analysis (major problem review) can be scheduled and performed.
> All priority-2/severity-2 incidents without an identified root cause can be reviewed and scored by the Problem Management team for possible creation of a problem.
> Requests from IT Operations or business leadership to perform an investigation of identified problems.
> Notification from suppliers or vendors that a problem exists with their products or services

The ITIL v2011 Service Operation book and many other references online provide guidance on the base Problem Management procedure (work flow and activities). along with the ITIL v2011 Service Operation book, there are a number of books out there that have a lot of good information that you may want to also use as part of your learning.

I hope this helps and my apologies for the formatting of this reply. I wish the editor was more like Word. ;-)

Should you have other questions or want to know more, please let me know.

Corde Wagner
ITIL 4 Managing Professional - ITIL v3 Expert - v2 Red Badge - VeriSM-Plus - Certified Agile Service Manager
Post Reply