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 management ideas and well-tried procedures, which can be useful also for the project management practice.
This paper presents some interesting analogies between IT service management described by ITIL® (OGC, 2000) and project management, using the framework and terminology described in the A Guide to the Project Management Body of Knowledge (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 knowledge to better understand and manage our projects.
Exhibit 1 – Looking for analogy between ITIL® and PMBOK® Guide
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® Guide 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.
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 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 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 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. 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® Guide 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.
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® Guide 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.
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.).
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
We'll show 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.