How to make Change Management work in the real world

Everything you’re never told
about how to make Change Management work
in the real world!
Presented by: Peter Hubbard,
Pink Elephant EMEA
Pink Elephant EMEA Ltd
Think Differently. Think Pink

Change Management © Pink Elephant, 2015 All Rights Reserved. ITIL® is a Registered Trade Mark of Axelos.
Introduction – Peter Hubbard
 Principal ITSM Consultant
 Worked in ITSM for almost 20 years
 Regular speaker at industry events
 Worked in all sorts of organisations, large and small
 Once pelted a co-worker with plastic balls in the name
of Release Management
City of London
2

Change Management © Pink Elephant, 2015 All Rights Reserved. ITIL® is a Registered Trade Mark of Axelos. 3
Change Management: Value to the Business
Change Management’s biggest contribution is to enable the service
provider to cope with higher volumes of change without impacting service
quality.
Increased understanding of risk during and after a Change
CHANGE

Poor Change Hurts!
"Earlier today we encountered an
error while making an infrastructure
configuration change that briefly
made it difficult for people to access
Facebook.” (Source USA Today:
September 2014)
that describes
it as a combination of some
planned maintenance, a failure to
update some internal configuration
files and a programmatic memory
leak (Source www.cio.com) The
issue lasted 4 days
The nearly weeklong failure points
to far larger problems for the bank,
which include managing a large
and disparate IT team that was
likely having difficulty
communicating with each other
about the upgrades.
(Source: Americanbanker.com)

Nat West
5
Cost of outage
estimated at over
£125m

RBS & Natwest....again!
6

Change Management in the Wild…A study
Top 5 Issues with an organisations
Change Process itself are:
 People unclear whether a change is needed
or not.
o Highly bureaucratic process painful to interact
with
o CAB meeting a technical torture chamber
o No visible way to add value leading to a poor
perception of change itself
o Approvers don’t always have knowledge or
understand the change / risks involved.
o Unable to determine change success rate
Top 5 Indicators of Poor Change
management within an organization
are
o No central view of all changes occurring
o Unauthorized Changes occurring
o Unplanned outages
o A high number changes rushed through
o Limited project handover leading to operational
issues
o No change reporting

Agility vs. Safety
Agility
Safety
An agile process but taking safety
into account
• Std Changes
• Minor Changes
• Unplanned Changes
• Emergency Changes
What is the focus of
your Change Mgt
Process?

High Level Change Process Activity

So what is a change?
 Change - the addition, modification, or removal of
anything that could have an effect on IT Services. (Do
you have a Service Catalogue?)
The scope of Change Management should include changes to
all architectures, processes, tools, metrics and
documentation, as well as changes to IT services and other
configuration items.
So…..a change is pretty much everything then?

Make sure Techies know when to engage
“Any non pre approved modification, maintenance or
monitoring activity taking place on an in scope item”
Examples of Changes for IT Services could include:-
• Server installations
• Network router modifications
• Server application patching
• Changes to SLAs
• Removal of hardware on an in scope item
• Break/fix to an in scope item
DOES FIXING AN INCIDENT REQUIRE A CHANGE?

Sample Change Scope
Item Example Items
Services
Email Service
Internet Service
Servers
Physical Servers
Logical / Virtual Servers
Data Centre Environmental
Infrastructure
Air Conditioning Units
UPS (Uninterruptable Power Supplies)
Network Infrastructure
Firewalls
Routers
Switches
Software on an in scope item
Customer Relationship Management Software
MS Exchange Server
Service Level Agreements Service Desk SLA
Supplier Contracts Thales Support Contract
Groups of 25 or more PCs
Changes that are projected to affect more than 25 Pcs at a
time.
Multi Function Printers This the large scale printers and not individual inkjets.
Software Builds / Images Documented Software Builds for PCs

Standard Changes
 Standard
 A Standard change (Std Change) is a routine, pre approved
change. Standard changes can be utilised to fix incidents
where appropriate and do not need to be submitted for
Change Management approval each time.
 Examples
 Scripts to reinsert a deleted entity
 Antivirus patch updates
 Admin of Vasco tokens
 Authorisation Level Required
 CAB (on initial creation)
 Local Authority (i.e. the Change Requestor)
13

Change Admin…the most hated part!
 Your role is to
ensure enough
information
exists to make
an informed
decision. Not to
demand war and
peace!
15

Make sure change
assessment is simple and
clear. It drives your workload
for the rest of the process

Risk Assessment Form
11 Questions
30 seconds to complete
MANDATORY
Change Category Example Lead Time
Minor Update to Java 3 days
Significant .com release 5 days (Plus CAB)
Major Datacentre switch replacement 10 days (Plus CAB)
Emergency Major Incident resolution Immediate (Plus ECAB)*

Change Assessment & Lead Time
Change Raised
Change Manager
Circulates RFC to
CAB for
Assessment
5 days notice
Change Manager
& relevant
approvers agree
& schedules RFC
3 days notice
Change Manager
Circulates RFC to
CAB for
Assessment
10 days notice
CAB Estimates
Impact, Resources
Schedules
Changes
Endorsed?
Authorized?
RFC Rejected &
Closed; Initiator
Informed
Yes
No
No
Yes
Category 1
Minor
Category 2
Significant
Category 3
Major
Implement Change
Why the lead time?
Lead time is there to allow
approvers time to review
and approve too. The
bigger the risk, the more
comprehensive the review
to protect the
organisation.
Think carefully about your
lead times. They can be a
rally point for resentment
but they ARE important!

Change Definition - Emergency
A change is considered Emergency when it meets ALL of
the following criteria:-
• The change is unplanned and unforeseen
• The change is deemed to have a ‘Business Critical Impact’ and is seen to be
necessary to prevent disruption or further disruption to the production
environment.
Please note that a ‘Business Critical Impact’ could also include the following areas:-
• Changes required by Security
• Changes required by a sudden change in legislation / regulatory rules, or to
resolve an incident that means that something required by legislation is no longer
occurring
• The change is categorised as significant or major.
• The change requires implementation prior to the next Change Advisory Board (CAB)
meeting.
• The change has been deemed to be an emegrnecy by the CAB/EC

 If the process cannot
be broken, it will be
shattered.
Tips from the trenches
Tip
Plan for the process
to be broken!
 This process is in place
to protect the
organisation.
 They are the shields
 Who is only person
allowed to drop the
shields?
20

Emergency Changes – Special Powers
• The change is implemented as soon as it is possible.
• The change assessment and approval may happen verbally.
• Associated change documentation (i.e. the change form) can be
completed retrospectively BUT must occur within 24 hours of the RFC
implementation.
• The CAB/EC may choose to postpone any testing of the change until
after the change has been implemented.
• After completion the urgent change must be subject to a Post
Implementation Review conducted by the Change Manager. Both to
assess if any issues are likely to occur in the future as a result of the
change as well as if the change could have avoided being deemed an
emergency.

Change Approvers - ECAB
 If you have MIM then involve them.
 Suggested Policy
 Break Fix = MIM is ECAB
 Business Requirement = Full ECAB
 OOH its break fix ONLY
 Don’t forget to support and train your MIM!
22

Change Categories
 Unplanned
 For instances where a change requires implementation urgently, but
does not meet the definition of an Emergency change, it may be
included as an ‘Unplanned Change’ and follow the same process.
 In addition to the Emergency Change Process characteristics an
unplanned change must:-
 Be authorised by the relevant team manager
 However an unplanned change should be reviewed upon
implementation by the Change Manager to ascertain
 1) Any unanticipated side effects.
 2) Why the Change was unplanned.
 This information should be presented to the Head of IT Operations
and fed back to the authorising team manager, along with any
disruption or additional costs incurred due to the unplanned change
being implemented.
23
Possible deterrent
policy:- The
requester of an
unplanned
Change will be
required to
explain to the
Head of IT why
the RFC could not
follow normal
process

Change Approvers - CAB
 Change is a meeting. Learn
how to run meetings!
 CAB is a VERY important
meeting. Do your homework
 Let people leave when they
are done (if relevant)
 Use the other tools available
to you. CMDB, Service
Catalogue
 Involve Problem Management
as participants
24

Change Review
 ITIL Best Practise is to review every change.
 EVERY Change?! How much time do you think I have?!!
Suggested Policy
 Review EVERY Emergency Change
 Review EVERY Failed Change
 Review EVERY Major Change
 Sample review the rest
ALWAYS make time to review at least some changes. It’s the only
way you learn.
26

My suggestions...
 MTTA per category - Performance
 Number of Incidents caused by changes - Quality
 % Changes successful - Value
 % reduction in emergency/ unplanned changes - Compliance
 Number of Changes broken down by Category:- Workload
 “We dealt with 957 changes, implementing 85% of them on time
and successfully.
 We reduced the number of change related outages from 3 a
month to 3 every 6 months
 We have also reduced the average MTTA for changes by 30%
since the process started and less than 10 changes made had not
been fully cleared by the process first
27

What will Change management look like in the
future?
Successful Change Management
Should:
We will deliver those benefits by
 Minimizing unnecessary admin while
increasing the understanding of the
risks involved in change
 Only asking those who have a genuine
expertise in the areas involved in a
change for comment or approval
 Reduce risks inherent in change
 Minimize change impact
 Ensuring that the change process is
understood across the board and risks
mitigated.
 Reduce costs and time to both IT and
the business
 Remove unnecessary admin from
technicians
 Working to reduce the admin required
to submit and progress a change
 An increased focus on the use of pre
approved changes
 Be seen to increase change success
rates
 Measuring and publishing the value
added by Change Management in an
easy to understand way

Some Golden Rules
 Problem Management are
your eyes and ears. Work
with them.
 Most failed changes come
from failure of a process,
not technology. Include
those in your reviews and
fix things
 Talk to the Service
Desk…a lot!
 I’m not kidding about those
Doughnuts..
 Change Management without
Standard Changes is
inexcusable. It WILL fail!
 Actively work to reduce admin.
You have an ITSM tool. Never
keep a dog and bark yourself!
 Bring Doughnuts to CAB
(Seriously)
 Have change training as part of
IT staff onboarding. Use the
hook of ITSM toolset training if
you can

Questions?
p.hubbard@pinkelephant.co.uk
info@pinkelephant.co.uk
www.pinkelephant.co.uk
Please rate our webinar.
What are we doing well? How can we make it better?
30
Follow us:
30

How to make Change Management work in the real world

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

How to make Change Management work in the real world