ITIL® V3 : Release, Control & Validation Best Practices

Foreword____________________________

As an education and training organization within the IT Service Management (ITSM) industry, we have been impressed by the positive changes introduced by the refresh of ITIL® in July 2007. The evolution of the core principles and practices provided by the framework provides the more holistic guidance needed for an industry that continues to mature and develop at a rapid pace. We recognize however, that many organizations and individuals who had previously struggled with their adoption of the framework will continue to find challenges in ‘implementing’ ITIL® as part of their approach for governance of IT Service Management practices. In light of this, one of our primary goals is to provide the quality education and support materials needed to enable the understanding and application of the ITIL® framework in a wide-range of contexts. This workbook’s primary purpose is to complement the accredited ITIL® Release, Control & Validation program provided by The Art of Service or one of our accredited partners. We hope you find this book to be a useful tool in your educational library and wish you well in you IT Service Management career!

The Art of Service

© The Art of Service Pty Ltd ‘All of the information in this document is subject to copyright. No part of this document may in any form or by any means (whether electronic or mechanical or otherwise) be copied, reproduced, stored in a retrieval system, transmitted or provided to any other person without the prior written permission of The Art of Service Pty Ltd, who owns the copyright.’ ITIL® is a Registered Community Trade Mark of OGC (Office of Government Commerce, London, UK), and is Registered in the U.S. Patent and Trademark Office.

©The Art of Service

2

ITIL® V3 : Release, Control & Validation Best Practices

How to access the eLearning Program
1. 2. 3. 4. Direct your browser to: www.theartofservice.org Click ‘login’ (found at the top right of the page) Click ‘Create New Account’ Follow the instructions to create a new account. You will need a valid email address to confirm your account creation. If you do not receive the confirmation email check that it has not been automatically moved to a Junk Mail or Spam folder. 5. Once your account has been confirmed, email your User-ID for your new account to:

Itilv3rcv@theartofservice.com
6. You will receive a return email with an enrolment key that you will need to use in order to access the eLearning program. Next time you login to the site, you will need to access the program associated with this study guide and enter the enrolment key that was sent to you. 7. If you have any difficulties using the program or enrolling please email elearning-support@artofservice.com.au Minimum system requirements for accessing the eLearning Program: Processor RAM OS Browser : Pentium 4 (1 GHz) or higher : 256MB (512 MB recommended) : Windows XP, Vista, MCE, Mac OSX : Macromedia Firefox 3+ (recommended), Internet Explorer 6.x or higher, Safari, Opera, Chrome, all with cookies and JavaScript enabled. : Macromedia Flash Player 8 or higher : Due to multimedia content of the site, a minimum connection speed of 512kbs is recommended. If you are behind a firewall and are facing problems in accessing the course or the learning portal, please contact your network administrator for help

Plug-Ins Internet Connection

If you are experiencing difficulties with the Flash Presentations within the eLearning Programs please make sure that: 1) You have the latest version of Flash Player installed, by visiting 2) You check that your security settings in your web browser don't prevent these flash modules playing. 3) For users of Internet Explorer 7 a solution involves DESELECTING "Allow active content to run files on my computer" in Internet Explorer -->Tools, Options, Advanced, Security settings.

©The Art of Service

1.2 2.1 6.1 2.1.3 6.1.1.2 6.4 6 6.2 4.1 4.3 3 3.2.2 4.2.1.4 4.3 5.1 6.6 SERVICE TRANSITION OBJECTIVES OF SERVICE TRANSITION BENEFITS OF SERVICE TRANSITION INTERFACES TO OTHER SERVICE LIFECYCLE PHASES RELEASE.ITIL® V3 : Release. Control & Validation Best Practices 3 Contents FOREWORD____________________________ 1 2 2.4 6.1 3.1.1.1 5.3 4.5 6.1.3 4.2.3 4 4. CONTROL PROCESSES AND THE SERVICE LIFECYCLE________________ 5. CONTROL AND VALIDATION PROCESSES_________________________ CHANGE MANAGEMENT GOALS AND OBJECTIVES SCOPE DESIGNING AND PLANNING CHANGE MANAGEMENT POLICIES CHANGE MODELS TRIGGERS AND INTERFACES .1.1.2 3.1 4.1 4.3 INTRODUCTION_______________________ IT SERVICE MANAGEMENT______________ THE FOUR PERSPECTIVES (ATTRIBUTES) OF ITSM BENEFITS OF ITSM BUSINESS AND IT ALIGNMENT WHAT IS ITIL®?_____________________ THE SERVICE LIFECYCLE MAPPING THE CONCEPTS OF ITIL® TO THE SERVICE LIFECYCLE HOW DOES THE SERVICE LIFECYCLE WORK? COMMON TERMINOLOGY_______________ WHAT ARE SERVICES? BUSINESS UNITS AND SERVICE UNITS CREATING SERVICE VALUE SERVICE PACKAGES AND SERVICE LEVEL PACKAGES SERVICE PORTFOLIOS PROCESSES & FUNCTIONS DEFINING PROCESSES DEFINING FUNCTIONS CONNECTING PROCESSES AND FUNCTIONS OTHER TERMINOLOGY AND VALIDATION 37 39 40 41 42 45 47 47 48 49 49 50 52 ©The Art of Service 1 7 9 10 11 12 15 16 18 20 21 22 24 26 27 29 31 31 33 34 35 5 RELATIONSHIP BETWEEN THE RELEASE.2 4.2 5.

1 6.13 6.4.6 6.9 ITIL® V3 : Release.1.2 6.1 6.11 6. Control & Validation Best Practices CHANGE MANAGEMENT ACTIVITIES ROLES AND RESPONSIBILITIES WITHIN CHANGE MANAGEMENT KEY PERFORMANCE INDICATORS (KPIS) OF CHANGE MANAGEMENT CHALLENGES AFFECTING CHANGE MANAGEMENT RELATIONSHIP WITH PROJECT MANAGEMENT TYPICAL CONTENTS OF CHANGE DOCUMENTATION RACI EXAMPLE FOR MANAGING CHANGE RELEASE AND DEPLOYMENT MANAGEMENT GOALS AND OBJECTIVES SCOPE BENEFITS TERMINOLOGY TRIGGERS AND INTERFACES RELEASE DESIGN OPTIONS AND CONSIDERATIONS RELEASE POLICY RELEASE AND DEPLOYMENT ACTIVITIES KEY PERFORMANCE INDICATORS (KPIS) OF RELEASE & DEPLOYMENT MANAGEMENT SERVICE VALIDATION AND TESTING GOALS AND OBJECTIVES SCOPE BENEFITS POLICIES AND PRINCIPLES TEST MODELS TESTING APPROACHES AND TECHNIQUES SERVICE VALIDATION AND TESTING ACTIVITIES TRIGGERS AND INTERFACES KEY PERFORMANCE INDICATORS (KPIS) OF SERVICE VALIDATION AND TESTING SERVICE EVALUATION GOALS AND OBJECTIVES SCOPE BENEFITS PRINCIPLES OF EVALUATION EVALUATION ACTIVITIES TRIGGERS AND INTERFACES KEY PERFORMANCE INDICATORS (KPIS) FOR SERVICE EVALUATION REQUEST FULFILMENT GOAL AND OBJECTIVES SCOPE BENEFITS REQUEST MODELS REQUEST FULFILMENT ACTIVITIES TRIGGERS AND INTERFACES KEY PERFORMANCE INDICATORS (KPIS) FOR REQUEST FULFILMENT SERVICE ASSET AND CONFIGURATION MANAGEMENT GOAL AND OBJECTIVES SCOPE BENEFITS POLICIES AND PRINCIPLES OF SERVICE ASSET AND CONFIGURATION MANAGEMENT TERMINOLOGY THE CONFIGURATION MANAGEMENT SYSTEM (CMS) CONFIGURATION MANAGEMENT ACTIVITIES TRIGGERS AND INTERFACES ROLES AND RESPONSIBILITIES 54 59 60 61 62 63 67 68 68 69 69 69 72 73 75 75 85 86 86 87 87 87 90 91 93 95 96 97 97 97 98 98 98 102 102 103 103 103 104 104 104 106 107 108 108 108 109 109 111 111 114 120 121 ©The Art of Service .7 6.7.6.4 6.8 6.7 6.3 6.2.2.3 6.1.5 6.6.7.1 6.5 6.7 6.7 6.2.8 6.2.7.5 6.9 6.4.2 6.3.5.4.1 6.7.4.6 6.3 6.1.2.12 6.1 6.2 6.7.6 6.6.4 6.3 6.5.1 6.7 6.3 6.2 6.8 6.6.6.3 6.7 6.5.2 6.4.7 6.9 6.2.1.5.7.2.1.5 6.2.6.4 6.2.5 6.5 6.5.10 6.7.4.5.7.7.4 6.4.5.2 6.6.4 6.4 6.6 6.4 6.1.6 6.6 6.1.

8 7 7.8.7 12 13 13.3 KEY PERFORMANCE INDICATORS (KPIS) FOR REQUEST FULFILMENT KNOWLEDGE MANAGEMENT GOAL AND OBJECTIVES SCOPE CHALLENGES FACED BY KNOWLEDGE MANAGEMENT POLICIES AND PRINCIPLES OF KNOWLEDGE MANAGEMENT THE SERVICE KNOWLEDGE MANAGEMENT SYSTEM (SKMS) KNOWLEDGE MANAGEMENT ACTIVITIES TRIGGERS AND INTERFACES KEY PERFORMANCE INDICATORS (KPIS) OF KNOWLEDGE MANAGEMENT ROLES AND RESPONSIBILITIES FOR RCV____ GENERIC ROLES ROLES WITHIN SERVICE TRANSITION TECHNOLOGY CONSIDERATIONS_________ KNOWLEDGE MANAGEMENT TOOLS COMMUNITIES COLLABORATION WORKFLOW MANAGEMENT CONTROL AND 9 IMPLEMENTING RELEASE.8.1 10.1 9.1 6.8.1 8.4 11.5 11.1 VALIDATION 143 144 145 147 148 149 153 154 155 156 159 160 161 162 163 167 167 THE CONTINUAL SERVICE IMPROVEMENT MODEL MANAGING CULTURAL CHANGE SERVICE TRANSITION SUMMARY_________ SERVICE TRANSITION SCENARIO REVIEW QUESTIONS CHECKLIST FOR RCV PRACTICES_________ SERVICE MANAGEMENT AS A PRACTICE SERVICE TRANSITION PRINCIPLES SERVICE TRANSITION PROCESSES SERVICE TRANSITION COMMON OPERATION ACTIVITIES ORGANIZING SERVICE TRANSITION SERVICE TRANSITION TECHNOLOGY CONSIDERATIONS IMPLEMENTING SERVICE TRANSITION GLOSSARY_________________________ CERTIFICATION______________________ ITIL® CERTIFICATION PATHWAYS ©The Art of Service .8.10 6.2 8.1.2 11 11.2 11.2 8 8.2 10 10.8.1 8.6 6.ITIL® V3 : Release.8 6.1 7. PROCESSES________________ 9.1.1 11. Control & Validation Best Practices 5 122 123 123 123 124 125 126 127 129 130 133 133 134 139 141 141 142 142 6.8.8.5 6.7.1.2 6.3 11.6 11.7 6.3 6.8.4 6.

2 14 15 ITIL® V3 : Release. Control & Validation Best Practices ISO/IEC 20000 PATHWAYS ANSWERS TO REVIEW QUESTIONS REFERENCES 168 169 171 ©The Art of Service .6 13.

modified and existing IT Services. The bad news unfortunately is that there is still a long road to go and considerable challenges to overcome before this maturity is achieved for many IT Service Providers. Control and Validation of new. Control & Validation Best Practices 7 1 Introduction_______________________ As we approach yet another major information technology (IT) revolution coming in the form of Cloud and Utility Computing. it is in fact these conflicting requirements that leads to the necessity of quality practices to be adopted by an organization as part of its approach to quality IT service management. many observers might have expected that by 2008 the IT industry may have achieved maturity in many of its most fundamental practices.ITIL® V3 : Release. with particular focus on those capabilities required for the Release. Assumptions are made by the authors that readers already have some familiarity with IT and ITIL terminology or have already completed an ITIL Foundation program. This workbook is best used in addition to the combination of an accredited ITIL training program as well as practical experience gained in the field. ©The Art of Service . this workbook aims to develop the reader’s knowledge and appreciation of the practices for IT Service Management. While it may seem contradictory that the words Release (let go) and Control (maintain authority) are used together. In light of this.

Control & Validation Best Practices ©The Art of Service .8 ITIL® V3 : Release.

experience and skills. However IT Service Management comprises more than just these capabilities alone. • The purpose primarily being to deliver and support the technology or products needed by the business to meet key organizational objectives or goals.ITIL® V3 : Release. being complemented by an industry of professional practice and wealth of knowledge. The ITIL® framework has developed as a major source of good practice in Service Management and is used by organizations worldwide to establish and improve their ITSM practices. describing ITSM as “A set of specialized organizational capabilities for providing value to customers in the form of services”. customers and other stakeholders involved. ©The Art of Service . The official ITIL® definition of IT Service Management is found within the Service Design volume on page 11. • The management of external suppliers (partners) involved in the delivery and support of the technology and products being delivered and supported by IT. Control & Validation Best Practices 9 2 IT Service Management______________ The term IT Service Management (ITSM) is used in many ways by different management frameworks and organizations seeking governance and increased maturity of their IT organization. • Definition of roles and responsibilities for the people involved including IT staff. the culture that exists within the service organization and the intangible nature of the output and intermediate products of IT services. Standard elements for most definitions of ITSM include: • Description of the processes required to deliver and support IT Services for customers. These organizational capabilities are influenced by the needs and requirements of customers. The combination of these elements provide the capabilities required for an IT organization to deliver and support quality IT Services that meet specific business needs and requirements.

• Partners/Suppliers Perspective: Takes into account the importance of Partner and External Supplier relationships and how they contribute to Service Delivery.1 – Four Perspectives (Attributes) of ITSM There are four perspectives (“4P’s”) or attributes to explain the concept of ITSM. budgets. It is the same when designing new or modified Services themselves. hardware & software. This includes IT staff. in that these four perspectives need to be considered and catered for in order to enable success in its design. • People Perspective: Concerned with the “soft” side of ITSM. Control & Validation Best Practices 2. • Process Perspective: Relates the end to end delivery of service based on process flows. Do staff have the correct skills and knowledge to perform their roles? • Products/Technology Perspective: Takes into account IT services.1 The Four Perspectives (Attributes) of ITSM Partners/Suppliers People Process Products/Technology Figure 2. ©The Art of Service . transition and eventual adoption by customers.g. E. tools.10 ITIL® V3 : Release. customers and other stakeholders. Quality IT Service Management ensures that all of these four perspectives are taken into account as part of the continual improvement of the IT organization.

These stakeholders can come from: • senior management • business unit managers • customers • end users • IT staff • suppliers ©The Art of Service . such benefits include: • improved capability for supporting business growth and change • improved efficiency of business and IT staff though quality information and knowledge being made available • decreased variance between estimated and actual resource requirements • reduction in the number of software license and asset management discrepancies • reduction in the number and impact of failed Changes and Release rollbacks. Control & Validation Best Practices 11 2.2 Benefits of ITSM While the benefits of applying IT Service Management practices vary depending on the organization’s needs. It is important to consider the range of stakeholders who can benefit from improved ITSM practices.ITIL® V3 : Release. Customer and User demands • integrated centralized processes • everyone knows their role and knows their responsibilities in service provision • learning from previous experience • demonstrable performance indicators In particular reference to the scope of Release. some typical benefits include: • improved quality service provision • cost justifiable service quality • services that meet business. Control & Validation.

IT Service Organization (What IT Services are required to enable the effective and efficient execution of the business processes above?) 4. These layers are communicated by the following: 1. When staff members of an IT organization have an internal focus on the technology being delivered and supported. IT Technical Activities (The actual technical activities required as part of the execution of the ITIL® processes above. IT Service Management (The focus here is on the ITIL® processes required for quality delivery and support of the IT Services above) 5. A way in which to communicate how IT supports the business is using the following Figure demonstrating business and IT alignment. ©The Art of Service . Control & Validation Best Practices 2. Organization (What are the key goals for the organization?) 2.3 Business and IT Alignment A central concept to keep in mind when discussing the benefits of IT Service Management is the goal of business and IT alignment. These are technology specific and as such not the focus of ITIL® or this document.B below divides an organization into a number of supporting layers that work towards meeting a number of organizational goals. CORE Business Processes (These enable the objectives above to be met) 3. Figure 1. they lose sight of the actual purpose and benefit that their efforts deliver to the business.12 ITIL® V3 : Release.

automatic procurement system for buying products. marketing.ITIL® V3 : Release. buying. What IT Services are these business processes dependent on? Web site. If this occurs we cannot adequately support our business processes effectively and efficiently. Incident MGT etc. email. And therefore we cannot meet or support our overall organization’s objectives!!! ©The Art of Service .) Provisioned cost-effectively (Financial . Control & Validation Best Practices 13 Figure 2. Capacity Management etc) Available when we need it (Availability. procurement.2 – Business and IT Alignment Example to illustrate business and IT alignment: Business: A fashion store What are some of your organization’s objectives or strategic goals? We want to make a lot of money $$$! We want to have a good image and reputation. Point of Sale Services We have ITSM in order to make sure the IT Services are: What we need (Service Level Management. Service Level MGT) If we don’t manage the IT Services appropriately we cannot rely on these services to be available when we need. HR etc. What Business Processes aide in achieving those objectives? Retail.

Control & Validation Best Practices ©The Art of Service .14 ITIL® V3 : Release.

By the early 1990s they had produced a large collection of books documenting the “best practices” for IT Service Management.) • Standards (ISO 20 000. CMMI etc. ITL is only one of many sources for best practices. ITL has gone through several evolutions and was most recently refreshed with the release of version 3 in 2007. Through these evolutions the scope of practices documented has increased in order to stay current with the continued maturity of the IT industry and meet the needs and requirements of the ITSM professional community. ITIL® is the international de facto management framework describing “best practices” for IT Service Management.1 – ITIL V3 Framework Five volumes make up the IT Infrastructure Library (Version 3).ITIL® V3 : Release. including those documented by: • Public frameworks (ITIL®. COBIT. • Service Strategy • Service Design • Service Transition • Service Operation • Continual Service Improvement ©The Art of Service . The Office of Government Commerce in the UK continues to operate as the trademark owner of ITIL®. Control & Validation Best Practices 15 3 What is ITIL®?_____________________ ITIL® stands for the Information Technology Infrastructure Library. The ITIL® framework evolved from the UK government’s efforts during the 1980s to document how successful organizations approached service management. Figure 3. This library was eventually entitled the IT Infrastructure Library. BS 15 000) • Proprietary knowledge of organizations and individuals Generally best practices are those formalized as a result of being successful in wideindustry use.

adult. toddler. much of the focus of ITIL® was on the processes required to design. problems and known errors? As Version 3 now maintains a holistic view covering the entire lifecycle of a service. human stages are birth. capacity and continuity? By first asking these questions it enables a service provider to provide overall strategic objectives for the IT organization. For example. infant. transitioned. capacity and continuity of services? • How can we respond to and manage incidents. child.16 ITIL® V3 : Release.1 The Service Lifecycle Figure 3. These included: • How should we design for availability. pre-teen. but also why? • Why does a customer need this service? • Why should the customer purchase services from us? • Why should we provide (x) levels of availability. which will then be used to direct how services are designed.2 – ITIL® Service Lifecycle Model © Crown Copyright 2007 Reproduced under license from OGC Lifecycle: The natural process of stages that an organism or inanimate object goes through as it matures. The concept of the Service Lifecycle is fundamental to the refresh of ITIL® for Version 3. As a result of this previous focus on processes. deliver and support services for customers. no longer does ITIL® just answer the how questions. supported and improved in order to deliver maximum value to customers and stakeholders. teenager. Control & Validation Best Practices 3. Previously. ©The Art of Service . elderly adult and death. young adult. Version 2 of the ITIL® Framework provided best practices for ITSM based around the how questions.

ITIL® V3 : Release. This end-to-end view of how IT should be integrated with business strategy is at the heart of ITIL’s five core volumes (books). Together they provide a body of knowledge and set of good practices for successful service management. The 5 phases of the Service Lifecycle provide the necessary guidance to achieve this success. ©The Art of Service . Control & Validation Best Practices 17 The ultimate success of service management is indicated by the strength of the relationship between customers and service providers.

18 ITIL® V3 : Release. It also demonstrates the increased scope now covered by ITIL® over the previous version.2 Mapping the Concepts of ITIL® to the Service Lifecycle There has been much debate as to exactly how many processes exist within Version 3 of ITIL®. Control & Validation Best Practices 3. Figure 3. Control & Validation syllabus by EXIN International. Questions asked include: • What exactly constitutes a process? • Shouldn’t some processes be defined as functions? • Why has x process been left out? In developing this material we have based our definitions of processes and functions and where they fit on the guidance provided by the ITIL® Release. Figure 3.B demonstrates the processes and functions of ITIL® in relation to the 5 Service Lifecycle Phases.3 – The Major Concepts of ITIL® ©The Art of Service .

ITIL® V3 : Release, Control & Validation Best Practices

19

NOTES: • The Service Lifecycle phases (and ITIL® books) are shown through the arrows at the bottom. • The concepts in light shading are the V2 ITIL® concepts. • The concepts not shaded are the new ITIL® V3 concepts. • The concepts in dark shading are Functions. • Although Service Level Management officially sits in the Service Design book, it plays a very important role in the Continual Service Improvement phase, and therefore could also fit in the CSI book as a process.

©The Art of Service

20

ITIL® V3 : Release, Control & Validation Best Practices

3.3 How does the Service Lifecycle work?
Although there are 5 phases throughout the Lifecycle, they are not separate, nor are the phases necessarily carried out in a particular order. The whole ethos of the Service Lifecycle approach is that each phase will affect the other, creating a continuous cycle. For this to work successfully, the Continuous Service Improvement (CSI) phase is incorporated throughout all of the other phases. Figure 3.C demonstrates some the key outputs from each of the Service Lifecycle Phases.
•IT Budgets

Service Strategy Service Design Service Transition Service Operation Continual Service Improvement

•Patterns of Business Activity •Service Portfolio information •New and changed service assets •Service Catalogue, SLAs, OLAs, UCs •Testing and Validation Criteria •Known Errors from Development •Testing and validation results •Change Authorization •Incidents & Problems, Events, Service Requests •Request for Changes •Information collected from infrastructure monitoring

Service and Process Improvements

Figure 3.4 – How does the Service Lifecycle Work?

It is important to note that most of the processes defined do not get executed within only one lifecycle phase. As an example we will look at the process of Availability Management and where some activities will get executed throughout Service Lifecycle. Service Design Phase: Designs the infrastructure, processes and support mechanisms needed to meet the Availability requirements of the customer. Service Transition Phase: Validates that the Service meets the functional and technical fitness criteria to justify release to the customer. Service Operation Phase: Monitors the ongoing Availability being provided. During this phase we also manage and resolve incidents that affect Service Availability.

©The Art of Service

ITIL® V3 : Release, Control & Validation Best Practices

21

4 Common Terminology_______________
Critical to our ability to participate with and apply the concepts from the ITIL® framework is the need to be able to speak a common language with other IT staff, customers, end-users and other involved stakeholders. This next section documents the important common terminology that is used throughout the ITIL® framework.

Figure 4.1 – The importance of terminology © Crown Copyright 2007 Reproduced under license from OGC

©The Art of Service

I can go to a restaurant that delivers a service that provides me with the same outcome (a nice meal) without the time. It isn’t just the quality of the food itself that will influence my perceptions but also: • • • • • The cleanliness of the restaurant The friendliness and customer service skills of the waiters and other staff The ambience of the restaurant (lighting. ©The Art of Service . Now relate this to our role in providing an IT Service. I would need to.1 What are Services? The concept of IT Services as opposed to IT components is central to understanding the Service Lifecycle and IT Service Management principles in general. The mindset requires instead an alternative outlook to be maintained.) The time taken to receive my meal (and was it what I asked for?) Did they offer water on top of normal drinks and beverages? If just one of these factors don’t meet my expectations than ultimately the perceived quality and value being delivered to me as a customer are negatively impacted. go to a grocery store. If I was to cook. buy the ingredients.22 ITIL® V3 : Release. decorations etc. Now consider how I would identify the quality and value of that service being provided. music. effort and general fuss if I was to cook it myself. there are often times where I wish to enjoy quality food without the time and effort required to prepare a meal. Well what does this actually mean? To explain some of the key concepts I will use an analogy that most (food lovers) will understand. with the focus being the Service oriented or end-toend view of what their organization actually provides to its customers. If we as IT staff focus on the application or hardware elements being provided and forget or ignore the importance of the surrounding elements that make up the end-to-end service. set the table and of course clean up the kitchen afterwards. take these ingredients home. prepare and cook the meal. The alternative of course. the customer experience and perceived quality and value will be negatively impacted. then like before. It requires not just a learned set of skills but also a way of thinking that often challenges the traditional instincts of IT workers to focus on the individual components (typically the applications or hardware under their care) that make up the IT infrastructure. The official definition of a Service is “a means of delivering value to Customers by facilitating outcomes customers want to achieve without the ownership of specific costs or risks”. While I do enjoy cooking. Control & Validation Best Practices 4.

ITIL® V3 : Release. ©The Art of Service . Control & Validation Best Practices 23 But if we take a Service oriented perspective. Appropriate resolution times are maintained for end user and customer enquiries Transparency and visibility of the IT organization and where money is being spent is maintained. The IT organization works proactively to identify potential problems that should be rectified or improvement actions that could be made. To help clarify the relationship between IT Services and the business we need to look at the concepts of Business Units and Service Units. we also ensure that: • • • • Communication with customers and end users is effectively maintained.

Other services increase the performance of customer’s management. organization. control. control and deploy its resources to create value. A business unit’s capabilities coordinate. Value is always defined in the context of customers. ©The Art of Service .1 Business Units and Service Units Management Prospects Competitors Regulators Suppliers Influence Demand Organization Create value Business unit Capabilities Goods/ Services Consume assets Knowledge Coordinate. which ensures that the business unit maintains an adequate return on investment. Some services simply increase the resources available to the customer. The relationship with customer becomes strong when there is a balance between value created and returns generated. Control & Validation Best Practices 4. Customers pay for the value they receive.1. The relationship is good as long as the customer receives value and the business unit recovers cost and receives some form of compensation or profit. people and processes. and deploy Resources Supply Generate returns (or recover costs) Information Processes People Customers Asset types Applications Infrastructure Financial capital Figure 4.24 ITIL® V3 : Release.2 – Business Units © Crown Copyright 2007 Reproduced under license from OGC A business unit is a bundle of assets with the purpose of creating value for customers in the form of goods and services.

ITIL® V3 : Release. possibly by spreading these costs and risks across more than one customer or Business Unit. a bundle of service assets that specializes in creating value in the form of services.4 – Balancing service potential against demand for services © Crown Copyright 2007 Reproduced under license from OGC ©The Art of Service . Services define the relationships between business units and service units. Business units (customers) and Service units (providers) can be part of the same organization or from multiple independent organizations. Customer Performance potential Customer Assets Service potential Service Provider Service Assets + Capabilities + Service Risks Costs + Capabilities – Resources + Demand Idle capacity – Resources (Business Unit) (Service Unit) Figure 4. Control & Validation Best Practices 25 (Service unit) (Business unit) Performance potential Service potential Customer Assets + Services + Service Assets Value potential + Business outcomes Figure 4. This relationship enables Business Units to focus on the outcomes provided by services. while the Service Units(s) focuses on managing the costs and risks of providing the service.3 – Relationship between business units and service units © Crown Copyright 2007 Reproduced under license from OGC Service units are like business units.

26

ITIL® V3 : Release, Control & Validation Best Practices

4.1.2 Creating Service Value
Perhaps historically, both providers and customers have used price as the focal point for communication and negotiation, but it is this path that ultimately leads to a negative experience for both parties. One of the key mantras that exist for any modern Service provider (IT or otherwise) is that it is essential to clearly establish value before you can attach a price to the services offered. This ensures a few key things: • • • It avoids an apple to oranges comparison, which usually occurs with a price focal point. It enables the Service Provider to distinguish their capabilities and differentiation from their competitors. It clearly communicates to the customer what they can expect to receive as part of the delivery service.

Providers of IT Services need to take special appreciation of the concept of value creation and communication, due to the many misunderstandings about technology on behalf of customers (and poor communication by their IT providers). To support this need, one of the major elements of the Service Strategy lifecycle is the creation of value through Services and Service Packages
Performance supported? Constraints removed? Fit for purpose?

UTILITY

Available enough? Capacity enough? Continuous enough? Secure enough? Figure 4.5 – Creating Service Value © Crown Copyright 2007 Reproduced under license from OGC

Value
WARRANTY

Fit for use?

Formula: Service Warranty + Service Utility = Service Value Service Utility describes the positive effect on business processes, activities, objects and tasks. This could be the removal of constraints that improves performance or some other positive effect that improves the outcomes managed and focused on by the customer and business. This is generally summarized as being fit for purpose.

©The Art of Service

ITIL® V3 : Release, Control & Validation Best Practices

27

Service Warranty on the other hand describes how well these benefits are delivered to the customer. It describes the Service’s attributes such as the availability, capacity, performance, security and continuity levels to be delivered by the provider. Importantly, the Service Utility potential is only realized when the Service is available with sufficient capacity and performance. By describing both Service Utility and Service Warranty, it enables the provider to clearly establish the value of the Service, differentiate themselves from the competition and, where necessary, attach a meaningful price tag that has relevance to the customer and associated market space.

4.1.3 Service Packages and Service Level Packages
To discuss Service Packages, Service Level Packages and how they are used to offer choice and value to customers, we’re going to use the example of the packages made available by typical Internet Service Providers (ISPs). As customers, we have a wide range of choice when looking for an ISP to provide broadband internet. So as a result ISPs do need to work hard to attract customers by communicating the value that they provide through their offerings. They also need to offer a wide range of choice for customers, who have varying requirements and needs for their broadband internet service.

A Service Package contains
Core Service Package
(The basic critical services)

Supporting Services Package
(Provides differentiation or more effective use of Core Services)

Service Level Packages
(Defines level of utility and warranty provided by Service Package)

A Service Package provides a detailed description of package of bundled services available to be delivered to Customers. The contents of a Service Package includes: • The core services provided • Any supporting services provided (often the excitement factors) • The Service Level Package (see next page) Service Level Packages are effective in developing service packages with levels of utility and warranty appropriate to the customer’s needs and in a cost-effective way. • Availability Levels • Continuity Measures • Capacity Levels • Security Levels

Figure 4.6 – Service Package Example

Service Level Packages
(Defines level of utility and warranty provided by Service Package)

Availability Levels Continuity

Capacity Levels Security Levels

Features of service Support of service

Figure 4.7 – Service Package Example

©The Art of Service

28

ITIL® V3 : Release, Control & Validation Best Practices

So for our ISP example, we can define a Service Package in the following way:

Service Package: Broadband SuperUser ($69.95 per month) Core Service Package: • Internet Connection • Email Addresses Supporting Services Package: • Static IP Address • Spam filtering • 100MB Web-Space • VOIP

• • • • •

Service Level Package: Download Speeds: 8000kbs – 24 000kbs (max) Download Quota: 30 GB (Shaped to 512kbs after) Backup dial-up account 98 % Availability Guarantee (otherwise rebate offered) 24 x 7 Service Desk for Support.
Figure 4.8 – Service Package Example (ISP)

Most of the components of Service Packages and Service Level Packages are reusable components of the IT organization (many of which are services). Other components include software, hardware and other infrastructure elements. By providing Service Level Packages in this way it reduces the cost and complexity of providing services while maintaining high levels of customer satisfaction. In our example above, the ISP can easily create multiple Service Packages with varying levels of Utility and Warranty provided in order to offer a wide range of choice to customers, and to distinguish themselves from their competition. The use of Service Packages and Service Level Packages enables Service Providers to avoid a one-size fits all approach to IT Services.

©The Art of Service

we need to ensure the balance between risk and benefit provided by the Service Portfolio. • Includes the complete set of services managed by a service Provider. These portfolios are used to articulate business needs and the Service Provider’s response to those needs. The Portfolio should have the right mix of services in the pipeline and catalogue to secure the financial viability of the service provider. • Provides the information required to manage the entire lifecycle of all services. ©The Art of Service . It is possible for a Service Provider to have multiple Service Portfolios depending on the customer groups that they support. and is used to manage the lifecycle of all services in order to maximize the value of IT Service Management to the business.9 – A Service Portfolio Service Portfolios have a much larger scope than Service Catalogues.ITIL® V3 : Release. 3 Categories of services defined in Service Portfolio • Service Pipeline (proposed or in development) • Service Catalogue (Live or available for deployment) • Retired Services (Decommissioned services) Service Portfolio Requirements Description Value proposition Business cases Priorities Risks Offerings and packages Cost and pricing Service Pipeline Service Catalogue •Service Description •Functional Spec’s •Business English •Options •Gold. Silver. Just like a Financial Portfolio. They include the complete set of services managed by a Service Provider.4 Service Portfolios A Service Portfolio describes provider’s services in terms of business value. Control & Validation Best Practices 29 4.1. Bronze •customizations Availability times •(Price list) Retired Services Figure 4.

What are the pricing or chargeback models? 4. priorities and risk? 5. Control & Validation Best Practices The Service Portfolio uses the above information to provide informed responses to the following strategic questions: 1. Why should they buy these services from us? 3. How are resources and capabilities to be allocated? ©The Art of Service . What are our strengths and weaknesses.30 ITIL® V3 : Release. Why should a customer buy these services? 2.

1 Defining Processes Processes can be defined as a structured set of coordinated activities designed to produce an outcome and provide value to customers or stakeholders. but measuring overall efficiency including cost. responsibilities. policies. The ITIL processes covered in detail by this workbook are: • Change Management • Release and Deployment Management • Service Validation and Testing • Evaluation • Request Fulfilment • Service Asset and Configuration Management • Knowledge Management ©The Art of Service . There may be several Managers for the one process or the same person may be both the process owner and process manager (typically in smaller organizations). Some principles: • All processes should be measurable and performance driven (not just time. activities and work instructions if they are needed.ITIL® V3 : Release.2 Processes & Functions 4. A process manager is the person responsible for the operational management of a process. • Processes may define roles. A process owner is the person responsible for ensuring that the process is fit for the desired purpose and is accountable for the outputs of that process. effort and other resources used) • Processes are strategic assets when they create competitive advantage and market differentiation. A process takes one or more inputs and through the activities performed turns them into defined outputs. tools. standards.2. guidelines. management controls. Control & Validation Best Practices 31 4.

32 ITIL® V3 : Release. communication and learning processes. which is intangible.10 – Generic Process Elements © Crown Copyright 2007 Reproduced under license from OGC The figure above describes the physical components of processes. but at the same time they greatly affect and impact the form. So when defining and designing processes. it is important to consider both the physical and behavioural aspects that exist. The behavioural component. which are tangible and therefore typically get the most attention. Control & Validation Best Practices Figure 4. Behavioural components have no independent existence apart from the work processes in which they appear. is an underlying pattern so deeply embedded and recurrent that it is displayed by most members of the organization and includes decision making. ©The Art of Service . substance and character of activities and subsequent outputs by shaping how they are carried out.

This means that Technical and Application Management can be organized in any combination and into any number of departments.ITIL® V3 : Release.g. Mainframe. Control & Validation Best Practices 33 4. Figure 4. Server) are examples of activities performed by Technical Management and are not a suggested organizational structure.2.11 – The ITIL® Functions from Service Operation NOTE: These are logical functions and do not necessarily have to be performed by equivalent organizational structure.2 Defining Functions Functions refer to the logical grouping of roles and automated measures that execute a defined process. ©The Art of Service . The functions within Service Operation are needed to manage the ‘steady state’ operation IT environment. an activity or combination of both. Just like in sports where each player will have a specific role to play in the overall team strategy. IT Functions define the different roles and responsibilities required for the overall Service Delivery and Support of IT Services. The lower groupings (e.

A – Accountability (is made accountable for ensuring that the action takes place. This role implies ownership. RACI Model Service Desk Logging Classification Investigation RACI RACI ACI Desktop RCI RCI Applications RCI Operations Manager CI CI CI Figure 4. I – Inform (the function or position that is told about the event after it has happened). C – Consult (advice/ guidance / information can be gained from this function or position prior to the action taking place). Control & Validation Best Practices 4. This saying comes from failure when executing processes due to misunderstandings of the people involved and a lack of clarity regarding the roles and responsibilities that exist.. ©The Art of Service .2. RACI stands for: R – Responsibility (actually does the work for that activity but reports to the function or position that has an “A” against it).until people get involved.34 ITIL® V3 : Release. with more than one being appropriate where there is shared responsibility.11 – The RACI Model: A RACI Model is used to define the roles and responsibilities of various Functions in relation to the activities of Incident Management. General Rules that exist: • Only 1 “A” per Row can be defined (ensures accountability. more than one “A” would confuse this) • At least 1 “R” per Row must be (shows that actions are taking place). even if they might not do it themselves). A useful tool to assist the definition of the roles and responsibilities when designing processes is the RACI Model.3 Connecting Processes and Functions It is often said that processes are perfect….

3 Other Terminology Terminology IT Service Management: Capabilities: Explanations A set of specialized organizational capabilities for providing value to customers in the form of services. process. E. people. Control & Validation Best Practices 35 4. one IT organization within each of the business units. options. Service provider that provides IT services to external customers. An internal service provider that is embedded within a business unit.ITIL® V3 : Release. i. money or anything else that might help to deliver an IT service. including costs. application. outsourcing A decision support and planning tool that projects the likely consequences of a business action.g. The ability of an organization.g. • Capabilities are intangible assets of an organization and cannot be purchased. • The functions and processes utilized to manage services. person. A generic term that includes IT Infrastructure. • The ITSM set of organizational capabilities aims to enable the effective and efficient delivery of services to customers. but must be developed and matured over time. issues. benefits. It provides justification for a significant item of expenditure. An internal service provider that provides shared IT service to more than 1 business unit e.: one IT organization to service all businesses in an umbrella organization. Resources are also considered to be tangible assets of an organization. IT Services typically don’t provide a source of competitive advantage. but instead support effective and efficient business processes. The person who is accountable for the delivery of a specific IT Service. risks and possible problems. The key factor is that the IT Services provide a source of competitive advantage in the market space the business exists in. They are responsible for continual improvement and management of change affecting Services under their care. Resources: Service Owner: Internal Service Providers: Shared Service Providers: External Service Providers: Business Case ©The Art of Service .e. CI or IT service to carry out an activity.

Control & Validation Best Practices ©The Art of Service .36 ITIL® V3 : Release.

Figure 5. systems and functions required to package.ITIL® V3 : Release.1: – Scope of Service Transition © Crown Copyright 2007 Reproduced under license from OGC ©The Art of Service . Control and Validation Processes and the Service Lifecycle________________ The focus of this workbook is on the processes. build. Control & Validation Best Practices 37 5 Relationship between the Release. This is primarily captured within the Service Lifecycle phase of Service Transition (and supported by Service Operation). test and deploy a release into production and establish the service according to specified requirements.

38

ITIL® V3 : Release, Control & Validation Best Practices

Processes that will be discussed that play a role supporting all lifecycle phases (not just Service Transition) are: • • • Change Management Service Asset and Configuration Management Knowledge Management

Service Transition (by means of the RCV processes) is also responsible for testing and managing change to all of the processes found in the other lifecycle phases.

©The Art of Service

ITIL® V3 : Release, Control & Validation Best Practices

39

5.1 Service Transition
The Service Transition lifecycle phase focuses on the vulnerable transition between the Design phase and the Operation phase of a service. It is particularly critical as functional and technical errors not found during this phase will result in significantly higher impact levels to the business and/or IT infrastructure and will usually cost much more to fix once the Service is in operation. Processes: • Transition Planning & Support** • Change Management • Release & Deployment Management • Service Validation and Testing • Evaluation • Service Asset & Configuration Management • Knowledge Management **(Not covered by the ITIL RCV Program)

Figure 5.2: Service Transition

©The Art of Service

40

ITIL® V3 : Release, Control & Validation Best Practices

5.2 Objectives of Service Transition
The primary objective of Service Transition is the development and improvement of capabilities for transitioning new and modified services into operation. Other objectives include: • To ensure that new and changed services meet customer requirements and do not adversely impact the IT infrastructure or business processes. • To reduce the variation between estimated and actual costs, timeframes, risks and impact scales. • To build, configure, test and deploy quality Releases into operation in the most efficient manner while also minimising disruption to the business and customers.

©The Art of Service

Other benefits delivered include: • Increased success rate of Changes and Releases • More accurate estimations of Service Levels and Warranties • Less variation of costs against those estimated in budgets • Less variation from resources plans.ITIL® V3 : Release. ©The Art of Service .3 Benefits of Service Transition Effective Service Transition can significantly improve a Service provider’s ability to effectively handle high volumes of change and releases across its Customer base. Control & Validation Best Practices 41 5.

Control & Validation Best Practices 5.4 Interfaces to other Service Lifecycle Phases Service Transition rests between the phases of Service Design and Service Operation. Regulations • Architectures • Service Management Plan (a requirement of ISO/IEC 20000) Inputs from the Service Design phase: • Service Definitions • Service Architecture & Structure (including core and supporting services) • Cost models • Capacity/Resource models • Availability and Capacity plans • Acceptance Criteria • Request For Change (RFC) to initiate the required changes to the environment Outputs from the Service Transition phase: The primary outputs from Service Transition are to Service Operation and the customer and end user community being served. Compliance Obligations. with the majority of day-to-day interfaces involved between these three.42 ITIL® V3 : Release. However there are other inputs and outputs that exist with Service Transition and the Service Lifecycle. The following outputs are typically delivered as following successful execution of Service Transition: • Approved Service Release packages and associated deployment packages • Updated Service Packages • Updated Service Catalogues and Service Portfolios • Documentation and Early Life Support for a transferred or decommissioned service. Inputs from the Service Strategy phase: • Service Portfolio Information • Customer and Business Portfolios • Supplier and Vendor Contracts Information • Policies • Organizational Strategies • Constraints. ©The Art of Service .

and UCs. Release Packages. Configuration Item information (CMDB) Service Strategy Service Design Service Transition Initial End User Support. PIR Testing and Validation Results. Control & Validation Best Practices 43 FSC.3: – Some outputs to other lifecycle phases. OLAs. process metrics for improvements. Guidance for SLAs. Change Authorization. CMDB Service Operation Testing and validation results. IT infrastructure audits Continual Service Improvement Figure 5. ©The Art of Service . Changes to IT infrastructure & services. Known Errors from Development. Testing and Validation Results.ITIL® V3 : Release.

Control & Validation Best Practices ©The Art of Service .44 ITIL® V3 : Release.

Control and Validation Processes_________________________ The processes of Release Control and Validation (RVC) are highly interdependent. customers and end-users. • Training and awareness is developed for all stakeholders including IT staff. maintain.ITIL® V3 : Release. Critical Success Factors (CSFs) and associated Key Performance Indicators (KPIs) for all processes involved. • Clear definition of the scope. • Regulations and compliance factors affecting the business or IT. • Knowledge Management providing the mechanism to all Service Transition processes by which to record. objectives. • The management of the RCV processes are based on a defined Service Transition policy (to help define interfaces and resolve possible conflicts). • The type of business and associated customers being served by IT. Control & Validation Best Practices 45 6 Release. the actual RCV team may be a single person in a small IT department or involve a worldwide network of specialist groups in an international organisation. • Service Validation and Testing providing assurance to satisfy both the associated Changes and Releases being implemented. it is important to always ensure: • Clear definition of roles and responsibilities (using a RACI model) of the people. share and communicate knowledge. complexity and maturity of the IT infrastructure. groups and stakeholders involved. ©The Art of Service . all playing specific roles that contribute to the successful management of change in IT Services and IT Service Management processes. Regardless of the size of the actual teams responsible for the RCV processes. This interdependency can be seen by: • Changes being implemented in a controlled manner by using packaged Releases • The typical scope of a Configuration Management System (CMS) being identical to the defined scope of the Change Management process. Based on these influencing factors. The way in which an organization manages the actual Changes and Releases being implemented depends on many influencing factors including: • The complexity and culture of the organisation • The relative size. • The use of outsourcing and external suppliers for small or large portions of the overall IT Service Delivery.

defining the key elements that exist and how they should be used as part of the successful control and management of change of IT Services. Control & Validation Best Practices This chapter describes the RCV processes.46 ITIL® V3 : Release. ©The Art of Service .

all of which require a controlled process by which to assess. 6. it is important to consider the diverse types of Changes that will be assessed and how a balance can be maintained in regards to the varying needs and potential impacts of Changes. complexity and risk of Changes being assessed. These include strategies focussing on time-to-market. “Remember: Not every change is an improvement. in order to minimize the impact of Change-related Incidents upon service quality. efficient and prompt handling of all Changes.1 Goals and Objectives To ensure that standardized methods and procedures are used for controlled. but every improvement is a change!” ©The Art of Service .1 Change Management The ability to control and manage Changes to defined IT services and their supporting elements is viewed as a fundamental element of quality service management. The process of Change Management typically exists in order to: • Optimize risk exposure (defined from both business and IT perspectives • Minimize the severity of any impact and disruption • Delivery successful Changes at the first attempt. In light of this it is important to interpret the following Change Management guidance with the understanding that is intended to be scaled to suit the organization and the size. seeking to improve services.ITIL® V3 : Release. Changes arise for a number of reasons: • From requests of the business or customers. reduce costs or increasing ease and effectiveness of delivery and support. and consequently to improve the day-to-day operations of the organization. most of these are underpinned by the requirement of effective Change control. To deliver these benefits while being careful not causing excessive delays or bottlenecks as part of a coordinated approach to Service Transition. increased market share or high availability and security platforms.1. • From internal IT groups looking to proactively improve services or to resolve errors and correct service disruption. control and manage Changes with varying levels of rigour. Control & Validation Best Practices 47 6. When reviewing the typical strategic objectives defined for an IT service provider.

Control & Validation Best Practices Change Management’s purpose is also to ensure that: 1. supported or baselined hardware. Service Portfolios provides the clear definition of all planned. desktop build or associated documentation. Figure 6. software. environment. application. 2. Overall business risk is optimized 6.2 Scope The term Change is often defined in varying ways. As discussed in 4. All Changes to service assets and configuration items (CIs) are recorded in the Configuration Management Systems (CMS). ©The Art of Service . however the best definition of a service change is: “Any alteration in the state of a Configuration Item (CI).1: Scope of Change Management for IT Services © Crown Copyright 2007 Reproduced under license from OGC The figure above demonstrates the typical scope of the Change Management process for an IT Service Provider and how it interfaces with the business and suppliers at strategic. system. tactical and operational levels.1.” It is important however that every organization defines those changes which lie outside the scope of their service change process (such as operational or business process and policy changes).4. This includes the addition. modification or removal of approved.1. network.48 ITIL® V3 : Release. current and retired services.

1. These policies are typically created with information relating to: • Creating a culture of Change Management – with zero tolerance on unauthorized changes. 6.3 Designing and Planning It is generally advised that the Change Management process should be planned in conjunction with Release & Deployment. policy or other compliance requirements • Documentation requirements • Identification of impact. and Service Asset & Configuration Management. Control & Validation Best Practices 49 6.ITIL® V3 : Release. • Aligning the service Change Management process with business. for internal and external providers.g. • Roles and responsibilities involved • Procedures required.4 Change Management Policies There must be policies and standards defined that clarify. when and what the consequences of non-compliance to the policy will be. • Interfaces to other Service Management processes (e. who must do what. Problem Management) • Toolset requirements to support Change Management • Configuration Management interfaces. project and stakeholder Change Management • Prioritization of changes • Establishing accountability and responsibilities • Segregation of duty controls • Establish a single focal point for changes • Prevent people who are not authorized to make changes from accessing production environment • Integration with other Service Management processes • Change windows • Performance and risk evaluation • Performance measures for the process. These processes together will help in the evaluation of impact. urgency and priority codes for changes. timings and overall risk for changes being assessed. ©The Art of Service . needs.1. The checklist of typical requirements when designing the Change Management process includes: • Regulatory.

password reset or provision of standard equipment to a new employee.3 for the example process flow for normal changes.g. and they are logged and tracked using a different mechanism. E. which will escalate the Change for assessment to the most appropriate person or group. Change Models defines how various categories of changes are assessed & authorized.50 ITIL® V3 : Release. STANDARD Change: A pre-approved Change that is low risk. While standard changes are effectively preapproved by Change Management. RFCs are not required to implement a Standard Change. they may still require forms of authorization such as other groups such Human Resources (HR) or Financial departments. Control & Validation Best Practices 6. such as a service request. with different mechanisms and activities used to process and deliver changes based on the change type. See Figure 6.1. It is assessed by either a Change Manager or Change Advisory Board. The defined Change Models should also include: • What steps should be taken to manage the change • Roles and Responsibilities • Timescales and thresholds for actions • Escalation procedures’ Change Models defined within ITIL include the following: NORMAL Change: A change that follows all of the steps of the change process. ©The Art of Service .5 Change Models The definition of different process models will allow an organization to maintain a balance between providing an appropriate level of control for changes without causing bottlenecks or restricting business growth. relatively common and follows a procedure or work instruction. Normal Changes will often be further defined by the relative impact and complexity.

Organizations should be careful to ensure that the number of emergency changes be kept to a minimum..ITIL® V3 : Release. to resolve a major incident or implement a security patch. STANDARD Change: The main elements of a standard change are that: • Authority is effectively given in advance • The tasks are well known. without sacrificing normal management controls. EMERGENCY Change: A change that must be introduced as soon as possible.. with some documentation occurring after the change has occurred. The change management process will normally have a specific procedure for handling Emergency Changes quickly. because they are typically more disruptive and prone to failure. documented and proven • There is a defined trigger to initiate the Request For Change (RFC) • Budgetary approval is typically defined or controlled by the requester • The risk is usually low and always well understood Over time and as the IT organization matures the list of standard changes should increase in order to maintain optimum levels of efficiency and effectiveness. E. Control & Validation Best Practices 51 Continued. ©The Art of Service .g. To enable this to occur. methods of assessment and documentation are typically modified.

transition. deployment. The inputs required for the change and outputs produced will vary depending on the type defined and whether it is strategic. records and reports Interfaces with other service lifecycle processes should also be considered for a coordinated approach to quality service management. Control & Validation Best Practices 6. release. tactical or operational in nature. documents. project management and supplier management is recommended to enable seamless level of IT quality to be delivered. test. ©The Art of Service . suppliers or other stakeholders. Normal outputs from the process will be: • Rejected RFCs • Approved RFCs • Changes to services. test report and evaluation reports. infrastructure components resulting from approved RFCs • Updated change schedule • Revised PSO • Authorized change plans • Change decisions.1. Additionally the integration of Change Management with Business Change processes. Normal inputs include: • Request for Changes (RFC) • Policy and strategies for change and release • Plans (change. evaluation and remediation) • Current change schedule and projected service outage (PSO) • Current or affected assets and configuration items • Test results.6 Triggers and Interfaces Requests for Change can come from anywhere within service lifecycle or from interfaces with the business.52 ITIL® V3 : Release.

including: • RFCs • Service Desk calls • Project Initiation Documents Different types of change require different types of change request.ITIL® V3 : Release. Control & Validation Best Practices 53 Figure 6. An organization needs to ensure that appropriate procedures and forms are available to cover the anticipated requests from the different parties and stakeholders involved.2: Change Management workflow and key interfaces with Configuration Management © Crown Copyright 2007 Reproduced under license from OGC There can be various types of Change Requests to initiate the execution of Change Management processes. ©The Art of Service . Avoiding a bureaucratic approach to documenting a minor change alleviates some of the cultural barriers and resistance that may exist when adopting the Change Management process.

Assess and evaluate the Change – may require involvement of CAB or ECAB. 6.54 ITIL® V3 : Release. The RFC is recorded.1.7 Change Management Activities The following diagram represents the typical activities involved for Normal Changes that have been identified. The Change is reviewed. 4. ©The Art of Service . Create RFC Record the RFC Update change and configuration information in CMS Initiator Change proposal (optional) requested Review RFC Change Management Ready for evaluation Assess and evaluate change Ready for decision Authorize Change Change authority authorized Plan updates Change Management scheduled Co-ordinate change* Change Management implemented Work orders Authorize Change proposal Work orders Review and close Evaluation report Figure 6. Authorization or rejection of the Change 5. Control & Validation Best Practices 6. The Change is scheduled. Work orders are issued for the build of the Change (but carried out by other groups) 7. The actual steps and procedures need to be further refined depending on any specific Change models that have been created. Review the RFC for classification and prioritization 3. 9. 8. The Change is closed.3: The Activities of Change Management Overview of Important Steps: 1. Change Management coordinates the work performed. 2.

Procedures should stipulate that. via normal management channels. The level of information recorded for a change depends largely on the size and impact of the change. and the log should record this fact.ITIL® V3 : Release. Depending on the Change model that has been applied. a change proposal may be required. Assess and evaluate the Change. This may be recorded directly on the RFC form and details of the change and actions may be recorded in other documents and referenced from the RFC such as business cases. For a major change with significant organizational and/or financial applications. The RFC is recorded. The change proposal will include sign off by appropriate levels of business management. as changes are logged. an initial review should act as a filtering mechanism to apply the correct Change model to be used (classification). together with brief details of the reason for the rejection. The change is raised by a request from the initiator. Review the RFC for classification and prioritization. risk and resource requirements. Change Management reviews each Change request and return any that are: • Totally impractical • Repeats of earlier RFC’s • Incomplete submissions These requests will be returned to the initiator. and should be incorporated within the procedures. Some information is recorded initially and some information updated as the change document progresses through its lifecycle. There should be an opportunity to appeal. cost and complexity. identify the relative priority of the Change. All changes will be assessed for their relative potential impact. ©The Art of Service . To ensure Change Management is using an appropriate level of control based on factors of risk. this assessment may require involvement from: • Only the Change Manager and Change Owner for local authorization • The Change Advisory Board (representing all key stakeholders) • The IT Management (Steering) Board • Business Executive Board. 2. which will contain a full description of the change together with a business and financial justification for the proposed change. 3. Control & Validation Best Practices 55 1. and to ensure that the required details are supplied.

capacity plan. Control & Validation Best Practices The scope of potential impacts on services for failed changes is wide. baselines.Executive decision Change impacts multiple services/ organizational divisions Change impacts only local/ service group Change to a specific component of an IT Service Standard Change ©The Art of Service .56 ITIL® V3 : Release. person or a group of people. and any Service Operation practices. service models. security etc • Impact on other services • Impact on non-IT infrastructures • Effect of not implementing • Cost and staffing implications • Current Change Schedule • Ongoing resources required after implementation • Impact on continuity plan. A degree of delegated authority may also exist within an authorization level. The IT Management (Steering) Board Change Advisory Board (CAB) or Emergency CAB (ECAB) Change Manager Local Authorization Potential Impact/Risk High cost/risk change . The levels of authorization for a change should be judged by: • Type • Size • Risk • Financial implications • Scope. The following table describes the type of hierarchical structures that may be used for different levels of change authorization. Formal authorization is obtained for each change from a change authority that may be a role. test environments. so the assessment needs to identify potential for: • Impact on customer’s business operation • Effect on SLA’s. Level 1 2 3 4 5 Change Authority Business Executive Board. security plan.

in addition to any planned downtime from other causes such as planned maintenance and data backups. it is important to consider both the implications of performing the Change. test or implementation of the change will be scheduled when resources are available and when they least impact on live services or business critical times. The assessment of the change will have provided an estimation of the resource requirements for delivering a successful change. test and implementation of the change? 7. Who RAISED the change? 2. The Change is scheduled. These questions are: 1.What’s it going to cost? And what’s the cost of not doing it? • Business Approval . they in turn will ensure they have the approval of three main areas. Any service disruption is documented in with the Projected Service Outage (PSO). customers and end users. What is the REASON for the change? 3. Change Management will need to coordinate with Release and Deployment Management so that any activities required for the build.ITIL® V3 : Release. Control & Validation Best Practices 57 The 7 Rs of Change Management provide a set of guiding questions that need to be answered as part of the overall assessment for Changes. as well as the impacts of NOT implementing the Change. What is the RETURN required from the change? 4.What are the consequences to the business? And not doing it? • Technology Approval . ©The Art of Service . What are the RISKS involved in the change? 5. 5. What is the RELATIONSHIP between this change and other changes? 4. What RESOURCES are required to deliver the change? 6. This details any revised Service Level Agreement and service availability targets because of the events in the Change Schedule. The timing of events and eventual implementation will be communicated via the Change Schedule. • Financial Approval . Who is RESPONSIBLE for the build. and visible to the appropriate IT staff members.What are the consequences to the infrastructure? And not doing it? When authorizing changes. Authorization or rejection of the Change While the responsibility for authorization for Changes lies with the Change Manager. This also requires empowering the Change Manager with an appropriate level of authority as their primary role is to protect the integrity of the IT infrastructure and the services provided to customers.

Lessons learned should be embedded into future changes as part of continuous improvement. Ideally. and by establishing that the remediation is viable. The Change is reviewed. This includes whether the request should be developed as a standard change or whether another change model is more appropriate for future management of similar requests. Change Management coordinates the work performed. Control & Validation Best Practices 6. Only by considering what remediation options are available before instigating a change. This will be greatly influenced by the availability of staff and any Release policies defining how and when changes are released to the live environment. 7. and then presented as a completed change for stakeholder agreement. no change should be approved without having explicitly addressed the question of what to do if it is not successful. Remediation Planning is a critical element during the coordination of Changes. This is an oversight role to also ensure that all changes that can be. ©The Art of Service . There should be a back-out plan that will restore the organization to its initial situation. special care needs to be taken during implementation. through reloading a baselined set of Configuration Items. On completion of the change. the results should be reported for evaluation to those responsible for managing changes. Change Management plays a co-ordination role as implementation is the responsibility of others (under the direction of Release and Deployment management or from Project Management groups). Work orders are issued for the build of the Change (but carried out by other groups) Change Management will coordinate with Release and Deployment to identify the groups or individuals responsible for the implementation of the various elements making up the Change. The review should confirm that the change has met the defined objectives.58 ITIL® V3 : Release. that the initiator and stakeholders are happy with the results and that there have been no unexpected sideeffects. are thoroughly tested. In all cases involving changes that have not been fully tested. can the risk of the proposed change be determined and the appropriate actions taken. 8. Major changes will require more customer and stakeholder input throughout the entire process.

Members of the CAB are made up by IT staff.8 Roles and Responsibilities within Change Management Change Advisory Board (CAB) The CAB is a body that assists the Change Manager is evaluating and approving changes that have been requested. The Change is closed. Control & Validation Best Practices 59 Two types of reviews are performed for normal changes: • • The review of a service change – immediately visible to the customer and scheduled for discussion at the next service level management review meeting. archiving or other policy requirements that have been defined. If the change review was satisfactory or the original change is abandoned (e. suppliers and other stakeholders in such a way that all changes that impact their domain can be appropriately assessed from business.ITIL® V3 : Release. When a change has not achieved its objectives. technical and support viewpoints. Change Management must review new or changed services after a predefined period has elapsed. This process will involve CAB members. the needs for the change is decreased or disappears) the RFC should be formally closed in the logging system. Change Management (or CAB) will decide what follow-up action is required. 6. ©The Art of Service . 9. which will be (almost) invisible to the customer.g. An infrastructure change – concerned with how IT delivers rather that what IT delivers. The CAB is not necessarily a physical meeting of people. compliance. Typical representatives for a CAB under normal conditions are: • The Change Manager (chairs the CAB) • Customer representatives • User management • Application Developers/Supporters • Technical Experts and Consultants • Other Services Staff • Vendors and Suppliers. since change reviews are a standard CAB agenda item. but can be enabled with the use of technology such as video-conferencing. customers.1. These records will be kept for a period of time based on business.

Metrics should be linked to business goals whenever practical. which is a sub-group that will provide the assistance for the evaluation of Emergency Changes. • Current and outstanding changes.60 ITIL® V3 : Release. reliability and customer satisfaction. availability. an ECAB would be used instead. 6. CAB members should come prepared with any documentation that was produced as part of their evaluation or advice on current changes.9 Key Performance Indicators (KPIs) of Change Management It is important that a balanced view of metrics is used when assessing the effectiveness and efficiency of the Change Management process. and to cost. ©The Art of Service . In order to maintain an effective meeting. • RFCs to be assessed by the CAB ordered by priority. • Identified process issues or improvements. Standard items for the CAB agenda include: • Failed. Emergency Change Advisory Board (ECAB) For Emergency Changes. • Concluded changes for review. As it will not always be possible to convene a full CAB meeting. it is still important to apply an appropriate level of testing as well as define any roll-back mechanisms relative to the potential risk and impact identified. Ultimately the final decision to authorize changes will rest with the Change Manager or whichever body or person has been delegated for this in the organization (typically the IT director or service manager). Control & Validation Best Practices Rather than having a static list of members. • Advance notice of RFCs expected for review at next CAB meeting. a separate defined procedure and authorization mechanisms should exist and be clearly documented and understood. the CAB should include both static and dynamic members who will attend based on the needs for the changes being discussed. This may be 3 or 4 members of the normal CAB who between them have the best overview of the potential risks and impacts of implementing the Emergency Change. While complete testing may not be possible. unauthorized or backed-out changes.1.

Control & Validation Best Practices 61 These metrics include: • Number of RFCs (Accepted/Rejected) • Number and % of successful Changes • Emergency Changes • Number of Changes awaiting implementation • Number of implemented Changes • Change backlogs and bottle-necks • Business impact of changes • Frequency of Change to CIs • Number of disruptions (incidents and problems) caused by unsuccessful changes • Level of variance between estimated and actual resources and time required for changes • Frequency of change (by service. ©The Art of Service . as there can be many instances where service quality can be negatively impacted as a result of changes executed by the end-user community. it may be appropriate to run a pilot for Change Management. the scope of Change Management should eventually include the customers and end users just as much as IT staff members themselves.ITIL® V3 : Release.) • Number of changes (by change type) • Number of changes recorded and tracked using automated tools • Staff utilization • Number of unauthorized changes detected by Configuration Management 6.10 Challenges affecting Change Management Implementing Change Management should be managed with particular sensitivity and awareness due to the often large cultural changes that will need to take place.1. This will need to be addressed by developing stakeholder awareness at all stages during the implementation project. Over time. including gaining feedback about their needs. expectations and ideas. Depending on the current maturity of informal change management practices. in order to identify the potential successes and failures and to better refine and scale according to the organization’s needs. business area etc.

projects ducking the Change Management planning Optimal link with Configuration Management .4: Relationship with Project Management How does Change Management work with Project Management? • Change Management authorizes.11 Relationship with Project Management Figure 6. • It does not plan. coordinates the changes involved in a given project.62 • • • • • ITIL® V3 : Release. build. ©The Art of Service . test or implement.1 central process comes into place that influences everyone’s activities Bypassing .to execute a controlled change all data MUST be reliable Commitment of the supplier(s) to the process Commitment of management. Control & Validation Best Practices Typical challenges that affect the success of Change Management include: Change in culture . 6.1. controls. • Change Management is also concerned with Remediation Planning to ensure that each RFC has a fallback / rollback plan.

ITIL® V3 : Release. Business Case Summary Full justification Effect of not implementing the change (business. e. legislation) √ Description Summary Full description Identity of item(s) to be changed – description of the desired change Summary Full description Service (for enhancement) or CI with errors (corrective changes) Reason for change.g. financial etc.1. problem report number. to purchase order.12 Typical Contents of Change Documentation RFC Change proposal (if appropriate) √ Related assets/CIs Attribute on the change record Unique Number Trigger (e. business need. error records. Control & Validation Best Practices 63 6.) √ Configuration items and baseline versions to be changed √ Affected baseline / release Details of CIs in baseline / release ©The Art of Service .g. technical.

64 ITIL® V3 : Release. resources. benefits Provisional Initial Impact √ ©The Art of Service . Control & Validation Best Practices Contact and details of person proposing the change √ Date and time that the change was proposed √ Change category. e. cost. minor. significant.g. costs and quality of service Change priority Summary / reference Full Proposed Risk assessment and risk management plan Summary / reference Full Back-out or remediation plan Possibly Full Impact assessment and evaluation – resources and capacity. major Proposed Predicted timeframe.

and test plan? √ Change decision body √ Decision and recommendations accompanying the decision √ Authorization signature (could be electronic) √ Authorization date and time √ Target baseline or release to incorporate change into Target change plan(s) for change to be incorporated into √ √ ©The Art of Service . security plan. capacity plan.ITIL® V3 : Release. Control & Validation Best Practices 65 Plans affected Would the change require consequential amendment of IT Service Continuity Management (ITSCM) plan.

Control & Validation Best Practices Scheduled implementation time (change window. release window or date and time) √ Location / reference to release / implementation plan √ Details of change implementer √ Change implementation details (success / fail / remediation) √ √ Actual implementation date and time √ Review date(s) √ Review results (including crossreference to new RFC where necessary) Summary Closure Summary ©The Art of Service .66 ITIL® V3 : Release.

Set up a system for communicating change Steer change Mobilize the organization Mobilize their department.g. team Lead workshops and group analysis of the current processes Run effective meetings Solve problems in groups A/R A/R A/R A A/R A C C C A/R A/R A/R A/R C C C A/R A/R C A/R A/R A/R A C A/R A C C C C A/R A/R A/R A/R A/R A/R A/R A/R A/R ©The Art of Service . e. process owners. team leader instructing change C Change target.13 RACI Example for Managing Change Change Sponsor.g. unit.ITIL® V3 : Release. understand the levers for change and the obstacles Manage change and input to change plan Input to design of target organization or structure. e. business and IT leaders Change enabler.1. e. e.g.g. individual performing the change I Role/Responsibility Articulate a vision for the business and service change in their domain Recognize and handle resistance to change Initiate change. Control & Validation Best Practices 67 6. service owners A/R Change agent. etc.

transition support to service operation. test and deploy a release into product and enable effective handover to service operations.1 Goals and Objectives To deploy new releases into production. • Ensure the required skills and knowledge is transferred to support staff. ©The Art of Service . 6. While timely and accurate distribution is indeed a goal of the process.68 ITIL® V3 : Release. customers and service operations. customers. Release and Deployment can be mistakenly seen as the poor cousin of Change Management. systems and functions required to build. distribute and rollback releases in accordance with defined policies that improve efficiency and reduce business disruption. and enable its effective use in order to deliver value to the customer. Much of the confusion and misunderstanding is perpetuated by the idea that Release and Deployment only focuses on the actual distribution of changes to the live environment. In conjunction with the use of Change Management. reuse. Other objectives of Release and Deployment are: • To define and agree upon Release policies. the actual scope includes all of the activities. suppliers and any other relevant stakeholders. compile. and Release and Deployment plans with customers and stakeholders. Release and Deployment will enhance an organization’s capabilities to develop. installed. verified. uninstalled or backed out if necessary. Control & Validation Best Practices 6.2. being of less importance and priority to both the business and IT organizations. • Ensure that all release packages can be tracked.2 Release and Deployment Management Often forgotten or ignored in many IT Service Management implementations or initiatives. end users. • Ensure the integrity of constructed release packages and that they are recorded accurately in the Configuration Management System (CMS). • There is minimal unpredicted impact on the production services.

test and distribute a release unit • The complexity of interfaces between the proposed unit and the rest of the services and IT infrastructure • The storage and resources available in the build. 6. Well planned and implemented release and deployment will make a significant difference to an organization's service costs.2. Typical benefits seen as a result of improved Release and Deployment are: • • • • Delivering change. it is important to remember that it should be utilized in conjunction with the other Service Transition processes. improvements in the metrics defined for Release and Deployment may be at the expense of the other transition processes. Control & Validation Best Practices 69 6. force IT personnel to spend significant amounts of time troubleshooting problems and managing complexity. As a result. At worst.4 Terminology Release Unit: A ‘release unit’ describes the portion of a service or IT infrastructure that is normally released together according to the organization’s release policy. ©The Art of Service .3 Benefits When identifying the benefits that Release and Deployment provides for. at optimum cost and minimized risk Assuring customers and users can use the new or changed service in a way that supports the business goals Improving consistency in implementation approach across the business change.2. 6. at best. test. it can cripple the environment and degrade the live services. service teams. distribution and live environments.2 Scope Release and Deployment works closely in conjunction with the other RCV processes to enable the quality transition of services. A release is a collection of authorized changes to an IT service. The role played specifically by Release and Deployment is to build. A poorly designed release and deployment will. faster. When defining the most appropriate release unit structure. suppliers and customers Contributing to meeting auditable requirements for traceability through Service Transition. validate and distribute authorized service changes to the target systems or users.2. the following factors should be taken into account: • The ease and amount of change necessary to release and deploy the release unit • The amount of resources needed to build. package.ITIL® V3 : Release.

v2.70 ITIL® V3 : Release. Like the definition of release units. • Emergency Fix: Banking_System v1.2 etc o A temporary or permanent Quick Fix for a Problem or Known Error ©The Art of Service . v1.1.1.1. v1. including the associated user or support documentation that is required. the amount of change occurring and resources required will be considered when formulating a complete Release Package. it may mean that for critical applications the release unit is the complete set of application components and for optional features or add-ons only the single component itself. Release Identification: The unique release identification scheme which is normally defined in the Release Policy and conforms to any standards defined by Service Asset and Configuration Management.1. factors such as the modularity of components. v1. v3 etc o Major roll-out of new hardware and/or software • Minor Release: Banking_System v1.5: Simplified example of release units for an IT service © Crown Copyright 2007 Reproduced under license from OGC Release Package: A release package may be a single release unit or a structured set of release units. Control & Validation Best Practices Based on these factors. Typical identification schemes include the following examples: • Major Release: Banking_System v1.2. Figure 6.3 etc o A few minor improvements and fixes to Known Errors.

ITIL® V3 : Release. The DML includes both electronic and physical copies of definitive software releases. and additional components can be used when needed for additional systems or in the recovery from Incidents.6: The use of the DML by Release and Deployment © Crown Copyright 2007 Reproduced under license from OGC Definitive Spares: Physical storage of all spare IT components and assemblies maintained at the same level as within the live environment. details of these assemblies are recorded in the ©The Art of Service . with Release and Deployment being responsible for any additions. Figure 6. New IT assemblies are stored here until ready for use. Control & Validation Best Practices 71 Definitive Media Library (DML): The secure library where the definitive authorized versions of all media CIs (typically software) are stored and protected. Like the DML. removals or maintenance that needs to be performed. The DML should include definitive copies of purchased software (along with license documents and any controlled information) as well as software developed on site. modifications.

This should include automation where possible for its compilation and distribution. 6. Build Management: The software. UCs • Deployment plans and packages • Service Transition Report ©The Art of Service . Control & Validation Best Practices CMDB. Other inputs will also be provided from Service Strategy and Service Design to ensure that the requirements for value provision have been met.5 Triggers and Interfaces The primary interfaces of release and deployment exist with Change Management and the surrounding Service Transition processes. The inputs to release and deployment include: • Authorized RFCs • Service Packages • Service Design Package • Service Acceptance Criteria • Service Management policies and standards (including the Change Policy) • Build Models and plans • Exit and entry criteria for each stage of release and deployment The outputs include: • Release and deployment plan • Updated RFCs for any required activities • Updated service catalogue reflecting any service changes • New or modified service • New or modified processes • Skilled and knowledgeable support staff • End users with capabilities to use the service • SLAs. which for large organizations can significantly reduce the Total Cost of Ownership (TCO) for the services involved. OLAs.72 ITIL® V3 : Release. and their management and deployment the responsibility of the Release and Deployment process.2. hardware and documentation that comprise a release unit should be assembled in a controlled manner to ensure a repeatable process.

consideration about the potential impact and need for resources will affect how releases will be deployed to the target locations.6 Release Design Options and Considerations When planning individual releases or defining the policies that should exist.ITIL® V3 : Release. The common options for deploying releases are described below: Big Bang or Phased Big Bang: Where the new or changed service is deployed to all user areas in one operation. © Crown Copyright 2007 Reproduced under license from OGC Phased roll-out ©The Art of Service . and then this operation is repeated for subsequent parts of the user base via a scheduled rollout plan. Release Policy Release 1 Release 2 Release 3 1 2 3 4* 5* 1 2 3 4 5 6* 7* 1 2 3 4 5 6 7 8* Initial Launch ‘Big Bang’ roll-out * Additional Workstations Figure 6.7: Options for ‘big bang’ and phased rollouts.2. This will often be used when introducing an application change and consistency of service across the organization is considered important. Control & Validation Best Practices 73 6. This will be the case in many scenarios such as in retail organizations for new services being introduced into the stores’ environment in manageable phases. Phased Approach: The service is deployed to a part of the user base initially.

Pull approaches do not rest so heavily on accurate configuration data and they can trigger an update to user records.74 Push or Pull ITIL® V3 : Release. since the new or changed service is delivered into the users’ environment at a time not of their choosing.C’s and servers when it best suits the customer. Software is made available in a central location but users are free to pull the software down to their own location at a time of their choosing or when a workstation restarts. which are typically pulled down to update P. triggering investigation into their continued existence. The use of ‘Pull’ updating a release over the internet has made this concept significantly more pervasive. either in big bang or phased forms is the use of a push approach. This may be through new users appearing and requesting downloads or expected users not doing so. This will ultimately slow down the release team and create resource and capacity issues that affect the agreed service levels ©The Art of Service . In terms of service deployment. however at times of extreme virus risk this may be overridden by a release that is pushed to all know users. The time required to provide a well-designed and efficient automated mechanism may not always be available or viable. Typical examples of activities that are capable of a degree of automation are: • Discovery tools aid release planning • Automate builds reduce time taken this in turn can resolve scheduling conflicts and delays • Automated configuration baselines procedures save time and reduce errors in identifying the status of CI’s and releases during build. A good example is virus signature updates. delivering updated service components to all users. test and deployment etc Manual: Important to monitor and measure the impact of many repeated manual activities as they are likely to be inefficient and error prone. Control & Validation Best Practices The Push Approach: service component is deployed from the centre and pushed out to the target locations. Automated or Manual Automation: Helps to ensure repeatability and consistency. The Pull Approach: used for software releases.

preparation & training Logistics.2. Control & Validation Best Practices 75 6.ITIL® V3 : Release. Typical contents of a Release Policy include: • • • • • • • • • Level of infrastructure to be controlled by Releases Preferred structure and schedules for Release Packages Definition of major and minor releases.8 Release and Deployment Activities Release policy & planning Design & develop or order & purchase Build & configure release Release testing & acceptance Deployment planning Communication.7 Release Policy A Release Policy is the formal documentation of the overarching strategy for releases and was derived from the Service Design phase of the Service Lifecycle. The Release Plan is the operational implementation for each release. Delivery & installation Key Points: The Release Policy is the overarching strategy for Releases and was derived from the Service Design phase of the Service Lifecycle. emergency fixes Expected deliverables for each type of Release Policy on the production and execution of back out plans How and where Releases should be documented Blackout windows for releases based on business or IT requirements Roles and responsibilities defined for the Release and Deployment process Supplier contacts and escalation points 6.2.8: Phases and activities of Release and Deployment ©The Art of Service . Figure 6. It is the governing policy document for the process and must accommodate the majority of releases being implemented. The Deployment Plan is the documented approach for distributing a single Release.

and conform to any policies that have been defined. Review and close Service Transition 1. Plan and prepare for deployment 6. impact and resource requirements for components of the change.76 ITIL® V3 : Release. Typically the release and deployment plans should document the: • Scope and content of the release • The risk assessment for the release • Affected stakeholders • Teams responsible for the release • Communication strategy to be used during the release and deployment process Plans should take into account the acceptance criteria that exist for the release and when authorization points will verify a pass or fail. test and deployment 3. Review and close the deployment 10. Deployment and retirement 7. Build and test 4. Preparation for build. pause or revert to previous stages of the release. Control & Validation Best Practices Overview of Important Steps: 1. For each release. Release Planning Any plans created for the release and deployment will need to be integrated with the overall Service transition plan. The processes of Evaluation and Service Validation and Testing will be integrated here to assist in the determination whether to continue. Early Life Support 9. Perform transfer. Service test and pilots 5. Release planning 2. ©The Art of Service . Verify deployment 8. plans should be authorized by Change Management and used to assist in the evaluation of the risk.

roles and responsibilities for any key activities • Defining the build exit and entry criteria. • Scheduling the resources and time required to setup the environments • Testing the build and compilation procedures • Scheduling the build and compilation activities • Assigning resources. Control & Validation Best Practices 77 Build and test planning The approach taken for building.ITIL® V3 : Release. Environments that may be utilized during this period include: • Build environments • Testing and integration environments • Deployment environments • Pilot environments • Backup and recovery environments Utilizing Pilots Pilots may be useful for testing the service with a group of participants that are representative of the broader end-user community. Deployment Planning ©The Art of Service . For complex releases or in large and diverse organizations it may be appropriate to use more than one pilot for address the different implementation and support issues that exist. For this to be effective the scope needs to be carefully determined. The activities that occur here are: • Developing build plans based on the Service Design Package and defining any environment requirements. Pilots should include mechanisms by which feedback can be gathered about various aspects of the release and associated processes. testing and maintaining the controlled environments to production will need to be planned in order to enable optimum use of resources for the development of the release. as being either too large or too small will likely result in some negatively impact to the overall success and quality of the release and deployment process.

Who else needs to be prepared well in advance? (training. security etc) 6. Control & Validation Best Practices There are many factors that will be considered when choosing the most appropriate deployment strategy (refer back to deployment options). Where are the users? 5. various financial and commercial factors will need to be assessed before the deployment activities. Are there location dependences? 4. Preparation for build. the release design must be validated against the requirements defined for the new or changed service offering. Training of involved release and deployment staff In many cases the introduction of a release may require additional training for the release. including: • Working capital • Contracts and licenses • Funding • Intellectual property requirements 2. and any issues documented in an interim evaluation report. deployment. When does the deployment need to be completed? 7. test and deployment Before the actual building of the release occurs. What are the critical success factors and exit criteria? 9. This should be an independent evaluation that checks the release will deliver the predicted outcomes. Who are the users? 3. What needs to be deployed? 2. build and test teams. Such training could be related to the: • Service management processes to be used • Changes in security or health and safety procedures • Understanding of the Service Design documentation and plans • Technology being utilized for the release. What is the current capability of the service provider? Financial/Commercial Planning Where necessary.78 ITIL® V3 : Release. Questions that must be answered include: 1. ©The Art of Service . Why is the deployment happening? 8.

Build and test Wherever possible. sharing and archiving knowledge. capturing and recording information. ensuring proof of licence and triggering updates to the Asset Management System.ITIL® V3 : Release. moving and installing equipment o Wiping sensitive data and media o Publishing. Typical documentation that will be used by the release teams include: • Contract agreements • Purchase requests • Health and Safety guidelines • Security policies • Licence agreements • Procedures for: o Distributing software o Delivering. Acquire and test required components Release and Deployment should be interfaced with the organization’s existing procurement processes to acquire any required components for the release. This includes managing the: • Build. knowledge bases and other guidance should be consistently available to support the release team in the activities performed. each of the individual components should be tested to verify that any quality criteria has been met. ©The Art of Service . This will save time and effort in verifying assets. initiating action where quality criteria is not met. information and data. As part of the overall Service Validation and Testing. test and packaging environments • Compilation and packaging tools • Configuration of the releases themselves: o Version control o Documentation templates for testing and validation o Access rights and security procedures Release and build documentation Documentation templates. Control & Validation Best Practices 79 3. procedures. repeatable practices and reusable components should be utilized to during the build and test of releases.

to provide repeatable practices and expected outcomes. Managing the build and test environments The need for multiple environments in which to build and test will depend on the size. Automating the installation of systems and software reduces the workload of people. frequency and impact of the releases being managed. Key actions to take during pilots are: • Training of any people involved • Documentation of any required procedures • Continual communication and engagement with customers and users • Determine the levels of support required for the actual release • Discover and fix issues wherever possible before the final deployment • Document improvements where appropriate and incorporate them into future plans ©The Art of Service . When a definitive package has been assembled. a baseline should be taken of the release package and the correct versioning and naming conventions applied.80 ITIL® V3 : Release. With particular focus on the release itself. Test environments should be protected using a range of testing best practices (see also Service Validation and Testing). testing and validation must be performed at multiple levels. tools and checklists should be utilized as part of the release packaging. which simulates as much of the service as possible in an extensive and widely involved practice session. Pilots Previous planning should have already identified what pilots will be used as part of the overall release and deployment. complexity. This would normally occur after other pilots have run. Control & Validation Best Practices Release Packaging Build management procedures. service rehearsals may be used. 4. and is designed to be the last measure to detect any potential issues that will arrive during or after the deployment to the live environment. but also requires testing of the scripts and mechanisms that will be used. and appropriate access to these environments given based on the priorities defined. Service testing and pilots (See Service Validation and Testing) As part of a coordinated effort with Service Validation and Testing.

9: – Example set of deployment activities © Crown Copyright 2007 Reproduced under license from OGC ©The Art of Service .ITIL® V3 : Release. Control & Validation Best Practices 81 5. Plan and prepare for deployment At this stage the focus is to prepare the organization and people for organizational change and to refine and deployment plans that have been documented. These plans should include guidance regarding: • Risk mitigation plans • Disposal and retirement plans • The logistics for delivery • Knowledge transfer • Mobilizing users to be ready to use the service • Mobilizing the support staff for service readiness Figure 6.

8: Early Life Support The quality of transition to Service Operation is a crucial element to the success of the overall service change that is being implemented. verification should occur that users are capable of operating the service. This enables more stability in this vulnerable period. the activities performed can be grouped under the following tasks: 1. 7: Verify deployment Once the activities for the deployment of releases are finished. Transfer financial assets 2. Verification should ensure that: • The service/release components are in place by means of a configuration audit • Documentation has been updated accordingly • Roles and responsibilities have been correctly assigned • The measurement and reporting systems are established to measure performance of the service Any noted deviations from plans or other items raised should be documented in order to improve future implementations and processes used. enhanced learning and better momentum for continual improvement. Transfer service 6. deployment and retirement During the actual implementation itself. Deploy processes and materials 4. increased customer and user satisfaction. Rather than simply hand off support post-deployment. incidents and problems that are detected in the early of the new or modified service. Decommissioning and service retirement 8. Transfer changes required to business/organization 3. Deploy Service Management Capability 5. the release and deployment teams should assist in managing any calls. Deploy service 7. Control & Validation Best Practices 6: Perform transfer.82 ITIL® V3 : Release. The resource allocation from these teams will then be gradually reduced while Service Operation takes on more responsibility for support. Remove redundant assets These activities will need to be modified to accommodate any items specified in the deployment plan as part of the acceptance criteria for ‘go live’. ©The Art of Service .

©The Art of Service . and the transfer of knowledge to service desk staff (including knowledge base articles).10: Typical Early Life Support Activities © Crown Copyright 2007 Reproduced under license from OGC Figure 6. which might include such conditions as: • Users can use the service effectively and efficiently for their business activities • Service delivery is managed and controlled across any service provider interfaces • Service levels and performance standards are being consistently achieved • Stakeholder groups verify the transfer of required knowledge • All deliverables required for the release have been signed off. Control & Validation Best Practices 83 Figure 6.11: The benefits of using Early Life Support The example shown in the figures above demonstrate how the number of incidents for deployment A was significantly reduced through the use of Early Life Support. The acceptance criteria for finalizing Early Life Support should be agreed early in the process.ITIL® V3 : Release. including the training of users and staff.

Control & Validation Best Practices 9: Review and close the deployment A formal review of deployments should be performed for all releases of a determined level of size. Figure 6.12: Transitioning New and Changed Services into Operation ©The Art of Service .84 ITIL® V3 : Release. This will utilize the process of Evaluation and is driven by Change Management. The review seeks to ensure that all requirements for the release have been met and to identify and potential improvements that can be made. which will verify successful completion and that the handover to Service Operation is complete. Items that should be reviewed include: • Any quality criteria deviations that exist • Any open actions or necessary fixes that have been identified • Review open changes • Review performance targets and achievements • Experiences and feedback from customers. impact. users and staff involved with the deployment. • All problems and known errors are documented and accepted by the business and/or suppliers • Check that any redundant assets (including licences) have been removed 10: Review and close Service Transition The final step required in finalizing the completion of Service Transition is a formal review appropriate to the relative scale of the change. cost or risk to the organization. The “lessons learnt” should be documented to provide any improvement opportunities that can be made and developed by Continual Service Improvement for future transitions.

6. Release & Deployment. test and deployment activities Customer metrics: • Decreased variance in service performance against predicted performance • Reduced number of incidents during Early Life Support • Increased customer and user satisfaction • Faster adoption of new and modified services amongst end user community ©The Art of Service .ITIL® V3 : Release.9 Key Performance Indicators (KPIs) of Release & Deployment Management Service Provider metrics: • Reduced resources and costs to diagnose and fix incidents and problems in deployment and production • Reduced discrepancies in configuration audits • Increased accuracy in deployment of software • Increased compliance with software licence requirements and reduced oversubscriptions • Reduced time and resources consumed by build. Service Validation & Testing and Service Asset & Configuration Management work together for the transition of new or modified Services.2. package. Control & Validation Best Practices 85 Note how Change.

capacity and constraints. This includes verification that the service is ‘fit for purpose’ and ‘fit for use’.1 Goals and Objectives The overriding goal of Service Validation and Testing is to assure that the new or modified service will provide the appropriate value to customers and their business. ©The Art of Service . • Confirm that customer and stakeholder requirements and criteria are correctly defined and address and variances as early as possible. Control & Validation Best Practices 6.86 ITIL® V3 : Release.3. The underlying concept to which Service Validation contributes is quality assurance – establishing that the service design and release will deliver a new or changed service or service offering that satisfies the requirements and standards of the customers and stakeholders involved. Other objectives include: • Provide confidence that service changes deliver the expected outcomes and value for customers within the projected costs.3 Service Validation and Testing 6.

Depending of the criticality.2 Policies and Principles Service Quality Policy Consideration needs to be given to defining the meaning of service quality. The process of Service Validation and Testing can be used as an opportunity to clarify that it is impossible to guarantee exact levels of performance and quality. In addition to these overall guidance provided by Service Strategy. any dominant focus will influence how services are designed.4. 6. in extreme circumstances even injury or death.1 Benefits Insufficient testing practices will usually always result in some level of service failure. Control & Validation Best Practices 87 6. this can result in long-lasting effects on the reputation and success of the provider and business. more detailed service level metrics will be developed during the Service Design phase and handed over as part of the Service Design package. Release and Deployment and Evaluation will need to be interfaced with Service Validation and Testing. This will require that the all components and providers that are involved in the end-to-end service are considered as part of the approach for Service Validation and Testing. operated. size and number of end users or customers affected. ©The Art of Service . Service Strategy should provide guidance regarding the approach and standards for quality. The processes of Change. test and deployment activities of the releases required.4 Scope The concepts of Service Validation and Testing can be applied throughout the entire service lifecycle to quality assure any aspect of a service and the provider’s capability to deliver and support it. from the perspectives of: • Level of excellence • Value for money • Conformance to specification • Meeting or exceeding expectations While a balanced approach to these perspectives should be maintained. which in turn will ensure the appropriate levels of testing are performed for the build.4. but instead that an appropriate level of confidence can be achieved with appropriate testing and safeguards in place. 6.ITIL® V3 : Release. measured and controlled.

validation and testing and security provision for services being offered. As the frequency of releases increases so does the requirement for consistent and reusable test models and automated testing mechanisms. As different segments will have varying attitudes and perspectives regarding risk. Change Management Policy Like the Release policy. In the case of a release that is behind schedule but still needs to be deployed within a defined change window. including the level of Change control.88 Risk Policy ITIL® V3 : Release. type and frequency for releases will have a large impact of the levels of testing and validation used. Control & Validation Best Practices Risk policies are designed to influence how a service provider manages risk. Release Policy The documented policy describing the approach. what sacrifices will be made in order achieve the proposed distribution date? Typical elements within Change Management policies that relate to testing include: • The integration of testing within the service lifecycle and projects • Using a risk-based approach to testing • Engaging all appropriate stakeholders throughout the project and service lifecycle for testing • Automation of testing mechanisms ©The Art of Service . the level of confidence established in services will change depending on the safety criticality or compliance factors that apply. any documented change windows will influence the level of testing that can be provided for throughout Service Transition.

©The Art of Service .ITIL® V3 : Release.13: Design constraints of a service © Crown Copyright 2007 Reproduced under license from OGC When constructing a Service Design package there are many influencing constraints that influence how a new or modified service will be developed and built (see figure above). Control & Validation Best Practices 89 Figure 6. Service Validation and testing should verify that these boundaries are correctly defined and that the service can be transitioned within those boundaries. Within these constraints. the primary focus of service validation is ensuring that the required service utility and warranty (see below) has been delivered by the new or modified service.

3 Test Models A test model describes a test plan. goals and objectives of service testing and validation • Scope and organizations • Applicable standards. Control & Validation Best Practices Performance supported? Constraints removed? UTILITY Fit for purpose? Available enough? Capacity enough? Continuous enough? Secure enough? Figure 6.14: Creating Service Value Value WARRANTY Fit for use? Test Strategy A test strategy describes the overall approach to organizing testing and validation. There is traceability to the initial design requirements and criteria 2.90 ITIL® V3 : Release. legal and regulatory requirements • Service Management policies. documentation. It ensures that testing is a repeatable process and that the defined deliverables are achieved. a set of services or a single service. That test elements can be reused or changed ©The Art of Service . Test models should be structured so that: 1. All activities can be measured and audited 3. including the allocation of the enabling resources required. the scope of a test and the test scripts that define how each element will be tested. control. The typical contents of a test strategy document include: • The purpose. execution etc) • Test metrics • Service Provider interfaces • Test criteria • Roles and responsibilities • Environment requirements • Deliverables 6. processes and practices applicable to testing • Test models used • Test process activities (planning and estimation. It may apply to the whole organization.4.

different test models will ensure that each level is sufficiently tested and validated against that the requirements and any criteria are met. From the high level business perspective through to the technology perspective. Using techniques such as the Service V model (see below) for Service Validation and Testing. SPI 1b Validate Service Packages. SLP. Service Package. ©The Art of Service . Control & Validation Best Practices 91 See the Service V Model for examples of test models used according to the different levels of testing and validation that apply.4. provides a framework to help organize the levels of Configuration Items that are needed and the associated testing and validation activities within and across stages of the change. 6. Level 1 Define Customer/Business Requirements 1a Define Service Requirements 2a SLR Draft SLA Service Acceptance Criteria/Plan Service Acceptance Test 2b Service Operational Readiness Test 3b Service Release Package Test 4b Service Review Criteria/Plan Contract.4 Testing Approaches and Techniques Any test strategy needs to provide for a range of perspectives in order to determine whether the service will deliver as required.15: The Service V Model © Crown Copyright 2007 Reproduced under license from OGC The Service V Model is a concept of establishing acceptance requirements against the various levels of requirements that apply in order to justify release to the customer for trial and assessment.ITIL® V3 : Release. Offerings and contracts Level 2 Level 3 Design Service Solution Service Operational Criteria/Plan SDP including: Service Model Capacity and resource plans Service Release Test Criteria 3a Level 4 Design Service Release 4a Release Design Release plan Develop Service Solution 5a Level 5 Component and Assembly Test 5b Service Component Build and Test Levels of configuration and testing Deliveries from internal and external suppliers BL Baseline point Internal and external suppliers Figure 6.

These normally include: • Usability testing • Accessibility testing • Process and procedure testing • Knowledge transfer and capability testing • Performance. load and scalability testing • Availability.92 ITIL® V3 : Release. The right hand side focuses on the validation and test activities that are performed against the specifications defined on the left hand side. backup and recovery testing • Security testing • Logistics. It also describes that the person/group or sign off on the requirements on the left side should be involved on the right side to accept that the requirements have been met. ©The Art of Service .g. stress. Test Management Approach (TMAP) that provide more details about the specific types of testing activities that can be performed. The actual tests required at each level should reflect the approach to risk and level of confidence that is required for the service change being transitioned. It shows that service validation and acceptance test planning should start with the definition of the high level requirements. deployment and migration testing • Build. There are many frameworks and sources of guidance focused specifically on testing e. capacity and resilience testing • Volume. Control & Validation Best Practices The left hand side represents the specification of the service requirements down to the detailed Service Design. and there is direct involvement by the equivalent party on the right hand side. packaging and distribution testing • Operability and maintainability testing.

ITIL® V3 : Release. Test Management typically involves tasks such as: • Planning and scheduling test resources • Prioritizing and scheduling the sequence of testing events • Managing any non-conformance. Control & Validation Best Practices 93 6. ©The Art of Service .16: Typical activities used for the Service Validation and Testing process © Crown Copyright 2007 Reproduced under license from OGC Depending on the relative size of the service change. This is an activity best suited to be carried out by the Service Test Manager as it involves the coordination of resources based on the analysis of a range of test metrics and management of any issues or conflicts that arise.5 Service Validation and Testing activities Figure 6.4. issues and risks • Ensuring any incoming known-errors from development and their documentation items are processed. 1. or run in sequence or in parallel depending on available resources and testing interdependencies. Test Management Test Management is the overall coordination. the activities shown in the figure above may need to be increased or decreased in effort and scope for confidence in service quality. control and reporting of the validation and testing activities that are performed during Service Transition. • Monitoring progress • Monitoring overall performance and quality of the process.

Checks should also be performed to verify that the test scripts are complete and accurate. Control & Validation Best Practices 2. A baseline should also be captured of the initial test environment for any later comparison in the release process. Based while the outputs from testing will vary depending on the test model defined. errors and any non-conformance that need to be resolved • Resolved problems and errors • Sign off from test agents and stakeholders. Plan and design test This should be started early in the service lifecycle.94 ITIL® V3 : Release. Prepare Test Environment There may be configuration required in order to make use of the test environment. 5. using either manual or automated mechanisms. Any exceptions that are raised from the test activities should be documented for future re-tests. Verify Test Plan and Test Design Review the test plans and designs to verify that the test models used are appropriate for the levels of risk that exist and the level of confidence that needs to be assured for the service change. ©The Art of Service . 4. Perform tests Any tests required will be performed. and includes: • Resourcing • Ensuring capability for tests required • Acquiring any business/customer resources that are required • Schedule of milestones and deliverable dates • Entry and exit points • Financial requirements – budgeting and funding 3. they typically include: • Actual results showing proof of appropriate levels testing • Problems.

Evaluate exit criteria and report Documented results from the testing activities must be compared to the expected results. Control & Validation Best Practices 95 6. capacity. including the associated operation.ITIL® V3 : Release. other reports submitted will communicate the effectiveness of the utilized test model and process used.6 Triggers and Interfaces The key inputs into the Service Validation and Testing process are: • The Service Design Package. including both internal and external boundaries that exist. the environment should be cleaned or restored to the initial state. financial models and detailed design and interface specifications • The service package – the combination of core and supporting services that provide the utility and warranty required from the customers and business. Along with the exit criteria documentation. ©The Art of Service . Test clean up and closure If testing is complete for a given release. the decision to buy or build and any other identified improvements that can be made 6. • Release and Deployment plans • Acceptance criteria • Request For Change (RFC) The key outputs from Service Validation and Testing are reports provided to Service Evaluation. Any exceptions can be defined as: • Pass/fail • Risk to the business/service provider • Change in expected value outcome (including higher costs to deliver benefits) 7. • The service provider interfaces. risks identified and other issues encountered). These reports document: • Testing activities carried out (including the information on the test model used) • Configuration baselines for the testing environments • Results from tests • Analysis of the results (identifying reasons for exception.4.

Control & Validation Best Practices Other outputs (used by all elements of the Service Lifecycle): • Updated data. These include: • Reduced error rate in later testing stages or production • Number of known errors documented in earlier testing phases • Effort and cost to configure testing environment • Reduction of repeat errors • Re-use of testing data • Percentage of errors at each lifecycle stage • Percentage of incidents and errors caused by externally supplied/controlled component Business/Customer metrics: The primary purpose for testing and validation is to provide a level of confidence in the value being created by a new or modified service. vendors and partners.96 ITIL® V3 : Release. information and knowledge in the CMS and SKMS (see Knowledge Management). The effectiveness of testing and validation in providing this confidence can be measured by: • Early validation that the service will deliver the predicted value • Reduction in the impact of incidents and errors in the live environment due to transitioned services • More effective use of the service by the end user community • Clear understanding of roles and responsibilities for the transitioned service • Reduced cost and resources required due to customer and end user involvement ©The Art of Service . 6.4. • Test incidents.7 Key Performance Indicators (KPIs) of Service Validation and Testing Service Provider metrics: Internal metrics from the service provider’s perspective are primarily concerned with the effective and efficient execution of the Service Validation and Testing process. problems and error records • Improvement ideas for Continual Service Improvement • Feedback for any third party relationships including suppliers.

evaluation will assist in providing accurate information and in managing stakeholders’ expectations.2 Scope Within Service Transition. the process considers the evaluation of new or changed services defined by Service Design. during deployment and before final transition to service operations.5. Control & Validation Best Practices 97 6. ©The Art of Service . value for money is appropriate and whether it will be accepted to be built/purchased/deployed etc. This adds value by: • Evaluating the intended effects and as much of the unintended effects as is reasonably practical for the service change being transitioned • Providing timely and accurate information to assist Change Management is deciding whether a service change will be approved or rejected 6.ITIL® V3 : Release. Continual Service Improvement can benefit by identifying areas that can be analyzed for future improvements to the process of change and evaluation. When interfaced with Change Management.5 Service Evaluation Evaluation is a generic process that considers whether the performance of something is acceptable.1 Goals and objectives The purpose of evaluation is to provide the capability for consistent and standardized methods that can determine the performance and value of a service change. 6. with any deviations between the two being managed for risk.5. The importance of evaluating the actual performance of any service change against its anticipated performance is an important source of information to service providers to help ensure that expectations set are realistic and to identify that if there are any reasons that production performance does not meet what was expected. The actual performance of a change is assessed and compared against the predicted performance.

Risk Management 5. Check. These activities are: 1. with improved capabilities in the determination of the value being delivered by a service change and whether any identified risks are unacceptable to the business.3 Benefits Change Management is the primary beneficiary of enhanced evaluation. Control & Validation Best Practices 6. When performed correctly. 6. Evaluate Actual Performance 4.5. Document Evaluation Report ©The Art of Service .98 ITIL® V3 : Release.17: Plan. Do.5.5.4 Principles of Evaluation The Evaluation process follows the Plan-Do-Check-Act (PDCA) model to ensure consistency across all evaluations. the PDCA model allows enhanced improvement and organizational learning to occur while managing risks that may affect the success of the improvement action or initiative. Figure 6. customers or existing IT services. Evaluate Predicted Performance 3.5 Evaluation Activities The key activities of Service Evaluation are shown in the figure below. Act (PDCA) Model 6. Plan the evaluation 2.

Control & Validation Best Practices 99 Figure 6.ITIL® V3 : Release.18 Typical Activities of Service Evaluation © Crown Copyright 2007 Reproduced under license from OGC ©The Art of Service .

evaluating whether any differences will cause unacceptable risks. Through evaluation the involved stakeholders can also identify any potential effects that have not already been identified. require further analysis through Change Management.100 ITIL® V3 : Release. which can. highlighting the outcomes of this comparison. it assists in understanding all of the intended and unintended effects of the service change being transitioned. an evaluation is made as to whether the actual performance is creating unacceptable risks or if there have been any unintended effects that have occurred. It these are unclear or ambiguous the evaluation should stop. end users. Evaluate Predicted Performance Using the input Service Design Package (including all relevant Acceptance criteria). The second interim report produced describes the outcome of this evaluation and provides a recommendation to Change Management whether the service change should be rolled back. An interim evaluation report will be provided to Change Management. Like before. together with a recommendation whether to reject or accept the service change in its current form. it could mean the implications are not fully understood and it will be more difficult to identify the most suitable roles to include for evaluation. The change documentation should already specify what the intended effects of the change will be and how they will be measured. ©The Art of Service . depending on the risk. suppliers and other key stakeholders. with a recommendation for further analysis to be communicated back to Change Management. 2. a report on the actual performance is generated by service operations and compared against the Service Design Package and performance models defined. including the business. 3. When all the appropriate stakeholders are involved in the evaluation. service provider. Plan the evaluation The key factor in planning the evaluation is the consideration of the perspectives required. Evaluate Actual Performance After the service has been implemented. a comparison is made with the predicted performance. If the RFC and associated change documentation is ambiguous. customers. Control & Validation Best Practices 1.

Document Evaluation Report Evaluation Report The evaluation report is provided to Change Management. e. or how recovery techniques can be used to increase the resilience of a service. with both interim and final reports being delivered.ITIL® V3 : Release. The evaluation report contains the sections: • Risk Profile • Deviations report • Qualification statement (for critical services in regulated environments.19: Example Risk Profile © Crown Copyright 2007 Reproduced under license from OGC 5.g. Figure 6. Control & Validation Best Practices 101 4. If a risk is determined to require mitigation. defence) • Validation statement • Recommendations ©The Art of Service . Risk Management The evaluations that are performed are designed to manage the risks that might be introduced as a result of the service change. plans should be made as to how the threat may be removed.

5.5.102 ITIL® V3 : Release.6 Triggers and Interfaces Triggers: • Request for Evaluation from Change Management or Service Transition Manager.7 Key Performance Indicators (KPIs) for Service Evaluation Service Provider: • Reduced failed designs that have been transitioned • Reduced cycle time to perform an evaluation Business/customer: • Reduced variance between estimated and actual performance • Reduce number of incidents against transitioned service ©The Art of Service . • Project Management request for Evaluation Inputs: • Service Design Package (and Acceptance Criteria) • Test results • Associated Service Package Outputs: Evaluation Reports for Change Management 6. Control & Validation Best Practices 6.

Control and Validation. The objectives include: • To provide a channel for users to request and receive standard services for which a pre-defined approval (from Change Management) qualification exists • To provide information to users and customers about the availability of services and the procedure for obtaining them • To source and deliver the components of requested standard services • To assist with general information. Control & Validation Best Practices 103 6. There may still be authorization from other groups such as Human Resources. however Change Management will not need to approve each execution of the standard change. creating bottlenecks and affecting the quality of assessment and coordination for normal changes.6. controlled and implemented by the IT department. the scope of Request Fulfilment should grow over time as maturity develops for Service Requests. Its primary purpose is to provide effective and efficient capabilities for fulfilling requests. including: • Users and customers asking questions. with manual activities being used where necessary to fulfil the request. 6.6 Request Fulfilment Although Request Fulfilment is found in the Service Operation volume. Without a separate process it is likely that Change Management would be flooded by a large volume of low risk standard changes. ©The Art of Service .ITIL® V3 : Release. complaints or comments 6.6. it is an appropriate inclusion within the scope of Release.2 Scope The scope of Request Fulfilment is influenced heavily by the success of Change Management and what types of pre-approved changes can be effectively managed.1 Goal and objectives Request Fulfilment is concerned with fulfilling requests from the end user community using consistent and repeatable methods. providing comments and making complaints • Users seeking changes to their access levels (utilizes Access Management) • Users wishing to have common services and applications installed for their use Many elements of Request Fulfilment may be automated through the use of self-help such as websites and user applications. As part of continual improvement. relatively common and follows a procedure or work instruction. Standard Change: A pre-approved Change that is low risk. questions and queries that are placed upon the IT department by users.

the business and customers can be supported in improved productivity of staff and/or higher quality in business services and products offered.6.3 Benefits Through effective and efficient access to standard services from the IT department. 6.104 ITIL® V3 : Release.6. this will enable the IT department (and the Service Desk in particular) with a clear definition of the appropriate types of Service Requests and repeatable actions describing how requests should be fulfilled.5 Request Fulfilment Activities Figure 6. This is achieved by reduced the bureaucracy involved in making requests and centralizing the end-to-end management of those requests.6. 6.4 Request Models As many service requests will be frequently recurring. predefined request models should be defined that document: • What activities are required to fulfil the request • The roles and responsibilities involved • Target timescales and escalation paths • Other policies or requirements that apply Similar to Change Models. Control & Validation Best Practices 6.20: Typical Activities for Request Fulfilment ©The Art of Service . Increased customer and user satisfaction can also be developed as a result of quality Request Fulfilment.

software deployment and other tools. These approval mechanisms should be built into the request models as appropriate. For others. suppliers or other parties involved in the provision of IT services. and safeguard these conditions in order for the standard change to be qualified for preapproval. 3. however the Service Desk should maintain control and visibility for all requests regardless where it is fulfilled. In some instances the fulfilment of the Service Request can be entirely automated using workflow. Some requests can be fulfilled using only automated mechanisms. 4. ERP.ITIL® V3 : Release. 2. otherwise the cost must be estimated and submitted to the user/customer for financial approval (who may in turn require their own line management/financial approval). an agreed process for charging should follow in the later steps in accordance with the organization’s financial management policies. Request Fulfilment should be interfaced with existing procurement and supplier processes. Where financial approval is involved. To ensure compatibility. some mechanism of self-help should be utilized so that users can generate Service Requests using technology that interfaces with existing Service Management tools. Financial Approval While the Service Request may already have approval from Change Management. Control & Validation Best Practices 105 1. wider business approval may be needed. Menu selection Where practical. Others may be fulfilled by the Service Desk at the first-line. or escalated where necessary to internal or external specialist groups. ‘Other’ Approval Where there may be compliance and regulatory implications for the service request. This might be via a website that offers users a menu driven interface. manual activities will be required to fulfil the request using resources from the IT department. Fulfilment The tasks required for fulfilment will vary depending on the characteristics of the service request at hand. It may be possible to agree upon fixed prices for ‘standard’ requests. where they can select common services and provide input details. ©The Art of Service . Change Management should establish that there are mechanisms in place to check for. there may be some form of financial approval that is required when there are financial implications (usually those above a defined dollar amount).

it should be referred back to the Service Desk to initiate closure. Change Management should be continually transferring standard changes to Request Fulfilment as maturity is gained in dealing with those changes.106 5. • Checks will need to be made for any licence requirements for deployed software • The Configuration Management System (CMS) will need to be updated after any deployment or change in the configuration of IT infrastructure.g. utilizing the Definitive Media Library (DML) where necessary. and Service Asset and Configuration Management are also important as: • Requests for deployment of software may involve pre-defined releases that can be automatically deployed. Closure ITIL® V3 : Release. Interfaces with Release and Deployment. or by using a self-help option to make their request. a request is made to have a faulty printer serviced). • The Service Desk acts as the primary party responsible for managing Service Requests. and maintains visibility for those requests escalated to specialist groups. ©The Art of Service . Control & Validation Best Practices When the Service Request has been fulfilled. This should include some verification that the request has been satisfied using either confirmation with the end user or other automated means.6.6 Triggers and Interfaces Most service requests will be triggered through users calling or emailing the Service Desk. The primary interfaces within Service Management are those with the Service Desk and Incident Management: • Some requests will be triggered during the use of Incident Management (e. 6.

7 Key Performance Indicators (KPIs) for Request Fulfilment Metrics will be broken down by the request type for each appropriate reporting period.21: Interfaces with Request Fulfillment 6.6. ©The Art of Service . Control & Validation Best Practices 107 Figure 6. These include: • The total number of service requests • Percentage of service requests successfully fulfilled • The size of current backlogs for service requests • Mean elapsed time for handling service requests • The average cost per service request • Levels of client satisfaction • Utilization of self-help mechanisms.ITIL® V3 : Release.

7. Other objectives include: • To support the business and customer’s control objectives and requirements • To minimize the number of quality and compliance issues caused by improper configuration of services and assets • To optimize the service assets.2 Scope Asset Management: The scope of Asset Management includes any IT or service asset used within the Service Lifecycle. Control & Validation Best Practices 6. It provides a logical model of the infrastructure. 6.108 ITIL® V3 : Release. controlling and providing information about Configuration Items (CI’s) and Service Assets throughout their life cycle. Configuration Management: Identifies. those used within Service Transition. capabilities and resources. baselines and maintains Configuration data so that changes to the IT infrastructure can be controlled.1 Goal and objectives The goal of Service Asset and Configuration Management is to support the agreed IT service provision by managing. It provides a complete inventory of assets and defines who is responsible for their control. assets and infrastructure and the relationships that exist between them.7 Service Asset and Configuration Management 6. Quality and timely information supplied about CI’s and Service Assets will enhance the effectiveness and efficiency of other Service Management processes. IT configurations.7. ©The Art of Service . and in particular. documents. recording services. It may cover non-IT assets or business products used or involved in the delivery and support of services. storing.

Asset policies may be applicable for certain asset types (e. but over time should begin to include a greater scope of the IT infrastructure. which will include how it will interface with existing Change and Release Policies. Control & Validation Best Practices 109 6.7. ©The Art of Service .4 Policies and principles of Service Asset and Configuration Management There should be clear definition of the scope and objectives for Service Asset and Configuration Management is being planned. • Incidents and problems to be resolved within the service level targets • Changes to be traceable from requirements • Enhanced ability to identify the costs for a service Benefits that may be seen to be provided primarily by the process alone includes: • Better adherence to standards • Greater compliance to legal and regulatory obligations • Optimum software licensing by ensuring correlation between licenses needed against the number purchases.7. the focus may be managing assets and services that are business critical or required as part of legal or regulatory compliance obligations.3 Benefits The majority of benefits enabled by effective Service Asset and Configuration Management can be seen in improvements of other Service Management processes.ITIL® V3 : Release. 6. managed and disposed accordingly.g. Initially. By having quality asset and configuration data available. desktops) and will define how the type of asset will be purchased. the benefits to other processes include: • Better forecasting and planning of changes • Changes and releases to be assessed planned and delivered successfully.

Configuration Models assist the IT department in: • Assessing the impact and cause of incidents and problems • Assess the impact of proposed changes • To plan and design new or changed services • To plan technology upgrades’ • To plan and deploy release packages • To optimize asset utilization. COMMON representation of the IT infrastructure. resources and costs. Control & Validation Best Practices The Configuration Model: The development of a configuration model is one of the primary objectives of Configuration Management. This should become the SINGLE. the business. The level of information recorded can vary. with more detail applied for complex or critical infrastructure and services. customers and any other involved party. and the relationships that exist. Figure 6. or those with particular compliance needs.110 ITIL® V3 : Release. used by all of IT Service Management.22: Example of a Configuration Model ©The Art of Service . The model aims to show the elements making up the infrastructure. attributes describing those elements.

being tested. Control & Validation Best Practices 111 6. It captures Configuration Items (CIs) and the relationships that exist between them. Reporting of all current and historical data about each CI throughout its lifecycle.g. live. Incident Records.6 The Configuration Management System (CMS) The CMS is a set of one or more connected information sources that provide a logical model of the IT infrastructure. withdrawn etc Attribute: CI Level: Status Accounting: Configuration Baseline: Configuration established at a specific point in time. Used as a reference point for later comparison (e.7. Specific information about CI’s.5 Terminology Terminology Configuration Item (CI): Explanations ANY component that supports an IT service (except people). Example: IT components or associated items such as Request for Changes. ©The Art of Service . After major changes.7. Example: Under Development. It’s a trade-off balancing the value that the information will provide versus the effort and cost to manage the information over time. Example: Size of RAM.ITIL® V3 : Release. bandwidth Recording and reporting of CI’s at the level that the business requires without being overly complex. hard drive. disaster recovery etc) 6. Captures both the structure and details of a configuration. Service Level Agreements. The figure below demonstrates a simplified representation of the CMS.

Control & Validation Best Practices Configuration Items CI’s Include Software & Documentation!! Relationships CI Attributes • Hard disk space • Serial number • Owner • Location • Ram Figure 6. the CMS may be formed by a combination of physical Configuration Management Databases (CMDBs). network management and other tools being used with interfaces to the CMS. with discovery.23: The Configuration Management System (CMS) Scope CI Level As shown.112 ITIL® V3 : Release. ©The Art of Service . Automation is a factor for success for larger CMS deployments. the CMS should provide access to information for other inventories rather than duplicating the data captured. HR or other reasons. telecommunication equipment). Wherever possible. including business processes where information is required for financial. audit. as well as other sources they feed and interface information together. The CMS is also used for a wide range of purposes. Components out of scope are those typically not under the control of Change Management (e.g. it is important to determine what level to which the CMDB will record information about the IT infrastructure and to decide what is not covered within the scope of the CMDB. inventory. compliance. At the data level.

Control & Validation Best Practices 113 Figure 6.24: Example of a Configuration Management System © Crown Copyright 2007 Reproduced under license from OGC ©The Art of Service .ITIL® V3 : Release.

an approach driven by continual improvement should be taken. a formal project may be appropriate to plan. manage and control the work performed and deliverables required. as well as how these objectives will be achieved.7 Configuration Management Activities Figure 6. that seeks to develop the maturity and scope of Configuration Management. including the scope and level. scope and level as early as possible.114 ITIL® V3 : Release. The scope and level needs to be carefully chosen. Depending on the scale of implementation. Control & Validation Best Practices 6. The development of a Configuration Management plan should document the overarching strategy for Configuration Management. as many implementations fail when organizations try to achieve too much.25 Configuration Management Activities © Crown Copyright 2007 Reproduced under license from OGC 1. ©The Art of Service . what activities are performed and how the process will be controlled. and to increase value provided by its use. Instead.7. too soon with Configuration Management. Management and Planning Planning for configuration management should seek to define the objectives.

auditability requirements o Link to requirements for the Configuration Management System (CMS) • Applicable policies and standards: o Change Management.ITIL® V3 : Release. Service Management and contractual requirements o Summarize accountability. changes and releases • Asset and Configuration Management Systems and Tools o Configuration Identification o Version management o Interface management o Supplier management o Release and deployment o Build Management o Establishing and maintaining configuration baselines o Maintaining the CMS o Reviewing and auditing the integrity of configurations and the CMS • CMS Housekeeping o Data migration o Backups o Archiving Data • Links to business processes/customer capabilities o Financial Management o Procurement o Project Management o Customer Service o Human Resources ©The Art of Service . Transition Policies o ISO/IEC 20000. Release. strategy. for establishing baselines. traceability. Control & Validation Best Practices 115 Example contents of a Configuration Management Plan: • Context and Purpose • Scope o Applicable Services o Environments and infrastructure o Geographical Locations • Requirements o Links to policy. 197000/1 • Organization for Configuration Management o Roles and responsibilities o Change and configuration control boards o Authorization mechanisms.

labelling and registration of CIs. Control & Validation Best Practices 2.26 – Example configuration breakdown for an IT Service ©The Art of Service . grouped and classified • The approach to identification. Identification can take place for: • Hardware and Software – include OS • Business systems – custom built • Packages – off the shelf • Physical databases • Feeds between databases and links • Configuration baselines • Software releases • Documentation Identification is also used to define the approach and techniques utilized by Configuration Management. detection. It is the activity that determine what CIs will be recorded. including the specification of: • How the classes and types of assets and CIs are to be selected. and what relationships exist with other CIs. what their attributes are. including the naming and labelling conventions to be used • Define the roles and responsibilities for the owner or custodian of CIs Figure 6.116 ITIL® V3 : Release. Identification: Identification includes the selection.

Generally. Specify the relevant attributes for each CI 5.ITIL® V3 : Release. ©The Art of Service . Selecting CIs for recording based on selection criteria The configuration model should provide information describing the relationship and composition of CIs in each structure. When choosing the appropriate level. an important part of Management and Planning is deciding the level at which recording is to occur and control will be exercised. Each individual CI should be uniquely identifiable using an identifier and version reference. Identify the owner responsible for each CI item Some identification tasks explained: 1. Select CIs for recording based on selection criteria 3. Control & Validation Best Practices 117 The identification activity includes the tasks: 1. Defining and documenting selection criteria for CIs 2. CI information is valuable if it facilitates the management of change. Naming conventions should also take into account any existing corporate or supplier structures. where top-level CIs are broken down into components. Name and Label CIs Configuration Management should work with Release and Deployment to establish policies regarding the naming conventions of CIs. As discussed earlier. Defining and documenting selection criteria for CIs 2. The version describes the exact instance of what may be considered the same CI. baselines. and describes the relationships that exist between CIs. This should be performed using a top down approach. builds and releases and assemblies. Specify when each CI is brought under the control of Configuration Management 6. some of which are document CIs. or must be recorded for legal and regulatory compliance. which in turn may be CIs themselves. The figure showing an example configuration breakdown for an IT service describes how the service is broken into relative component CIs. it involves weighing up the benefit that the information will bring against the cost and effort required to maintain accurate information for each CI. Name and Label CIs 4. the identification and resolution of incidents and problems. 3.

For releases.2.1. Specify the relevant attributes for each CI Attributes are recorded that describe specific characteristics that are valuable for the management and control of change. Measures are required to ensure that: • Identifiers printed on tags are unique • Tags are difficult to remove or can be identified if removed • Tags are attached at a fixed.1. v. identification includes a reference to the CI that it represents and a version number that will normally have two or three parts.1. v.1. As an example: • Major releases: Banking_System v.1. Control & Validation Best Practices Physical CIs should be labelled with the identifier and version so that they can be easily identified in the physical environment.1.2. Typical CI attributes include: • Unique identifier/label for CI • CI type • Name/description • Version • Location • Supply date • Licence details and expiry date • Owner/Custodian • Status • Supplier/source • Related documents • Historical data • Relationships to other CIs • Applicable SLA(s) ©The Art of Service .1.1. v. and general management of each CI. visible and accessible spot depending on the CI type Adding a barcode to the tag can also improve the efficiency and reliability of any reviews or audits that are performed over time.1.3 etc • Emergency fix releases: Banking_Systen v. v.3 etc • Minor releases: Banking_System v.118 ITIL® V3 : Release.2 etc 4. v.1.

Control & Validation Best Practices 119 3. in order to protect the integrity of the CMS. Configuration Control: Configuration Control is used to ensure that only authorized and identifiable CIs are recorded from receipt to disposal. service management tools. with interfaces into existing asset management systems. however for large and complex infrastructures. with each state being of significance to the management of the CI. including: • Registration of all new CIs and versions • Update of CI records and licence control • Updates in connection with RFCs and Change Management • Update the CMS after periodic checking of physical items Methods to ensure Configuration Control are wide ranging and include a mix of manual and automated mechanisms. Configuration Control may be primarily utilized by a Configuration Librarian. Each CI will progress through various states.ITIL® V3 : Release. Control occurs anytime the CMS is altered. Control should be passed from the project or supplier to the service provider at the scheduled time and with accurate configuration records. For small organizations. procurement systems etc. 4. Status Accounting: Status Accounting provides the capability for the reporting of all current and historical data concerned with each CI throughout its lifecycle. Typical states include: • Registered • Development or draft • Approved • Installed • Under Change/Maintenance • Withdrawn The use of status reporting will provide information on: • Configuration baselines • Latest software item versions • The person responsible for status change • CI change/incident/problem history • Changes implemented and in progress ©The Art of Service . more automated mechanisms and delegation of authority for CI upkeep will be required.

the results ensure: • Conformity between the CMs and live environment • The physical existence of CIs match those recorded in the CMs • The appropriate configuration documentation is provided before a release Configuration Audits should occur at the following times: • Before and after major changes to the IT infrastructure • Following recovery from disaster • In response to the detection of an unauthorized CI • At other determined regular intervals Any unregistered or unauthorized CIs detected during an audit should be recorded and investigated. accounting and charging.g. ©The Art of Service . the procedures required. with corrective measures restoring CIs to a baselined version where exceptions are found (e. Automated tools should be utilized for regular checks. Verification and Audit: Reviews and audits should be used to verify the existence of CIs. 6. Control & Validation Best Practices Status reports of assets for a business unit are often required by financial management for budgeting.8 Triggers and Interfaces Most updates to the CMS are triggered by: • Change requests • Incidents and Problems • Purchase orders • Service Requests • Exceptions found during reviews and audits. Specifically.7. a desktop found with unauthorized software installed). with corrective action taken to rectify the exception and to address possible issues with procedures and the behaviour of staff. checking that they are correctly recorded in the CMS and that there is conformity between the documented baselines and the actual environment to which they refer. and what implications and non-conformance can have. reports on the number of software licence holdings can be used to assess any over or under licensing in the software environment.120 ITIL® V3 : Release. Continual training and awareness campaigns should be maintained so that staff understand the importance of Configuration Management. For the service provider.

The actual roles related to Service Asset and Configuration Management includes: • Service Asset Manager • Configuration Manager • Configuration Analyst • Configuration Administrator/Librarian • CMS/Tools Administrator • Change Manager (all Changes to CIs must be authorized by Change Management) ©The Art of Service . assets and infrastructure by recording the relationships between service assets and configuration items.ITIL® V3 : Release. are those maintained with the other Service Transition processes as discussed in this volume. using the CMS to capture key financial information • Capacity Management. some important interfaces are: • Change Management. using CMS data for the assessing the impact of Changes • Financial Management.9 Roles and Responsibilities Service Asset Management: The management of service assets across the whole lifecycle including: • Full lifecycle management of IT and service assets from acquisitions to disposal • Maintenance of the asset inventory. • To ensure control procedures are complied with to protect the integrity of Configurations. Configuration Management: • To provide a logical model of the services.7. using CMS data to identify potential bottlenecks in the infrastructure • Availability Management. • To support the information needs of other ITIL® processes. Control & Validation Best Practices 121 While almost every aspect of Service Management is supported by the information maintained within the CMS. using CMS data to identify single points of failure and for component failure analysis Most important out of all the Service Lifecycle relationships however. 6.

should be very close to 100% • Percentage re-use and redistribution of under-utilized assets and resources • Improved aliment between provided maintenance and business support • Improvement in maintenance scheduling and management for CIs Other metrics focused on the effectiveness and efficiency of the process specifically include: • Improved quality and accuracy of configuration information • Decreasing number of exceptions detected during audits • Improved utilization of automation • Increased efficiency for activities performed ©The Art of Service .7.10 ITIL® V3 : Release. Control & Validation Best Practices Key Performance Indicators (KPIs) for Request Fulfilment Much of the focus for determining the value contribution of Configuration Management requires analysing improvements seen in the other Service Management processes.122 6. Potential metrics demonstrating this contribution include: • Improved speed for Incident and Problem Management for identifying and analysing the cause and potential effect • Improved ratio of used licences against paid for licences.

All of this in turn depends on the availability of accurate and timely knowledge.8. Benefits: ©The Art of Service . • Ensuring staff have a clear and common understanding of the value that their services provide to customers and the ways on which benefits are realized for the use of those services. The objectives of Knowledge Management are: • Enable the service provider to be more efficient and improve quality of service. 6. quality and relevant data and information to be available to staff. • Ensuring that. What is not considered to be within the scope of Knowledge Management is the detailed Configuration Item information that is captured and maintained by Service Asset and Configuration Management (but is interfaced with the same tools and systems). Control & Validation Best Practices 123 6.8. the understanding of the benefits and consequences of actions taken.1 Goal and Objectives To enable organizations to improve the quality of management decision making by ensuring that reliable and secure information and data is available throughout the service lifecycle. The primary purpose is to improve efficiency by reducing the need to rediscover knowledge. 6.ITIL® V3 : Release. service provider staff have adequate information on: o Who is currently using their services o The current states of consumption o Service delivery constraints o Difficulties faced by the customer in fully realizing the benefits expected from the service. This requires accessible. information and data. increase satisfaction and reduce the cost of service.2 Scope While Knowledge Management is found. it is a process used by all elements of the Service Lifecycle to improve the decision making that occurs. and the analysis of any of the surrounding issues involved. at a given time and location.8 Knowledge Management The quality of decision making within the Service Lifecycle depends on the ability and understanding of those parties involved. provided in a way that can be easily accessed and interpreted by the appropriate parties. and primarily explained within the context of Service Transition.

information and data being available. One of the more difficult components of Knowledge Management is ensuring that we do more than simply capture discrete facts about various elements of the organization and IT infrastructure. Control & Validation Best Practices With particular focus on Service Transition.124 ITIL® V3 : Release. as well as documented procedures for resolving known errors and requests. decision making at the strategic. Examples where successful transition requires effective Knowledge Management include: • User.8. Designing a system that can scale well as an organization grows. 6. to facilitate their roles within that service • Awareness of the use of the service. Having the extra time required to record relevant information and knowledge after actions are made. services and technology) • Improved feedback loops between the design architects and the support staff for services • Better real-time information and data for operational staff responding to user requests and incidents. service desk. ©The Art of Service . What this requires is an understanding of the different components and processes required to develop and mature knowledge and wisdom. Managing information and knowledge that is no longer correct or relevant for the organization. resources. including knowledge of errors signed off before deployment. Some benefits include: • Optimized service portfolios (with appropriate balance of investments.3 Challenges faced by Knowledge Management • • • • Getting staff to use the systems. Outside of Service Transition. support staff and supplier understanding of the new or changed service. knowledge is one of the important elements that needs to be transitioned as part of the service changes and associated releases being managed. tactical and operational levels all benefits from quality knowledge. and the discontinuation of previous versions • Establishment of the acceptable risk and confidence levels associated with the transition.

Most organizations capture significant amounts of data every day. Knowledge Management focuses on measures for capturing. where? Data © Crown Copyright 2007 Reproduced under license from OGC Understanding Figure 6. Knowledge Management activities seek to improve the capabilities for capturing.ITIL® V3 : Release. ©The Art of Service . This usually requires the analysis of information. Control & Validation Best Practices 125 6.4 Policies and principles of Knowledge Management Data. Wisdom (DIKW) Knowledge Management is usually seen within the context of the DIKW structure seen below. Knowledge. and is applied in such a way to facilitate decision making. ideas. insights and judgments from individuals and from their peers’. Knowledge: Knowledge is composed of the experiences. Information: Information comes from providing context to data. what.27: Moving from data to wisdom Data: Data is a set of discrete facts.8. analyzing. finding and reusing information so that work is not duplicated. synthesizing data and transforming it into information. when. This usually requires capturing various sources of data and applying some meaning or relevance to the set of facts. Information. Context Wisdom Why? Knowledge How? Information Who.

manages. including the Configuration Management System as well as other tools and databases. as Wisdom is a concept relating to abilities to use knowledge to make correct judgments and decisions.5 The Service Knowledge Management System (SKMS) SKMS (Service Knowledge Management System) CMS (Configuration Management System) Decisions CMDB (Configuration Management Database) KEDB (Known Error Database) Figure 6.8. ©The Art of Service . We can use tools and databases to capture Data. The use of wisdom ultimately enables an organization to direct its strategy and growth in competitive market spaces. Control & Validation Best Practices Wisdom: Gives the ultimate discernment of the material and having the application and contextual awareness to provide a strong common sense judgment. Information and Knowledge. The SKMS stores. The main purpose of the SKMS is to provide quality information so that informed decisions can be made by the IT service provider.2: Components making up the Service Knowledge Management System SKMS: Service Knowledge Management System (SKMS): The SKMS describes the complete set of tools and databases that are used to manage knowledge and information. but Wisdom cannot be captured this way. updates and presents all information that an IT service provider needs to manage the full lifecycle of its services. 6.126 ITIL® V3 : Release.

the SKMS has a broader scope (as implied by the diagram) which includes anything pertaining to the needs of service management.ITIL® V3 : Release. suppliers and partners. distilling. Knowledge Management Strategy An overall strategy for Knowledge Management (for IT Service Management) should be developed that describes the approach taken by the organization.8. ©The Art of Service . Control & Validation Best Practices 127 Whereas the CMS focuses on providing information relating to the configuration of the IT infrastructure. • Designing a systematic process for organizing. including: • Experience of staff • Records of peripherals • Supplier & Partner requirements and abilities • Typical and anticipated user skill levels. 6. The strategy will address: • Governance Model • Organizational changes • Establish roles and responsibilities • Policies. Data and information management 4. • Accumulating knowledge through processes and workflow • Generating new knowledge • Accessing valuable knowledge from outside sources • Capturing external knowledge from diverse sources such as databases. processes. and how it fits within the larger concept of Knowledge Management (corporate-wide) practices already in place. This will include: • Assisting an organization to identify knowledge that will be useful. Knowledge Management strategy 2. Using the service knowledge management system 1. employees. Knowledge transfer 3. storing and presenting information in a way that improves peoples understanding in relevant areas. The strategy should identify and plan for the capture of relevant knowledge and the consequential information and data that will support it. procedures and methods for KM • Technology and other resource requirements • Performance measures. websites.6 Knowledge Management Activities The activities of Knowledge Management can be grouped in to the following elements: 1.

privacy and ownership o Defining access requirements o Considering any interfaces required to Change Management • Establishing data and information management procedures o Defining procedures for the storage and retrieval of data and information o Establishing procedures for adequate backup and recovery of data o Identifying the review and audit procedures required o Implement the mechanisms required to capture. strategic planning and decision making. dynamic learning. photographs etc) • Seminars. Knowledge transfer Throughout the service lifecycle. store and retrieve data and information from desired sources • Evaluation and improvement o Seek continuous improvement for the capture. This covers the monitoring. with representatives of each group cascading the knowledge to their working colleagues. Control & Validation Best Practices 2. many of the service management processes will be interfaced with knowledge management so that knowledge transfer can occur from one unit to another (or several). an organization will capture. manage and provide knowledge though problem solving. o Identify data and information sources that are no longer needed ©The Art of Service . Data and Information Management For efficiency purposes.128 ITIL® V3 : Release. webinars and advertising • Journals and newsletters • Awareness sessions 3. The three main elements involved are: • Establishing data and information requirements o Defines the policies and standards to follow when collecting and using data and information o Encouraging the use of common and uniform content o Establishing the requirements for security. capture. Traditional knowledge transfer relied on formal face-to-face training and documentation. and how this will be used for decision making at all levels. this is supported by a range of techniques including: • ‘Hands-on’ (tactile) learning • Knowledge visualization (visuals. use and re-use of data and information. In the modern age however. and what mechanisms can be utilized to reduce the manual workload required. diagrams. Knowledge Management must define what inputs will provide data and information. To support this. images. use and distribution of data and information.

All training and knowledge material needs to be aligned to the business perspective. ©The Art of Service . and is used in different contexts depending on the requirements for information and knowledge. Materials to be included are: • Business language and terminology • Business processes and where IT underpins them 6.7 Triggers and Interfaces As previously discussed. ‘’updated and used by its operating entities. Some of the primary interfaces however.8. Using the SKMS A service provider must first establish a SKMS that can be shared.ITIL® V3 : Release.29: Service Knowledge Management System © Crown Copyright 2007 Reproduced under license from OGC 4. Knowledge Management provides value and capabilities throughout the entire Service Lifecycle. are those with the processes of Service Operation and those within Service Transition. partners and customers. Control & Validation Best Practices 129 Figure 6.

to be fed back. Awareness and understanding of these will make future transitions easier. • Reduction in the ‘user error’ category of incidents • Enhanced customer experiences and satisfaction • Reduced time for transition and duration of early life support ©The Art of Service . Service Transition – Staff capture data of relevance through all lifecycle phases and so need to be aware of the importance of collecting it accurately and completely. consequences and workarounds will be made available to Service Operations in an easy to use fashion: • Front line incident management staff. are the point of capture for much of the everyday ITSM data.130 ITIL® V3 : Release. • Problem Management staff will be key users of collected knowledge and typically responsible for the normalization of data capture by means of developing and maintaining scripts supporting data capture within Incident Management.8 Key Performance Indicators (KPIs) of Knowledge Management When planning to implement Knowledge Management. via CSI. Service Transition staff capture data and information: • Relevant to adaptability and accessibility of the service as designed. Normal measures for the benefits of Knowledge Management include: • Successful implementation and early life operation of new and changed services with few knowledge-related errors • Increased responsiveness to changing business demands • Improved accessibility and management of standards and policies • Knowledge dissemination • Reduced time and effort required to support service • Reduced time to find information for diagnosis and fixing incidents and problems • Reduced dependency on personnel for knowledge. thought should be given as to how the benefits will be measured how to make these benefits visible to all levels of the organization. on service desk and second-line support. 6. Control & Validation Best Practices Service Operations – Errors within the service detected during transition will be recorded and analyzed and the knowledge about their existence. to Service Design • ‘Course corrections’ and other adaption's to the design required during transition.8.

ITIL® V3 : Release.30 Contribution of knowledge to effectiveness of support staff © Crown Copyright 2007 Reproduced under license from OGC ©The Art of Service . Control & Validation Best Practices 131 Measures directly relevant to the service provider are: • Usage of the knowledge bases • Contributions made to knowledge bases • Errors reported by staff or in audits • Degree of re-use for information and knowledge • Satisfaction of staff with training and knowledge transfer methods • Involvement of staff in knowledge gathering exercises (e.g. forums) Figure 6.

Control & Validation Best Practices ©The Art of Service .132 ITIL® V3 : Release.

with key responsibilities being: • To act as the primary customer contract for all service-related enquiries and issues • To maintain service quality that meeds agreed customer requirements • To identify opportunities for improvement • To represent the service for CAB meetings • To monitor and report data and statistics in order to provide visibility and insight into service quality and performance • To be accountable to the IT director for the delivery of the service. making changes and improvements where necessary • Communication process information to key stakeholders • Ensuring that staff involved have adequate training. skills and knowledge • Addressing issues with the process • Providing input into Continual Service Improvement Service Owner: The person/role that is responsible to the customer for the initiation.ITIL® V3 : Release. ©The Art of Service .1 Generic Roles Process Owner: The person/role that is responsible for ensuring that all activities defined within the process are undertaken. and is responsible for: • Defining the process strategy and approach • Ensuring the process is designed appropriately for the organization’s needs • Ensuring documentation is produced for the process • Defining appropriate policies and standards • Auditing the process to ensure compliance • Review the process. Control & Validation Best Practices 133 7 Roles and Responsibilities for RCV____ 7. transition and ongoing improvement of a particular service.

as both require Service Transition in order to deliver one or more service changes. Figure 7.2 Roles within Service Transition To ensure the quality execution of Service Transition and handover to Service Operations. Control & Validation Best Practices 7. This includes interfaces to Service Design and Project Management.134 ITIL® V3 : Release.1: Example of Service Transition organization and its interfaces © Crown Copyright 2007 Reproduced under license from OGC ©The Art of Service . there should be clear definition of the roles and responsibilities involved.

Control & Validation Best Practices 135 The roles required for managing the Release. Service Transition Manager Has responsibility for the day-to-day management and control of all the resources. Knowledge Management process owner Depending on the relative size and complexity of the organizations. 1. Service Test Manager 5. Their prime responsibilities include: • Overall planning and management of Service Transition delivery • Managing and coordination the Service Transition functions and resources • Budgeting and accounting for the team activities and resources involved • Acting as the main interface with senior management • Ensuring all policies and procedures are followed within transitions • Ensuring the transition meets the agreed requirements • Making a final recommendation regarding the decisions for deploying a release in the live environment 2. In other organizations. Control and Validation of service changes that will be described are: 1. Regardless of size. The Change Manager The main responsibilities (including those which may be delegated) include: • To maintain oversight of the Change Management process • Document and communicate agendas for CAB meetings • Choosing appropriate CAB members • Chair CAB and ECAB meetings • Authorizing or rejecting Changes based on evaluation decisions • Issuing Change Schedules to be communicated by the Service Desk • Review changes for completion of objectives • Audit the process for compliance • Review the process for potential inputs to Continual Service Improvement • Producing regular management reports ©The Art of Service . all organizations should ensure that testing is managed and performed by resources independent of other functions and processes. Release and Deployment Manager 4. Service Transition Manager 2. and requirements for service management. these roles may be combined and performed by one individual. processes and activities being utilized for Service Transition. there may be the need to formally define extra roles responsible for specific elements of the Service Transition processes. Service Asset and Configuration Management roles 6.ITIL® V3 : Release. Change Manager 3.

testing and deployment of all software and hardware required for service changes. build. issues and risks • Oversee test execution • Managing test environments • Verifies tests conducted by Release and Deployment teams • Assisting in the evaluation of service changes based on test results. design. test. The main responsibilities include: • Manage all aspects of the end-to-end release • Coordinate the resources required for release and deployment activities • Define an appropriate release policy • Assist in release and deployment planning • Oversee communication. ©The Art of Service . Service Test Manager The Service Test Manager should be an independent (not shared) role within Service Transition. preparation and training • Oversee any audits of hardware and software in the DML and Definitive Spares The Release and Deployment Manager may be supported by other defined roles including: • Packaging and build managers • Deployment managers • Early life support • Build. deployment environment managers 4. configuration. Release and Deployment Manager Has overall responsibility for the planning.136 ITIL® V3 : Release. with typical responsibilities including: • Documenting the appropriate test strategy • Designing test models • Allocating and coordinating test resources • Providing management reports on test results. Control & Validation Best Practices 3.

including interfaces with other processes such as procurement and HR. including the authorization of ownership rights for CIs o Produces Configuration reports and baselines o CMS/tools administrator: o Evaluates off the shelf CMS and interfacing tools that meet the organization’s budget. and appropriate policies and standards to be used o Determines appropriate scope and CI recording level for Configuration Management o Develops awareness campaigns to gain support o Assists in evaluating and choosing appropriate systems and tools for the Configuration Management Systems o Oversees the management of the CMS o Provides management reports Configuration administrator/librarian: o Has the operational responsibility for managing the CMS and master copies of software. or many roles defined to ensure process objectives are met.ITIL® V3 : Release. o Audits the process for compliance and to detect exceptions o Provide management reports such as audit outcomes and asset reports • • ©The Art of Service . resource and technical requirements o Manages any tools required for Service Asset and Configuration Management o Liaises with suppliers for customizations and support o Oversees and in-house developed solutions Service Asset Manager: o Has responsibility for the overall management of the service assets used by a service provider o Agrees the scope and strategy of the process o Designs the process. Control & Validation Best Practices 137 5. assets and documentation CIs. The key roles normally defined are: • Configuration Manager: o Responsible for designing and implementing the Configuration Management process. there may be one. o Responsible for controlling updates and retrievals of information in the CMS o Provides status reports on CIs o Administers the control activity. Service Asset and Configuration Management roles As the scope of implementations for the process can vary greatly.

Control & Validation Best Practices 6. Knowledge Management process owner Is responsibility for the design and maintenance of the Knowledge Management strategy. Key responsibilities are: • To interface designs with the organizational policies and processes • To identify information and knowledge sources. and providing capabilities for capturing using electronic means • Maintains the controlled knowledge items to ensure current validity and usefulness • Ensures accessibility of relevant knowledge bases • Advise the business and IT staff members on Knowledge Management concepts and procedures • To provide management reports on the use and value of Knowledge Management ©The Art of Service . process and procedures.138 ITIL® V3 : Release.

The two main ways in which transition is supported by technology are: • Enterprise-wide tools that support the broader systems and processes within which support is delivered. content management. Control & Validation Best Practices 139 8 Technology Considerations_________ Technology is a significant factor in the quality and success of Service Transition for the modern service provider.ITIL® V3 : Release. Releases and CIs While the needs for supporting technology will be influenced by a large number of factors. tools and systems that can be utilized include: • Configuration Management Systems (CMS) and tools • Version control tools • Distribution and installation tools • Discovery tools • Virtualization for simulating multiple environments • Detection and recovery tools • Backup and recovery tools • Reporting tools for Changes. providing automated support for some elements of Service Transition management: • IT Service Management systems: o Enterprise frameworks o System. an integrated suite of ITSM tools and systems should generally include the following functionality: ©The Art of Service . network and applications management tools o Service dashboards and reporting tools Specific ITSM technology and tools that cover: o SKMS o Collaborative. workflow tools o Data mining tools o Extract. load and transform data tools o Measurement and reporting systems o Test Management and testing tools o Database and test data management tools o Copying and publishing tools o Release and deployment technology o Deployment and logistics systems and tools. • With particular focus on the Service Transition processes. • Tools targeted more specifically at supporting Service Transition The following systems support the wider scope for enterprise requirements.

140 • • • • • • • • • ITIL® V3 : Release.1: Typical Activities for selecting ITSM tools and systems © Crown Copyright 2007 Reproduced under license from OGC Typical items to consider when evaluating various products for the most appropriate selection include: • Data structure • Integration • Conformity • Flexibility • Usability • Support for monitoring service levels • Conversion requirements • Support options • Scalability • Tool and Vendor credibility • Training needs • Customization • What level of adaptation is needed to implement the product successfully? ©The Art of Service . Control & Validation Best Practices Self-Help Workflow or process engine Integrated CMS Discovery/Deployment/Licensing technology Remote control Diagnostic utilities Reporting Dashboards Integration with Business Service Management What requirements? Evaluate products Identify products Short listing Selection criteria Scoring Rank the products Select product Figure 8.

©The Art of Service . captured and disseminated using one or more IT Services such as a website or email system. best practice. o Includes the management of Incident. graphics and other forms of knowledge presentation. collaborate and share knowledge.ITIL® V3 : Release. Examples of services and functions provided within the typical online community are: • Community portals • E-mail alias management • Wikis and forums groups • Focus groups • Intellectual property.1 Communities Communities are rapidly becoming the method of choice for groups of people spread across time zones and county boundaries to communicate. o Includes user and customer generated information. archiving. User and support documents etc. These needs are typically categorized into the following areas: • Document Management o Defines the set of capabilities to support the storage.1 Knowledge Management Tools Knowledge Management tools should be utilized to address an organization’s needs for processing information. The result is often a knowledge asset represented in written words. • • 8. archiving. Content Management o Defines the capability that manages the storage. and enabling and distributing knowledge. maintenance and retrieval of documents and information of a system or website. figures. classification and retirement of records. Records Management o Defines the set of capabilities to support the storage protection. Control & Validation Best Practices 141 8. work examples and template repository • Online events and net shows. classification and retirement of documents and information. Problem and CI records during Service Transition and Service Operation. Underpinning Contracts.1. protection. o Is used to manage documentation CIs such as Service Level Agreements.

1. It is also recommended that senior management actively participates in these communities to foster a culture and environment that rewards knowledge sharing and collaboration. Workflow applications provide the infrastructure and support necessary to implement a highly efficient process to accomplish these types of tasks. to acknowledge and reward the contribution of valuable knowledge assets. Typical workflow services provided within this services category include: • Workflow design • Routing objects • Event services • Gate keeping at authorization checkpoints • State transition services. can significantly improve the productivity of people by streamlining and improving the way they collaborate. Examples of knowledge services. or approves aspects of the asset.1.3 Workflow Management Workflow Management is another broad area of knowledge services that provides systematic support for managing knowledge assets through a predefined workflow or process. widely available today: • Shared calendars and tasks • Threaded discussions • Instant messaging • White-boarding • Video or teleconferencing • E-mail.142 ITIL® V3 : Release. modifies. Knowledge services. 8. Control & Validation Best Practices Successful communities often implement reward schemes for their members. ©The Art of Service . Many knowledge assets today go through a workflow process that creates. 8.2 Collaboration Collaboration is the process of sharing tacit knowledge and working together to accomplish stated goals and objectives. when properly implemented. augments. informs.

or those described in the volume of Continual Service Improvement.ITIL® V3 : Release. including those using project management methodologies. Control & Validation Best Practices 143 9 Implementing Release. Control and Validation processes________________ Typically the implementation of RCV processes comes from the identified need for more formalized practices for transitioning service changes in a controlled and efficient manger. ©The Art of Service . There can be many types of approaches used for implementing these processes. Even the practices from Service Transition themselves are useful guidance to consider when implementing these processes in an effective way.

1 The Continual Service Improvement Model The CSI Model provides the basis by which improvements to Service Transition can be made. ©The Art of Service . © Crown Copyright 2007 Reproduced under license from OGC The Continual Service Improvement Model summarizes the constant cycle for improvement. Control & Validation Best Practices 9. the questions require close interactions with all the other ITIL® processes in order to achieve Continual Service Improvement. goals and objectives Where are we now? Baseline assessments How do we keep the momentum going? Where do we want to be? Measurable targets How do we get there? Service & process improvement Did we get there Measurement & metrics Figure 9. They are questions asked in order to ensure all the required elements are identified to achieve the improvements desired. What is the vision? Business vision.144 ITIL® V3 : Release. While there may be a focus on Service Transition.1: Continual Service Improvement Model.

risks and priorities of the Service Provider. tend to create resistance in the IT staff. or the taking away of power and authority that the staff members may previously have had. Did we get there? At agreed time schedules. what is the next course of improvements that can be made? This should feed back into re-examining the vision and following the CSI model steps again. • • • • • 9. compliance. Is the focus on Service Quality. weaknesses. costs or customer satisfaction? What is the broad approach that we should take? Where are we now? Baselines taken by performing maturity assessments and by identifying what practices are currently being used (including informal and ad-hoc processes) What information can be provided by the Service Portfolio regarding strengths. security.2 Managing Cultural Change Formalizing processes and procedures will require the delivery and management of cultural changes. Those responsible or accountable for implementing Service Transition should consider the various stakeholders that will be involved or affected. Where do we want to be? Defining key goals and objectives that wish to be achieved by the formalization of Service Transition processes. Which objectives have been achieved? Which haven’t? What went well and what went wrong? How do we keep the momentum going? Now that the targets and objectives have been met. Typically the process owners and Service Transition manager will oversee the design/improvement of the processes. History has shown that initiatives surrounding Service Transition. ©The Art of Service . so that all those involved understand the reasons for the changes. team meetings and face to face discussions. customers and end users involved or affected. especially Change Management. How do we get there? Perform a gap analysis between the current practices and defined targets to begin developing plans to overcome these gaps.ITIL® V3 : Release. This is largely due to the perception of bottlenecks and bureaucracy being created. the benefits that are being created and how their role contributes or has changed as a result. including both short term and long term targets. Control & Validation Best Practices 145 Steps taken to improve Service Transition: • What is the Vision? Defining what wants to be achieved by improving Service Transition. and how best their support can be gained. This typically will involve holding awareness sessions. making sure they are fit for purpose and interface as needed with other Service Management processes. checks should be made as to how the improvement initiatives have progressed.

146 ITIL® V3 : Release. Control & Validation Best Practices ©The Art of Service .

ITIL® V3 : Release. OLAs. Guidance for SLAs.1: Some outputs to other lifecycle phases. Configuration Item information (CMDB) Service Design Service Strategy Service Transition Initial End User Support. IT infrastructure audits Continual Service Improvement Figure 10. Control & Validation Best Practices 147 10 Service Transition Summary_________ Effective Service Transition can significantly improve a Service provider’s ability to effectively handle high volumes of change and releases across its Customer base. Changes to IT infrastructure & services. Release Packages. ©The Art of Service . FSC. and UCs. process metrics for improvements. Known Errors from Development. Testing and Validation Results. Change Authorization. PIR Testing and Validation Results. Other benefits delivered include: • Increased success rate of Changes and Releases • More accurate estimations of Service Levels and Warranties • Less variation of costs against those estimated in budgets • Less variation from resources plans. CMDB Service Operation Testing and validation results.

Control & Validation Best Practices 10. affecting other business critical apps. This will assist to speed up resolution times.g. found RAM issues and referred back to Change via RFC • Quality of components ©The Art of Service . Release and Deployment Management • Builds and tests HYPE – decision here to limit video resolution to minimize bandwidth. for example. test and deploy HYPE.148 ITIL® V3 : Release. you would be able to identify if you have the skills required to support videoconferencing.ensuring that the password policies are adhered to.eg – through testing. Change Mgt will assist with decision making to determine best path of action (through CAB). • The SKMS will also help to determine the team required to build. • User and support documentation Service Asset and Configuration Management • HYPE software is registered as CI and relationships between it and the other CIs are known if…when… an incident occurs. impact on live environment • As stated previously. it is found that the RAM required slows down the pc. • Stores original authorized software in DML • Ensures that design aspects are adhered to when building (e. .1 Service Transition Scenario Knowledge Management • If your SKMS is established. • Decision made as to whether webcams are CIs themselves or an attribute of the pc/laptop it is attached to Change Management • Ensure that the introduction of this new service minimizes impact on other services. • Organizes training on using HYPE – (inservices Service Desk 1st ) Service Validation and Testing • Tests HYPE based on customer criteria – (set out in Service Design) • looks at access.

wisdom Question 4 Which activity in Service Asset & Configuration Management would help to ascertain which Configuration Items conform to that which exists in the physical environment? a) control b) verification and audit c) identification d) status accounting Question 5 After a Change has been implemented. an evaluation is performed. wisdom d) Data. knowledge. facts. ? a) Push vs Proposed b) Push vs Pull c) Requested vs Forced d) Proposed vs Forced Question 3 The 4 spheres of knowledge management are: a) Data. facts knowledge. Automated vs Manual 3. Big bang vs Phased 2.2 Review Questions Question 1 In which process would you find the Service V model? a) Release Management b) Service Transition c) Service Validation and Testing d) Knowledge Management Question 2 Release and deployment options include: 1. Control & Validation Best Practices 149 10. information. information. wisdom c) Data. What is this evaluation called? a) Forward Schedule of Changes (FSC) b) Post Implementation Review (PIR) c) Service Improvement Programme (SIP) d) Service Level Requirement (SLR) ©The Art of Service .ITIL® V3 : Release. facts. knowledge. wisdom b) Ideas.

150 ITIL® V3 : Release. Control & Validation Best Practices Question 6 Which of the following is not change type? a) Standard change b) Normal change c) Quick change d) Emergency change Question 7 Which process is responsible for maintaining the DML? a) Release and Deployment Management b) Service asset and configuration Management c) Service validation and testing d) Change Management Question 8 Which process or function is responsible for communicating the forward schedule of changes to the users? a) Change Management b) Service Desk c) Release and Deployment Management d) Service Level Management Question 9 Which of the following best describes a baseline? a) Used as a reference point for later comparison b) The starting point of any project c) The end point of any project d) A rollback procedure Question 10 The main objective of Change Management is to? a) Ensure that any changes are approved and recorded b) Ensure that standardised methods and procedures are used for controlled handling of all changes c) Ensure that any change requests are managed through the CAB d) Ensure that the CAB takes responsibility for all change implementation ©The Art of Service .

The updated business service has been ready for deployment for 2 weeks and it is very important that it is released within the next Change window in 3 weeks time as a competitor has been offering the same capability for over a month. Which of the following is the BEST type of Change to use in this scenario? a) A Standard Change b) An Emergency Change c) A Normal Change d) A Change Implementation Answers can be found on the last page of this book. Question 11 Which of the following BEST explains the disagreement between the two parties described in the scenario above? a) b) c) d) Differences in the perception of risks involved It is not clear who is responsible for implementing the Change There is a misunderstanding as to who is authorized to request the Change The customer does not understand the value of a good Change Management process Question 12 The GM and her staff first became aware of the need for the new functionality 6 months ago and have been working with IT to develop a solution. but also urgent because her business operates in a very competitive environment and a major competitor is already offering the new functionality she needs. They agree the Change is needed but insist that the change cannot be implemented within the next Change Window because there is a 30% chance of failure. From her perspective the requested Change is not only important. Control & Validation Best Practices 151 Use scenario for questions 11 & 12 The General Manager (GM) of a mobile phone supplier is in disagreement with her IT organization over the risks of implementing a change to a business service. IT managers have a different perspective. The IT managers are very surprised by her views. ©The Art of Service . and there is a danger that a significant number of customers will start to move to the competitor’s service if this is not achieved. The GM’s reaction is that very few business initiatives have a 70% chance of success and therefore the change should be implemented without further hesitation. However.ITIL® V3 : Release.

Control & Validation Best Practices ©The Art of Service .152 ITIL® V3 : Release.

ITIL® V3 : Release. Control and Validation. Figure 11.1: – Service Transition ©The Art of Service . Control & Validation Best Practices 153 11 Checklist for RCV Practices_________ The following section provides common items that should be satisfied as when implementing the practices involved for Release.

1 Service Management as a Practice • • • • • • • • • • • • • • • Service Management is clearly defined We know what our services are We have clearly defined functions and processes across the lifecycle We are able to measure the processes in a relevant matter The reason a process exists is to deliver a specific result Every process delivers its primary result to a customer or stakeholder The goals of Service Transition are defined The objectives of Service Transition are defined The purpose of Service Transition is Defined The Scope of Service transition is defined Service Transition enables us to align the new or changed service with the customer's business requirements Service Transition ensures that customers and users can use the new or changed service so that it maximizes value to the business We have measurements for alignment with the business and It plans We have measurements for Service Transition Interfaces to other Service Lifecycle stages are clearly defined ©The Art of Service .154 ITIL® V3 : Release. Control & Validation Best Practices 11.

Control & Validation Best Practices 155 11.ITIL® V3 : Release.2 Service Transition Principles • • • • • • • • • • • • • • • • Service Utilities are Defined Service Warranties are Defined We have defined and implemented a formal policy for service transition We have a policy for implementing all changes to services through service transition We have a policy for adopting a common framework and standards We have a policy for Maximizing re-use of established processes and systems We have a policy for aligning service transition plans with the business needs We have a policy for establishing and maintaining relationships with stakeholders We have a policy for establishing effective controls and discipline We have a policy for providing systems for knowledge transfer and decision support We have a policy for planning release and deployment packages We have a policy for Anticipating and managing course corrections We have a policy for Proactively managing resources across service transitions We have a policy for ensuring early involvement in the service lifecycle We have a policy for assuring the quality of the new or changed service We have a policy for proactively improving quality during service transition ©The Art of Service .

principles and basic concepts for Release and Deployment are defined • Release Unit and Identification is defined • Release design options are considered • Release and deployment models are defined • The planning of releases is managed • Preparation for build. principles and basic concepts for change management are defined • We have defined the types of change requests • We have defined standard (pre-authorized) changes • Remediation planning for changes is defined • Planning and controlling changes is an integrated activity of change management • Change and release scheduling is an integrated activity of change management • Ensuring there are remediation plans is an integrated activity of change management • Measurement and control of changes is an integrated activity of change management • Management reporting is an integrated activity of change management • Understanding the impact of change is an integrated activity of change management • Continual improvement is an integrated activity of change management • Raising and recording changes is defined • Reviewing the RFC is defined • Assessing and evaluating the Change is defined • Authorizing the Change is defined • Co-ordinating change implementation is defined • Reviewing and closing change records is defined • Change process models and workflows are defined • The Change advisory board is defined • Emergency changes are defined • Triggers.3 Service Transition Processes Change Management: • The purpose. goal and objective for the Change Management process is defined • The scope for change management is defined • The policies. goal and objective of the Release and Deployment Management process is defined • The scope for Release and deployment is defined • The policies. Control & Validation Best Practices 11. test and deployment is managed • Build and test is managed ©The Art of Service .156 ITIL® V3 : Release. Input and output and inter-process interfaces are defined • Key performance indicators and metrics are defined Release and Deployment Management: • The purpose.

Input and output and inter-process interfaces are defined Key performance indicators and metrics are defined Service Validation and Testing: • The purpose. principles and basic concepts for Service Validation and testing are defined • Inputs from Service Design are defined • Service quality and assurance is defined • Service Quality. Input and output and inter-process interfaces are defined • Key performance indicators and metrics are defined ©The Art of Service . release and change management Policies are defined • The Test strategy is defined • Test Models are defined • Validation and testing perspectives are defined • Testing approaches and techniques are examined and defined • Design considerations are defined • Different types of testing are defined • Triggers. goal and objective of the Evaluation process is defined • The scope for Evaluation is defined • The policies. Deployment and retirement are managed Deployment verification is managed Early life support is managed Review and closing of a deployment is managed Review and closing of the service transition is managed Triggers. principles and basic concepts for Evaluation are defined • Service Evaluation terms are defined • The Evaluation process and associated plans are defined • Evaluation of predicted performance is managed • Evaluation of actual performance is managed • Risk management is defined • Evaluation reporting is defined • Triggers. service transition. Risk. Input and output and inter-process interfaces are defined • Key performance indicators and metrics are defined Service Evaluation: • The purpose. goal and objective of the Service Validation and Testing process is defined • The scope for Service Validation and Testing is defined • The policies.ITIL® V3 : Release. Control & Validation Best Practices 157 • • • • • • • • • Service testing and pilots are managed Planning and preparing for deployment are managed Transfer.

Critical Success Factors and Risks ©The Art of Service . Input and output and inter-process interfaces are defined • Key performance indicators and metrics are defined Service Asset & Configuration Management: • The purpose. objectives and scope • We have defined Request Fulfilment's Value to the business • We have defined Request Fulfilment's Policies. Goal. Inputs. Control & Validation Best Practices Knowledge Management: • The purpose. principles and basic concepts for SACM are defined • The Configuration Management System is defined • Asset and Configuration Management activities are defined • Management and planning for SACM is defined • Configuration identification is defined • Configuration control is defined • Status reporting is defined • Verification and audit is defined • Triggers. Input and output and inter-process interfaces are defined • Key performance indicators and metrics are defined Request Fulfilment: • We have defined Request Fulfilment's Purpose. Outputs and interfaces • We have defined Request Fulfilment's KPIs and metrics • We have defined Request Fulfilment's Information Management reporting • We have defined Request Fulfilment's Challenges. goal and objective for the Service Asset and Configuration Management process is defined • The scope for SACM is defined • The policies.158 ITIL® V3 : Release. Principles and basic concepts • The "Menu Selection" activity is specified • The "Financial approval" activity is specified • The "Other approval" activity is specified • The "Fulfilment" activity is specified • The "Closure" activity is specified • We have defined Request Fulfilment's Triggers. principles and basic concepts for Knowledge Management are defined • Knowledge management is defined using a DIKW (data -information-knowledgewisdom) approach • A Service Knowledge Management System (SKMA) Is in place to capture and manage knowledge • The Knowledge Management Strategy is defined • Knowledge Transfer is defined • Data and information Management is integrated with Knowledge Management • Access and use of the Knowledge Management system is defined • Triggers. goal and objective of the Knowledge Management process is defined • The scope for knowledge management is defined • The policies.

ITIL® V3 : Release.4 • • • • • • • • • • • • • • • • • Service Transition common operation activities Managing Communication and commitment is a common operation activity Communications during Service Transition are defined Communication planning is managed Different methods of communication are applied Managing Organization and stakeholder Change is a common operation activity The emotional cycle of change is managed Service Transition's role in organizational change is clearly defined Organizational change is planned and implemented A variety of organizational change products is used Organizational readiness for Change is assessed Progress of organizational change is monitored Organization and people issues are dealt with in sourcing changes Organizational Change management's best practices (e. Control & Validation Best Practices 159 11.g. Kotter) are applied Stakeholder management is a common operation activity We have a stakeholder management strategy We produce stakeholder maps and analysis Changes in stakeholder commitment are captured ©The Art of Service .

160 • • • • • • • • • • • • • • • • • • • • • • • ITIL® V3 : Release.5 Organizing Service Transition The Process Owner role and the Service Owner role are defined The organizational context for transitioning a service is set Organizational models to support service transition are defined The Service Transition Manager role is defined Planning and support is organized The Service Asset Manager role is defined The Configuration Manager role is defined The Configuration Analyst role is defined The Configuration administrator / librarian role is defined The CMS / Tool administrator role is defined The configuration control board role is defined Change Authority is defined The Change Manager role is defined The Change Advisory Board role is defined Performance and risk evaluation management is defined Service Knowledge management is defined The service test manager role is defined The release and deployment roles are defined The Release packaging and Build roles are defined Deployment is defined Early life support is defined Build and test environment management is defined The Service Transition relationship with other lifecycle stages are defined ©The Art of Service . Control & Validation Best Practices 11.

mapping and graphical representations with drill down reporting tools are in place ©The Art of Service . load and transform tools are in place Measurement and reporting system tools are in place Test management and testing tools are in place Database and test data management tools are in place Copying and publishing tools are in place Release and deployment technology tools are in place Deployment and logistics systems and tools are in place Configuration Management systems and tools are in place Version control tools are in place Document-management systems are in place Requirements analysis and design tools. databases) are in place Build and Release tools (that provide listings of input and output CIs) are in place Installation and de-installation tools (that provide listings of CIs installed) are in place Compression tools (to save storage space) are in place Listing and configuration baseline tools (e. Control & Validation Best Practices 161 11. content management.6 Service Transition Technology Considerations • • • • • • • • • • • • • • • • • • • • • • • • A service Knowledge Management system is in place Collaborative. systems architecture and CASE tools are in place Database management audit tools to track physical databases are in place Distribution and installation tools are in place Comparison tools (software files. directories. Full directory listings with date–time stamps and check sums) are in place Discovery and audit tools (also called ‘inventory’ tools) are in place Detection and recovery tools (where the build is returned to a known state) are in place Visualization.ITIL® V3 : Release.g. workflow tools are in place Data mining tools are in place Extract.

162 • • • • • • • • ITIL® V3 : Release. Control & Validation Best Practices 11.7 Implementing Service Transition Justification of Service Transition is undertaken Designing Service Transition has been done Applicable standards and policies have been researched Relationships have been defined Budgets and resources have been allocated Service transition has been introduced the Cultural change aspects have been addressed Risks and value have been weighed ©The Art of Service .

process. Modeling: A technique used to predict the future behaviour of a system. something has changed. Control & Validation Best Practices 163 12 Glossary_________________________ Alert: A warning that a threshold has been reached. DML: Definitive Media Library Function: A team or group of people and the tools they use to carry out one or more processes or activities. Baselines: A benchmark used as a reference point for later comparison.ITIL® V3 : Release. CI etc MTBF: Mean Time Between Failures (Uptime) MTBSI: Mean Time Between Service Incidents MTRS: Mean Time to Restore Service (Downtime) OLA: Operational Level Agreement ©The Art of Service . Application Sizing: Determines the hardware or network capacity to support new or modified applications and the predicted workload. or a failure has occurred. Asset: Any resource or capability. Incident: An unplanned interruption to. or reduction in the quality of an IT service Known Error: A problem that has a documented Root Cause and a Workaround KEDB: Known Error Database Maintainability: A measure of how quickly and effectively a CI or IT service can be restored to normal after a failure. CMDB: Configuration Management Database CMS: Configuration Management System Configuration Item (CI): Any component that needs to be managed in order to deliver an IT Service.

Remediation: Recovery to a known state after a failed Change or Release RFC: Request for Change Service: A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and risks Service Owner: Role that is accountable for the delivery of a specific IT service SCD: Supplier and Contracts Database Service Assets: Any capability or resource of a service provider Serviceability: Measures Availability. UC: Underpinning Contract ©The Art of Service . SIP: Service Improvement Plan SKMS: Service Knowledge Management System SLA: Service Level Agreement SLM: Service Level Manager SLR: Service Level Requirements SSIP: Supplier Service Improvement Plan Status Accounting: Reporting of all current and historical data about each CI throughout its lifecycle. Control & Validation Best Practices Process: A structured set of activities designed to accomplish a specific objective.164 ITIL® V3 : Release. Trigger An indication that some action or response to an event may be needed. Reliability. Process Owner: Role responsible for ensuring that a process is fit for purpose. Maintainability of IT services/CI’s under control of external suppliers. Tuning: Used to identify areas of the IT infrastructure that could be better utilized.

VBF: Vital Business Function Warranty: A promise or guarantee that a product or service will meet its agreed requirements. ©The Art of Service . Often summarized as ‘what it does’.ITIL® V3 : Release. Control & Validation Best Practices 165 Utility: Functionality offered by a product or service to meet a particular need.

166 ITIL® V3 : Release. Control & Validation Best Practices ©The Art of Service .

1 ITIL® Certification Pathways There are many pathway options that are available to you once you have acquired your ITIL® Foundation Certification.com. Below illustrates the possible pathways that available to you.au ©The Art of Service .artofservice.1 – ITIL® Certification Pathway For more information on certification and available programs please visit our website http://www.ITIL® V3 : Release. Control & Validation Best Practices 167 13 Certification______________________ 13. considered to be equal to that of Diploma Status. Figure 13. Currently it is intended that the highest certification is the ITIL® V3 Expert.

artofservice. you are eligible to pursue the ISO/IEC 20000 certification pathways.com. Once you have acquired your ITIL® Foundation Certification.2 ITIL® V3 : Release. Control & Validation Best Practices ISO/IEC 20000 Pathways ISO/IEC 20000 Standard is becoming a basic requirement for IT Service providers and is fast becoming the most recognized symbol of quality regarding IT Service Management processes.au ©The Art of Service . ISO/IEC 20000 programs aim to assist IT professionals master and understand the standard itself and issues relating to earning actual standards compliance.168 13.2 – ISO/IEC 20000 Certification Pathway For more information on certification and available programs please visit our website www. Figure 13.

10b. 5b. 9a. Control & Validation Best Practices 169 14 Answers to Review Questions ANSWERS 1c.ITIL® V3 : Release. 8b. 6c. 7a. 12c ©The Art of Service . 11a. 3d. 2b. 3b.

Control & Validation Best Practices ©The Art of Service .170 ITIL® V3 : Release.

org www. Foundations of IT Service Management Based on ITIL V3. Control & Validation Best Practices 171 15 References ITIL. Metrics and Measurements and Benchmarking Workbook. Van Haren Publishing. The Art of Service The Art of Service (2008) How to Develop. London. Implement and Enforce ITIL v3 Best Practices. Metrics for IT Service Management. The Art of Service Websites www.theartofservice. Zaltbommel.ITIL® V3 : Release. Service Strategy (2007) OGC. Brisbane. London. The Art of Service The Art of Service (2008) IT Governance. ITSMF International (2008). Brisbane. Van Haren Publishing.theartofservice. Zaltbommel. Brisbane. TSO ITIL.artofservice. TSO ITIL. Service Design (2007) OGC. The Art of Service The Art of Service (2007) ITIL Factsheets. Continual Service Improvement (2007) OGC. London. TSO ITIL. London. ITSMF International (2006). Van Haren Publishing The Art of Service (2008) CMDB and Configuration Management Creation and Maintenance Guide. Brisbane. TSO ITIL. ISO/IEC 20000: An Introduction.com.au www. London. London. Zaltbommel. Brisbane. The Art of Service The Art of Service (2008) Risk Management Guide. Service Operation (2007) OGC. Passing your ITIL Foundation Exam (2007) OGC. TSO ITSMF International (2007). TSO ITIL.com ©The Art of Service . Service Transition (2007) OGC.

91. 102 accountability 34. 109. 39-40. 64. 29. 158 release Configuration 120 authorization 50. 141 assemblies 71. 117 assessment 50-1. 70. 158 C CAB (Change Advisory Board) 50. 11-13. 145 boundaries 89 Brisbane 171 browser 2 bundle 24-5 business 3. 108-9. 41. 108. 148. 40. 48. 150. 105 archiving 59. 120-1. 145. 63. 29. 126 approach. 163 Behavioural components 32 benefits 4. 119 assets 24-5. 149 bang 73 Banking 70. push 74 approval. 112 business processes/customer capabilities 115 Business Service Management 140 business services 104. 149. 118. 50. 9. 54. 35. 35. 29. 45. 11-12. 117. 137 automation 72. 35. 120 Business Units and Service Units 23-4 business value 29 business 154. 103. 52. 64. 87. 54-6. 59-60. 151 updated 151 business units 3. 47-9. 27. 86-7. 82-3. 120. Control & Validation Best Practices A acceptance criteria 76. 74. 110-12. 123 B balance 24. 112 availability 13. 48. 10. 35. big 73-4. 137. 136-7. 29. 56-7. 123-4. 116. 108-11. 150 ©The Art of Service . 80. 12-13. financial 57. 103. 142. 63. 63 Business/customer 102 Business/Customer metrics 96 business/customer resources 94 Business Function 165 business goals 60 business management 55 business/organization 82 business perspective. 60. 163 attributes 3. 124 bang. 55-7. 59. 24-5. 34-5. 20. 154-5 [12] Business Case 35. 97-8. 116-18. 27. 95. 137. 103. 47. 83. 130 [4] Benefits of Service Transition 41 BENEFITS of SERVICE TRANSITION 3 bottlenecks 47. 16. 148 audits 112. 50. 23. 67-8. 69. 47. 100. 57. 58. 26.172 INDEX* ITIL® V3 : Release. 94. 118 baselines 56. 24. 154 applications 22. high level 91 business processes 12-13. 115 accredited ITIL training program 7 activities integrated 156 technical 12 alignment 3. 103 Asset Management 108 Asset Management System 79.

24-6. 91. 111-12. 125. 94. 145 components 22. 7. 103. 167-8 Certification Pathway 5. 57-62. 115. 79. 61-2. 163-4 CI information 117 CI Level 111-12 CIs (configuration items) 48. 116-22. 121. 45. 1267. 63 change requests 53. 111-13. 95. 135 Change Models 50. 163 CMS data 121 Collaboration 5. stakeholder 49 Change Management Activities 4. 9. 126. 106. 100-3. 84. 97-8. 111 classification 34. 124 Change Advisory Board. 52-5. 90-2. 70-1. 35. 104 change proposal 54-5. 97. 108. 128. 141-2 competition 27-8 competitors 26. 147. 56 change implementation 150-1 Change Management 47-50. 54. 76. 151. 56-7. 54-5. 32. financial information 121 certification 5. 68. 112. 112. 47. 53. 154 changes Frequency 61 choice 27-8. 163 required 79 ©The Art of Service . 95. 142 combination 7. 108. 86. 150 change schedule 52. 97. 135 compliance 59. 130. 108. 141 CI (Configuration Item) 34-5. 58. 135 CAB members 59-60 capabilities 7. 57 change window 66. 112 communication 26. see CAB change authority 54. 158. 76. 86. 22. 156 change management process document 135 change management processes 53 change management reviews 55 change management work 62 change management 156 change management Change 156 change management Management 156 change management Measurement 156 change management Raising 156 Change Manager 50. 45. 124. 137. 119-21. 48. 55. 59-60. 78. 150 [2] integrated activity of 156 sourcing changes Organizational 159 Change Management. 72. 68. 115. 26-7. 121. 148. 40. 139. 80. 48-9. 105. 137. 91. 63. 119. 69. 59. 55. 151 changed services 40. 60. 95 Capacity Management. 51. 96. 111-12. 161 CI s 74. 30. 148-9. 69. 84. 126. 58. 163 CMS (CONFIGURATION MANAGEMENT SYSTEM) 4. 139. 73-4. 148-9. 9. 109-10. 106 CMDB (Configuration Management Databases) 43. 159 communities 5. 135 complexity 28. 105-6. 54 change management planning 62 change management Policies 157 Change Management Policies 3. 56. 92. 78. 145. Control & Validation Best Practices 173 CAB meeting 60 CAB meetings 133. 167-8 challenges 4-5. 124. 52. 163-4 [3] capacity 16. 117. 84. 75. 111-12. 48. 64. 49.ITIL® V3 : Release. 63. 72. 141 Clear understanding of roles and responsibilities 96 closure 66. 28. 117-19. 151 complaints 103 completion 58. 50. 160-1. 108. 141. 33. 88 Change Management process 45. 87. 112. 137. 141.

121-9. 149. 113-14. 45. 153 [2] Control & Validation Best Practices 4-37. 47. see CIs Configuration Management 4. 115. 106. 158. 61-2. 24-6. 171 Continual Service Improvement Model 5. 67-9. 121. 95-6. 68-9 consistency 73-4. 45. 135 Core Service Package 27-8 costs 22. 93. 24. 81-4. 5. 105. 96-7. 39-41. 152-7. 113-14 [7] CSFs (Critical Success Factors) 45 CSI (Continuous Service Improvement) 19-20. 57. 72-3. 135. see CI Configuration Item information 43. 108. 114-17. 94. 120-2 support Change Management 49 Service Asset & 39 Configuration Management Activities 4. 31. 147 configuration items. 123. 37. 103. 68-9. 78-9. 158 Configuration Control 119 configuration data 74. 143-4. 96 level of 88. 30-1. 130 Customer Assets 25 Customer/Business Requirements 91 customer contract. 38. 137 Configuration Management System 4. 60. 81. 35. 18-19. 103. 55 cook 22 coordinate business unit s capabilities 24 end-to-end release 136 coordination 58. 144 continuity 16. 130 control 3. primary 133 customer enquiries Transparency 23 customer experience 22 customer groups 29 customer metrics 85 customer requirements 133 Customer Service 115 customers 9-11. 70-1. 42. 27 Continuous Service Improvement (CSI) 19-20. 10. 48. 89-111. see CMDB configuration management roles 135. 132-41. 68. 7. 112. 133. 129 continual improvement. 24-5. 154 [14] external 35 increased 82. 28-9. Control & Validation Best Practices service/release 82 concepts 3. 53. 21. 108. 127. 105. 137. 84-5. 86. 98 business goals Improving 69 constraints 26. 20-8. 93. 39-47. 84. 117-19. 114. 115. 108-9 configuration information 54 configuration information Decreasing number 122 Configuration Item. 45-7. 126. 73. 85. 21-3. 103-4. 91. 64. 26. change management 156 Continual Service Improvement 19-20. 96 configuration 91. 31. 166-71 [7] Control & Validation Best Practices Release 80 control. 90. 147. 43. 89-90 contexts 24. 114. 74. 55. 92. 163 CONFIGURATION MANAGEMENT SYSTEM. 89. 86-7. 104 ©The Art of Service . 125. 158 Configuration Management Database 126. 117 conjunction 49. 106. 99. 96. 32. 151. 126-7 basic 156-8 confidence 86-7. 40. 86-7. 16-17. 111-13. appropriate level of 50. 93. 111. 83. 146-9. 91. 86-7. 163 Configuration Management Databases. 108-10. 135. 93. 94.174 ITIL® V3 : Release. 35. see CMS Configuration Management Systems and Tools 115 Configuration Models 110. 57-9. 53. 123. 117 [4] improved quality service provision 11 organization's service 69 Critical Success Factors (CSFs) 45 Crown Copyright 16. 136-7. 48. 16. 12. 109-11. 159-63. 123. 49-61.

96. 45. 31. 68-9. 106.ITIL® V3 : Release. 97. 93. Information. 123-6. 74-6. 156-7 [2] deployment activities 4. 68-9. 139. 157 evaluation reports 52. 78-85. 151 Enforce ITIL 171 Enhanced customer experiences 130 environments 33. 95. 71. 56. 126-7. 77 deployment plans 68. historical 111. 67. 124. 82-3. 136. 147 evaluation 4. 76. 150. 106. 115. 60 Emergency Change 51. see DML delivery. 52. 97-8. 60. Knowledge. customer s business operation xf0b7 56 effect. 128. 48. 87. 76. 136. 85. 54. 101 ©The Art of Service . 164 Data. 74. 94. 122. 135 errors 47. 37. 130. 63. 69. 135. 136-8. 55. 148 defined Evaluation 157 defined Key performance indicators 156-8 defined Release Unit 156 defined Service Evaluation terms 157 Definitive Media Library. 163 documentation templates 79 E Early Life Support 42. 63 design 10. 81. 100-2. 148 Design Service Release 91 diagrams 54. 75. Control & Validation Best Practices customer s 27 customer s control objectives 108 customer s management 24 175 D data. Wisdom (DIKW) 125. Knowledge. 94-5. 149. 149. 111. 117. Wisdom) 125. 124. 130 eLearning Programs 2 Emergency CAB (ECAB) 54. 67. 75. 79. 58. 158 Data and Information Management 128 databases 116. 72. 84. 65. 68-9. 120. 52. 49. 108. 100 effort 12. 22. 157 testing 31. 54. 110. 42. 118-19. 110 deploy 24. positive 26 effectiveness 47. 161 decision 32. 95. 51. 130 estimations of Service Levels 41. 139 DML (Definitive Media Library) 71. 142 live 58. 20. 149. 92. 39 Evaluation Activities 4. 76-7 deployment roles 160 deployment staff 78 description 27. 56. 54. 16. 58. 158 disagreement 151 distribute 68-9 distribution 68-9. 81-2 deployment plans acceptance criteria xf0b7 95 deployment process 72. 98 Evaluation and Service Validation 76 evaluation process 98. 87. 117. 128. business activities Service 83 department 33. 87 Deployment Management 4 deployment management process 156 deployment planning 75. 78. 80. 92. 127-8 differentiation 26-7 DIKW (Data. 103-5. 80. 60. 71-2. intended 97. 77. 64. 95-6. 130 ECAB (Emergency CAB) 54. 60. 115. 148 deploy release packages 110 deployment 29. Information. 96. 131 effects. 75-6. 60 Effect.

149 Foundation Certification 167-8 framework 9. 9. 137 Human Resources. 123. 95-7. 141. 153. 163 Increased success rate of Changes and Releases 147 Increased success rate of Changes and Releases 41. 34. 61. 54. 143 incidents 16. 50. 63. 141. 92. 112. 72. 82-3. 141. 69-70. 114. 86. 12. 70. 137-8. 151. 68. 26.176 ITIL® V3 : Release. 102. 156-8 organizational 12 goods 24 groups 45. 149 fulfilment 105 functionality 139. 87. 58. 78. 103. 56. 112. 155 Implementing Change Management 61 Implementing Release 5. 110. 117. 15 information 20. 47. 88 FSC (Forward Schedule of Changes) 43. 139. 143. 55. 16 Forced 149 Forward Schedule of Changes (FSC) 43. 34. 33-5. 67. 143. 115. 79. see HR HYPE 148 I identification 116-18. 124. 31. 82. 167-8 [4] consequential 127 controlled 71 generated 141 interface 112 level of 55. 22. 37. 147 industry 7. risks xf0b7 Oversee test 136 F factors 45. 20. 128. 130. 139 facts. 164 focus 7. 151. 80-1. 55. 68. 147. 90. 145. 148. 111-12. 151. 85. 133 GM (General Manager) 151 goals 3-5. 29-30. 24. 90. 18-19. 91-2 frequency 80. 49. 154. 121. 97. 9. 86. 51. 120. 144. 103. 163 HR (Human Resources) 13. 60. Control & Validation Best Practices interim 78. 96. 28. 121. 109. 141. 79. 144-5 focus of ITIL 12. 16. 22. 142. 123-31. 150. 81. 51. 110 processing 141 real-time 124 record 112 recording 79 reusing 125 ©The Art of Service . 147 change management 47 H hardware 10. 122. 47. 25. 156 identifier 117-18 implementation 57-8. 149. 147. 47. 143 implementing 56-7. 15-16. 136. 103. 108. 135. 117. 124. 163 fit 18-19. 137. 50. 137 execution. 100 Evaluation Reports for Change Management 102 evolutions 15 example configuration breakdown 116-17 Example of Service Transition organization 134 exceptions 94-5. 137. 43. 163 guidance 17-18. 122. 37. 165 functions 3. 12. 61. 21. discrete 124-5 failure 34. 71. 103. 77. 77. 163 G General Manager (GM) 151 Generic Roles 5.

ITIL® V3 : Release, Control & Validation Best Practices

177

timely 108 Communication process 133 information-knowledge-wisdom 158 information management 127-8 information Management 158 information management, defined Request Fulfilment's 158 information management procedures 128 information sources, connected 111 information technology 7 Information Technology Infrastructure Library 15 infrastructure 20, 22, 24, 35, 39-40, 43, 45, 57, 69, 75, 106, 108-12, 115, 121, 124, 127 [3] Infrastructure Library 15 initiator 54-5, 58 inputs 31, 42, 52, 67, 72, 102, 128, 156-8, 161 interface management 115 interfaces 3-5, 42, 45, 48-9, 52, 69, 72, 95, 102, 105-7, 109, 112, 119-21, 128-9, 134-5, 137 [1] inter-process 156-8 primary 72, 106, 129 Internet Explorer 2 Internet Service Providers (ISP) 27-8 inventories 112 involved release 78 ISO/IEC 6, 42, 115, 168, 171 ISP (Internet Service Providers) 27-8 IT Service Continuity Management (ITSCM) 65 IT Service Management (ITSM) 3, 7, 9-13, 15-16, 22, 29, 35, 45, 68, 110, 127, 139, 168, 171 ITIL official 9 refresh of 16 ITIL Factsheets 171 ITIL Foundation Exam 171 ITIL Foundation program 7 ITIL processes 31 ITIL RCV Program 39 ITIL terminology 7 ITIL V3 Framework Five volumes 15 Itilv3rcv@theartofservice.com 2 ITIL s 17 ITL 15 ITSCM (IT Service Continuity Management) 65 ITSM, see IT Service Management ITSM set of organizational capabilities 35 ITSMF 171 J judgments 125-6

K key, enrolment 2 KEY PERFORMANCE INDICATORS (KPIS) 4-5, 45, 60, 85, 96, 102, 107, 122, 130, 156-8 Key Performance Indicators, see KPIs knowledge 9-10, 17, 24, 45, 68, 83, 96, 124-31, 141, 149 knowledge assets 141-2 Knowledge Management 31, 38, 123-5, 127-30, 138, 141, 148-9, 158 defined Service 160 knowledge management activities 5, 125, 127 knowledge management process owner 135, 138 Knowledge Management Strategy 127, 158 knowledge management system 158 Knowledge Management Tools 5, 141 knowledge services 142 knowledge transfer 83, 127-8, 155 knowledgeable support staff End users 72 known errors 16, 20, 43, 70, 84, 96, 147, 163 ©The Art of Service

178

ITIL® V3 : Release, Control & Validation Best Practices

KPIs (Key Performance Indicators) 4-5, 45, 60, 85, 96, 102, 107, 122, 130 KPIS, see KEY PERFORMANCE INDICATORS L layers 12 levels 27-8, 39, 47, 56, 71, 80, 87-8, 91-2, 94, 111-12, 114, 117, 128, 130, 140 appropriate 55, 57, 60, 87, 94, 117 licences 79, 84, 122 license 16, 21, 24-6, 32, 37, 48, 53, 70-1, 73, 78, 81, 83, 89, 91, 93, 113-14 [9] lifecycle 16, 20, 29, 55, 111, 119, 121, 126, 164 lifecycle phases 20, 38, 43, 130, 147 Links 115 location 66, 74, 112, 123 London 171 M maintainability 92, 163-4 maintenance 71, 122, 138, 141 Major Concepts of ITIL 18 management 9, 24, 35, 45-6, 55-6, 58, 62, 72, 93, 96, 114, 117-19, 122, 135, 137, 141 [3] management reports 137-8 resources Providing 136 managers 31, 151 Managing information 124 meal 22 mechanisms 45, 50, 60, 77, 80, 88, 105, 128 automated 94, 105, 119 meeting, service level management review 59 members 32, 59-60, 142 metrics 60-1, 69, 96, 107, 122, 144, 156-8, 171 Mobilize 67 model 91, 98, 136, 149 logical 108, 111, 121 momentum 82, 144-5 N Name and Label CIs 117 naming conventions 80, 117 non-conformance 93-4, 120 O objectives 3-5, 12-13, 40, 45, 47, 59, 68, 86, 90, 97, 103, 108-9, 114, 123, 142, 144-5 [2] strategic 16, 47 offerings 27, 29, 91 OGC 16, 21, 24-6, 32, 37, 48, 53, 73, 81, 83, 89, 91, 93, 99, 113-14, 171 [7] OGC Release Package 70 operation 39-40, 47, 73, 84, 130 operation activity , common 159 organizational capabilities 9 specialized 9, 35 organizational change 81, 159 organizational objectives 9 organizations 7, 9-10, 12, 15-16, 22-5, 28, 31-2, 35, 47-8, 50-1, 53, 58, 67-8, 90, 123-8, 135 [9] organization s 11, 61, 79, 105, 133, 141 organization s capabilities 68 organization s objectives 13 organization s release policy 69 OS Business systems 116 outcomes 22, 25-6, 31, 100 outputs 9, 31-2, 42-3, 52, 72, 94, 96, 102, 147, 156-8 owner 112, 116-17 P packages 27, 29, 37, 42, 69, 85, 102 ©The Art of Service

ITIL® V3 : Release, Control & Validation Best Practices
parties 26, 53, 92, 105, 123, 151 partners 9, 96, 127, 129 pathways 6, 167-8 PDCA (Plan-Do-Check-Act) 98 performance 24-7, 31, 87, 90, 93, 97 actual 97-8, 100, 157 predicted 97-8, 100, 157 person 31, 35, 50, 56, 60, 64, 119 person/role 133 perspectives 3, 10, 87-8, 91, 100, 151, 157 phases 17, 20, 39, 42, 73, 75 pilots 61, 76-7, 80, 157 PIR (Post Implementation Review) 43, 147, 149 Plan-Do-Check-Act (PDCA) 98 plans 62, 65, 76-7, 80-2, 94, 98, 100-1, 110, 114, 127 configuration management 114-15 release 52 Service Management 42 Policies and principles of Service Asset and Configuration Management portfolios 29 Post Implementation Review (PIR) 43, 147, 149 practices best 15-16, 80, 141, 159, 171 informal change management 61 price 26 principles 4, 31, 87, 109, 125, 156-8 prioritization 54-5 process manager 31 process owners 31, 67, 133, 145, 164 products 9, 13, 68, 104, 140, 165 project 35, 49, 62, 88, 119, 150 Project Management 4, 52, 58, 62, 115 projected service outage (PSO) 52, 57 Proprietary knowledge of organizations 15 providers 25-7, 87 PSO (projected service outage) 52, 57

179

109

Q quality 7, 10, 22, 52, 77, 82, 87, 93, 103-4, 108, 123, 139, 155, 163, 168 perceived 22 quality service management 47, 52 R RACI 34 RACI Model 34 RAM 2, 111, 148 RCI 34 RCV processes 38, 45-6, 69, 143 recommendation 65, 100 rejection 54-5, 57 relationships 3-4, 17, 23-5, 37, 57, 62, 108, 110-12, 116-17, 121, 148 Release improved 69 single 75 words 7 Minor 70 Release & Deployment 49, 85 Release & Deployment Management 85 RELEASE & DEPLOYMENT MANAGEMENT 4 Release and Deployment 58, 68-9, 71, 75, 79, 106, 117, 156 Release and Deployment Activities 75 Release and Deployment and Evaluation 87 Release and Deployment management 58 Release and Deployment Management 57, 68, 148, 150, 156 ©The Art of Service

33-4. 164 RFCs and Change Management 119 ©The Art of Service . 88 release policy 136 release rollbacks 11 release scheduling 156 release teams 74. 133-8 [3] restaurant 22 retirement 76. 95. 100. 31. 54-5. 116-18. 104-5 resource requirements 55. 15. 120. 76 resources 24-5. 35. 64. 70. 96. 63. 45. 128 formal 84 RFC (Request For Change) 20. 76. 72 single 70 release unit 69 release window 66 release 76. 75. 95. 30-1. 58-60. 162-4 [3] resources plans 41. 72-80. 96. 120 Request For Change. 158 scope of 103 request models 4. 90. 105. 80 release policy 75 releases 3-4. 115-16. 105-7. 52. 68. 94. 118. 68-9. 11. 147 packaged 45 releases Asset 115 releases preferred structure 75 reports 34. 69-70. 156-7 [6] complex 77 configure 75 deploy quality 40 deploying 73 designed 69 implemented 69 minor 75. 42. 85. 86-8. 93. 84. 118 pre-defined 106 rollback 68 Emergency fix 118 releases 41. 160 release planning 76. 157 retrievals 128. 122. 80. 82. 75. 56-7. 73-4. 79 release tools 161 release unit structure 69 release unit 69 release units 69-70. 66. 135-7. 72. 77. 45. 57. 37. 147 complete 70 constructed 68 release packaging 80. 147 responsibilities 4-5. 100. 41. 77. 111. 78 Release Design Options and Considerations 73 Release Design Release plan 91 Release Identification 70 release identification scheme. 90. 52. 75. unique 70 Release Management 149 Release Packages 43.180 ITIL® V3 : Release. 135-6. 61. 137. 73. 141 review 54-5. 103. 70. 82-4. 156. 59-63. 141. 82. 9. 49. see RFC Request Fulfilment 4-5. 57-9. 65-6. 20. Control & Validation Best Practices Release and Deployment Management process 156 Release and Deployment Manager 135-6 Release and Deployment plans 68 Release and Deployment process 72 Release and Deployment process Supplier 75 Release and Deployment teams 136 Release Control and Validation 45 release design 4. 155-6 discovery tools aid 74 Release Policy 4. 50-2.

35. 164 Service Catalogues 20. 19. 157-8 [5] low 50. 128-9 Service Lifecycle Phases 3. 130. 130. 135. 126-7. 48. 128. 100. 68-9. 77. 121. 154 Service Management processes 49. 87-8. 148 Service Asset and Configuration Management roles 135. 141. 15. 157. 35. 42-3. 101 risks 22. 108-9. 164 service lifecycle 3. 82. 91 Service Packages and Service Level Packages 27-8 Service Pipeline 29 Service Portfolio information 20 ©The Art of Service 181 . 52. 151. 134 service organization 9. 97. 29-30. 7. 22-3. 82. 158 Service Asset & Configuration Management work 85 Service Asset and Configuration Management 70. 164 service Knowledge Management system 161 Service Knowledge Management System 5. 124. 164 SERVICE KNOWLEDGE MANAGEMENT SYSTEM. 42 service lifecycle work 3. 108. 93-4. 86-7. 149. 29 service changes 48. 87. 84. 97-8. 39. 150 Service Evaluation 4. 108-9. 151 scheduling test resources Prioritizing 93 scope 3-5. 75. 67. 92. 25. 150 Service Level Packages 3. 147 service provider interfaces 83 Service Level Agreements 111. 147-8. 55-8. 37. 45 service deployment 74 Service Design 19-20. 121. 134-6 Service Component Build and Test 91 Service Delivery 10. 147. 108. 18. 15. 91. 59. 33. 123. 41. 158. 129. 104-6. 123. 20 Service Management 5. 80. 40. 150 Service Asset & Configuration Management 49. 47. 16-20. 130. 106. 95. 86. 137. 156-8 [6] Scope of Change Management 48 scope of Release 11. 61. 69. 122. 127. 144. 94. 149. 45. 63. 75. 124. 164 Service Level Management 13. 29. 129. 27. 140 self-help 103. 12 Service Package Example 27-8 Service Packages 26-8. see SKMS Service Level 13. 145 selection criteria 117. 97. 56.ITIL® V3 : Release. 17. 102. 103 potential 60 unacceptable 100 Roles and Responsibilities for RCV 133 Row 34 Rs of Change Management 57 S SACM 158 scenario 73. 97-8. 121. 96. Control & Validation Best Practices risk evaluation management 160 Risk Management 98. 35. 49. 25. 94-5. 89. 157 Service Improvement Programme (SIP) 149. 106. 27. 171 Service Desk 34. 56. 157. 22. 68. 76. 128. 163-4 associated deployment packages Updated 42 Service Asset 4. 51. 20. 78. 115. 9. 42-3. 84. 171 service operations 68. 27-8 Service Level Requirement (SLR) 149. 103 Scope of Service transition 154 Scope of Service Transition 37 security 2. 123. 37. 116. 108-9. 164 Service Level Requirements 149. 100-1. 100-1. 42. 135. 145 Service Operation 20. 74. 48. 137. 105 sequence 93 Service 20. 112. 137 Service Asset Management 121 service assets 25. 12. 114. 97-8. 108-9. 56.

37-43. 100. 45. 29-30. 100-1. 87. 108-11. 80. 58-9. 68-9. 137. 149. 119. 52. 76. 118. 126-7. 42-3. 89. 47-8. 26. 82. 69-70. 86. 105. 16-17. 103-7 service requests 107 service requirements 91-2 Service Strategy 20. 82-3. 82. 100. 123. 123-4. 112. 126. 157 deployment management 31 Service Validation and Testing process 93. 155. 59. 96. 70-2. 163 T tags 118 target locations 73-4 TCO (Total Cost of Ownership) 72 technology 9. 48. 40. 42. 157 Service Transition. 5. 164 SLR (Service Level Requirement) 149. 139 ©The Art of Service . 96 standard 103-4 Services Package 27-8 SIP (Service Improvement Programme) 149. 97. 26. 50. 125. 28-9. 28. 78. 139-41. 70. 129. 145 Service Release 42 Service Release Package Test 91 Service Release Test Criteria 91 service requests 20. 164 skills. 130-1. 135 service transition organization 134 service transition 155 service transition interfaces 154 service units 3. 158. 86-91. 83-4. 22-30. 134-6. 92. 123-4. 64. 56-7. 145 service provider 7. 26. 88. 128. 130. 70-1. 93. 52-3. 119-20. 86-7. 126-7. 93. 59. 127. 91. 116. 145. 137 external 9. 105 storage 69. 61. 16. 129-30. 161. 72. 127. 106. 131 [4] service provider interfaces 95 service quality 47. 45. 95-6. 23-5 Service Utility 26-7 Service Validation 39. 12-13. 89. 145 STANDARD Change 50-1 standards 15. 96-7. 137. 85. 128. 31. 72-3.182 ITIL® V3 : Release. 25-6. 12. 103. 79-80. 45. 147. 67-8. 31. 49. 86-7. 129. 123-4. 15. 131 systems 37. 1234. Control & Validation Best Practices Service Portfolios 3. 151 stakeholders 9-11. 48. 148. 104. 35. 133. 54. 81. 95-6. 141 strategy 47. 120. 16. 85-6. 164 support staff 68. 127 staff 9-11. 91. customer's business requirements 154 Service Transition Manager 102. 87. 157 Service Value 3. 139. 171 Service Test Manager 93. 164 software 10. 80. 119. 105 core 27 modified 10. 159 [3] SERVICE TRANSITION 3. 135-6 Service Transition 20. 124. 124. 105. 88. 100. 68. 74. customer service 22 SKMS (SERVICE KNOWLEDGE MANAGEMENT SYSTEM) 5. 163-5 [23] common 103. 62. 115. 154-5. 123. 47. 153-4. 45-8. 102. 52. 115. 108. 90 Service Warranty 26-7 services 9-10. 21. 48. 94. 95-6. 148-9. 164 steps 50. 137 overarching 75. 139. 35. 143-5. 147. 84. 133. 114 release Communication 76 suppliers 48. 97. 168 Status Accounting 111. 58-9. 136-7 software deployment 105-6 software releases 74 definitive 71 sources 9. 35. 96.

59. 156 test environment management 160 test environments 56. 83. 52. 86. 141. 105-6. 135. 5. 87. 47. 95. 35. 52. 149 work orders 54. 147 TMAP (Test Management Approach) 92 tools 2. 78-80. 171 what s 57 wisdom 124-6. 80. 131. 111 terminology. 24-7. 96. 157 testing activities 4. 74. 148. 92. common 3. 105. 114. 69. 92-3. 103-4. 139. 95 Testing and Validation Results 43. 161 Total Cost of Ownership (TCO) 72 training 75. 10. 79-80. 127. 47. Control & Validation Best Practices Terminology 3-4. 165 websites 103. 88. 78. 119 test data management 139. 129. 88. 142-3. 82. 123. 139. 31. 142 183 ©The Art of Service . 90. 151 [3] value contribution 122 value creation 26 Van Haren Publishing 171 Vendor Contracts Information Policies 42 verification 82. 135. 31. 145 TSO 171 types 45. 139 Test Management Approach (TMAP) 92 test models 4. 23. 94-5. 57. 90-1. 75. 133. 58 Workflow Management 5. 141. 68-9. 22. 109. 80. 82-3 transition 10. 156-7 Typical Activities of Service Evaluation 99 U UCs Deployment plans 72 understanding 22. 153 Validation Processes 3. 69. 78. 105. 97. 45. 130 unintended effects 97. 100. 126. 123. 40. 74. 84-5. 21 test 37. 68. 143 validation results 20.ITIL® V3 : Release. 137. 29. 94-5 test strategy 90-1. 89-90. 87. 76. 147 value 9. 136. 161. 149 visibility 23. 103. 111. 90. 34. 129. 116. 52-3. 57. 167. change management 119 user base 73 user/customer 105 users 2. 145. 62. 103. 127. 37. 94 Test Management 93. 82-4. 68-9. 123-5. 100 unit 67. 130. 90-3. 128 updates. 163 deployment technology 161 service management 105. 35. 133 vision 67. 95 level of 27 V validation 7. 144-5 W warranty 26-8. 69. 133 Training of involved release 78 transfer 76. 86. 124. 90-2. 56. 105-6. 85. 138. 150 [1] utility 26-8. 43. 106. 61. 100. 120. 11. 115.

Sign up to vote on this title
UsefulNot useful