Specifying, choosing and implementing computer systems

Stage 9 - Train all users

When UAT is complete, all users will need to be trained to use their processes. Since training revolves round the tasks the user will be carrying out, the Task Database (SS 2-1 Tasks) can be used for planning.

The basic format of training is:

 Instruction in the use of the software: Logging on; moving around the screen; access to help screens; action if the system ‘freezes.

 Copy (or obtain) typical and exceptional items for input (invoices, time sheets, non-bar-coded goods, new employee forms).

 Provide to the trainee the copy forms, or items

 Provide the relevant section(s) of the manual.

 Demonstrate how to input data from the forms, using the manual as a basis. Cover exceptional circumstances (for example, refusal of a credit card).

 Let the trainee input data, with reference to the manual, under supervision of the trainer.

 Allow the trainee to input with further examples, asking questions if necessary.

 Ask the trainee for feedback on the manual.

 Record the date of final training on the Task database (SS 2-1 Tasks).

Stage 10 - Implement the system (in parts if necessary)

If the system is to be implemented in parts, the Task database (SS 2-1 Tasks).can be used the dates of go-live.

On the 'go live' date and until the system is operating without problems:

 Project manager and all stakeholder users to provide support to new users.

 Appointment of a Systems Administrator to maintain some standing data, such as access and passwords, plus liaison with the company providing software services. (Depends on size of organization implementing the systems).

 Establish a central help desk to answer users' queries.

 At the end of the first day, ask users how they feel about the new procedures. Formally record their comments.

 Review the previous day's successes and problems early on the following day. Take action as necessary, for example modify procedures and change the manual.

 After 6 weeks (so one month-end has passed) formally review the project. Did it deliver the expected output/functionality on time and within budget? Note learnings for future projects.

Regular risk assessment meetings

As already mentioned a ‘Risk Workshop’ of all the users should be held in order to identify:

 The opportunities which may arise to benefit the achievement of the objectives (for example: major improvements to the software, beneficial changes to the output required).

 The risks which may arise to threaten the achievement of the objectives (for example: loss of key staff, adverse changes to the output required).

 The risks and opportunities should be documented, scored in some way to order them in terms of importance and the means of managing them recorded.

 This list should be examined by a group of users at least monthly to update the opportunities/risks and take action as appropriate.


Home previous page site map