The Change Management Process Flow
ITIL provides a framework that is adaptable to meet individual organization’s service delivery and support requirements. Designing a standardized change management process that is sanctioned by management will aid in quickly, economically and effectively managing changes when they occur. The process can then be automated by service management support software. Change control is a subordinate element of the overall change management process designed to ensure changes are controlled, recorded, analyzed and approved.
A typical Change Management Process includes the following activities:
1) Create & Log the Request for Change (RFC)
A Request for Change is typically created by the individual, process or business unit requiring the change. Depending on the type of change, an RFC record will contain varying information necessary to make decisions for authorization and implementation of the change, including, identifying information, a description, configuration item incurring the change, a reason for the change, requestor’s contact information, type of change, timeframe, costs, back out plan and business justification.
2) Review Request for Change (RFC)
Each Request for Change should be reviewed and prioritized by the change authority for business practicality. These requests can be rejected and returned to the submitter or management as notification or in request of more detail. These unapproved changes should be monitored and closed as needed.
See a Demo: Ivanti Neurons for ITSM - Change Management
3) Evaluate the Change
Evaluating the change to assess the impact, risk and benefits to IT services is critical in order to avoid unnecessary disruption to business operations. For certain types of changes, such as major changes, a formal change evaluation takes place by the change evaluation process and is documented in a Change Evaluation Report. Impact assessment will consider the impact on the business, infrastructure, customer service, other services – both IT and non-IT services, implementation resources and currently scheduled changes in the change log. A Change Advisory Board (CAB) can also evaluate changes. The CAB can consist of various stakeholders such as the service owner, technical personnel, and/or financial personnel to help evaluate the need for the change.
4) Approve/Authorize the Change
Change requests commonly require authorization prior to implementation and each change requires authorization from the appropriate authority level depending on type of change (strategic, tactical, operational). This varies across organizations, but commonly depends on the size of the business, anticipated risk of the change, potential financial repercussions and the scope of the change.
5) Coordinate Implementation
Once authorized, a change request or the change record is handed over to the release and deployment process for coordination and collaboration with the appropriate technical and/or application management teams for building, testing and deploying the change. Each change should have remediation plans prepared in the case of an implementation failure. Once building and testing are complete, release and deployment should notify the change manager of the results and suggested implementation requirements. The Change Manager should schedule each CHANGE based on the suggested implementation requirements and the management of business risk. The Change Manager using a Forward Schedule of Changes (FSC) or Change Schedule will communicate to all stakeholders upcoming changes that may impact them. The FSC along with projected service outages (PSO), or expected deviations in service availability, will be taken into consideration when coordinating change implementation. Release and Deployment will be responsible for the implementation and coordination of training needs.
6) Review and Close Change Request
Upon completion of the change, a Post Implementation Review (PIR), which is a review of the detailed implementation results, should take place to confirm the change has successfully achieved its objectives. If successfully implemented, and the change was associated with fixing and error in service all associated problems and known errors should be closed. If not successful, the remediation plan should be activated appropriately.
A Change Management policy should also be defined to support the process. This policy might include, defining what an emergency change is; implied benefit of the process; encouraging a change and ITIL friendly business culture, establishing roles and responsibilities for various change management activities, restricting change management access to authorized staff, risk management, and performance measurement.