During the Conference Room Pilot phase, initial drafts of the User Procedures were developed. These drafts may have been based on procedures for the system being replaced, documentation and on-line help provided with package or custom software, or job descriptions for system users.
Preparing the drafts early in the project reduces the time required for the Finalize User Procedures activity late in the project. If no draft procedures exist, return to the Draft User Procedures activity in the Conference Room Pilot phase for guidance on how to being building them.
Procedures from Documentation
In some cases, documentation provided by the software vendor represents the only set of procedures in existence at the beginning of the Procedures and Training activity. In this situation, the following steps are preferable to starting entirely from scratch:
1. Locate those portions of the vendor-provided User Guides or training materials which can be used "as-is". For example, the correct procedure for entering Accounts Payable vouchers may exactly as documented in the User Guides. (On the other hand, a User Guide's procedure for generating checks may be inappropriate for the current implementation.)
2. Cut and paste these sections into a logical sequence, a sequence in which the system users would likely access them.
3. Build procedures for the custom-developed portions of the system, and those portions for which the vendor's documentation is not adequate. Use the same format and style as the vendor's material, to ensure a consistent end product.
4. Assemble the various pieces for each user type (ex: Payables Clerk, Staff Accountant, Sales Order Entry Clerk, etc.) For a small system, a single volume may contain all procedures. Alternatively, a volume may be used for each user classification.
Be aware that many package software User Guides are protected by copyright. However, most licensing arrangements allow customers modify and copy these the materials for on-site use as described above.
It may also be possible to obtain electronic versions of the vendor's documentation, in a word-processing format, to make altering, cutting, and pasting easier. Custom portions of the User Procedures can then be added in the same word-processing tool. Conversely, the vendor's documentation may be translated into another available electronic format before editing begins.
Testing the Procedures
After completion, the User Procedures should be tested using the full, final version of the software solution, including all modifications and custom programs. Any mismatches should be investigated, with the likely resolution being a correction of the procedures.
Before User Training is conducted, a training manual should be developed. The User Training Manual will differ from training material provided by the software vendor (in a package software implementation). Among the differences:
The User Training Manual will not include set-up options, code definitions, or most other behind-the-scenes system features that end users will not see. These system components are typically found in vendor-provided material used in the Project Team Training activity.
The User Training manual will include functions based on system modifications and custom software.
The User Training manual should be organized by function or process (add journal entries, post journal entries, print month-end reports, etc.), rather than by application (General Ledger, Accounts Payable, etc.).
Procedures vs. Training Manual
In fact, the User Training manual should be based very closely on the User Procedures which were finalized in the last activity. Although the User Procedures and User Training Manual are similar, here too there are differences:
Training manuals are intended for one-time use, and illustrate most common transactions and conditions, vs. the more exhaustive coverage of the procedures.
Training manuals should be very easy to read, including plenty of white space for note taking, and graphics to illustrate system concepts.
The training material should include exercises to help reinforce learning.
For a complex system requiring extensive training, an instructor's version of the training manual may be created, including solutions to exercises and other supporting details. This technique is particularly useful in situations where the instructor has limited expertise in the software solution.
However, for a relatively simple installation, or one with a limited budget, the User Procedures may serve as the manual for User Training.
User Training, or "End User Training", is a critical activity in the implementation of any new system. Without carefully conducted training, the commencement of live operation will likely be followed by confusion, frustration, and eventual rejection of the provided solution. Unfortunately, schedule and budget pressures force many project managers to omit or reduce the scope of the User Training sessions.
The training sessions should be conducted after the System Test and all custom development items are completed. This insures that the training, and user confidence in the new system, will not be disrupted or damaged by technical problems.
The best training period is as close to the beginning of live system operation as is possible.
The Training Schedule
During the Develop Training Plan activity, in the Project Definition phase, a high-level, tentative training plan was developed. This preliminary plan is used as the basis for the final, detailed User Training plan. The details added to the training plan will include:
Attendees
Specific dates
Location(s)
Instructor name(s)
Before the schedule is finalized, arrangements should be confirmed for the facility, the instructor, any required workstations, and training manuals. Once all information on the schedule is confirmed, it may be circulated among participants and their line management, who will be impacted by the absence of the trainees during training.
On the following page is a sample detailed User Training schedule, for a system whose applications include General Accounting, Budgeting, and Accounts Payable.
Sample End User Training Schedule
|
Application
|
Trainer
|
Attendees
|
|
|
|
|
|
General Ledger - Section 1
|
Steve Davis
|
Jane Fisher
|
|
Site - Main Demo Room
|
|
Tom Fisher
|
|
December 1& 2
|
|
Ed Garcia
|
|
9:00 AM to 4:30 PM
|
|
Pam Holter
|
|
|
|
Sue Jacobs
|
|
|
|
Sue Johnson
|
|
|
|
Arnold Kline
|
|
|
|
Bob Landry
|
|
|
|
Ted Stone
|
|
|
|
Andy Thomas
|
|
|
|
Stan Wilson
|
|
|
|
Bob Young
|
|
|
|
|
|
General Ledger - Section 2
|
Steve Davis
|
Sam Anderson
|
|
Site - Main Demo Room
|
|
Bo Bovar
|
|
December 3 & 4
|
|
Tim Brice
|
|
9:00 AM to 4:30 PM
|
|
Rob Dennison
|
|
|
|
Randy Myers
|
|
|
|
Debbie Nordster
|
|
|
|
Oscar Petrie
|
|
|
|
Donna Ryan
|
|
|
|
Debbie Smith
|
|
|
|
Travis Smith
|
Sample End User Training Schedule (cont.)
|
Application
|
Trainer
|
Attendees
|
|
|
|
|
|
Budgeting
|
Cindy Bowers
|
Sam Anderson
|
|
Site - Main Demo Room
|
|
Bo Bovar
|
|
December 7 & 8
|
|
Tim Brice
|
|
9:00 AM to 4:30 PM
|
|
Rob Dennison
|
|
|
|
Randy Myers
|
|
|
|
Debbie Nordster
|
|
|
|
Ted Stone
|
|
|
|
Andy Thomas
|
|
|
|
Tim Thomas
|
|
|
|
Stan Wilson
|
|
|
|
Bob Young
|
|
|
|
|
|
|
|
|
|
Accounts Payable
|
Mary Douglas
|
Pam Bruffer
|
|
Site - Main Demo Room
|
|
Monica Cox
|
|
December 9, 10, & 11
|
|
Jay Dinkens
|
|
9:00 AM to 4:30 PM
|
|
Candy Edgar
|
|
|
|
Clyde Jones
|
|
|
|
Andy Lewis
|
|
|
|
Rod Malloy
|
|
|
|
Ann Nelson
|
|
|
|
Bernie Ricker
|
|
|
|
Walter Yount
|
|
|
|
|
If the training facility accommodates a maximum of 12 trainees, there must be two sessions of the General Ledger class, as illustrated in the example above. Another reason for breaking the classes into sections is that while some members of a user department are in training, the remaining personnel can be conducting the department's business.
Note that the trainers who conduct these sessions would be project team members who were involved in the Conference Room Pilot, and who had themselves been trained during the Conduct Project Team Training activity in the Project Definition phase.
The Training Environment
In some cases, End User Training may be conducted at remote user locations to save on travel costs. Whether the classes are conducted at remote sites or at the company's main offices, the following training guidelines are applicable:
The training facility should be away from the normal working environment of the class participants. There should not be a working telephone inside the facility.
The training facility should include all equipment and materials as required for Project Team Training, including sufficient workstations, projectors, desk space, flip charts, markers, etc.
Each trainee should be present for all sessions of a given course, rather than attending in a piecemeal fashion.
Conducting the Training
The system (computer and/or network) being used for training should be free of any resource-intensive activity (high-volume testing, program compiling, large batch programs, etc.) during training sessions. Training data should be in a separate environment from the clean production environment, so that transactions may be entered during training and cleaned out afterward.
Training Evaluations should be issued to each trainee and collected at the end of each class. A sample training evaluation appears at the end of the Procedures and Training section of this guide.
A Conversion Schedule is based on the conversion strategy developed as part of the work planning activities in the Project Definition and Conference Room Pilot phases.
Conversion Approaches
Conversion strategies may be described as following one or more of the classic conversion approaches:
Total Conversion: Converting all applications, for all business functions and units, at the same time. Also known as "Direct Conversion"
Phased Conversion: Converting a group of applications together, followed by a second group of applications, and possibly a third, and so on. For example, financial applications may be followed by Inventory and Sales Order applications, and finally by manufacturing control applications.
A variation on the phased approach involves converting only certain business segments, followed by the remainder of the business later. For example, a single product line may be processed by a new manufacturing system for a period of time, and the remaining products added in a subsequent conversion. In a second example, an Order Processing system may accept orders only from certain Sales Regions at start-up, while other regions temporarily remain on the old system.
In a phased approach, a separate conversion schedule should be developed for each conversion, whether it is for an application group of business segment.
Parallel Conversion: In a parallel conversion, both systems are run concurrently for a period of time, with the same applications, business segments and transactions. This approach offers a safety net for the new system, but usually requires heavy resources, both human and hardware, to handle the duplicate processing.
A conversion strategy may be a combination of the three approaches. For example, a Payroll application may be processed on both the old and new systems for the first few weeks after conversion, to demonstrate that deductions and paychecks are being processed accurately, while all other applications are converted using the Total Conversion approach.
In any case, the strategy identified early in the project may now be confirmed, based on the experiences in subsequent project phases (Conference Room Pilot, Development / Programming, and System Integration.)
Conversion Schedule
A Conversion Schedule is a fairly detailed document which defines the timing of various conversion events. The Conversion Schedule should include, at a minimum:
1. The conversion time frame (month-end, year-end, etc.). The time frame will usually be based on normal business cycles. For example, accounting system conversions will almost always occur at the end of an account period, which may or may not correspond with the last day of the month. A Payroll conversion would ideally coincide with a year-end, since W-2 forms and many other totaling requirements are based on the calendar year.
2. Specific key dates in the conversion. Some examples might be:
July 9: Last day to post adjusting entries on the old G/L system.
January 3: Last check run on the old Payroll system.
March 1: First day to accept Sales Orders on the new system.
3. Project team responsibilities and activities. Responsibility should be defined for the conversion activities associated with each application. Many activities will be technical in nature, including hardware connections, workstation set-up and configuration, and data backups. Others will involve supporting users and management, attempting to conduct business in a seamless manner during the start-up, as the new software, hardware, and procedures are put to use in a production mode.
Conversion Scripts
A highly detailed, short term (perhaps 1 to 5 days) conversion plan is called a Conversion Script. The Conversion Script details exactly who will do what, at what time, and where it will happen. The goal of the conversion script is the preservation of data integrity.
Examples of entries in a detailed conversion script might look like:
Friday, 6:00 PM
Frank verifies that all General Ledger Users are signed off of the old system. He then disables the passwords for each of these users, and runs the Trial Balance Report..
Friday, 7:00 PM
Frank creates a tape with the Account Detail File and the Account Balance File. He takes the tape to the new data center in the administration building.
Friday, 9:00 PM
Bob loads the final version of the Account Balance and Account Detail file into the conversion environment on the new computer. He verifies that the record counts for these files are identical to the count on the old system.
Friday, 11:00 PM
Bob executes the detail and balance conversion programs in the conversion library, and runs the new Trial Balance report against these files.
Saturday, 8:00 AM
Sandy and Tim compare Trial Balance reports to verify that detail and balance information were accurately converted, in the conversion environment. They approve the copying of these files into the production environment.
(etc.)
The last step of the conversion script should be a management review, validating that converted data is accurate, complete, and in balance.
At the completion of all other activities in the Procedures and Training Phase, the appropriate Project Manager's Checklists need to be reviewed or completed.
Project Manager's Checkpoints, end of Procedures and Training Phase:
Review & Complete Procedures and Training Checklist
Review & Complete Project Administration Checklist
Training Evaluation
Class: Date:
Instructor:
Student Name:
(Optional)
Please indicate your satisfaction with various aspects of the training course below. Check the "5" column to indicate areas of high satisfaction, and "1" to indicate areas of weakness.
Please enter additional comments or suggestions at the end of the evaluation form.
Item 5 4 3 2 1
COURSE
1. The course material was relevant and appropriate for my job duties.
___ ___ ___ ___ ___
2. The course material was organized in a logical sequence.
___ ___ ___ ___ ___
3. The course was long enough, and contained sufficient detail.
___ ___ ___ ___ ___
4. The course was concise, targeted, and without unnecessary sections and exercises.
___ ___ ___ ___ ___
Item 5 4 3 2 1
5. The training facility and environment were conducive to learning.
___ ___ ___ ___ ___
6. Visual aids and training manuals were useful and informative.
___ ___ ___ ___ ___
7. The course contained enough exercises and hands-on activities.
___ ___ ___ ___ ___
8. The course greatly increased my knowledge in the training subject area.
___ ___ ___ ___ ___
INSTRUCTOR
9. The instructor was knowledgeable in the course topic and material.
___ ___ ___ ___ ___ ___
10. The instructor communicated effectively with the class.
___ ___ ___ ___ ___ ___