AD | Application | AWS | Azure | Cloud | Database | Enterprise | Environmental | Event Log | File System | IoT | IT Service | Network/System | Infra | Performance | Protocol | SaaS | Security | Service Level | Storage | Linux | VMware | VoIP | Web | Wireless | SNMP

Crumbtrail

MonitorTools.com » NetTech Insights » ITIL Insights » Processes » Change Management

Change Management

The Change management process depends on the accuracy of the configuration data to ensure the full impact of making Changes is known. There si therefore a very close relationship between Configuration Management, Release Management and Change Management.

Details of the Change process are documented in SLAs to ensure that Users know the procedure for requesting Changes and the projected target times for, and impact of the implementation of Changes.

Details of Changes need to be made known to the Service Desk. Even with comprehensive testing there is an increased likelihood of difficulties occurring following Change implementation either because the Change is not working as required or expected, or because of queries on the Change in functionality.

The Change Advisory Board (CAB) is a group of people who can give expert advise to the Change Management team on the implementation of Changes. This board is likely to be made up of representatives from all areas within IT and representatives from business units.

Change Management consists of five steps.

The one person who is most responsible and accountable for change management is the change manager. The change manager is more of a role, depending on the size, complexity and structure of your IT organization, there may be more than one person playing the role of change manager for assisting with several activities. The change manager plays a leading role in many of the major activities of change management as follows:

 

Change Management - Assessing the impact of changes

Having discussed the process of change in some depth, a word of caution is needed. Because electoral systems have psychological as well as mechanical effects, the long-term effect of changes may take some time to work through. Parties, candidates and voters may take two or three elections to fully observe and respond to the effects and incentives of particular changes. The tendency towards mixed systems may accentuate this, as the overall effect on candidates and voters of mixed incentives may be less clear.

First, it's important to understand the level of change that needs to take place in order to achieve your business objectives, so as to have a realistic appreciation of the effort required and the hurdles you will face along the way. We've categorized change into 3 broad levels, and provide a few examples below (slowly glide your mouse on the blue symbols for explanations):

Change levels

 

Change Management - Change Advisory Board

The CAB is a cross-functional group set up to evaluate change requests for business need, priority, cost/benefit, and potential impacts to other systems or processes. Typically the CAB makes recommendations for implementation, further analysis, deferment, or cancellation.

The Change Advisory Board (CAB) is a concept defined in ITIL V2 and V3's Change Management process and is a body that exists to support the authorization of change and to assist Change Management in the assessment and prioritization of change. The CAB is usually consulted for significant change that have a broad or major impact to the organisation. The CAB may be asked to consider and recommend the adoption or rejection of change appropriate for higher level authorization and then recommendations will be submitted to the appropriate Change Authority.

Similar in concept to the CAB is the Emergency Change Advisory Board (ECAB). This is done as part of the Emergency Change procedure which is used to process a change request related to fixing an error in the IT infrastructure that has major impact to the business if it is not fixed quickly, hence the Emergency Change. An ECAB is necessarily formed since there is often not enough time to convene a normal and larger scale CAB meeting.

The Change advisory board (CAB) delivers support to the Change Management team by approving requested changes and assisting in the assessment and prioritization of changes. This body is generally made up of IT and Business representatives that include: the Change Manager, User managers and groups, technical experts, possible third parties and customers (if required).

The CAB members should selectively be chosen to ensure that the requested changes are thoroughly checked and assessed from both a technical and business perspective. The considered change will dictate the required personnel to convene in a CAB meeting. These entities are not required to meet face-to-face on each requested change, but rather use electronic support and communication tools as a medium. It is however advised that a quarterly meeting is scheduled to review outstanding changes, signitilfoundations.comff on approved changes and discuss any future major changes.

Any Request for Change (RFC) should be circulated in advance to allow the CAB members whether to attend in person, send a representative, or communicate via the Change Manager.

A standard agenda may also be used to conduct the CAB meetings.

 

Change Management - Authorizing changes

Approvals for changes can be specified in one of several ways.

Using automated approvals, emails will be sent out informing the appropriate user that they need to approve the change. They can either update the Approval field on the form, or can simply respond to the email if the appropriate inbound email action is configured.

change authorization

In this activity, a change is approved, dismissed or cancelled. Change Authorization takes into account the priority and category of the change, as well as the projected costs, time and resource constraints. The decision concerning the Change Authorization must be reflected by the Change Record. The decision between approval or dismissal of the change is met by the Change Authority (CA) responsible for that respective change. The nature of the CA depends on the category (risk) of the change. That is why the CA can either be the Service Owner of the affected service, the CAB, or the Senior Management after a consultative meeting of the CAB. The Change Record is then shifted into the status "authorized-approved" or "authorized-dismissed" depending on the vote of the CA.

To authorize, the following factors have to be taken into account:

Activity Specific Rules

 

Change Management - Forward schedule of changes

The objective of the Forward Schedule of Change (FSC) is to inform the recipients of the upcoming changes which will be implemented in the next period and beyond. There should be enough information in the FSC for the person reading to determine whether the change is going to affect them and to be able to view the change request in detail by having key data.

A simple form of FSC would be like RFC No. Change Summary, Planned date of implementation and status of the RFC. The FSC should be available for everyone within the organisation. It just acts like the change calendar for external users. What it does is enables the IT and business people to schedule their RFC accordingly.

Changes to IT applications (or infrastructure) must be scheduled and communicated well in advance to identify dependencies and avoid risks to the production environments. The Forward Schedule of Changes (FSC) is the document used to communicate change plans to the organization. Use this template to:

Ideally, the FSC should be part of an automated configuration/change management or IT service desk solution. If such a solution does not exist, employ this FSC template.

 

Change Management - Requests For Change (RFC)

To be frank, requests for changes need to be reviewed by the management team. Some requests simply are not practical or feasible. Some requests may be a duplication of efforts. So the first step of change management, is to review the requested changes and assure only practical realistic changes are setup to be given focus by the IT resources.

The Request for Change (RFC) is formal request for the implementation of a Change. A Request for Change is to be submitted to Change Management for any non-standard Change (a set of standard/ routine Changes is usually defined by Change Management; these are minor Changes which do not require submission to the Change Management process). A Change is backed by a Change Owner, holding a budget for its implementation. In many cases the Change Owner is identical with the RFC initiator. Typically Changes are owned by Service Management roles (e.g. the Problem Manager or Capacity Manager) or by IT management. The RFC is a precursor to the Change Record and contains all information required to approve a Change. Further information is added as the Change progresses through its lifecycle. The level of detail depends on the size and likely impact of the Change. Often there will be references to further documents containing more detailed information, e.g. a detailed Change proposal.

As major Changes are typically implemented as projects, the RFC often takes on the role of what is also known as a "Project Charter".