Step Four - Roll Outs

At the end of the pilot the plan should allow for a series of feedback sessions and both parties should agree what changes are needed to the core system specification and document these. More importantly both parties should review the actual timetable required for the pilot as opposed to the planned timetable and the actual resources required to support the pilot as opposed to the planned resources.

Any significant variances should be noted and the planned timetable for the first roll out should be reviewed and either revised backwards or additional resources brought in to keep to the original timetable. The plan should also break the roll out down by department/section or process so you have a defined number of steps. If you were rolling out to 40 departments you would have 40 discrete steps in your roll out high level plan and a plan for each step that should follow a generic format.

After that review has been conducted then you need to manage the roll out as a series of steps where each step is handled like the pilot. On a regular basis you should review the scope of the steps you have planned to see whether the scope of each step of the roll out can be expanded or should be reduced. Then for each step you should conduct the same three tasks detailed above for the pilot:

• Communications and change management

• Implementation and support

• Acceptance

We have changed the third task from "User acceptance test" to acceptance to signify that if you are rolling out a core set of functions there is less need for a formal test. Instead you should agree with the supplier a checklist of points to monitor progress with the roll out and provided each point has been met without incident you should accept the solution for that step and move on to the next step. Where a step involves a major integration with a new line of business system then you might revert to treating that step as a full pilot and agree to hold a full user acceptance test at the end of that step.