FITS - Change Management

This section tells you how to create and complete a request for change and what to do with it at each stage of the process.  After following the steps you will have implemented a basic change management process.

We have created a template request for change form that you may download and add to, or personalise with any existing additional steps you may already have in place - for example, additional approvers.

Step 1:  Identify change

Step 2:  Create request for change

Step 3:  Approval to proceed

Step 4:  Plan and prepare change

Step 5:  Peer review

Step 6:  Approval to implement

Step 7:  Communication

Step 8:  Implement

Step 9:  Update configuration management database

Step 10: Closure

There is also an optional change advisory committee  section which you may choose to implement or not, depending upon what is appropriate for your school.

Go back to Implementation guide

First select the change to which the change management process will be applied.

In FITS Change Management a change is the result of:

Go back to Implement

A new request for change should be created for each change.  You must do this before you buy items or spend any time preparing the change, so that you can seek appropriate approval first. 

The originator should create the request for change.  A request for change in this context should not be confused with a user request for a change to their computer or other personal ICT facilities.  This is initiated using the incident/request form and its application is described in Incident Management.  The request for change form referred to here relates to changes to shared ICT infrastructure that are initiated by ICT staff, although these may be as a result of a user incident or request.  End- users are not required to complete change management requests for change.

We have created a request for change template which you can download and use as it is or customise.  See also example request for change. The following sections on the request for change should be completed at this stage:

The unique identifier is a reference that applies only to the item to be changed.

This may be:

For clarity, the unique identifier should be entered on the request for change form, especially if the make/model/type exists more than once.

Example:

Go back to Create Request for Change

The name of the item to which the change applies should be entered on the request for change form.

This may be:

The purpose of this is to give a meaningful name to associate with the unique identifier, as it is unlikely that the unique identifier alone will immediately identify the type of equipment to the reader of the form.

Example:

Go back to Create Request for Change

A brief description of the proposed change should be entered on the request for change.

This should include:

The purpose of this is to provide sufficient information to enable the initial approver to assess the cost in time and money of carrying out the change.

Example:

Go back to Create Request for Change

A brief description of the reason for the change should be entered on the request for change.

This may include:

The purpose of this is to provide sufficient information to enable the initial approver to assess the value of carrying out the change.

Example:

Go back to Create Request for Change

Example:

Go back to Create Request for Change

Approval to proceed is granted (or not) by the initial approver, who must assess the cost and value of proceeding with the change.  If insufficient information is on the request for change to enable the initial approver to make an assessment, they should refer back for further details to the originator, who must also update the request for change for the record.

This stage of approval is important, as it prevents time and money being wasted on activities that may be inappropriate in terms of strategy and the bigger picture.  The initial approver (see roles and responsibilities) has the power to approve, reject or place on hold proposed changes as they see fit and should have the appropriate level of authority.

Go back to Implement

Once approval to proceed has been granted, the originator may plan and prepare the change in earnest. 

The following sections on the request for change must be completed at this stage:

Full details of the change should be entered on the request for change.

This should include:

The purpose of this is to provide sufficient information to enable the peer reviewer and the final approver to assess the suitability and robustness of the change and plan before approving implementation.

Example:

Go back to Plan and Prepare Change

Details of the impact of the change on existing ICT services and users should be described.

This should include:

The purpose of this is to highlight the disruption to normal day-to-day activities that are likely to occur during implementation of the change and to enable the final approver to assess whether or not the disruption is acceptable.

Example:

Go back to Plan and Prepare Change

Details of the impact and risk of failure of the change should be outlined.

This should include:

The purpose of this is to highlight the risks associated with the change if implementation does not go according to plan and to highlight the potential disruption to normal day-to- day activities.

Example:

Go back to Plan and Prepare Change

Details of a fallback plan for implementation in the event of change failure should be outlined.

This should include:

The purpose of this is to demonstrate that a plan is in place for service recovery in the event of change failure.  If a change fails, it is important that all original components are restored so that inventory records remain accurate.  See Configuration Management for further details.

Example:

Go back to Plan and Prepare Change

The date and time that the change will be implemented should be recorded on the request for change.

An estimate of the amount of time the change will take should also be included.

Example:

Go back to Plan and Prepare Change

Example:

Go back to Plan and Prepare Change

On completion of the request for change, approval to implement is recommended (or not) from a technical perspective by the peer reviewer, who must assess the change and implementation plan for technical suitability and robustness of solution.   If insufficient information is on the request for change to enable the peer reviewer to make an assessment, they should refer back for further details to the originator, who must also update the request for change for the record.

Go back to Implement

Following approval by the peer reviewer, ultimate approval to implement is granted (or not) by the final approver.  They should seek the views of affected or relevant user representatives to take part in this decision- making process.  If insufficient information is on the request for change to enable the final approver to make an assessment they should refer back for further details to the originator, who must also update the request for change for the record.

Go back to Implement

It is important to communicate relevant details of the change to affected users.  It is not necessary to distribute full technical details of the change, but those dependent upon the ICT services affected will appreciate a brief outline of the user impact.

A change communication should include:

It is good practice to present such changes in a positive light by highlighting the benefits of the change.

See the toolkit for an example of change communication.

It is also good practice to have a standard method for communication so that users can come to expect a similar format for everything related to ICT.  It may be a good idea to make one person responsible for all communications.  A consistent forum is also a good idea, for example, staff briefing meetings or intranet home page.

Go back to Implement

Following final approval and after relevant and timely communications have been issued, the change may be implemented in accordance with the plan and the scheduled date and time.

It should be recorded on the request for change whether the change was successful or unsuccessful, so that it is clear from the record what the outcome of the request for change was. 

Go back to Implement

Following successful change, inventory records should be updated to reflect the details. For example, if a file server is replaced and the old one is disposed of, the new file server needs to be recorded on the inventory with details such as make, model, serial number, asset tag number.  Details of the old one must be removed.

The following are some examples of outcomes that may require inventory update:

This activity forms part of the Configuration Management process, which is the subject of a separate section of FITS.

Go back to Implement

Congratulations, you have completed your request for change!

You should retain the signed paperwork for future reference.

Go back to Implement

A change advisory committee may be set up as a forum for the review and approval or rejection of proposed changes and change plans.

Membership of the change advisory committee should include but is not restricted to:

Consensus may be achieved via a brief meeting that may be either scheduled to take place regularly or arranged as required.  These should be treated as formal meetings

The change advisory committee is in addition to the request for change process and should be used only if it enhances the process.  It may be helpful to have a regular meeting at which all changes are discussed and approved.  But, depending upon the volume and frequency of changes, this may get in the way of change - which is not an acceptable feature of the process! 

You may find it safer to consider each change as it arises, at least until the process is familiar, to avoid wasting time in unnecessary meetings and to avoid delaying changes.  This also makes it easier to review emergency changes if all changes are dealt with as they arise.

Go back to Implement

The change advisory committee meeting should approve or reject changes.  The change manager should manage the meeting and facilitate agreement. 

Creative use of technology can be used in place of a physical meeting.  For example, you could to circulate requests for change and gather responses by email, or hold a virtual meeting via telephone conferencing.  The latter methods can be particularly useful for gaining agreement in emergencies without taking up too much time and without having to wait for a meeting.

Go back to Change advisory committee