Triumfant ITIL Primer
An Introduction to ITIL
Definition, History, Purpose and Relevance
ITIL stands for Information Technology Infrastructure Library, and is literally a set of books
developed by the British government. Figure 1 shows the various books that comprise the
library. The Central Computer and Telecommunications Agency (CCTA) of the U.K. was the
original owner of ITIL. As of 2001, however, the CCTA became part of the Office of Government
Commerce (OGC), which is the current owner of ITIL today.
ITIL was developed under the premise that organizations were becoming increasingly
dependent upon IT to fulfill their corporate objectives. This growing dependency gave way to the
need for those IT services to maintain quality standards that corresponded to the objectives of
the business, which in turn relate to the requirements and expectations of the customer. ITIL
provides a set of best practices for IT service processes to provide effective and efficient
services in support of the business.
ITIL is not a standard. BS15000 is a British standard for IT Service Management based heavily
upon ITIL. ISO20000 has been proposed as the international version of the BS15000 standard.
ITIL is also a core part of the foundation of Control Objectives for Information and related
Technology (COBIT). COBIT is the framework of choice for external auditors performing IT
audits for SarbanesOxley (SOX). Together, ITIL and COBIT provide a formidable combination
to achieve SOX compliance.
ITIL has been rapidly adapted across Europe for best practices and is rapidly gaining
acceptance across the globe. As SOX and other IT governance issues become driving forces
for many organizations, ITIL will be looked at seriously as a key component for achieving
compliance within IT for those governance bodies.
Triumfant ITIL Primer Page 2
Figure 1: ITIL Publication Framework
IT Service Management
Much of the focus on ITIL is within IT Service Management (ITSM). ITSM pertains to the
delivery and support of IT services that meet the requirements of the business organization.
This primer will focus on the Service Support domain. Table 1 shows the various components
contained within ITSM.
Table 1: IT Service Management Processes
Service Support Operational Processes
ITIL Service Support generally focuses on the daily operation and support of IT services and is
broken down into five main processes and one key function. These processes, functions, and
their relationships to one another are illustrated in Figure 2.
Triumfant ITIL Primer Page 3
Figure 2: ITIL Service Support
The Service Desk
The service desk is the only function within the ITIL framework. It handles incidents, problems
and questions and is responsible for resolving incidents as quickly as possible. The service
desk usually serves as the single point of contact for customers and is integrated into other
service management processes and business processes. There are various classes of service
desk that correspond to the capabilities required within a given IT organization. These
capabilities can range from simple call routing to expertlevel specialists resolving incidents.
The goal of the Incident Management process is to restore service as quickly as possible with
minimal disruption to the business. This allows the highest levels of service and availability to be
maintained. An incident comprises any event, not part of a standard service operation, which
causes, or may cause, an interruption or reduction in quality of service. Incidents are typically
broken down into two categories—service requests and all other incidents. Service requests
include requests for information or documentation and nonurgent requests (e.g., How To's,
Password Resets, etc.).
Important ITIL Terms
Incident: Any event, not part of a standard service operation, which causes, or may cause, an
interruption or reduction in quality of service.
Triumfant ITIL Primer Page 4
Problem: A condition characterized by multiple incidents exhibiting common symptoms, or a
single significant incident for which the root cause is unknown.
Known Error: A problem for which the root cause and a workaround have been determined.
ITIL Incident Management Process
As shown in the diagram above, there are many activities that make up Incident Management.
· Incident Acceptance and Recording Incidents arrive at the service desk via many
possible avenues including phone, email, fax, selfservice portals, etc. Regardless of the
method, a record of the incident is recorded.
· Classification and Initial Support Incidents are coded by type, status, impact,
urgency, Service Level Agreement (SLA), priority, etc. The service desk may give the
user suggestions to solve the issue, even if they provide only a temporary workaround.
· Service Requests If the incident is a service request, the appropriate procedure for
that request is initiated.
· Matching Incidents are investigated and initially compared to a known error database.
This database typically comprises a common knowledge base utilized by the service
desk in addition to what an individual service desk administrator may already know. If
the incident is not recognized as a known error, it is then compared to entries within
the known problem database. Here, problem records identify open problems that
are currently under investigation or pending change resolution. If the incident
Triumfant ITIL Primer Page 5
matches either a known error or known problem, it is matched to a known solution or
· Investigation and Diagnosis If there is no match of known errors or known problems,
the incident must be further investigated. This involves gathering as much information as
possible about the incident to determine how to restore service as quickly as possible. If
first level support within the service desk cannot determine a solution, the incident is
escalated to second level support. This escalation process continues as appropriate
according to SLAs, internal procedures, etc. If no resolution can be found, the incident is
declared a problem and the Problem Management process is initiated.
· Resolution and Recovery Once a solution is found, the issue is resolved by restoring
services to normal operation.
· Closure After the user verifies that service has been restored satisfactorily, the incident
The Problem Management process has the goal of minimizing the adverse impact of incidents
and problems resulting from errors within the IT infrastructure, and to prevent the recurrence of
incidents related to those errors. There are two different types of activities within Problem
Management—Proactive and Reactive.
Proactive Problem Management: Prevents incidents from occurring by identifying weaknesses
or errors in the infrastructure and proposing applicable resolutions. Although most organizations
aspire to implement this portion of Problem Management, few are able to achieve success for
reasons to be discussed later.
Reactive Problem Management: Identifies the root cause of past incidents and proposes
improvements and resolutions. Figure 4 illustrates how Reactive Problem Management is
broken down into two areas: Problem Control and Error Control.
Triumfant ITIL Primer Page 6
Problem Management Process
Problem Control: Identifies underlying root causes of incidents to prevent future recurrences.
Problem Control consists of the following activities:
· Analysis Information is gathered to be analyzed from various sources including
outputs from various ITIL processes such as Incident Management, Capacity
Management, Configuration Management, Service Level Management and Availability
· Problem Identification and Recording Parameters defining the problem are
established, such as recurring incident symptoms or service degradation threatening
SLAs. Problem characteristics are recorded within the known problem database. Future
incidents that occur related to the individual problem may reference the problem record.
· Classification and Allocation Problems are classified by category, impact, urgency,
priority and status.
· Investigation and Diagnosis Data obtained from various processes and locations is
analyzed to diagnose the root cause of the problem. This activity may include recreating
the problem or several iterative phases to deduce the actual root cause. Once the root
cause has been determined, a workaround is developed if required. Once the
Triumfant ITIL Primer Page 7
diagnosis is complete, the problem is turned into a known error and is passed to the
Error Control portion of Problem Management.
Error Control: The process of monitoring and providing solutions for known errors until they
are resolved. Error control contains the following activities:
· Known Error Identification and Recording Once the root cause has been
determined, the problem status changes to known error. A workaround is developed to
feed back to Incident Management to handle future incidents that occur before a final
solution is implemented. The known error definition can also be sent to the known error
database to be used in the matching process.
· Solution Investigated An assessment is performed on what will be required to resolve
the known error. This activity could consist of crossfunctional teams to weigh different
solutions on various criteria including costs and benefits.
· Defining Solution A final solution is developed and a Request for Change (RFC) is
made via the Change Management Process.
· Problem Evaluation and Review After the change has been implemented, a Post
Implementation Review (PIR) is performed to evaluate the success of the solution and
· Closure Assuming the problem review declares the solution as successful, the
problem is finally closed.
Triumfant ITIL Primer Page 8
The goal of Change Management is to manage the process of change through standardized
methods and procedures, thereby limiting incidents related to change and improving daytoday
Change Management Process
Throughout the Change Management process, illustrated in the figure above, various levels of
management may need to be involved for approval and planning depending on the type of
change. Typically there is a Change Manager, a Change Advisory Board (CAB), and an
emergency change committee. The following activities are performed for all nonstandard
· Request for Change (RFC) Other ITIL processes, customers and IT personnel make
requests for modifications to the managed infrastructure. These changes are typically
Triumfant ITIL Primer Page 9
not considered Service Requests, as those are considered standard changes that do not
need to be individually addressed by Change Management.
· Recording Information relevant to the RFC is recorded that includes a change
identification number, relevant problem/known error, justification, description, change
date, request originator information, and what configuration items are to be changed.
· Acceptance RFCs are checked for valid information and either accepted or denied.
Typically the acceptance involves financial approval, technical approval and business
· Classification Priorities and categories are specified for RFCs. Priority specifies the
level of importance and category specifies the basis of impact and resources.
· Planning A change calendar, or Forward Schedule of Changes (FSC), details all
approved and planned changes. The CAB will meet to discuss the various
considerations surrounding the RFC, such as dependencies, conflicts with other
changes, impact to resources and other services, backout plans, change window, etc.
· Coordination Change Management is responsible for the coordination of building,
testing and implementing the change. This is typically done in conjunction with the
Release Management process.
· Evaluation Results of nonstandard changes should be evaluated to ensure that
objectives were met, users are satisfied, evaluate possible side effects, and confirm if
changes were within the projected budget.
· Closure After a successful evaluation, the RFC is closed.
The goal of Release Management, illustrated in the figure below, is to ensure quality within the
production environment through a managed rollout of new versions within the managed
infrastructure. Change Management is focused on the coordination and planning of changes
while Release Management is focused on the actual implementation of those changes.
Release Management also works with Configuration Management to ensure that the CMDB is
kept up to date and that all new software releases are stored in the Definitive Software Library
(DSL). All spare hardware components and assemblies are stored within the Definitive
Hardware Store (DHS).
Triumfant ITIL Primer Page 10
Release Management Process
The following activities are part of Release Management:
· Policy and Planning A document, called the Release Policy, is developed by the
Release Manager and defines how and when releases are configured. Prior to planning
a release, information must be gathered about various aspects of the release, such as
product life cycle, description of relevant IT service and service levels, authorization for
relative RFCs, etc. Planning the release involves coordination, scheduling,
communication planning, definition of roles and responsibilities, development of backout
and quality plans, and more.
· Design, Building and Configuration Standard and reusable procedures and
documentation should be used for designing, building and configuring releases.
Configuration items within the release may come from internal or external bodies. In
either case, laboratorybased development testing along with appropriate operational
documentation should be prerequisites before a release is considered available for
· Testing and Acceptance Lack of testing is the most common cause for unsuccessful
changes and releases. Releases should undergo functional, operational, performance
and integration testing by the appropriate personnel. Testing should include backout
plans. Acceptance should be performed for each step of the release process and be
submitted to Change Management for approval. Once approved, the release can be
rolled out and the relevant configuration changes can be integrated within the CMDB
(see Configuration Management).
Triumfant ITIL Primer Page 11
· Rollout Planning Includes a detailed timetable of release events including staff
responsibilities and action items, documentation and purchasing plans for required
hardware and software.
· Communication Personnel, typically the Service Desk or Customer Relations,
communicate the planned changes to users and the expected service impact. Training
sessions may be required to aid users with the release.
· Distribution and Installation Involves the distribution of software and supporting
hardware identified and approved in the previous activities.
The goal of Configuration Management is to manage the value of IT services by maintaining a
logical model of the IT infrastructure and services, and by providing information about them to
other processes. This is accomplished by identifying, monitoring, controlling and providing
information about configuration items and their versions. Configuration Management aims to
have reliable records of IT components and services, while also providing accurate
Configuration Management, illustrated in the figure below, identifies the various components of
IT infrastructure as Configuration Items (CIs). All of the information regarding CIs is held within
the Configuration Management Database (CMDB).
Configuration Management Process
Triumfant ITIL Primer Page 12
The following are activities within the Configuration Management Process:
· Planning Defining the scope, purpose, objectives, priorities, policies and procedures of
the Configuration Management process.
· Identification Defining and maintaining configuration structures for CIs including
naming conventions, version numbers, physical components, interrelationships and
documentation. This activity involves allocating identifiers and version numbers, and
entering data into the CMDB.
· Control Ensures the authorization and recording of CI changes, such as additions,
deletions, relationship changes, etc.
· Status Monitoring Tracks life cycle states of CIs.
· Verification Auditing used to validate the physical existence of CIs and that the
corresponding entries in the CMDB are accurate.
Triumfant ITIL Primer Page 13