The ITIL®

First Aid Kit

Essential information for professionals and organizations using ITSM®
ITIL® is a registered trade mark of AXELOS Limited
The ITIL®
First Aid Kit
The ITIL® First Aid Kit is an essential toolkit for the effective utilization of the IT Infrastructure Library (ITIL®) in any organization. However, it
does not provide any one-size-fits-all solutions or formulae that ensure a successful IT Service Management (ITSM) implementation. This kit
is meant as guidance to provide you with areas of attention and possible strategies to include in your program approach. Each organization
is different, and your program needs to be unique to your organizational needs and business drivers.
The kit provides essential ITIL program approaches to support you when you need them the most. In every ITSM program emergency, think
of this kit before looking elsewhere.

Copyright: ITIL® is a registered trade mark of AXELOS Limited. | The Swirl logo™ is a trade mark of AXELOS Limited. | The ITIL Accredited Training
Organization logo is a trade mark of AXELOS Limited. | IT Infrastructure Library® is a registered trade mark of AXELOS Limited | No part of this
document may be reproduced in any form without the written permission of both ITpreneurs and AXELOS Limited. Permission can be requested at
www.ITpreneurs.com and licensing@AXELOS.com. | Material in this document has been sourced from ITIL® Service Lifecycle Suite 2nd Edition, 2011.
1 The Need to Deliver Value
• Information, previously a sup-
porting element, has become the
basis for value itself. In addition,
information-based Services are
changing and evolving at a rapid
rate.
• Capabilities and resources in the
management of IT and services
are no longer perceived as simply
operational concern for detail. They
are the basis for creating value, for
competition, and for distinctive
performance.
• IT organizations require a keen
sense of the nature and dynamics
of Services as a means of providing
value to customers.
• It is important for IT organiza-
tions to review their positions and
to clearly understand how they
provide differentiated market value
to their customers.
Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
• A well-managed IT organization can
act like a business within a business
and deliver value that meets or
exceeds other commercial alterna-
tives. For this reason, concepts such
as Utility, Warranty, market spaces,
and portfolios are introduced in the
Service Strategy processes within
the Service Lifecycle.
1.1 Ensure Value Creation by Asking
What is our business?
Who is our customer?
What does the customer value?
Who depends on our Services?
How do they use our Services?
Why are they valuable to them?
Service Strategy is
your main body of
reference to assist with
structuring the flow
of and answering these
key questions.
Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
1.2 Multiple Views of IT

VIEW V I S U A L I Z AT I O N VERNACULAR

IT / Component Components of systems and processes “Our billing system is IT-enabled”

“We use it to improve interactions with our customers

through self service terminals at key locations.”

“IT touches every part of our business. Without appropriate

controls that in itself is a risk.”

IT / Organization Internal unit function of the enterprise “Our IT is headed by a CIO of tremendous experience in the
or commercial Service Providers transportation industry.”

“Our heavily centralized IT suits our business model which

more than anything requires stability and control over
business operators.”

“IT does not understand the nature of our business.

Much is lost in translation.”
IT / Service Type of shared service utilized by “I haven’t been able to access the internet since yesterday.
Business Units when do you expect the service to be restored?”

“Our remote access service is very secure but it is also very

difficult to set up and use.”

“We decided not to use our own enterprise applications

for administrative functions. We are better off utilizing IT
services provided to us under a commercial contract.”

IT / Asset Capabilities and resources that provide “It is the core of our business process. We use IT to create
a dependable stream of benefits value for customers. It is part of our core production
process.”

“Our IT investments are like Costs of Goods Sold (COGS).

They are direct costs not overheads.”

“IT is our business.”

Source: Quoted text source is ITIL® Service Lifecycle Suite 2nd Edition, 2011. Copyright © AXELOS Limited 2014. Material is reproduced under license from AXELOS.
2 Management of Change (MOC)

Aspects of managing the cultural/behavioral
Change experienced with the implementa-
tion of ITIL processes need to be identified and
controlled. This Change is mainly the shift from
being an IT-centric organization to becoming a
customer-focused organization. Less emphasis
is placed on individual IT units performing well
in isolation than on one where each IT unit
needs to understand its part in delivering Ser-
vice to the end user and in being accountable
for its performance in the supply chain.
A formal ITSM program approach is used to
manage these elements of cultural change,
with specific emphasis placed on the develop-
ment of awareness campaigns aimed at all
target audiences – IT management, IT staff,
and customers – and strong communications
planning.
It is important to note that the most successful
ITSM programs are those that focus on attain-
ing corporate objectives. Indeed, the sooner
you can drop the project name – ITSM or ITIL
program – and align this work to support a set
of corporate initiatives, the more successful the
implementation will be.
2.1 The 4 Ps

People Processes Partners Products

Many designs, plans,
and projects fail because
of a lack of preparation
and management.
The implementation of ITSM as a practice is about preparing and planning for the effective
and efficient use of the 4 Ps. This approach is critical when designing your ITSM program, for
correctly focusing on clarity of communication, and for ensuring a culture that supports and
rewards process adherence through changed behaviors.
It is especially important to focus on the People aspect of the 4 Ps because this is where your
Change effort will succeed or fail.
2.2 Eight Steps to Transform Your Organization

John P. Kotter of the Harvard Business School introduced this

approach to manage Change within an organization. This approach 5 Empower Others to Act on
the Vision 7 Consolidate Improvements and
Produce More Change
• Remove obstacles to Change. • Use increased credibility to change
has proven successful over the years and can be helpful when
• Change systems or structures systems, structures, and policies
designing the management of Change into your ITSM program.
that seriously undermine that don’t fit the vision.
• Hire, promote, and develop

1 3
the vision.
Establish a Sense of Urgency Create a Vision
• Encourage risk taking and emplo-yees who can implement
• Examine market and • Create a vision to help
nontraditional ideas, activities, the vision.
competitive realities. direct the Change effort. • Reinvigorate the process with new
and actions.
• Identify and discuss crises, • Develop strategies for projects, themes, and Change
potential crises, or major achieving that vision. agents.
opportunities.
6 Plan for and Create Short-Term Wins

8
4
• Plan for visible performance Institutionalize New Approaches
Communicate the Vision
• Articulate the connections

2
Form a Powerful Guiding Coalition
• Assemble a group with enough
power to lead the Change effort .
• Encourage the group to work • Teach new behaviors by citing the
as a team.
improvements.
• Use every vehicle possible to
• Create those improvements. between the new behaviors and
communicate the new vision
• Recognize and reward organizational success.
and strategies.
employees involved in • Develop the means to ensure
the improvements. leadership development and
example of the guiding coalition.
succession
Source: Leading Change - John P. Kotter - 1996
2.3 Pitfalls when Attempting to Change the Organization
In his book, “Leading Change,”
Kotter identifies the errors
observed when undertaking
Change initiatives in practice.
Make sure that you plan to
mitigate these Risks in your
ITSM program.
1 Writing a memo instead
of lighting a fire
At least half of failed Change efforts
bungle the first critical step — estab-
lishing a sense of Urgency.
2 Talking too much and
saying too little
Most leaders under-communicate
their Change vision by a factor of 10
(or 100 or even 1,000!). In addition,
the efforts they make to convey their
message are typically of the least
convincing variety — speeches and
memos.
3 Declaring victory before
the war is over
When a project is completed or an
initial goal met, it is tempting to
congratulate all involved and
proclaim the advent of a new era.
While it is important to celebrate
results along the way, kidding necessary, underpinning processes
yourself or others about the • Wishful thinking on timeframes,
difficulty and duration of orga-
nizational transformation can be
catastrophic. Celebrating incremental
improvements is a great way to mark
progress and sustain commitment,
but don’t forget how much work is wins and to communicate these wins
still to come.
4 Looking for villains in
all the wrong places
Long-term program challenges
• Changes in sponsorship/leadership
The perception that large organiza- • Changes in team
tions are filled with recalcitrant middle
• Change in business (mergers,
managers who resist all change is not
acquisitions, and so on)
only unfair, but also untrue.
In professional Service organiza- • Temporary changes in
economic fortunes
tions, and in most organizations with
an educated workforce, people at • Poorly articulated project strategy
every level are engaged in Change
processes. Often, it’s the middle level
• Initial excitement based on a de-
sired result without investing in the
that brings issues to the attention of
the senior executives.
meaning not enough planning for
5 Lack of focus on short-term wins
To maintain momentum and the longer term (scenarios/phases)
sustain funding and support, it is • Wrong emphasis on tools at the
important to deliver on short-term wrong time
• Inadequate focus on the human
to all stakeholders in the program. element
3 The Value of Training Two critical success factors within an ITSM program are communication and training. A well-
thought-out ITIL training strategy and plan play a key role in successful ITSM programs.
Source: Alan Nance
3.1 Typical approach to training
Typically, a high number of staff is initially trained in Foundations, along with some Service Manager/Advanced-level training. Most of the training budget is spent
upfront, with little left to sustain Change throughout the program. This is a concern because most courses represent a significant investment to the company and
there is a Risk of having the wrong people trained before major organizational decisions are complete.

3.2 Recommended approach to training

This approach will sustain involvement over the length of the program, maximize education spend, and ensure that training is delivered on a just-in-time (JIT) basis.
The approach begins with a simulation. Simulations are valued for their ability to touch people at a “feeling” level, to firmly anchor the requirement for Change. “I hear
and I forget, I see and I remember, I do and I understand.” – Confucius, 600 BC
Simulation is then best followed by a core Foundation training as a level-set. This basic training is then best followed with a Mobilization Workshop as part of your
overall training strategy.
Introducing a Mobilization Workshop as the next step in your training strategy is intended to further enhance the effectiveness of Management of Change. Mobiliza-
tion provides a focused workshop for key stakeholders, where they assess their current ITSM environment and agree via group consensus on the need for Change,
emerging with a strong team commitment to and ownership of the ongoing program activities.
The remainder of the training plan over the Lifecycle of the program should be designed as role-based (once the new process roles have been assigned), with ap-
propriate funding over time, and should include a strategy for training new employees entering into the process-based organization.
3.3 Factors to Consider in Your Training Strategy
• Corporate geography, time zones, and shifts
• Budget
• JIT training
• Role-based training
• Overall program approach and objectives
• Formal certification training AND customized training, for example, ITIL 101’s (basic) process/product training unique to the organization

3.4 A Winning Program Strategy

• Respect the cultural/behavioral management of change – mobilize early and focus on quick wins.
• The most successful ITSM programs are those that are not called ITSM programs.
• Introduce formal training and communication planning.
4 Services “A means of delivering value to customers by facilitating the outcomes that the customers want to achieve
without the ownership of specific costs and risks.”

The differences

Product Service
Tangible Tangible (products) / intangible (activities)
Produced first, sold afterwards Sold first, developed afterwards
A product can be involved in one or more Services A Service is compiled from mostly a large number of
products
Perceived as an “end-to-end” Service Perceived as an “end-to-end” service
Performance measured in IT-technical terms Performance measured at the customer interface
Mostly defined in IT terms Defined in the “customer’s language”
Directly supporting the Services Directly supporting the “business processes”

Source: Quoted text source is ITIL® Service Lifecycle Suite 2nd Edition, 2011. Copyright © AXELOS Limited 2014. Material is reproduced under license from AXELOS.
 PRODUCTS

Store Information

Store Files

Store What?
SERVICE
Store Equipment

Storage Service

Online Database

Store How?

Portable Devices

Secure Cabinets
5 Processes - What Are We Talking About?
Processes are routines:
• To organize the work as efficiently and effectively as possible.
• To prevent reinventing the wheel.
• To measure and improve.
Benefits of Process Management:
• Provide clarity to the business about what IT does.
• Impose organizational discipline.
• Define organizational boundaries and roles.
• Support continuous improvement.
• Allow processes to be audited and improved.
5.1 What Is a Process?
It is a set of activities in a logical order that transfers input into output, to achieve an objective for a customer.

Process
Input
Process Control Triggers Process Process Enablers

Process Policy
Process Process Work
Process Owner Metrics Instructions
Process
Resources
Process Process
Process Documentation
Activities Roles
Process
Process Objectives Capabilities
Process Process
Procedures Improvements
Process Feedback

Process Including Process

Output Reports and Reviews

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
5.2 Characteristics of a Process
• Are measurable
• Have specific results
• Have customers and/or stakeholders
• Consist of a number of successive activities
• Have a clear start and end, as well as input and output
• Are repeatable
• Provide value for the organization/stakeholders
• Respond to specific events – while a process may be ongoing or iterative, it should be traceable to a specific trigger
Each previous activity delivers value to the following activity in the process; otherwise, this activity should be eliminated.
5.3 Characteristics of a Process According to ITIL
Measurable
• Performance driven
• Cost, quality, duration, productivity, and so on
Specific results
• Delivery of a specific result
• Individually identifiable and countable
Customers
• Result delivery to a customer or stakeholder
• Could be internal or external
• Meeting customer expectations
Respond to a specific event
• Traceable to a specific trigger
5.4 Critical Success Factors in Process Management Design and Implementation
• Kick off an improvement initiative or process
design workshop with the processes that are
clearly defined already. Some room to alter these
processes must be allowed to facilitate Change
acceptance.
• Ensure that the processes are detailed at the right
levels. An overly detailed process description
will limit the flexibility required to customize the
process for the organization.
• Start process design activities with a clear vision • Demonstrate management commitment.
and specific objectives. • Demonstrate strong training, communication, and
• Delegate the process tasks, responsibilities, and awareness campaigns.
process ownership to people with the right level of
skills, knowledge, and authority.
• Ensure the correct positions of the Process Owners,
as required uniquely by the organization. Consider
a mix with Process Managers, as appropriate.
5.5 Process Implementation Approach
While it is important to note that
there is no “one-size-fits-all” formula
for process implementation, here is
a set of steps that can be considered
when designing your program.
Remember, when you start with
implementing processes, you are
also changing the way people are
used to working. Normally, people
will resist Change, so it is important
to also consider your MOC approach,
such as Kotter’s 8 Steps for Change,
as part of your overall process
design/improvement activities
within your ITSM program.
1 Define the vision: Why you want to work
with processes, what is to be achieved, what 5 Design and document the processes: Involve
the key stakeholders in the organization to help
is the relationship with the company’s strategy, prevent resistance to Change and to build a
and what are the business requirements strong crew of Change agents.
– remember that Process Management is
not a goal by itself.
6 Implement the processes: Activate the pro-
cesses according to the defined descriptions.
2 Define the objectives: Ensure that you use
SMART (Specific, Measureable, Achievable,
7 Audit the processes: Audit the processes peri-
Realistic, and Timely) as an approach to define odically to ensure compliance and adherence.
measureable objectives in line with the
company’s strategy and vision.
8 Measure the performance of the processes:
Based on defined Key Performance Indicators
3 Identify the processes: Decide which
processes are in scope.
(KPIs), the processes can be measured for ef-
ficiency and effectiveness in support of further
improvement over time.
4 Define the format of the processes: Processes
should be defined using a standard template
for creating a high level of acceptance, reorga-
nization, and availability – see Appendix C in
Service Design – Cabinet Office, 2011 for more
details.
6 Functions and Roles
“Service Management is a set DIFFERENCE BETWEEN FUNCTIONS AND ROLES
of specialized organizational
It is important to understand the difference between a formal function within an organization and
capabilities for providing
the process roles that the function is expected to perform. A formal function may fulfill more than one
value to customers in the form
specific Service Management role and conduct activities relating to more than one process.
of services. The capabilities
take the form of functions For example, a formal function, Network Administrator, may be responsible for performing Incident Manage-
and processes for managing ment as well as Capacity Management activities. Although the Network Administrator may report to a func-
services over a Lifecycle, with tional line manager, the Network Administrator is also responsible for performing activities for the Service
specialization in strategy, Desk Manager, the Incident Management Process Owner, and the Capacity Management Process Owner.
design, transition, operation,
and continual improvement.”

Source: Quoted text source is ITIL® Service Lifecycle Suite 2nd Edition, 2011. Copyright © AXELOS Limited 2014. Material is reproduced under license from AXELOS.
6.1 Functions

• Are units of organizations specialized to perform
specific types of work and be responsible for
specific outcomes.
• Are self-contained, with the capabilities and
resources necessary for their performance and
outcomes.
• Have their own body of knowledge, accumulated
through experience.
• Provide structure and stability to organizations.
• Typically define roles and the associated authori-
ties and responsibilities for a specific performance
and outcome.
• Tend to optimize work methods locally to focus
on assigned outcomes.
• Poor coordination between functions, combined
with an inward focus, leads to functional silos that
hinder the alignment and feedback critical to the
success of the organization as a whole.
• Well-defined processes can improve productivity
within and across functions.

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
6.2 Roles “A set of responsibilities defined in a process and assigned to a person or team. One
person or team may have multiple roles, for example, the roles of Configuration
Manager and Change Manager can be performed by one person.”

ROLE RESPONSIBILITY
Process Owner Is accountable for the overall quality of the process and oversees the management of and
compliance with the processes, procedures, data models, policies, and technology associated
with the IT business process.

Process Manager Is responsible for the Operational Management of a process. There may be several Process
Managers for one process, for example, regional or departmental Change Managers or IT
Service Continuity Managers for each data center.

Service Owner Is accountable for the delivery of a specific service, regardless of where the underpinning
technology components, processes, or professional capabilities reside.

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
7 RACI RACI is an authority model used to help define roles and responsibilities.

RACI is an acronym for the four main roles of:

R A C I
RESPONSIBLE ACCOUNTABLE CONSULTED INFORMED

The person or people respon- Only one person can be The people who are The people who are kept
sible for getting the job done accountable for each task consulted and whose opinions up-to-date on progress
are required
7.1 Building a RACI

“Whether RACI or some other tool or model The authority or RACI matrix clarifies — to all involved — which activities they are expected to fulfill and identifies
is used, the important thing is to not just any gaps in Service delivery and responsibilities. The RACI matrix can also be used to assess and develop staffing
leave the assignment of responsibilities models in the following way:
to chance or leave it to the last minute to
decide. Conflicts can be avoided and
decisions can be made quickly if the 1 2 3 4 5 6
roles are allocated in advance.”

Identify Identify/define Conduct Identify Distribute Ensure

the activities/ the functional meetings and any gaps or the chart and that the as-
processes. roles. assign RACI overlaps, for incorporate signments are
codes. example, where feedback. activated in the
there are two organization.
As or no As.

Source: Quoted text source is ITIL® Service Lifecycle Suite 2nd Edition, 2011. Copyright © AXELOS Limited 2014. Material is reproduced under license from AXELOS.
Example RACI Matrix
Director Service Service Level Problem Security Procurement
Management Manager Manager Manager Manager

A ctivity 1 AR C I I C

A ctivity 2 A R C C C

A ctivity 3 I A R I C

A ctivity 4 I A R I

A ctivity 5 I I A C I

In the RACI model, only one person can be accountable for an activity while “In this model, accountable means end-to-end accountability for the process.
several people may be responsible for an activity or parts of an activity. Accountability should remain with the same person for all activities of a
process.”
Source: Quoted text source is ITIL® Service Lifecycle Suite 2nd Edition, 2011. Copyright © AXELOS Limited 2014. Material is reproduced under license from AXELOS.
7.2 Critical Success Factors with RACI
• Having more than one person accountable for a process, meaning that, in
practice, no one is accountable
• Delegation of responsibility or accountability without necessary authority
• Focusing on matching processes and activities with departments
• Incorrect division/combination of functions; conflicting agendas or goals
• Combination of responsibility for closely related processes, such as Incident
Management, Problem Management, Configuration Management, Change
Management, and Release Management

Be aware of the time demands of each of the activities because the immediate activities will always take precedence over the more proactive activities.
For example, combining Incident Management activities with Problem Management activities within the same function.

Identify the gaps and remove the overlaps for the best approach to process efficiency and effectiveness.

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
7.3 The Service Management Process Maturity Framework

The Service Management Process Maturity Framework (PMF) is the de facto standard for measuring the maturity of any process.
It is important to create an original baseline when starting your ITSM program However, be cautious in this approach because it may be difficult to find
to answer the “Where are we now?” question posed in the Continual Service benchmarks that come significantly close to the unique characteristics of your
Improvement (CSI) model. The PMF can be used to assess this initial baseline. organization. These benchmarks can be used to answer the “Where do we want
Because this approach is industry standard and has been in place for several to be?” question within the CSI model.
years, it may be possible to assess your organization’s maturity against industry
benchmarks.

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
7.4 When to Assess?
A way to think about assessment timing is in line with the Deming
improvement Lifecycle.
Plan (Project Initiation)
assess the targeted processes at the
start of process introduction to form
the basis for a process improvement
project.
Plan (Project Midstream)
a check during process implementa-
tion or improvement activities serves
as validation that process project
objectives are being met and, most
What to Assess?
At the end of a process project, it is important to vali-
date the increased maturity of the process and the
process organization because of the overall project.
importantly, provides tangible
evidence that benefits are being
Assess the:
achieved from the investment of time
Vision and steering
and resources in process initiatives.
Process
Do/Check (Process in Place)
at the end of a process project, it is
People
important to validate the increased
Technology
maturity of the process and the
process organization because of the Culture
overall project.
Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
7.5 The Process Maturity Framework (PMF)

In term of:

Vision and Steering

People
5 Optimizing

Processes

Te c h n o l o g y
4 Managed

Culture 3 Defined

2 Repeatable

1 Initial

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
Initial
(Level 1)
The process has been recog-
nized, but there is little or no
Process Management activity.
The process is assigned as
of no importance, with no
resources or focus within the
organization. This level can
also be described as ad hoc or
occasionally even chaotic.
Repeatable
(Level 2)
The process has been
recognized and is allocated
little importance, resources,
or focus within the operation.
In general, activities related to
the process are uncoordinated,
irregular, without direction,
or directed toward process
effectiveness.
Defined
(Level 3)
The process has been recog-
nized and is documented but
there is no formal agreement,
acceptance, or recognition of
its role within IT operations as
a whole. However, the process
has a process owner, formal
objectives, and targets with
allocated resources and is
focused on the efficiency as
well as the effectiveness of the
process. Reports and results
are stored for future reference.
Managed
(Level 4)
The process has now been
fully recognized and accepted
throughout IT. It is Service
focused and has objectives
and targets that are based on
business objectives and goals.
The process is fully defined,
managed, and has become
proactive, with documented,
established interfaces and
dependencies with other IT
processes.
Optimizing
(Level 5)
The process has now been
fully recognized and has
strategic objectives and
goals aligned with the overall
strategic business and IT
goals. These IT goals have
now become institutionalized
as part of everyday activities
for everyone involved in the
process. A self-contained, con-
tinual process of improvement
is established as part of the
process, which is now develop-
ing a pre-emptive capability.

1 2 3 4 5
Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
8 Metrics

8.1 Succeed with Measurements

One of the management trends of the past years is to work according to performance indicators. Organizations use performance indicators to check whether or not
the “ship is still going in the right direction.”

This is sometimes referred to as the “organization’s cockpit” or dashboard.

This approach to use metrics and measurements throughout the ITSM program answers the “Did we get there?” question posed in the CSI model.
8.2 Why Measure?
STRATEGY VISION

TO VALIDATE

YOUR
TO TO
FACTUAL EVIDENCE MEASUREMENT TARGET AND METRICS
JUSTIFY DIRECT
FRAMEWORK

TO INTERVENE

CHANGES AND
CORRECTIVE ACTIONS

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
It is important to link the
creation and management
of KPIs and metrics to the
corporate vision, mission,
goals, and objectives.
Ask yourself
What does the KPI really tell us about achieving the goal?
How easy is it to analyze the KPI, and does the KPI support decision making?
How accurate and stable is the KPI?
At what frequency do we need to report on the KPI?
Who owns the KPI?
VISION

MISSION

GOALS

OBJECTIVES

CSF

KPI

METRICS

MEASUREMENTS

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
8.3 Continual Service Improvement Process

1 2
IDENTIFY THE
Data
DEFINE WHAT YOU
Wisdom STRATEGY FOR WILL MEASURE
IMPROVEMENT
Vision
apply
Business need

7 3
Strategy
IMPLEMENT GATHER THE DATA
Tactical goals
IMPROVEMENT Who? How? When?
Operational goals
Criteria to evaluate
integrity of data
Operational goals
Service measurement
PLAN

ACT DO
6
PRESENT AND USE THE

4
INFORMATION CHECK PROCESS THE DATA
Assessment summary
Frequency?
Action plans
Format?
Etc.

5
Tools and systems?
ANALYZE THE Accuracy?
INFORMATION
AND DATA
Trends?
Targets?
Improvements
required?
Knowledge Information

Metrics and measures using the 7-Step Improvement model from Continual Service Improvement:
Identify the strategy for improvement, define what you will measure, gather the data, process the data, analyze the information and data,
present and use the information, and implement improvement.
Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
8.4 Goals, Questions, and Metrics Approach

The Goals, Questions, and Metrics (GQM) paradigm (Basili – 1980s) stands the test of time as an approach to assist with identifying metrics.

An example:
Goal Questions Metrics
Reduce the business • Which Services impact the business the most? According to whom? • Current Incident volume, outage time, and

impact of IT outages • What is the current Impact of outages on these business Services? reasons for key IT Service outages

and user-experienced • What are the reasons for these outages? • Identified Problems causing multiple outages

problems. • What are the major perceived Problems according to users? • Changes carried out to rectify Problems
• How can we reduce the amount and duration of these outages and Prob- • Incident volume/outage time following
lems? Changes
• Where can we gain the most success or quick wins?

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
8.5 Balanced Scorecard Approach In early 1992, Kaplan and Norton first introduced the idea of a Balanced Scorecard
in the Harvard Business Review. Since then, many organizations have used this
approach to measure initiative success against corporate strategy.

FINANCIAL Understanding IT costs to the business Customer Availability of IT Services

As customers how do Ability to control IT costs to the business What do we as Quality of IT Services
we view the costs of Economy of IT provision customers expect Performance of IT Services
IT provision? Return on IT infrastructure investments of IT provision? Value for money IT Services
IT contracts management Reliability of the IT Infrastructure
Support of hands-on IT users

INNOVATION Flexibility of the IT infrastructure Internal Service-oriented culture

Does our IT infrastructure Ability to control Changes to IT Services and What must our IT Skilled staff and IT expertise
enable us to continue to the IT infrastructure providers (internally) Efficiency of IT Service provision
Adaptability of the IT infrastructure to Service delivery times
improve the business? excel at?
changing demand in the business Processing capacity
Communication and knowledge transfer
Security
Business productivity in relation to IT costs
Accountability of IT provision
Harnessing (new) technology
Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
8.6 The Format of a Performance Indicator Steps to Develop Performance Indicators

Performance indicators should be defined and documented Here is an example of a step-by-step plan to develop performance
in a format that is owned and maintained as a document CI indicators in the processes. The Process Owner / Manager should:
in the CMDB. For each performance indicator, the following
should be defined and maintained:

• Title • Lead the measurement effort.

• Description • Educate the team about performance indicators and the measurement
• Measurement unit and reporting of corporate standards.
• Report frequency • Create a team for each process to determine measurement points and
• Period of the report capabilities.
• Employees responsible for the delivery of information • Create performance indicator documentation.
• Data sources • Validate the IT and business performance indicators with the manage-
• Performance indicator ownership (role accountable for action ment team.
on any reported exceptions) • Implement measurements and reporting.
8.7 Pitfalls During the Development of Performance Why Use Performance Indicators in Processes?
Indicators
Some of the pitfalls faced when developing performance indicators are:
• Obsessive measurement • Measurements are knowledge.
• Nondirected measurement – measure because we can • Processes are controlled.
• Lack of ownership of results • Improvement points are identified.
• Measurements not linked to business objectives • Facts, instead of opinions, become known.
It is recommended to start with a minimum number of highly relevant perfor- • There are links with policy and strategy.
mance indicators and to add or change them, as required, to validate, direct, • Business decisions are supported.
intervene, or justify ongoing program investment and continuity.
9. Technology
It is recognized that the use of Service Management
tools is essential for the success of all but the very
smallest process implementations. However, it is
important that the tool(s) being used support the
processes, not the other way around. As a rule,
don’t modify processes to fit the tool.
With today’s sophisticated levels of integrated
Service Management applications, it is important
to work closely with your technology partner
to understand possible process functionality
limitations that might be expensive to recode
and support, as required. These decisions and
limitations may need to be taken into account
when designing your processes.
9.1 Service Design Tools
• Assist with automating hardware, software, environment,
process, and data designs.
• Speed up the design process.
• Ensure that standards and conventions are followed.
• Offer prototyping, modeling, and simulation facilities.
• Enable “What if?” scenarios to be examined.
• Enable interfaces and dependencies to be checked and
correlated.
• Validate designs before they are developed and implemented to
ensure that they satisfy and fulfill their intended requirements.
Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
9.2 Tools to Support the Service Lifecycle
• Service achievement, Service Level
Agreement (SLA), Operational Level
Agreement (OLA), contractual and supplier
measurement, reporting, and management
• Consolidated metrics and Metrics Trees,
with views from management dashboards
down to detailed component information,
performance and fault analysis, and
identification
• Consistent and consolidated views across
all processes, systems, technologies, and
groups
• A comprehensive set of search and A Statement of Requirements (SoR) is essential for
reporting facilities, enabling accurate use during the selection process. This can be used as
information and analysis for informed a check list, categorized using the MoSCoW analysis:
decision-making
M
• Management of Service costs
MUST have this
• Management of relationships, interfaces,
and interdependencies
S
• Management of the Service Portfolio and
SHOULD have this if at all possible
Service Catalogue
• Configuration Management System (CMS)
C
• CMDB COULD have this if it does not
• Service Knowledge Management System affect anything else
(SKMS)
W WON’T have this time but
WOULD like in the future
Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
9.3 Service Management Tools

Some aspects that organizations should consider when evaluating Service Management tools: The exact requirements for the
tool must be considered. You
• Breadth and depth of functionality • Ease with which data can be analyzed need to check what the man-
• Flexibility in implementation, usage, and presented datory requirements and the
and data sharing • Data structure, handling, and integration desired requirements are. There
• Implementation complexity • Distributed data input plus central data view are many integrated tools in the
• Ease of use and quality and extent • Experience and commitment of the marketplace to enable the
of supplier training supplier to best practices Service Management processes
• Quality of management information • Data backup and security and provide integration
produced as standard • Cost between the processes.
9.4 The Tool Evaluation Process

Identify your tool requirements before

researching products. Some of your WHAT REQUIREMENTS IDENTIFY PRODUCTS SELECTION CRITERIA
research may result in new require-
ments. Complete this iterative process
(if required) before defining your
selection criteria. EVALUATE PRODUCTS

SHORT LISTING

SELECT A PRODUCT RANK THE PRODUCTS SCORING

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
10 ITIL Service Lifecycle

Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
Service Strategy
Provides guidance on
designing, developing,
and implementing Service
Management, not only as an
organizational capability but
also as a strategic asset.
Service Design
Provides guidance on the
design and development of
Services and Service Manage-
ment processes. It covers
design principles and meth-
ods for translating strategic
objectives into portfolios of
services and Service Assets.
Service Transition
Provides guidance on the
development and improve-
ment of capabilities for tran-
sitioning new and changed
Services into operations. It
also provides guidance on
how the requirements of Ser-
vice Strategy, as architected
in Service Design, are finally
realized in Service Operations
while controlling the risks of
failure and disruption.
Source: Based on AXELOS ITIL® Service Lifecycle Suite 2nd Edition, 2011. Reproduced under licence from AXELOS.
Service Operation
Achieves effectiveness and
efficiency in the delivery and
support of Services, for ensur-
ing value for the customer
and the Service Provider.
Maintains stability in Service
operations while allowing
for Changes in design, scale,
scope, and Service levels.
Continual Service
Improvement
Provides guidance on creat-
ing and maintaining value
for customers through the
provision of approaches and
methods to achieve improve-
ments in Service quality,
operational efficiency, and
business continuity.
w w w. I Tp r e n e u r s . c o m