Changes – short for ITIL's term "Request for Change (RFC)" – refers to any changes being made to the service or any of its components (including configuration items). Change records allow technicians to not only justify why time and money is being spent on the change effort, but also to track and streamline the effort and any other components that might be related. Changes can stem from many sources, such as fixes for incidents or problems, new or improved functionality within the service, additions or modifications to configuration items or updates to the service (e.g., new compliance obligations). Service Desk change forms are designed to enable the following development process: planning, approval, building, and testing.

The correct ITIL term for a Change is an RFC (Request for Change) - we simply refer to them as 'Changes' in Service Desk for the sake of simplicity. Changes a pretty self explanatory - basically any change to a service or to something that will affect a service should be defined and logged as a Change. Change Management allows you to justify any change, have that change go through an approval process, plan the urgency and impact and allocate resources. You should also be able to tightly manage the plan, build and test phases of a change. An in-depth description of change management can be found on Wikipedia's ITIL page.

Objective: To track and manage the planning, building and testing of changes to services.

Change management enables technicians to easily collaborate and move a change through its lifecycle, from planning to building to testing. In addition, it enables technicians to justify the business need for changes and ensure the organization is putting its resources in the right place. It's easy for IT departments to focus on adding features just because they seem "better" or "cooler," but ultimately those things might not add value to the organization in the overall scheme of things. Change needs to be managed and streamlined to ensure that development is kept on budget without compromising quality, as well as to keep negative business impact to a minimum – Service Desk addresses this with a built-in change approval process. Seamless linking between incidents, problems, changes and releases allows the organization to have an easy audit trail that will keep even the most rigorous of auditors happy.

Logging and managing changes allows agents to do the following:

• Prioritize its urgency
• Justify and plan it
• Complete an approval process
• Allocate resources
• Tightly mange the planning, building and testing phases

Administrators can configure change settings to suit the organization's needs. The settings for changes can be managed on a per-service basis, as detailed in the following related articles:

• Set Priority Levels (Problems, Changes and Releases)
• Set Types
• Set Categories
• Add Custom Fields
• Set Approvers (Changes and Releases)
• Set Up Triggers
• Create, Configure and Manage Services

Learn how to create, build, test and close changes as well.

Change management enables technicians to easily collaborate and move a change through its lifecycle, from planning to building to testing. In addition, it enables technicians to justify the business need for changes and ensure the organization is putting its resources in the right place. It's easy for IT departments to focus on adding features just because they seem "better" or "cooler," but ultimately those things might not add value to the organization in the overall scheme of things. Change needs to be managed and streamlined to ensure that development is kept on budget without compromising quality, as well as to keep negative business impact to a minimum – Service Desk addresses this with a built-in change approval process. Seamless linking between incidents, problems, changes and releases allows the organization to have an easy audit trail that will keep even the most rigorous of auditors happy.

The process of completing changes from beginning to end can essentially be split into 3 phases, each of which is represented on the change form: planning, building, and testing, plus review.

First, determine exactly why the change is being proposed in the first place. This ultimately boils down to the following questions: 

• How will the organization benefit from the change?
• How much will the change cost the organization? 

Once those questions have been answered, the relevant stakeholders must decide whether it's truly beneficial for the change to be approved. This is what ITIL calls a CAB (change advisory board) meeting. CAB members would normally consist of technical staff, but also include business representatives as well.

While you likely have things like impact analysis, risk factors and the impact of not completing the change to consider, at the end of the day it’s a trade off between the benefits that the change is going to bring versus the cost it will take to implement it. In the end, it's the business that should decide what gets done and what doesn't, not the IT team.

Once a change is approved, it’s important to keep tabs on how the build of the change is progressing. While this step seems obvious, it's quite easy to just start developing without tracking the effort. In order to ensure that everything is going to plan, it's crucial that the development process be documented using the change record so that the relevant stakeholders can track the progress.

Once a change is built, it’s always wise to put it through the quality assurance process by having the stakeholders review it and ensure that it's up to the appropriate standard. Put simply, it should be tested from beginning to end. This crucial part of the change process includes testing, raising issues and fixing them, and then repeating the process until it is up to the right standard.

Finally, it’s always worth reviewing how the change went, including what was done well, what was not done well, and taking note of what can be done better next time. This will help streamline the process for next time, which in turn improves your overall change management.

Related articles

Create and Approve Changes

Build Changes

Test Changes

Close and Delete Changes