Content uploaded by Lajos Pálvölgyi
Author content
All content in this area was uploaded by Lajos Pálvölgyi on Jun 15, 2018
Content may be subject to copyright.
PMBOK® versus ITIL® - what can we learn? *
Lajos Pálvölgyi
Abstract
The goal of this paper is to give a systematic review and consideration of the most characteristic
ITIL® concepts, in order to identify ways and opportunities to generate some new ideas and
interpretations to our project management knowledge.
ITIL® (IT Infrastructure Library) provides a best practice based framework, developed since the
late 1980’s by the UK Government’s CCTA, now Office of Government Commerce (OGC). It is
the most widely used and accepted approach to IT service management around the world. ITIL®
was developed relatively independently from project management, and includes several valuable
concepts and well-tried procedures, which can be useful also for project management.
This paper presents some interesting interdisciplinary analogies between IT service management
described by ITIL® (OGC, 2000) and project management, using the framework and
terminology described in the PMBOK® Guide (PMI, 2004). Reviewing ITIL® concepts doesn’t
mean, that the scope of this paper would be limited to IT projects. The scope is actually project
management in general, especially the Monitoring and Controlling Process Group. Based on the
discussed concepts we’ll see the analogy and relevance to important project management issues,
and we’ll try to gain some new ideas, concepts and process to better understand and manage our
projects.
Exhibit 1 – Looking for analogy between ITIL® and PMBOK®
New concept?
Existing concept
Existing concept
New concept?
Existing concept
Existing concept
ITIL
PMBOK
(*) Originally published: In: Project Managament Institute (PMI) Global Congress EMEA Budapest
Proceedings, Newtown Square (PA): Project Management Institute (PMI), 2007. Paper 00101017600.
2
Introduction
There are several connections between ITIL® and project management. Some components of the
IT Infrastructure Library – such as Planning to Implement Service Management, Application
Management or Release Management –, are very closely linked with projects. ITIL® refers to
“Service Management Projects that are implemented to introduce new processes or to improve
the current processes for the delivery or support of IT services.” (OGC, 2000, p 16) Nevertheless
the subject of this paper is something else.
From a theoretical point of view it seems to be very interesting to investigate the possible deeper
analogy between the inherent logic of both managerial areas. Identifying and using analogy,
similar to modelling and simulation, can be a productive method to gain new knowledge in
different research topics (Pálvölgyi, 1981, p 30-36). Following this approach, we are reviewing
the most important ITIL® concepts and looking for possible “mirror images” in project
management for them. We’ll find a number of existing project management concepts on this
way, but also some new ones. Of course, this method could be used also in the opposite direction
(how to apply PMBOK® concepts to ITIL®), but this second approach is out of the scope of this
paper (Exhibit 1).
Service Culture vs. Project Culture
As we can read in the relevant literature, IT Service Management (ITSM) is defined as the
management of IT services to support one or more business areas. The IT Infrastructure Library
describes the “best practice” processes relevant for ITSM. The ITIL® philosophy adopts a
process driven approach which is scalable to fit both large and small IT organisations. The key
objectives of ITSM are: “(1) to align IT services with the current and future needs of the business
and its Customers, (2) to improve the quality of the IT services delivered and (3) to reduce the
long-term cost of service provision.” (Macfarlane & Rudd, 2001, p 4) According to ITIL®, these
objectives can only be realised by the best utilisation of the so called four P’s; people (Users,
Customers, IT staff managers etc), processes, products (tools and technology), and partners.
Looking for the analogy between ITIL® (OGC, 2000) and PMBOK® Guide (PMI, 2004) based
on the statements above, we can say the following. Project management is understood as the
management of a single project to meet project objectives. By satisfying business needs, based
on which the project was initiated, projects support usually one or more business areas of an
organisation. PMBOK® Guide describes processes relevant for project management, which are
generally recognised as “good practice” (PMI, 2004, p 3). This philosophy also adopts a process
driven approach which is scalable to fit both large and small projects and organisations. Some
key objectives could be: (1) to align project execution with the recorded needs of the business
according to approved project documents, (2) to improve the quality of the project execution and
(3) to minimise the costs of the project. Very similar to ITIL®, these objectives can only be
realised by the best utilisation of the four P’s; people, processes, products and partners – also in
case of projects.
3
Customer and User
Following the ITIL® terminology (OGC, 2000, p 7), we can distinguish also in our projects
between Customer and User - not only in IT projects. The Customer defines requirements, orders
the project, pays for it and approves (accepts) the project results, while Users use the project’s
result on a daily basis, having no real decision authority (but they may have some influence on
the Customer). Usually the Customer is the leader of an organisation, while Users are members
of it. Customer and User may have different interests. (The PMBOK® Guide currently doesn’t
make any difference between them.) In case of an internal project the project will have an
Internal Customer and Internal Users. In many cases the Internal Customer can be the Sponsor
itself.
Customer Focus
Customer focus and Service culture are other important concepts in ITIL®, having strong
relationship to each other. Service culture is a Customer oriented culture with the objectives of
Customer satisfaction and helping the Customer to achieve their business objectives (OGC,
2000, p 20-26). Customer focus means understanding the Customers’ language, thinking and
perspective, and to recognise and to meet the real needs of Customers and Users.
Of course, we can apply these important terms also in our projects. Project culture can be
interpreted as a Customer oriented culture, having the objectives of Customer satisfaction and
helping the Customer to achieve his business objectives. Also Customer focus can have the same
or very similar meaning, as in case of ITIL®. But we can not forget, the primary goal of our
project is to meet the project objectives as recorded in the approved project documents, and close
the project on time and on budget. In case of any changes we therefore need to use the Integrated
Change Control process as discussed in the PMBOK® Guide (PMI, 2004, p 96-102). This can
generate some modifications in one or more of the following baselines: scope baseline, quality
baseline, schedule baseline and cost baseline. Continuous Customer relationship management,
good communication and a well thought-out expectation management can also help to maintain
Customer focus without jeopardising other project results.
Incident Management
ITSM is split into two core sections: (1) Service Delivery, which is concerned with tactical or
medium term management cycles; and (2) Service Support, which describes operational or short
term management cycles. These two core sections contain eleven disciplines. One important
component of Service Support is Incident Management.
According to ITIL®, the goal of Incident Management is “to restore normal service operation as
quickly as possible and minimise the adverse impact on business operations, thus ensuring that
the best possible levels of service quality and availability are maintained. ‘Normal service
operation’ is defined here as service operation within Service Level Agreement (SLA) limits.”
An Incident is “any event which is not part of the standard operation of a service and which
4
causes, or may cause, an interruption to, or a reduction in, the quality of that service.” (OGC,
2000, p 71)
For Incident handling ITIL® describes the following process flow: (1) Incident detecting and
recording, (2) initial classification and support, (3) investigation and diagnosis, (4) resolution and
recovery, (5) Incident closure. In case of Service Requests the process goes after step 2 to the
Service Request procedure. Ownership, monitoring, tracking and communication are elements
covering the whole process. (OGC, 2000, p 71-76)
Project Incidents
Considering the possible analogy we can define the concept of Incidents for projects as follows:
a Project Incident is any event that is not part of the planned project execution and which causes,
or may cause, a failure (trouble) to, or a reduction in, the quality of the project execution.
According to this interpretation a Project Incident is any deviation from the plan (for example:
schedule delay, cost overrun, poor quality, conflict between project team members), or any other
event, which can have any negative impact on project execution, and needs to be managed. The
goal of Project Incident Management could be to restore normal project execution as quickly as
possible and minimise the adverse impact on project objectives, thus ensuring that the best
possible levels of process quality and continuous project execution are maintained. ‘Normal
project execution’ is understood here as execution within predefined control limits recorded in
the project management plan.
In ITIL® the prioritisation of Incidents is based on impact and urgency. “Urgency is an
assessment of the speed with which an Incident needs resolution. Impact reflects the likely effect
the Incident will have upon the business service. The priority for allocating resources to
resolution of an Incident is based upon a combination of impact and urgency, together with other
relevant factors such as availability of resources.” (Macfarlane & Rudd, 2001, p 17) Target
resolution times can be defined based on the priorities. Incident status can be, e.g.: new,
accepted, scheduled, assigned, work in progress, on hold, resolved, closed. There are two kinds
of escalations: in addition to the well known hierarchical escalation path there is a functional
escalation route as well, connecting the first line support to the second line (specialists), and the
second line to the third line, for example to a third party. (OGC, 2000, p 74-76)
Using this approach all the major ideas of Incident Management seem to be applicable to
projects. Urgency will be an assessment of the speed with which a Project Incident needs
resolution. The impact will reflect the likely effect the Project Incident will have upon the project
objectives. The process flow described above, the priority setting, target resolution times,
Incident status, the hierarchical and functional escalations can be relevant and used in some
processes of the Monitoring and Controlling Process Group discussed in the PMBOK® Guide.
But unlike to ITIL® some deviations from plan may have also positive impact on projects, for
example: working package finished earlier as scheduled and cost savings achieved. Based on
this, we can redefine a Project Incident, as any event which means a deviation from the planned
project execution and which causes, or may cause, a positive or negative impact on the project
execution (and consequently on project objectives). With this modified interpretation we are
5
already very close to the project risk definition, as described in PMBOK® Guide (PMI, 2004, p
238). Based on this connection, it seems to be a good idea to make later a more detailed
investigation on how to apply Incident Management process knowledge to Project Risk
Management.
Service Desk
The Service Desk (SD) is - unlike other disciplines discussed in the Service Support section of
ITIL® - a function and not a process. It is the principal operational interface between the IT
organisation and the Users. Good first impression, effective communication, access to tools and
relevant databases, interfaces to other ITIL® disciplines, and quick solutions are major features
of a well operating SD.
The goal of a SD is, as defined in ITIL®, to act as the central (single) point of contact between
the User and IT service management, to handle Incidents and Service Requests, to restore service
whenever possible, to maximise service availability and to provide an interface for other
activities such as Change, Problem, Configuration, Release, Service Level and IT Continuity
Management. The SD is the first level support to the service, having the following major
responsibilities: receive and record all calls from users, deal directly with simple requests and
complains, provide initial assessment of all Incidents, make a first attempt at resolution and/or
refer to the second line support, monitor and escalate all Incidents based on the agreed Services
Level Agreements (SLA), keep users informed on status and progress, manage all Incidents to a
closure and produce management summaries. (OGC, 2000, p 27-36)
Important features of a SD are among others: a central log of all Incidents (numbered and time
stamped), diagnostic scripts and other aids (knowledge base), support by Configuration
Management tools, an impact coding system, automatic escalation procedures, an interface to
SLAs, classification of Incidents at call opening and closure, a regular progress reporting. The
SD should be aware of business needs, and of the impact of a failure upon the business. The
target effectiveness metrics can be built on different key performance indicators (KPIs). The
types of SD can be: local, central, and virtual SD. (OGC, 2000, p 36-69)
Project Desk
Looking for the possible analogy again we can define the concept of Project Desk (PD) as
follows. The goal of a PD could be to act as the central (single) point of contact between
stakeholders (including project team members and other resources) and project management
team (PMT), to handle Project Incidents and Requests, to restore planned project execution
whenever possible, to ensure trouble-free project execution as much as possible and to provide
an interface for other project management processes. The PD is the first level management
support to the project execution, having the following major responsibilities: receive and record
all calls and escalations from stakeholders, deal directly with simple troubles, requests and
complains, provide initial assessment of all Project Incidents, make a first attempt at resolution
and/or refer to the second line of project management, monitor and escalate all Incidents based
on the approved project management plan and other relevant project documents, keep
6
stakeholders informed on status and progress, to manage all Incidents to a closure and produce
management reports. Of course, in project management context PD can have also the proactive
role and responsibility to collect and analyse incoming performance reports, for example in order
to identify and handle Project Incidents.
The second paragraph about SD above could be “translated” also this way into the project
management context. But don’t forget, we are speaking here about management and not about
IT. That means for example, that knowledge base and diagnostic scripts are dealing in this
context not with technical, but with management issues (for example: what to do in case of a
resource problem or an activity delay). The PD could be the front office of the PMT relieving the
rest of the team and as a result allow the team to concentrate on other important tasks. The role
of a PD can be carried out for example by a project office, a project assistant, or a selected PMT
member (“officer on duty”), and can be very helpful especially in larger projects.
Problem Management
Problem Management is another important chapter discussed in the Service Support section of
ITIL®. The goal of this process is “to minimise the adverse impact of Incidents and Problems on
the business that are caused by errors within the IT infrastructure, and to prevent recurrence of
Incidents related to these errors.” A Problem is an unknown underlying cause of one or more
Incidents. A Known Error is a successfully diagnosed Problem (the root cause is known) for
which a temporary workaround or a permanent solution has been identified. (OGC, 2000, p 95)
Problem Control, as part of ITIL®, focuses on transforming Problems into Known Errors
seeking to get the root cause of Incidents, while Error Control’s responsibility is to resolve
Known Errors using the Change Management process. The steps of Problem Control are:
problem identification and recording, problem classification, problem investigation and
diagnosis, and root cause analysis (determining the unknown underlying cause of the problem).
The responsibilities of Error Control are: error identification and recording, error assessment,
recording error resolution (this is the point at which the request for change will be raised for a
permanent resolution), error closure, and monitor resolution progress. (OGC, 2000, p 96-109)
Project Problems
Investigating the possible analogy again we could interpret the goal of Project Problem
Management as follows. The goal of this (sub)process is to minimise the adverse effect of
Project Incidents and Problems on achieving project objectives caused by troubles and risk
events in the project execution and to proactively prevent the occurrence of Project Incidents,
Problems and risk events. A Project Problem is the unknown underlying cause of one or more
Project Incidents. It will become a “Known Trouble” when the root cause is known and a
temporary workaround or a permanent solution has been identified. We can follow the steps of
Problem Control and Error Control processes described above also in the project management
context. Looking at PMBOK® Guide we can say that recorded Problems are in the project issue
log. But issue logs are mentioned only in two processes: at the Manage Project Team process and
the Manage Stakeholders process (PMI, 2004, p 218, 236), and not in other control processes.
7
Consequently the shown analogy can deliver maybe some new ideas to other elements of the
Monitoring and Controlling Process Group.
Based on the ITIL® analogy we can say, the responsibility of Project Problem Management is to
resolve Project Problems quickly and effectively, to ensure resources are prioritised to resolve
Problems in the most appropriate order based on the need of the project, to improve productivity,
and to provide management information. Problem Management acts not only reactively, but also
proactively. Proactive Problem Management covers the activities aimed at identifying and
resolving Project Problems before Incidents occur, such as trend analysis (based e.g. on Incident
database), or supply workaround and/or avoidance instructions to stakeholders to prevent future
Incidents. The proactive part of the so interpreted Project Problem Management has obviously a
strong relationship to Project Risk Management, partly overlapping this PMBOK® Knowledge
Area (PMI, 2004, 237-268).
Pain Value Analysis
Different useful techniques belong to the Problem Management, as described in ITIL®, such as
Pain Value Analysis (PVA), Major Problem Reviews, Kepner and Tregoe Analysis, and
Ishikawa Diagrams. The last one is also included into the PMBOK® Guide (PMI, 2004, p 192),
but the other techniques are less known in the project management context. As an example of
how to use these techniques in projects, let’s have a closer look at the PVA.
In project management context PVA would be a snapshot technique showing which group of
Incidents is causing the most “pain” to the project at a given point in time. For example, the
calculation could be made as shown:
Pain Value = number of Incidents x severity x weighting factor
First we need a reasonable grouping of all Incidents (based on common underlying cause, if
possible). Severity in this formula should be understood as priority, but indicating the higher
priority with a larger number. As we already know, priority is based on impact and urgency. The
weighting factor should be any data meaningful to the business, and can vary dynamically with
the real situation. For example, let’s assume: (1) we have three groups of Incidents related to
three different deliverables, (2) we have the same delay in case of all the three deliverables, and
(3) every delay has received the same priority, but (4) one deliverable became few days ago
much more important for the Customer, based on a new market situation. In this example it is
reasonable to give a higher weighting factor related to the business critical deliverable, and to
focus on it first (if there is no other reason not to do this) to achieve better Customer satisfaction.
This could be also an example of how to ensure Customer focus during project execution.
After having calculated the pain values for each group of Incidents, we can use the Pareto
Diagram technique, as described in PMBOK® Guide (PMI, 2004, p 195). In these diagrams,
rank ordering is used to guide corrective actions. The PMT should take action first to fix
problems causing the Incidents with the highest pain value.
8
Configuration Management
Configuration Management is a central part of the Service Support section of ITIL®. The goal of
this process is to provide a logical model and accurate information of the IT Infrastructure.
Configuration is a generic term, used to describe a group of Configuration Items (CI), which
work together to deliver an IT Service, or a recognisable part of it. A CI is any component that
needs to be managed in order to deliver an IT Service. (OGC, 2000, p 121-122)
Configuration Management Database
Information about each CI is recorded in form of configuration records in the Configuration
Management Database (CMDB) and is maintained throughout its lifecycle according to ITIL®.
The CMDB is of central importance within ITSM, recording the attributes of each CI, and
relationships with other CIs. A CMDB may contain a lot of other information linked to CIs, for
example Incident, Problem, Known Error or Change records. This single repository of
information will be accessed across the ITIL® processes and is a major driver of consistency
between them. (OGC, 2000, p 121-157)
Looking at the analogy between ITIL® and PMBOK® processes, we can develop some
definitions for the project management context again. The goal of project configuration
management could be to provide a well structured database of all project relevant information by
identifying, controlling, maintaining and verifying the versions of all configuration items (CI) in
existence. The term ‘configuration’ will be used to describe a group of CIs, which work together
to meet project objectives (or a recognisable part of it). A CI is any component that needs to be
managed in order to meet project objectives. It is very important, that CIs can not only be
hardware or software, or any component of a deliverable, but also documents, tools, procedures
and people – or anything else.
The PMBOK® Guide (PMI, 2004, p 90) describes the Configuration Management System
(CMS), which is a subsystem of the overall Project Management Information System, as “a
collection of formal documented procedures used to apply direction and surveillance to: identify
and document the functional and physical characteristics of a product, result, service, or
component; control any changes to such characteristics; record and report each change … “
(PMI, 2004, p 354) If well understood, CMS seems to be the analogue of CMDB of ITIL®.
But CMDB may include any kind of information relevant for ITIL® processes, therefore it
seems to be better to say, CMS may also include any kind of information relevant for a project.
Following this ITIL® driven interpretation the CMS (=CMDB) will be the only integrated
knowledge base of the project. Having only one single information repository (whatever its name
is), should be good news for Integration Management. Of course, this knowledge base can have
an appropriate name and can be physically distributed and implemented in many ways.
9
Change Management
Change Management belongs to the Service Support section of ITIL®. This process is also well
known in the project management context. Let’s look first what ITIL® says. “The goal of the
Change Management process is to ensure that standardised methods and procedures are used for
efficient and prompt handling of all Changes, in order to minimise the impact of Change-related
Incidents upon service quality.” (OGC, 2000, p 165) Change Management is responsible for
controlling Changes to all CI’s within the live environment. But it is not responsible for Changes
within ongoing application development projects, which are managed by the Integrated Change
Control of that project. Both types of change management processes should be integrated with
each other.
Core elements of process knowledge
Using the analogy again, we can say, Change Management in a project should ensure that
standardised methods and procedures are used for an efficient and prompt handling of all
Changes, in order to minimise the impact of any related Incidents upon the project. Change is the
addition, modification or removal of any CI which could have an impact on project objectives.
Changes can effect the widest range of all CIs, procedures, documents, people etc. The major
steps of the process could be: initiation, logging and filtering, prioritisation, categorisation,
assessment, decision (approval or rejection), implementation, review and closure. Only formally
documented requested Changes can be processed.
The Change Control Board (CCB) (= ITIL® analogue: Change Advisory Board) is responsible
for assessing the impact of requested Changes and estimating the resource requirements in case
of significant Changes, while the Change manager does the same for minor changes. Major
Changes should be handled by the Project Steering Committee and urgent changes by the CCB
Emergency Committee. The Forward Schedule of Changes (FSC) contains details of all
approved Changes and their implementation dates for an agreed period, that have to be
incorporated into the project management plan. (OGC, 2000, p 170-179)
The process can be accelerated by standard Changes, which are accepted solutions to an
identifiable and relatively common set of requirements, where authority is effectively given in
advance of implementation (pre-approved Changes). Standard Changes can be supported by
Change models. The analogy works again; we can apply also this process knowledge to projects.
A Change model is a predefined procedure of dealing with Changes of a known type. It is a kind
of process template applied to well-defined standard Changes ensuring that they are managed to
a proven, predefined process. (OGC, 2000, p 176-178)
An example for a Change model in a project could be the following. As part of the project we
should deliver training for a high number of different locations, but the number of participants in
the locations is not exactly known yet. We should be prepared for a +/- 30% range of difference.
In this case we can develop a master plan for any location and a Change model of how to
customise this to the current situation by the local project team, identifying the input parameters
of this model and also all the consequences of the deviations (on schedule, resources, cost etc.).
10
As a short summary, some typical interactions between Change Management and other related
major ITIL® processes are shown on Exhibit 2.
Exhibit 2 – Some typical interactions between ITIL® processes
Further processes
It will be explained in the presentation, how to “translate” further concepts into project
management context, including terms of the Service Delivery part of ITIL®. This was not
possible in the limited framework of this paper.
References
Macfarlane, I. & Rudd, C. (2001) IT Service Management. Reading: itSMF Ltd.
OGC (2000) Service Support. London: Office of Government Commerce. The Stationery Office.
OGC (2000) Service Delivery. London:
Office of Government Commerce. The Stationery Office.
Pálvölgyi, L. (1981) A modellezés lehetőségeiről a pedagógiában. (On the opportunities of
modeling in the pedagogy) Budapest: Akadémiai Kiadó.
PMI (2004) A guide to the project management body of knowledge (PMBOK
®
Guide) (Third
ed.). Newtown Square, PA: Project Management Institute.
PMI (2006) Projektmenedzsment útmutató (PMBOK
®
Guide) (Third ed.). Project Management
Institute. Budapest: Akadémiai Kiadó.
Rudd, C. (2004) An Introductory Overview of ITIL
®
. Reading: itSMF Ltd.
… …
= Incident Management
… … = Problem Management
… … = Change Management
Workaround
developed
Incidents impact reduced Incidents no longer occur
Call
Incidents keep happening
Change effected
Problem
>
Known Error
Problem Control
Escalation
Ongoing Incident Management
Change request
Error Control
Problem solved
CMDB
© 2007, Dr. Lajos Pálvölgyi, PMP
Project Management Institute, Hungarian Chapter
PROJECON Project Consulting Ltd.
E-Mail: lajos@projecon.hu / Web: www.projecon.hu
Linkedin: http://hu.linkedin.com/in/palvolgyi
ResearchGate: : https://www.researchgate.net/profile/Lajos_Palvoelgyi
