The IT Service Capability Maturity Model

The IT Service Capability Maturity Model Frank Niessink, Viktor Clerc and Hans van Vliet Software Engineering Research Centre, P.O.Box 424, 3500 AK, Utrecht, The Netherlands Tel: +31 30 2545412, Fax: +31 30 2545948, niessink, clerc @serc.nl Division of Mathematics and Computer Science, Faculty of Sciences, Vrije Universiteit De Boelelaan 1081a, 1081 HV, Amsterdam, The Netherlands Tel: +31 20 4447768, Fax: +31 20 4447653, J.C.van.Vliet@cs.vu.nl IT Service CMM Release L2+3-0.3 Status: Draft December 6, 2002 R CMM is registered in the U.S. patent and Trademark Office. Accuracy and interpretation of this document are the responsibility of Software Engineering Research Centre. Carnegie Mellon University has not participated in this publication.

Contents 1 Introduction 3 1.1 Origin of the IT Service CMM............................. 3 1.2 Structure of this document............................... 4 1.3 Other publications.................................... 4 I The IT Service CMM: Background, Concepts, Structure, and Usage 5 2 The IT Service Capability Maturity Model 6 2.1 The structure of the IT Service CMM......................... 6 2.2 Characteristics of the IT Service CMM......................... 6 2.3 Primary objectives of the IT Service CMM....................... 8 2.4 The maturity levels of the IT Service CMM...................... 8 2.5 Design choices..................................... 9 3 Interpreting the IT Service CMM 12 3.1 Interpreting the Key Practices.............................. 12 3.2 Interpreting the Common Features........................... 12 3.3 Service Concepts.................................... 13 3.4 Organizational Structure and Roles........................... 14 3.5 Problem Management.................................. 16 4 The Key Process Areas of the IT Service CMM 17 4.1 Level 1: Initial..................................... 17 4.2 Level 2: Repeatable................................... 17 4.3 Level 3: Defined.................................... 20 4.4 Level 4: Managed.................................... 23 4.5 Level 5: Optimizing................................... 23 II The Key Practices of the IT Service CMM 24 5 The Key Process Areas for Level 2: Repeatable 25 5.1 Service Commitment Management......................... 25 5.2 Service Delivery Planning.............................. 30 5.3 Service Tracking and Oversight........................... 37 5.4 Subcontract Management.............................. 44 1

5.5 Configuration Management............................. 51 5.6 Event Management.................................. 56 5.7 Service Quality Assurance.............................. 61 6 The Key Process Areas for Level 3: Defined 66 6.1 Organization Service Definition........................... 66 6.2 Organization Process Definition........................... 69 6.3 Organization Process Focus............................. 75 6.4 Integrated Service Management.......................... 80 6.5 Service Delivery.................................... 91 6.6 Intergroup Coordination............................... 98 6.7 Training Program................................... 103 6.8 Resource Management................................ 109 6.9 Problem Management................................ 114 III Appendices 121 A Change history 122 B The IT Service CMM and ITIL compared 124 B.1 IT Infrastructure Library................................ 124 B.2 Differences and Similarities............................... 125 C Mapping the Key Practices to Goals 127 2

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 requirements and service provider capabilities. Customers often cannot express their real service requirements and do not know the corresponding performance needs. Likewise, 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 [18]. The left part of the lemniscate concerns the specification of IT services (upper arrow) and the evaluation and monitoring of the performance of the 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 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 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. 3

specifying and quantifying SLA s tracking and evaluating service processes IT service needs Service Level Management Service Level Agreement Service Process Management Service process tracking and evaluating SLA s design and implementation of service processes Figure 1.1: IT Service Lemniscate 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 is coordinated by the Software Engineering Research Centre and involves participants from several universities and companies. As opposed to the Concrete Kit and Kwintes project, the DOCIS project is not sponsored by the governement and there is no formal project organisation. Participation is on a voluntary basis. Level three of the IT Service CMM focuses on organization-wide standardization and integration of the service processes. These practices include the definition of standard services, the definition of standard service processes, and the tailoring of these standard service process into defined service processes. Furthermore, level three contains practices on delivering consistent IT services effectively and efficiently and practices to establish a means for different service groups to participate actively with eachother so service delivery is more likely to satisfy the customer s needs. 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 in terms of their goals and common features. Note that so far only levels two and three of the IT Service CMM have been specified completely. The specification of the key practices of level four and level five remains to be done. Part III contains two appendices that describe the change history of this document and the differences and similarities between the IT Service CMM and the IT Infrastructure Library (ITIL). 1.3 Other publications Earlier reports on the IT Service CMM and related subjects have been published in [2, 8, 9, 10]. The results of the research projects Concrete Kit and Kwintes are summarized in two books (in Dutch) [13, 19]. 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

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. 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. 6

Maturity Levels Indicate Contain Process Capability Key process areas Achieve Organized by Goals Common features Address Contain Implementation or institutionalization Key practices Describe Activities or infrastructure Figure 2.1: The CMM structure (taken from [14]) 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,, etc., to reside on level. 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,, etc., before reaching level, 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 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 7

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 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, 12]. 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. 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 the 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 8

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. The organization is able to introduce new technologies and services into the organization in an orderly manner. 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 choices During the development of the IT Service CMM a number of design choices 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.1 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. 9

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. [15]. 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 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 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 service provider and customer need to evaluate the service on a regular basis: is the service still what the customer needs? Possibly, the 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 organization operates, sufficient emphasis should be on processes like the ones mentioned above, to be able to deliver quality IT services. See [8, 10] 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 1 Software obviously is not tangible, but it is still a product because of its other characteristics (a, b, and c). L23-0.1/29 10

of other capability maturity models, such as the People CMM [4, 5] and the Systems Engineering CMM [1]. Second, we wanted to provide organizations with a mechanism with which they can perform stepwise 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 [6], Bootstrap [7], or Trillium [20], 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 L23-0.1/1 IPW Stadia Model of Quint Wellington Redwood provides a framework for rating the maturity of ITorganizations as a starting point for ITIL-based change [3, 12]. CMM-I (CMM Integration) [16, 17] 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. 11

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 detemrine whether an organization has effectively implemented the key process area [14]. L2-1.0/15 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]: 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. 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. 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. 12

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. 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 project 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. The IT Service CMM key process areas mostly contain service support activities opposite 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. Information Technology service (IT service) A service of which the benefits 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 business-to-business services and business-to-consumer services. L3-0.2/57 13

Examples of the benefits provided by such IT services are the punctual payment of salaries, 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. Service delivery Service delivery denotes the execution of service activities, according to the planning of the service and according to the standard 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 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. A standard service process is a description of service activities to perform in order to deliver a certain service type. 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 of 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. 14

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. 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 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. L2-1.0/3 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 could 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 delivery process 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 event 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. 15

3.5 Problem Management This section provides definitions of terms used in the Problem Management key process area. They are taken from [3]. 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. Problem Unknown underlying cause of one or more 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. 16

Chapter 4 The Key Process Areas 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 for that maturity level and those for lower levels. The term key process area merely means that these processes are seen as the key to reach a certain maturity level. There might be more non-key processes, but these are not strictly necessary to reach the next maturity level. L23-0.1/5 Table 4.1 gives an overview of 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. 1 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 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 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). To ensure that the service levels are realistic, the service provider draws up a service plan that shows 1 Note that because the model is still under development, the key process areas for level four and five have been specified in less detail than the level two and three key process areas. 17

Process categories Levels Optimizing Management Enabling Delivery Service planning, management, etc. Support and standardization. Process Change Management Actual service delivery. Technology Change Management Problem Prevention Managed Quantitative Process Management Service Quality Management Defined Repeatable Initial Integrated Service Management Service Commitment Management Service Delivery Planning Service Tracking and Oversight Subcontract Management Organization Service Definition Organization Process Definition Organization Process Focus Training Program Intergroup Coordination Resource Management Problem Management Configuration Management Event Management Service Quality Assurance Ad hoc processes Service Delivery Table 4.1: Key process areas, assigned to process categories the feasibility of the service levels (Service Delivery Planning). During service delivery, the 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 period of service provision, the customer and the service provider review the service level agreement to see whether it still conforms to the IT 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, al- 18

most all IT services concern the management, operation or maintenance of hardware and software 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, events can occur that need to be resolved by the service provider. These events range from simple requests for service to serious incidents that prevent the customer from using its information technology. All these events need to be identified, tracked, resolved and reported to the customer (Event Management). To handle the service request and to resolve incidents, changes to the configuration may be necessary. The change requests are evaluated by the configuration control board 2 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). Finally, to ensure the quality of the services, the service provider deploys quality assurance techniques, such as reviews and audits (Service Quality Assurance). 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 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. 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 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 IT subcontractors and manage them effectively. 2 Note that this is a role, and not an actual organizational unit. 19

The service provider can select and hire subcontractors to delegate parts of the service. If this is the case, the service to be delivered by the subcontractors is laid down in a service level agreement. The service provider keeps track of the actual services delivered by the 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 hardware and software components which need to be put under configuration control. This includes components owned by the customer that are being managed by the 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. Event Management: Purpose: Events regarding the service are identified, registered, tracked, analyzed, and resolved. The status of events is communicated with the customer and reported to management. This key process area concerns the management of events that causes or might cause service delivery to deviate from the agreed upon service levels. Events can be either: Requests for service from 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 requests for service and incidents, changes to the configuration might be necessary. The decision whether to implement the change request that results from a service request or 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, service 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 and audits. Note that where Service Tracking and Oversight is concerned with measuring service quality in retrospect, from an external point of view, Service Quality Assurance is concerned with measuring quality in advance, from an internal point of view. 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. 20

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 events occuring during different service deliveries are analyzed (Problem Management) and resources are negiotiated 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: Purpose: Develop and maintain a set of standard services for the organization and collect information related to the delivery of these standard services. The description of the standard services is called a service catalog. This service catalog contains a specificaiton of the services in terms of benefits for the customer. The service catalog also includes the service levels that the provider can guarantee and the price of the services. 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 process used to deliver the services defined in the service catalog. 3. Organization Process Focus: Purpose: Establish organizational responsibility for service process activities that improve the organization s overall service process capability. This key process areas covers the activities needed to assess, develop, maintain and improve the organization s service processes are resourced and coordinated across current and future services. A 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. 21

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 service provider. Procedures need to be put in place on how these reports will be delivered to the service provider and whether the helpdesk or the 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 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. 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 services defined 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. 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, it is necessary to train employees to perform their roles. This is not possible at level two, since standard organization-wide 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. 9. Problem Management: Purpose: Remove problems from the IT that is managed, maintained or operated by the service provider. This key process area implements the organization-wide investigation of events and weak spots L23-0.1/6 22

that occur during service delivery. Practices like root-cause analysis 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). There are two level four key process areas: 1. Quantitative Process Management: Purpose: Control the process performance and costs of the service delivery quantitatively. 2. Service Quality Management: Purpose: Develop a quantitative understanding of the quality of the services delivered and achieve specific quality goals. 4.5 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. 2. Technology Change Management: Purpose: Identify new technologies and inject them into the organization in an orderly manner. 3. Problem Prevention: Purpose: Identify the cause of problems and prevent them from recurring by making the necessary changes to the processes. 23

Part II The Key Practices of the IT Service CMM 24

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. L2-1.0/15 L2-1.0/2 Goals Goal 1 Goal 2 Service commitments are documented. Service commitments are based on current and future IT service needs of the customer. Commitment to Perform Commitment 1 A service manager is designated to be responsible for negotiating service commitments. 25

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. Which other groups and individuals are affected is context dependend, but may include groups such as the configuration management group, event management group, and the resource management group. L2-1.0/3 6. The service commitments are evaluated periodic basis. 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 Ability 3 Adequate resources and funding are provided for developing the service commitments. Service managers are trained to perform their service commitment management activities. 26

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. L2-1.0/5 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: 1. The purpose, scope, and goals of the services to be delivered. 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. 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 13. 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. 27

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. 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. 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. 4. The service delivery schedule. The service delivery schedule specifies when certain service activities will take place that have an effect on the service levels. Examples of such activities are: the delivery and installation of new software releases, planned outage of systems for maintenance purposes, upgrading hardware due to increasing performance demands. 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. 5. Specification of the service conditions. 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). 6. Specification of calamities. 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 such situations are: natural disasters such as earthquakes, storms, tidal waves, civil unrest, strikes, riots, war, power failures, telecommunication failures. 7. Agreements on reviewing actual service delivery. 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. Refer to the Service Tracking and Oversight key process area for practices concerning the tracking of actual service delivery. Refer to Activity 13 of the Service Tracking and Oversight key process area for practices concerning the review of actual service delivery. 8. Planning of service evaluation. 28

Part of the service commitments are agreements on how and when the service commitments will be evaluated. Refer to Activity 4. Activity 4 Service commitments are evaluated with the customer on both a periodic and an event-driven basis. 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 evaluation of the service commitments are synchronized with the L2-1.0/7 business planning of the customer, as appropriate. 2. The current IT service needs of the customer are identified and documented. 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. 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 5 Actual service delivery is evaluated with the customer on both a periodic and an event-driven basis. Measurement and Analysis 1. Actual service delivery is compared with the service commitments. Refer to the Service Tracking and Oversight key process area for practices concerning the tracking of actual service delivery. Refer to Activity 13 of the Service Tracking and Oversight key process area for practices concerning 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 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. 29

Verifying Implementation Verification 1 The service commitment management activities are reviewed with senior management periodic basis. 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 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 commitment management 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. 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 L2-1.0/7 30

workload, effort and costs; the service delivery schedule; identification of risks, and plans for service facilities and tools. In addition, planning data needs to be recorded so that it can be used for the planning of future services. Goals Goal 1 Goal 2 Goal 3 Service estimates are documented for use in planning and tracking the actual service delivery. Service delivery activities and internal commitments are planned and documented. Affected groups and individuals agree to their commitments related to the service delivery. Commitment to Perform Commitment 1 A service delivery manager is designated to be responsible for negotiating L2-1.0/7 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. 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 s planning: 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, documentation support. 31

Ability to Perform 4. The service delivery plan is managed and controlled. 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 1 Responsibilities for developing the service delivery plan are assigned. 1. The service delivery manager, directly or by delegation, coordinates the de- L2-1.0/2 velopment 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: 1. The service delivery plan is based on and conforms to: the service delivery standards, as appropriate, and 32

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. Refer to Activity 3. 4. Estimated use of hardware and software resources. Refer to Activity 4. 5. Estimated service delivery workload. Refer to Activity 5. 6. Estimates of the service delivery effort and costs. Refer to Activity 6. 7. The service delivery schedule. Refer to Activity 7. 8. Identification and assessment of the service delivery risks. Refer to Activity 8. 9. Plans for the service delivery facilities and support tools. 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: 33

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 activity planning is documented, reviewed, and agreed to. Examples of groups and individuals who review and agree to the planning of service delivery activities include: the service delivery manager, and the service delivery group. Activity 4 Software and hardware products that are needed to establish and maintain control of the service delivery are identified. Refer to Activity 4 of the Configuration Management key process area. Activity 5 Estimates for the service delivery workload are derived according to a documented procedure. 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 workload estimates include: the service manager, the service delivery manager, 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. 2. Productivity data (historical and/or current) are used for the estimates when available; sources and rationales for these data are documented. 34

3. Effort, staffing, and cost estimates are based on past experience. 4. Estimates and the assumptions made in deriving the estimates are documented, reviewed, and agreed to. Activity 7 The service delivery schedule is derived according to a documented procedure. This procedure typically specifies that: 1. The service delivery schedule is related to: the service delivery workload estimates, and the service delivery effort and costs estimates. 2. The service delivery schedule is based on past experience. Delivery of similar services to other customers are 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, and documented. 1. The risks are analyzed and prioritized based on their potential impact to the service quality levels. 2. Contingencies for the risks are identified and arranged for. Examples of contingencies include: schedule buffers, making backups of datafiles, alternative staffing plans, and alternative plans for additional computing facilities. Activity 9 Activity 10 Plans for the service facilities and support tools are prepared. Service planning data are recorded. Measurement and Analysis 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 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. 35

Verifying Implementation Verification 1 The service delivery planning activities are reviewed with senior management periodic basis. Verification 2 Verification 3 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. The service delivery planning activities are reviewed with the service delivery 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. The service quality assurance group reviews and/or audits the service delivery planning activities and work products and reports the results. 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. L2-1.0/15 36

5.3 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. L2-1.0/16 Goals Goal 1 Goal 2 Goal 3 Actual service delivery is tracked against the specified service levels and reported to the customer. Corrective actions are taken and managed to closure to prevent actual service delivery to deviate from the specified service levels. Changes to the service delivery planning are agreed to by the affected groups and individuals. Commitment to Perform Commitment 1 Commitment 2 A service delivery manager is designated to be responsible for the actual service delivery. 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. 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. Refer to Activity 4 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 estimating, service quality assurance group, and configuration management group. 37

Ability to Perform Ability 1 A service delivery plan is documented and approved. 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 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 hardware and software resources. 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, event management ( service desk ) software, and project planning/scheduling programs. Ability 4 The service delivery managers are trained in managing the technical and personal 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. 38

Activities Performed Activity 1 A documented service delivery plan is used for tracking the service delivery activities and communicating status. 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: the service delivery group, the service managers, the service delivery managers, senior management, and other affected groups. Activity 2 The service delivery plan is revised according to a documented procedure. 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. 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. 39

3. Changes in actual service levels that affect service commitments are negotiated with affected groups and are documented. Activity 5 The service delivery workload is tracked, and corrective actions are taken as necessary. Refer to Activity 5 of the Service Delivery Planning key process area for practices covering the derivation of service 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 6 The service delivery activities costs and effort are tracked, and corrective actions are taken as necessary. Refer to Activity 6 of the Service Delivery Planning key process area for practices covering the derivation of cost and effort 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. Activity 7 The service facilities are tracked, and corrective actions are taken as necessary. Refer to Activity 9 of the Service Delivery Planning key process area for practices covering the planning of service facilities. 1. The actual and projected use of service facilities are tracked and compared to the estimates as documented in the service delivery plan. 2. Changes in the estimated use of service facilities that affect the service commitments are negotiated with the affected groups and are documented. Activity 8 The service delivery schedule is tracked, and corrective actions are taken as necessary. Refer to Activity 7 of the Service Delivery Planning key process area for practices covering the derivation of the service delivery schedule. 40

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 9 The service delivery activities are tracked, and corrective actions are taken as necessary. 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 periodic basis. 2. Deviations from the service delivery planning in any of the service delivery activities are identified, recorded, reviewed, and tracked to closure. Refer to Activity 4 of the Event Management key process area for practices covering the management of events. Activity 10 The service delivery risks associated with cost, resource, schedule and technical aspects of the services are tracked. 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 periodic basis. Activity 11 Actual measurement data and replanning data for the service are recorded and made available. 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. 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. 41

Activity 12 Activity 13 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. Formal reviews to address the accomplishments and results of the services are conducted with the customer at selected moments according to a documented procedure. 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. 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. Refer to Activity 4 of the Service Commitment Management key process area for practices concerning the evaluation of service commitments and actual service delivery. Formal reviews to address the accomplishments and results of the services are conducted at selected moments according to a documented procedure. 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. Refer to Activity 4 of the Service Commitment Management key process area for practices concerning the evaluation of service commitments and actual service delivery. 42

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 periodic basis. 1. The technical, cost, staffing, schedule, and service delivery 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 status report from each meeting is prepared and distributed to the affected groups. 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 hardware and software resources is reviewed; current estimates and actual use of these resources 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. 43

Verification 3 The service quality assurance group reviews and/or audits the service tracking and oversight activities and work products and reports the results. 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. 5.4 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 eachother. The prime contractor remains responsible for the service to be delivered to the customer. L2-1.0/16 Goals Goal 1 Goal 2 Goal 3 Goal 4 The prime contractor selects qualified service subcontractors. The prime contractor and the service subcontractor agree to their commitments to each other. The prime contractor and the service subcontractor maintain ongoing communications. The prime contractor tracks the service subcontractor s actual results and performance against its commitments. 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. 44

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. 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. 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. 45

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. 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. 46

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. Effective management of some subcontracts may require frequent face-to-face 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. Activity 3 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. 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: event management 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. 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. Refer to Activity 2 of the Service Delivery Planning key process area for practices covering the content of the service delivery plan. 47

Activity 5 A documented and approved service subcontractor s service delivery plan is used for tracking the service activities and communicating status. Refer to the Service Tracking and Oversight key process area for practices concerning the tracking of services. 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. 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. Refer to Activity 4 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. Refer to Activity 5 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 services are conducted with the service subcontractor at selected moments according to a documented procedure. 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. Refer to Activity 7 and 8. 48

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. 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 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 event management group monitors the service subcontractor s event management activities according to a documented procedure. This procedure typically specifies that: 1. The service subcontractor s plans, resources, procedures, and standards for event management are reviewed to ensure they are adequate. 2. The prime contractor and the service subcontractor coordinate their activities on matters relating to event management to ensure that the event management activities are sufficiently integrated. 49

Measurement and Analysis 3. The service subcontractor s event management library is periodically audited to assess how well the standards and procedures for event management are being followed and how effective they are in event management. 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 events handled 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 periodic basis. Refer to Activity 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 delivery manager on both a periodic and an event-driven basis. Refer to Activity 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. 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. 3. The activities for coordinating configuration management and event 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. 50

5.5 Configuration Management Purpose The main purpose of the Configuration Management key process area is to establish control over all IT products that are needed to properly deliver the services. These IT products are identified and recorded in the configuration baseline. In addition, changes to the IT products are controlled. L2-1.0/16 Goals Goal 1 Goal 2 Goal 3 Goal 4 Configuration management activities are planned. Selected hardware and software products are identified, controlled, and available. Changes to the identified hardware and software products are controlled. Affected groups and individuals are informed of the status and content of configuration baselines. 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. 2. CM is implemented throughout the service s life cycle. 3. CM is implemented for all external hardware and software subject to the service commitments, and designated internal hardware and software used for service delivery. 4. A repository for storing configuration items and/or the associated CM records is made available. 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. Work products that are placed under configuration management are referred to as configuration items. 5. The configuration baselines and CM activities are audited 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): 51

1. Authorizes the establishment of configuration baselines and the identification of configuration items. 2. Represents the interests of the service manager and all groups who may be affected by changes to the configuration baselines. Examples of affected groups include: service delivery group, event management group, end users. 3. Reviews and authorizes changes to the configuration baseline. 4. Authorizes the creation of products from the configuration baseline. 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 baseline library. 2. Development, maintenance, and distribution of the CM plans, standards, and procedures. 3. The identification of the set of software and hardware products to be placed under CM. 4. Management of the access to the configuration baseline library. 5. Updates of the configuration baseline. 6. Creation of products from the configuration baseline library. 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 engineers. 52

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. 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. 53

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. Examples of work products that may be identified as configuration items include: process-related documentation (e.g. plans, standards, or procedures), software requirements, test procedures, 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. Refer to the key process area Event Management for practices concerning the management of action items. Activity 6 Changes to configuration baselines are controlled according to a documented procedure. This procedure typically specifies that: 1. Reviews and/or tests are performed to ensure that changes have not caused unintended effects on the configuration baseline. 2. Only configuration items that are approved by the CCB are entered into the baseline library. 3. Configuration items are checked in and out in a manner that maintains the correctness and integrity of the baseline library. Examples of check-in/out steps include: verifying that the revisions are authorized, creating a change log, maintaining a copy of the changes, updating the baseline library, and archiving the replaced configuration baseline. Activity 7 Products from the configuration baseline are created and released according to a documented procedure. This procedure typically specifies that: 54

1. The CCB authorizes the creation of products from the baseline library. 2. Products from the baseline library, for both internal and external use, are built only from configuration items in the baseline library. Activity 8 The status of configuration items/units is recorded according to a documented procedure. 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 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. 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 baselines is assessed. 3. The structure of and facilities of the configuration management library system are reviewed. 4. The completeness and correctness of the 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. 55

Measurement and Analysis Measurement 1 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 Verification 2 Verification 3 Verification 4 The CM activities are reviewed with senior management periodic basis. The CM activities are reviewed with the service manager on both a periodic and an event-driven basis. The CM group periodically audits configuration baselines to verify that they conform to the documentation that defines them. The service quality assurance group reviews and/or audits the CM activities and work product and reports the results. 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. 5.6 Event Management Purpose The main purpose of the key process area Event Management is to identify, record, track, analyse, and resolve events that occur during service delivery. An event is an occurrence that if not resolved eventually will cause the service provider to break its service commitments. Note that it does not matter whether the service provider knows that the event has happened. Two types of events are distinguished: service requests and incidents. 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. Events are always concerned with one or more IT components. Events are resolved by action items. L2-1.0/16 56

Goals Goal 1 Goal 2 Goal 3 Event management activities are planned. Events are identified, recorded, analyzed, tracked, and resolved. Affected groups and individuals are informed of the status of events and action items. Commitment to Perform Commitment 1 A written organizational policy is followed for implementing event management (EM). This policy typically specifies that: 1. Responsibility for EM for each service is explicitly assigned. 2. EM is implemented throughout the duration of the service commitments. 3. A repository for storing event information is made available. 4. The event repository and EM activities are audited periodic basis. Ability to Perform Ability 1 A group that is responsible for coordinating and implementing EM for the service (i.e., the EM group) exists. The EM group coordinates or implements: 1. Creation and management of the service s event repository. 2. Development, maintenance, and distribution of EM plans, standards, and procedures. 3. Management of the access to the event repository. 4. Changes to the event repository. 5. Recording of EM activities. 6. Production and distribution of EM reports. Ability 2 Adequate resources and funding are provided for performing the EM activities. 1. A manager is assigned specific responsibility for EM. 2. Tools to support the EM activities are made available. Examples of support tools include: workstations and/or portable computers, event management software. 57

Ability 3 Members of the EM group and related groups are trained in the objectives, procedures, and methods for performing their EM activities. Examples of related groups include: service quality assurance group, configuration management group, end users, and service engineers. Examples of training include: the standards, procedures, and methods to be followed for EM activities, and the role, responsibilities, and authority of the EM group. Activities Performed Activity 1 An EM plan is prepared for each service according to a documented procedure. This procedure typically specifies that: 1. The EM plan is developed in the early stages of, and in parallel with, the overall service delivery planning. 2. The EM plan is reviewed by affected groups. 3. The EM plan is managed and controlled. Activity 2 A documented and approved EM plan is used as the basis for performing the EM activities. The plan covers: 1. Estimates of the event workload. 2. The EM activities to be performed, the schedule of the activities, the assigned responsibilities, and the resources required (including staff, tools, and computer facilities). Activity 3 An event management library system is established as a repository for the event records. This library system: 1. Provides for the storage, update, and retrieval of event records. 2. Provides for the sharing and transfer of event records between affected groups. 3. Helps in the use of event management procedures. Refer to Activity 4. 4. Provides for the archival and retrieval of historic event information. 5. Supports production of EM reports. 58

Activity 4 Events are identified, recorded, analyzed, reviewed, and resolved according to a documented procedure. This procedure typically specifies that: 1. The events are recorded in sufficient detail so that the content and the status of each event are known. This typically includes: a unique identifier, description of the event, date and time of occurrence, name and contact information of the person who reported the event, the configuration items concerned, and relevant characteristics of the situation in which the event occurred. 2. The impact of the event to the service commitments is assessed and documented. 3. Action items resulting from events are: identified, assessed for risk, documented, planned, initiated, communicated to the affected groups and individuals, tracked to closure, and evaluated. Activity 5 Affected groups and individuals are informed of the status of events 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 EM activities and the contents of the event repository are developed and made available to affected groups and individuals. Examples of reports include: event description and status, action item description and status, summary of events by configuration item, and summary of events during a certain period. 59

Activity 7 Event 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 event repository is assessed. 3. The facilities of the event management library system are reviewed. 4. The completeness and correctness of the repository are verified. 5. Compliance with applicable EM 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 events in the event repository. Examples of measurements include: number of events unresolved, average leadtime of closed events, percentage of events not closed within the maximum time. Measurement 2 Measurements are made and used to determine the status of the EM activities. Examples of measurements include: number of events processed per unit time, number of action items completed per unit time, and effort expended and funds expended in the EM activities. Verifying Implementation Verification 1 Verification 2 Verification 3 Verification 4 The EM activities are reviewed with senior management periodic basis. The EM activities are reviewed with the service manager on both a periodic and an event-driven basis. The EM group periodically audits event repositories to verify that they conform to the documentation that defines them. The service quality assurance group reviews and/or audits the EM activities and work products and reports the results. 60

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. L2-1.0/15 Goals Goal 1 Goal 2 Goal 3 Goal 4 Service quality assurance activities are planned. Adherence of services and service activities to the applicable standards, procedures and service commitments is verified objectively. Affected groups and individuals are informed of service quality assurance activities and results. Noncompliance issues that cannot be resolved within the service delivery group are addressed by senior management. 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. Commitment 2 Senior management periodically reviews the SQA activities and results. Ability to Perform Ability 1 Ability 2 A group that is responsible for coordinating and implementing SQA for the service (i.e. the SQA group) exists. Adequate resources and funding are provided for performing the SQA activities. 1. A manager is assigned specific responsibilities for the service s SQA activities. 61

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 communications. Ability 4 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 event management group as well as the service task leaders). 3. The SQA plan is managed and controlled. 62

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. Resources 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: event management activities, event management library, 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. 8. Procedures for documenting and tracking noncompliance issues to closure. 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 that 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. 63

1. The activities are evaluated against the service delivery plan and the designated service standards and procedures. 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 Activity 6 The SQA group periodically reports the results of its activities to the service delivery group. 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, k 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 7 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. Verifying Implementation Verification 1 The SQA activities are reviewed with senior management periodic basis. Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews. 64

Verification 2 Verification 3 The SQA activities are reviewed with the service manager on both a periodic and an event-driven basis. Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of management oversight reviews. Experts independent of the SQA group periodically review the activities and work products of the SQA group. 65

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 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 service providers this may be dictated by the business of the customer, for other 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). L2-1.0/15 L3-0.2/60 Goals Goal 1 Goal 2 Standard services of the organization are developed and maintained. Information related to the delivery of the organization s standard services is collected, reviewed, and made available. 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. 66

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. 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 Ability 2 Adequate resources and funding are provided for developing and maintaining the organization s standard services. The individuals who develop and maintain the organization s standard services receive required training to perform these activities. Refer to the Training Program key process area. Ability 3 Historical information on the delivery of the organization s standard services is available. Refer to Activity 4 of the Organization Process Definition key process area for practices covering the service process database. Activities Performed Activity 1 Activity 2 Activity 3 The organization s standard services are developed and maintained according to a documented procedure. The organization s standard services are documented according to established organization standards. 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, 67

Examples of tailoring include: adapting the standard service for a specific hardware environment, 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. Measurement and Analysis 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. Refer to Activity 4 of the Organization Process Definition key process area for practices covering the service process database. 4. The service catalog is managed and controlled. Measurement 1 Measurements are made and used to determine the status of the organization s service definition activities. Examples of measures 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. Refer to the Service Quality Assurance key process area. At a minimum, these reviews and/or audits verify that: 68

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. L3KPAS- 0.2/3 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 processes, along with related process assets, such as descriptions of process tailoring guidelines and criteria, the organization s service process database 1 and a library of service processrelated documentation. 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). L2-1.0/15 L23-0.1/8 Goals Goal 1 Goal 2 A standard service process for the organization is developed and maintained. Information related to the use of the organization s standard service process to deliver services is collected, reviewed, and made available. Commitment to Perform Commitment 1 The organization follows a written policy for developing and maintaining a standard service process and related process assets. 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 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. 69

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. 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. The organization s standard service process may contain multiple service processes. Multiple service processes may be needed to deliver different services, or to address the needs of different customers, technologies, and tools. 3. A service s defined service process is a tailored version of the organization s standard service process. 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). Refer to the Organization Process Focus key process area for practices covering the group responsible for the organization s service process 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. 70

Examples of training include: service delivery practices and methods such as the IT Infrastructure Library, process analysis and documentation methods, and process modeling. Refer to the Training Program key process area. 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. 71

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. 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. 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. 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. 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. L3KPAS- 0.2/8 L3KPAS- 0.2/7 72

3. The relationships of the process elements are described and address: the ordering, the interfaces, and the interdependencies. 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, 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. 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. 73

4. User access to the database contents is controlled to ensure completeness, integrity, and accuracy of the data. 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, A service s service delivery plan, A service s 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, configuration management, 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. L23-0.1/9 Examples of measurements include: status of the schedule milestones for process development and maintenance, and costs for the process definition activities. 74

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. 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. L2-1.0/15 Goals Goal 1 Goal 2 Goal 3 Service process development and process improvement activities are coordinated across the organization. The strengths and weaknesses of the service processes used are identified relative to a process standard. Organization-level process development and improvement activities are planned. 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: 75

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. 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 commitments 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 improvement and development. Senior management: 1. Ensures that the organization s standard service process supports its business goals and strategies. 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 activities exists. 76

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. This group is normally called the service delivery process 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, user support, software operation, configuration management, and service quality assurance. Ability 2 Adequate resources and funding are provided for the organization s service process 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 activities are made available. Examples of support tools include: statistical analysis tools, desktop publishing tools, database management systems, and process modeling. Ability 3 Members of the group responsible for the organizations service process 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. 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 activities and their roles in those activities. 77

Refer to the Training Program key process area. Activities Performed Activity 1 The service process is assessed periodically, and action plans are developed to address the assessment findings. Assessments are typically conducted every 1.5 to 3.0 years. Assessments look at all service processes used in the organization, but may do this by sampling process areas and specific service deliveries. Depending on the goal of the assessment, an appropriate assessment approach is to be chosen. L3KPAS- 0.2/9 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 Activity 3 The organization develops and maintains a plan for its service process development and improvement activities. This plan: 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. 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. The activities for developing and improving the service processes are coordinated at the organization level. This coordination covers the development and improvement of: 1. The organization s standard service process. 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. Refer to Activities 1 and 2 of the Integrated Service Management key process area for practices covering the service s defined service process. L3KPAS- 0.2/10 78

Activity 4 The use of the organization s service process database is coordinated at the organizational level. 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. 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 and service s service processes is coordinated across the organization. 1. Plans for training on subjects related to the organization s and service s service processes are prepared. 2. Where appropriate, training may be prepared and conducted by the group responsible for the organization s service process activities (e.g., service delivery process group) or by the training group. Refer to the Training Program key process area. Activity 7 The groups involved in implementing the service processes are informed of the organization s and service 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 process development and improvement activities. 79

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. 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 L3KPAS- 0.2/11 80

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 Goal 2 The service s defined service process is a tailored version of the organization s standard service process. The service delivery is planned and managed according to the service s defined service process. 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. 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. Each service documents the service s defined service process by tailoring the organization s standard service process. 2. The service s deviations from the organization s standard service process are documented and approved. 3. Each service performs its service activities in accordance with the service s defined service process. 4. Each service collects and stores appropriate service measurement data in the organization s service process database. 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. 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. Ability 2 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. 81

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 delivery. 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. 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. 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. 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. Refer to Activity 2 of the Organization Process Definition key process area for practices covering the expected contents of a process definition. The tailoring uses the organization s process assets as appropriate. 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. 82

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 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. 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 delivery process 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. L2-1.0/15 Activity 3 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. 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. 83

Activity 4 The service delivery is managed in accordance with the service s defined service process. 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. 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. 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. Activity 5 The organization s service process database is used for service planning and estimating. 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. 84

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 s estimates is recorded. 3. The service delivery provides appropriate service planning data, replanning data, and actual measured data for storage in the organization s service process database. Examples of data recorded by the service project 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. Refer to Activity 5 of the Service Delivery Planning key process area and Activity 5 of the Service Tracking and Oversight key process area for basic practices covering planning and tracking size of service delivery workload. This procedure typically specifies that: 1. A group that is independent of the service delivery process 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. 85

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. Refer to the Resource Management key process area. Activity 7 The service delivery effort and costs are managed according to a documented procedure. Refer to Activity 6 of the Service Delivery Planning key process area and Activity 6 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: Service delivery effort, cost, and staffing profile models, if used, are adapted to the service delivery and use available historical data where appropriate. Referenced productivity and cost data are adjusted to incorporate service delivery variables. Examples of service delivery variables include: the geographic locations of the service delivery s 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. The overall service delivery effort and cost is allocated to individually managed tasks or stages as needed to manage the effort and cost effectively. 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. 86

Actual data on service delivery productivity and other new service delivery costs are used where appropriate. 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 service delivery s critical computer resources are managed according to a documented procedure. Refer to the Resource Management key process area for practices covering resource management. Activity 9 The critical dependencies and critical paths of the service delivery s schedule are managed according to a documented procedure. Refer to Activity 7 of the Service Delivery Planning key process area, Activity 8 of the Service Tracking and Oversight key process area, and Activity 3 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). 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 schedule. 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 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. 87

Activity 10 The service delivery risks are identified, assessed, documented, and managed according to a documented procedure. Refer to Activity 8 of the Service Delivery Planning key process area and Activity 10 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 events that could introduce or increase risks, and close monitoring of key service delivery risk indicators. This procedure typically specifies that: 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 the 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. Alternative for each service delivery risk are identified, where possible, along with criteria for selecting among the alternatives. 88

4. The initial release and major revisions to the service delivery risk management plan undergo peer review. 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. 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. The end users referred to in these practices are the customer-designated end users or representatives of the end users. Refer to Activities 4 and 5 of the Service Commitment Management key process area for practices covering the evaluation of service commitments and actual service delivery. 89

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. Verifying Implementation Verification 1 The activities for managing the service delivery are reviewed with senior management periodic basis. 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 delivery manager on both a periodic and an event-driven basis. Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service delivery 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. 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 s planning, estimating and tracking activities. 90

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 methodes and tools. Documentation needed to perform the service delivery activities (e.g. service commitments) 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. L23-0.1/11 Goals Goal 1 Goal 2 The service delivery tasks are defined, integrated, and consistently performed to deliver the service. 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. 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. 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, 91

supporting users of IT components, and replacing IT components. 2. Tools to support the service delivery tasks are made available. Examples of service delivery support tools include: workstations, database management systems, online help aids, graphics tools, interactive documentation tools, and 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. The members of the service engineering technical staff should receive training in the customer s business domain. Examples of training include: use of the tools selected for supporting service delivery, and the design of the existing IT infrastructure. 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 user support. 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. 92

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. 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. 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. Refer to the Configuration Management key process area. Activity 2 IT components are acquired according to the service s defined service process. 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 components, or a combination of the aforementioned. 1. IT components are acquired according to the service s resource management plan. Refer to Activity 3 of the Resource Management key process area for practices covering the contents of the resource management plan. 93

2. IT components are assembled according to the service s resource management plan. 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 in the IT infrastructure 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, subcontractors, customer, and end users, as appropriate, back-out plans, release acceptance criteria, communication with affected groups, and training schedule for affected groups. Examples of affected groups include: end users, service delivery group, configuration management group, and event management group. L2-1.0/15 2. The release planning 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. 94

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. Refer to Activity 6 of the Configuration Management key process area for practices covering changing the configuration baseline. 7. Release planning and actual delivery are communicated with affected groups. L23-0.1/12 8. Affected groups and individuals are trained as appropriate. Examples of affected groups include: end users, service delivery group, configuration management group, and event 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. Refer to Activity 5 of the Resource Management key process area for practices covering the monitoring of IT components. 2. Corrective action is taken as soon as measurement data exceeds earlier set limits. Refer to the Event Management key process area for practices covering the management of events. Refer to the Resource Management key process area for practices covering the monitoring of IT components. Activity 6 IT components are repaired when needed according to the service s defined service process. 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. 95

1. Spare IT components are acquired. Acquiring spare IT components can be done on demand or by means of a stock of components, as appropriate. Refer to Activity 2. 2. The failed IT component is retired. Refer to Activity 8. 3. The new IT component is released into the production environment. 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. Acquiring new IT components can be done on demand or by means of a stock of components, as appropriate. 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. 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. 5. The new IT component is released into the production environment. Refer to Activity 3. Activity 8 IT components are retired when needed according to the service s defined service process. Activity 9 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. Refer to Activity 6 of the Configuration Management key process area for practices covering changing the configuration baseline. Preventive maintenance of IT components is perfomed according to the service s defined service process. 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. L23-0.1/12 96

Measurement and Analysis 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 a periodic and event-driven basis. 4. Preventive maintenance activities are reviewed and revised as necessary based on actual failures on a periodic and event-driven basis. Measurement 1 Measurement 2 Measurements are made and used to determine the quality of the services delivered. Refer to the Service Tracking and Oversight key process area for practices covering the measurement of service delivery. Measurements are made and used to determine the status of the service delivery activities. 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 Verification 2 The service delivery activities are reviewed with senior management periodic basis. Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews. The service delivery activities are reviewed with the service delivery manager on both a periodic and an event-driven basis. Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service management oversight reviews. 97

Verification 3 The service quality assurance group reviews and/or audits the activities and work products for service delivery and report the results. Refer to 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. 6.6 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. L23-0.1/13 Goals Goal 1 Goal 2 Goal 3 The service commitments are agreed to by all affected groups. The commitments between the service groups are agreed to by the affected groups. The service groups identify, track, and resolve intergroup issues. 98

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 requirements and service-level objectives for the service are defined and reviewed by all affected groups. Examples of affected groups include: service delivery, service estimating, service testing, service quality assurance, configuration management, 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 facilitatie 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. 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 Ability 2 Adequate resources and funding are provided for coordinating the service delivery activities with other service groups. 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, problem tracking packages, and library management tools. Ability 3 All managers in the organization receive required training in teamwork. 99

Examples of training include: building teams, managing teams, establishing, promoting, and facilitating teamwork, and group dynamics. 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. Refer to the Training Program key process area. Ability 5 The members of the service groups receive orientation in working as a team. 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 requirements. 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 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. 100

6. Reviewed and agreed to by all service groups and the service delivery manager. Activity 3 Critical dependencies between service groups are identified, negotiated, and tracked according to a documented procedure. 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. 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. L2-1.0/15 Activity 4 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 5 Intergroup issues not solvable by the individual representatives of the service delivery 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. 101

Activity 6 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 requirements conform to the service requirements agreed upon. 4. Review the commitments to determine whether they are being met. Refer to the Service Tracking and Oversight key process area for practices covering reviews. 5. Review the technical risks and other technical issues. 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. 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 are reviewed with senior management on a periodic basis. 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 delivery manager on both a periodic and event-driven basis. Refer to Verification 2 of the Service Tracking and Oversight key process area for practices covering the typical content of service delivery management oversight reviews. 102

Verification 3 The service quality assurance group reviews and/or audits the activities and work products for intergroup coordination and reports the results. 6.7 Training Program Refer to the Service Quality Assurance key process area. 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. 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. 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. L23-0.1/14 Goals Goal 1 Goal 2 Goal 3 Training activities are planned. Training for developing the skills and knowledge needed to perform service management and technical roles is provided. 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. 103

2. Training vehicles for imparting skills and knowledge are identified and approved. Examples of approved training vehicles include: classroom training, computer-aided instruction, guided self-study, formal apprenticeship and mentoring programs, and facilitated media. L2-1.0/15 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. 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. 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. 104

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. 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. Ability 3 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 Each service develops and maintains a training plan that specifies the training needs. 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. 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, computer-aided 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. Refer to Ability to Perform common feature in all other key process areas for examples of specific training needs. L23-0.1/15 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. Training may be provided by the service delivery group, by the organization s training group, or by an external organization. 105

Examples of training appropriately done by the service include: training in specific techniques and requirements of the service, and other training more effectively or efficiently performed at the service level. Activity 2 The organization s training plan is developed and revised according to a documented procedure. This procedure typically specifies that: 1. The plan uses the service s training needs identified in their 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. 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 (including all subgroups, such as maintenance personnel), service estimating, service quality assurance, configuration management, 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: 106

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. 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: 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. Activity 4 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. L23-0.1/15 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. 107

Activity 5 Activity 6 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. Records of training are maintained. Measurement and Analysis 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 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. 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. Refer to Verification 1 of the Service Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews. 108

Verification 2 Verification 3 The training program is independently evaluated on a periodic basis for consistency with, and relevance to, the organization s needs. 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 of 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 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 services. L23/0.1/16 Goals Goal 1 Goal 2 Goal 3 Resource management activities are planned. The amount and availability of resources needed for each service delivery is identified, planned, and tracked. 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: 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. 109

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 management repository. 2. Development, maintenance and distribution of the RM plans, standards, and procedures. 3. Management of access to the resource management repository. 4. Changes to the resource management 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. Activities Performed Activity 1 The organization s RM plan is developed and revised according to a documented procedure. This procedure typically specifies that: 1. The organization s resource management plan covers all standard services of the 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. 110

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. 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. Refer to Activity 5 for practices covering the monitoring of resources. 2. Resource-related data on the service processes. These data may be obtained from the service process database. 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: 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. L2-1.0/15 The resource management library system may be combined with the configuration management library system. 111

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. 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. 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, documented, planned, initiated, communicated to the affected groups and individuals, tracked to closure, and evaluated. Activity 6 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. Reactive RM activities are performed when incidents regarding IT components occur or when service commitments are negotiated. 112

Activity 7 Affected groups and individuals are informed of the status of resources on both a periodic and event-driven basis. Examples of affected groups and individuals include: configuration management group, service delivery group, and service delivery manager. Activity 8 Activity 9 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. 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. 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 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. 113

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. 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. 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 Verification 3 Verification 4 The RM activities are reviewed with the service delivery managers on both a periodic and event-driven basis. The RM group periodically audits resource information repositories to verify that they conform to the documentation that defines them. The service quality assurance group reviews and/or audits the organization s RM activities and reports the results. Refer to the Service Quality Assurance key process area At a minimum, the reviews and/or audits verify: 6.9 Problem Management 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. Purpose The main purpose of the key process area Problem Management is to identify and resolve underlying causes of events and to prevent events from occuring. Problem management activities are both reactive and proactive. Reactive activities include the investigation of the root cause of events. Proactive activities include the monitoring of IT components in order to prevent events from occuring. L23-0.1/18 114

Goals Goal 1 Goal 2 Goal 3 Problem management activities are planned. Problems are identified, recorded, analyzed, tracked, and resolved. Affected groups and individuals are informed of the status of problems and action items. 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 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 the 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. 115

Ability 3 Members of the PM group and related groups are trained in the objectives, procedures, and methods for performing their PM activities. Examples of related groups include: event management group, service quality assurance group, configuration management group, 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 Activity 2 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. 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 overall service delivery planning. 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: 116

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. Refer to Activity 5. 4. Provides for the archival and retrieval of historic problem information. 5. Supports production of PM reports. The problem management library system may be combined with the event 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 events. Refer to the Event Management key process area for practices covering event management. 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 events, 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. 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. 7. The problem is analysed and diagnosed. 117

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 this activity confines itself to configuration items, appropriate actions are taken by the Configuration Management group. Refer to the Configuration Management key process area for practices covering configuration management. L2-1.0/15 Activity 6 Problem management activities are performed both proactively and reactively. Examples of proactive problem management activities include: trend analysis of events, periodically obtaining other information that will benefit the problem management activities, and monitoring IT components in order to prevent events from occuring. Reactive problem management activities are performed based on the occurence of events. Activity 7 Affected groups and individuals are informed of the status of problems on both a periodic and an event-driven basis. Examples of affected groups and individuals include: 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. 118

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. 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 Verification 2 Verification 3 Verification 4 The PM activities are reviewed with senior management periodic basis. The PM activities are reviewed with the service delivery managers on both a periodic and an event-driven basis. The PM group periodically audits problem repositories to verify that they conform to the documentation that defines them. The service quality assurance group reviews and/or audits the PM activities and work products and reports the results. 119

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é 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. 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. 120

Part III Appendices 121

Appendix A 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 Added common features of Event Management, section 5.6. L2-0.0-980506 Added common features of Subcontract Management, section 5.4. Rewrite of section on design decisions, section 2.5. L2-0.0-980519 Added appendix B 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 L2-0.0-980804 the margin. Some more text on the differences between ITIL and the IT Service CMM in appendix B. Split the document in two parts. Described Service Planning and Evaluation into much more detail. L2-0.1-981014 Added explanation of the common features, see page 12. 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. L2-0.1-981207 Comments of Gerrit Matser processed. L2-0.2-981210 Adapted Configuration Management to comments of review board, see section 5.5. Described Event Management into more detail, see section 5.6. L2-0.4-990118 Added overview to Event Management, see section 5.6. L2-0.5-990208 Described Service Tracking and Oversight in more detail, see section 5.3. 122

L2-0.6-990301 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. L2-0.7-990325 Described Subcontract Management into more detail, see section 5.4. L2-0.8-990416 Adapted Subcontract Management to comments review board, see section 5.4. More extensive index. New chapter ( 3) on the intepretation of the IT Service CMM. Small overview sections at start of each key process area in part II. L2-1.0 Layout and other small changes. L2+3-0.1 Added level three key process areas based on DOCIS project documents. L2+3-0.2 Processed some of the review comments, added comparison of ITIL and IT Service CMM (Appendix B). L2+3-0.3 Fixed layout problems introduced in L2+3-0.2. The changebars in this version are relative to L2+3-0.1. 123

Appendix B 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, 12]. 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 B.1. Next, we discuss the main similarities and differences in section B.2. L2-1.0/1 B.1 IT Infrastructure Library The IT Infrastructure Library (ITIL) is a framework of best practices for the support and delivery of IT services [12]. 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). 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 [11]: The Service Support book describes service desk, incident management, problem management, 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 explainsthe steps necessary to identify how an organisation might expect to benefit from ITIL, and how to set about reaping those benefits. The ICT Infrastructure Management book is to include network service management, operations 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. 124

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. B.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 [12]. 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 organizations. 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. Table B.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 eachother. 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. 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 Event 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 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. 1 Yet. It might become part of level four in the future. 125

IT Service CMM Service Commitment Management Service Tracking and Oversight Subcontract Management Service Delivery Planning Event Management Configuration Management Service Quality Assurance Organization Service Definition Organization Process Definition Organization Process Focus Integrated Service Management Service Delivery Resource Management Training Program Intergroup Coordination Problem Management ITIL Service Level Management Service Desk Incident Management Configuration Management Change Management Financial Management for IT Services Release Management IT Service Continuity Management Availability Management Capacity Management Availability Management Problem Management Table B.1: ITIL and IT Service CMM processes compared 126

Appendix C 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. To be done. L2-1.0/10 127

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] 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. [5] 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. [6] Khaled El Emamand Jean-Normand Drouin and Walcélio Melo, editors. SPICE: The Theory and Practice of Software Process Improvement and Capability Determination. IEEE Computer Society, 1998. [7] Pasi Kuvaja, Jouni Similä, Lech Krzanik, Adriana Bicego, Günter Koch, and Samuli Saukkonen. Software Process Assessment and Improvement: The BOOTSTRAP Approach. Blackwell Publishers, 1994. [8] 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/. [9] Frank Niessink and Hans van Vliet. Towards Mature IT Services. Software Process Improvement and Practice, 4(2):55 71, June 1998. [10] 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. 128

[11] Office of Governement Commerce. IT Infrastructure Library Online, April 2002. http://www.itil.co.uk. [12] Office of Government Commerce. Best Practice for Service Delivery. IT Infrastructure Library. The Stationary Office, London, UK, 2001. [13] Leo Ruijs, Wouter de Jong, Jos Trienekens, and Frank Niessink. Op weg naar volwassen ICTdienstverlening: Resultaten van het Kwintes-onderzoek. Perform Service Management. Academic Service, Schoonhoven, the Netherlands, 2000. pp. 145. [14] The Capability Maturity Model: Guidelines for Improving the Software Process. SEI Series in Software Engineering. Addison-Wesley Publishing Company, 1995. Carnegie Mellon University/Software Engineering Institute. [15] T. Stålhane, 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. [16] 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. [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. Staged Representation. [18] J.M. Trienekens and M. van der Zwan. Zonder harde afspraken geen verbetering dienstverlening in IT. Automatisering Gids, (39):19 21, 27 September 1996. [19] 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. (In Dutch). [20] Trillium Model For Telecom Product Development and Support Process Capability. Model Issue 3.2, Bell Canada, May 1996. 129

Index action item, 29, 30, 36, 42, 43, 48, 49, 54 57, 59, 60, 115, 118, 119 actual service delivery, see service delivery, actual business process, 27 strategy, 27 calamity, 28 CCTA, see Central Computer and Telecommunications Agency Central Computer and Telecommunications Agency, 124 commitments, 31, 39, 41, 44, 48 internal, 26, 31 service, see service commitments component, see IT component configuration baseline, 49, 51 56, 63 item, 51 55, 59, 117, 119 Configuration Management, 18 20, 32, 34, 51, 72, 83, 93, 95, 96, 106, 112, 118, 122, 125, 126 configuration management, 47, 49 56 activities, 49, 51 53, 55, 56, 63 group, 15, 26, 31, 33, 37, 39, 49, 52, 53, 56, 58, 59, 89, 94, 95, 116, 118 manager, 46 plan, 52, 53 record, 51, 53 report, 52 customer, 14, 15, 25 29, 35, 37, 42 44, 47, 48, 53, 56, 62 64, 89 end user, 42, 52, 58, 59, 89, 94, 95, 118 estimate, see service estimate evaluation, see service evaluation event, 41, 50, 56, 57, 59, 60, 114, 117, 118 Event Management, 18 20, 41, 54, 56, 95, 117, 122, 123, 125, 126 event management, 47, 49, 50, 57, 58, 60, 117 activities, 49, 57 60, 63 group, 15, 26, 49, 52, 57, 58, 60, 62, 94, 95, 116 library system, 117 plan, 57, 58 report, 57, 58 incident, 56 Integrated Service Management, 18, 21, 22, 67, 69, 70, 76, 78, 80, 81, 91, 93, 101, 102, 125, 126 Intergroup Coordination, 18, 21, 22, 87, 98, 125, 126 internal commitments, see commitments, internal IT component, 27, 34, 56, 114, 118 IT Infrastructure Library, 2, 8, 71, 122, 124 126 IT service, 13, 14, 26 28, 125 needs, 25 27, 29, 48 provider, 27 IT strategy, 27 ITIL, see IT Infrastructure Library management senior, see senior management manager, 14, 15, 52, 57, 61, 62, 115 measurements, 29, 35, 43, 50, 56, 60, 64, 119 Office of Governement Commerce, 124 OGC, see Office of Governement Commerce Organization Process Definition, 18, 21, 66 69, 78 84, 111, 125, 126 Organization Process Focus, 18, 21, 70, 75, 125, 126 Organization Service Definition, 18, 21, 66, 125, 126 130

prime contractor, 44, 47 50 problem, 115, 117 119 analysis and diagnosis, 118 record, 116, 117 repository, 115, 118, 119 workload, 116 Problem Management, 16, 18, 21, 22, 114, 125, 126 problem management, 115, 119 activities, 114 116, 118, 119 group, 115, 116, 119 library system, 116, 117, 119 plan, 115 117, 119 procedure, 117 Problem Prevention, 7, 18, 23 Process Change Management, 18, 23 Quantitative Process Management, 7, 18, 23 Resource Management, 18, 21, 22, 86, 87, 93 95, 109, 125, 126 resource management group, 26 senior management, 13, 15, 26, 30, 36, 39, 43, 50, 56, 60 62, 64, 90, 97, 119 service activities, 14, 28, 32, 34, 47, 48, 56, 61, 64 Service Commitment Management, 14, 17 19, 25, 31, 37, 42, 47, 48, 66, 89, 91, 112, 123, 125, 126 service commitment management activities, 26, 29, 30 service commitments, 25 31, 33, 39 42, 44, 46 48, 51, 56, 57, 59, 61, 63, 89, 91, 98, 117 subcontract, see subcontract service commitments service condition, 28 Service Delivery, 18, 21, 22, 91, 125, 126 service delivery, 14, 25 27, 31, 32, 34, 37 39, 46, 51, 56, 62, 63, 80 activities, 13, 15, 30, 31, 33, 34, 38 41, 49, 61, 63, 91, 97 actual, 14, 25, 28, 29, 31, 37, 38, 42, 43, 48, 89, 91 group, 15, 26, 31, 34, 37, 39, 41, 42, 45, 52, 53, 56, 59, 61 64, 94, 95, 100, 116, 118 manager, 15, 31 34, 36 39, 41, 42, 46, 48, 50, 62, 64, 82, 83, 90, 92, 97, 118, 119 plan, 26, 31 33, 36 44, 46 48, 63, 64, 83, 91 planning, 19, 30, 32, 37, 41, 53, 58, 62, 63, 116 activities, 32, 35, 36 risk, 29, 30, 33, 36, 41 43, 48, 82, 86, 88, 89 schedule, 28, 31, 33, 35, 40, 42, 48 task, 91 Service Delivery Planning, 8, 18, 19, 30, 38 41, 47, 80 88, 123, 125, 126 service engineer, 15, 32, 34, 52, 58 service estimate, 31 service evaluation, 28, 29, 37, 48 service manager, 15, 25, 26, 30 34, 37 39, 42, 43, 45, 52, 55, 56, 59 65, 83, 106, 108 Service Planning and Evaluation, 122, 123 Service Quality Assurance, 18 20, 30, 36, 50, 56, 61, 68, 75, 90, 98, 103, 114, 122, 123, 125, 126 service quality assurance, 49, 61, 62, 64, 103 activities, 49, 61 65 function, 61 group, 13, 15, 30, 31, 33, 36, 37, 39, 44, 49, 50, 52, 56, 58, 60 65, 68, 89, 90, 98, 116, 119 manager, 46 plan, 62, 63 records, 49 role, 62 Service Quality Management, 18, 23 service request, 34, 56 service task leader, 15, 31, 38, 42, 62, 64 Service Tracking and Oversight, 18 20, 28, 29, 37, 48, 50, 64, 65, 80 88, 90, 97, 102, 108, 114, 122, 123, 125, 126 service tracking and oversight activities, 43, 44 Software CMM, 10, 12, 14 Software Product Engineering, 22 standard service process, 14, 81 83 131

subcontract, 44 48, 50 management activities, 50 manager, 45, 46 service commitments, 47, 48 Subcontract Management, 18, 19, 26, 44, 122, 123, 125, 126 subcontractor, 44 50, 89 Technology Change Management, 18, 23 Training Program, 18, 21, 22, 67, 71, 77 79, 82, 84, 92, 100, 103, 125, 126 132