Project Delivery Process D750

D750 - User Procedures

SUMMARY

Human procedures should normally be defined and agreed for all types of user.  This may have been done as part of the functional design work and be documented in the corresponding implementation papers.  Alternatively, the implementation papers should normally show clearly the needs for procedures.

The procedures may relate to:

• fully manual procedures, where those procedures form a part of the overall business solution even though they do not involve the computer,
• human/computer interactions, covering the way in which computer assisted tasks are performed, and
• fully automated processes, where no human action is required but where the staff need to understand the automated process.

User Manuals (or electronic documentation of the procedures) showing how to use the system should be extracted from the implementation papers and expanded / supplemented as necessary to meet the needs of the user population.

In the Application Software Delivery-IDDI approach it is common to produce the procedures and instructions in the form of a manual (although “electronic manuals” are becoming increasingly viable instead).  In a “Brief Delivery” it is common to rely upon the vendor’s documentation for a majority of the information and produce notes to supplement these as required.  Where there has been no custom modification of the system, it may be that the documentation supplied with the system is adequate.

A library of “Example Procedures” is available.  This illustrates business procedures for a wide range of functions and applications.

The definition of the user procedures may include the design of forms to be used where appropriate.

PATH PLANNING GUIDANCE

Normal Practice

DEPENDENCIES

Prerequisites (Finish-Start):

• Implementation Paper(s) defining the approach to user documentation

Prerequisites (Finish-Finish):

• Implementation Paper(s) defining the needs for user procedures eg procedures and controls IP, Data Input, reports and enquiries, security, etc.

Dependent procedures (Finish-Start):

• formal testing and acceptance of the corresponding functions within the system

RECEIVABLES

• relevant Implementation Paper(s)
• business process descriptions (from process R065 - R069)
• Form & Input Screens Worksheet (if applicable)

DELIVERABLES

• user procedures and corresponding documentation ready for formal testing
• User Manual (or equivalent documentation as required)
• Reference Documentation Sign Off letter (if required)
• forms (as required)
• Forms Signoff Letter (if required)

TOOLS

• various package specific materials
• Application Software Screen Cams for relevant Application functions - If Available
• Example Procedures - library of procedures for a wide range of applications and functions
• Example:  Forms and Input Screens Worksheet
• Example: Organisational Impact Worksheet
• Example: Report Fields Worksheet
• Example: Report Layout
• Example: Reports and Inquiry Screen Worksheet
• Example: Screen Fields Worksheet
• Example: Screen Layout
• Example: Source Document Fields Worksheet
• Example: Source Document Layout
• Example: Management Reference Guide TOC
• Example: Operations Reference Guide TOC
• Example: System Reference Guide TOC
• Example: User Reference Guide TOC
• Example: Reference Documentation Sign Off letter
• Example: Forms Signoff Letter

DETAILED DESCRIPTION OF TASKS

What are user procedures / Who are the users?

In this context, we are referring to the functional use of the system, either directly or indirectly. (Technical support and operation of the system is dealt with under Process D720).

User procedures explain how users should perform their work concerning the system.  this should be clear and easy to follow.   The information should be readily accessible.  The procedures should cover both normal use of the system and abnormal conditions such as actions to take in the event of foreseeable error conditions.

Typical types of user may be:

• normal staff making routine enquiries, eg name and address look up
• normal staff processing transactions, eg reordering a stock item
• supervisory staff controlling those staff and authorising transactions
• managers primarily concerned with extracting management information
• other management or external parties needing to understand information generated by the system (but not themselves using it)
• specialist staff controlling the operation of the overall system (from a functional point of view), eg system administrators,
• functional security controller.

It is important to understand that these different types of user will have different levels of understanding of the system and will need information concerning different aspects of the overall system.  It is, therefore, not normally a good idea to produce one large book containing everything everyone needs to know.

Documentation of the procedures

The techniques used to record the procedures will vary according to needs and according to the technology available.  This may have been defined in an earlier Implementation Paper, or it may be constrained by normal practice within the client organisation.

Conventionally, documentation is still produced in paper form.  It is, however, increasingly valuable to prepare documentation in electronic format - particularly where the documentation allows for search facilities to allow the rapid location of required information, and/or “expert” logic to assist users to find the appropriate action for a given set of events.

Some approaches that may be considered include:

• Workflow Automation system
• Customisable On-line HELP facility within the package
• “Wizards” / “bubble help” etc - ie optional help text constantly appearing to guide the user through each step as it is done
• “Screen Cams” are recordings of Windows applications as if they were happening for real.  These can be used to demonstrate any Windows based activities.
• Some Application Software Solutions provides predefined “Screen Cams” showing the layout and sequencing of screens as snapshots of windows sessions. “Screen Cams” could very well be taken for the application installed at the client site, and used for demonstrating user interaction with the Application Software system.
• Other electronic medium for holding and accessing information.
• User procedure “crib notes” - ie very brief summaries of what to do.
• Sectionalised User Manual with appropriate sections going to those needing them.

The approach to be used will normally have been agreed in an environmental Implementation Paper.

In large, complex environments it will often be necessary to document procedures in a formal and detailed manner.  The documentation produced under the Software Implementations’ Delivery-IDDI approach is frequently, therefore, in the form of a detailed manual or equivalent level of detail in an electronic format.

With a simple stand-alone system, it may be reasonable to rely primarily on the package vendor’s own documentation.  This can be supplemented by specific notes as required.  The documentation produced during a “Brief Delivery” approach is usually, therefore, restricted to brief notes detailing the procedures as a supplement to the vendor’s standard documentation.

Where there has been no customisation, it may be possible to rely entirely upon the documentation supplied with the system.  Accordingly, this task might not required in “Implement Only” projects.

Detail should normally relate to the specific way in which the system has been set up and the specific way in which it should be used.  It should not, however, repeat information already covered adequately in the vendor’s own documentation (other than where that detail is incidental to the definition of a specific user procedure), although it may be valuable to issue a summary of the vendor’s standard information so that it can be more readily accessible.  (Note - care should be taken to ensure that no breach of copyright is made where text or other materials are copied from another source.)

For example, some of the major Application Software packages provide detailed information on the contents and usage of system features like transactions, fields, or reports.  This system generic information would have to be complemented with information on the customisation of the package and the procedures for the use of the package, for example:

• the chart of accounts and under which circumstances to use which accounts,
• the procedures for handling specific customer requests, or
• a list of distribution channels and associated sales materials.

The following table shows typical sections of a User Manual and the typical types of users who need access to those sections.  Note particularly that needs of users will also vary according to the different subsets of the full system functionality they require, based on their different departments, sections, roles, etc.  For example, an accounts receivable clerk may not need the sections concerning accounts payable.

The example categories of staff used in the table are:

Enq	normal staff making routine enquiries, eg name and address lookup
Clerk	normal staff processing transactions, eg reordering a stock item
Sup	supervisory staff controlling those staff and authorising transactions
Man	managers primarily concerned with extracting management information
Exec	other management or external parties needing to understand information generated by the system (but not themselves using it)
Sys Adm	specialist staff controlling the operation of the overall system (from a functional point of view), eg system administrator
Sec	functional security controller

For each topic and category of staff, the table shows that the information would normally be provided (O), that the information may optionally be appropriate (O), or that the information is unlikely to be relevant (X).

	Type of user
Topic	Enq	Clrk	Sup	Mgr	Exec	Sys Adm	Sec
General overview of the system	O	O	✔	✔	✔	O	O
Starting up and closing down equipment, software, terminals, local printers etc	O	O	O	O	X	O	O
Using the screens - use of mouse and keys, help key, tabs, function keys, enter, menus, undo, windows etc	✔	✔	✔	✔	X	O	O
Logging in and logging out / changing the password	✔	✔	✔	✔	X	O	O
Transaction and master file enquiries (section per business function)	✔	✔	✔	✔	X	O	X
Transaction input, correction and amendment (section per business function)	X	✔	✔	X	X	X	X
Manual processes, control procedures, authority limits, authorisations, forms etc (section per business function)	X	✔	✔	O	X	X	X
Transaction error reports and error correction (section per business function)	X	✔	✔	X	X	O	X
Master file updates (section per business function)	X	✔	✔	X	X	✔	X
Security profile management	X	X	X	X	X	O	Ö
Creating, maintaining and deleting user details	X	X	X	X	X	O	Ö
Standard on-line reporting and enquiries (section per business function)	O	O	✔	✔	X	O	X
Regular reporting cycles (eg daily, weekly, monthly) - requests, distribution, control	X	O	O	X	X	Ö	X
Standard reports - contents and interpretation (section per business function)	X	X	O	✔	✔	O	X
Requesting optional reports	X	X	✔	✔	X	Ö	X
Defining or modifying reports using the Report Writer	X	X	O	O	X	Ö	X
Defining or modifying on-line reports or enquiries using the query language	O	O	O	O	X	✔	X
Defining or modifying screen layouts using a screen paint facility	X	X	X	X	X	O	X
Processing cycle manual and automatic controls	X	O	✔	X	X	✔	X
Archiving, purging, data retention, clean-up, file reorganisation procedures etc	X	O	O	X	X	✔	X
Run request, control and reconciliation of interfaces  (section per interface)	X	X	O	X	X	✔	X
Problem reporting procedures	✔	✔	✔	✔	X	✔	✔
Updating the package software and applying bug fixes	X	X	X	X	X	O	X

Developing Documentation

Developing reference documentation encompasses writing and printing any reference manuals required to ensure consistent operations over the effective life of the system.  Reference documentation provided by the vendor is usually written in generic terms and is limited to the standard system functions and operations.

It is usually necessary to develop additional reference material covering client-specific manual procedures, workflow and operations.  In developing procedures for manual tasks, special attention should be given to finding ways to eliminate unnecessary tasks and streamlining the entire flow of information.  This requires looking beyond what is being done and evaluating why it is being done.

Hints:

• When writing Implementation Papers and other design documentation, it is a good idea to write in a style which can be directly copied into the user documentation thus saving time and effort.
• Where information is readily available from standard sources, eg vendor documentation, it does not need to be reproduced.
• Where existing vendor information is relevant in a customised document, first check with the vendor to see that there is no problem with the copyright, and to see if the vendor can supply information already in an electronic format.

• It is important to balance the value added from custom-developed reference documentation with the ongoing cost of maintaining it.

• When writing user documentation, an attempt to keep each section distinct should be made to reduce the costs of maintaining it.  Even if the complete manual is redistributed after revisions, omitting cross references will keep costs down.
• Not all personnel need the same information - a sectionalised manual allows the materials to be issued selectively.
• Types of User Manual customised and developed as supplementary reference documentation may include:
• System Reference Guide – client-specific instructions on using the system functions
• User Reference Guide – client-specific instructions on performing the related manual procedures
• Operations Reference Guide – technical instructions on executing system processes
• Management Reference Guide – functional system overview with emphasis on on-line inquiry and reporting.
• It is important to balance the value added from detailed reference guides with the cost associated with maintaining the documentation.
• The sample policies and procedures (“Example Procedures” section) provide a starting point for developing reference documentation unique to the client environment.  

Example Steps:

The following is an example task list:

• Establish/review document design and format standards
• Finalise table of contents and review sample policies and procedures
• Review table of contents and samples with client sponsor and finalise content and format standards
• Draft procedures and reference documentation
• Review materials with users and revise, as needed
• Client management
• Department users
• MIS support personnel
• Test procedures using the documentation - revise as needed
• Review documentation with client sponsor and obtain approval
• Order publishing supplies
• Binders
• Dividers
• Special covers
• Special paper
• Publish and assemble reference documentation
• Prepare Reference Documentation Sign Off Letter, if needed

Developing Forms

Developing forms encompasses designing and printing the forms  needed in the defined user procedures.  Existing forms generally require significant changes in order to be usable with the new system.  It is often best that the new form mirror precisely the format of the new screen.

Where the forms are to be professionally printed, for example where a good standard of presentation or multi-part stationery is required, a substantial amount of time may be required to design the proofs, revise them, and get them agreed.  Due allowance should be made in the segment plan for such delays (although the team might also provide a temporary draft version as a contingency measure).

Objectives:

• Design and publish the forms to be used for collecting, entering and controlling system data, and controlling user procedures

Hints:

• Depending on the quality and quantity needed, laser printing and photocopying provides an economical approach to publishing forms.
• It is recommended that forms that are to be professionally printed are not submitted to the printer until after System Test so that the design can be fully tested.
• Some forms may be printed out by the computer, for example turn around documents.  It is important, however, that the testing accurately checks the precise positioning of the output.  Final tests should be repeated using draft layouts from the printer as a mask to ensure that they are satisfactory
• The fields of data entry forms should follow the same sequence of fields as the system’s screens for ease of entry.
• Multi-part forms should be avoided if possible, because they tend to be complicated, expensive to print and file and generally contribute to inefficient workflow.  If duplicates are occasionally needed, photocopies can be an inexpensive alternative.

Example Steps:

The following is an example task list:

• Review the Forms & Input Screens Worksheet and prepare layouts for new or modified forms
• Input documents
• Preprinted output forms (e.g., cheques, statements,)
• Review and test forms with users and revise as needed
• Review forms with client sponsor and obtain approval
• Print and stock forms
• Quantities for system testing
• Quantities for initial inventories
• For preprinted forms, review proofs prior to printing and inspect forms when received
• Organise samples of forms
• Prepare Forms Signoff Letter, if needed