Good preparation can make the difference between a successful implementation of
a process and an unsuccessful one.
|
Roles and
responsibilities
|
The first step is to identify the process participants and
assign roles and responsibilities. We recommend that for
the initial implementation you involve as few people as
possible so that the tasks can become familiar with minimum
impact on the day-to-day workload of the school.
|
|
Training
|
After you have assigned roles and responsibilities, it is
important to ensure that those participating in the
implementation and subsequent operation of the process
understand what is required of them. Use this website as
training material.
|
|
Start date
|
Set a start date. A 'go-live' date is important in any
implementation. Make sure that you allow enough time to do
all the other preparatory tasks before your go-live date.
|
|
Communication
|
Communication must take place within the implementation
team to agree plans, schedule dates and so on, but it is also
important to communicate externally and inform the user
community of the new process.
The implementation of a process can be seen as a change
just like the upgrading of a server and the impact on the user
community should be communicated to them clearly in
advance of the change.
|
|
Materials
|
Before you can go ahead with the implementation, you will
need all the materials required for the process. Make sure
that you have downloaded the templates you need and that
everyone involved has access to them.
|
|
Pilot
|
Carry out a pilot implementation first as a test. To do this,
complete a request for change for one change to familiarise
the participants with the process. Then conduct a review and
discuss any issues. When you are happy that everyone
understands the requirements and that all roles are
adequately fulfilled, you can raise a request for change for all
changes as they arise.
|
|
|
Assigning roles and responsibilities in Change Management
|
Role
|
Suggested representative(s)
|
Comments
|
|
Originator
|
Person responsible for carrying
out technical changes, eg:
- technician
- ICT co-ordinator
- network manager
- supplier.
|
- You can have as many
originators as there are people
responsible for technical change.
|
|
|
- Person who manages
technical support or ICT, eg:
- ICT manager
- ICT co-ordinator
- network manager
- ICT teacher.
|
- It is likely that there will be only
one initial approver in a school.
This will be the person who is
responsible for the management of
ICT.
|
|
|
- Technical person who can
confirm that the change plan is
technically sound and
appropriate, eg:
- another technician
- network manager
- supplier
- technician from another
school.
|
The peer reviewer should be
someone other than the originator,
as they are reviewing the
originator's change details.
It is permissible to omit the peer
review step from the process when
initially implementing Change
Management, to simplify the
process.
|
|
Final approver
|
Person who has authority or
delegated authority to give the go-
ahead to make the change as
planned, eg:
- headteacher
- ICT manager
- ICT co-ordinator
- another teacher.
|
This could be anyone who is in a
position to sanction the actual
change and agree that the impact
on the rest of the school is
acceptable (for example, any
system downtime required).
This level of participation should
eventually be extended to someone
outside the ICT area.
|
|
Implementer
|
Person responsible for carrying
out technical changes, eg:
- technician
- ICT co-ordinator
- network manager
- supplier
- teacher.
|
You can have as many
implementers as there are people
responsible for technical change.
Implementers and originators can
be the same person.
|
|
|
|
|
|
