It is important as a Help Desk Manager or Agent to understand what Change Management is and how it is related to the Help Desk. In this posting we discuss what is Change Management and some of the important aspects of Change Management and the Help Desk. We then discuss what is a Request For Change, the responsibilities of a Change Manager and the Change Advisory Board, and what is a Forward Schedule of Changes. Let’s get started and discuss Change Management and the Help Desk..
What is Change Management?
Change Management is the process to submit, review, schedule, document, and if needed back out changes that may affect your Information Technology environment. The Change Management process works hand in hand with all of your other IT Service Management processes. To be effective, having the right change management tools is important. If you are able to run your Change Management activities within your ticketing software application, you will have great visibility and coordination. A recent post by Cisco confirms that Change Management is important since 80% of all outages are related to changes. Managing changes to your environment is crucial to keep your technology systems and users up and running. It is critical that Change Management and the Help Desk are in sync with each other.
Help Desk and Change Management
The Help Desk team plays a significant role in your company’s Change Management process. A member from the Help Desk should be a member of the Change Advisory Board (CAB) providing input during the change approval process. The Help Desk must be aware of change activity start and end times in case there are user calls or monitoring alerts for the impacted system. After the completion of the change, the Help Desk will look for trends in user calls and try and correlate if the change caused an issue.
Request for Change (RFC)
The Request for Change is part of the change management step and is a formal request for change to be made. A RFC includes details of the proposed change captured by a change request form. Information gathered on the RFC form is the system affected, testing completed, version of applications, specific hardware involved, impact if the change is not completed, change start and end times, back out plans, and who will be performing the change. Once submitted the RFC form is used to create a change ticket inside your ticketing application.
A Change Manager or Change Coordination will be the first to review the new change ticket. The will look for completeness of all the required fields. They will look for scheduling conflicts between changes. The system, application, and/or host that will be changed is called a configuration item (CI). If you have a Configuration Management Database (CMDB), then your change can be associated with the CI. This will allow you to analyze the impact to the system and see if this conflicts with other changes. Once the change is reviewed by the Change Manager or Change Coordinator and any updates are made by the requester, then the RFC is accepted pending Change Advisory Board (CAB) approval.
Change Advisory Board (CAB)
The Change Advisory Board is a group of people that reviews all RFCs and based on all available information, approves, reschedules, or rejects the change. The CAB may be composed of representatives of all branches within the organization, including IT Management, IT Engineers, representatives from the business, Help Desk, and possibly vendors.
Forward Schedule of Changes (FSC)
The Forward Schedule of Change is a document distributed to all concerned groups that lists all the approved changes for then next week. This includes a summary of the changes, which includes start time, end times, priority, description, CI, and a reference to the full change record. The objective of the Forward Schedule of Change 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. Awareness of upcoming changes lead to more successful implementations and reduces unplanned outages.