ITIL ST Workbooks3.amazonaws.com/Quint.Redwood/ST/Resources/ITIL ST Workbook.pdf2 The Objective Tree...

Foreword

The strategies and content in this book are a result of experience and understanding of ITIL® and

the refresh of ITIL in July 2011. 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.

This workbook’s primary purpose is to complement the accredited ITIL Service Transition Program.

This book is not a replacement for completing the course.

Each process contains a summarized overview of key knowledge. These overviews are designed to

help you to reference the knowledge gained through the course.

We hope you find this book to be a useful tool in your educational library and wish you well in your IT

Service Management career!

ITIL® is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

IT Infrastructure Library® is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved

Copyright The Art of Service | Distributed by Quint Wellington Redwood | Accredited by PeopleCert

Notice of Rights

All rights reserved. No part of this book may be reproduced or transmitted in any form by any

means, electronic, mechanical, photocopying, recording, or otherwise without the prior written

permission of the publisher.

Notice of Liability

The information in this book is distributed on an “As Is” basis without warranty. While every

precaution has been taken in the preparation of the book, neither the author nor the publisher

shall have any liability to any person or entity with respect to any loss or damage caused or

alleged to be caused directly or indirectly by the instructions contained in this book or by the

products described in it.

Trademarks

Many of the designations used by manufacturers and sellers to distinguish their products are

claimed as trademarks. Where those designations appear in this book, and the publisher was

aware of a trademark claim, the designations appear as requested by the owner of the trademark.

All other product names and services identified throughout this book are used in editorial fashion

only and for the benefit of such companies with no intention of infringement of the trademark.

No such use, or the use of any trade name, is intended to convey endorsement or other affiliation

with this book.

Contents Foreword 1

1 ITIL Certification Pathway 16

1.1 Exam Specifics 17

1.2 Exam Prerequisites 17

1.3 Exam Hints 18

2 The Objective Tree 20

2.1 Study Notes 21

3 Introduction 22

4 IT Service Management 23

4.1 Benefits of ITSM 24

4.2 Business and IT Alignments 25

5 What is ITIL? 29

6 Core Concepts and Common Terminology 32

7 Common Terminology 36

7.1 What are Services? 36

7.1.1 Business Units and Service Units 38

7.1.2 Creating Service Value 40

7.1.3 Service Packages and Service Level Packages 42

7.1.4 Service Portfolios 46

7.2 Processes and Functions 47

7.2.1 Defining Processes 47

7.2.2 Defining Functions 50

7.2.3 Connecting Processes and Functions 52

8 Introduction to Service Transition 55

8.1 Relationship to Service Lifecycle 55

8.2 Purpose and Objectives of Service Transition 56

8.3 Scope of Service Transition 57

8.4 Business Value of Service Transition 59

8.5 Context of Service Transition to Other Lifecycle Stages 60

8.5.1 Service Strategy 60

8.5.2 Service Design 61

8.5.3 Service Transition 61

8.5.4 Service Operation 62

9 Principles of Service Transition 64

9.1 Service Transition Policies 64

9.1.1 Service Transition Approach 65

9.1.2 Managing Service Changes 67

9.1.3 Transition Framework and Standards 68

9.1.4 Process and System Re-use 69

9.1.5 Business Alignment 70

9.1.6 Stakeholder Relationships 72

9.1.7 Transition Control 73

9.1.8 Knowledge Transfer and Decision Support 74

9.1.9 Releases 75

9.1.10 Project Changes 77

9.1.11 Transition Resource Management 78

9.1.12 Early Involvement of Transition Resources 78

9.1.13 Service Quality 79

9.1.14 Quality Improvement 80

9.2 Service Transition Performance 80

9.2.1 Business and IT Plan Alignment 81

9.2.2 Service Transition Performance 81

9.3 Inputs and Outputs of Service Transition 83

9.4 Elearning Module 3 & Workbook Review Questions 86

10 Processes of Service Transition 89

10.1 Transition Planning and Support 89

10.1.1 Purpose and Objectives 90

10.1.2 Scope 91

10.1.3 Value to Business 91

10.1.4 Policies, Principles, and Basic Concepts 92

10.1.5 Process Activities 92

10.1.6 Triggers, Inputs, and Outputs 93

10.1.7 Critical Success Factors and Key Performance Indicators 95

10.1.8 Challenges and Risks 96

10.1.9 Summary for Transition Planning and Support 97

10.1.10 Elearning Module 4 & Workbook Review Questions 99

10.2 Change Management 102


10.2.2 Scope 104




10.3 Process Activities 116




10.3.4 Summary for Change Management 123


10.4 Service Asset and Configuration Management 129


10.4.2 Scope 130







10.4.9 Summary for Service Asset and Configuration Management 142


10.5 Release and Deployment Management 147


10.5.2 Scope 148







10.5.9 Summary for Release and Deployment Management 159


10.6 Service Validation and Testing 164


10.6.2 Scope 166









10.7 Change Evaluation 185


10.7.2 Scope 186




10.7.6 Triggers, Inputs and Outputs 188





10.8 Knowledge Management 195


10.8.2 Scope 196








11 Managing People in Transition 207

11.1 Communication in Service Transition 208

11.1.1 Understanding People 209

11.1.2 Communication Planning 210

11.1.3 Delivery Methods 211

11.2 Managing Organizational Change 214

11.2.1 Ingredients for Change 215

11.2.2 Role of Service Transition 216

11.2.3 Planning for Organizational Change 218

11.2.4 Tools for Organizational Change 221

11.2.5 Organizational Readiness 223

11.2.6 Monitoring Progress 223

11.2.7 Challenges with Sourcing Changes 224

11.2.8 Approaches to Organizational Change 225

11.3 Stakeholder Management 229

11.3.1 Stakeholder Maps 230

11.3.2 Stakeholder Changes 231


12 Organizing for Service Transition 235

12.1 Organizational Development 236

12.1.1 Stages of Organizational Development 236

12.2 Departmentalization of Organization 240

12.2.1 Functions 241

12.2.2 Service Transition Structures 242

12.2.3 Service Transition Project Teams 244

12.3 Roles and Responsibilities 245

12.3.1 Service Owner 245

12.3.2 Process Owner 247

12.3.3 Process Manager 250

12.3.4 Service Transition Practitioner 252

12.3.5 Other Roles in Service Transition 254


13 Technology Considerations 259

13.1 The Tools of Service Transition 260

13.2 Knowledge Management 261

13.3 Collaboration 263

13.3.1 Communities 264

13.3.2 Workflow Management 265

13.4 Configuration Management System 266

14 Implementing Service Transition 268

14.1 Why Service Transition? 268

14.2 Designing Service Transition 269

14.2.1 Standards and Policies 269

14.2.2 Relationships 270

14.2.3 Funding and Resource Management 270

14.3 Impact of Introducing Service Transition 271

14.3.1 Organizational Change 272

14.3.2 Value and Risk 273

14.4 Process Integration 274

14.5 Virtual or Cloud Environments 274


15 Challenges, Critical Success Factors, and Risks 277

15.1 Challenges for Service Transition 277

15.2 Risks of Service Transition 279

15.3 Critical Success Factors in Service Transition 280

As this itiL intermediAte Workbook is designed to help you memorize and understand the official ITIL terminology,

in addition to helping you to apply this theory in a practical scenario, many instances of formal definitions and

terminology have been quoted from the official core publications.

ALL GrAy, ITALIC texts Are from the five ITIL official lifecycle books (SS, SD, ST, SO, CSI) Copyright © AXELOS

Limited 2011. Reproduced under licence from AXELOS Limited. All rights reserved. ITALIC text is referenced to

corresponding book and page number.

ALL other texts Are bAsed on AXELOS material. ITIL® is a registered trade mark of AXELOS Limited, used under

permission of AXELOS Limited. All rights reserved. IT Infrastructure Library® is a registered trade mark of AXELOS

Limited, used under permission of AXELOS Limited. All rights reserved

15.4 Other Implementation Concerns 281

16 Answers to Elearning Module & Workbook Review Questions 284

17 Glossary 286

18 References 298

19 Index 299

16 17

1 ITIL Certification Pathway

Since July 2007, a new certification path was also released. This new path encompasses all

the new Programs, ending in the possible attainment of “Expert Status.” The figure below

demonstrates the possible pathways that you could take to achieve the Expert status. The 2011

update to ITIL made no significant changes to the certification path.

To achieve Expert status, you are required to gain a minimum of 22 points by completing various

ITIL programs:

• You must complete the Foundation Program (2 points).

• You must complete 15 credits minimum from the Foundation and Intermediate modules.

(3–4 points for each module).

• Optional: qualifications from earlier versions of ITIL and complementary qualifications can

also earned additional credits (0.5–3.5 points each).

• You must complete the Managing across the Lifecycle Program (5 points).

• You must process a balanced knowledge base across the ITIL Service Lifecycle.

The numbers on each program indicate the point value.

It is yet to be finalized how the “Advanced Level” can be achieved, but it is expected to be based

on demonstration of practical experience in ITIL and IT Service Management.

1.1 Exam Specifics

The ITIL Intermediate Qualification Service Transistion exam has the following features:

• Multiple-choice exams.

• 90 minutes in length.

• 8 scenario-based questions.

• Passing mark is 70%.

• Closed book exam.

• Scaled Marking system:

Ř Most correct answers – 5 marks.

Ř Next – 3 marks.

Ř Next – 1 mark.

Ř 1 answer – 0 marks.

It is possible to do a paper- or a web-based exam. (Please check with your Accredited

Examination Center for more information on this.)

1.2 Exam Prerequisites

In order to sit the ITIL Intermediate ST Exam, you MUST have an ITIL V3/2011 Foundation

Certificate and completion of an accredited program from an ITIL-Accredited Training Provider

Chapter 1

18

Copyright The Art of Service | Distributed by Quint Wellington Redwood | Accredited by PeopleCert Copyright The Art of Service | Distributed by Quint Wellington Redwood | Accredited by PeopleCert

ITIL® SERVICE TRANSITION INTERMEDIATE LIFECYCLE WORKBOOK 19

1.3 Exam Hints

When it comes time to sit your exam, you need to do this through an accredited Authorized

Examination Center. You may have the option to do the exam as web- or paper-based. Either way,

you will be given a paper copy of the Scenarios. A good thing! (Especially if you are doing web-

based exam—do not waste time opening web versions of the scenario—use the paper ones.)

Do not be fooled by the “only 8 questions” concept. These questions are designed to test you—

not only your knowledge, but also your understanding and application of the theory. You have

90 minutes, which means roughly 11 minutes per question. Most questions come with their

own case study/scenario. You need to CAREFULLY read the scenario, then the question, then the

scenario again.

There are 4 possible answers—1 is totally WRONG! And usually it is obvious to see which that is. If

we do our math—you need 28/40 to pass. This means that if the answers are based on a 5/3/1/0

scale—you really cannot afford to get any 0 answers. You MUST get at least 2 × 5 mark answers

and the remaining averaging 3s (to get minimum of 28). So you DO need to know your stuff.

THINK Business! Remember, as “Techies,” we tend to get caught up in “our” IT world. The ITIL lifecycle and, in particular, ITSM is customer-centric… THINK THIS WAY when answering questions!

Know your content—know your order. This study guide gives you a solid revision approach to

this course—but does not cover ALL content (that’s why you do the course). Make sure you know

what makes up a policy/plan and the activities for each process, as well as who does what.

Case Study Hints:

a. Identify main process/concept being tested.

b. Identify the “issue/problem” faced within the scenario—there will always be one—your

role is to resolve that issue.

c. Once you have read the associated question, go back and identify/confirm that you are

on the right track.

Question Hints:

• The 4 possible answers will appear to be similar—you need to read the possible answers

carefully.

• Eliminate the most obvious “wrong answer.” Things to look for:

Ř Order of activities.

Ř Red herring activities.

Ř Wrong processes.

Ř Wrong description.

• From the remaining 3 responses, start to identify similarities/differences. This will help you

to eliminate the next response generally. The differences will be a hint that one of them is

incorrect—you have to decide which one.

• It is probable that the “most correct” response would have the correct order of activities/

descriptions and “just that little bit more.”

• DO NOT assume that the longest response is the most correct one.

• Expect a “phase” question. While most questions are obvious with what it is testing for (i.e.

process), you could expect to get a “big picture” question asking about Service Transition in

general—so make sure you understand your related phases.

20 21

2 The Objective Tree

This Objective Tree is a very useful tool for understanding and “tunneling” down into how ITSM

can contribute to achieving a corporate objective. This helps us to better understand how the

Service Lifecycle can contribute to achieving the Business objectives.

The aim of the Objective Tree is to walk down the tree to understand HOW each level of the

organization is assisted in achieving their objective by receiving support from the level below.

Once you get to the bottom, you then walk back up the tree, giving an example of WHY each

would be of benefit to the one above in achieving its objectives.ITIL contributes in the darker IT

aspects in providing quality IT Service Management.

2.1 Study Notes

The following study notes are broken down into the following topics:

• Introduction to Service Transition.

• Service Transition Principles.

• Service Transition Processes.

• Managing Personnel.

• Organizing for Service Transition.

• Technology Considerations.

• Implementing Service Transition.

• Challenges, Critical Success Factors and Risks.

Again, these study notes are not intended to replace an accredited ITIL Foundation or

Intermediate Qualification Program. These notes are supplementary and may not include EVERY

concept that may be tested.

Chapter 2

22 23

3 Introduction

While often seen as a stepping stone into higher-level specialist roles in IT, operational

support plays a critical part in the quality of IT services being delivered in any organization

supported by technology. Many factors influence the success being experienced in operational

support, including customer expectations, staff turnover, the relative age and complexity of

the infrastructure, quality of communication, and knowledge sharing practices, as well as the

overall quality of Service Management employed by the IT organization.

In light of this, this workbook aims to develop the reader’s knowledge and appreciation of the

practices for IT Service Management with particular focus on those capabilities required for

Service Transition (ST) in the modern IT environment. It also seeks to challenge some traditional

thinking of the role of IT support, including the measurement of its success. Rather than

focusing on a limited set of activities or Service Level Agreement (SLA) targets, organizations

are now beginning to focus on the value provided by IT support, specifically its impact on user

productivity and business-unit performance.

This comprehensive book is designed to complement the in-depth accredited ITIL Service

Transition (ST) eLearning program and, together with your practical experience gained in the

field, prepare you for the corresponding examination. Assumptions are made by the authors

that readers already have some familiarity with IT and ITIL terminology and have already

completed an ITIL Foundation program.

4 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. Standard elements for most definitions of ITSM include:

• Description of the processes required to deliver and support IT services for customers.

• The purpose primarily being to deliver and support the technology or products needed by

the business to meet key organizational objectives or goals.

• Definition of roles and responsibilities for the people involved including IT staff, customers,

and other stakeholders.

• The management of external suppliers (partners) involved in the delivery and support of the

technology and products being delivered and supported by IT.

The combination of these elements provides the capabilities required for an IT organization to

deliver and support quality IT services that meet specific business needs and requirements.

The official ITIL definition of IT Service Management is found within the Service Design volume

on page 16, describing ITSM as “the implementation and management of quality IT services

that meet the needs of the business. IT Service Management is performed by IT service providers

through an appropriate mix of people, process, and information technology.” These organizational

capabilities are influenced by the needs and requirements of customers, the culture that exists

within the service organization, and the intangible nature of the output and intermediate

products of IT services.

Chapter 3 Chapter 4

24



However, IT Service Management comprises more than just these capabilities alone. It is being

complemented by an industry of professional practice and wealth of knowledge, experience,

and skills. 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.

4.1 Benefits of ITSM

While the benefits of applying IT Service Management practices vary depending on the

organization’s needs, some typical benefits include:

• Improved quality service provision.

• Cost-justifiable service quality.

• Services that meet business, 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.

It is important to consider the range of stakeholders who can benefit from improved ITSM

practices. These stakeholders can come from:

• Senior management.

• Business unit managers.

• Customers.

• End users.

• IT staff.

• Suppliers.

4.2 Business and IT Alignments

A central concept to keep in mind when discussing the benefits of IT Service Management

is the goal of business and IT alignment. When staff members of an IT organization have an

internal focus on the technology being delivered and supported, they lose sight of the actual

purpose and benefit that their efforts deliver to the business. A way in which to communicate

how IT supports the business is using Figure 4.A (on page 27) that demonstrates business and IT

alignment.

Figure 4.A divides an organization into a number of supporting layers that work toward meeting

a number of organizational goals. These layers are communicated by the following:

Term DefinitionOrganization What are the key strategic goals and objectives for

the organization? These objectives define who we are as an organization and where we want to be in the future.

CORE Business Processes These are represented by the repeatable business activities that produce desirable results for the business. Without these results, the organizational objectives defined above would not be supported or achieved.

IT Service Organization Defines the IT Services and supporting infrastructure that is required to enable the effective and efficient execution of the business processes above. IT Services are used by the business to facilitate and enhance outcomes, including improved efficiency of operations or ensuring accuracy in the records and information being managed.

26



Term DefinitionIT Service Management Made up by the repeatable, managed, and

controlled processes used by the IT department that enable quality and efficiency in the delivery and support of the IT Services above.

IT Technical Activities The actual technical activities required as part of the execution of the ITSM processes above. ITSM is utilized to ensure that any resources and effort spent performing the technical activities are optimized according to the greatest business need or reward. As these activities are technology specific (e.g. configuring application server), they will not be a focus of this book’s content.

Each layer within this structure is utilized to support the layer(s) above. At the same time, each

layer will, in some way, influence the layer below it. For example, a business process that is

required to be executed at all times without disruptions (e.g. emergency health services) would

result in highly resilient IT services—being implemented and supported by ITSM processes—

that reduce the risk and impact of disruptions occurring.

Figure 4.A – 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.

29

28


ITIL® SERVICE TRANSITION INTERMEDIATE LIFECYCLE WORKBOOK

What business processes aide in achieving those objectives?

• Retail, marketing, buying, procurement, HR, etc.

What IT services are these business processes dependent on?

• Web site, email, automatic procurement system for buying products, Point of Sale Services.

We have ITSM in order to make sure the IT services are:

• What we need (Service Level Management, Capacity Management, etc.).

• Available when we need it (Availability Mgt, Incident Mgt, etc.).

• Provisioned cost-effectively (Financial Mgt, Service Level Mgt).

If we do not manage the IT services appropriately, we cannot rely on these services to be

available when we need them. If this occurs, we cannot adequately support our business

processes effectively and efficiently. And, therefore, we cannot meet or support our overall

organization’s objectives.

5 What is ITIL?

ITIL stands for the Information Technology Infrastructure Library. ITIL is the international de

facto management framework describing best practices for IT Service Management. The

ITIL framework evolved from the UK government’s efforts during the 1980s to document

how successful organizations approached Service Management. By the early 1990s, they

had produced a large collection of books documenting the best practices for IT Service

Management. This library was eventually entitled the IT Infrastructure Library.

ITIL has gone through several evolutions and was most recently refreshed with the release of

the 2011 edition. 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 only one of many sources for best practices, including those documented by:

• Public frameworks (ITIL, COBIT, CMMI, etc.).

• Standards (ISO 20000, BS 15000).

• Proprietary knowledge of organizations and individuals.

Generally, best practices are those formalized as a result of being successful in wide-industry

use.

Chapter 5

30



Figure 5.A – ITIL Framework

Copyright © AXELOS Limited 2011. Reproduced under licence from AXELOS Limited. All rights

reserved.

Five volumes make up the IT Infrastructure Library:

• Service Strategy.

• Service Design.

• Service Transition.

• Service Operation.

• Continual Service Improvement.

Each volume provides the guidance necessary for an integrated approach and addresses

the direct impact of capabilities on a service provider’s performance. The structure of the

ITIL framework is that of the service lifecycle. It ensures organizations are able to leverage

capabilities in one area for learning and improvements in others. The framework is used to

provide structure, stability, and strength to Service Management capabilities with durable

principles, methods, and tools. This enables service providers to protect investments and

provide the necessary basis for measurement, learning, and improvement.

In addition to the core publications, there is also ITIL Complementary Guidance. This consists

of a complementary set of publications with guidance specific to industry sectors, organization

types, operating models, and technology architectures.

32 33

6 Core Concepts and Common Terminology

Critical to our ability to participate with and apply the concepts of 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 chapter documents the important common terminology

that is used throughout the ITIL framework. Most of these concepts and terms will not be new

to you, as you will be using them within your workplaces and/or remember them from your

foundation level study. This chapter is provided to help you revise the key terms and refresh

your memory of the definitions.

A full glossary has also been included at the back of this book for terminology and acronyms

that are covered under the ITIL 2011 SS syllabus. The following introductory glossary is provided

as an introduction to the common terms found within the framework. Throughout the book,

relevant terms will be discussed in more detail in the context of their corresponding process

and/ or lifecycle stage.

Terminology ExplanationsBaselines (ITIL Continual Service Improvement) (ITIL Service Transition)

A snapshot that is used as a reference point. Many

snapshots may be taken and recorded over time but only

some will be used as baselines. For example:

• An ITSM baseline can be used as a starting point to

measure the effect of a service improvement plan.

• A performance baseline can be used to measure

changes in performance over the lifetime of an IT

service.

• A configuration baseline can be used as part of a

back- out plan to enable the IT infrastructure to be

restored to a known configuration if a change or

release fails.Business Case A decision support and planning tool that projects the likely

consequences of a business action. It provides justification

for a significant item of expenditure, includes information

about costs, benefits, options, issues, risks, and possible

problems.Capabilities The ability of an organization, person, process, application,

CI, or IT service to carry out an activity. Capabilities can

be described as the functions and processes utilized

to manage services. These are intangible assets of an

organization that cannot be purchased but must be

developed and matured over time.

The ITSM set of organizational capabilities aims to enable

the effective and efficient delivery of services to customers.External Service Provider Service provider that provides IT services to external

customers e.g. providing internet hosting solutions for

multiple customers

Chapter 6

34



Terminology ExplanationsFunctions A team or group of people and the tools they use to carry

out one or more processes or activities. Functions hold units

of an organization responsible for specific outcomes. ITIL

Functions covered include:

• Service Desk.

• Technical Management.

• Application Management.

• IT Operations Management.Internal Service Providers An internal service provider that is embedded within a

business unit e.g., one IT organization within each of the

business units. The key factor is that the IT services provide

a source of competitive advantage in the market space

where the business exists.IT Service Management A set of specialized organizational capabilities for providing

value to customers in the form of services.

Process A set of coordinated activities combining and implementing

resources and capabilities in order to produce an outcome

and provide value to customers or stakeholders.

Processes are strategic assets when they create competitive

advantage and market differentiation. They may define

roles, responsibilities, tools, management controls, policies,

standards, guidelines, activities, and work instructions if

they are needed.

Terminology ExplanationsProcess Owner The person/role responsible for ensuring that the process

is fit for the desired purpose and is accountable for the

outputs of that process.

Example: The owner for the Availability Management

ProcessProcess Manager The person/role responsible for the operational

management of a process. There may be several managers

for the one process. They report to the Process Owner.Resources A generic term that includes IT infrastructure, people,

money, or anything else that might help to deliver an IT

service. Resources are also considered to be tangible assets

of an organization.Service A means of delivering value to customers by facilitating

outcomes that customers want to achieve without the

ownership of specific costs or risks. The role of the service

provider is to manage these costs and risks appropriately,

spreading them over multiple customers if possible.Service Owner The person/role accountable for the delivery of a specific

IT Service. They are responsible for continual improvement

and management of change affecting services under their

care.

Example: The owner of the Payroll Service.Shared Service Providers An internal service provider that provides shared IT service

to more than one business unit, e.g., one IT organization

to service all businesses in an umbrella organization. IT

Services for this provider do not normally provide a source

of competitive advantage but, instead, support effective and

efficient business processes across an organization.

36 37

7 Common Terminology

7.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. 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 mindset requires, instead, an alternative outlook

to be maintained, with the focus being the service-oriented or end-to-end view of what their

organization actually provides to its customers.

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” (Service

Strategy, page 13). But what does this actually mean? The following analogy explains some of

the key concepts in a way that most (food lovers) will understand.

While most people do enjoy cooking, there are often times when they wish to enjoy quality

food without the time and effort required to prepare a meal. If they were to cook, they would

need to go to a grocery store, buy the ingredients, take these ingredients home, prepare and

cook the meal, set the table, and, of course, clean up the kitchen afterward. The alternative

is that they can go to a restaurant that delivers a service that provides them with the same

outcome (a nice meal) without the time, effort, and general fuss required if they were to cook it

themselves.

Now consider how that person would identify the quality and value of that service being

provided. It is not just the quality of the food itself that will influence their 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, music, decorations, etc.).

• The time taken to receive the meal (and was it what they asked for?).

• Did they offer a choice of beverages?

If any one of these factors does not meet the person’s expectations, then ultimately, the

perceived quality and value delivered to them as a customer is negatively impacted.

Now, relate this to an IT staff member’s role in provisioning an IT Service. If they focus only

on the application or hardware elements provided and forget or ignore the importance of

the surrounding elements that make up the end-to-end service, just like in the example of

the restaurant, the customer experience and perceived quality and value will be negatively

impacted.

But if they take a service-oriented perspective, they also ensure that:

• Communication with customers and end users is effectively maintained.

• Appropriate resolution times are maintained for end-user and customer inquiries.

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

Chapter 7

38



7.1.1 Business Units and Service Units

Figure 7.A – Business units

Copyright © AXELOS Limited 2011. Reproduced under licence from AXELOS Limited. All rights reserved.

A business unit is a bundle of assets with the purpose of creating value for customers in the

form of goods and services. The value received by the customer is paid for by the customer,

which, in turn, ensures that an adequate return on investment is obtained for the business

unit. The creation of value is dependent on the business unit’s investment of resources to

increase their capabilities in delivering services. The function of the service can vary from

simply providing resources to the customer to increasing the performance capabilities of

the customer’s business processes. The relationship between business unit and customer is

symbiotic and beneficial when value is created and returns on investment are generated.

Figure 7.B – Relationship between business units and service units


Service units are like business units: a bundle of service assets that specialize in creating value in

the form of services. 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

can be from multiple independent organizations.

This relationship enables business units to focus on the outcomes provided by services, while

the service units focus on managing the costs and risks of providing the service, possibly by

spreading these costs and risks across more than one customer or business unit.

Figure 7.C – Balancing service potential against demand for services

40




7.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-orange 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 with 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.

Figure 7.D – Creating service value


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.

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

42



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.

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

Figure 7.E – Service package example

A service package provides a detailed description of a 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.

44



Figure 7.F – Service level package example

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 and Capacity Levels.

• Continuity Measures.

• Security Levels.

So, for our ISP example, we can define a service package in the following way:

Figure 7.G – 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.

46



7.1.4 Service Portfolios

A service portfolio describes the provider’s services in terms of business value. They include 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. It is possible for a service

provider to have multiple service portfolios, depending on the customer groups that they

support.

• Includes the complete set of services managed by a service provider.

• Provides the information required to manage the entire lifecycle of all services.

Three categories of services defined in service portfolios:

• Service Pipeline (proposed or in development).

• Service Catalog (live or available for deployment).

• Retired Services (decommissioned services).

Figure 7.H – A service portfolio

Service portfolios have a much larger scope than Service Catalogs and are used to manage the

lifecycle of all services in order to maximize the value of IT Service Management to the business.

The portfolio should have the right mix of services in the pipeline and catalog to secure the

financial viability of the service provider. Just like a financial portfolio, we need to ensure the

balance between risk and benefit provided by the service portfolio.

The service portfolio uses the above information to provide informed responses to the

following strategic questions:

1. Why should a customer buy these services?

2. Why should they buy these services from us?

3. What are the pricing or chargeback models?

4. What are our strengths and weaknesses, priorities, and risk?

5. How will resources and capabilities be allocated?

7.2 Processes and Functions

7.2.1 Defining Processes

Processes can be defined as “a structured set of activities designed to accomplish a specific

objective” (Service Strategy, page 20). The function of a process is to create a defined output

from one or more definition. This is accomplished by defining the required actions, sequence

of those actions, and dependencies with each other and the defined inputs. When effective,

processes can improve the organization’s productivity. Some basic characteristics exist for each

process including:

• Measurability: The process is measured to monitor performance relative to cost, quality,

duration, and productivity.

48



• Specific results: A process’ purpose is in delivering a specific result as defined output or

• outcome of using the process, which must be clearly identifiable.

• Customers: The primary results of the process are defined and delivered to customers

and stakeholders, whether they are internal or external to the organization. Within this

context, the process and its results must meet the expectations of the customer.

• Responsiveness to specific triggers: Every process is invoked by a specific trigger. This is

the case whether the process is iterative like incident management or ongoing like event

management.

The process is managed and executed by three generic roles:

• Process Owner – ensures the process is fit for purpose. The role takes on the strategic and

tactical aspects of the process and ensures the process is aligned with the objectives of

Service Management and the customer.

• Process Manager – manages the operational aspects of the process on a daily basis.

The process manager role may be fulfilled by the same person fulfilling the process

owner. In larger organizations, a different process manager may be assigned to different

business units or customers.

• Process Practitioner – primary responsibilities include:

Ř Carrying out one or more activities of a process.

Ř Understanding how their role contributes to the overall delivery of service and

creation of value for the business.

Ř Working with other stakeholders, such as their manager, co-workers, users, and

customers, to ensure that their contributions are effective.

Ř Ensuring that inputs, outputs, and interfaces for their activities are correct.

Ř Creating or updating records to show that activities have been carried out correctly (Service

Strategy, page 332).

Figure 7.I – Generic process elements


50



The figure above describes the physical components of processes, which are tangible and,

therefore, typically get the most attention. The behavioral component, which is intangible, is

an underlying pattern so deeply embedded and recurrent that it is displayed by most members

of the organization and includes decision-making, communication, and learning processes.

Behavioral components have no independent existence apart from the work processes in which

they appear, but, at the same time, they greatly affect and impact the form, substance, and

character of activities and subsequent outputs by shaping how they are carried out. So, when

defining and designing processes, it is important to consider both the physical and behavioral

aspects that exist.

The ITIL processes covered within the Service Transition capability are:

• Transition Planning and Support

• Change Management

• Service Asset and Configuration Management

• Release and Deployment Management

• Service Validation and Testing

• Change Evaluation

• Knowledge Management

7.2.2 Defining Functions

Functions refer to the logical grouping of roles and automated measures that execute a defined

process, an activity, or combination of both. The functions within Service Operation are needed

to manage the steady state operation IT environment. 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 ITIL functions covered within the ITSM capability are:

• Service Desk

• Technical Management

• IT Operations Management

• Applications Management

Figure 7.J – The ITIL functions from Service OperationCopyright © AXELOS Limited 2011. Reproduced under licence from AXELOS Limited. All rights

reserved.

NOTE: These are logical functions and do not necessarily have to be performed by equivalent

organizational structure. This means that Technical and Application Management can be

organized in any combination and into any number of departments. The lower groupings (e.g.

Mainframe, Server) are examples of activities performed by Technical Management and are not

a suggested organizational structure.

52



7.2.3 Connecting Processes and Functions

It is often said that processes are perfect…..until people get involved. 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.

A useful tool to assist the definition of the roles and responsibilities when designing processes is

the RACI Model. 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).

A—Accountability (is made accountable for ensuring that the action takes place, even if they

might not do it themselves). This role implies ownership.

C—Consult (advice/guidance/information can be gained from this function or position prior to

the action taking place).

I—Inform (the function or position that is told about the event after it has happened).

Figure 7.K – The RACI model

”Copyright © AXELOS Limited 2011. Reproduced under licence from AXELOS Limited. All rights reserved.

A RACI Model is used to define the roles and responsibilities of the 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 defined (shows that actions are taking place), with more than

one being appropriate where there is shared responsibility.

In the example RACI model given, the service desk is both responsible and accountable for

ensuring that incidents are logged and classified, but not responsible for the subsequent

investigation, which, in this case, will be performed by other functional teams.

For the service lifecycle to be successful, an organization will need to clearly define the roles

and responsibilities required to undertake the processes and activities involved in each lifecycle

stage. These roles will need to be assigned to individuals, and an appropriate organizational

structure of teams, groups, or functions will need to be established and managed. These are

defined as follows:

55

54



• Group: A group is a set of people who share some common theme or interest, such as

performing the same activities regardless of the technology used or who they perform

the work for. These people may not even work in the same functional unit. For instance,

insurance agents from different companies can be a group. Groups are not used to define

a formal organizational structure, but can be used to logically contain people who must

follow a common process.

• Team: A team is a special type of group who share a common objective or purpose. They

may not be part of the same organization structure, but they are typically working together

and will build relationships with each other. Teams are useful in collaborating between

organizational structures or dealing with a temporary situation, such as a project or major

incident.

• Department: Formal organizational structures designed to perform several defined

activities on an ongoing basis. Departments will employ hierarchy involving managers

responsible for the execution of activities by department members, as well as the day-to-

day management of those department members.

• Division: A self-contained entity consisting of multiple departments grouped together by a

shared theme, such as geography

8 Introduction to Service Transition

8.1 Relationship to Service Lifecycle

Service Transition is the third stage of the ITIL Service Lifecycle. The other stages of the service

lifecycle are:

• Service Strategy.

• Service Design.

• Service Operation.

• Continual Service Improvement

Service Strategy is considered the hub of the service lifecycle, with design, transition, and

operation acting as spokes to the outer support ring of Continual Service Improvement;

however, Service Transition is the primary stage of the lifecycle where the service will move

through the most states of the lifecycle. Service Transition is responsible for effectively realizing

service requirements in Service Operation which were identified and Service Strategy and

developed in Service Design.

Each stage of the service lifecycle will influence and depend on the effectiveness of the stages;

thus creating an environment of checks and balances between the different aspects of IT

Service Management and ensure services provide value to the customer.

Chapter 8

56



8.2 Purpose and Objectives of Service Transition

Service Transition is about movement. Transition is commonly referred to as “passage from

one state, stage, subject, or place to another” (Merriam-Webster Online Dictionary). In

context, Service Transition is simply the passage of a service from conceptual to actual; but it

provides uniform processes to ensure this passage is performed consistently and according to

expectations and requirements.

The purpose of the Service Transition is to ensure that any new, changed, or retired service

meets the expectations of the business as documented in the Service Strategy and Service

Design stages. From this purpose, Service Transition is involved in three main activities:

• Introducing new services to the live environment.

• Introducing changes to existing services in the live environment.

• Removing (retiring) services from the live environment.

The objectives of Service Transition include:

• Planning and managing changes to services efficiently and effectively.

• Managing risks related to new, changed or retiring services.

• Successfully deploying service releases in appropriate environments.

• Setting accurate expectations for new or changed services’ performance and use.

• Ensuring that the expected business value is obtained from service changes.

• Ensure the organization has good quality knowledge about the services and service assets.

Several general activities must occur for Service Transition to be successful:

• Capacity and resources required to manage Service Transitions must be planned and

managed appropriately.

• A rigorous framework for evaluating service capabilities and risk provides must be

implemented and used before new or changed services are deployed.

• The integrity of service assets must be established and maintained.

• Efficient repeatable mechanisms must be in place for building, testing and deploying

services and releases.

• Services must be managed, operated and supported according to constraints prescribed in

the Service Design stage.

8.3 Scope of Service Transition

The scope of Service Transition encompasses several activities revolving around state changes

for the service:

• Introduction of new services.

• Modification of existing services.

• Continual updates or releases to existing services.

• Retirement of existing services.

• Transfer of services between service providers.

An individual Service Transition may involve any number of processes or service components,

but is usually centered on a single transition. Like Service Design, transitions are typically

project-based, with a defined beginning and end. A transition project may be a continuation

of the design project or managed separately. If separate, many participants on the project

team may be the same people, especially from operations, to minimize any loss of knowledge

between projects.

In some cases, the transition project may begin before the end of the Service Design stage

and assist in the final draft of the Service Design package, specifically the requirements for

Service Transition. If the two projects are combined; the acceptance (and handover) of the

58



Service Design package will likely be the major event that transforms the project from design

to transition (as defined by organizational policies). The stages of Service Transition and Service

Operation will also overlap for a period called early life support.

Within the transition period, the following considerations are addressed:

• The complexity related to a change in services or Service Management processes must be

managed.

• Encouraging the introduction of innovation in transition while minimizing any unintended

consequences of change.

• Introduction of new services in a live environment.

• Managing changes to existing services, including expansions, reduction, changes in supplier

or user population, or changes in requirements.

• Decommissioning or discontinuing services, applications and other service components.

• Transferring services to and from another service provider.

In addition to the actual services, Service Transition is also responsible for managing changes

to the underlying Service Management system, Service Management processes and specific

components used in the delivery and support of services.

Like other Service Management processes in the service lifecycle, the Service Transition

processes have responsibilities specific to Service Transition but also have responsibilities or will

influence significantly the activities of other stages in the service lifecycle. Within this context,

the processes can be divided into two categories based on the level of influence across the

lifecycle. The processes that contribute significantly to all stages of the service lifecycle are:

• Change Management.

• Service Asset and Configuration Management (SACM).

• Knowledge Management.

The Service Transition processes which have minimal contributions to other lifecycle stages are:

• Transition Planning and Support.

• Release and Deployment Management.

• Service Validation and Testing.

• Change Evaluation.

8.4 Business Value of Service Transition

The value captured through Service Transition is dependent on the adoption and

implementation of consistent and standard approaches. As a result, Service Transition can:

• Estimate accurately the cost, time, and resources required to successfully complete

transition projects.

• Accurately identify, assess and manage risks associated with each Service Transition.

• Establish ease of use and understanding of the service provider staff.

• Share and reuse Service Transition assets.

• Reduce delays from unexpected dependencies and conflicts.

• Reduce time and effort associated with managing test and pilot environments used in

Service Transition.

• Improve abilities related to setting expectations with all stakeholders.

• Increase confidence in the delivery and support of new or changed services.

• Deploy new or changed services which can be managed successfully and are cost effective.

• Improve control of service assets and configuration items.

60



8.5 Context of Service Transition to Other Lifecycle Stages

As mentioned before, Service Transition will realize the requirements from Service Strategy and

development in Service Design and deploy the appropriate solutions managed and maintained

in Service Operations. Service Transition focuses on moving a service from one state to the next,

namely:

• Design to development.

• Development to build.

• Build to test.

• Test to approve.

• Approve to deploy.

• Deploy to implement.

Service Transition principles and processes are useful for services, processes and individual

components of a service.

8.5.1 Service Strategy

Strategy is the center of the service lifecycle because it creates the rules, policies, and plans

which all other Service Management processes align. While the service lifecycle can be seen

as a sequence or cycle of activities, in reality, it is neither linear nor cyclical, but meshed. In

this context, Service Strategy has an impact on all other lifecycle stages, and how these stages

are engaged by the service provider will have a profound effect on meeting the objectives of

Service Strategy.

Service Strategy is focused on the creation of value and begins the process by understanding

the opportunities and constraints associated with organization objectives and customer

requirements. The developed strategy will provide the boundaries regarding the services and

the systems managing those services. It is within this context that the Service Design operates,

by establishing how the services and management systems will develop and operate for the

purpose of fulfilling strategic objectives and customer outcomes.

8.5.2 Service Design

Design activities focus on the development of a comprehensive solution and how it will fit into

the existing environment in order to meet the requirements of the business defined in Service

Strategy. The design approach is holistic; that is, it considers more than the service solution

itself, namely the architectures, management systems, processes and measurements used to

ensure the delivery and support of the service solution. The end result of Service Design is the

Service Design package, which includes a high-level plan for Service Transition and Service

Operation.

8.5.3 Service Transition

Service Transition is responsible for introducing new or changes services into the production

environment: this includes providing the necessary guidance for developing and improving

capabilities to support such introductions. Service Transition focuses on managing the “state”

of a service, while controlling the risks associated with its introduction to the production

environment. The lifecycle stage ensures the value identified in Service Strategy and encoded in

Service Design can be realized in Service Operation.

62



Service Strategy will provide rules, policies and standards that must be honored within the

services flowing through transition, but also for how Service Transition proceeds. Service Design

will “encode” these rules, policies and standards into the necessary service assets and plans for

transition. Most Service Transitions will be in the form of projects; and it will be necessary to

design a program and project management function which consistently meets its objectives

across all projects regardless of type, size, or purpose.

The Service Knowledge Management System is introduced in Service Transition and serves to

identify, gather, and disseminate information necessary to be effective in all service lifecycle

stages and decisions made in those stages. The design of the SKMS and its operation is a

product of the Service Design stage, but more importantly, the SKMS serves as a means of

capturing and disseminating information from Service Design to the other lifecycle stages as

well as making information from those stages to Service Design for purposes of understanding

the real world opportunities and struggles related to the design of services and management

systems.

8.5.4 Service Operation

Service Operation is responsible for managing services in a production state. This lifecycle stage

fulfills this responsibility according to how the service is designed, as well as how the underlying

management system is designed. The responsibility involves:

• Providing guidance on achieving and improving service effectiveness and efficiency.

• Providing support of services in order to deliver expected value to the customer, users, and

the service provider.

The design created within the Service Design stage has an opportunity to create the expected

value within the Service Operation stage; but to do this effectively, the current environment

must “built up” the resources and capabilities available to the service provider. This “build up” is

the focus of Service Transition and enables the Service Operation stage to fully realize the value

of the services

8.5.5 Continual Service Improvement

Continual Service Improvement provides guidance on the creation and maintenance of value

through better capabilities in Service Strategy, design, transition, and operations. Continual

Service Improvement leverages the knowledge and best practices of quality management,

Change Management, and capability improvement.

In theory, the better the organization is on creating and communicating strategy, the more

mature and competitive the organization will be. Likewise, the better the organization is at

designing, developing, deploying, and managing services, the more likely the organization

will fulfill their strategic objectives. Both these situations are made possible through continual

improvement.

Continual Service Improvement can be used to achieve incremental and large-scale

improvements to:

• Service quality.

• Operational efficiency.

• Business continuity.

• Investment return.

Continual Service Improvement provides guidance on:

• The improvement of services.

• The improvement of capabilities and resources to each of the service lifecycle stages.

64 65

9 Principles of Service Transition

While the concept of Service Transition is simple, its actual execution can be intricate and

complex. Service Transition provides more to the service lifecycle and Service Management

capabilities of the service provider than the basic move from conceptual (Service Design) to

actual (Service Operation); it provides the means for understanding the service environment

and controlling. Its three primary processes provide systems which are used extensively

throughout the entire service lifecycle, namely:

• Service Knowledge Management System.

• Configuration Management System.

• Change Management Process.

9.1 Service Transition Policies

Because Service Transition is synonymous with change, how that change is controlled is

essential of the organization’s success. As a result, the number of policies applied to Service

Transition activities may seem more than any other lifecycle stage. If true, the number of policies

demonstrates the level of awareness required when transitioning a service into an operational

state; these policies provide the necessary guidance appropriate to preparing for and making a

state change.

The most significant policies for Service Transition revolve around the following topics:

• Overall approach to Service Transition.

• Managing service changes.

• Common framework and standards for Service Transition.

• Reuse of established processes and services.

• Alignment with business needs.

• Stakeholder relationships.

• Control of transition.

• Knowledge transfer and decision support.

• Release packages.

• Changes in transition plans.

• Resource management.

• Early involvement.

• Quality assurance.

• Improvement in Service Transition.

9.1.1 Service Transition Approach

A formal policy for Service Transition serves to define what transition is for the organization,

what its objectives are and the criteria for initiating a transition. The principle reason for a formal

policy is to enhance everyone’s perspective of transition beyond a simple project: which focuses

on delivering the end product or service within constraints such as schedule, budget, and

scope. While the transition relies heavily on project management methodologies, its purpose

and objectives reach far beyond the “project.”

The development of the Service Transition allows sponsors and decision-makers the

opportunity to shape how Service Transition will impact the organization and also to

Chapter 9

66



demonstrate what their commitment is to adopting and implementing the policy. The

policy enables decision makers to ensure Service Transition work is aligned with the overall

governance framework and policies of the organization and Service Management, as well as

external standards, such as ISO/IEC 20000, IEC/ISO 38500, and COBIT.

The Service Transition policy begins shaping how the organization relates to changes and

releases. For instance, all changes to services should be delivered as releases, or a new version

of the service. The exception to this statement would be pre-defined and approved standard

changes and some emergency changes. This requires starting the understanding of what

a standard or emergency change; though not defined in this policy, the direction for the

distinctions may begin here. The policy will also address when and to what extent Change

Management or Release and Deployment Management are engaged when changes are

proposed to the organization.

Finally, the Service Transition is a means of integrating the Service Management processes

and competencies within the Service Transition stage. The policy will define the various

accountabilities and responsibilities within Service Transition. For instance, the service owner

has accountability for the service throughout its entire lifecycle, but what are the specific

responsibilities of each service owner during the transition of a new service or a change to

an existing service. The policy may define the responsibilities of the IT planner, architect, or

designer in transition as well as operational personnel assigned to a project.

The Service Transition policy must be formally agreed upon by all management, sponsors, and

decision makers involved in the development of the policy, which should include all executives

and relevant process owners.

9.1.2 Managing Service Changes

If all service changes are to be managed through the Service Transition lifecycle stage, one of

the first acts of management is to define what a ‘service change’ actually is. Some high level

definitions are pretty obvious, such as a new service, or a change to a service as documented

in the service portfolio or service catalogue. The definition of a service change may be a

combination of investment, complexity, impact, risk, or any variety of considerations.

While it may be initiated by changes to business requirements, the scope of Service Transition

would normally not include changes in the business. For instance, a change in business may

be to add a few more locations which could change the demand on certain services, but does

not change the design of the service. Therefore, would adding capacity to meet demand be

a service change which requires going through Service Transition—probably not. It would

possibly be considered a standard change.

Standard changes are pre-defined, pre-approved changes which are well-documented and low

risk. These changes typically represent routine actions required to continue the same level of

support and delivery of IT services. In most cases, there are clear criteria for defining a standard

change, as well as specific and repeatable actions that must be rigorously executed for success.

A good metaphor for standard changes would be recipes: meals which have been made so

often with the same results that any deviation would be intolerable, therefore it is essential to

follow the recipe exactly.

The policy for managing changes would introduce the concept of a single focal point

responsible for managing the changes across the organization. This focal point would minimize

the chance of conflicting changes to the environment and unsuspecting disruptions due to ill-

planned changes. The policy would identify who has the authority to ‘make’ a change or release

to the environment, not who can “request” a change: though it may define the avenues for

requesting a change.

68



The change policy will define the relationship between Change Management and Release and

Deployment Management; for instance all releases will be designed and governed by a request

for change. The policy will address the relationship between these two processes and Service

Asset and Configuration Management; namely that all changes and releases are to be recorded

in the Configuration Management system and against the impacted services assets and/or

configuration items. Audits of the Configuration Management system can be used to identify

unauthorized changes in the environment. The policy will also differentiate how external

changes (by a customer and suppliers) will be handled to minimize impact and risk on existing

services.

9.1.3 Transition Framework and Standards

The potential risk of Service Transition is evident when one considers the number of different

“projects” or changes which could be managed through the lifecycle stage. Consistency and

effectiveness within Service Transition is not obtained by accident; it is designed and begins

with the development of a common framework and standards to follow during Service

Transition. For instance, how does the organization consistently evaluate service capability to

ensure a service will provide the intended value before it is deployed.

The framework and standards policy is used to define the standard processes and systems to be

reused across multiple transition projects and to reduce the level of variation in the processes.

The standards documented within the policy may be based on industry best practices. The

policy will typically stipulate control of the framework and standards are supported by Change

Management and Service Asset and Configuration Management. Also stipulated would be the

need for regular reviews and audits of Service Management processes.

The intent of this policy is to define the underlying framework for ensuring consistent delivery

from Service Transition. It requires understanding and commitment from management. The

policy also addresses how improvements to the framework will be handled.

9.1.4 Process and System Re-use

A typical approach for improving effectiveness and efficiency in most efforts is the re-use of

established and proven processes and systems, and Service Transition is no different. However,

the benefits of reusability must be designed into the process or system: for instance, for a

process to be reusable, it must consider a variety of environmental conditions which may

impact successful completion of an activity, such as in incident management, “how can the

process be initiated before an end-user calls the Service Desk?” This may require more effort

upfront in the design of the process or system, but it save the organization more in the long run

because the process or system can be applied to a greater number of situations.

The re-use policy simply declares the organization’s commitment to the re-use of processes

and systems and the extent or level of re-use expected in the environment. The policy will also

provide guidelines for controlling reuse; for instance, with regards to data. In communications

training, a popular exercise is to tell a story to one person who tells another, then another until

the story have been told at least five times and then the final person tells the story out loud. In

almost every case, the final iteration of the story is significantly different from the original story.

Another example is the distortion of faxing a fax. The reason for the distortion is interpretation:

an iteration of the original is simply an interpretation of the original or an interpretation of an

interpretation.

In Service Management and business, data is a valuable commodity. The most reliable source

of data is its original source, i.e. the system which initially gathers the data. This data is often

pulled and used for other purposes and sometimes these secondary systems become sources

themselves. This begins the phenomenon of ‘distortion through interpretation” illustrated

above. However, the reason for the distortion is because these secondary systems tend to put

data into some context that is not available in the original source, often times pulling relatable

data from several sources to reach a conclusion. The reuse policy enforces the concept that the

data should be retrieved from its original source for all secondary systems, but it also enforces

the concept that the original source should expand its data gathering to include additional and

70



relevant data needed by these secondary sources, if possible.

The idea and benefits of re-use can be expanded to the use of Service Transition models:

standardized projects for implementing similar types of changes to the environment. This

level of standardization is similar in concept to the development and use of architectures

and standard designs in the Service Design stage. These Service Transition models can even

incorporate industry standards and best practices. The re-use policy may specify which external

standards and best practices will be leveraged. As organizations grow, different objects for re-

use may be classified into a hierarchy, i.e. objects for global use as well as objects for regional

use.

Some common considerations for re-use to be defined in the policy are:

• Common deliverables into and out of Service Transition, i.e. SDP, SAC, change approval, etc.

• Program and projected management method (PRINCE2 or PMBOK).

• Existing communication channel (SLM, BPM, ITSCM, and supplier management).

• Corporate governance and resource management processes (human resources, education,

finance, and facilities management).

9.1.5 Business Alignment

Ensuring IT services are aligned with the requirements of the customer or business has been

a dominate theme throughout the service lifecycle; unfortunately in Service Transition,

the perception may be that the focus on maintaining alignment is less important than the

development and deployment of the new or changed service – in fact, should the Service

Design have ensured proper alignment. The truth is, Service Transition does have a role in

maintaining alignment between what is required and what is being delivered.

In the last decade of game development, a particular method has been adopted by many

major game studios. The Cerny Method, developed by Mark Cerny Lead Architect for Sony’s

Playstation 4, developed a playable portion of a game as a prototype which is handed over to

potential buyers of the game to “test.” The development team then observes how the game is

being played and will make decisions about the design and progress of the game. In essence,

what the method does is ensure the game is “aligned” with the desired expectations of the end-

user. While it sounds like test is being done in the design phase of game development, if can

occur at any time to ascertain whether the game is “hitting the mark.”

Several activities for maintaining alignment must exist in Service Transition, including:

• Setting expectations with the customer and user about how Service Transition will transpire.

• Setting expectations with the customer and user about how services can be used effectively

to enable business change.

• Provide sufficient information and processes to allow the customer to incorporate service

changes into their business processes and services.

• Ensure customer and stakeholder satisfaction with the service by ensuring compliance with

service requirements and constraints specified earlier in the service lifecycle.

• Share knowledge about the service with customers, users, and stakeholder to increase their

capability with using the new or changed service deployed.

• Monitor and measure service use during deployment and early life to ensure that the service

is fully established before ending Service Transition.

• Compare the predicted and actual performance of the service.

The most devastating directions a service provider can take is to design and develop new or

changed services in isolation from the customer or end-user. This approach actually alienates

the receiving parties of the service and will drastically impact customer satisfaction. A clear

indication of this isolation is the deployment of a service which the end-user does not know

how to use or doesn’t use at all. If this is the case, the service holds no value, and the effort

by the service provider is wasted. The alignment policy provides guidelines for collaborating

with the business, customer and user to ensure the receiving environment can use the new

72



or changed service immediately upon deployment. The guidelines will likely impact project

management, communication plans, business change, and stakeholder management.

9.1.6 Stakeholder Relationships

Stakeholders are representatives of functions, departments, or groups who will be affected

by the new or changed service. They can be from the customer organization, the service

provider organization or a third party, such as a supplier. Typically, stakeholders need to know

the progress of a transition project, any issues and what to expect as the project proceeds. In

most cases, the same representatives will be in place for most projects. Because of this, Service

Transition should build strong relationships with relevant stakeholders.

The objectives of stakeholder relationships are to:

• Set consistent expectations on the use and performance of any new or changed service

being transitioned into the live environment.

• Communicate any changes to the requirements, design, or expectations set for the new or

changed services which occur during the transition period.

• Provide accurate and up-to-date information and knowledge about the new or changed

service to allow stakeholders to understand and prepare for the change.

The result of effective stakeholder relationships will lead to greater satisfaction over the

deployed service and increased feedback about the service during the transition period.

The development of stakeholder relationships is done in cooperation with service level

management, business relationship management and supplier management. The Service

Transition policy will define how these relationships will be developed and maintained

appropriately based on the aforementioned processes. The policy will also define to what extent

knowledge and information from Service Transition will be shared, i.e. what plans and progress

issues are shared.

9.1.7 Transition Control

Transition is all about change and change to services and Service Management systems must

be controlled rigorously. The transition control policy defines what controls will be established

throughout the service lifecycle to ensure the transition of service changes and releases

are performed smoothly and utilizes the concepts of Service Transition. Some topics of the

transition control policy include:

• Maintaining integrity of all service assets and configurations as identified within the CMS.

• Detection of unauthorized changes through automated audits of the CMS.

• Clearly defining “handover points” (i.e., from development to testing, from testing to

acceptance, and so on), which includes what to handover, the participants, and when and

where the handover takes place.

• Defining the roles and responsibilities for handover and acceptance.

• Establishing auditable processes for configuration, change and problem management

within Service Transition.

• Ensure measurements and reports are in place to ensure realization of business

requirements within Service Transition.

The intent of the transition control is to clearly define:

• Roles and responsibilities within Service Transition.

• Ownership and use of the SKMS and CMS.

• Integration of incident, problem, change and Service Asset and Configuration Management

processes.

• Competencies required to implement changes to controlled, test, and living environments.

• Details for audits of processes and configurations.

• Controls for ensuring services can be managed, operated, and supported according to

design requirements and constraints.

74



9.1.8 Knowledge Transfer and Decision Support

Two systems are developed within Service Transition and useful in all stages of the service

lifecycle: Service Knowledge Management Systems (SKMS) and Configuration Management

system (CMS). This policy provides guidance on why these systems exist, how they should be

used, and what benefits they should bring to the organization.

The policy may touch upon:

• What is quality in terms of data, information, and knowledge?

• Where can quality data, information and knowledge be found?

• Who needs this data, information and knowledge and for what reasons?

• What training and knowledge is required for users to maximize the benefits from acquiring

the aforementioned data, information and knowledge?

• How can quality be improved to increase satisfaction while optimizing costs and

maintenance efforts

• How can improved quality in documentation reduce the number of incidents and

problems?

• How can improved access to documentation increase productivity and effectiveness in

business and Service Management processes?

• How can data, information, and knowledge be centralized to maximize quality and reduce

costs?

• How can data, information and knowledge be summarized effectively to support

specific decisions in predefined and recurring situations, such as approving changes for

implementation?

In essence, the policy will identify what systems are available for storing and sharing knowledge,

who can access those systems and through what interfaces, what knowledge will be contained

within those systems, and the responsibilities of relevant Service Management processes, such

as Service Asset and Configuration Management and Knowledge Management.

9.1.9 Releases

The primary driver of this policy is to establish the need to plan releases in a manner that

enables traceability, efficiencies, and effectiveness in the deployed release. The release policy

will typically touch upon:

• Agreements with the business and other relevant stakeholders.

• Resource utilization and management.

• Resource coordination.

• The mechanisms used in release and distribution to ensure component integrity during

installation, handling, packaging and delivery.

• Emergency releases.

• Failed releases.

• Measurements of Release and Deployment Management.

The release policy is a governing document for the Release and Deployment Management

process; but understanding the policy is essential for the success of any Service Transition

effort. The policy should be defined for one or more services and define what a release is for

the organization. For most people, a release is seen as one or more changes which will impact

different types of service assets and involves the coordination of multiple people across one or

more organizations

Some details of the release policy would include:

• Different types of releases are defined by a description and though unique identification,

numbering, and naming conventions.

• The roles and responsibilities of each stage in the Release and Deployment Management

process are defined.

• Only software assets found in the definitive media library (managed by Service Asset and

Configuration Management) will be used.

• The expected frequency for each type of release will be defined.

• An approach will be established and agreed for accepting and grouping changes into a

76



release.

• The build, installation, and release of distributions process will be automated to improve re-

use, repeatability, and efficiency.

• A configuration baseline for the release will be captured and verified against the actual

release contents.

• The acceptance of a release into Service Transition stage will be supported by the

appropriate exit and entry criteria and authority.

• The acceptance of a release into controlled test, training, disaster recovery or other support

environments will be supported by the appropriate exit and entry criteria and authority.

• Criteria and authority will be established to exit early life support and handover of transition

outputs to the Service Operation.

The general categories for release types include:

• Major releases – involves the introduction of a significant number of new functionality and

will typically supersede some minor upgrades, releases, or emergency fixes previously in

place.

• Minor releases – involves small enhancements and fixes and will only supersede emergency

fixes.

• Emergency releases – involves fixes applied to a small number of known errors or small

enhancements.

One of the main topics of the release policy is establishing a means of distinguishing between

services and release types. A commonly used format for a unique identifier is ABC_x.y.z, which

can be used to identify the service (ABC), major release (x), minor release (y), and emergency fix

(z).

9.1.10 Project Changes

Inevitably, some changes in how a project should proceed will occur; this process is intended

to provide guidance in this situation. While many changes will be the result of unknown

information at the time of planning, the fact that the change may be required should still be

known and planned. This policy should emphasize the need for risk assessment management to

identify the risks associated with these ‘unknown’ factors and document the range of changes

(ITIL uses the phrase course corrections, Service Transition, page 42) allowed by the project.

In this situation, the staff must be trained to recognize when a change is required and apply it

appropriately.

The context of this policy is to set expectations for customer and stakeholders that project

changes may occur within Service Transition and the reasons or conditions for those changes.

The policy also re-enforces the need to capitalize on previous projects for determining what

changes will be needed, the “where” in the project, and the resulting outcomes in these

previous decisions. The “predicted” changes make it easy to perform post-implementation

reviews and debriefs by focusing on whether these decisions were handled appropriately and

with success.

All changes should be managed properly using Change Management and process

management. Such changes can be documented and controlled without making the effort

too bureaucratic. However, the effectiveness of this policy is dependent on the resources and

capabilities allocated to risk management.

78



9.1.11 Transition Resource Management

For most organizations, the personnel used in Service Transition are not dedicated to Service

Transition, but have responsibilities in Service Design, Service Operations or both. Even project

managers may not be dedicated to Service Transition as the PMO organization may exist

outside of the IT department (for internal customers); though most organizations will capitalize

on the experience gained in Service Transition to justify using the same project managers. Even

without the obvious sharing of resources between service lifecycle stages, the probability that

multiple transitions occurring simultaneously but using the same resources is extremely high as

the size of the organization decreases. Resource conflicts are not restricted to human resources

either, as systems may have a variety of functions beneficial to both Service Transition and other

stages of the service lifecycle.

The intent of the resource management policy is to provide guidance for planning for and

resolving any resource conflicts in a manner that eliminates project delays and optimizes the

utilization of all resources. The policy seek to identify what resources are required: for human

resources, this may be defining the roles, responsibilities, skills and knowledge required to

operate within the context of Service Transition. The policy will define how project teams and

tools (project and Service Management) will be selected and developed. While most resources

will be shared, some organization may choose to allocate dedicated resources, which would

be identified within this policy, including their intended use. Commonly used shared resources

should also be identified and common processes be automated.

9.1.12 Early Involvement of Transition Resources

Another concern for most organizations will be when exactly transition resources should be

engaged in the service lifecycle. In theory, the answer to this inquiry is ‘as soon as possible’;

which is still not decisive enough. In Service Design, it was acknowledged that the design effort

and Service Transition will overlap; particularly in developing the Service Design package, as the

high-level transition plan will be defined in the package and input for Service Transition would

be justified. Truthfully, feedback from a Service Transition perspective would be invaluable

when reviewing and revising strategies, in the same manner feedback from Service Operations

would identify improvements to Service Transition.

In practice, participation from Service Transition in early activities of the service lifecycle may

not be easily managed. This process details how Service Transition will be leveraged early on.

This may be mechanisms which detect faults early on which can impact the transition project,

or it may empower Service Transition to stop progress on the project from moving forward

when it is clear that benefits cannot be realized.

The policy may also address how early resources should be engaged within the Service

Transition: for instance when should customers or users be engaged to involve them in the

planning and design of service acceptance testing.

9.1.13 Service Quality

What steps should Service Transition take to ensure proposed changes to services can deliver

the requirements and benefits relevant to the customer and business, as defined in service

and release definitions, service models and Service Design packages? This policy answers that

question and define those steps, the roles and responsibilities, and the methods used in quality

assurance and testing.

The service quality policy will provide guidance for service validation and testing and change

evaluation processes, as well as establishes the roles for problem management and Service

Asset and Configuration Management in assuring quality in service delivery and support. The

policy will essentially define what quality is and how it should be determined.

80



9.1.14 Quality Improvement

As new or changed services are developed and testing, incidents and problems may occur.

These should be promptly resolved using the appropriate Service Management process for

the purpose of eliminating recurrence in operations. Consider the failure of a service test

caused by a wrong configuration: from a Service Management perspective, it is not enough to

simply correct the problem to continue the test, the problem should be logged appropriately,

a resolution investigated and sought after and the final resolution documented for use in

the future. If the problem is significant enough, it may warrant a distinct classification in the

problem management system or establish a known error within the appropriate database. How

to leverage problem and incident management during Service Transition is the intent of this

policy.

9.2 Service Transition Performance

In addition to transition a service into a production environment, responsibilities of Service

Transition include striving for greater efficiencies and effectiveness in the transition effort. This

typically extends beyond any individual transition project, but builds confidence and trust in

how the service provider organization responds to service changes. In this context, a number

of measurements need to be in place to monitor and improve the performance of Service

Transition as a lifecycle stage.

The two categories of measurements for Service Transition are:

• Business and IT plan alignment.

• Service Transition performance.

9.2.1 Business and IT Plan Alignment

The first area for measuring Service Transition simply establishes that all involved parties are on

the same page in reference to Service Transition and ensures that Service Transition meets the

requirements and needs of the business and the customer.

Typical metrics for meeting this objective can include:

• An increase in the percentage of Service Transition plans which are aligned with the

strategies and plans of the business, IT and Service Management.

• The percentage of customers and stakeholders who have a clear understanding of the

practices and capabilities of Service Transition.

• The percentage allocation of the budget for Service Transition activities.

• A rating of quality for Service Transition plans which shall adhere to a structured transition

approach, use of templates and demonstrates completeness in planning.

• The percentage of plans for Service Transition being aligned with policies for Service

Transition.

• The percentage of projects (strategic and tactical) which adopt the practices of Service

Transition.

• Percentage of planning meetings where all relevant stakeholders participate.

• The percentage of documents regarding release planning are quality assured from a Service

Transition perspective.

9.2.2 Service Transition Performance

Ultimately, the performance of a Service Transition is contingent on whether the new or

changed service achieves the predicted/expected levels of utility, warranty, service levels and

resource utilization required. Specific metrics can relate to:

• Resource utilization.

• Resource capacity.

• Capabilities.

82



• Warranty.

• Service levels.

• Cost versus budget.

• Time versus schedule.

• Quality of service.

• Service value.

• Errors and incidents.

• Risks.

While these metrics can be applied to the operational state of the service, they can also be

applied effectively to the transition project to improve the effectiveness and efficiencies of

Service Transition: in essence, Service Transition is a service which addresses the development,

testing and deployment of a new or changed service into a production environment. In

addition to the above concerns, other metrics related to Service Transition can include:

• Comparisons between the cost of testing and evaluation the service pre-deployment

against the cost of incidents post-deployment.

• Delays in Service Transition which constitute a ‘loss of service’ for the customer or business.

• The number of operational problems which could/should have been discovered in Service

Transition.

• Stakeholder satisfaction with Service Transition.

• Cost savings resulting from targeting testing to actual changes to the Service Design (for

existing services or service components).

• A reduction in unplanned work resulting from an emergency, urgent, or late changes or

releases.

• A reduction in the cost of transitioning services and releases.

• Increase in staff productivity.

• Increase in the re-use and sharing of service assets and process assets for Service Transition.

• Staff satisfaction and motivation.

• Improved staff communication and collaboration.

• The improved performance of individual Service Transition processes.

9.3 Inputs and Outputs of Service Transition

The inputs to Service Transition from other service lifecycle stages include:

• Service Strategy:

Ř Vision and mission.

Ř Service Portfolio.

Ř Policies.

Ř Strategies and plans.

Ř Priorities.

Ř Change proposals, with requirements and expected timescales.

Ř Financial information and budgets.

Ř Input to change evaluation and change advisory board meetings.

• Service Design:

Ř Service catalog.

Ř Service Design packages.

Ř Requests for change for transition and deployment of new or changed services.


Ř Process and procedures designs for Service Transition

Ř SLAs, OLAs, and underpinning contracts.

• Service Operation:

Ř Requests for change to solve operational issues.

Ř Feedback on transition quality.

Ř Input to operational testing.

Ř Performance information.


• Continual Service Improvement:

Ř Customer and user satisfaction survey results.

Ř Input to testing requirements.

Ř Data required for metrics, KPIs, and CSFs.


84



Ř Service reports.

Ř Requests for change for implementing improvements

The outputs from Service Transition to other service lifecycle stages include:

• Service Strategy:

Ř Transitioned services.

Ř Information and feedback for business cases and service portfolio.

Ř Response to change proposals.

Ř Service portfolio updates.

Ř Change schedule.

Ř Strategy and policy feedback.

Ř Financial information for input to budgets.

Ř Financial reports.

Ř Knowledge and information found in SKMS.

• Service Design:

Ř Updates to service catalog.

Ř Feedback on Service Design and Service Design packages.

Ř Input and feedback on transition plans.

Ř Response to requests for change.

Ř Knowledge and information found in SKMS and CMS.

Ř Design errors identified in transition.

Ř Evaluation reports.

• Service Operations:

Ř New or changed services.

Ř Known errors.

Ř Standard changes for use in request fulfillment.


Ř Change schedule.

• Continual Service Improvement:

Ř Test reports.

Ř Change evaluation reports.


Ř Achievements against metrics, KPIs and CSFs.

Ř Logged improvement opportunities.

86



9.4 Elearning Module 3 & Workbook Review Questions

1. Which of the following is not an objective of Service Transition?

a. Ensure changes are planned and managed

b. Document and coordinate how service assets are used

c. Manage risks associated with new o changed services

d. Successfully deploy releases

2. When defining the scope of service changes, which of the following change types should be

excluded from the control of IT Change Management?

a. Service portfolio changes

b. Service Strategy changes

c. Business process changes

d. Service Management process changes

3. What is the primary benefit of re-use in Service Transition?

a. Improves efficiency and effectiveness

b. Ensures adoption of new services

c. Facilitates automated activities

d. Establishes rules for behavior

4. What chief non-IT discipline is used to manage Service Transition and may be a part of the

customer or business organization?

a. Human Resources

b. Finance

c. Facilities

d. Project Management

5. The Service Knowledge Management System is used primarily to support what type of

activity in the IT organization?

a. Documentation

b. Decision making

c. Collaboration

d. Configuration control

6. What is a course correction in terms of Service Transition?

a. A change in project scope, schedule, or deliverable

b. An alternative pathway defined in the process

c. An issue or problem that results in delay

d. A strategic re-focus on a deployed service

7. Which of the following disciplines are not commonly associated with Service Transition?

a. Quality assurance

b. Project management

c. Risk management

d. Operational control

8. What metrics used in Service Transition should be aligned with metrics from what other

service lifecycle stage?

a. Service Strategy

b. Service Design

c. Service Operation

d. Continual Service Improvement

89

88



9. What is not typically measured in Service Transition?

a. Effectiveness and efficiency of Service Transition processes

b. Alignment between developed services and Service Design

c. Alignment between Service Design and business requirements

d. Customer satisfaction with a new or changed service

10. What service lifecycle stage is responsible for delivering results of customer’s satisfaction

with Service Transition?

a. Service Strategy

b. Service Design



10 Processes of Service Transition

The processes of Service Transition include:

• Transition Planning and Support.


• Service Asset and Configuration Management.


• Service Validation and Testing.

• Change Evaluation.

• Knowledge Management.

10.1 Transition Planning and Support

Transition Planning and Support and Design Coordination (from Service Design) are very

similar because they provide oversight to the lifecycle stage they belong. Like the Service

Design processes, many of the Service Transition processes have responsibilities in other stages

of the service lifecycle; transition planning and support merely has interfaces to these other

stages. In this capacity, transition planning and support is a means of identifying, managing

and monitoring those process activities which are relevant to Service Transition as a whole and

applied to individual transition efforts and projects.

Chapter 10

90



10.1.1 Purpose and Objectives

The purpose of transition planning and support is to provide overall planning for Service

Transitions and to coordinate the resources required to successfully complete the deployment

of new or changed services. While transition planning and support is heavily dependent on

project management methodologies, projects infer a clearly defined beginning and end,

whereas transition planning and support has responsibility before and after any individual

project.

The objectives of transition planning and support are:

• Ensure the requirements of Service Strategy encoded in the Service Design are effectively

realized in Service Operation though successful resource planning and coordination.

• Coordination activities across projects, suppliers and service teams.

• Within predicted costs, quality and time estimates, establish new or changes services within

appropriately support environments.

• Meet requirements established in Service Design by establishing new or modified:

Ř Management information systems and tools.

Ř Technology and management architectures.

Ř Service Management process.

Ř Measurements methods and metrics.

• Enforce the adoption of a common framework of standard re-usable processes and support

systems.

• Provide clear and comprehensive plans for aligning customer and business change projects

with Service Transition plans

• Identify, manage and control risks.

• Ensure Service Transition issues, risk, and deviations are reported to stakeholders and

decision makers.

• Monitor and improve the performance of the Service Transition lifecycle stage.

10.1.2 Scope

Transition planning can be seen on two levels:

• High level oversight across multiple projects, services and service teams.

• Individual transition projects to build, test and deploy changes or release to a production

environment.

In truth, the process of transition planning and support only covers, in scope, the high

level oversight; the detailed planning required for individual projects is part of the Change

Management and Release and Deployment Management processes. In this context, the

detailed scope of transition planning an support includes:

• Maintaining policies, standards and models used for transition activities and processes.

• Guiding individual changes or releases through all the Service Transition process.

• Coordinating the effort required to manage multiple transition projects simultaneously.

• Prioritizing resources and requirements to minimize impact from conflicts.

• Budget and resource planning needed to fulfill future transition requirements.

• Reviewing and improving the performance of transition planning and support activities.

• Coordinating Service Transition with program and project management, Service Design,

and service development activities.

10.1.3 Value to Business

The primary value received from transition planning and support is the increased ability of the

service provider to manage high volumes of changes and releases and ensures the transition

plans of the service provider are aligned with the project plans of the customer and business.

92



10.1.4 Policies, Principles, and Basic Concepts

The transition planning and support makes use of two policies (both were introduced in the

previous section:

• Service Transition policy.

• Release policy.

10.1.5 Process Activities

The activities of transition planning and support focus on:

• Establishing a transition strategy.

• Establishing criteria to move through the lifecycle stages of a Service Transition.

• Preparing for Service Transition.

• Planning and coordinating Service Transition:

Ř Planning individual Service Transitions.

Ř Integrated planning between multiple transitions.

Ř Adopting program and project management.

Ř Reviewing transition plans.

• Providing transition process support in the form of:

Ř Advice.

Ř Administration.

Ř Communication.

Ř Progress monitoring and reporting.

An important concept to understand is the Service Transition lifecycle stages. These are usually

defined by Service Design and contained in the Service Design package; however the exit

and entry criteria to move from one stage to the next are typically standardized and defined

by transition planning and support. The typical stages of the Service Transition lifecycle can

include:

• Acquire and test new configuration items and components.

• Build and test.

• Service release test.

• Service operational readiness test.

• Deployment.

• Early life support.

• Review and close Service Transition.

Not every Service Transition will need to go through all stages, though some stages may be

required for all changes and releases as a whole, or based on the type. At the end of each stage

is a set of deliverables, which altogether demonstrate “quality” within the service, change, or

release.

10.1.6 Triggers, Inputs, and Outputs

Transition Planning and Support will be triggered by the following events:

• Authorized change for individual transition of new or changed service.

• Change proposals from service portfolio for long-term planning.

• Budget for financial planning across multiple Service Transitions.

94



The inputs and outputs of design coordination are summarized in the following table:

Inputs OutputsChange proposal Transition strategy and budgetAuthorized change Integrated set of Service Transition plansService Design Package, which includes:

• Release package definition and

design specification.

• Test plans.

• Deployment pans.

• Service acceptance criteria (SAC).

Transition Planning and Support will interface with the Service Transition processes, as well as

Design Coordination in the form of the Service Design package and the functional groups of

Service Operations. The intent of the interfaces is to ensure the smooth running of individual

Service Transitions from design to operations. The major interfaces for Transition Planning and

Support are:

• Demand Management – provides relevant information about long-term requirements on

resources.

• Service Portfolio Management – elicits feedback on transition planning and decision making

as well as specific change proposals to trigger long-term planning for Service Transitions.

• Business Relationship Management – manages appropriate two-way communication with

the customers, particularly in situations where cooperation from the customer is required to

complete transition activities.

• Design Coordination – provides the Service Design package detailing the work required in

Service Transition with input from Service Design packages.

• Supplier Management – manages appropriate two-way communication with suppliers,

particularly when meeting requirements of Service Transition (products, services and

activities) which are the responsibility of the supplier to deliver and/or support.

• Service Transition Processes – activities related to Change Management, Service Asset and

Configuration Management, Release and Deployment Management, service validation and

testing, change evaluation and Knowledge Management within Service Transition are to be

coordinated though transition planning and support.

• Service Operation Processes and Functions – transition planning and support coordinates

any pilots, handovers and early life support of transitioning new or changed services, as well

as elicits any feedback related to the operational risks, opportunities, and capabilities when

deploying and accepting a new or changed service into the production environment.

• Program and Project Management – provides appropriate methodologies for managing

transition projects.

10.1.7 Critical Success Factors and Key Performance Indicators

The following critical success factors and key performance indicators are samples related to

Transition Planning and Support. Each critical success factors has at least one key performance

indicators which is used to demonstrate achievement of the CSF.

• Tradeoffs between cost, quality and time are understood and managed:

Ř The number of releases meeting the customer’s agreed requirements for scope, quality,

cost and schedule is increasing.

Ř The variation between actual and predicted scope, quality, cost, and schedule are

decreasing.

• Communication with stakeholders is effective:

Ř Customer and user satisfaction with plans and communication is increasing.

Ř The number of business disruptions due to misalignment with Service Transition plans

and business activities is decreasing.

• Risks of failure and disruption to service are identified and managed:

Ř The number of issues, risk, and delays is decreasing.

Ř The success rate for Service Transition is increasing.

• Activities from multiple Service Management processes during individual Service Transitions

are effectively managed:

Ř Efficiency and effectiveness of the processes and supporting systems, tools, knowledge,

96



information and data used in transitioning new or changes service sis improving.

Ř The time and resources required to develop and maintain integrated transition plans and

coordinated activities are decreasing.

• Conflicts between shared resources are managed:

Ř Satisfaction from project and service teams regarding Service Transition practices is

increasing.

Ř The number of issues related to conflicting demand for shared resources is decreasing.

10.1.8 Challenges and Risks

Transition Planning and Support required multiple relationships to be established and managed

appropriately in order to effectively maintain a solid approach to Service Transition. These

relationships are key for Service Transition as a lifecycle stage and as individual projects to

implement new or changed services. The management of multiple project requires careful

coordination and prioritizing to ensure smooth progress for individual projects regardless of

resource conflicts, delays, or other issues.

The risks related to transition planning and support include:

• Lack of information from service portfolio management and demand management

regarding long-term requirements on Service Transition; which results in greater reactivity

when Service Transition activities are required.

• Poor relationships with program and project teams, which results in unexpected Service

Transition requirements.

• Resource constraints which are enhanced when delays in one Service Transition impact

future Service Transition because committed resources cannot be freed.

• Insufficient information to prioritize conflicting requirements.

10.1.9 Summary for Transition Planning and Support

ContXT is a rapidly growing marketing firm with some major clients. Over the last few years,

they have been a relatively small outfit providing some high quality output. They have grown

from a staff of 10 to over 120 people in the last five years. They have three people who handle

all their IT requirements full time but they have not fully investigated at how IT can enrich their

productivity and corporate goals. As a result for the first time in several years, they are receiving

negative feedback from their clients regarding issues like communication, duplicate requests,

and slower than expected project schedules.

From work done as part of the Service Strategy lifecycle stage (as detailed in the Service

Strategy Certification Book), the IT department has identified several services (with associated

objectives):

1. Increase the number of available conference sessions each week.

Ř Teleconferencing service.

Ř Video conferencing service.

Ř Client interface with project management system.

Ř Information security.

2. Reduce the overall time and resource commitments allocated to existing and future

marketing schedules (projects).

Ř Project management system.

Ř Internal knowledge base.


3. Reduce the risks associated with knowledge capture and sharing internally, with clients, and

through remote network access.


Ř Remote access (VPN).

98



While the company currently has processes, systems, and practices in place for several of these

services, none have been formally designed and deployed in the environment; while other

services, like remote access, will be completely new to the environment.

Through the work performed in Service Design, each of these services were analyzed and an

appropriate Service Design package was created. Some services will rely heavily on external

suppliers to deliver or support the majority of the service (video and tele-conferencing

services), while other services were critical to the core business processes of the company and

the majority of the solution developed and deployed in-house (project management system

and internal knowledge base).

For transition planning and support, each service is represented by a Service Design package

which includes the requirements and plan for Service Transition. Based on how the organization

chose to proceed strategically, there could be six to nine Service Transitions (information

security may be three separate projects due to the different focus areas and the client interface

may be one project with the project management system as another project) to manage: each

with varying requirements regarding scope, quality, cost and time. With an initial IT department

consisting of three people, the level of resource management needed in ensuring each Service

Transition is successful is high. With information from service portfolio management, demand

management, and the Service Design package, the Service Transitions can be prioritized and

issues impacting Service Transitions can be communications (particularly those issues related to

lack of human resources).

10.1.10 Elearning Module 4 & Workbook Review Questions

1. What is not within the scope of Transition Planning and Support?

a. Detailed planning of the build, test and deployment of individual changes or

releases

b. Planning the budget and resources needed to fulfill Service Transition requirements

c. Guiding each major change or new service through all Service Transition processes

d. Maintaining policies, standards and models for Service Transition activities

2. What is the value of Transition Planning and Support?

a. To ensure all Service Transition processes meet objectives

b. To coordinate transition efforts across the organization and with external customers

and suppliers

c. To improve the ability of the service provider to handle high volumes of change and

releases to its customers

d. Gathering and providing meaningful information and knowledge to be used in

decision-making at all levels of the organization

3. In what service lifecycle stage are Release and Deployment Management plans developed?

a. Service Strategy

b. Service Design

c. Service Operations


4. What part of the Service Design package will describe the expected utility and warranty of a

service to be transitioned into the production environment?

a. Service model

b. Service specifications

c. Service acceptance criteria

d. Service charter

100



5. Which of the following is not addressed by the release policy?

a. Unique identification of the release

b. Roles and responsibilities

c. Cost control for release management

d. Expected frequency for releases

6. If given an application with the name “controlapp 3.2.6,” what is the likely indicator of the

number “2”?

a. Major release version

b. Minor release version

c. Emergency release version

d. Application version

7. What is the trigger for Transition Planning and Support?

a. Authorized change

b. Service issues

c. Service improvements

d. Design changes

8. Which of the following is an output of Transition Planning and Support?

a. Service Design package

b. Change proposal

c. Transition budget

d. Authorized change

9. What process must Transition Planning and Support interfaces with to facilitate

communication with the customer?

a. Service Portfolio Management

b. Business Relationship Management

c. Supplier Management

d. Demand Management

10. Which of the following key performance indicators will best demonstrate effective

management of conflicting resources for shared resources during Service Transition?

a. Increased project and service team satisfaction with Service Transition practices

b. Reduction in the number of issues, risks and delays

c. Increased customer and user satisfaction with plans and communication

d. Reduction in the variation found between actual and predicted scope, quality, cost

and schedule

11. What is the greatest challenge for Transition Planning and Support?

a. Lack of information about the service

b. Resource constraints

c. Conflicting requirements

d. Stakeholder relationships

102



10.2 Change Management

ITIL Service Transition defines change as “the addition, modification or removal of anything that

could have an effect on IT services. The scope should include changes to all architectures, processes,

tools, metrics, and documentation, as well as changes to IT services and other configuration items.”

(page 306). Within this definition, the key to managing change is determining what the

statement, “anything that could have an effect on IT services” means for the organization. When

taken in the context of the service lifecycle, here are some potential items that could have an

effect on IT services:

• Service Strategy – corporate strategy, Service Strategy, IT strategy, plans, policies,

requirements, service portfolio, budgets, service models.

• Service Design – service solution, management and technical architectures, management

information tools and techniques, Service Management processes, measurements and

metrics, Service Design package, service acceptance criteria, service level agreements,

process-based plans and policies.

• Service Transition – project plans and templates, CMS, policies, SKMS, testing environment,

transition cost and schedule, change and release schedule(s).

• Service Operation – automation, monitoring, known error database, internal controls.

• Continual Service Improvement – CSI Register.

Based on the definition, changes to any of these items will need to be controlled and managed.

However, the organization must decide the level of formality and rigor they bring to managing

change; though some pressure is given from external regulations, legislation, and standards to

demonstrate change control. A formal Change Management will support:

• Different sizes and kinds of organization.

• Different types and sizes of changes.

• Various levels of impact and priority

• Constraints to change, such as time, cost, and quality.

Change is a simple concept to understand: knowing how to effectively manage change is a

different story. Changes can be introduced proactively or reactively. New or changed services

are typically proactive changes because the effort to develop and deploy them will usually be

to obtain some form of benefit or improvement out of the service which was not there before.

Reactive changes are generally a response to some error in the environment or an immediate

change in circumstances. Ideally, an organization will want to have more proactive changes

than reactive.

The reasons to manage change of any type are to:

• Manage the exposure to risk.

• Minimize the impact or potential disruption due to the change.

• Minimize the number of failures and rework in implementing the change.

• Raise stakeholder awareness of upcoming changes and obtain appropriate feedback.


The purpose of Change Management is to control the lifecycle of changes in order to obtain

the most benefit with the least disruption to the environment. Like most Service Management

process, it is best to perceive Change Management in terms of instances: where each change is

an instance of the executing the Change Management process. In this context, each instance

of change has its own lifecycle. However, the lifecycles of individual changes will overlap, as

most times several changes are occurring simultaneously. So while controlling the lifecycle of

individual changes may obtain most attention from the organization, managing the combined

set of changes is also a major responsibility of Change Management. This is especially important

when considering that multiple changes will have a ripple effect on impact: much like dropping

two stones in water, the ripples resulting from one rock may be minor, but the impact is greater

where the ripples of both stones meet.

104



The objectives of Change Management are:

• Maximizing the value and reducing re-work, incidents and disruption when responding to

the customer’s changing business requirements.

• Supporting the alignment of services and customer needs by responding appropriately to

business and IT requests for change.

• Ensuring the recording and evaluation of all changes.

• Ensuring authorized changes are prioritized, planned, tested, implemented, documented

and reviewed in a controlled manner.

• Ensuring all changes to controlled configuration items are recorded accurately in the

Configuration Management system.

• Optimize overall business risk.

10.2.2 Scope

As mentioned before, the scope of Change Management is depending on the direction of the

organization. Some organizations may support multiple programs for Change Management;

though it is preferable that IT Change Management is used to control all changes in the IT

environment. Therefore, there is a natural distinction between business change and IT Change

Management processes: for external service providers, the distinction can be expanded to

include customer change, business change, and IT Change Management processes. With the

use of suppliers, the supplier Change Management process may be included. Another possible

approach to distinguishing different programs is strategic, tactical and operational. A large

organization may even distinguish between global, regional and local. Even at a component

level, some distinctions can be made: for instance, process change, technical change, and

document change.

Despite all these possible distinctions in programs, the best practice for an organization is

ensuring that the policies and processes of Change Management are consistent across the

entire organization. This means that there are common concepts, techniques and themes which

are adopted consistently by all the programs.

One popular theme in Change Management is its integration with service asset and

configuration items in the form of all configuration items documented within the Configuration

Management systems must be controlled using the Change Management process. This theme is

highly advantageous for determining when Change Management is involved, as the impacted

object to be changed must be recorded in the CMS. However, the theme has an inherent flaw:

the organization must agree upon what constituents a configuration item (or service asset). In

some organizations, the definition may extend only to technical components, and disregards

documentation and standards which have an impact on the delivery and support of the service.

In truth, the problem is usually rooted in functional responsibilities; as different teams will only

want to manage what they have direct responsibility. In any case, the definitions of change and

configuration items may create potential conflicts in meeting the overall objectives of Change

Management.

Ideally, the best approach for determining the scope of Change Management is looking at the

five aspects of Service Design:

• Service solutions.

• Architectures.

• Management systems.

• Processes.

• Measurements and metrics.

If Service Design is done effectively using a holistic approach, then a change to any aspect of

Service Design will potentially impact the delivery and support of an IT service and should be

formally controlled.

106



Another approach for defining the scope of Change Management is to define what is out of

scope, for instance:

• Changes which have a significantly wider impact (service changes which should be

managed by Release and Deployment Management).

• Operational changes (repairs and routine maintenance).

In whole, the Change Management process should, at minimum, be applied whenever

an addition, modification or deletion is made of an IT service, its documentation, and its

constituent components. The process should interface with the Change Management processes

of the customer and any suppliers of services or products, as IT changes may have an impact

and require assistance in deployment for all parties involved.


The key to success in IT Service Management is reliability and business continuity and this is

only available to control of one’s environment. Consider a situation where the organization has

no real control over the environment; they would essentially be blind to their surroundings

and, like a blind person, they would be at a disadvantage. Reliability is, at some level, trust in

one’s environment. For a blind person, this requires creating a regimen, such as counting steps

to certain places or arranging furniture a certain way. For an IT organization, knowledge is also

required to create a regimen in the form of an IT service. The more detail found in the regimen,

the greater the organization’s ability to navigate, deliver and support the service as intended.

Similar to a blind person, any unannounced change to the regimen would cause confusion, loss

and potential harm: for this reason, the IT organization must establish and enforce an approach

to Change Management.

Change Management in an IT organization enables the service provider to:

• Protect the business and other services, during the change and from unauthorized changes.

• Meeting requirements while optimizing costs, schedules and risks.

• Enforcing governance, legislation, regulations, and contract requirements by providing

auditable information about changes.

• Reducing failures during changes which contribute to potential disruptions, defects and re-

word regarding the service.

• Tracking changes through the service lifecycles and to service and customer assets.

• Assessing risks associated with Service Transition.

• Improving staff productivity by minimizing disruptions due to unplanned or ‘emergency’

changes.

• Reducing time and effort required to implement corrective changes, thus decreasing mean

time to restore service.

• Coordinating with business (customer Change Management processes to identify

opportunities for business improvement.

A well-structured and effective Change Management process can obtain significant efficiencies

and cost savings while delivering:

• Impact assessments of business changes in IT.

• Impact analysis of a service or IT change on a business.

• Communicating the existence and status of requests for changes to interested stakeholders.

• Recording and maintaining accurate information for change, configuration and release and

deployment.

• Managing and resolving incidents resulting from changes.

• Identifying problems that require change to resolve.

• Identifying new ideas and technologies to add to, modify, or change existing service

environment.

108




The Change Management policy, or change policy, is a comprehensive set of guidelines

regarding how Change Management is integrated into the overall service environment.

These guidelines originated, and therefore be committed, from executive management.

While the majority of the policy may focus on the expectations for how Change Management

operates and to reduced unplanned and unauthorized changes, the policy may also include

commitments to shorten change times and reduce costs in the process.

The change policy should address:

• Establishing a cultural intolerance for unauthorized change

• Creating alignment between the various Change Management processes operated by

customer, business, project, stakeholder, and supplier organizations when dealing with

changes in the IT environment.

• Ensuring business value and benefits are achieved by measuring and reporting each

change.

• Prioritizing changes to optimize benefits, costs, schedules, and risk.

• Establishing accountability and responsibilities for changes throughout the service lifecycle.

• Applying controls regarding segregation of duties.

• Establishing a single focal point for changes.

• Preventing unauthorized personnel from making changes to support the environment.

• Establishing controls for tracing changes, detecting unauthorized changes, and identifying

change-related incidents though close integration with other Service Management process.

• Establishing and enforcing change windows.

• Evaluating the performance and risk of all changes.

• Establishing and measuring performance measures for the Change Management process.

The design and plan of Change Management must be tightly integrated with the design

and plans for Service Asset and Configuration Management and Release and Deployment

Management. The design considerations should address:

• Compliance with relevant legislation and regulations, industry codes of practices, standards

and governance.

• Means of eliminating unauthorized changes.

• Identifying and classifying changes, change records, change document types, templates,

expected content and methods for determining impact, urgency and priority for individual

changes.

• Establishing an organization structure for change, with clear roles and responsibilities for

stakeholders, evaluators, testers and advisory boards.

• Providing clear processes, procedures and training to stakeholders to enable them to make

their own changes appropriately with the necessary planning, communication and control

to minimize any adverse impact.

• Establishing an approach to group and relate changes according to a planned change

window, release, build or baselines.

• Establishing effective procedures for:

Ř Authorizing changes.

Ř Raising a request for change.

Ř Tracking and managing change requests.

Ř Performing prompt impact assessment and evaluation of change requests.

Ř Identifying dependencies and incompatibilities between change requests.

Ř Verifying change implementation.

Ř Providing oversight and evaluation of deliverables for the implementation of changes

and releases.

Ř Measuring and reporting result of changes and business benefit(s) achieved.

Ř Conducting regular change reviews to identify trends and potential improvements.

• Interfaces with other Service Management processes to obtain proper assessment and

review of the impact.

• Interfaces with incident and problem management to measure and reduce incidents related

to changes.

110



• Interfacing with Service Asset and Configuration Management to providing quality

information needed in impact assessment and reporting, identifying high-risk and impact

configuration items, capturing information on configurations, configuration baselines,

releases and related deliverables.

The Change Management process will generally initiate with a change request. The actual

format of the request may vary from a document, a service desk call, or a record managed by

another process. The truth is different types of change may require different formats. Three

types of changes are typically recognized:

• Normal change – any service change not viewed as an emergency or standard change.

• Emergency change – a service change that must be implemented quickly and therefore will

utilize a special procedure where much of the administrative work for a change is performed

post-implementation. A high level of risk is involved in this type of change and therefore is

discouraged, except in cases where failure to implement the change will prove even riskier

for the customer.

• Standard change – a pre-authorized service change that is performed frequently and

perceived as routine and low risk: such changes will have procedures or work instructions

which must be executed precisely and does not have to invoke the Change Management

process with each request. Requests for access to applications or systems or asset moves are

considered standard changes.

At times, the terms, change, change record and request for change, are used synonymously;

though there is a distinction. A change is the addition, modification or removal of an ‘object’.

A request for change is a formal proposal for the change and is submitted by paper or

electronically. A request for change is different from a change proposal which is developed as

part of the service portfolio management process: a change proposal may turn into a request

for change eventually. A change record is a document containing the details of the change.

Every request for change will have a change record associated with it and the change record will

detail the specific configuration items affected by the change.

As mentioned before, change requests may arrive from a number of directions, but at some

point, every change request will be documented as a change record in some system. Typically,

change records are stored in the Configuration Management system or another component of

the Service Asset and Configuration Management with appropriate links to the Configuration

Management system. Another interface to consider is with the service desk tool used to log

calls, as some service requests through the Service Desk are typically requests for standard

change that still must be recorded in the appropriate Change Management system.

A convenient approach to managing the different types of changes, means of requesting

changes, and the context of the different changes is to establish and maintain change models.

A change model predefines the steps to take when dealing with a particular type of change.

Emergency changes and standard changes will often be associated with a particular change

model.

Change models will address:

• Steps to complete the change.

• Steps to handle unexpected issues or events.

• Sequence and dependencies related to the steps.

• Who/what performs each step.

• Estimated timescales and thresholds for completing each step and the overall change.

• Procedures for escalation.

112



Change models can be used to develop standard changes: as change models are used with

little or no deviation over multiple changes, the organization may be able to establish a known

standard changes. Standard changes will have some common characteristics:

• A defined trigger for initiating the change is identified.

• The tasks for implementing the change are well-known, documented and proven.

• Authorization for the change is obtained quickly and with little argument.

• Budgetary approval for the change is obtained beforehand or the affected budget is under

the control of the person requesting the change.

• Risks associated with the change are well-known and usually seen as low risk.

The use of change models and standard changes increases the efficiency of the Change

Management process.

While the primary trigger for Change Management is any request for change, the process can

also be consulted to assess and analyze potential changes before they are requested. These

requests usually are submitted by the service portfolio management process in the form of

change proposals and include:

• High-level description of the new, changed, or retired services.

• Business case with detailed risks, issues and alternatives, including budgetary and financial

expectations.

• Draft schedule for design and implementation of the change.

Even the best planning for a change will not prevent a change from failing. The challenge of

a failed change is returning the service to a workable state: this may be achieved by back-out

of a change, invoking service continuity plans, or other actions approved by the organization.

Because the possibility of failure always exists, even at minimum levels, every change should

document appropriate plan for remediation.


1. Which of the following reasons are not valid for why change should be managed in an IT

environment?

a. Minimize the impact of change on the environment

b. Prevent unnecessary rework due to failure

c. Increase satisfaction with new functionality

d. Ensure stakeholders are informed

2. Which of the following assessments is not required for a change?

a. Risk assessment

b. Cost assessment

c. Impact assessment

d. Continuity assessment

3. Which of the following statement is not part of the purpose for Change Management?

a. Control the lifecycle of all changes

b. Enable beneficial changes to be made

c. Enable minimum disruption to IT services

d. Control the type and scope of changes to the environment

4. Which Service Management process does Change Management work closely with to ensure

proper tracking of changes to service components in the environment?

a. Service Asset and Configuration Management

b. Release and Deployment Management

c. Knowledge Management

d. Service Catalogue Management

114



5. Which of the following is not controlled through the IT Service Management process for

Change Management?

a. Service solutions

b. Business processes

c. Measurement systems

d. Technology architectures

6. A tactical change from the business will potentially affect what aspect of the service

provider directly?

a. IT services

b. Service portfolio


d. Service Transition

7. When a change is preauthorized, what type of change is this commonly referring to?

a. Standard change

b. Normal change

c. Emergency change


8. What term most accurately describes the document used to manage the lifecycle of a

change?

a. Change

b. Change proposal

c. Request for change

d. Change record

9. While all changes must be documented, what type of change allows most of the

documentation to be performed post-implementation?

a. Standard change

b. Normal change

c. Emergency change


10. What must be in place before any change is authorized for the purpose of handling

unexpected issues?

a. Remediation plan

b. Risk analysis

c. Impact assessment

d. Change evaluation

116



10.3 Process Activities

The process of Change Management covers:

• Planning and controlling change.

• Scheduling changes and releases.

• Communications.

• Decision-making and authorization regarding changes.

• Remediation planning.

• Management reporting.

• Impact assessment and analysis.

• Continual improvement.

The typical steps of the process with regard to individual changes address:

• Creating and recording the request for change.

• Initial review of requests for change.

• Assessing and evaluating the change, including determining:

Ř Level of change authority requirement.

Ř Relevant areas of interest.

Ř Business justification, impact, cost, benefits, risk, and predicted performance.

Ř Submitting request for evaluation to change evaluation process.

Ř Authorizing change.

Ř Review by Change Advisory Board or other change authority.

Ř Communicating decision to all stakeholders of the change.

Ř Updating change plan.

Ř Coordinating the implementation of the change.

Ř Review and closing the change, including collation of all change documentation,

performing post-implementation, entering relevant information into SKMS and closing

the change record.


Change Management will be triggered by the following events:

• Strategic Changes, including changes to:

Ř Legislation and regulations.

Ř Organization.

Ř Policies and standards.

Ř Service offerings.

Ř Service portfolio.

Ř Customer portfolio.

Ř Customer agreement portfolio.

Ř Patterns of business activity.

Ř User profiles.

Ř Sourcing models.

Ř Technology innovation or plans.

• Service Changes, including changes to:

Ř Service catalog.

Ř Service packages.

Ř Service definitions and characteristics.

Ř Release packages.

Ř Capacity and resource requirements.

Ř Service level requirements.

Ř Warranties.

Ř Utilities.

Ř Cost of utilization.

Ř Service assets.

Ř Acceptance criteria.

Ř Predicted quality of service.

Ř Predicted performance.

Ř Predicted value of service.

Ř Organizational design.

118



Ř Stakeholder and communication plans.

Ř Physical environment.

Ř Measurement systems.

Ř Process-specific plans.

Ř Decommission/retire services.

Ř Procedures, manuals, and service desk scripts.

• Operational Changes:

Ř User requests – typically through request fulfillment process.

Ř Corrective and preventative changes.

• Improvement Changes.

The inputs and outputs of Change Management are summarized in the following table:

Inputs OutputsChange strategy and policy Rejected or cancelled requests for serviceRelease strategy and policy Authorized changesRequest for change Authorized change proposalsChange proposal Changes to services, service assets or

infrastructurePlans, specifically change, transition,

release, test, evaluation and remediation

New, changed or disposed configuration

itemsChange schedule and PSO (projected

service outage)

Revised change schedule

Evaluation reports and interim evaluation

reports

Revised projected service outage

Current assets o configuration items (as

recorded in CMS)

Authorized change plans

As-planned configuration baseline Decisions and actions regarding individual

changes

Inputs OutputsTest results, test report, and evaluation

report

Change documents and records

Change Management reports

Change Management will integrate at a general level with:

• Transition Planning and Support – to coordinate management of Service Transitions and

resulting changes.

• Business change processes.

• Project management change approach.

• Organizational and stakeholder change processes.

• Supplier change processes.

• Partner change processes.

Specific interfaces with Service Management processes will be found with

• Service Asset and Configuration Management – shares information contained within

the CMS to assess and evaluate RFCs and change proposals, with the information being

updated after the completion of the authorized changes.

• Problem Management – a primary source for initiating requests for changes required to

implement workarounds and fix known errors.

• IT Service Continuity Management – provides impact assessments of all change on service

continuity, while Change Management is used to control changes to continuity plans.

• Information Security Management – provides impact assessment of changes from a security

perspective.

• Capacity Management – provides assessment of changes from a capacity perspective.

• Demand Management – communicates projected changes or impact of RFCs to service

demand.

• Service Portfolio Management – prioritizes and charters strategic changes and submits

120



change proposals for authorization in long-term planning.

Change Management can be used to control changes to all process documentation, policies,

and plans.



Change Management. Each critical success factor has at least one key performance indicator

which is used to demonstrate achievement of the CSF.

• Respond to business and IT requests for changes and ensure they align services with

business needs while maximizing value:

Ř Percentage increase in changes meeting customer’s agreed requirements.

Ř Benefits of change exceed the costs of change.

Ř Reduction in the number of change requests in backlog.

Ř Average time to implement change meets SLA targets, based on change type, urgency

and priority.

Ř The number of predictions accurate in terms of time, quality, risk, resource and

commercial impact of changes increases.

Ř Stakeholder satisfaction increases, as demonstrated though survey scores.

• Optimizing overall business risk:

Ř The number of disruptions, defects, and re-work resulting from poor or incomplete

impact assessments or inaccurate specifications for change is decreasing.

Ř Percentage decrease in the number of emergency changes occurring.

Ř Change success rate is increasing.

Ř Number of changes where remediation plans are invoked is decreasing.

Ř The number of failed changes is decreasing.

Ř The number of unauthorized changes is decreasing.

Ř The number of change-related incidents is decreasing.

• Ensure all changes to configuration items are managed well and documented appropriately

in the Configuration Management system:

Ř The number and percentage of changes with incomplete change specifications is

decreasing.

Ř The number of percentage of changes with incomplete impact assessments is

decreasing.

Ř The number of audit compliance issues related to Change Management is decreasing.

Ř The number and percentage of discrepancies found in a verification and audit of Service

Asset and Configuration Management is decreasing.


The primary reason for an ineffective Change Management process is the lack of recording and

managing each and every change in or impacting the service environment. This reason for this

is the scope of the process is not broad enough or the process is being by-passed by personnel.

This can be easily rectified with active and visible sponsorship of the Change Management

from executive and senior management. The process owner should have a plan for regularly

communicating the scope and value of Change Management to IT staff.

A mis-perception of Change Management is that it introduced delays, rather than facilitate

change. Practically speaking, unnecessary delays may be the result of too much bureaucracy or

when certain steps required to introduce the change have no real value. In the end, the process

must keep everyone on point – Change Management should demonstrate that changes can

occur faster and have a greater success rate than without the process.

Another misconception of Change Management is its only value is to manage the operational

state for the service provider; therefore, some organization will only implement an operational

Change Management. This scope is too constraining for a Change Management process to

support the entire service lifecycle. One source of this problem is the implementation of a

Change Management tool which is supposed to support the entire process; but it is difficult to

cater specific change types without inducing confusion.

122



For instance, the Service Desk needs access to the Change Management tool to record service

requests; but the classifications and other options used by the Service Desk is very limited;

however, there is only one interface in the current tool version to enable logging and the

number of available options are more than the service desk requires. In this situation, the

Change Management tool may be seen as incompatible with the service desk; the solution

is to provide a different tool for their use or create a different interface for logging service

requests or other alternative available to the organization based on their objectives, cost, and

competencies. The basic lesson is focusing on serving one group with technology or attempting

to find a “one-size-fits-all” technical solution will be difficult in Change Management.

As an organization grows in size and complexity, changes will begin to occur on several levels

and require different levels of authority and management. Consider a company with several

locations around the world, changes can occur:

• Global – changes impacting every location and every person in the organization, these are

often attributed to strategic changes.

• Regional – changes impacting a large portion of the company but not all of it. Regional

changes can be based on continent, country or state and may be attributed to cultural

factors or legislative or regulatory boundaries.

• Local – changes impacting a single location, usually in response to external factors or

change of focus on operational objectives.

• Departmental (line of business) – a special level of change which introduce changes along

organizational boundaries. This type of change may be global, regional or local but impact

only a portion of the company at each level.

The risks associated with Change Management include:

• Lack of commitment from business or customer.

• Lack of commitment from IT management.

• Lack of commitment from IT staff.

• Unauthorized changes or not using the Change Management process to manage change.

• Change assessments which do not sufficiently consider or evaluate the risks, costs, and

benefits of every change.

• Delays to change implementation without any reasonable justification or value

• Too much bureaucracy in the Change Management process.

• Insufficient time allocated to perform change assessments.

• Pressure to expedite decisions about specific changes.

• Insufficient time allocated to implement a change.

• Too many changes occurring at the same time.

• Insufficient resources allocated to the assessment, planning, and implementation of a

change.

• Poor or misunderstood interfaces with other Service Management process, particularly

Release and Deployment Management and Service Asset and Configuration Management.

10.3.4 Summary for Change Management

At present, ContXT operates as a single office in a major metropolis, but they do have plans to

expand their operations and currently they do partner with several marketing firms in other

cities to support their larger customers. The business has a highly sophisticated business

change process which manages changes to client requirements, but not to actual marketing

project (the reason behind a project management system service). Change Management

within the IT management is even more lacking, though the staff is rigorous in recording actual

configuration changes to hardware assets.

124



The lack of a formal IT Service Management focus has been the greatest factor in the level of

controlling change for the internal service provider. Now with the focus in place, the need

to formally introduce Change Management increases. Several other factors provide further

justification. While the IT department may be minimally impacted by changes to client-specific

projects, the future plans for expansion by the company will impact the IT environment

as demand of services will likely increase. Even without the expansion plans, the current

partnering relationships may identify opportunities for technology to facilitate interfaces, if not

already in place.

A couple of formal services in the pipeline will likely be engaging third-party supplier in some

capacity. As a result, some interaction needs to occur between the IT department’s change

process and that of the supplier. This is in addition to the interaction with the company’s

business change process and, potentially, the change processes of their partners.

Because of the size of the IT department relative to company, it is reasonable to limit the level

of variation in Change Management. This means the number of standard changes performed

should be higher than normal changes and the criteria for authorizing emergency changes

extremely high. Change has to be integrated into the cultural aspect of the company and

supported by all levels of management. The creation of change models will encourage greater

consistency and standardization across multiple change types. A maximum number of changes

implemented during change windows should be clearly defined within the change policy and

the change schedule should be set up to identify when limits are reached.

Cost constraints will push for a single implementation of a Change Management tool to record

and track all changes, or as a component of a Configuration Management system. It may be

justified to rely heavily on document control mechanisms to manage changes to documented

strategies, plans, processes and other IT-related documents and formats. One requisite

component of any Change Management technology is the ability to recognize and link different

types of changes: the ability to identify strategic, tactical and operational changes and link

any correlations will enable the IT management to assess and manage changes with different

priorities and impact.

The implementation of IT Change Management for ContXT will depend heavily on managing

stakeholders, to ensure the right people are involved with each change. The Change Advisory

Board will likely consist of the same participates as the IT Steering Committee: the size of the

company justifies this integration and it properly enforces the role of governance in managing

change.

126




1. Which of the following activities is not the responsibility of Change Management?

a. Planning and controlling changes

b. Communications to stakeholders

c. Status reports in individual CIs

d. Scheduling releases

2. When should a change be authorized?

a. After evaluation of the change

b. After review of request for change

c. After the plan is updated

d. After implementation

3. A normal change will be raised using what convention?

a. Change proposal

b. Request for change

c. Change record

d. Service request

4. The change advisory board may be just one change authority for an organization; if so, what

type of changes would they be most likely to authorize?

a. Changes with a high risk or cost

b. Changes impacting multiple services or customers

c. Changes impact a single service or customer

d. Standard changes

5. What will trigger the Change Management process?

a. New requirement

b. Identified problem

c. Service request

d. Request for change

6. What information used by Change Management is not an output of Service Asset and

Configuration Management?

a. Configuration baseline

b. Configuration details

c. Evaluation report

d. Component relationships

7. Which is not an unacceptable output of the Change Management process and is a possible

indicator of the process not working?

a. Authorized changes

b. Failed changes

c. Cancelled changes

d. Rejected changes

8. What management process will interface with Change Management to ensure changes are

well-managed and the change schedule is effective?

a. Project management

b. Business Change Management

c. Supplier management

d. Stakeholder Change Management

128



9. While Change Management must interface with all Service Transition processes, what

process will likely cripple Change Management if it is not operating effectively because

insufficient information would be available to make the necessary decisions regarding

change?

a. Release and Deployment Management

b. Knowledge Management

c. Service Asset and Configuration Management

d. Service validation and testing

10. Which of the following key performance indicators does not demonstrate the organization’s

ability to optimize business risk?

a. Reduction in the number of failed changes

b. Reduction in the number of unauthorized changes

c. Reduction in the number of incidents attributed to changes

d. Reduction in the number of change requests in backlog

10.4 Service Asset and Configuration Management

A common perception of Service Asset and Configuration Management efforts is within the

realm of inventory management; however, this is very limiting to what the process really is and

is not. For one thing, service asset is defined as “any resource or capability of a service provider”

(Service Transition, page 328). Assets themselves are classified in terms of management,

organization, process, knowledge, people, information, applications, infrastructure or financial

capital. This goes beyond the typical understanding of what “inventory” is. Additionally, a

major concept of Configuration Management is the relationships between different assets: the

self-contained information about an asset has value, but understanding it interrelationships,

dependencies and impact on other assets expands the value exponentially in IT Service

Management.

The idea being the inventory management perception is usually based on financial tracking as a

means of identifying and tracking a company’s financial assets. While there is some correlation,

Service Asset and Configuration Management is not financial management; though it may

provide sufficient information to enable effective financial management for all controlled assets

in its scope.


The purpose of the Service Asset and Configuration Management (SACM) process is layered:

• Ensures proper control of all assets required to deliver and support services for the

customer.

• Ensure information about those assets is available when and where it is needed throughout

the entire service lifecycle.

• Ensure the asset information is accurate and reliable at all times.

• Ensure the information contains details about how assets are configured and the

relationships they have with other assets.

130



The achievement of this purpose is typically a coordinated effort between Service Asset and

Configuration Management, Change Management and Release and Deployment Management.

The objectives of Service Asset and Configuration Management are:

• Identify, control and properly maintain all assets under the IT organization’s control

throughout their lifecycle.

• Identify, control, record, report, audit and verify services and other configuration items (CIs),

including versions, baselines, supporting components, attributes and relationships.

• Ensure that the integrity of the configuration items is accounted for, managed, and

protected

• Working with Change Management to ensure that only authorized access and changes are

made to services and other configuration items.

• Establish and maintain an accurate and complete Configuration Management system (CMS).

• Maintain accurate configuration information on the historical, planned and current state of

services and other configuration items.

• Provide accurate configuration information to Service Management processes to enable

effective and efficient decisions.

10.4.2 Scope

To understand the scope of Service Asset and Configuration Management it is important to

understand the distinction between service assets and configuration items. An asset is any

resource and capability and a service asset is an asset owned and managed by service provider.

If the management of a service asset is required to deliver or support a service, it is also known

as a configuration item. In this context, every configuration item is a service asset: however,

not every service asset is a configuration item. For instance, information and knowledge

are typically considered assets, but are not configuration items. Another approach to this

distinction is any service asset which is under the formal control of Change Management is

a configuration item, while service assets not under Change Management control are simply

service assets.

The primary focus of Service Asset and Configuration Management is the management of every

configuration item throughout its lifecycle. This means identifying, baselining, maintaining,

and controlling changes to each configuration item currently operating in or planned to

be in the service environment. The process will enforce efforts surrounding the authorized

access, use, release, and change to individual configuration items. The information about each

configuration item will show relationships between CIs and can be used to assess impact and

support decisions effectively. Not every configuration item managed by SACM is an IT asset:

work products not classified as an asset in business terms may be used to develop services and

therefore controlled within the SACM process.

Many organizations will have a fixed asset management or financial management process

which will interface with SACM by is not SACM. Typically, the two processes are maintained by

different parts of the same organization. Usually, information from SACM will be communicated

to the fixed asset management process to enable that process to meet its objectives. SACM will

also interface with other internal or external service providers where shared assets need to be

controlled.


The value of Service Asset and Configuration Management is the ability to accurately represent

the services, releases, and environmental characteristics of IT currently in place to support the

business or customer. Capturing this data and information is necessary for every process where

activities exist to plan, assess, evaluate, validate, audit, or report. The information can be used

to demonstrate compliance to requirements, to establish baselines to set future goals and

objectives, and to optimize the performance, costs and risks associated with service delivery

and support.

132



Specific benefits to an effective SACM process are:

• Enables understanding of the configurations and relationships of services, service

components, and other configuration items.

• Enables better forecasting and planning of changes.

• Enables the assessment, planning and delivery of changes and releases.

• Supports the resolution of incidents and problems according to service level targets.

• Supports the delivery of service levels and warranties

• Ensures adherence to standards, legal and regulatory obligations.

• Improves confidence and trust in the service provider who has better control of assets and

services.

• Provides the ability to trace changes from requirements.

• Ability to identify the costs of the service.

• Reduces cost and time needed to discover configuration information.

• Ensures proper stewardship of fixed assets under the control of the service provider.


The first thing to consider in Service Asset and Configuration Management is its close

relationship with Change Management and Release and Deployment Management: the

SACM process plays a critical role in providing and collecting information which is used in

and generated within these processes, in particular, and all Service Management processes in

general. Configuration information is critical to the assessment and evaluation of changes to the

environment, and as changes are applied, changes to the information are fed back into SACM.

Release information is stored and collected as versions by SACM, which enables the service

provider to have a historically accurate evolution of particular configuration items.

Therefore, SACM policies are heavily influenced and dependent on the change and release

policies. SACM policies should set the objectives, scope, principles and critical success factors of

the process. The handling of different types of assets or services may require further guidance

within the policies. Because of constraints on cost and resources in the organization, the

implementation of SACM may be limited in scope and expanded: often organizations will

initially choose to focus on basic hardware and software assets and services.

The body of the SACM policies will focus on basic principles applied to the development and

maintenance of assets and configurations. These principles will establish a framework for SACM

and will typically address:

• The costs and resources for operating SACM should be consistent with the potential risk

to the service: i.e. if more risks exist for the service, more investment is required to manage

configurations.

• SACM resources and capabilities should be consistent with the need to deliver governance

requirements, such as software asset management, Sarbanes-Oxley, ISO/IEC 20000, ISO/IEC

38500, or COBIT.

• SACM resources and capabilities should be consistent with the need to deliver the

resources, capabilities and warranties defined by service level agreements and contracts.

• SACM resources and capabilities should support the delivery of available, reliable and cost-

effective services.

• SACM information should support clear economic and performance criteria relevant to the

ongoing management of costs and optimization of service delivery; for instance, tracking

asset depreciation against value capture.

• SACM resources and capabilities should support a variety of whole-life cost appraisal

methods.

• SACM resources and capabilities should enable the organization to achieve a state of being

proactive (predict and prevent) over reactive (find and fix).

• SACM information should be adequate to support requirements from internal and external

stakeholders.

• A level of control and requirements must be maintained to allow for sufficient traceability

and auditability.

• SACM resources and capabilities should support continual improvement of service levels,

assets and configuration.

134



• SACM information should be adequate to support other business and Service Management

processes.

• Integration with other processes is expected and should be a prioritized accordingly.

• A common CMS architecture must be supported.

• Implementation of automation should be introduced to reduce costs and errors.

At the beginning of this section, the distinction between service asset and configuration

item was explored: every configuration item is a service asset, but not every service asset is a

configuration item and changes to every configuration item are controlled through the Change

Management process. Additional distinctions need to be made regarding configuration records,

configuration databases and the Service Knowledge Management System (SKMS).

Configuration records are a set of attributes and relationships used to describe configuration

items, but they are not the configuration items themselves. Configuration records are stored

within a Configuration Management system; while configuration items exist within the service

environment. While the distinction is simple to understand, the slang use of ‘configuration’ often

refers to either the record or the actual configuration of a service asset. It is important to note

that the scope of SACM is to manage the configuration record, not the actual configuration

item.

The means of collecting and managing configuration records is the Configuration Management

system (CMS), which in turn can be comprised of one or more configuration databases. A single

configuration database may be used to track specific types of service assets or configuration

items. Since service assets may represent management, organization, process, knowledge,

people, information, applications, infrastructure or financial capital resources and capabilities, it

is possible to have one or more database for each category. Databases can be used to organize

by geography, customer, service, or organization. The composite of these databases will be and

is governed by the Configuration Management system.

The CMS is actually a large portion of the Service Knowledge Management System (SKMS)

which is a set of tools and databases used to manage knowledge, information and data. In the

same manner that not all service assets are configuration items, not all information required

for IT Service Management will be reflected in a configuration record. The SACM process is not

responsible for managing the SKMS, but is responsible for managing the CMS which is part

of the SKMS: in this context, there may be SKMS requirements which must be achieved when

managing the CMS.

While the CMS does not need to be more than one database, many organizations have

benefited from have multiple views into the CMS. These views enable the service provider

to present relevant information based on the audience when it is require. The general set of

presentation views into the CMS include:

• Change and release view.

• Technical configuration view.

• Service Desk view.

• Configuration lifecycle view.

Two different methods of presenting or collecting configuration information are configuration

baselines and snapshots. Baselines are configurations of a service, product or infrastructure

which has been formally reviewed and agreed upon. They are generally established to support

changes by representing the existing (before the change) environment. Configuration baselines

are useful to:

• Mark milestones in service development.

• Establish a defined set of inputs for service components (commonly called a build).

• Enable a change or rebuild to a specific version at a future data.

• Back out of a failed change.

• Assemble all relevant components in readiness for a change or release

• Enable configuration audits.

136



Snapshots are created though discovery tools and can be compared against existing

configuration information or recorded as part of the configuration as a fixed historical record

of the configuration item. Snapshots represent the current state of a configuration item or

environment outside of their configuration record and are useful for:

• Supporting problem management in analysis of evidence pertaining to incidents.

• Facilitating system restores to the last good configuration.

• Supporting software used for security scanning.

The core principle behind all SACM efforts is the ability to represent a service asset’s

characteristics and relationships. This representation can be established effectively though

the creation of a configuration model: a logical model of the service and its supporting

components. The configuration model can be seen as a detailed version of the service model

created in the Service Strategy stage. A well-developed service model can support:

• Impact assessments and root cause analysis of incidents and problems.

• Impact assessments of changes.

• Planning and designing new or changed services.

• Planning technology refreshes or software upgrades.

• Planning releases.

• Migrating service assets to different physical locations.

• Optimizing asset utilization and costs.

The level of detail found in a configuration model should be consistent with the level of control

and traceability required on the service provider: specific attributes and relationships should be

not be represented unless they provide value.

The purpose of the configuration model is to show the relationships between configuration

items as they relate to supporting a service. In truth, configuration items can be classified by

type based on size, complexity and purpose. Typical categories for CI types include:

• Service lifecycle CIs – key strategic and tactical documents that define the service, how

they are delivered, expected costs, benefits, and schedule: includes business cases, Service

Management plans, service lifecycle plans, Service Design packages, release plans, change

plans and test plans.

• Service CIs – represents the resources and capabilities related to service delivery and

support (i.e. service assets), as well as service models, service packages, release packages

and service acceptance criteria.

• Organization CIs – represents those assets sourced externally but used and controlled

internally, such as business strategies and policies, regulatory and statutory requirements.

• Internal CIs - the tangible and intangible assets used to support service delivery, i.e. Service

Management software required to deliver and maintain the service and infrastructure.

• External CIs – external customer requirements and agreement, services or service releases

from third-party suppliers.

• Interface CIs – represents the process and/or system interfaces necessary to deliver end-to-

end services.

SACM can contribute to the overall fixed asset management required of the organization by:

• Identifying each asset with a unique name and label.

• Identifying and recording asset owners.

• Maintaining an asset register.

• Understanding and documenting the purchase cost, depreciation and net book value of

each asset.

• Supporting the protection of asses from damage, theft, etc.

• Performing regular audits (inventories) to ensure integrity of fixed assets.

138



While fixed assets are typically seen as hardware, SACM can be extended to support the lifecycle

of service assets, particularly:

• Ensuring software licenses are purchased before use.

• Minimizing the risk and impact of loss of proof of licenses.

• Ensuring license agreements are adhered to during use.

• Identifying when software licenses are not being used or more licenses are required.

Secured stores or libraries are collections of software, electronic or document CIS of known

types and status where access is restricted. The purpose of these stores is to control and release

components throughout the service lifecycle when required. A common secure store is for

definitive hardware spares—spare components and assemblies that are maintained at the same

configuration levels as the systems found in the production environment. These spares are used

when a live system must be replaced. Definitive spares must be managed in the same manner

as every fixed asset.

The definitive media library (CML) is another secure store housing authorized versions of all

media CIs, typically master copies of all controlled software in an organization and controlled

documentation for a system (warranties, install instructions etc.). A fireproof safe may be

considered a DML if it is used to store physical copies of software and documents. Secure stores

and their contents must be identified and managed in SACM.

Since SACM is responsible for the lifecycle of every configuration item, this includes its

decommission. To ensure the confidentiality and integrity of the organization, decommissioning

and disposal of assets must be controlled and is often regulated at some level. Proper

decommissioning considers:

• Redeployment, re-use or selling of assets to maximize the value of the asset.

• Meeting environmental standards or regulatory and legal requirements when disposing

assets.

• Retrieving/erasing/managing data stored properly on decommissioned assets

• Returning leased requirements.

• Updating or cancelling maintenance contracts.

• Updating status the CMS.

• Communicating status to any fixed asset management processes.


The activities of Service Asset and Configuration Management can be segregated into the

following areas:

• Management and planning – focuses on the completion of a Configuration Management

plan and incorporates or aligns to policies, standards, strategies, service portfolio, customer

portfolio, customer agreements portfolio and contract requirements.

• Configuration identification – leverages requirements design, maintenance, release,

deployment and operations plans to ensure all configuration items are identified, named,

labeled, recorded and baselines or release IDs documented.

• Configuration control – coordinates with Change Management to manage the integrity of

all configuration items

• Status accounting and reporting - utilizes change and configuration records to report the

status and performance of configuration items.

• Verification and audit – performs and leverages reviews, audits and tests of configuration

items to ensure they are performing as expected and documented accurately.


Service Asset and Configuration Management will be triggered by the following events:

• Change Management updates.

• Release and Deployment Management updates.

• Purchase orders.

• Acquisitions.

• Service requests.

140



The inputs and outputs of Service Asset and Configuration Management are summarized in the

following table:

Inputs OutputsDesigns, plans, and configuration from

Service Design packages

New and updated configuration records

Requests for change and work orders Updated asset information for fixed asset

registerConfiguration information collected

through tools and audits

Information about attributes and

relationships of configuration itemsOrganization’s fixed asset register Configuration snapshots and baselines

Status reportsAudit reports

Service Asset and Configuration Management will interface with all Service Management

process at some level, specifically in providing and capturing configuration data. Details

regarding specific interfaces include:

• Change Management – provides information regarding the impact of proposed changes.

• Financial Management for IT Service – provides information regarding the financial value of

configuration items including purchase price, depreciation, owners, users, maintenance cost

and repair costs.

• IT Service Continuity Management – utilizes configuration information to produce accurate

continuity plans and depends on effective control of key spares and software when

continuity plans are invoked.

• Incident and problem management – utilizes configuration information in the investigation,

diagnosis and evaluations of incidents and problems and their resolutions.

• Availability Management – utilizes configuration information to detect potential points of

failure.



Service Asset and Configuration Management. Each critical success factors has at least one key

performance indicators which is used to demonstrate achievement of the CSF.

• Integrity of configuration items is accounted for, managed, and protected across the service

lifecycle

Ř Accuracy in budgets and charges for assets utilized by individual customers and business

units is improved.

Ř Re-use and redistribution of under-utilized resources and assets is increasing.

Ř The use of unauthorized hardware and software, non-standard and variant builds is

decreasing.

Ř The number of exceptions reported by configuration audits is decreasing.

• Accurate configuration information is provided at the right time to support the efficiency

and effectiveness of individual Service Management processes:

Ř Improved maintenance scheduling over an asset’s lifetime.

Ř Speed in identifying faulty CIs and restore service though incident management in

improving.

Ř Average time and cost of diagnosing and resolving incidents and problems is decreasing

per type.

Ř Ratio of used licenses against purchased licenses is improving.

Ř Time required to identify poor performance and/or quality in assets is improving.

Ř Risks related to unauthorized changes are decreasing due to early detection.

Ř The percentage decrease of changes not completed successfully.

• An accurate and complete Configuration Management system is established and

maintained

Ř The business impact of outages and incidents related to poor management of service

assets and configuration items is decreasing.

Ř Increased accuracy and quality of configuration information.

Ř Audit compliance improving.

Ř The time required to perform audits decreasing as quality configuration information

142



becomes available more.

Ř Fewer operational errors due to out-of-date configuration information.


The challenges to Service Asset and Configuration Management are:

• Adopting a check-in/check-out policy for definitive spares and physical assets.

• Obtaining and justifying funding for the SACM process: in an effective service environment,

SACM is hidden from the customer and is sometimes seen as a subset of the Change

Management process.

• Data overload – collecting data just because it can be done without any observable value.

• Lack of commitment from management.

The risks associated with Service Asset and Configuration Management include:

• Focusing all SACM efforts on managing technology.

• Information degradation over time, making CI data out-of-date and unusable.

• Too broad a scope for the process.

• Unauthorized changes to service environment.

10.4.9 Summary for Service Asset and Configuration Management

Like most businesses, ContXT has a fixed asset management process in place to track hardware

and software inventory. The process does well in identifying the fixed location of the products

and to whom they are assigned. This information can be the basis for establishing a Service

Asset and Configuration Management process, which will add to the covers items to be

controlled and identify relationships.

Because the company is still relatively small, the CMS may be a small database or structured

documents. The challenge is to identify all the relevant attributes to discover about the various

types of configuration items. The development of the Service Strategy and service portfolio will

provide clues to what to track for each configuration items.

There are two general approaches to meeting the objective to have accurate and complete

information in the CMS: perform a company-wide ‘audit’ to identify all configuration items or

identify CIs as they are applied to new services being transitioned into the service environment.

The first is resource-intensive and may not be the best option unless more people are available

to do the work; however, the advantage is the work is completed faster. The second option

will ensure the alignment between services and configuration items, but will take some time

before the objective can be fully met. One standard operating procedure that can be adopted

is anytime a configuration item is touched due to incident, problem or change, its configuration

data in the CMS is verified and updated accordingly.

The difficulty of IT Service Management with regards to the SACM process is analogous to

the “cart before the horse”: the strategic and design work is appropriate for linking related

configuration items together in alignment with services and business needs, yet the

planning aspects of these efforts are dependent on accurate information from the CMS. This

interdependency may create some conflict about where to start and this is where regular

service reviews and continual improvement has its place. For ContXT, formalizing a few services

will greatly mature IT service delivery even if it is not supported by a complete CMS. While

planning and design for each service would benefit by the configuration data, they can proceed

with the appropriate risk(s) documented and managed.

144




1. What is a service asset?

a. Any resource or capability that could contribute to the delivery of a service

b. Any configuration item which is controlled by the service provider

c. A configuration item that is needed to be managed in order to deliver an IT service

d. Any physical resource used to deliver or support an IT service

2. What is a configuration item?

a. A set of attributes and relationships about a service asset used in the delivery of a

service

b. A tool or database used to manage knowledge, information and data about a

service asset

c. A service asset that is needed to be managed in order to deliver an IT service

d. Any resource or capability that could contribute to the delivery of a service

3. Which of the following is not a benefit of a configuration model?

a. Enables the impact and cause of incidents and problems with a configuration items

to be assessed

b. Enables the impact of proposed changes to be assessed

c. Enables the planning and design of new or changed services

d. Enables the management of risks to service delivery

4. What type of configuration item would a corporate policy be for an internal service

provider?

a. Service lifecycle CI

b. Service CI

c. Organization CI

d. Internal CI

5. The Configuration Management System may be part of what larger IT Service Management

solution?

a. Service Portfolio

b. Service Knowledge Management System

c. Security Management Information System

d. Known Error Database

6. Which of the following is not a correct statement about a configuration baseline?

a. A configuration baseline represents a configuration item which has been reviewed

and agreed

b. A configuration baseline can be used as a basis for comparison

c. A configuration baseline can only be changed using formal change procedures

d. A configuration baseline represents the current state of a configuration item

7. Where are authorized versions of all media configuration items stored and protected?

a. Configuration Management system

b. Definitive media library

c. Service Knowledge Management System

d. File system or safe

8. Which of the following activities does not relate to the decommissioning of an asset?

a. Redeployment

b. Disposal

c. Returns

d. Buying

146



9. The information resulting from a change to a Configuration Management will be updated as

part of what process step in Service Asset and Configuration Management?

a. Management and planning

b. Configuration control

c. Status accounting and reporting

d. Verification and audit

10. Which of the following will not trigger Service Asset and Configuration Management?

a. Acquisitions

b. Purchase orders

c. Requests for change

d. Service requests

10.5 Release and Deployment Management

ITIL defines release as “one or more changes to an IT service that are built, tested and deployed

together. A single release may include changes to hardware, software, documentation, processes

and other components” (Service Transition, page 325). The basic idea behind release

management is to manage complex or large scale changes in the environment. As an individual

people may not give a second thought to new versions or updates to existing software on their

systems, for instance; however in an enterprise, similar updates need to be tested, verified, and

deployed appropriately to multiple systems. This process is especially important for customized

hardware and applications, but is also necessary to manage any conflicts in configurations:

though in truth, many updates are usually designed to eliminate such conflicts.

In any case, Release and Deployment Management is applied to ensure all aspects of the new

version are considered and to make ready the release package and the environment in which it

will be deployed.


The purpose of Release and Deployment Management is to plan, schedule and control the

build, test and deployment of the release with the intention of introducing new or changed

functionality while maintaining the integrity of the entire service environment.

The objectives of Release and Deployment Management include:

• Define plans for Release and Deployment Management and obtain agreement with

customer and stakeholders.

• Creates and test release packages.

• Store all release packages in the Definitive Media Library and recorded accurately in the

Configuration Management system.

148



• Ensure the integrity of a release package and its components is maintained during Service

Transition.

• Deploy release packages from the definitive media library according to an agreed plan and

schedule.

• Ensure the service provider can track, install, test, verify, and/or install or back out of all

release packages.

• Manage organization and stakeholder change during release and deployment efforts.

• Ensure new and changed services are capable of delivering the agreed utility and warranty.

• Record and manage deviations, risks and issues relevant to the deployment of new or

changed services.

• Take preventive or corrective actions to deviations, risks, and issues when appropriate.

• Ensure the proper skills and knowledge are in place to effectively and efficiently deliver,

support, and maintain services.

10.5.2 Scope

Plan, schedule and control the build, test and deployment of releases: this is the focus of the

Release and Deployment Management process. It is reasonable to assert that a release consists

of one or more changes to a set of service assets and configuration items. Consider a simple

security update to anti-virus software. The direct impact of the update is in the application itself,

but as part of the organization’s security focus, it is important to track which machines have

the update installed. Some basic considerations need to be addressed, such as in distributed

environments, what if the server is updated, but the client is not or vice versa, or what if there

are any conflicts with other updates.

At this point, we are not even speaking about the delivery method for the update, just the

impacted configuration items. When the delivery method is introduced, the considerations to

consider are the level of manual or automation required in the install, and whether the update

needs to be pushed or pulled to some machines. More extensive release packages may need

to consider the organization’s readiness in receiving the update, particularly awareness and

training.

Overall, a single release may be isolated to or impact the following:

• Physical hardware.

• Applications and software.

• Virtual representations of hardware or systems.

• Staff and user awareness and training.

• Service and service agreements.

While Release and Deployment Management is responsible for the build, test and deployment

of releases, it is important to note that this is from a management perspective, not an

operational perspective. Actual testing is performed as part of the Service Validation and Testing

process; Release and Deployment Management will make a request for testing and define

what type and level of testing is required. Additionally, deployment of changes asserts that a

change to the environment will occur; however control of the change is a function of Change

Management, not Release and Deployment Management. The RDM process is not responsible

for authoring changes and it requires authorization from Change Management to proceed

through the various stages of a release.


Why does Release and Deployment Management exist? The primary reason is to optimize the

speed and cost needed to manage different versions of configuration items and to minimize the

risks surrounding these releases. There is a direct correlation that must naturally occur between

the customer’s business and the IT services delivered to the customer. As the customer improves

their business, IT services must also improve. Even without the change to the business, there

is typically an expectation that services will be improved to minimize risks, reduce costs, or

increase value. But improvement is typically iterative, requiring small steps to be taken: for the

customer, it may mean that one location serves as a pilot for one service iteration while the

other locations must wait, or it may be different users can chose the service iteration they most

desire. How many people do you know who still use Windows NT over Windows 8?

150



More important than the fact that multiple versions of the same service may exist in the

service environment is the certainty that new releases of services will become available as

the necessary improvements are applied. As a result, it is beneficial to establish a consistent

approach to implementing new release packages. Improving that consistency will result in

reducing the demand on resources, implementation costs and risks. A consistent approach will

also serve to ensure auditable requirements are met, particularly around traceability.


The initial challenge to understanding Release and Deployment Management is to understand

its terms, particularly release unit and release package. A release unit refers to a service

component which can normally be released as a single entity. Units can be defined by type or

item of service asset or service component and the definition will be formalized as part of the

release policy. One or more release units may be grouped together into a release package.

Considering the release-unit level for each asset or component is essential for managing and

implementing release packages. For instance, specifications can change depending on what

operating system—or version of operating system—is used. Therefore, an application which

is optimized for Windows 8, may not be appropriate for systems for Windows 7 or below. In

this instance, the release-unit level for the application and the operating system must be

compatible; however, the interdependency can extend to the hardware release or other

relevant technology used. For example, some hardware systems would perform poorly if

running Windows 8, therefore a release would have to ask why Windows 8 is not available for

the application and then take corrective actions accordingly.

The most common considerations regarding release units are:

• Ease and amount of change needed to release a release unit.

• Resources and time needed to build, test, distribute, and implement a release unit.

• Interface complexity between the release unit and the remaining service components.

• Available storage in the build, test, distribution, and production environments.

A release package may consist of one or more release units in a structured set. While all release

units may be impacted by a release, not all release units may be changed. In some situations,

release units can be removed from a release package if they cause issues in testing. Each

release package must be designed to meet objectives and preserve the integrity of the service

environment. The design of a release package is reliant on the participating architectures to

determine what changes are needed, where and in what order. For instance, in our previous

Windows application example, the order of the release implementation will typically start with

hardware, then operating system, then the application. If a problem occurs with upgrading the

hardware (such as no funding to replace the system), then the rest of the release will fail.

Another consideration for a release is how it is distributed and deployed. There are three basic

decisions to make for any release:

• Automatic or Manual.

• Push or Pull.

• “Big Bang” or Phased.

152



Automation is a good choice to ensure repeatability and consistency in release and deployment;

however, not every situation allows for total automation. Some installations require hands-on

building and testing of components, particularly if they are hardware-based. Nevertheless, it is

generally a good rule to automate as much as possible throughout the release and deployment

process. Some activities that can incorporate some level of automation include:

• Aiding release planning through automatic discovery.

• Checking for required prerequisites and co-requisites before installing new or changed

software components.

• Automating OS builds and recovery activities which can reduce the time and conflicts

associated with schedules.

• Configuration baselines procedures that capture status of configurations and releases

during the release lifecycle.

• Performing comparisons, such as the “as is” live configuration with the planned “to be”

configuration to identify any potential issues which can result in incidents or deployment

delays.

• Processes to load and update the CMS to ensure records are accurate and complete.

• Updating user and license information in the CMS as part of the installation.

The push and pull deployment options focus on the distribution of the release. Consider

application installs from a network drive: there are two means of handling the install from a user

perspective. When the application is automatically installed to the computer upon connecting

the network (with user permission of course), the application was pushed to the user. However,

when the user must go to a web site or catalog and request the installation to start, the

application is being pulled. As a rule of thumb, most mandatory service components will be

pushed, while optional service components may be best if pulled.

Although application installs are the easiest and most common example of the push/pull

approaches, the concept can be adopted for different types of configuration items. For instance,

technology refreshes can be seen as a push to upgrade hardware systems, while still allowing

individuals to request hardware upgrades between scheduled refreshes (pull).

The “big bang” and phased approaches are typically a consideration against the size and

complexity of the deployment: small and simple deployments are more likely to be done all at

once (big bang) while large and complex deployments may need to be phased over time. The

two approaches can even be used in combination: for instance, a global company with four

distinct regional locations may touch each location individual (phased) but deploy the release

to all personnel within the region simultaneously (big band). Another possibility for the phased

approach is that parts of the service are available to all personnel in increments.

The combination of these approaches can create several interesting variants from which

the organization can distribute and deploy releases. The variants can be expanded when

adding different approaches to building and testing service and component releases. Most

organizations will attempt to identify and leverage just a few possible variants. The advantage

to limiting approaches is it builds familiarity, consistency, and reliability with release and

deployment activities.

When an organization commits to and documents the variant they will be using, they are

creating a release and deployment model. These models are useful when:

• Releasing a new version of an existing application.

• Deploying a new virtual service using a standard configuration.

• Upgrading the operating system to a new version.

• Implementing a security patch.

154



Defining release and deployment models addresses:

• The overall structure for building a release package and the target environments.

• The exit and entry criteria for acceptance across different stages of the release and

deployment lifecycle.

• The establishment of controlled environments to build and test the release at each release

level.

• Roles and responsibilities for each configuration item at each release level

• The configuration baseline model and promotion of the release into the production

environment.

• Template schedules for release and deployment.

• Support systems, tools and procedures for documenting and tracking RDM activities.

• Handover activities and responsibilities.

At the forefront of all these concepts, release units, release packages, deployment options and

release and deployment models, is the establishment of the release policy and other relevant

policies. These policies will define how the organization should relate to these concepts, make

them real, and align them with current business objectives and needs.


There are four phases to the Release and Deployment Management process:

• Planning – this phase begins with authorization from Change Management to plan the

release and ends with authorization from Change Management to create the release.

Planning involves the design of the release, the level of testing required, and the

deployment approach to be taken.

• Build and Test – once authorization for the release to be created is given, this phase

will continue until authorization from Change Management allows the baseline release

packaged to be deployed and information sent through Service Asset and Configuration

Management. The focus of this phase is to build, test, and check the release package into

the definitive media library.

• Deployment – once the release package is in the DML, it can be deployed within the

production environment. Deployment continues until all parts of the release can be handed

over to Service Operations.

• Review and Close – this is a “lesson learned” or feedback part of the process to review

targets, achievements, and potential future improvements to Release and Deployment

Management.


Release and Deployment Management will be triggered by the following events:

• Authorized changes to plan, build, test, and deploy.

The inputs and outputs of Release and Deployment Management are summarized in the

following table:

Inputs OutputsAuthorized changes New, changed, or retired servicesService Design package, including service

charter, service models and service

acceptance criteria

Release and deployment plan

IT service continuity plan and related plans Updates to Change ManagementService Management and operational plans

and standards

Service notification

Technology and procurement standards and

catalogues

Service catalog updates

Existing service assets, configuration items

and their documentation

New tested service capability and

environmentBuild models and plans New or changed Service Management

documentationEnvironment requirements and

specifications

SLAs, underpinning OLAs, and contracts

156



Inputs OutputsRelease policy and release design from

Service Design

Tested continuity plans

Release and deployment models including

template plans

Complete and accurate information about

configuration items within the release

packageExit and entry criteria for each RDM stage Updated service capacity plan

Baseline release package checked into DMLService Transition report

Release and Deployment Management will require the following interfaces with other Service

Management processes:

• Design Coordination – the Service Design package will be a major input into the release

and deployment plans which will require consultation with the Release and Deployment

Management process. In practice, the effort to produce the Service Design package and the

release package will likely overlap; though acceptance of the release package can only occur

after the acceptance and verification of alignment with the Service Design package.

• Transition planning and support – provides the framework for operating Release and

Deployment Management, as well as context through accepted transition plans.

• Change Management – tightly integrated to ensure work throughout the Release and

Deployment Management is authorized and changes are implemented effectively. Release

and deployment plans will be integrated with the change schedule.

• Service Asset and Configuration Management – provides accurate and complete

information regarding existing configuration items and receives updated information as

part of the release and deployment activities.

• Service Validation and testing – performs the testing required and requests by Release and

Deployment Management.


The following critical success factors and key performance indicators are samples related to Release

and Deployment Management. Each critical success factor has at least one key performance

indicators, which is used to demonstrate achievement of the CSF.

• Defining release plans and obtaining agreement with customer and stakeholders:

Ř Number and percentage of releases utilizing a common framework of standards, re-

usable processes and supporting documentation is increasing.

Ř Number and percentage of releases meeting the cost, time, and quality expectations of

the customer are increasing.

• The integrity of release packages and supporting components is ensured throughout

Service Transition:

Ř Number of audit failures within the CMS and DML due to release is decreasing.

Ř Number of deployments from sources other than the DML is decreasing.

Ř Number of incidents due to deployment of incorrect components is decreasing.

• New or changed services are capable of delivering the agreed utility and warranty:

Ř Variance in service performance required by the customer is decreasing.

Ř Number of incidents against the service is decreasing or low.

Ř Customer and user satisfaction with service delivery is increasing.

Ř Service issues related to poorly tested or untested services is decreasing.

Ř Resources and costs required for diagnosing and fixing incidents and problems in

deployment and live use is decreasing.

• Knowledge transfer is appropriate:

Ř Number of incidents categorized as “user knowledge” is decreasing.

Ř Percentage increase of incidents solved at service desk over level 2 or 3 support.

Ř Increased satisfaction as demonstrated through customer, user, and Service Operation

function surveys.

158




The challenges related to Release and Deployment Management includes:

• Establishing standard performance measures and measurement methods across release and

deployment projects and suppliers.

• Inaccurate estimated delivery data and Service Transition delays due to project and supplier

issues.

• Different stakeholder perspectives that underpin effective risk management for change

assessments and testing.

• A thorough understanding of risk impacting or will be impacting the successful Service

Transition of services and releases.

• Encouraging a risk management culture where knowledge is shared and risk is measured

appropriately.

The risks related to Release and Deployment Management includes:

• Poorly defined scope and dependencies in proposed releases which can lead to scope

creep.

• Using personnel not dedicated to Release and Deployment Management.

• Not using Release and Deployment Management to retire services.

• Lack of funding, project delays into the next fiscal cycle, and lack of clarity regarding funding

for changes or fixes during transition.

• Inadequate corporate policies, lack of definition in required controls, difficulty tracking and

managing software licenses, or unexpected changes in regulatory or licensing requirements.

• Lack of or ineffective management for organizational and stakeholder change.

• Poor commitment or decision making.

• Authorization not obtained in a timely manner.

• Indecision or late decision-making.

• Lack of operational support.

• Compromise of health and safety.

• Time allocation to release and deployment activities.

• Lack of or ineffective relationships with suppliers and partners.

• Inadequate “back-out” or contingency planning.

• Application and technical infrastructure risks including:

Ř Poor design of service.

Ř Professional negligence.

Ř Human error or incompetence.

Ř Infrastructure failure.

Ř Differences and dependencies in infrastructure and/or applications.

Ř Increased cost to decommission or dismantle existing services or service components.

Ř Compromise of safety protocols.

Ř Performance failure.

Ř Breaches in security.

Ř Unforeseen barriers and constraints.

10.5.9 Summary for Release and Deployment Management

The state of ContXT’s IT support is a dismay, given that it has operated without any formal Service

Management in place. All the services developed in the service pipeline will eventually be managed

into deployment by Release and Deployment Management. Unfortunately, the effort may be

stifled and at risk with the relative immaturity of the process, as well as the processes for Change

Management and Service Asset and Configuration Management. However, the issues can be

mitigated effectively if considerable care is given in understanding and complying with the process’

purpose, “to plan, schedule and control the build, test and deployment of releases.”

A convenient way to adhere to the process’ purpose is to create a matrix:

Plan Schedule ControlBuildTestDeploy

160



For each service release, identify the inputs, estimated resources required, dependencies,

constraints, outputs, and measures, for each of the phases of the process (build, test, deploy).

Scheduling should be coordinated with Change Management and each phase should end with

authorization to move to the next phase by an established change authority. Control can be

developed in cooperation with Service Asset and Configuration Management to determine

what control points are necessary and what measurements, methods, and metrics to undertake.

It is best that this matrix approach, or any other approach for release and deployment planning,

is initiated early, preferably when creating the Service Design package: which will provide

much of the information needed to understand the release and deployment requirements

for each service. Since the process concepts are assumedly new to the ContXT IT department,

it would be justifiable to dig deeper into each intersects in the matrix (i.e. Plan/Build, Plan/

Text, Schedule/Deploy, Control/Test, etc.) to fully understand and develop an effective release

policy. Each service will test this understanding and expand the department’s knowledge; and

the post-implementation review should address whether the service release adhered to the

understanding of each intersect and where improvements should be made.


1. What is a release as it relates to ITSM?

a. The availability of a service for general consumption

b. One or more changes to a service that are built, tested and deployed together

c. The delivery of a final service solution to the customer

d. The transition of a service from conceptual to operation

2. What is a release unit?

a. An instance of a release existing in the environment, i.e., application install

b. A set of configuration items built, tested and deployed as a single entity

c. A portion of a service normally released as a single entity

d. A component required to successfully release a service

3. Which of the following does not accurately describe a release package?

a. A set of configuration items built, tested and deployed as a single entity

b. A compilation of release units used to create a larger solution for a release

c. Service components released together to meet a specific objective

d. The availability of utility and warranty desired by the customer

4. Which of the following deployment options is also known as parallel deployment?

a. Big Bang

b. Phased approach

c. Push

d. Pull

162



5. Application catalogs, such as the App Store for Android and Apple devices, are examples of

what type of deployment option?

a. Phased

b. Push

c. Pull

d. Automated

6. In which phase of Release and Deployment Management is a change authorization not

required?

a. Release and deployment planning

b. Release build and testing

c. Deployment of release

d. Review and close of release effort

7. What is the trigger for the Release and Deployment Management process?

a. Service request

b. Authorized change

c. Request for change

d. New service requirement

8. Which of the following is an input to Release and Deployment Management?

a. Service Design Package

b. Service Level Agreement

c. Service Transition Report

d. Release and Deployment Plan

9. Which of the following key performance indicators does not effectively demonstrate the

integrity of a release package being maintained throughout Service Transition?

a. Reduced number of CMS and DML audit failures due to releases

b. Reduced number of deployments from sources other than the DML

c. Reduced dissatisfaction of customers and users for releases

d. Reduced number of incidents due to deployment of incorrect components

10. What is Release and Deployment Management expected to generate in cooperation with

problem management?

a. Work instructions

b. Known errors

c. Improvements

d. Impact assessment

164



10.6 Service Validation and Testing

Service Validation and Testing has a primary responsibility over the test environment for IT.

It can be engaged by any Service Management process that requires any form of testing,

but the majority requests will come from Change Management or Release and Deployment

Management. From a Service Transition perspective, service validation and testing is an

essential component of ensuring that the service is built according to design and is capable of

meeting the business needs required of the service. However, testing can also be performed

as part of Service Operations, as data from the production environment is reviewed for various

reasons like compliance, performance reviews, etc. The driving factor for all service validation

and testing activities is quality assurance, before and after deployment into the production

environment.

Without sufficient testing, services introduced to a production environment may have one or

more of the following characteristics:

• Increased number of incidents due to component failure and differences between what is

wanted and what is being delivered by the service.

• Influx of user questions and issues, if the service is not intuitive or functionality is not

available as expected.

• Problems and errors are harder to diagnose, leading to longer resolution times.

• Increase costs due to resolving incidents and problems in the production environment.

• Users are not using the service as effectively, and the desired value for the service is not

being achieved.


The purpose of Service Validation and Testing is two-fold, but relatable:

• Ensure that the new or change service matches its design specifications.

• Ensure that the new or change service meets the needs of the business.

It’s important to note that these objectives are distinct but interrelated. A service is designed to

meet the business needs. After transition, the desire is to have the service match its design and

meet the business needs. If during testing, the design is matched but the needs are not, testing

has discovered a problem with Service Design. If business needs are met, but the design does

not match, the problem is with Service Transition (but may eventually fall into Service Design).

In the unlikely chance that neither the design matches nor business needs are met, the likely

problem is in the requirements generated during Service Strategy. Therefore, Service Validation

and Testing can provide an effective control for determining the effectiveness of the service

lifecycle stages.

The objectives of Service Validation and Testing include:

• Build confidence that a service release will introduce a new or changed service that delivers

the expected outcomes and value for the customer as designed.

• Perform a quality assurance check on a release, its supporting service components and the

resultant service capabilities.

• Validate the services functionality (fit for purpose or utility).

• Provide assurance of a service’s warranty (fit for use).

• Confirm service requirements from customers and stakeholders are correctly defined and

make any corrections.

• Plan and implement a structured validation and testing process.

• Identify, assess and address issues, errors, and risks throughout Service Transition.

166



10.6.2 Scope

As mentioned before, service validation and testing offers quality assurance to the service

provider’s ability to deliver service resources and capabilities for the purpose of meeting

business needs. The scope of service validation and testing is essentially directly tied to the

services being offered by the service provider, but specifically in assurance the service provider’s

capability to deliver, operate and/or maintain customer and service assets at agreed levels

of warranty. When third-party partners and suppliers are involved in the end-to-end service,

testing of requisite interfaces is also necessary.

Testing can be applied equally to any service, service component, or process activity. Testing is

a means to assure the service or its components behave as expected. Different levels of testing

can be applied to obtain more detail about service performance and behavior and reaching

the right balance in testing is necessary to confirm quality assurance without being expensive,

time-consuming, or losing value.


Service delivery and support is only effective and valuable if the services are available, reliable,

and protected. Service failures can have profound effects on the service provider and the

customer: when these failures occur within the production environment, the effects can be

even more pronounced.

Testing provides an opportunity to discover potential points of failure or areas of concern

proactively. If performed effectively in Service Transition, before the service is deployed in the

production environment, these failures will have minimal impact to both the service provider

and the business and allows the problems to be resolved.


A service validation and testing policy will typically address:

• All tests must be designed and executed by persons not involved in the design or

development of the service being tested.

• Criteria for test pass/fail must be documented in the Service Design package before starting

any testing.

• Every test environment must be restored to a known state before starting any testing.

• A test library shall be established and contain re-usable test models, test cases, test scripts

and test data.

• Testing shall be integrated into the project and service lifecycle to aid in detecting and

removing function and non-functional defects and reduce incidents in the production

environment.

• A risk-based testing approach shall be adopted to reduce risk to the service and the

customer’s business.

• Throughout the project and service lifecycle, customers, stakeholders, users and service

teams will be engaged to enhance testing skills and obtain feedback on quality of services

and service assets.

• Test measurements and monitoring systems shall be established to improve the efficiency

and effectiveness of service validation and testing.

• Automated testing tools and systems should be used when complex systems and services

are involved.

• Time to change is critical.

Other policies that can impact the execution of service validation and testing are:

• Service quality policy.

• Rick policy.

• Service Transition policy.

• Release policy.

• Change Management policy.

168



The primary input into service validation and testing is the service charter, which details the

agreed utility and warranty for the service in terms of outcomes, assets and patterns of business

activity. The service charter will be included in the Service Design package which defines

the service. The service definition will provide the context of how the service is used and the

attributes related to the form and function of the service. In addition, the SDP will define the

agreed requirements of the service, as expressed though the service model which describes

the structure and dynamics of the service. Another topic provided through the Service Design

package is the constraints on the service: which can be used to validate and test the boundaries

of the service.

Service Validation and Testing will be asked to touch upon all these service characteristics to

some level. As the organization matures their production and delivery of the service charter,

Service Design package and the service model, the effectiveness of service validation and

testing will improve.

Testing the service and service components is a means of observing or review the service

against a standard or specification. The aforementioned documents provide the basic

description of the appropriate standard or specification to be used in testing. Testing is used as

a means of validation: a set of activities performed to ensure or build confidence that a service

or system will accomplish its intended use, goals and objectives. Validation appropriately occurs

throughout the service lifecycle: for instance, the production of the Service Design package

may include a validation step to ensure the design specifications can be mapped directly to

intended business objectives.

Validation does not require formal testing; however testing provides an opportunity to validate

in operational terms. Consider the design and testing of machines (cars, appliances, game

consoles, etc.). A machine has a specific purpose to achieve and its design should be produced

to ensure this purpose can be achieved; therefore, a car’s engine should be able to accelerate

to 60 mph in 6 seconds, or a computer’s GPU should be able to handle 60 frames per second,

or a refrigerator’s water dispenser should be able to reach a minimal 5 degrees temperature. A

Service Design package may verify the capabilities needed to meet these objectives are present

‘on paper’ and the SDP should be reviewed to validate. However until a ‘prototype’ build can

be tested in action, there will always be some doubt about the true capabilities of the product.

Testing is a “hands on” validation of the service capabilities against its objectives.

The effectiveness of testing will depend on the organization’s testing strategy or approach

to organizing tests and allocating testing resources. The scope of individual tests can involve

the entire organization, a set of services or functions, or a single service or process. Service

validation and testing should be engaged early and well before any actual testing occurs to

allow for sufficient planning. Its primary interfaces are with design coordination, Release and

Deployment Management, and change evaluation. Planning activities will typically involve:

• Translating service requirements and Service Design into test requirements and test models.

• Leveraging the risk profile, change impact assessments, and resource assessments to

determine the best approach to optimize coverage of the test.

• Translating service acceptance criteria into entry and exit criteria for each level of testing.

• Translating risks and issues into test requirements.

Because Service Transition is usually project-based, the process manager for service validation

and testing should work with project managers to:

• Ensure appropriate test activities and resources are included in the project plans.

• Specialist testing resources are allocated, when needed.

• Mandatory and optional testing deliverables are understood by everyone on the project.

• Testing activities are managed, monitored, and controlled.

170



The test strategy and plans should define:

• Policies, processes and practices relevant to effective testing in the organization.

• Purpose and objectives of testing.

• Context for performing testing, such as required to validate Service Design and/or required

to obtain conformance to regulatory standard.

• Applicable requirements from standards, legislation, or regulations.

• Applicable contracts and agreements, including Service Management policies, processes

and standards.

• Scope and participation from organizations (service provider teams, test organization, third

parties, business units, customers and users.

• Test process.

• Test metrics and improvement.

• Identifying items to be tested, specifically, service charter, SDP, and service models.

• Service Operation test plan.

• Service Management test plan.

• Service provider interface.

• General approach to testing.

• Appropriate criteria.

• Roles, responsibilities and authority.

• Environment requirements.

• Test deliverables.

Test models can be created to drive consistency, repeatability, and reliability in testing. They

include a test plan to define what to do, as well as information about what to test and test

scripts, which define the conditions of the test, expected results and test cycles. Test models

need to be structured to:

• Provide traceability to requirement or design criteria.

• Enable auditability.

• Ensure the maintenance of test elements.

Common test models include:

• Service contract – verifies the service can deliver the proposed value to the customer.

• Service requirements – verifies the service provider can deliver the service as required.

• Service level – verifies the service can be delivered at the agreed service levels.

• Service - verifies the capabilities of the service provider to deliver, operate a new or changed

service as designed.

• Operations – verifies the functions of Service Operation can operate and support the new or

changed service or service component.

• Release deployment – verifies the personnel, tools and procedures are sufficient to deploy

the release package into the target production environment on schedule.

• Deployment installation – verifies the personnel, tools, and procedures can install the

release package into the target production environment on schedule.

• Deployment verification – verifies that the deployment was completed successfully.

The challenge in testing is related to ensuring that a service will deliver what is required, which

is largely subjective to those who use, deliver, deploy, manage, and operate the service: the

technician may perceive the service one way while the user another. Testing service acceptance

is based on agreement over the service requirements and then the service acceptance criteria,

where agreement is obtained from various stakeholders, including customers, users, supplies,

and the service provider.

172



Testing should cover all aspects of the service including:

• Service Design – functional.

• Service Design – management.

• Service Design – operational.

• Technology design.

• Process design.

• Measurement design.

• Documentation.

• Skills, knowledge and competency.

These perspectives can lead to different levels of testing and test models used which are

defined as part of Release and Deployment Management. In addition, different approaches and

techniques in testing can be used, including:

• Document reviews.

• Modeling and measuring.

• Risk-based approach.

• Standards compliance.

• Experience-based approach.

• Software development approach.

• Simulations.

• Scenario testing.

• Role playing.

• Prototyping.

• Regression testing.

• Laboratory testing

• Walkthroughs or workshops.

• Dress or service rehearsals.

• Conference room pilots.

• Live pilot.

Even with these variations, different types of tests and levels can be performed, including:

• Usability testing.

• Accessibility testing.

• Process and procedure testing.

• Knowledge transfer and competency testing.

• Performance, capacity and resilience testing.

• Volume, stress, load and scalability testing.

• Availability and failover testing.

• Backup and recovery testing.

• Compatibility testing.

• Documentation testing.

• Regulatory and compliance testing.

• Security testing.

• Logistics, deployability, and migration testing.

• Coexistence and capability testing.

• Remediation, continuity and recovery testing.

• Configuration, build and installation testing.

• Service measurements and reporting testing.

• Operability and maintainability testing.

Service test models, test cases and test scripts are items to be designed and build. The general

design considerations regarding testing involve:

• Financial – the money available to fund testing.

• Documentation – service documentation is available and easy to use.

• Suppliers – determining the performance of internal and external interfaces.

• Service Build – determines whether the service, service assets or components can be built

into a release package and test environments.

• Testable – determines if the service or service components can be tested using the

resources, time and facilities available.

• Traceability – determines with requirements can be traced back to objectives.

174



• Schedule and location – when and where a test should be performed.

• Remediation – testing if the backout and recovery plans for a release or change is viable.

The detailed considerations for service testing design include:

• Organization:

Ř Ensuring alignment with business services, processes and procedures.

Ř Business dependencies, priorities, criticality, and impact.

Ř Business cycles and seasonal variations.

Ř Levels of business transactions.

Ř Numbers and types of users.

Ř Anticipated user growth.

Ř New facilities and functionality.

Ř Business scenarios.

Ř Segregation of duties.

• Service architecture and performance:

Ř Service portfolio.

Ř Different types of service assets, utility, and warranty.

Ř Service level requirements and targets.

Ř Levels of service transactions.

Ř Constraints.

Ř Predictions on volume and performance.

Ř Monitoring, modeling and measurement.

• Service release test environment requirements.

• Service Management:

Ř Service Management models.

Ř Service Operation model.

Ř Service support model.

Ř Service Management information.

Ř Volumes of service users and service transactions.

• Application information and data:

Ř Interactivity with information databases and technical information.

Ř Functionality testing.

Ř Access rights.

• Technical infrastructure:

Ř Physical asset specifications.

Ř Technical resource capacity.

Ř Definitive spares.

For Service Management, there are a few general categories for testing, including:

• Service level testing – validates the service provider can deliver services against agreed

service level requirements and targets.

• Fit for use testing – a series of individual tests designed to test the availability, capacity,

continuity or security of a service.

• Usability testing – tests the service from the perspective of the users and/or maintainers of

the service, and may be important to determine special classes of users such as disabled or

second language users.

• Contract and regulation testing – validates the service provider can deliver services against

external contractual, legal, regulatory or statutory requirements.

• Compliance testing - validates the service provider can deliver services against internal

regulations, commitments or governance.

• Service Management testing – ensures the integration of Service Management processes.

• Operational testing – a series of tests to establish and retain the operational capabilities of

the service and service components, specifically focusing on load and stress tests, security

tests, and recoverability.

• Regression testing – a method of repeating a test already run and comparing the results to

identify any issues or trends.

176




The activities of Service Validation and Testing provide both an overall management of

the process in the organization and individual testing opportunities. Validation and test

management can typically be associated with managing the “test environment” and how

the organization relates to validation and testing activities. This overall management activity

addresses:

• Resource management for tests.

• Prioritizing and scheduling tests (what and when).

• Processing incoming known errors and their documentation.

• Monitoring progress on tests and collating feedback.

• Managing incidents, problems, errors, non-conformance, risks and issues discovered during

transition.

• Reducing errors going into production.

• Capturing configuration baseline(s).

• Testing collection, analysis, reporting and management, or metrics.

When focusing on individual testing opportunities, the process activities include:

• Planning and designing tests.

• Verifying test plans and test design.

• Preparing the test environment.

• Performing tests:

Ř Preparing test model.

Ř Performing tests and recording results.

Ř Resolving any incidents or issues and mitigating risks, if any.

Ř Repeating tests if necessary.

• Evaluating exit criteria and reporting..

• Clean-up and close testing.


Service Validation and Testing will be triggered when a scheduled activity on a release plan, test

plan, or quality assurance plan is reached.

The inputs and outputs of Service Validation and Testing are summarized in the following table:

Inputs OutputsService Design Package Report to change evaluation, with:

• Configuration baseline

• Description of testing

• Test results

• Analysis of resultsService Charter Updated data, information and knowledge

to SKMSService provider interface definitions Test incidents, problems and error recordsOperation models Potential improvements recorded in CSI

RegisterCapacity model and plans Information on third-party relationshipsFinancial or cost modelsService Management modelTest conditions and expected resultsDesign and interface specificationsRelease and deployment plansAcceptance criteria

178



Service validation and testing will interface with the following processes:

• Release and Deployment Management – submits requests for testing.

• Change Evaluation – obtains reports on test results.

• Service Design Coordination – ensures designs can be tested.

• Continual Service Improvement – obtains failure information and improvement ideas from

testing.

• Service Operation – uses maintenance tests to ensure continued efficiency of services.

• Service Strategy – supports testing with proper funding, resources, information, etc.


The following critical success factors and key performance indicators are samples related to Service Validation and Testing. Each critical success factor has at least one key performance indicator which is used to demonstrate achievement of the CSF.

• Understand stakeholder perspectives that underpin effective risk management for change

impact assessment and test activities:

Ř Document and agree upon the roles and responsibilities for impact assessments and

testing.

Ř Number of new or changed services where roles and responsibilities are clearly and

completely documented and agreed is increasing.

Ř Percentage increase of impact assessments and test activities where documented roles

are participating as expected stakeholder satisfaction of service validation and testing

process is increasing.

• Understanding the risks that have impacted or will impact successful Service Transitions of

services and releases:

Ř Impact of incidents and errors of newly transitioned services is decreasing.

Ř Number of risk identified in Service Design or early Service Transition is increasing

compared to those errors found during or after testing.

Ř Ratio of errors detected in Service Design compared to Service Transition is increasing.

Ř Ratio of errors detected in Service Design compared to Service Operation is increasing.

• A risk management culture is promoted where people share information and takes a

pragmatic and measured approach to risk:

Ř Number of people who identify risks for new or changed services is increasing.

Ř Number of documented risks for each new or changed service is increasing.

Ř Percentage increase in the number of risks managed within the risk register.

• Evidence is available to demonstrate service assets and configurations are built and

implemented correctly and delivering to the needs of the customer:

Ř Percentage increase in the number of new and changed services tested using service

acceptance criteria.

Ř Percentage increase of service build and implementations have been tested, separate

from individual utility and warranty tests.

• Re-usable test models are beign developed:

Ř Number of tests in a repository for re-use is increasing.

Ř Number of times a test is re-used is increasing.

• A balance between cost of testing and effectiveness of testing is achieved:

Ř Variance between test budget and test expenditure is decreasing.

Ř Cost of fixing errors, due to earlier detection is decreasing.

Ř Business impact due to delays in testing is decreasing.

Ř Variance between planned and actual cost of customer and user time to support testing

is decreasing.


The greatest challenge to Service Validation and Testing is the lack of respect or understanding

for testing as a vital component of ensuring the effectiveness and efficiency of service delivery

and support. This often leads to a lack of or insufficient funding and results in:

• Inability to maintain a test environment.

• Inability to test data matching the production environment.

• Insufficient staff, skills and testing tools to deliver adequate coverage for testing.

• Project overruns and rushed testing windows to preserve project go-live days.

• Lack of standard performance measures and measurement methods across projects and

suppliers.

• Delivery dates estimated incorrectly, resulting in transition delays.

180



The risks associated with service validation and testing are:

• Unclear objectives and/or expectations.

• Lack of understanding of the risks of not testing at the right time or right scope.

• Resource shortages.


For some of the services being formalized for ContXT, such as video- and tele-conferencing, the

service is simply documented completely and expanded. As a result, it may seem that testing

requirements may be minimal. While this may be true, it should not be assumed: for one, the

expansion of the service may require addition configurations when integrated with the overall

production environment and it would be necessary to test the demand on resources expected.

In addition, the formalizing of the service may arise a new design configuration and processes

to use in accessing these services, especially related to scheduling.

For completely new services, such as the project management system, testing will ensure the

desired quality of the system across several groups of stakeholders, including employees and

clients. Because of the relative immaturity of the IT department, it would be best to address

testing considerations early in the strategy stage and continue addressing testing concerns as

they come up, especially:

• What needs to be tested?

• How should it be tested?

• What do we want to see in the results?

• What are the checkpoints of the Service Design and development process that warrant

validation and testing?

• What is acceptable to move forward?

Where ContXT is at a disadvantage is the number of people currently comprising the IT

department. These three people should not be part of the actual testing. Ideally, the company

will want to hire a dedicated person to be responsible for testing or to utilize a third-party to

perform any testing. If the service will be delivered by a third-party supplier, sufficient language

should be part of the contract or service level agreements to ensure that not only is testing of

the service performed and results delivered to the customer, but that the customer and/or users

will be actively involved in the testing of service utility and warranty.

182




1. What is the underlying concept of service validation and testing?

a. Business alignment

b. Quality assurance

c. Service support

d. Design compliance

2. Which of the following is not a result of effective testing?

a. Reduced costs of operation

b. Fewer service desk calls

c. Easier diagnostic of problems

d. Increased number of incidents

3. Which of the following is not a policy typically associated with service validation and

testing?

a. All tests must be designed and conducted by people who are not involved in the

design or development activities of the service

b. Test pass/fail criteria must be documented in a Service Design package before the

start of any testing

c. Establish measurements and monitoring systems to improve the efficiency and

effectiveness of service delivery

d. Adopt a risk-based testing approach aimed at reducing risk to the service and the

customer’s business.

4. Which of the following is not an input to service validation and testing from Service Design?

a. Change schedule

b. Service charter

c. Service model

d. Service constraints

5. Which of the following statements does not relate to validation activities?

a. Validation confirms, though objective evident, that requirements for a specific

intended use have been fulfilled

b. Validation is a set of activities ensuring and gaining confidence that a service is able

to accomplish its intended use

c. Validation of service requirements requires agreement from the customer about

definitions

d. The validation of service requirements and related service acceptance criteria begins

from the time service requirements are defined

6. Which of the following is a valid component of the test approach to be defined in an

organization’s test strategy and plan?

a. Test management and control

b. Service Operation test plan

c. Entry and exit criteria for each test stage

d. Selecting a test model

7. What aspect of designing service tests ensures that test results can be linked back to

requirements?

a. Traceability

b. Documentation

c. Testability

d. Remediation

8. Fit for use testing is another name for what type of test?

a. Service level test

b. Assurance test

c. Usability test

d. Operational test

184



9. What is the trigger for testing?

a. Request for change

b. Authorized change

c. Request for testing

d. Service Design package

10. What Service Management process relies heavily on the output of service validation and

testing?

a. Change Management

b. Release and Deployment Management

c. Change Evaluation

d. Service Asset and Configuration Management

10.7 Change Evaluation

The management of changes is a vital component of ensuring the integrity and control over

the production IT environment; however, the essence of the change process is inevitably a go/

no-go decision to implement the change. The Change Management process is responsible for

activities before and after this decision; however, the activities required to make an effective

decision can be seen as having greater criticality than any other moment in the change process.

When just dealing with requests for change, the ITIL process flow can be characterized as:

1. Request for change submitted, reviewed and authorized for pursuit.

2. Change plan established and approved.

3. Alignment with service and business objectives validated.

4. Service and service components to be changed are built and tested.

5. Impact and risks on production environment identified.

6. Test results, impact assessment and risk profile evaluated.

7. Change accepted or rejected based on evaluation

8. Change implemented.

9. Post-implementation review.

Steps 3–5 above are supported by the Service Validated and Testing Process, while step 6 is the

focus of the Change Evaluation process. The separation of this step from the overall change,

or release and deployment process, demonstrates the importance of the evaluating changes

before implementation from an ITIL perspective.

Where service validation and testing can be seen as a quality assurance process, change

evaluation is more of a value assurance process: the concern is to ensure a change to the

environment has “value.”

186




The purpose of change evaluation is to provide a means which is consistent and standardized

for determining the service change’s performance with regards to achieving business outcomes

and interacting with the existing services and infrastructure. It must be clear that the process

focuses on the performance of the change rather than the general concern of the service’s

performance: in other words, the change evaluation process answers the question, “will the

benefits of this change outweigh the potential costs and risks associated with making the

change?”

The objectives of change evaluation are:

• Set expectations for stakeholders correctly.

• Provide effective and accurate information to Change Management.

• Evaluate the intended effects of a service change.

• Evaluate the unintended effects of a service changes which can be reasonably done given

constraints on capacity, resources and the organization.

• Ensure changes that adversely affect service capability and introduce additional risks are not

transitioned unchecked.

• Provide information of good quality to support effective decision-making in Change

Management.

10.7.2 Scope

Every change to the environment must be authorized by an appropriate change authority. In

most cases, authorization has to be provided at multiple points in the service lifecycle. Change

evaluation is focused on ensuring these decisions are well-informed and made within the

proper context. For example, it can be easy to make a decision to buy an application for use in

the office without considering the ramifications of not going through proper channels. Change

evaluation enables the consequences surrounding these decisions for change are properly

understood. With regard to the application decision, some downloadable and generic software

will have hidden bits of code which provide back doors to potential hackers and are therefore,

security risks.

The change evaluation is initiated for every formal request for change received by the Change

Management process. Its responsibility continues until the change is finally authorized.


Effective change evaluation ensures that each change made to the environment is beneficial

to the value proposition to the business, meets governing standards and regulations, and

efficiently uses resources. In addition, the data obtained through change evaluation provides a

deeper understanding of where the organization and its services can improve.


Change evaluation must comply with several policies, including:

• Service Designs or changes must be evaluated before transitioned into a production

environment.

• Every change must be evaluated, but only significant changes may require a formal change

evaluation process; therefore criteria must be established to determine which changes are

in the scope of the change evaluation process.

• Risks and issues related to the service being changed will be identified through the change

evaluation process, as well as other services or shared infrastructure.

• Any deviation between the actual and predicted performance will be managed by the

customer, or designated representative, by accepting, rejecting, or requiring the change to

be implemented with a revised performance agreement.

188



While performing change evaluation activities, the following principles may apply:

• Intended and unintended, if reasonably practical, the effects of a change must be identified

and consequences understood and addressed.

• Evaluations of service changes must be fair, consistent, open and objective.

• Change Management will receive an evaluation report, or interim report, to support

decisions at each point of the service lifecycle where authorization is required.


The activities of change evaluation include:

• Plan the evaluation.

• Evaluate predicted performance and report results.

• Evaluate actual performance and report results.

• Wait for the next change authorization point.

• Provide a final evaluation report when change lifecycle ends.

10.7.6 Triggers, Inputs and Outputs

Change Evaluation will be triggered by a request for evaluation from the Change Management

process

The inputs and outputs of Change Evaluation are summarized in the following table:

Inputs OutputsService Design package Interim evaluation reports(s)Change proposal Final evaluation report Request for change, change records and

detailed documentation regarding the

changeDiscussions with stakeholders

Test results and reports

Change Evaluation is effective with a single interface to the Change Management process.

Change Management will be responsible for feeding change evaluations the information

required to effectively analyze a change. The results of the evaluation will be sent to Change

Management at different authorization points in the process.

In practice, the information required by the change evaluation process may come directly

from the process producing the information: i.e. the Service Design package from design

coordination or test results from service validation and testing. This is especially true when

the information is posted to an accessible database to be pulled from appropriate personnel,

including evaluators. Despite the number of shortcuts available through effective use of

technology, it must be enforced that Change Management is the appropriate interface should

any issues arise with or during change evaluations.

190





Service Validation and Testing. Each critical success factor has at least one key performance

indicator that is used to demonstrate achievement of the CSF.

• A good understanding of new or change service’s expected performance is possessed by all

stakeholders:

Ř The number of incidents for new or changed services due to failure to deliver expected

utility and warranty is decreasing.

Ř Stakeholder satisfaction with new or changed services is increasing as demonstrated

through customer surveys.

• Good quality evaluations enable Change Management to make correct decisions

Ř Percentage increase in the number of evaluations delivered within agreed times.

Ř The number of changes that invoke remediation plans due to unexpected errors or

failures is decreasing.

Ř The number of failed changes is decreasing.

Ř Satisfaction with the change evaluation process by Change Management personnel is

increasing.


The challenges with change evaluation are:

• The development of standard performance measures and measurement methods across

projects and suppliers.

• Different stakeholder perspectives that underpin effective risk management for change

evaluation.

• Being able to assess the balance between managing and taking risks which affects the

overall strategy of the organization and service delivery and support.

• Less variation being measured and demonstrated related to predictions during and after

transition.

• A pragmatic and measured approach to risk being adopted.

• Effectively communicating the organization’s attitude to risk and approach to risk

management in evaluation reports.

• Developing a solid understanding of the risk that have and will have an impact on Service

Transitions.

• Encouraging people the share information regarding potential risks.

The risks associated with change evaluation include:

• Lack of clear criteria for when change evaluation should be engaged formally

• Unrealistic time frames to complete change evaluations.

• Personnel performing change evaluations have insufficient experience or organizational

authority to influence decisions

• Incorrect estimates in project of supplier delivery dates which cause delays in scheduling

change evaluation.


Frankly, the current IT environment for ContXT is at a disadvantage, given the number of

personnel, lack of formality, and immaturity in service delivery and support. While it is likely

that the company will realize that adopting a Service Management approach to IT will require

beefing up its staff and that priorities have to be considered at every step, there is just as likely

a lack of familiarity required from both the business and additional staff member. Simply put,

business professionals may not be technically savvy to make uninformed decisions about

IT, and technical managers may not have the appropriate knowledge to ensure that value is

delivered to the customer for every service decision.

Fortunately, change evaluation can force both business and IT personnel to be on the same

page and collaborate in all decisions regarding services. Of course, this requires Change

Management to be fully implemented and enforced. The benefits of change evaluation

should be easily dismissed for ContXT. At each point of the service lifecycle where change

will be introduced, change evaluation has an opportunity to inform the decision to authority

192



the change: sufficient business information can be provided to IT managers to enable their

understanding of how the service and respective change will benefit the customer and meet

their needs and IT information can be provided to business management to enable their

understanding of how the service and change will be delivered and supported.

Why is this so important for ContXT? In simple terms, the company and the IT department have

not had the opportunity to make these decisions before, at least not to this degree. For the

business, IT support has been a cursory means of supporting an end: much like a regular person

will open an application without a clear understanding of its basic structure and programming.

For many users, this level of transparency is satisfactory as long as the application continues

working as expected; but once it breaks, users tend to want answers, even when they don’t

understand it. For the technical staff, this desire for transparency allows a level of autonomy to

get the job done quickly and doing whatever it takes; but it also breeds a cultural environment

of reaction and “putting out fires” over innovation and improvement. Decisions for both parties

are typically done within the context of confusion or survival, which does not bode well for

improving the overall maturity and capability of the services.

In this whirlwind of activity, change evaluation provides an opportunity for every stakeholder to

check for themselves if the service is what they want or need. The reason the focus is on change

is because these decisions do not need to be made on the status quo, as most organizations

learn to deal with and expect “business as usual” operations. It is only when an objective is

created which will change the status quo that more attention is required. At this point, the

decision is whether the change will enable the organization to achieve the objective or not. If

not, the change should be rejected. If the objective can be met, the change should be approved.

And if the objective is partially achieved, either the organization must return to the change

proposition or objective, and make the appropriate adjustments. The information necessary for

these decisions is supplied to and evaluated within the change evaluation process.


1. Which of the following is not an objective of change evaluation?

a. Evaluate the intended and unintended effects of a service change

b. Provide good-quality outputs to ensure Change Management can quickly and

effectively decide on whether to authorize a service change or not

c. Set stakeholder expectations correctly

d. Ensure all changes recorded and evaluated

2. Which of the following statements best describes when change evaluation is invoked?

a. When final change authorization is required

b. Whenever a change authorization is required

c. Whenever a release is ready for deployment

d. Whenever a request for change is recorded

3. What is the primary concern of change evaluation?

a. Quality

b. Compliance

c. Value

d. Schedule

4. Which of the following is not a standard input into the change evaluation process?

a. Organizational readiness assessment

b. Request for change

c. Service Design package

d. Test plan and results

194



5. What is the trigger for change evaluation to be invoked?

a. Request for change

b. Request for evaluation

c. Report of incident

d. Impact assessment

6. What Service Management process will receive the outputs of the change evaluation

process?

a. Release and Deployment Management

b. Change Management

c. Service validation and reporting

d. Transition planning and support

7. Which of the following is a key performance indicator used to confirm the effectiveness of

change evaluations in the Change Management process?

a. Increased percentage of evaluations delivered by greed times

b. Reduced number failed changes

c. Increased satisfaction with change evaluation process by Change Management

personnel

d. Increased satisfaction by stakeholders with new or changed service

10.8 Knowledge Management

Throughout the service lifecycle, and particularly Service Transition, data, information and

knowledge are vital components to the effectiveness of the Service Management system, its

supporting processes and the services. Whether its generating data from Service Validation

and Testing, to evaluating the data in Change Evaluation, to storing the data in Service Asset

and Configuration Management, or ensuring the data is provided to the necessary people

from Release and Deployment Management, Service Management is dependent on the

organization’s ability to manage data, information and knowledge.

Knowledge Management is essential for answering:

• What data, information and knowledge are required to deliver and support services to the

customer?

• Why is it (data, information or knowledge) important?

• Who can provide it?

• What occurs if they cannot provide as expected?

• What resources are required to capture the desired data, information and knowledge within

a reasonable timeframe?


The purpose of Knowledge Management is threefold:

• To share different perspectives, ideas, experience and information.

• To ensure this information is available to the right person in the right place at the right time

to support informed decisions.

• To improve efficiency by reducing the need to rediscover knowledge.

196



Knowledge Management supports the entire organization, not just management. For instance,

the known error database stores resolutions and workarounds to be reused in the environment.

The information is based on the experience gained and results of root cause analysis performed

as part of problem management. The information is available to any person tasked with

resolving an incident or problem or assessing the impact of change on the environment.

Because the information is available, the likelihood of meeting agreed resolution targets

increases and allows IT personnel to be more productive and less reactive in the environment.

The Knowledge Management objectives include:

• Improve the quality of decision-making from management by providing reliable and secure

data, information and knowledge about the service throughout its lifecycle.

• Improve the efficiency and quality of service, as well as increase satisfaction and reduce the

cost of service.

• Provide a clear and common understanding of the value that services provide for the

customer and how those benefits are realized through service delivery.

• Maintain a Service Knowledge Management System (SKMS) which controls access to data,

information and knowledge for the different user groups or communities.

• Gather, analyze, store, share, use, and maintain data, information and knowledge related to

service delivery and support.

10.8.2 Scope

Knowledge Management supports decisions; therefore the scope of the process can be

limitless, as long as the data, information and knowledge it manages can be used to support

decisions within the service environment. This includes supporting the entire lifecycle of a

service, IT governance, and all of the Service Management processes.

Can Knowledge Management be restricted? Yes, based on what decisions the organization

wants to support. However, everyone, at some level, seeks knowledge to understand their role

in the organization or to make it easier to fulfill their responsibilities; therefore, it is a natural

characteristic for people to seek knowledge. A formal Knowledge Management program with

no restrictions provides the means of managing how people access knowledge, what validity of

the knowledge is, and how that knowledge is used.

While Knowledge Management may provide some general principles and policies relative

to all data, information and knowledge, it relies heavily on Service Asset and Configuration

Management to capture, maintain and use configuration data. In practical terms, the

Configuration Management system and associated processes are considered a subset of the

Service Knowledge Management System, but is managed independently from the rest of

the SKMS. In truth, this form of separation is prevalent with any process-specific information

database, such as the known problem database, the AMIS, ISMS, ITCMS, and so on: but it

is important to narrow in on the difference in responsibilities for SACM and Knowledge

Management.


Data, information, and Knowledge Management enables an organization to:

• Understand, conform, and provide evidence of conformance to requirements, particularly

legal or regulatory

• Maintain and adhere to agreed and documented requirements for the retention of different

types or categories of data, information and knowledge.

• Defines different forms of data, information, and knowledge for the purpose of making it

more accessible and usable to the organization.

• Ensures that data, information and knowledge is current, complete and valid.

• Ensures data, information, and knowledge is properly disposed, when required.

198



Knowledge Management and Service Transition are particularly interdependent. Sufficient

knowledge is necessary to effectively transition a service into a production environment:

information which is generated from all stages of the service lifecycle. At the same time, Service

Transitions generate significant amounts of information which is necessary to effective success

in each of the other service lifecycle stages, particularly Service Operation. Consider these

examples:

• In order to understand the risks and issues facing a Service Transition, an understanding

the current production environment is required to ensure the service can be integrated and

operated as designed.

• In order for Service Operations to easily incorporate a new or changed service into their

existing routine, schedules and overall responsibilities, they require an understanding of the

service, its purpose, its design and any issues affecting proper delivery and support of the

service.

Some basic Service Transition tasks supported by Knowledge Management include:

• Defining knowledge ownership, or intellectual property.

• Knowledge transfer to operational staff.

• User, staff, supplier, and stakeholder training of supported services.

• Recording of risks, errors, faults, and corrective actions of controls discovered during Service

Transition.

• Capturing testing and implementation information.

• Supporting impact assessments.

• Reusing release, deployment, change and testing plans, templates, and other

documentation.

• Demonstrating compliance with external standard and regulations.

• Evaluation and authorization of changes.


The primary concept to understand from a Knowledge Management perspective is the

distinctions between data, information, knowledge and wisdom. These distinctions are

commonly related to the Data-to-Information-to-Knowledge-to-Wisdom structure. A general

description of the distinctions includes:

• Data – data is a set of discrete facts. Knowledge Management activities ill capture accurate

data, analyze, synthesis and transform that data into useful information. The system must

identify relevant data and allocate sufficient resources to capturing the data. Commonly

stored in databases.

• Information – establishes context to data and stored in semi-structured devices, such as

documents, media and messages. Knowledge Management serves to enable information to

be captured, queried, found, re-used and learned from, particularly as a means to avoid past

mistakes and duplication of work.

• Knowledge – is a composite of tacit experiences, ideas, insights, values and judgments from

individuals and groups: is generated from experiences and analysis of data and information.

A dynamic and contextual=based aspect of the structure, knowledge is used to facilitate

decision-making.

• Wisdom – creates value though correct and well-informed decisions based on knowledge:

wisdom is the application of data, information and knowledge to a specific situation or

problem.

The technology behind Knowledge Management is the establishment of a Service Knowledge

Management System (SKMS). The largest portion of the SKMS is usually the Configuration

Management system, but other systems are found, such as:

• Service Portfolio.

• Customer Portfolio.

• Customer Agreement Portfolio.

• Application Portfolio.

• Availability Management Information System.

• Capacity Management Information System.

200



• Service Continuity Information System.

• Security Management Information Systems.

• Definitive Media Library.

• Incident/Problem/Change Management Tools.

• Known Error Database.

• CSI Register.

• Risk Register.

• Project Register.

• Policies and Plans.

• Service and Management Reports.

• Monitoring and Measurement Tools.

Simply put any technology or activity which has functionality to generate or utilize IT

data, information and knowledge are a component of the SKMS. As a system, Knowledge

Management establishes relationships and dependencies between these different tools. For

instance, several systems, such as the management information systems, may be organized

by how individual services are supported. Under this requirement, each system could justify

creating a unique profile for each service: which opens up the possibility of duplication and

conflict between the individual systems. By tying every system to the service portfolio, and

more specifically, the service descriptions stored there, the profiles are established at a central

location and leveraged throughout the organization. The individual systems can feed and be

fed data, information and knowledge based on the service portfolio’s service description. From

a Service Management perspective, this is also a simplistic way to establishing alignment across

the information generated about a service.


The activities of Knowledge Management fall into several discrete categories:

• Establishing a Knowledge Management strategy.

• Promoting knowledge transfers:

Ř Identifying learning styles.

Ř Knowledge visualization.

Ř Driving behaviors.

Ř Sponsoring seminars, webinars, and documentation.

Ř Utilizing journals and newsletters.

Ř Supporting the use of discussion forums and social media.

• Managing data, information and knowledge:

Ř Establishing requirements for data, information and knowledge.

Ř Defining the data and information architecture.

Ř Establishing procedures for managing data, information and knowledge.

Ř Evaluating and improving Knowledge Management activities.

• Encouraging the use of a Service Knowledge Management System.


Knowledge Management will be triggered by any activity that generates or requires data,

information, or knowledge. This can range from routine searches using a web browser or

meetings to assessments, evaluations and audits. Some knowledge will be generated or

used as part of the daily responsibilities while some will be associated with a specific project,

program or activity. As a general rule of thumb, every activity within the Service Management

lifecycle has a requirement against Knowledge Management, even if the only requirement is to

document what the activity is.

202



The inputs and outputs of Knowledge Management are summarized in the following table:

Inputs OutputsRelevant business data from the customer Any knowledge required to manage

decisions, specifically for Service Transition

and operations staffAll data, information and knowledge used

by the service provider to deliver and

support services

Awareness and training of Knowledge

Management objectives and benefits

Knowledge Management will interface with and direct all Service Management process at some

level, particularly in relation to identifying, managing and making available the required data,

information and knowledge relevant to each process.


The following critical success factors and key performance indicators are samples related

to Knowledge Management. Each critical success factor has at least one key performance

indicators which is used to demonstrate achievement of the CSF.

• Knowledge and information is available to support management decision-making:

Ř The number of accesses to the SKMS by manager is increasing.

Ř Percentage increase in the number of SKMS searches performed by managers receive a

‘good’ rating.

• Time and effort required to support and maintain services is significantly reduced:

Ř Number of times material is re-used in documentation is increasing.

Ř Number of accesses to SKMS by Service Operation teams is increasing.

Ř Number of issues (incidents/problems) transferred to other people is decreasing and

more resolutions are occurring at lower staff levels.

Ř Percentage increase in the number of incidents resolved using known errors.

Ř Satisfaction in Knowledge Management by Service Operations staff is increasing.

• Few knowledge-related errors arise during the implementation and early life operation of

new or changed services:

Ř Number of incidents and problems categorized as ’knowledge-related’ is decreasing.

Ř Percentage increase of successful Service Transitions.

• The accessibility and management of standards and policies is improved:

Ř Number of standards and policies stored in SKMS is increasing.

Ř Number of times that standards and policies in the SKMS have been accessed is

increasing.

Ř Percentage increase of the standards and policies reviewed by the agreed review date.

• The dependency on the practice of directly engaging personnel for knowledge is

diminishing:

Ř Number of times the SKMS is accessed is increasing.

Ř Percentage increase of SKMS searches resulting in a ‘good’ rating by the user.

Ř Customer satisfaction regarding Knowledge Management is increasing.

Measuring the value of knowledge can be difficult at times, but is necessary to justify the

pursuit of Knowledge Management. The best approach for measuring the value of knowledge is

by establishing a financial cost. These can be done by estimating the following:

• The cost of collecting and storing knowledge (maintaining databases and repositories).

• The cost of transferring or sharing knowledge (reporting, search engines, communication

tools, etc.).

• The cost of not having the reusable knowledge or knowledge tools (duplicate effort, rework,

mistakes, delays, etc.).

The value of knowledge is change based on the person, the circumstances, and the condition

of the knowledge. For instance, known errors are extremely valuable to the service desk when

resolving incidents and problems, but they have little value for managers attempting to develop

strategies.

204




The implementation of a common Knowledge Management approach can be very difficult.

First of all, most departments or groups already have some form of information repository in

place: though the level of implementation may vary from a filing cabinet or desk drawer to

a fabricated knowledge repository. Secondly, groups and individuals tend to be protective

of ‘their’ information and knowledge: thinking that by sharing what they know they are

somehow less competitive in the company. Ironically, the companies that promote knowledge

sharing with its employees tend to be the most competitive in the market space. Lastly, some

stakeholders may struggle with understanding the need for a holistic, centralized approach to

Knowledge Management. While they may recognize the importance of knowledge, they find it

difficult to embrace the principles of Knowledge Management. This can be easily compounded

by frequent failures in managing knowledge.

The risks associated with Knowledge Management include:

• Focusing on tools and technology for Knowledge Management rather than creating value.

• Insufficient understanding of the data, information and knowledge requirements for the

organization.

• Lack of investment and/or commitment in resources and tools needed to support the SKMS.

• Focus on knowledge capture overshadows any focus on knowledge transfer and re-use.

• Information and knowledge which are dated and irrelevant is still stored and shared across

the organization.

• Lack of stakeholder support and commitment.


1. Which of the following is not a purpose of Knowledge Management?

a. Share perspectives, ideas, experience and information

b. Ensure knowledge is available to enable informed decisions

c. Ensure accurate and reliable information about service assets is available when and

where needed

d. Improve efficiency by reducing the need to rediscover knowledge

2. Which of the following is not the responsibility of Knowledge Management?

a. Oversight of the management of knowledge, the information and the data from

which knowledge derives

b. Detailed attention to the capturing, maintenance and use of configuration data

c. Maintain a Service Knowledge Management System for controlled access to

knowledge, information and data

d. Gather, analyze, store, share, use and maintain knowledge, information and data

3. A set of discrete facts is commonly referred to as:

a. Data

b. Facts

c. Information

d. Knowledge

4. The measurement, average time to close priority 1 tickets, in incident management is an

example of what?

a. Data

b. Information

c. Knowledge

d. Wisdom

207

206



5. Which of the following creates value though correct and well-informed decisions

a. Data

b. Information

c. Knowledge

d. Wisdom

6. What is the chief outcome of an effective Knowledge Management process?

a. Better decision-making

b. Greater competency in staff

c. Ease of collaboration

d. Increased intellectual capital

7. Which critical success factor is best served by measuring the key performance indicator,

increased number of times that the SKMS is accessed?

a. Availability of knowledge and information to support management decisions

b. Reduced time and efforts required to support and maintain services

c. Improved accessibility and management of standards and policies

d. Reduced dependency on personnel for knowledge

11 Managing People in Transition

Transition is about introducing change to the environment and the most unpredictable

variables to change happens to be people. In order for any Service Transition to be successful,

everyone has to be on board—from management to worker bees. When they are not, then

the transition process will struggle, schedules are delayed, costs increases and failures occur.

Conversely, when people are on board with the change, schedules shorten, budgets are

maintained and money saved, opportunities for success are found and fewer non-technical

issues arise. Many organizations still invest heavily in making the technical change and avoid

investing in organizational change. Ironically, while investing in managing organizational

change may not reap benefits in terms of budget, schedule, or quality of output, not making the

investment can have significant adverse effects.

Managing people within the context of Service Transition is a significant investment of

resources and capabilities. The effort covers three key areas of discipline:

• Communication.

• Organizational Change.

• Stakeholder Management.

In most cases, these activities cannot be automated and require significant amounts of labor:

upwards to 50% of the Service Transition based on the size, complexity and significance of the

Service Transition.

Chapter 11

208



11.1 Communication in Service Transition

Anytime change is being introduced to an organization, communication is essential. The level of

communication required is congruent to the level of change occurring. For instance, changing

the configuration of a service component may not require much communication; at minimum,

approval from a change authority and recording the change in the Configuration Management

system. However, more communication is required if the service component is considered

critical to a service supporting the customer’s core business process. Even more communication

is required if several service components to a service are being reconfigured.

Some essential elements of the change must be communicated, such as:

• What the change is?

• What are the reasons and rationale for the change?

• What is the implementation plan for introducing the change?

• What are the benefits or intended effects of the change?

• What risks and constraints are involved?

Interestingly enough, everybody may be asking the same questions, but they are expecting

different answers, usually in the context of “how does this change affect me?” Managers are

more prone to needing the organizational impact of the change while technical likely to

seek the environmental impact of the change. Further, users are still more likely to need the

procedural impact of the change. Timing of the communication is also important, as most

people do not need to know about the change until it’s closer to implementation. Security

is another concern as some aspects of the change may be sensitive and cannot be shared;

though it is a good practice to admit these restrictions and the rationale behind protecting the

information.

11.1.1 Understanding People

The underlying reason for people being an unpredictable variable is the range of emotions

tied to accepting change and the different levels of authority to be managed. For change to

be effective, communication has to support moving persons of authority into accepting and

supporting the change. This acceptance is commonly referred to as “by-in” and the key persons

of authority are the stakeholders in the change, namely those managers affected by the change.

For most people, the introduction of change triggers an “emotional cycle”: an often illogical

reaction to change which includes some forms of shock, avoidance, resistance, denial,

acceptance and finally support. Psychologically, every person is subject to this emotional cycle;

however people can move through the cycle quicker than others. For most people, effective

communication is the key reason why they can move through the cycle faster rates.

For every change and every stage of the change, there are three sets of people to consider:

• People already supporting the change.

• People strongly opposed to the change.

• People who are neither supportive or opposed to the change.

The natural tendency in communication is to focus on the first two sets: either surrounding

oneself with like-minded people or picking and winning the fight. Unfortunately, either of

these approaches will provide little benefit when implementing change. The greatest benefit is

obtained when communication is focused on the third set—those people still on the fence. This

does not mean that the first two sets are ignored; only that they be incorporated into the mass

communication with the third set.

An important realization about communication is it is bidirectional: it is just as important

to listen to people as it is to speak to them. While every change requires information to be

210



disseminated outward, effective communication will also consider the feedback and take action

accordingly. In modern times, the push towards ‘collective intelligence’ has demonstrated the

value of knowledge from the masses rather than a few specialists: as a result, even the best

strategies and designs are likely not to consider some important factors known in the collective.

In highly mature organization, the involvement of the collective early on in the service lifecycle

will generate stronger and more valuable services.

11.1.2 Communication Planning

Communication can be broken down into a series of statements, where each statement is

intended to focus on a single topic. Politics have embraced this concept and the art of debating

has shown the benefits of creating clear and concise messages that build excitement and

communicate to the most people. Communication planning will, for the most part, focus

on what the messages should be for a particular Service Transition and how they should be

conveyed. Earlier, five questions for every change were introduced which would need at least

one statement to be developed for each audience (though some statements may be shared):

• What the change is?

• What are the reasons and rationale for the change?

• What is the implementation plan for introducing the change?

• What are the benefits or intended effects of the change?

• What risks and constraints are involved?

The following considerations will shape the necessary statements:

• What is being communicated?

• What is the objective of the communication?

• What are the desired outcomes of the communication?

• How formal and robust does the communication need to be?

• How should the communication be delivered? Individually or tied to other statements? In a

sequence with other statements?

• When should the statement be communicated?

• What tone should be conveyed?

• What actions must be taken to ensure the communication is understood and placed in the

right context to encourage acceptance?

• Who will be involved in the communication and in what context?

• Will the statement enable further communication to occur in the future, or does it close any

communication pathways?

• Are the stakeholders’ communication needs being met?

• How will the success of the communication be measured

Most Service Transitions will have multiple messages to be communicated. An effective

communication strategy and plan will provide the following details about each message?

• Ownership.

• Style.

• Delivery methods.

• Audience.

• Minimal competencies for receiving audience.

• Other related activities.

• Timescales.

• Critical success factors.

• Audience feedback monitoring.

11.1.3 Delivery Methods

All communication is delivered in three general formats: written, verbal and visual. Highly

formal communications should usually be recorded: in the past, such recordings required

written communication, however technology has advanced somewhat to allow both audio and

video recordings, though they are still not seen for legally required communications.

212



If the goal of communication is to enable people to internalize a specific message, it is prudent

to acknowledge that different people are influenced by different forms of delivery. Some may

be able to internalize verbal cues, while others lean towards audio or written cues. As a result,

communication plans should consider using a variety of formats to deliver a message. Not every

message needs to be delivered in all formats; however, those messages which are critical to

the success of the Service Transition and ongoing operations of the service should use every

advantage they can take.

While the delivery methods for communicating are rather simplistic, the different types of

media to be used can vary greatly. Media, in this sense, refers to the different means by which

the message is conveyed. For instance, verbal communication can occur in several mediums, or

capacities; such as large groups, small groups, or individuals. Generally speaking, the intimacy

afforded by small groups or individuals allows for a more laid back approach in communication

and greater focus on addressing specific concerns of feedback. When communicating to large

groups, the message tends to be more ambivalent and require a more critical approach to

communicating the exact message.

Here are various media types which can be leveraged to communicate a message:

• Enterprise meetings – company-wide meetings are excellent opportunities for

communicating strategic messages, but require intense planning and are usually conducted

after communicating with key stakeholders to refine the message and/or aid them in

communicating the message in other media. These types of meetings ensure that everyone

has been communicated the same message at the same time.

• Newsletters – this avenue for communication are a perfect means of communicating to a

wide audience, but should only be used to convey already existing messages. Therefore,

a newsletter should never be used to introduce a new message, though they do have an

advantage of exploring the same message from different perspectives.

• Workshops – provides an opportunity to introduce any communication, new or old, to a

smaller set of involved people or stakeholders. Workshops are best used at the beginning

of a project or large activity and designed to build understanding, excitement and establish

ownership for actions and future communication of the messages. Workshops will typically

focus on the tactical aspect of the message.

• Team meetings – a means of reinforcing the message, usually at an operational level, to a

smaller set of people who share a common attribute. Team leaders should be adequately

prepared to communicate the message as intended and answer any questions and/or they

should be supported by people more familiar with the message.

• One-on-one meetings, interviews, and discussions – these very intimate meetings are

encouraged for every stakeholder. They are advantageous in both directions—meeting with

the stakeholder ensures the person’s questions about a message are clearly understood

and addressed appropriately, while stakeholders taking the lead to have meetings with key

individuals demonstrates senior management commitment of the message and allows a

different form of feedback to be given.

• Training sessions – may vary in content depending on the audience, but is intended to

reinforce the message. While new concepts and perspective could be introduced, they

should be tied to the core message(s). Training sessions are primarily used to prepare people

to take actions consistent with the message.

• Q&A, suggestion boxes and comments – this type of media focuses on the feedback of a

message and enables an opportunity for anonymous contributions across the organization

to arise. From a communicator’s perspective, listening is the core objective and appropriate

action taken to address the feedback.

• Intranet or Internet – the use of web-based communication mechanisms, like blogs, wikis,

and the like are excellent sources for conveying current messages, but like newsletters

should never convey new messages. However, the accessibility to read or write web content

easily has its own issues, especially in providing false information regarding the message

• Posters/roadmaps/brochures – these provide the message in a visually captivating manner

which can be hung on the walls of the office or placed in public areas.

• Reference cards – similar to posters and brochures, these credit-card sized documents allow

key messages to be conveyed and are provided to all personnel to keep.

• Reinforcement memos – these are regular reminders of the message usually addressing

feedback on the message or providing status on actions taken when addressing the

214



message practically. These are particularly important for persons not actively involved in

Service Transitions at any particular time.

• Pay advice notes – attached to payslips/paychecks, these mediums allow reminders to be

communicated to the broadest group of people.

• Simulation games – a practical and fun way of internalizing a message is to allow personnel

to play a game or simulate the change in a controlled environment.

11.2 Managing Organizational Change

Managing organizational change is an important concept in Service Transition: the success

or failure of the Service Transition is largely based on the organization’s readiness to, not just

accept, but use the new or changed service. When putting new technology in the market place,

it is beneficial to provide a user’s guide for the customer. The reason is if a person cannot use

the product, it is considered a failure. The same is true for IT services; if using the service is not

intuitive or requires training which is not available, then the service is not providing the value it

needs to create.

Organization change is largely focused on preparing the organization for the change resulting

from a new or changed service. In many cases, the effort to prepare people may begin long

before the service is finally deployed and available in the production environment. Additionally,

organizational change may require a variety of concerns based on the organization: some

prominent activities related to organizational change can be:

• Employee moves or transfers.

• Business or management training.

• Change in roles and responsibilities.

• Promotions and layoffs.

• Department mergers or separations.

• New or changed policies and processes.

In the previous section, the emotional cycle of change was introduced to the individual. For

most changes, dealing with each individual will be extremely difficult and time-consuming.

Luckily, people tend to congregate into groups and usually based on their emotional state.

Because of this, it is possible to gauge the organization’s “emotional” state to a particular

change, and address any barriers to acceptance of the change.

Managing group reaction to a change can have its advantages and disadvantages based on

the same phenomenon—the ability of persons in the group influencing each other. A single

person or two may be able to sway the entire group to one side or the other. For major changes,

it is recommended to establish “champions” for the change: persons who may not be directly

active in the technical aspect of the new or changed service, but understand enough about the

change and its rationale to influence the emotional acceptance of the change.

11.2.1 Ingredients for Change

How the transition team (and champions) approach organizational change will depend on what

already exists in the organization. Every change requires five important ingredients for success:

• Necessity – where need is not established, people resist.

• Vision - where there is no vision, the people are confused.

• Plan – where no plan exists, people have no focus.

• Resources – where resources are lacking, people become frustrated.

• Competence – where skill and experience is lacking, people become afraid.

216



Managers and executives are responsible for managing change in the organization. This may be

a rather obvious assertion, but it is critical to understand in the setting of a Service Transition.

Consider this example: a transition project is sponsored by a managing stakeholder and

assigned a project manager to manage the schedule, budget and quality of output from the

project, which is responsible for deploying a service within the stakeholder’s department. The

assignment of the project manager may transfer some of the work away from the stakeholder as

manager, but not their accountability for the success of the project.

Likewise, the project manager must understand what is required to obtain acceptance of

the change by the department and be willing to enlist the stakeholder in working with the

department. For each of the ingredients above, the managing stakeholder is in a better position

to provide them than the project manager. Ideally, the general ingredients will be in place

well before the project is started. For organizational change to be successful, managers and

executives must actively participate in the Service Transition: at the very least, they should be

conduits for communication between the transition project and the organization.

11.2.2 Role of Service Transition

So what is the role of Service Transition in organization change? Any change in the business or

technology can initiate a request for change or release to be deployed into the environment.

Service Transition is responsible for fulfilling the objectives of the request, not for the overall

change in the environment. IT similar to encouraging a group of people to exercise more by

providing easier access to a gym: a Service Transition may be responsible for converting a

room into a gym and setting up the machines, but they are not responsible for ‘making’ people

exercise.

However, if people do not exercise, the efforts of the Service Transition have little value; so

organizational change and Service Transition are dependent on each other. It is important

for the Service Transition to understand the culture of the organization(s) involved, including

the business, customer, IT department, suppliers, and stakeholder personalities. Assessments

regarding the culture or organizational readiness are outputs of Service Strategy and design,

but the results must be communicated to and addressed during the Service Transition.

Organizational culture is demonstrated by the ideas, corporate values, beliefs, practices and

expectations about daily behavior shared by persons within the organization.

Success in change initiatives is dependent on the following factors:

• Leadership for the change.

• Adoption by the organization.

• Governance.

• Organizational capabilities.

• Mustiness and service performance measures.

• Strong communication with opportunities for feedback.

The planning and execution of Service Transition must ensure these factors are addressed

appropriately. Since organizational change is responsible for changing the mindsets of people,

Service Transition must actively seek the involvement of people, including:

• Staff.

• Customers.

• Users.

• Service Operation functions.

• Suppliers.

• Stakeholders.

218



As a rule of thumb, the greater the change in mindset for an individual or group, the more

Service Transition will want them involved. Some common reasons for involving people in

Service Transition are:

• Examining the need for knowledge and effective knowledge transfer.

• Examining the importance of making decisions in a timely manner.

• Examining the need to establish and review configuration baselines in a timely manner.

• Support the effectiveness of risk assessment and management.

• Meet deadlines for submitting changes and releases.

11.2.3 Planning for Organizational Change

Service Design will be responsible for organizational assessments and creating the plans

surrounding organizational change: Service Transition simply needs to follow those plans

accordingly. Service Transition will also have to follow the clues to determine the relevance

of the change under different circumstances that may appear as well as determine if

organizational change will deliver the predicted organization, resources and capabilities

required by the service

The first step in planning for organizational change is to understand the culture of the

organization. This can be done by assessing the following factors:

• Language – does the organization have a common or shared language? While traditional

languages are applicable, like English or Spanish, so are the specialized languages often

attributed to business industries or technology. Being able to speak in the language of the

audience goes a long way in building trust and confidence in the proposed change.

• Change – how does the organization typically respond to change? Are they resistant or

eager? Do they ask a lot of questions are apathetic? Resistance and acceptance of change

can come in many forms, so understanding the driving factors for an organization can adjust

the plan accordingly.

• Communication – what modes of communication commonly work better for the

organization? Are communication channels open for all to participate or is it closed and

based on hierarchies? IT is always best to leverage existing communication channels and

expectations if they are effective.

• Knowledge flow – how do people access or share knowledge in the organization. How

effective are these methods? The speed of change will improve generally the more people

are involved in the change, particularly when sharing knowledge.

• Communities – what communities, clichés, and social groups exist within the organization?

Who are the leaders and how these communities structured and operate within the current

organizational structure? Small ‘social groups’ will tend to exist whether sponsored by the

company or not and while some may not provide much value to the company, some can be

indispensable in promoting a necessary change.

• Networks – are personal networks well developed for most individuals and what kind of

information is shared within the network? Within the context of knowledge sharing and

communities, understanding what has already been communicated in existing networks

can determine what opportunities to communicate can be leveraged.

• Working environment – does the work environment support knowledge transfer or

collaboration? Are employees in open spaces or offices? Do common areas, such as kitchens

or break rooms, exist and are they used? The physical and emotional configuration of

the organization may indicate the difficulties present in communicating and managing

organizational change?

• History – what is the organization’s history, and is it embraced in positive or negative terms?

Does historical context influence decision making or acceptance of change? Some of the

reasons for resisting or accepting change has nothing to do with the actual change, but is

influenced heavily by past experiences with change in general. For instance, organizations

which have attempted to introduce change and failed several times may be faced with

a highly resistant environment, while success in past changes may enable staff to accept

easily.

• Meetings – are meetings frequently conducted? Are they effective? How are they

managed? Does everyone participate in the meetings (beyond just showing up)? It may be

necessary to leverage existing meetings to convey information about the change, but such

opportunities may be wasted if the meetings are not run effectively over time.

• Rewards and motivations – what motivates people in the organization? Are they recognized

220



for sharing knowledge? What will motivate people to make the necessary change and

what rewards are available to those who go beyond the call of duty to make the change

successful?

• Time – What is the overall relationship to time for the organization? Are they laid-back or

rigid? Can they adapt or are they inflexible?

Organizational change planning should coincide with technical or project planning for

the Service Transition. This requires the stakeholders, planners and staff understand the

requirements on organizational change. The following question can enable those requirements

to be flushed out clearly:

• What are the strategic drivers and personalities and policy changes which are driving the

Service Transition?

• What does the proposed change solve?

• What will be delivered by the new or changed service?

• What utility and warranty will be provided by the new or changed service?

• What objectives need to be changed (business, service, process, etc.)?

• How will existing processes, templates, decision points and systems be used in Service

Transition?

• What level of reporting is required to make effective decisions?

• Who will be involved or not involved in the Service Transition?

• What will be affected by the change within and outside of the organization?

• What constraints exist regarding schedule, equipment availability, staff availability or

supplier availability?

• What is the planned timescale for the change?

• Who or what can assist with planning the implementation of the service?

• What skills are needed to make the change?

• What measures should be established to demonstrate effectiveness in making the change?

• How will the environment or behaviors be affected?

• What will consequential changes be?

11.2.4 Tools for Organizational Change

As with most activities, several tools are available and necessary to ensure organizational

change is properly managed. These tools consist of:

• Stakeholder maps.

• Organization and capability assessments (current).

• Competency models and assessments (current and required).

• Organization, capability and resource constraints.

• Service Management process model.

• Policies, processes and procedures.

• Definitions of roles and responsibilities.

• Relationship Management.

• Communication plan(s).

• Supplier framework.

Large-scale changes, such as mergers, acquisitions and outsourcing, will require additional

considerations to be taken in the following areas:

• Career development.

• Performance evaluations.

• Rewards and compensation.

• Recruitment and selection.

• Relevant laws and agreements (trade unions, etc.).

222



These tools and considerations are typically addressed as part of the Service Design; however

familiarity to them by Service Transition staff is necessary to ensure they are properly leveraged

and updated. The first set of activities in Service Transition will build the solution and underlying

management system for the service. The deliverables of the build stage relative to organization

change are typically:

• Organization model:

Ř New or changed structure for organization.

Ř Career development structure.

Ř Reward and compensation structure.

Ř Performance evaluation structure.

Ř Performance measurement structure.

• Detailed design for competency model:

Ř Competency list.

Ř Competency or activity list.

Ř Target job, role, staffing, and competence requirements matrix.

Ř Job definition and design.

Ř Role definitions and descriptions staffing plan.

• Individual:

Ř Individual assessment.

Ř Competency, role and skill assessments.

Ř Performance assessments.

Ř Performance enhancement needs assessment.

Ř Learning needs assessment.

• Education and training:

Ř Learning approach.

Ř Learning test approach.

Ř Performance enhancement design.

Ř Learning definition and design.

Ř Course definition.

Ř Performance enhancement support design.

Ř Performance enhancement support plan.

11.2.5 Organizational Readiness

Assessing the readiness of an organization to accept a change requires asking a few general

questions, including:

• Has an assessment been conducted which includes the number of staff required and their

current skill levels relative to the service change?

• Is the vision and strategy documented and used to address any risks?

• Has a review been conducted on the generic roles and interactions throughout Service

Transition?

• Have specific roles and measures been defined

• Have skills for each area been defined?

• Has an assessment been conducted to evaluate the organization’s personnel relative to the

requirements on personnel?

• Has the areas of the organization outside the scope or impact of the Service Transition been

considered, particularly the personnel of those areas?

• Have the requirements for development and maintenance to support business needs been

considered?

• Has the level of risk been documented as it pertains to the support available for each area,

including those areas that cannot be supported and the assumptions that apply to this

analysis?

11.2.6 Monitoring Progress

Since organizational change deals with the change of culture or attitudes and behaviors of

the personnel in the organization, the best approach for monitoring progress is by reviewing

feedback from those personnel. An easy approach is through regular checkpoints and surveys.

224



Progress can be evaluated a number of different ways, such as:

• The number of people aware of the change.

• The number of people who are open and accepting of the change.

• The number of people who understand their role in/after the change.

• The number of people who are positive about the change.

• The number of people who have adopted the change after deployment.

These regular checks should provide an opportunity for people to communicate any issues with

the change or Service Transition.

11.2.7 Challenges with Sourcing Changes

A particular form of Service Transition occurs when the responsibility for service delivery and/or

support changes hands; that is the service will be sourced by a different organization. This will

commonly occur when internal operations are transferred to an external provider or vice versa,

but it is also relevant when transferring service responsibilities internally or to another supplier.

When sourcing changes occurs, several special considerations must be addressed, including:

• Employee shock – sourcing changes will often have a significant impact on the organization

and its structure, usually resulting in transfer personnel with the service, reallocating

them to another business area, or eliminating their role in the organization. Each of these

outcomes will create issues at an emotional level or with morale: the best approach to

address these issues is clear and extensive communication.

• Knowledge sharing – when sourcing changes occur, significant amounts of knowledge may

be transferred from the original source to the new source; however, the idea of “sharing

everything” has its own disadvantages and risks, which may create confusion, distrust

and resistance. Unfortunately, not sharing enough will often result in the same outcomes.

Since sourcing is a business relationship, the best approach is to evaluate the “need-to-

know” status of the information being provided and who should receive it. This requires

understanding the information and the audience to whom it is being delivered.

• Change in physical location – very few sourcing changes will occur where a location change

is not necessary. While there are cultural and organizational considerations to be addressed,

these considerations may vary in importance based on the nature of location change. For

instance, changing locations within the same geographical location will likely have fewer

considerations than changing locations to another country or continent.

• Interconnections – especially when moving responsibilities from a long-standing provider

to a new provider, interconnections between the provider and the ‘customer’ may be

widespread and undocumented. When multiple groups have an interface with the original

source, they need to reestablish those connections with the new provider and those

connections tested to ensure the same value can be obtained.

11.2.8 Approaches to Organizational Change

A prominent approach to organization change is J.P. Kotter’s eight steps to transform your

organization. Those steps include:

1. Establish a sense of urgency.

2. Create a guiding coalition.

3. Develop a vision and strategy.

4. Communicate the change vision.

5. Empower broad-based action.

6. Create short-term wins.

7. Consolidate gains and produce more change.

8. Anchor new approaches in culture.

226



While these eight steps provide a good framework for introducing and managing change, it

lacks in identifying the best strategic approach to organizational change. Kotter and Schlesinger

(1979) suggest six general strategic approaches:

• Education and commitment – people are informed about the change and the expected

implications as early as possible. This generally tends to increase the success of the overall

change.

• Participation and involvement – people are allowed to participate in the change: this

approach must be used in conjunction with education and commitment. Effective

monitoring by management is required to assess the impact on the change and ensure

people do not return to “the old way.”

• Facilitation and support – management will address any fears and anxieties expressed about

the change and activities can include skills gap analysis, process training, and marketing of

service benefits.

• Negotiation and agreement – managements use negotiation and formal agreements to

obtain acceptance of the change from people, either as individuals or as groups.

• Manipulation and co-option – this approach is typically used with people opposed to a

change to “buy” their acceptance and participation.

• Explicit and implicit coercion – used in few instances because of the potential high costs,

now and in the future.

If an organization is seeking acceptance toward a change, it is natural that they must overcome

any resistance to the change. Rosabeth Moss Kanter identifies ten reasons why people resist

change at the individual level. Effective communication will impact these reasons appropriately

when the change is announced. T ten reasons are:

1. Loss of control – people tend to lean towards the familiar and any change will disrupt this;

leading people to experience a loss of control. Control can be restored by involving them in

the decision-making: give them a choice.

2. Excessive personal uncertainty – a common question regarding change for people is ‘what

does this mean for me?’ If this question is not answered quickly or appropriately, people

begin to think the worse on a personal and business level. Be honest even about the

answers which do not exist.

3. Avoid surprises – last minute announcements or forced acceptance is not a good thing:

most people like the opportunity to think through the implementation of change. Rushing

people to accept will tend to create skepticism about the change.

4. The difference effect – As mentioned before, people lean towards the familiar and, because

of this, they create identities around different facets of their work. Change should occur

without disrupting this identity as much as possible.

5. Loss of face – one of the dangers of change for people is they are moving from an

experience where their competency is known to an experience where their competency

‘may be’ insufficient. This can be counteracted by acknowledging the person’s competency

and involving them in the change process.

6. Fear about competence – this reason is routed in a person’s perception that they cannot

adapt to the change, which can often be addressed through proper training.

7. Ripples – resistance to change can occur outside of the scope of the change, by people not

directly impacted by the change but who would be affected by the “ripple effect” caused.

Often, these people do not have sufficient information to respond appropriately because

their concerns were not addressed during the planning phase. The best solution is to

encourage people to think widely and divergently during planning to present unlikely, as

well as likely, possibilities related to the change.

8. Workload increases – for many people, change will frequently result in more work, even for

the short term. If this is the case, acknowledge it and reward the effort.

9. Past resentments – failure can be a major reason for resisting change, especially when the

change is associated with a particular service, individual, or organization which has failed in

the past o the person has outstanding resentment. This can usually be resolved one-on-one.

10. Real threats – some changes will impact some people adversely and they are justified in

their resistance. These people have to be approached early and involved in the solution.

228



When managing organizational change, here are some things not to do:

• Micro-management.

• Overload minor changes with bureaucracy.

• Overcome the agreed degree of exposure to risk.

• Ignore input from stakeholders.

• Focus only on IT, forgetting about non-IT components.

• Forgetting the people.

• Over-complicate things.

• Ignore the after-effects of failed changes.

• Ignore or neglect the costs of transition.

• Forget to re-assess validity and relevance of the change during transition

• Pretend everyone will win (change will produce some “losers,” people who do not receive

what they want).

Here are some things to do when managing organizational change:

• Establish a vision and baseline.

• Develop a communication strategy.

• Articulate and communicate clearly the reasons behind the change.

• Ensure every communication is understood.

• Identify the impact of the change on other services, processes, systems and people outside

the Service Transition.

• Ensure stakeholder participation in decisions, prioritization, execution and measurements.

• Identify new requirements on skills and knowledge.

• Consider development requirements and how they will be addressed, i.e. training, coaching,

mentoring.

• Promote the right culture

• Promote organizational discipline.

• Integrate support from Human Resources.

• Ensure the right people are in the right job or role.

• Support stress management for people.

• Encourage positive thinking – have people think in terms of continual improvement.

• Ensure information about the change is easily accessible to everyone.

• Ensure documentation (new or changed) is concise and understandable for the target

audience.

11.3 Stakeholder Management

While organizational change and communication deal with the overall organization, same

special considerations need to be taken when dealing with stakeholders of the change.

Stakeholders are those people who have placed requirements on the service being transition

and are expecting those requirements to be met be the end of the transition period. If the

rightful stakeholders are not identified up front, Service Transition will likely struggle and

potentially fail.

Service Design is responsible for setting the strategy regarding stakeholder management and

addresses:

• Who are the stakeholders?

• What are their interests and influences in regard to the proposed change?

• How should they be engaged?

• What information must be communicated to them and when?

• How will their feedback be processed?

Rather than dealing with stakeholders as individuals, it would be best to group and categorize

them. Categories should be based on practical groups rather than abstract ones: for instance,

people located in New York would be a good category while people who value freedom would

not.

230



11.3.1 Stakeholder Maps

Stakeholders will have a different interest in a particular change. Some may be interested in the

actual change, while others may be interested in the impact or risks from the change. Some

stakeholders will be interested in the technical aspects, while others will be interested in the

organization or people. Some are financially astute while others are more interested in the

timeframes.

Most stakeholders will share some interests and it is easier to group them based on their

interests. Plotting stakeholders based on their interests creates a tool called a stakeholder map.

General groups of interest can include:

• Change sponsors.

• People implementing the change.

• People affected by the change.

• Suppliers.

• Service Management teams.

• Customers or consumers.

• Relationship management staff.

• Internal and/or external auditors.

• Information security.

• Fraud unit or legal services.

• Risk management.

• Shareholders, management, or staff.

• Labor groups or trade unions.

• Political or regulatory bodies.

• Project and program management teams.

Each group should be analyzed to establish a clear understanding of the stakeholder, their

requirements and their interest in the change. Stakeholder maps have re-use value across

multiple changes and the analysis can identify this consistency. A stakeholder map can plot the

individual’s interest in particular activities or aspects of the transition, or against the level of

communication and involvement needed to satisfy them.

11.3.2 Stakeholder Changes

Inevitably, changes in stakeholders will occur over time, sometimes within a single transition.

Change sponsors should never change during a transition. Additionally, the stakeholder’s

interest may only reside with a particular aspect of a change, for instance with planning the

transition; in this situation, they may not require much after the planning stage is completed.

To facilitate stakeholder change, sufficient records and documentation should be maintained

to effectively hand over stakeholder interests and how they are being addressed in plan and in

actuality.

232




1. What is central to any Service Transition change process?

a. Communication

b. Integrity

c. Excellence

d. Control

2. While the attitudes of all persons should be identified for a change, the majority of

communications should focus on what group of people?

a. People who support the change

b. People who oppose the change

c. People who are causing the change

d. People who neither support nor oppose the change

3. Which of the following questions does not have any relative value when planning

communications to ensure everyone in the organization is aware of changes to the

organization?

a. What is the objective of the communication and what are the desired outcomes?

b. What security risks are present with current communications?

c. What should be the tone of each message be?

d. How and when will groups be involved in furthering the message being

communicated?

4. What method of communication is a fun and practical means of communicating a new

service or process?

a. Training

b. Posters

c. Simulation

d. Workshops

5. A large part of any change (up to 50%) focuses on what set of activities?

a. Service development

b. Stakeholder management

c. Service testing

d. Organizational change

6. Which of the following ingredients, if missing, will lead to chaos during Service Transition?

a. Vision

b. Plan

c. Necessity

d. Competence

7. Who is responsible for change in an organization?

a. Involved managers

b. Impacted stakeholders

c. Service Designers

d. Change Implementers

235

234



8. What tools can be used to identify and track common interests between key decision-

makers involved in a change?

a. RACI matrix

b. Stakeholder map

c. Service Management process model

d. Communication plan

9. Which of the following is not a common reason for resisting change (as identified by

Rosabeth Moss Kanter’s work)?

a. Loss of control

b. Loss of face

c. Fear about competence

d. Lack of compensation

10. Of all the stakeholders, which role poses the greatest risk to a change if the person in the

role changes during the change?

a. Process Owner

b. Service Owner

c. Change Sponsor

d. Change Implementer

12 Organizing for Service Transition

Service Transition insinuates change or progression from one state to the next. As such, it

has a unique feature from an organizational perspective of utilizing a mixture of roles and

responsibilities from across the organization and the service lifecycle. Persons dedicated to

Service Design may be involved upfront to ensure the design is understood and the Service

Transition plan will build, test and deploy the design’s various aspects. Persons dedicated to

the ongoing Service Operations are often utilized heavily as resources for the Service Transition

activities. Even Service Strategy and Continual Service Improvement have a role to play and are

affected by how Service Transition is organized.

Service Transition is important to both the design and operations of a service because it will

be the first opportunity to have hands on experience with the various service components.

Feedback to Service Design will provide information about the viability, ease of use, and

constraints found when actually integrating the different components: factors which may

impact the predicted performance of the Service Design and even change it. The developed

procedures and knowledge generated in Service Transition will often be incorporated into

Service Operations for the daily maintenance and support of the service

Chapter 12

236



12.1 Organizational Development

Organizational change does not occur on its own: it must be planned, designed, and

implemented. Organizational change does not occur instantaneously: it can take months and

years to achieve its goals. There is no single, or best, way to organize.

Organizations tend to move between two paradigms: centralization and decentralization.

Centralization focuses on bringing components under a single, or central, authority and is often

initiated when problems within the organization are persistent and complex. Decentralization

allows decisions to be made locally to the operations and provides greater autonomy to lower

level managers; however, their decisions can be narrow, short-sighted, and incongruent to the

larger organization’s objectives.

Organization structures are influenced by:

• Commitment of senior management.

• Industry, regulatory, and legislative factors.

• Corporate and IT strategies.

• Organization age, size, and scope.

12.1.1 Stages of Organizational Development

Management styles will generally describe how an organization operates and can be used

to identify and plan the growth and maturity of the organization. There are five dominate

management styles:

• Network.

• Directive.

• Delegative.

• Coordination.

• Collaborative.

The organization can be served by each of these management styles for a while, but growth

will usually require the organization to Change Management styles to succeed. To move from

one management style to the next, an organization will typically need to overcome a specific

challenge related to the dominate management style.

The Network management style represents an informal, rapidly paced, and ad hoc delivery of

services. Organizations with this dominant style are entrepreneurial and innovative, will focus

heavily on its technology and will avoid establishing formal structures. Past successes will

reinforce the need to continue in this style, but growth in service demand makes the model not

sustainable over time.

The network management style relies heavily on localized knowledge and dedication from staff

members. Actions between individuals and groups are coordinated by agreements, rather than

authority; relying on people to complement each other without formal structures. To grow as an

organization, leadership must be identified and empowered. This focus on leadership will fly in

the face of the autonomy present in the network style because it begins to create a formalized

structure from which decisions and policies are made.

The advantages of a network structure are:

• Bureaucratic costs due to complex structures are avoided.

• Fewer managers are required, making the organization “flat.”

• The structure of the organization is highly adaptable and can be altered quickly to meet

different challenges.

The disadvantages of a network structure are:

• Management must ensure the integration of individual activities from staff members.

• Significant problems exist when coordinating activities.

• Sourcing functional activities to external providers is extremely challenging as sourcing

decisions are made locally.

238



Overcoming the leadership challenge of a network structure will move the organization into

a directive structure, where upper management becomes focused on “directing” strategy and

lower management will assume responsibilities at the operational, or functional, level. The

focus of a directive structure is to establish a hierarchy where functional activities are separated

and managed. In an IT organization, this may separate technical teams, support for particular

applications, systems or processes, and even shared functions like the service desk.

In this style, communication becomes more formal and processes are implemented. Interactions

may be defined entirely by the process or through operational level agreements (OLA) which

supplement existing SLAs. Managers in functional areas will often be forced to choose between

taking the initiative or to follow the process; leading to shift towards centralization as the

organization because a major driver in decision making.

Autonomy becomes the challenge to organizational growth at this stage: approval is required

at high levels of the organization, while successful performance at lower levels goes unnoticed

and unrewarded. To move forward, the organization must be willing and able to shift

responsibility downward into the organization though delegation. This downward shift requires

management to empower and recognize the efforts of managed personnel.

The structure for delegation shifts the authority for minor decisions to lower level managers,

whose increased control is matched by a corresponding reward system. Delegation combines

the best elements of both network and directive structures: allow the organization to

encourage innovation while leveraging efficiencies in the environment. The delegation

structure is a decentralized structure which shifts responsibilities appropriately from a

functional paradigm to a process paradigm.

When problems arise with the delegation structure, the typical response is to return to a

centralized solution at the functional level: which does not enable growth for the organization.

The proper response, however, is greater control of the process(es) to improve coordination of

individual efforts.

Greater control in the organization results in the implementation of formal systems: a hallmark

of the coordination structure. Senior managers will see formal systems as critical to business

success and take responsibility for their implementation and use. Coordination techniques

and solutions support planned structures for Service Management, which are continuously

reviewed and improved. In the coordination structure, functions are centralized and processes

are decentralized.

The challenge for the organization at this stage is its agility: the organization’s ability to respond

rapidly to changes in the internal and external environments, usually because of pressure

to adhere to procedural requirements. In theory, the capability toward rapid response is the

product of collaboration, as information flows through a diverse group of people rather than a

single individual.

The most developed organizational structure will encourage greater collaboration between

functional units within an organization, with external organizations, and between processes.

Matrix-based organization structures are representative of the collaborative stage, which

identified roles and responsibilities based on function and product or customer.

The advantages of a matrix structure are:

• Barriers between functions are overcome and reduced.

• Personnel can respond better to change, internal and external.

• Communication is improved between functional personnel, or specialists.

• Cross-training between functions is possible.

• Skills and experience from supporting different products and customers can be leveraged

for problematic or new ventures.

240



The disadvantages to a matrix structure are:

• A control structure is lacking which can develop stable expectations across functional and

customer responsibilities.

• Conflict with roles can be developed as greater ambiguity may be perceived, especially in

similar roles supporting different customers.

• Conflict can be developed over time, between functional and customer teams.

To approach organizational growth and structuring, upper management must understand:

• What stage of development the organization already resides.

• What range of options is available and appropriate to the organization.

• That each solution will create new challenges to overcome.

12.2 Departmentalization of Organization

Departmentalization is a method of dividing an organization into manageable components

relative to the organizational activities performed by a certain number of people in the

organization. Departmentalization is typically a result of growth: as the organization grows in

size and scope, groups within the organization are seen as departments. Departmentalization

can be facilitated by focusing on the following distinctions:

• Function – specialized resources are pooled together and reduces duplication of effort.

• Product – helpful in environments with diverse strategies, products and services.

• Market space or customer – promotes differentiation for increased knowledge of and

response to specific customer preferences.

• Geography – minimizes travel and distribution costs while leveraging localized knowledge

and expertise.

• Process – supports end-to-end management of a process.

These structures for departmentalization lend to the following strategic considerations:

• Functional:

Ř Specialization.

Ř Common standards.

Ř Small department sizes.

• Product:

Ř Focus on output (product).

Ř Strong product knowledge.

• Market space/Customer:

Ř Unique services to segments.

Ř Customer service.

Ř Buyer strength.

Ř Rapid customer service.

• Geography:

Ř On-site services.

Ř Closer proximity to customer for delivery and support.

Ř Local perceptions of organization.

• Process:

Ř Process cycle times must be minimized.

Ř Process excellence.

12.2.1 Functions

The term, function, is used in ITIL to describe a team of group of people and other resources

used to execute one or more processes or activities. A function may be further broken down

into smaller departments, teams, or groups or may represent a single organization unit. In small

organizations, a function can consist of a single person. Service Design must clearly define

the roles and responsibilities required to execute a process or activity. While Service Design

does not define any specific functions for the organization, it does rely heavily on the skills and

knowledge of the technical and application management functions.

242



Despite the lack of clarity for functions in Service Design, some organization may elect to define

functions within the design phase. One common function is application development, which

focuses on the developing the utility required by the business. Most application development

work is project-based where specific functionality must be delivered on time and within budget.

However, most work is structured using common software development lifecycles.

Another probable function found in Service Design focuses on project management. This may

be a team of certified project manager who are assigned to individual projects to manage

skilled subject matter experts to collaborate and produce a comprehensive solution. The project

manager may not have any specific IT knowledge to bring to the subject matter of the project,

but are in place to manage the project itself. In most cases, this lack of knowledge in the subject

matter is advantageous because it requires the project manager to involve team members to

greater extent.

12.2.2 Service Transition Structures

The organizational structure of Service Transition can be rather simple for a small organization,

and expanded greatly as the size, reach, and complexity of the organization grow. At the very

least, the Service Transition structure should include:

• Service Transition Manager – process owner, manager and practitioner of the transition

planning and support.

• Change, configuration and release team – includes a person fulfilling the roles of

process owner and manager of Change Management, Service Asset and Configuration

Management, Release and Deployment Management and Knowledge Management, as well

as team members.

• Evaluation and test team – includes a person fulfilling the roles of process owner and

manager of service valuation and testing and change evaluation, as well as team members.

In a small transition, the project team for an individual Service Transition may consist of just the

people above, but the small number of resources would allow maybe one or two transitions at

the same time. The project team may add subject matter experts from different technical teams

and the service desk. As the organization grows and more transitions are demanded at the

same time, the Service Transition structure will eventually find teams specifically covering the

different processes, with a dedicated person fulfilling the role of process owner and manager for

each process.

The organization can continue to grow as the role of process owner and process manager are

separated and assigned to different people. In service environments with multiple customers,

a different process manager may be assigned to individual customers. In this situation, the

process manager may have input into Service Transitions which impact only that customer,

while transitions which impact multiple customers would fall directly in the process owner’s

jurisdiction. As included in the mix would be the different process owners and managers from

the other Service Management processes.

Geographical growth can have an impact on the Service Transition structure, as each region or

location may have a dedicated Service Transition team for the region to handle any changes

specific to that location. Of course, any changes affecting the global community would need

to be managed by a governing Service Transition team, usually located at the company’s

headquarters. For global transitions, the regional teams would still be leveraged to ensure

the transition progresses appropriately in their respective regions. The regional teams may be

smaller in size and structure than the global team, but should sufficient manage the regions

change, configurations, knowledge and release and deployment requirements.

244



12.2.3 Service Transition Project Teams

In every organization, it is unlikely that everyone working on a particular Service Transition

would be a dedicated member of the Service Transition structure. For example, resources from

availability management may be involved to address any availability requirements a member

of the Service Desk may be involved to address appropriate knowledge requirements for the

Service Desk. The level of involvement may vary depending on the type of transition and the

impact on the organization.

In addition to internal staff, a Service Transition may involve representatives from customers

and suppliers. From a customer perspective, a change in service may result in an organizational

change in the business environment. This would require some involvement by relevant groups

including human resources and education services. Internal service providers are more likely

to involve corporate resources during transitions, particularly if the company has a dedicated

project management organization (PMO): in this case, the project manager for the Service

Transition may not be assigned to the IT department.

Given the above scenarios, organization of the Service Transition must address the following

objectives:

• Management of the transition project (costs, schedule, quality, etc.).

• Build, test and deployment of service and service components.

• Integration with supplied services and service components (supplier management).

• Impact on operational environment (design, operations, risk management).

• Acceptance of new or changed service (organizational change).

With the number of participants from various sectors of the service provider, customer and

supplier organizations, the establishment and maintenance of effective interfaces between key

departments is essential not just for individual transitions but the whole of Service Transition

activities across the services.

12.3 Roles and Responsibilities

A role is a set of responsibilities, activities and authorities assigned to a person or team. Roles

and job titles (position) are not synonymous terms. Roles are defined by a process; job titles are

defined by the organization. A person fulfilling the responsibilities associated with a job title

may be filling several roles.

There are two categories of roles:

• Generic – roles which are found in every process, such as process owner and process

manager.

• Specific – roles which are developed for specific processes.

Roles can be accountable or responsible for a specific activity: meaning several roles may

participate in the successful completion of an activity. RACI models are useful tools for

separating responsibilities for an activity between different roles.

12.3.1 Service Owner

The service owner is a generic role with responsibility for managing a service within a business

context. The service owner is accountable for the delivery of a single, and specific, service across

the entire lifecycle of the service. Accountability over the service is independent of where

technological components, processes or professional capabilities reside in the organization.

246



A person fulfilling the service owner role may do so for several services. The specific

responsibilities of a service owner are (responsibilities are associated with relevant Service

Strategy processes):

• Ensures that service delivery and support consistently meet agreed customer requirements.

• Participating in internal service review meetings (with IT).

• Assist in defining service models and service assessments.

• Identify opportunities for service improvements.

• Raise RFCs for service improvements.

• Provide input on service attributes (performance, availability, capacity, etc.).

• Understand the service.

• Solicit required data, statistics and reports for analysis.

• Facilitate effective service monitoring and performance.

• Understand and translate customer requirements into service-related activities, measures,

and components used in meeting those requirements.

• Ensure consistent communication with customer(s) for service-related questions and issues.

• Discuss potential service improvements with customer.

• Serve as a point of escalation for major incidents in service delivery.

• Participate in external service review meetings (with customer).

• Ensure service entry in service catalogue in accurate and maintained.

• Liaison with appropriate process owners throughout the service lifecycle.

• Represent the service across the organization.

• Represent the service in change advisory board meetings.

• Participate in negotiating SLAs and OLAs.

• Raise service improvement opportunities in CSI register.

• Review and prioritize improvements in CSI register.

• Make improvements to service.

The service owner is a primary stakeholder in all Service Management processes that underlie

and support the delivery of the service they own, including

• Incident Management.

• Problem Management.



• Service Asset and Configuration Management.

• Service Level Management.

• Availability Management.

• Capacity Management.

• IT Service Continuity Management.

• Information Security Management.

• Financial Management for IT Services.

12.3.2 Process Owner

The specific roles associated with other Service Design processes are usually restricted to

process owner and process manager. A process owner is accountable for ensuring a process is

fit for purpose, or the process performs according to agreed and documented standards and

meets the aims of the process definition. A process manager is accountable for the operational

management of a process. The same person may be assigned to fulfill the process owner and

process manager roles

248



The specific responsibilities for process owner are (additional responsibilities for individual

Service Design processes are also provided):

• Generic:

Ř Sponsor, design and manage change to the process and its metrics.

Ř Define process strategy.

Ř Assist in process design.

Ř Ensure the availability and currency of process documentation.

Ř Define policies and standards relative to the process.

Ř Audit the process regularly to ensure compliance.

Ř Communicate process information or changes.

Ř Provide process resources to service lifecycle activities.

Ř Ensure technicians working the process have the required knowledge and understanding

of business and technical information needed to deliver the process.

Ř Identify, review and prioritize opportunities for process improvements (with CSI

manager).

Ř Address process issues.

Ř Implement process improvements.

Ř Carry out the above responsibilities for their assigned Service Management process.

• Transition Planning and Support:

Ř Setting Service Transition scope and policies

Ř Overseeing the overall design of all Service Transition process to optimize the

collaboration between processes.

• Change Management:

Ř Designing the hierarchy for change authority.

Ř Designing criteria for allocating requests for change to different levels of change

authority.

Ř Designing change models and workflows.

Ř Work with other process owners to ensure integrated approach to design and

implementation of Change Management, Service Asset and Configuration Management,

Release and Deployment Management, and service validation and testing.

• Service Asset and Configuration Management:

Ř Ensuring the scope for SACM is agreed upon and documented, including a policy for

determining which service assets will be controlled as configuration items.

Ř Work with other process owners to ensure integrated approach to design and

implementation of service asset management, Change Management, Release and

Deployment Management, and Knowledge Management.

• Release and Deployment Management:

Ř Designing release models and workflows.

Ř Work with other process owners to ensure the integrated approach to design, and

implementation of Release and Deployment Management, Change Management,

Service Asset and Configuration Management, and service validation and testing.

• Service Validation and Testing:

Ř Defining the organization’s overall test strategy.


implementation of service validation and testing, Change Management, change

evaluation, and Release and Deployment Management.

• Change Evaluation:


implementation of change evaluation, Change Management, Release and Deployment

Management, and service validation and testing.

• Knowledge Management:

Ř Creating an architecture for identifying, capturing, and maintaining knowledge within

the organization.

250



12.3.3 Process Manager

The specific responsibilities for process manager are (additional responsibilities for individual

Service Design processes are also provided):

• Generic:

Ř Work with process owner to plan and coordinate all process activities.

Ř Ensure all relevant service lifecycle activities are executed.

Ř Appoint people to required roles.

Ř Manage resources assigned to process.

Ř Work with service owners and other process managers to ensure smooth running of

services.

Ř Monitor and report on process performance.

Ř Identify, review and prioritize opportunities for process improvements (with CSI

manager).

Ř Implement process improvements.

Ř Carry out the above responsibilities for their assigned Service Management process.

• Transition Planning and Support:

Ř Manage and coordinate all functions involved in Service Transition.

Ř Budget and account for all Service Transition activities and resources.

Ř Act as prime interface for senior management during planning and reporting of Service

Transition activities.

Ř Manage and coordinate requests for resources.

Ř Coordinate Service Transition activities across multiple projects, suppliers and service

teams.

Ř Ensure final delivery of each Service Transition which meets the agreed customer and

stakeholder requirements specified in the Service Design package.

• Change Management:

Ř Plan and manage support for Change Management tools and processes.

Ř Maintain the change schedule and project service outage.

Ř Coordinate interfaces between Change Management and other processes, specifically

SACM and Release and Deployment Management.

• Service Asset and Configuration Management:

Ř Provides stewardship of fixed assets under control of IT.

Ř Define and agree to what service assets are controlled as configuration items.

Ř Ensure configuration data is available when and where in order to support Service

Management processes.

Ř Plan and manage SACM tools and processes.

Ř Coordinating interfaces between SACM and other processes, specifically Change

Management, Release and Deployment Management, and Knowledge Management.

• Release and Deployment Management:

Ř Plan and coordinate all resources required to build, test, and deploy each release,

including those resources from other functions.

Ř Plan and manage the support of Release and Deployment Management tools and

processes.

Ř Ensure change authorization is obtained before any activity that requires it.

Ř Coordinate interfaces between Release and Deployment Management with other

processes, specifically Change Management, SACM, and service validation and testing.

• Service Validation and Testing:

Ř Aid the design and plan test conditions, test scripts and test data sets in Service Design

to ensure appropriate and adequate coverage and control of tests.

Ř Allocate and manage test resources, according to test policies.

Ř Verify tests conducted by other teams and the Release and Deployment Management

process.

Ř Manage test environment requirements.

Ř Plan and manage support for service validation and testing tools and processes.

Ř Provide management reports on test progress, test outcomes, success rates, issues and

risks.

• Change Evaluation:

Ř Plan and coordinate all resources required to evaluate change.

Ř Ensure evaluation reports and interim evaluation reports are delivered on time to

support necessary decisions by change authorities.

• Knowledge Management:

252



Ř Ensure that all knowledge items are accessible in the most efficient and effective manner

possible.

Ř Plan and manage support for Knowledge Management tools and processes.

Ř Encourage knowledge contributions to SKMS from all IT staff.

Ř Act as advisor to business and IT personnel on Knowledge Management concerns.

12.3.4 Service Transition Practitioner

Unlike many other Service Management processes, the Service Transition processes require

multiple people unaffiliated with the processes to performed routine and repeatable tasks to

meet their intended objectives. For instance in Change Management, the people must likely

to ‘implement’ the change are not directly dedicated to the Change Management process,

but are members of a technical team and could be operating only direct guidance by another

manager focused on a service, a technology, or a process. These people are best described as

practitioners.

Here are the responsibilities of these practitioners based on the different Service Transition

processes:

• Transition Planning and Support

Ř Maintain and integrate plans for specific Service Transitions.

Ř Maintain and monitor progress for Service Transition changes, issues, risks and

deviations.

Ř Maintain records and provide management information on resource use, Service

Transition progress and financial status.

Ř Communicate with stakeholders.

• Change Management

Ř Verify requests for change are completed correctly.

Ř Allocate requests for change to appropriate change authorities based on defined criteria.

Ř Engage change evaluation process by submitting requests for evaluation.

Ř Communicate formally decisions of change authorities to affected parties.

Ř Monitor and review team and function activities to build and test changes to ensure

proper completion of work (for all changes not related to releases).

Ř Publish change schedule and projected service outage and ensure availability.

• Release and Deployment Management (release packaging and build practitioner)

Ř Help design the release package during the Service Design stage.

Ř Establish the final release configuration, including knowledge, information, hardware,

software and infrastructure.

Ř Provide input to support authorization to check-in release to the Definitive Media Library.

• Release and Deployment Management (deployment practitioner)

Ř Help plan service deployment during Service Design stage.

Ř Ensure all deployment activities are authorized by Change Management.

Ř Perform final deployment of physical service components.

Ř Coordinate release documentation and communication, including training and

customer, Service Management and technical release notes.

Ř Provide technical and application guidance and supports throughout the release

process.

Ř Provide feedback on release effectiveness.

Ř Record and report deployment metrics according to service level agreements

• Early Life Support Practitioner (Release and Deployment Management)

Ř Provide IT service and business functional support from deployment to final acceptance

of a transitioning service.

Ř Ensure appropriate support documentation is delivered to operational teams.

Ř Provide release acceptance for providing of initial service support.

Ř Provide support to service desk responding to incidents and known errors detected

within a transitioning service.

Ř Adapt and perfect elements, such as user documentation, support documentation and

data management.

Ř Embed activities for a transitioning service.

Ř Deal with the final transition of a service to Service Operations and Continual Service

Improvement.

Ř Monitor incidents and problems, raising requests for change when necessary.

254



Ř Provide initial performance reporting and assessing service risk based on performance.

• Service Validation and Testing

Ř Conduct tests as defined in test plans and designs and documented in the Service

Design package.

Ř Record, analysis, diagnose, report and manage test events, incidents, problems and

retests.

Ř Administer test assets and components.

• Change Evaluation

Ř Use Service Design package and release package to develop an evaluation plan as input

to service validation and testing.

Ř Establish risks and issues associated with Service Transition.

Ř Create an evaluation report as input to Change Management.

• Knowledge Management

Ř Identify, control and store any information pertinent to a service which is not available by

any other means.

Ř Maintain currency, relevance and validity of controlled knowledge items.

Ř Monitor assimilation of knowledge polices, processes and tools to ensure no information

is duplicated and a central source of information is used across the organization.

12.3.5 Other Roles in Service Transition

In addition to the more general roles described before, each process may have specific roles

necessary to support the Service Transition processes. These roles may be fulfilled by anyone

dedicated to the process or managed outside of the process. These roles include:

• Change Initiator (Change Management)

Ř Identify requirement for change.

Ř Complete and submit change proposal, if appropriate.

Ř Complete and submit request for change.

Ř Attend CAB meeting to provide future information, if invited.

Ř When requested by Change Management, review change (especially before closure of

change record).

• Change Authority (Change Management)

Ř Review specific RFC categories.

Ř Formally authorize changes at agreed points in the change lifecycle.

Ř Participate in change review before closing change record.

Ř Attend CAB meetings to discuss and review changes.

• Change Advisory Board Member (Change Management)

Ř Participate in CAB meetings.

Ř Represent group or function when authorizing changes.

Ř Prepare for CAB meetings by circulating relevant RFCs in group or function and

coordinating feedback.

Ř Review RFCs and recommend authorization.

Ř Review successful and failed changes.

Ř Review unauthorized changes.

Ř Review change schedule and provide information regarding potential conflicts or

resource issues.

Ř Review projected service outage and provide feedback on potential impact.

• Change Authority Board Chair (Change Management)

Ř Determine CAM members and meeting participates.

Ř Plan, schedule, manage and chair CAM meetings.

Ř Select RFCs for review according to the change policy.

Ř Circulate RFCs in advance of CAB meeting to facilitate a member’s preparation.

Ř Conduct emergency change advisory board (ECAB) meetings when emergency changes

are required, according to policy.

Ř Select successful and failed changes for review at CAB meetings.

• Configuration Analyst (SACM)

Ř Propose scope for Service Asset and Configuration Management.

Ř Support the creation of principles, processes and procedures with process owner and

process manager.

Ř Define the Configuration Management system structure(s), including CI types, naming

conventions, attributes and relationships.

• Configuration Librarian (SACM)

256



Ř Control the receipt, identification, storage, and withdrawal of all supported CIs.

Ř Maintain status information on CIs and provide status to appropriate stakeholders when

necessary.

Ř Archive superseded CIs.

Ř Assist with configuration audits.

Ř Identify, record, store, and distribute SACM issues.

• Build and Test Environment Manager (Release and Deployment Management)

Ř Ensure service infrastructure and application are built to design specifications.

Ř Plan the acquisition, building, implementation, and maintenance of the ICT

infrastructure.

Ř Ensure all components are from controlled sources.

Ř Develop an integrated application software and infrastructure build.

Ř Deliver appropriate building, operations and support documentation for build and test

environments.

Ř Build, deliver and maintain required test environments.

• Knowledge Creator (Knowledge Management)

Ř Create and share knowledge relevant to the transitioning service.


1. For a small organization, which role is not necessary to fulfill the objectives of Service

Transition?

a. Service Transition manager

b. Change, configuration and release team

c. Evaluation and test team

d. Knowledge manager

2. What role is responsible for setting the scope and policies for Service Transition?

a. Project manager

b. Transition planning and support process owner

c. Change Management process owner

d. Service owner

3. In the Change Management process, which role is responsible for deciding who attends the

CAB meeting?

a. CAB chair

b. CAB member

c. Change initiator

d. Change Management process owner

4. Which of the following is the responsibility of the configuration analyst?

a. Controlling receipt, identification, storage and withdrawal of all support CIs

b. Archiving superseded CIs

c. Performing configuration audits

d. Maintaining status information on CIs

259

258



5. Which of the following roles is responsible for providing support to asset the service desk in

responding to incidents and errors detected within a new or changed service?

a. Deployment practitioner

b. Early life support practitioner

c. Release packaging and build practitioner

d. Build and test environment manager

6. What generic role is responsible for monitoring and reporting on process performance?

a. Service Owner

b. Process Owner

c. Process Practitioner

d. Process Manager

7. When using a RACI matrix, which attribute can only be assigned to one role?

a. Responsible

b. Accountable

c. Consulted

d. Informed

13 Technology Considerations

Sometimes during periods of change, the focus is inappropriately narrowed to simply ensuring

that the scope of the particular change is managed properly. However, Service Transition has a

responsibility to look beyond the individual transition project to how supporting the entirety

of the service lifecycle. While many of the considerations here are also in strategic planning and

design, Service Transition is the lifecycle which enables those considerations to become real.

For instance, an environmentally conscience organization may decide to ‘go green’ with their

business practices, including Green IT initiatives. Green technologies would be researched and

Service Designs modified to adhere to the initiative. But it isn’t until Service Transition that the

benefits from the initiative are realized. Additionally, the effectiveness of Service Transition will

influence how beneficial Green IT is in the future when implemented in the environment.

One of the considerations of Service Transition is enabling processes and tools to be

implemented to meet current needs while remaining flexible to support future needs. One

particular concern is selecting and implementing a Configuration Management system that

support the current set of recognized configuration items while ensuring new configuration

types can be added at any time. This is especially important if the organization is looking to start

adapting emerging trends such as mobile computing and cloud computing.

Chapter 13

260



13.1 The Tools of Service Transition

For many Service Transition projects, the output may be the initial implementation or release of

a new tool or technology to support a service; however, Service Transition will have its own set

of tools which are used to support the management of Service Transitions. These tools can be

categorized into two sets:

• Tools supporting the service lifecycle.

• Tools supporting Service Transition or its parts.

In the first category, the following tools (or tool classes) may be implemented:

• IT Service Management Systems:

Ř Enterprise frameworks integrated with the Configuration Management system (i.e. fixed

asset management system).

Ř System, network and application management tools.

Ř Service dashboard and reporting tools.

• Specific ITSM technology and tools:

Ř Service Knowledge Management System.

Ř Collaboration, content management and workflow tools.

Ř Data-mining tools.

Ř Extract, transform and load data tools.

Ř Measurement and reporting systems.

Ř Test management and testing tools.

Ř Database and test data management tools.

Ř Copying and publishing tools.

Ř Release and Deployment Management tools.

Ř Deployment and logistics systems and tools.

Those tools which are specifically used to support Service Transition can include:

• Configuration Management systems and tools.

• Version control tools.

• Document management systems.

• Requirements analysis and design tools.

• Systems architecture and computer,-aided software engineering (CASE) tools.

• Database management audit tools.

• Distribution and installation tools.

• Comparison tools.

• Build and release tools.

• Installation and de-installation tools.

• Listing and configuration baseline tools.

• Discovery and audit tools.

• Detection and recovery tools.

• Visualization, mapping and graphical representations.

• Reporting tools.

13.2 Knowledge Management

The tools used in Knowledge Management must enable various processes, such as gathering,

organizing, verifying, storing, and disseminating knowledge. The evolution of Knowledge

Management, as a discipline, has undergone a number of name changes and new concepts

over the last 50 years. As a result, some confusion may exist about what a Knowledge

Management system is and is not. In many cases, people look to some form of knowledge

repository to fulfill the requirements of the process; unfortunately, effective Knowledge

Management goes beyond any simple tool to engage and motivate people to share their

experiences and their knowledge.

262



Still, a document repository, or several really, is still the cornerstone of any Knowledge

Management initiative. There are generally three accepted categories of Knowledge

Management tools.

• Document Management Systems – these support the Knowledge Management activities as

it relates to entire documents: the management is on the documents themselves, not the

content within the documents. File systems are prime examples of unrestricted document

management systems.

• Record Management Systems – records are used as evidence of activities and are

distinguishable from documents. For example, a procedure is considered a document, but

each instance the procedure is executed would be a record.

• Content Management Systems – these systems focus on generating, maintaining and

disseminating content. Wikis, blogs, Yahoo, homepages, YouTube, and Facebook are

examples of tools which promote content.

In each of these systems, the information-related activities supported include:

• Storage.

• Protection.

• Classification.

• Searching.

• Retrieval.

• Maintenance.

• Archiving.

• Retirement.

13.3 Collaboration

The management of change as performed by Service Transition requires collaboration from

multiple groups and people. As a result, many tools for collaboration are used at various points

in a Service Transition. However, what is collaboration? The discipline involves any number

of people working together to accomplish a single goal or objective though sharing of tacit

knowledge. Tacit knowledge is any undocumented knowledge, such as experiences or intuition.

While collaboration is part of Knowledge Management, the tools extend beyond the passivity

of the aforementioned Knowledge Management tools to actively support knowledge sharing at

any given moment. In most cases, the results of collaboration will be recorded and stored within

a Knowledge Management system. Collaboration tools can include:

• Shared calendars and tasks.

• Threaded discussions.

• Instant messaging services.

• White boards.

• Team building activities or brainstorms.

• Video or teleconferencing.

• Email.

• Shared workspaces.

• Wikis.

The definition of collaboration insinuates two major concepts:

• Communities – groups of people who share a common interest.

• Workflow – continuity of purpose or idea towards a single goal or objective.

264



13.3.1 Communities

Traditionally, communities were understood in terms of physical communities; however, the

growth of Internet use and social networking has seen an increased surge in the development

of logical communities. This is important to acknowledge for organizations because employees

will seek relationships in and out of the organization. For instance, systems administrators

may form a community within the organization, even across regional locations, and form

communities with system administrators outside the organization. This has its benefits and risks

to the organization. A major benefit is that it increases the range of knowledge available to the

community member. The risk is the potential sharing of privileged information with someone

outside the organization.

It is important that communities are distinguished from teams or project teams. In general,

teams are forced together through resource management to deliver an agreed outcome or

output. A team member will usually not have a choice about their participation and they are

expected to provide a minimal level of productivity. Communities are generally based on a

specific interest, participation is voluntary, and the level of participation is at the discretion of

the person, not the group. Despite these differences, the structure of communities and teams

are often similar.

The Internet provides the most convenient means of collaboration with the community and

there are a number of solutions which take advantage of web concepts. Effective communities

will have an established leader responsible for managing and running the community. A

number of subject matter experts may be identified and asked to contribute and evaluate the

knowledge assets of the community. The members of the community are free to use or provide

feedback on the knowledge assets. Successful communities will adopt a reward and recognition

program to acknowledge contributions or achievements of their members, particularly as it

relates to generating knowledge assets.

Organizations should establish acceptable methods for creating communities internally

and how the organization will support these organizations. In addition, the organization

should establish a list of preferred communities from external sources which the organization

will support, usually by paying any membership fees or covering the costs of attending a

community event. Typically, external communicates supported should include professional

groups, certification-based focus groups, or group supported by recognized authority. For

instance, a person wishing to share knowledge in IT Service Management may join one of these

established communities:

• itSMF.

• ISACA.

• ITSM Portal.

• ITIL Community.

13.3.2 Workflow Management

A knowledge asset is any accumulation of information, experience, awareness and intellectual

property associated with a specific action of the content. Knowledge assets can be explicit or

tacit; meaning in simply term, they are either documented or undocumented. Organizations

seek to manage, protect and increase/expand their knowledge assets. They may be

copyrighted, patented or trademarked. Knowledge assets can include policies, plans, processes,

designs, configurations, service definitions, methodologies, reports and surveys.

In many cases, the value of a knowledge asset is obtained only when the knowledge asset is

used properly. For instance, the change policy will define the criteria for accepting change into

the environment. Any unauthorized change is essentially a change which does not follow the

policy by bypassing the Change Management process. But even if the Change Management

process is used, there are specific points in the process where the policy must be used to ensure

the criteria for acceptance is adhered.

266



Workflow management is a means of managing knowledge assets through a predefined

workflow or process. The change record is an example of a knowledge asset which goes

through a workflow, namely the Change Management process. In this context, a Change

Management tool may be (but not always) a workflow management tool. Any tool or effort

which provides the infrastructure and support to move knowledge assets along an agreed path

is providing workflow management.

Commonly recognized workflow management tools can be used to:

• Design workflows.

• Route objects (knowledge assets).

• Monitor and respond to events.

• Monitor gateways (authorization checkpoints).

• Manage state changes.

13.4 Configuration Management System

Every organization will have some form of Configuration Management in place, as configuration

items are often tied directly to capital assets. However, Configuration Management is more

than simple accounting and will require something more than paper ledgers. Software-based

Configuration Management systems enable an organization to maintain information about

different types of configuration items. That information will usually consist of attributes, history

and relationships.

At minimum the Configuration Management database (CMDB) should be linked to the

Definitive Media Library (DML). The most comprehensive solutions will integrate several tools

for gathering, tracking, storing, disseminating, and reporting information about configuration

items. These processes may even be automated.

The considerations when designing a Configuration Management system include:

• Multiple data sources should be integrated, encouraging the use of open standards or

known interfaces and protocols.

• Ability to limit access on need-to-know basis using sufficient security controls.

• Ability to support varying complexity within CIs.

• Ability to establish hierarchical and networked relationships between CIs, useful for

facilitating impact assessments in Change Management.

• Adding new and deleting old CIs should be easy for authorized persons.

• Input data should be automatically validated.

• Relationships can be automatically established when new CIs are added.

• Ability to support different model numbers, version numbers and copy numbers of CIs.

• When a CI is the object of a reported incident, problem, known error or change, other

impacted CIs are automatically identified.

• Data from problem management, incident management and Change Management should

be integrated within the CMS.

• Updates and recording of a CI’s version number should be automatic when the version

number is changed, including within the records of related or dependent CIs, if needed.

• History of all CIs should be maintained.

• Configuration baselines need to be supported and managed.

• Reporting capabilities of CMS must be well developed and identify useful information for

audits, interrogations and trend analysis.

• Reporting capabilities of CMS should enable easier collection of data during configuration

audits.

• Reporting capabilities should properly facilitate impact analysis.

• Ability to show graphical models and maps for CIs, as well as allow information to be

inputted though these graphical representations.

• Ability to show parent/child relationships between CIs.

268 269

14 Implementing Service Transition

The assumption of this chapter is the organization has no formal Service Transition approach

in place. The basic fact is that every organization has had to deal with change at some level.

So when formalizing the approach to Service Transition, the first step is to assess their current

relationship to change and how they have managed change in the past, then improve upon

those capabilities. Specifically, the organization should focus on their current capabilities within

each of the Service Transition processes. The best practices introduced by ITIL in relation to

introducing new or changed services can be applied directly to the introduction of new or

improved Service Transition processes. In this context, each of the processes will be treated as a

service available internally.

14.1 Why Service Transition?

Introducing new or improved Service Transition processes may require some organizational

change, an effort which will require answering the question, “Why?” The resulting answer will

be a justification of Service Transition as an integrated approach to managing the environment

and changes placed upon it. There may be several generic reason used in justifying this lifecycle

stage, including:

• Assurance of delivery quality to the customer or business.

• A delivery mechanism between design and day-to-day operations of a service.

• Validation that services are aligned with business or customer objectives.

• Enables and monitors the balance between impact and cost.

Another factor in justifying the need for Service Transition is that its processes are often hidden

from the customer. Therefore, it is necessary to identify some financial reason to improve

Service Transition. This evidence will often come in the form of:

• Cost and impact of failed changes.

• Extra costs of introducing change (transition) against budgeted costs.

• Operational errors which could have been avoided though proper development, testing and

service validation.

14.2 Designing Service Transition

The design principles and activities of Service Transition processes should be similar to those of

designing services; however, there are a few additional considerations to address, including:

• Standards and policies.

• Relationships.

• Funding and resource management.

14.2.1 Standards and Policies

Changes in business, and therefore Service Transition, can be highly regulated depending

on the industry, country, or market space the organization is operating. These requirements

typically revolve around independent and visible accountability for assets, their protection, and

ensuring changes are authorized and tracked.

The recommendation for any organization expected to fulfill externally sourced standards

and policies would be to ensure all personnel within Service Design and Service Transition are

deeply familiar with them. For instance if an organization has to comply with Sarbanes-Oxley

Chapter 14

270



(every publicly traded company in the US), the Service Transition processes need to ensure they

comply with the requirements of this legislation when applicable; however, some requirements

may need to be fulfilled as part of the Service Transition approach.

14.2.2 Relationships

Service Transition will establish new relationships or interfaces with several groups, including:

• Internal non-IT support services – HR, facilities, Production control, education and training.

• Program and project management.

• Internal development teams (i.e. application development).

• External suppliers.

• Customer/users.

• Other stakeholders.

14.2.3 Funding and Resource Management

A typical organization will generally need to maintain three separate environments for Service

Transition – build, test and production environment. These environments may not actually

be directly controlled by Service Transition. The production environment is actually the live

operating environment managed through Service Operations and Service Transition will release

new or changed services. In this situation, the interfaces and authorities of Service Transition

and other controlling entities need to be clearly established, understood, maintained and

managed.

Another area that may be adversely affected from a funding standpoint is the Configuration

Management system and/or Service Knowledge Management System. Often an organization

will provide enough funding to maintain the system, but not enough to enable their

effectiveness as a tool of their respective processes. Consider Configuration Management—an

intended objective is to establish and maintain relationships between configuration items. This

may require automatic verification of the relationship within the operating environment. If the

funding is not available to support this verification effort, then the relationships may only be

verified when a CI is manually touched.

Another example would be the need for knowledge analysts to identify and correct duplicate,

aged, or irrelevant data, information and knowledge. This often requires extensive training in

identification approaches but also in the content itself. A major challenge is determining if this

activity is a Service Transition or Service Operation activity because the effort continues for the

life of the knowledge and the service it is associated.

Other resources have similar concerns. Transition personnel are typically not dedicated and can

come from any corner of the organization. The majority of project teams are often operational

personnel who have been assigned temporarily to the project, but must continue to meet their

day-to-day responsibilities. Particularly software deployments will require the use of network

resources to complete the deployment. These network resources will also be used throughout

the Service Transition for purposes of communication, collaboration, and management within

the project; however it is unlikely that an organization will maintain a dedicated network for

Service Transition.

14.3 Impact of Introducing Service Transition

For most organizations, by the time they start implementing formal Service Transition practices

into the environment, they already have existing projects active. Attempting to implement

these ‘improvements’ into these projects is not recommended as they are likely to disrupt their

progress greatly. Of course, exceptions are allowed if a particular project is problematic and the

new practices need to be implemented immediately.

272



If incorporating Service Transition practices into existing projects is the desired intention, the

best candidates to begin with are those services which have just started the design phase. The

idea here is that the longer a project is “in play,” the harder it will be to adopt the new practices

and the more disruption caused. Ideally, you want to implement these practices backwards;

that is, start with deployment, then testing practices, then build practices, and so on. In taking

this approach, only the projects which are about to enter the particular phase will be affected:

while some additional work may be required, the entire phase will not require rework. Another

approach is to identify those current and planned practices which are similar and to avoid any

radically different practices on an existing project.

The recommended approach is to introduce all new or changes Service Transition practices to

new projects in the future. One benefit to this approach is the ease in which metrics between

similar projects, before and after implementation, can be compared.

14.3.1 Organizational Change

Every improvement to the Service Transition approach will require some organizational

change; however, on existing projects, the need and speed of organizational change increases

dramatically. An immediate concern for effective organizational change is to demonstrate a

sense of urgency: this is more likely to happen on problematic projects, as the need for change

can be justified in order to ensure success. For projects which are already on target in all their

measures, the team may have greater resistance to the proposed practices: or they may be

in the right mind to “pilot” or “lead” the introduction. Ironically, people who work in Change

Management or evangelize change as just as resistant to changing themselves as everyone else.

When making a change in how Service Transition is performed, the immediate concern for

organization change is obtaining acceptance by those people doing the work of Service

Transition. However, those people who are supporting, or being supported by, Service

Transition also require some understanding of the change, why it is being adopted and how it

will impact the current project.

14.3.2 Value and Risk

As with any action performed in and for a business, the question of value and risk will arise.

When adopting Service Transition practices into existing projects, the questions to ask are:

• What is the value of implementing the practice of this project over another?

• What is the risk of implementing the practice of this project?

Consider that all projects are planned and managed according to plan. When a change in

practices, even formalizing an existing practice, occurs, it is essentially a change in plan and

poses its own risk. For instance, if a project is expected to adopt the change without an increase

in funding, what will be the implications? While some projects may be able to absorb the

cost, others may not. In some cases, the change may be adopted but impact the initial value

proposition for the project.

When adopting new or changed practices in a project currently running, the following benefits

need to be ensured:

• Increased customer or user satisfaction.

• Decreased incident and failure rates.

• Reduced cost of transitioning the service.

The potential risks to adopting these practices in current project activities are:

• Alienation of support staff.

• Excessive costs for adoption to the business.

• Unexpected or unacceptable delays.

274



14.4 Process Integration

Throughout this book, the necessity of integrating the Service Transition processes has been

alluded to and explicitly mentioned. Unlike any other set of Service Management processes, the

Service Transition processes must be seen as a set of interdependent activities and tools which

must be designed and implemented together. While it may be possible to focus on one of the

processes, it cannot be done in isolation from the others. This is particularly true for Change

Management, Service Asset and Configuration Management, and Release and Deployment

Management.

An integrated plan for introducing and improving Service Transition processes should address:

• Clear understanding of how processes will work together for different types of transitions.

• The dependencies between different process steps, i.e. what required inputs for a Change

Management step is the result of outputs from what configuration or release process step

• Each activity has roles which are accountable and responsible and qualified to fulfill those

roles.

• An integrated set of CSFs, KPIs and metrics.

• Integrated improvement plan.

14.5 Virtual or Cloud Environments

Virtualization or cloud architectures can be highly beneficial to a company are a number of

levels; however from the perspective of Service Transition, these types of solutions are very

dynamic and require rapid change within seconds. This will impact the design, implementation

and operation of Service Transition.

The most likely solution is to automate all Service Transition activities, particularly:

• Creation, deployment and retirement of virtual servers from physical servers.

• Adding physical resources to provide more capacity to the virtual server.

• Moving a virtual service from a physical service under maintenance to a different physical

service.

Models should be created which identify the allowed and preferred configurations for virtual

servers. Different states should be identified and appropriate configurations maintained for

those states. For instance, a virtual machine may have a different configuration under normal

operations, dealing with an incident or a change, or subject to a different stage of the service

lifecycle. The use of virtualization of cloud solutions may require the creation of new CI types,

change models, release models and standard changes. Different sets of tools and techniques

may be used to create and manage virtual servers over physical servers, but they need to

provide similar metrics.

277

276




1. What activity is directly supported by web-publishing tools?

a. Data management

b. Document management

c. Records management

d. Content management

2. Which tool is not commonly used to encourage collaboration?

a. Whiteboards

b. Emails

c. Flowcharts

d. Instant messaging

3. What is a distinction of a well-run community?

a. Leadership

b. Online events and shows

c. Intellectual property

d. Community portal

4. What is the greatest challenge in justifying Service Transition?

a. Service Transition is really the work of Service Design

b. Service Transition processes are not always visible to the customer

c. Rarely can a balance be created between cost and business impact

d. Service Transition costs too much to formalize

15 Challenges, Critical Success Factors, and Risks

15.1 Challenges for Service Transition

The general challenges to Service Transition include:

• Stakeholder involvement – Service Transition will enable every business process and IT

service, involving and impacting a large number of customers and stakeholders.

• Relationship management – the potential involvement from multiple customers,

users, programs, projects, suppliers and partners in Service Transition requires rigorous

management of contacts, interfaces and relationships.

• Process integration – many of the business and IT processes, such as finance, engineering

and human resources, will impact Service Transition but have little in common with each

other in terms of discipline or process objectives.

• Differences in technology or competency – the inherent differences in legacy systems,

new technology, and competency of individuals in these areas may result in unknown

dependencies and greater risk when changed.

• Operational balance – the ability to maintain a stable production environment must be

balanced with the need to respond to changing service requirements for the customer and

business.

• Balance in oversight – the need for pragmatism and bureaucracy must be balanced.

• Driving consistency – a Service Transition environment must foster standardization,

simplification and knowledge sharing.

• Business change – as an enable of business change, Service Transition may be an integral

part of the business change programs.

• Organizational change – leaders to champion changes and improvements need to be

Chapter 15

278



established in all areas of the organization.

• Assigning responsibilities appropriately – distinguishing who should be doing what

transition activities over who is doing what, as well as when and where those activities

should be done.

• Culture of collaboration – encouraging people to work together effectively, collaborate and

share knowledge.

• Standard measures – establishing standard performance measures and measurement

methods across different types of projects and suppliers.

• Quality assurance – ensuring the quality of service delivery and support matches the

business need and use of new technology.

• Lifecycle issues – ensuring a transition’s schedule and budget is not impacted adversely by

events or problems occurring earlier in the service lifecycle.

• Risk acceptance – understanding the different perspectives of stakeholders underpinning

effective risk management.

• Risk management – understanding, and assessing, the balance between managing and

taking risks as it relates to impacting organization strategy.

• Reporting – the effectiveness of reporting required for risk management and compliance to

corporate governance.

Specific challenges consist of:

• Short schedules.

• Restricted finances.

• Restricted resource availability.

• Absence of required skills and competency.

• Organization politics or disincentives; i.e. threats of redundancy or outsourcing of services,

confrontation, internal rivalries.

• External issues, such as weather, political instability, post-disaster, legislation, etc.

15.2 Risks of Service Transition

Risk describes a possible event that can cause harm or loss, or impact the organization’s ability

to achieve objectives. Risk is measured in terms of probability, vulnerability, and impact.

Handling of risk in an organization involves two major activities:

• Risk Assessment.

• Risk Management.

Managing risks effectively in Service Transition require rigorous attention to the potential

risks for both services currently in transition and those services where new releases are being

planned. For instance, how does the implementation of change impact following releases of

the same or related services or how will a new improvement under consideration impact he

predicted results of the existing service release currently being tested?

The risks associated with Service Transition include:

• Potential de-motivators when accountabilities, responsibilities or practices change during

existing Service Transition projects.

• Alienation of key support and operations staff.

• Unplanned costs added to services during transition.

• Resistance to change.

• Circumvention of processes due to perceived or actual bureaucracy.

• Service Transition practices and plans are overly risk-averse which leads to excessive costs to

the business.

• Wrong people have access to information or people have access to the wrong information

(knowledge sharing).

• Lack of maturity and integration of systems and tools.

• Poor integration between processes.

• Poor Service Transition processes causing loss of productive hours, higher costs, loss of

revenue, or service and business failures.

280



15.3 Critical Success Factors in Service Transition

The primary objective of any IT organization is to continually improve the quality of service

which is cost effective and aligned to business requirements. Service Transition is a key enabler

for quality assurance and the following critical success factors should be considered for Service

Transition:

• Understanding and managing stakeholder perspectives that underpin effective

management.

• Establishing and maintaining stakeholder acceptance and commitment for Service

Transition.

• Clearly defining relationships and interfaces with program and project management.

• Maintaining contacts and managing relationships during Service Transitions.

• Ensuring integration of Service Transition with other service lifecycle stages, processes and

disciplines.

• Understanding the underlying dependencies among legacy systems, new technologies, and

human elements which can make change difficult.

• Automating processes to eliminate errors and reduce cycle times.

• Creating and maintaining new and updated knowledge that can be easily accessed and

used by people.

• Developing systems, tools, processes and procedures that ensure the effective management

of Service Transition practices.

• Developing a firm foundation of understanding the processes, procedures, skills and

competencies required to manage a Service Transition practice.

• Ensure the workforce has the necessary knowledge, skills, training and culture to properly

support a service and its use.

• Defining clear roles, responsibilities and accountabilities.

• Establishing a culture for knowledge sharing.

• Demonstrating improved cycle times and less variation in time, cost and quality predictions.

• Demonstrating improved customer and user satisfaction during Service Transitions.

• Demonstrating the benefits of establishing and improving Service Transition practices and

processes

• Communicating the organization’s attitude to risk and approach to risk management

effectively.

• Ensuring a clear and complete understanding of risks to Service Transition is identified in the

service portfolio.

• Ability to appreciate and exploit the cultural and political environment.

• Ability to understand service and technical configurations and their dependencies.

15.4 Other Implementation Concerns

Service Transition has to balance demand across multiple factors, such as cost, time, quality

and risk. At different times, projects may be pressured to reduce costs, shorten implementation

times, improve quality or optimize risks without impacting the other factors too dramatically.

This may be difficult when the quality of the service requires a longer schedule or higher

budget, which if not available increases the risk profile for the Service Transition.

Because of this balancing act, the focus on risk management is critical. The following principles

from risk management should be applied accordingly.

• Empower staff to take the appropriate levels of risks based on their level of authority.

• Do not hide any absolute cut-off date/time for any deliverables from Service Transition or

create a ‘need to know’ stance for this information.

• Clearly identify and communicate which service components will be available at the cut-off

date and which will be added later.

• Understand the components of the service and their dependencies to ensure the right

components are properly dealt with during a Service Transition.

• Define what users, customers, locations, etc., must be in place at the cut-off date.

• Communicate openly what the impact of failing will be.

282



At some point in the Service Transition a crisis will arise. Effective crisis management will ensure:

• Panic is not created.

• Good crisis managers who make decisions instantly and acts on them.

• Acceptance that decisions regarding a crisis will not be perfect and blame should be

avoided when best effort is provided.

• Staff is aware of their empowerment levels and believes they will be supported.

• Authorization channels exist and are open and respond rapidly.

• Recognizing that following a procedure also has some level of risk and should not be

punished.

A probable concern for Service Transition may be the lack of resources or skill in human

resources. When this occurs, transition projects must create priorities in their objectives,

specifically the cost, time, and quality objectives. The following considerations should be

addressed:

• Punishing efforts when working within parameters: for instance, going over budget when

asked to deliver by a certain time under the parameter, “whatever the cost.”

• What parameters are most important for a particular project – time, cost, quality, etc.

• All staff should be aware and document requirements on the Service Transition.

When IT services will impact or work in high-risk or safety-critical environments, Service

Transitions must acknowledge and work within those conditions. To adhere to the concerns in

these areas, the best approach includes:

• Document appropriately and quickly.

• Ensuring quality is of highest priority.

• Rigorously test the service and collect and managing greater data an/or details in the data.

• Ensure measures of safety are accurately assessed by an acceptable authority.

• Ensure inappropriate pressures do not contribute to authorizing change.

• Ensure the proper allocation of resources, especially those tasks requiring more than one

person.

• Considering ‘veto’ privileges of sub-groups responsible for key or critical aspects of the

service.

Physical environments are not the only potential challenge to Service Transitions; difficult

customers can cause more than a few problems. Difficult customers may range from micro-

managing the project, to not being involved in decisions, to not providing the proper support

or resources to complete a task, such as user testing.

The solution may require awareness and education for all people involved. Some additional

actions to improve the situation may include:

• Identify the appropriate context at different levels of the customer organization.

• Ensure persons representing the customer are fully aware of their responsibilities.

• Ensure communication and reporting requirements during Service Transition are agreed

with the customer.

• Provide the customer with sufficient information to make decisions quickly and effectively.

284 285

Module 3:

1. B

2. C

3. A

4. D

5. B

6. A

7. D

8. B

9. C

10. D

Module 4:

1. B

2. C

3. A

4. D

5. B

6. A

7. D

8. B

9. C

10. D

Module 5:

1. C

2. B

3. D

4. A

5. B

6. B

7. A

8. D

9. C

10. A

Module 6:

1. C

2. A

3. B

4. C

5. D

6. C

7. B

8. A

9. C

10. D

Module 7:

1. A

2. C

3. D

4. C

5. B

6. D

7. B

8. D

9. B

10. C

Module 8:

1. B

2. C

3. D

4. A

5. C

6. D

7. B

8. A

9. C

10. B

Module 9:

1. B

2. D

3. C

4. A

5. C

6. D

7. A

8. B

9. B

10. C

Module 10:

1. D

2. B

3. C

4. A

5. B

6. B

7. D

Module 11:

1. C

2. B

3. A

4. C

5. D

6. A

7. D

Module 12:

1. A

2. D

3. B

4. C

5. D

6. B

7. A

8. B

9. D

10. C

Module 13:

1. D

2. B

3. A

4. C

5. B

6. D

7. B

Module 14:

1. D

2. C

3. A

4. B

Chapter 16

16 Answers to Elearning Module & Workbook Review Questions

286 287

17 GlossaryGlossary terms and definitions are based on the content taken from the five ITIL official lifecycle

books (SS, SD, ST, SO, CSI) Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS.

Term DefinitionsAccounting In the context of ITSM, this is a synonym for

IT Accounting.Agreement A Document that describes a formal

understanding between two or more parties. An Agreement is not legally binding, unless it forms part of a Contract.

Application Management The Process responsible for managing Applications throughout their Lifecycle.

Asset Management (Financial Management) Asset Management is the Business Process responsible for tracking and reporting the value and ownership of financial Assets throughout their Lifecycle.

Availability (Availability Management) (Security Management) Ability of a Configuration Item or IT Service to perform its agreed Function when required. Availability is determined by Reliability, Maintainability, Serviceability, Performance, and Security. Availability is usually calculated as a percentage. This calculation is often based on Agreed Service Time and Downtime. It is Best Practice to calculate Availability using measurements of the Business output of the IT Service.

See Security Principle. Availability Management (Availability Management) The Process

responsible for defining, analyzing, Planning, measuring and improving all aspects of the Availability of IT services. Availability Management is responsible for ensuring that all IT Infrastructure, Processes, Tools, Roles etc. are appropriate for the agreed Service Level Targets for Availability.

Term DefinitionsBaseline The recorded state of something at a specific

point in time. A Baseline can be created for a Configuration, a Process, or any other set of data. For example, a baseline can be used in:

• Continuous Service Improvement, to establish a starting point for planning improvements.

• Capacity Management, to document performance characteristics during normal operations.

• Configuration Management, to enable the IT Infrastructure to be restored to a known configuration if a Change fails. Also used to specify a standard Configuration for data capture, release or Audit purposes.

Budgeting (Financial Management) The Activity of predicting and controlling the spending of money. Consists of a periodic negotiation cycle to set future Budgets (usually annual) and the day-to-day monitoring and adjusting of current Budgets.

Build (Release Management) The Activity of assembling a number of Configuration Items to create part of an IT Service. The term Build is also used to refer to a Release that is authorized for distribution. For example Server Build or laptop Build.

Business Continuity Plan (BCP) (IT Service Continuity Management) A Plan defining the steps required to Restore Business Processes following a disruption. The Plan will also identify the triggers for Invocation, people to be involved, communications etc. IT Service Continuity Plans form a significant part of Business Continuity Plans.

Chapter 17

288



Term DefinitionsBusiness Impact Analysis (BIA) (IT Service Continuity Management)

BIA is the Activity in Business Continuity Management that identifies Vital Business Functions and their dependencies. These dependencies may include Suppliers, people, other Business Processes, IT Services, etc.

BIA defines the recovery requirements for IT Services. These requirements include Recovery Time Objectives, Recovery Point Objectives and minimum Service Level Targets for each IT Service.

Business Relationship Management (BRM) (Business Relationship Management) The Process responsible for maintaining a Relationship with the Business. This Process usually includes:

• Managing personal Relationships with Business managers.

• Portfolio Management. • Ensuring that the IT Service Provider

is satisfying the Business needs of the Customers.

This Process has strong links with Service Level Management.

Capacity (Capacity Management) The maximum Throughput that a Configuration Item or IT Service can deliver whilst meeting agreed Service Level Targets. For some types of CI, Capacity may be the size or volume, for example a disk drive.

Capacity Management (Capacity Management) The Process responsible for ensuring that the Capacity of IT Services and the IT Infrastructure is able to deliver agreed Service Level Targets in a Cost Effective and timely manner. Capacity Management considers all Resources required to deliver the IT Service, and plans for short-, medium- and long-term Business Requirements.

Term DefinitionsChange (Change Management) The addition,

modification or removal of anything that could have an effect on IT Services. The Scope should include all Configuration Items, Processes, Documentation, etc.

Change Advisory Board (CAB) (Change Management) A group of people that assists the Change Manager in the assessment, prioritization and scheduling of Changes. This board is usually made up of representatives from all areas within the IT Service Provider, representatives from the Business, and Third Parties such as Suppliers.

Change Advisory Board / Emergency Committee (CAB/EC)

(Change Management) A sub-set of the Change Advisory Board who make decisions about Emergency Changes. Membership of the CAB/EC may be decided at the time a meeting is called, and depends on the nature of the Emergency Change.

Change Management (Change Management) The Process responsible for controlling the Lifecycle of all Changes. The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services.

Charging (Financial Management) Requiring payment for IT Services. Charging for IT Services is optional, and many Organizations choose to treat their IT Service Provider as a Cost Center.

Configuration Item (CI) (Configuration Management) Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the CMDB and is maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs.

290



Term DefinitionsConfiguration Management (Configuration Management) The

Process that is responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships. This information is managed throughout the Lifecycle of the CI. The primary objective of Configuration Management is to underpin the delivery of IT Services by providing accurate data to all IT Service Management Processes when and where it is needed.

Configuration Management Database (CMDB)

(Configuration Management) A Database used to manage Configuration Records throughout their Lifecycle. The CMDB records the Attributes of each CI, and Relationships with other CIs. A CMDB may also contain other information linked to CIs, for example Incident, Problem or Change Records. The CMDB is maintained by Configuration Management and is used by all IT Service Management Processes.

Cost (Financial Management) The amount of money spent on a specific Activity, IT Service, or Business Unit. Costs consist of real cost (money), notional cost such as people’s time, and Depreciation. Cost is also used as the name of a Charging Policy that recovers the exact cost of providing the service.

Critical Success Factor (CSF) Something that must happen if a Process, Project, Plan, or IT Service is to succeed. KPIs are used to measure the achievement of each CSF. For example a CSF of “protect IT Services when making Changes” could be measured by KPIs such as “percentage reduction of unsuccessful Changes,” “percentage reduction in Changes causing Incidents,” etc.

Customer Someone who buys goods or Services. The Customer of an IT Service Provider is the person or group who defines and agrees the Service Level Targets. The term “Customers” is also sometimes informally used to mean Users; for example, “this is a Customer Focused Organization.”

Term DefinitionsDefinitive Hardware Store (DHS) (Release Management) One or more

physical locations in which hardware Configuration Items are securely stored when not in use. All hardware in the DHS is under the control of Change and Release Management and is recorded in the CMDB. The DHS contains spare parts, maintained at suitable revision levels, and may also include hardware that is part of a future Release.

Definitive Software Library (DSL) (Release Management) One or more locations in which the definitive and approved versions of all software Configuration Items are securely stored. The DSL may also contain associated CIs such as licenses and documentation. The DSL is a single logical storage area even if there are multiple locations. All software in the DSL is under the control of Change and Release Management and is recorded in the CMDB. Only software from the DSL is acceptable for use in a Release.

Demand Management (Capacity Management) Optimizing the use of Capacity by moving Workload to less utilized times, Servers, or places. Demand Management often uses Differential Charging to encourage Customers to use IT Services at less busy times. Demand Management also makes use of other techniques such as limiting the number of concurrent Users.

Emergency Change (Change Management) A Change that must be introduced as soon as possible. For example, to resolve a Major Incident or implement a Security patch. The Change Management Process will normally have a specific Procedure for handling Emergency Changes.

Financial Management for IT Services (Financial Management) The Process responsible for managing an IT Service Provider’s Budgeting, Accounting and Charging requirements.

292



Term DefinitionsHelp Desk (Service Desk) A point of contact for Users

to log Incidents. A Help Desk is usually more technically focused than a Service Desk and does not provide a Single Point of Contact for all interaction. The term Help Desk is often used as a synonym for Service Desk.

Incident (Incident Management) An unplanned interruption to an IT Service or reduction in the Quality of an IT Service. Any event which could affect an IT Service in the future is also an Incident. For example Failure of one disk from a mirror set.

Incident Management (Incident Management) The Process responsible for managing the Lifecycle of all Incidents. The primary Objective of Incident Management is to return the IT Service to Customers as quickly as possible.

Information Technology (IT) The use of technology for the storage, communication, or processing of information. The technology typically includes computers, telecommunications, Applications and other software. The information may include Business data, voice, images, video, etc. Information Technology is often used to support Business Processes through IT Services.

IT Infrastructure Library (ITIL) A set of Best Practice guidance for IT Service Management. ITIL is owned by the AXELOS and is developed in conjunction with the itSMF. ITIL consists of a series of publications giving guidance on the provision of Quality IT Services, and on the Processes and facilities needed to support them.

See http://www.axelos.com for more information.

Term DefinitionsKey Performance Indicator (KPI) A Metric that is used to help manage a

Process, IT Service or Activity. Many Metrics may be measured, but only the most important of these are defined as KPIs and used to actively manage and report on the Process, IT Service or Activity.

KPIs should be selected to ensure that Efficiency, Effectiveness, and Cost Effectiveness are all managed.

Knowledge Management The Process responsible for gathering, analyzing, storing and sharing knowledge information within an Organization. The primary purpose of Knowledge Management is to improve Efficiency by reducing the need to rediscover knowledge.

Known Error (KE) (Problem Management) A Problem that has a documented Root Cause and a Workaround. Known Errors are created by Problem Control and are managed throughout their Lifecycle by Error Control. Known Errors may also be identified by Development or Suppliers.

Known Error Database (Service Desk) (Incident Management) (Problem Management) A Database containing all Known Error Records. This Database is created by Problem Management and used by Incident and Problem Management.

Lifecycle The various stages in the life of a Configuration Item, Incident, Problem, Change etc. The Lifecycle defines the Categories for Status and the Status transitions that are permitted. For example:

• The Lifecycle of an Application includes Design, Build, Test, Deploy, Operate, etc.

• The lifecycle of an Incident includes Detect, Respond, Diagnose, Repair, Recover, Restore.

• The lifecycle of a Server may include: Ordered, Received, In Test, Live, Disposed, etc.

294



Term DefinitionsMajor Incident (Incident Management) The highest

Category of Impact for an Incident. A Major Incident results in significant disruption to the Business.

Operational Level Agreement (OLA) (Service Level Management) An Agreement between an IT Service Provider and another part of the same Business that provides Services to them. For example there could be an OLA with a facilities department to provide air conditioning or with the procurement department to obtain hardware in agreed times. An OLA may also be between two parts of the same IT Service Provider, for example between the Service Desk and a Support Group.

Policy Formally documented management expectations and intentions. Policies are used to direct decisions, and to ensure consistent and appropriate development and implementation of Processes, Standards, Roles, Activities, IT Infrastructure etc.

Proactive Problem Management (Problem Management) Part of the Problem Management Process. The Objective of Proactive Problem Management is to identify Problems that might otherwise be missed. Proactive Problem Management analyses Incident Records, and uses data collected by other IT Service Management Processes to identify trends or significant problems.

Problem The root cause of one or more incidents.Problem Management (Problem Management) The Process

responsible for managing the Lifecycle of all Problems. The primary objectives of Problem Management are to prevent Incidents from happening, and to minimize the Impact of Incidents that cannot be prevented. Problem Management includes Problem Control, Error Control and Proactive Problem Management.

Term DefinitionsRelease (Release Management) A collection

of hardware, software, documentation, Processes or other Components required to implement one or more approved Changes to IT Services. The contents of each Release are managed, tested, and deployed as a single entity.

Release Management (Release Management) The Process responsible for Planning, scheduling and controlling the movement of Releases to Test and Live Environments. The primary objective of Release Management is to ensure that the integrity of the Live Environment is protected and that the correct Components are released. Release Management works closely with Configuration Management and Change Management.

Request for Change (RFC) (Change Management) A formal proposal for a Change to be made. An RFC includes details of the proposed Change, and may be recorded on paper or electronically. The term RFC is often misused to mean a Change Record, or the Change itself.

Return on Investment (ROI) (Financial Management) A measurement of the expected benefit of an investment. Calculated by dividing the average increase in financial benefit (taken over an agreed number of years) by the investment.

Risk The possibility of suffering harm or loss. In quantitative Risk Management this is calculated as how likely it is that a specific Threat will exploit a particular Vulnerability.

Risk Assessment The initial steps of Risk Management. Analyzing the value of Assets to the business, identifying Threats to those Assets, and evaluating how Vulnerable each Asset is to those Threats.

Risk Management The Process responsible for identifying, assessing and managing Risks. Risk Management can be quantitative (based on numerical data) or qualitative.

296



Term DefinitionsService Catalog A Document listing all IT Services, with

summary information about their SLAs and Customers. The Service Catalog is created and maintained by the IT Service Provider and is used by all IT Service Management Processes.

Service Desk (Service Desk) The Single Point of Contact between the Service Provider and the Users. A typical Service Desk manages Incidents and Service Requests, and also handles communication with the Users.

Service Level Agreement (SLA) (Service Level Management) An Agreement between an IT Service Provider and a Customer. The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. A single SLA may cover multiple IT Services or multiple customers.

Service Level Management (SLM) (Service Level Management) The Process responsible for negotiating Service Level Agreements, and ensuring that these are met. SLM is responsible for ensuring that all IT Service Management Processes, Operational Level Agreements, and Underpinning Contracts, are appropriate for the agreed Service Level Targets. SLM monitors and reports on Service Levels, and holds regular Customer reviews.

Single Point of Contact (SPOC) Providing a single consistent way to communicate with an Organization or Business Unit. For example, a Single Point of Contact for an IT Service Provider is usually called a Service Desk.

Single Point of Failure (SPOF) Any Configuration Item that can cause an Incident when it fails, and for which a Countermeasure has not been implemented. A SPOF may be a person, or a step in a Process or Activity, as well as a Component of the IT Infrastructure.

Term DefinitionsStandard Change A pre-approved Change that is low Risk,

relatively common and follows a Procedure or Work Instruction. For example password reset or provision of standard equipment to a new employee. RFCs are not required to implement a Standard Change, and they are logged and tracked using a different mechanism, such as a Service Request.

Underpinning Contract (UC) A Contract with an external Third Party that supports delivery of an IT Service by the IT Service Provider to a Customer. The Third Party provides goods or Services that are required by the IT Service Provider to meet agreed Service Level Targets in the SLA with their Customer.

Urgency A measure of how long it will be until an Incident, Problem or Change has a significant Impact on the Business. For example a high Impact Incident may have low Urgency, if the Impact will not affect the Business until the end of the Financial Year. Impact and Urgency are used to assign Priority.

User A person who uses the IT Service on a day-to-day basis. Users are distinct from Customers, as some Customers do not use the IT Service directly.

Vital Business Function (VBF) A Function of a Business Process which is critical to the success of the Business. Vital Business Functions are an important consideration of Business Continuity Management, IT Service Continuity Management and Availability Management.

Workaround (Incident Management) (Problem Management) Reducing or eliminating the Impact of an Incident or Problem for which a full Resolution is not yet available. For example by restarting a failed Configuration Item. Workarounds for Problems are documented in Known Error Records. Workarounds for Incidents that do not have associated Problem Records are documented in the Incident Record.

298 299

18 References

ITIL®. Continual Service Improvement (2011) Cabinet Office. London. Published on behalf of

AXELOS Limited by TSO.

ITIL®. Service Design (2011) Cabinet Office. London. Published on behalf of AXELOS Limited by

TSO.

ITIL®. Service Operation (2011) Cabinet Office. London. Published on behalf of AXELOS Limited by

TSO.

ITIL®. Service Strategy (2011) Cabinet Office. London. Published on behalf of AXELOS Limited by

TSO.

ITIL®. Service Transition (2011) Cabinet Office. London. Published on behalf of AXELOS Limited by

TSO.

19 Index

A

acceptance 57, 73, 76, 154, 156, 209, 211, 215-16, 218-19, 226, 244, 265, 282

accountabilities 52-3, 66, 216, 245, 269, 279-80

agreements 75, 137, 147, 170-1, 183, 221, 226, 237, 286, 294, 296

alignment 25, 27, 65, 70, 88, 104, 108, 143, 156, 174, 185

applications 18, 33, 36-7, 58, 100, 110, 129, 134, 147-52, 159, 186, 192, 199, 256, 292-3

approach, integrated 30, 248-9, 268

assessments 109-10, 119-21, 123, 132, 169, 178, 185, 198, 201, 217, 221-3, 267, 289

assets 35, 38, 110, 118, 129-33, 137-8, 141, 145, 150, 168, 258, 269, 286, 295

attributes 130, 134, 136, 140, 143-4, 168, 255, 258, 266, 290

audits 68, 73, 121, 130-1, 139-41, 143, 146, 201, 248, 267

authority 67, 76, 170, 191, 209, 236-8, 245, 270, 281-2

authorization 112, 116, 120, 149, 154, 158, 160, 186, 188, 198, 255

autonomy 192, 236-8

availability 42, 161, 173, 175, 246, 248, 253, 286

Availability Management 35, 140, 244, 247, 286, 297

AXELOS 15, 30, 38-41, 49, 51, 286, 292

AXELOS Limited 15, 30, 38-41, 49, 51, 286, 298

Chapter 19Chapter 18

300



B

baselines 33, 109, 130-1, 135, 139-40, 228, 287

Basic Concepts 8-11, 92, 108, 132, 150, 167, 187, 199

book 1, 15, 32, 274

budgets 65, 81-4, 91, 93-4, 99, 102, 141, 207, 216, 242, 250, 278, 282, 287

bureaucracy 121, 123, 228, 277, 279

business 8-11, 23-5, 27, 34-5, 69-71, 79-82, 106-8, 122-3, 149, 164-6, 191-2, 268-9, 277-9, 287-9, 294-

5, 297

business change 71-2, 104, 107, 277

Business Change Management 127

business processes 25-6, 28, 41, 71, 114, 277, 286-8, 292, 297

Business Relationship Management (BRM) 72, 94, 101, 288

business requirements 67, 73, 88, 280

business units 34-5, 38-9, 48, 141, 170, 290, 296

C

capabilities 22-4, 30, 33-4, 38, 40, 47, 62-3, 71, 77, 81, 95, 129-30, 133-4, 144, 169, 268

capacity 42, 56, 67, 89, 117, 124, 173, 175, 186, 212, 246, 275, 288, 291

Capacity Management 28, 119, 247, 287-8, 291

catalog 3, 47, 152

Challenges and Risks 8-11, 96, 121, 142, 158, 179, 190, 204

Change Advisory Board (CAB) 116, 125, 289

change authority 116, 126, 160, 208, 248, 251-2, 255

change evaluation 50, 59, 83, 89, 95, 115, 169, 177-8, 184-95, 242, 249, 251, 254

change evaluation process 79, 116, 185, 187, 189-90, 192-4, 252

Change Management 50, 102-9, 112-13, 116-24, 127-8, 130, 139-40, 149, 154, 186, 188-91, 193-4,

247-55, 266-7, 289

Change Management and Release and Deployment Management 68, 91, 130, 132

Change Management process 64, 103-6, 108, 110, 112, 121, 123, 127, 134, 142, 185, 187-9, 194, 252,

257, 265-6

change models 111-12, 124, 275

change record 110-11, 114, 116, 126, 254-5, 266

change schedule 84, 124, 127, 156, 182, 250, 253

Change Sponsor 230-1, 234

changed services 56-7, 59, 70-2, 80-4, 86, 88, 90, 93, 95-6, 103, 148, 171, 178-9, 190, 214-15, 220

clients 97, 148, 180

CMDB 266, 289-91

CMS (Configuration Management system) 64, 68, 73-4, 84-5, 102, 104-5, 111, 118-19, 121, 134-5,

143, 145, 152, 259-61, 266-7

collaboration 82, 87, 206, 219, 239, 248, 260, 263-4, 271, 276, 278

combination 23, 50-1, 67, 153

commitment 66, 68, 108, 123, 142, 175, 204, 226, 280

communication 22, 37, 40-1, 50, 92, 95, 97-8, 101, 109, 116, 126, 207-13, 216, 218, 232-3, 238-9

communities 196, 219, 263-5

company 54, 98, 122, 124-5, 129, 143, 181, 191-2, 204, 219, 244, 274

competencies 66, 73, 122, 172-3, 206, 222, 227, 277-8, 280

302



concepts 18, 21, 25, 32, 36-7, 41, 64, 67, 69-70, 73, 103, 129, 152, 154, 182, 210

configuration baselines 33, 76, 110, 127, 135, 145, 176-7, 267

configuration data 140, 143, 197, 205, 251

configuration information 130, 132, 135, 140-1

Configuration Item (CI) 33, 59, 104-5, 110, 118, 130-2, 134-6, 138-41, 143-5, 148-9, 154-6, 161, 266-7,

270-1, 287-91, 296-7

configuration items (CIs) 59, 68, 102, 105, 110, 118, 120, 130-2, 134-6, 138-41, 143-5, 148-9, 154-6,

161, 266-7, 287-91

Configuration Management 121, 129, 146, 266, 270, 287, 289-90

Configuration Records 134-6, 290

configurations 33, 73, 80, 107, 110, 127, 132-6, 140, 147, 152, 173, 179, 242-3, 274-5, 286-7, 289-90

conflicts 59, 91, 96, 143, 147-8, 152, 200, 240

Continual Service Improvement 30, 55, 63, 83-4, 87-8, 99, 102, 178, 298

continuity plans 119, 140, 287

control 59, 86, 103-4, 106, 109, 112-13, 129-30, 132, 138, 147-9, 159-60, 183, 185, 226, 239, 251

ContXT 97, 123, 142-3, 159-60, 180-1, 191-2

coordinate 86, 90, 139, 250-1

costs 35-6, 39, 59, 82, 95, 101-2, 108, 116-17, 122-3, 131-4, 149, 157, 179, 203, 280-2, 290

criteria, entry 76, 93, 154, 156

Critical Success Factor (CSF) 13, 21, 83, 85, 95, 120, 132, 141, 157, 178, 190, 202, 206, 280, 290

Critical Success Factors and Key Performance Indicators 95, 120, 141, 157, 178, 190, 202

culture 23, 217-18, 223, 225, 280

customer portfolio 117, 139, 199

customers 23-4, 32-45, 47-8, 70-1, 81-3, 94-5, 149, 157, 165-7, 239-41, 243-4, 246, 268-70, 276-7,

290-2, 296-7

D

databases 134-5, 144, 199, 260, 290, 293

decisions 62, 71, 74, 77, 87, 94, 158, 185-6, 191-2, 196-7, 202, 218, 228, 236-8, 252, 282-3

decreasing 95-6, 107, 120-1, 141, 157, 178-9, 190, 202-3

delays 59, 87, 95-6, 101, 121, 123, 179, 191, 203

delivery 23, 26, 35, 58-9, 61, 67, 75, 105, 132-3, 144, 161, 168, 179, 198, 212, 241

delivery methods 148, 211-12

department 26, 51, 54, 72, 78, 97-8, 124, 160, 180-1, 192, 216-17, 240, 244, 294

dependencies 47, 111, 129, 158-60, 200, 203, 274, 280-1, 288

deploy 59-60, 103, 153, 155, 159-60, 171, 235, 251, 293

deployment 46, 70-2, 82-3, 90, 93, 99, 106-7, 139, 147-9, 152-5, 157, 159, 163-4, 171, 193, 271-2

deployment activities 153, 156, 158, 253

Deployment Management 50, 59, 66, 68, 75, 89, 95, 106, 147, 149-50, 155-9, 162-4, 194-5, 247-51,

253

Deployment Management process 75, 91, 148, 154, 156, 162, 251

deployment models 153-4, 156

deployment plans 155-6, 162, 177

design 55, 58, 60, 62-3, 67, 69, 71-2, 79, 109, 143-4, 164-5, 167-8, 177-8, 222, 235, 248-9

design coordination 89, 94, 156, 169, 189

development 46, 60-1, 65-6, 68, 70, 72-3, 82, 133, 143, 167, 190, 223, 240, 264, 269, 293

304



discipline 207, 261, 263, 277, 280

disruptions 26, 95, 103-4, 120, 272, 287, 289, 294

DML (Definitive Media Library) 75, 138, 145, 147-8, 154-7, 163, 200, 253, 266

documentation 74, 87, 102, 105-6, 115, 147, 155, 172-3, 176, 183, 189, 198, 201-2, 229, 231, 289

E

effectiveness 55, 68, 74-5, 77, 80, 82, 86, 88, 95, 141, 165, 169, 179, 182, 194-5, 293

efficiency 26, 62, 69, 75-6, 80, 82, 86, 88, 95, 107, 112, 141, 167, 178-9, 195-6, 293

Elearning Module 86, 99, 113, 126, 144, 161, 182, 193, 205, 232, 257, 276

Emergency change 66, 110, 114-15, 289, 291

entities, single 150, 161, 295

environment 22, 50, 55, 67-71, 98, 103-4, 106, 108, 113, 135-6, 147, 185-7, 196, 216, 219-20, 270-1

errors 76, 80, 82, 84, 103, 119, 134, 163-5, 176, 178, 198, 202-3, 253, 258, 267, 293

evaluation 82, 104, 109, 116, 118, 126, 132, 140, 185, 188-90, 194, 198, 201, 242, 252, 257

evaluation reports 84, 118-19, 127, 188, 191, 251, 254

existing services 56-8, 66, 68, 82, 159, 186

experience 16, 22, 24, 78, 195-6, 199, 205, 215, 219, 226-7, 235, 239, 261, 263, 265

F

failures 52, 80, 95, 103, 110, 112-13, 140, 166, 190, 207, 214, 227

feedback 78-9, 83-4, 95, 167, 210, 212-13, 217, 223, 229, 253, 255, 264

Financial Management 129, 140, 247, 286-7, 289-91, 295

formats 110, 124, 211-12

framework 30, 32, 56, 68, 133, 156

functions 12, 33-4, 38, 47, 50, 52-3, 72, 78, 95, 149, 168-9, 239-42, 250-1, 255, 286

funding 151, 158, 178, 269-71, 273

G

groups 34, 53-4, 72, 109, 122, 180, 199, 204, 215-16, 218, 229-30, 232, 239-41, 255, 263-5, 289-90

growth 236-8, 240, 264

guidance 30-1, 52, 63, 74, 77-9, 132, 292

guidelines 34, 69, 71-2, 108

H

handover 57, 73, 76, 95

hardware 36, 45, 138, 147, 149, 151, 253, 289, 291, 294-5

human resources 70, 78, 86, 98, 228, 277, 282

I

Impact assessments 113, 115-16, 136, 163, 194

improvements 30, 63, 68, 79, 103, 149, 155, 160, 163, 170, 192, 246, 253, 271-2, 277

incident management 48, 53, 69, 80, 141, 205, 247, 267, 292-4, 297

incidents 53-4, 73-4, 80, 82, 104, 109, 128, 136, 140-1, 143-4, 157, 163-4, 202-3, 253-4, 292-4, 296-7

information 71-2, 74, 84-5, 129-32, 134-5, 140, 142-4, 177-8, 189, 191-2, 195-202, 204-6, 253-5, 265-

7, 289-90, 292-3

306



Information security 97-8, 230

infrastructure 22, 33, 35-6, 118, 129, 134-5, 137, 159, 186, 253, 256, 266, 286-8, 294, 296

ingredients 36, 215-16

installation 75-6, 152, 173, 261

interests 54, 116, 229-30, 264

interfaces 48, 74, 89, 94, 106, 109, 111, 119, 122, 124, 127-8, 131, 140, 178, 250-1, 270

Internal Service Providers 34-5, 124, 144, 244

investment 30, 38, 67, 133, 204, 207, 295

ISO 29, 66, 133

ITIL framework 24, 29-30, 32

ITSM 18, 20, 23-4, 26, 28-9, 161, 286

K

Key Performance Indicator (KPIs) 83, 85, 95, 101, 120, 128, 141, 157, 163, 178, 190, 194, 202, 290, 293

key performance indicators 95, 120, 141, 157, 178, 190, 194, 202, 206, 293

knowledge 18, 22, 24, 71-2, 74, 84-5, 129-30, 134-5, 195-206, 218-19, 224, 241-3, 264-5, 271, 277-80

Knowledge Management 50, 58, 89, 95, 113, 128, 195-205, 249, 251-2, 254, 256, 261-3, 293

knowledge transfer 65, 157, 173, 198, 201, 204

L

leadership 217, 237-8, 276

licenses 15, 30, 38-41, 49, 51, 138, 141, 286, 291

lifecycle 46-7, 55, 58, 66, 103, 113-14, 130-1, 138, 196, 245, 259, 286, 289-90, 292-4

lifecycle stages 32, 53, 59-62, 64, 68, 80, 89, 92, 96, 268

locations 67, 122, 149, 153, 174, 200, 243, 281, 291

M

machines 148, 168, 216

management 23, 35, 54, 66-8, 96, 122-5, 129-31, 133-4, 176, 196, 226, 237-8, 262-3, 286, 288-95, 297

management processes 127, 251, 291

management systems 61-2, 105, 222

managers 35, 48, 54, 192, 202-3, 208-9, 216, 237-8, 242-3, 252

managing changes 56, 58, 67, 102, 125, 216, 226

Material 30, 38-41, 49, 51

media 199, 212-13

meetings 25, 60, 81, 105, 138, 143, 164, 196, 201, 212-13, 219, 246, 255, 288-9

message 199, 210-14, 232

metrics 81-3, 85, 87, 90, 102, 105, 160, 176, 248, 272, 274, 293

money 27, 35, 37, 173, 207, 287, 290

N

network 152, 219, 236, 238, 260

newsletters 201, 212-13

number 16, 25, 51, 57, 64, 68-9, 95-7, 100-1, 120-2, 128, 157, 178-9, 189-91, 202-3, 223-4, 263-4

308



O

OLAs (operational level agreements) 83, 238, 246, 294, 296

order 17-18, 28-9, 34, 45, 47, 61-2, 96, 103, 144, 151, 198, 207, 251, 272, 289

organization 21-5, 29-30, 33-7, 63, 65-70, 74-5, 98-9, 102-7, 121-2, 133-5, 169-70, 196-7, 213-27, 235-

46, 264-6, 268-71

organization change 214, 216, 222, 225, 272

Organization structures 54, 109, 236

organizational change 207, 214-18, 220-1, 223, 225-6, 229, 233, 236, 244, 268, 272, 277

organizational structure 51, 54, 219, 239, 242

organization’s ability 106, 128, 195, 239, 279

organization’s objectives 27-8, 236

outcomes 25, 34-6, 39, 41, 48, 77, 168, 210, 224, 232

ownership 35-6, 52, 73, 211, 213, 286

P

participation 79, 170, 226, 264

people 23, 34-5, 52, 54, 97-8, 181-2, 209, 212-20, 224, 226-30, 232, 239-41, 263, 272, 278-80, 287-90

performance 33, 41-2, 56, 71-2, 81, 90-1, 108, 131, 139, 141, 173-4, 186, 188, 238, 246, 254

person 33, 35, 37, 48, 69, 112, 122, 167, 214-15, 234-5, 242, 245-7, 264-5, 282-3, 296-7

personnel 78, 121, 153, 158, 171, 191, 194, 196, 203, 206, 213-14, 223, 239, 252, 269

phases 19, 154, 160, 162, 272

planning 56, 77-9, 81, 90-2, 99, 116, 123, 126, 132, 136, 139, 143-4, 146, 154, 169, 217-18

plans 18, 81, 101-2, 109, 117-18, 120-1, 123-4, 147-8, 154-5, 159-60, 215, 218, 250-2, 255-6, 273, 287-

8

policies 62, 64-70, 74-5, 77-81, 92, 102, 108, 117-18, 132-3, 154, 167, 203, 248-9, 265, 269

practices, best 29, 63, 68, 70, 104, 268, 286, 292

practitioners 242, 252-3, 258

problem management 73, 79, 109, 119, 140, 163, 196, 247, 267, 293-4

Process Activities 89, 92, 116, 139, 154, 166, 176, 188, 201, 250

process integration 274, 277

process manager 35, 48, 169, 243, 245, 247, 250, 255, 258

process owner 35, 48, 66, 121, 234, 242-3, 245, 247-50, 255, 258

processes 18-19, 32-5, 47-8, 60-1, 68-9, 121, 127-9, 131-2, 159-60, 238-41, 245, 247-8, 250-2, 254-5,

279-81, 286-96

production environment 61, 80, 82, 91, 95, 99, 138, 151, 154-5, 164, 166-7, 179-80, 185, 187, 198,

270

products 23, 28, 62, 65, 94, 106, 135, 142, 169, 214, 239-41

program 16, 62, 70, 91-2, 96, 104, 201, 270, 277, 280

project management 72, 86-7, 91-2, 95, 127, 242, 270, 280

project management system 97-8, 180

project managers 78, 169, 216, 242, 244, 257

project plans 91, 102, 169

project teams 57, 78, 96, 243, 264, 271

projected service outage 118, 253, 255

projects 33, 54, 57-8, 62, 65-6, 68, 72, 77-9, 89-90, 96-8, 167, 190-1, 216, 242, 271-3, 277-8

310



providers 35, 39-42, 225, 294

Purpose and Objectives 90, 103, 129, 147, 165, 186, 195

Q

quality 21-3, 26, 37, 47, 74, 79, 81, 90, 93, 95, 98, 101-2, 120, 141, 281-2, 292

quality assurance 65, 79, 87, 164-6, 182, 278, 280

R

rationale 208, 210, 215

re-use 69-70, 82, 86, 138, 141, 179, 204

readiness, organizational 217, 223

reduction 58, 82, 101, 120, 128, 290, 292

relationships 37-9, 54, 68, 72, 96, 129-32, 134, 136, 140, 142, 144, 200, 220, 266-71, 290

release 57, 66-8, 75-6, 82, 91, 93, 99-100, 109-10, 131-2, 135, 147-58, 160-3, 177-8, 287, 291, 295

Release and Deployment Management 50, 59, 66, 75, 89, 95, 106, 147, 149, 155-9, 162-4, 194-5, 247-

9, 251, 253

Release and Deployment Management process 75, 148, 154, 156, 162, 251

Release Management 100, 147, 287, 291, 295

release packages 65, 117, 137, 147-8, 150-1, 154-7, 161, 171, 173, 253-4

release policy 75-6, 92, 100, 132, 150, 154, 156, 167

release units 150-1, 154, 161

representatives 72, 244, 289

Request for Change (RFCs) 68, 109-10, 112, 114, 116, 118-19, 126-7, 162, 184-5, 187, 189, 193-4, 216,

246, 254-5, 295

requests 67-8, 83-4, 104, 107, 109-12, 114, 116, 118, 120, 126-7, 140, 146, 184-5, 193-4, 216, 252

requirements 23, 29, 42, 56-8, 60-1, 90-1, 96-8, 101-2, 131-3, 183, 200-1, 220, 223, 229-30, 269-70,

288

resistance 209, 218, 224, 226-7, 272, 279

resource management 65, 98, 176, 264, 269-70

resources 26, 35, 38, 47, 56, 62-3, 77-8, 129-30, 133, 144, 150-1, 186-7, 215, 243-4, 250-1, 282-3

response 19, 84, 103, 122, 238-40

responsibilities 23-4, 52-3, 58, 62, 66, 73-5, 78-80, 89-90, 108-9, 154, 178, 197-8, 238-9, 245-6, 248,

250

review 93, 109, 116, 126, 155, 162, 168, 223, 246, 248, 250, 255

rewards 26, 219-22, 227, 264

rights 30, 38-41, 49, 51

risk management 77, 87, 144, 191, 230, 244, 278-9, 281, 295

risks 8-11, 13, 35-6, 39, 47, 95-7, 107-8, 141-2, 148-50, 158-9, 178-80, 185-7, 190-1, 273, 277-9, 281

roles 22-4, 34-5, 48, 50, 52-3, 73, 78-9, 178, 221-4, 234-5, 239-41, 245, 254, 257-8, 274

S

SACM process 131-2, 135, 142-3

scenario 15, 18-19, 172, 244

schedule 65, 82, 87, 95, 101-2, 107-8, 137, 147-8, 152, 159-60, 171, 174, 193, 198, 207, 216

scope 29, 47, 65, 86, 91, 95, 99, 102, 121, 129-30, 132-4, 166, 169-70, 186-7, 196

312



SDP 70, 168-70

service acceptance criteria 94, 99, 102, 137, 155, 171, 179, 183

Service acceptance criteria (SAC) 70, 94, 99, 102, 137, 169, 171, 179, 183

Service Asset 105, 129-30, 134, 144, 150

Service Asset and Configuration Management (SACM) 50, 58, 68, 75, 79, 89, 95, 110-11, 113, 127-34,

137-42, 146, 247-9, 251, 255

service assets 39, 56-7, 59, 73, 75, 82, 86, 117-18, 130, 134-5, 137-8, 141, 148, 166-7, 173-4, 179

service being 37, 167, 187

service capabilities 68, 165, 169, 186

Service Catalog 46-7, 83-4, 117, 296

service changes 56, 67, 71, 73, 80, 86, 106, 110, 117, 186, 188, 193, 223

service charter 99, 168, 170, 182

service components 57-8, 82, 113, 132, 135, 150-1, 159, 161, 166, 168, 171, 173, 175, 185, 208, 244

service continuity 119, 287, 297

Service Continuity Management 119, 140, 247, 287-8

service definitions 117, 168, 265

service delivery 48, 50, 79, 131, 133, 137, 143-4, 157, 166, 179, 182, 190-1, 196, 224, 246, 278

Service Design 55, 57-8, 60-2, 78-9, 82-4, 87-91, 93-4, 98-100, 102, 105, 156, 167-70, 172, 178, 235,

241-2

Service Design stage 57, 62, 70, 253

service desk 34, 51, 53, 69, 111, 122, 135, 157, 203, 238, 243-4, 253, 258, 292-3, 296

service environment 64, 108, 121, 131, 134, 142-3, 147, 150-1, 196, 243

Service Knowledge Management System 62, 64, 74, 87, 134-5, 145, 196-7, 199, 201, 205, 260, 270

Service level 81-2, 132-3, 171, 175, 296

Service Level Management (SLM) 28, 70, 72, 247, 294, 296

service level targets 132, 288, 290

service lifecycle 20, 30, 53, 55, 58, 60, 64, 70-1, 73-4, 78-9, 89, 102, 107-8, 167-8, 259-60

service lifecycle stages 62-3, 78, 83-4, 87-8, 99, 165, 198, 280

Service Management 16, 21-6, 29-30, 34, 47-8, 55, 64, 66, 69, 78, 81, 106, 129, 174-5

Service Management processes 58, 60, 66, 68, 74, 90, 102, 108-9, 113, 119, 123, 130, 132, 134, 140,

290

Service Management Systems 58, 73, 195, 260

service models 79, 99, 102, 136-7, 155, 168, 170, 182

Service Operation functions 157, 171, 217

Service Operations 30, 50-1, 55, 58, 60-2, 64, 76, 78-9, 83-4, 87-8, 90, 178, 198, 202, 235

service owner 35, 66, 234, 245-7, 250, 257-8

service packages 41-3, 45, 117, 137

service portfolio 46-7, 67, 83-4, 93, 102, 114, 117, 139, 143, 145, 174, 199-200, 281

service portfolio management 94, 96, 98, 101, 119

service provider 23, 30, 35, 45-7, 57-8, 62, 71, 91, 129-30, 132, 135-6, 166, 171, 175, 288-90, 296-7

service quality 63, 79, 82, 167, 196, 280

service release 137, 160, 165

Service request 111, 126-7, 139, 146, 162, 296-7

service requirements 55, 71, 165, 171, 183

Service solutions 61, 102, 105, 114

314



Service Strategy 30, 36, 41, 47, 55, 60-3, 83-4, 87-8, 90, 97, 99, 102, 143, 165, 178

service teams 90-1, 96, 167, 250

Service Transition (ST) 21-2, 55-62, 64-75, 77-84, 86-96, 98, 216-18, 222-4, 235, 242-4, 259-60, 268-

72, 276-7, 279-83

Service Transition, individual 57, 92, 94-5, 243

Service Transition activities 64, 81, 96, 99, 235, 244, 250, 275

Service Transition Approach 65, 270, 272

Service Transition perspective 78, 81, 164, 274

Service Transition plans 81, 90, 95, 235

Service Transition policy 66, 72, 92, 167

Service Transition practices 81, 101, 273, 279-80

Service Transition Principles 21, 60, 64

Service Transition processes 21, 58-9, 88-9, 91, 94-5, 99, 128, 248, 252, 254, 268-70, 274, 276

Service Utility 41-2, 181

service validation 10, 50, 59, 79, 89, 95, 128, 164-9, 176-80, 182, 184-5, 189-90, 194-5, 248-9, 251,

254

Service Value 40-1, 82

services being 22, 166, 180

set 34, 36, 54, 72, 93, 124, 131-2, 134-5, 144, 148, 161, 168-9, 209, 259-60, 274-5, 287

skills 24, 36, 78, 148, 172, 179, 215, 220, 223, 228, 239, 241, 280, 282

SKMS (Service Knowledge Management Systems) 62, 73-4, 84-5, 102, 116, 134-5, 177, 196-7, 199-

200, 202-4, 206, 252

SLAs (Service Level Agreement) 22, 83, 102, 133, 155, 162, 181, 253, 289, 296-7

software 45, 138, 140-1, 147, 149, 253, 289, 291-2, 295

sources, original 69, 224-5

staff 23-4, 32, 37, 77, 97, 121, 123, 149, 191, 198, 206, 217, 219-20, 223, 230, 281-2

Stakeholder Changes 148, 158, 231

Stakeholder Management 72, 207, 229, 233

Stakeholder Maps 221, 230, 234

stakeholder relationships 65, 72, 101

stakeholders 23-4, 34, 48, 59, 71-2, 75, 77, 81, 90, 95, 107-9, 113, 189-90, 211-13, 216-17, 228-31

standards 29, 34, 62, 65, 68, 91, 99, 102, 105, 109, 117, 170, 203, 269

state 56, 60-1, 112, 122, 130, 133, 136, 145, 159, 167, 235, 275

steps 79, 111, 116, 121, 185, 191, 218, 225-6, 268, 287, 296

structure 26, 30, 154, 168, 199, 224, 237-8, 241, 243, 264

success 22, 67, 75, 77, 106, 207, 211-12, 214-17, 219, 226, 237, 272, 297

Summary for Transition Planning and Support 97, 180, 191

support services 129, 195, 202

systems 61, 64, 68-9, 74, 78, 98, 110-11, 138, 147, 149-51, 167-8, 180, 199-200, 220, 228, 260

T

teams 34, 53-4, 105, 241-3, 245, 251, 264, 272

technology 22-3, 26, 41, 54, 90, 107, 122, 124, 150, 155, 189, 199-200, 204, 211, 216, 292

Term Definitions 25-6, 286-97

test 18, 60, 71, 73, 80, 93, 147-9, 151, 154-5, 159-60, 167-70, 173-6, 179-80, 182-3, 251, 293

316



test environments 164, 167, 173, 176, 179, 256

test management 176, 183, 260

test models 169-70, 172, 183

test results 119, 177-8, 183, 185, 189

test scripts 167, 170, 173, 251

theme 70, 104-5

tools 20, 30, 34, 52, 78, 90, 95, 171, 204, 221-2, 259-63, 266, 274-6, 279-80

training 74, 76, 109, 148-9, 202, 214, 222, 227-8, 233, 270-1, 280

transition 55-8, 62-3, 65-6, 73, 80, 83-4, 118, 158, 161, 165, 207, 228, 231, 243-4, 279

transition period 58, 72, 229

transition planning 89-96, 98-9, 156, 194, 242, 257

Transition Planning and Support 50, 59, 89, 93-6, 99-101, 119, 248, 250, 252

transition plans 65, 84, 91-2, 156

transition project 57, 72, 79, 82, 216, 244, 282

transitioning service 82, 253, 256

types 62, 75, 87, 93, 102-3, 110-11, 113-15, 122, 124, 126, 132, 143-4, 149-50, 173-4, 212-13, 274

U

UC (Underpinning Contract) 83, 296-7

unauthorized changes 68, 73, 107-9, 120, 123, 128, 141-2, 255, 265

Underpinning Contract (UC) 83, 296-7

understanding 18, 20, 36, 48, 59, 61-2, 64, 129, 158-60, 178-80, 192, 198, 218-19, 278, 280

updates 84, 147-8, 152, 267

users 32, 37, 48, 62, 71, 74, 79, 140, 149, 152, 163-4, 170-1, 174-5, 192, 296-7

V

validation 168, 176, 183, 268

value 22, 34-40, 42, 47, 55, 59, 61-3, 71, 121, 129, 164-5, 199, 203-4, 273

Value to Business 91, 106, 131, 149, 166, 187, 197

vision 83, 215, 223, 225, 228, 233

W

warranty 44-5, 81-2, 99, 117, 132-3, 138, 148, 157, 161, 166, 168, 174, 181, 190, 220

wisdom 199, 205-6

work 25, 42, 52, 54, 94, 97-8, 143, 156, 169, 199, 216, 227, 248-50, 272, 282

workarounds 119, 196, 293, 297

Workbook Review Questions 86, 99, 113, 126, 144, 161, 182, 193, 205, 232, 257, 276

workflows 248-9, 263, 266

Workshops 212-13, 233

318



ITIL ST Workbooks3.amazonaws.com/Quint.Redwood/ST/Resources/ITIL ST Workbook.pdf2 The Objective Tree...

Documents

Transcript of ITIL ST Workbooks3.amazonaws.com/Quint.Redwood/ST/Resources/ITIL ST Workbook.pdf2 The Objective Tree...