Changes and modifications can be subdivided into four categories. Depending on the impact on users and other systems, a change is considered to be one of the following;
- A new application or service development.
- Adding a new function to an existing application or service.
- Changing, modifying, or upgrading an existing application or service.
- Adding, changing, modifying or upgrading software or hardware.
Surveys performed and commissioned by the Information Technology Process Institute have found that on average 80% of service outages were self-inflicted. In these cases, IT made self-authorized and often undocumented changes to their infrastructure that resulted in unplanned work being performed to correct the problem. Additionally, they found that 80% of the time that was spent resolving the problem was determining what had changed in the first place.
The goal of this document is to provide a methodology to easily track changes using our existing systems and by tracking our changes reduce our mean time to recovery (MTTR). We will achieve this goal by implementing and following the rules within this policy.
WHEN DOES THIS POLICY APPLY?
This document applies to changes proposed by both our clients and ourselves. There are two scenarios where you do NOT need to go through the change management process:
- You are making a change to an end-user workstation that has no implications outside of the machine.
- You are making a change that has a corresponding checklist.
Below are some examples of when the policy does and does NOT apply.
A client calls because they want an email address deleted from the email server. If the address is a user account and we are using the User Termination checklist then the change management process does NOT apply.
A client calls because they want an email address deleted from the email server. If the address is not a user address (info@, scanner@, help@, etc.) then this change is neither in a checklist nor contained within a workstation so you must go through the change management process.
A client calls because they would like to create a VPN account for one of their employees. As this change is neither in a checklist nor contained within a workstation you must go through the change management process.
A client requests a new user setup / termination / email migration. We have checklists for this. Confirm that the client's request is logically sound and schedule the task.
A client requests a change that we do not have a checklist for but you feel we should make one. Use the change management process and send an email to the team with your suggestion. If the team agrees we will create a new checklist which can then be used for future requests.
HOW DOES IT WORK?
There are three required stages that correspond to three service desk macros.
- Macros > Change Management > Stage 1: Planning
- Macros > Change Management > Stage 2: Approval & Scheduling
- Macros > Change Management > Stage 3: Execution & Verification
There is an additional macro for when a change is canceled or pending:
- Macros > Change Management > Change Canceled / Pending
Each macro has a set of pre-populated tags associated with it to quickly track and locate (search for) previous changes. Five of the tags used in our change management process should NOT be removed:
The following tags can and should be removed if they do not fit with the particular change:
Let's walk through the process...
A change is requested by a client. The change is outside of a workstation AND a corresponding checklist is not available. Select the Planning checklist, fill out the information and save it as a private comment in the current working ticket. You will notice that the ticket will auto-populate with a variety of tags. Remove any tags that do not correspond to your change.
Once the planning template is complete it is time to get another engineer involved. This can be any other available engineer on our team. The two of you discuss the change. Be critical and thorough.
There will be one of three outcomes: APPROVED / CANCELED / PENDING
If APPROVED then select and fill out the Approval and Scheduling macro. If CANCELED or PENDING then fill out the Change Canceled / Pending macro. Be sure that you document WHY the change has been canceled or is pending and who is in charge of the next steps.
Let's assume that your change has been planned and seconded by another engineer on our team. You have filled out the Approval and Scheduling macro and the day has come to finally execute. Proceed with your scheduled change and complete the Execution & Verification macro. Be sure to take screenshots to verify that a) you performed the change b) you performed the change correctly c) can prove to the client that the work was performed.
Q: The client says it is an emergency and I agree. Can I make the change without going through this process?
A: No. There is no excuse for side-stepping this policy.
Q: The client says it is an emergency and I agree. No one is available to review my change plans. Can I skip approval and move to execution?
A: No. There is no excuse for side-stepping this policy.
Q: What do I do if I cannot reach another engineer to move the change forward?
A: The change will wait. If it is an emergency contact your manager on their mobile number.
Q: This process slows me down. Is there a way to streamline it?
A: This process is in place to make changes manageable and easily searchable, increase accountability, decrease unplanned work resulting from 'cowboy' changes and increase the uptime of the devices we manage.
THE BOTTOM LINE
We take the time to document and enforce change management so that we get our time back. We are critical and thorough at the start so that we do not overlook something that would end up costing hours of work — and downtime — later on. We PLAN, we APPROVE and we EXECUTE to ensure that our clients receive the most detailed, thorough, and consistent support and advice.