Change Management Quick Reference

"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change." -Author unknown, commonly misattributed to Charles Darwin.

"It is not necessary to change. Survival is not mandatory." -W. Edwards Deming.

"The only man I know who behaves sensibly is my tailor; he takes my measurements anew each time he sees me. The rest go on with their old measurements and expect me to fit them." -George Bernard Shaw.

Change Management (CM) is the most complex process in Service Support. It's
importance resides on a fact that over 80% of incidents emerge from performed changes. Therefore changes should be managed. Most of the ITIL compliancy projects fail at CM. It requires a high level of collective discipline, skills and mindset.

There is a connection of Change with all other ITSM disciplines, but especially with Release, Configuration and Capacity Management.
For your convenience, here are Change Management quick reference data I gathered for my ITIL Service Manager exam:



Definitions:

• RFC - Request For Change: can be triggered from different sources: Incident/Problem resolution, introduction/upgrade/removal of the CI...
• FSC - Forward Schedule of Changes: details of all the Changes approved for implementation and their proposed implementation dates
• PSA - Projected Service Availability: contains details of Changes to agreed SLAs and service availability because of the currently planned FSC
• CAB - Change Advisory Board: a body that approves Changes and assists Change Management in the assessment and prioritization of changes, composed of major stakeholders impacted by the change and technical staff responsible for tech. implementation
• CAB/EC - Change Advisory Board / Emergency Comitee: a smaller body with authority to make emergency decisions in case of Urgent Changes
• CMDB - Configuration Management Database

Goals

• To minimize the adverse impact of change upon service quality
• To ensure standard methods and procedures are used for efficient and prompt handling of all changes
• To assess the potential benefits of change to the organization against the risk and associated costs to the organization

Picture: Change Management Mind Map


Process

• raising and recording Changes
• assessing the impact, cost, benefits and risk of Changes
• developing the business justification and obtaining approval
• management and co-ordination of Change implementation
• monitoring and reporting on the implementation
• closing and reviewing the Change requests

Inputs

• RFCs
• CMDB
• FSC - Forward Schedule of Changes

Activities

• Initiating and logging
• Initial filtering
• Allocating initial priority
• Categorization
• Assessing impact and resource
• Authorizing and approving
• Scheduling
• Building
• Testing
• Implementing
• Reviewing
• Management reporting on Change Management quality and operations

Outputs

• FSC
• RFCs
• CAB minutes and actions
• Change Management Reports

Picture 1: BASIC Change Management Process


Benefits

• Less adverse impact of changes on the quality of IT services and SLA
• A better assessment of the cost of proposed changes, before it is incurred
• A reduction in the number of changes that have to be backed-out, but an ability to be able to do this more easily
• An ability to absorb a higher level of change without difficulty
• Increased visibility and communication of changes to both business and service support staff
• Improved risk assessment
• Improved Problem and Availability mgt. trough the use of valuable management information relating to changes
• Increased productivity of key staff as less need for diversion from planned duties to implement urgent changes or back our erroneous changes

Possible Problems

• Implementing on over bureaucratic process
• Attempt to bypass the process
• Paper based system - bottleneck
• Cultural difficulties - getting buy-in
• Contracts and third parties
• Scope of change is too wide
• Ownership of impact systems is unclear
• Lack of Configuration Management
• Inaccurate configuration details leading to poor impact assessment
• Lack of management commitment
• Poor synchronization of upgrades between platforms and across locations
• Back-out procedures are missing or not tested
• Handling of urgent changes
• Progressing RFC is too manually intensive
• Complex distributed or mobile infrastructure
• Time-scales (too ambitious)
• Lack of resources (people, products)

Picture 2: STANDARD Change Management Process
Responsibilities
Change Manager:

• Receive, log and allocate priority to all RFCs. Rejects inappropriate RFCs
• Table RFCs for CAB meetings
• Decides meeting participants according to RFC nature
• Convene Urgent CAB or CAB/EC meetings for all URGENT RFCs
• Chair ALL CAB meetings
• Authorize acceptable Changes (according to CAB decisions)
• Issue FSC via Service Desk
• Liaise with all parties to coordinate change building, testing and implementation
• Update Change log with progress
• Review implemented changes
• Review all outstanding RFCs waiting consideration or action
• Analyze Change records to identify trends or apparent problems that can occur
• Close RFCs
• Management reporting

CAB:

• Review all submitted RFCs. As appropriate, determine and provide details of their likely impact, the implementation resources, and the ongoing costs of all Changes.
• Attend all relevant CAB or CAB/EC meetings. Consider all Changes on the agenda and give an opinion on which Changes should be authorized. Participate in the scheduling of all Changes.
• (CAB/EC only). Be available for consultation should an urgent Change be required.
• Provide advice to Change Management on aspects of proposed urgent Changes.

Picture 3: URGENT Change Management Process


Key Performance Indicators
Controlling Changes

• Number of RFCs processed
• Number of RFCs rejected
• Number of unauthorized changes detected
• Number of RFCs implemented on schedule
• Number of RFCs requiring reschedules

Making Quick and Accurate Changes Based On Business Priorities

• Number of RFCs marked as URGENT
• Number of RFCs not tested prior to implementation
• Number of RFCs that failed
• Number of RFCs without business case
• Number of RFCs bypassing CAB or CAB/EC

Protecting Services When making Changes

• Number of high Severity incidents caused by RFC implementation
• Number of other incidents caused by RFC implementation
• Number of RFCs without a backup strategy