Change Management

- Premanand Lotlikar

24th July, 2007

 Agenda
• Introduction
• Objective of Change Mgmt
• Basic Concepts
• Benefits
• Relationship with other processes
• Activities in Change Mgmt
• Process Control
• Key Performance Indicators
• Cost
• Possible Problems
 Introduction
• Change is the only constant!
• Incidents lead to Changes and vice-versa
• Motto of Change Mgmt:
“Not every change is an improvement, but every improvement is a change”

http://www.nextslm.org/itil/video5.html
 Difference b/w Change Mgmt &
Change Control
• Change Control is “the procedure to ensure that all
changes are controlled, including the submission, analysis,
decision making, approval, implementation and post
implementation of the change”.
• Change Mgmt is “the process of controlling changes to the
infrastructure, or any aspect of services, in a controlled
manner thus enabling approved changes to be
implemented with minimum disruption”
Change Mgmt - Lifecycle
 Basic Concepts
• Change Manager
– Responsible for filtering, accepting and
classifying all RFCs
– For obtaining reqd authorizations
– Also for planning and coordinating the
implementation of change
– Supported by Change coordinators. Main job is
liaising
 Basic Concepts
• Change Advisory Board (CAB)
– Meets regularly to assess, prioritize and plan
changes
– Members consists of Change Manager (chair),
Service Level Manager, Representative of
Service Desk and Problem Management, IT
Line Managers, Business Managers, User
Group Representatives, Application
Development representative, Supplier reps
 Basic Concepts
• Standard Changes
– Routine tasks (Service Requests)
– E.g. creating user Ids, installing PCs
– NOT CONTROLLED BY CHANGE MGMT
– Not to overload CM and make it less
bureaucratic
– Done according to Change models
 Objectives & Benefits
• To minimize IT failures caused by changes made
to IT infrastructure
• Efficient and prompt handling of changes
• Ensure standardized methods and procedures are
used
• Assess risk, impact, cost, and resource
requirements for all change requests
• Maintain balance between impact and cost
• Improved Quality of IT Services
• Business alignment indicator
Relationship with other processes
Relationship with other processes
• Incident Management has two sided relation
with Change Mgmt
– CM puts through changes requested by IM
– On other hand, changes may lead to incidents
Relationship with other processes
• Configuration Mgmt and Change Mgmt are
tightly coupled
– Change Mgmt records changes in CMDB
– CMDB provides information to Change Mgmt
to avert adverse impact
Relationship with other processes
• A change leads to modification of data in
CMDB:
– A change in the status of an existing CI
– A change in the relationship b/w the CI and
other CI’s
– A new CI or variation of an existing CI
– A new owner or location of the CI
Relationship with other processes
• Problem Mgmt and CM are interlinked
– Changes are often requested to correct errors
– On the other hand changes, if not controlled
adequately can introduce new errors
Relationship with other processes
• Service Level Mgmt may be represented on
CAB, depending on situation
– CM reports to SLM in form of Projected
Service Availability (PSA) report
– PSA lists changes to the agreed SLA and
impact of the Forward Schedule of Changes
(FSC)
Relationship with other processes
• Availability Mgmt initiates changes that
improve service availability
– Verifies if intended improvement is actually
obtained
Relationship with other processes
• Capacity Mgmt should primarily be
concerned with the cumulative effect of
changes over a period of time
– On basis of capacity plan, Capacity Mgmt will
regularly propose enhancements and changes in
the form of RFCs
Relationship with other processes
• IT Service Continuity Mgmt
– Prevention measures and recovery plan should
ensure that changes should not make the
continuity plan unworkable
 Activities
• Recording
• Acceptance
• Classification
• Planning and Approval
• Coordination
• Evaluation
 Recording
• All RFCs have to be recorded or logged
• Where do RFC’s originate?
– Problem Management
– Customers
– Legislation
– Suppliers
– Projects
– All other IT personnel
 Recording
• Information that could be recorded in RFC
– Identification no of the RFC
– Associated problem/known error number
– Description and identification of relevant CIs
– Reason for the change including justification and
business benefit
– Current and new version of the CIs to be changed
– Name, location and telephone no of the person
submitting RFC
– Estimated resources and timeframes
 Acceptance
• After recording the RFC
– Initial assessment to check if any RFC is
unclear, illogical, impractical or unnecessary
• Such RFC’s are rejected, stating reason
• Person submitting the RFC should always
be given opportunity to defend his case
 Acceptance
• After acceptance of the RFC, the following information is
added:
– Assigned priority
– Assessment of the impact and required costs
– Category
– Date and time of authorizations
– Backup plans
– Support requirements
– Implementation plan
– Planned implementation date of the change
– Date of evaluation
– Test results and observed problems
– Reasons for rejection of request (if any)
 Classification
• Once an RFC has been accepted, its priority and
category are specified
• Priority indicates how important a change is
relative to other RFC
– Derived from urgency time scale
– Priority may have been added by Problem Mgmt
– Change Mgmt allocates final priority code after
considering all other RFC’s
 Classification
• Priority code system
– Low priority
– Normal priority
– High priority
– Highest priority
• Codes could be associated with number
– Low = 1
– Highest = 4
 Classification
• Category is determined based on the impact of the
change and the demand it makes on IT
organization
– Minor impact
– Substantial impact
– Major impact
• Codes could be associated
– Minor = 1
– Major = 3
 Planning and Approval
• Change Mgmt uses Forward Schedule of Changes (FSC)
• FSC contains details of all approved changes and their
planned implementation dates
• CAB advise on the planning of significant changes, the
availability of personnel, resources, costs, affected service
aspects and ensuring that customers are involved
• Approval consists of 3 aspects:
– Financial approval
– Technical approval
– Business approval
 Planning and Approval
• Agenda for CAB Meetings
– Unauthorized changes
– Authorized changes that have not been
submitted to the CAB
– RFC’s which must be assessed by the member
of the CAB
– Open and closed changes
– Evaluation of past changes
 Planning and Approval
• Estimating the impact and resources
– Capacity and performance of the affected services
– Reliability and recoverability
– IT Services Continuity Mgmt plans
– Back-out plans
– Security
– Impact of the change on other services
– Recording and approval
– Required resources and cost
– Required cycle time for change
– New resource to be purchased and tested
– Any conflict with other changes
 Coordination
• Important phases are building, testing and
implementation
• Building
– Not all changes have a build phase
– May include creation of new s/w version
– New documentation, manuals, installation procedures,
back-out plan and h/w changes
– Change Mgmt provides control and coordination
 Coordination
• Testing
– Back-out procedures, change implementations
and envisaged result must be tested
– Need of separate test environment
– User acceptance testing
– Operational testing
 Coordination
• Implementation
– Relevant department is assigned
implementation of change
– Ensure change is on schedule
– Clear communication plan indicating who has
to be informed of the change
 Evaluation
• Implemented changed must be evaluated
– Did the change lead to the required objective?
– Are the users satisfied with the results?
– Were there any side effects?
– Were the estimated costs and efforts exceeded?
• Results are included in the Post
Implementation Review (PIR)
Activity Chart
 Process Control
• Management Reports
– No of changes implemented in a period
– List of the causes of changes and RFC’s
– No of successfully implemented changes
– No of back outs and their reasons
– No of incidents related to implemented changes
 Key Performance Indicators
• No of changes completed per time unit, by
category
• Rate at which changes are implemented
• No of rejected changes
• No of incidents resulting from changes
• No of back outs related to change
• Cost of implemented change
• No of changes within resource and time estimate
 Cost
• Personnel Cost
• Tool Cost
 Possible Problems
• Paper-based systems are difficult to use
• Resistance against umbrella Change Mgmt
authority
• Attempts to implement changes without
going through the agreed procedures
Thank you!