ITIL Change Management: A Beginner’s Guide

1 itil Change management - A Beginner's the basics of Change ManagementTable of contentITIL Change ManagementChange management Process flowTypes of ChangesUse cases for itil Change ManagementIntegration with other modulesThe Right Approach13681113 itil Change ManagementDigital transformation and initiatives lead to new projects within organizations. Seamless business operation is a gift for businesses to improve productivity. Businesses undergo transitions on a regular basis that differ in risk and impact. It is vital to streamline this process to keep these two factors in control. Change management is significant to deploy new changes without any disruption or downtime. itil Change management follows a standard operating procedure to eliminate any unintended interruptions and capture necessary details about a Change before it is implemented such as reason for Change , planning and Change management is essential for businesses to implement changes smoothly and maintain current working state.

2 Change management works closely with other itil modules such as Incident management , problem management , configuration management to manage infrastructure and Configuration Items, CIs that are affected or going through the Change . This delivers better context and consistency so that Change team can be proactive in avoiding any potential failure. Implementing a Change is a costly affair thus Change management ensures everything is in control and even if something goes wrong, damage is risk and impactRetention of current working stateCommunication and approval managementEffective Change planning using available resourcesReduction in number of incidents due to changeShifting office space, deploying a fix to production server, windows patch, replacing cloud service provider, updating ManagementProcess flowIncident causes a new Change Change is created as a result of a known problem End user requests a new changeChange manager creates a Change as result of an ongoing maintenanceThe first step is to request for a Change with valid reasons.

3 Change requests are created due to one of the following reasonsRequest for Change proposal contains following information along with necessary detailsRequest for Change Impact and risk are calculated and documented including configuration items, the reason on why Change has to be created,affected parties and desired for changeImpact & Risk assessment Cost benefit analysis Implementation planning Steps for implementing Change that includes project members, timelines and resource utilization and cost incurred along with potential benefits are documented4 Reason for changeImpact & Risk assessmentCost benefitanalysisImplementation planningITIL Change management follows a set of processes and every detail about Change is recorded for future tracking. Following the process ensures that there are no loopholes and Change is validated to ensure successful deployment. It is helpful for other service desk teams such as release management , configuration management to understand the type and complexity of Change .

4 Change manager is responsible for successful planning & evaluation. Release management team takes care of the actual implementation of Change . Following is the Change management process flow4 Change assessment committee evaluates submitted RFC and suggests necessary changes that would be taken care by Change initiator. This is followed by Change planning that follows a standard procedure and it includes activities such as Change Evaluation and planningScheduling a Change Depending on the priority, scheduling is fixed. If it s a low priority Change , it could be pushed to the next deployment a Change After analyzing the reasons and RFC, prioritize Change request and determine Change type depending on the risk/impactIdentifying stakeholders Identifies the project members who are responsible for carrying out the implementation and members who need to approveCommunicating the Change and its details to relevant stakeholders and getting on time approval is key to success. Automate the approval process to reduce manual effort.

5 Approval process flow is decided depending on the type of Change . For example, major Change requires approval from CAB as well as management whereas standard Change does not require any CAB approval as they are pre-approved. Change request is approved only if all the CAB members approve it. Upon rejection, reassessment review is done and submitted again for CAB approval. Change approvalsOnce the Change is approved, implementation is carried out with the help of release management team. Release team follows their own processes that include planning and testing. Change review happens once implementation is completed to determine whether it s a success or failure. Review of completed changes help in revisiting and modifying existing Change management process if necessary. Change implementation & reviewRoll out plan details about implementation steps and approach Decide on the planned start date and end date Ensure there is no clash with other major activities that are scheduled 5 Types of ChangesTypes of changesMajor changes are high impact and high risk items that may alter production systems.

6 This requires CAB approval along with business approval. This has a huge impact on ongoing business operations and also has financial implications. Therefore, RFC contains a detailed proposal on cost-benefit, risk-impact analysis. Examples - migration from one datacenter to another; replacing an existing enterprise solution(ERP). Major Standard changes are generally pre-approved changes that have low impact and low risk. These changes occur periodically and follow a standard procedure. They do not follow the conventional process flow and it can be saved as a standard Change template for reuse. Every time, CAB approval is not required as these changes are evaluated and approved once initially. Examples - OS upgrade, deploying patch, setting up an user account etc. Standard changeMinor changes are generally normal changes that do not have a major impact and are less risky to execute. These are non-trivial changes that do not happen frequently but this undergoes every stage of Change lifecycle including CAB approval.

7 It is important to document related information so that this can be converted to a standard Change in future. Examples - application performance improvement, website changes are unexpected interruptions that need to be fixed as quick as possible. This does not follow the usual norm whereas retrospective RFC has to be submitted post implementation and approvals can be managed through Emergency CAB (ECAB). These changes can be reviewed later to avoid potential infrastructure risks in future and detailed documentation is done post Change execution. Examples - Fix for security breach, server outage. Emergency7 Use cases for itil Change ManagementApplication of itil Change management in BCP/DR is vital as this is one of the critical operations to ensure business continuity. This is classified as a major Change due to its high impact/high risk on live environments. This involves changes to production servers and therefore having an effective Change management is necessary. The objectives of Change management in BCP/DR includeThere are many practical use cases for itil Change management that are handled by IT and DevOps team on a day to day basis.

8 Let us look at some of the common use cases. BCP/DR has a predefined template to capture necessary details. Minimal/no disruption to the current ecosystemEffective resource utilizationHaving an approved backout plan and related backout activitiesIdentifying configuration items that may be potentially impacted due to BCP/DRProper documentation of all relevant changesCommunication of changes to all stakeholdersMonitoring service availability & metrics such as recovery time taken (RTO,RPO)Use cases for itil Change management CASE I - Business Continuity Plan & Disaster Recovery StageBCP/DRRequest for changeChange planning & evaluationCustomer reports an issue and requests for a Change that may be due to BCP/DR Change implemented. Change usually includes infrastructure manager & team reviews the RFC; analyzes reason, impact, cost associated and plan for the Change in a scheduled time frame. BCP/DR could be applicable to multiple locations. Change team should identify specific location where BCP/DR will be approvalsChange implementation& reviewGet the approvals from BCP team and other stakeholders; Communicate the new changes to all customers, vendors; update all relevant collaterals including BCP templateImplementation is carried out by release team and Change team performs periodic any security threat or breach is a typical example of an emergency Change .

9 This is generally high risk, high impact Change with time constraints. Live environments and production systems are vulnerable when you execute emergency changes. Though the fix has to be really quick, standard testing and approval by ECAB is important to avoid any unintended issues. Since emergency changes need quick resolutions, this cannot wait too long to follow a typical Change management process. Following is the usual process for emergency changesChange requester submits an emergency Change ticketChange team evaluates the risk/impact Quick Change planning is done using the template including roll out and back out plan activitiesApproval is triggered to ECAB members (Emergency CAB members)Once it is approved, Change is implemented Detailed assessment happens post Change implementationRetrospective RFC is submitted post implementation for documentation and audit purposePeriodic audit review is done to avoid any similar issue in futureCASE II - Security patchBusinesses are moving towards cloud and agile.

10 Change management in cloud is a typical example of standard Change which follows a pre-approved procedure. Release cycles have shortened leading to frequent feature releases and enhancements. Deployment in cloud environment often requires smaller units of testing and due to this, changes to production environment might happen often. Therefore, following a standard Change management process helps in controlling the risk and a Change request in order to make any changes to production there are any corresponding tickets or problems, associate them to this Change the contract with cloud service provider regarding uptime, service availability and securityPrepare a standard Change template for new releasesPlan your releases - In a multi-tenant architecture, releases need to be planned without any disturbance to existing configuration settingsPlan for backout activities - To retain current ecosystem, plan for backout activities and keep them readyUse sandbox environment for testing - Sandbox testing ensures expected and actual behavior of new releases match with each other without affecting live environment.