|
Creating and approving
requests for change
|
The frequency of creating requests for change will depend on the
amount of change you undertake. It is good practice to use the
request for change cycle as a way to trigger the appropriate
planning stages. It is appropriate, therefore, to begin a request for
change as soon as a change is identified and add to it as the plan
develops.
Request for change instructions and the template can be found in
toolkit, downloads
|
|
Communicating changes
|
ICT system users should be given as much advance warning of
ICT system downtime as possible in order to minimise disruption
to their work and plans. It may also be a good idea to issue a
reminder shortly before the downtime.
The service desk staff also should be given as much notice as
possible, as the potential impact of the change may have a direct
effect on their plans and workload.
|
|
Monitoring the Change
Management process
|
Measurements can be taken and reported weekly if you have a lot
of changes, or monthly if there are not so many.
It is important to be consistent in frequency so that the emerging
trends are not distorted. The frequency can be reviewed and
changed, but it is best not to switch randomly between weekly and
monthly.
|
|
Making decisions
|
Reports should be reviewed as frequently as they are issued and
trends identified as they appear. Actual causes of trends will be
easier to identify if the data is recent.
|
|
|
|
|
|
