The systems development life cycle is generally described as four phases of activity: analysis, design, implementation, and operation. The tasks involved are detailed in Exhibit 1. These tasks require the collection, organization, and analysis of information about the old system and the proposed new system. They involve developing new ideas and procedures. Most difficult of all, the design of a new system requires change (which often generates resistance and fear) and an urgent need to communicate the concepts and details of the new system to those who must use it and who are most affected by it.

Documentation and training are an effective means of communicating information. Communication is needed among members of the development team and also between the development team and users who will ultimately accept or reject the new system. Yet, unfortunately the functions of documentation and training, useful when communicating information, are often not considered part of the development cycle and thus are neglected or postponed until after the systems development process has been essentially completed.

Documentation and training are also necessary for the ongoing education of systems support staff and users once the system has entered production. Without this knowledge, maintenance and modification is inefficient and sometimes inadequate, and users are unable to use the production system to its maximum potential. As the system ages, important details are forgotten and the full power of the system is lost.

To correct these conditions, training and documentation should not be discrete activities undertaken only at the conclusion of the systems development life cycle. Instead, they must begin at project inception and continue into system operation. Good training and documentation help ensure the support of the system by senior management, its acceptance by user middle management, its use by staff, and ultimately the development and maintenance of a more enduring product.

Effective execution of the documentation and training functions requires that these tasks be addressed in all phases of the systems development cycle, not just at the end. Further, it requires assignment of responsibility for these functions to a professional for whom this is a primary responsibility. This documentation coordinator/systems trainer must be a person with strong communications and interpersonal skills who has an understanding of the business problems being addressed, as well as the technology employed in their resolution.

Documentation and Training During Systems Analysis

During systems analysis, the coordinator/trainer can increase user awareness and help document business activities, needs, and objectives. Early project success can be ensured by establishing channels of communication with the user community. Communications can increase the understanding of the business issues and problems that will be addressed by the future system.

An effective vehicle for improving communications and increasing project awareness in the user community is the project newsletter. Throughout the project life cycle, the newsletter can keep the broad user community informed of project orientation, decisions, and status. Serving as an "early warning system," the newsletter encourages user input during planning and analysis and provides the following information. * The identity of the project and management; * Definition of the problems that will be addressed by the project team; * Definition of the systems, files and databases that may be affected; and * The identity of members of the user community assigned to work on the project.

One of the major tasks in systems analysis is the documentation of existing business and systems activities and problems. Documenting the old system presents the opportunity for the coordinator/trainer to become acquainted with the processes and problems that will be addressed during development.

Experience in the user area also makes the coordinator/trainer a valuable information resource. During systems analysis the coordinator/trainer can develop an understanding of system and business functions which will help define later training needs and audiences.

At the conclusion of systems analysis, the documentation coordinator/trainer can assist in preparing the report to senior management. The report should identify business and systems problems, performance requirements, scope and costs/benefits of development. By including the report, or an abstract of it, in a project newsletter, a larger audience can be introduced to the new system, and the process of "selling" the system can begin.

Documentation and Training During Systems Design

Systems design requires decisions effecting the choice of hardware, software and manual resources to be used in developing the new system. Usually at this stage, a choice must be made between buying or building the system. The buy decision involves the coordinator/trainer in the evaluation of vendor documentation and training; the build decision involves the coordinator/trainer in the design of user interfaces to support business functions and the design of the help function and online documentation.

The Buy Decision. The buy decision begins with the evaluation of vendor software. All requests for proposals should include questions related to the availability and quality of documentation and training. Development of these questions is the responsibility of the coordinator/trainer. Questions on training and documentation addressed during the initial selection process can be general and designed to eliminate candidates who are definitely unsuitable. Some questions related to training and documentation follow.

Training:

* Does vendor provide training? Types of training (classroom, self- study, computer assisted)? At vendor location? Onsite? * Is training included in licensing agreement? Number of hours? Number of courses? Number of self-study guides? Interactive training programs? Cost of additional training not included in licensing agreement?

Documentation:

* Is documentation available? System documentation? Program documentation? User documentation? * Cost of additional copies of documentation?

After narrowing the field of candidates, detailed evaluation of training and documentation begins. During detailed evaluation the coordinator/trainer attends vendor training sessions; performs a review of all training materials and documentation; and participates in software testing.

Attendance at vendor training sessions provides the coordinator/trainer with the opportunity to evaluate the quality of classroom instruction and instructional materials. The systems trainer can determine whether:

* Classes are scheduled at intervals and locations that will meet the needs of the user. * Instructional materials are interesting, logically organized and address the needs of specific user groups. * Qualified instructors are used in all classes. * Sufficient time is provided to address problems that may be unique to individual users. * Instructors or other qualified individuals are available to answer questions that arise after the conclusion of the class.

The coordinator/trainer and other members of the project team also review supplementary instructional materials, self-study guides and computer assisted instruction. When evaluating the contents of self- study guides, the systems trainer considers whether:

* Use of self-study materials is appropriate. * Organization of the guides is clear, logical and oriented toward the solution of business problems. * Learning objectives are clearly stated and users are frequently tested on their understanding of the materials.

If computer assisted instruction is available, the systems trainer exercises these programs to determine whether:

* Programs are fully documented and designed for users with no prior experience with software. * The organization and presentation of instructional materials is clear and logical. * Users have the ability to terminate, without completing the session, and to return later, picking up where they have left off. * Learning is regularly assessed with the system providing additional review and problems, if remedial work is required.

The coordinator/trainer also assesses the usability of documentation. Members of the project team who have used the documentation are an excellent source of information for the coordinator/trainer about the accuracy of technical documentation and its ease of understanding. On the basis of these opinions, the coordinator/trainer provides an overall assessment of its organization, its understandability and ease of use.

On-line documentation and help facilities are also useful. As with any other documentation, the coordinator/trainer should evaluate it considering whether:

* Online help and documentation are available from all locations in the system. * The system supports more than one level of user help, accommodating both general and specific function documentation. * Entry into and exit from the help and documentation functions is quick and easy. * Instructions used to access the help function are easy to understand and remember. * Information provided in vendor developed on- line documentation can be understood by the business user. * On-line documentation and help are easily modified and maintained.

The Build Decision. A build decision engages the coordinator/trainer more directly in product design. Definition of business functions and supporting business activities drive the design of the system, as well as the design of the training. In this process business activities are associated with the system activities that will be used in their support. Subsequently related system activities can be grouped in logical units and user access menus defined. The coordinator/trainer, working with system designers, can design these user access interfaces. Other responsibilities of the coordinator/trainer in this phase include the development of user instructions for the new system, and design of on-line help and documentation. A logical, well-organized system that is also user friendly will enhance system use and understanding as well as serve as the basis for user-oriented training.

A common problem associated with the systems analysis phase of project development is the lack of communication with user areas throughout the organization. Many designers tend to work with a limited group of key users, and focus their attention upon the system. This can leave many users without adequate knowledge of the new system or the opportunity to provide potentially valuable input. Again, the importance of the project newsletter cannot be overemphasized. While all users may not be actively engaged in the evaluation or design process, they should be kept abreast of decisions and project status. The newsletter can communicate results and direction. In addition, management information sessions to inform the user community of basic design decisions and address questions and concerns about the project can enhance the exchange of information between user management and systems developers. Information sessions are an effective precursor to formal training, familiarizing the audience with basic design concepts and approaches.

Documentation and Training During Systems Implementation

During systems implementation, the coordinator/trainer provides training to audiences in the user community, develops or tailors on-line help and documentation functions, and compiles systems, program and user documentation. How each of these tasks is accomplished is largely determined by three factors: the buy or build decision; audience location and size; and type of software. When software is purchased, the vendor frequently provides training classes and materials. If these classes fulfill user requirements, the coordinator/trainer functions primarily as an administrator, scheduling classes and enrolling users in them. On the other hand, if training materials or instruction provided by the vendor prove to be inadequate, the trainer tailors or develops educational materials and conducts in-house training sessions.

Audience size and location and the types of software can drive the decision to supplement vendor training materials and conduct in-house sessions. If the audience is large and training has to be repeated on multiple occasions at multiple sites, using an in-house trainer to conduct classes results in substantial cost savings. The type of software dictates the degree to which training materials may have to be tailored. Users of the utility software, including Lotus 1-2-3, can be trained primarily in the software functions (often using vendor material), because it is expected that users will recognize the application of these utilities to their specific business problems. On the other hand, users of applications-oriented software, including general ledger, accounts payable, accounts receivable and payroll systems, often require training that is tailored to the support of their unique business activities.

The development of tailored, in-house training for use with a purchased package is a time consuming and complex task. In-house development of training starts with the definition of user groups, a review of their functions and related activities. Working together, designer, trainer and user can map business activities to the purchased system activities that will be used to support them. Definition of training modules can be the result of this mapping process. System activities that support related business activities should be addressed in the same training modules.

The decision to build a system brings with it the commitment to build the training. The building of a system presents the opportunity to structure software and training so that it reflects the system activities.

During design, system activities that support related user business activities should be identified. Subsequently related system activities can be grouped so that they can be accessed through common user menus. The systems trainer, as part of the project team, should be actively engaged in the definition of these menus and their contents. In a well designed system, user menus can serve as the logical basis for the development of user-oriented training modules.

Training Programs

Typically, three levels of audiences require instruction in the system and its capabilities. Overview sessions are developed for managers in order to acquaint them with the functionality available in the system and how it can be used in their specific areas. Classes for first-line supervisors, which incorporate hands-on instruction, are designed to acquaint supervisors with menus, screens, help functions, user documentation and user controls. The third level of instruction focuses upon the needs of the direct user audience. These sessions are hands-on and employ "real life examples" throughout the class. This level should provide the participants with the opportunity to exercise the system and understand how it will be used in solving their business problems. A hands-on approach to instruction encourages system use in the controlled environment of the classroom. To enable all users to attend training, multiple small sections of the same class should be scheduled. This flexible scheduling enables all system users to attend class without disrupting their personal schedules or work activities. Training should occur close to the time when the system becomes available in the user area, because practice on the system helps reinforce procedures learned in class.

The project newsletter plays an important role in the training program. The newsletter can publish descriptions and schedules for user classes, and detailed enrollment procedures. The newsletter can also serve as a training vehicle. By reporting on project progress and major project-related decisions, it describes system functionality to a broad audience. Although it may be difficult for user management to attend traditional classes, they can become acquainted with system functions through well chosen "articles" presented in the project newsletter.

Whether the system is built or bought, the coordinator/trainer may be called upon to develop user-oriented on-line help and documentation functions. The on-line help function supplements training information and is a substitute for additional documentation.

Information, supplied in the on-line help function, should be expressed in terms that the user can understand, and should support information requirements at different levels of detail.

During systems implementation, the coordinator/trainer also compiles documentation. With purchased software, this can entail the establishment of a documentation library to house master copies of systems, program and operations documentation. If the software is modified in any way, fully documented changes should be added to the library. Software written in-house imposes additional demands for the development of documentation. In most large companies, documentation standards have been defined. It is the responsibility of the coordinator/trainer to see that these standards are met and that documentation for these systems is complete, properly organized and maintained.

Documentation and Training Considerations During Systems Operations

Adaptation of the new systems environment often brings the reassignment of the coordinator/trainer. All too often, this transfer means that formalized training in the system has ended and that documentation, although now complete, will not be maintained. The department that is designated as the "owner" of the system should assume these responsibilities. To ensure a smooth transition to the new "owner" area, the coordinator/trainer must provide for a continuation of this function. This means identifying individuals in the owner area who will be available to maintain documentation and to continue classes, as necessary, over the life of the system. The new coordinators/trainers must become familiar with all instructional materials and system operations. If there is constant turnover in the user departments, classes in system use will be required at regular intervals. The "owner" department coordinator/trainer must provide class instruction and maintain instructional materials and user documentation. Maintenance of other documentation, such as systems, program and operations manuals, is done by the systems maintenance area. Regular audits of the user area and system maintenance function help ensure the integrity of production system instruction, documentation and maintenance procedures. Exhibit 1 Omitted

Linda R. Garceau, DBA, CPA, Cleveland State University and Elise Jancura, PhD, CPA, Cleveland State University