Table of Contents
The change process is designed to make sure any changes in the services delivered by the ICT department are properly logged and examined before implementing them. This ensures continuity and stability among related systems. Implementations of a change process can vary greatly, but a number of common policies and procedures should be in place. The explanation of handling changes in this chapter is based on a somewhat minimalist approach while still covering the key areas.
The common change process consists of the following steps: logging a request for change, discussing the request for change in the change advisory board, deciding the best implementation strategy, implementing the change in a test environment, testing related components in the test environment, updating documentation, rolling out the change into production, verifying that there are no operational issues for users, and closing the change.
The first step to get the change process started is the logging of a change request. You cannot log a change directly, because a change will always have to be approved by the Change Advisory Board as described in the next section. The change request needs to describe:
The change requested. What system needs to be changed and how?
The reason for the change request. What will this change solve or how will we benefit from this change?
A related problem or incident if it exists.
Who this change is reported by and who it is reported for.
Priority for the change will be determined by the Change Advisory Board after the change has been accepted. If a change is requested from the output of the problem process, the implementation details required can often be provided. If not this will be handled by the Change Advisory Board.