The IT Service Capability Maturity Model∗ Frank Niessinka , Viktor Clerca , Ton Tijdinka , and Hans van Vlietb a
CIBIT Consultants | Educators, P.O.Box 2, 3720 AA, Bilthoven, The Netherlands Tel: +31 30 2308900, Fax: +31 30 2308999,
[email protected] b
Department of Computer Science, Faculty of Sciences, Vrije Universiteit De Boelelaan 1081a, 1081 HV, Amsterdam, The Netherlands Tel: +31 20 4447768, Fax: +31 20 4447653,
[email protected]
IT Service CMM Version 1.0, Release Candidate 1 January 28, 2005
∗ R
CMM
is registered in the U.S. patent and Trademark Office. Accuracy and interpretation of this document are the responsibility of CIBIT Consultants | Educators. Carnegie Mellon University has not participated in this publication.
Contents 1
Introduction 1.1 Origin of the IT Service CMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Structure of this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 2 2
I
The IT Service CMM: Background, Concepts, Structure, and Usage
5
2
The IT Service Capability Maturity Model 2.1 The structure of the IT Service CMM . . . 2.2 Characteristics of the IT Service CMM . . . 2.3 Primary objectives of the IT Service CMM . 2.4 The maturity levels of the IT Service CMM 2.5 Design decisions . . . . . . . . . . . . . .
3
4
II 5
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
7 7 7 9 10 10
Interpreting the IT Service CMM 3.1 Interpreting the Key Practices . . . . . . . . . . . . . . . . . . . . . . 3.2 Interpreting the Common Features . . . . . . . . . . . . . . . . . . . 3.3 Service Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Organizational Structure and Roles . . . . . . . . . . . . . . . . . . . 3.5 Service Request and Incident Management and Problem Management
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
13 13 13 14 16 17
The Maturity Levels of the IT Service CMM 4.1 Level 1: Initial . . . . . . . . . . . . . . 4.2 Level 2: Repeatable . . . . . . . . . . . . 4.3 Level 3: Defined . . . . . . . . . . . . . 4.4 Level 4: Managed . . . . . . . . . . . . . 4.5 Level 5: Optimizing . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
19 19 19 23 26 27
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
The Key Process Areas of the IT Service CMM The Key Process Areas for Level 2: Repeatable 5.1 Service Commitment Management . . . . . . . . . . . . . . . . . . . . . . . . . i
29 31 31
ii
CONTENTS 5.2 5.3 5.4 5.5 5.6 5.7
6
Service Delivery Planning . . . . . . . . . . Service Tracking and Oversight . . . . . . . Subcontract Management . . . . . . . . . . Configuration Management . . . . . . . . . Service Request and Incident Management Service Quality Assurance . . . . . . . . . .
The Key Process Areas for Level 3: Defined 6.1 Organization Service Definition . . . 6.2 Organization Process Definition . . . 6.3 Organization Process Focus . . . . . 6.4 Integrated Service Management . . 6.5 Service Delivery . . . . . . . . . . . . 6.6 Intergroup Coordination . . . . . . . 6.7 Training Program . . . . . . . . . . . 6.8 Resource Management . . . . . . . . 6.9 Problem Management . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
38 47 56 64 72 77
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
83 83 86 93 99 110 120 125 132 138
7
The Key Process Areas for Level 4: Managed 145 7.1 Quantitative Process Management . . . . . . . . . . . . . . . . . . . . . . . . . 145 7.2 Service Quality Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.3 Financial Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
8
The Key Process Areas for Level 5: Optimizing 169 8.1 Problem Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 8.2 Technology Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . 178 8.3 Process Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
III
Appendices
199
A Acknowledgments
201
B Change history
203
C The IT Service CMM and ITIL compared 205 C.1 IT Infrastructure Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 C.2 Differences and Similarities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 D Mapping the Key Practices to Goals
209
Chapter 1
Introduction This document describes the Information Technology Service Capability Maturity Model, or IT Service CMM for short. The IT Service CMM is a capability maturity model that specifies different maturity levels for organizations that provide IT services. Examples of IT services are the maintenance of software systems, operation of information systems, the management and maintenance of workstations, networks or mainframes, or the provision of contingency services. An important question is how these services should be defined and managed. The complexity of IT applications makes it difficult to properly tune customer IT service needs and IT service provider capabilities. Customers often cannot express their real service requirements and do not know the corresponding performance needs. Likewise, IT service providers often do not know how to differentiate between IT services and how to attune them to a specific customer. The IT Service CMM is aimed at enabling IT service providers to assess their capabilities with respect to the delivery of IT services and to provide IT service providers with directions and steps for further improvement of their service capability.
1.1
Origin of the IT Service CMM
The IT Service CMM described in this document originates from two multi-partner research projects, partly supported by the Dutch Ministry of Economic Affairs. Partners in these projects – ‘Concrete Kit’ (1995-1997) and ‘Kwintes’ (1997-1999) – were Cap Gemini, Twijnstra Gudde, the Tax and Customs Computer and Software Centre of the Dutch Tax and Customs Administration, the Technical Universities of Delft and Eindhoven, and the Vrije Universiteit Amsterdam. These projects were aimed at developing a method to specify and control IT services. The process model used to describe the dynamics of IT service management is depicted in figure 1.1 [19]. The left part of the lemniscate concerns the specification of IT services (upper arrow) and the evaluation and monitoring of the performance of the IT service provider (lower arrow). The right part concerns the evaluation and monitoring of service processes (upper arrow) and the design and organization of those processes. The mutual commitments between IT service provider and customer, laid down in a service level agreement (SLA), play a pivotal role in this scheme. The IT Service CMM captures the activities represented by the four arrows in figure 1.1 in five maturity levels and different key process areas. Level two of the IT Service CMM, developed during the Kwintes project, is aimed at describing what practices organizations need to implement to be 1
2
Introduction
Figure 1.1: IT Service Lemniscate able to consistently traverse the above described IT service lemniscate. These practices include the management of commitments, the tracking of service delivery, configuration management, the planning of service delivery, etc. A third project was initiated in 1999 to specify level three of the IT Service CMM. This project – DOCIS, which stands for Development of an Open-Content IT Service Maturity Model – was coordinated by CIBIT Consultants | Educators1 and involved participants from several universities and companies. As opposed to the Concrete Kit and Kwintes project, the DOCIS project was not sponsored by the government and there is no formal project organisation. Participation was on a voluntary basis. The DOCIS projected ended in January 2005.
1.2
Structure of this document
Part I gives an overview of the model, its structure, the concepts used, and the design decisions made. Part II specifies the key process areas of each of the maturity levels in terms of their goals and common features. Part III contains a number of appendices. Appendix A acknowledges the support we have received from different organizations and people in developing and applying the IT Service CMM. Appendix B describes the change history of this document. Appendix C briefly discusses the differences and similarities between the IT Service CMM and the IT Infrastructure Library (ITIL). Finally, appendix D presents a number of tables that relate the individual key practices to the key process area goals.
1.3
Other publications
Added The IT Service CMM Pocket Guide [4] provides a light-weight introduction to the IT Service
reference to
the pocket CMM. guide 1
The Software Engineering Research Centre was acquired by CIBIT in 2003.
1.3 Other publications
3
Earlier reports on the IT Service CMM and related subjects have been published in [2, 9, 10, 11]. The results of the research projects Concrete Kit and Kwintes are summarized in two books (in Dutch) [15, 20]. A web site is available on the Kwintes project at http://www.kwintes.nl. The development and distribution of the IT Service CMM is coordinated through the IT Service CMM website at http://www.itservicecmm.org. The website contains additional materials besides this document, such as a IT Service CMM questionnaire, DOCIS project documents, and IT Service CMM mailinglists.
4
Introduction
Part I
The IT Service CMM: Background, Concepts, Structure, and Usage
5
Chapter 2
The IT Service Capability Maturity Model In this chapter we describe the IT Service Capability Maturity Model. First, in section 2.1 the structure of the IT Service CMM is presented. Section 2.2 presents the major characteristics of the model. Next, in section 2.3 the objectives of the IT Service CMM are laid out. Section 2.4 presents the maturity levels of the model. Finally, section 2.5 describes the most important design decisions made during the development of the IT Service CMM.
2.1
The structure of the IT Service CMM
The IT Service CMM is based on the Software CMM Version 1.1 [14] (see section 2.5.2 for the motivation of this choice). Where applicable, the descriptions of the IT Service CMM maturity levels and key process areas are adjusted from [14]. The structure of the Software CMM and the IT Service CMM are the same, see figure 2.1. The model consists of five maturity levels, which contain key process areas. For an organization to reside on a certain maturity level, it needs to implement all of the key processes for that level, and those of lower levels. Each key process area is structured using common features. Common features are practices that, when performed together, guarantee that the key process area is implemented and institutionalized. Common features consist of key practices that describe activities that have to be performed or infrastructures that have to be present.
2.2
Characteristics of the IT Service CMM
There are a number of characteristics of the IT Service CMM that are important for understanding its nature. The main focus of the model is the complete service organization, the scope of the model encompasses all service delivery activities, i.e. those activities which are key to improving the service delivery capability of service organizations, the model is strictly ordered, and the model is a minimal model in different senses. 7
8
The IT Service Capability Maturity Model
Figure 2.1: The CMM structure (taken from [14]) Focus The main focus of the model is on the maturity of the service organization. The model does not measure the maturity of individual services, projects or organizational units, but only that of the whole service organization. Scope The model covers the service delivery process. The service delivery process covers all activities involved in creating the result for the customer, starting from identifying the needs of the customer until evaluating the delivered services. It does not cover the development of new services. Strictly ordered The key process areas are assigned to different maturity levels in such a way that lower level processes provide a foundation for the higher level processes. Therefore, an organization has to implement all key processes of level n, n − 1, etc., to reside on level n. This rather strict requirement is feasible because the model is also a minimal model, see below. Note that the model does not prohibit the implementation of key processes from level n + 1, n + 2, etc., before reaching level n, but in general it will be difficult to fully implement key processes from higher maturity levels. Higher level key process areas often build upon activities and infrastructure implemented by lower level key process areas. For example, they key process area Problem Prevention (level 5) builds upon the quantitative data that is only fully available when Quantitative Process Management (level 4) has been implemented. Minimal The IT Service CMM is a minimal model in different ways: • The model only specifies processes needed to reach a certain level of maturity, hence the
2.3 Primary objectives of the IT Service CMM
9
term key processes. The quality of other processes that an organization might use – such as financial administration and human resource management – is not deemed essential to the IT service process maturity of the organization. Therefore, these processes are not part of this maturity model. • The model only prescribes what processes and activities are needed to reach a certain maturity level. The model does not tell you how to implement them, what organization structure to use, etc. For example, one of the activities of the key process area Service Delivery Planning states that ‘The service delivery plan is developed according to a documented procedure’. How exactly that documented procedure looks is not dictated by the IT Service CMM. One way to implement the processes would be to use best practices, such as the best practices for IT management described in the IT Infrastructure Library [3, 13].
2.3
Primary objectives of the IT Service CMM
The objective of the IT Service CMM is twofold: 1. to enable IT service providers to assess their capabilities with respect to the delivery of IT services, and, 2. to provide IT service providers with directions and steps for further improvement of their service capability. The IT Service CMM fulfills these goals by measuring the capability of the IT service processes of organizations on a five level ordinal scale. Each level prescribes certain key processes that have to be in place before an organization resides on that level. Key processes implement a set of related activities that, when performed collectively, achieve a set of goals considered important for enhancing service process capability. Hence, organizations can improve their service capability by implementing these key processes. More formally, we define IT service process capability as the range of expected results that can be achieved by following a service process. IT service process performance represents the actual results achieved by following an IT service process. IT service process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled and effective. The IT Service CMM focuses on measuring and improving the IT service process maturity of IT service organizations. An organization that scores high on the IT Service CMM scale will be able to: • deliver quality IT services, tailored to the need of its customers; • do so in a predictable, cost-effective way; • combine and integrate different services, possibly delivered by different service providers, into a consistent service package; • continually and sustainably improve service quality in a customer-focused way.
10
The IT Service Capability Maturity Model
2.4
The maturity levels of the IT Service CMM
We measure the service process maturity of organizations on a five level ordinal scale. The first – initial – level has no associated key process areas. This is the level where all IT service organizations reside that have not implemented all level two key process areas. Level two is the repeatable level. Organizations that have reached level two will be able to repeat earlier successes in similar circumstances. Thus the emphasis of level two is on practices for delivering individual services to individual customers. On level three, the defined level, the service organization has defined its processes and is using tailored versions of these standard processes to deliver the services. By using common organization-wide standard processes, the process capability to deliver services consistently is improved. At level four, the managed level, organizations gain quantitative insight into their service processes and service quality. By using measurements and an organization-wide measurement database organizations are able to set and achieve quantitative quality goals. Finally, at level five, the optimizing level, the entire organization is focused on continuous process and service improvement. Using the quantitative measurements the organization prevents problems from recurring by changing the processes.
changed
The organization is able to introduce new technologies and processes into the organization in an
’services’
into orderly manner. ’processes’
More formally, we define the five maturity levels as follows: 1. Initial level: The IT service delivery process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics. 2. Repeatable level: Basic service management processes are established. The necessary discipline is in place to repeat earlier successes on similar services with similar service levels. 3. Defined level: The IT service processes are documented, standardized, and integrated into standard service processes. All services are delivered using approved, tailored versions of the organization’s standard service processes. 4. Managed level: Detailed measurements of the IT service delivery process and service quality are collected. Both the service processes and the delivered services are quantitatively understood and controlled. 5. Optimizing level: Continuous process improvement is enabled by quantitative feedback from the processes and from piloting innovative ideas and technologies.
2.5
Design decisions
During the development of the IT Service CMM a number of design decisions have been made. In this section we discuss the two major decisions made and the motivation for these decisions. First, the focus on service capability is discussed in section 2.5.1. Second, the choice for an improvement and assessment based capability maturity model is discussed in section 2.5.2.
2.5 Design decisions
2.5.1
11
Scope: a Service Capability Model
A major difference between software and hardware development on the one hand, and software maintenance, system operation, network management, etc., on the other hand, is the fact that the first result in a product, whereas the latter result in a service being delivered to the customer. Usually, a service is defined as an essentially intangible set of benefits or activities that are sold by one party to another. The main differences between products and services are: a) Services are transitory by nature, products are not. Hence, services can not be easily held in stock. b) Product delivery results in a transfer of ownership, service delivery does not. c) The use of products can be separated from the production of products. Services are produced and consumed simultaneously. d) Services are largely intangible, whereas products are largely tangible.1 The difference between products and services is not clear-cut. Often, services are augmented with physical products to make them more tangible, for example, luggage tags provided with a travel insurance. In the same way, products are augmented with add-on services, for example a guarantee, to improve the quality perception of the buyer. Moreover, customers might even consider the quality of service more important than the characteristics of the product itself, e.g. [16]. Often, products and services are intertwined. An example is a newspaper subscription, in which case both the product – the newspaper itself – and the service – the daily delivery – are essential to the customer. This means that the quality of such a product-service mix will be judged on both product and service aspects: is the newspaper delivered on time, and does it contain the desired information. Like the newspaper, IT management and maintenance can very well be a mixture of product and service. For example, in a situation where a software maintainer analyzes change requests for a fixed price per period and implements change requests for a price per change request, software maintenance is a product-service mixture. Here, the service is the customer having the possibility to have change requests analyzed, and the product is the implemented change. Looking at IT management and maintenance activities from a service perspective, a number of issues that pertain to the quality of these activities emerge: • If the activities are performed in an ongoing relationship with the customer, which they will almost always be, the IT service provider needs to facilitate communication between end users and its organization. Moreover, this communication needs to be managed and controlled. • The customer and the IT service provider have to agree on the quality levels with which the service will be delivered. Examples are: the maximum number of change requests that will be implemented per period, the availability of IT systems and networks, etc. • The IT service provider and customer need to evaluate the service on a regular basis: is the service still what the customer needs? 1
Software obviously is not tangible, but it is still a product because of its other characteristics (a, b, and c).
12
The IT Service Capability Maturity Model • Possibly, the IT service provider has to cooperate with third parties to perform its job. For example, new software may be developed by a software house, and is subsequently maintained by the service provider. Or the software may be operated by a separate computer center and maintained by the service provider.
Although each of the above points plays a role in software and hardware development too, the conjecture is that these activities are more important as service aspects are more prevalent. Regardless of the exact circumstances in which an IT service provider operates, sufficient emphasis should be on processes like the ones mentioned above, to be able to deliver quality IT services. See [9, 11] for a more elaborate discussion of these issues.
2.5.2
Form: a Capability Maturity Model
There are two reasons why it was decided to use the capability maturity framework developed at the SEI as a basis for our service improvement model. First, the Software CMM is a widely used and well-known software process improvement model. We felt that its structure is generic enough to facilitate other areas besides software processes. This has already been shown by the development of other capability maturity models, such as the People CMM [5, 6] and the Systems Engineering CMM [1]. Second, we wanted to provide organizations with a mechanism with which they can perform step-wise improvement. Improvement should be an integral part of the framework. This is the case with the CMM where the framework functions as a prescriptive model and assessments are used to compare the actual situation with the model. The granularity of the improvement steps of the CMM is rather coarse – an organization resides on one of five different levels. Other software process improvement models, such as SPICE/ISO 15504 [7], Bootstrap [8], or Trillium [21], use a more detailed architecture, called a continuous model as opposed to the staged model of the CMM. Bootstrap, for example, distinguishes between the maturity of the organization and the maturity of projects. The SPICE model, Trillium and Bootstrap rate the maturity of organizations with respect to different processes: this makes it possible that an organization rates level three for one process and level four for another process, for example. The IPW Stadia Model of Quint Wellington Redwood provides a framework for rating the maturity of IT organizations as a starting point for ITIL-based change [3, 13]. CMM-I (CMM Integration) [17, 18] goes even further and provides both a staged and a continuous representation of the maturity models. Also, CMM-I includes different disciplines like software engineering, systems engineering, and integrated product and process development. However, we decided to use the simpler approach of the CMM for practical reasons: we wanted to construct a fairly complete framework with limited resources, within limited time.
Chapter 3
Interpreting the IT Service CMM In this chapter, we discuss the concepts used in the specification of the IT Service CMM and how to interpret them. Definitions of concepts that originate from the Software CMM, such as most of the CMM-specific terminology, are taken from [14].
3.1
Interpreting the Key Practices
The key practices are not intended to require a specific implementation or organizational structure. They are intended to cover the activities that an organization needs to implement to reach a certain level of maturity. How the organization implements them is not important, as long as they are performed. Therefore the IT Service CMM only specifies what practices are needed, not how they need to be implemented. The key practices are grouped into key process areas. Each key process area has a purpose and several goals. The purpose of the key process area is the effect that is intented to be reached by means of the key practices. The goals are a summary of the key practices of a key process area that can be used to determine whether an organization has effectively implemented the key process area [14].
3.2
Interpreting the Common Features
Each key process area is defined in terms of its goals and its common features. Common features are the activities that an organization needs to perform to properly implement a key process area. The common features are divided into five categories [14]: Commitment to Perform The key practices in the Commitment to Perform common feature describe the actions the organization must take to ensure that the process is established and will endure. They typically involve establishing organizational policies and leadership. Ability to Perform The key practices in the Ability to Perform common feature describe the preconditions in the services or organization necessary to implement the service process competently. They typically involve resources, organizational structures, and training. 13
14
Interpreting the IT Service CMM
Activities Performed The key practices in the Activities Performed common feature describe the activities, roles, and procedures necessary to implement a key process area. They typically involve establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary. Measurement and Analysis The key practices in the Measurement and Analysis common feature describe basic measurement practices that are necessary to determine status related to the process. Measurements included in this common feature are used to control and improve the process. Verifying Implementation The key practices in the Verifying Implementation common feature describe the steps to ensure that the activities are performed in compliance with the process that has been established. They generally include key practices that relate to oversight by senior management and service management, as well as specific verification activities that the service quality assurance group or others are expected to perform to verify that the process is being performed properly.
3.3
Service Concepts
The IT Service CMM describes the processes needed for mature provision of IT services. To describe IT service maturity, we need a set of terms that cover the IT service domain, such as service and service delivery. In this section, we describe the important concepts and their interrelationships. Service A service is an essentially intangible set of benefits provided by one party to another party. As such, the word service can mean both a type of service (e.g. application management) and an instance of a type of service (e.g. management of application X for customer Y). We use the phrase service type to denote a type of service and we use service delivery to denote the delivery of a certain type of service to a certain customer. Service activity An activity that contributes to the creation of a (sub)set of benefits. Services are created by performing certain activities. We call these activities service activities. The definition uses the word ‘contributes’ instead of ‘creates’ because services are usually created by a large number of activities that create the benefits together. Each activity contributes directly or indirectly to the set of benefits. Activities that directly create a benefit are called service delivery activities. Activities that indirectly contribute to the delivery of services are called service support activities. Service delivery activity A service activity that directly creates benefits for the customer. For example, ‘creating a new user login’, ‘resetting a password’, and ‘running batch jobs’. Service support activity A service activity that indirectly contributes to the creation of benefits for the customer. For example, ‘recording an incident’, ‘planning the service’, and ‘establishing a configuration baseline’.
3.3 Service Concepts
15
The IT Service CMM key process areas mostly contain service support activities as opposed to service delivery activities. The service delivery activities will differ between different services, so the specification of these activities is left to the service organization itself; decisions in what services to deliver lie outside the scope of the IT Service CMM. Information Technology service (IT service) A service the benefits of which enable the customer to efficiently and effectively employ information technology to support and/or execute its business processes.
Examples of IT services are network infrastructure management, user support, operations of
hardware and/or software, maintenance of software, contingency services, internet access, etc.
IT services can thus be aimed at serving individual end users (i.e., installing a new version
L3-0.2/58 of a text processing program on the workstation of a end user as part of the service desktop
support) or aimed at serving organizations of organizational groups (i.e., making the payroll
application available to the finance department). Examples of the benefits provided by such IT services are the punctual payment of salaries, end users that are able to efficiently use their software, software that is up-to-date with respect to changes in legislation, etc. The exact benefits obviously depend on the business of the customer. In the context of the IT Service CMM we usually omit the prefix ‘IT’ if we talk about IT services. IT component IT services enable the customer to efficiently and effectively employ information technology. Information technology consists of IT components. IT components include: • hardware components, such as computers, network cables, routers, and printers, • software components, such as operating systems, middleware, database systems, and application software, • documentation, such as end user documentation and maintenance documentation, and • information used and manipulated by hardware and software components, such as data files, databases, passwords, and licenses. Service delivery Service delivery denotes the execution of service activities, according to the planning of the service and according to the standard service processes of the service organization, to create services for a specific customer with specific service levels. Service delivery is the counterpart of ‘software project’ in the Software CMM [14]. Actual service delivery The actual service delivery denotes the service delivery as it has actually happened. We use this term to distinguish between the planned service delivery and the service as it was actually delivered, for example when comparing the actual service delivery with the service commitments in the Service Commitment Management key process area. Service process A description of service activities to perform in order to deliver a certain service. This description includes the order in which activities are to be performed, interrelationships and interdependencies of activities, and responsibilities and authorities.
16
Interpreting the IT Service CMM
Standard service process A standard service process is a description of service activities to perform in order to deliver a certain service type. Organizations that deliver more than one service type may have a set of standard service processes. In this document we often use the singular phrase standard service process, but it can be interpreted as meaning ‘one or more standard service processes’. Defined service process A defined service process is a tailored description of one or more standard service processes to be performed in order to deliver (a) certain service (s) to a certain customer. Organization’s service process assets Service process assets include: • the organization’s standard service process, • the guidelines and criteria for tailoring the organization’s standard service process, • the organization’s service process database, and • the library of service process-related documentation. The service process assets are available for use in developing, maintaining and implementing defined service processes.
3.4
Organizational Structure and Roles
As mentioned in section 3.1, the IT Service CMM attempts to describe what activities are needed for high maturity IT service delivery, and not how these activities should be implemented. However, in order to describe the activities, some roles are needed. These are described below.
3.4.1
Organizational Roles
A role is a unit of defined responsibilities that may be assumed by one or more individuals [14]. The following roles are used in the description of the key practices. Manager A manager provides technical and administrative direction and control to individuals performing tasks or activities within the manager’s area of responsibility. Senior manager A senior manager fulfills a management role at a high enough level such that the primary focus is on the long-term vitality of the organization, rather than on short-term issues. Service manager A service manager is responsible for the specification of a service type. The service manager determines the benefits the service should deliver to customers, the scope of the service, deliverables, pricing, etc. Furthermore, the service manager is responsible for adapting the service type specification to practical experience with delivering services of that type. Service delivery manager A service delivery manager is responsible for the day-to-day delivery of a service (or a set of services) to a specific customer.
3.4 Organizational Structure and Roles
17
Service task leader A service task leader fulfills the role of leader of a technical team and has technical responsibilities. Service engineers Service engineers are the technical people, including service task leaders, who perform the service delivery activities needed to deliver the service. Note that these roles are all roles in the organization of the IT service provider. The IT Service CMM is a model that describes the maturity of the service provider organization and not of the customer organization. Hence, it does not specify any roles for the customer organization.
3.4.2
Organizational Structure
The following organizational concepts are used: Organization An organization is a unit, possibly within a company or other entity, by which services are delivered as a whole. Group A group is a collection of departments, managers, and individuals who have responsibility for a set of tasks or activities. A group can vary from a single individual assigned part time, to several part-time individuals assigned from different departments, to several individuals dedicated full-time. Examples of groups are the service delivery group, the service quality assurance group, and the configuration management group. Considerations when implementing a group include organizational structure and the organizational culture. Some groups, such as the service quality assurance group, are focused on service delivery activities, and others, such as the service process improvement group, are focused on organization-wide activities. Service group A service group is responsible for certain service activities. Examples of service groups are the configuration management group, the service request and incident management group, documentation support, and ‘service delivery groups’. Service delivery group A group responsible for certain service delivery activities. Service delivery groups perform the activities that create the service for the customer. They install new software, resolve incidents, answer questions from customer’s employees, etc. Hence, service delivery groups are a special kind of service group.
3.5
Service Request and Incident Management and Problem Manage-
Updated
title ment
This section provides definitions of terms used in the Service Request and Incident Management and Problem Management key process areas. Some of these are taken from [3].
18
Interpreting the IT Service CMM
The Service Request and Incident Management key process area deals with service requests and incidents: Incident Any event that is not part of the standard operation of a service and that causes, or may cause, an interruption to, or a reduction in, the quality of that service. Service request A request by a customer for certain service delivery activities – that fall within the bounds of the service commitments – to be performed. Service requests and incidents may be caused by an underlying cause. These causes are problems, and dealth with by the Problem Management key process area. Problem Unknown underlying cause of one or more service requests or incidents. Known error An incident or problem for which the root cause is known and for which a temporary work-around or a permanent alternative has been identified.
Chapter 4
The Maturity Levels of the IT Service CMM As stated in section 2.3, for an organization to reside on a certain maturity level, it needs to implement all key processes of that maturity level – and those for lower levels. The term key process area stresses that these processes are seen as the key to reach a certain maturity level. There might be more – nonkey – processes, but these are not strictly necessary to reach the next maturity level. Table 4.1 gives an overview of the maturity levels and the key process areas. The key process areas are grouped into three process categories: management, enabling and delivery. The first group is concerned with the management of services. The second category deals with enabling the delivery process by means of support processes and standardization of processes. The third category consists of the processes that result in the consistent, efficient delivery of services according to the appropriate quality levels. Below we present the key process areas for each of the maturity levels of the IT Service CMM.
4.1
Level 1: Initial
There are no key process areas prescribed for level one.
4.2
Level 2: Repeatable
The key process areas for maturity level two are concerned with establishing the processes that enable the organization to repeat earlier successful services in similar situations. We distinguish between two kinds of processes that an organization has to implement on this level. The first category deals with service management: the planning, specification, tracking and evaluation of services. The second category is concerned with service support: processes that support the activities that actually deliver the services. The management processes on this level look as follows. First, the IT service provider and the customer draw up an agreement about the services to be delivered, the quality of the services – specified in terms of service levels– and the costs of the services (Service Commitment Management). 19
20
The Maturity Levels of the IT Service CMM Process categories Levels
Management
Enabling
Delivery
Service planning, management, etc.
Support and standardization.
Actual service delivery.
Technology Change Management
Optimizing
Process Change Management Managed
Quantitative Process Management Financial Service Management
Defined
Integrated Service Management
Organization Service Definition
Problem Prevention Service Quality Management Service Delivery
Organization Process Definition Organization Process Focus Training Program Intergroup Coordination Resource Management Problem Management Repeatable
Service Commitment Management
Configuration Management
Service Delivery Planning
Service Request and Incident Management
Service Tracking and Oversight
Service Quality Assurance
Subcontract Management Initial
Ad hoc processes Table 4.1: Key process areas, assigned to process categories
To ensure that the service levels are realistic, the IT service provider draws up a service delivery plan that shows the feasibility of the service levels (, the commitment process, Service Delivery Planning). During service delivery, the IT service provider tracks the realized service levels and reports these to the customer on a regular basis to demonstrate that the provider has indeed delivered the services against the promised service levels (Service Tracking and Oversight). After a
4.2 Level 2: Repeatable
21
period of service provision, the customer and the IT service provider review the service level agreement to see whether it still conforms to the IT service needs of the customer (Service Commitment Management). Just like the organization draws up a service level agreement with its customer, the organization should also use service level agreements when it delegates parts of the service delivery to third parties (Subcontract Management). We identify three support processes that a level two organization needs to implement. First, almost all IT services concern the management, operation or maintenance of IT components. Therefore, where necessary for consistent service delivery, these components are put under configuration control. This ensures that at all times the status and history of these components is known, and that changes are controlled (Configuration Management). Second, during the period that the services are delivered, service requests and incidents can occur that need to be resolved by the IT service provider. These service requests and incidents can range from simple requests for a new laptop to serious incidents that prevent the customer from using its information technology. All these service requests and incidents need to be identified, tracked, resolved and reported to the customer (Service Request and Incident Management). To handle the service requests and to resolve incidents, changes to the configuration may be necessary. The change requests are evaluated by the configuration control board1 with respect to the service level agreement and risk for the integrity of the configuration. Only after a change request has been approved by the configuration control board, will the configuration be changed (Configuration Management). Added Finally, to ensure the quality of the services and service processes, the IT service provider deploys
’service
quality assurance techniques, such as reviews and audits (Service Quality Assurance). processes’
Next follows a description of the level two key process areas: 1. Service Commitment Management: Purpose: Services are specified and realistic service levels are negotiated with the customer in order to deliver services that satisfy the customer’s need for IT services. The delivered services, the specified service levels and the customer’s IT service needs are reviewed with the customer on a regular basis. When necessary, the service level agreement is adjusted. There are two basic issues targeted by this key process area: first, the service to be delivered is specified in a contract – the service level agreement– containing measurable service levels. Second, the service levels specified should address the business needs of the customer. 2. Service Delivery Planning: Purpose: The service delivery is planned in order to ensure that the specified services can indeed be delivered according to the agreed upon service levels. The service delivery planning forms the basis for delivering the services. In practice, the service commitments and service delivery planning will be developed in parallel because of the interdependencies between them. This ensures the presence of the commitment process (a service provider should make external promises with the customer before checking the availability of resources internally). 1
Note that this is a role, and not an actual organizational unit.
22
The Maturity Levels of the IT Service CMM 3. Service Tracking and Oversight: Purpose: Service delivery is being tracked. The realized service levels are compared with the specified service levels and are reported to the customer and management on a regular basis. Corrective actions are taken when actual service delivery deviates from the specified service levels. The IT service provider reports to the customer the actual services delivered, the actual service levels, and, when relevant, calamities that hindered accurate service delivery. The service level reports are used as input for the evaluation of service level agreements (see Service Commitment Management). 4. Subcontract Management: Purpose: Select qualified service subcontractors and manage them effectively. The IT service provider can select and hire service subcontractors to delegate parts of the service. If this is the case, the service to be delivered by the service subcontractors is laid down in a service level agreement. The IT service provider keeps track of the actual services delivered by the service subcontractor and takes corrective actions when the actual service levels deviate from the specified service levels. 5. Configuration Management: Purpose: The integrity of IT components which are subject to or part of the IT services is established and maintained. Configuration Management involves the identification of the relevant IT components which need to be put under configuration control. This includes components owned by the customer that are being managed by the IT service provider, components owned by the provider that are used by the customer and components owned by the provider that are used to deliver the service. Changes to the configuration are evaluated with respect to the service level agreement and with respect to possible risks for the integrity of the configuration. 6. Service Request and Incident Management: Purpose: Service requests and incidents regarding the service are identified, registered, tracked, analyzed, and resolved. The status of service requests and incidents is communicated with the customer and reported to management. This key process area concerns the management of service requests and incidents that cause or might cause service delivery to deviate from the agreed upon service levels. Service request and incident management deals with: • Requests for service from end users. For example, requests for a new feature in the software. • Incidents that cause or will cause service levels to be lower than agreed upon if no action is being taken. For example, a server that is down might cause the specified maximum down-time to be exceeded if it is not restarted quick enough. To resolve service requests and incidents, changes to the configuration might be necessary. The decision whether to implement the change request that results from a service request or
4.3 Level 3: Defined
23
incident is the concern of Configuration Management. 7. Service Quality Assurance: Purpose: Management is provided with the appropriate visibility into the processes being used and the services being delivered. Service Quality Assurance involves the reviewing and auditing of working procedures, ser-
vice delivery activities and work products to see that they comply with applicable standards
and procedures. Management and relevant groups are provided with the results of the reviews
Elucidated and audits. Note that Service Tracking and Oversight is concerned with measuring service
relation
between quality in retrospect, from an external point of view. It enables monitoring of service levels to
be reported to the customer as a result of the service delivery. Service Quality Assurance KPAs is concerned with measuring quality in advance, from an internal point of view, by measuring
the service processes and work products.
4.3
Level 3: Defined
At level three, an organization standardizes its processes and uses tailored versions of these standard processes to deliver the IT services. This results in more predictable performance of the processes and hence it increases the ability of the organization to draw up realistic service level agreements. The level three key process areas each fall into one of the three process categories: management, enabling or delivery. The first category – service management – is concerned with the tailoring of the standard service processes to the customer and the service level agreement at hand. Also, the actual service processes need to be integrated with each other and with third party service processes (Integrated Service Management). The second category – enabling – deals with making standard processes available and usable. The organization develops a set of standard services and describes these services in the service catalog (Organization Service Definition). The organization develops and maintains standard processes for each of these standard services. Usually, organizations will provide several services to one customer at the same time. Hence, not only the service processes themselves, but also the integration of these processes has to be standardized as much as is feasible (Organization Process Definition). To coordinate process efforts across services and organizational units and over time, organizational support is institutionalized (Organization Process Focus). Also, to teach people how to perform their roles and how to work with the standards, a training program needs to be put in place (Training Program). Furthermore, means are established for the different groups involved in the service delivery to communicate efficiently and effectively (Intergroup Coordination). Underlying problems of service requests and incidents occurring during different service delivery are analyzed (Problem Management) and resources are negotiated before making service commitments, and monitored during the service delivery (Resource Management). The third category – service delivery– concerns the actual delivery of the services to the customer using the tailored service processes (Service Delivery). The level three key process areas are described as follows: 1. Organization Service Definition:
24
The Maturity Levels of the IT Service CMM Purpose: Develop and maintain a set of standard services for the organization and collect information related to the delivery of these standard services.
Removed
The description of the standard services is called a service catalog. This service catalog con-
pricing info tains a specification of the services in terms of benefits for the customer. The service catalog
in the
service also includes the service levels that the provider can guarantee. catalog
The decision what services to include in the catalog is based on issues external to the IT Service CMM, such as marketing research or contractual obligations (in case of in-house IT service providers). The service catalog is continuously updated with experiences from the actual delivery of services. 2. Organization Process Definition: Purpose: Develop and maintain a usable set of service process assets that improve process performance across services, and provide a basis for cumulative, long-term benefits to the organization. This key process area covers the actual development and maintenance of the standard service processes used to deliver the services defined in the service catalog. 3. Organization Process Focus: Purpose: Establish organizational responsibility for service process development and improvement activities that improve the organization’s overall service process capability. This key process area covers the activities needed to assess, develop, maintain and improve the organization’s service processes. The activities are resourced and coordinated across current and future services. A service process improvement group is established to coordinate the service process activities. 4. Integrated Service Management: Purpose: Integrate the service and management activities into a coherent, defined service process that is derived from the organization’s standard service process. The service planning is based on this tailored service process and describes how its activities will be implemented and managed. The service planning takes the organization-wide capacity and availability of resources into account. Cooperation with third parties that also deliver IT services or products to the customer, is planned. Note that these third parties can be external providers or organizational units of the customer itself. An example of this could be the customer having its own helpdesk which relays reports of hardware failures to the IT service provider. Procedures need to be put in place on how these reports will be delivered to the IT service provider and whether the helpdesk or the IT service provider will inform the user of the status of the report. An example which involves coordination with third parties that deliver products to the customer, is software development. Suppose a third party is developing software for the customer that is to be managed and maintained by the IT service provider. Involvement of the service provider in the development process can ensure that maintenance and management of the software is sufficiently being taken into account during development.
4.3 Level 3: Defined
25
5. Service Delivery: Purpose: Consistently perform a well-defined service delivery process that integrates all service delivery activities to deliver correct, consistent IT services effectively and efficiently. Service Delivery involves the performing of service delivery activities using a tailored version of the standard service processes (which is the output of the Integrated Service Management key process area). Because the service activities depend on the particular services being provided, there is no fixed list of activities to be performed. However, all services should perform the activities as defined in the level two key process areas. The list of activities will be filled in depending on the services at hand. For example, in the case of software maintenance the general service activities will be extended with the software engineering tasks mentioned in the key process area Software Product Engineering of the Software CMM [14, pp. 241– 261]. 6. Intergroup Coordination: Purpose: Establish means for communication between the different groups involved in delivering the service to the customer. This involves the service delivery groups’ participation with other service groups to address the
service commitments, service schedule and other issues. Representatives of the service groups
This text participate in establishing the service commitments and plans by working with the customer
was missing and end users, as appropriate. These commitments and plans become the basis for all service
activities.
7. Training Program: Purpose: Develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently. Because level three organizations use standard processes, standard roles are defined that op-
More erate in these processes. Next, it is possible to train employees to obtain the skillset needed
thoroughly to perform these roles. This is not possible at level two, since standard organization-wide
explained
processes are not yet in place.
8. Resource Management: Purpose: Control of the resources (hardware and software) needed to deliver the services is maintained. Before commitments are made to customers, resources are checked. If not enough resources are available, either the commitments are adapted or extra resources are installed.
Human resources other than discussed in the Training Program key process area are outside
L23-0.1/17
the scope of the IT Service CMM. 9. Problem Management: Purpose: Remove problems from the IT that is managed, maintained or operated by the IT service provider. This key process area implements the organization-wide investigation of service requests and incidents and weak spots that occur during service delivery. Practices like root-cause analy-
26
The Maturity Levels of the IT Service CMM sis are used to determine underlying problems. Problems are solved by changing either the infrastructure, the processes or the training.
4.4
Level 4: Managed
At level four, organizations gain a quantitative understanding of their standard processes by taking detailed measures of service performance and service quality (Quantitative Process Management) and by using these quantitative data to control the quality of the delivered services (Service Quality Management). The quantitative data is also used to develop a cost model of the IT services and provide a charging system tailored to the customer and IT services delivered (Financial Service Management). There are three level four key process areas: 1. Quantitative Process Management: Purpose: Control the process performance and costs of the service delivery quantitatively.
This key process area involves establishing goals for the performance of the service’s defined
service process, taking measurements of the process performance, analyzing these measure-
ments, and making adjustments to maintain process performance within acceptable limits.
New key
When the process performance is stabilized within acceptable limits, the service’s defined process area
service process, the associated measurements, and the acceptable limits for the measurements
are established as a baseline and used to control process performance quantitatively. 2. Service Quality Management: Purpose: Develop a quantitative understanding of the quality of the services delivered and achieve specific quality goals. This key process area involves defining quality goals for the service levels, establishing plans
to achieve these goals, and monitoring and adjusting the service plans, service work products,
New key activities, and quality goals to satisfy the needs and desires of the customer and end user for
process area
high quality services.
3. Financial Service Management: Purpose: Develop a quantitative understanding of the cost structure of the IT services and provide tailored charging systems to customers. This key process area aims to specify, justify and manage the costs of the IT services agreed
upon in the service commitments. The customer is charged for services delivered based on
budgeting and accounting of the costs of IT services. Charging furthers optimal use of the IT
services according to the customer’s IT service needs, and it allows the IT service provider to
New key
operate as a business. Budgeting enables the IT service provider to cover predicted spending process area
on service commitments, to compare predicted with actual spending and to reduce the risks of
overspending. Accounting enables the IT service provider to account for money charged or
spent on service commitments.
4.5 Level 5: Optimizing
4.5
27
Level 5: Optimizing
At level five, service providers learn to change their processes to increase service quality and service process performance (Process Change Management). Changes in the processes are triggered by improvement goals, new technologies or problems that need to be resolved. New technologies are evaluated and introduced into the organization when feasible (Technology Change Management). Problems that occur are prevented from recurring by changing the processes (Problem Prevention). The level five key process areas are: 1. Process Change Management: Purpose: Continually improve the service processes used in the organization with the intent of improving service quality and increasing productivity. This key process area involves defining process improvement goals and, with senior manage-
ment sponsorship, proactively and systematically identifying, evaluating, and implementing
New key improvements to the organization’s standard service process and the services’ defined service
process area
processes on a continuous basis.
2. Technology Change Management: Purpose: Identify new technologies and inject them into the organization in an orderly manner. This key process area involves identifying, selecting, and evaluating new technologies and
New key incorporating effective technologies into the organization. The objective is to improve service
process area
quality, increase productivity, and decrease the effort expenditure for service delivery.
3. Problem Prevention: Purpose: Identify the cause of problems and prevent them from recurring by making the necessary changes to the processes. This key process area involves analyzing problems that were encountered in the past and taking
specific actions to prevent the occurence of those types of problems in the future. The problems
New key may have been identified in other services as well as in earlier stages or tasks of the current
process area service delivery. Problem prevention activities are also one mechanism for spreading lessons
learned between services.
28
The Maturity Levels of the IT Service CMM
Part II
The Key Process Areas of the IT Service CMM
29
Chapter 5
The Key Process Areas for Level 2: Repeatable 5.1
Service Commitment Management
Purpose The main purpose of Service Commitment Management is to ensure that the service commitments between service provider and customer, and hence the actual services delivered, are based on the IT service needs of the customer. The service commitments specify (amongst other things) the results of the services to be delivered. These results should contribute to fulfilling (parts of) the IT service needs of the customer. The activities in this key process area are targeted at ensuring that the service commitments are based on the IT service needs, and stay in line with possibly changing IT service needs. This is enforced by periodic and event-driven evaluations of the service commitments with respect to the IT service needs and by periodic and event-driven evaluations of the actual services delivered.
Goals Goal 1
Service commitments are documented and agreed to by the customer and the IT service provider. i The service commitments are the basis for delivering a service to the customer. Hence, both the customer and the IT service provider need to agree to the service commitments. Z Refer to Activity 3 for practices covering the contents of the service commitments.
Goal 2
Service commitments are based on current and future IT service needs of the customer. 31
32
The Key Process Areas for Level 2: Repeatable i The IT service provider identifies the IT service needs in cooperation with the customer. The identified IT service needs, in conjunction with the capabilities of the IT service provider, are the basis for establishing the service commitments.
Commitment to Perform Commitment 1
A service manager is designated to be responsible for negotiating service commitments. i The service commitments consist of external and internal commitments. External commitments can be both agreements with the customer on the services to be delivered, and agreements with third parties on out-sourced services. Internal commitments are agreements between internal groups and individuals on the resources and activities needed to accurately deliver the agreed services. The service commitments to the customer are set down in a service level agreement. Commitments by a third party are set down in a separate service level agreement between the organization and the third party, see also the key process area Subcontract Management. The internal commitments are described in the service delivery plan.
Commitment 2
The IT service is specified and evaluated according to a written organizational policy. This policy minimally specifies that: 1. The IT service needs of the customer are identified and documented. 2. The IT service needs of the customer are reviewed by: • the customer, and • the service manager. 3. The IT service needs of the customer are used as the basis for negotiating the service commitments with the customer. 4. The service commitments are documented. 5. The service commitments are reviewed by: • • • • •
the customer, the service manager, senior management, service delivery groups, and other affected groups and individuals. changed
group i Which other groups and individuals are affected is context dependent,
example to but may include groups such as the configuration management group, ser-
service vice request and incident management group, and the service quality as-
quality surance group.
assurance group
6. The service commitments are evaluated on a periodic basis.
5.1 Service Commitment Management
33
Ability to Perform Ability 1
Responsibilities for developing the service commitments are assigned. 1. The service manager, directly or by delegation, coordinates the development of the service commitments.
Ability 2
Adequate resources and funding are provided for developing the service commitments.
Ability 3
Service managers are trained to perform their service commitment management activities. ` Examples of training include: • negotiating methods and techniques, and • the application domain.
Activities Performed Activity 1
The IT service needs of the customer are identified according to a documented procedure. This procedure minimally specifies that: 1. The IT service needs are identified in cooperation with the customer. 2. The IT service needs are reviewed by the customer.
Activity 2
The IT service needs are documented. The IT service needs typically cover: 1. The business strategy of the customer. 2. The IT strategy of the customer, detailing how the business strategy is (to be) supported by IT. 3. The business processes supported by the IT. 4. The relevant IT components. 5. Expected changes to the business strategy, IT strategy, business processes, and IT components. 6. Current IT services used by the customer.
Activity 3
The service commitments are documented. The service commitments minimally cover:
34
The Key Process Areas for Level 2: Repeatable 1. The purpose, scope, and goals of the services to be delivered. i Here, the services to be delivered are related to the IT service needs of the customer. In case of differences between the actual IT service needs and the IT services specified in the service commitments, the extent of the differences and a rationale is included. For example, a difference may occur if the business processes of a customer would require 99.9% availability of certain IT components but the customer cannot pay for this service level due to its financial situation.
2. Specification of the services to be delivered. i The services to be delivered are specified in terms of benefits to the customer, rather than in terms of activities. See also the definition of service on page 14. This also makes sure the specification of the services to be delivered is understandable for both customer and IT service provider.
3. Specification of the quality levels of the services to be delivered. i Service quality levels specify the minimum or maximum value for all relevant attributes of the service. Service quality levels should be specified in a measurable way, because the service levels of the delivered services have to be reported to the customer, see the key process area Service Tracking and Oversight. The performance attributes measure the benefits provided by the IT services, not the activities performed to create those benefits. E.g., the number of backups made per month is not a good performance attribute. ` Examples of performance attributes of IT services include: • the guaranteed availability of a system, • the maximum responsetime of a system, and • maximum processing times of service requests.
4. Agreements on the charging policy. i A charging policy defines how the costs of the services delivered are charged to the customer. Elements of the charging policy include how fixed and variable as well as direct and indirect costs are apportioned to customers, IT services, and/or chargeable items. The goal of the charging policy is to recover costs for delivering the IT service to the customer. Additional goals may be to operate the IT service provider as a business unit with profit responsibility and/or to influence end user and customer behavior. Note that there is a close relation between the range of possible charging policies and the accounting system used by the IT service provider. The accounting system determines the level of detail with which cost information is gathered, which in turn determines what charging policies are feasible. So, the accounting system should be tuned to what kinds of charging policies the IT service provider wants to employ.
5. The service delivery schedule.
Added due
to addition
of
Financial
Service
Manage
ment
5.1 Service Commitment Management
35
i The service delivery schedule specifies when certain service activities will take place that have an effect on the service levels. Note that the service delivery schedule both contains service activities that take place at a fixed moment in time, for example new releases, or activities that are executed when certain other conditions are met, for example installing additional hardware to meet increasing performance demands. ` Examples of activities that determine the service delivery schedule include: • the delivery and installation of new software releases, • planned outage of systems for maintenance purposes, and • upgrading hardware due to increasing performance demands.
6. Specification of the service conditions. i Service conditions are resolutive conditions that the customer has to fulfill (i.e. the service provider is exempted from delivering the service according to the service quality levels, if the customer does not fulfill the service conditions).
7. Specification of calamities. i Calamities are situations in which the service provider is exempted from delivering the service according to the service quality levels. Note that these calamities are subject to negotiation. ` Examples of calamities include: • natural disasters such as earthquakes, storms, and tidal waves, • civil unrest, strikes, riots, war, and • power failures, telecommunication failures.
8. Agreements on reviewing actual service delivery. i Part of the service commitments are agreements on how and when the service provider will report on the delivered services to the customer. The service delivery reports minimally cover the actual service levels as compared to the service levels specified in the service commitments. Z Refer to the Service Tracking and Oversight key process area for practices covering the tracking of actual service delivery. Z Refer to Activity 15 of the Service Tracking and Oversight key process area for practices covering the review of actual service delivery.
9. Planning of service evaluation. i Part of the service commitments are agreements on how and when the service commitments will be evaluated. Z Refer to Activity 6.
Activity 4
The feasibility of the service commitments is demonstrated by a service delivery plan.
36
The Key Process Areas for Level 2: Repeatable i By developing a service delivery plan the organization investigates the feasibility of the service commitments. Whether the service delivery plan is discussed with, reviewed by, or agreed to by the customer depends on the relationship between the IT service provider and the customer. Z Refer to the Service Delivery Planning key process area for practices covering the development of a service delivery plan.
Activity 5
IT service provider and customer agree to the service commitments. 1. The service commitments are made available to affected groups and individuals. ` Examples of affected groups and individuals include: • the customer, • senior management, • service delivery groups, • service request and incident management group, • service quality assurance group, • service manager, and • service delivery manager.
2. The service commitments are managed and controlled. i ‘Managed and controlled’ implies that the work product adheres to organizational documentation standards, that the version of the work product in use at a given time (past or present) is known (i.e. version control), and that changes are incorporated in a controlled manner (i.e. change control). If a greater degree of control than is implied by ‘managed and controlled’ is desired, the work product can be placed under the full discipline of configuration management, as is described in the Configuration Management key process area.
Activity 6
Service commitments are evaluated with the customer on both a periodic and an event-driven basis. i The primary purpose of periodic and event-driven service evaluations of the service commitments with the customer is to ensure that the actual services delivered stay in line with current and future IT service needs of the customer.
1. The service evaluations of the service commitments are synchronized with the business planning of the customer, as appropriate. 2. The current IT service needs of the customer are identified and documented. Z Refer to Activity 1 and Activity 2.
3. The current IT service needs of the customer are compared with the previously identified IT service needs.
5.1 Service Commitment Management
37
4. The current IT service needs of the customer are compared with the previously established service commitments. 5. If necessary, the service commitments are adapted to the new IT service needs. Activity 7
Actual service delivery is evaluated with the customer on both a periodic and an event-driven basis. 1. Actual service delivery is compared with the service commitments. Z Refer to the Service Tracking and Oversight key process area for practices covering the tracking of actual service delivery. Z Refer to Activity 15 of the Service Tracking and Oversight key process area for practices covering the review of actual service delivery.
2. Service delivery risks are addressed. 3. Nonconformance to the service commitments is addressed. 4. Significant issues, action items, and decisions are identified and documented. 5. Action items are assigned, reviewed, and tracked to closure.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the service commitment management activities. ` Examples of measurements include: • work completed, effort expended, and funds expended in the service commitment management activities compared to the plan.
Verifying Implementation Verification 1
The service commitment management activities are reviewed with senior management on a periodic basis. i The primary purpose of periodic reviews by senior management is to provide awareness of, and insight into, service process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
1. The technical, cost, staffing, and schedule performance is reviewed. 2. Conflicts and issues not resolvable at lower levels are addressed. 3. Service delivery risks are addressed. 4. Action items are assigned, reviewed, and tracked to closure.
38
The Key Process Areas for Level 2: Repeatable 5. A summary report from each meeting is prepared and distributed to the affected groups and individuals.
Verification 2
The service commitment management activities are reviewed with the service manager on both a periodic and an event-driven basis. 1. Affected groups are represented. 2. Status and current results of the service delivery planning activities are reviewed. 3. Dependencies between groups are addressed. 4. Conflicts and issues not resolvable at lower levels are addressed. 5. Service delivery risks are reviewed. 6. Action items are assigned, reviewed, and tracked to closure. 7. A summary report from each meeting is prepared and distributed to the affected groups and individuals.
Verification 3
The service quality assurance group reviews and/or audits the service commitment management activities and work products and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. The activities for reviewing and developing service commitments.
5.2
Service Delivery Planning
Purpose The key process area Service Delivery Planning has as its main purpose to plan the delivery of services specified in the service commitments. The service delivery planning includes the planning of service delivery activities and other service-related activities; estimation of resources needed, expected workload, effort and costs; the service delivery schedule; identification of risks, and plans for service facilities and support tools. In addition, planning data needs to be recorded so that it can be used for the planning of future services.
Goals Goal 1
Service estimates are derived and documented for use in planning and tracking the actual service delivery. i Service estimates are estimates of the service delivery workload, needed IT components, effort, and costs. Tracking the service estimates enables the IT service provider to take corrective actions when the actuals deviate from the estimates.
5.2 Service Delivery Planning Goal 2
39
Service delivery activities and internal commitments are planned and documented. i The service is planned in terms of service delivery activities that need to be performed. In addition, the internal agreements between groups and individuals on the activities are documented, typically as part of the service delivery plan, to make the planning trackable.
Goal 3
Affected groups and individuals agree to their commitments related to the service delivery. i To ensure a realistic planning and commitment to that planning affected groups and individuals explicitly agree to their commitments (the internal commitments) before external commitments are made. This is called the commitment process.
Commitment to Perform Commitment 1
A service delivery manager is designated to be responsible for negotiating internal commitments and developing the service delivery plan.
Commitment 2
The service delivery is planned according to a written organizational policy. This policy minimally specifies that: 1. The service commitments are used as a basis for planning the service delivery. Z Refer to Activity 3 of the Service Commitment Management key process area.
2. Internal commitments are negotiated between: • • • •
the service manager, the service delivery manager, the service task leaders, and other affected groups.
3. Affected groups review the service delivery planning’s: • effort and cost estimates, • schedules, • other commitments. ` Examples of affected groups include: • service delivery groups, • service estimating, • service testing, • service quality assurance group, • configuration management group, and • documentation support.
40
The Key Process Areas for Level 2: Repeatable 4. The service delivery plan is managed and controlled. i ‘Managed and controlled’ implies that the work product adheres to organizational documentation standards, that the version of the work product in use at a given time (past or present) is known (i.e. version control), and that changes are incorporated in a controlled manner (i.e. change control). If a greater degree of control than is implied by ‘managed and controlled’ is desired, the work product can be placed under the full discipline of configuration management, as is described in the Configuration Management key process area.
Ability to Perform Ability 1
Responsibilities for developing the service delivery plan are assigned. 1. The service delivery manager, directly or by delegation, coordinates the development of the service delivery plan. 2. Responsibilities for service activities are partitioned and assigned in a traceable, accountable manner.
Ability 2
Adequate resources and funding are provided for planning the service delivery. 1. Where feasible, experienced individuals, who have expertise in the application domain of the services being planned, are available to develop the service delivery plan. 2. Tools to support the service delivery planning activities are made available. ` Examples of support tools include: • spreadsheet programs, • estimating models, and • project planning and scheduling programs.
Ability 3
The service managers, service delivery managers, service engineers, and other individuals involved in the service delivery planning are trained in the estimating and planning procedures applicable to their areas of responsibility. ` Examples of training include: • the methods, standards, and procedures used, and • the application domain.
Activities Performed Activity 1
The service delivery plan is developed according to a documented procedure. This procedure minimally specifies that:
5.2 Service Delivery Planning
41
1. The service delivery plan is based on and conforms to: • the service delivery standards, as appropriate, and • the service commitments. 2. Plans for service related and support groups involved in the service delivery activities are negotiated with those groups, the support efforts are budgeted, and the agreements are documented. ` Examples of service related groups include: • service quality assurance group, • configuration management group, and • documentation support.
3. The service delivery plan is reviewed by: • • • •
the service manager, the service delivery manager, other service delivery managers, and other affected groups.
4. The service delivery plan is managed and controlled. Activity 2
The service delivery plan is documented. The service delivery plan covers: 1. The purpose, scope, and goals of the service delivery. 2. Identification of the selected procedures, methods, and standards for delivering the services. 3. Identification of service delivery activities to be performed and internal commitments on the service delivery activities. Z Refer to Activity 3.
4. Estimated use of IT components. Z Refer to Activity 4.
5. Estimated service delivery workload. Z Refer to Activity 5.
6. Estimates of the service delivery effort and costs. Z Refer to Activity 6.
7. The service delivery schedule. Z Refer to Activity 7.
8. Identification and assessment of the service delivery risks. Z Refer to Activity 8.
42
The Key Process Areas for Level 2: Repeatable 9. Identification and planning of service facilities and support tools. Z Refer to Activity 9.
Activity 3
Service delivery activities to be performed are identified and planned according to a documented procedure. This procedure typically specifies that: 1. Service delivery activities are identified based on the service to be delivered and the service quality levels. 2. Service delivery activities are decomposed into subactivities to the granularity needed to meet the estimating objectives. 3. Historical data are used where available. 4. The service delivery activities and internal commitments are documented, reviewed, and agreed to. ` Examples of groups and individuals who review and agree to the planning of service delivery activities and internal commitments include: • the service delivery manager, • the service request and incident management group, and • the service delivery group.
Activity 4
IT components that need to be controlled to deliver the service are identified. i These IT components are called selected IT components . ` Examples of IT components that are needed to deliver the service include: • desktop computers, telephones, and headsets in case of desktop management services, • application software, servers, and network components in case of application management services.
Z Refer to Activity 4 of the Configuration Management key process area for practices covering the identification of IT components to be placed under configuration management.
Activity 5
Estimates for the service delivery workload are derived according to a documented procedure. i The service delivery workload influences, directly or indirectly, the amount of effort needed to deliver the service.
5.2 Service Delivery Planning
43
` Examples of service delivery workload include: • the number of users of application software, • the number of transactions processed by a software system per day, • the number of individual or department moves from one location to another, and • the number of change requests that is submitted by the customer.
This procedure minimally specifies that: 1. Workload estimates are made for all service activities. ` Examples of service activities include: • activities for identifying, reviewing, tracking, and resolving service requests, • activities for maintaining IT components, and • activities for operating IT systems.
2. Historical data are used where available. 3. Workload assumptions are documented. 4. Workload estimates are documented, reviewed, and agreed to. ` Examples of groups and individuals who review and agree to service delivery workload estimates include: • the service manager, • the service delivery manager, • the customer, • the service estimating group, and • the service engineers.
Activity 6
Estimates for the service delivery effort and costs are derived according to a documented procedure. This procedure minimally specifies that: 1. Estimates for the service delivery effort and costs are related to the service delivery workload estimates. i The service delivery workload may result in for the service engineers.
2. Productivity data (historical and/or current) are used for the estimates when available; sources and rationales for these data are documented. 3. Historical data are used where available. 4. Effort, staffing, and cost assumptions are documented. 5. Effort and cost estimates are documented, reviewed, and agreed to.
44
The Key Process Areas for Level 2: Repeatable ` Examples of groups and individuals who review and agree to the service delivery effort and cost estimates include: • the service manager, • the service delivery manager, • the service estimating group, and • the service engineers.
Activity 7
The service delivery schedule is derived according to a documented procedure. i The service delivery schedule determines when service delivery activities are performed. The service delivery schedule is derived from the service commitments, service delivery activities, and service delivery workload estimates. ` Examples of items in the service delivery schedule include: • the release schedule of software applications, • the schedule of preventive maintenance activities, and • the batch processing schedule.
This procedure typically specifies that: 1. The service delivery schedule is related to: • the service commitments, • the service delivery workload estimates, and • the service delivery effort and cost estimates. 2. The service delivery schedule is based on past experience. • Information about the delivery of similar services to other customers is used when possible. 3. Assumptions made in deriving the service delivery schedule are documented. 4. The service delivery schedule is documented, reviewed, and agreed to. Activity 8
The risks associated with the cost, resource, schedule, and technical aspects of the service are identified, assessed, documented, and mitigated as appropriate. ` Examples of service delivery risks include: • data loss e.g. due to disk crashes, • unexpected down time of software applications due to software bugs, • loss of a building due to fire, and • unstable infrastructure due to lack of knowledge of the technology in use.
1. The risks are analyzed and prioritized based on their potential impact to the service quality levels.
5.2 Service Delivery Planning
45
2. Contingencies for the risks are identified and arranged for. ` Examples of contingencies include: • schedule buffers, • making backups of data files, • alternative staffing plans, • alternative plans for additional computing facilities, and • local and/or remote failover facilities.
Activity 9
Service facilities and support tools needed for the delivery of the service are identified and planned. ` Examples of service facilities and support tools include: • monitoring tools, • server rooms, • remote dial-in facilities for service engineers, and • test tools.
Activity 10
Service planning data are recorded and made available. i The primary purpose of recording and making available service planning data is to facilitate the planning of future services.
1. Information recorded includes the estimates and the associated information needed to reconstruct the estimates and assess their reasonableness. 2. Service planning data are managed and controlled.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the service delivery planning activities. ` Examples of measurements include: • completion of milestones for the service delivery planning activities compared to the plan, and • work completed, effort expended, and funds expended in the service delivery planning activities compared to the plan.
Verifying Implementation Verification 1
The service delivery planning activities are reviewed with senior management on a periodic basis.
46
The Key Process Areas for Level 2: Repeatable i The primary purpose of periodic reviews by senior management is to provide awareness of, and insight into, service process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
1. The technical, cost, staffing, and schedule performance is reviewed. 2. Conflicts and issues not resolvable at lower levels are addressed. 3. Service delivery risks are addressed. 4. Action items are assigned, reviewed, and tracked to closure. 5. A summary report from each meeting is prepared and distributed to the affected groups and individuals. Verification 2
The service delivery planning activities are reviewed with the service manager on both a periodic and an event-driven basis. 1. Affected groups are represented. 2. Status and current results of the service delivery planning activities are reviewed. 3. Dependencies between groups are addressed. 4. Conflicts and issues not resolvable at lower levels are addressed. 5. Service delivery risks are reviewed. 6. Action items are assigned, reviewed, and tracked to closure. 7. A summary report from each meeting is prepared and distributed to the affected groups and individuals.
Verification 3
The service quality assurance group reviews and/or audits the service delivery planning activities and work products and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. The activities for service estimating and planning. 2. The activities for preparing the service delivery plan. 3. The standards used for preparing the service delivery plan. 4. The content of the service delivery plan.
5.3 Service Tracking and Oversight
5.3
47
Service Tracking and Oversight
Purpose The main purpose of the Service Tracking and Oversight key process area is to provide information about the actual service delivery. This information is to be used to report actual service levels to the customer and to monitor the actual service delivery and take corrective actions as soon as possible. If necessary, the service delivery plan is adjusted.
Goals Goal 1
Actual service delivery is tracked against the specified service levels and reported to the customer. i The service levels as specified in the service commitments need to be reached in order to satisfy the commitments. Hence, actual service delivery is tracked to ensure that the agreed to service levels are reached. The actual service delivery is reported to the customer as a basis for periodic evaluation of the actual service delivery and the service commitments.
Goal 2
Corrective actions are taken and managed to closure to prevent actual service delivery to deviate from the specified service levels. i The IT service provider tracks the service delivery planning, including the service delivery activities, estimates of needed resources, service delivery workload estimates, service delivery effort and cost estimates and service delivery risks, to identify deviations from the planning and take corrective actions as soon as possible.
Goal 3
Changes to the service delivery planning are agreed to by the affected groups and individuals. Z Refer to Goal 3 of the Service Delivery Planning key process area for an explanation of the commitment process.
Commitment to Perform Commitment 1
A service delivery manager is designated to be responsible for the actual service delivery.
Commitment 2
The service delivery is managed according to a written organizational policy. This policy typically specifies that: 1. A documented service delivery plan is used and maintained as the basis for tracking the actual service delivery. 2. The service manager is kept informed of the service delivery status and issues.
48
The Key Process Areas for Level 2: Repeatable 3. Corrective actions are taken when the service delivery plan is not being achieved, either by adjusting the plans or by initiating a service evaluation. Z Refer to Activity 6 of the Service Commitment Management key process area.
4. Changes to the service delivery planning are made with the involvement and agreement of the affected groups. ` Examples of affected groups include: • service delivery group, • service request and incident management group, • service estimating, • service quality assurance group, and • configuration management group.
Ability to Perform Ability 1
A service delivery plan is documented and approved. Z Refer to Activities 1 and 2 of the Service Delivery Planning key process area for practices covering the service delivery plan.
Ability 2
The service delivery manager explicitly assigns responsibility for the service delivery activities. The assigned responsibilities cover: 1. The service delivery activities to be performed. 2. The effort and cost for these activities. 3. The schedule for these activities. 4. The budget for these activities. 5. The usage of IT components.
Ability 3
Adequate resources and funding are provided for tracking actual service delivery. 1. The service delivery managers and service task leaders are assigned specific responsibilities for tracking actual service delivery. 2. Tools to support service tracking are made available. ` Examples of support tools include: • spreadsheet programs, • network monitoring software, • service request and incident management (‘service desk’) software, and • project planning/scheduling programs.
5.3 Service Tracking and Oversight Ability 4
49
The service delivery managers are trained in managing the technical and personnel aspects of the service delivery. ` Examples of training include: • managing technical projects, • tracking and oversight of service results, costs, effort, and schedule, and • managing people.
Ability 5
Service managers receive orientation on the technical aspects of the service delivery. ` Examples of orientation include: • the service delivery standards and procedures, and • the service application domains.
Activities Performed Activity 1
A documented service delivery plan is used for tracking the service delivery activities and communicating status. Z Refer to Activity 2 of the Service Delivery Planning key process area for practices covering the content of the service delivery plan.
This service delivery plan is: 1. Updated as the service delivery progresses to reflect accomplishments. 2. Readily available to: • • • • • Activity 2
the service delivery group, the service managers, the service delivery managers, senior management, and other affected groups.
The service delivery plan is revised according to a documented procedure. Z Refer to Activity 1 of the Service Delivery Planning key process area for practices covering the activities for producing the service delivery plan.
This procedure typically specifies that: 1. The service delivery plan is revised, as appropriate, to incorporate plan refinements and incorporate plan changes, particularly when plans change significantly. 2. The service delivery plan is updated to incorporate all new service commitments and changes to commitments.
50
The Key Process Areas for Level 2: Repeatable 3. The service delivery plan is reviewed at each revision. 4. The service delivery plan is managed and controlled.
Activity 3
Approved changes to the service delivery plan are communicated to the members of the service delivery group and other related groups. ` Examples of other related groups include: • service quality assurance group, • configuration management group, and • documentation support.
Activity 4
Actual service levels are tracked against the specified service levels, and corrective actions are taken as necessary. 1. Actual service levels are tracked and compared to the service levels documented in the service commitments. 2. Effects of higher or lower actual service levels are evaluated for impacts on future activities or service levels. 3. Changes in actual service levels that affect service commitments are negotiated with affected groups and are documented.
Activity 5
Actual service levels are reported to the customer on a periodic basis. i These reports are often called service level reports.
At a minimum, these reports cover: 1. The actual service levels during the previous period. 2. A summary of the specified service levels in the service commitments. 3. A comparison of the actual service levels with the specified service levels. 4. An explicit statement whether the specified service levels were met or not. Activity 6
The service delivery activities are tracked, and corrective actions are taken as necessary. Z Refer to Activity 3 of the Service Delivery Planning key process area for practices covering the planning of service delivery activities.
1. Members of the service delivery group report the status of their service delivery activities to their service delivery manager on a periodic basis. 2. Deviations from the service delivery planning in any of the service delivery activities are identified, recorded, reviewed, and tracked to closure. Z Refer to Activity 4 of the Service Request and Incident Management key process area for practices covering the management of service requests and incidents.
5.3 Service Tracking and Oversight Activity 7
51
Selected IT components are tracked and corrective actions are taken as necessary. i Refer to Activity 4 of the Service Delivery Planning key process area for practices covering the identification of IT components that need to be controlled to deliver the service. ` Examples of tracking IT components include: • tracking the stock of spare parts, • tracking the availability of servers and applications, • tracking the performance of network components, and • tracking the number of users of a software system.
Activity 8
The service delivery workload is tracked, and corrective actions are taken as necessary. Z Refer to Activity 5 of the Service Delivery Planning key process area for practices covering the derivation of service delivery workload estimates.
1. Actual workload over time is compared to the estimates documented in the service delivery plan. 2. Effects of higher or lower workload are evaluated for impacts on future activities and service levels. 3. Changes in workload that affect service commitments are negotiated with the affected groups and are documented. Activity 9
The service delivery effort and costs are tracked, and corrective actions are taken as necessary. Z Refer to Activity 6 of the Service Delivery Planning key process area for practices covering the derivation of service delivery effort and cost estimates.
1. Actual expenditure of effort and costs over time and against service delivery activities performed are compared to the estimates documented in the service delivery plan to identify potential overruns and underruns. 2. Service costs are tracked and compared to the estimates documented in the service delivery plan. 3. Effort and staffing are tracked and compared to the estimates documented in the service delivery plan. 4. Changes in staffing and other service costs that affect service commitments are negotiated with the affected groups and are documented.
52 Activity 10
The Key Process Areas for Level 2: Repeatable The service delivery schedule is tracked, and corrective actions are taken as necessary. Z Refer to Activity 7 of the Service Delivery Planning key process area for practices covering the derivation of the service delivery schedule.
1. Actual completion of service activities, milestones, and other commitments is compared against the service delivery plan. 2. Effects of late and early completion of service delivery activities, milestones, and other commitments are evaluated for impact on future activities and service levels. 3. Service schedule revisions that affect service commitments are negotiated with the affected groups and are documented. Activity 11
The risks associated with cost, resource, schedule and technical aspects of the services are tracked. Z Refer to Activity 8 of the Service Delivery Planning key process area for practices covering the identification and assessment of service delivery risks.
1. The priorities of the risks and contingencies for the risks are adjusted as additional information becomes available. 2. High-risk areas are reviewed with the service delivery manager on a periodic basis. Activity 12
The service facilities and support tools are tracked, and corrective actions are taken as necessary. Z Refer to Activity 9 of the Service Delivery Planning key process area for practices covering the planning of service facilities and support tools.
1. The actual and projected use of service facilities and support tools are tracked and compared to the estimates as documented in the service delivery plan. 2. Changes in the estimated use of service facilities and support tools that affect the service commitments are negotiated with the affected groups and are documented. Activity 13
Actual measurement data and replanning data for the service are recorded and made available. Z Refer to Activity 10 of the Service Delivery Planning key process area for practices covering the recording of service planning data.
1. Information recorded includes the estimates and associated information needed to reconstruct the estimates and verify their reasonableness.
5.3 Service Tracking and Oversight
53
2. The service replanning data are managed and controlled. 3. The service planning data, replanning data, and the actual measurement data are archived for use by ongoing and future services. 4. The service planning data, replanning data, and the actual measurement data are made available to affected groups. Activity 14
The service delivery group conducts periodic internal reviews to track activity status, plans, actual service levels, and issues against the service delivery plan. These reviews are conducted between: 1. The service delivery managers and their service task leaders. 2. The service delivery managers and service managers, as appropriate.
Activity 15
Formal reviews to address the accomplishments and results of the service are conducted with the customer at selected moments according to a documented procedure. ` Examples of accomplishments and results of the service are: • upgrade of all end user workstations to a new operating system version, • movement of all IT infrastructure of a department to a new location, and, • installation of a new version of an information system.
These reviews: 1. Are planned to occur at meaningful points in the service delivery schedule. 2. Are conducted with the customer and end users, as appropriate. i The end users referred to in these practices are the customer designated end users or representatives of the end users.
3. Use materials that are reviewed and approved by the responsible service delivery managers. 4. Address the service commitments and actual service delivery. 5. Result in the identification and documentation of significant issues, action items, and decisions. 6. Address the service delivery risks. 7. Result in the refinement of the service delivery plan, as necessary. 8. Result in an evaluation of service commitments and actual service delivery, as necessary. Z Refer to Activity 6 of the Service Commitment Management key process area for practices concerning the evaluation of service commitments and actual service delivery.
54 Activity 16
The Key Process Areas for Level 2: Repeatable Formal reviews to address the accomplishments and results of the service are conducted internally at selected moments according to a documented procedure. ` Examples of accomplishments and results of the service are: • upgrade of all end user workstations to a new operating system version, • movement of all IT infrastructure of a department to a new location, and, • installation of a new version of an information system.
These reviews: 1. Are planned to occur at meaningful points in the service delivery schedule. 2. Are conducted with affected groups within the organization. 3. Address the service commitments and actual service delivery. 4. Result in the identification and documentation of significant issues, action items, and decisions. 5. Address the service delivery risks. 6. Result in the refinement of the service delivery plan, as necessary. 7. Result in an evaluation of service commitments and actual service delivery, as necessary. Z Refer to Activity 6 of the Service Commitment Management key process area for practices concerning the evaluation of service commitments and actual service delivery.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the service tracking and oversight activities. ` Examples of measurements include: • effort and other resources expended in performing the service tracking and oversight activities, and • change activity for the service delivery plan, which includes changes to workload estimates, effort and cost estimates, and schedule.
Verifying Implementation Verification 1
The service tracking and oversight activities are reviewed with senior management on a periodic basis. 1. The technical, cost, staffing, and schedule performance is reviewed. 2. Conflicts and issues not resolvable at lower levels are addressed.
5.3 Service Tracking and Oversight
55
3. Service delivery risks are addressed. 4. Action items are assigned, reviewed, and tracked to closure. 5. A summary report from each meeting is prepared and distributed to the affected groups and individuals. Verification 2
The service tracking and oversight activities are reviewed with the service manager on both a periodic and an event-driven basis. 1. Affected groups are represented. 2. The technical, cost, staffing, schedule, and service delivery performance is reviewed against the service delivery plan. 3. Use of IT components is reviewed; current estimates and actual use of these components is reported against the original estimates. 4. Dependencies between groups are addressed. 5. Conflicts and issues not resolvable at lower levels are addressed. 6. Service delivery risks are addressed. 7. Action items are assigned, reviewed, and tracked to closure. 8. A summary status report from each meeting is prepared and distributed to the affected groups. ` Examples of situations that can lead to a review of the service tracking and oversight activities are: • a considerable difference between the reported actual service delivery and the perception of the customer of the actual service delivery, and • a considerable difference between the reported actual service delivery and the perception of affected groups of the actual service delivery.
Verification 3
The service quality assurance group reviews and/or audits the service tracking and oversight activities and work products and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. The activities for reviewing and revising commitments. 2. The activities for revising the service delivery plan. 3. The content of the revised service delivery plan. 4. The activities for tracking the service delivery cost, schedule, risks, technical constraints, and service levels. 5. The activities for conducting the planned technical and management reviews.
56
5.4
The Key Process Areas for Level 2: Repeatable
Subcontract Management
Purpose The key process area Subcontract Management describes the activities that a service provider – the prime contractor – should implement when (part of) a service, to be delivered to a customer of the prime contractor, is subcontracted to a third party – the service subcontractor. The prime contractor and the service subcontractor negotiate service commitments between each other. The prime contractor remains responsible for the service to be delivered to the customer.
Goals Goal 1
The prime contractor selects qualified service subcontractors. i To ensure that the service subcontractor is sufficiently qualified to deliver the service to be subcontracted, the prime contractor selects the service subcontractor from a number of potential service subcontractors, based on an evaluation of the service subcontractor bidders’ ability to deliver the service to be subcontracted. i In situations of forced sourcing of certain services, the prime contractor cannot freely select a qualified service subcontractor. In these cases, the prime contractor will need to ensure that its service subcontractor is indeed qualified in a different way. Examples of verifying the qualifications of its service subcontractor include: • benchmarking the service subcontractor with peer organizations, • determining the maturity level of the service subcontractor, • a certified quality system employed by the service subcontractor, • historic information on the quality of similar services delivered by the service subcontractor, or • a combination of the above.
Goal 2
The prime contractor and the service subcontractor agree to their commitments to each other. i The subcontract service commitments document the mutual commitments between prime contractor and service subcontractor.
Goal 3
The prime contractor and the service subcontractor maintain ongoing communications. i To ensure that the subcontracted service stays in line with the service delivered by the prime contractor to its customer, the prime contractor and service subcontractor maintain ongoing communications.
Goal 4
The prime contractor tracks the service subcontractor’s actual results and performance against its commitments.
5.4 Subcontract Management
57
i Since the prime contractor is responsible for the service delivered by the service subcontractor, and because the subcontracted service is usually very visible to the customer of the prime contractor, the prime contractor tracks the service subcontractor’s actual service delivery.
Commitment to Perform Commitment 1
A written organizational policy is followed for managing the service subcontract. This policy typically specifies that: 1. Documented standards and procedures are used in selecting service subcontractors and managing the service subcontracts. 2. The contractual agreements between the prime contractor and the customer form the basis for managing the service subcontract. 3. Changes to the service subcontract are made with the involvement and agreement of both the prime contractor and the service subcontractor.
Commitment 2
A subcontract manager is designated to be responsible for establishing and managing the service subcontract. 1. The subcontract manager is knowledgeable and experienced in IT service delivery or has individuals assigned who have that knowledge and experience. 2. The subcontract manager is responsible for coordinating the technical scope of the service to be subcontracted and the terms and conditions of the service subcontract with the affected parties. i The service delivery group defines the technical scope of the activities to be subcontracted. The appropriate business function groups, such as purchasing, finance, and legal, establish and monitor the terms and conditions of the subcontract.
3. The subcontract manager is responsible for: • selecting the service subcontractor, and • managing the service subcontract.
Ability to Perform Ability 1
Adequate resources and funding are provided for selecting the service subcontractor and managing the service subcontract. 1. Service managers and other individuals are assigned specific responsibilities for managing the service subcontract.
58
The Key Process Areas for Level 2: Repeatable 2. Tools to support managing the service subcontract are made available. ` Examples of support tools include: • estimating tools, • spreadsheet programs, and • project management and scheduling programs.
Ability 2
Service managers and other individuals who are involved in establishing and managing the service subcontract are trained to perform these activities. ` Examples of training include: • preparing and planning for service subcontracting, • evaluating a subcontract bidder’s service process capability, • evaluating a subcontract bidder’s service delivery estimates and plans, • selecting a service subcontractor, and • managing a service subcontract.
Ability 3
Service managers and other individuals who are involved in managing the service subcontract receive orientation in the technical aspects of the service subcontract. ` Examples of orientation include: • application domain, • hardware and software technology involved, • software tools being used, • methodologies being used, and • standards and procedures being used.
Activities Performed Activity 1
The service to be subcontracted is specified and planned according to a documented procedure. This procedure typically specifies that: 1. Services to be subcontracted are selected based on a balanced assessment of both technical and nontechnical characteristics of the service to be delivered. • The services to be subcontracted are selected to match the skills and capabilities of potential service subcontractors. • The specification of the services to be subcontracted is determined based on a systematic analysis and appropriate decomposition of the service to be delivered and the service commitments.
5.4 Subcontract Management
59
2. The specification of the service to be subcontracted and the standards and procedures to be followed are derived from the: • service commitments, • service delivery plan, and • service standards and procedures. 3. The specification of the service to be subcontracted is: • prepared, • reviewed, • agreed to, ` Examples of individuals who review and agree to the specification of the service to be subcontracted include: – the service delivery manager, – the configuration management manager, – the service quality assurance manager, and – the subcontract manager.
• revised when necessary, and • managed and controlled. 4. A plan for selecting a service subcontractor is prepared concurrent with the service commitments and is reviewed, as appropriate. Activity 2
The service subcontractor is selected, based on an evaluation of the service subcontract bidders’ ability to deliver the service, according to a documented procedure. This procedure covers the evaluation of: 1. Proposals submitted for the planned service subcontract. 2. Prior performance records on similar services, if available. 3. The geographic locations of the service subcontract bidders’ organizations relative to the prime contractor and/or the customer. i Effective management of some subcontracts may require frequent face-toface interactions.
4. Service delivery capabilities. 5. Staff available to perform the service activities. 6. Prior experience with similar services. 7. Available resources. ` Examples of resources include: • facilities, • hardware, • software, and • training.
60 Activity 3
The Key Process Areas for Level 2: Repeatable The contractual agreement between the prime contractor and the service subcontractor is used as the basis for managing the service subcontract. The contractual agreement documents: 1. The subcontract service commitments. Z Refer to Activity 3 of the Service Commitment Management key process area for practices covering the typical content of service commitments.
2. The standards and procedures to be used to integrate the service to be subcontracted and the services delivered by the prime contractor. ` Examples of procedures include: • service request and incident procedures, • configuration management procedures, and • reporting procedures.
Activity 4
A documented service subcontractor’s service delivery plan is reviewed and approved by the prime contractor. 1. This service delivery plan covers (directly or by reference) the appropriate items from the prime contractor’s service delivery plan. i In some cases, the prime contractor’s service delivery plan may include the service delivery plan for the service subcontractor, and no separate service subcontractor’s service delivery plan is needed. Z Refer to Activity 2 of the Service Delivery Planning key process area for practices covering the content of the service delivery plan.
Activity 5
A documented and approved service subcontractor’s service delivery plan is used for tracking the service subcontractor’s service activities and communicating status. Z Refer to the Service Tracking and Oversight key process area for practices covering the tracking of actual service delivery.
Activity 6
Changes to the service subcontractor’s service commitments, service delivery plan, and other commitments are resolved according to a documented procedure. 1. This procedure typically specifies that all affected groups of both the prime contractor and the service subcontractor are involved.
Activity 7
Subcontract service commitments are evaluated with the service subcontractor on both a periodic and an event-driven basis.
5.4 Subcontract Management
61
i The primary purpose of periodic and event-driven service evaluations of the service commitments with the service subcontractor is to ensure that the subcontract service commitments stay in line with current and future IT service needs of the customer. Z Refer to Activity 6 of the Service Commitment Management key process area for practices covering evaluation of the service commitments.
Activity 8
Actual service delivery of the subcontracted services is evaluated with the service subcontractor on both a periodic and an event-driven basis. Z Refer to Activity 7 of the Service Commitment Management key process area for practices covering evaluation of the actual service delivery.
Activity 9
Formal reviews to address the accomplishments and results of the service are conducted with the service subcontractor at selected moments according to a documented procedure. ` Examples of accomplishments and results of the service are: • upgrade of all end user workstations to a new operating system version, • movement of all IT infrastructure of a department to a new location, and, • installation of a new version of an information system.
These reviews: 1. Are planned to occur at meaningful points in the service delivery schedule. 2. Are conducted with the service subcontractor. 3. Use materials that are reviewed and approved by the responsible service delivery managers. 4. Nonconformance to the service subcontract is addressed. 5. Result in the identification and documentation of significant issues, action items, and decisions. 6. Address the service delivery risks. 7. Address critical dependencies and commitments between the service subcontractor and the prime contractor. 8. Result in the refinement of the service delivery plan, as necessary. 9. Result in an evaluation of subcontract service commitments and actual service delivery, as necessary. Z Refer to Activity 7 and 8.
10. Action items are assigned, reviewed, and tracked to closure. Activity 10
The prime contractor’s service quality assurance group monitors the service subcontractor’s service quality assurance activities according to a documented procedure.
62
The Key Process Areas for Level 2: Repeatable This procedure typically specifies that: 1. The service subcontractor’s plans, resources, procedures, and standards for service quality assurance are periodically reviewed to ensure that they are adequate to monitor the service subcontractor’s performance. 2. Regular reviews and/or audits of the service subcontractor are conducted to ensure the approved procedures and standards are being followed. • The prime contractor’s service quality assurance group spot checks the subcontractor’s service delivery activities. • The prime contractor’s service quality assurance group audits the subcontractor’s service quality assurance records, as appropriate. 3. The service subcontractor’s records of its service quality assurance activities are periodically audited to assess how well the service quality assurance plans, standards, and procedures are being followed.
Activity 11
The prime contractor’s configuration management group monitors the service subcontractor’s configuration management activities according to a documented procedure. This procedure typically specifies that: 1. The service subcontractor’s plans, resources, procedures, and standards for configuration management are reviewed to ensure they are adequate. 2. The prime contractor and the service subcontractor coordinate their activities on matters relating to configuration management to ensure that the configuration baselines are consistent, as appropriate. 3. The service subcontractor’s configuration baseline is periodically audited to assess how well the standards and procedures for configuration management are being followed and how effective they are in managing the configuration baseline.
Activity 12
The prime contractor’s service request and incident management group monitors the service subcontractor’s service request and incident management activities according to a documented procedure. This procedure typically specifies that: 1. The service subcontractor’s plans, resources, procedures, and standards for service request and incident management are reviewed to ensure they are adequate. 2. The prime contractor and the service subcontractor coordinate their activities on matters relating to service request and incident management to ensure that the service request and incident management activities are sufficiently integrated.
5.4 Subcontract Management
63
3. The service subcontractor’s service request and incident management library system is periodically audited to assess how well the standards and procedures for service request and incident management are being followed and how effective they are in service request and incident management.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the subcontract management activities. ` Examples of measurements include: • work completed, effort expended, and funds expended in the subcontract management activities compared to the plan.
Measurement 2
Measurements are made and used to determine the service subcontractor’s performance. ` Examples of measurements include: • average leadtime of service requests handled by the service subcontractor, • percentage of incidents solved on time by the service subcontractor, and • actual service levels for subcontracted services compared to the plan.
Verifying Implementation Verification 1
The subcontract management activities are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The subcontract management activities are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
Verification 3
The service quality assurance group reviews and/or audits the subcontract management activities and work products and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. The activities for selecting the service subcontractor. 2. The activities for managing the service subcontract.
64
The Key Process Areas for Level 2: Repeatable 3. The activities for coordinating configuration management and service request and incident management activities of the prime contractor and service subcontractor. 4. The conduct of planned reviews with the service subcontractor. 5. The conduct of reviews that establish accomplishment of service levels by the service subcontractor.
5.5
Configuration Management
Purpose The main purpose of the Configuration Management key process area is to establish control over all IT components that are needed to properly deliver the services. This typically includes IT components that are operational in the production environment but may include other environments as well. These IT components are identified and recorded in configuration baselines. In addition, changes to the IT components in the production environment are controlled.
Goals Goal 1
Configuration management activities are planned.
Goal 2
Selected IT components are identified, controlled, and available. i The IT service provider identifies the IT components that are important for the delivery of the service. These IT components are controlled to make sure they are available.
Goal 3
Changes to the identified IT components are controlled. i Since the identified IT components need to be controlled to properly deliver the services, changes to these IT components need to be controlled as well.
Goal 4
Affected groups and individuals are informed of the status and content of configuration baselines. i Affected groups and individuals are informed of the status of both configuration items and changes to the configuration items on both a periodic and an event-driven basis
Commitment to Perform Commitment 1
A written organizational policy is followed for implementing configuration management (CM). This policy typically specifies that: 1. Responsibility for CM for each service is explicitly assigned.
5.5 Configuration Management
65
2. CM is implemented throughout the service’s life cycle. 3. CM is implemented for all external IT components subject to the service commitments, and designated internal IT components used for service delivery. i External IT components are used by end users of the customer. Internal IT components are used by service groups to deliver the service.
4. A repository for storing configuration items and/or the associated CM records is made available. i The contents of this repository are referred to as the ‘configuration baseline’ in these practices. The tools and procedures for accessing this repository are referred to as the ‘configuration management library system’ in these practices. i Work products that are placed under configuration management are referred to as configuration items.
5. The configuration baselines and CM activities are audited on a periodic basis.
Ability to Perform Ability 1
A board having the authority for managing the configuration baseline exists or is established. The Configuration Control Board (CCB): 1. Authorizes the establishment of configuration baselines and the identification of configuration items. 2. Represents the interests of the service delivery manager and all groups who may be affected by changes to the configuration baselines. ` Examples of affected groups include: • service delivery group, • service request and incident management group, • end users.
3. Reviews and authorizes changes to the configuration baseline. 4. Authorizes the release of IT components into the production environment. Ability 2
A group that is responsible for coordinating and implementing CM for the service (i.e., the CM group) exists. The CM group coordinates or implements: 1. Creation and management of the service’s configuration management library system.
66
The Key Process Areas for Level 2: Repeatable 2. Development, maintenance, and distribution of the CM plans, standards, and procedures. 3. The identification of the set of IT components to be placed under CM. 4. Management of the access to the configuration management library system. 5. Updates of the configuration baseline. 6. Creation of products from the configuration management library system. 7. Recording of CM activities. 8. Production and distribution of CM reports.
Ability 3
Adequate resources and funding are provided for performing the CM activities. 1. A manager is assigned specific responsibilities for CM. 2. Tools to support the CM activities are made available. ` Examples of support tools include: • workstations and/or portable computers, • database programs, • configuration management tools.
Ability 4
Members of the CM group and related groups are trained in the objectives, procedures, and methods for performing their CM activities. ` Examples of related groups include: • service quality assurance group, • documentation support, and • service delivery group. ` Examples of training include: • the standards, procedures, and methods to be followed for CM activities, and • the role, responsibilities, and authority of the CM group.
Activities Performed Activity 1
A CM plan is prepared for each service according to a documented procedure. This procedure typically specifies that: 1. The CM plan is developed in the early stages of, and in parallel with, the overall service delivery planning. 2. The CM plan is reviewed by the affected groups.
5.5 Configuration Management
67
3. The CM plan is managed and controlled. Activity 2
A documented and approved CM plan is used as the basis for performing the CM activities. The plan covers: 1. The CM activities to be performed, the schedule of activities, the assigned responsibilities, and the resources required (including staff, tools, and computer facilities). 2. The CM requirements and activities to be performed by the service delivery group and other related groups.
Activity 3
A configuration management library system is established as a repository for the configuration baselines. This library system: 1. Supports multiple control levels of CM. ` Examples of situations leading to multiple levels of control include: • differences in the levels of control needed for different IT systems, and • differences in the levels of control needed for different IT needs of the customer.
2. Provides for the storage and retrieval of configuration items. 3. Provides for the sharing and transfer of configuration items between the affected groups and between control levels within the library. 4. Helps in the use of product standards for configuration items. 5. Provides for the storage and recovery of archive versions of configuration items. 6. Helps to ensure correct creation of products from the software baseline library. 7. Provides for the storage, update, and retrieval of CM records. 8. Supports production of CM reports. 9. Provides for the maintenance of the library structure and contents. Activity 4
The products to be placed under configuration management are identified. 1. The configuration items are selected based on documented criteria.
68
The Key Process Areas for Level 2: Repeatable ` Examples of work products that may be identified as configuration items include: • process-related documentation (e.g. plans, standards, or procedures), • test procedures, • software requirements, • software components (e.g. application software, support tools), and • hardware components (e.g. workstations, network components, auxiliaries).
2. The configuration items are assigned unique identifiers. 3. The characteristics of each configuration item are specified. 4. The configuration baselines to which each configuration item belongs are specified. 5. The period in its life-cycle that each configuration item is placed under configuration management is specified. 6. The person responsible for each configuration item (i.e. the owner, from a configuration management point of view) is identified. Activity 5
Action items for all configuration items/units are initiated, recorded, reviewed, approved, and tracked to closure according to a documented procedure. i Typically, the procedure for action items will be a light-weight variant of the procedure for changes to configuration baselines. i Action items are actions that do not change the configuration baseline, but do affect the configuration items that are part of the configuration baseline. Action items are sometimes called null-changes. ` Examples of action items include: • rebooting a server, • restoring an accidently deleted file from backup, and • resetting a password. Z Refer to Activity 4 of the Service Request and Incident Management key process area for practices covering the management of action items.
Activity 6
Changes to configuration baselines are initiated, recorded, reviewed, approved, and tracked to closure according to a documented procedure. This procedure typically specifies that: 1. Reviews and/or tests are performed to ensure that changes will not cause unintended effects on the configuration baseline. 2. The CCB authorizes changes to the configuration baseline.
5.5 Configuration Management
69
3. Related changes are grouped into releases. 4. Affected groups and individuals are informed of approved changes. ` Examples of affected groups and individuals are: • the customer, • service delivery manager, • service request and incident management group, • configuration management group, and • service delivery groups.
Activity 7
Products are released into the production environment according to a documented procedure. This procedure typically specifies that: 1. Only configuration items that are approved by the CCB are entered into the production environment. 2. New or changed products are tested prior to releasing them into the production environment. 3. A back-out plan is developed prior to releasing the new or changed products. 4. Conversion of data is planned and tested. 5. A formal decision is made during the release to either keep the new product in the production environment or back out the change (’go/no-go’ decision). 6. The status of the configuration items/units is changed in the configuration management library system. Z Refer to Activity 8
Activity 8
The status of configuration items/units is recorded according to a documented procedure. i Both the status of changes (refer to Activity 6) and the status of configuration items are recorded. This is necessary because the status of configuration items is updated when a change is implemented, but information about changes needs to be recorded much earlier than that.
This procedure typically specifies that: 1. The configuration management actions are recorded in sufficient detail so that the content and status of each configuration item are known and previous versions can be recovered. 2. The current status and history (i.e. changes and other actions) of each configuration item are maintained. Activity 9
Affected groups and individuals are informed of the status of configuration items/units and changes.
70
The Key Process Areas for Level 2: Repeatable ` Examples of affected groups and individuals include: • service request and incident management group, • service delivery group, • service delivery manager, and • end users.
Activity 10
Standard reports documenting the CM activities and the contents of the configuration baselines are developed and made available to affected groups and individuals. ` Examples of reports include: • CCB meeting minutes, • change request summary and status, • trouble report summary and status (including fixes), • summary of changes made to the baseline, • revision history of configuration items, • baseline status, and • results of configuration baseline audits.
Activity 11
Configuration baseline audits are conducted according to a documented procedure. This procedure typically specifies that: 1. There is adequate preparation for the audit. 2. The integrity of the configuration baselines is assessed. 3. The structure of and facilities of the configuration management library system are reviewed. 4. The completeness and correctness of the configuration baseline library contents are verified. 5. Compliance with applicable CM standards and procedures is verified. 6. The results of the audit are reported to the service manager. 7. Action items from the audit are tracked to closure.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the configuration baseline.
5.5 Configuration Management
71
` Examples of measurements include: • availability of selected IT components, • response times of selected IT components, and • location of mobile hardware products.
Measurement 2
Measurements are made and used to determine the status of the CM activities. ` Examples of measurements include: • number of change requests processed per unit time, • completions of milestones for the CM activities compared to the plan, and • work completed, effort expended, and funds expended in the CM activities.
Verifying Implementation Verification 1
The CM activities are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The CM activities are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
Verification 3
The CM group periodically audits configuration baselines to verify that they conform to the documentation that defines them. Z Refer to Activity 11 for practices covering the auditing of configuration baselines.
Verification 4
The service quality assurance group reviews and/or audits the CM activities and work products and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. Compliance with the CM standards and procedures by: • • • •
the CM group, the CCB, the service delivery group, and other related groups.
2. Occurrence of periodic configuration baseline audits.
72
5.6
The Key Process Areas for Level 2: Repeatable
Service Request and Incident Management
Purpose The main purpose of the key process area Service Request and Incident Management is to identify, record, track, analyse, and resolve service requests and incidents that occur during service delivery. Both service requests and incidents are events that – if not resolved – eventually will cause the IT service provider to break its service commitments. Service requests are requests by the customer for certain service activities to be performed. Note that these activities should fall within the bounds of the service commitments. For example, the customer asks for an extra workplace to be installed. Incidents are events that need to be resolved in order to meet the service commitments. For example, if a system goes down it has to be restarted before the maximum downtime is exceeded. Service requests and incidents are always concerned with one or more IT components. They are resolved by action items.
Goals Goal 1
Service request and incident management activities are planned. i The planning of service request and incident management activities includes estimating the service request and incident workload and deriving the schedule of service request and incident management personnel.
Goal 2
Service requests and incidents are identified, recorded, analyzed, tracked, and resolved.
Goal 3
Affected groups and individuals are informed of the status of service requests, incidents, and action items.
Commitment to Perform Commitment 1
A written organizational policy is followed for implementing service request and incident management (SR&IM). This policy typically specifies that: 1. Responsibility for SR&IM for each service is explicitly assigned. 2. SR&IM is implemented throughout the duration of the service commitments. 3. A repository for storing service request and incident information is made available. 4. The service request and incident repository and SR&IM activities are audited on a periodic basis.
5.6 Service Request and Incident Management
73
Ability to Perform Ability 1
A group that is responsible for coordinating and implementing SR&IM for the service (i.e., the SR&IM group) exists. The SR&IM group coordinates or implements: 1. Creation and management of the service’s service request and incident repository. 2. Development, maintenance, and distribution of SR&IM plans, standards, and procedures. 3. Management of access to the service request and incident repository. 4. Changes to the service request and incident repository. 5. Recording of SR&IM activities. 6. Production and distribution of SR&IM reports.
Ability 2
Adequate resources and funding are provided for performing the SR&IM activities. 1. A manager is assigned specific responsibility for SR&IM. 2. Tools to support the SR&IM activities are made available. ` Examples of support tools include: • workstations and/or portable computers, • service request and incident management software.
Ability 3
Members of the SR&IM group and related groups are trained in the objectives, procedures, and methods for performing their SR&IM activities. ` Examples of related groups include: • service quality assurance group, • configuration management group, • end users, and • service delivery group. ` Examples of training include: • the standards, procedures, and methods to be followed for SR&IM activities, and • the role, responsibilities, and authority of the SR&IM group.
74
The Key Process Areas for Level 2: Repeatable
Activities Performed Activity 1
A SR&IM plan is prepared for each service according to a documented procedure. This procedure typically specifies that: 1. The SR&IM plan is developed in the early stages of, and in parallel with, the overall service delivery planning. Added
2. The SR&IM plan is reviewed by the service manager and affected groups. k service manager
3. The SR&IM plan is managed and controlled. Activity 2
A documented and approved SR&IM plan is used as the basis for performing the SR&IM activities. The plan covers: 1. Estimates of the service request and incident workload. 2. The SR&IM activities to be performed, the schedule of the activities, the assigned responsibilities, and the resources required (including staff, tools, and computer facilities).
Activity 3
A service request and incident management library system is established as a repository for the service request and incident records. This library system: 1. Provides for the storage, update, and retrieval of service request and incident records. 2. Provides for the sharing and transfer of service request and incident records between affected groups. 3. Helps in the use of service request and incident procedures. Z Refer to Activity 4.
4. Provides for the archival and retrieval of historic service request and incident information. 5. Supports production of SR&IM reports. Activity 4
Service requests and incidents are identified, recorded, analyzed, reviewed, and resolved according to a documented procedure. This procedure typically specifies that: 1. The service requests and incidents are recorded in sufficient detail so that the content and the status of each service request and incident are known. This typically includes:
5.6 Service Request and Incident Management
75
• • • •
a unique identifier, description of the service request or incident, date and time of occurrence, name and contact information of the person who reported the service request or incident, • the configuration items concerned, and • relevant characteristics of the situation in which the service request or incident occurred. 2. The impact of the service request or incident to the service commitments is assessed and documented. 3. Action items resulting from service requests and incidents are: • • • • • • • • Activity 5
identified, assessed for risk, documented, planned, initiated, communicated to the affected groups and individuals, tracked to closure, and evaluated.
Affected groups and individuals are informed of the status of service requests and incidents on both a periodic and an event-driven basis. ` Examples of affected groups and individuals include: • configuration management group, • service delivery group, • service manager, and • end users.
Activity 6
Standard reports documenting the SR&IM activities and the contents of the service request and incident repository are developed and made available to affected groups and individuals. ` Examples of reports include: • service request and incident description and status, • action item description and status, • summary of incidents by configuration item, and • summary of service requests during a certain period.
Activity 7
Service request and incident repository audits are conducted according to a documented procedure.
76
The Key Process Areas for Level 2: Repeatable This procedure typically specifies that: 1. There is adequate preparation for the audit. 2. The integrity of the service request and incident repository is assessed. 3. The facilities of the service request and incident management library system are reviewed. 4. The completeness and correctness of the repository are verified. 5. Compliance with applicable SR&IM standards and procedures is verified. 6. The results of the audit are reported to the service manager. 7. Action items from the audit are tracked to closure.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the service requests and incidents in the service request and incident repository. ` Examples of measurements include: • number of incidents unresolved, • average leadtime of closed service requests, • percentage of incidents not closed within the maximum time.
Measurement 2
Measurements are made and used to determine the status of the SR&IM activities. ` Examples of measurements include: • number of service requests processed per unit time, • number of action items completed per unit time, and • effort expended and funds expended in the SR&IM activities.
Verifying Implementation Verification 1
The SR&IM activities are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The SR&IM activities are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
5.7 Service Quality Assurance Verification 3
77
The SR&IM group periodically audits service request and incident repositories to verify that they conform to the documentation that defines them. Z Refer to Activity 7 for practices covering the auditing of the service request and incident repository.
Verification 4
The service quality assurance group reviews and/or audits the SR&IM activities and work products and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. Compliance with the SR&IM standards and procedures by: • the SR&IM group, • the service delivery group, and • other related groups. 2. Occurrence of periodic service request and incident repository audits.
5.7
Service Quality Assurance
Purpose The main purpose of the key process area Service Quality Assurance is to provide management with the appropriate visibility into the processes being used and the services delivered. The independent service quality assurance group reviews and audits working procedures, standards, and service delivery activities to see that they comply with the applicable procedures and standards. The results of these reviews and audits are reported to the involved groups and individuals and to senior management. Senior management is responsible for acting upon the results of the service quality assurance activities.
Goals Goal 1
Service quality assurance activities are planned. i Service quality assurance activities need to be planned to ensure that audits and reviews are performed on a regular basis.
Goal 2
Adherence of services and service activities to the applicable standards, procedures and service commitments is verified objectively.
Goal 3
Affected groups and individuals are informed of service quality assurance activities and results.
Goal 4
Noncompliance issues that cannot be resolved within the service delivery group are addressed by senior management.
78
The Key Process Areas for Level 2: Repeatable
Commitment to Perform Commitment 1
A written organizational policy is followed for implementing service quality assurance (SQA). This policy typically specifies that: 1. The SQA function is in place on all services delivered. 2. The SQA group has a reporting channel to senior management that is independent of the service manager, the service’s service delivery group, and the other service related groups. 3. Senior management periodically reviews the SQA activities and results.
Ability to Perform Ability 1
A group that is responsible for coordinating and implementing SQA for the service (i.e. the SQA group) exists.
Ability 2
Adequate resources and funding are provided for performing the SQA activities. 1. A manager is assigned specific responsibilities for the service’s SQA activities. 2. A senior manager, who is knowledgeable in the SQA role and has the authority to take appropriate oversight actions, is designated to receive and act on service noncompliance issues. • All managers in the SQA reporting chain to the senior manager are knowledgeable in the SQA role, responsibilities, and authority. 3. Tools to support the SQA activities are made available. ` Examples of support tools include: • database programs, • spreadsheet programs, and • auditing tools.
Ability 3
Members of the SQA group are trained to perform their SQA activities. ` Examples of training include: • roles and responsibilities of the service delivery group, • standards, procedures, and methods for the services delivered, • application domain of the service, • SQA objectives, procedures, and methods, • involvement of the SQA group in the service activities, • effective use of SQA methods and tools, and • interpersonal communication.
5.7 Service Quality Assurance Ability 4
79
The members of the service delivery group receive orientation on the role, responsibilities, authority, and value of the SQA group.
Activities Performed Activity 1
A SQA plan is prepared for the service delivery according to a documented procedure. This procedure typically specifies that: 1. The SQA plan is developed in the early stages of, and in parallel with, the overall service delivery planning. 2. The SQA plan is reviewed by the affected groups and individuals. ` Examples of affected groups and individuals include: • the service delivery manager, • other service delivery managers, • the service manager, • customer SQA representative, • the senior manager to whom the SQA group reports noncompliance issues, and • the service delivery group (including all subgroups, such as the service request and incident management group as well as the service task leaders).
3. The SQA plan is managed and controlled. Activity 2
The SQA group’s activities are performed in accordance with the SQA plan. The plan covers: 1. Responsibilities and authority of the SQA group. 2. Resource requirements for the SQA group (including staff, tools, and facilities). 3. Schedule and funding of the service’s SQA group activities. 4. The SQA group’s participation in establishing the service delivery plan, standards, and procedures for the service delivery. 5. Evaluations to be performed by the SQA group. ` Examples of activities and products to be evaluated include: • service request and incident management activities, • service request and incident management library system, • configuration management activities, and • configuration baseline.
6. Audits and reviews to be conducted by the SQA group. 7. Standards and procedures to be used as the basis for the SQA group’s reviews and audits.
80
The Key Process Areas for Level 2: Repeatable 8. Procedures for documenting and tracking noncompliance issues to closure. i These procedures may be included as part of the plan or may be included via reference to other documents where they are contained.
9. Documentation the SQA group is required to produce. 10. Method and frequency of providing feedback to the service delivery group and other service-related groups on SQA activities. Activity 3
The SQA group participates in the preparation and review of the service commitments and service delivery planning, standards and procedures. 1. The SQA group provides consultation and review of the plans, standards, and procedures with regard to: • compliance to organizational policies, • compliance to externally imposed standards and requirements (e.g., standards required by the customer), • standards that are appropriate for the service delivery, • topics that should be addressed in the service delivery plan, and • other areas as assigned by the service manager. 2. The SQA group verifies that plans, standards, and procedures are in place and can be used to review and audit the service delivery.
Activity 4
The SQA group audits the service delivery activities and service support activities to verify compliance. 1. The activities are evaluated against the service delivery plan and the designated service standards and procedures. Z Refer to the Verifying Implementation common feature in the other key process areas for practices covering the specific reviews and audits performed by the SQA group.
2. Deviations are identified, documented, and tracked to closure. 3. Corrections are verified. Activity 5
The SQA group audits designated service work products to verify compliance. ` Examples of service work products include: • service level reports, • evaluation of changes, and • contingency plan.
1. Deliverable service work products are evaluated before they are delivered to the customer.
5.7 Service Quality Assurance
81
2. The service work products are evaluated against the designated service standards, procedures, and contractual requirements. Z Refer to the Verifying Implementation common feature in the other key process areas for practices covering the specific reviews and audits performed by the SQA group.
3. Deviations are identified, documented, and tracked to closure. 4. Corrections are verified. Activity 6
The SQA group periodically reports the results of its activities to the service delivery group.
Activity 7
Deviations identified in the service activities and delivered service are documented and handled according to a documented procedure. This procedure typically specifies that: 1. Deviations from the service delivery plan and the designated service standards and procedures are documented and resolved with the appropriate service task leaders, service delivery managers, or service managers, where possible. 2. Deviations from the service delivery plan and the designated service standards and procedures not resolvable with the service task leaders, service delivery managers, or service manager are documented and presented to the senior manager designated to receive noncompliance items. 3. Noncompliance items presented to the senior manager are periodically reviewed until they are resolved. 4. The documentation of noncompliance items is managed and controlled.
Activity 8
The SQA group conducts periodic reviews of its activities and findings with the customer’s SQA personnel, as appropriate.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the cost and schedule status of the SQA activities. ` Examples of measurements include: • completions of milestones for the SQA activities compared to the plan, • work completed, effort expended, and funds expended in the SQA activities compared to the plan, and • number of activity reviews compared to the plan.
82
The Key Process Areas for Level 2: Repeatable
Verifying Implementation Verification 1
The SQA activities are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The SQA activities are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
Verification 3
Experts independent of the SQA group periodically review the activities and work products of the SQA group.
Chapter 6
The Key Process Areas for Level 3: Defined 6.1
Organization Service Definition
Purpose The Organization Service Definition key process area is aimed at developing and maintaining a description (service catalog) of the services that an organization is able to provide. The services are to be described in terms of benefits for the customer, not in technical terms. The service catalog should also include typical service levels the IT service provider can deliver and an indication of the price of the services. Which services are in the service catalog largely depends on factors outside the scope of the IT Service CMM. For in-house IT service providers this may be dictated by the business of the customer, for other IT service providers this may depend on the mission, business strategy and marketing information. The processes needed to deliver the services in the service catalog are developed by Organization Process Definition. So Organization Service Definition describes the services in terms of benefits for the customer, while Organization Process Definition describes what activities are needed to create the services. Information about the actual delivery of the services is collected and made available to guide in establishing realistic service commitments with customers (Service Commitment Management).
Goals Goal 1
Standard services of the organization are developed and maintained. i Typically, the standard services are documented in a service catalog.
Goal 2
Information related to the delivery of the organization’s standard services is collected, reviewed, and made available. i By collecting information about the delivery of the standard services, the organization gains insight in the service levels it can guarantee and the cost of the services.
83
84
The Key Process Areas for Level 3: Defined
Commitment to Perform Commitment 1
The organization follows a written policy for developing and maintaining standard services. This policy typically specifies that: 1. Standard services are defined for the organization. i The primary purpose of standardizing services is to deliver services with predictable service quality.
2. Services delivered to customers are tailored versions of the organization’s standard services. Z Refer to Activity 1 of the Integrated Service Management key process area for practices covering tailoring of the organization’s standard services.
3. The organization’s standard services are maintained. 4. Information collected from the delivery of services is organized and used to improve the organization’s standard services. ` Examples of collected information include: • process and service measurements, • lessons learned, and • other service-related documentation.
Ability to Perform Ability 1
Adequate resources and funding are provided for developing and maintaining the organization’s standard services.
Ability 2
The individuals who develop and maintain the organization’s standard services receive required training to perform these activities. i The individuals who develop and maintain the organization’s standard services are usually the service managers. Z Refer to the Training Program key process area.
Ability 3
Historical information on the delivery of the organization’s standard services is available. Z Refer to Activity 4 of the Organization Process Definition key process area for practices covering the service process database.
Activities Performed Activity 1
The organization’s standard services are developed and maintained according to a documented procedure.
6.1 Organization Service Definition Activity 2
85
The organization’s standard services are documented according to established organization standards. These standards typically specify that:
Added
1. The service is specified in terms of customer benefits. 2. The range of service levels that can be delivered are specified. 3. The standard charging policy of the service is specified. Activity 3
Guidelines and criteria for the tailoring of the organization’s standard services are developed and maintained. 1. The tailoring guidelines and criteria cover: • selecting and combining standard services, • tailoring the standard services to accommodate the service commitments and the service delivery planning, ` Examples of tailoring include: – adapting the standard service for a specific hardware environment, – adapting the charging policy for parts of the service,
k
Added example
– customizing the standard service for a specific customer, and – elaborating and adding detail to the service specification so that the resulting service can be delivered to the customer.
• standards for documenting the tailored service. 2. Changes proposed for the tailoring guidelines and criteria are documented, reviewed, and approved by the group responsible for the organization’s standard services before they are incorporated. 3. The tailoring guidelines and criteria are managed and controlled. Activity 4
The organization’s service catalog is established and maintained. 1. The organization’s service catalog is established to make available information on the services the organization can deliver to its customers. ` Examples of information in the service catalog include: • description of services in terms of customer benefits, • typical service levels the organization can maintain, and • historical data on delivered services and their service levels.
2. The information entered into the service catalog is reviewed to ensure the integrity of the service catalog. 3. The information in the service catalog is based on the service process database. Z Refer to Activity 4 of the Organization Process Definition key process area for practices covering the service process database.
86
The Key Process Areas for Level 3: Defined 4. The service catalog is managed and controlled.
Activity 5
The organization’s service process database is established and maintained. Z Refer to Activity 4 of the Organization Process Definition key process area for practices covering the service process database.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the organization’s service definition activities. ` Examples of measurements include: • status of the schedule milestones for service definition and maintenance, and • costs for the service definition activities.
Verifying Implementation Verification 1
The service quality assurance group reviews and/or audits the organization’s activities and work products for developing and maintaining the organization’s standard services and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, these reviews and/or audits verify that: 1. The appropriate standards are followed in developing, documenting, and maintaining the organization’s standard services. 2. The organization’s standard services are controlled and used appropriately. Reports of non-compliance are provided for senior management and service delivery managers.
6.2
Organization Process Definition
Purpose The purpose of Organization Process Definition is to develop and maintain a usable set of service process assets that improve process performance across services and provide a basis for cumulative, long-term benefits to the service organization and its customers. Organization Process Definition involves developing and maintaining the organization’s standard service process, along with related process assets, such as descriptions of process tailoring guidelines and criteria, the organization’s service process database1 and a library of service processrelated documentation. 1
The service process database contains data on the execution of processes, such as estimates on workload, effort, and costs, productivity data, service level measurements, number of incidents, etc.
6.2 Organization Process Definition
87
The organization’s service process assets are available for use in developing, implementing, and maintaining the services’ defined service processes. (Practices related to the development and maintenance of the service’s defined service process are described in the Integrated Service Management key process area).
Goals Goal 1
A standard service process for the organization is developed and maintained. i Typically, the organization develops a standard service process for each standard service it provides.
Goal 2
Information related to the use of the organization’s standard service process to deliver services is collected, reviewed, and made available. i By collecting information about the use of standard service process to deliver the standard services, the organization gains insight in the service levels it can guarantee and the cost of the services.
Commitment to Perform Commitment 1
The organization follows a written policy for developing and maintaining a standard service process and related process assets. i The organization’s service process assets include: • the organization’s standard service process, • guidelines and criteria for the tailoring of the organization’s standard service process, • the organization’s service process database, and • a library of service process-related documentation previously developed and available for reuse.
This policy typically specifies that: 1. The organization’s standard service process is based upon the corresponding standard service of the organization. 2. A standard service process is defined for the organization. i The primary purpose of a standard service process is to maximize the sharing of process assets and experiences across services and to provide the ability to define and aggregate a standard set of process measurements from the delivered services at the organization level. i The organization’s standard service process may contain multiple service processes. Multiple service processes may be needed to deliver different services, to address the needs of different customers, or to effectively use different technologies and tools.
L3KPAS
0.2/4
88
The Key Process Areas for Level 3: Defined 3. A service’s defined service process is a tailored version of the organization’s standard service process. Z Refer to Activity 1 of the Integrated Service Management key process area for practices covering tailoring of the organization’s standard service process.
4. The organization’s service process assets are maintained. 5. Information collected from the delivery of services is organized and used to improve the organization’s standard service process. ` Examples of collected information include: • process and service measurements, • lessons learned, and • other process-related documentation.
Ability to Perform Ability 1
Adequate resources and funding are provided for developing and maintaining the organization’s standard service process and related process assets. 1. The development and maintenance of the organization’s standard service process and related process assets is performed or coordinated by the group responsible for the organization’s service process activities (e.g., service delivery process group). Z Refer to the Organization Process Focus key process area for practices covering the organization’s service process development and improvement activities.
2. Tools to support process development and maintenance are made available. ` Examples of support tools include: • desktop publishing tools, • database management systems, and • process modeling tools.
Ability 2
The individuals who develop and maintain the organization’s standard service process and related process assets receive required training to perform these activities. ` Examples of training include: • service delivery practices and methods such as the IT Infrastructure Library, • process analysis and documentation methods, and • process modeling. Z Refer to the Training Program key process area.
6.2 Organization Process Definition
89
Activities Performed Activity 1
The organization’s standard service process is developed and maintained according to a documented procedure. This procedure typically specifies that: 1. The organization’s standard service process satisfies the standard services, service policies, process standards, and service levels imposed on the organization, as appropriate. 2. The organization’s standard service process satisfies the service process standards and service levels that are commonly imposed on the organization’s services by their customers, as appropriate. 3. State-of-the-practice service delivery tools and methods are incorporated into the organization’s standard service process, as appropriate. 4. The internal process interfaces between the service disciplines are described. ` Examples of service disciplines include: • software maintenance, • user support, • software operation, • configuration management, and • service quality assurance.
5. The external process interfaces between the service process and the processes of other affected groups are described. ` Examples of other affected groups include: • software development, • contract management, and • documentation support.
6. Changes proposed for the organization’s standard service process are documented, reviewed, and approved by the group responsible for the organization’s service process activities (e.g., service delivery process group) before they are incorporated. ` Examples of sources for change include: • changes to the organization’s standard services, • the findings and recommendations of service process assessments, • results of the tailoring of the organization’s standard service process, • lessons learned from monitoring the organization’s and services’ process activities, • changes proposed by the organization’s staff and managers, and • process, product, and service measurement data that are analyzed and interpreted.
90
The Key Process Areas for Level 3: Defined 7. Plans for introducing changes to the service process of ongoing services are defined as appropriate. 8. The description of the organization’s standard service process undergoes peer review when initially developed and whenever significant changes or additions are made. Z Refer to the Software CMM Peer Reviews key process area.
9. The description of the organization’s standard service process is placed under configuration management. Z Refer to the Configuration Management key process area.
Activity 2
The organization’s standard service process is documented according to established organization standards. These standard typically specify that: 1. The process is decomposed into constituent process elements to the granularity needed to understand and describe the process. i Each process element covers a well-defined, bounded, closely related set of activities. ` Examples of process elements include: • service work-load estimating element, • IT change element, • service request intake element, • end-user communication element.
2. Each process element is described and addresses: • • • • • • • • • •
the required procedures, practices, methods, and technologies, the applicable process, product, and service standards, the responsibilities for implementing the process element, the required tools and resources, inputs, input prerequisites, the work products produced, the work products that should undergo peer review, the readiness and completion criteria, and the product, services, and process data to be collected.
3. The relationships of the process elements are described and address: • the ordering, • the interfaces, and • the interdependencies.
6.2 Organization Process Definition
91
i This relationship of the process elements is sometimes referred to as a service process architecture.
Activity 3
Guidelines and criteria for the tailoring of the organization’s standard service process are developed and maintained. 1. The tailoring guidelines and criteria cover: • tailoring the organization’s standard service process to accomodate service commitments and service delivery planning. ` Examples of tailoring include: – adapting the process for a new hardware environment, – customizing the process for the combined delivery of different services, and – elaborating and adding detail to the process so that the resulting defined service process can be enacted.
• standards for documenting the defined service process. 2. Changes proposed for the tailoring guidelines and criteria are documented, reviewed, and approved by the group responsible for the organization’s standard service process activities before they are incorporated. 3. The tailoring guidelines and criteria are managed and controlled. Activity 4
The organization’s service process database is established and maintained. 1. The database is established to collect and make available data on the service processes and resulting services. ` Examples of process and service data include: • service level measurements, • estimates of workload, effort, and cost, • actual data on workload, effort, and cost, • productivity data, • number and severity of incidents and service requests, and • time to resolve incidents and service requests.
2. The data entered into the database are reviewed to ensure the integrity of the database contents. i In addition, the database also contains or references the actual measurement data and related information and data needed to understand and interpret the measurement data and assess it for reasonableness and applicability.
3. The database is managed and controlled. 4. User access to the database contents is controlled to ensure completeness, integrity, and accuracy of the data.
92
The Key Process Areas for Level 3: Defined i Access is limited to those who have a need to enter, change, view, analyze, or extract data. Sensitive data are protected and access to these data is appropriately controlled.
Activity 5
A library of service process-related documentation is established and maintained. ` Examples of service process-related documentation include: • the description of a service’s defined service process, • a service’s standards, • a service’s procedures, • service delivery plans, • measurement plans, and • a service’s process training materials.
1. Candidate documentation items are reviewed, and appropriate items that may be useful in the future are included in the library. 2. The documentation items are catalogued for easy access. 3. Revisions made to documentation items currently in the library are reviewed, and the library contents are updated as appropriately. 4. The library contents are made available for use by the service delivery groups and other service related groups. ` Examples of service-related groups include: • service quality assurance group, • configuration management group, and • documentation support.
5. The use of each documentation item is reviewed periodically, and the results are used to maintain the library contents. 6. The library contents are managed and controlled.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the organization’s process definition activities. ` Examples of measurements include: • status of the schedule milestones for process development and maintenance, and • costs for the process definition activities.
6.3 Organization Process Focus
93
Verifying Implementation Verification 1
The service quality assurance group reviews and/or audits the organization’s activities and work products for developing and maintaining the organization’s standard service process and related process assets and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, these reviews and/or audits verify that: 1. The appropriate standards are followed in developing, documenting, and maintaining the organization’s standard service process and related process assets. 2. The organization’s standard service process and related process assets are controlled and used appropriately.
6.3
Organization Process Focus
Purpose The purpose of Organization Process Focus is to establish the organizational responsibility for process activities that improve the organization’s overall service process capability. Organization Process Focus involves developing and maintaining the understanding of the organization’s and services’ processes and coordinating the activities to assess, develop, maintain, and improve these processes. The organization provides the long-term commitments and resources to coordinate the development and maintenance of the service processes across current and future service delivery via a process improvement group. This group is responsible for the organization’s service process activities. It is specifically responsible for the development and maintenance of the organization’s standard service process and related process assets, and it coordinates the process activities.
Goals Goal 1
Service process development and improvement activities are coordinated across the organization. i Service process development and improvement activities are typically coordinated by a service process improvement group.
Goal 2
The strengths and weaknesses of the service processes used are identified relative to a process standard. i The process standard used to identify the strengths and weaknesses of the service processes will usually be an external standard. Examples of process standards include the IT Service CMM and the IT Infrastructure Library. Typically, the strengths and weaknesses of the service processes are identified by means of process assessments.
94 Goal 3
The Key Process Areas for Level 3: Defined Organization-level process development and improvement activities are planned. i Sufficient preparation and planning is needed to succesfully identify strengths and weaknesses of the service processes and, more importantly, to successfully implement improvements to the service processes.
Commitment to Perform Commitment 1
The organization follows a written organizational policy for coordinating service process development and improvement activities across the organization. This policy typically specifies that: 1. A group is established that is responsible for the organization-level service process activities and coordinating these activities with the actual service delivery. 2. The service processes used during service delivery are assessed periodically to determine their strengths and weaknesses. 3. The service processes used during service delivery are appropriately tailored from the organization’s standard service process. Z Refer to Activity 1 of the Integrated Service Management key process area for practices covering tailoring of the organization’s standard services.
4. Improvements to, and other useful information on, each service’s defined process, tools, and methodologies are made available to other services. Commitment 2
Senior management sponsors the organization’s activities for service process development and improvement. Senior management: 1. Demonstrates to the organization’s staff and managers its commitment to these service process activities. 2. Establishes long-term plans and commitments for funding, staffing and other resources. 3. Establishes strategies for managing and implementing the activities for process development and improvement.
Commitment 3
Senior management oversees the organization’s activities for service process development and improvement. Senior management: 1. Ensures that the organization’s standard service process supports its business goals and strategies.
6.3 Organization Process Focus
95
2. Advises on setting priorities for service process development and improvement. 3. Participates in establishing plans for service process development and improvement. • Senior management coordinates service process requirements and issues with higher level staff and managers. • Senior management coordinates with the organization’s managers to secure the managers’ and staff’s support and participation.
Ability to Perform Ability 1
A group that is responsible for the organization’s service process development and improvement activities exists. 1. Where possible, this group is staffed by a core of professional service engineers who are assigned full time to the group, possibly supported by others, on a part-time basis. i This group is normally called the service process improvement group.
2. This group is staffed to represent the service delivery discipline and servicerelated disciplines. ` Examples of service delivery and service-related disciplines include: • software maintenance, • end user support, • software operation, • configuration management, and • service quality assurance.
Ability 2
Adequate resources and funding are provided for the organization’s service process development and improvement activities. 1. Experienced individuals who have expertise in specialized areas are committed to support this group. ` Examples of specialized areas include: • software maintenance, • service level agreement specification, • measurement, and • training course development.
2. Tools to support the organization’s service process development and improvement activities are made available.
96
The Key Process Areas for Level 3: Defined ` Examples of support tools include: • statistical analysis tools, • desktop publishing tools, • database management systems, and • process modeling tools.
Ability 3
Members of the group responsible for the organization’s service process development and improvement activities receive required training to perform these activities. ` Examples of training include: • service delivery practices and methods such as the IT Infrastructure Library, • process analysis and documentation methods, and • process modeling. Z Refer to the Training Program key process area.
Ability 4
Members of the service delivery group and other service-related groups receive orientation on the organization’s service process development and improvement activities and their roles in those activities. Z Refer to the Training Program key process area.
Activities Performed Activity 1
The service processes are assessed periodically, and action plans are developed to address the assessment findings. i Assessments are typically conducted every 0.5 to 1.5 years.
Assessments observe all service processes used in the organization, but may do this
Rephrased
by sampling process areas and specific services and customers. Depending on the goal of the process assessment, an appropriate assessment approach is selected. i The action plan identifies: • which assessment findings will be addressed, • guidelines for implementing the changes to address findings, • the groups or individuals responsible for implementing the changes, and • when the changes, or parts of the changes, will be implemented.
Activity 2
The organization develops and maintains a plan for its service process development and improvement activities. This plan:
6.3 Organization Process Focus
97
1. Uses the action plans from the service process assessments and other organization improvement initiatives as primary inputs. 2. Defines the activities to be performed and the schedule for these activities. 3. Specifies the groups and individuals responsible for the activities. 4. Identifies the resources required, including staff and tools. 5. Undergoes peer review when initially released and whenever major revisions are made. Z Refer to the Software CMM Peer Reviews key process area.
6. Is reviewed and agreed upon by the organization’s service managers and senior managers. Activity 3
The activities for service process development and improvement are coordinated at the organization level. This coordination covers the development and improvement of: 1. The organization’s standard service process. Z Refer to Activities 1 and 2 of the Organization Process Definition key process area for practices covering the organization’s standard service process.
2. The service’s defined service processes. Z Refer to Activities 1 and 2 of the Integrated Service Management key process area for practices covering the service’s defined service process.
Activity 4
The use of the organization’s service process database is coordinated at the organizational level. i The organization’s service process database is used to collect information on the service processes and resulting services of the organization and its service delivery activities. Z Refer to Activity 4 of the Organization Process Definition key process area for practices covering the organization’s service process database.
Activity 5
New processes, methods, and tools in limited use in the organization are monitored, evaluated, and, where appropriate, transferred to other parts of the organization. ` An innovative configuration management tool that was used in delivering a certain service upon customer’s request might be evaluated positively by the organization’s personnel. The organization might decide to use this configuration management tool in delivering other or future services.
Activity 6
Training for the organization’s service processes is coordinated across the organization.
98
The Key Process Areas for Level 3: Defined 1. Plans for training on subjects related to the organization’s service processes are prepared. 2. Where appropriate, training may be prepared and conducted by the group responsible for the organization’s service process development and improvement activities (e.g., service process improvement group) or by the training group. Z Refer to the Training Program key process area.
Activity 7
The groups involved in implementing the service processes are informed of the organization’s activities for service process development and improvement. ` Examples of means to inform and involve these people include: • electronic bulletin boards on organizational service processes, • e-mail, • process advisory boards, • working groups, • information exchange meetings, • surveys, • process improvement teams, and • informal discussions.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the organization’s service process development and improvement activities. ` Examples of measurements include: • work completed, effort expended, and funds expended in the organization’s activities for process assessment, development, and improvement compared to the plans for these activities, and • results of each service process assessment, compared to the results and recommendations of previous assessments.
Verifying Implementation Verification 1
The activities for service process development and improvement are reviewed with senior management on a periodic basis.
6.4 Integrated Service Management
99
i The primary purpose of periodic reviews by senior management is to provide awareness of, and insight into, service process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
1. Progress and status of the activities to develop and improve the service process are reviewed against the plan. 2. Conflict and issues not resolved at lower management levels are addressed. 3. Action items are assigned, reviewed, and tracked to closure. 4. A summary report from each review is prepared and distributed to the affected groups and individuals.
6.4
Integrated Service Management
Purpose The purpose of Integrated Service Management is to integrate the service delivery and management activities into a coherent, defined service process that is tailored from the organization’s standard service process and related process assets, which are described in Organization Process Definition. Integrated Service Management involves developing the service’s defined service process and managing the service using this defined service process. The service’s defined process is tailored from the organization’s standard service process to address the specific characteristics of the service to be delivered. The service delivery plan (see the Service Delivery Planning key process area) is based on the service’s defined service process and describes how the activities of the service’s defined service process will be performed and managed. The management of the service levels, effort, cost, schedule, staffing, and other resources is tied to the tasks of the service’s defined service process. Since the services’ defined service processes are all tailored from the organization’s standard service processes, services can share process data and lessons learned. The basic practices for estimating, planning, and tracking service delivery are described in the Service Delivery Planning and Service Tracking and Oversight key process areas. They focus on recognizing problems when they occur and adjusting the plans and/or performance to address the problems. The practices of this key process area build on, and are in addition to, the practices of those two key process areas. The emphasis of Integrated Service Management shifts to anticipating problems and acting to prevent or minimize the effects of these problems.
Goals Goal 1
The service’s defined service process is a tailored version of the organization’s standard service process.
100
The Key Process Areas for Level 3: Defined i The service’s defined service process is tailored to the service commitments at hand. This ensures that the service’s defined service process fits the service commitments and other characteristics of the service to be delivered. At the same time, the defined service process is still a version of the standard service process so that process data and lessons learned can be shared, for this service and future services.
Goal 2
The service delivery is planned and managed according to the service’s defined service process. i This goal ensures that the standard service process is not only tailored to the service commitments at hand, but is also used as the basis for planning and managing the service delivery.
Commitment to Perform Commitment 1
The service follows a written organizational policy requiring that the service delivery be planned and managed using the organization’s standard service process and related process assets. Z Refer to the Organization Process Definition key process area for practices covering the organization’s standard service process and related process assets.
This policy typically specifies that: 1. For each service to be delivered, the defined service process is documented by tailoring the organization’s standard service process. 2. Deviations from the organization’s standard service process are documented and approved. 3. For each service delivered, the service activities are performed in accordance with the service’s defined service process. 4. For each service delivered, appropriate service measurement data are collected and stored in the organization’s service process database. Z Refer to Activity 4 of the Organization Process Definition key process area for practices covering the organization’s service process database.
Ability to Perform Ability 1
Adequate resources and funding are provided for managing the service delivery using the service’s defined service process. Z Refer to Ability 2 of the Service Delivery Planning key process area and Ability 3 of the Service Tracking and Oversight key process area for practices covering resources and funding for service delivery planning, tracking, and oversight.
6.4 Integrated Service Management Ability 2
101
The individuals responsible for developing the service’s defined service process receive required training in how to tailor the organization’s standard service process and use the related process assets. ` Examples of specialized areas include: • using the service process database, • using the organization’s standard service process, and • using the guidelines and criteria for tailoring the organization’s standard service process to meet the needs of the service to be delivered. Z Refer to the Training Program key process area.
Ability 3
The service delivery managers receive required training in managing the technical, administrative, and personnel aspects of the service delivery based on the service’s defined service process. Z Refer to Ability 3 of the Service Delivery Planning key process area and Ability 4 of the Service Tracking and Oversight key process area for practices covering training for service delivery planning, tracking, and oversight. ` Examples of training include: • methods and procedures for service estimating, planning, and tracking based on the service’s defined service process, and • methods and procedures for identifying, managing, and communicating service delivery risks. Z Refer to the Training Program key process area.
Activities Performed Activity 1
The service’s defined service process is developed by tailoring the organization’s standard service process according to a documented procedure. Z Refer to Activity 2 of the Organization Process Definition key process area for practices covering the contents of the organization’s standard service process.
This procedure typically specifies that: 1. The service’s defined service process is tailored to the service commitments at hand, the service delivery planning, and the types of IT components. 2. The description of the service’s defined service process is documented. Z Refer to Activity 2 of the Organization Process Definition key process area for practices covering the expected contents of a process definition. i The tailoring uses the organization’s process assets as appropriate.
102
The Key Process Areas for Level 3: Defined 3. Tailoring of the organization’s standard service process for the service is reviewed by the group responsible for coordinating the organization’s service process activities (e.g., service delivery process group) and approved by senior management. Z Refer to Activity 5 of the Organization Process Definition key process area for practices covering the library of service process-related documentation.
• Waivers for deviations from the organization’s standard service process are documented and are reviewed and approved by senior management. 4. Waivers for deviations from contractual service process requirements are documented and are reviewed and approved by senior management and the service’s customer, as appropriate. 5. The description of the service’s defined service process is managed and controlled. i ‘Managed and controlled’ implies that the work product adheres to organizational documentation standards, that the version of the work product in use at a given time (past or present) is known (i.e. version control), and that changes are incorporated in a controlled manner (i.e. change control). If a greater degree of control than is implied by ‘managed and controlled’ is desired, the work product can be placed under the full discipline of configuration management, as is described in the Configuration Management key process area.
Activity 2
Each service’s defined service process is revised according to a documented procedure. This procedure typically specifies that: 1. Changes derived from the following are documented and systematically reviewed: • lessons learned from monitoring the service activities of the organization’s services, • changes proposed by the service delivery group, and • service, process, and work product measurement data. 2. Changes to the service’s defined service process are reviewed and approved before they are incorporated. ` Examples of individuals who review the changes include: • members of the groups responsible for the organization’s service process activities (e.g., service process improvement group), • the service managers, and • the service delivery manager. ` Examples of individuals who approve the changes include: • the service manager, and • the service delivery manager.
6.4 Integrated Service Management Activity 3
103
The service’s service delivery plan, which describes the use of the service’s defined service process, is developed and revised according to a documented procedure. Z Refer to Activities 1 and 2 of the Service Delivery Planning key process area and Activities 1 and 2 of the Service Tracking and Oversight key process area for practices covering the service delivery plan.
Activity 4
The service delivery is managed in accordance with the service’s defined service process. Z Refer to the Service Delivery Planning and the Service Tracking and Oversight key process areas for basic practices covering managing service delivery.
The service’s defined service process typically specifies that: 1. Provisions are made for gathering, analyzing, and reporting measurement data needed to manage the service delivery. 2. The activities for service estimating, planning, and tracking are tied to the key tasks and work products of the service’s defined service process. 3. Documented criteria are defined to indicate when to replan the service delivery. 4. Technical and management lessons learned are documented and stored in the organization’s library of service process-related documentation. Z Refer to Activity 5 of the Organization Process Definition key process area for practices covering the organization’s library of service process-related documentation.
5. Technical and management lessons learned from monitoring the activities of other service deliveries in the organization are systematically reviewed and used to estimate, plan, track, and replan the service delivery. 6. The staffing plan addresses the service delivery’s needs for individuals with special skills and application domain knowledge. 7. Training needs are identified and documented to fit the specific needs of the service delivery. Z Refer to Activity 1 of the Training Program key process area for practices covering the identification of the service’s training needs.
8. The service delivery plans and processes followed in interacting with other people are adjusted to account for disparities with these groups and for other potential problems. ` Examples of disparities and problems include: • differences in process maturity, • process incompatibility, and • various business factors.
104 Activity 5
The Key Process Areas for Level 3: Defined The organization’s service process database is used for service planning and estimating. Z Refer to Activity 4 of the Organization Process Definition key process area for practices covering the organization’s service process database.
1. The database is used as a source of data to estimate, plan, track, and replan service delivery; data for similar services delivered before are used when possible. ` Examples of data contained in the organization’s service process database include: • planned and actual service levels, • size of service work products, • service delivery effort, • service delivery cost, • schedule, • staffing, and • technical activities.
2. Parameter values used to derive estimates for service delivery service levels, effort, cost, schedule and use of critical computer resources are compared to those of other services delivered to assess their validity. • Similarities and differences to the other services in terms of IT components and customer organization are assessed and recorded. • Rationales for similarities and differences between the parameter values are recorded. • The reasoning used to judge the credibility of the service delivery estimates is recorded. 3. Appropriate service planning data, replanning data, and actual measured data are provided for storage in the organization’s service process database. ` Examples of data recorded about the service delivery include: • the task description, • the assumptions, • the estimates, • the revised estimates, • the actual measured data, and • the associated information needed to reconstruct the estimates, assess their reasonableness, and derive estimates for new work.
Activity 6
The service delivery workload is managed according to a documented procedure.
6.4 Integrated Service Management
105
Z Refer to Activity 5 of the Service Delivery Planning key process area and Activity 8 of the Service Tracking and Oversight key process area for basic practices covering the planning and tracking of the service delivery workload.
This procedure typically specifies that: 1. A group that is independent of the service process improvement group reviews the procedures for estimating the size of the service delivery workload, and provides guidance in using historical data from the organization’s service process database to establish credible estimates. ` An example of an independent group is a service estimating group.
• The individuals who prepare the workload estimates ensure that the procedures and data used in the estimates are appropriate. • When the validity of a workload estimate is questioned, a team of peers and experts review the estimate. 2. A contingency factor is applied to the workload estimate for each service element identified as a service delivery risk. • The rationale for the contingency is documented. • The risks associated with reducing or eliminating the contingency are assessed and documented. 3. Reusable IT components for delivering the service are identified. 4. Factors which could significantly affect the size of the service delivery workload are identified and monitored closely. 5. A size threshold is established for workload element which, when projected to be exceeded, requires action. Z Refer to the Resource Management key process area.
Activity 7
The service delivery effort and costs are managed according to a documented procedure. Z Refer to Activity 6 of the Service Delivery Planning key process area and Activity 9 of the Service Tracking and Oversight key process area for basic practices covering planning and tracking service delivery efforts and costs.
This procedure typically specifies that: 1. Service delivery effort, cost, and staffing profile models, if used, are adapted to the service delivery and use available historical data where appropriate. 2. Referenced productivity and cost data are adjusted to incorporate service delivery variables.
106
The Key Process Areas for Level 3: Defined ` Examples of service delivery variables include: • the geographic locations of the service delivery groups and organizations (e.g., subcontractor), • the size and complexity of the service delivery, • the stability of the service commitments, • the stability of the service workload, • the availability of resources, and • other special constraints.
3. The overall service delivery effort and cost is allocated to individually managed tasks or stages as needed to manage the effort and cost effectively. 4. When the service delivery effort and cost status is reviewed and the estimates are revised, actual expenditures over time and against work completed are compared to the service delivery plan and used to refine the effort and cost estimates for remaining work. • Parameter values of the models used in estimating service delivery effort and costs are updated whenever major changes are made to the service commitments. • Actual data on service delivery productivity and other new service delivery costs are used where appropriate. 5. An effort and cost threshold is established for each individually managed service delivery task or stage which, when projected to be exceeded, requires action. Activity 8
The IT components critical for the delivery of the service are managed according to a documented procedure. Z Refer to the Resource Management key process area for practices covering the management of IT components.
Activity 9
The critical dependencies and critical paths of the service delivery schedule are managed according to a documented procedure. Z Refer to Activity 7 of the Service Delivery Planning key process area, Activity 10 of the Service Tracking and Oversight key process area, and Activity 4 of the Intergroup Coordination key process area for practices covering negotiating and tracking critical dependencies.
This procedure typically specifies that: 1. Milestones, tasks, commitments, critical dependencies, staffing, costs, and reviews are allocated in the schedule consistent with the service’s defined service process. • The service schedule identifies specific tasks and milestones whose completion can be objectively determined (i.e., a binary yes/no determination).
6.4 Integrated Service Management
107
i Different levels of schedule detail, appropriately tied to each other, are developed to accomodate the needs of different groups and individuals.
2. Critical dependencies are defined, negotiated, and reflected in the service delivery schedule. i Critical dependencies include both those within the service delivery group (i.e., between subgroups) and between the service delivery group and other affected groups.
3. Schedule critical paths are defined and reflected in the service delivery schedule. 4. Critical dependencies and schedule critical paths for service delivery are tracked on a regular basis. 5. Specific documented threshold criteria are established for each critical path which, when projected to be exceeded, requires action. ` Examples of actions include: • conducting analyses and simulations to tradeoff quality, cost, schedule, staffing, and other resources, • allocating contingencies and schedule slack, if available, • evaluating the effects of contemplated actions on all critical paths, and • making decisions visible to the affected groups.
Activity 10
The service delivery risks are identified, assessed, documented, and managed according to a documented procedure. Z Refer to Activity 8 of the Service Delivery Planning key process area and Activity 11 of the Service Tracking and Oversight key process area for basic practices covering identifying and tracking risk. ` Examples of service delivery risks that are to be managed include significant possibilities that the service delivery could fail to meet its objectives in areas such as: • schedule, • cost, • throughput or real-time performance, and • reliability or availability. ` Examples of activities to manage risks include: • early identification of high-risk service delivery objectives, • identification of incidents that could introduce or increase risks, and • close monitoring of key service delivery risk indicators.
This procedure typically specifies that:
108
The Key Process Areas for Level 3: Defined 1. A service delivery risk management plan is documented and used to identify and manage the service delivery risks. ` Examples of items in a service delivery risk plan include: • resources required (including staff and tools), • risk management methods (e.g., identification, analysis, prioritization, planning, monitoring, and resolution), • list of identified risks (including assessment, prioritization, status, and plans), • responsibilities and authorities, • method and frequency of communicating risk status and activities, and • measurements.
2. Contingency planning is based on the service’s defined service process and is performed throughout service delivery. ` Examples of areas covered by contingency planning activities include: • identification of options, • impact assessment of options, • technical feasibility of options, • allocation of management reserves, and • decision criteria on when to pursue an option.
3. Alternatives for each service delivery risk are identified, where possible, along with criteria for selecting among the alternatives. 4. The initial release and major revisions to the risk management plan undergo peer review. Z Refer to the Software CMM Peer Reviews key process area.
5. The service delivery risk management plan is managed and controlled. 6. Service delivery risks are tracked, reassessed, and replanned at designated risk checkpoints, and during the planning of significant changes that affect the service delivery. • Risk priorities and service delivery risk management plans are reviewed and revised at these reassessment points. • Information obtained from monitoring the risks is used to refine risk assessments and service delivery risk management plans. 7. The service delivery group and other affected groups and individuals are included in the communications on the service delivery risks, the service delivery risk management plans, and the results of risk mitigation.
6.4 Integrated Service Management
109
` Examples of affected groups and individuals include: • customer, • service subcontractors, • end users, • service estimating, • service testing, • service quality assurance group, • configuration management group, • contract management, and • documentation support.
Activity 11
Reviews of the service delivery are periodically performed to determine the actions needed to bring service delivery performance and results in line with the current and projected needs of the business, customer, and end users, as appropriate. ` Examples of actions include: • accelerating the schedule, • changing the service commitments in response to a change in market opportunities or customer and end user needs, and • terminating the service delivery. i The end users referred to in these practices are the customer-designated end users or representatives of the end users. Z Refer to Activities 6 and 7 of the Service Commitment Management key process area for practices covering the evaluation of service commitments and actual service delivery.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the effectiveness of the integrated service management activities. ` Examples of measurements include: • effort expended over time to manage the service delivery, compared to the plan • frequency, causes, and magnitude of replanning effort, • for each identified service delivery risk, the realized adverse impact compared to the estimated loss, and • the number and magnitude of unanticipated major adverse impacts to the service delivery, tracked over time.
110
The Key Process Areas for Level 3: Defined
Verifying Implementation Verification 1
The activities for managing the service delivery are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The activities for managing the service delivery are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
Verification 3
The service quality assurance group reviews and/or audits the activities and work products for managing the service delivery and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. The process for developing and revising the service’s defined service process. 2. The process for preparing the service’s service delivery plan and service delivery risk management plan. 3. The processes for managing the service delivery in accordance with the service’s defined service process. 4. The processes for collecting and providing appropriate data to the organization’s service process database. 5. The process for using the organization’s service process database to support the service delivery planning, estimating and tracking activities.
6.5
Service Delivery
Purpose The purpose of Service Delivery is to consistently perform a well-defined service process that integrates all the service activities to deliver correct and consistent IT services effectively and efficiently. Service Delivery involves performing the service activities to operate, manage and maintain the IT using the services’ defined service process (which is described in the Integrated Service Management key process area) and appropriate methods and tools. Documentation needed to perform the service delivery activities is developed and reviewed to ensure that each task addresses the result of predecessor tasks and the results produced are appropriate for the subsequent tasks. When changes are approved, affected work products, plans, commitments, processes, and activities are revised to reflect the approved changes.
6.5 Service Delivery
111
Goals Goal 1
The service delivery tasks are defined, integrated, and consistently performed to deliver the service.
Goal 2
Actual service delivery conforms to the service commitments.
Commitment to Perform Commitment 1
The organization follows a written organizational policy for performing the service delivery activities. This policy typically specifies that: 1. The service delivery tasks are performed in accordance with the service’s defined service process. Z Refer to Activity 1 and 2 of the Integrated Service Management key process area for practices covering the service’s defined service process.
2. Appropriate methods and tools are used to deliver the service. 3. The service delivery plans, tasks, and work products are traceable to the service commitments. Z Refer to the Service Commitment Management key process area for practices covering the management of service commitments.
Ability to Perform Ability 1
Adequate resources and funding are provided for performing the service delivery tasks. 1. Skilled individuals are available for performing the service delivery tasks, including: • acquisition of IT components, • monitoring IT components, • repairing IT components, • supporting users of IT components, and • replacing IT components. 2. Tools to support the service delivery tasks are made available.
112
The Key Process Areas for Level 3: Defined ` Examples of service delivery support tools include: • workstations, • database management systems, • online help aids, • graphics tools, • interactive documentation tools, • word processing systems. • network monitoring tools, • disk usage monitoring tools, • log file analyzing tools, • computer virus scanners, • back-up programs, and • user management programs.
Ability 2
Members of the service engineering technical staff receive required training to perform their technical assignments. i The members of the service engineering technical staff should receive training in the customer’s business domain. ` Examples of training include: • the customer’s business domain and business processes, • use of the tools selected for supporting service delivery, and • the design of the existing IT infrastructure.
Z Refer to the Training Program key process area.
Ability 3
Members of the service engineering technical staff receive orientation in related service engineering disciplines. ` Examples of related service engineering disciplines include: • corrective maintenance, • contingency management, and • end user support.
Z Refer to the Training Program key process area.
Ability 4
The service delivery manager and service group leaders receive orientation in the technical aspects of the service.
6.5 Service Delivery
113
` Examples of orientation include: • IT service methods and tools, • the customer’s business domain, and • guidelines on how to manage the service delivery using the chosen methods and tools.
Activities Performed Activity 1
Appropriate service delivery methods and tools are integrated into the service’s defined service process. Z Refer to Activities 1 and 2 of the Integrated Service Management key process area for practices covering the service’s defined service process.
1. The service delivery tasks are integrated according to the service’s defined service process. 2. Methods and tools appropriate for delivery of the service are selected. i Candidate methods and tools are selected based on their applicability to the organization’s standards, the service’s defined service process, the existing skill base, availability of training, contractual requirements, power, ease of use, and support services.
• The rationale for selecting a particular tool or methods is documented. 3. Configuration management models appropriate to the service to be delivered are selected and used. ` Examples of configuration management models include: • check-out/check-in models, • composition models, • transaction models, and • change set models.
4. The tools used to deliver the service are placed under configuration management. Z Refer to the Configuration Management key process area.
Activity 2
IT components are acquired according to the service’s defined service process. i IT components may need to be acquired to satisfy the service commitments. Acquiring IT components can entail buying components, developing components, composing components from separately acquired (sub)components, or a combination of the aforementioned.
114
The Key Process Areas for Level 3: Defined 1. IT components are acquired according to the service’s resource management plan. Z Refer to Activity 3 of the Resource Management key process area for practices covering the contents of the resource management plan.
2. IT components are assembled according to the service’s resource management plan. Z Refer to Activity 3 of the Resource Management key process area for practices covering the contents of the resource management plan.
3. Component acceptance criteria are developed and reviewed. ` Examples of component acceptance criteria include: • documentation on operating the component is present, • the component complies with specified interface standards, and • the capability to process a required volume of data.
4. A component intake environment is developed and maintained. 5. Component intake is planned and performed to demonstrate that the IT components satisfy the component acceptance criteria. Activity 3
IT components are released into their intended operating environment according to the service’s defined service process. 1. IT components are released according to a documented release plan, which is reviewed with and approved by, the customer and end users, as appropriate. The release plan covers: • type and contents of the release ` Examples of release types include: – full release, – delta release, and – package release.
• the overall release schedule and approach, • the roll-out plan, • responsibilities of the service organization, service subcontractors, customer, and end users, as appropriate, • back-out plans, • release acceptance criteria, • communication with affected groups, and • training schedule for affected groups.
6.5 Service Delivery
115 ` Examples of affected groups include: – end users, – service delivery group, – configuration management group, and – service request and incident management group.
2. The release plan is managed and controlled. 3. The release is assembled according to the release plan. • The release may consist of hardware, software, and documentation. 4. The release contents are verified against the release plan for release acceptance testing. 5. The contents of the release are distributed, installed and integrated into the production environment according to the release plan. 6. Changes to the production environment are administrated in the configuration management library system. Z Refer to Activity 6 of the Configuration Management key process area for practices covering changing the configuration baseline.
7. Release planning and actual releases are communicated with affected groups. 8. Affected groups and individuals are trained as appropriate. ` Examples of affected groups include: • end users, • service delivery group, • configuration management group, and • service request and incident management group.
Activity 4
IT components are operated in their intended operating environment according to the service’s defined service process. 1. IT components are operated according to their operational documentation. 2. IT components are started and stopped, as appropriate. 3. IT components are provided with input, as appropriate, according to their operational documentation. 4. Output of IT components is processed, as appropriate, according to their operational documentation.
Activity 5
IT components are monitored for proper functioning according to the service’s defined service process. 1. IT components are monitored using monitoring tools, as appropriate. Z Refer to Activity 5 of the Resource Management key process area for practices covering the monitoring of IT components.
116
The Key Process Areas for Level 3: Defined 2. Corrective action is taken as soon as measurement data exceeds earlier set limits. Z Refer to the Service Request and Incident Management key process area for practices covering the management of service requests and incidents. Z Refer to the Resource Management key process area for practices covering the management of IT components.
Activity 6
IT components are repaired when needed according to the service’s defined service process. i IT components that do not function according to the specified functional or quality requirements are repaired. Repair may mean providing a work-around, fixing a part of the IT component, replacing part of the IT component, or replacing the entire IT component.
1. Spare IT components are acquired. i Acquiring spare IT components can be done on demand or by means of a stock of components, as appropriate. Z Refer to Activity 2.
2. The failed IT component is retired. Z Refer to Activity 8.
3. The new IT component is released into the production environment. Z Refer to Activity 3.
Activity 7
IT components are upgraded when needed according to the service’s defined service process. 1. IT components to replace old IT components are acquired. i Acquiring new IT components can be done on demand or by means of a stock of components, as appropriate. Z Refer to Activity 2.
2. Migration of hardware products, software products or data used by the upgraded IT components is planned. 3. The IT component to be replaced is retired. Z Refer to Activity 8.
4. Any hardware product, software product or data used by the upgraded IT component is migrated to be suited for usage by the new IT component.
6.5 Service Delivery
117
5. The new IT component is released into the production environment. Z Refer to Activity 3.
Activity 8
IT components are retired when needed according to the service’s defined service process. 1. The IT component to be retired has been replaced by a new IT component taking over the functionality of the component to be retired, or the IT component to be retired is no longer in use. 2. The IT component is removed from the production environment. Z Refer to Activity 6 of the Configuration Management key process area for practices covering changing the configuration baseline.
Activity 9
Preventive maintenance of IT components is performed according to the service’s defined service process. i Preventive maintenance activities consist of taking preventive measures to guarantee effective and efficient repair of failed IT components. Furthermore, it includes taking measures to remove possible future causes of failures such as degrading performance.
1. Preventive maintenance activities are identified according to a failure analysis method. ` Examples of failure analysis methods include: • fault tree analysis, • flow charts, and • critical incident analysis.
2. Preventive maintenance activities are planned. • Preventive maintenance activities are scheduled to interfere as little as possible with normal operation. 3. Failures are simulated and repair activities are practiced to test the preventive measures and repair activities on both a periodic and an event-driven basis. 4. Preventive maintenance activities are reviewed and revised as necessary based on actual failures on both a periodic and an event-driven basis. Activity 10
Consistency is maintained across service delivery activities and service work products, including service commitments, service delivery plan, process descriptions, resource management plan, release plan, monitoring tools, and operational documentation. i Consistency is maintained across service delivery activities and service work products to meet the service commitments.
118
The Key Process Areas for Level 3: Defined 1. Service work products are documented, and the documentation is readily available. 2. The service delivery plan, resource management plan, release plan and other documents are traced to the source from which they were derived and to the products of subsequent service delivery activities. 3. The documentation tracing the service commitments through the service delivery plan, resource management plan, release plan and other documents is managed and controlled. 4. As understanding of the service improves, changes to the service work products, plans, process descriptions, and service delivery activities are proposed, analyzed, and incorporated as appropriate. • Impact of changes is determined before changes are made. • Where changes to the service commitments are needed, they are approved and incorporated before any service work products or service delivery activities are changed. Z Refer to the Service Commitment Management key process area for practices covering the management of service commitments.
• Changes to all service work products, plans, process descriptions, and service delivery activities are coordinated. • Changes are negotiated with and communicated to the affected groups. ` Examples of affected groups include: – service delivery group, – service request and incident management group, – configuration management group, and – service quality assurance group.
• Changes are tracked to completion.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the quality of the services delivered. Z Refer to the Service Tracking and Oversight key process area for practices covering the tracking of actual service delivery.
Measurement 2
Measurements are made and used to determine the status of the service delivery activities.
6.5 Service Delivery
119
` Examples of measurements include: • status of IT components, • incidents and problem reports by severity and length of time they are open, • change activity for all IT components, • effort to perform preventive maintenance activities, • effort and cost to implement and release incorporated changes, including initial estimate and actual effort and cost.
Verifying Implementation Verification 1
The service delivery activities are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The service delivery activities are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
Verification 3
The service quality assurance group reviews and/or audits the activities and work products for service delivery and report the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. Service commitments are reviewed to ensure that they are: • • • •
correct, consistent, feasible, and measurable.
2. Readiness and completion criteria for each service delivery task are satisfied. 3. IT components comply with the standards and requirements specified for them. 4. Required testing is performed. 5. Tests satisfy their acceptance criteria, as documented in the release planning. 6. Tests are satisfactorily completed and recorded.
120
6.6
The Key Process Areas for Level 3: Defined
Intergroup Coordination
Purpose The purpose of Intergroup Coordination is to establish a means for the service groups to participate actively with each other so service delivery is more likely to satisfy the customer’s needs effectively and efficiently. Intergroup Coordination involves the service delivery groups’ participation with other service groups to address the service commitments, service schedule and other issues. Representatives of the service groups participate in establishing the service commitments and plans by working with the customer and end users, as appropriate. These commitments and plans become the basis for all service activities. The technical working interfaces and interactions between groups are planned and managed to ensure the quality and integrity of all delivered services. Technical reviews and interchanges are regularly conducted with representatives of the service groups to ensure that all service groups are aware of the status and plans of all the groups and that service and intergroup issues receive appropriate attention.
Goals Goal 1
The service commitments are agreed to by all affected groups. i The service commitments are explicitly agreed to by all affected groups to ensure that the service commitments are realistic.
Goal 2
The commitments between the service groups are agreed to by the affected groups. i Internal commitments are agreed to by affected groups to ensure that the commitments are realistic, explicit, and known to all affected groups.
Goal 3
The service groups identify, track, and resolve intergroup issues. i Intergroup issues that occur during service delivery are identified, tracked, and resolved to reduce the risk of not meeting the service commitments to the customer.
Commitment to Perform Commitment 1
The service follows a written organizational policy for establishing interdisciplinary service teams. This policy typically specifies that: 1. The service commitments and service-level objectives for the service are defined and reviewed by all affected groups.
6.6 Intergroup Coordination
121
` Examples of affected groups include: • service delivery group, • service estimating, • service testing, • service quality assurance group, • configuration management group, • contract management, and • documentation support.
2. The service groups coordinate their plans and activities. 3. Managers are responsible for establishing and maintaining an environment to facilitate interaction, coordination, support, and teamwork between the service’s service groups, between the service groups and the customer or end users, as appropriate, and throughout the organization. i The end users referred to in these practices are the customer-designated end users or representatives of the end users.
Ability to Perform Ability 1
Adequate resources and funding are provided for coordinating the service delivery activities with other service groups.
Ability 2
The support tools used by the different service groups are compatible to enable effective communication and coordination. ` Examples of support tools that should be compatible include: • word processing systems, • database systems, • graphics tools, • spreadsheet programs, • incident tracking tools, • problem tracking packages, and • library management tools.
Ability 3
All managers in the organization receive required training in teamwork. ` Examples of training include: • building teams, • managing teams, • establishing, promoting, and facilitating teamwork, and • group dynamics.
122
The Key Process Areas for Level 3: Defined Z Refer to the Training Program key process area.
Ability 4
All task leaders in each service group receive orientation in the processes, methods, and standards used by the other service groups. Z Refer to the Training Program key process area.
Ability 5
The members of the service groups receive orientation in working as a team. Z Refer to the Training Program key process area.
Activities Performed Activity 1
The service delivery group and the other service groups participate with the customer and end users, as appropriate, to establish the service commitments. Specifically, these groups: 1. Define the critical characteristics of the customer’s and end users’ requirements, as appropriate. 2. Negotiate critical dependencies. 3. Document the acceptance criteria for each service delivered to the customer or end user, as appropriate.
Activity 2
Representatives of the service delivery group work with representatives of other service groups to monitor and coordinate technical activities and resolve technical issues. 1. The representatives of these groups monitor and coordinate technical activities by: • providing the technical review and analysis needed to manage and control changes to the service commitments and service delivery plan. • providing the technical review and analysis needed to manage and control changes to the production environment. Z Refer to Activity 6 of the Configuration Management key process area for practices covering change management.
• assessing, developing recommendations for, and tracking technical risks that involve more than one service group. Z Refer to Activity 10 of the Integrated Service Management key process area for practices covering risk management.
2. The representatives of the groups handle technical issues by: • resolving technical conflicts and clarifying technical issues.
6.6 Intergroup Coordination
123
• developing joint recommendations to resolve problems. • addressing process issues that span multiple service groups. Activity 3
A documented plan is used to communicate intergroup commitments and to coordinate and track the work performed. This plan is: 1. The baseline for: • the service delivery schedule, • the contractual and technical aspects of the service, and • the assignment of responsibilities to the service groups. 2. Used to coordinate activities between the different service groups. 3. Readily available to the members of all service groups. 4. Updated to incorporate all intergroup commitments and changes to these commitments. 5. Updated as the work progresses to reflect progress and plan changes at the service level, particularly when plans change significantly. 6. Reviewed and agreed to by all service groups and the service delivery manager.
Activity 4
Critical dependencies between service groups are identified, negotiated, and tracked according to a documented procedure. Z Refer to the Activity 9 of the Integrated Service Management key process area for practices covering management of critical dependencies.
This procedure typically specifies that: 1. Each critical dependency is explicitly defined, including: • • • •
the item to be provided, who will provide it, when it will be provided, and the acceptance criteria.
2. Critical dependencies are negotiated between the service delivery group and other service groups involved in the service and organization. 3. Need dates and availability dates of critical dependency items are tied to the service delivery schedule. 4. The agreement for each critical dependency is documented, reviewed, and approved by both the receiving group and the group responsible for providing the critical dependency item. 5. Cricital dependencies are tracked on a regular basis and corrective actions are taken when appropriate.
124
The Key Process Areas for Level 3: Defined • Status and actual or projected completion are compared to the plan used to coordinate intergroup commitments. • Effects of late and early completions are evaluated for impacts on future activities and milestones. • Actual and potential problems are reported to the appropriate managers.
Activity 5
Work products produced as input to other service groups are reviewed by representatives of the receiving groups to ensure that the work products meet their needs and conform to the standards and criteria used by the other groups.
Activity 6
Intergroup issues not solvable by the individual representatives of the service groups are handled according to a documented procedure. ` Examples of intergroup issues include: • incompatible schedules, • inadequate funding, • technical risks, and • deviation from agreed to service levels.
Activity 7
Representatives of the service groups conduct periodic technical reviews and interchanges. In these meetings, the participants: 1. Provide visibility of the needs and desires of the customer and end users, as appropriate. 2. Monitor the technical activities of the service, 3. Ensure that the groups’ interpretation and delivery of the service conform to the service commitments agreed upon. 4. Review the service commitments and internal commitments to determine whether they are being met. Z Refer to the Service Tracking and Oversight key process area for practices covering the tracking of actual service delivery.
5. Review the technical risks and other technical issues. Z Refer to Activity 10 of the Integrated Service Management key process area for practices covering risk management.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the intergroup coordination effectiveness of the intergroup coordination activities.
6.7 Training Program
125
` Examples of measurements include: • actual effort and other resources expended by the service delivery group for support to other service groups, • actual effort and other resources expended by the other service groups in support of the service delivery group, • actual completion of specific tasks and milestones by the service delivery group to support the activities of other service groups, and • actual completion of specific tasks and milestones by the other service groups to support the activities of the service delivery group.
Verifying Implementation Verification 1
The activities for intergroup coordination are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The activities for intergroup coordination are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
Verification 3
The service quality assurance group reviews and/or audits the activities and work products for intergroup coordination and reports the results. Z Refer to the Service Quality Assurance key process area. i The service quality assurance responsibilities for this key process area may be subsumed into a quality assurance function that covers all the service delivery groups.
At a minimum, the reviews and/or audits verify: 1. The procedure for identifying, negotiating, and tracking critical dependencies between the service groups. 2. The handling of intergroup issues.
6.7
Training Program
Purpose The purpose of the Training Program key process area is to develop the attitude, skills, and knowledge of individuals so they can perform their roles effectively and efficiently.
126
The Key Process Areas for Level 3: Defined
Training Program involves first identifying the training needed by the organization, services, and individuals, then developing or procuring training to address the identified needs. For each service, the current and future skill needs are evaluated and it is determined how these skills will be obtained. Some skills are best imparted through informal vehicles (e.g. on-the-job training and informal mentoring), whereas other skills need more formal training vehicles (e.g. classroom training and guided self-study) to be effectively and efficiently imparted. The appropriate vehicles are selected and used.
Goals Goal 1
Training activities are planned.
Goal 2
Training for developing the skills and knowledge needed to perform service management and technical roles is provided.
Goal 3
Individuals in the service delivery group and service-related groups receive the training necessary to perform their roles.
Commitment to Perform Commitment 1
The organization follows a written organizational policy for meeting its training needs. This policy typically specifies that: 1. The needed skills and knowledge for each service management and technical role are identified. 2. Training vehicles for imparting skills and knowledge are identified and approved. ` Examples of training vehicles include: • classroom training, • computer-aided instruction, • guided self-study, • formal apprenticeship and mentoring programs, and • facilitated media.
3. Training is provided to build the skill base of the organization, to fill the specific needs of the services, and to develop the skills of the individuals. 4. Training is developed withing the organization or obtained from outside the organization when appropriate.
6.7 Training Program
127 ` Examples of external sources of training include: • customer-provided training, • commercially available training courses, • academic programs, • professional conferences, and • seminars.
Ability to Perform Ability 1
A group responsible for fulfilling the training needs of the organization exists. i The members of the training group may include full-time or part-time instructors drawn from the organization; the members may also be drawn from external resources.
Ability 2
Adequate resources and funding are provided for implementing the training program. ` Examples of training program elements include: • the organization’s training plan, • training materials, • development or procurement of training, • conduct of training, • training facilities, • evaluation of training, and • maintaining records of training.
1. A manager is designated to be responsible for implementing the organization’s training program. 2. Tools to support the training program activities are made available. ` Examples of support tools include: • workstations, • instructional design tools, • database programs, and • packages for developing presentation materials.
3. Appropriate facilities are made available to conduct training. i Classroom training facilities should be separated from the students’ work environment to eliminate interruptions. Where appropriate, training is conducted in settings that closely resemble actual performance conditions and include activities to simulate actual work situations.
128 Ability 3
The Key Process Areas for Level 3: Defined Members of the training group have the necessary skills and knowledge to perform their training activities. ` Examples of ways to provide these skills and knowledge include: • training in instructional techniques, and • refresher training in the subject matter.
Ability 4
Service managers receive orientation on the training program.
Activities Performed Activity 1
For each service, a training plan is developed and maintained that specifies the training needs for that service. The plan covers: 1. The set of skills needed and when those skills are needed. 2. The skills for which training is required and the skills that will be obtained via other vehicles. i Some skills are effectively and efficiently imparted through informal vehicles (e.g., informal training and presentations, reading books and journals, ”chalk talks”, brown-bag lunch seminars, on-the-job training, and informal mentoring); while other skills, to be effectively and efficiently imparted, need to be based on more formal training vehicles (e.g., classroom training, computeraided instructions, guided self-study, facilitated media, and formal apprenticeship and mentoring programs).
3. The training that is required, for whom it is required, and when it is required. Z Refer to the Ability to Perform common feature in all other key process areas for examples of specific training needs. i Where appropriate, training for individuals is tied to their work responsibilities, so that on-the-job activities or other outside experiences will reinforce the training within a reasonable time after the training.
4. How training will be provided. i Training may be provided by the service delivery group, by the organization’s training group, or by an external organization. ` Examples of training appropriately done by the service delivery group include: • training in specific techniques and requirements of the service, and • training in the specific configuration of IT components.
Activity 2
The organization’s training plan is developed and revised according to a documented procedure. This procedure typically specifies that:
6.7 Training Program
129
1. The plan uses the services’ training needs identified in the services’ training plans. 2. The specific training to be provided is identified based on the skills needed by the organization and when those skills are needed. 3. The organization’s training plan is revised, as appropriate, to incorporate changes. 4. The organization’s training plan is reviewed by the affected individuals when it is initially released and whenever major revisions are made. ` Examples of affected individuals include: • senior management, • service managers, • managers of service-related groups.
5. The organization’s training plan is managed and controlled. i ‘Managed and controlled’ implies that the work product adheres to organizational documentation standards, that the version of the work product in use at a given time (past or present) is known (i.e. version control), and that changes are incorporated in a controlled manner (i.e. change control). If a greater degree of control than is implied by ‘managed and controlled’ is desired, the work product can be placed under the full discipline of configuration management, as is described in the Configuration Management key process area.
6. The organization’s training plan is readily available to the affected groups and individuals. ` Examples of affected groups and individuals include: • senior management, • the training group, • the managers of service-related groups, • service delivery group (including all subgroups, such as maintenance personnel), • service estimating, • service quality assurance group, • configuration management group, • contract management, and • documentation support.
Activity 3
The training for the organization is performed in accordance with the organization’s training plan. This plan covers: 1. The specific training needed within the organization and when it is needed. 2. The training that will be obtained from external sources and training that will be provided by the training group.
130
The Key Process Areas for Level 3: Defined 3. The funding and resources (including staff, tools, and facilities) needed to prepare and conduct or procure the training. 4. Standards for instructional materials used in training courses developed by the training group. 5. The schedule for developing and revising the training courses that will be developed by the training group. 6. The schedule for conducting the training, based on the projected need dates and the projected number of students. 7. The procedures for: • • • •
Activity 4
selecting the individuals who will receive the training, registering and participating in the training, maintaining records of the training provided, and collecting, reviewing, and using training evaluations and other training feedback.
Training courses prepared at the organization level are developed and maintained according to organization standards. These standards require that: 1. A description of each training course is developed. 2. Prior knowledge for each training course is determined. ` Examples of the topics addressed by the description include: • intended audience, • preparation for participating, • training objectives, • length of the training, • lesson plans, • criteria for determining the students’ satisfactory completion, • procedures for periodically evaluating the effectiveness of the training, and • special considerations, such as piloting and field testing the training course, needs for refresher training, and opportunities for follow-up training.
3. The materials for the training course are reviewed. ` Examples of individuals who review the training materials include: • instructional experts, • subject matter experts, and • representative students from pilot sessions of the training course being reviewed.
4. The materials for the training courses are managed and controlled.
6.7 Training Program
131
Activity 5
A waiver procedure for required training is established and used to determine whether individuals already possess the knowledge and skills required to perform in their designated roles.
Activity 6
Records of training are maintained. 1. Records are kept of all students who successfully complete each training course or other approved training activity. 2. Records are kept of all students who successfully complete their designated required training. 3. Records of successfully completed training are made available for consideration in assignments of the staff and managers.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the training program activities. ` Examples of measurements include: • actual attendance at each training course compared to the projected attendance, • progress in providing training courses compared to the organization’s and service’s training plans, and • number of training waivers approved over time.
Measurement 2
Measurements are made and used to determine the quality of the training program. ` Examples of measurements include: • results of post-training tests, • reviews of the courses from the students, and • feedback from the service managers.
Verifying Implementation Verification 1
The training program activities are reviewed with senior management on a periodic basis. i The primary purpose of periodic reviews by senior management is to provide awareness of, and insight into, service process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
132
The Key Process Areas for Level 3: Defined
Verification 2
The training program is independently evaluated on a periodic basis for consistency with, and relevance to, the organization’s needs.
Verification 3
The training program activities and work products are reviewed and/or audited and the results are reported. At a minimum, the reviews and/or audits verify: 1. The process for developing and revising the organization’s training plan is followed. 2. The process for developing and revising a training course is followed. 3. Training records are properly maintained. 4. Individuals designated as requiring specific training complete that training. 5. The organization’s training plan is followed.
6.8
Resource Management
Purpose
The purpose of Resource Management is to provide proactive organization-wide management
L23-0.1/17
of IT resources needed to provide the IT services. This means that based on the service catalog resources are established (such as network infrastructure and computing capacity). Before service commitments are made to the customer, the needed resources are checked. If not enough resources are available, either the service commitments are adapted or extra resources are installed. During service delivery, the amount and availability of resources is tracked to ensure that enough capacity is available to deliver the IT services.
Goals Goal 1
Resource management activities are planned. i Resource management activities need to be planned to ensure sufficient effort and attention is given to them, particularly to proactive resource management activities.
Goal 2
The amount and availability of resources needed for each service delivered is identified, planned, and tracked.
Goal 3
Affected groups and individuals are informed of the status of resources.
Commitment to Perform Commitment 1
The organization follows a written organizational policy for implementing resource management (RM). This policy typically specifies that:
6.8 Resource Management
133
1. Responsibility for RM is explicitly assigned. 2. RM is implemented across services. 3. All IT components are monitored and measured. 4. A repository for storing information regarding resources is made available. 5. Both proactive and reactive actions are taken to manage the available resources to ensure that the delivery of each service meets the commitments.
Ability to Perform Ability 1
A group that is responsible for coordinating and implementing RM for the organization (i.e., the RM group) exists. The RM group coordinates and implements: 1. Creation and management of the organizations resource repository. 2. Development, maintenance and distribution of the RM plans, standards, and procedures. 3. Management of access to the resource repository. 4. Changes to the resource repository. 5. Recording of RM activities. 6. Production and distribution of RM reports.
Ability 2
Adequate resources and funding are provided for implementing the resource management activities. 1. A manager is assigned specific responsibility for RM. 2. Tools to support the RM activities are made available.
Ability 3
Members of the RM group and related groups receive required training to perform their activities. ` Examples of related groups include: • the service delivery group, • the service quality assurance group, and • the configuration management group. ` Examples of training include: • identifying resources that are needed based on the service commitments, and • the standards, procedures, and methods to be followed for RM activities.
134
The Key Process Areas for Level 3: Defined
Activities Performed Activity 1
The organization’s RM plan is developed and revised according to a documented procedure. i The purpose of the organization’s RM plan is to gain insight in the status of resources used organization-wide across different services delivered and to predict future resource utilization.
This procedure typically specifies that: 1. The organization’s resource management plan covers all standard services of the IT service provider. 2. The organization’s resource management plan is reviewed by affected groups. 3. The organization’s resource management plan is managed and controlled. Activity 2
A RM plan is developed for each service according to a documented procedure. This procedure typically specifies that: 1. The RM plan is developed in the early stages of, and in parallel with, the development of a standard service. 2. The RM plan is reviewed by affected groups. 3. Changes to the RM plan occur both periodically and event-driven. 4. The RM plan is managed and controlled.
Activity 3
A documented and approved resource management plan is used as the basis for performing the RM activities. The plan covers: 1. The resources to be monitored for a service. Z Refer to Activity 5 for practices covering the monitoring of resources.
2. Resource-related data on the service processes. i These data may be obtained from the service process database. Z Refer to Activity 4 of the Organization Process Definition key process area for practices covering the organization’s service process database.
3. Forecasts of changes in resources necessary to deliver the service. 4. Options for service delivery improvement are explored periodically and the benefits are documented. Activity 4
A resource management library system is established as a repository for information on the resources. This library system:
6.8 Resource Management
135
1. Provides for the storage, update, and retrieval of resource-related information. 2. Provides for the sharing and transfer of resource-related information between affected groups. 3. Should contain a subset of the information stored in the configuration management library system. 4. Helps in the use of resource management procedures. 5. Supports production of RM reports. i The resource management library system may be combined with the configuration management library system.
Activity 5
Resources are identified, recorded, and tracked according to a documented procedure. This procedure typically specifies that: 1. For each service, the number of IT components needed to provide sufficient resources is identified. The amount of resources necessary to deliver the service is negiotiated with the service delivery manager. Z Refer to Activity 1 of the Service Commitment Management key process area for practices covering the IT service needs.
2. The IT components are placed under configuration management. Z Refer to Activity 4 of the Configuration Management key process area.
3. For each resource, alternatives to increase the resource capacity are identified, along with criteria for selecting among the alternatives. 4. For each service delivered, a usage threshold for each resource involved in the service delivery is determined. 5. Tuning activities are identified for each resource and predictions of their likely effect are recorded. ` Examples of tuning activities include • balancing workloads, • changing database storage techniques, and • duplicating servers in order to increase computing power.
6. The resources are monitored throughout the delivery of the standard services. 7. Action items resulting from the monitoring results are: • identified, • assessed for risk,
136
The Key Process Areas for Level 3: Defined • • • • • •
Activity 6
documented, planned, initiated, communicated to the affected groups and individuals, tracked to closure, and evaluated.
Resource management activities are performed both proactively and reactively. ` Examples of proactive resource management activities include: • trend analysis, and • periodically obtaining other information that will benefit the amount and availability of resources. i Reactive RM activities are performed when incidents regarding IT components occur or when service commitments are negotiated.
Activity 7
Affected groups and individuals are informed of the status of resources on both a periodic and an event-driven basis. ` Examples of affected groups and individuals include: • configuration management group, • service delivery group, and • service delivery manager.
Activity 8
Standard reports documenting the RM activities and the contents of the resource repository are developed and made available to affected groups and individuals. ` Examples of reports include: • short-, medium-, and long-term trends in resource usage, broken down by hardware platform, • actions undertaken to free or obtain resources, and • summary of resources whose usage limit was exceeded.
Activity 9
Resource repository audits are conducted according to a documented procedure. This procedure typically specifies that: 1. There is adequate preparation for the audit. 2. The integrity of the resource repository is assessed.
6.8 Resource Management
137
3. The facilities of the resource management library system are reviewed. 4. The completenes and correctness of the respository are verified. 5. Compliance with applicable RM standards and procedures is verified. 6. The results of the audit are reported to the service delivery managers. 7. Action items from the audit are tracked to closure.
Measurement and Analysis Measurement 1
Measurements made are used to determine the status of the resources in the resource repository. ` Examples of measurements include: • the number of resources whose usage limit is exceeded, • the utilisation of all IT components is being recorded in the resource repository, and • the average time needed to resolve the exceeded resource usage.
Measurement 2
Measurements are made and used to determine the status of the RM activities. ` Examples of measurements include: • the number of resources monitored per unit time, and • the effort expended in the RM activities.
Verifying Implementation Verification 1
The RM activities are reviewed with senior management on a periodic basis. i The primary purpose of periodic reviews by senior management is to provide awareness of, and insight into, service process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The RM activities are reviewed with the service manager on on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
138
The Key Process Areas for Level 3: Defined
Verification 3
The RM group periodically audits resource repositories to verify that they conform to the documentation that defines them. Z Refer to Activity 9 for practices covering the auditing of resource repositories.
Verification 4
The service quality assurance group reviews and/or audits the organization’s RM activities and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. The process for developing and revising the organization’s resource management plan is followed. 2. The process for making changes to IT components in order to conform to the availability and amount of resources is followed. 3. The organization’s resource management plan is followed.
6.9
Problem Management
Purpose The main purpose of the key process area Problem Management is to identify and resolve underlying causes of service requests and incidents and to prevent them from occuring. Problem management activities are both reactive and proactive. Reactive activities include the investigation of the root cause of service requests and incidents. Proactive activities include the monitoring of IT components in order to prevent incidents from occuring and to anticipate service requests.
Goals Goal 1
Problem management activities are planned. i Problem management activities need to be planned to ensure sufficient effort and attention is given to them, particularly to proactive problem management activities.
Goal 2
Problems are identified, recorded, analyzed, tracked, and resolved. i Note that not all problems are necessarily removed. Analysis might show that the solution for a certain problem is too expensive. Consequently, the organization may decide to resolve the problem by dealing with the resulting incidents instead of removing the problem.
Goal 3
Affected groups and individuals are informed of the status of problems and action items.
6.9 Problem Management
139
Commitment to Perform Commitment 1
A written organizational policy is followed for implementing problem management (PM). This policy typically specifies that: 1. Responsibility for PM is explicitly assigned. 2. PM is implemented across services. 3. A repository for storing problem information is made available. 4. The problem repository and problem management activities are audited on a periodic basis. 5. Both proactive and reactive actions are taken to perform problem management activities.
Ability to Perform Ability 1
A group that is responsible for coordinating and implementing PM for the organization (i.e., the PM group) exists. The PM group coordinates or implements: 1. Creation and management of the organization’s problem repository. 2. Development, maintenance, and distribution of PM plans, standards, and procedures. 3. Management of access to the problem repository. 4. Changes to the problem repository. 5. Recording of PM activities. 6. Production and distribution of PM reports.
Ability 2
Adequate resources and funding are provided for performing the problem management activities. 1. A manager is assigned specific responsibility for PM. 2. Tools to support the PM activities are made available. ` Examples of support tools include: • workstations and/or portable computers, • problem management software.
Ability 3
Members of the PM group and related groups are trained in the objectives, procedures, and methods for performing their PM activities.
140
The Key Process Areas for Level 3: Defined ` Examples of related groups include: • service request and incident management group, • service quality assurance group, • configuration management group, and • service delivery group. ` Examples of training include: • the standards, procedures, and methods to be followed for PM activities, and • the role, responsibilities, and authority of the PM group.
Activities Performed Activity 1
The organization’s PM plan is developed and revised according to a documented procedure. This procedure typically specifies that: • The organization’s PM plan covers the problem management activities performed across different services. • The organization’s PM plan is reviewed by affected groups. • The organization’s PM plan is managed and controlled.
Activity 2
A PM plan is prepared for each service according to a documented procedure. This procedure typically specifies that: 1. The PM plan is developed in the early stages of, and in parallel with the development of a standard service. 2. The PM plan is reviewed by affected groups. 3. The PM plan is managed and controlled.
Activity 3
A documented and approved problem management plan is used as the basis for performing the PM activities. The plan covers: 1. Estimates of the problem workload. 2. The PM activities to be performed, the schedule of the activities, the assigned responsibilities, and the resources required (including staff, tools, and computer facilities).
Activity 4
A problem management library system is established as a repository for the problem records. This library system:
6.9 Problem Management
141
1. Provides for the storage, update, and retrieval of problem records. 2. Provides for the sharing and transfer of problem records between affected groups. 3. Helps in the use of problem management procedures. Z Refer to Activity 5.
4. Provides for the archival and retrieval of historic problem information. 5. Supports production of PM reports. i The problem management library system may be combined with the service request and incident management library system.
Activity 5
Problems are identified, recorded, analyzed, reviewed, and resolved according to a documented procedure. This procedure typically specifies that: 1. Problems are identified based on periodic and event-driven analysis of service requests and incidents. Z Refer to the Service Request and Incident Management key process area for practices covering the management of service requests and incidents.
2. The problems are recorded in sufficient detail so that the content and the status of each problem are known. This typically includes: • • • • •
a unique identifier, description of the problem, related incidents or service requests, the configuration items concerned, and problem classification.
3. The category of the problem is determined and documented. Possible categories include: • Non-CI (configuration item) causes: human error, procedure failure, • CI (configuration item) causes: application, tools, system software, computer hardware, networking hardware. 4. The impact of the problem to the service commitments is assessed and documented. 5. The urgency of the problem is assessed and documented. 6. The priority of the problem is established and documented. i Urgency is not the same as priority. The urgency of a problem is the extent to which resolution of a problem can bear delay. The priority indicates the relative priority in which a series of problems should be addressed. The priority is established based on risk, resource availability, urgency and impact.
142
The Key Process Areas for Level 3: Defined 7. The problem is analysed and diagnosed. ` Examples of problem analysis and diagnosis methods include: • Ishikawa (’fishbone’) diagrams, • brainstorming sessions, • flowcharts methods, and, • fault tree analysis.
8. Action items resulting from problem analysis and diagnosis are: • identified, • assessed for risk, • documented, • planned, • initiated, • communicated to affected groups and individuals, • tracked to closure, and • evaluated.
If the action item involves configuration items, appropriate actions are taken
Rephrased
by the CM group. Z Refer to the Configuration Management key process area for practices covering the management of configuration baselines.
Activity 6
Problem management activities are performed both proactively and reactively. ` Examples of proactive problem management activities include: • trend analysis of incidents, • trend analysis of service requests, • periodically obtaining other information that will benefit the problem management activities, and • monitoring IT components in order to prevent incidents or service requests from occuring.
i Reactive problem management activities are performed based on the occurence of service requests and incidents.
Activity 7
Affected groups and individuals are informed of the status of problems on both a periodic and an event-driven basis.
6.9 Problem Management
143
` Examples of affected groups and individuals include: • service request and incident management group, • configuration management group, • service delivery group, • service delivery manager, • end users.
Activity 8
Standard reports documenting the PM activities and the contents of the problem repository are developed and made available to affected groups and individuals. ` Examples of PM reports include: • problem description and status, • action item description and status, • summary of problem by configuration item, • summary of problems during a certain period.
Activity 9
Problem repository audits are conducted according to a documented procedure. This procedure typically specifies that: 1. There is adequate preparation for the audit. 2. The integrity of the problem repository is assessed. 3. The facilities of the problem management library system are reviewed. 4. The completeness and correctness of the repository are verified. 5. Compliance with applicable PM standards and procedures is verified. 6. The results of the audit are reported to the service delivery managers. 7. Action items from the audit are tracked to closure.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the problems in the problem repository. ` Examples of measurements include: • number of problems unresolved, • average leadtime of closed problems,
Measurement 2
Measurements are made and used to determine the status of the PM activities.
144
The Key Process Areas for Level 3: Defined ` Examples of measurements include: • number of problems processed per unit time, • number of action items completed per unit time, • effort expended and funds expended in the PM activities.
Verifying Implementation Verification 1
The PM activities are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The PM activities are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
Verification 3
The PM group periodically audits problem repositories to verify that they conform to the documentation that defines them.
Verification 4
The service quality assurance group reviews and/or audits the PM activities and work products and reports the results. Z Refer to the Service Quality Assurance key process area.
Chapter 7
The Key Process Areas for Level 4: Managed 7.1
Quantitative Process Management
New key
process area
Purpose
The purpose of the key process area Quantitative Process Management is to control the performance of the service delivery processes quantitatively. Service process performance represents the actual results achieved from following a service process. Quantitative Process Management involves establishing goals for the performance of the service’s defined service process, which is described in the Integrated Service Management key process area, taking measurements of the process performance, analyzing these measurements, and making adjustments to maintain process performance within acceptable limits. When the process performance is stabilized within acceptable limits, the service’s defined service process, the associated measurements, and the acceptable limits for the measurements are established as a baseline and used to control process performance quantitatively. The organization collects process performance data from the services delivered and uses these data to characterize the process capability (i.e., the process performance one can expect for the delivery of standard services) of the organization’s standard service process, which is described in the Organization Process Definition key process area. Process capability describes the range of expected results from following a service process (i.e. the most likely outcomes that are expected from the next delivery of the service). These process capability data are, in turn, used by the service delivery groups to establish and revise their process performance goals and to analyze the performance of the service’s defined service process.
Goals Goal 1
The quantitative process management activities are planned. 145
146
The Key Process Areas for Level 4: Managed
Goal 2
The process performance of the service’s defined service process is controlled quantitatively.
Goal 3
The process capability of the organization’s standard service process is known in quantitative terms.
Commitment to Perform Commitment 1
A written organizational policy is followed for measuring and quantitatively controlling the performance of the service’s defined service process. This policy typically specifies that: 1. For each service delivered a documented plan is implemented to bring the service’s defined service process under quantitative control. i The term ”quantitative control ” implies any quantitative or statistically based technique appropriate to analyze a service process, identify special causes of variantions in the performance of the service process, and bring the performance of the service process within well-defined limits. A special cause of variation is some transient circumstance (such as a specific local condition, a single machine, a single individual, or a small group of people performing in an unexpected way) that causes an unexpected, transient change in the process performance.
2. Sensitive data relating to individuals’ performances are protected, and access to these data is appropriately controlled. i Use of measurement data to evaluate individuals will negatively affect the correctness and usefulness of the measurement data that are reported.
Commitment 2
The organization follows a written policy for analyzing the process capability of the organization’s standard service process. This policy typically specifies that: 1. The service delivery measurements of process performance are analyzed to establish and maintain a process capability baseline for the organization’s standard service process. i The process capability baseline includes: • the description of the organization’s standard services and standard service process, • the standard definitions of the measurements, and • the expected range of values for the measurements.
2. The process capability baseline for the organization’s standard service process is used by the service delivery groups in establishing their process performance goals.
7.1 Quantitative Process Management
147
Ability to Perform Ability 1
A group that is responsible for coordinating the quantitative process management activities for the organization exists. 1. Either this group is part of the group responsible for the organization’s service process activities (e.g., service process improvement group) or its activities are closely coordinated with that group.
Ability 2
Adequate resources and funding are provided for the quantitative process management activities. 1. The managers and task leaders of the service delivery groups and other service-related groups perform the service’s quantitative process management activities. ` Examples of service-related groups include: • service quality assurance group, • configuration management group, and • service request and incident management group.
2. An organization-wide measurement program exists. i The organization’s measurement program includes: • the definition of the organization-wide measurements, • the collection of the organization’s measurement data, • the analysis of the organization’s measurement data, and • the quantitative measurement goals for the organization.
3. Tools to support quantitative process management are made available. ` Examples of support tools include: • helpdesk support tools, • network monitoring tools, • transaction monitoring software, • quantitative analysis packages, and • problem-tracking packages.
Ability 3
Support exists for collecting, recording, and analyzing data for selected process, service and product measurements. i The service and product data referred to in these practices are service and product measurements used in analyzing the service process.
Ability 4
The individuals implementing or supporting quantitative process management receive required training to perform these activities.
148
The Key Process Areas for Level 4: Managed ` Examples of training include: • modeling and analyzing the service process, • selecting, collecting, and validating the process measurement data, and, • applying basic quantitative methods and analysis techniques (e.g., estimation models, Pareto diagrams, and control charts). Z Refer to the Training Program key process area.
Ability 5
The members of the service delivery group and other service-related groups receive orientation on the goals and value of quantitative process management. Z Refer to the Training Program key process area.
Activities Performed Activity 1
The quantitative process management plan for the service delivery is developed according to a documented procedure. This procedure typically specifies that: 1. The quantitative process management plan is based on: • the organization’s strategic goals for service quality, costs, productivity, and service responsiveness, • the organization’s measurement program, • the organization’s standard service process, • the service’s goals for service quality, costs, productivity, and responsiveness, • the measured performance of other service’s defined service processes, and • the description of the service’s defined service process. 2. The plan undergoes peer review. Z Refer to the Software CMM Peer Reviews key process area.
3. The plan is reviewed by the group responsible for the organization’s service process activities (e.g., the service process improvement group). 4. The plan is managed and controlled. Activity 2
The quantitative process management activities are performed in accordance with the service delivery’s quantitative process management plan. The plan covers: 1. The goals and objectives of the quantitative process management activities.
7.1 Quantitative Process Management
149
2. The service delivery tasks or other service activities that will be measured and analyzed. 3. The instrumentation of the service’s defined service process. i The instrumentation is based on the organization’s measurement program, the description of the organization’s standard service process, and the description of the service’s defined service process.
4. The quantitative process management activities to be performed and the schedule for these activities. i In addition to current organizational and service needs, measurements that may be useful to future efforts are included.
5. The groups and individuals responsible for the quantitative process management activities. 6. The resources required to perform the quantitative process management activities, including staff and tools. 7. The procedures to be followed in performing the quantitative process management activities. Activity 3
The strategy for the data collection and the quantitative analyses to be performed are determined based on the service’s defined service process. The attributes of the service’s defined service process that are considered include: 1. The service work products and their relationships to each other and to the service’s defined service process. 2. The tasks, the activities, and their relationships to each other. 3. The process control points and data collection points.
Activity 4
The measurement data used to control the service’s defined service process quantitatively are collected according to a documented procedure. This procedure typically specifies that: 1. The measurement data collected support the organization’s and the service delivery measurement goals and objectives. 2. The specific measurement data to be collected, their precise definitions, the intended use and analysis of each measurement, and the process control points at which they will be collected are defined.
150
The Key Process Areas for Level 4: Managed ` Examples of measurement data include: • estimated/planned versus actual data on service quality levels, • productivity data, • quality measurements as defined in the service quality plan, • effectiveness of training, • test coverage and efficiency, • software availability measures, • number, severity and rate of closure of service requests and incidents during service delivery, • number, severity and rate of closure of problems during service delivery, and • number and rate of closure on action items.
3. The measurements are chosen from both service delivery activities and service support activities. 4. The measurements cover the properties of the key service delivery activities and major service work products. 5. The measurement data that relate to the organization’s standard service process are uniformly collected across services delivered. 6. The measurements to be controlled are a natural result of the service activities where possible. 7. The measurements are selected to support predefined analysis activities. i In some cases, measurements may be research oriented and should be explicitly designated as such.
8. The validity of the measurement data is independently assessed. 9. The collected measurement data are stored in the organization’s service process database, as appropriate. Z Refer to Activity 4 of the Organization Process Definition key process area for practices covering the organization’s service process database.
Activity 5
The service’s defined service process is analyzed and brought under quantitative control according to a documented procedure. This procedure typically specifies that: 1. The specific data analysis activities are predefined. i The description of the data analysis activities covers: • input data required, • tools used, • data manipulations performed, • information to be derived, and • decision criteria used in performing the analysis and deciding what actions to take as a result of the analysis.
7.1 Quantitative Process Management
151
` Examples of analysis techniques include: • Pareto diagrams, • control charts, • trend diagrams, and, • scatter diagrams.
2. Measurement data on the process activities throughout the service’s defined service process are identified, collected, and analyzed. 3. The selected measurements appropriately characterize the process they represent. 4. The expected values for mean and variance are specified for each measurement. 5. The acceptable limits for each measurement are defined, and the service’s process performance baseline is established. ` An example of establishing acceptable limits is to calculate the historical deviation from the mean performance of the process.
6. The actual values of each measurement are compared to the expected values of the mean and variance. ` Examples of comparing actual process performance to defined acceptable limits include: • comparing the time to closure of service requests or incidents to the upper and lower limits determined by analyzing historical data, and, • comparing the unexpected downtime of servers compared to the upper and lower limits determined by analyzing historical data.
7. Adjustments are made to bring the actual process performance in line with the defined acceptable limits, as appropriate. 8. When the service’s defined service process is controlled quantitatively, baselines are established for: • the definitions of the measurements, • the actual measurement data, and, • the acceptable limits for the measurements. 9. The process performance baseline for the service delivered is managed and controlled. Activity 6
Reports documenting the results of the service delivery quantitative process management activities are prepared and distributed. 1. The results of the data analysis are reviewed with those affected by the data before they are reported to anyone else. 2. The service delivery managers, service delivery task leaders, and senior management receive regular reports appropriately for their needs.
152
The Key Process Areas for Level 4: Managed 3. The service quality assurance group receives regular reports appropriate to its needs. 4. The service delivery manager, senior managers, service managers, and service delivery task leaders receive specialized reports on request.
Activity 7
The process capability baseline for the organization’s standard service process is established and maintained according to a documented procedure. This procedure typically specifies that: 1. The service delivery process data, as summarized in its process performance baseline, are recorded in the organization’s service process database. Z Refer to Activity 4 of the Organization Process Definition key process area for practices covering the organization’s service process database.
2. The process performance baseline for each service’s defined service process is incorporated, as appropriate, into the process capability baseline for the organization’s standard service process. 3. The process capability baseline for the organization’s standard service process is documented. 4. Process capability trends for the organization’s standard service process are examined to predict likely problems or opportunities for improvements. ` Examples of using capability trends include: • predicting the occurence of service requests and incidents and comparing the predictions to the actuals, and • predicting the distribution and characteristics of service requests and incidents based on data from resource management and problem management. ` Examples of areas that are likely sources of service requests and incidents include: • incomplete or incorrect service commitments, • deployment of new versions of software, • changes in the IT infrastructure, • changes in the customer organization, • large fluctuations in service workload, and • long-running systems. ` Examples of areas that are likely opportunities for improvement include: • activities that have successfully been automated for other services or by other organizations, • nondeliverable and support items and activities such as training and tools, • quality-oriented activities such as testing and reviewing, and • labor-intensive activities.
7.1 Quantitative Process Management
153
5. The process capability baseline for the organization’s standard service process is managed and controlled. 6. When a service is delivered that is substantially different from past services of the same service type, a new process performance baseline is established for the service as part of tailoring the organization’s standard service process. Z Refer to Activity 1 of the Integrated Service Management key process area for practices covering the tailoring of the organization’s standard service process. ` Examples of substantial differences include: • new application domains, • use of radically different technologies, and • significant change in the number of end-users.
7. Changes to the organization’s standard service process are tracked and analyzed to assess their effects on the process capability baseline.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the activities for quantitative process management. ` Examples of measurements include: • the cost over time for the quantitative process management activities, compared to the plan, and • the accomplishment of schedule milestones for quantitative process management activities, compared to the approved plan (e.g., establishing the process measurements to be used during service delivery, determining how the process data will be collected, and collecting the process data).
Verifying Implementation Verification 1
The activities for quantitative process management are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Organization Process Focus key process area and Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The activities for quantitative process management are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
154
The Key Process Areas for Level 4: Managed
Verification 3
The service quality assurance group reviews and/or audits the activities and work products for quantitative process management and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify that: 1. The plans for the quantitative process management activities are followed. 2. The procedures for quantitative process management are followed. 3. The collection and analysis of quantitative process management data are performed as required, including verification that: • • • • • • • • • •
7.2
the needed data exist, the needed data are collected, the data collected are needed, the data collected support the goals and objectives of the organization’s measurement program, the cost of collecting the data is justified by the usefulness of the data, the data are collected at the correct point in the service delivery schedule, the data are accurate and correct, the data are timely, the date are reported properly, the confidentiality of the data is properly protected.
Service Quality Management
Purpose
New key
process area
The purpose of the key process area Service Quality Management is to develop a quantitative understanding of the quality of the service delivered and achieve specific quality goals. Service Quality Management involves defining quality goals for the service levels, establishing plans to achieve these goals, and monitoring and adjusting the service plans, service work products, activities, and quality goals to satisfy the needs and desires of the customer and end user for high quality services. The practices of Service Quality Management build on the practices of the Integrated Service Management and Service Delivery key process areas, which establish and implement the service’s defined service process, and the Quantitative Process Management key process area, which establishes a quantitative understanding of the ability of the service’s defined service process to achieve the desired results. Quantitative goals are established for the service levels based on the needs of the organization, the customer, and the end users. So that these goals may be achieved, the organization establishes
7.2 Service Quality Management
155
strategies and plans, and the service’s defined service process is specifically adjusted to accomplish the quality goals.
Goals Goal 1
The service quality management activities for service delivery are planned.
Goal 2
Measurable goals for service quality and their priorities are defined.
Goal 3
Actual progress towards achieving the quality goals for the service levels is quantified and managed.
Commitment to Perform Commitment 1
A written organizational policy is followed for managing service quality of the delivered services. This policy typically specifies that: 1. The service quality management activities for service delivery support the organization’s commitment to improve the quality of services delivered. i Improvements to the process that increase service quality are a top priority of the organization. Each service delivered should be measurably better than the previous service delivered or the same service delivered by the leading competitor.
2. Measurements used for service quality management are defined and collected based on the service’s defined service process. 3. Quality goals for the service levels are defined and progress towards them is monitored. 4. Responsibilities for service quality management are defined and assigned to the service delivery group and other service-related groups. ` Examples of service-related groups include: • service quality assurance group, • configuration management group, and • service request and incident management group.
• Criteria are established to enable the groups to determine their success in achieving the quality goals for the service levels.
Ability to Perform Ability 1
Adequate resources and funding are provided for managing the quality of services.
156
The Key Process Areas for Level 4: Managed 1. Specialty engineers in areas such as safety, security and reliability are available to set the service quality goals and review progress towards the goals. 2. Tools to support predicting, measuring, tracking, and analyzing service quality are made available. ` Examples of support tools include: • data collection tools, • network and system monitoring tools, • security audit tools, and • quantitative analysis tools.
Ability 2
The individuals implementing and supporting service quality management receive required training to perform their activities. ` Examples of training include: • planning quality commitments and goals for the service, • measuring service, product and process quality, and • controlling service quality using the defined service process. Z Refer to the Training Program key process area.
Ability 3
The members of the service delivery group and other service-related groups receive required training in service quality management. ` Examples of training include: • understanding the goals and benefits of quantitatively managing service quality, • collecting measurement data, • understanding the quality measurements for the service levels and service process, and • planning and controlling the quality of the service. Z Refer to the Training Program key process area.
Activities Performed Activity 1
The service quality plan for service delivery is developed and maintained according to a documented procedure. This procedure typically specifies that: 1. An understanding of the service quality needs of the organization, customer, and end users is developed, as appropriate. i The end users referred to in these practices are the customer-designated end users or representatives of the end users.
7.2 Service Quality Management
157
` Examples of ways to measure the customer’s and end users’ service quality needs include: • surveys, • interviews, and • focus groups.
2. The service quality needs and priorities of the organization, customer and end user are traceable to the service commitments and the service quality goals. ` An example of a method to trace these needs and priorities is Quality Function Deployment (QFD). An example of tracing needs and priorities to the service quality goals for the service is establishing targets for the number of unplanned downtimes and performing predictive exercises during service delivery to assess the likelihood of meeting those goals.
3. The capability of the service’s defined service process to satisfy the service quality goals is assessed and documented. i Techniques such as Quality Function Deployment can be used to relate the quality goals of a service to the process capability.
4. The service quality plan is based on plans for previous or current services delivered in the organization, as appropriate. 5. The service quality plan is updated at the start of the service delivery, at major milestones, and whenever the service commitments change significantly. 6. The service quality plan undergoes peer review. Z Refer to the Software CMM Peer Reviews key process area.
7. The service quality plan is reviewed by affected groups and individuals. ` Examples of affected groups and individuals include: • the customer, • the end users, • service delivery group, • service quality assurance group, • configuration management group, and • service request and incident management group.
8. Senior management reviews the service quality plans. 9. The service quality plan is managed and controlled. 10. The service quality plan is available to all affected groups and individuals. Activity 2
The service quality plan is the basis for the activities for service quality management during service delivery. The plan covers:
158
The Key Process Areas for Level 4: Managed 1. The points in the process where service quality is measured. 2. The high-leverage quality goals for the service levels. i High-leverage quality goals for the service levels are those that provide the greatest customer satisfaction at the least cost, or the ”must haves” from the customer or end user.
3. The actions that will be implemented for the delivery of this service to improve on past quality performance. 4. The activities to measure service quality. ` Examples of service activities to measure service quality include: • work product reviews, • system and network monitoring, and • testing.
5. Quality goals for service work products, as appropriate. ` Examples of quality goals for service work products that are appropriate to document in the service quality plan include: • the characteristics that are planned to be met, and • the critical characteristics that, if not met, would make the service undesirable or not needed by the customer or end users.
6. The actions that will be taken when the service quality is projected not to meet the quality goals. Activity 3
The quantitative quality goals for the service levels are defined, monitored, and revised throughout the delivery of the service. 1. Characteristics of service quality that describe how well the service will be delivered are identified. ` Examples of service quality characteristics include: • availability of software, • response times of software, and • average lead time to install certain software to desktops.
2. The measurements used to quantify the characteristics of service quality are identified. ` Examples of activities to identify measurements for service quality include: • reviewing prior performance data and customer service needs, • critical incident reviews, • problem reviews, and • conducting tests.
3. For each characteristic of service quality, measurable, numeric values, based on the required and desired values, are selected as quality goals for the service.
7.2 Service Quality Management
159
` Examples of possible quality goals for service reliability include: • the mean time between failures, • the mean time between failures that must be achieved (as determined by analysis and experimentation), and • the mean time between failures that is planned to be achieved.
4. Quality goals for the service are documented in the service quality plan. ` Examples of quality goals for services that are appropriate to document in the service quality plan include: Huh? • the characteristics that are planned to be met, and These are • the critical characteristics that, if not met, would make the service unde- not quality sirable or not needed by the customer or end users. goals.
5. The quality goals for each service activity are defined and documented. ` Examples of service activities include: • installing software on a desktop computer, • unlocking a user account, and • replacing a broken monitor with a new one. ` Examples of quality goals related to service activities include: • 99.5% of software installations on desktop computers are finished within one hour, and • at least 60% of the calls are solved by service desk staff during the call.
6. The quality goals for the service levels are revised as understanding of the service and understanding of the organization’s, customer’s, and end users’ needs evolve. Activity 4
The quality of the service delivered is measured, analyzed, and compared to the quantitative quality goals of the service delivered on an event-driven basis. Z Refer to the Quantitative Process Management key process area for practices covering the use of measurement data.
1. The service tasks are planned and performed to address the delivered service’s service quality goals. At the beginning of a service task, the team performing the task: • • • •
reviews the quality goals for the service, determines the quality goals applicable to the service task, identifies its plans to achieve the service quality goals, and reviews changes made to the process to meet the service quality goals.
160
The Key Process Areas for Level 4: Managed ` An example of a change is revising a product acceptance checklist to address defects that have been found to escape the product acceptance test.
2. The quality of service work products is measured. ` Examples of methods to measure the quality of service work products include: • peer reviews, • simulation, and • testing.
3. The quality measurements are analyzed and compared to the service quality goals to determine whether the quality goals are satisfied. 4. Appropriate actions, consistent with the service quality plan, are taken to bring the quality measures of the delivered service in line with the service quality goals. 5. When it is determined that the service quality goals conflict (that is, one goal cannot be achieved without compromising another goal), actions are taken to resolve the conflict. • The cost for achieving the service quality goal is analyzed. • Alternative service quality goals are considered in light of long-term business strategies as well as short-term priorities. • The customer and end users participate in quality tradeoff decisions, as appropriate. • The service work products and plans are revised, as appropriate, to reflect the results of the tradeoffs. Activity 5
The quantitative quality goals for the service delivery are allocated appropriately to the service subcontractors delivering subcontracted services. Z Refer to Activity 1 of the Subcontract Management key process area.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the service quality management activities. ` Examples of measurements include: • the cost of poor quality (based on the known quality measurements to whatever degree of accuracy they can be collected), and • the costs for achieving the quality goals.
7.3 Financial Service Management
161
Verifying Implementation Verification 1
The activities for service quality management are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The activities for service quality management are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
Verification 3
The service quality assurance group reviews and/or audits the activities and work products for service quality management and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. The preparation of the service’s service quality plan. 2. The process for establishing and tracking the service quality goals.
7.3
Financial Service Management
New key
process area
Purpose The purpose of the key process area Financial Service Management is to specify, justify and manage the costs of the IT services agreed upon in the service commitments. The customer is charged for services delivered based on budgeting and accounting of the costs of IT services. Charging furthers optimal use of the IT services according to the customer’s IT service needs, and it allows the IT service provider to operate as a business. Budgeting enables the IT service provider to cover predicted spending on service commitments, to compare predicted with actual spending and to reduce the risks of overspending. Accounting enables the IT service provider to account for money charged or spent on service commitments.
Goals Goal 1
Financial service management activities are planned.
Goal 2
The costs of delivering IT services are identified, planned, recorded, reviewed, analyzed, and tracked.
162 Goal 3
The Key Process Areas for Level 4: Managed The customer is charged for the IT services delivered according to the charging policy agreed to in the service commitments. i At level four, an IT service provider is able to provide a choice to the customer in what way charging is organized, as opposed to lower levels where only lump-sum charging is possible because no detailed information is available about the cost drivers of the standard services.
Goal 4
Affected groups and individuals are informed of the planned and actual costs and revenues of IT services delivered.
Commitment to Perform Commitment 1
A written organizational policy is followed for performing the financial service management activities. This policy typically specifies that: 1. Responsibility for financial service management is explicitly assigned. 2. An accounting system is implemented to record the actual costs and revenues of delivering services. 3. A repository for storing cost, charging and budgeting information (i.e., the financial service management repository) is made available. 4. For each service delivered, actual costs are recorded according to the accounting system implemented. 5. Agreements are made and documented in the service commitments with each customer on the charging policy for the services delivered to that customer. i A charging policy defines how the costs of the services delivered are charged to the customer. Elements of the charging policy include how fixed and variable as well as direct and indirect costs are apportioned to customers, IT services, and/or chargeable items. The goal of the charging policy is to recover costs for delivering the IT service to the customer. Additional goals may be to operate the IT service provider as a business unit with profit responsibility and/or to influence end user and customer behavior. Note that there is a close relation between the range of possible charging policies and the accounting system used by the IT service provider. The accounting system determines the level of detail with which cost information is gathered, which in turn determines what charging policies are feasible. So, the accounting system should be tuned to what kinds of charging policies the IT service provider wants to employ.
6. The cost, charging, and budgeting repository and financial service management activities are audited on a periodic basis.
7.3 Financial Service Management
163
Ability to Perform Ability 1
A group that is responsible for coordinating and implementing financial service management (i.e. the financial service management group) exists. The financial service management group coordinates or implements: 1. Development and maintenance of the organization’s accounting system. 2. Creation and management of the organization’s financial service management repository. 3. Development, maintenance, and distribution of financial service management plans, standards, and procedures. 4. Management of access to the financial service management repository. 5. Changes to the financial service management repository. 6. Recording of financial service information. 7. Production and distribution of financial service reports and service bills.
Ability 2
Adequate resources and funding are provided for performing the financial service management activities. 1. A senior manager, who is knowledgeable in the financial service management role and has the authority to take appropriate oversight actions, is designated to receive and act on financial non-compliance issues. • All managers in the financial service management reporting chain are knowledgeable in the financial service management role, responsibilities and authority. 2. A manager is assigned specific responsibility for the financial service management activities. 3. Tools to support the financial service management activities are made available. ` Examples of tools include: • effort registration tools, • system monitoring tools, • financial administration tools, and • report generators.
Ability 3
Members of the financial service management group receive required trained to perform their financial service management activities. ` Examples of training include: • budgeting and financial planning, • charging methods, and • accounting standards, procedures, and methods to be followed for financial service management activities.
164
The Key Process Areas for Level 4: Managed Z Refer to the Training Program key process area.
Ability 4
Service managers and service delivery managers receive orientation on the financial aspects of service delivery.
Activities Performed Activity 1
The organization’s accounting system is developed, implemented, and revised according to a documented procedure. i The organization’s accounting system enables the organization to: • track actual service delivery costs and revenues against budgets, and • charge customers for the IT services delivered. The accounting system may obtain information about cost elements from several different sources, such as: • the effort registration system, • the configuration management library system, • the , and • service commitments.
This procedure typically specifies that: 1. The organization’s accounting system supports the charging policies employed by the organization. 2. The organization’s accounting system is reviewed by affected groups. 3. The organization’s accounting system is managed and controlled. Activity 2
A financial service management plan is prepared for each service according to a documented procedure. This procedure typically specifies that: 1. The financial service management plan is developed in the early stages of, and in parallel with the development of a standard service. 2. The financial service management plan is reviewed by affected groups. 3. The financial service management plan is managed and controlled.
Activity 3
A documented and approved financial service management plan is used as the basis for performing the financial service management activities. The plan covers: 1. Development of the charging policy used to charge actual service delivery costs to the customer, including any adaptations that may need to be made in the accounting system to provide for the required level of detail in cost information.
7.3 Financial Service Management
165
2. The budget for delivery of the service per period, based on the service estimates. Z Refer to the Service Delivery Planning key process area for practices covering the estimation of service delivery workload, effort, and costs.
3. The pricing policy of the service and service elements. i Examples of pricing policies include: • cost-based pricing. The price of the service is based on the actual costs of delivering the service. • market price. The price of the service is based on the prices of comparable services that are charged by other IT service providers. • fixed price. The price of the service is determined by negotiations with the customer.
4. The use of the accounting system to calculate the costs of delivering the IT service to the customer. 5. The financial service management activities to be performed, the schedule of the activities, the assigned responsibilities, and the resources required (including staff and tools). Activity 4
A financial service management library system is established as a repository for cost, charging and budgeting information. This library system: 1. Provides for the storage, update, and retrieval of cost, charging, and budgeting information. 2. Helps in the use of financial service management procedures. Z Refer to Activity 5.
3. Provides for the archival and retrieval of historic cost, charging, and budgeting information. 4. Provides for the production of service bills. Z Refer to Activity 6.
5. Supports production of financial service management reports. Z Refer to Activity 8.
Activity 5
Actual service delivery costs are identified, recorded, analyzed, reviewed, and tracked according to a documented procedure. This procedure typically specifies that: 1. Costs are identified and recorded according to the accounting system developed for the standard service. 2. Actual costs are compared to budgets or cost predictions.
166
The Key Process Areas for Level 4: Managed 3. Action items resulting from the comparison of actual costs and budgets are: • • • • • • • •
Activity 6
identified, assessed for risk, documented, planned, initiated, communicated to affected groups and individuals, tracked to closure, and evaluated.
Actual service delivery costs are reported to the customer on a periodic basis and charged as documented in the service commitments. 1. Actual service delivery costs are reported to the customer on a periodic basis, in parallel with the service level reports. Z Refer to Activity 5 of the Service Tracking and Oversight key process area for practices covering the reporting of actual service levels.
2. Actual service delivery costs are charged to the customer according to the charging policy agreed to in the service commitments. Z Refer to Activity 3 of the Service Commitment Management key process area for practices covering the contents of the service commitments.
Activity 7
Affected groups and individuals are informed of the status of actual service delivery costs on both a periodic and an event-driven basis. ` Examples of affected groups and individuals include: • service manager, • service delivery manager, • resource management group, and • senior management.
Activity 8
Standard reports documenting the financial service management activities and contents of the financial service management repository are developed and made available to affected groups and individuals. ` Examples of reports include: • budgets, expenditures against budgets and budget underruns or overruns. • actual and estimated costs per cost element. • costs charged per service and per customer.
7.3 Financial Service Management
167
` Examples of affected groups and individuals include: • service manager, • service delivery manager, • resource management group, and • senior management.
Activity 9
Financial service management repository audits are conducted according to a documented procedure. This procedure typically specifies that: 1. There is adequate preparation for the audit. 2. The integrity of the financial service management repository is assessed. 3. The facilities of the financial service management library system are reviewed. 4. The completeness and correctness of the repository are verified. 5. Compliance with applicable financial service management standards and procedures is verified. 6. The results of the audit are reported to senior management. 7. Action items from the audit are tracked to closure.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of cost, charging, and budgeting information. ` Examples of measurements include: • the number of services where budget overruns occur, • the average amount of budget overruns, and • the accuracy of cost estimations.
Measurement 2
Measurements are made and used to determine the status of the organization’s financial service management activities. ` Examples of measurements include: • the effort expended for different charging policies, and • the effort expended and funds expended in the financial service management activities.
168
The Key Process Areas for Level 4: Managed
Verifying Implementation Verification 1
The activities for financial service management are reviewed with senior management on a periodic basis. Z Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.
Verification 2
The activities for financial service management are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
Verification 3
The financial service management group periodically audits the financial service management repository to verify that it conforms to the documentation that defines it.
Verification 4
The service quality assurance group reviews and/or audits the activities and work products for financial service management and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. The process for developing and revising the organization’s financial service management plan is followed. 2. The procedures for the financial service management activities are followed. 3. The organization’s financial service management plan is followed.
Chapter 8
The Key Process Areas for Level 5: Optimizing 8.1
Problem Prevention
New key
process area
Purpose
The purpose of the key process area Problem Prevention is to identify the cause of problems and prevent them from recurring. Problem Prevention involves analyzing problems that were encountered in the past and taking specific actions to prevent the occurence of those types of problems in the future. The problems may have been identified in other services as well as in earlier stages or tasks of the current service delivery. Problem prevention activities are also one mechanism for spreading lessons learned between services. Trends are analyzed to track the types of problems that have been encountered and to identify problems that are likely to recur. Based on an understanding of the service’s defined service process and how it is implemented (as described in the Integrated Service Management and Service Delivery key process areas), the root causes of the problems and the implications of the problems for future activities are determined. Both for the service and for the organization specific actions are taken to prevent recurrence of the problems. Some of the organizational actions may be handled as described in the Process Change Management key process area.
Goals Goal 1
Problem prevention activities are planned.
Goal 2
Common causes of problems are sought out and identified.
Goal 3
Common causes of problems are prioritized and systematically eliminated. 169
170
The Key Process Areas for Level 5: Optimizing
Commitment to Perform Commitment 1
The organization follows a written policy for problem prevention activities. This policy typically specifies that: 1. Long-term plans and commitments are established for funding, staffing, and other resources for problem prevention. 2. The resources needed are allocated for the problem prevention activities. 3. Problem prevention activities are implemented across the organization to improve the services and service processes. 4. The results of the problem prevention activities are reviewed to ensure the effectiveness of those activities. 5. Management and technical actions identified as a result of the problem prevention activities are addressed.
Commitment 2
The service follows a written organizational policy for problem prevention activities. This policy typically specifies that: 1. Problem prevention activities are included in each service’s service delivery plan. 2. The resources needed are allocated for the problem prevention activities. 3. Service management and technical actions identified as a result of the problem prevention activities are addressed.
Ability to Perform Ability 1
An organization-level team to coordinate problem prevention activities exists. 1. This team is either part of the group responsible for the organization’s service process activities (e.g., service process improvement group) or its activities are closely coordinated with that group. Z Refer to the Organization Process Focus key process area.
Ability 2
A team to coordinate problem prevention activities for the service exists. 1. This team is closely tied to the team responsible for developing and maintaining the service’s defined service process. i Members of the team coordinating problem prevention activities are usually assigned to this team on a part-time basis and have other service delivery activities as their primary responsibility.
8.1 Problem Prevention
171
Z Refer to Activities 1 and 2 of the Integrated Service Management key process area for practices covering developing and maintaining the service’s defined service process.
Ability 3
Adequate resources and funding are provided for problem prevention activities at the service and organization levels. 1. Problem prevention activities are planned into each person’s responsibilities, as appropriate. ` Examples of problem prevention activities include: • task kick-off meetings, • causal analysis meetings, • reviewing and planning proposed actions, and • implementing actions.
2. Management participation in the problem prevention activities is planned. 3. Each service is represented on the team coordinating problem prevention activities for the organization, as appropriate. 4. Tools to support problem prevention activities are made available. ` Examples of support tools include: • statistical analysis tools, and • database systems.
Ability 4
Members of the service delivery group and other service-related groups receive required training to perform their problem prevention activities. ` Examples of service-related groups include: • service quality assurance group, • configuration management group, and • documentation support. ` Examples of training include: • problem prevention methods, • conduct of task kick-off meetings, • conduct of causal analysis meetings, and • statistical methods (e.g., cause/effect diagrams and Pareto analysis). Z Refer to the Training Program key process area.
172
The Key Process Areas for Level 5: Optimizing
Activities Performed Activity 1
The service develops and maintains a plan for its problem prevention activities. This plan: 1. Identifies the problem prevention activities (e.g., task kick-off and causal analysis meetings) that will be held. 2. Specifies the schedule of problem prevention activities. 3. Covers the assigned responsibilities and resources required, including staff and tools. 4. Undergoes peer review. Z Refer to the Software CMM Peer Reviews key process area.
Activity 2
At the beginning of a service task, the members of the team performing the task meet to prepare for the activities of that task and the related problem prevention activities. i Kick-off meetings are held to familiarize the members of the team with the details of the implementation of the process, as well as any recent changes to the process. ` Examples of service tasks include: • production acceptance test of a new version of a software application, • release of a new version of a software application in production, and • movement of desktop equipment of a business department to a new office location.
The kick-off meetings cover: 1. The service process, standards, procedures, methods and tools applicable to the task, with an emphasis on recent changes. i Changes may be implemented as an experiment to evaluate a recommendation from a previous casual analysis meeting.
2. The inputs required and available for the task. 3. The outputs to be produced with examples, if available. 4. The methods to be used to evaluate the outputs. 5. The methods to be used to verify adherence to the service process. 6. A list of errors that are commonly made or introduced during the current task and recommended preventive actions for these errors. 7. The team assignments. 8. The task schedule.
8.1 Problem Prevention
173
9. The service process quality goals for the task and the service. Z Refer to the Service Quality Management key process area.
Activity 3
Causal analysis meetings are conducted according to a documented procedure. This procedure typically specificies that: 1. Each team that performs a service task conducts causal analysis meetings. • A causal analysis meeting is conducted shortly after the task is completed. • Meetings are conducted during the service task if and when the number of problems uncovered warrants additional meetings. • Periodic causal analysis meetings are conducted during service delivery, as appropriate. • For service tasks of long duration, periodic in-process causal analysis meetings are conducted as appropriate. ` An example of a long-duration task is monitoring availability of hardware components.
2. The meetings are led by a person trained in conducting causal analysis meetings. 3. Problems are identified and analyzed to determine their root causes. ` An example of a method to determine root causes is cause/effect diagrams.
4. The problems are assigned to categories of root causes. ` Examples of problem root cause categories include: • inadequate training, • breakdown in communications, • insufficient contingency measures, and • mistakes in manual procedures (e.g., typing).
5. Proposed actions to prevent the future occurrence of identified problems and similar problems are developed and documented. ` Examples of proposed actions include modifications to: • the process, • training, • tools, • methods, • communications, and • service work products.
6. Common causes of problems are identified and documented.
174
The Key Process Areas for Level 5: Optimizing ` Examples of common causes include: • insufficient testing of software before it is put into production, and • insufficient training of service engineers.
7. The results of the meeting are recorded for use by the organization and in the delivery of other services. Activity 4
Each of the teams assigned to coordinate problem prevention activities meets on a periodic basis to review and coordinate implementation of action proposals from the causal analysis meetings. i The teams involved may be at the organization or service level.
The teams: 1. Review the output from the causal analysis meetings and select action proposals that will be addressed. 2. Review action proposals that have been assigned to them by other teams coordinating problem prevention activities in the organization and select action proposals that will be addressed. 3. Review actions taken by the other teams in the organization to assess whether these actions can be applied to their activities and processes. 4. Perform a preliminary analysis of the action proposals and set their priorities. i Priority is usually nonrigorous and is based on an understanding of: • the causes of problems, • the implications of not addressing the problems, • the cost to implement process improvements to prevent the problems, and • the expected impact on service quality. An example of a technique used to set priorities for the action proposals is Pareto analysis.
5. Reassign action proposals to teams at another level in the organization, as appopriate. 6. Document their rationale for decisions and provide the decision and the rationale to the submitters of the action proposals. 7. Assign responsibility for implementing the action items resulting from the action proposals. • Implementations of the action items includes making immediate changes to the activities that are within the purview of the team and arranging for other changes. • Members of the team usually implement the action items, but, in some cases, the team can arrange for someone else to implement an action item.
8.1 Problem Prevention
175
8. Review results of problem prevention experiments and take actions to incorporate the results of successful experiments into the rest of the service delivery or organization, as appropriate. ` Examples of problem prevention experiments include: • using a temporarily modified process, and • using a new tool.
9. Track the status of the action proposals and action items. 10. Document service process improvement proposals for the organization’s standard service process and the service’s defined service processes as appropriate. i The submitters of the action proposal are designated as the submitters of the service process improvement proposals. Z Refer to Activity 5 of the Process Change Management key process area for practices covering handling of service process improvement proposals.
11. Review and verify completed action items before they are closed. 12. Ensure that significant efforts and successes in preventing problems are recognized.
Activity 5
Problem prevention data are documented and tracked across the teams coordinating problem prevention activities.
1. Action proposals identified in causal analysis meetings are documented. ` Examples of data that are in the description of an action proposal include: • originator of the action proposal, • description of the problem, • description of the problem cause, • problem cause category, • stage when the problem was caused, • stage when the problem was identified, • description of the action proposal, and • action proposal category.
2. Action items resulting from action proposals are documented.
176
The Key Process Areas for Level 5: Optimizing ` Examples of data that are in the description of an action item include: • the person responsible for implementing it, • a description of the areas affected by it, • the individuals who are to be kept informed of its status, • the next date its status will be reviewed, • the rationale for key decisions, • a description of implementation actions, • the time and cost for identifying the problem and correcting it, and • the estimated cost of not fixing the problem.
3. The problem prevention data are managed and controlled. i ‘Managed and controlled’ implies that the work product adheres to organizational documentation standards, that the version of the work product in use at a given time (past or present) is known (i.e. version control), and that changes are incorporated in a controlled manner (i.e. change control). If a greater degree of control than is implied by ‘managed and controlled’ is desired, the work product can be placed under the full discipline of configuration management, as is described in the Configuration Management key process area.
Activity 6
Revisions to the organization’s standard service process resulting from problem prevention actions are incorporated according to a documented procedure. Z Refer to Activity 1 of the Organization Process Definition key process area for practices covering the organization’s standard service process.
Activity 7
Revisions to the service’s defined service process resulting from problem prevention actions are incorporated according to a documented procedure. Z Refer to Activity 2 of the Integrated Service Management key process area for practices covering the service’s defined service process.
Activity 8
Members of the service delivery group and service-related groups receive feedback on the status and results of the organization’s and service’s problem prevention activities. The feedback provides: 1. A summary of the major problem categories. 2. The frequency distribution of problems in the major problem categories. 3. Significant innovations and actions taken to address the major problem categories. 4. A summary status of the action proposals and action items.
8.1 Problem Prevention
177
i Examples of means to provide this feedback includes: • electronic bulletin boards, • newsletters, and • information flow meetings.
What is a information } flow meeting?
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the problem prevention activities. ` Examples of measurements include: • the costs of problem prevention activities (e.g., holding causal analysis meetings and implementing action items), cumulatively, • the time and cost for identifying the problems and correcting them, compared to the estimated cost of not correcting the problems, • profiles measuring the number of action items proposed, open, and completed, • the number of problems injected in each stage, cumulatively, and • the number of problems.
Verifying Implementation Verification 1
The organization’s activities for problem prevention are reviewed with senior management on a periodic basis. i The primary purpose of periodic reviews by senior management is to provide awareness of, and insight into, service process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
These reviews cover: 1. A summary of the major problem categories and the frequency distribution of problems in these categories. 2. A summary of the major action categories and the frequency distribution of actions in these categories. 3. Significant actions taken to address the major problem categories. 4. A summary status of the proposed, open, and completed action items. 5. A summary of the effectiviness of and savings attributable to the problem prevention activities.
178
The Key Process Areas for Level 5: Optimizing 6. The actual cost of completed problem prevention activities and the projected cost of planned problem prevention activities.
Verification 2
The activities for quantitative process management are reviewed with the service manager on both a periodic and an event-driven basis. Z Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews.
Verification 3
The service quality assurance group reviews and/or audits the activities and work products for problem prevention and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify that: 1. The service managers and technical staff are trained for their problem prevention roles. 2. The task kick-off meetings and causal analysis meetings are properly conducted. 3. The process for reviewing action proposals and implementing action items is followed.
8.2
Technology Change Management
Purpose
New key
process area
The purpose of Technology Change Management is to identify new technologies (i.e., tools, methods, and processes) and transition them into the organization in an orderly manner. Technology Change Management involves identifying, selecting, and evaluating new technologies and incorporating effective technologies into the organization. The objective is to improve service quality, increase productivity, and decrease the effort expenditure for service delivery. The organization establishes a group (such as a service process improvement group or technology support group) that works with the service engineers in service delivery to introduce and evaluate new technologies and manage changes to existing technologies. Particular emphasis is placed on technology changes that are likely to improve the capability of the organization’s standard service process (as described in the Organization Process Definition key process area). By maintaining an awareness of service-related technology innovations and systematically evaluating and experimenting with them, the organization selects appropriate technologies to improve the quality of its services and the productivity of its service activities. Pilot efforts are performed to assess new and unproven technologies before they are incorporated into normal practice. With appropriate sponsorship of the organization’s management, the selected technologies are incorporated into the organization’s standard service process and current services delivered, as appropriate.
8.2 Technology Change Management
179
Changes to the organization’s standard service process (as described in the Organization Process Definition key process area) and the services’ defined service processes (as described in the Integrated Service Management key process area) resulting from these technology changes are handled as described in the Process Change Management key process area.
Goals Goal 1
Incorporation of technology changes is planned.
Goal 2
New technologies are evaluated to determine their effect on quality and productivity.
Goal 3
Appropriate new technologies are transferred into normal practice across the organization.
Commitment to Perform Commitment 1
The organization follows a written policy for improving its technology capability. This policy typically specifies that: 1. Objectives for technology change management are established and documented. 2. A documented plan addresses the objectives for technology change management.
Commitment 2
Senior management sponsors the organization’s activities for technology change management. Senior management: 1. Helps to define a strategy that addresses the organization’s goals for service quality, productivity, and effort expenditure for service delivery. 2. Helps to define a strategy that addresses the customer’s and end users’ needs and desires, as appropriate. i The end users referred to in these practices are the customer-designated end users or representatives of the end users.
3. Coordinates with the organization’s managers in defining their goals and approaches for accomplishing the organization’s strategy. 4. Makes a commitment to the effort for technology change management that is visible throughout the organization. 5. Establishes long-term plans and commitments for funding, staffing, and other resources.
180 Commitment 3
The Key Process Areas for Level 5: Optimizing Senior management oversees the organization’s technology change management activities. Senior management: 1. Helps to establish policies for technology change management and reviews and approves these policies. 2. Allocates resources for technology change management activities. 3. Helps relate organizational strategies and objectives to strategies for technology change management. 4. Participates in establishing the plans for technology change management. • Senior management coordinates requirements and issues for technology change management at all appropriate levels of the organization. • Senior management coordinates with the organization’s managers to secure the managers’ and staff’s support and participation.
Ability to Perform Ability 1
A group responsible for the organization’s technology change management activities exists. 1. The group is either part of the group responsible for the organization’s service process activities (e.g., service process improvement group) or its activities are closely coordinated with that group. 2. The group coordinates and helps to: • explore potential areas for applying new technology, • select and plan for new technologies, • acquire, install, and customize new technologies, • communicate and coordinate with related research and development activities within the organization, and • communicate with the technology suppliers on problems and enhancements.
Ability 2
Adequate resources and funding are provided to establish and staff a group responsible for the organization’s technology change management activities. 1. Experienced staff members with expertise in specialized areas are available to this group to help in evaluating, planning, and support in initiatives for technology change management. ` Examples of specialized areas include: • workstations, • computer hardware, • software reuse, and • measurement,
8.2 Technology Change Management
181
2. Tools to support technology change management are made available. ` Examples of support tools include: • workstations, • statistical analysis tools, and • subscriptions to on-line technology databases.
Ability 3
Support exists for collecting and analyzing data needed to evaluate technology changes. This support includes the ability to:
1. Record selected process and product data automatically. 2. Support data analysis. 3. Display selected data. i The results of data analysis are presented in fomats that can appropriately convey the information content, e.g., graphical displays.
Ability 4
Appropriate data on the service processes and service work products are available to support analyses performed to evaluate and select technology changes. ` Examples of process and product data include: • resource expenditures and productivity by service delivery, stage of the service delivery, tools and methods used, service type, etc., • schedule time by service delivery, stage of the service delivery, service type, effort, etc., • problem data showing the staged introduced, stage removed, type, cause, severity, and time and effort to fix, • change activity, including the effort spent, etc., • data on the activities to resolve problems, the release in which the problem was resolved, and identification of incidents introduced in implementing each problem resolvement, and • density of problems per service delivery, service type, and service work products.
Ability 5
Members of the group responsible for the organization’s technology change management activities receive required training to perform these activities.
182
The Key Process Areas for Level 5: Optimizing ` Examples of training include: • the organization’s standard service process, • technology transfer and change management, • service process improvement, • tools and methods used by the organization, • analytical and support facilities available to the organization, and • principles of statistical quality control. Z Refer to the Training Program key process area.
Activities Performed Activity 1
The organization develops and maintains a plan for technology change management. This plan: 1. Covers the assigned responsibilities and resources required, including staff and tools. 2. Defines the long-term technical strategy for automating and improving the organization’s standard service process and enhancing the organization’s market position. 3. Identifies the procedures to be followed in performing the organization’s technology change management activities. 4. Describes the approach for introducing new technologies to address specific needs of the organization and services. • Process areas that are potential areas for technology changes are identified. • Approaches for identifying opportunities for technology changes are identified. • The specific planned or candidate technologies are identified. • Where appropriate, the life span for the planned technologies is estimated, from introduction to replacement. • The make/buy tradeoff studies are documented. • Approaches for assessing unproven candidate technologies are defined. • The acquisition and installation procedures are defined. • The initial training, continuing training and consultation support are defined. 5. Undergoes peer review. Z Refer to the Software CMM Peer Reviews key process area.
8.2 Technology Change Management
183
6. Is reviewed by the affected managers. Activity 2
The group responsible for the organization’s technology change management activities works with the service engineers in identifying areas of technology change. This group: 1. Solicits suggestions for technology changes. 2. Identifies available new technologies that may be appropriate to the organization’s and services’ needs. • A periodic search is made to identify commercially available technologies that meet identified and anticipated needs. • Systematic efforts are made to maintain awareness of leading relevant technical work and trends of technologies. • Systematic efforts are made to review the technologies used externally and compare these technologies to those used within the organization. • Areas where new technologies have been used successfully are identified, and data and documentation of experience with using them are collected and reviewed. 3. Evaluates new technologies to determine their applicability to the organization’s and services’ current and future needs.
Activity 3
Service managers and technical staff are kept informed of new technologies. 1. Information on new technologies is disseminated, as appropriate. 2. Information on advanced technologies already in use in parts of the organization is disseminated, as appropriate. 3. Information on the status of technologies being transferred into the organization is disseminated, as appropriate.
Activity 4
The group responsible for the organization’s technology change management systematically analyzes the organization’s standard service process to identify areas that need or could benefit from new technology. This group: 1. Analyzes the organization’s standard service process to determine areas where new technologies would be most helpful. 2. Identifies helpful technology changes and determines the economics of those changes. 3. Defines the relationship of the identified technology to the organization’s standard service process.
184
The Key Process Areas for Level 5: Optimizing 4. Defines the expected outcomes of the technology change qualitatively and quantitatively, as appropriate. 5. Determines the need for piloting each potential technology change. 6. Determines the priority of the candidate new technologies. 7. Documents the results of the analysis activities.
Activity 5
Technologies are selected and acquired for the organization and services according to a documented procedure. This procedure typically specifies that: 1. Requests for the acquisition of new technologies are documented. • Management approval is required for technologies with projected expenses above a predefined level. 2. Preliminary cost/benefit analyses are performed for the potential technology changes. 3. Predefined and approved selection criteria are used to identify the highest potential benefits. 4. Requirements and plans for the selected technology changes are defined and documented. • Where practical, the expected life span and plans for replacement/upgrading are estimated. • Where appropriate, tradeoff studies are performed, reviewed, and documented to determine whether the technology should be developed internally or produced externally. • Where appropriate, the plan provides for installing the new technology on a pilot basis to determine its effectiveness and economic benefits. • The requirements and plans are reviewed by the managers of the affected groups and the group responsible for technology change management activities.
Activity 6
Pilot efforts for improving technology are conducted, where appropriate, before a new technology is introduced into normal practice. 1. These pilot efforts are conducted to determine the feasibility and economics of untried or advanced technologies. 2. The plans for the pilot effort are documented. • The plan covers the objectives, evaluation criteria, and activities for the pilot effort.
8.2 Technology Change Management
185
3. The plan for conducting the pilot effort is reviewed and approved by the managers of the affected groups. ` Examples of affected groups include: • service delivery (including all subgroups), • service estimating, • service testing, • service quality assurance, • configuration management, • contract management, and • documentation support.
4. The group responsible for the technology change management activities provides consultation and assistance to the service engineers implementing the pilot effort. 5. The pilot effort is performed in an environment that is relevant to the production environment. 6. The results of the pilot effort are collected, analyzed, and documented. • Lessons learned and problems encountered during the effort are documented. • The benefits and impacts of broader use in the organization are estimated. The uncertainty in these estimates is assessed. • A decision is made whether to terminate the effort, proceed with broadscale implementation of the technology, or replan and continue the pilot effort. Activity 7
Appropriate new technologies are incorporated into the organization’s standard service process according to a documented procedure. Z Refer to Activity 1 of the Organization Process Focus key process area and Activity 5 of the Process Change Management key process area for practices covering the changes to the organization’s standard service process.
Activity 8
Appropriate new technologies are incorporated into the service’s defined service process according to a documented procedure. Z Refer to Activity 2 of the Integrated Service Management key process area for practices covering revision of the service’s defined service process according to a documented procedure.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the organization’s activities for technology change management.
186
The Key Process Areas for Level 5: Optimizing ` Examples of measurements include: • the overall technology change activity, including number, type, and size of changes, and • the effect of implementing the technology change, compared to the goals.
Verifying Implementation Verification 1
The organization’s activities for technology change management are reviewed with senior management on a periodic basis. i The primary purpose of periodic reviews by senior management is to provide awareness of, and insight into, service process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
These reviews: 1. Summarize the activities for technology change management. 2. Identify needed strategy changes. 3. Result in the resolution of issues. 4. Result in the approval of revisions to the plans for technology change management, as appropriate. Verification 2
The service quality assurance group reviews and/or audits the activities and work products for technology change management and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify: 1. The plans for technology change management. 2. The process for selecting, procuring, and installing new technologies.
8.3
Process Change Management
Purpose
New key
process area
The purpose of Process Change Management is to continually improve the service processes used in the organization with the intent of improving service quality, increasing productivity, and decreasing the effort expenditure in service delivery. Process Change Management involves defining process improvement goals and, with senior management sponsorship, proactively and systematically identifying, evaluating, and implementing
8.3 Process Change Management
187
improvements to the organization’s standard service process and the services’ defined service processes on a continuous basis. Training and incentive programs are established to enable and encourage everyone in the organization to participate in improvement activities. Improvement opportunities are identified and evaluated for potential payback to the organization. Pilot efforts are performed to assess process changes before they are incorporated into normal practice. When service process improvements are approved for normal practice, the organization’s standard service process and the services’ defined service process are revised as appropriate. The practices for revising the organization’s standard service process are found in the Organization Process Definition key process area, and the practices for revising the services’ defined service processes are found in the Integrated Service Management key process area.
Goals Goal 1
Continuous proces improvement is planned.
Goal 2
Participation in the organization’s service process improvement activities is organization-wide.
Goal 3
The organization’s standard service process and the services’ defined service processes are improved continuously.
Commitment to Perform Commitment 1
The organization follows a written policy for improving implementing service process improvements. This policy typically specifies that: 1. The organization has quantitative, measurable goals for service process improvement and tracks performance against these goals. 2. The organization’s process improvements are directed towards improving service quality, increasing productivity, and decreasing effort expenditure. 3. All of the organization’s staff and managers are expected to participate in improving the service processes. i Skilled and motivated people are recognized as the principal process improvement resource.
Commitment 2
Senior management sponsors the organization’s activities for service process improvement. Senior management: 1. Establishes the organization’s long-term goals and plans for process improvement.
188
The Key Process Areas for Level 5: Optimizing 2. Allocates resources for process improvement activities. 3. Coordinates with the service managers to ensure they have reasonable, yet aggressive, process improvement goals and effective process improvement plans to meet these goals. 4. Monitores process improvement performance against goals. 5. Maintains a consistent priority focus on process improvement in the face of service crises. 6. Ensures that process improvement issues are promptly resolved. 7. Rewards employee participation in the process improvement activities.
Ability to Perform Ability 1
Adequate resources and funding are provided for service process improvement activities. 1. Resources are allocated to: • • • •
lead, guide, and support the process improvement activities, maintain the process improvement records, develop, control, and disseminate process changes, and establish and operate the administrative and human resource functions to conduct the communications, motivation, and recognition activities needed to maintain a high level of employee participation.
2. Experienced individuals who have expertise in defining and analyzing service processes are available to help the organization’s staff and managers in its process improvement activities. 3. Tools to support process improvement are made available. ` Examples of support tools include: • statistical analysis tools, • database systems, • process automation tools, and • process modeling tools.
Ability 2
Service managers receive required training in service process improvement. ` Examples of training include: • managing technological and organizational change, • team building, and • teamwork skills as applied to continuous process improvement. Z Refer to the Training Program key process area.
8.3 Process Change Management Ability 3
189
The managers and technical staff of the service delivery group and other service-related groups receive required training in service process improvement. ` Examples of service-related groups include: • service quality assurance group, • configuration management group, and • documentation support. ` Examples of training include: • the principles of quality and process improvement, and • the procedures for proposing process improvements. Z Refer to the Training Program key process area.
Ability 4
Senior management receives required training in service process improvement. ` Examples of training include: • benchmarking and comparative evaluation, • principles of process improvement, • setting and tracking goals for process improvement, and • motivation and team building in an environment of continuous process improvement.
Activities Performed Activity 1
A service process improvement program is established which empowers the members of the organization to improve the processes of the organization.
Activity 2
The group responsible for the organization’s service process activities (e.g., service process improvement group) coordinates the service process improvement activities. This group: 1. Defines organizational goals and measurement plans for service process performance. 2. Reviews the organizational goals for process performance with senior management for their endorsement. 3. Participates in the effort to define the organization’s training needs for process improvement and supports the development and presentation of training course materials.
190
The Key Process Areas for Level 5: Optimizing Z Refer to the Training Program key process area.
4. Defines and maintains the procedures for handling process improvement proposals. 5. Reviews service process improvement proposals and coordinates the actions for these proposals. 6. Tracks status, accomplishments, and participation in the process improvement activities and periodically reports the results to senior management. 7. Coordinates and tracks changes to the organization’s standard service process. 8. Defines, establishes, and maintains the process improvement records. Activity 3
The organization develops and maintains a plan for service process improvement according to a documented procedure. Z Refer to Activity 2 of the Organization Process Focus key process area for other practices covering the organization’s service process improvement plan.
This procedure typically specifies that: 1. The service process improvement plan is based on: • the organization’s business and strategic operating plans, and • customer satisfaction indicators. 2. The service process improvement plan undergoes peer review. Z Refer to the Software CMM Peer Reviews key process area.
3. The service process improvement plan is reviewed by the affected managers. 4. The service process improvement plan is managed and controlled. i ‘Managed and controlled’ implies that the work product adheres to organizational documentation standards, that the version of the work product in use at a given time (past or present) is known (i.e. version control), and that changes are incorporated in a controlled manner (i.e. change control). If a greater degree of control than is implied by ‘managed and controlled’ is desired, the work product can be placed under the full discipline of configuration management, as is described in the Configuration Management key process area.
Activity 4
The service process improvement activities are performed in accordance with the service process improvement plan. The plan covers: 1. The resources required, including staff and tools. 2. The highest priority process areas for improvement.
8.3 Process Change Management
191
3. Measureable short-term and long-term goals for service process performance and improvement. 4. Teams and their assignments for addressing improvements for specific process areas. i Examples of teams include: • working groups, • process action teams, and • technical committees.
5. The procedures for: • the senior managers overseeing the service process improvement activities, • the service managers planning and coordinating the service process improvement activities, • individuals and teams identifying, evaluating, and introducing appropriate service process improvements, and • the teams developing service process improvements for assigned process areas. 6. The administrative and support plans required to maintain continuous process improvement. • Appropriate administrative procedures are included to encourage participation in and facilitate the service process improvement activities. • Administrative personnel are included in oversight and review of the service process improvement activities. • The roles and contributions of employees to continuous process improvement are recognized.
Activity 5
Service process improvement proposals are handled according to a documented procedure. This procedure typically specifies that:
1. Service process improvement proposals are submitted. i The service process improvement proposals can be submitted at any time and can address any area of the service processes.
192
The Key Process Areas for Level 5: Optimizing ` Examples of sources for service process improvement proposals include: • the findings and recommendations of service process assessments, • the organization’s service process improvement goals, • analysis of data on customer problems and customer satisfaction, • analysis of data on service performance compared to service quality and productivity goals, • the results of process benchmarks, • the potential for process/task automation, • analysis of data on problem causes, • the measured effectiveness of the service process activities. • examples of service process improvement proposals that were successfully adopted, and • feedback on previously submitted service process improvement proposals, as appropriate.
2. Each service process improvement proposal is evaluated; a decision is made whether to implement the proposal, and the decision rationale is documented. 3. The expected benefits of each service process improvement proposal are determined. ` Examples of benefit areas include: • productivity, • quality, • cycle time, • other indicators of customer or end user satisfaction, and • any other internal factors.
4. The priority of service process improvement proposals selected for implementation is determined. • Focus on high-priority service process improvement proposals is maintained. 5. Implementation of the service process improvement actions resulting from the proposals is assigned and planned. 6. Service process improvement actions that require a substantial effort are assigned to a team responsible for implementation. ` Examples of substantial efforts include improvements requiring piloting of new technologies and other large changes. i Teams to focus on specific service process areas are established. Actions that are appropriate for piloting are coordinated.
8.3 Process Change Management
193
` Examples of teams include: • working groups, • process actions teams, and • technical committees.
7. The status of each service process improvement proposal is tracked. 8. Service process improvement proposals for which the response has been unusually long are identified and acted upon. 9. Service process changes that are judged to have a major impact on service quality or productivity or that will significantly alter satisfaction of the customer and end users are reviewed by appropriate management before they are closed. 10. Completed service process improvement actions are reviewed, verified, and approved before they are closed. 11. Submitters of the service process improvement proposals receive: • prompt acknowledgement of their proposals, and • notification of the disposition of their proposals. Activity 6
Members of the organization actively participate in teams to develop service process improvements for assigned process areas. 1. Each of these process improvement teams is funded and the activities are planned and scheduled. 2. Goals are established for each process improvement effort; where possible, these goals are defined quantitatively. 3. The plans are approved by the managers of the affected groups and the group that defines and maintains the affected process descriptions. ` Examples of affected groups include: • service engineering (including all subgroups, such as task leaders in the service delivery groups), • service estimating, • service testing, • service quality assurance, • configuration management, • contract management, and • documentation support.
Activity 7
Where appropriate, the service process improvements are installed on a pilot basis to determine their benefits and effectiveness before they are introduced into normal practice.
194
The Key Process Areas for Level 5: Optimizing 1. Adjustments to the proposed process improvement are made and documented during the pilot effort to optimize its implementation. 2. Lessons learned and problems encountered are documented. 3. The benefits, risks, and impacts of the process improvement’s broader use in the organization are estimated, and the uncertainty in these estimates is assessed. 4. A decision is made whether to terminate the effort, proceed with broad-scale implementation of the improvement, or replan and continue the pilot effort.
Activity 8
When the decision is made to transfer a service process improvement into normal practice, the improvement is implemented according to a documented procedure. This procedure typically specifies that: 1. The resources needed to support major changes to the service process are established and funded. 2. The strategy for collecting data to measure and track the change in service process performance is documented, reviewed and agreed to. • This strategy is agreed to by the individuals responsible for implementing the service processes affected by the change. • The support tools are instrumented, as appropriate, to record the desired data automatically. 3. Training courses are updated to reflect the current service process, and training is provided before installing the process change for general use. Z Refer to the Training Program key process area.
4. Consultation support, appropriate to the expected needs, is established before installing the process change for broad-scale use and is continued as needed. 5. Appropriate process changes are incorporated into the organization’s standard service process. Z Refer to Activity 1 of the Organization Process Definition key process area for practices covering the service’s standard service process.
6. Appropriate process changes are incorporated into the services’ defined service processes. Z Refer to Activity 2 of the Integrated Service Management key process area for practices covering the service’s defined service process.
Activity 9
Records of service process improvement activities are maintained.
8.3 Process Change Management
195
1. Information about the initiation, status, and implementation of service process improvement proposals is maintained. 2. Ready access is provided to the service process improvement records. 3. Historical data are maintained and reports are produced on service process improvements. ` Examples of records and reports include: • the service delivery’s productivity, quality, and schedule performance, • the service delivery’s problem history, • the organizational service quality and productivity trends, and • the cost, schedule, and productivity of service process development and improvement. Z Refer to Activity 4 of the Organization Process Definition key process area for practices covering the organization’s service process database, which is one of the possible mechanisms for maintaining process improvement records.
Activity 10
Service managers and technical staff receive feedback on the status and results of the service process improvement activities on an event-driven basis. The feedback provides:
1. A summary of the major service process improvement activities. 2. Significant innovations and actions taken to address service process improvement. 3. A summary status of the service process improvement proposals that are submitted, open, and completed. ` Examples of means to provide this feedback include: • electronic bulletin boards • newsletters, and • information flow meetings.
Measurement and Analysis Measurement 1
Measurements are made and used to determine the status of the service process improvement activities.
196
The Key Process Areas for Level 5: Optimizing ` Examples of measurements include: • the number of service process improvement proposals submitted and implemented for each process area, • the number of service process improvement proposals submitted by service engineers of different service deliveries, groups, and departments, • the number and types of awards and recognitions received by each of the service engineers, groups, and departments, • the response time for handling service process improvement proposals, • the overall change activity, including number, type, and size of changes, • the effect of implementing each process improvement compared to its defined goals, • overall performance of the organization’s and service’s processes, including effectiveness, quality, and productivity compared to their defined goals, • overall productivity and service quality trends for each service, and • process measurements that relate to the indicators of the customer’s satisfaction.
Verifying Implementation Verification 1
The activities for service process improvement are reviewed with senior management on a periodic basis. i The primary purpose of periodic reviews by senior management is to provide awareness of, and insight into, service process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
These reviews are held to: 1. Summarize participation in the process improvement activities. 2. Assess process performance. 3. Identify needed goal changes. 4. Resolve issues. 5. Approve revisions to the service process improvement plan as appropriate. Verification 2
The service quality assurance group reviews and/or audits the activities and work products for service process improvement and reports the results. Z Refer to the Service Quality Assurance key process area.
At a minimum, the reviews and/or audits verify that: 1. The preparation of the organization’s service process improvement plan.
8.3 Process Change Management
197
2. The process of initiating, submitting, reviewing, approving, and planning implementation of service process improvement proposals. 3. The degree to which process measurements conform to the service process descriptions and reflect actual performance. 4. The process for documenting, reviewing, approving, controlling, and disseminating changes to the organization’s standard service process and services’ defined service processes. 5. The degree to which service process improvement activities are consistently measured and tracked. 6. The degree to which actual service process improvement performance achieves the plans and goals.
198
The Key Process Areas for Level 5: Optimizing
Part III
Appendices
199
Appendix A
Acknowledgments This research was partly supported by the Dutch Ministry of Economic Affairs, projects ‘Concrete Kit’, nr. ITU94045, and ‘KWINTES’, nr. ITU96024. Partners in these projects are Cap Gemini, Twijnstra Gudde, the Tax and Customs Computer and Software Centre of the Dutch Tax and Customs Administration, and the Technical Universities of Delft and Eindhoven. We would like to thank the following people for their contribution to this document: • The contents of this document were partially developed under the supervision of the Kwintes IT Service CMM review board, which consisted of: Gerrit Matser, Rob Akershoek, Willem Bor, Ben Kooistra, Frank Eggink, Alexander Westra (Cap Gemini), Yolanda Louwinger, Johann Schreurs, Toos Lubbers (Tax and Customs Computer and Software Centre) and Ren´e Hombergen (Twijnstra Gudde). • Useful advice was given by: Jacques Bouman and Mark van der Zwan (Technical University of Eindhoven), Leo Ruijs (Cap Gemini), Thijs Sommers, Micha van der Velden, and Mark de Wijn (MSc students). • The members of the DOCIS project group for their contributions in specifying level three of the IT Service CMM. • Employees of the Rabobank Group that provided feedback on level two and three of the IT Service CMM. CMM, Capability Maturity Model, and Capability Maturity Modeling are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. Carnegie Mellon University and the Software Engineering Institute were not involved in the development of this model, nor are responsible for the content of this document.
201
202
Acknowledgments
Appendix B
Change history Version L2-1.0 has been released after level two of the model was considered to be complete and ready for use by the IT Service CMM Review Board. Preliminary versions were numbered 0.1, 0.2, 0.3, etc. The minor number was increased after each review by the review board. Dates are used to distinguish intermediate releases. Versions starting at L2+3-0.1 include all level three key process areas and are based on separately published DOCIS documents, see http://www.itservicecmm.org for details.
Change history: L2-0.0-980416 L2-0.0-980506 L2-0.0-980519
L2-0.0-980804
L2-0.1-981014
L2-0.1-981207
Added common features of Event Management, section 5.6. Added common features of Subcontract Management, section 5.4. Rewrite of section on design decisions, section 2.5. Added appendix C which compares ITIL with the IT Service CMM, not yet finished. Added common features of Service Quality Assurance, section 5.7. Changes with respect to the last release are marked with a gray bar in the margin. Some more text on the differences between ITIL and the IT Service CMM in appendix C. Split the document in two parts. Described Service Planning and Evaluation into much more detail. Added explanation of the common features, see page 13. Explained the more detailed key practice descriptions of the IT Service CMM as compared to the Software CMM, see section 2.5.2. Adjusted the activities of the Service Planning and Evaluation key process area. Described Configuration Management into much more detail, see section 5.5. Comments of Gerrit Matser processed. 203
204 L2-0.2-981210
L2-0.4-990118 L2-0.5-990208 L2-0.6-990301
L2-0.7-990325 L2-0.8-990416
L2-1.0 L2+3-0.1 L2+3-0.2 L2+3-0.3 0.4
0.5
1.0RC1
Change history Adapted Configuration Management to comments of review board, see section 5.5. Described Event Management into more detail, see section 5.6. Added overview to Event Management, see section 5.6. Described Service Tracking and Oversight in more detail, see section 5.3. Split Service Planning and Evaluation into Service Commitment Management and Service Delivery Planning, see sections 5.1 and 5.2. Adapted Service Tracking and Oversight to comments of review board, see section 5.3. Adapted Event Management to comments of review board, see section 5.6. Described Service Quality Assurance into more detail, see section 5.7. Described Subcontract Management into more detail, see section 5.4. Adapted Subcontract Management to comments review board, see section 5.4. More extensive index. New chapter (3) on the interpretation of the IT Service CMM. Small overview sections at start of each key process area in part II. Layout and other small changes. Added level three key process areas based on DOCIS project documents. Processed some of the review comments, added comparison of ITIL and IT Service CMM (Appendix B). Fixed layout problems introduced in L2+3-0.2. The changebars in this version are relative to L2+3-0.1. The changebars in this version are relative to L2+3-0.3. Changed versioning scheme to regular major.minor scheme. Renamed Event Management into Service Request and Incident Management to better reflect its contents. Rephrased goal and some practices of Service Commitment Management to more clearly indicate that both customer and IT service provider should agree to the service commitments. Made it more explicit that the service delivery plan should demonstrate the feasibility of the service commitments. Added explanations to goals. Added explanations and examples throughout the key process areas. Added mapping of key practices to goals (Appendix D). The changebars in this version are relative to release 0.4. Added the level four key process areas. This version was released internally only. The changebars in this version are relative to release 0.4. Added the level five key process areas.
Appendix C
The IT Service CMM and ITIL compared This appendix presents a brief comparison of the IT Service CMM and the new version of ITIL as described in [3, 13]. Four more ITIL books are planned, but these have not been published at the time of writing. First, we give an overview of ITIL in section C.1. Next, we discuss the main similarities and differences in section C.2.
C.1
IT Infrastructure Library
The IT Infrastructure Library (ITIL) is a framework of best practices for the support and delivery of IT services [13]. ITIL was originally developed by the British government through their Central Computer & Telecommunications Agency (CCTA). Nowadays, ITIL is being maintained by the Office of Government Commerce (OGC). 205
206
The IT Service CMM and ITIL compared
The library is currently being reorganised and will consist of several books that contain those ‘best practices’ in IT service delivery. Six books are currently planned, the first two of which are available at the time of writing [12]: • The Service Support book describes service desk, incident management, problem manage- ment, configuration management, change management, and release management. • The Service Delivery book covers capacity management, financial management for IT services, availability management, service level management, and IT service continuity management. • The Planning to Implement Service Management is to explain the steps necessary to identify
This needs
how an organisation might expect to benefit from ITIL, and how to set about reaping those updating benefits.
• The ICT Infrastructure Management book is to include network service management, opera- tions management, management of local processors, computer installation and acceptance, and systems management. • The Applications Management book will include the software development lifecycle, software lifecycle support and testing of IT services. • The Business Perspective book will cover business continuity management, partnership and
outsourcing, surviving change, and transformation of business practice through radical change.
Each of the processes is described by means of a selection of the following subjects: rationale, costs and benefits, basic concepts, planning and implementation, tools, methods and techniques, activities and interfaces with other processes.
C.2
Differences and Similarities
The main simularity between ITIL and the IT Service CMM is that they are both aimed at the domain of IT service management. The main difference is the difference in framework architecture. ITIL, on the one hand, is organized as a framework of best practices, organized by different processes. Currently, the organizing structure of ITIL is described in terms of ‘jigsaw puzzle pieces, some of which have a precise fit, and some of which overlap or do not fit together accurately’ [13]. The IT Service CMM, on the other hand, is organized as an ordered set of key process areas, that provide an improvement path for IT service providers. Further differences are: • ITIL provides more detail on process implementation and process activities than the IT Service CMM does. One can paraphrase this as saying that the IT Service CMM focuses more on the ‘what’ and the ITIL more on the ‘how’. • ITIL defines IT services as services delivered by IT, whereas the IT Service CMM defines IT services as services delivered by one party to another that maintain, operate, or improve the information technology.
C.2 Differences and Similarities
207
Table C.1 shows how the ITIL processes (from the Service Delivery and Service Support books) and IT Service CMM key process areas (level two and three) relate to each other. Because of the different nature of both frameworks, the relationship between the two is not a one-to-one mapping. Some IT Service CMM key process areas cover more than one ITIL process and vice versa. IT Service CMM Service Commitment Management Service Tracking and Oversight Subcontract Management Service Delivery Planning Service Request and Incident Management Configuration Management
ITIL Service Level Management
Service Desk Incident Management Configuration Management Change Management
Service Quality Assurance Financial Management for IT Services Organization Service Definition Organization Process Definition Organization Process Focus Integrated Service Management Service Delivery
Resource Management Training Program Intergroup Coordination Problem Management
Release Management IT Service Continuity Management Availability Management Capacity Management Availability Management
Problem Management
Table C.1: ITIL and IT Service CMM processes compared Most of the activities of ITIL process Service Level Management are covered by Service Commitment Management, Service Tracking and Oversight and Subcontract Management. There is no real counterpart for Service Delivery Planning in ITIL. The activities for Service Request and Incident Management are covered by the ITIL processes Service Desk and Incident Management. The IT Service CMM key process area Configuration Management is covered by the ITIL processes Configuration Management and Change Management. Service Quality Assurance has no clear counterpart in ITIL. Financial Management for IT Services has no counterpart in the IT Service CMM 1 The IT Service CMM level three key process areas Organization Service Definition, Organization Process Definition, Organization Process Focus and Integrated Service Management 1
Yet. It might become part of level four in the future.
208
The IT Service CMM and ITIL compared
have no clear counterpart in the ITIL. The reason for this is that the IT Service CMM assumes an organization will define its own processes, whereas ITIL provides those processes itself. Service Delivery is partly covered by the ITIL processes Release Management, IT Service Continuity Management, and Availability Management. Resource Management is comparable to the ITIL process Capacity Management and Availability Management. The IT Service CMM key process areas Training Program and Intergroup Coordination have no counterpart in ITIL. Finally, the IT Service CMM key process area Problem Management and the ITIL process Problem Management are very similar.
Appendix D
Mapping the Key Practices to Goals Since satisfying a key process area implies addressing each of the goals for that key process area, it may be helpful to understand the relationships between the key practices and the goals. The following tables map each of the key practices to its associated goal(s). Practices, like key process areas, are not independent of one another. Many key practices map to more than one goal. For example, there is usually only one policy statement per key process area, and it covers all of the goals for that key process area. Even when a practice is mapped to a single goal, there may be subpractices that contribute to achieving another goal. For example, the subpractice on planning evaluation of the service commitments in Activity 3 of Service Commitment Management contributes to Goal 2, even though the associated key practice contributes directly to Goal 1, as is indicated in this appendix. Note: if you are viewing this document with a PDF-viewer you should be able to click on the numbers below to jump to the relevant goal or practice. Service Commitment Management Goal Commitment Ability 1 1, 2 1, 2, 3 2 1, 2 1, 2, 3
Activity 3, 5 1, 2, 4, 6, 7
Measurement 1 1
Verification 1, 2, 3 1, 2, 3
Service Delivery Planning Goal Commitment Ability 1 1, 2 1, 2, 3 2 1, 2 1, 2, 3 3 1, 2 1, 2, 3
Activity 1, 2, 5, 6, 7, 10 1, 2, 3, 4, 8, 9 1, 3
Measurement 1 1 1
Verification 1, 2, 3 1, 2, 3 1, 2, 3
Activity 4, 5, 13, 15, 16 1, 6, 7, 8, 9, 10, 11, 12, 14 2, 3
Measurement 1 1
Verification 1, 2, 3 1, 2, 3
1
1, 2, 3
Service Tracking and Oversight Goal Commitment Ability 1 1, 2 3, 4, 5 2 1, 2 1, 2, 4, 5 3
1, 2
1, 2, 4, 5
209
210
Mapping the Key Practices to Goals
Subcontract Management Goal Commitment Ability 1 1, 2 1, 2 2 1, 2 1, 2, 3 3 1, 2 1, 2, 3
Activity 1, 2 3, 4, 5 6, 7, 8, 9, 10, 11, 12 3, 5, 8, 9
Measurement 1 1 1
Verification 2, 3 1, 2, 3 2, 3
1, 2
1, 2, 3
Activity 1, 2 2, 3, 4, 5 6, 7 8, 9, 10, 11
Measurement 1, 2 1, 2 1, 2 1, 2
Verification 2, 4 4 4 1, 2, 3, 4
Service Request and Incident Management Goal Commitment Ability Activity 1 1 1, 2, 3 1, 2 2 1 1, 2, 3 3, 4 3 1 1, 2, 3 3, 5, 6, 7
Measurement 1, 2 1, 2 1, 2
Verification 2, 4 4 1, 2, 3, 4
Service Quality Assurance Goal Commitment Ability 1 1 1, 2, 3 2 1 1, 2, 3, 4 3 1 1, 2, 3, 4 4 1 1, 2, 3, 4
Activity 1, 2 2, 3, 4, 5 6, 7, 8 7
Measurement 1 1 1 1
Verification 2, 3 2, 3 1, 2, 3 1, 2, 3
Organization Service Definition Goal Commitment Ability 1 1 1, 2 2 1 1, 2, 3
Activity 1, 2, 3, 4 4, 5
Measurement 1 1
Verification 1 1
Organization Process Definition Goal Commitment Ability 1 1 1, 2 2 1 1, 2
Activity 1, 2, 3 4, 5
Measurement 1 1
Verification 1 1
Organization Process Focus Goal Commitment Ability 1 1, 2, 3 1, 2, 3, 4 2 1, 2, 3 1, 2, 3, 4 3 1, 2, 3 1, 2, 3, 4
Activity 3, 4, 5, 6, 7 1 2
Measurement 1 1 1
Verification 1 1 1
4
1, 2
1, 2, 3
Configuration Management Goal Commitment Ability 1 1 2, 3, 4 2 1 1, 2, 3, 4 3 1 1, 2, 3, 4 4 1 1, 3, 4
211 Integrated Service Management Goal Commitment Ability 1 1 1, 2 2 1 1, 3
Activity 1, 2, 3 3, 4, 5, 6, 7, 8, 9, 10, 11
Measurement 1 1
Verification 2, 3 1, 2, 3
Measurement 2
Verification 1, 2, 3
1, 2, 3, 4
Activity 1, 2, 3, 4, 5, 6, 7, 8, 9 10
1
1, 2, 3
Intergroup Coordination Goal Commitment 1 1 2 1 3 1
Ability 1, 2, 3, 4, 5 1, 2, 3, 4, 5 1, 2, 3, 4, 5
Activity 1 3, 4, 5 2, 6, 7
Measurement 1 1 1
Verification 2, 3 2, 3 1, 2, 3
Training Program Goal Commitment 1 1 2 1 3 1
Ability 1, 2, 3, 4 1, 2, 3, 4 1, 2, 3, 4
Activity 1, 2, 3 3, 4 5, 6
Measurement 1 1, 2 1, 2
Verification 1, 3 1, 2 2, 3
Resource Management Goal Commitment 1 1 2 1 3 1
Ability 1, 2, 3 1, 2, 3 1, 2, 3
Activity 1, 2, 3 3, 4, 5, 6 7, 8, 9
Measurement 2 1, 2 1, 2
Verification 4 2, 4 1, 2, 3, 4
Problem Management Goal Commitment 1 1 2 1 3 1
Ability 1, 2, 3 1, 2, 3 1, 2, 3
Activity 1, 2, 3 3, 4, 5, 6 7, 8, 9
Measurement 2 1, 2 1, 2
Verification 4 2, 4 1, 2, 3, 4
Quantitative Process Management Goal Commitment Ability 1 1, 2 1, 2, 4, 5 2 1 1, 2, 3, 4, 5 3 2 1, 2, 3, 4, 5
Activity 1, 2, 3 2, 4, 5, 6 7
Measurement 1 1 1
Verification 2, 3 1, 2, 3 1, 3
Service Quality Management Goal Commitment Ability 1 1 1, 2, 3 2 1 1, 2, 3 3 1 1, 2, 3
Activity 1, 2 3, 5 2, 4
Measurement 1 1 1
Verification 2, 3 2, 3 1, 2, 3
Service Delivery Goal Commitment 1 1 2
1
Ability 1, 2, 3, 4
212
Mapping the Key Practices to Goals
Financial Service Management Goal Commitment Ability 1 1 1, 2, 3 2 1 1, 2, 3, 4 3 1 1, 2, 3, 4 4 1 1, 2, 3, 4
Activity 1, 2, 3 3, 4, 5 3, 4, 6 7, 8, 9
Measurement 2 1, 2 1, 2 1, 2
Verification 4 2, 4 2, 4 1, 2, 3, 4
Process Change Management Goal Commitment Ability 1 1, 2 1, 2, 3 2 1, 2 1, 2, 3, 4 3 1, 2 1, 2, 3, 4
Activity 2, 3, 4 1, 6, 10 4, 5, 7, 8, 9
Measurement 1 1 1
Verification 2 1, 2 1, 2
Technology Change Management Goal Commitment Ability 1 1, 2, 3 1, 2, 5 2 1, 2, 3 1, 2, 3, 4, 5 3 1, 2, 3 1, 2, 5
Activity 1 2, 4, 5, 6 3, 7, 8
Measurement 1 1 1
Verification 2 1, 2 1, 2
Problem Prevention Goal Commitment 1 1, 2 2 1, 2 3 1, 2
Activity 1, 2 3, 5 4, 6, 7, 8
Measurement 1 1 1
Verification 2, 3 3 1, 2, 3
Ability 1, 2, 3, 4 3, 4 1, 2, 3, 4
Bibliography [1] Roger Bate, Dorothy Kuhn, Curt Wells, James Armitage, Gloria Clark, Kerinia Cusick, Suzanne Garcia, Mark Hanna, Robert Jones, Peter Malpass, Ilene Minnich, Hal Pierson, Tim Powell, and Al Reichner. A Systems Engineering Capability Maturity Model, Version 1.1. Technical Report CMU/SEI-95-MM-003, Software Engineering Institute/Carnegie Mellon University, November 1995. [2] Jacques Bouman, Jos Trienekens, and Mark van der Zwan. Specification of Service Level Agreements, clarifying concepts on the basis of practical research. In Proceedings of the Software Technology and Engineering Practice conference, Pittsburgh, Pennsylvania, USA, August 30 - September 2, 1999. [3] Central Computer and Telecommunications Agency. Best Practice for Service Support. IT Infrastructure Library. The Stationary Office, London, UK, 2000. [4] Viktor Clerc and Frank Niessink. IT Service CMM, a pocket guide. ITSM Library Pocket Series. Van Haren Publishing, 2004. [5] Bill Curtis, William E. Hefley, and Sally Miller. Overview of the People Capability Maturity Model. Technical Report CMU/SEI-95-MM-01, Software Engineering Institute/Carnegie Mellon University, September 1995. [6] Bill Curtis, William E. Hefley, and Sally Miller. People Capability Maturity Model. Technical Report CMU/SEI-95-MM-02, Software Engineering Institute/Carnegie Mellon University, September 1995. [7] Khaled El Emam, Jean-Normand Drouin, and Walc´elio Melo, editors. SPICE: The Theory and Practice of Software Process Improvement and Capability Determination. IEEE Computer Society, 1998. [8] Pasi Kuvaja, Jouni Simil¨a, Lech Krzanik, Adriana Bicego, G¨unter Koch, and Samuli Saukkonen. Software Process Assessment and Improvement: The BOOTSTRAP Approach. Blackwell Publishers, 1994. [9] Frank Niessink. Perspectives on Improving Software Maintenance. PhD thesis, Division of Mathematics and Computer Science, Faculty of Sciences, Vrije Universiteit Amsterdam, the Netherlands, March 2000. Available from http://www.niessink.com/. 213
214
BIBLIOGRAPHY
[10] Frank Niessink and Hans van Vliet. Towards Mature IT Services. Software Process – Improvement and Practice, 4(2):55–71, June 1998. [11] Frank Niessink and Hans van Vliet. Software maintenance from a service perspective. Journal of Software Maintenance: Research and Practice, 12(2):103–120, March/April 2000. [12] The Office of Government Commerce. http://www.itil.co.uk.
IT infrastructure library online, June 2003.
[13] Office of Government Commerce. Best Practice for Service Delivery. IT Infrastructure Library. The Stationary Office, London, UK, 2001. [14] Mark C. Paulk, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis. The Capability Maturity Model: Guidelines for Improving the Software Process. SEI Series in Software Engineering. Addison-Wesley Publishing Company, 1995. [15] Leo Ruijs, Wouter de Jong, Jos Trienekens, and Frank Niessink. Op weg naar volwassen ICT-dienstverlening: Resultaten van het Kwintes-onderzoek. Perform Service Management. Academic Service, Schoonhoven, the Netherlands, 2000. [16] T. St˚alhane, P.C. Borgersen, and K. Arnesen. In Search of the Customer’s Quality View. The Journal of Systems and Software, 38(1):85–93, July 1997. [17] CMMI Product Team. Capability Maturity Model Integration (CMMI): CMMI for Systems Engineering and Software Engineering. Technical Report CMU/SEI-2002-TR-01, Software Engineering Institute/Carnegie Mellon University, December 2002. Continuous Representation. [18] CMMI Product Team. Capability Maturity Model Integration (CMMI): CMMI for Systems Engineering and Software Engineering. Technical Report CMU/SEI-2002-TR-01, Software Engineering Institute/Carnegie Mellon University, December 2002. Staged Representation. [19] J.M. Trienekens and M. van der Zwan. Zonder harde afspraken geen verbetering dienstverlening in IT. Automatisering Gids, (39):19–21, 27 September 1996. [20] J.M. Trienekens, M. van der Zwan, F. Niessink, and J.C. van Vliet. De SLA Specificatiemethode. Cap Gemini Perform Service Management. Academic Service, 1997. [21] Trillium Model – For Telecom Product Development and Support Process Capability. Model Issue 3.2, Bell Canada, May 1996.
Index process, 39, 47 Commitment to Perform, 13 commitments intergroup, see intergroup commitments service, see service commitments component, see IT component Concrete Kit, 1–3 configuration baseline, 14, 62, 64–68, 70, 71, 79, 115, 117, 142 item, 64, 65, 67–70, 75, 141–143 configuration control board, 21, 65, 68–71 Configuration Management, 20–23, 36, 40, 42, 64, 90, 102, 113, 115, 117, 122, Bootstrap, 12 129, 135, 142, 176, 190, 203, 204, business 207, 210 process, 33, 34 configuration management, 2, 42, 60, 62, 64– strategy, 33 71, 90, 95, 113, 135, 193 activities, 62, 64–67, 70, 71, 79 calamity, 35 group, 17, 32, 39, 41, 48, 50, 62, 65, 66, Capability Maturity Model, 1, 12, 13 69, 71, 73, 75, 92, 109, 115, 118, Capability Maturity Model Integration, 12 121, 129, 133, 136, 140, 142, 143, causal analysis 147, 155, 157, 171, 189 meeting, 173–175 library system, 65–67, 69, 70, 115, 135, CCTA, see Central Computer and Telecom164 munications Agency manager, 59 Central Computer and Telecommunications Agency, model, 113 205 plan, 66, 67 change, 64 record, 65, 67 request, 21, 22 report, 66 technology, 179, 181–184, 186 tool, 97 charging policy, 34, 85, 162, 164, 166 commitment, 1, 2, 25, 39, 49, 52, 55, 56, 60, customer, 1, 9–11, 14–26, 31–37, 43, 44, 47, 61, 120, 133 50, 53, 55–57, 59, 61, 65, 67, 69, 72, external, 32, 39 79–81, 83–86, 89, 96, 97, 102, 104, 109, 112, 114, 120–122, 124, 132, internal, 32, 39, 41, 42, 120, 124 Ability to Perform, 13 accounting system, 34, 162–165 action item, 37, 38, 46, 53–55, 61, 68, 70, 72, 75, 76, 99, 135, 137, 138, 142–144, 166, 167, 174–177 action proposal, 174, 175 Activities Performed, 14 actual service delivery, see service delivery, actual assessment, see process assessment, 96, 98 approach, 96 finding, 96 process, 93, 96–98, 192
215
216
INDEX 154, 156–162, 164–166, 190, 192, 193, 204
end user, 11, 15, 22, 25, 26, 34, 53, 54, 61, 65, 70, 73, 75, 95, 109, 112, 114, 115, 120–122, 124, 143, 154, 156– 160, 162, 179, 192, 193 estimate, see service estimate evaluation, see service evaluation Event Management, 203, 204 Financial Service Management, 20, 26, 34, 161, 212 financial service management, 162, 163, 165– 168 activities, 161–165, 167, 168 group, 163, 168 plan, 164, 168 group, 17, 17, 38, 46, 55 incident, 14, 18, 18, 21–23, 25, 50, 63, 72, 74– 76, 107, 116, 138, 141, 142, 150–152 Integrated Service Management, 20, 23– 25, 84, 87, 88, 94, 97, 99, 110, 111, 113, 122–124, 145, 153, 154, 169, 171, 176, 179, 185, 187, 194, 207, 211 intergroup commitments, 123, 124 issues, 120, 124, 125 Intergroup Coordination, 20, 23, 25, 106, 120, 207, 208, 211 internal commitments, see commitments, internal IPW Stadia Model, 12 IT component, 15, 15, 21, 22, 33, 34, 38, 41– 43, 48, 51, 55, 64–66, 71, 72, 101, 104–106, 111, 113–117, 119, 128, 133, 135–138, 142 IT Infrastructure Library, 2, 9, 12, 88, 93, 96, 203–208 IT service, 1, 9, 12, 14, 15, 15, 16, 21–26, 32– 34, 132, 161, 162, 164, 165, 205, 206 lemniscate, 2
management, 14, 206 maturity, 14 needs, 1, 21, 26, 31–34, 36, 37, 61, 135, 161 provider, 1, 9, 11, 12, 17, 19–22, 24–26, 31, 32, 34, 36, 38, 47, 64, 72, 83, 134, 161, 162, 165, 204, 206 IT strategy, 33 ITIL, see IT Infrastructure Library known error, 18 Kwintes, 1–3, 201 management, 22, 23 senior, see senior management manager, 16, 16, 17, 66, 73, 78, 139, 147, 163 maturity level, 1, 2, 19 measurement, 14, 26, 37, 45, 54, 63, 70, 71, 76, 81, 86, 92, 95, 98, 108, 109, 118, 119, 124, 125, 131, 137, 143–147, 149–151, 153, 155, 156, 158, 160, 167, 177, 180, 185, 186, 195, 196 data, 146–151, 156, 159 goal, 147, 149 plan, 92 program, 147–149, 154 Measurement and Analysis, 14 Office of Governement Commerce, 205 OGC, see Office of Governement Commerce organization, 13, 15–17, 17 Organization Process Definition, 20, 23, 24, 83–86, 97, 99–104, 134, 145, 150, 152, 176, 178, 179, 187, 194, 195, 207, 210 Organization Process Focus, 20, 23, 24, 88, 93, 153, 170, 185, 190, 207, 210 Organization Service Definition, 20, 23, 83, 207, 210 Pareto analysis, 174 People CMM, 12 pricing policy, 165 prime contractor, 56, 57, 59–62, 64
INDEX problem, 18, 18, 23, 25–27, 138, 139, 141– 144, 169, 173–176 analysis and diagnosis, 142 record, 140, 141 repository, 139, 143, 144 workload, 140 Problem Management, 17, 18, 20, 23, 25, 138, 207, 208, 211 problem management, 139, 143, 152 activities, 138–140, 142–144 group, 139, 140, 144 library system, 140, 141, 143 plan, 139–141, 143 procedure, 141 Problem Prevention, 8, 20, 27, 169, 212 problem prevention, 170, 171, 176–178 activities, 27, 169–172, 174–178 experiment, 175 problem prevention data, 175, 176 process capability, 145, 146 performance, 26, 145, 146, 151–153, 189, 191 Process Change Management, 20, 27, 169, 175, 179, 185, 186, 212 production environment, 64, 65, 69 Quality Function Deployment, 157 quantitative control, 146, 150, 151 Quantitative Process Management, 8, 20, 26, 145, 154, 159, 211 quantitative process management, 147, 148, 153, 154, 178 activities, 145, 147–149, 151, 153, 154 plan, 148 release plan, 114, 115, 117, 118 reliability, 156 request change, see change request service, see service request resource, 132–138 Resource Management, 20, 23, 25, 105, 106, 114–116, 132, 207, 208, 211
217 resource management, 132–135, 152 activities, 132–134, 136–138 group, 133, 138, 166, 167 library system, 134, 135, 137 plan, 114, 117, 118, 133, 134, 138 report, 133, 135 resource repository, 133, 136–138 risk management, 122, 124 plan, 108, 110 role, 16, 16, 17, 21 management, 16 root cause, 18, 173 category, 173 safety, 156 security, 156 SEI, see Software Engineering Institute senior management, 14, 16, 16, 27, 32, 36, 37, 45, 46, 49, 54, 63, 71, 76–79, 81, 82, 86, 94, 95, 97–99, 102, 110, 119, 125, 129, 131, 137, 144, 151–153, 157, 161, 163, 166–168, 177, 179, 180, 186, 187, 189–191, 196 service, 14, 14, 15, 16, 165, 166 activities, 14, 14, 15–17, 25, 35, 40, 43, 59, 60, 72, 77, 81, 149, 150, 159, 178 capability, 1 catalog, 23, 24, 83, 85, 86, 132 commitments, 15, 18, 21, 23, 25, 26, 31– 39, 41, 44, 47, 49–54, 56, 58–61, 65, 72, 75, 77, 80, 83, 85, 91, 100, 101, 106, 109, 111, 113, 117–120, 122, 124, 132, 133, 136, 141, 152, 157, 161, 162, 164, 166, 204, 209 condition, 35 delivery, 14, 15, 15, 21–23, 25, 26, 31, 32, 34, 39–42, 47, 49, 58, 65, 72, 79, 80, 93, 95, 99–101, 103, 104, 108, 109, 113, 120, 132, 145, 146, 148–152, 154–157, 159–162, 164, 178, 179, 181 actual, 15, 15, 22, 31, 35–38, 47, 48, 53–55, 57, 60, 61, 109, 111, 118, 124 effort and costs, 41, 43, 51
218
INDEX group, 17, 17, 25, 32, 36, 39, 42, 48– 50, 53, 57, 65–67, 69–71, 73, 75, 77– 81, 92, 96, 102, 106–108, 115, 118, 120–123, 125, 126, 128, 129, 133, 136, 140, 143, 145–148, 155–157, 164– 166, 171, 193 manager, 16, 36, 39–44, 47–50, 52, 53, 59, 61, 65, 69, 70, 79, 81, 86, 101, 102, 112, 123, 135–137, 143, 151, 152, 164, 166, 167 plan, 2, 20, 32, 35, 36, 39–41, 46–55, 59–61, 79–81, 92, 99, 103, 110, 111, 117, 118, 122, 170, 204 planning, 21, 38–40, 47, 48, 50, 66, 74, 79, 80, 85, 91, 101 risk, 37, 38, 41, 44, 46, 47, 52–55, 61, 101, 105, 107–109 schedule, 34, 35, 38, 41, 44, 52–54, 61, 106, 107, 123, 154 task leader, 151, 152 workload, 38, 41–43, 51, 104, 105, 165 engineer, 17, 40, 43–45, 178 estimate, 38, 165 evaluation, 35, 36, 48, 61 facilities, 38, 42, 45, 52 group, 17, 17, 65 level, 10, 15, 19–22, 24, 26, 64, 104, 154– 156, 158, 159 agreement, 1, 21, 22, 95 report, 22 manager, 16, 32, 33, 36, 38–41, 43, 44, 46, 47, 49, 53, 55, 57, 58, 63, 70, 71, 74–76, 78–82, 84, 97, 102, 110, 119, 125, 128, 129, 131, 137, 144, 152, 153, 161, 164, 166–168, 178, 188, 191, 195 process, 13, 15, 16, 93, 96, 145–147, 181, 186–188, 191, 193, 194, 197 activity, 148, 180, 189, 192 asset, 16, 16, 24, 86 database, 16, 84, 97, 100, 101, 104, 105, 110, 150, 152, 195 development and improvement activity,
88, 93, 95–98 improvement, 27, 186–197 improvement activity, 188, 190, 191, 195– 197 improvement group, 17, 24, 93, 95, 98, 102, 105, 147, 148, 170, 178, 180, 189 improvement plan, 190, 196 improvement proposal, 190–193, 195– 197 standard, 10, 15, 16, 16, 23–25, 27, 86– 91, 93, 94, 97, 99–102, 145, 146, 148– 150, 152, 153, 175, 176, 178, 179, 182, 183, 185, 187, 190, 194, 197 quality, 23, 155, 156, 158 goals, 26, 154–161 needs, 156, 157 plan, 156–161 request, 18, 18, 21–23, 25, 43, 50, 63, 72, 74–76, 116, 138, 141, 142, 150–152 type, 14, 16, 153 Service Commitment Management, 15, 19– 22, 31, 39, 48, 53, 54, 60, 61, 83, 109, 111, 118, 135, 166, 204, 207, 209 service commitment management activities, 33, 37, 38 service commitments subcontract, see subcontract service commitments Service Delivery, 20, 23, 25, 110, 154, 169, 207, 208, 211 service delivery activity, 7, 14, 14, 15, 17, 18, 23, 25, 38, 39, 41, 42, 44, 47–52, 62, 77, 80, 97, 110, 111, 117–119, 121, 150, 170 costs, see service delivery effort and costs task, 111, 113, 119, 149 Service Delivery Planning, 9, 20, 21, 36, 38, 47–52, 60, 99–101, 103, 105–107, 165, 204, 207, 209 Service Planning and Evaluation, 203, 204 service process
INDEX defined, 16, 16, 26, 27, 101, 145, 146, 148–152, 154–157, 169–171, 175, 176, 179, 185, 187, 194, 197 Service Quality Assurance, 20, 21, 23, 38, 46, 55, 63, 71, 77, 86, 93, 110, 119, 125, 138, 144, 154, 161, 168, 178, 186, 196, 203, 204, 207, 210 service quality assurance, 62, 78, 79, 81, 95, 125, 193 activities, 61, 62, 77, 78, 80–82 function, 78 group, 14, 17, 32, 36, 38, 39, 41, 46, 48, 50, 55, 61–63, 66, 71, 73, 77–82, 86, 92, 93, 109, 110, 118, 119, 121, 125, 129, 133, 138, 140, 144, 147, 152, 154, 155, 157, 161, 168, 171, 178, 186, 189, 196 manager, 59 plan, 79 records, 62 role, 78 Service Quality Management, 20, 26, 154, 173, 211 service quality management, 155–157, 161 activities, 155, 160 service request and incident information, 74 Service Request and Incident Management, 17, 18, 20–22, 50, 68, 72, 116, 141, 204, 207, 210 service request and incident management, 22, 48, 62–64, 72, 73, 76, 77 activities, 62, 72–77, 79 group, 17, 32, 36, 42, 48, 62, 65, 69, 70, 73, 77, 79, 115, 118, 140, 143, 147, 155, 157 library system, 63, 74, 76, 79, 141 personnel, 72 plan, 73, 74 report, 73, 74 service request and incident procedure, 60, 74 service request and incident record, 74 service request and incident repository, 72, 73, 75–77
219 service request and incident workload, 72, 74 service support activity, 14, 14, 15, 80, 150 service task leader, 17, 39, 48, 53, 79, 81 Service Tracking and Oversight, 20, 22, 23, 34, 35, 37, 47, 60, 63, 71, 76, 82, 99– 101, 103, 105–107, 110, 118, 119, 124, 125, 131, 137, 144, 153, 161, 166, 168, 178, 204, 207, 209 service tracking and oversight activities, 54, 55 Software CMM, 7, 12, 13, 15, 25, 90, 97, 108, 148, 157, 172, 182, 190, 203 Software Engineering Institute, 12 Software Product Engineering, 25 SPICE, 12 standard service, 23, 24, 83–87, 89, 94, 134, 135, 162, 165 subcontract, 56–61, 63, 160 management activities, 63 manager, 57, 59 service commitments, 56, 60, 61 Subcontract Management, 20–22, 32, 56, 160, 203, 204, 207, 210 subcontractor, 22, 56–64, 109, 114, 160 support tools, 38, 40, 42, 45, 48, 52, 58, 66, 68, 73, 78, 88, 96, 112, 121, 127, 139, 147, 156, 171, 181 Systems Engineering CMM, 12 Technology Change Management, 20, 27, 178, 212 technology change management, 179–183, 185, 186 activities, 180–185 training, 13, 26, 40, 66, 73, 96–98, 101, 112, 126–132, 140, 147, 148, 156, 171, 181, 182, 188, 189, 194 activities, 126, 128, 131 course, 95, 127, 130–132 group, 98, 127–130 material, 92 needs, 126–129, 189
220 plan, 128, 129, 131, 132 program, 23, 127, 128, 131, 132 record, 131, 132 vehicles, 126, 128 Training Program, 20, 23, 25, 84, 88, 96, 98, 101, 103, 112, 122, 125, 126, 148, 156, 164, 171, 182, 188–190, 194, 207, 208, 211 Trillium, 12 Verifying Implementation, 14
INDEX
