Table of Contents

SACM ITIL – Template.........................................................................................................................12

Known Error Record Template...........................................................................................................14
ITIL Problem Management.................................................................................................................15
ITIL v4 – Principles and Concepts........................................................................................................18
ITIL implementation............................................................................................................................19
ITIL v4 – Principles and Concepts........................................................................................................22
ITIL Service Transition.........................................................................................................................25
ITIL Event Management......................................................................................................................29
Daily Log Template.............................................................................................................................32
IT Service Level Requirements Template...........................................................................................34
Release Testing and Verification........................................................................................................38
Service Delivery Status Report Template...........................................................................................41
What is Project Management and its Importance in ITSM................................................................42
ITIL Service Delivery | Difference Between IT Service Delivery & IT Service Support.......................45
Difference between ITIL Service Support and ITIL Service Delivery...................................................46
Lists 26 ITIL Processes & 4 ITIL Functions...........................................................................................48
6 Goals of Incident Management.......................................................................................................53
Release Management Best Practices in ITIL.......................................................................................55
What is Release and Deployment Management? | Release Management Process Flow.................59
Roles and Responsibilities in Release and Deployment Management | RACI Matrix Template......64
Change Request Form | Fillable Change Request Template & Sample.............................................67
Roles and Responsibilities Template for Change Management (RACI Matrix Template)?...............71
Release Management | Agile and Scrum Release Management.......................................................74
ITIL Emergency Change | Emergency Change Management Process................................................77
Post Implementation Review Template.............................................................................................81
Operation Level Agreement...............................................................................................................83
IT Asset Management Best Practices - 10 Steps Covering ITAM Process...........................................86
What Is IT Asset Management - ITAM Benefits - Why Business need ITAM.....................................88
Service Report Template – Example and Format...............................................................................91
IT Asset Management - Asset Management Process.........................................................................94
IT Asset Management Policy | ITIL Asset Management...................................................................102
Service Catalogue Template | ITIL Service Catalog..........................................................................107
IT Service Management | ITSM vs ITIL | ITSM Tools List.................................................................110
Service Charter Template.................................................................................................................114
Service Level Agreement Template..................................................................................................116
Roles and Responsibilities in ITIL with a RACI..................................................................................119
IT Service Continuity - Plan and Template........................................................................................122
ITIL Change Management Process....................................................................................................125
ITIL Service Strategy..........................................................................................................................131
Post Implementation Review Template for Incident Closure..........................................................134
Incident Management Process.........................................................................................................137
Request for Change Template..........................................................................................................142
Incident Catalogue Template............................................................................................................144
Release Plan Template......................................................................................................................146
Incident Management Policy - Template And Procedure................................................................148
Incident Management Metrics.........................................................................................................153
Customer Complaint Log..................................................................................................................156
What is ITIL and its lifecycle?............................................................................................................158
Customer Complaint Report Template.............................................................................................162
Internal Audit Report Template.......................................................................................................165
MOM Template for ITIL Problem Review.........................................................................................167
MoM Change Advisory Board Template..........................................................................................169
Problem Record Template................................................................................................................171
Major Problem Report Template.....................................................................................................173
Service Request Form Template.......................................................................................................175
What is Incident Management?.......................................................................................................177
Major Problem Catalogue Template................................................................................................180
Incident Report Template | Major Incident Management..............................................................182
SACM ITIL – Template
Service Asset and Configuration Management plan is a high-level document which provides
guidance on the SACM activities that should be followed by the SACM team.

SACM plan is necessary for any IT organization as it prompts information to the operational
managers about the operational activities in the five phases:

 Management and planning

 Configuration identification
 Configuration control
 Status accounting and reporting
 Verification and audit

Purpose of SACM plan

 defines the streamlined procedures for managing the lifecycle of CIs.

 defines procedures for managing the CDMBs
 defines control procedures for CI identification, tracking, controlling changes, status
accounting and verifying, auditing, and reporting the CIs
 Template Name Service Asset and Configuration Management
plan
Actual File Location http://itil-docs.com/7741bb33-3aa5-482d-9eaf-
39491f7c7bed
 Known Error Record Template

Known Error Record

Known error is an error that is known to the IT infrastructure and that has occurred before,
and one that has a discovered solution (which is a work around but not a permanent fix). All
known errors are stored in a database called Known error database (KEDB).

Any record that encompasses the complete details of a known error is called known error
record.

Template Name Known Error Record Template

Actual File Location http://itil-docs.com/69d2782a-f338-4862-87c6-
8afc6ec3f7c0
 ITIL Problem Management

Problem management is the standardized process for managing problems and known errors
by identifying the root cause of the issue, discovering a work around and permanent fix.

Problem management will be performed at two stages:

 proactive problem management

 reactive problem management

Proactive problem management identifies, analyzes, and develops a resolution plan for
recurring incidents or an incident that has no solution. Proactive problem management
identifies future issues through processes like event management, incident management,
availability management, and capacity management. Proactive problem management
analyzes events, incidents, availability, and capacity designs, and identifies vulnerabilities
that can turn into problems.

Reactive problem management does the post-mortem investigation, diagnosis, and develops
resolution plan after the breakdown of services.

Objectives:

 Identify workarounds for incidents.

 Perform RCA and identify permanent fix for recurring incidents.
 Establish and maintain the KEDB.
 Act as next level escalation point for unresolved issues in incident management function.
Process Context Diagram

Sl. No. Procedure Description

1.0 Detect the need for a problem analysis Problem Management process can get a trigger
from several sources. Some of them are:

Major Incident Management:

The Problem Management process may get
triggered if a major incident happens for which
a work around and not a permanent solution is
given and therefore such a Major Incident can
occur again.

Incident Management:
The Incident Owner resolves an incident by
giving a workaround in order to restore the
service as soon as possible as per the objective
of Incident Management, and the need for a
problem analysis of the incident is detected.

Recurring incidents, Trend analysis, Pareto

analysis etc
Each resolver group may identify recurring
incidents and also identification of potential
problem areas through the conduct of periodic
Trend/Pareto analysis and other statistical
analysis with the help of the Problem Manager.
This will lead to a need for doing Problem
Manager.
2.0 Record a problem ticket If a unique problem is identified then a
problem record will be created with all the
relevant details. The problem details should
include information required for tracking and
monitoring to ensure the problem is
investigated in the shortest time possible based
on the below criteria:

 Symptoms
 Incident Details
 All incidents related to the Problem
must be linked to the Problem Record

3.0 Categorize and prioritize Service desk categorizes the tickets based on
the CTI. Then the problem tickets are
prioritized based on the urgency and impact of
the underlying incident.

The Problem ticket will be assigned to the

correct Resolver Group and the status of the
ticket will be updated accordingly.
4.0 Investigate the underlying issue The Problem Owner along with the Problem
Manager will investigate further and gather
more details around the Problem
5.0 Conduct in-depth RCA The Problem Owner along with the Problem
manager conducts an in-depth and detailed
root cause analysis.

In case the problem analysis was triggered

because of a Major Incident, then the MIR is
used as an input to the conduct of an RCA.

The following parameters are used in

conducting an RCA:

 Source of the Problem

 Symptoms

 Impact details

 Any dependencies

The root cause analysis (RCA) may reveal more

than one possible solution.
6.0 Identify workaround The Resolver Group works on finding out the
workaround for the problem based on the in-
depth RCA conducted in the previous step.
The incident which was kept pending owing to
not being able to provide the resolution is now
opened and the Workaround will be provided
to the User and the incident will be closed.
The KEDB is updated with the work around
provided to the ticket.
7.0 Identify perm fix The Problem Owner and Problem Manager will
investigate whether the issue requires Supplier
engagement.
If there is no Resolution found or the
Resolution found is not cost effective for the <
Customer > Organization, the Problem
Manager convenes the discussion with the
Customer SME and then updates the ticket
with the decision taken on the future course of
action for the problem under consideration.
If no change is needed to implement the
resolution, the resolution is directly
implemented.
After providing the resolution, the Problem
record is updated with the details of the
Problem and discussion with < CUSTOMER >
and resolution procedure of the Problem.
8.0 Inform user If a User is directly involved in asking for a
 Problem analysis, he/she is informed by the
Problem owner regarding the resolution.
9.0 Close problem ticket Once the Problem Manager ensures that all the
necessary steps are taken towards Problem
Closure Problem Status is set to “Resolved”.
The problem ticket then gets the status
“Closed”

Inputs

 Results of Proactive Problem Management

 The occurrence of a Major Incident (Reactive Problem Management)
 Any unknown issue
 Change Implemented
 Workarounds
 Known errors arising from the IT development teams and test environments
 Configuration Management
 Service Level Management
 Incident Management
 Availability Management

Outputs

 Request for Change (RFC)

 Resolution for the problem
 Knowledge Articles
 Trigger to Change Management

ITIL v4 – Principles and Concepts

 ITIL implementation

Implementing ITIL in PDCA approach

The best way to implement ITIL processes is in a phased approach, for that first you would
need to understand what are the pain points in the IT, what is the most important process
applicable for IT operations, and the implementation methodology. Some of the popular
implementation methodologies can be defined as Deming cycle and Six sigma DMADV.
So here in this article, I am going to explain the ITIL implementation in PDCA approach.

Plan

Prepare the project charter, consisting of a business case, goal statement, project plan, project
scope, and roles and responsibilities.

Business case -should describe the benefits and opportunities of considering the following
areas:
  What are the short-term benefits and long-term benefits of this project?
 Does this new initiative align with other business processes, if any exist?
 What impacts will this new initiative have on other business units and employees? Pros and
cons.
 Should we have an explicit <Respective process> function ?
 What are the risks and issues involved, what are the dependencies?
 Business needs.
 Estimations of costs on infrastructure assets (hardware, software, people-ware) and other
miscellaneous things.

Goal statement –should be closely associated with the prepared business case. Goals should
be SMART and mention:

 What are the CSFs?

 What are the KPIs?
 What is the time estimated to see the results?

Project interfaces - should define the boundaries, scope, relationships of the <Respective
process> .

Project plan - should show the timeline, milestones for various activities to establish
<Respective process> function in place and run the process.

Roles and responsibilities - should identify the required roles and hire the human resources.
Primary roles needed for <Respective process> , can be defined as:

 Process manager
 Process practitioner
 Process owner
 Operational roles

Define RACI model for clarity in roles and responsibilities.

Develop

Develop the SOW for the <Respective process> process, defining the:

 scope of services/products, for which applies

 identification of service assets and CIs that are out of scope
 hardware, software and people-ware and <Respective process> tools required
 costs involved.

Categorize services, to organize a hierarchy.

Hardware software

desktop and accessories operating system

laptop and accessories applications

servers and accessories middleware

networking devices databases

 Define the conditions for process triggers.

 Define the impact and urgency levels for various services.
 Establish a separate repository for the information system), to store its records.
 Define email and announcements templates for process information and notifications.
 Define different strategies and methodologies to solve process activities.
 Enable access to different ITIL process tools and repositories.
 Define IT and process contacts list responsible for different services (e.g.: process manager,
process owner, operations manager, etc.).
 Define metrics and SLAs for consulting SLM, as per the customer’s requirements. Best
practice on definition of SLAs:
o Use historical data of the operations, to define the SLAs.
o If the operations haven't gone live yet, if it’s a Greenfield project define SLAs after
understanding the operations for at least 2 months. And also revisit the SLAs at
every month and redefine them.
 Acquire assets with regards to IT infrastructure (hardware, software).
 Training on process, technical knowledge, etc.
 Execute the operations.

Check

 Ensure that all unresolved issues are tracked and escalated to the next level of supervision in
consideration with SLAs.
 Ensure all issues are registered, categorized, tracked, and closed in the <Respective process>
tool.
 Update the IT contacts list regularly, with all the necessary contact details.
 Ensure the operation is in consideration with metrics, and SLT's defined in SLAs.

Act

 Integrate the tool with the knowledge base.

 Perform technical analysis on recurring issues, and escalate it to the <Respective process>
management.
 Perform GAP analysis.
 Provide adequate training for the respective process and technology.
 Record all operational transactions in its respective tools.
 Identify areas of improvement for the current services.
 Develop plans to mitigate significant risks.
 Prepare monthly reports (including accomplishments, targets met as per SLA, targets
breached, issues logged and resolved, etc).
ITIL v4 – Principles and Concepts
ITIL is a well-known best practice framework from UK, and currently owned by Axelos. The
evolution of ITIL can be represented through its three versions ITIL v1 (which described
some best practices and procedures), ITIL v2 in 1980’s (which had totally 10 processes and 1
function) and ITIL v3 in 2007 (which has 26 processes and 4 functions) and again in 2011,
ITIL v3 had some minor updates.

Now the next thing is ITIL v4, which is going to release in a year or 2 years, which would
have some new concepts focusing on the multi-supplier management, cyber security in
information security management, guidance on implementing and using ITIL with agile, lean
and devops methodologies, guidance for automation, guidance for adapting and adopting
ITIL.

ITIL v4 restructuring and redesigning is going to happen on six design principles, which will
focus on Provision of Value, Designs for human centred experience, Working holistically,
Progressing iteratively, Keeping the framework simple and collaborative.

ITIL v4 Principles

These six design principles would be:

Modular: This principle allows different frequency of updates to the upcoming version.

Lean: This principle eliminates the unnecessary content in the core guidance.

Practical: This principle provides useful advice, examples, and templates in the core
guidance.

Evolutionary: This principle ensures the evolution is focusing on the new trends and patterns
in the business and technology.
Collaborative: This principle ensures that the ITIL v4 framework is co-developed by ITSM
professionals, not just by some folks from specific region or specific experience.

Flexible: This principle ensures that the ITIL v4 framework can be adapted and adopted as
per the new practices like agile, devops, lean and etc.

Major concepts in ITIL v4

Human centered approach

ITIL v3 focused on identifying operational goals, creating concepts, and fitting concepts to
users.
ITIL v4 focus would be on understanding humans, creating concepts, and building
operational systems.
ITIL v4 will focus more on understanding the customer and their experiences and driving
business decisions from the customer perspectives.

Cloud computing and its impact on processes

Cloud computing will have huge impact on many of the ITSM processes. For example,
change management, change requests in cloud environments can be triggered for various
reasons as mentioned below:

 An end user currently uses Microsoft office cloud services like MS-Word, Powerpoint, Excel
and now needs to use Visio for 1 month; so he/she would place a change request to have
Visio access enabled for his/her login credentials.
 As per country's new legal requirement all CSP's should follow the ISO/IEC20K standard for
managing the IT services

Change types in a cloud environment can be classified into three types as request for change
for new requirements (RFC-FNR), request for change for resolving incidents (RFC-FRI), and
request for change for routine operations (RFC-FRO).

 Examples on RFC-FNR: As per country's new legal requirement all CSP's should follow the
ISO/IEC20K standard for managing the IT services
 Examples on RFC-FRI: An error or failure that has occurred in a specific software/ hardware
with respect to cloud service.
 Examples on RFC-FRO: An end user requests for more storage space on his virtual desktop

Multi-supplier management

In ITIL v3, there was vendor management which focused on managing the UC’s
(underpinning contracts) of the suppliers and Business Relationship Management to manage
the relationships with the customers, potential customers and competitors. ITIL v4 will define
practices and methods that will enable the organization to obtain different IT services from
different IT service providers, providing seamless service and ensuring the SLA’s are not
breached.
Cyber-security

In ITIL v3, there was no concept of cyber-security, but ITIL v4 provides explicit process
activities for risk, vulnerability and threat identification in application, information, network,
business continuity, operations, and end user. All these would be encapsulated in Information
Security Management which is generally defined in Service Design process area, aiming to
protect network, data and systems from cybercrimes.

ITIL v4 for the society

ITIL v4 for Individuals

Individuals who have passed their ITIL v3 foundation, intermediate and expert certifications
need not panic about their certifications validity. Professionals who have already done their
ITIL v3 foundation or intermediate or expert can do a bridge course and upgrade their
certifications to ITIL v4.

ITIL v4 for Organizations

Organizations need not worry about the investments that they have made with respect to staff
training on ITIL, procurement of tools, ISO standards, etc. since the latest version will only
add some new concepts.
Organizations can be assured that ITIL will be cost-effective, value driven, focusing on the
latest trends and technologies in IT.

ITIL Service Transition

ITIL Service Transition is the third stage in ITIL v3 lifecycle-based model which focuses on
transitioning services from design stage to operations stage.

ITIL service transition process

ITIL service transition has the processes as mentioned below:

 Change management
 Change evaluation
 Release and deployment management
 Service asset & configuration management
 Knowledge management
 Transition planning and support
 Service validation and testing

Change management:

Defines a standard procedure for managing the lifecycle of change requests, which can be
categorized into phases as registration & categorization, risk and impact assessment, approval
and deployment. Changes are generally categorized into normal, standard and emergency
changes.

Release and deployment management:

Defines a standard procedure for managing the lifecycle of release requests, which can be
categorized into phases as planning, build and test, deployment, early life support and
closure. Release types can be categorized into two types as big-bang & phased approach.
Knowledge management:

Defines a standard procedure for creating and managing the knowledge articles, which can be
categorized into phases as creation, editorial review, technical review and publish.

Service asset and configuration management:

Defines a standard procedure for managing the lifecycle of CI’s, which can categorized into
phases as management and planning, CI identification, CI control, CI status accounting and
reporting, and CI verification and audit.

Transition planning and support:

Defines a standard procedure for planning and coordinating the resources needed for
transition.

Service validation and testing:

Defines a standard procedure for validating and testing, here different types of testings are
performed based on the scope of the services.

Change evaluation:

Defines a standard procedure for evaluating the changes.

ITIL service transition ensures the testing is done thoroughly, on the designed and developed
services in service design stage.

Objectives:

 Ensure thorough planning, coordination of resources and capabilities while transitioning the
designed services.
 Ensure thorough risk and impact analysis, testing, deployment, and early life support for the
transitioned services.
 To prepare enough number of knowledge and reference materials for the new or changed
services.
 To ensure all the new and changed services and its associated CI’s are updated in the CMDB.

Inputs:

 SDP

Outputs:

 Test plans & results

 Updated CMDB
 Approved changes
 Deployed releases
  Published knowledge articles

Roles and Responsibilities

Primary roles needed for service transition are:

 Process owners
 Change manager
 Change analysts
 Release and deployment manager
 Build and test analyst
 Service validation and test manager
 Knowledge manager
 Knowledge analysts
 Service asset and configuration manager
 Service asset and configuration analysts
 Transition planning and support manager

Process owner:

 Define the Business Case for the respective process

 Ensure end-to-end responsibility for the respective process
 Ensure that the respective process is fit-for-purpose
 Ensure that there is optimal fit between people, process and technology
 Ensure that proper Key Performance Indicators (KPIs) are set
 Ensure that reports are produced, distributed and used

Process manager:

 Ensure that the respective process is conducted correctly

 Ensure that the process KPIs are met
 Ensure that the process operates effectively and efficiently
 Ensure that process management staff are empowered in their jobs
 Ensure that process, procedure and work instruction documentation is up-to-date

Process analyst:

 Be the operational process executer for his or her specific IT service, technology platform, or
organizational entity
 Enter all relevant details into the change/CI/ release/ etc record and ensure that this data is
accurate
 Ensure that the process is used correctly within all departments
 Be informed of the objectives and activities of all support groups
 Ensure correct closure and evaluation of change/ release / knowledge/ etc.
 ITIL Event Management

Event management is a process which defines a standard and sequential procedure for
managing the lifecycle of events.

Event management is the process of monitoring, responding, and resolving the events
triggered in infrastructure through a lifecycle approach. Generic event’s lifecycle can be
represented through different phases starting from notification, registration, categorization,
prioritization, diagnosis, resolution, and closure.

Any occurrences/observations that have significance to the delivery of IT infrastructure or

services are called events.

Objectives:

 Monitor CIs and services constantly and provide operational information about the
infrastructure.
 To provide a proactive mechanism for early detection of incidents.

Process Context Diagram

Sl
Procedure Description
No.
 1. Events in the IT Infrastructure are detected by monitoring tools.
2. The two type of monitoring tools used are –

-Active monitoring tools that poll key CIs to determine their status and
Event Detection
1 availability. Any exceptions will generate an alert that needs to be
& Filtration
communicated to the appropriate tool or team for action.
-Passive monitoring tools that detect and correlate operational alerts or
communications generated by CIs. Filter the events, to decide whether to
continue treating the event or to discard it.

1. Events are acknowledged and categorised into three broad categories –

Informational, Warning and Exception.
2. If the output of filtration is an exception, it means that the service or a
device is currently operating abnormally. Exceptions could represent a total
failure, impaired functionality or degraded performance. Incident
Event management would be invoked.
2 Correlation and 3. If the output of filtration is Informational, it refers to an event that does not
Response require any action. They are typically stored in a system or service log files and
kept for a predetermined period.
4. If the output of filtration is a warning, it is an Event that is when a service or
device is approaching a threshold. Warnings are intended to notify the
appropriate person, process or tools that the situation can be checked and
the appropriate action taken to prevent an exception.

1. Events responded are reviewed for appropriateness of action taken.

Review &
3 2. Events are closed if satisfactory actions were taken or sent back for
Closure
correlation.

Inputs

 Any alerts and events generated by the monitoring tools

Outputs

 Trigger to Incident Management (which will in turn trigger Problem or Change Management)
 Updated CMDB
 Trigger to Availability Management
 Trigger to Capacity Management

Roles and Responsibilities

Event Management process owner:

 Define the Business Case for the Event Management Process

 Ensure end-to-end responsibility for the Event Management Process
 Ensure that the Event Management process is fit-for-purpose
 Ensure that there is optimal fit between people, process and technology
 Ensure that proper Key Performance Indicators (KPIs) are set
 Ensure that reports are produced, distributed and used
Event manager:

 Ensure that the Event Management process is conducted correctly

 Ensure that the Event Management KPIs are met
 Ensure that the Event Management process operates effectively and efficiently
 Ensure that Event Management Staff are empowered in their jobs
 Ensure that process, procedure and work instruction documentation is up-to-date

Event management analyst:

 Be the operational process executer for his or her specific IT service, technology platform, or
organizational entity
 Enter all relevant details into the Event record and ensure that this data is accurate
 Ensure that the Event Management process is used correctly within all departments
 Be informed of the objectives and activities of all support groups
 Execute and coordinate Proactive & Reactive Event Management
 Ensure correct closure and evaluation of Events

Daily Log Template

Daily Log Report

Daily log report is an operational level management report which details all the transactions,
interaction and operations that have happened in the IT operations.
This report will be sent to the mid-level management team daily. This report is generally
prepared by the IT operations manager ensuring all the data is accurate and signed by him/
her.

Why do we need daily log report?

Below are some more detailed points elaborating the importance of daily log report:

 To communicate regularly with the mid and top level team

 To provide accurate, useful and detailed information on the IT operations.
 Help the mid and top level management to make quick and wise decisions with the
information provided.

Legend:
Informational message: Any message that provides an information about the CI’s.
Warning: Any alert informing that a specific is CI is about to breach.
Exception: Any alert informing that a specific CI has breached its defined conditions.
Standard change: Any change that is preauthorized and has defined models to manage the
lifecycle of change.
Normal change: Any change that requires detailed study with respect to planning, risk
assessment, approval and implementation.
Emergency change: Any change that is invoked when there is a major incident or
emergency situation.

Template Name Daily Log Template

Actual File Location http://itil-docs.com/69d2782a-f338-4862-87c6-
8afc6ec3f7c0
http://itil-docs.com/02fb3763-08b5-4d85-91e3-
f8b9cf3c0670
 IT Service Level Requirements Template

Service Level Requirements (SLR)

It is the collection of requirements that is gathered by the IT service provider detailing the
service requirements with respect to description of the service, availability, capacity,
continuity, service level objectives, service level targets, suppliers needed, roles and
responsibilities needed, etc.
SLR’s are the initial documents prepared by the service provider, with reference to the
discussions made with the customer. Based on the SLR’s, service level objectives and service
level targets will be drafted, negotiated, agreed and consolidated into SLA’s.

Objectives:
 To define the functionality and non-functional requirements of the IT service.
 To define the core service, enabling service, and enticing services.
 To define the utility and warranty specifications.
 To capture all the customer requirements as defined without missing any information.
Transfiguration of SLR to SLA

Sl. No. Procedure Description

 Service Level Management team will

understand the initial requirements
from the customer which could be
gathered through emails, documents,
direct conversations in meetings or
phone calls.
 The focus areas in gathering
requirements would be:
o Understanding service
Requirement understanding from description
1
customer o Understanding the service start
date
o Service success criteria
o Service availability
o Service capacity
o Planned service interruptions
o Security requirements with
respect to identity and access
o Business continuity

After gathering requirements, the service level

management team and design coordination
manager will refine those gathered
requirements and will document them into a
2 Drafting SLR’s
document called service level requirements.
Drafted SLR’s are then sent to the customer for
their consent. If the customer doesn’t agree,
then the requirements are gathered again.

If the drafted SLR’s are as per customer

3 Approved SLR expectations, then the customer would approve
the SLR’s.
 Based on the approval of SLR’s, SLO’s and SLT’s
are prepared by the service level management
team.
SLT: Targets, which are SMART (Specific,
4 Preparation of SLO’s and SLT’s
Measurable, Achievable, Relevant, and
Timebound) and is usually based on KPIs.
SLO: Objectives, which define the service
description and criteria.


o Service level management team
along with Supplier
management, IT service
continuity management,
Availability, Capacity,
Information Security
management teams will draft
Drafting, negotiating and standardizing the SLA’s.
5
SLA’s

o Then SLA’s are negotiated with
the customer.

 After the negotiations, the SLA’s are

standardized, defined and published to
all stakeholders.

Legend:
Service availability: Details the service availability for example:
Service availability during weekdays, weekends, timings

Service capacity: Details the service capacity for example:

Number of users who can use the service concurrently
Number of transactions to be processed at a point of time
Peak usage during days, weeks, months, or seasons

Service security: Details the service security for example:

Confidentiality, integrity, availability and non-repudiation with respect to IT systems
Confidentiality, integrity, availability and non-repudiation with respect to user credentials

Service continuity: Details the service continuity for example:

Recovery procedures & restoration procedures for IT systems

Template Name IT Service Level Requirements Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/10/IT-Service-Level-Requirements-
Template.docx
Release Testing and Verification
Release Testing

Release testing and validation contributes to quality control and assurance of a new
release that is Fit-for-Purpose and Fit-for-Use.

Release Testing & Verification provides objective evidence that a release of a new or
changed service and its service components will support both the customer’s business and the
stakeholders’ requirements, including agreed-to service levels. This activity assesses, and
addresses issues, errors, and risks identified throughout release life cycle.

Release testing and verification

Release testing and verification is an important activity in release and deployment

management which can be explained through the <> phases as:

 Defining the release test strategy

 Defining release test models
 Selecting the type of testing
 Test execution

Defining the release test strategy:

Test strategy should define the methodology to test and allocate testing resources, which
needs to be developed with appropriate stakeholders with respect to the release. To do an
effective testing, release management should understand the precise requirements on
availability, capacity, performance, security, etc. to plan and design the test approach using
information from the service package, SLPs, and SDP.

Defining release test models:

Test models should define the test plans for different types of releases, which should describe
what is to be tested, how it is to be tested, and the test scripts defining how each feature and
aspect of a release will be tested. A test model defines some predefined and repeatable steps
for a release in an effective and efficient way.

Selecting the type of testing:

Type of testing will vary depending on the scope, requirements, risks, constraints, etc. hence
there can be different approaches.
Some of the common release test types are service requirements testing, service level testing,
service testing, operations testing, deployment release testing, deployment installation testing,
and deployment verification testing.

Service requirements testing will verify and validate if the service provider has delivered the
service as per the customer requirements.

Service level testing will verify & validate if the service provider can deliver the
requirements as per the defined SLA’s.

Service testing will verify and validate if the service provider can manage the new or
changed service.

Operations testing will verify and validate if the operations teams like service desk,
application management, technical management, etc. can provide the support for new or
changed service.
Deployment release testing will verify and validate if the deployment team can deploy the
release into the environment in the defined SLA’s.

Deployment installation testing will verify and validate if the deployment team can do the
installation of the release components into the environment in the defined SLA’s.
Deployment verification testing will verify and validate if the deployment team has
successfully completed the deployment and meets the business requirements and customer
acceptance criteria.

Some of the common test types in functionality of a release would be component and
assembly testing, release package testing, operational readiness testing, and acceptance
testing.
Some of the common test types in non-functionality of a release would be usability,
accessibility, availability, security testing, etc.

Test execution

Test execution on releases involves prime activities like:

 Defining the test plan, schedule of milestones, delivery dates, hardware and software
resources needed
 Preparation of test environment
 Performing tests and documenting the findings
 Evaluation of the results with respect to expected results
 Clean-up and closure of the test environment

Service Delivery Status Report Template

Service Delivery Management

Service delivery status report is an top level service delivery management report which
highlights all the achievements, progress and issues happening in ITSM projects.

Service Delivery Status Report

Service delivery status report has to be sent to the customer management team regularly
based on the agreed requirements like weekly/ monthly/ quarterly. This report has to be
prepared by the IT service provider’s team ensuring all the data is accurate and signed by all
the IT service provider’s top-level management.

Why do we need service delivery status report?

Below are some more detailed points elaborating the importance of service delivery status
report:

 To communicate regularly with the customer team.

 To provide accurate, useful information on the ITSM projects to the customer team.
 To provide consolidated summary on IT service management projects.
 Help the customer management to make quick and wise decisions with the reports
provided.

Template Name IT Service Delivery Status Report Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/07/Service-Delivery-Status-Report-
Template.docx
 What is Project Management and its Importance
in ITSM

Project management

Project management is the art of managing the project and fulfilling the goals of the project
as per the defined time, scope, cost, and quality targets.

Note: Project is any temporary work that has a defined starting time and end time with some
defined outputs.

Project management has become an integral practice in any organization, irrespective of the
industry (like banking, health care, chemical, manufacturing, hospitality, construction, etc.).

Project management can be broadly classified into 5 phases as initiation, planning, execution,
monitoring and closing.

Some of the prime processes that should be there in project management are scope
management, risk management, cost management, procurement management, quality
management, schedule management, communications management, etc.

Why do we need project management?

Project management practice is essential to follow a defined a process in initiating, planning,

executing, monitoring and controlling the project activities which meets the customer
requirements and commitments as promised by the service provider.

Below are some more detailed points elaborating the importance of project management:
  To ensure the project gets completed in time as promised to the customer
 To ensure the project is not exceeding the planned budget
 To ensure there is no scope creep.
 To schedule the work in an appropriate order as per the priorities of customer
 To identify the potential risks & dependencies in the project work
 To provide a communication channel to the customer, who can provide the updates and
progress on the project status.

Some of the important project management methodologies which are currently popular are
Agile, Scrum, & Devops. Certifications that are available in project management are PMP
(Project Management Professional), PRINCE2 (Projects in controlled environment), etc.

Project Management Professional (PMP)

Project management professionals can be primarily classified into two categories as project
manager and project management coordinator.

Project managers are accountable for delivering the project outcomes, this role will have to
plan and organize schemes, resources and people ensuring that the project work is on time, in
scope and in budget. This role will have to track the work to be completed, set deadlines and
delegate tasks to the project team, identifying any potential risks.

Project management coordinator/ officer works reporting to the project manager to assist and
support specific teams on a project. Project Coordinator plans, organizes, and administers
projects and coordinates the work assigned to associates on the project teams.

Responsibilities of Project Manager

 Plan, monitor the work and set deadlines to make sure the project is on time, cost, scope
and budget.
 Motivate project team, co-ordinate the work, identify and manage risks and delegate tasks
to the right human resources.
 Act as a liaison with all internal and external stakeholders, and report regularly to
management.

Responsibilities of Project Management Coordinator / Officer

 Executing administrative duties such as coordinating and scheduling meetings, preparing
agendas, and documenting minutes of the meeting.
 Managing and tracking detailed tasks, milestones and risks in MS Project, Excel and MS
PowerPoint.
 Preparing and assisting the project manager in creating weekly and monthly status reports.

Project management in ITSM

Project management will play a very important role in IT Service Management, because even
ITSM’s focus is on achieving outcomes that is customer satisfaction with respect to incident
resolution and closure, service request fulfilment and closure, change implementation and
closure, problem resolution and closure, etc. in defined timelines, cost, scope and quality
parameters.

As project management has five phases initiation, planning, execution, monitoring and
closure; in the same way, ITSM can be categorized into five phases as service strategy,
service design, service transition, service operations, and continual service improvement.

Though we cannot map the five phases of project management to IT service management, yet
the phases, processes, principles and best practices of project management can be
implemented in all the 26 processes and 4 functions of ITSM.

For example, implementing and operating incident management:

To implement incident management as a process and execute the operations, you would need
an incident manager and incident analysts as human resources, who can follow the resource
management process in project management. To maintain quality in incident management, IT
governance team can utilize the practices of project quality management from project
management.

To maintain good communication to all the internal (problem manager, change manager, etc)
and external stakeholders (like customer team), IT governance team can utilize and embed
the practices of project communications and stakeholder’s management from project
management.

Likewise, one can utilize other processes like risk management, integration management, cost
management into the operations of ITSM.
 ITIL Service Delivery | Difference Between IT
Service Delivery & IT Service Support

Service Delivery

Service delivery has a specific definition and prominence in ITIL v2, focusing on the long-
term aspects of IT services like Financial Management, Availability Management, Capacity
Management, Service Level Management, and IT Service Continuity Management.

Be it any IT organization, no management would create budgets every day.

Be it any IT organization, no team would define availability plans for an IT service everyday.
Be it any IT organization, no team would define capacity plans for an IT service everyday.
Be it any IT organization, no teams would define continuity plans for an IT service everyday.
Be it any IT organization, no teams would define SLA’s for an IT service everyday.

You do the above mentioned activities, once in a month or quarter or half a year, hence these
activities are focused on long term. Hence the processes Financial Management, Availability
Management, Capacity Management, Service Level Management, and IT Service Continuity
Management is categorized under Service Delivery.

Service Support

On the other side, there was Service support which focused on day to day operations. The
processes and functions covered in service support are Incident Management, Problem
Management, Change Management, Release Management, Configuration Management and
one function Service Desk.

Incidents, problems, changes, releases, configurations and interactions with service desk
happens regularly in day to day operations, hence these processes and function is categorized
in service support.

IT v3 Service Delivery

In ITIL v3, there is no specific definition for IT service delivery, as ITIL v3 is a lifecycle-
based approach which runs on the five process areas service strategy, service design, service
transition, service operations, continual service improvement.

In practical IT environment, IT Service Delivery means the delivery of IT services which

involves defining the strategy, designing the service, transitioning the service, performing
operations, and improving the service.

Some of the prime activities involved in IT Service delivery are:

 Formulating and planning, designing, scheduling and monitoring the strategy, design,
transition, operations and continuous improvement related activities to meet time and
targets.
 Providing training to the IT workforce appropriately on the respective processes, tools,
technologies to provide good support on incidents, service requests, problems, and change
requests in the pre-defined SLA targets.
 Understanding the ticket volumes and backlog.
 Leading, executing structured governance and managing the escalations, communications,
relationship with the customer, etc.
 Developing, negotiating and managing the SLAs as per the business unit needs
 Managing services within budget guidelines, and providing progress, issues, and
improvements reports for top, mid, and low-level management.
 Identifying all possible risks that can affect the IT services with respect to time, cost, scope
and quality.
 Reviewing and monitoring the IT operations performance reactively and proactively to meet
SLAs and customer requirements.
 Defining and evolving the support models / plans for new services.
 Managing compliance with the defined SOP’s and policies associated with the IT operations
and process.

Difference between ITIL Service Support

and ITIL Service Delivery

IT Service Support IT Service Delivery

IT Service support focuses on providing day IT Service delivery focuses on planning and
to day support in IT operational environment. designing the IT infrastructure services.

Processes involved in service support are Processes involved in service delivery are
 Financial Management, Availability
Incident management, problem management,
Management, Capacity Management, Service
change management, release management,
Level Management, and IT Service Continuity
configuration management.
Management.
Has one function – Service Desk.
No functions defined.
 Lists 26 ITIL Processes & 4 ITIL Functions

ITIL Processes

ITIL v3 has 26 processes which have been segregated into five process areas service
strategy, service design, service transition, service operations, continual service improvement.
Process is a sequence of activities which has some inputs, triggers, outputs and delivers
specific outcomes to the customer.

Service strategy process area has 5 processes:

Strategy management for IT services:

This process has 4 sequential activities which can be mentioned as performing strategic
assessment, generating strategy, executing strategy, measurement and evaluation.

Demand management:

This process has 4 sequential activities which can be mentioned as identifying sources of
demand and forecasting, analysing the patterns of business activity and user profiles,
developing differentiated offerings and managing operational demand.

Service portfolio management:

This process has 4 sequential activities which can be mentioned as definition of the services,
analysis of the services, approval and chartering of services.

Financial management for IT services:

This process has 3 sequential activities which can be mentioned as budgeting, accounting and
charging.

Business relationship management:

This process has 3 sequential activities which can be mentioned as request and complaints
handling, opportunity identification, and managing business relationships.

Service design process area has 8 processes:

Service catalogue management:

This process has 4 sequential activities which can be mentioned as documenting service
definition and description, agreeing service catalogue contents, and finally producing and
maintaining service catalogue.

Availability management:

This process has 4 sequential activities which can be mentioned as monitoring availability,
analyse availability data, investigate service unavailability, availability planning, and finally
review availability and testing.

Information security management:

This process has 5 sequential activities which can be mentioned as understanding security
requirements, producing security policy, implementing security policy, assessing information
assets and risks, and finally reviewing security controls.

Service level management:

This process has 4 sequential activities which can be mentioned as understanding

requirements and drafting SLA’s, negotiating the SLA’s, define and standardize the SLA’s,
and finally monitor and report service performance.

Capacity management:

This process has 5 sequential activities which can be mentioned as monitor capacity and
performance data, analyse the capacity data, investigate capacity issues, define and revise
capacity plans, and finally review and optimize/improve capacity.

Design coordination:
This process has 4 sequential activities which can be mentioned as defining policies and
methods, planning resources and capabilities, managing design risks, and finally improving
service design.

Supplier management:

This process has 5 sequential activities which can be mentioned as defining requirements,
evaluating suppliers, selection of suppliers, manage performance, and finally renew or
terminate contracts.

IT service continuity management:

This process has 3 sequential activities which can be mentioned as develop requirements,
develop continuity plans, implement continuity plans, and finally invoking the continuity
plan.

Service transition process area has 7 processes:

Transition planning and support:

This process has 5 sequential activities which can be mentioned as definition of transition
strategy, preparing for service transition, planning and coordinating service transition, and
finally monitoring and reporting progress.

Change management:

This process has 5 sequential activities which can be mentioned as registration and
categorization, risk and impact analysis, approval, coordinate change build and test, authorize
change deployment, and finally review and close change record.

Change evaluation:

This process has 3 sequential activities which can be mentioned as plan evaluation,
evaluation of predicted performance, and finally evaluating actual performance.

Release and deployment management:

This process has 5 sequential activities which can be mentioned as release planning, build
and test release, deployment, early life support, and finally review and closure.

Service asset and configuration management:

This process has 5 sequential activities which can be mentioned as management and
planning, CI identification, CI control, Status accounting and report, and finally verification
and accounting.
Service validation and testing:

This process has 5 sequential activities which can be mentioned as planning and designing
tests, verifying test plans and designs, preparing test environments, performing tests,
evaluating exit criteria, and finally cleaning test environments and closure.

Knowledge management:

This process has 5 sequential activities which can be mentioned as defining knowledge
management strategy, identify and gather data sources, draft knowledge, technical review,
editorial review, and finally publish.

Service operation process area has 5 processes:

Access management:

This process has 5 sequential activities which can be mentioned as access requisition,
verification and validation, provision of rights, monitoring the access, tracking the access and
finally deprovisioning the access.

Event management:

This process has 5 sequential activities which can be mentioned as event notification, event
detection, correlating and filtering events, categorization events, and finally event review and
closure.

Service request fulfillment:

This process has 5 sequential activities which can be mentioned as request registration,
validating request, categorize and prioritize request, review and authorize request, and finally
request closure.

Incident management:

This process has 5 sequential activities which can be mentioned as incident registration &
categorization, prioritization, investigation and diagnosis, resolution, and finally closure.

Problem management:

This process has 5 sequential activities which can be mentioned as problem detection and
logging, categorization, investigation and diagnosis, and finally resolution and closure of
problem.

Continual service improvement process area has 1 process:

Seven step improvement: This process has seven sequential steps which can be mentioned as
identify the strategy for improvement, define what you will measure, gather data, process
data, analyse information and data, present and use information, and implement
improvement.

ITIL Functions

Function is a team or a group of people who perform a set of activities.

ITIL v3 defines four functions as Service Desk, Application management, Technical
Management, and Operations Management.

4 ITIL v3 Functions

Service desk

This is a function who will be the first point or single point of contact for end user issues.

Application management

This is a function who will manage the application development and maintenance issues.

Technical management

This is a function who will manage the technical expertise for the ITSM processes and
operations.

Operations management

This is a function who will manage the day to day operations with respect to IT operations
control and IT facilities management.

6 Goals of Incident Management

The prime goal of incident management is to resolve incidents either with temp fix or perm
fix and bring back the IT service. We list here few steps involved during incident process.

Resolve incidents to reduce downtime to the business

The prime goal of incident management is to resolve incidents either with temp fix or perm
fix and bring back the IT service. Resolving the incidents, firstly requires to register the
incident in the ITSM tool with a unique reference number, then categorization of the incident
is done based on hardware, software, etc. and then the incident is assigned to the appropriate
team or a person to take quick action, then the investigation and diagnosis is done, then
resolution is implemented by searching knowledge articles or reference materials or KEDB
and once the issue is resolved then the incident is closed.

Improve the quality of IT service and increase availability of the services

operation

Incident management can improve the quality of IT services by identifying the recurring
incidents, and logging problem tickets to identify the root cause of the incident/ incidents. If
there is any new incident which has no resolution, then a problem ticket is created to identify
the root cause and a fix.
By identifying the recurring incidents and its associated CI’s, availability management or
capacity management or information security management or continuity management can
redefine or revise the respective plans and procedures to improve the delivery of services.

Monitoring of services, detecting and mitigating incidents

As incident management team in many organizations is also involved in monitoring, they will
get a complete picture why the incident occurred, what errors or warnings or exceptions have
occurred. Accordingly, the monitoring team can consolidate the complete information from
monitoring and event management tools and inform the problem management team for
quicker resolution of unknown incidents.

Communicate regarding the progress of the major incidents to all

stakeholders

Incident management team will communicate the progress of the major incidents to all the
necessary stakeholders from the moment it has been registered to the closure.
Incident management team keeps sending notifications regularly after every half an hour or
the defined timelines to all the relevant stakeholder giving information on the incident like:

1. What is the incident?

2. What is the priority?
3. When the incident occurred?
4. Where is the incident happening or happened?
5. What is the associated CI?
6. How many people are impacted?
7. Who is working on the issue?
8. Estimated time to resolve the incident

Ensure SLA’s don’t breach for any reason

Incident manager and management team will have to ensure the SLA doesn’t breach on any
of the incident ticket, for any reason like 3rd party involvement, negligence of the incident
management team, dependency on any other problem or change ticket.

Measure the effectiveness of incident management operations

Incident manager has to track the effectiveness of the incident management operations by
defining the metrics and KPI’s (Key Performance Indicators) like:

1. Number of incidents
2. Number of major incidents
3. Number of recurring incidents
4. Average time taken to resolve the incident
5. Average time taken to resolve the major incident
6. Incidents that triggered problem tickets
7. Incidents that triggered change tickets

Release Management Best Practices in ITIL

Release and Deployment Management

Best practices are those real practices that have delivered efficient, effective, and excellent
results in the IT processes and real operations.

Best practices for Release and Deployment management processes and operations can
be defined as mentioned below:

Release planning is a must for every major and minor release

Release analysts should do appropriate planning, before the release plans, packages and
builds are sent for testing to avoid wastage of time and efforts. Planning should involve
analysis on aspects like:

 What requirements are there for the release, determine which release units to be included
in the release and to include complete application and related components into release to
ensure proper testing.
 Release dates of major releases.

Building release packages

 Release Management Best Practices[/caption]

The release team must document the manual processes and procedures required to deploy the
release into production (or remove it as necessary) in addition to any technology solution,
along with the exact order of execution and success indicators of the steps.
The documentation created as part of the build stage should include details of how to monitor
and check the effectiveness of the release and how to recognize and react to problems.

Release test plans and review test results

Adequate testing on release is a mandatory activity that should happen without a miss. All the
testing work should happen in coordination with SVT process.
Once the build is ready, tests need to be performed to verify in the functionalities of the
release are in line with the change objectives. Depending on the nature of the change the test
requirements like System integration tests, functionality tests, and UAT/Pilot tests should be
performed defined by the SVT process.

Assess the deployment readiness

Assessing the deployment readiness should involve:

 Identifying the people (deployment stakeholders) who will be involved in the deployment,
 Taking a baseline of the current configuration before the deployment can start on the
production Environment which will be useful when the roll-out fails.
 Conducting post deployment test on the production environment and the test results to
review the release acceptance criteria.

Deployment Documentation
Release notes should be prepared with the content of known issues/bugs identified during the
testing and should coordinate with SACM team to strategize for the release documentation
updates in CMS/CMDB.

ELS the most important role in Release management

ELS team should provide the support to support staff by providing knowledge sessions and
training on the release and the technicalities involved in fixing issues. Also, known bugs,
known issues should be explained to resolve any knowledge transfer or training gaps.

Release closure

Release Coordinator should ensure:

 That all affected CIs (which were created/modified) during deployment are updated
correctly in CMDB.
 That all related release documents are updated correctly in CMDB and are linked to
appropriate CIs.
 All new KB articles prepared during the ELS phase are to be updated at the appropriate
location in the SKMS so that those can be easily reused later by the operations/support staff.
 Analyze the Deployment and ELS Completion reports and results and discuss with the
release team to identify what went correct and what went wrong in the release cycle.

Lessons Learned Document

Documentation of lessons learned should be a must, and should be submitted as knowledge

articles to verify and validate them and to publish them in knowledge base.

Have a unified calendar with complete visibility

Having an integrated calendar accessible to change, release, and other operational teams like
incident and problem would be very helpful to see planned changes and releases by time, day,
week and month.

Participation of release management staff in service

improvement meetings
Participation of release staff in service improvement meetings is very vital to understand the
priorities and goals of IT organization and accordingly release management staff should align
its operations. Also release staff can provide many great inputs for improving the IT service
delivery.

Regular meetings with other ITSM process owners

Regular meetings with other ITSM process owners should happen continuously to update the
trends and patterns of releases and the concerns of EU's and customers.
Maintenance of ITSM process owners and onsite
technicians contacts list
Maintenance of ITSM process owners, onsite technicians and service owner's contacts
details, and being up to date is a must which will enable the change management staff to do
the planning & coordination with other service transition stakeholders.

Access to KEDB, CMDB, CMS and SKMS

Release management staff should have access to KEDB, CMDB, CMS and SKMS;
accessibility to these tools will help the staff to understand the impact of a release, associated
services, SLAs associated, financial value, etc. and will help them to evaluate the risks
associated.

Regular training sessions

Training sessions on release management process, policies, procedures and technical
knowledge is a must which should happen at regular intervals.
Most of the delays and discrepancies in release management operations happen due to
unawareness on process, policies, and procedures; hence, it is a mandatory objective for IT
management to conduct training sessions which can bring thorough awareness to all
stakeholders. Management should also conduct exams and assessments to evaluate the
proficiency of the staff, and reward them with some gifts or incentives.

Template Name Release Management Best Practices

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/07/Release-Management-Best-
Practice.pdf
What is Release and Deployment Management? |
Release Management Process Flow

ITIL Release Management Process

Release and deployment management defines a standardized process for planning the release,
building and testing the release, scheduling the release, testing the release, deploying the
release, providing early life support (ELS), and closure of releases.

Release Management Process flow

In practical IT environment, release management operations would generally be executed as

per the below diagram:

Process Description of Release Management

Step 1: Create a release ticket

Request for Change (RFC) from the Change Management Process forms an input to Release
& Deployment Management process.
For all Releases, a Release ticket is raised in <<tool>> and is to be tagged to the RFC which
triggered the Release.
There may be many to one mapping between changes and releases (i.e. many changes can be
released together) or one to one mapping (i.e. one change can be released stand alone).
Release can be a normal release (Major or Minor) or an emergency Release.

Step 2: Create a release plan

For every release, the Release Manager will own the responsibility of preparing a Release
Plan. Release Manager coordinates with Change Management team and Build team regarding
the same.
The Release Plan will be submitted to the CAB.

Step 3: Assign release activities to technical teams

Release Manager will assign the release activities in <<tool>> to the person responsible for
those activities.

 These tasks are tracked and monitored by the Release Manager to monitor the release
status.
 If a release needs a vendor involvement, then the ticket is assigned to the vendor queue in
<<tool>> and <<if tool integration exists it is routed to vendor’s tool via the B2B the ticket
gets created in their system>>.
 Release Manager will then publish the release calendar based on the dates finalized in the
Release Plan.

Step 4: Release packaging

Release Manager will ensure that releases are packaged and released in a controlled manner
as per the plan.
Release packaging includes assembling and integrating the release components as per the
dependencies identified.

Step 5: Build the release

Release Manager will coordinate with Build team to build the release and produce the build
document which will contain:

 Build, installation and test plans, procedures and scripts

 Monitoring and quality assurance of the release
 Processes and procedures for distributing, deploying and installing the release into the
target environment
 Release unit roll-back procedures
 Change remediation steps in case of release failure

Release Manager will coordinate with Build and Change Management teams and ensure that
the build activity is completed as per the Release plan.
Build team will consider various aspects relating to version control, baseline management,
control of inputs and outputs from a build.
Creation of a configuration baseline which is recorded in the configuration management tool
for the release before and after installation, to provide a restore point in case of rollback is
initiated by the Release Manager along with the Change and Configuration Manager.

Other aspects taken into consideration for a Release are:

 Checking that the security requirements are met

 Verification activities to ensure prerequisites are met before a build or test begins
 Preparing and controlling the service release readiness for deploying into the next
environment

Step 6: Service validation and testing

Build prepared by the build team is then moved into Test Environment for testing. Release
Manager will initiate testing as per the Release Plan. Service Validation & Testing team will
complete testing of the release and will provide test results to the Release Manager.
Build and Test activities will be completed in the stipulated time frame as per the Release
Plan. Time allocated to each activity will depend on the release type.

Step 7: Test successful ?

Release Manager will ensure that all mandatory tests are conducted and all tests are
successful before a release can be flagged off to production.

Step 8: Update Release Plan & Rollback Plan ?

Once testing is successful, Release Manager will update the Release Plan and rollback plan as
required and circulate the same to Change Manager and other stakeholders.
Release Manager will also ensure that Rollback plan is properly prepared and is tested (or
verified wherever testing of rollback plan is not possible).
All releases will be subject to pre-implementation checks and the Release Manager will work
with the Change Manager for changing, reassessing, and rescheduling unsuccessful release
packages.

Step 9: Release preparation and communication

Release Manager will ensure that all the environments are ready for release and will send out
a communication to all stakeholders.
Acceptance criteria for the release are documented wherever relevant in the release ticket.
Successful release(s) with the positive test results is now moved to deployment phase.

Step 10: Deployment readiness activities

Readiness assessment for the deployment group will be done to check for issues and risks in
delivering the current release that may affect the deployment.
For all non-major Releases, Delivery Manager will give Go/ No-Go decision regarding the
releases.
Deployment team will prepare the training plan, training material, training schedule and
training communication (for all major releases). Before the deployment they will ensure that
the users, relevant support teams and other concerned stakeholders are appropriately trained.
Step 11: Initiate backup

Release Manager will coordinate and ensure that the backup is taken for the current release.
This is to ensure that rollback to previous baseline is possible in case the deployment of the
release fails.

Step 12: Deploy release as per plan

Release is deployed in the environment as per the deployment plan. Release Manager
broadcasts the down-time related information wherever necessary in advance.

Step 13: Test Deployment

Success of the deployment is tested during this activity. Health check will be conducted by
the Release Manager in coordination with the deployment team to verify the success of
deployment.

Step 14: Change evaluation

Change evaluation process will evaluate the release.

Step 15: Change Management

Change management process will own and perform the Post Implementation review (PIR).

Step 16: Rollback required due to failed change?

During PIR Change Management will decide on the success or failure of the change.

Step 17: Rollback release

If a release fails, Release Manager will authorize (on the advice of <<Customer>> Delivery
Manager or Change Manager) and initiate a Rollback of the release and restore the services to
normal stage.
A root cause analysis for the failure of the release may be triggered (on need basis) via the
Problem Management process.

Step 18: Change management

Change Management will ensure update to the RFC and related updates to the requester.
Required communication regarding failure of change will be sent as per the Change
Management Process.

Step 19: Update and close release ticket

Release Manager will resolve the release ticket and pass on the status update and post-
implementation status to Change Management and update/ close the release ticket
accordingly.
Release Manger will update the RFC with release closure comments.

Step 20: (If the change fails): Ensure CMDB update

Release Manager will ensure that the CMDB is updated with new (or updated) configuration
details as per the release documentation and that a new baseline is created in the CMDB.

SACM
Configuration Manager will update the CMDB with the new or updated CI details.

Roles and Responsibilities in Release and

Deployment Management | RACI Matrix Template
Roles and Responsibilities Template

Generic roles that are available in Release and deployment management are Release
manager, deployment engineer, and CAB (Change advisory board).

Release Manager Roles

 Release manager will need to interface and communicate with test managers, IT operations,
 Development team and the PMO on a daily basis and keep track of multiple project release
timelines.
 He/she will liaise with and manage the Release process with the Quality Assurance team,
Service
 Management teams, business users, developers and technical support specialists on product
issues.
 Creating Release Plans providing timelines for release build and test, deployment, early life
support and closure.
 Maintaining and publishing project Release Plans, Release Calendar and managing schedules
and resource allocation and adhering to the timelines to ensure timely product delivery.
 Does the critical review on all the release and change collaterals (change requests, release
plans, build and test plans, deployment plans, etc.)
 Maintains the track of all releases that are to be implemented and that have been
implemented.
 Directs and leads the release management team members with appropriate trainings.

Release and build Engineer

 Development, monitoring and maintenance of release and build pipelines

 Development of release and build infrastructure
 Design and run quality tests on the builds and releases
  Creating packages, builds, releases and patches as well as the software deliverables for the
customers
 Identify defects and inform them to the release manager

Deployment engineer

 Create deployment plans

 Automate the manual work related to deployment configuration in day-to-day tasks.
 Improve deployment procedures with automation and documenting the deployment
procedures
 Documenting change logs accurately in build and deployment processes.
 Identify defects and inform them to the release manager

ELS Engineer

 Provide technical support on releases in production issues.

 Monitor and keep a log of the issues being raised by end-users.
 Provide trainings and prepare manuals with respect to every new release

How to implement RACI matrix?

1. First, define the process, which will be a sequence of activities that will result in a specific
outcome with the help of some roles and capabilities. Here you need to define the different
roles needed for the process like release manager, build engineer, deployment engineer,
test engineer, etc.
2. Second, Identify the sequence of activities in a life-cycle based approach. For example: Raise
release request, Categorize the release request, etc.
3. Third, Identify the decisions in every activity. For example: Approve the build plan, Approve
the deployment plan, etc.
4. Fourth, each and every defined activity and decision should be tagged to a specific role.
5. Fifth, define the matrix with columns and rows. Naming the first column heading as
‘Activity’, and below it (that is Activity column) define the different activities in a sequenced
order. Define the other columns headings with the respective roles defined in the process.
6. Finally, populate the information ‘R’, ‘A’, ‘C’, ‘I’ in the rows and columns ensuring there is:
o One and only one ‘A’ (i.e. accountable role) for a specific task
o Every task should have one ‘R’ and can also have many ‘R’s (i.e. responsible roles)
based on the task
o Lastly, tasks can have one or more ‘C’s (i.e. consulted roles) and ‘I’’s (i.e. informed
roles) based on the task.

Template Name RACI Matrix Template for Release &

Deployment Management
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/07/RACI.xlsx
Change Request Form | Fillable Change Request
Template & Sample
Change Request Form
Change request form is the medium through which the change initiator can describe the
details of the proposed change.

Normal Request For Change

Important details to be captured in Normal Change tickets are:

RFC Number: a unique ID registered for the change

Change Description: the description of the change
Change Location: the location where the change will be implemented
Change Requester: the person who requested the change request/RFC
Change Analyst: the name of the change analyst who will analyze the change request/RFC
Change Requested Date: the date on which the change was requested
Change Triggered By: defines the sources that triggered the change like legal requirements,
business requirements, etc.
Change Classification: the classification of the change like Normal, Standard, and
Emergency
Category: the category of the change
Type: the type of change
Item: item of the change
Assignment group: The group assigned to own and possibly implement the Change Request
Risk analysis: describes the risks associated with the change
Business Case: the plan which defines the business justification, benefits, and resources
needed
Rollback Plan: the description of the rollback plan
Risk analysis: the description of the risk analysis
Remediation Plan: the description of the remediation plan
Impacting Services: the services that will be impacted by the change
Impacting CIs: the CIs that will be impacted by the change
Relative Benefit of Implementing the Change: the benefit of implementing change
Relative Cost: This should define the relative costs
Estimated Effort in Man Days or Hours: Man days or hours
Change Approval/Rejected Date: the date and time when the change was approved/
rejected by

CAB
CAB Decision: a decision made by the CAB
CAB Comments: comments given by the CAB
ECAB Decision: decision made by the ECAB
ECAB comments: comments given by the ECAB
Change Manager: name of the change manager
Impact: The number of people that will be affected by change
Urgency: how soon the change has to be implemented
Priority: It will be based on impact and urgency
SLAs Associated: SLAs associated with change management
SLA Target Date and Time: date and time when the SLAs will be breached with respect to
the change
Major Change Review: This determines if it's a major change
Major Change Justification: This defines the business justification and why it should be
treated as a major change
Associated Incidents: the details of the incident tickets that are associated with this change
Associated Problems: the details of the problem tickets that are associated with this change
SLAs Breach Details: the description why the SLAs were breached, and by how many
minutes or hours did we breach the SLAs.
PIR: defines the lessons learnt

Emergency RFC
 Emergency RFC Template

Important details to be captured in Emergency Change tickets are:

RFC Number: a unique ID registered for the change

Change Description: the description of the change
Change Location: the location where the change will be implemented
Change Requester: the person who requested the change request/RFC
Change Analyst: the name of the change analyst who will analyze the change request/RFC
Change Requested Date: the date on which the change was requested
Change Triggered By: defines the sources that triggered the change like legal requirements,
business requirements, etc.
Change Classification: the classification of the change like Normal, Standard, and
Emergency
Category: the category of the change
Type: the type of change
Item: item of the change
Risk analysis: describes the risks associated with the change
Business Case: the plan which defines the business justification, benefits, and resources
needed
Rollback Plan: the description of the rollback plan
Risk analysis: the description of the risk analysis
Remediation Plan: the description of the remediation plan
Impacting Services: the services that will be impacted by the change
Impacting CIs: the CIs that will be impacted by the change
Change Approval/Rejected Date: the date and time when the change was approved/
rejected by

CAB
ECAB Decision: decision made by the ECAB
ECAB comments: comments given by the ECAB
Change Manager: name of the change manager
Impact: The number of people that will be affected by change
Urgency: how soon the change has to be implemented
Priority: It will be based on impact and urgency
SLAs Associated: SLAs associated with change management
SLA Target Date and Time: date and time when the SLAs will be breached with respect to
the change
Associated Incidents: the details of the incident tickets that are associated with this change
Associated Problems: the details of the problem tickets that are associated with this change
SLAs Breach Details: the description why the SLAs were breached, and by how many
minutes or hours did we breach the SLAs.
PIR: defines the lessons learnt

Template Name Normal RFC Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/07/Normal-RFC-Template.docx

Template Name Emergency RFC Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/07/Emergency-RFC-Template.docx
 Roles and Responsibilities Template for Change
Management (RACI Matrix Template)?

RACI Matrix Template

RACI matrix is one of the ITSM process collateral which will be used for ITSM
stakeholders to define and demarcate the roles and responsibilities in an ITSM process.

RACI matrix stands for Responsible, Accountable, Consulted, and Informed.

 Role that is tagged as Responsible in RACI matrix, will perform the task/ tasks.
 Role that is tagged as Accountable in RACI matrix, will have the complete authority , will
make decisions and will be answerable for the success or failure of the task.
 Role that is tagged as Consulted in RACI matrix, will be like a subject matter expert who will
be approached for recommendations and feedback.
 Role that is tagged as Informed in RACI matrix, will be a stakeholder who should be
communicated about the actions taken in performing the specific task.

Lack of matrix in ITSM operations will lead to ambiguity in performing respective duties,
blame games, and confusions at their work activities.
Roles and Responsibilities Template for Change
Management
Generic roles that are available in change management are change manager, change analyst,
and CAB (Change advisory board).

Change Manager

 Maintaining change management system, including policies, processes, systems, metrics and
procedures that are used across the entire IT business and adheres to all regulatory
requirements.
 Research & proactively identify opportunities to process, measurements, and systems in
order to improve the effectiveness and efficiency of change management services.
 Work closely and communicate effectively with users and stakeholders of the change
process to drive the improvements.
 Assure service quality objectives, governance compliance, and responsiveness through KPIs
and metrics.
 Attends all CAB meetings.
 Support the development and execution change management activities in partnership with
customer teams - including stakeholder engagement, communication, training, and
readiness and adoption measurement plans.
 Collaborate with the team and key stakeholders to ensure timely delivery and quality of
assigned deliverables.
 Identify possible issues/concerns, escalate risks and issues to management and project
leadership teams, and implement mitigation plans if necessary.
 Identify training needs by analysis of common errors.
 Keep the customers and internal stakeholders up to date on high priority changes through
timely and regular written and verbal communications.
 Review the business case of all RFCs/change requests and formulate a plan of action for
handling the change based on area of expertise/responsibility.
 Ensure change management documentation is updated.
 Gather and analyze information on a variety of changes and develop action plans to contain
and control incidents.
 Liaison with internal training and communications staff to produce user guidance and
bulletins explaining best practice and common issues.
 Provide information and reports on change implementations, successful changes, and failed
changes.
 Verify implemented changes.
 Conduct PIR on successful and failed changes and conduct RCA.

Change Analyst

 Register, categorize, and prioritize changes after conducting thorough analysis

 Conduct risk analysis before submitting it for CAB approval
 Facilitate CAB meetings
 Maintain a balance between the business need for prompt change and the necessity of
ensuring that stability of existing systems is not compromised.
 Document and publish the CAB - MOM (Minutes of the meetings)
 Reroute misdirected changes that have not been handled in a timely manner
 Identify changes that needs special attention or escalation
  Ensure change report is created immediately after successful implementation
 Draft and send out communications to ensure that all relevant stakeholders are aware of
procedures
 Work with change manager to ensure change activities are properly communicated
 Ensure change implementers are adhering to the process and procedures as defined

CAB

 Responsible for making decisions on whether or not the RFC would bring positive results,
value to the organization, reduce the manual efforts, and reduce the costs.
 Approve changes/reject the changes based on:
1. the risk to IT services and business services
2. impact of a change on availability, performance, security, compliance, and SLAs
3. provision of procedures
4. test plans defined
5. test results gathered
 Ensure that the change is planned well and is equipped with all procedures to test and
implement.
 Review the implemented changes
 Discuss previously failed, rolled back, and backed out changes to understand what went
wrong
 Participating in CAB meetings
 Authority to represent a particular group or function
 Preparing for CAB meetings by circulating RFCs within their own group and coordinating
feedback
 Reviewing RFCs and recommending whether they should be authorized
 Reviewing successful and failed changes
 Reviewing unauthorized changes
 Reviewing the change schedule and providing information to help identify conflicts or
resource issues
 Reviewing the projected service outage and providing feedback on the impact of planned
outages.

How to implement RACI matrix

1. First, define the process, which will be a sequence of activities that will result in a specific
outcome with the help of some roles and capabilities. Here you need to define the different
roles needed for the process like change manager, change implementer, CAB, etc.
2. Second, Identify the sequence of activities in a lifecycle based approach. For example: Raise
change request, Categorize the change request, Assess the change request, etc.
3. Third, Identify the decisions in every activity. For example: Approve the test plan, Approve
the rollback plan, etc.
4. Fourth, each and every defined activity and decision should be tagged to a specific role.
5. Fifth, define the matrix with columns and rows. Naming the first column heading as
‘Activity’, and below it (that is Activity column) define the different activities in a sequenced
order. Define the other columns headings with the respective roles defined in the process.
6. Finally, populate the information ‘R’, ‘A’, ‘C’, ‘I’ in the rows and columns ensuring there is:
o One and only one ‘A’ (i.e. accountable role) for a specific task
o Every task should have one ‘R’ and can also have many ‘R’s (i.e. responsible roles)
based on the task
 o Lastly, tasks can have one or more ‘C’s (i.e. consulted roles) and ‘I’’s (i.e. informed
roles) based on the task.

Template Name RACI Matrix Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/07/RACI-Matrix.xlsx

Release Management | Agile and Scrum Release

Management

What is Release Management ?

Release management in agile and scrum methodologies manages the releases as per the tight
timelines and agile customer requirements.
So to understand a release in simple words, it is a collection of user stories from a single
product or multiple products which is created by a product owner. A release has a defined
time period with a start and end date.

Purpose of release management

 Helps business to communicate with the team regarding the expectations.

 Helps as a guidepost to manage the scope creeps, to understand the impact of changes, to
understand how much work can be done and what is the time period.

Agile and Scrum Release Management

Inputs for release planning and management in agile and scrum approaches would be team’s
velocity, project length, and prioritized product backlog and the output would be a release
plan which guides the scrum team during the release period.

Sequence of steps involved in agile and scrum release planning and management are:

 Determining the conditions of satisfaction: It focuses towards business goals, which could
date driven or scope boxed.
 Estimating the user stories: As a product backlog might have many stories, but in a release
you would need few stories which are needed; hence estimation of user stories is needed
(which can happen during the release planning or before the release planning). Estimating a
story is generally done using Fibonacci series which indicates its complexity and the size of
the story.
 Selecting an iteration length: Iteration length can vary depending on the length of the
release, if you have high uncertain project with frequent changes, you will need to have
small iterations.
 Estimating the velocity: Estimating the velocity can be done by the historical data, by
experimenting, and forecasting.
 Prioritizing user stories: Prioritization of user stories is generally done by the product owner
by understanding the importance as per customer requirements based on Moscow analysis,
time needed for the stories, human resources needed, etc.
 Selection of user stories and release dates: Team selects the user stories and the release
dates are calculated based team’s historical record.

Release management meetings in agile and scrum methodology provides the overall direction
for the agile projects to discuss the aspects on:

 Opening, product vision and roadmap: Senior executives and product owner will give the
vision and roadmap which discusses the vision and roadmap for the project and products.
 Conduction of satisfaction: Conditions of Satisfaction in simple words are story conditions
and constraints which will be given by the Product Owner to the team describing what the
user wants.
 Planning data: Scrum master presents the velocity, iteration length, stories from backlog,
etc. to plan the release.
 Issues and concern: Whatever issues have been identified till the release meeting will be
discussed by the stakeholders.
  Prioritization of stories: Though stories get prioritized before the release meeting, they are
yet re-evaluated in the meeting.
 Story mapping: Team will connect the dots in the stories and will visualize the stories to do
the mapping.
 Release scheduling and iterations: Distribution of stories in the upcoming iterations is
defined here based on the velocity, iteration length, etc.
 Present the release plan: Product owner will present the release plan
 Retrospective and closure discussion: To understand the lessons learnt in the meeting, to
discuss the things that went well, and which went bad.

Differentiation between Waterfall and Agile Release

Management

 In traditional or waterfall methodology, release of a software is in big-bang approach and

scope of work is precisely known to the project team members. In waterfall methodology,
customer is involved at the end of the product release. Since the customer is not involved
thoroughly, there will be some kind of delays in the proposed project plan.In agile and scrum
project management, release of a software is split into smaller chunks or functional
components with a specified time boxes called sprints. In this methodology customer has
regular and transparent view to check and approve every sprint (i.e. the work) developed by
the team.
 Release of the software will be done after the complete software is developed and
accordingly testing is done. Testing team gets less time for various reasons like detailed
focus on business analysis, design, and development.
Release of the software need not wait till the complete software package is ready, here
testing of every functional components (or sprints) is done in a progressive fashion.
 Any changes in the customer requirements are very difficult to embed in waterfall approach.
Any changes to the software being developed is easier to implement in the agile and scrum
methodologies.
 ITIL Emergency Change | Emergency Change
Management Process

What is Emergency Change in ITIL?

A Change is nothing but of shifting/transitioning/modifying/from its current state to a desired

future state.
Any change that is implemented to restore a service or to avoid an outage of a service,
especially when it impacts multiple users. Emergency changes would need Emergency CAB
approvals to validate and approve the change.
 RACI for Emergency Change Management

Emergency Change Management

Objectives

 The objective of Emergency Change Management is to:

 To define a standard procedure for handling emergency changes in the infrastructure.
 To understand the urgency of emergency changes and implement them without creating any
incidents.
 To ensure changes are successfully deployed, at the first attempt.

Emergency Change Management Process flow

In practical IT environment, change management operations would generally be executed as

per the below diagram:

Change Management Flow - Process Description of Emergency Change

Management

Change Trigger/Input
Emergency change is triggered when a major incident occurs or when an important issue is
about to happen (like a security upgrade, regulatory requirement, etc.)
Each and every emergency change ticket should be recorded so that it could be tracked,
monitored, and updated throughout its life cycle, no emergency changes can be implemented
based on verbal/ email communications.

Emergency Change Validation

When a Major Incident happens, an Emergency Change may have to be deployed into
Production (The trigger for Emergency Change Management is always via the Major
Incident). The Emergency Change management process gets triggered by logging an
Emergency Change in Remedy with appropriate categorization.

Change Manager will be notified of the Emergency Change.

Change Manager will validate the need for an Emergency Change in consultation with Major
Incident Manager who will be the Change Owner in this case.

Need emergency change

Change Manager, in consultation with Change Owner will ascertain whether the change is an
Emergency Change.

Gather Requirements
If an Emergency Change is triggered, Change Owner will be ready with all functional &
technical requirements and then document the impact of Change if implemented along with
back out readiness.

Convene ECAB meeting

Change Manager convenes the E-CAB so that the emergency change can be discussed for
approval. E-CAB is convened based on the urgency of the situation. This meeting may be
conducted via a bridge line opened by the Change Manager. Also, E-CAB members will be
made aware of the urgency of the meeting.
Change Manager works in close cooperation with Major Incident Manager towards
implementing the solutions for major incidents via changes. Following (but not limited to) are
the members of the E-CAB

 Change Manager
 <<Customer>> Service Manager
 <<Customer>> <<Role>>
 Major Incident Manager
 Service Delivery Managers

ECAB Approval
E-CAB will consider the Change from an impact/cost perspective and either approve or do
not give their approval. Back-out plan has to be there and would be a mandatory requirement
for approving the change.
While a verbal approval may act as a trigger for the change to be built, it is mandatory to
attach an approval email to the RFC. Without a documented approval, an Emergency Change
should not be implemented.

Build, Schedule and Implement Change

In case the Change is approved by the E-CAB, the Change is scheduled for implementation.
All relevant Technology Leads/ Experts are informed via a broadcast mail by the Change
Manager.
Relevant Resolver Group(s) would build, test and implement the change. Testing would be
performed based on availability of a Test Environment. Testing, in case of Emergency
Changes, is not detailed like that performed during normal or expedited change.
Change Owner coordinates the change with the Release Manager. Minimal testing is carried
out to gain the confidence and also to avoid post-implementation issues.
Release successful ?
Once the Release is deployed (Change implemented), Resolver Group checks if the
implementation is successful or not.
Change Manager will work with Major Incident Manager and ensure that the service is
restored at the earliest.

Rollback
In case change is not successful it would be rolled back by the Change Owner.

Complete RFC & Close

Once the Service is restored, RFC is updated by the Change Owner with the entire
information in all aspects.
In case of failed change, RFC is updated with the relevant details.

PIR
The Change Manager triggers a Post Implementation Review meeting with the Change owner
and other key stakeholders, CAB, on <<Day>> to check the impact of Changes on the
environment and also to understand whether the Change met its goal or not.

Change successful?
Once the Change is implemented, Change Manager checks if the implementation is
successful or not.
Change Manager will work with Major Incident Manager and ensure that the service is
restored at the earliest.

Reclassify change
Change is reclassified as normal/ standard change. Change Manager would seek a business
approval to classify the change as a normal/ standard change.

Template Name RACI for Emergency Change Management

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/05/RACI-for-Emergency-Change-
Management.xlsx
 Post Implementation Review Template

Post Implementation Review - Post Project Review

Post Implementation review or post project review is the investigation that is done by
all the prime stakeholders of change management, after implementing the change.

What is PIR in Change Management?

After change is done to the project, Prime stakeholders investigate and do post project
review.

PIR should be done for both successful and failed changes, its main objective is to learn from
the experience and document them for future references.

Who Should Do Post Project Review?

PIR activity should be chaired by change manager setting the direction for PIR meeting.

What to cover in Post Implementation Review?

The Post Project Review or PIR activity should be chaired by change manager setting the
direction for PIR meeting which generally starts with:

 Deciding the date, time, location, stakeholders needed and the method how the meeting
will
be organized
 Discussion on what went correct and what went wrong
  Examining the planned versus the actual results with respect to test plans, backout plans,
remediation plans, impact analysis, change collisions, etc.
 Lessons learnt from the implementation
 Finally developing description of the action plan, action plan for the change manager,
change builder, change tester & implementer.

Post Implementation Review Template

PIR should capture all the important information on a change request, detailing:

 Change number
 PIR number
 RFC created date
 RFC closed date
 PIR meeting date
 Change result
 Change description
 Change category
 Stakeholders involved (Change analyst, implementer, CAB staff, Change manager)
 Scheduled change implementation date and time
 Actual change implementation date and time
 List of CIs & Business Services that were impacted on account of the change
 Test results
 RCA if the change failed
 What was done well and what are the things where we could have done better
 Additional review comments/feedbacks
 Lessons learned
Etc.

Template Name Post Implementation Review

Template

Actual File Location http://itil-docs.com/wp-content/uploads/

2018/05/Post-Implementation-Review-
Template.docx
 Operation Level Agreement
Service Level Management

The purpose of SLM is to ensure that the service targets are created, negotiated, agreed,
documented, monitored, reviewed and reported to the customer. SLM acts like a liaison
between the customer and the service provider which sets the targets in terms of quality, time,
and scope as per the SLR and SAC.

The Service Level Management (SLM) process is responsible for seeking a realistic
compromise between the customers’ needs, expectations and the cost of associated services,
such that these are acceptable by both the customers and to the IT Organization. This also
aims to ensure that an agreed level of IT service is provided for all current IT services, and
that future services will delivered to agreed achievable targets. Service Level Management is
also responsible for ensuring that all appropriate Operational Level Agreements and
Underpinning Contracts are in place for monitoring the vendors and other groups.

Operational level agreement (SLA) is an agreement between the service provider and an
internal department of the same IT organization. OLAs define supporting services that has to
be provided by the service provider and its internal department. An OLA should describe the
services being delivered, service level targets, responsibilities of the IT Service Provider and
the internal department.

OLA Definition Process

OLA definition process will also be the same like SLA definition process which can be
mentioned as Planning, Development, Piloting, Publish, SLA Activation & Monitoring.
Planning process involves:

 Understanding the business requirements of the customer (with respect to scope of

services, timeliness, etc.) and translating it into IT requirements.
 Gather and analyze historical data from customer or from previous experiences (where
similar services were offered to any other customer).

Development process involves:

 Define, develop, negotiate and standardize SLTs for OLA.

 Encompass SLTs in OLA.
 Get approvals from service provider on OLA.
 OLA will contain details like:
1. Start, review and end dates
2. Scope of services
3. Roles and responsibilities
4. Operational hours
5. Holidays list
6. Service costs
7. Incentives and penalties
8. Define detailed metrics, KPI’S, etc.

Mandatory details needed for OLA development are:

 vendor’s name
 vendor id
 vendor type (elite, large scale business, medium scale business, small scale business)
 SLA id
 OLA id
 SLA name
 SLA type
 OLA name
 service hours
 start date and end date
 description of the OLA

Piloting
When the internal department is not sure about the realistic conditions in operations; internal
department does the piloting before base-lining the OLAs for the next quarter or half a year.
When it’s a Greenfield project, internal department pilots operations and observes the trends,
issues, and patterns for few months and then baselines OLAs. The service provider should
keep revisiting the piloted OLAs and redefine them after the observations.

Publish
In this phase OLAs are standardized and published. Management and stakeholders are made
aware of the consolidated OLAs.

OLA activation
In this phase OLAs are activated for the live IT operations. IT operations take the defined
OLAs as a baseline, and execute the IT operations.
Monitor
Monitoring is the main focus of SLM, which involves:

Reactive monitoring: monitoring the weekly reports, monthly reports, quarterly reports and
evaluates the quality of services.
Proactive monitoring: This is proactively advising the operations and ensuring that there are
no OLA misses or breaches, preventing penalties, preventing customer escalations and
threats.

Template Name Operational Level Agreement

Template
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/04/Operational-Level-Agreement-
Template.docx
 IT Asset Management Best Practices - 10 Steps
Covering ITAM Process

Given Ten IT Asset Management best practices in ITAM Process that will help you save
more costs and increase saving opportunities,boost overall productivity and good high
ROI on your IT assets.

Best Practices IT Asset Management

All IT Assets should be registered and uniquely identifiable

The IT Asset registration assigns unique asset tags to IT Assets that will serve as the unique
identifier during the asset’s lifecycle. Organization has a labelling system to ensure IT Assets
are labelled with the assigned unique asset tag that will enable positive identification during
the asset’s lifecycle.

Integrated asset management tool encompassing all the ITAM processes

Using different tools for different ITAM processes (financial management, disposal,
inventory, etc.) will make the data scattered and isolated at different places which in turn will
become complex to integrate and consolidate.

Identify your assets in inventory using automated discovery

Identifying and tracking assets in inventory is a very tedious and complex task as they would
be located in different locations/ regions as per the size of the organization. Hence using
discovery tools would be a good option for identifying and tracking the assets.

Commissioning and decommissioning of IT Assets should be done in a structured way

Perform commissioning and decommissioning of IT Assets in a structured way to ensure
efficient use of stock and keeping track of IT Assets usage. Organizations should have a
standard process for commissioning and decommissioning IT Assets.
Audits should be conducted to ensure the correct registration of IT Assets
Perform audits to ensure the correct registration of IT Assets; compare the registration with
reality.

IT Asset information should be in line with best practices and organizational security
policies
All IT asset information should be stored in one trusted source ensuring there are:

 Security policies are clear

 Connections to the IT Asset repository are secure
 Rights to access or modify IT Asset information is limited to designated organizational roles
 Roles are assigned to people based on organizational needs.

Adding / changing attributes of IT Asset information should follow defined processes

Any changes to IT asset information should be governed and performed in a structured way
following IT management processes like portfolio management, change management, etc.

Reporting on compliance
Reporting on compliance will enable organization to see whether they are compliant or need
to take remedial action on aspects like:

 Checks on EOL and retiring and disposing the assets as per the process
 Reconciliation between licenses and installations and usage.
 Software entitlements to ensure if there are enough licenses.

Always track the complete IT costs and value

Track and relate the IT Asset costs during the lifecycle, book value of IT assets, and business
value of IT services to ensure decisions can be made based on common business rules.

Understand the complete disposal procedures from the supplier

Understand the possible disposal procedures at the time of procuring an asset in association
with the supplier. Ensure data is erased using CESG approved data wiping software,
complying with state and country specific regulations and environmental laws.

Template Name IT Asset Management Best

Practices PDF
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/04/IT-Asset-Management-Best-
Practices.pdf
 What Is IT Asset Management - ITAM Benefits -
Why Business need ITAM

Information Technology Asset Management

What is IT Asset Management ?

IT Asset Management (ITAM) i.e Information Technology Asset Management is a business
practice which comprises of the set of processes for managing the IT assets with respect to
strategy, financial, procurement, inventory, retirement, and disposal, etc. (like software,
hardware, and services) to enable cost-efficient and timely delivery of business services
within the organization. IT Asset Management Benefits organization by integrating solution
process that manages the life cycle of information technology assets throughout the
organization.

IT Asset Management Benefits

An IT Asset Management system is an important, foundational piece of the overall systems

necessary to manage IT infrastructure. Without good IT Asset Management, an organization
will waste time and resources managing inventory, buying unnecessary equipment and
software, and maintaining license compliance for software. With a well functioning IT Asset
Management system, the organization can expect to reduce the total cost of ownership for IT
infrastructure and provide a solid foundation to keep the IT infrastructure operating
efficiently.

Crucially, ITAM enables the financial management of IT assets. A good IT Asset

Management solution provides cost-effective stewardship of IT assets and the resources to
provide IT services. To implement an accurate ITAM system, tools must be aligned to
processes that are event-oriented and traceable.

IT Asset Management is most importantly a management system supported by

organizationally defined metrics. Without a metric focus, there is no IT Asset Management
initiative. Furthermore, if there is no baseline for forming the asset repository, then it is
nearly impossible to relate the underlining assets to the critical business services that are
being delivered. Full business management of IT assets requires a repository of multiple
types of information about the asset, as well as integration with other systems such as supply
chain, help desk, procurement and HR systems.

IT Asset Management stores all of the relevant information about that asset, such as user,
location, asset type, model, serial number and more. Important information such as cost or
leasing information, decommission or replacement date, history, maintenance, repair, change
and upgrade information are all held within the ITAM data repository. Once an IT asset is
disposed of, all of the historical information about that asset is stored within the IT Asset
Management solution.

IT Asset Management is not just about storing data, it extends to deploying that data
successfully to operations and the synchronization of tasks. The automation of procedures is
vital in the coordination of large-scale projects. Not only does it help operators in their daily
tasks, the collection of data throughout operational processes reduces the risk of double
entries and human error.

The ultimate goal of IT Asset Management is that an employee has the relevant information
in the most appropriate format, at the right time. The information can be used for
management reporting, financial reporting, auditing and planning purposes. Data can be
linked between systems, usually using a single source of data rather than unnecessary
duplication of the same information in multiple places.

IT Asset Management and its Benefits

Value to Business

 IT Asset Management provides essential management information for utilizing IT assets

efficiently, economically and cost effectively throughout all stages of the IT asset’s lifecycle
 Provides the business with information to make the correct decisions in gaining a
competitive edge
 Reduces costs – specifically costs related to the physical or virtual IT assets of the
organization
 Manages IT asset resource utilization; Releases capital back into the business
 Minimizes risk of non-compliance to regulations
 Optimizes the quality of data and processes to improve business performance
 Helps improve the bottom line profitability of the business

Value to IT Organization

 Optimizes the IT infrastructure, resources and capabilities

 Evolves the IT organization to meet business needs
 Provides visibility in costs related to IT assets and business services
  Improves the procurement, change and retirement processes for IT assets
 Enables accountability by charging back to the business unit
 Supports Service Management processes with accurate IT asset information
 Foundational to the Service Asset and Configuration Management initiative in the IT
organization

Why does business need ITAM?

Finance lacks insight in IT Assets maintained in the organization, which is legally

required for assets on the Balance Sheet
In order to record IT spending as investment on the company’s Balance Sheet, organization
must know if it still exists and where it is contributing to the company’s business.

Avoids additional expenses and penalties

Organizations don't want to pay maintenance and support fees for IT Assets that are no longer
in use and they want to avoid risk penalties or unsupported issues for IT Assets in use.

Provides ability to effectively reuse assets

When IT Assets are returned before the end of their technical or economical life, they are not
effectively reused. Instead, organizations buy/lease new assets and leave the used assets on
the shelf.

Minimizes the compliance and regulatory risk

Knowing what IT Assets we have, where they are and where they are used for mitigates the
risk of being under licensed and the risk of violating regulations.

Reduce the time and effort required to gather information during audits
Provides information to internal and external auditors, that they require during audits as it
costs significant time and effort. Having the required information in a central repository and
being able to report on that easily will avoid reinventing the wheel every time, saving
significant amount of time and effort.

Effectively retire assets

IT Assets nowadays need to be retired and disposed of in compliance with environmental
regulations and data security policies. Also any residual value needs to be cashed.

Determines Total Cost of Ownership and actual asset value

Determines TCO includes costs of acquiring the asset as well as all costs associated with the
exploitation of the asset during its lifecycle and the actual asset value is the actual value at
any given time, not necessarily purchase price minus depreciation.

Determines ROI for IT Assets

Determines not only costs but also Return on Investment for IT Assets adds additional
information for decision making.
 Service Report Template – Example and Format

Service Report

Service reporting is a standard process for creating, maintaining, and managing the reports on
IT service management. Service reporting through Service Report Template brings
awareness and notifies the vital information to stakeholders about the service provider’s
operations through accomplishments, issues, breaches etc. These reports are created in
service report template to capture key information about IT operations, enabling the
stakeholders to make important decisions. Main deliverables of service reporting are report
templates and reports.

Service reporting produces different types of service reports for different levels of
management.

 Reports for Operational Management should be very detailed and contain complete details
of every transaction associated with IT services. These reports will generally contain bulky
volumes of data, and these reports are normally produced daily.
 Reports for Tactical Management should have very important details of IT services,
operations, and processes; these reports are produced weekly or monthly.
 Reports for High Level Management should present vital information which should be easily
understandable, accessible, and should give a snapshot of the IT operations and processes.

Service reporting will produce a variety of reports like Informational Reports, Analytical
Reports, Compliance Reports, Persuasive Reports, Trend analysis reports, and standard
reports (which are ad-hoc, daily, monthly, quarterly and annual).

Important tasks in service reporting are:

 Data collection
 Data processing, based on the audience
 Review
  Approval
 Data Publishing and distribution

Service Report Purpose

Purpose of Service reports are to give a summary of the overall quality, issues, risks,
compliments and complaints happening at the IT service delivery and operations.

Service Report Objectives

Provide accurate & useful information on IT services to the requestors and stakeholders.
Provide consolidated summary on IT services and operations.
Help the management to make quick and wise decisions with the reports provided.

Service Report Development Life cycle

Service Report Template

Data Collection

Data collection is the foundational activity for service reporting which involves collecting the
data about the organizational IT services and its associated information.
Data collection is performed through regular checks on IT services and its information from
different IT processes. Data collection can also be performed automatically through the usage
of automated tools and technology.

Data Processing

Data processing is the activity which organizes the data into a structure to present the data
into organized and useful information. Data processing also eliminates discrepancies, like
redundant information, inconsistencies, and inaccuracies in the drafted reports.

Data Review

Data review is the activity to verify and validate the data collected with respect to the
requiremnets made by the different stakeholders. It identifies and evaluates the ability of
processed information and determines whether if it fits the business needs. Reviews are
performed both technically and editorially.

Data Approval

Data approval is the activity which validates, authorizes, and approves the reports so that they
can be sent for distribution.
Data Distribution

Data distribution is the activity which publishes and distributes the data to the requestors and
management. This activity publishes the reports in appropriate formats, fonts, and structures
using different tools.

Template Name Service Report Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/04/Service-Report-Template.docx
 IT Asset Management - Asset Management
Process

IT Asset Management Process

IT Asset Management (ITAM) is a business practice which comprises of some prime Asset
Management process like:

Financial management for IT assets which defines a standardized process for establishing
the budgeting, accounting, and charging goals, policies, and various other financial aspects of
IT assets.

IT Asset procurement which defines a standardized process for procuring IT assets from a
supplier at economic costs and with good quality.

IT Asset inventory which defines a standardized process for tracking, arranging and
managing the organization’s stock of valuable IT assets in structured way.

Software license management which defines a standard process to manage and optimize the
purchase, deployment, maintenance, utilization, and retirement of software within the
organization.

Asset Disposal which defines a standard process to decommissioning the IT assets (due to
damage/ loss/ theft/ EOL) as per the organizational, legal, and environmental requirements.

IT Asset Management Scope

In Scope
  Classifying the IT asset portfolio according to type, model, manufacturer, and so on, from
introduction to disposal whether in the productive or non-productive state
 Managing the lifecycle of IT assets
 Associating IT assets to people, places, things, cost center, cost type, purchase order and
contract
 Tracking costs related to IT assets
 Tracking contracts related to IT assets
 Reconciling data on the IT asset identifier
 Recording IT asset attributes useful for the Service Management processes

Out of Scope

 Purely Configuration Management – configuration items (CIs) will be included within the
total number of assets managed but these will appear as physical items
 Change or Release Management for configuration items
 Associating CIs with CIs
 Tracking changes related to CIs or the fixed asset register within accounting or enterprise
resource planning terminology
 The central contract management solution
 Reconciling data on the CI name
 The Service Management solution

IT Asset Management Objectives

The objective of IT Asset Management is to:

 To give real time and accurate view on IT assets, creating an IT Asset repository that is up to
date and accurate information for decision making and establishing compliance with
regulations and policies.
 To control assets under contracts ensuring the organization doesn’t use IT assets more than
what is licensed for, or pay for IT Assets which they no longer have or use.
 To retire securely and effectively to ensure adherence to environmental regulations and
data security policies and improve IT asset reuse.

IT Asset Management Processes

Financial Management For IT assets - Process flow
 Financial Management For IT assets

Step 1: IT Finance Manager creates Fixed Assets (Capital Assets) in the Fixed Asset Register
(FAR).
Step 2: IT Asset Manager relates the fixed asset number to the corresponding assets in the
Asset Management System (AMS).
Step 3: IT Asset Manager determines the book value and residual for assets.
Step 4: IT Finance Manager adjusts the Fixed Asset Register (FAR) based upon the
impairment information received from the IT Asset Manager.
Step 5: IT Finance Manager determines the book value for fixed assets.
Step 6: Accounts Payable receives the invoices sent by suppliers.
Step 7: IT Asset Accounts Payable Manager books all invoices. Invoices must be matched to
a contract or a purchase order and the individual PO Lines or Assets involved.
Step 8: The IT Accounts Payable Manager verifies against documents like purchase order,
receipt of assets, asset invoice, inspection of unpacked assets.
Step 9: Accounts Payable pays the invoice.

IT Asset Requisition - Process Flow

 IT Asset Requisition - Process Flow

Step 1: IT Asset Coordinator reviews the IT asset request. Verify if the request and the
request lines containing the IT assets are valid.
Step 2: IT Asset Coordinator checks if decommissioning of IT Asset is required based upon
the individual request lines.
Step 3: IT Asset Coordinator identifies which type of IT Asset component need
decommissioning.
Step 4: IT Asset Coordinator checks whether the requested IT Hardware and Service Assets
can be delivered, are part of the IT Catalog, and that they are fit for purpose.
Step 5: IT Asset Coordinator updates the IT asset request stating if the IT Asset is a valid or
invalid based on the outcome of the IT Asset Planning and Portfolio Management activities.

IT Asset Procurement - Process Flow

 IT Asset Procurement - Process Flow

Step 1: IT Asset Procurement Manager creates the IT asset purchase request.

Step 2: IT Asset Procurement Manager uses the vendor selection and contract selection
activities to determine the best vendor and contract options for the purchase.
Step 3: IT Asset Procurement Manager requests a quote for the purchase order's non-catalog
items from the vendor
Step 4: IT Asset Procurement Manager receives a quotations from the suppliers.
Step 5: IT Asset Procurement Manager obtains technical & financial approvals.
Step 6: IT Asset Procurement Manager orders the IT assets from the selected vendor. The
order is based upon pre-approval or on the quotation and approval.
Step 7: IT Asset Procurement Manager closes the order when all IT assets ordered are
received in full and after all invoices are paid. Before closing, validation is taken from other
relevant processes and the organization.

Software License Management – Process Flow

 Software License Management – Process Flow

Step 1: Software Asset Manager checks if sufficient licenses are available for the requested
software.
Step 2: Software Control and Distribution Manager processes the entitlement and/or license
for software.
Step 3: Software IT Asset Manager receives the proof of software license.
Step 4: The Software Control and Distribution Manager monitors the software entitlements
and types of licenses.
Step 5: Software Asset Manager audits the license, entitlement & usage pool.
Step 6: Software IT Asset Manager checks and determines if product de-installations or
license purchase is required to be compliant with both external legal regulations and internal
company policy. Accordingly Software License Analysts will revoke or de-install in order to
achieve compliancy.

Inventory Asset – Process Flow

 IT Asset Inventory – Process Flow

Step 1: IT Asset Inventory Manager checks if the requested IT Assets are in stock.
Step 2: IT Asset Inventory Manager checks if Asset needs to be refurbished. If the asset
needs refurbishment, IT Asset Inventory Manager initiates the process to refurbish IT Assets.
Step 3: IT Asset Inventory Manager determines the minimal stock levels for the IT Catalog
items and replenishes stock as necessary.
Step 4: IT Asset Inventory Manager determines the suitable method of tracking
identification. Determine how and via which attributes IT Assets should be identified.
Step 5: IT Asset Inventory Manager tags the IT Asset. The IT Asset tag is used for tracking
the asset.
Step 6: IT Asset Inventory Manager notifies the IT Asset Manager that the IT Assets are
tagged and can be deployed within the organization when needed.
Step 7: IT Asset Inventory Manager audits the inventory of the entire organization both on
deployed assets (installed base) and operational stock assets.

IT Asset Retirement and Disposal – Process Flow

 IT Asset Retirement and Disposal – Process Flow

Step 1: IT Asset Coordinator determines whether IT assets must be retired or disposed.

Step 2: IT Asset Coordinator checks if replacement is required for the assets in use (As per
the organizational policies).
Step 3: IT Asset Coordinator verifies if there are IT assets in use and if there are any
dependent assets.
Step 4: IT Asset Disposal Manager determines if multiple assets can (or will) be reused.
Decide whether asset components can and will be reused.
Step 5: IT Asset Disposal Manager carries out the disposal or resell procedures as per the
policy and guidelines. Also removes all components from the asset (for future (re)use of for
disposal).
Step 6: IT Asset Disposal Manager receives the disposal certificate from the disposal
company.
Step 7: IT Asset Disposal Manager notifies the IT Procurement Manager and IT Financial
Manager that the disposal is complete. This notification is required to close and satisfy the
order to the disposal company.
 IT Asset Management Policy | ITIL Asset
Management

What is IT Asset Management Policy

IT Asset management policy is a management directive that significantly influences the
IT asset management processes and procedures.

ITIL Asset Management Policies are written instructions which specify

 What needs to be accomplished

 Who are the audience for the policy
 Why is the policy needed

An IT asset management policy sample must contain:

 Defined in simple understandable language

 Implemented by building about awareness and education
 Periodically reviewed and updated to maintain relevance

Guidelines for IT Asset Management Policy Operations

Guidelines for Financial Management for IT Assets

1. Define the procedures for activities like budgeting, accounting, invoicing, etc.
2. Establish a database for tracking budget and costs associated with assets, accounting details,
invoicing details, and auditing details.
3. Define a budget for all assets, comprising software, hardware, facility assets, compliance
requirements, etc.
 4. Define an invoice payment mechanism to capture the details of the invoices (invoice
number, vendor name, invoice date and time, purchase order number, invoice items,
quantity, unit price, total price and etc) and payments.
5. Perform accounting on fixed assets, current assets and intangible assets.
6. Develop depreciation calculation procedure for all hardware and software assets.
7. Consolidate asset values and replacement costs.

Guidelines for IT Asset Procurement

1. Define the policies and standards for all procurement internal activities.
2. Develop supplier management plans like:
o Escalation process
o Supplier contingency plan
o Supplier contract renewal and termination procedures
3. Define the templates for documentations like purchase request (PR), request for quotation
(RFQ), request for information (RFI), and request for proposal (RFP’s).
4. Establish a database for procurement which will track all the details and activities of the
asset procurement process.
5. Categorize the suppliers and their respective products.
6. Establish a bidding system, defining the procedure for contacting a list of suppliers and
selection.
7. Define and negotiate the contracts, service level agreements (SLA’s), and penalization
procedures. Key aspects to be considered in negotiation are:
o Payment frequency and procedure
o Asset acceptance criterion
o Contract closure formalities
8. Define a method to submit purchase requests (PR) to the supplier, capturing all the details of
the needed asset.
9. Define the conditions and criteria, when a PR should seek approvals from the Procurement
lead and IT Asset Manager.
10. Define a team to register, receive, and inspect the assets with respect to the purchase
requests submitted.

Guidelines - IT Asset Management Software License

1. Classify and group the assets licenses into categories based on license type, agreements,
costs, and renewal dates, etc. to define an organized structure.
2. Identify the license life span, and define a mechanism to track the license expiration dates
and renewals dates.
3. Define a mechanism to get detailed information on purchased licenses and installed licenses.
4. Define a mechanism to get information on the unauthorized software in the organization.
5. Define a mechanism for tracking the proof of purchase on licenses.
6. Define a mechanism to notify the license expiry details.
7. Define a procedure for optimum utilization of licenses especially for instances like
transferred licenses.
8. Define procedures for license renewal and maintenance.
9. Define procedures for license entitlements.
10. Develop a procedure for associating the requested assets with its respective software
licenses and entitlements.
11. Develop a standard procedure for attributing software license entitlements and software
license installations to the requested assets.
Guidelines for IT Asset Inventory

1. Establish IMIS (Inventory Management Information System) which will track all the IT asset
details.
2. Develop the inventory documents like stock requisition, stock transfer receipt, stock return,
etc.
3. Define a method to group your assets which enables you to understand the context and to
manage them easily.
4. Define a method to track and identify the assets and its attributes:
o Record all hardware serial numbers, model numbers, etc.
o Record all software names, versions, and editions, etc.
5. Set up an assets handling team to receive and register the assets in IMIS (Inventory
Management Information System).
6. Define a procedure for communicating with other teams like financial management and
procurement in clearance of the invoices.
7. Define a procedure for the asset handling team to move the assets at the requestor’s
premises.
8. Define a procedure to reserve and ship the assets requested through the asset catalog.
9. Define a check-in and check-out policy for all assets being moved from inventory to live
environment and vice versa.

Guidelines for IT Asset Retirement and Disposal

1. Target Zero Waste Goal.

2. Define an asset disposal procedure encompassing identification of assets, assessment of
assets, approval, disposal methods, and reporting.
3. Define a status snapshot mechanism for an asset to represent whether if the asset is in
“stock”, “operational”, “repair”, and “disposal” statuses.
4. Define data security procedures to protect the confidential data.
5. Develop Request for disposal (RFD) forms capturing the important details of assets.
6. Define asset disposal methods for assets based on the utilization rate, financial value, asset
lifetime, assets category, etc.
7. Implement data security procedures on assets before disposal.
8. Define a procedure for mass asset disposal.

IT Asset Management Policy - Roles and Responsibilities

Responsibilities of IT Asset manager

IT Asset manager is accountable for the whole asset management practice and its
encompassing processes and activities. IT asset manager administers, supports, and manages
the contracts for technology spending on IT assets across the organization. He/ She ensures:

1. Definition and facilitation of communication between the organization and its suppliers in
order to deliver products and services according to plan and within budget.
2. Providing advice to management and staff on IT asset management related processes,
models, improvements, and best practices.
3. Continuous improvement on the ITAM-process model framework and alignment with the
relevant departments to fine-tune the processes.
Responsibilities of IT Financial manager

Asset Financial Manager is accountable for the financial management for IT assets process
and operations. He/ She ensures:

1. Definition of process, policies, and standards as per business requirements.

2. Execution of financial operations (budgeting, accounting, invoicing, and payments) in sync
with defined policies.
3. Appropriate cash flow management to ensure proper funding with minimal financial charges
and in line with business requirements.
4. Analysis of opportunities and development of financial models with respect to the strategies
defined.

Responsibilities of IT Asset Procurement Manager

IT Procurement Manager is accountable for the asset procurement process and operations.
He/ She ensures:

1. Definition of process, policies, and standards as per business requirements.

2. Execution of the procurement operations (bidding, selection of the suppliers, quoting prices,
negotiating the contracts and agreements) in sync with defined policies.
3. Developing long term procurement strategy of purchasing materials with visibility and
alignment with corporate strategy while considering the continuity of supply with a
contingency plan.
4. Revenue of bought outs & its associated services as per project schedule on a monthly basis.
5. Identification of suppliers, establishment of contracts, cost models and price agreements. It
also develops alternate suppliers and solutions.

Responsibilities of Software License Manager

Software license manager is accountable for the software license management process and
operations. Software license manager has the goal to utilize software licenses as efficiently as
possible and ensure that the organization is in control of its software licenses. He/ She
ensures:

1. Definition of the process, policies, and standards.

2. Execution of the operational activities like license distribution, administration, control, and
renewal of licenses.
3. Tracking, evaluating and managing of a wide variety of software licenses and usage.
4. Support during audits with respect to software asset licenses.
5. Up-to-date knowledge on developments in the market with respect to software license
models and entitlements.
6. Compliance checking to reconcile license usage to plan for renewals.

Responsibilities of IT Inventory manager

Asset Inventory manager is accountable for the complete asset inventory process and
operations. He/ She ensures:

1. Definition of process, policies, and standards as per business requirements.

 2. Execution of the inventory operations (stocking, stock replenishment, stock inspection, and
stock returning) in sync with defined policies.
3. Reviewing all the purchase requests and purchase orders processed.
4. Receiving the goods, physical checking, appropriate storage and maintenance of records.
5. Conducting physical count regularly and ensure inventory accuracy.
6. Monitoring and reporting of all out of stocks, below safety stocks and expected out of
stocks.
7. Providing demand shaping recommendations.

Responsibilities of IT Asset Disposal Manager

Asset Disposal Manager is accountable for asset disposal process and operations. He/ She
ensures:

1. Definition of the process, policies, and standards.

2. Retirement and disposal of obsolete assets at the right time in the right way to avoid risks
and non-compliances.
3. Disposal of garbage in accordance with the waste management plan.
4. Risk free asset disposal process including packaging, transportation and warehouse storage.

Template Name IT Asset Management Policy

Template
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/04/IT-Asset-Management-Policy-
Template.docx

Template Name IT Asset Management Policy PDF

Document
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/04/IT-Asset-Management-Policy-PDF-
Document.pdf
Service Catalogue Template | ITIL Service Catalog

Service Catalogue Management

Service catalogue management (SCM) is the process responsible for creating, updating, and
maintaining the service catalogue in ITIL service. An ITIL service catalog contains accurate
information on all operational services in the IT infrastructure which will act as a medium for
users and customers to know about the available services in an organization. Service
Catalogue Template which lists all IT services, including information related to a specific
service that is presented in service catalogue.

Service Catalogue
A service catalogue briefs the information about the services, services description, its costs,
and SLAs associated.
A service catalogue can be viewed from two perspectives, from the business department and
from technical departments, as:

 business service catalogue

 technical service catalogue

The purpose of SLM is to provide an accurate and updated single point of view of current/
live or operational IT services that are available for IT stakeholders.
ITIL Service Catalog - Objectives

Services Catalog Template

 Provides an accurate and updated view of current IT services that are available.
 Provides an easy interface, so that customers and internal users can select and order
items/services that are currently available in the IT infrastructure.

Service Development Process

Development of Service Catalogue can be defined as Design, Draft, Classification,
Verification and validation, & Publish.

Design

Important tasks to be considered in the design phase of a service catalogue are:

 Define the architecture and structure for service catalogue portal or database.
 Define the service catalogue template.
 Define the user groups that can access the service catalogue portal or database.

Draft

Information on the operational services and retired services is collected from different service
owners, process owners and IT staff. Information on all services is gathered, analyzed, and
consolidated as a draft in one place.

Classify

After defining the services, classification and categorization of services is done as per the
business needs and processes defined.
Services are usually classified based on category, impact, urgency, priority, financial value,
and frequently requested services.

After the services are classified and categorized, an association is established between:

 IT services and business units

 IT services and the underlying CIs.

Verify and validate

Drafted services are verified to check that all accurate and complete details like price,
specifications of a service, delivery time, etc., are collected.
Then the drafted services are validated by checking the existence of identified IT services in
the operational environment.

Publish

After the services are verified and validated, the services are populated in the service
catalogue and published to different stakeholders as per their privileges.
Services published in the service catalogue will be visible only for the authorized users and
IT staff.
Mandatory details needed for this phase are:

 service name.
 service id.
 description of the service.
 cost of a service.
 service owner.
 quantity.
 SLAs associated.
 date requested.
 impact of the service requested.
 urgency of the service requested.

Template Name Service Catalogue Template -

Word
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/04/Service-Catalog-Template.docx

Template Name Service Catalogue Template -

Excel
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/04/Service-Catalogue-Template.xlsx
 IT Service Management | ITSM vs ITIL | ITSM
Tools List

IT Service Management
IT Service Management (ITSM) is a branch of science in IT industry, which focuses on
management and delivery of IT services to the customer, adhering to time, cost, scope and
quality parameters defined by the customer. We will also look in detail difference between
two ITSM vs ITIL.

IT Service ManagementIT Service Management (ITSM) is a practice which details

procedures for providing and managing the IT services in an effective and efficient way,
ensuring provision of customer satisfaction to the customers.

IT Service Management is an important, foundational piece of the IT infrastructure to deliver

IT services. Without good IT Service Management, an organization will waste time and
resources performing redundant, ineffective, unnecessary tasks. Having ITSM practice in an
organization will avoid loss of reputation (as a service provider) and loss of money as
penalizations. With a well functioning IT Service Management, the organization can expect
to deliver:

 better customer satisfaction

  more effective and efficient IT services
 better quality in IT services

To set up a strong ITSM practice, an organization would require people with strong
knowledge in ITSM, ITSM processes (which can be referred from ITIL, MOF, ISM, etc.),
and ITSM tools which must be aligned to the business requirements of the organization.

ITSM Best Practice Frameworks

In ITSM there are many practices that have incepted, some of the prominent are ITIL (IT
Infrastructure Library), MOF (Microsoft Operations Framework), ISM (Integrated Service
Management), and recently a new digital service management approach is VeriSM.

Value to Business

 Resolves IT issues quickly and will enable to run business operations.

 Provides the business with information to make the correct decisions with respect to IT
investments, technology, vendors, etc.
 Manages IT services and run the business operations without any breakdowns.
 Minimizes risk of penalizations and non-compliance to the agreed contracts
 Improves the quality of IT services to improve business performance
 Helps improve the bottom line profitability of the business

Value to IT

 Provides defined, repeatable processes, procedures, metrics, roles and responsibilities

 Improves the customer satisfaction to IT end users
 Proactively identifies, mitigates and tries to avoid IT issues

Practical understanding of ITSM

Imagine if a company called <Available > is managing and providing internet service to a
business/ residential customers
Or
Imagine if a company called <Use App> is developing an application and providing
application support services to another company
Or
Imagine if a company called <Data Manage> is managing a data center for another company

Here, all the above 3 instances, companies are involved in managing and delivering a service
(i.e.: Internet/ Application development and Support/ Managing a Data center) which means
they are involved in ITSM.

Let me explain more in detail with an example:

Available LLP company is an internet service provider in US, and its goal is to be the best
internet service provider in the city New Jersey.

In order to achieve its goal, it needs to provide good internet service which is reliable,
available, with good bandwidth (performance), security, etc.
To provide good internet service with reliability, availability, with good bandwidth
(performance), security, etc. the company Available LLP should have:

 Good helpdesk staff to provide support on phone calls / and onsite; and network engineers
who can configure the cables, routers, etc.
 Good cabling system (supplied by company A), routers & wifi routers (supplied by company
B), gateways (supplied by company C), base station antenna (supplied by company D), etc.
configured with backup plans and continuity plans.
 There should be good technicians and engineers, with defined processes and procedures to
do regular maintenance to check proactively and reactively
 There should be defined roles who are accountable & responsible of doing specific tasks

Performing all these tasks is doing IT Service Management in internet service provision.

Data Manage LLP company is Data center company in US, and its goal is to be the best
data center company in the US.
To provide data hosting service with reliability, availability, security, etc. the company Data
Manage LLP should have :

 Skilled resources and knowledge to manage the equipments in DC like racks, servers,
application delivery controllers, cables, WAN optimizers, routers, switches, bridges,
repeaters, SAN, NAS, etc.
Stocked spare parts
 Execution of timely backups, restoration, and archival of data as per the defined SLA’s.
 Followed change management approvals before making any changes in the data center
environment.
 Defined governance structure, roles, and responsibilities.
 Defined of escalation procedures & operations procedures

Performing all these tasks is doing IT Service Management in Data center to store all the data
at one place and disseminate as per the requests.

ITSM vs ITIL : Difference

ITSM ITIL

ITIL is one such best practice framework (for

ITSM), which is a collection of 26 processes and 4
ITSM is a branch of science in IT to manage the IT
functions providing guidelines for managing the
services. Managing the IT services involves
lifecycle of IT incidents, problems, service
various tasks like installation/ reinstallation/
requests, changes, release, etc. ITIL framework is
modification of IT components (hardware/
classified into 5 process areas as Service Strategy,
software/ etc.)/ upgradation/ etc. and the
Service Design, Service Transition, Service
purpose of doing these tasks is to deliver the IT
Operations and Continual Service Improvement
services without any interruption ensuring
where all the 26 processes and 4 functions are
customer satisfaction.
allocated their respective places in a lifecycle
approach.

ITSM is a branch of science in IT, an approach for ITIL framework is owned by Axelos, which was
managing the IT services and it is not owned by earlier owned by UK Government. ITIL can be
anyone. adopted and adapted as per the requirements.

ITSM has no defined lifecycle. ITIL is a lifecycle based approach.

ITSM Tools List

Managing IT services in an organization will require people, processes and the most
important tools for managing IT services. Some of the generic tools used in ITSM are:

Monitoring tools: To monitor the IT infrastructure (servers, networks, routers, computers,

storage, etc) availability, capacity, performance, security issues, etc.

Service desk tools: To log and manage the lifecycle of service desk calls.
Backup and disaster recovery tools: To perform backup and recover data.

Self service portal: To help the end users to request/ order services or IT components, to find
information, to resolve issues, etc. Self help functionality acts as a front-end for end users to
be defined offering different menus, screens, buttons, etc providing direct interface to
request/ order services.

Configuration and build management tool: To identify, track and assign unique numbers
for software and hardware configurations.

Security management tools: To protect the integrity of the network, systems and
applications, guarding against intrusion and inappropriate access and usage.

Content management systems: To store all the content of the IT service provider in various
repositories like knowledge base, known errors, service catalogue, employee information, etc.
Email systems: To send, receive, backup, recover, etc. emails.

Project management tool: To manage the status of the projects in the IT organization.

Dashboard tools: To provide an overview of the overall IT service performance.

Remote Logging Tools: To enable the support staff and other escalation teams to conduct
investigations to provide more efficient and effective support.
 Service Charter Template

Service Charter
IT Service Charter is a high-level document for any new or significantly modified services
and its approach to develop a new/ modified service. Customer Service Charter document
will consolidate all the necessary information on the purpose, requirements of the new/
modified service, scope, resources needed, roles and responsibilities, service acceptance
criteria, KPI’s and metrics, constraints, etc.

Service Charter Template

The Service Charter Template is the document that will provide clear communication to the
Service Design process area with all the necessary information for designing a new service.

Purpose of Service Charter

Service charter documents the necessary information required by the service design manager
to design the service for transition and operations. Customer service charter is created during
the service strategy phase which will provide clear direction to design the service for the
benefit of service design process owners and managers.

The intended audience of the service charter template is the Service Design Manager, Service Design
Process owners and managers and Service Owners.
Objectives of Service Charter

 To provide a high-level description of a new or changed service to the Service Design

stakeholders.
 To provide the service level requirements, service acceptance criteria, and goals of the
customer.

Service Charter Development Life cycle

Development of a service charter can be defined through 4 stages as analysis, budgeting,

approval, and publish.

Analysis: An understanding is developed about the service provider’s current IT operations.

Assessments and analysis is made on current services, market spaces, risks associated,
customer’s history, customer needs, customer feedbacks and recommendations, competitors,
and competitors’ services. These assessments are made in form of: interviews, questionnaire,
direct observation, simulations, etc.

Budgeting: This stage involves predicting the funds necessary for services to deliver the
agreed upon IT service. Budgets are allocated for every new IT service proposed.

Approval: In this stage, service portfolio manager makes the decision of approving services
or rejecting, after careful evaluation of the analysis.

Publish: In this phase, chartered service is documented with high level descriptions with
respect to availability, capacity, performance expected, security, continuity, etc. and are
standardized and published. Accordingly, the service charter is disseminated to all the
relevant stakeholders in service design process area (availability management, capacity
management, information security management, IT service continuity management, etc.)

Template Name Service Charter Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/03/Service-Charter-Template2.docx
 Service Level Agreement Template

Service Level Management

The purpose of Service Level Management (SLM) is to ensure that the service targets are
created, negotiated, agreed, documented, monitored, reviewed and reported to the customer.
SLM acts like a liaison between the customer and the service provider which sets the targets
in terms of quality, time, and scope as per the SLR and SAC.

The Service Level Management (SLM) process is responsible for seeking a realistic
compromise between the customers’ needs, expectations and the cost of associated services,
such that these are acceptable by both the customers and to the IT Organization. Service
Level Management is also responsible for:

 Performing service reviews

 Creating reports on SLA’s, OLA’s & UC’s
 Defining metrics and KPI’s

What is a Service Level Agreement ?

Service level agreement (SLA) is a document/agreement that describes the scope of services,
details of services, availability, quality, recovery times, etc.

SLA Definition Process

Defining SLA should involve participation of all the service owners, process owners, and all
other stakeholders from the IT organization. This definition process can be mentioned as
Planning, Development, Piloting, Publish, SLA Activation & Monitoring.

Service Level Agreement Template

Planning process involves:

  Understanding the business requirements of the customer (with respect to scope of
services, timeliness, etc.) and translating it into IT requirements.
 Gather and analyze historical data from customer or from previous experiences (where
similar services were offered to any other customer).

Development process involves:

 Define, develop, negotiate and standardize SLTs for SLA.

 Encompass SLTs in SLA.
 Get approvals from customer on SLA.
 SLA will contain details like:
 stakeholders involved
 stakeholders involved
 start, review and end dates
 scope of services
 roles and responsibilities
 operational hours
 holidays list
 service costs
 incentives and penalties
 Define detailed metrics, KPI’S, etc.

Mandatory details needed for SLA development are:

 vendor’s name
 vendor id
 vendor type (elite, large scale business, medium scale business, small scale business)
 SLA id
 SLA name
 SLA type
 service hours
 start date and end date
 description of the SLA

Piloting

When the service provider is not sure about the realistic conditions in operations; service
provider does the piloting before base-lining the SLAs for the next quarter or half a year.
When it’s a Greenfield project, service provider pilots operations and observes the trends,
issues, and patterns for few months and then baselines SLAs. The service provider should
keep revisiting the piloted SLAs and redefine them after the observations.

Publish

In this phase SLAs are standardized and published. Management and stakeholders are made
aware of the consolidated SLAs.
SLA activation

In this phase SLAs are activated for the live IT operations. IT operations take the defined
SLAs as a baseline, and execute the IT operations.

Monitor

Monitoring is the main focus of SLM, which involves:

Reactive monitoring:

monitoring the weekly reports, monthly reports, quarterly reports and evaluates the quality of
services.

Proactive monitoring:

This is proactively advising the operations and ensuring that there are no SLA misses or
breaches, preventing penalties, preventing customer escalations and threats.

Template Name Service Level Agreement

Template
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/03/Service-Level-Agreement-Template-
2.docx
 Roles and Responsibilities in ITIL with a RACI

ITIL RACI Template Excel

ITIL Roles
Executive Sponsor

The Executive Sponsor is accountable for the framework implementation and responsible for
securing spending authority and resources to implement and manage the Services and
Processes. The Executive Sponsor is a vocal and visible champion who legitimizes goals and
objectives, involved in major activities, is the ultimate decision-maker, has final approval of
all scope changes, and signs off on approvals to proceed to each succeeding phase.

Service Domain Owner

The primary responsibility of the Service Domain Owner is to ensure the processes within the
Service Domain provide support to the Service Owners, who have accountability for the
Services that are provided. The Service Domain Owner is accountable for all the Processes in
the Service Domain, the interfaces and Process interdependencies and for measuring and
maintaining Process maturity levels.

The Service Domain Owner ensures proper resourcing, the appointment of Process Owners,
and the strategy for each Service Domain. The Service Domain Owners work jointly to
ensure proper handoffs between the Service Domains. The Service Domain Owners represent
their Service Domain on the upper governance boards, while establishing governance boards
to handle Domain-specific matters related to policy, standards.

Service Domains are usually aligned with the stages in the Service Lifecycle.

Service Owner

Each Service needs an owner. The Service Owner is accountable for the Service without
regard for where the technology, processes, or other enablers reside. In short, the Service
Owner owns the end-to-end Service even if he or she relies on other Services to provide the
Service. For example, the Business Service supporting Accounting will rely on multiple
Infrastructure Services. The Service Owner will be the primary stakeholder in these
supporting Services. This owner wants to ensure that these supporting Services enable his or
her Service to be successful.

Service Manager

This role is responsible for managing the end-to-end lifecycle of one or more IT Services.
The Service Manager:
Provides leadership on the development of the business case and process architecture,
Service deployment and lifecycle management schedules,
Performs Service cost management activities in close partnership with other organizations
such as operations, engineering, and finance.

The Service Manager is also responsible for the controls built into the Service, both
supporting the processes and corporate controls (e.g., SOX).

Process Owner

As with the Service Owner, the Process Owner is the one individual accountable for the
success of the Process. The Process Owner will ensure the Process is being performed as
agreed and documented in the Process documentation. This Process Owner is concerned with
the overall quality and performance of the Process, especially the measuring of health and
performance of the Process.

This is obtained through the definition of Key Performance Indicators (KPIs) and frequently
reviewing the metrics, and acting as necessary. These metrics represent a scale of measuring
managed Services, Processes, and activities and are used to identify trends, productivity,
resources, and opportunities for improvement.

Process Manager

The Process Manager will manage the day-to-day activities of the Process. In matters that
pertain to the Process, the Process Manager is answerable to the Process Owner and performs
the day-to-day operational and managerial tasks demanded by the Process activities. While
there should be one Process Owner for each process, there may be multiple Process Managers
for that same Process. The Process Manager does not necessarily fall within the Process
Owner’s organizational chain of command.
Process Analyst

The Process Analyst is responsible for Process execution, supporting Process development,
design and implementation, implementing the process, and providing continuous process
improvement support.

Template Name ITIL RACI Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/03/ITIL-RACI-Template-Swapnil.xlsx
 IT Service Continuity - Plan and Template

Introduction to IT Service Continuity Management

IT Service Continuity Management (ITSCM) defines a standardized procedure for

developing restoration, recovery and continuity mechanisms for IT Infrastructure. It ensures
that the IT services are available, continual and recovered within agreed timescales as defined
in SLA.

IT Service Continuity Management (ITSCM) works closely with Business Continuity

Management (BCM) and supports the business goals. ITSCM plans differ by region, size of
the organization, type of the business operation, and etc.

ITSCM Process Description

IT Service continuity management subprocesses can be defined as:

Initiation

Initiation process involves defining the ITSCM policy and communicating throughout the
organization so that all those concerned are aware of the need for ITSCM.

In the initiation phase, IT Service Continuity Manager will identify define the scope of
ITSCM and identifies the appropriate roles and responsibilities for ITSCM related activities.
S(he) will determine of the command and control structure required to support a business
interruption.

For the identified roles and responsibilities, the ITSCM manager will identify and allocate
resources and familiarize and/or train staff to accomplish the ITSCM related tasks, like BIA,
Risk
Assessment, etc.

Requirements analysis

Based on the business plans and business continuity plans, IT service continuity management
staff will do the Business Impact Analysis, and will identify the Vital Business Functions and
related IT services. They shall quantify the impact to the business due to loss of service (such
as it could be a ‘hard’ impact that can be precisely identified – such as financial loss – or
‘soft’ impact – such as public relations, morale, health and safety or loss of competitive
advantage).

Strategy development

Based on the BIA and Risk Assessment, IT service continuity management staff will prepare
the IT Continuity Strategy with an optimum balance of risk reduction and recovery or
continuity options.

The strategy would typically include:

Risk reduction by taking suitable prevention measures such as:

 Define recovery procedure

 Build components redundancy
 Improve availability detection
 Refine maintenance scope, frequency
 Appropriate recovery mechanisms (such as Manual Workaround, Reciprocal Arrangements,
Gradual Recovery, Intermediate Recovery, Immediate Recovery

Planning and Implementation

Based on the ITSCM strategy, IT service continuity management will plan the
implementation of ITSCM by preparing detailed IT Plans, Recovery Plans and Procedures.
These include plans such as:

 Emergency Response Plan

 Communication Plan
  Disaster Recovery Plan

Operational management

In operational management, ITSCM manager and coordinator shall periodically review the IT
service continuity and DR training material for any updates. Further, they shall oversee and
ensure that the Trainings are being conducted as per the planned schedule.

Disaster Recovery

In this phase, ITSCM Manager will initiate the execution of the ITSCM & DR Plan and
closely monitor the execution till the services have returned to normal. After the services are
back to normal state, the ITSCM Manager will:

 Produce a report of disaster recovery and mention what went right and what went wrong
during the execution.
 Send the report to senior management for review.
 Record any identified improvement opportunity in the CSI register.
 If required, update ITSCM & DR plans (after due approvals from the Change management
and relevant stakeholders)

Metrics

 Time to recover and restore services after an outage

 Number of changes to continuity plans
 Frequency and number of periodic reviews
 Number of tests on VBFs
 Costs involved in storage.

Template Name IT Service Continuity Plan

Template
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/03/Template-for-IT-Service-Continuity-
Plan.docx
 ITIL Change Management Process

ITIL Change Management - Process Overview

A Change is nothing but of shifting/transitioning/modifying/from its current state to a desired

future state.

ITIL Change management is an IT service management discipline. It is a process used for

managing the authorized and planned activities like addition, modification, documentation,
removal of any configuration items in the configuration management database that are a part
of a business's live production and test environments along with any other environment that a
business wants to have under Change Management.

Change Management focuses on transitioning new services or modifying the existing services
into IT operational environment ensuring the changes wouldn’t create any outages in the IT
environment.

Objectives

The objective of Change Management is to:

 Respond to the customer’s changing business requirements while maximizing value and
reducing incidents, disruption and re-work.
 Respond to the business and IT requests for change that will align the services with the
business needs
  Ensure that changes are recorded and evaluated, and that authorized changes are
prioritized, planned, tested, implemented, documented and reviewed in a controlled
manner
 Ensure that failed changes are analyzed and RCA’s done to reduce the reoccurrence of such
instances. Check points are enforced to understand the progress of change and to
understand the failures.
 Ensure that all changes to configuration items are recorded in CMS
 Optimize overall business risk

Scope

Scope of Change Management can be defined as:

 Architectures
 Processes
 Tools
 Metrics
 Documentation
 IT services
 Configuration Items

Interface with other Processes

The Change management process interfaces with various other Service management
processes as shown in the diagram above. This diagram depicts how Change Management is
operated and the interfaces associated with it.

Change Management Process

Change Management Process flow

In practical IT environment, change management operations would generally be executed as

per the below diagram:

Change Management Process flow[/caption]

Process Description of Change Management

Change Trigger/Input
This process starts with Request for Change due to major or minor upgrade to an existing
service or a service request requiring a change.
Each change ticket or RFC is recorded so that it could be tracked, monitored, and updated
throughout its life cycle.
Sub processes involved in change management is defined below:
RFC logging and review
The objective is to filter out Requests for Change which do not contain all information
required for assessment or which are deemed impractical. The Change Initiator requests for a
Change to Service Desk who in turn; creates a Change record. Where tool access is available,
the Change Initiator raises a Change record himself.
Based on the initiator’s assessment and the Change Management policy/guidelines, the
change is classified as Emergency, Normal, Standard, Minor change.
Check RFC for completeness, practicability and perform initial assessment: Consider the
7R’s of the Change Management.

 Who raised the change?

 What is the reason for the change?
 What is the return required from the change?
 What are the risks involved in the change?
 What resources are required to deliver the change?
 Who is responsible for the build, test and implementation of the change?
 What is the relationship between this change and other changes?

Assessment and implementation of Emergency change

This phase assesses, authorizes and implements an Emergency Change as quickly as possible.
This process is invoked if normal Change Management procedures cannot be applied because
an emergency requires immediate action.
ECAB will be responsible for approving any emergency changes without formally going thru
the CAB meeting. The verbal or telephonic approval from ECAB will construe the change
management approval. Members of CAB/EC are:

 Change Initiator
 Change Manager
 Configuration Manager
 Domain Owner(s) (As per Change requirements)
 Depending on the nature of the change, Change manager determine the other members of
the ECAB.

Categorization
Categorization determines the required level of authorization for the assessment of a
proposed Change. Significant Changes are passed on to the CAB for assessment, while minor
Changes are immediately assessed and authorized by the Change Manager

Assessment by the CAB

Assesses a proposed Change and authorizes the Change planning phase. If required, higher
levels of authority (e.g. IT Management) are involved in the authorization process.

Change Manager schedules CAB Meeting. The CAB reviews to RFC and related documents
to understand the requirements of the change. The CAB determines if a Formal Evaluation is
necessary for the proposed change.

CAB understands the effects of the change and identifies predicted performance. This can be
determined from the requirements mentioned in the RFC, acceptance criteria, discussing with
relevant stakeholders, etc.
CAB assesses risks and conducts feasibility analysis:
Feasibility analysis is performed with respect to different aspects to find if the proposed
change is a viable option. The analysis could include different factors like:

 Cost-benefit (Cost effectiveness)

 Resource availability
 Identified Risks
 Impact on other services and business impact
 Compliance requirements (if any)

Based on the assessment findings, CAB either approves the change or rejects it.

Scheduling and Building

This phase authorizes detailed Change and Release planning, and to assess the resulting
Project Plan prior to authorizing the Change Build phase.
It involves other tasks like

 Preparing the FSC after considering all approved RFCs which are still open for
implementation. Also the ongoing RFC implementations are considered which preparing the
schedule of changes. Changes of similar kind are grouped together to help release planning.
The change window is reviewed with the Availability Management and ITSCM process plans
for consistency.
 Depending on the nature of the RFC, a decision is made on the requirement of a formal
evaluation before the approval for build is provided.
 Based on the criteria for evaluation after planning and before build, the project plan as well
as the test plan are reviewed and evaluated.

Deployment
Deployment assesses if all required Change components have been built and properly tested,
and to authorize the Change Deployment phase.

Deployment determines if a formal evaluation is required before the deployment can begin.
Accordingly, provide the related/relevant documents to the Change Evaluation Process and
request for a formal evaluation prior to deployment.

CAB is convened to:

 Verify that all components required for the change have been built
 Verify that all components required for the change have been successfully tested
 Verify that the test results indicate that the change will meet its objectives
 Assess the Project Plan for conflicts with other planned/ongoing changes and to check
resource availability
 Review the Evaluation Reports
 Approve/Reject the change for deployment

Accordingly the change record is updated with the assessment findings of the CAB and the
status of the change as appropriate. The change schedule is also updated as necessary.
Post Implementation Review and Closure
PIR assesses the course of the change implementation and the achieved results, in order to
verify that a complete history of activities are present for future reference, and to make sure
that any mistakes are analyzed and lessons learned.

Major activities involves are:

 Determine if a formal evaluation is required post the deployment.

 Determine if the implementation of the change achieved its objectives.
 Analyze and identify lessons learnt from the whole lifecycle of the change. Collate all post
implementation analysis and assessment information in the Change Evaluation report
 Find how the implementation of change can be improved and update the CSI register for
initiating SIP.
 Determine if such change is likely to recur in future. If so, then a new change model might be
necessary to handle such changes in future.
 Update the change record with relevant inputs and set the status to “Closed” to formally
close the change.

Tasks and Responsibilities

Step Task Responsibility

1 RFC Logging and Review Change Manager / CAB

Assessment and Implementation of Emergency

2 Change Manager / Practitioner
Change

3 Change Assessment and Categorization Change Manager / ECAB / Change Coordinator

4 Change Assessment by the CAB Change Manager / Practitioner

5 Minor Change Deployment Change Manager / CAB / Change Practitioner

6 Change Scheduling and Build Authorization Change Manager / Practitioner / Coordinator

7 Change Manager / Practitioner / Coordinator Change Manager / CAB / Change Practitioner

Post Implementation Review and Change

8 Change Manager / CAB / Change Practitioner
Closure

9 Change Management Support Change Manager / Practition

Template Name Change Management Process

Template
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/03/Change-Management-Process.docx
ITIL Service Strategy
Service Strategy

Strategy Management for IT Services defines service strategy as a standardized process for
building strategic assets with vision, strategic goals, innovation, value creation, and resilient
attitude for adapting new changes.

ITIL Service Strategy main focus is to define the market, propose the service offerings,
develop the service offerings as strategic assets, execute the developed offerings, also
measure and evaluate the strategies.
Strategy Generation for IT Services is the most critical process for long term sustainability of
the organization’s offerings.

Service Strategy Process Description

Strategy management for IT services subprocesses can be defined as:

Strategic Service Assessment

The Business strategy manager identifies the organization strengths and weakness. This is
done by analyzing factors such as – existing services, resources, capabilities, projects,
finance, operations etc.
Next step is to identify the growth opportunities and threats. By analyzing external factors
such as - customer’s, supplier’s, partner’s, political trend’s, socio economic trend, technology
trend etc. organization gets fair idea of its current position in market and can formalize future
growth and
expansion plans.
Business strategy manager lists all market spaces where organization currently has hold and
also lists any new market space identified after internal and external analysis. To decide on
which market space to target it is important to define all critical success factor required for a
market. Based on this information a decision can be taken to cater to the market need or not.
High level objectives are set after discussion with steering committee, service management
director and service management process owners.

Service Strategy Definition

Business strategy manager defines the perspective to find out how objective can be achieved
in best possible way. Vision and mission statements are prepared in alignment with business
objective to be achieved.
To determine how the service provider will be differentiated from other service provider in
the industry the business strategy manager finalizes a position for organization.
Based on positioning strategy and objectives to be achieved the business strategy manager
finalizes on the type of service and the type of customer to be targeted. All services are
mapped to business outcomes and aligned with end organization objective.
Determine critical success factor, risk, assumption and dependencies to be considered while
preparing the strategic plan. Prepare the IT strategy and decide on actions to be taken to
achieve the objectives.

Service Strategy Execution

Identify budget requirements for developing new services identified as per IT strategy.
Perform
service valuation to check for feasibility of developing a service and if post program ROI is
required.
Prioritize IT strategy plans in the order of importance and ease of implementation.
Communicate the plan to stakeholders.
Business strategy manager lists down all available assets and their utilization pattern.
Organization services, process, skills, tools etc. are compared with competitors and the gap is
documented.
If an organization lack any of the critical success factor required being successful in
identified market space then such critical success factors are to be developed.
Investment options are prioritized and approved by senior management. Service offerings are
developed accordingly. The business strategy manager will work with other service
management
process owners to implement strategic plans and achieve desired outcome.

Metrics

1. Total number of services triggered as a result of IT strategy

2. Number of new proposals, plans defined
3. Number of new services proposed
4. Number of failed services (that have not been approved by strategy manager/IT steering
group)
5. Total time taken for proposing a new service in service portfolio
 Template Name Service Strategy Template
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/Template-for-Service-Strategy.docx

Post Implementation Review Template for

Incident Closure
Post Implementation Review (PIR)
Once an incident is reported to the IT help desk of the organization, they open a ticket which
will follow the incident from report to conclusion. Once the incident has been resolved one
way or another, the ITIL methodology says that the help desk must conduct a PIR (Post
Implementation Review). The Post Implementation review will help the organization
conclude whether the change made was required, if its implementation was successful and
what the lesson learned was.

Post Implementation Review TemplateThere are many ways to conduct these types of
reviews, either internally or by the help of a 3rd part auditor. Not each incident requires such
a review, and only ones who were deemed important enough to the organization’s continuous
growth are subject to a PIR.

Post Implementation Review Template

The Post Implementation Review Template includes the following information and details
–

Name and Logo

The name and logo of the organization appear at the top

Source Details

The source details of the incident (PIR) appear below them, and include –

 Who submitted the report

 What their role is
 When it was submitted
 To which team they belong to
 The PIR unique number
 Who reported the incident
 What the duration of the malfunction was
 What the status of the incident is

Review Details

The review details include the following –

 A short description of the incident

 What the scope of the PIR is, and which change is the subject of the review. This is a brief
history of the incident from start to finish, which includes the problem, the diagnosis and the
solution.
 The actual PIR of the incident which is mentioned in the paragraph above, and this section is
the heart of the PIR. This includes the outcome of the PIR, whether the change was deemed
as necessary and if the change fixed the initial problem. It also includes how the change was
documented, and if any new lessons learned were added to the organizations’ “memory”
 If any new lessons learned were indeed added, then the next field documents them. This
includes simple instructions on what to do in future similar cases, and when. This field may
contain more than one lesson

Authorization of PIR

The authorization of the PIR, including any future instructions as a result of the lessons
learned. This includes the name and role of the authorizer, their decision and when it was
approved. All of these are made official by the signature which comes last.

How This Fits Into the ITIL Methodology

Since the cornerstone of the ITIL methodology is aligning the IT with the business needs of
the organization, constant improvements and learning from past mistakes is essential.
Conducting thorough reviews and suggesting improvements are vital for living up to this
goal, and the PIR is a major step in this direction.

The methodology doesn’t specify whether the PIR should be conducted internally or by an
independent party, but hiring an external 3rd party professional is better for recognizing faults
which an internal employee may deem as something that has “always been like this”. The
downside of this is that the process may be lengthier, and almost always more expensive.

Template Name Post Implementation Review

Template for Incident Closure
Actual File Location http://itil-docs.com/wp-content/uploads/
 2018/02/ITIL-PIR-for-Incident-Closure.docx

Incident Management Process

Incident Management

This document defines the Incident Management Process. Incident management is the
most important process in ITSM process implementations. The process is based on the ITSM
best practices, and can be modified to reflect requirements specific to your organization.

The primary audience for this document is IT managers, process owners and process
managers responsible for the design, implementation, management, and continuous
improvement of this process. This incident management document may also be of interest to
IT staff members who execute a specific role within this process and business organizations
that want to better understand how the process has been defined within the IT organization.
 Incident Management Process

Introduction to Incident Management Process

Process is a sequence of activities that will result in a specific outcome. Incident

management process defines the sequence of activities that will result in effective incident
resolution and closure.

Incident management is the most important process which can be considered like the face of
the IT service provider and it would be the first process which will implemented in ITSM
process implementations.

Common examples of incidents are:

1. Network server slow or network not accessible

2. File server not accessible
3. Emails not receiving or sending

Objectives:
Objectives section defines the definition of term incident and the objectives of incident
management.
Scope:
Scope section defines the scope of incident management which includes any event which
disrupts, or which could disrupt, a service. It includes events which are communicated
directly by users, either through the service desk or through an interface from event
management to incident management tools.

Incident management activities and the lifecycle of incident record, can be briefly mentioned
as:

 Detects and records incidents

 Classification, prioritiation and initial support to Customers
 Investigation and diagnosis of incidents, including possibly opening Requests for Change
(RFCs)
 Escalation (functional or hierarchical)
 Restores service to its normal operation after incident resolution
 Provides resolutions according to Service Level Agreements
 Closure

Interface with other processes

Incident management process interfaces

This section defines the incident management process interfaces with various other Service
management processes.

Incident Management Process Flow

 I
ncident Management Process

This section presents the visual representation and explanation of incident management
activities, its respective roles, how an incident is triggered, how its prioritized and
categorized, how investigation and diagnosis is done, how the tickets are handled with 3rd
party vendors, resolution and closure.

Process flow – P1 Critical incident management

C
ritical incident management Process Flow

This section presents the visual representation and explanation of critical incident
management activities, responsible groups, and actions.
Key notes on critical incident:

 Any Incident that results in significant Business disruption will be called as Major Incident
  Major incidents require shorter resolution timescales and greater urgency due to its impact
on Business.
 Definition of what is “Major” must be agreed and mapped onto the overall Incident
prioritization process.
 May require a MI team under the leadership of the Incident Manager.
 Should not divert the attention of the Service Desk Manager.
 At times an Emergency change might be triggered to resolve a Major Incident.

Key skills for incident management staff

 Good Communication & Analytical skills

 Ability to work under pressure
 Ability to be collaborative
 Quick decision making capabilities
 Excellent customer handling skills
 Subject knowledge
 Details focused
 Patient and persistent
 ITIL Awareness

Template Name Incident Management Process

Document
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/Incident-Management-Process.docx
 Request for Change Template

What is a Request for Change in ITIL?

Any change to an existing system or procedure entails cross organizational implications,

which must be addressed and planned before they are implemented. An RFC (Request for
Change Template) addresses these implications, while outlying what the change will be,
who will be affected by it and what the cost benefit analysis is.

Any change involves risk as an integral part, and these risks need to be a part of any RFC as
well.

The RFC is then presented to various people and boards across the organization, whose job it
is to understand the implications and risks, and determine whether the request should be
approved. Upon approving the RFC, a plan for its successful implementation is drawn up and
initiated.

Request for Change Template

The RFC template is filled out for each request and the requestors fill out the top table which
contains the following fields –

1. When the request was submitted

2. Who requested the change and which division they belong to
3. Their communication methods (E-Mail, Telephone)
4. A description of what it is that is being requested
5. Requested Date: When the requester would like the change to be approved
 6. A summary description of the request. This description will serve as the main form of
information to the request reviewers, in their decision whether to approve or deny the
request
7. The cost-benefit analysis: This section lays out the cost and expected earnings of the change,
as well as the risks of carrying it out. It also describes how the change will be carried out if it
is approved

RFC Template Tracking

The reviewers fill out the table below, which has check boxes which track the RFC and also
contains the following fields –

 The status of the request (approved or not).

 Any comments by the requester, after the CAB asked their questions.
 Follow-Up Actions: this section includes restrictions of the change, which can serve as a
general guideline and a point of no return timeline. This section shouldn’t appear if the
request was denied.
 Validation Action by the CAB: This field also outlines the budget allocated to the project,
what the timeline of completing the change should be, how it will be tracked and monitored,
and what is the priority of the change request.
 The authorization table appears last and lists who requested the change, their supervisor’s
name, the owner of the change (if approved) and when the change request was distributed
throughout the organization. All of the employees must sign the document.

How This Fits Into the ITIL Methodology

Planning and reviewing any changes to the organization require planning and understanding
of the implications of it. The IT service desk should be a part of the decision making process,
in order to weigh in regarding the implications to them.

This will allow them to properly align themselves post change, in order to keep allowing the
business to grow and improve while relying on the IT systems to do so. Recording changes
will also help in understanding what the past was, and why it needed to change.

Template Name Request for Change Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-Request-for-Change-Template-
V2.docx
 Incident Catalogue Template

Catalog Template - For Incident Record

A major part of the ITIL methodology is to continuously improve as an organization, while
increasing the business activities through IT alignment with these goals. In order for the
organization to grow and improve, records of past incidents must be kept and analysed on a
periodical basis by maintaining incident catalogue template. By maintaining Catalog
template and analyzing the incident will allow the IT department (and more specifically their
services desk) to recognize similar incidents which are evidence of a major problem, and
come up with lessons learned in order to refrain from re-inventing the wheel every time.

The basic incident catalogue template is a living document, which should have a minimum
number of employees in order to maintain uniformity in language and form.

Incident Catalogue Template

The template of the catalogue contains the following information-

Details of the Catalogue

 When it was last updated

 Who was the one who updated it last
 What their role is in the organization
 To which team they belong
Listing Incidents

The incidents themselves are listed next, while each one contains the following information –

1. The name of the incident, which succinctly describes the problem. This field also contains
the name of the user who raised the incident (if it is only one user)
2. The priority of dealing with the incident. This is usually one of the following four
possibilities: Urgent, High, Medium, Low
3. The name of the team who this incident falls under their purview
4. Who is the owner of the incident, and needs to solve it to the satisfaction of the user who
raised the incident to the service desk
5. The category of the incident. This will help in resolving future incidents of the same nature,
and rooting out major problems which have similar incidents
6. Whether an escalation is required. A simple Yes / No field which should be set to “Yes” if the
service desk need to purchase a service or product In order to resolve the issue (above a
certain amount)
7. The incident’s number: A unique number for follow-ups and documentation. If the service
desk work with an incident tracking system, clicking on the number will open up a detailed
record of the incident
8. The diagnosis of the incident, made by its owner. This includes the proposed solution and
the cost of implementing it. This is the heart of the incident’s log, and can be used in the
future to solve a similar incident
9. The escalation decision: only if the escalation was answered “Yes”
10. The status of the incident. This is usually one of the following three possibilities: Completed,
In Process or Cancelled

How This Fits Into the ITIL Methodology

Learning from past mistakes and trying to recognize root problems are a big part of the ITIL
methodology, and maintain logs of past incidents allows the IT service desk to help the
business side of the organization to focus on their main goal: improving the operations and
the profitability of the company. A good log is often consulted before the incident is resolved.

Template Name Incident Catalogue Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-Incident-Catalogue-Template.xlsx
 Release Plan Template

Release Planning
Releasing a new version / software / system requires planning called Release Planning on all
fronts, including the IT department. The ITIL methodology defines a release as a set of
authorized changes to an IT service. The Release Plan Template presents and records the all
necessary details regarding a release plans.

Types of Release

Release are split into three types –

 Minor Release: A significant improvement to an existing system, many times packaging

together several fixes. These are usually numbered after the decimal point of the major
release. For example a minor release to version 2 will be numbered 2.1
 Major Release: Introducing new functionality to the organization, and contain either
hardware or software. These are usually numbered before the decimal point. For example a
major release to will be numbered 1.0
 Emergency Release: As the name implies, this is an un-planned fix to a certain function
which simply solves a symptom, allowing the IT department to root out the cause and fix the
problem. These are usually numbered after the minor release number. For example: an
emergency release to minor release 3.1 will be numbered 3.1.1
Release Plan Template

The release plan template presents and records the following details regarding a release plan

 The basic details of the plan appear at the top of the template, and present the description
of the release and the following details –

1. The owner of the plan. This is who will update the plan and the details on a periodic
timeline, and what their role is
2. When the release plans was submitted, and to whom (the approver of the plan)
3. The type of release (one of the three types listed above), and the number of release
4. The status of the plan (Approved, Pending Approval or Rejected) and its risk level (High,
Medium or Low). A High risk means that if the implementation is unsuccessful, the
organization will be impacted immensely
5. The owner of the release program (usually this is the Project Manager)
6. The start & finish dates, and the duration of the release plan

 What the changes in the version will be: These include the major changes from the previous
version, or the last system which was used.
 Who will be affected by the release: This can focus the internal users who will need to
adapt to the changes of the new release, and help them prepare accordingly.
 Risks: Every change includes risks and a release plan must address these, otherwise they
may be overlooked. The risk should include mitigation plans as well, not just the potential
problem.
 Who needs to approve any CR (Change Request): Any change to the release must be
submitted, reviewed, approved and documented. This section outlines what the chain for
these approvals is.
 The timeline: This is usually a high-level plan for the release, and outlines what needs to be
done and by who, the status and any comments pertaining to the tasks. The format can be
Excel, MS-Project, etc.

How This Fits Into the ITIL Methodology

A release must be planned and tracked, like with any work plan. Planning the release allows
the IT department to align its resources to the requirement of the organization, while making
sure that the business improves as a result. A release plan takes into consideration the
business needs, and allows the IT department to prepare a solid plan which will execute and
bring the release to fruition.
Deploying the release is followed by KPI’s (Key Performance Indicators) gathering, to
ascertain whether the new release did in fact help the business side of the organization and to
make any adjustments in order to continuously improve these.

Template Name Release Plan Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-Release-Plan-Template.docx
 Incident Management Policy - Template And
Procedure

Incident Management Policy

Policy is a management directive that significantly influences the processes and
procedures. Incident Management Policy drives the decision making in incident
management operations and ensures consistent and appropriate development and
implementation of processes, metrics, roles, activities, etc., with regard to this policy. This
policy will be reviewed annually and upon a change to the process and/or tool.

Incident Management Policy Template

Incident Management Policy Purpose

The purpose of this policy is to ensure that any incidents that affect the daily operations of the
organization are managed through an established process.

Incident Management Policy Scope

This policy applies to all IT organization, including contracted vendors involved in activities
that cause or require resolution to incidents. Therefore the scope of the Incident Management
Policy includes the following:

 All IT supported locations

 All environments subject to the Incident Management Policy determined by the ITSM
Steering Committee
 Vendor owned Incidents under IT service provider management
 Vendor/Partner owned Incidents under Vendor management
 IT service provider owned but Vendor supported Incidents

Incident Management Operations Guidelines

Guidelines for incident management operations section defines the guidelines for the
recording, classifying, prioritizing, and communicating with IT stakeholders.

Guidelines to Decide Urgency

Guidelines to decide urgency section defines the guidelines for defining the urgency (urgency
is defined based on how criticality of services) which is defined as critical, normal and low.

RACI Matrix

RACI Matrix - Incident Management Policy

RACI (Responsibility, Accountability, Consulted & Informed) matrix clearly provides the
segregation of roles and responsibilities as activities with respect to the incident management
roles (service desk, incident manager, L2, technical lead, service delivery manager, customer
service manager).

Service Level Agreements

Service Level Agreements - Incident Management Policy

SLA’s defines the agreement between IT service provider and the customer. SLAs section,
defines how incidents have to be handled with priority P1/ P2/ P3, what should be the
response time, restoration time, closure notification time, resolution time, and communication
updates timing.

Reports
 Reports - Incident Management Policy

Reports define the key findings, details, and useful information presented to the different
levels of management and users for making effective decisions and actions.
Reports section here talks about three types of reports like post incident report, weekly
reports, monthly reports, etc.

Meetings

Meetings - Incident Management Policy

Meetings section defines the types of meetings that should be conducted like daily meetings,
weekly meeting and monthly meetings, its agenda, expected meeting outcomes, etc.

Responsibilities of Incident Manager

 Responsibilities of Incident Manager

Responsibilities of incident manager defines the responsibilities with respect to different

areas like governance, business impact assessment, involvement and etiquette in technical
bridges, customer engagement, timely notifications, PIR (Post Incident Report), supplier
management)

Template Name Incident Management Policy

Template
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/Incident-Management-Policy.docx
Incident Management Metrics
ITIL Metrics - Incident Management
ITIL Metrics are measurements which quantitatively and qualitatively evaluate the
performance of incident management operations. As there is a saying “If you can’t measure,
you can’t manage”, hence measuring incident management operations is very much necessary
to drive improvements focusing on customer satisfaction, increasing efficiency and
effectiveness in operations. Incident management metrics objective is to adhere to SLA's.

Metrics for any IT/ Business process should drive the strategy of the organization, help the
management make decisions, and drive towards the goals, objectives and priorities of the
company.

The primary objective of incident management metrics is to ensure that the operations are
been carried out to provide good customer satisfaction and adhere to defined SLA’s.

Incident Management Metrics

Customer satisfaction %

Helps us understand what the end user/ customer feels about the service provided. It is the
most important metric for incident management operations.
Threshold value: <6
Target value: 8
Possible values: 0-10

Number of incidents logged

Helps us understand the number of incidents logged in ITSM tool.

Threshold value: None
Target value: None
Possible values: None

Number of major incidents

Major Incidents that have been critical to business operations, which have incurred huge
financial losses/ reputation. It will help us understand the financial loss.
Threshold value: As per the defined SLA
Target value: As per the defined SLA
Possible values: As per the defined SLA

Number of recurring incidents

Incidents which are occurring again and again. It shows the inefficiency of resolutions
provided by incident management staff and problem management staff.
Threshold value: As per the defined SLAs
Target value: As per the defined SLAs
Possible values: As per the defined SLAs
Number of incidents that needed onsite human resources intervention

Incidents that needed human presence at the site or machines or systems. This metric
provides an opportunity to automate operations.
Threshold value: As per the defined SLAs
Target value: As per the defined SLAs
Possible values: As per the defined SLAs

% of first time fixes

Incidents that are resolved in the first attempt, it shows the efficiency and effectiveness of the
incident management staff in resolving the issues without reopening the incidents.
Threshold value: 75%
Target value: 90%
Possible values: 0-100%

Number of incidents that are assigned to wrong functions

When calls are registered in the ITSM tool, they are assigned to some assignment groups for
resolution. This metric shows how accurately the incidents are been assigned.
Threshold value: As per the defined SLAs
Target value: As per the defined SLAs
Possible values: As per the defined SLAs

Number of calls resolved by L1 support

Incident management function would have layers of support teams like L1/ L2/ L3; this
metric shows the efficiency of L1 support by the number of calls resolved.
Threshold value: As per the defined SLAs
Target value: As per the defined SLAs
Possible values: As per the defined SLAs

Number of calls escalated to L2 support

Incident management function would have layers of support teams like L1/ L2/ L3; this
metric shows the efficiency of L2 support by the number of calls resolved.
Threshold value: As per the defined SLAs
Target value: As per the defined SLAs
Possible values: As per the defined SLAs

Mean time between system incidents

This metric defines the mean time between system incidents.

Threshold value: As per the defined SLAs
Target value: As per the defined SLAs
Possible values: As per the defined SLAs
 Template Name Incident Management Metrics
Template
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/Incident-Management-Metrics.docx

Customer Complaint Log

What is a Complaint Log?
Maintaining a complaint log is vital for an organization which wants to learn from its
mistakes, and refrain from re-inventing the wheel each time it encounters a known (but
forgotten) incident. A customer complaint log records all of the past complaints made by the
external and internal regarding any incidents which have to do with the organizations IT
services.

This type of log can be used as a database for the service desk employees, whenever they
encounter an incident for the first time. Putting effort into a log like this may seem like a
waste of time at first, but once it saves the service desk time and effort (and money for the
organization) they will see the benefit of it. This means that they need to detail each and
every incident they encounter, and tag each one with the correct words.

Customer Complaint Log Template

[the_ad id="667"]

Template consists of the following information - Which team owns it and uses it (Division >
Team), who updated it last and when it was last updated.

The reference number of the complaint record, which is a unique reference number. If the log
is on a shared folder or SharePoint site, then clicking on the number will open up the full
complaint record thus allowing the service desk to review the entire complaint from start to
finish

The keywords of the complaint, which is basically the summary of the entire complaint into a
few keywords (between one and three usually). For example: SharePoint, Upload, Full
Memory to describe an issue a customer had while trying to upload a file to the SharePoint
site and failing due to the fact that the site reached its capacity

When the complaint was received: date and time. This will help in sorting the log, last entry
should appear at the top (Z to A)

When the complaint was resolved to the satisfaction of the complainer. This can aide in
understanding the required number of days to resolve certain incidents, and calculate which
ones exceeded their SLA (Service Level Agreement)

Comments: Free text where the owner of the incident can write any and all best practices,
suggestions and tips for future use and reference.

Lessons Learned & Escalations

This section tries to summarize incidents of the same nature, and collate them into a major
problem. Once one is recognized, then the service desk can try and root out the problem and
prevent it from recurring. These escalations need to be authorized, and this is done in the
bottom section of the log.
How It Fits Into the ITIL Methodology

Continuous improvement is a cornerstone of the ITIL methodology, and keeping a log of past
complaints helps in refraining from repeating them. This is a major tool in analysing the
major problems of an organization, and allowing the business to grow with the help of the IT
services.

Template Name Customer Complaint Log

Template
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-Customer-Complaint-Log.docx

What is ITIL and its lifecycle?

ITIL Service Lifecycle
To perform at their best, organizations must offer customers useful and competitive products
and services. The ability to adapt quickly to volatile economic and technological
environments is essential for sustained growth. The ITIL Service Lifecycle is a strategy that
organizations can use to engage in a perpetual cycle of improvement for their services.

ITIL stands for Information Technology Infrastructure Library. It is a well-known set of

guidelines used to manage intricate technology systems. It originated in the United Kingdom
during the 1980s as a method of coping with increasing dependence on technology and has
since transformed into a universally accepted knowledge-base that organizations use to
optimize their technology infrastructure.

Over the years, ITIL has grown and evolved after being revised several times to keep up with
the fast-changing landscape of technology and its impact upon organizations.
Today, ITIL is in its third version, often referred to as v3. ITIL provides a method that
organizations can utilize to increase the efficacy of their IT services while reducing their cost.

What is the ITIL Service Lifecycle?

The “IT Service Lifecycle” refers to an all-encompassing framework that spans the lifetime
of information technology within an organization. Primary elements of this lifecycle are:

Each of these five elements has a specific guideline, requirement, and process detailed for
each stage of the lifecycle phase. This allows organizations the ability to implement ITIL in
focused areas or in a comprehensive manner. The most effective implementation comes about
as a result of adopting the lifecycle principles in their entirety.
 ITIL Service Lifecycle

ITIL Overview
1. Service Strategy

The cornerstone of the ITIL lifecycle is the service strategy. The service strategy contains the
financial models, requirements, and goals for the IT systems of an organization. In this
strategy, the full range of service operations is laid out, along with policies or principles for
consideration. Simply put, this element describes the overall goal of the services lifecycle.

2. Service Design

In the ITIL lifecycle, service design refers to the blueprint used by an organization to create
the IT infrastructure it needs to complete its service strategy. This aspect identifies the people
and resources necessary for the successful execution of that strategy. It also includes changes
relating to new rules and regulations.

3. Service Transition

After having determined the strategy and design phases, our organization must then focus on
service transition. The goal of this is to align operations with projects. Every aspect of our
service comes together to make sure it has been tested and integrated as a whole. Paying
adequate attention to the details of this phase can cut down on unexpected problems later on.

4. Service Operation

The purpose of service operation is to enable comprehensive practices that allow us to sustain
stable services. Our operational team handles incident management and takes feedback on
customer satisfaction.

5. Continual Service Improvement

The final phase of the ITIL lifecycle serves to integrate and maintain the other four.
Continual service improvement means that we are always aligning our services with the
needs of our business, seeking opportunities for improvement and changing practices
accordingly.

What are the benefits of ITIL?

The development of ITIL occurred through a collaborative effort on the part of a large
number of experts and organizations. It provides a versatile and dynamic framework that can
be applied to any organization due to being conceived by a wide range of IT experts and
professionals.

The ITIL approach provides a number of advantages -

Guidance provided by ITIL is commonly used and recognized, making it an easy avenue of
communication between many organizations and individuals. Many high-profile companies
have turned to ITIL guidance for their business practices, including IBM, NASA, and HSBC.

Organizations around the world have proven the effectiveness of this model by adapting it to
their business models, leading to a continuous cycle of improvement.

A fundamental aspect of the success of ITIL is its requisite education and certification
schemes. These uniform requirements help companies to deliver quality service by having
their service personnel properly trained and educated.

ITIL allows us to create and maintain beneficial business relationships with our customers
and increase their satisfaction. It also enables us to discover the most efficient practices for
our teams to use in understanding and managing customer expectations.

The adoption of proven standards leads us to provide quality service on a consistent basis.
By using ITIL, we can incorporate changing elements of our customer’s needs while also
increasing stability and reducing risk. These processes allow us to act in accordance with
changing circumstances in short order. By aligning plans for services with plans for the
business, we can decrease the likelihood of unexpected deficiencies in business performance.

In short, the ITIL service lifecycle allows us to engage in a positive feedback loop. Our
service strategy, design, transition, and operation are integrated into continual service
improvement so that present and future challenges are met and adapted to with ease.

Customer Complaint Report Template

Customer Complaint Form
These days when most services and products are in abundance and are accessible
worldwide, a company’s reputation and overall customer feedback score is crucial in
attracting new customers and retaining existing ones.

The WOM (word of mouth) rule states that a satisfied customer will sing the company’s
praises to three of their acquaintances, while a dissatisfied customer will let eleven of their
acquaintances know that the service / product wasn’t according to their expectations. This
rule makes it absolutely necessary for the company to allow its customers to complain about
their service or product, and the best format to achieve this is a complaint report or
customer complaint form. These reports are usually on the company’s website, but can also
be received via mail, fax or phone-call. Once a complaint is received, the sooner the
complaint is addressed the better.

Customer Complaint Report Template

The attached template contains the following sections –

The basic details of the complaint

These include the following attributes

 1. Who complained (Name)
2. Their means of communication (E-Mail & Phone Number), and how they prefer to be
contacted
3. Method in which the complaint was registered
4. When the complaint was made (Date and time)
5. What the complaint category is. This is done by the complainer, and helps in the initial
assigning and prioritization of the complaint
6. The complaint number: a sequence running number for follow-up and tracking

The complaint itself

This section allows the complainer to write any and all things which are perceived as not
according to the promised value for money.

How the complaint was resolved

1. Who is in charge of resolving the complaint

2. When they received the complaint and took ownership of resolving it
3. Which actions were taken tin order to fix the problem, what was the root cause of the
problem and which (if any) compensation was offered as a result of the problem
4. When the issue was resolved to the customers satisfaction, and the ticket was closed
5. Whether an escalation of the problem is required

Required Improvements

If any lessons were learned during the course of addressing the complaint, this section will
list them. This is to be filled in by the owner of the ticket (from the service desk), and to be
authorized (or declined) by the approver of the complaint resolution

Authorization

since any improvement measure has vast implications on the organization, it must be
approved before it is implemented. This is usually done by the service desk manager, or the
CIO of the organization.

How It Fits Into the ITIL Methodology

Since some complaints have to do with the IT services of the organization, the ITIL tries to
ensure that the IT service desk handles all of the complaints which are aimed at the services
offered by them. The constant improvement and learning from past mistakes is a cornerstone
of the ITIL methodology, and this helps in aligning the IT services to the business goals of
the organization.

Template Name Complaint Report Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-Customer-Complaint-Report.docx
Internal Audit Report Template
Internal Audit Report
The purpose of an internal audit is to assure that the organization is complying with its
processes, procedures and any governmental / industry regulations. The internal audit
report aids the organization in improving its effectiveness in the control and governance
areas, while providing an objective source of independent review. Internal Audit Report
Template includes advice and proposed solutions to any problems or issues which comes
during the course of the audit.

Since everyone wants to do well in any form of test, there is considerable pressure on the
auditor to provide a positive feedback regarding the tested subject. This requires integrity and
accountability from the auditor, as well as a strong moral compass.

The audit report includes advice and proposed solutions to any problems or issues which
may have risen during the course of the audit.

Internal Audit Report Template

The template includes the following sections –

The audit report basic details

1. Timeframe of the audit: this is usually over a period of time, between a few days and a few
weeks (depending on the scope of the inspected team)
2. When the report was issued
3. Who conducted the audit and issued the report. This can be a team of auditors, depending
on the scope of the audit
 4. The scope of the audit: What the auditors reviewed, and in which team / division of the
organization

The Audit Trail

This is the heart of the report, and includes three main sections

1. Documentation: this section details which documents were reviewed over the course of the
audit. Each document must be identified according to its specific sequence number, and
contain a short summary of what the document contains
2. Interviews: this section shows which employees of the audited team were interviewed,
what their role is and how they relate to the scope of the audit
3. Nonconformities: If any instances where the actual actions taken aren’t in line with the
official process of the organization, this section will highlight them. The usual structure of
these bullets is: the problem, the proposed solution, and who will implement the solution
(the owner of the solution, if it is approved).

Internal Audit Report - Review and Authorization

This is the last section of the report, which details when the initial and final drafts were
reviewed and by whom (Name & Role). The section also lists who approved the proposed
solutions, and when this was done. This is usually done by one of the top management
officers of the organization. The last row presents the name and signature of the auditor.

How It Fits Into the ITIL Methodology

An ITIL audit focuses on making sure that the IT services are aligned with the business
requirements of the organization, and that the processes and methodology of the service desk
come as close as possible to providing seamless continues IT services.

The auditor examines processes and past occurrences which may have not been in-line with
the methodology of the ITIL and the organizations goal, and suggests ways of fixing these
nonconformities.

The auditor may an employee of an organization, or an employee of a reputable company

which specializes in auditing.

Template Name Internal Audit Report Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-Internal-Audit-Report.docx

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 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
o Name
o Title
o Means of communication (E-Mail, Phone, etc.). This is optional
 The agenda of the meeting, with the following information –
o Start and finish hour of each topic
o The topic which will be discussed
o 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 –
o Number of the action item. Usually a simple running number list
o 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)
o 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
o Due Date: Presents when the owner of the action item needs to complete it
o 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.
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.

Template Name MOM Template for ITIL Major

Problem Review
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-MoM-Template-for-Major-
Problem-Review.docx

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.

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 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.

Template Name ITIL MOM Change Advisory Board

Template
Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-MoM-Template-for-Change-
Advisory-Board.docx

Problem Record Template

What is a Problem Record?
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 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.

Template Name Problem Record Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-Problem-Record-Template.docx

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.

8 Steps to Resolve an ITIL Problem

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.

Template Name Major Problem Report Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-Major-Problem-Report-
Template.docx
 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.

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.

Template Name Service Request Form Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-Service-Request-Form-
Template.xlsx
 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.

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?

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.


o 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.


o 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 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

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).

Template Name ITIL Problem Catalogue Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/ITIL-Problem-Catalogue-Template.docx
 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.

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
 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.

Template Name Incident Report Excel Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/Incident-Report-Excel-Template.xlsx

Template Name Incident Report Word Template

Actual File Location http://itil-docs.com/wp-content/uploads/
2018/02/Incident-Report-Excel-Template.xlsx