MOM Template for ITIL Problem Review

ITIL MOM for Major Problems Review

After multiple incidents were reported to the service desk and a problem was recognized, the ITIL methodology recommends to convene a MOM meeting in order to review the problem and make recommendations on how to resolve it. During the ITIL MOM meeting similar problems which occurred in the past are reviewed, in hope of using the same (or similar) solution to resolve the current problem by using MOM Template.

[the_ad id=”667″]

ITIL MoM Template for Major Problem Review
MoM Template for ITIL Problem Review

The MoM (Minutes of Meeting) template records the following issues and details –

  • The major problem which was discussed during the meeting
  • The location of the meeting
  • Who recorded the minutes, and who was the organizer (chair) of the meeting
  • Basic details: Date, Start Hour and Duration of the meeting
  • The participants of the meeting, with the following information regarding each participant
    • Name
    • Title
    • Means of communication (E-Mail, Phone, etc.). This is optional
  • The agenda of the meeting, with the following information –
    • Start and finish hour of each topic
    • The topic which will be discussed
    • Who will present the topic
  • The action items which were decided upon in the meeting. These usually appear in the form of a table, and include the following columns –
    • Number of the action item. Usually a simple running number list
    • The action item itself. This is the main column of the table, and should explain in detail exactly what needs to be done in order to solve the problem (or a part of it)
    • Owner: Lists who is responsible for performing the action item. This may require more than one person, but shouldn’t list more than one. In this case, the one owner is accountable for the action item being completed. The owner may appear in name, or by role
    • Due Date: Presents when the owner of the action item needs to complete it
    • Comments: This column may be filled in during the meeting, or before the next one in which it will be reviewed

How It Fits Into the ITIL Methodology

In order for the organization to be as efficient as can be, each problem should be reviewed before its solution is authorized. This review should include past solutions to similar problems, and brainstorming the recommended solution. Meeting in small groups can achieve this goal, and the result of each meeting should be clear action items written in a MoM. The service desk should always have a recommendation on how to solve the problem, and this should serve as an agenda for the meeting. Of course the recommendation doesn’t necessarily have to be approved.

Best Practices for MOM

  1. The MoM should be displayed to all the participants during the meeting, so that the action items are visible to all.
    [the_ad id=”667″]
  2. Any presentations or other relevant material should be distributed to the participants in advance of the meeting
  3. The group should be made of many different roles, in order to refrain from group thinking, and to force the members to explain themselves in simple language.

Download MOM Template for ITIL Major Problem Review

You may be also interested in MOM PPT Format and Outlook Format Templates

MoM Change Advisory Board Template

What is Change Advisory Board in ITIL?

The ITIL methodology aims at performing any and all changes according to a set of processes and methodologies, and the ITIL CAB (Change Advisory Board) board goal is to facilitate the changes by assessing the change requests and prioritizing the approved ones.

[the_ad id=”667″]

Change Advisory Board,Change Advisory Board Template
Change Advisory Board Template

Change Advisory Board Members

The CAB should be made up of professionals from both the IT and the business side of the organization, in order to ensure that the IT services are aligned with the business needs. This also aims at ensuring that the proposed change doesn’t overlook any requirements of other groups in the organization (accounting, HR, etc.). In order to achieve this, the change advisory board members should be made up of employees from different sections/divisions of the organization.

Change Advisory Board Template

[the_ad id=”667″]

The MoM (Minutes of Meeting) change advisory board template of a CAB meeting captures the following information –

  1. At the top of the page is the company logo, and its name
  2. The first section includes the basic details of the meeting –
    1. When the meeting was held (date and time)
    2. Where it was held (physical location and any other means of video / audio conferencing)
    3. When the MoM was sent out (by the recorder)
    4. What the goal of the meeting was
  3. The next section is the list of participants, where each participant is recognized by their name, role and any other comment. For example: the chair of the meeting, the fact that they participated via video conferencing, etc.
  4. The agenda of the meeting appears next, where each topic has a specified timeframe and presenter
  5. The last and most important section of the MoM is the action items table. In this table all of the action items are recorded and assigned to various employees (not only the ones who participated in the meeting). The table includes the following information –

Number of the action item (In an ABC format). Usually a simple running number list

The action item itself. This is the main column of the table, and should explain in detail exactly what needs to be done in order to solve the problem (or a part of it)

Due Date: Presents when the owner of the action item needs to complete it

Owner: Lists who is responsible for performing the action item. This may require more than one person, but shouldn’t list more than one. In this case, the one owner is accountable for the action item being completed. The owner may appear in name, or by role.

Comments: This column may be filled in during the meeting, or before the next one in which it will be reviewed

Change Advisory Board Best Practices

The MoM should be displayed to all the participants during the meeting so that the action items are visible to all. Any presentations or other relevant material should be distributed to the participants in advance of the meeting.

Download ITIL MOM Change Advisory Board Template

Problem Record Template

What is a Problem Record?

[the_ad id=”667″]

Problem record template records a separate problem which the service desk encountered, and lists the detailed information related to it. The structure of the template is similar to a problem management flowchart, where the left side contains all of the information gathered regarding the problem and the right side presents all of the corrective actions which were taken in order to resolve the problem. At the top of the template (in the most prominent area) the problem itself appears, and this allows the readers of the record to understand exactly what the problem was.

[the_ad id=”667″]

Problem Record, Problem Record Template
Problem Record Template

The left side presents the following problem detail (from top to bottom) –

  • Record Date: When the record was written by the service desk.
  • Recorded by: Who wrote the record, and what their role in the organization is.
  • Problem Date: When the problem was reported to the service desk.
  • Duration: How long the problem lasted since it was first reported to the service desk, until it was resolved by them.
  • Priority: This helps the service desk decide which problem to try and solve first. There are usually three possible attributes: Low, Medium and High (some organizations add the fourth “Critical” attribute). Since everyone who reported a problem want theirs to be resolved first, this section is very sensitive issue. Most organizations only allow their senior service desk employees to set this attribute in the record.
  • Category: This section contains the tags of the problem, which help in future searches. This should be filled in with thought and attention, since it will aid in avoiding similar future problems.
  • Description: This section is usually the largest in the left side details. It allows the service desk to outline in a simple and professional language how the problem was reported, analyzed and how the solution was reached.

The right side presents the how the problem was resolved after the diagnosis was reached, and what (if any) future actions will be taken as a result of the problem. The following problem details appear (from top to bottom) –

  • Corrective Actions: How the service desk corrected the problem, how long it took them to do so and what the result was.
  • Lesson(s) Learned: What changed in the organization as a result of the problem, and when this change should take place. Usually this is a periodical solution.
  • Authorization: Since most changes require some sort of funding, the added cost needs to be authorized by a stakeholder within the organization. This section shows who authorized the solution, what their role is, and what the financial implications are on the organization (sometimes this is $0).

How It Fits Into the ITIL Methodology

Recording the details of the root cause of a problem, and how it was solved aids the organization in aligning the IT services with the business requirements. The record can also be used to explain the need in certain monetary decisions, and helps the managers in preparing their yearly fund requests.

Download Problem Record Template

Major Problem Report Template

Incident vs Problem

Many organizations struggle to differ between problems and incidents, and the ITIL methodology aims at clarifying the difference between the two Incident vs Problem: A problem refers to the unknown cause of one or more incidents. To use a simple analogy: If a problem is like a disease, then the incidents are the symptoms.

[the_ad id=”667″]

Major Problem Report Template
Major Problem Report Template

8 Steps to Resolve an ITIL Problem

[the_ad id=”667″]

Whenever the service desk encounters a major problem within its systems, there are eight steps which it needs to perform in order to resolve the problem –

Detection 

The first step is to identify the root cause of the problem, and not just the lone incident which is only a symptom of the problem. This requires identifying incidents throughout the organization, either proactively or by receiving multiple service requests.

Recording

Since a service desk usually has more than one employee, it is important to share all the incidents. This will help in identifying the root cause of the problem, and will serve as a log for lessons learned and future improvements.

Categorizing

Since each user fills in a service request a bit differently, it is important to categorize them as they come in. This will help in modeling the incidents, which will allow the service desk to collate as many incidents into one major problem and solve it. It is possible to have more than one category. For example: Main category is “Communication”, whilst the secondary one is “Desk Phone”.

Prioritizing

Once all the requests are recorded and categorized, it is important to prioritize them in order of urgency and importance. Ideally the more important ones will be solved first, although most organizations solve the urgent ones first.

Diagnosing

Now comes the hardest part, figuring out what the problem is and deciding on how to solve it. This step of course requires the most amount of time, and it shouldn’t be rushed. Once the problem has been diagnosed and the root problem is detected, the service desk needs to suggest the best solution for rooting out the problem.

Workaround

If the suggestion in the previous step was approved, now the team needs to implement the solution across the organization. This step requires the whole team to understand the problem, the solution and to implement it in the same manner.

Documentation

After the problem has been solved, documenting the entire process (from stet #1 to #6) will assist in resolving future issues. This should be done in a set template, which will help in familiarizing the team with the process.

Lessons Learned

The final step is more often than not skipped, since most of the service desk employees don’t see an immediate benefit in doing so. This task usually falls on the team lead of the service desk, and is very important for the organization to grow and learn from its mistakes.

How it fits into the ITIL methodology

This process is crucial for the long-term success of the organization, and is the core foundation of a robust service desk entity. The problem resolving collates many different incident reports, and is internal as well as external facing.

Download Major Problem Report Template

Service Request Form Template

Service Request Form

In order for a user to officially request something, be it a simple password change or a more difficult software installation, they need to submit a service request form to the service desk of the organization. The ITIL describes a request as a “standard change” which requires the service desk to follow a simple procedure to create service request form template and is a low-risk change.




Service Request Form Template, ITIL Service Request Form Template
Service Request Form Template – ITIL

ITIL Service Request Goals

The four goals of the ITIL Service Request form are –

  • Outline to the users which services are available, how to request any one of them and what the standard duration is to fulfill these requests
  • To create a clear and simple procedure for handling any type of request
  • Detail which approvals a user needs for each type of request. For example who needs to approve installing new software, procuring a license, etc.
  • Grant a platform for general requests, comments and tips for improvement

ITIL Service Delivery – 5 Steps

The process of resolving a submitted form should be straightforward, and usually is made up of the following five steps –

Open a request

This is done by a user, and there is no place for pro activity here.

Assign 

This can be done automatically by a simple load balancing system, which spreads the requests amongst the service desk employees. Once a request is assigned, the responsible party will see the request through to fruition.

Resolving the request 

This step is the most important one of the process, and is where the service desk shows its value to the organization. The service desk must follow a procedure for fulfilling the request, and if one doesn’t exist then an escalation should be used. In this case the supervisor of the service desk needs to weigh in, and decide on how to continue from here.

Complete the request 

Once the procedure has been fulfilled, the service desk needs to validate that the solution is acceptable with the requester. If it is then continue to the next step, if not then go back to the previous step.

Close the request 

This is the official closure of the request, and is important for evaluating the timeline of the resolution to make sure that no SLA’s (Service Level Agreement) were breached.

Service Desk Best Practices

  • KIS (Keep it Simple): Try and make it as easy as possible for the employees of the organization to request anything that will make their lives easier and allow them to be more productive.
  • Clearly communicate the SLA’s (Service Level Agreement): This will lower the communication between the requestor and the service desk to a minimum, allowing both sides to focus on more important things.
  • Request feedback: Ask the requestors for feedback after their request was fulfilled, this will result in continuous improvement of the service desk.
  • Document the requests: Make sure that the service desk professionals don’t feel the need to invent the wheel every time they receive a new request.

Download Service Request Form Template- Excel

What is Incident Management?

ITIL Incident Management

Incident Management in ITIL is the key process in Service Operation.  Most Service Providers are evaluated and assessed by the speed they respond and restore service after an Incident has occurred.  By definition, an Incident is an unplanned interruption to an IT service or reduction in quality of an IT service. 

[the_ad id=”667″]

ITIL Incident Management, Incident Management
Incident Management

It may also be the failure of a Configuration item (CI) that has not yet impacted service.  The simple explanation is an Incident is an unplanned disruption, or impending disruption, to an IT service.  If disk space is filling up quickly and the service CI will be out of space in three hours, it is an Incident.  If the network quality is degraded, it is an Incident.  Incidents include disruptions reported by users (either via calls to the Service Desk or imputed into the ITSM tool), by technical staff, or automatically detected and reported by event monitoring tools.

The concept of Incidents disrupting a service is one most people are familiar.  Think of your household phone or internet service.  When you moved into your residence and signed up for service, your considered the service worth the price.  If there is a disruption in the service, it is painful to the customer and the goal should be quick resolution.  The customer does not want hours – or even days – without phone and internet.  Even if the customer is rebated for the outage, it still leaves a scar on the relationship.  This is the same with the customer of an IT service.  They want as few Incidents as possible, lasting the shortest amount of time as possible.  The customer is paying for a service and wants it available when needed.  The business customers who are paying for the IT service do not care about the cause of the disruption, just service restored as quickly as possible and the issue to not arise again.

How can you measure and report incidents?

[the_ad id=”667″]

As Incidents are reported, the Incident Management process seeks to understand the impact and urgency of the Incident on order to act accordingly.  The combination of Impact and Urgency is called Priority.

  • Impact is the measure of the effect of the Incident, Problem, Change, or other ITSM record. Impact is usually measured on the impact to service levels.
  • Urgency is the length of time until the Incident, Problem or Change has a significant impact on the IT service. This is how quickly the Service Provider needs to act to resolve on behalf of the business customer.
  • Priority is a way to identify the relative importance of an Incident, Problem, or Change. Priority allows a common understanding to offer relative importance of Incidents and Problems.

Most organizations utilize a Priority Matrix that is a 3-by-3 or 4-by-4 scale.  For example, high impact and high urgency would result in a Priority 1 Incident.  Additionally, a low impact and low urgency Incident would be the lowest Priority (some organizations call this Priority 4 or Priority 5).

Most Service Providers, both internal and external, use this matrix to determine the response and closure times for service levels.  These service levels are agreed upon and documented to form a Service Level Agreement (SLA) or Operating Level Agreement (OLA).

Users do not care the nature or the cause of the Incident, just how soon it can be resolved.  Problem Management will investigate root cause.  Most organizations keep volume metrics like number of Incidents broken down by Service Provider.  Many track service metrics suck as Mean Time to Restore Service (MTTRS) and Mean Time Between Service Interruptions (MTBSI).  The service metrics are great when reviewing service availability with the business customer.

Advanced process metrics will include a view into the maturity of the Incident Management process.  This includes the percentage of Incidents logged, categorized, and prioritized correctly, each with a separate metric tracked per Service Provider.  The Service Desk will be measured on first-call resolution, broken down per Service Desk agent.

Other metrics for measuring incidents

  • Average cost of handling an incident, broken down by Service Provider and Priority.
  • Incident Reopen Rate measuring if an Incident is closed prematurely as a wider-spread issue was unknown at the time.
  • Number of Incidents per service
  • Number of Incidents resolved within agreed SLAs or OLAs
  • Number of times SLA or OLA target times exceeded for Incident resolution

Incident Management is the process that determines how business customers view the performance of the service and the Service Provider.  The performance against the SLAs and OLAs will determine how the Service Provider is viewed by the business customer.

Major Problem Catalogue Template

ITIL Problem Management – Catalogue Template

Those who don’t learn from their mistakes are destined to repeat them: All organizations aim at learning from their mistakes, and hope to refrain from repeating them. The ITIL problem management template catalogues all of the problems which the service desk encountered over the years, and records the following –

[the_ad id=”667″]

ITIL Problem Management, ITIL Problem Catalogue Template
ITIL Problem Catalogue Template

The Problem

A problem is an unknown cause of multiple incidents, which stem from the same root cause. Solving a problem includes understanding said cause, and resolving it in a manner which resolves all of the incidents which stemmed from the problem. To use a simple analogy: If an incident is like a symptom, than a problem is like a disease. The problem needs to be written in a clear and simple language, which explains it in laymen terms.

Basic Details

The goal of this section is to list all the employees who raised an incident which stemmed from the problem, and when they reported it. This will help in analysing the time when the problem first appeared. The more incidents reported, the easier it will be to diagnose the problem. Hence it is recommended to repeat similar incidents in the catalogue.

Symptoms

This part of the catalogue explains in detail what the employee encountered when trying to access or use any information system in the organization. All of the incidents (symptoms) need to be listed here, since the symptom list will help the service desk identify the problem and decide on the required corrective actions. This part is like a doctor who tries to identify the disease according to the list of symptoms detailed by their patients.

Corrective Action Taken

After the problem was diagnosed, the problem needs to be resolved. The corrective actions taken are what the service desk decided to do in order to achieve this. The goal of this section is to assist the service desk in resolving similar problems in the future. In case a false root cause was thought to be the problem, this should also appear here, in order to rule it out in future cases.

Problem Category

Like tagging in social media, this section will help in search queries in order to easily find similar symptoms for future problems. The more tags, the easier it will be to locate it.

How It Fits Into the ITIL Methodology

The main goal of the methodology is to allow the organization to focus on improving its business results, while aligning the IT services with this goal. The report catalogue should be used as a DB (data base) for the service desk to diagnose problems which impede this goal, and thus allow the business to focus on improving their results over time.

Basic Catalogue Details

[the_ad id=”667″]

At the top of the catalogue there is a short section which needs to filled in after each addition to the catalogue. This includes the following information–

  • Date of the last time a problem was added to the report.
  • Who added the problem (updated the catalogue).
  • What their role is in the service desk.
  • Which team the belong to (either shift or professional alliance).

Download ITIL Problem Catalogue Template

 

Incident Report Template | Major Incident Management

Incident Report in ITIL Incident Management

Incident reporting is one of most important phase in Major Incident Management. Incident report is an authentic and authorized information written in Incident Report Template, explaining the complete details of an incident like what is the incident about, when did the incident occur, where did the incident occur, what is the time taken to resolve the incident, who resolved the incident, who all have handled the incident (how many functional and horizontal escalations have happened), what troubleshooting steps were taken to resolve the issue, and what customer satisfaction score was received on resolving the incident.

[the_ad id=”667″]

Incident report template word, Incident report template, Major Incident Management
Major Incident Report Template in ITIL

Why do you need a Incident Report ?

An incident report provides accurate and consolidated summary on an incident to the requester and higher-level management and to help the management, to make quick and wise decisions with the reports provided.  Also, to record the information regarding the incident and lessons learnt. This incident report information will be useful for bringing awareness to the management and it improves (effectiveness & efficiency) the IT incident management operations.

How to use the Incident Report Template

[the_ad id=”667″]

  • Report by label should have the details of the person/ persons who prepared the report
  • Report Date label should mention when the report was created
  • Incident number label should mention the unique ID assigned by ITSM tool/ Service Desk tool
  • Major incident label should mention the values “Yes/ No”, referring if the incident is major incident or not.
  • SLA Breached label should mention the values “Yes/ No”, referring if the incident breached the SLA or not.
  • Need for exculpation label should mention the values “Yes/ No”, referring if the incident ticket has a valid reason for exculpation.
  • Reason for exculpation label should describe the detailed reason explaining why the incident ticket should be exculpated.
  • Bridge call initiated label should mention the values “Yes/ No”, referring if the incident needed a bridge call to resolve the issue or not.
  • Stakeholders involved in bridge call label should mention the details of the stakeholders SME name, Position, Contact number and contact email.
  • Incident start time label should mention the time when the incident started
  • Incident end time label should mention the time when the incident ended
  • Business Services Impacted label should mention the impacted business services
  • Affected configuration items label should have the details of the CI’s that have got affected.
  • Caller details label should be populated with caller/ user details like user or employee name and number
  • Date and time when the incident was reported by the user label should be populated with date and time when the incident was reported by the user
  • Location label should mention the sites and locations which were affected by the incident
  • Category and subcategory label should mention the category and subcategory of the incident as segregated in the process and tool.
  • Problem number label should be mentioned with problem ticket number associated with the incident
  • Change number label should be mentioned with change ticket number associated with the incident
  • Priority of the incident label should be mention with the overall priority of the incident, which is generally calculated on the basis of impact and urgency
  • Impact label should mention the assigned impact
  • Urgency label should mention the assigned urgency
  • Executive summary label should mention the brief overview of the incident in one line or few words
  • Description of the incident label should mention the detailed description of the incident
  • Timeline label should have the precise time details like incident inception, notification, recording in tool, etc.
  • Number of hours label should mention the total number of hours and minutes it took to service restoration
  • Chronological analysis label should mention the chronology of events/ errors that lead to incident
  • Service providers involved label should mention the different vendors involved in resolving the incident
  • Technical details label should mention the technical details of the incident like logs, errors, event numbers, Knowledge base article numbers used for resolving the issue, details of troubleshooting.
  • Post-incident analysis label should mention the analysis that is conducted after the incident resolution and closure. It should capture the details like:
  • primary, secondary and contributing causes using 5 why analysis, Ishikawa diagrams, etc.
  • what additional actions or research needs to happen
  • Recommendation for corrective actions section should capture details of the corrective action description and the action owner
  • Incident report approval section should capture the details of the service provider name, incident manager name, service delivery manager name 

Best Practices for Incident Reporting

  • Every incident report should be identified with a unique registration number.
  • Incident reports should be generated for all major and new (that have never occurred before) incidents.
  • Create the incident report for every major incident, for every new incident, for incidents that have breached/ escalated/ filed complaint by the customer.
  • Don’t fill the report based on assumptions
  • Include only relevant details
  • Incident manager should not be engaged only as an escalation point or for escalations. It is a very common bad practice in organizations that incident managers are only used as escalation points, for managing escalations, or for doing follow ups. Incident managers should also be involved in diagnosis and resolution which will enable the team to provide quicker solutions.
  • Management should conduct meetings to discuss the what went good and bad, after the incident report is reviewed.

Download Incident Report Excel Template

Download Incident Report Word Template