Change Management Process
Change Management - Process Overview
A Change is nothing but of shifting/transitioning/modifying/from its current state to a desired future state.
Change management is an IT service management discipline. It is a process used for managing the authorized and planned activities like addition, modification, documentation, removal of any configuration items in the configuration management database that are a part of a business's live production and test environments along with any other environment that a business wants to have under Change Management.
Change Management focuses on transitioning new services or modifying the existing services into IT operational environment ensuring the changes wouldn’t create any outages in the IT environment.
Objectives
The objective of Change Management is to:
- Respond to the customer’s changing business requirements while maximizing value and reducing incidents, disruption, and re-work.
- Respond to the business and IT requests for change that will align the services with the business needs
- Ensure that changes are recorded and evaluated and that authorized changes are prioritized, planned, tested, implemented, documented, and reviewed in a controlled manner
- Ensure that failed changes are analyzed and RCA’s done to reduce the reoccurrence of such instances. Checkpoints are enforced to understand the progress of change and to understand the failures.
- Ensure that all changes to configuration items are recorded in CMS
- Optimize overall business risk
Scope
Scope of Change Management can be defined as:
- Architectures
- Processes
- Tools
- Metrics
- Documentation
- IT services
- Configuration Items
Interface with other Processes
The Change management process interfaces with various other Service management processes as shown in the diagram above. This diagram depicts how Change Management has operated and the interfaces associated with it.
Change Management Process
Change Management Process flow
In a practical IT environment, change management operations would generally be executed as per the below diagram:
Process Description of Change Management
Change Trigger/Input
This process starts with a Request for Change due to a major or minor upgrade to an existing service or a service request requiring a change.
Each change ticket or RFC is recorded so that it could be tracked, monitored, and updated throughout its life cycle.
Subprocesses involved in change management is defined below:
RFC logging and review
The objective is to filter out Requests for Change which do not contain all information required for assessment or which are deemed impractical. The Change Initiator requests for a Change to Service Desk who in turn; creates a Change record. Where tool access is available, the Change Initiator raises a Change record himself.
Based on the initiator’s assessment and the Change Management policy/guidelines, the change is classified as Emergency, Normal, Standard, Minor change.
Check RFC for completeness, practicability, and perform initial assessment: Consider the 7R’s of the Change Management.
- Who raised the change?
- What is the reason for the change?
- What is the return required from the change?
- What are the risks involved in the change?
- What resources are required to deliver the change?
- Who is responsible for the build, test, and implementation of the change?
- What is the relationship between this change and other changes?
Assessment and implementation of Emergency change
This phase assesses, authorizes, and implements an Emergency Change as quickly as possible. This process is invoked if normal Change Management procedures cannot be applied because an emergency requires immediate action.
ECAB will be responsible for approving any emergency changes without formally going thru the CAB meeting. The verbal or telephonic approval from ECAB will construe the change management approval. Members of CAB/EC are:
- Change Initiator
- Change Manager
- Configuration Manager
- Domain Owner(s) (As per Change requirements)
- Depending on the nature of the change, the Change manager determines the other members of the ECAB.
Categorization
Categorization determines the required level of authorization for the assessment of a proposed Change. Significant Changes are passed on to the CAB for assessment, while minor Changes are immediately assessed and authorized by the Change Manager
Assessment by the CAB
Assesses a proposed Change and authorizes the Change planning phase. If required, higher levels of authority (e.g. IT Management) are involved in the authorization process.
Change Manager schedules CAB Meeting. The CAB reviews RFC and related documents to understand the requirements of the change. The CAB determines if a Formal Evaluation is necessary for the proposed change.
CAB understands the effects of the change and identifies predicted performance. This can be determined from the requirements mentioned in the RFC, acceptance criteria, discussion with relevant stakeholders, etc.
CAB assesses risks and conducts feasibility analysis:
Feasibility analysis is performed with respect to different aspects to find if the proposed change is a viable option. The analysis could include different factors like:
- Cost-benefit (Cost-effectiveness)
- Resource availability
- Identified Risks
- Impact on other services and business impact
- Compliance requirements (if any)
Based on the assessment findings, CAB either approves the change or rejects it.
Scheduling and Building
This phase authorizes detailed Change and Release planning, and to assess the resulting Project Plan prior to authorizing the Change Build phase.
It involves other tasks like
- Preparing the FSC after considering all approved RFCs which are still open for implementation. Also, the ongoing RFC implementations are considered which preparing the schedule of changes. Changes of a similar kind are grouped together to help release planning. The change window is reviewed with the Availability Management and ITSCM process plans for consistency.
- Depending on the nature of the RFC, a decision is made on the requirement of a formal evaluation before the approval for the build is provided.
- Based on the criteria for evaluation after planning and before the build, the project plan as well as the test plan are reviewed and evaluated.
Deployment
Deployment assesses if all required Change components have been built and properly tested, and to authorize the Change Deployment phase.
Deployment determines if a formal evaluation is required before the deployment can begin. Accordingly, provide the related/relevant documents to the Change Evaluation Process and request for a formal evaluation prior to deployment.
CAB is convened to:
- Verify that all components required for the change have been built
- Verify that all components required for the change have been successfully tested
- Verify that the test results indicate that the change will meet its objectives
- Assess the Project Plan for conflicts with other planned/ongoing changes and to check resource availability
- Review the Evaluation Reports
- Approve/Reject the change for deployment
Accordingly, the change record is updated with the assessment findings of the CAB and the status of the change as appropriate. The change schedule is also updated as necessary.
Post Implementation Review and Closure
PIR assesses the course of the change implementation and the achieved results, in order to verify that a complete history of activities is present for future reference and to make sure that any mistakes are analyzed and lessons learned.
Major activities involve are:
- Determine if a formal evaluation is required to post the deployment.
- Determine if the implementation of the change achieved its objectives.
- Analyze and identify lessons learned from the whole lifecycle of the change. Collate all post-implementation analysis and assessment information in the Change Evaluation report
- Find how the implementation of change can be improved and update the CSI register for initiating SIP.
- Determine if such change is likely to recur in the future. If so, then a new change model might be necessary to handle such changes in the future.
- Update the change record with relevant inputs and set the status to “Closed” to formally close the change.
Tasks and Responsibilities
| Step | Task |
Responsibility |
| 1 | RFC Logging and Review | Change Manager / CAB |
| 2 | Assessment and Implementation of Emergency Change | Change Manager / Practitioner |
| 3 | Change Assessment and Categorization | Change Manager / ECAB / Change Coordinator |
| 4 | Change Assessment by the CAB | Change Manager / Practitioner |
| 5 | Minor Change Deployment | Change Manager / CAB / Change Practitioner |
| 6 | Change Scheduling and Build Authorization | Change Manager / Practitioner / Coordinator |
| 7 | Change Manager / Practitioner / Coordinator | Change Manager / CAB / Change Practitioner |
| 8 | Post Implementation Review and Change Closure | Change Manager / CAB / Change Practitioner |
| 9 | Change Management Support | Change Manager / Practitioner |
