SHOULD CHANGE AND
RELEASE MANAGEMENT
BE THE SAME PROCESS?
with
Mark Sherry
Mark Sherry
 Partner – Marval North America
 ITIL® Expert
 ISO 20000 Consultant
 MBA, MA, BComm
 25+ ITIL® implementations
 Trained Service Managers Globally
 10 Years in Industry
 Actively involved in five
independent businesses
2
Should Change and Release Management
be the Same Process?
 Where does the Change Management process stop and the
Release Management process take over?
 Should they be combined into one process?
 Should they remain separate processes?
 What type of change classifications do we need?
 Who decides if a release should be backed out?
3
Change Management – ITIL® Definition
“The process for controlling
the lifecycle of all changes,
enabling beneficial changes
to be made with minimum
disruption to IT services”.
ITIL®® Service Transition, 2011 Edition
4
Change Workflow - ITIL®
ITIL®® Service Transition, 2011 Edition
5
Release Management – ITIL® Definition
“The process for planning, scheduling and
controlling the build, test and deployment
of releases, and for delivering new
functionality required by the
business while protecting
the integrity of existing
services”.
ITIL®® Service Transition, 2011 Edition
6
Standard Release Workflow
7
Change According to ITIL®
Types of Service Change
Standard
Normal
Emergency
Major
Change Coordination Activities
Build and Test
Deployment
ITIL®® Service Transition, 2011 Edition
8
Release According to ITIL®
Release Activities
Release and Deployment Planning
Release and Build and Test
Deployment
Review and Close
ITIL®® Service Transition, 2011 Edition
9
What really happens?
 Many Change workflows in real world
 Workflows are usually a combination of
Change and Release
 Tasks are used to assign the work to
resources for Changes/Releases
 Change approval is in many organizations a
pre-release approval
 Changes/releases cycle through
development, test, production, and training
environments
10
Change/Release Relationship
One to One Relationship
One to Many Relationship
Many to One Relationship
11
Process Flow – Change Only
Approval Status
12
Process Flow – Release Only
Approval Status
13
Process Flow – Change and Release Combined
Approval Status
14
What is the Best Approach?
If you create separate change and
release workflows then you need to
manage more requests and relate
releases to changes and visa versa.
If you use one workflow you lose the
ability to add multiple changes to a
release.
15
Does a Certain Change Type Work Better
with a Particular Workflow ?
Standard
Minor
Normal
Significant
Major
Emergency
Specific Types – i.e. Software Request
16
For a Change that involves multiple Releases
i.e. Dev, Test, Prod – Two workflows usually works best
Many releases per change.
17
Circular Change/Release Workflow
18
For a Release that involves multiple Changes
Two workflows usually works best
Many changes per release.
19
Multiple Changes/Releases Change Type
Normal
Significant
Major
May have multiple changes for a given release.
May have multiple releases for a given change.
Therefore makes sense to separate.
20
For a Change that involves a single Release
One workflow makes sense
Approval Status
21
For a Change that involves a single Release
What if the Release has multiple tasks to be completed?
Approval Status
22
One Change One Release
Minor
 Minor release are usually straight forward and can be
managed.
Standard
 Usually managed as a Service Request.
Emergency
 Usually changes occur outside a workflow and entered
into ITSM system posthumously.
Specific Change Models
 Depends on the breadth of the change.
23
Is It That Simple?
 No just use as a guide.
 Tasks (Assignments or Sub-Requests) can allow
multiple tasks (Releases) to be created that are
related to a change. If this is the case is there need
for Release?
 Think through the complexity of
the changes and releases.
Generally the more complex the
higher the likelihood that they
should be separated.
24
Is It That Simple?
If you can get away with just one workflow for
two processes your process is streamlined.
Just because you have two processes in one
workflow does not mean that there is no
release process. Release just gets reassigned
the request (ticket) somewhere in the
workflow.
One workflow may make Change and Release
work better together.
25
Post Implementation Review
Change is responsible for the PIR but Release
needs to be involved.
Think of Change as the quality control point.
The more risk associated with a Change the
more a PIR needs to be completed.
Release in most cases will complete the PIR.
26
Approvals
What the process requires.
Do not get hung up on change
needs to approve everything at
each step in the process especially
if you have combined both
processes.
27
Change Classifications
 Start with:
Standard
Minor
Normal
Significant
Major
Emergency
Specific Types – i.e. Software Request
 System should be set up to use other Request
Classifications, such as Service, Application,
Hardware, Resolution.
28
Other Service Transition Processes
29
Other Service Transition Processes
What other processes could also be
captured in a Change/Release
workflow?
Service Validation
and Testing
Change Evaluation
(Pre/Post Implementation
Review)
30
Service Validation and Testing
“The purpose of the service
validation and testing
process is to ensure that a
new or changed IT service
matches its design
specifications and will meet
the needs of the business”.
ITIL®® Service Transition, 2011 Edition
31
Change Evaluation
“The purpose of the change evaluation
process is to provide a consistent and
standardized means of determining the
performance of a service change in the
context of likely impacts on the business
outcomes, and on existing and proposed
services and IT infrastructure”.
ITIL®® Service Transition, 2011 Edition
32
Should Change/Release Management use SLA’s?
Standard Changes - Yes as they
are most likely Service Requests.
Repetitive type changes where
the duration is known – Yes.
For changes where the duration
is unknown – No.
Create different types of changes
to meet your SLA needs.
33
Conclusion
Change and release can be
accomplished in the same
process/workflow.
Divide the processes when
it makes sense to do so.
Do not be afraid to use a blended
approach whereby some of your
changes/releases are combined and
some separate.
34
Questions
35
The End
[email protected]
www.marvalna.com
www.marval.co.uk
36