Practical Playscript Writing

Practical Playscript
Writing procedure manuals that people can use

ALSO BY ROBERT BARNETT
Managing Business Forms

Forms for People: designing forms that people can use
The Form Designers Quick Reference Guide
Writing procedure manuals
that people can use
Robert Barnett
Third Edition 2008

1993, 2003, 2008 Robert Barnett
All rights reserved
No part of this publication may be reproduced, stored in any retrieval system, or

transmitted in any form by any meanselectronic, mechanical, photocopying,
recording or otherwisewithout written permission from the author.
Published by Robert Barnett and Associates Pty Ltd

A.C.N. 002 941 120
PO Box 95, Belconnen ACT 2616, Australia
www.RBAinformationdesign.com.au
Printed in Canberra, Australia
ISBN 978-0-9586384-3-2
Contents
Acknowledgments ix
v
Chapter 1 The Role of Procedure Manuals 1
Why have a procedure manual? 2
Functions of a manual 5
Chapter 2 Content of Procedure Manuals 7

Types of material 7
Putting the facets together 12
An overview of Playscript 14
The advantages and uses of Playscript 14
Chapter 3 Rules of Structure 19

Changing the format 19
Procedures versus other material 20
Using a standard layout form 20
Procedure layout 23
Sequence of steps 29
Chapter 4 Subroutines and Side Channels 33

Short side channel involving one person 33
Short side channel involving more than one person 35
Two short alternative channels with multiple steps 35
Major branch into two separate activities 36
The rare problem exceptions 37
Choices within a choice 38
Handling multiple decisions 40
Chapter 5 Task Outlines 41

The basic structure 41
What to include 42
Special cases 43
Chapter 6 Writing Style 47

Start with a clear structure 48
Avoid confusion 48
Writing procedures as part of a team 56
Slanting the language to one department 58
vi
Chapter 7 The Writing Cycle 59
What makes up a procedure? 59
Writing the procedures 61
Rewriting existing procedures in a new format 64
Writing procedures for a new system 66
Documenting current unwritten procedures 67
Chapter 8 Usability Testing 69

Some common approaches to testing 69
Observational usability studies 75
How to conduct the usability study 78
Chapter 9 Implementing Playscript 81

Teaching users about Playscript 81
Teaching users about a new procedure or a change 82
Gaining acceptance 83
Encouraging revision 84
Manual production 84
Making changes 86
One final matter 87
Appendix 1 Suggested Reading 89
Appendix 2 Decision Tables 91
Appendix 3 Subject Index 99
vii
viii
Acknowledgments
M
ost books on management include ideas and principles gathered
by the author from predecessors and restructured to suit the ix
authors aims. This book is no exception.
The primary acknowledgment goes to Leslie H. Matthies whose books,
The New Playscript Procedure and Documents To Manage By, have been my
primary inspiration in writing procedure manuals. I have drawn heavily
on his work and have endeavoured to keep the Playscript format as close as
possible to his original concepts.
I have also drawn much inspiration from Clyde Jacksons book Verbal
Information Systems and from numerous other writers whose works are
mentioned in the footnotes and in Appendix 1.
I would also like to thank the many people who have contributed
positive comments about the earlier editions. This encouraged me to retain
the same format and writing style, while reducing the page size in keeping
with our other publications.
Most of all I would like to thank my wife Patricia for her never-ending
support and patience, and for her tireless efforts at rekeying all my old
course notes.
Robert Barnett
x
Chapter 1
The Role of Procedure Manuals
It has been said that behind every business activity there lies a piece of paper
and, even with todays emphasis on computers, this adage is still true. In addition 1
to such practical office work tools as forms, reports, correspondence and memos,
there is a vast range of other administrative papermuch of it essentialbut
much of it superfluous.
This book deals with documentation that comes under the general heading
of procedure manuals. Although it is primarily concerned with procedures, we
need to consider all manuals briefly because other material is often included in
procedure manuals, either through ignorance or because the writer cannot think
of anywhere else to put it. Administrative documentation covers a wide range of
subject matter such as:
Policy statements Organisation charts
Job/position specifications Standards
Lists of authorities Appointment announcements
Departmental functions lists Memos
Circular letters Temporary announcements
Form-filling instructions Forms catalogues
In addition to general administrative paper, we have a whole range of
computer systems documentation.
You need to write and structure each type of documentation to suit the
particular needs of its users, so you need to think carefully about what you are
including in each manual. Only some of this material comes under the general
category of procedures.
Why have a procedure manual?

In considering the role of manuals and how to produce them, you need to ask
some fundamental questions.
What type of people will use it?
What does each user need to get from the manual?
What benefit should each type of user get from it?
How much detail is needed?
If we give it to the operators, will they actually use it?
Is there some legal reason for having the procedures documented?
I have often found procedures and related forms left till last and treated as
unimportant, especially by computer people who forget that the best programs
in the world are useless in business if people dont know how to use them. As one
writer put it, effective procedure writing is the means to humanise systems. So
let us go back to the first question and have a look at each type of user in turn,
remembering that manuals are for people to use.
Procedures Analysts or Business Systems Analysts

These people often have a primary interest in people, workflow and efficiency.
But, together with Computer Systems Analysts, they are also interested in such
matters as origin of data, distribution and processing of reports and possible
sources of clerical errors. Their analytical need is for a detailed record of the work
2 that management requires and hopefully, is carried out.
The Procedures Analyst needs to see the total logical flow of work in the
system as well as a method of checking that the work is carried out.
The Analyst also needs a quick and efficient method of documenting
previously unwritten procedures, or alternatively, a method that can be taught
easily to staff so that they can write up their own tasks with a reasonable degree of
accuracy and completeness.
Computer Systems Analysts

All analysts have a great interest in the function of the system as a whole. In the
case of computer systems, it is most likely that the analysts primary concern will be
systems or project oriented. It is important for future system development on those
projects that they document the conceptual ideas behind them. So, somewhere in
the documentation there will need to be a project or system description.
Your manuals need to clearly distinguish the information needed for future
system development and programming changes from the information that is
required by the users of the system. Clyde W. Jackson1, speaking as a representative
of the computer systems fraternity, had this to say:
For much too long people who do not work in the systems/data processing section have held
the computer in awe almost as a mythological being. Because they communicate with the
1 Jackson, Clyde (1974) Verbal Information Systems, Association for Systems Management, Cleveland Ohio.
Chapter 1 The Role of Procedure Manuals
computer through us, they have seen us almost as the high priests. And, generally we love
every moment of it. Lets quit putting ourselves and them on. The computer is a machine.
Thats all. Granted, it is complex and sophisticated, but it is still a machine. It can only do
what people tell it to.
However, the extent to which you should include this type of material in
a users procedure manual is debatable. It has been my experience that many
computer people think of their work in terms of projects or programming products
rather than overall efficiency of the organisation. But general office workers dont
necessarily think in terms of systems or projects unless the content of those
systems coincides with the content of their day-to-day work. This can happen,
but it is wrong to assume that it is always the case. The structure of a computer
system tends to be machine-oriented and it is rare for the human component of
the system to follow the same form.
Keith London2 described this with a matrix based on the Blake Management
Grid as shown in Figure 1.1.
Figure 1.1 Keith London Systems Matrix
2 London, Keith (1976) The People Side of Systems, McGraw Hill Book Company (UK).
Line Managers and Supervisors

Unlike 19th Century sole proprietors, modern managers cannot make
decisions on work processes according to the whims and fancies of the moment.
Workers need instructions on how management wants each task carried out and
it is often the supervisors who make these decisions and write up day-to-day work
instructions and procedures. But supervisors and managers also need procedures.
Every manager should have a clear picture of the channels through which the
departments work flows and they should know all the processing steps located
along those channels irrespective of whether the people report direct to them.
Supervisors are in the firing line. If an operative doesnt know how to do
something, it is the supervisor who is supposed to know the answer and who gets
the blame if that answer is not forthcoming. On the other hand, senior management
expects the supervisor to see that the operative gets the job done. The supervisor
needs to know both the fine detail and the policy.
The supervisor or some other delegated person will usually have to work with
the systems/procedures analysts in the development of any new systems. With
this in mind, there is probably a need for a certain amount of computer system
documentation to be kept in the department as well as clerical procedures. But
only one copy of this is usually necessary and, even then, it may only need to be
part of the system documentation.
Operatives
4 The operatives are at the opposite end of the scale to management. They
certainly need to have a broad understanding of what management expects of
them, but their primary interest is in the fine detail. They want to know:
How do I do my job?
What happens next?
What do I do with this paper when it lands on my desk?
How do I make these calculations?
How do I evaluate this application?
What do I enter into this computer?
Where do I send this piece of paper?
Do I have the authority to make a decision on this problem or should I refer it to my
supervisor?
Clyde Jackson3 said that:
the impact of a procedure manual is either:
(1) To help solve operational and management problems, or:
(2) To help create operational and management problems.
If you dont write with the users in mind, then the manuals will create their
own additional problems.
3 Jackson, Clyde (1974) Verbal Information Systems, Association for Systems Management, Cleveland Ohio.
Chapter 1 The Role of Procedure Manuals
Senior and Middle Management

The needs of senior and middle management are different to those of
supervisors. Except in small organisations, senior people are rarely interested in
the fine detail of the operating procedures. They may be involved in the writing
of them, but after implementation their interest is often only limited to matters of
dispute. They may only be interested in the policy aspects since this is what they
are responsible for. So it should be quite easy for them to refer to these matters
without wading though masses of step-by-step detail.
Functions of a manual
In the next chapter well be looking at the types of material included in
manuals. But first we need to consider in more detail why we need manuals.
Clyde Jackson lists six important functions of manuals. While it would
be possible to add even more to his list, I believe that his descriptions are
comprehensive enough to be quoted without further comment.
INSTRUCTION. A manual instructs people in all levels of the company.
It teaches line personnel facts about their jobs, as well as providing step-by-step
instructions about performing their jobs.
It provides supervisory personnel with the knowledge required to manage the
productivity of their people.
It gives management a concise overview, plus the details of operations, depending on
how thoroughly management reads the manual.
5
It provides a training guide for new personnel.
REFERENCE. No one can remember everything about a system or a particular function
within the system. The manual is a valuable reference containing detailed information
about a system.
It is a source for solutions to non-routine problems. If a person can find the answer in a
manual, he saves his superiors time, and he is more independent.
It refreshes a persons knowledge of his job when he reviews the manual periodically.
It provides authoritative answers to operational questions.
REVIEW. A manual allows a review of operations. Putting operations down on paper
allows several levels of criticism.
It allows overall criticism, to see if the overall operation accomplishes its objectives.
It allows a more efficient sequencing of activities or assignments of personnel if needed.
It asks the question, Is this the best way to do it? of every function.
CONTROL. A manual, when well developed, has important control functions on several
levels.
It allows supervisory personnel to assign and evaluate their people more effectively.
It gives control departments such as auditing, quality, safety, etc., the information they
need to perform their functions.
It enables management to more intelligently allocate resources and set objectives.
STANDARDS. A manual is important for establishing and enforcing work standards.
Where required, it will help see that the same job is done the same way each time.
It defines the acceptable level of performance and instructs the personnel in the method
to achieve it.
It serves as an objective basis of evaluating either an individuals or a departments
performance by stating the criteria for measurement in advance of the evaluation. The
evaluator and the evaluatee will both benefit by knowing the ground rules.
DOCUMENTATION. Stated simply, a manual is a record of how a particular company
does a certain function. It is a record of what they do. While this statement is a gross
oversimplification, it accurately describes the documentation function of a manual.
6
Chapter 2
Content of Procedure Manuals
In the first chapter I covered the range of material that people include in
procedure manuals. We can now break this down into specific categories and this 7
will help us to arrive at the optimum structure.
Corporate policy
This is one of the most difficult areas to define because it varies greatly from
one organisation to another. Im not getting embroiled in the argument about
whether or not such a policy should exist. Writers such as Tom Peters1 and Robert
Townsend2 have strong words against it, while others sing its praises. My point in
this chapter is simply to define what we mean by corporate policy statements as a
component of manuals. To begin, here is what various writers have said.
Stephen Page3 defines policy as a predetermined course of action established as a
guide toward accepted business strategies and objectives.
George Terry4 defines policy as a basic guide to action. It prescribes the overall
boundaries within which activities are to take place and hence reveals broad management intentions
or forecasts broad courses of managerial action likely to take place under certain conditions.
Knowing the policies of an enterprise provides the main framework around which all actions are
based. Policies furnish the background for an understanding of why things are done as they are.
1 Peters, Tom (1987) Thriving on Chaos, Alfred A. Knopf, New York.

2 Townsend, Robert (1970) Up The Organization, Coronet Books, London.
3 Page, Stephen Butler (1984) Business Policies and Procedures Handbook, Prentice-Hall, New Jersey.
4 Terry, George R. (1970) Office Management and Control, Richard D Irwin Inc., Illinois.
Leslie Matthies5 described the characteristics of policy this way:

1. It does not tell people how to proceed.
2. It reflects a decision that can be used rather widely.
3. It is what management wants.
4. It helps supervisors and operating people to make sound decisions at the operating level.
5. It provides for fair treatment of all people. (This is extremely important.)
6. It brings consistency into numerous operations.
7. It provides a unity of purpose. It points all segments of the organization in a single,
goal-seeking direction.
8. It tends to point to the definite objective of the organization to its goals.
9. It relieves top executives from the job of making routine decisions repeatedly.
10. It can be applied in most similar situations.
11. With policy, good decisions can be made at the operating level.
12. It answers the what to do part of a question.
Of course most policy statements will not have all 12 characteristics. But if a document
has seven or eight of the characteristics it probably is a statement of policy.
It is important that you clearly distinguish policy from procedures and other
types of documentation. Many business systems analysts combine them as if they
are the same thing, or just different versions of the same thing. For the purpose
8 of this book I will treat it as an overview of what management wants done as
distinct from procedures that tell us how to put it into action.
Policy statements will usually include one or more of the following:
Purpose or objective
People or areas affected
Policy statement
Definitions
Responsibilities
Summary of the procedures that will be used to implement the policy
Exceptions.
Figure 2.1 shows an example of a Corporate Policy Statement.
System objectives/narrative
If your procedures are part of a computer system, you will usually need a
general description or narrative for the benefit of people who need an overview.
The narrative usually describes such features as:
the concepts behind the system
descriptions of the way in which each subsystem operates
descriptions of the functions and workings of each computer program
description of each report produced.
5 Matthies, Leslie H. (1982) Documents to Manage By, Office Publications Inc., Stamford.
Chapter 2 Content of Procedure Manuals
I have seen many computer systems where this was the only user document.
It was left to the individual managers and operatives to work out how to put it into
action. This doesnt help productivity. Good system documentation should go way
beyond the electronic aspects and deal with the people side of systems.
Figure 2.1 A Corporate Policy Statement
Forms Management Policy

1. Objective
The objective of the companys Forms Management Program is to provide all
departments with essential forms at minimum cost.
2. Functions
The Forms Management Department will specify the design of all printed forms used
throughout the company, in order to achieve:
2.1 Systems compatibility and efficiency in use
2.2 Economy in ordering and procurement
2.3 Prevention of redundant forms.
Accordingly, all requests for new or revised forms/screen layouts will require the
approval of the Forms Management Department.
3. Responsibilities
3.1 FORMS MANAGEMENT DEPARTMENT will maintain a central activity to

provide the following services:
Review and approval/disapproval of all requests for new or revised forms
Design of new forms 9
Redesign of existing forms
Assignment of form numbers
Determination of the best method of producing forms
Preparation of printing specifications
Review of printers proofs
Simplification and consolidation of forms
Periodic review and elimination of obsolete forms
Control of order levels and stocking levels (minimum/maximum) for forms
A central record of all company forms.
3.2 STATIONERY STORE will:
Send all new forms requisitions to the Forms Management Department for
approval
Notify Forms Management Department and the user departments of all
reorders originated
Maintain forms stock levels as directed by the Forms Management
Department.
3.3 PURCHASING DEPARTMENT will accept requisitions for outside-printed

forms only from the Stationery Store.
3.4 REPRODUCTION DEPARTMENT will reproduce only those forms identified

by a regular company form number unless specially approved by the Forms
Management Department.
Procedure/task objectives
This is similar to system objectives but broken down to the individual task
level. It can be helpful for staff to understand the objectives or reasons behind each
particular task, together with any organisational policy that specifically refers to
that item. These may be just very brief comments, or in the case of very important
matters, they could run into a number of pages.
Some writers object to any form of policy statement being included in a
procedure, but over the years I have come across many people doing jobs and not
having any idea why they were doing it. These people just go about their jobs as
a matter of daily routine and without any real enthusiasm for the task. Im a great
believer that workers need to be really involved in their jobs. The more they are
personally motivated, the happier they will be.
Procedure
Throughout this book I will be using the definition of procedure given by
Leslie Matthies6 to distinguish it from a task outline.
It is a write-up that reflects the system. It is a document that spells out clearly how an
activity flow proceeds from one work group to the next, down through the system channel
from start to finish.
It is a step-by-step instruction concentrating on the flow of work between
people. The main emphasis is on what is done rather than the how to. It may
10 include the how to but usually not in the same detail as a tack outline.
The procedures emphasis is on teamwork telling all the team members how
their work fits into the overall processor how the work proceeds from step to
step. Where you need a great amount of fine detail, you would cross-reference it to
a task outline. Figure 2.2 shows a typical Playscript procedure.
Task outline
This tells how to perform a certain task. It covers all the step-by-step detail,
usually leaving nothing out, and covering every alternative and optional course of
action. It describes the method of doing the job with the how to do it having
the greatest emphasis rather than what is done. You could call it a one-person
procedure. Figure 2.3 shows a typical task outline.
The task outline should be so comprehensive and straight forward that a new
person can follow it with little or no outside help. The intent of the task outline is to
give an employee all the information they need to perform the task.
Remember, if you can explain a task to someone in person, you should be
able to explain it in writing.
Form usage specification

This is similar to a task outline, describing each data field in detail and
6 Matthies, Leslie H. (1977) The New Playscript Procedure, Office Publications Inc., Stamford.
how to fill it in. My experience is that while possibly being of use in a system
description, or as part of the forms History File, it is usually a waste of time in
user documentation. Such a specification should be unnecessary if the form is well
designed and the procedures and task outlines are well written.
Supplementary data
This would include lists of codes, glossaries, error messages, etc. These are
often vital parts of a computer system that must be made known to the user.
Index and Table of Contents

All the good writing and sound structure is useless if people cant find what
they are looking for. Each manual certainly needs a good Table of Contents at the
front, listing all the procedures, task outlines and other documents in the manual.
An alphabetic subject index can also be a great help, but will require much effort
to prepare it effectively and especially to keep it up to date. The key question is: do
you really want to update the subject index every time you change a procedure?
If you hold the procedures on a computer then you probably wont need a
detailed index. A good computer system should allow you to search for keywords
or synonyms.
Figure 2.2 Page from a Playscript procedure

Subject
Action by
Purchasing items for the Association
Step Action performed
PPU020
11
Purchaser 1. PHONE the Association office and ask for a purchase order
number.
2. DESCRIBE the item and the total amount of money that
will be required.
Secretary 3. CHECK the Authorisation to buy list issued by the Branch
Council.
If the purchaser is on the list
3a GIVE the person the next order number.
If not on the list
3b ADVISE the person who has authority to order.
4. ENTER details into the Purchase Log.

Purchaser 5. GIVE the Purchase Order number to the vendor and ask
that the number be shown on the invoice.
If paying by cash
5a. OBTAIN the signature of the person receiving the
money plus the word PAID on the invoice.
If it is a credit purchase
5b INSTRUCT vendor to send the invoice to the
Association, marked Attention Treasurer.
Vendor 6. SHOW the Order Number on the Invoice.
-----------------------------
Figure 2.3 Page from a Task Outline
Subject New File Allocation TRM003
Performed by: Records Manager
Frequency: Whenever a new file is requested
1. COLLECT all relevant information about the file subject.

2. DETERMINE whether there is a keyword allocation that covers the subject.
If not arrange allocation of new Keyword (see Task Outline No TRM 001).
3. EXAMINE the numeric keyword index to find out if special file subdivisions are
used.
If so DETERMINE category.
Note: If the subject doesnt fit into an existing subdivision and it appears necessary
to open a new group, check with the manager of the department concerned before
allocating.
4. ALLOCATE next available file number.
5. SELECT appropriate descriptors(see Task Outline No TRM 002).
6. ENTER details onto Index Maintenance form (No. 765).
7. DETERMINE the file retention periods for the record type in accordance with the
needs of the user department.
8. ENTER Active file retention period on Record Location Maintenance form (No.
12 767).
-----------------------
Putting the facets together

Many systems and administrative people try to combine all the different
facets of documentation in one single formata narrativebut it just doesnt
work effectively. To complicate matters, they are usually written in poor English
with long, verbose sentences that leave the reader bewildered. How many times
have you read such a procedure and found that you needed to read it again to
understand what it was getting at? Some writers take great pride in their lengthy
discourses and seem to be more impressed by volume than clarity.
Leslie Matthies calls narrative procedures jellyfish procedures with no struc
ture, no pattern and no skeleton. Figure 2.4 shows a typical example. They usually
miss out on two essential components:
1. A clear starting point
2. A clear ending point.
This is the most fundamental issue when learning to write effective procedures.
Every procedure and task outline is triggered by some eventbe it a phone call,
paper arriving in an in-tray or an e-mail. This is where the task starts. But the
operative also has to know when the task is finished so that they arent left hanging,
wonding if theres anything else to do.
Figure 2.4 A Typical Narrative Procedure
Word Processing Request

When work of any kind (excluding photocopying) is sent to the Word Processing Ser-
vices Centre by other than the Telephone Dictation System, it MUST be accompanied
by a Word Processing Request.
It is important that the Word Processing Request be completed clearly and correctly
to ensure that staff in the Word Processing Services Centre can meet the requirements
of Centre users.
To complete a Word Processing Request, insert the originators name, department or
title, extension number and the date and time originated (to nearest quarter-hour) at
the top of the form. If copies are required, state the number of copies in addition to
the original to be produced (e.g. an original plus two copies should be stated as 2
and not 1 + 2 or 3. Tick the appropriate box in the Category of Work section
and insert any Standard Letter number(s) and/or form number(s). Indicate if there are
any Special Instructions (e.g. urgent, confidential, draft, extended retention, special
format or stationery), details of the signatory (if not the originator, etc.).
NOTE: If the work is urgent a required by time must also be shown.
When requesting typing of a large volume of work, which it is not possible to type or
which is not required within the processing time for routine work, Centre users should
specify in the special instructions section the date and/or time the work is required.
Insert the originators name in the box at the bottom of the form.
When relevant for standard work, record the variable details on the back of the form. 13
Note that if the details of two different standard letters are shown on a Word Process-
ing Request, it is necessary to indicate clearly on the back of the form the Standard
Letter number clearly to which each group of variables applies.
Many writers produce a highly structured version of the narrativesometimes

called Outline format, and not to be confused with a Playscript task outlinein
which each section, subsection and paragraph is clearly labelled and numbered to
aid identification of material and to show the outline structure. This is the method
I use for system descriptions and policy statements. But its use for procedures has
a number of disadvantages.
In the mid 1960s I was introduced to a different approach for procedure
writing. It listed the steps in a procedure in the exact sequence in which they
were to be done. Each step was numbered and started with a verb to highlight the
action to be performed. It was easy to write, simple for users to understand, and
great for seeing the overview of the system.
The most well known version of this approach is Playscript, developed by
Leslie H. Matthies, yet it is one of the least understood. Some writers have been
highly critical of it, but I believe that most of their criticism is unjustified and
based on insufficient knowledge of its operation. Some have based their critical
comments on the first edition of Matthies book. It has since been updated and
readers are advised to evaluate any criticism in the light of his later findings.
Its main thrust is to cull policy and general descriptive material leaving
behind the step-by-step detail of how to carry out the procedure. Having culled
this material, Matthies further breaks down the content into two separate types of
documents, Procedures and Task Outlines.
An overview of Playscript
I have been writing procedures for over forty years and have seen and tried
a great variety of systems. Some of them have been complete failures while others
have been reasonably successful.
When I was introduced to Playscript, we found problems with the way it
was being used and tried various ways to get around them. Later, we discovered
that we had not been given the full story. Matthies covered many of the problems
we encountered and it became clear that our criticisms were not justified. It was
we who were wrong; we werent using Playscript as intended to be used. Part of
this came about because Leslie Matthies book was written primarily to sell the
method, rather than to explain the fine detail of how it worked.
We didnt differentiate policy from step-by-step detail.
We didnt make provision for complex decision-making instructions.
We tried to write everything the same way when we should have used
different methods for different types of material.
14 The following five guidelines are what I use to produce effective user
manuals.
1. Write up any procedural and system policy or objectives in narrative or
Outline format.
2. Use Playscript Procedures to describe the overall workflow procedures
for every system and subsystem within the organisation. These explain
what is done.
3. Write detailed task outlines using the Playscript format where there is a
need for fine step-by-step detail for an individual employee. These explain
how to carry out each task.
4. Incorporate brief task-oriented policy and objectives at the top of task
outlines wherever there is a need for the individual to know them. These
explain why the task is being carried out.
5. Write up system descriptions and similar documentation as captioned
narratives.
The advantages and uses of Playscript

I have sometimes been accused of thinking too narrowly when recommending
Playscript. In some cases this has been because the client didnt want to be locked
into a single writing system. But my choice comes from many years experience as
an analyst, writer and user. The following points summarise its main advantages.
It establishes and clarifies responsibility

People who want to keep the work pattern vague so that they can pass the
buck may not like the method and this can be the real reason behind some peoples
objections. Playscript establishes exactly who is responsible for each action in a
system or procedure. Employees can readily see if they are involved in a particular
procedure. Likewise, managers can see the relationship of their departments to the
others involved in the flow of work.
It is a tool for getting agreement

Getting people to agree on what actually happens in an undocumented
system can be a problem. Even if you document the system using a narrative style,
the meaning can be muddy and agreement all but impossible.
Playscript clarifies the procedure. Either a specific step happens or it doesnt. It
helps the people to see the system clearly and not have to go searching through the
text for the unexpected. It also forces decisions to be made on work responsibilities
since these have to be clearly spelled out and the people identified.
It helps management
It is a great advantage to management whenever there is any dispute about the
way to do something. Management time is usually scarce and managers appreciate
having a procedural system that enables them to quickly locate troublesome
areas.
15
Playscript simplifies writing
While using a standard format such as this places restrictions on writers,
it is so simple that anyone who can write in plain language can use it effec
tively, and professional writers are not necessary. It helps to force writers to use
simple language. While the best results are going to come about if the writers
are professional analysts, I have had a great deal of success in training staff
to write their own Playscript procedures and task outlines. Leslie Matthies found
that most people learned to write clearly after only 5 or 6 hours of training and
practice. In my own consulting work, I have had similar results with procedure
writers being able to produce clear and logical procedures after only a few short
review sessions.
It forces brevity
Experience shows that any writer using Playscript automatically shortens the
statements and cuts out excessive description. The direct nature of the language,
using action verbs, brings this about.
It simplifies the finding of information

Because the content of a Playscript procedure is in step-by-step time sequence,
users find it easy to look up work details and locate relevant information.
It provides a uniform format

A formal method such as this forces a uniform format on the organisation
so that no matter where a person is working, the procedures can be clearly
followed. They are the organisations procedures, not those of the individual
manager or section. So a standard approach is going to bring rewards throughout
the organisation. In fact, the larger the organisation, the better the results. As
people move around from one job to another, they find they are familiar with the
approach and understand the procedures far more readily than when each section
has its own approach.
It provides for easier handling of non-routine procedures

Most organisations have unusual or non-routine procedures that raise their
heads only occasionally. These are the ones that are often forgotten. Playscript
is most effective in this area as users can refer to the procedure and carry it out
successfully and efficiently without the need to ask someone else what to do.
This is the area that causes so many probems for writers of procedure manuals
and has been one of the causes of much criticism of the PlayScript method by
people who didnt understand it fully.
Even though Playscript as developed by Leslie Matthies handles non-routine
procedures, they can still be very troublesome for the writer. Since the first edition
of Practical Playscript was written, we have been able to apply the results of modern
questionnaire-design research to the writing of procedures.
16 Over the past 20 years I have done a great deal of work with questionnaire design,
initially when working as a Senior Research Associate with the Communication
Research Institute of Australia and later in our own consulting business. Much of
the latter work has been with complex application forms for government and the
insurance and finance industries. The more I worked with these application forms,
the more I realised the similarity with the structure of Playscript procedures and
this has simplified the construction of complex routines.
Chapter 4 of this edition includes the application of that research to procedure
manuals.
It simplifies the introduction of change

It is particularly beneficial when you change a procedure. Users can see at a
glance just what the new procedure requires. Even experienced users need this
type of assistance. It is so easy to follow, that people who have been used to reading
procedures written in this style can readily write up their own new procedures in
roughly the right format.
It makes procedure linkage easy

The format makes it easy to link procedures. Other systems can certainly
do the same, but Playscript forces the linking together since no procedure series
should end with the reader left hanging with nowhere to go. If the procedures are
produced in electronic format, this linkage becomes even easier.
It helps the training of new employees

One of the most difficult tasks in inducting new employees into an organisa
tion is training them in their day-to-day work. Even after the oral description of
how to carry out a task, a new employee will usually want to look up any written
procedures. If these are in narrative format, it can be a long, tedious task to find
relevant information. My experience is that well-written Playscript procedures
are so easily followed that new employees can usually understand them with little
need to seek clarification from a supervisor.
It assists systems analysis

It is particularly valuable for analysts working on systems changes as it enables
them to clearly see exactly what happens at each step. It also helps analysts, when
they are developing new systems, to analyse those procedures that are too long. It
shows up duplication of effort or procedures where there is a constant flow of work
backwards and forwards between particular employees. Often, you can simplify a
procedure by having all these tasks combined so that paper moves less frequently.
An effective paper flow diagram will show up the same problem. Software such
as Business Process Charting from The Ben Graham Corporation can automatically
produce output to Playscript format (see www.worksimp.com).
Analysts find it a great help in sifting out unwanted material during system
development. I have found it a great interview time-saver because it helps to control
the direction of the interview. The person with a tendency to waffle can be brought
back to the point very quickly by being directed to the step under discussion.
17
It provides an effective audit trail
Its detailed step-by-step approach helps the systems auditor work through
the procedure from the point of view of theoretical controls and the practical
application by the workers.
It can be used in any organisation

I have used it successfully in a small organisation with only 15 employees and
in large government departments. It is ideally suited to a very large organisation
since it organises and simplifies the writing process and it works in government as
well as in private enterprise.
Suitability for on-line documentation

Playscripts structure means that you can easily use it for on-line procedure
manuals. This is particularly valuable in large organisations such as banks and
insurance companies where most workers have access to a computer terminal. Its
simple format, originally developed for typewriters, makes it ideal for text-based
systems. Text systems that can link documents can take advantage of Playscripts
built-in cross-referencing.
18
Chapter 3
Rules of Structure
If you intend to use Playscript, or are already using it, I recommend that
you read Leslie Matthies books Documents To Manage By and The New Playsript 19
Procedure for a useful and entertaining background to the method.
However, I have written this book as a training tool and have structured the
content in a straight through sequence, starting at the top of a procedure and
working down through the body with its various components and physical layout.
The basic rules of simple procedures are covered first with the more complex
subroutines dealt with in more detail later.
Changing the format

Matthies is very specific when it comes to physical layout, getting down
to specifying exactly how wide columns should be and so on. Bearing in mind
that he is writing for the US market, these would need to change when using
International Standard paper sizes with metric measurements, or with the use of
word processors and modern computers with proportional spacing. There may
also be other specific needs in your organisation that require you to override his
suggestions. On the other hand, there is no point in changing the basic approach
just for the sake of being different. As he says:
Most modifications of Playscript that I have seen are a form of backsliding. People go back
to experiment and use variations that we tried and abandoned years ago. Usually these
people are making the same mistakes and performing the same experiments that we did.
They are reinventing the wheel.
If you try to modify a proven, effective technique, all youre doing is improving
backwards. Fifteen years of research has developed a format that works. Another twelve
years of application in organizations of every type has convinced us that this is THE
format.
Procedures versus other material

This is the area where most people fall down in their understanding of Playscript.
They dont separate policy statements and other systems documentation.
Procedures are different to other typs of business documentsthey are
written for a different purposeand they are necessarily structured differently. I
have covered this in Chapters 1 and 2, but it needs repeating because it is such an
important concept. Playscript just doesnt work unless this is understood.
Using a standard layout form

In the larger organisation there is a strong case for using a standard layout
form. Figure 3.1 shows two examples I have encountered, but Im not suggest
ing either of these is ideal. You should develop what is most practical for your
organisation. It is not just a matter of dressing up the procedures to make them
look pretty, but is of practical value in giving them an official appearance. They
become a standard document that is more likely to gain acceptance.
Some people like to add the name of the function or using department to
20 the word procedure, but this may be redundant. They are the procedures for the
organisation, so you may only need to preprint the organisations name and/or
logo. This provides for standardisation throughout the organisation.
Page title
People call procedures by an incredibly wide variety of names. One of the
more common names that I have encounteredand one that Matthies also
mentionsis Standard Practice Instruction. On the other hand, some organi
sations use the word procedure when they arent procedures at all.
We are talking specifically about procedures here, so why not use the word?
It makes sense and everyone will know what it means.
The subject
Every procedure should state the subject. This is the key to indexing the
procedures and, although brief, should state clearly what the procedure deals with.
If you are indexing them using a keyword system then you will need to carefully
select every word in the subject. You will also need to make sure that no two
procedures in the organisation use the same subject.
If you are producing an index using an automatic indexing program such as
that in Microsoft Word or Adobe InDesign, then you will be able to add additional
hidden index words. If so, I suggest using the approach that I use when developing
an alphabetic index for a book such as this. Read through the procedure and ask
Chapter 3 Rules of Structure
what people would look up in the index if they were searching for the procedure.
Remember that people dont all think alike and will not necessarily look for the
same words that you would use. The subject should reappear at the top of each
separate procedure sheet. The matter of multiple pages is covered in more detail
under Page number.
Figure 3.1 Examples of preprinted headings
Procedure
Section Subsection Section No.
Procedure No.
Procedure No.
21
Subject Date
Date of the procedure

There can be many dates associated with the writing and publishing of a
procedure but I strongly support the idea that only one should appear on itthe
effective date. All other dates such as approval date, distribution date, printing
date and draft dates should be kept on the relevant procedures file or work folder,
not on the procedure itself.
Procedure number
Like its counterpart, the form number, this is one of those controversial
aspects of procedures. Yet, I have found that most people have little real basis for
their opinions. The way in which you number the procedures will depend on the
size and type of organisation for which theyre written and especially the number
of different types of manuals in use.
Some organisations number their procedures by department or section, but
procedures reflect business functions that can cross over departmental bound
aries. Categorising your procedures by department or section may be breaking
them down artificially and often to no advantage.
Another method is to categorise them by systems project. Now, we might
think that since procedures are system-based that this is the way to go, but
experience shows that, in the long term, this method doesnt work either. System
project groupings are usually chosen arbitrarily to reflect the work being carried
out at a specific period of time. On the other hand, the systems staff may have
chosen them because that particular group of procedures was all that they could
handle at any one time with the staff available. The development staff usually think
of tasks that have to be done to make the computer system work.
Added to both these problems is the matter of change. As soon as there is a
change to a system, or a regrouping of departments or sections, the old boundaries
may cease to exist and the total numbering system may have to change.
The solution is to categorise procedures by business function. In many cases
such functions will coincide with departmental boundaries and computer systems,
but I want to stress that this may be just coincidence. As many people have found
when they tried to number procedures by department or system, just because
22 function coincides with department or system at the time it is introduced, it is no
guarantee that it will continue into the future. I suggest that it should be corporate
policy that manuals are to be structured by function, unless there is a strong case
for doing otherwise in your organisation.
As for the numbering of the manuals, there are many approaches. Some
procedures analysts suggest that the best method is to number sequentially from
1 with a good alphabetic index. This is the same approach recommended by
most professional forms analysts for form numbering. It definitely works with
forms, but they are not like procedures. The practical use and reading process is
different. A form may be a part of the overall business system, but it is generally
used in isolation. Users often have to read a procedure in conjunction with related
procedures so that they can understand the whole system. The procedure is a
reference document, not a one-at-a-time resource.
My preference is to follow a system such as that given by Jean dAgenais &
John Curruthers1. From my experience it is more appropriate to large organi
sations. It breaks manuals up by business function rather than computer system or
department. Although dAgenais & Curruthers dont suggest it, I would give each
type of manual a two (or three) character alphabetic code starting at AA and
working sequentially to ZZ. Note that the codes themselves have no functional
1 dAgenais, Jean & Carruthers, John (1985) Creating Effective Manuals, South-Western Publishing Company,
Cincinnati Ohio.
significancethey are solely for identification and indexing. You would then break
each Manual down into Section, Subsection and Subject, each with a two-digit
code separated by spaces or dashes. The introductory pages would normally be in
Section 00. For example, you could classify the procedure for applying for annual
leave in the Human Resources Manual (Code HR) as HR-02-05-01:
SECTION 02 Leave
SUBSECTION 05 Annual
SUBJECT 01 Application
Following the same pattern, the document giving an overview of the
companys Annual Leave policy could be HR-02-05-00:
This construction allows for greater flexibility for the user. Related proce
dures are close to one another and save the user looking up indexes when the
whole function is being studied.
Page number
A well-planned Playscript procedure will usually have a maximum of about 25
work statements. This means that the average procedure could go on the front and
back of a single sheet of paper. Some people claim that short procedures dont need
page numbers. However, if you are using word processing software it is usually an
advantage to automatically number the pages. You may also find that it is helpful
to have the subject and page number on every page so that they dont get mixed up
in reproduction and filing. However, dont number the pages continuously for the
whole manual. Start each procedure at page 1. 23
Procedure layout
Playscript is written like a play and each step has four main ingredients:
1. action by (person performing the action)
2. logical step sequence number
3. action word (verb)
4. action performed
A normal Playscript page is laid out in columns as shown in Figure 3.2. Since
Playscript was devised, the introduction of International Standard paper sizes (e.g.
A4) and the use of computers for word processing has changed the way procedures
can be laid out. While it is possible to use a fixed pitch typeface such as Courier,
you would be more likely to use proportionally spaced type such as Times New
Roman. The amount of space you use will depend on the typeface and size you
have chosen. For space reasons in this book, the following example uses 8 point
New Century Schoolbook. On a full-size page, I would increase this to 10 point,
or 11 point if using Times New Roman (since it is a smaller typeface) and vary the
column width accordingly.
Figure 3.2 Layout of a Playscript page
Action by Step Action performed
Secretary 1. SORT time cards by department, placing in Time Summary En-

velope (Form 683), entering department designation.
2. DELIVER to time clerks.
Time Clerk 3. PREPARE time cards as instructed in procedure
02-04-04, Daily Time Tickets.
Employee (all) 4. SIGN time card at start of each day, writing department number
after signature, enclosing in parentheses, such as (12), (15), (17),
etc.
The margins you leave will depend on your binding mechanism and the
method you use for production. If you are using a typewriter or similar mechanical
device, you will probably need at least 25 mm (1 inch) at the bottom for a gripper.
If using a laser printer, you could reduce this. Figure 3.3 shows a suggested spacing
for each column. Note that the inch measurement only approximates the metric
measurement.
Figure 3.3 Suggested spacing for a Playscript page
A4 page 81/2 x 11 inch page

24
Left hand margin 25 mm 1 inch
Action By column 40 mm 11/2 inches
Sequence Number column 10 mm 1/3 inch
Action Performed column 110 mm 41/3 inches
Right hand margin 25 mm 1 inch
Column headings
Some people prefer the column headings to be over the centre of the columns.
My preference is to align them to the left as this is an easier typing action and may
also provide for greater reading clarity. This is another of those points that should
not be a major issue.
The Action by column

This shows who is responsible for carrying out the particular action. Some
users prefer the column to be headed with the word ACTOR although I believe
this is somewhat puerile. Others use terms such as Performed by, Doer, Person or
Action by. Using Person could be limiting as some actions could be left open to be
performed by any person in a section. I prefer Action by, but the wording is not a
major issue. Use whatever suits your organisation.
The white space around each Action by title clearly shows where the person
comes on and off the stage and how each action fits with the activities of other
people in the workflow.
Only the first word of the persons work position needs a capital initial letter
unless it is an official position title. In this case, each word would normally be
capitalised.
If you have a long title that must be written in full, then use two lines. You
could align the second line to the right or left, although the left takes less typing
activity. Alternatively, you could indent the second line a few spaces. Figure 3.4
shows three examples of the same step showing how it would appear. Note that the
last example has the Action performed starting on the same line as the second line
of Action by. If you are using a typewriter, this will probably be easier, but takes up
more space. My preference is for the first version.
Figure 3.4 Variations of multiline Action by descriptions

Plant and 5. INDICATE on the form when preliminary action
Facilities Engineer will be taken to investigate the matter.
Plant and 5. INDICATE on the form when preliminary action

Facilities Engineer will be taken to investigate the matter.
Plant and
Facilities Engineer 5. INDICATE on the form when preliminary action
25
will be taken to investigate the matter.
Step column
The step number is the logical sequence of the steps in time order and always
starts at 1 at the beginning of every procedure. The numbers would often be right
aligned so that where the number of steps reaches 10 or more, all numbers will be
aligned for neatness. Step sequence is covered later in the chapter.
Action performed column

Each action step normally begins with a verb as described later in this chap
ter, although there are some exceptions, notably when you have to give a timing
instruction. Where these timing notes represent a break in the action, I prefer to
use capital letters and underline them as shown in Step 8 in Figure 3.5. In this
example, there has been a break in the activity while the Association waits for the
vendor to send in the invoice.
Some users of Playscript disagree with the use of such a statement, saying
that it is redundant. I agree that this procedure makes sense without it since the
checking cannot take place until the Invoice has been received, but it highlights
the delay and makes it easier for the user to find the relevant place in the pro
cedure. Of course, you could logically argue that a break such as this should not
occur and that the Secretarys step, being a trigger action, should be the start of
a separate procedure. In fact, in a longer procedure, there would be a total break
here and a new procedure started. In this case it is only short, but the Secretary
needs to be able to pick up the flow easily at the point where it starts again, and I
have found underlining ideal for achieving this.
You can also use highlighting and underlining for branching activities and
alternative paths. This is covered in detail in Chapter 4.
Figure 3.5 Action column with timing break
-----------------
Purchaser 5. GIVE the Purchase Order number to the vendor and ask
that the number be shown on the invoice.
6. INSTRUCT vendor to send the Invoice to the Association,
marked Attention Treasurer.
Vendor 7. SHOW the Order Number on the Invoice and send it to
the Association as requested.
ON RECEIPT OF INVOICE
Association 8. CHECK with purchaser to make sure that items have
Secretary been received and note this on the Invoice.
26 -----------------
Highlighting verbs
Even before using Playscript, I found it very profitable to start each step of a
procedure with a verb and to highlight it.
In one company, we wrote the verb in a separate column but I found this
to be a waste of space and it makes reading unnatural. It is better to keep the
verb in the sentence context, maybe highlighting it in bold type. With modern
word processing systems this is an easy operation. You could use capital letters or
underlining in addition to bold type, or as an alternative to it. I have found this
approach advantageous for the following reasons:
1. Outline
The bold verbs provide an instant outline of the task outline or procedure.
2. Fast location
They help the reader go to a specific point in a procedure without the need to
read through from the start.
3. Memory assistance
They can assist a user who is working directly from the procedural text to carry
out a task. They assist the user to find the next step in the procedure once they
come back to it after completing the preceding step.
Verb tense
The verb is always in the present tense and may be in either the second or
third person. In the example in Figure 3.6, it is in the second person, which is my
preference since it is an instruction, but it is not wrong to use the third person.
For example: 2nd person 3rd person
SORT or SORTS
DELIVER or DELIVERS
SIGN or SIGNS
The third person may be better for straight through reading, but the second
person is more direct as an instruction.
This system relies on every sentence beginning with a verbsomething
that isnt always practical. For example, a step may begin with timing or other
information that shows when it is to commence. Figure 3.6 shows part of a
procedure using this approach. But note that the layout isnt compatible with
normal Playscript.
Figure 3.6 An action step with built-in timing instructions
Secretary 1. Upon receipt of time cards,

SORT by department, place in Time Summary Envelope
2.
Form 683, entering department designation.
DELIVER to time clerks.
27
Time Clerk 3. DISTRIBUTE time cards to all personnel.
Employee (all) 4. PREPARE time cards as instructed in procedure 02-04-
04, Daily Time Tickets.
5. SIGN time card at start of each day, writing department
number in parentheses after signature.
-----------------
A way around this is to turn the timing instruction into a subheading so that
the actual steps do begin with a verb immediately after the step number as shown
in Figure 3.7.
Combining actions in one step

Normally each separate action verb begins a new step, but sometimes this can
be confusing. For example, step 2 in Figure 3.8 uses two verbs.
On the other hand, it could have been written in two steps as shown in Figure
3.9. This approach may imply that they are two totally separate steps, whereas they
actually happen consecutively while the file is in front of the Records Officer. In
this case, you may prefer the original method.
Figure 3.7 Timing instructions removed from action step
UPON RECEIPT OF TIME CARDS

Secretary 1. SORT by department, place in Time Summary Envelope
Form 683, entering department designation.
2. DELIVER to time clerks.
Time Clerk 3. DISTRIBUTE time cards to all personnel.
Employee (all) 4. PREPARE time cards as instructed in procedure 02-04-04,
Daily Time Tickets.
5. SIGN time card at start of each day, writing department
number in parentheses after signature.
-----------------
Figure 3.8 Step 2 combines two actions in one step (examine and note)
Requestor 1. PHONE the Records Office to determine whether or not

the required Security File is available.
Records 2. EXAMINE the Security File Reference Record (Form No.
28 Officer 354) to ensure that the file has been cleared by the request-
Second action or, and note on the form the name of the requestor, the date
of the request and the fact that the question was asked.
-----------------
Figure 3.9 Separating a combined action into two steps

Records 2. EXAMINE the Security File Reference Record (Form No.
Officer 354) to ensure that the file has been cleared by the re-
questor.
3. NOTE on the form the name of the requestor, the date of
the request and the fact that the question was asked.
-----------------
Figure 3.10 contains two totally separate actions included together as if they
happen at the same time. Figure 3.11 is a better arrangement.
Figure 3.10 Step combining two totally different actions
Supervisor -----------------
4. ASK Department Head for approval. Tell the employee
that the official leave will be granted by personnel and that
a note will be sent to that effect.
Figure 3.11 Step rewritten to show the two actions
Supervisor -----------------
4. ASK Department Head for approval.
5. TELL the employee that the official leave will be granted
by personnel and that a note will be sent to that effect.
Spacing between lines and steps

The action steps should be single spaced (or with one or two points of leading)
so that the action forms a block as shown in Figure 3.12. The steps themselves 29
should have extra space between them.
Figure 3.12 Action step forming a block

2. EXAMINE the Security File Reference Record (Form No.
354) to ensure that the file has been cleared by the request-
or, and note on the form the name of the requestor, the date
of the request and the fact that the question was asked.
-----------------
Sequence of steps
To determine the sequence of steps, think in terms of time. A procedure is a
series of activities being carried out by people in a logical sequence. Except where
there is a branching activity and two things are happening at the one time, the
steps take place in strict time sequenceone after the other.
As Matthies2 says:
some people write their procedures as though this logical time sequence didnt exist.
For example, if an employee is applying for leave, the steps could occur as
follows:
MONDAY 9.00 a.m. Employee fills in Leave Application Form.

MONDAY 10.30 a.m. Supervisor signs application form.
MONDAY 11.00 a.m. Manager approves time allocation for leave.
TUESDAY 3.00 p.m. Personnel Manager approves leave.
TUESDAY 4.30 p.m. Personnel Manager advises Paymaster the persons leave
is approved.
FRIDAY 3.30 p.m. Paymaster pays leave pay.
FRIDAY 5.00 p.m. Employee goes on leave.
This is the sequence in which the steps occur, so unless there are exceptions
this is the sequence in which the procedure will be written. Branching activities
and alternative paths are dealt with in Chapter 4.
The main work sequence follows the action, not the piece of paper. The
following is a summary of the process. Chapter 7 covers it in more detail and
explains how to identify the work channels.
The starting point

30 The starting point for each procedure is a trigger action. Something
happens in the organisation to make an activity take place. Perhaps an order has
arrived in the mail, or a telephone call has been received, or a person has decided
to apply for leave. Each procedure should start with this event.
Figure 3.13 shows some typical trigger actions.
Figure 3.13 Some typical trigger actions
Insured 1. PHONE to advise that car has been in an accident and

person that a claim will be forthcoming.
Cashier 1. RECEIVE cash from customer, count amount and place to

one side on counter.
Mail Clerk 1. OPEN mail bag and empty onto sorting table.
Employee 1. FILL IN Leave Application form and take it to Supervisor

for approval.
The work cycle

Matthies3 make a very important point about this subject that needs stressing
here.
Cycle selection is not a technique or an exact science. It is an art.
There are no clear-cut rules to establish where one work cycle finishes and
another starts, but I can give some guidelines.
First, select the start point (trigger) and the end point (result). If your proce
dure has 20 to 30 steps then you can probably leave it as it is. On the other hand,
if it has 100 steps you may need to see if you can break it down into two or three
separate procedures.
But breaking it down into smaller procedures just for the purpose of conve
nience is not the prime consideration. You need to ask why the procedure has so
many steps. Does it contain any long series of steps for one person? If it does, it is
likely that these should be extracted and made into a task outline.
Assuming that the steps are necessary, look for breaks or delay points in the
procedurethose points where the activity stops for a time, waiting for something
else to happen. The next step is a new trigger because whatever we were waiting
for takes place. This is the logical place to break a procedure. Figures 3.14 and 3.15
show two examples of break points resulting from delays.
Figure 3.14 Procedure with built-in break

31
Claims Controller -----------------
23. ADVISE the insurer of the claim.
24. ESTABLISH the insurers requirements for lodging
the claim.
25. ARRANGE for an assessor to visit the client.
Assessor 26. VISIT the client and assesses the damage.
Delay
27. REPORT to the Claims Controller on the assessment
of the damage.
Claims Controller 28. COMPLETE claim form.
29. send completed claim form to insurer.
Subroutines and side channels

These are the most complex part of procedures and the area where most
people go wrong in using Playscript. Because of their complexity I have dealt with
them separately in Chapter 4.
Figure 3.15 Break into two procedures at delay point
Claims Controller -----------------

23. ADVISE the insurer of the claim.
24. ESTABLISH the insurers requirements for lodging
the claim.
Assessor 26. VISIT the client and assesses the damage.
It is at this point that a delay occurs while the damage is assessed.

Delay This is a logical point to divide the procedure into two parts with a
new procedure starting at step 1.
Claims Controller 1. RECEIVE report from Assessor on the assessment of

the damage.
2. COMPLETE claim form.
3. send completed claim form to insurer.
32 Gaps in the action sequence

Playscript is ideal for detecting gaps in the action sequence. This is an impor
tant part of procedure development and one of the main problems with narrative
formats. Each step must lead logically to the next step, or to a branching step in the
same procedure, or to another procedure altogether.
Inclusion of functions/policy
I agree very much with Leslie Matthies when he says that you should keep
matters such as departmental functions and systems separate. But I have found
a few occasions when it was helpful for the user to read a brief description of
the tasks function first. Statements of timing can be included under separate
subheadings. This is covered in more detail in Chapter 5.
Signatures and initials

It is unnecessary to publish approval signatures with each procedure. If
approvals are necessary then they can be recorded in the procedure file. The same
applies to initials of the approving authority.
There is also a tendency in some organisations to include the name, signature
or initials of the person who wrote up the procedure. Again, you should have this
information in the procedure history file but I have doubts about its value on the
procedure itself.
Chapter 4
Subroutines and Side Channels
These are the most difficult parts of any procedure and Playscript is no excep
tion. Subroutines occur whenever there is a decision-making point in a procedure. 33
In some cases there can even be decision-making points within a subroutine.
There are no firm rules for handling them, as you need to deal with each
procedure on its merits. The following principles provide guidelines for subroutines
of different complexities. As Ive mentioned in earlier chapters, in this edition of
Practical Playscript Ive added additional material based on more recent research
in human communication. The technique is based on the extensive success that has
been achieved through the use of questionnaires in the design of business forms.
It occurred to me that there is little difference between a numbered sequence of
questions in a form and a series of steps in a procedure. Both involve step-by-step
progress with action at each step. The advantage of the approach is that it simplifies
complex decision making routines using questions with Yes/No answers and
routing to relevant steps. The approach is explained in more detail later in the
chapter.
Short side channel involving one person

This occurs where there is a separate path for a small number of steps (up
to 4 or 5 steps). For example, a procedure for a cashier receiving money might
require a couple of different steps for processing cheques to what is required for
processing credit cards. After the payment is processed through these different
steps, the procedure returns to the main channel and everything else is handled
the same way.
Provided at least one of the two channels can be included in a single step,
indent the side channel using the same step number, but with lower case alpha
suffixes to indicate the substeps.
Figures 4.1 and 4.2 show two possible ways of handling the same side
channel.
Note that the second example highlights the alternative payments more
effectively and draws the cashiers attention to the fact that there are two different
actions.
After the side channel is completed, the procedure returns to the normal
position and numbering sequence.
Figure 4.1 Handling a short side channel alternative 1
Applicant -----------------
5. HAND payment and completed Application Form to the
Cashier.
Cashier 6. EXAMINE Application Form to verify amount to be paid
and, if paying with currency, enter amount into cash
register.
6a. If paying by cheque, EXAMINE Stop List to
determine whether cheques are acceptable from this
applicant.
34 6b. If cheques are not acceptable, TELL applicant to go to
the enquiry counter.
7. RECORD receipt on Application Form butt and return it
to the Applicant.
Figure 4.2 Handling a short side channel alternative 2

Applicant -----------------
5. HAND payment and completed Application Form to the
Cashier.
Cashier 6. EXAMINE Application Form to verify amount to be paid.
if paying with currency
6a. ENTER amount into cash register.
if paying BY CHEQUE
6b. EXAMINE Stop List to determine whether cheques
are acceptable from this applicant.
6c. If cheques are not acceptable, TELL applicant to go to
the enquiry counter.
7. RECORD receipt on Application Form butt and return it

to the Applicant.
Chapter 4 Subroutines and Side Channels
Short side channel involving more than one person

This is essentially the same as the previous type but it involves another person
in the side channel. It can be handled as shown in Figure 4.3.
Note that the change in person occurs within step 5. Step 6 does not start
until the side channel has been completed.
Figure 4.3 Side channel involving more than one person
Purchaser -----------------
5. GIVE the Purchase Order number to the vendor and ask
that the number be shown on the Invoice.
if paying by cash
5a. OBTAIN the signature of the person receiving the
cash plus the word PAID on the Invoice.
If credit purchase
5b. INSTRUCT the vendor to send the Invoice to the
Company marked Attention Accounts.
Vendor 5c. SHOW the order number on the Invoice and send it to
the company as requested.
Accountant 6. on receipt of invoice 35
check with purchaser to make sure that items have
been received and note this on the invoice.
Two short alternative channels with multiple steps

In this case, both channels have a number of steps. It doesnt occur very
frequently in procedures, although I have found many situations where I could use
it in task outlines. It is better to start each channel with a separate Step Number
and underline the heading as illustrated in Figure 4.4. The steps in each channel
retain the same Step Number as the heading so as not to confuse the reader about
where the channels finish.
Figure 4.4 Alternative channels with multiple steps
Account -----------------
Executive
7. SEND documents to Cover Note Clerk.
8. if invoice set has been produced
8a. ENTER Invoice Number in the Cover Note Control
Register.
8b. DELETE the entry from the Invoice Set Pending List.
8c. REMOVE photocopy of draft invoice from file and
destroy it.
9. if invoice set has not been produced
9a. ENTER Cover Note details in the Cover Note Control
Register.
9b. RECORD the Invoice in the Invoice Set Pending List.
9c. FILE photocopy of draft invoice in the Invoice Pending
File.
10. PREPARE Cover Expiry Record (Form No. 45) in
duplicate.
11. FILE original of the Cover Expiry Record in the Register
36 Box in expiry date sequence.
Major branch into two separate activities

Some procedures reach a point where a choice has to be made between
alternatives with the resultant activities being totally different for each. The
procedure divides into two courses of action that do not join again later.
Figures 4.5 and 4.6 show two ways you could handle it.
Referring to a separate procedure

The first method is to switch to a separate procedure for one of the channels
and continue in the same procedure for the other channel.
You should only use this where most of the activity goes though the main
channel. The act of continuing in one of the channels in the same procedure
implies that this is where most of the action is. See Figure 4.5.
Figure 4.5 Switching out to a subroutine
Records -----------------
Controller
4. SORT documents by subject.
5. EXTRACT appropriate Keyword File from cabinet and
place documents in strict date order with latest date on
top.
5a. If there is no Keyword File in existence for the subject,
switch to subroutine
go to Procedure 09-08-13.
6. RETURN the Keyword File immediately to the cabinet
and process the next set of documents as outlined above.
Switch out to a separate procedure

The second method is to switch out of the procedure completely and refer to
separate procedures for the continuing actions. Use this where there are multiple
choices or where there is no predominant channel. See Figure 4.6.
Figure 4.6 Switching out to separate procedures
Cashier -----------------
37
10. CIRCULATE cash receipts to Account Managers.
Manager 11. RETRIEVE appropriate record from file.
11a. if renewal of policy
switch to separate Go to Procedure 10-02-01.

procedures
11a. if new business
Go to Procedure 10-03-01.
The rare problem exceptions

Rare problem exceptions occur in many procedures. No matter how carefully
we might document what happens, many systems cannot handle every exception
and every potential problem. In certain types of business, covering every problem
would make the procedures so involved that it would be impossible to follow them.
This is especially so when the exceptions are occasional occurrences.
In these cases it is usually best to refer the user to a person who can handle
the situationa more knowledgeable person who has the authority to decide what
to do. See Figure 4.7.
Figure 4.7 Handling problem exceptions
Spare Parts -----------------

Clerk 10. RETRIEVE Stock Card for each item and record details of
supply.
handling problem 9a. If the item cannot be identified from the description
exception given on the order, refer the matter to the Technical
Supervisor.
Choices within a choice

This is the area of procedure manuals where writers have their greatest
problems. How do you document complex choice situations, often when there are
choices within choices or perhaps multiple choices at a single branching point?
Over the last twenty five years there has been a lot of research into human
communication, especially with regard to business forms. Researchers have found
that form fillers can progress easily through a complex form if given questions with
Yes/No type answers followed by a routing device such as Go to 8. We have
applied this technique in complex forms for a number of years and consistently
found that people follow it with ease. My book Forms For People covers the topic in
detail as it relates to forms. In thinking through the problem of complex procedure
38 routing, it became very clear to me that there was little difference between a
questionnaire style form and a procedure. The only significant difference is that
with a form, the work is done directly on the document being read whereas with a
procedure, the work is separate to the written document. So why not use the same
technique? In the following examples, Ive shown some of the issues that make
procedures difficult to follow and how they might be solved.
Figure 4.8 illustrates a complex set of choices that could confuse the readers
due to the number of choices within choices.
One solution to this problem would be to split the procedure into separate
task outlines depending on whether there is an Expiry Card. However, it would be
simpler to use the questionnaire technique as shown in Figure 4.9.
In a questionnaire type form it is generally best to have the No coming
before the Yes, since the latter often requires additional information and placing
the No first simplifies routing through the form. However, this is not relevant to
a procedure and it is more logical to place the YES first. Note that in most cases,
each YES/NO answer takes the user to a separate question for the subsequent
action.
Figure 4.8 Complex set of choices
Cover Note -----------------

Clerk
3. if there is no expiry card:
EXAMINE Invoice Pending File to see if a draft Invoice has been

received from the Account Executive.
3a. if so:
CORRECT recordsgo to Step 3e.
3b if not:
find out if an Invoice set has been issued and processed.
3c. if so:
CORRECT recordsgo to Step 3e.
3d. if not:
REQUEST Account Executive to provide a photocopy of the
draft, stamped with the INVOICE PENDING stamp.
3e. FILE the cover note alphabetically by name of insurer.
3f. PREPARE an Expiry Card (Form No. 23).
3g. FILE both copies of the Expiry Card in date order.
4. if there is an expiry card already in existence
4a. EXAMINE the card to see if the Expiry Date is the same as
39
that recorded.
4b. if so: go to Step 4c.
if not:
ENTER new Expiry Date and file in new date sequence.
-----------------
As with all Playscript procedure writing, there are no hard and fast rules
governing how you should handle choices and wording of steps. For example, in
Figure 4.9 it is easier to place the CORRECT action right after YES at steps 4
and 5 rather than create a separate step between 6 and 7 and then add additional
routing instructions. The aim is to make the procedure easy to follow. Practical use
comes before application of rigid rules. If you arent sure of the best approach, try
different techniques and conduct observational usability studies to find out which
works best. Usability testing is covered in more detail in Chapter 8.
Figure 4.9 Complex set of choices in questionnaire format
Action by Action performed
Cover Note -----------------

Clerk
3. Is there an Expiry card?
YES Go to step 10.
NO Go to next step.
4. Does the Pending File show that a draft invoice has been
received?
YES CORRECT records then go to step 7.
NO Go to next step.
5. Has an invoice been issued AND processed?
YES CORRECT records then go to step 7.
NO Go to next step.
6. REQUEST Account Executive to provide a photocopy of
the draft, stamped with the INVOICE PENDING stamp.
7. FILE the cover note alphabetically by name of insurer.
8. PREPARE an Expiry Card (Form No. 23).
9. FILE both copies of the Expiry Card in date order.
THE PROCEDURE IS NOW COMPLETE.
10. Is the Expiry Date on the card the same as that recorded?
40 YES Go to step 13.

NO Go to next step.
11. ENTER new Expiry Date.
12. FILE in new date sequence.
-----------------
Handling multiple decisions

If you reach a point in your procedure where there are so many possible
choices that you cannot document them easily, a decision table might be
the answer. You can switch the procedure out to a numbered table that is filed
elsewhere in the manual. You could include this table as part of a task outline for
ease of referencing. See Appendix 2 for more information on Decision Tables.
Chapter 5
Task Outlines
The task outline is no more than a very detailed explanation of one persons
task taken out of a procedure. It may be only one step of an overall procedure 41
involving many people, but needs to be written in fine detail for the person carrying
it out. It is usually so involved that to include it in detail in a procedure covering a
number of people would be an unnecessary waste of reading time. The procedure
is a summary. The task outline is a series of detailed how to instructions.
The basic structure

It is similar to the procedure except for the title and possibly the elimination
of the Action by column. Some users prefer to put the name of the person per
forming the task in the heading and extend the action column across the page.
I wouldnt necessarily disagree with this since it does save paper. There isnt
the need for the operatives to be highlighted as in a procedure. However, long lines
do hinder reading to a certain extent and for this reason, plus uniformity, you may
choose to use exactly the same spacing as for a procedure.
On the other hand, office workers are very familiar with reading long lines.
Since most correspondence and other office records are produced on A4 or letter
size paper, I dont have any strong feelings one way or the other. I do accept that
communication purists may disagree with me.
In summary, these are the basic features of a task outline:
The position titles of the people who are required to carry out the task are
shown at the top. There could be a number of different positions in the
organisation that carry out the same task.
The description should start with a trigger actionsomething which

causes the person to start doing the task.
Each work sentence should start with an action verb and use plain and
appropriate language for typical users.
The whole description should show a logical cycle of work and be written
in logical time sequence.
It finishes with a definite resulteither a complete stop when the task is
complete or a transfer to another procedure or task outline.
What to include
Here are some guidelines on what to include and the sort of questions that a
person would want to have answered.
How does the person start?

The person needs to know what triggers the task to start and then what is the
first action to carry out. There are many different types of triggers, for example:
The person receives a phone call from a customer.
The days mail is received from the post office.
A document is placed in the persons in-tray.
An incident occurs that needs to be reported.
An e-mail is received.
A computer message advises that a pre-determined action for a certain
42 date is required.
Next, relate the following step directly to the trigger action. For example,
if it is receipt of a document, what is the very first thing the person has to think
about?
Does the document itself have to be processed physically in some way?
Does the person need to examine it for particular information?
What steps are necessary to complete the task?

Check to see that each step leads directly to the next step. If there is any
branching into subroutines or side channels, then make sure that they all come
back logically to the main work channel.
Have you considered all the steps that are required? This is an area where
Playscript becomes valuable. I have found that where a task is carried out by a
number of different workers, it can be useful to sit down with all the workers and
go through the procedure or task outline step by step and get their input. Its not
unusual to find that workers may not have told you about every little thing that
they do when you did your initial analysis. They often just take some things for
granted and its not till they see it in writing that some workers are able to point out
the missing steps. Another useful check is to get someone who has never done the
task to use your newly written outline to carry it out, especially if an experienced
person is there to watch them doing it. Missing steps become very evident.
Chapter 5 Task Outlines
Are there any standards that have to be followed?

If there are any standards, you should refer to them in the description or give
a reference to where the details can be read. Again, think of the person who is
using the outline for the first time. There will naturally be some occasions when a
person has to ask a supervisor or manager for advice, but as much as possible, Id
advise putting the details into the document itself.
What about multiple-choice decisions?

These can be a problem in a procedure or task outline. Where a decision has
to be made based on a wide range of possible circumstances, you may need to use
a Decision Tablea table showing the choices and possible decisions for each (see
Appendix 2 for more information). But my preference is to include the choices
within the document as often as you can.
Are there any special timing requirements?

Activities often have to be carried out at specified times or on specified days.
Any such restrictions should be highlightedpossibly as part of the title of the
document, or at least in a clear instruction at the top.
How does the person know when the task is finished?

Many procedure writers leave people hanging at various points. The person
needs to be certain that once all the documented steps have been carried out, there
is no further responsibility and the task is complete. 43
What happens to the results of the work?
If there is further work done by someone else, it may be obvious by the nature
of the task. But this is not always the case and it is often advisable for the person
to be told who carries out the next operation in case there is a query or the person
needs to follow-up some action they have taken. This can be included in the
wording of the final step.
Special cases
Showing form completion details

The task outline is the place to record details of how to fill in a form. Some
organisations make the mistake of listing all this information in a special file
under the appropriate Form Number. I have found from long experience that
this is usually unsuccessful. There is too much cross-referencing that is very time
wasting. The result is usually that the workers just dont refer to the procedures but
act on what they think is right.
Form completion details are best placed in the task outline right at the point
where they will be needed in the workflow. See Figure 5.1 on the next page.
Figure 5.1 Form details in a task outline
Sales Clerk -----------------

1. ENTER the following details on a Sales Enquiry Record
(Form No. 1023).
Registered business name
Obtain the customers full and legal business name,
ensuring that spelling is correct.
Trading name
Some businesses use a trading name rather than
their registered company name.
If the same as the registered business name, write
as above.
Customers street address
Show full street address including State and
Postcode.
Do not use a Post Office Box address.
Customers Postal address
Show full postal address including State and
Postcode.
If the same as street address, write as above.
44 Telephone Number
Include 2 digit area code or country code and area
code for an overseas number. Where appropriate,
include internal extension number.
Date of enquiry
Date on which the person originally phoned, not the
date on which the enquiry was answered.
Enter the data in DD/MM/YYYY format.
Product
Include the name of any specific company product
mentioned by the customer. If no special product
name was mentioned, leave this field blank.
----------------
Chapter 5 Task Outlines
Including a technical explanation

Sometimes it will be necessary to explain technical details in a task outline
in addition to what might be shown in policy documents. Figure 5.2 shows an
example of the inclusion of notes in a task outline on keyword filing.
Figure 5.2 Technical notes in a task outline
Records -----------------
Officer
4. CHOOSE the appropriate Keyword from the Thesaurus
together with an appropriate Subject Title.
The Subject Title comprises up to four descriptors, each
consisting of a maximum of 13 characters.
NOTE:
The working rule is that each added descriptor should
make the Subject Title more specific. The descriptors must
be chosen carefully as this is the most important step in
the Keyword filing process. Always work from the general
to the particular, unless the descriptor columns have been
given specific headings. An example of working from the
general to the particular would be:
per-0006 personnel : australia ; sydney : smith : william
45
4a. If there appears to be no appropriate Keyword on
the list, or the subject title is unclear, REFER to the
Records Manager for guidance.
5. ENTER Keyword on the Numeric Index form followed by
the next available Subject Code.
NOTE:
1. Entries in the numeric index are printed in block
letters with a pencil to enable any corrections to be
made. Do not type the form.
2. The first subject within each Keyword classification
is given the number 0001, followed by 0002 for the
second, etc.
-----------------
46
Chapter 6
Writing Style
When I joined the Communication Research Institute of Australia I learned

a very important lesson. There has been much recent research into the way 47
people communicate and one of the strongest conclusions has been the failure
of the traditional idea that all you have to do to communicate effectively is use
the right message and send it along the right channel. There is far more to good
communication than just getting your message across.
With any procedure, the writer has to rely on the reader to interpret it cor
rectly. Some would consider that a perfect procedure would require no special
interpretation, but this overlooks the complexities of human communication.
However, while we cant place our thoughts automatically into the minds of the
readers, we need to come as close to that place as possibleto have empathy with
the reader. As Clyde Jackson1 says:
We have to come out of our world into the readers world, and learn his vocabulary and
conceptual framework.
It is wrong to think of the procedure manual as one-way communication.
The reader has to respond to the instructions given and put the work into action.
To start with, the writer needs a clear picture of what the user is to do. Then comes
appropriate language and finally, since a procedure manual often has more than
one user, you will need to understand the ways in which various people might
interpret the procedure.
The goal of the procedure writer is to put down the functions so clearly that
1 Jackson, Clyde (1974) Verbal Information Systems, Association for Systems Management, Cleveland Ohio
those who read them can perform the task effectively as management expects
them to. We may never reach this perfect goal, but we should aim at it. In doing
so, remember that procedures are like any other business document in that you
will never be sure of the success of your writing style until you have tested the
document in the real world.
Start with a clear structure

Many procedures and instructions have no backbone or skeleton. The reader
doesnt really know where the procedure starts or what is supposed to come out
the other end. Leslie Matthies called this the jellyfish approach.
You overcome it by having a clear start and a clear finish with a
logical time sequence flow connecting them. This is the key to effective procedure
writing and the basis for Playscript. This method not only solves the problem of
where to start writing, but it greatly simplifies writing style and reduces the need
for specialised training.
I have covered this writing cycle in more detail in Chapter 7.
Avoid confusion
Meaning is at the heart of effective communication and many of our com
munication problems arise from misunderstandings, lack of shared meaning, and
even a mistrust of the other persons intent. Fortunately, with procedure manuals,
48 mistrust does not have the high profile that it does with other business documents
such as forms and correspondence. However, there are still many ways in which
you can block effective understanding.
I dont intend this chapter to be a full text on grammar or the use of what
has become known as plain language. My purpose here is to provide only a
basic understanding of the major factors that simplify writing style in procedure
manuals. I strongly advise you to study other specialised publications on this
subject such as those listed in the bibliography.
I also stress that Im not talking about the use of what I call kidlishwriting
for the mythical average 12 year old. Procedure language should be appropriate for
typical readers2. If technical people need technical jargon, then use it. On the other
hand, if you are writing for average office workers who have no special language or
technical skills, then you need to write at their level.
The 1982 British Government Report3 forms under control had this to
say about English language:
...about one in 20 of the adult population have a reading age of less than nine. In all, about
one quarter of Britains adults fail to reach a reading age of 13 as measured by UNESCO
literacy standards.
2 Charrow, Veda (1979) What is Plain English anyway? Document Design Center, American Institutes for
Research, Washington DC.
3 Management and Personnel Office (1984) Forms Under control, a review of Administrative Forms: Report
on Control, London.
Chapter 6 Writing Style
...In order to be understood by the majority of recipients, we consider that forms must be
aimed towards a reading age of around eleven. This means above all, simple, direct language
with an absence of multi-syllable vocabulary.
In a paper presented in Canberra in 1983, Judith Goyen4 from Macquarie
University had this to say:
...communications intended for the rural population should, if possible, be written in a style
that is comprehensible to all but the functionally illiterate. Deciding on the readability
level at which such publications should be pitched is not an easy task. If the formulae
could be accepted at face value, then it would appear that a year 7 readability level may
be too high, since the reading attainment of a significant number of adults falls below this
level. Because of the shortcomings of readability formulae, however, this figure can only
be regarded as tentative. Not until a publication has been trialled on a sample of potential
readers can an accurate decision be made about its comprehensibility. Field tests should
then be carried out before the document is published.
You might think that the studies of the average population do not apply
to your organisation, but where do your personnel come from? The majority,
especially your clerical workers, come from the very group of people that have
been the subject of these studies. So in the majority of cases you need to apply the
principle to your procedure manuals.
A number of books on manual writing suggest that you should use readabil
ity formulas to assess the level of your writing. However, substantial research has
shown that they just dont work with technical material and, in fact, are of doubtful 49
value for any type of writing. I strongly recommend that you read the two reports
listed in the footnotes.5
There have been various studies of the ability of people to comprehend what
they read and some researchers have even come up with formulas that supposedly
tell you the readability of a given piece of prose.
The first person to popularise the subject of readability appears to have been
Rudolph Flesch with his book The Art of Plain Talk in 1946. Fleschs Reading
Ease Scale and Robert Gunnings Fog Index are concerned primarily with average
length of sentences and the percentage of words having three or more syllables.
Jefferson D. Bates6, commented on these systems in his excellent book Writing
With Precision:
Nobody can learn to be a writer by using a mathematical formula. Indeed, I have seen
many would-be writers mess themselves up by trying to apply the formula while they were
4 Goyen, Judith D (1983) Plain English and Government Communications, Adult Literacy Levels in Australia,
Department of Special Minister of State, Canberra.
5 Redish, Janice C. & Selzer, Jack (1985) The Place of Readability Formulas in Technical Communication,
Technical Communication, Fourth Quarter.
5 Klare, George R. (1978) Readability and Comprehension, in Information Design (Easterby & Zwaga Ed.)
John Wiley and Sons Ltd, Chichester.
6 Bates, Jefferson D. (1981) Writing with Precision, Acropolis Books, Washington D.C.
actually writing. The result was horrendous. They would lose their flow of words, forget their
thought patterns, and end up with nothing worth saying.
A piece of writing with a bad score is almost undoubtedly unclear, unless the writer was
or is a true master of the language On the other hand, a good score on the formula does
not necessarily guarantee that writing is either good or clear. The formula cannot evaluate
the content or information of a message; also, it cannot evaluate the style.
Although Bates is talking about normal prose, his comments still apply to
written procedures.
Aim for clear meaning

Ambiguity is a common cause of confusion and can occur for a number of
reasons.
Multiple word meanings
Using a word which has more than one meaning and where the context doesnt
indicate which one applies.
This is especially a problem where the word has a narrow technical meaning
in a specialised work environment that may be different to common usage.
For example, the word sensitive has a number of narrow technical meanings
depending on where it is being used. The medical world could use it to refer to
abnormal reactions such as skin rashes developing from the use of penicillin. On
the other hand, a sensitive subject could be one that causes embarrassment.
50 Bad clause sequence
Putting phrases and clauses together in a bad sequence.
For example, legal writing often lists condition clauses (those starting with if )
before getting to the main point of the sentence. As Robert Eagleson explains7:
Lawyers prefer to have conditions first so that they can check them off as they proceed. If
they come to one which does not apply, they can stop reading. However, general readers find
it easier to have the main clause first. They prefer the pattern:
main clause + condition + condition + condition +
Putting the main clause first gives readers a context in which to interpret the conditions.
Poor placement of modifiers
Placing adjectives, adverbs and other modifiers next to words which they are not
intended to modify.
Another cause of misunderstanding in written language is the placing of
words in the wrong order. Adjectives and adverbs are the biggest culprits. They are
called modifiers because they modify or refer to an attribute of the noun or verb
to which they are attached.
An adjective always relates to a noun and more clearly defines it. For example:
A green form on a small desk.
An adverb relates to a verb and describes how the verb is to be put into effect.
7 Eagleson, Robert D (1990) Writing in Plain English, Australian Government Publishing Service, Canberra.
For example: The applicants full name is to be written clearly in block letters.
The most common problem arises when there is more than one noun or verb
in a sentence. It is important to structure the sentence in such a way that there can
be no confusion about which noun or verb the modifier refers to. The rule is to
place the modifier as close as possible to the word that it modifies.
Modifiers are not just adjectives and adverbs. You can use whole phrases to
modify meaning and similar problems occur if you dont place them correctly in
the sentence. One common problem is what Jefferson Bates calls dangling modi
fiers. For example, here is a dangling phrase:
After getting the sack, my wife was offered a part-time job as a relieving manager
by her previous employer.
It seems simple enough, but it doesnt say who got the sack, the writer or his
wife. The writer is implied, but this couldnt be known unless you were familiar
with the situation.
Here is another, somewhat absurd example that illustrates the point. After
climbing the mountain, the view was beautiful. It wasnt the view that climbed the
mountain. Note that the word view has no subject. We could better express this
as: After climbing the mountain, we saw a beautiful view.
See Appendix 1 for information on books dealing with grammar.
Unclear pronoun usage
Not making clear what part of a sentence a pronoun refers to.
This humorous example from Gowers8 illustrates the point: 51
If the baby does not thrive on raw milk, boil it.
Illogical thought sequences
Using thought sequences that are illogical to the reader.
This is one of the most common problems with written procedures. Playscript
is a great help here since its structure relies on a strict time sequence.
Lack of empathy
Not putting yourself in the shoes of the reader.
Empathy is difficult with any communication and may never be fully
attainable. It is a potential problem with procedures used in jobs where the workers
are new employees unfamiliar with the organisation and its subject matter. In this
case, the readers may be totally unfamiliar with the language commonly used by
the writer.
No matter how hard you try to eliminate ambiguity, there is usually some
one who will not understand. Communicating is too much of a risky business to
guarantee perfect comprehension, so the more you can reduce genuine causes,
the better your procedure will be. The most obvious point should be that to
communicate to the workers effectively, you should write the procedures in their
language, using their jargon and level of comprehension. They have to translate
8 Gowers, Sir Ernest (1987) The Complete Plain Words, Penguin Books, Harmondsworth, Middlesex.
the procedure into action and if they get that action wrong, then you have most
likely failed to communicate effectively.
Put the content in the right sequence

Another common cause of confusion is failure to categorise content. Jefferson
Bates9 describes how the ability to categorise is a factor that seems to make the
human mind unique. The ability to sort things out is one of the most important
tools we have in learning and remembering. Bates describes how people go to a
grocery store with a list of items to be bought that has been written up just as they
came to mind. They go into the store and wander all over the place looking for the
items on the list.
When I was working from home many years ago, it was more convenient for
me to do most of my food shopping during the working day. Since time was in
short supply, I developed the habit of listing the items to be bought by category so
that I could locate them easily in the supermarket.
Authors categorise material in a book by writing it in chapters. Libraries cat
egorise books by subject so that users can find like books together and so speed
up reference. Records Managers specialise in records classification so that an
organisations records can be easily located.
Many writers muddle peoples thinking by not keeping logical thought
patterns together. They write down the material, like the shopping list, as it comes
into their heads. But this is not necessarily the sequence in which the work will
52 be carried out, or the sequence in which a new employee will want to learn about
the subject in order to understand what to do. If you follow the Playscript method
as described in this book, the step-by-step sequence will be a great aid to logical
action.
Keep foreign matter out of the procedure

Another common cause of confusion is what Matthies labelled foreign mat
ter in the procedure. This is information that is not directly related to the job of
telling someone how to go about a task. It may be useful and it may be interesting
background, but it doesnt belong in the actual procedural sequence. Frequently
this foreign matter is inserted by well-meaning managers who are trying to
overcome past problems with the way workers carry out their tasks. But they dont
realist that it is counterproductive.
Matthies lists the following as typical foreign matter in a procedure. However
two of these could occur in a task outline and I have marked them with u.
1. Authorising signatures.
2. Details on previous publishing dates, revisions or what this procedure obsoletes.
3. Policy statements.
4. Definitions of words used in this procedure.
u 5. How to fill out a printed form.
9 Bates, Jefferson D. (1981) Writing with Precision, Acropolis Books, Washington D.C..
6. Purposes
7. Scopes
8. Departmental classifications.
9. General objectives.
10. Opinions (of the writer).
11. Philosophy.
12. A general discourse on the subject matter.
u 13. Detailed instructions for one individual.
14. Departmental responsibilities and authorities.

15. Flag waving (we are in fighting trim).
Write for the readers work environment

Many procedure manuals are written from the writers viewpoint but in very
few cases is the writer also the reader. The writer may be the readers manager or
supervisor but in most cases it is a technical writer or analyst.
Some managers write to reflect past problems with the emphasis on policy,
rules or covering up loopholes. This is all very important and may need to be
covered somewhere in the documentation, but it is wrong to make this the primary
emphasis. Intimidation is no way to get workers on side. Of course, if you are a
manager and that is your style, then theres nothing much I can do about it other
than to warn that from my 50 plus years in the business world, it is not the best
way to deal with staff.
Some analysts think primarily in terms of the system. They design the content 53
and layout to show the systems backgroundespecially if it is a computer system
and the way in which the analysts logical thought processes were developed. They
write so that another analyst who may be faced with the task of changing the
system can understand it.
But a procedure manual should be task-orientedwritten in the work mode.
When you write to show people how to do something, it involves action. So you
use the present tense: write this, get that, move the piece of paper. Simple verbs are
the most important words in writing procedures.
Use the readers language

Another common problem is using a language that is inappropriate for the
reader. Computer analysts are prime culprits, using jargon that may be impor
tant within the confines of the computer system, but which is meaningless to
the average user. The majority of people using office procedures are outside the
computer industry. Dont forget that the computer world is really only a very tiny
cog in the wheel of business activity.
Jargon is only part of the foreign language problem. A related problem is
the use of big words and long sentences often written by people who have the
so-called dictionary habit. Knowing the correct words plays an important role
in good communication, but words serve little useful purpose if the readers dont
also understand them. This has been a constant problem for me in writing this
bookwondering whether all the readers will understand the way I use certain
words. Correctness is not an end in itself. You should not write manuals like college
textbooks that require exhaustive study. People in the work environment dont
usually have time to study. Work place manuals should not require the reader to
have an open dictionary or thesaurus on the desk. Procedure manuals are no place
for gobbledegook.
Use simple, logical sentences

Many writers use such badly constructed and ambiguous language that
understanding the intent is either impossible or takes such time-consuming effort
that the procedures arent read. On the other hand, some abbreviate too much,
leaving out connecting words in sentences in the mistaken view that brevity alone
is the key to comprehension.
Sentence structure is one of the major keys to readability. Researchers have
found that short sentences with under 20 words are usually easier to understand by
poor readers provided they dont have too many long or complex words. However,
it is unrealistic to specify a maximum length for all procedures since there are a
number of other factors that govern readability.
Each sentence should contain only one item of information. This is even
more important in procedures than it is in normal prose since people have to act
on what they read. If there are two instructions in the one sentence, it is possible
that one of them will not be followed.
54 As a further aid to comprehension, put clauses in chronological
order. In Figure 6.1 example (i), the first action is to read the instructions but
this doesnt become clear until the end of the sentence. Examples (ii) to (iv) are
clearer.
Figure 6.1 Examples of clause sequencing
BAD
(i) Before filling in the form, read the instructions.
GOOD
(ii) Read the instructions before filling in the form.
(iii) Read the instructions and then fill in the form.
(iv) After reading the instructions, fill in the form.
Try to maintain a close actor/action relationship, keeping the clause

naming the person doing the activity close to the clause that tells the person what
to do. In Figure 6.2 example (i), an explanation is inserted before the action is
complete. Example(ii) would be a clearer way of giving the instruction.
Figure 6.2 Example of Actor/Action relationships
BAD
(i) The supervisor sends, 5 days before leave commences, the
application to the Personnel Section.
GOOD
(ii) The supervisor sends the application to the Personnel Section 5
days before leave commences.
Use active voice

Active voice occurs when the doer of the action appears first and the action
follows. Passive voice is when the action comes before the doer. See Figure 6.3.
Figure 6.3 Examples of active and passive voice
ACTIVE VOICE - The Applicant completes the form.

PASSIVE VOICE - The form is completed by the Applicant.
Eliminating passive voice from all writing has tended to become a fad in
recent times. But while passive voice may be useful in a book, for procedural
instructions active voice is generally easier to understand, is more positive and
direct, and carries much more force. Usual exceptions would be:
when there is a special need to place emphasis on the action 55
when the doer of the action is unknown or unimportant
if you deliberately want to keep a low profile or avoid responsibility
in descriptive narratives where there is often the need to tie the subject of
a sentence to the subject of the narrative. In this case the sentence could
be passive.
Avoid confusing punctuation

Punctuation can often confuse, but if well used, it can aid comprehension.
British studies found that many people only understood commas, full stops
(periods) and question marks easily. That doesnt mean that you should never use
colons and semi-colons, but they should be infrequent if the manual will be used
by people of average reading ability. This is rarely a problem with Playscripts short
sentences.
Use the present tense

Past tense is usually not a problem as it doesnt occur in procedure manuals
but there is a tendency for writers to use future tense.
shall and will have no place in procedure writing. Procedures, as described
in this text, are very much a now document. People read them to find out what to
do in the present. Even in policy statements you should use future tense carefully
since it has an emphatic and definite meaning.
Use direct language

Using indirect language is one of the most common errors that I have found in
business writing and is often closely tied to the passive voice described previously.
Example (i) in Figure 6.4 shows a common approach where the verb authorise
is made into a noun. Example (ii) is much clearer, uses fewer words and is more
direct.
Playscript helps to avoid this problem by always using direct language in
active voice. But you still need to be aware of it as a potential problem in policy
statements or notes that may be embedded in procedures.
Figure 6.4 Examples of verbs versus nouns
BAD
(i) Authorisation for all absences is be given by the supervisor.
GOOD
(ii) The supervisor authorises all absences.
Writing procedures as part of a team

Procedure development is rarely a single person task. The procedures are
primarily for the benefit of the workers who will carry them out. I strongly believe
that you should get the people who will put the procedures into action heavily
involved in their development. If there is the likelihood of failure, they will usually
56 be the first to know. But those peoplewhile they may be experts in their day-
to-day tasksare not necessarily experts in business efficiency, system design or
procedure writing. This is where the Procedures Analysts combine their specialist
skills with those of the operational users. In the process you may have to deal
with technical specialists or people with a higher level of skill than yours. I have
found some analysts and technical writers who find it difficult to work on a team
basis and I have also found technical specialists who have difficulty working with
procedure writers.
The following guidelines are given primarily for the benefit of those who are
inexperienced in working in a team environment. I have placed the emphasis on
dealing with technical people, but the same general principles apply to all staff
discussions. An ideal key to solving teamwork problems easily is to have an
organisation policy statement covering the development of systems and procedures.
This should state exactly who is responsible for such matters as content, format,
language and style. However, not all organisations will have this type of sound
policy, and you may need to develop unofficial means for seeking cooperation and
making the team work. The following steps are given for the people who dont
have a corporate policy.
Step 1 - Establish responsibilities

In establishing who will be in charge, there may be a number of contributing
factors in the decision such as:
personalities of the individuals

the relative position of the people in the organisation
the status of the Procedures Analysis or Systems Development Section
relative to the rest of the organisation
any organisational policy regarding responsibility for language and
procedure construction.
Irrespective of politics and policy, someone must accept responsibility for
completing the task and ideally, this would be the Procedures Analyst.
Step 2 - Exchange information

Having established responsibilities, the next step is to exchange information
with one another.
You will need from the other person:
technical information that they believe is important
details of the functions to be performed plus technical instructions.
The other person will need from you:
an understanding of what you are trying to accomplish
an outline of your approach to the manual
details of other functions or information that might be important to the
department.
You will need to agree on what each is trying to prepare.
Step 3 - Prepare draft procedures 57

The purpose of the draft is to enable the technical specialist to verify the
accuracy of the content before final production. However, you should also aim at
clarity in writing style so that the other person only has to be concerned with the
technical contentnot style or format.
Step 4 - Review of draft procedures

It will probably be necessary to have a meeting in which you go over the draft,
one section at a time. Make sure that you give the other person a copy well in
advance to allow adequate time for review and analysis. If you are working with
someone who is difficult to deal with, it may be tempting to pass over this phase
quickly. But it is important that you do not lose sight of your primary goal
preparing clear instructions for the people who will later use them.
If there are major corrections, you should prepare a further draft.
Step 5 - Prepare final procedures

By this stage there should be no major correction or need for further
involvement of the technical specialist. The only changes should be minor correc
tions to technical material, writing style, format and logic.
Slanting the language to one department

Before we leave the subject of working with various groups, I want to cover
two areas where it is very easy to make a mistake.
Where programmers or computer systems analysts are writing procedures,
they often have a tendency to slant the language towards data processing. Most
procedures are used by non-computer people and should be written accordingly.
In most organisations there needs to be a distinct separation between the computer
systems specifications and the day-to-day office procedures.
The second problem occurs where most (or all) of the analytical work has
been carried out in one department, but where the procedure is actually used by
people from a number of areas. A procedureas distinct from a task outlineis
written in such a way that it ties together the work of various people, often from
various departments and specialties. The problem is particularly noticeable when
one of the operating departments (such as an Engineering Department) is highly
technical or specialised in its activities. If slanting the procedures to help the
specialist creates problems for other readers, then you should discuss the matter
with the appropriate authorities. If you cant gain cooperation, then as a last resort,
you may have to divide the procedures into smaller segments. This is no little
different to the issue discussed above regarding computer system documentation.
58
Chapter 7
The Writing Cycle
Planning is just as important to procedure writing and systems development

as to any other organisational function. Because business systems analysis is such 59
a large subject, I have written this book on the assumption that you will be able to
find general material on analysis and project planning from other sources. In this
chapter I want to concentrate on the special needs of the procedure writer.
For most people, procedure writing will take one of these three forms:
Rewriting existing procedures into a new format.
Documenting existing (but as yet unwritten) procedures.
Writing procedures associated with the development of new systems.
I will first look at the matter of where to start on procedure writing followed
by some general principles. Then I will go over each of the above environments in
detail and look at their special needs.
Systematic procedure writing also includes various reviews as the procedure
takes shape and as much more accurate information comes to hand. At every stage
of the writing cycle, consult with representatives from the affected departments.
What makes up a procedure?

The key to defining the boundaries of a procedure is to understand the three
primary ingredients of a cycle of activity.
Each procedural cycle must start with some type of trigger action and end
with a definite result. You should leave nothing dangling at the end. All documents
should have ended up either destroyed, filed, sent outside the organisation or been
taken up by another procedure.
Figure 7.1 Clearly identify the start and end points of each work cycle
1. TRIGGER Something happens!

A piece of paper arrives on a desk.
A customer arrives at the counter.
A decision is made.
Money is received by the cashier.
An employee applies for leave.
2. ACTION A series of activities takes place as a result of the trigger.
A form is filled in and distributed to other departments
for further processing.
A document is recorded in a register and processed.
Cash is banked and detail filled in on a computer input
form.
3. RESULT The action comes to a definite stop!
All documents are filed.
An employees leave is approved.
Goods are delivered to a customer.
Follow the action!

Matthies makes an important point in discussing Playscript when he says:
60 Follow the action, not the files. This means analysing the sequence of the actual
work done to achieve the required result. Because document flow charting can
be such a great help in systems analysis in making sure that you have covered
everything, it is very easy to place the emphasis on the pieces of paper. But dont
be sidetracked. Remember that the documents are only the tools used to carry
out the work. The procedure shows what each person has to do in addition to
moving paper around.
Think in terms of work objectives.
For example:
When an employee applies for leave, the true aim is not to process the
leave application, but to approve or disapprove the leave.
When cash is received, the true aim is not to issue and process the
Receipt form, but to ensure that all the cash is banked and
allocated to the right account.
When an order is received, the true aim is not to issue a Delivery Docket
and Invoice and distribute them to all appropriate parties, but to deliver
the correct goods to the customer and receive the payment
for them.
Keep the right goals in sight and writing procedures will be much easier.
Be selective
It is usually a waste of time to write up every activity in an organisation
Chapter 7 The Writing Cycle
in the finest detail. In most organisations, there wont even be enough procedure
writing staff to write up everything. Writing takes a great deal of expensive time
and effort and it is no use doing it if it is not going to be used.
Work on overall procedures first and then, only on the most important ones.
Once these are written you can concentrate on the less important. With computer
systems it is often necessary to have some form of documentation on every
subsystem and procedure but this may not have to be in detail. A brief outline
only of the less important procedures may be all that is necessary. You should
only write task outlines where there is a special requirement for detailed how to
instructions for a single employee.
Concentrate on the main workflow first

If you are starting from scratch, then the first job will be to identify the major
operational functions. Having identified these, look for the most important work
flows in each and concentrate on these.
The main work channel is the route the biggest and most important transac
tions go through. Think in terms of percentages. If 90% of the work goes through
a particular channel, then that will be the main one. On the other hand, if there
is a 60%/40% split into two channels, there is probably the need for two separate
procedures clearly identifying the separate activities.
I have highlighted the main work channels because complex procedures
can also contain sidetracks, subroutines, exceptions and variations. These can
be misleading in the early stages of writing. You will have to take care of them 61
eventually, but the easiest way is to get the basics down first. Once you have done
this, you can concentrate on how to handle the other matters.
While you are working on the main channels, make a note of any exceptions
and sidetracks. They will generally come up in discussion and you should have a
place in your procedures filing system to store them. Using the procedures will
bring many of these exceptions and sidetracks to attention of the users. Experienced
analysts know the old sayings that once is always and last week is regularly. Some
people will tend to worry about the most recent event, even if it only happened
once in the past year. If that once was last week, they will tell you that it always
or regularly happens.
Good user relations are essential for the analyst so I always make a point of
letting the person know that I have understood their comments and that I have
made a note of them. I also make a point of getting back to those people to let
them know what has been done about their suggestions.
Writing the procedures

A mistake of some procedure writers is failing to record their ideas as soon
as they come to mind. Keep a record of every idea and file it away in the proper
sequence immediatelyor as soon as you get back to your office. Ideas notes
will also include outlines for other procedures or other manuals, as well as prob
lem areas that may need further investigation or where documentation will be
difficult. In addition to providing you with good background material for your
manual, these notes will draw your attention to areas where you may have diffi
culty communicating with people during implementation. They can help during
implementation in explaining the reasons behind the procedures.
Ideas alone are not enough! Some people get so involved in the technicalities
of the writing process that they miss out on the more important aspects. It is
important for an analyst to be methodical, but it is equally important to let the
subconscious mind engage in creativity. Many analysts have never even considered
this possibility. The human mind was designed to be able to think in the creative
subconscious mode and our best work will come when we use this faculty.
A term used to describe creative thinking is brainstorming. That is, think
ing in an undisciplined manner in terms of wide sweeping thoughts. I have used
brainstorming effectively in workshops for a number of years. Its main advantage
is for people who are normally hesitant, in that it encourages them to bring up
new ideas without the fear of being put down by people who might think the idea
is silly or irrelevant. If you brainstorm alone, it can also help to stimulate your own
creativity. First, write down every idea that comes to mind, but do not criticise
those ideas. Be positive. Keep negative thoughts out. Keep going until you
run out of ideas or out of time. I find it a help to sleep on the ideas and let the
subconscious go to work for a day or two. Then, analyse and evaluate the ideas.
62 Preparing a writing outline
I find any form of writing far easier if I prepare an outline first. This is
particularly important when writing a procedure manual that will have many
components. I try to get the outline as close as I can to what I think the end
strucure will be. It may change as I get into the meat of the subject, but at least I
know what is being changed and how those changes will impact the remainder of
the structure. Broad categories come first and these will depend on the format used
in your manuals. It is usually best to split up the categories according to business
functions. You can further subdivide them to provide the detailed outline.
This outline exists for the primary purpose of logically collecting your
thoughts and ensuring that nothing is omitted. The writing outline, although it
is structured by function or system, does not necessarily form the outline for the
completed manual. It is the outline for your thinking!
Having written the outline, go through another brainstorming session to
review it. Analyse and evaluate every item. Rethink your initial concepts and
consider whether or not you have missed anything. Go over the outline with the
relevant user groups to see whether your list of procedures and task outlines is
complete.
Preparing a rough draft

This is the major work component and involves filling in all the fine details to
the outlinewriting the step-by-step instructions as described in Chapters 3 to 5.
I find it best to work on one section at a time, making sure that all the rou
tines and subroutines are complete and adequately linked. As explained earlier,
concentrate first on the main work channel or routine of each section and then fill
in the subroutines and exceptions.
Again, there is the need for reviewfirstly by yourself and any other analysts
working with you on the project, and then by the relevant user groups. Remember
that this is a rough draft and the purpose at this stage is to agree on the content
of the instructions, not to be too concerned with grammar and language. Im not
suggesting that grammar and language is unimportant, but your main interest
should be in getting the right steps in the right sequence ready for more thorough
editing. Of course, that doesnt stop you correcting any obvious errors.
Editing the draft

The edit stage is the place where you knock the procedure into shapewhere
you take your rough notes and drafts and turn them into workable procedures that
people can use in a real-world environment.
Check words for simplicity of meaning and correct any grammar and faulty
punctuation. Words should be those that your typical users will understand.
Grammar and punctuation are designed to aid comprehension, so dont overlook
these issues. On the other hand, some people get very fussy about minor points of
grammar, spelling and punctuation, often without any real value and in some cases,
based solely on their own notions of what is correct. If you work in a government
environment there may be special standards that you will need to follow. Sometimes 63
these will be nothing more than the whim of a person with artistic flair or they
may be serious issues. Some years ago, the Australian Government changed the
standards on punctuation, omitting full stops (periods) in abbreviations such as
eg. This has been reversed in the Governments latest Style Manual. Government
procedure writers need to keep up to date with relevant standards.
Write in the work mode and, wherever possible, with verbs beginning each
instruction. You arent writing an essay or descriptive prose. Your procedures are
work documents.
As you edit your drafts, clearly define any subroutines or branching
instructions so that readers dont become lost in your logic.
This is also the time to delete unnecessary material or duplication. It can be
a great help at this time to get a colleague to read through the procedures looking
for duplication or overlap, especially if the procedures are long or complex.
Check that every procedure covers every possibilityespecially those once
a year exceptions that usually have a habit of being overlooked.
Review again
I have emphasised review to the point where some readers may think I am
making the process too laborious. Nevertheless, I have seen too many procedure
manuals written with incomplete or obscure language and consequently not used.
If manuals are not useable, then it is a waste of time writing them.
Test the procedures

This may be one of the most important steps, especially with complex
procedures and those associated with a new computer system. You will find more
about this subject in Chapter 8.
The final procedures

Your edited draft may be satisfactory, but I often find that further adjustment
is necessary, and this may not occur till after implementation or during a trial
run.
One way to tell whether your procedures are complete, especially with a
new system, is to keep a record of the number of times you have to give further
explanations. Do people ask questions about content? If they use the procedures
without asking questions, do they carry out the job the right way? You will find
more about implementation in Chapter 9.
Rewriting existing procedures in a new format

This can be a colossal task, especially in a large organisation. It is a job that
requires a great deal of planning and very careful analysis.
If the current procedures follow the narrative style of writing, they will most
likely be mixed up with policy statements, systems or function definitions and
even individual position specifications.
64 The task is primarily one of heavy editing but, depending on the completeness
and accuracy of the original procedures, it may also involve extensive procedures
analysis. You will have to decide whether to work on one function or department
at a time, or whether you write the whole manual in one go. How you approach it
will depend on such factors as:
the size of the organisation
the functional structure of the organisation
the length and complexity of the procedures
the internal political climate of the organisation
the need to be seen to achieve output from the Procedures Section.
I suggest using the following outline for a systematic approach to the task.
Read the present procedures

Read through the present procedures to gain a mental overview of the total
content. If they are currently broken down into clear, logical sections, you may
be able to deal with one section at a time. But, I still believe it is necessary for the
person in charge of the task to have a good overall concept of the whole manual.
Prepare draft outline

Prepare a rough outline of what you think will be the final format and divide
the material into subjects. This will help you to extract the policy components.
Separate matter into component parts

To save a great deal of rewriting in the early stage, I find it best to obtain a copy
of the existing manual so that I can cut it up. A set of folders, all clearly labelled,
will be a great asset. As you cut up the present procedures, the various pieces can
be put into their relevant folders and even pasted down onto plain sheets to keep
them tidy and in sequence. If your existing procedures are in electronic format,
you could cut and paste relevant parts into separate draft documents, but my
preference is still to use paper.
Examine policy statements

Examine all the policy material, one subject at a time, paying special attention
to the following questions:
Are all operations and functions included?
Is material on each function complete?
Is there any redundant or duplicate material?
Does the material conform to current policy?
Rewrite policy statements

There will need to be a heavy edit at this stage with special emphasis on
appropriate language. I suggest that policy be dealt with first as it is necessary to get
this clearly in mind before working on the detailed procedures and task outlines.
The normal process of review should ensure that there is agreement with the
relevant user groups. This may be the most difficult part of the process. Managers
65
will be used to the present format and may be the ones who wrote it in the first
place. There may be objections. It is not unusual to hear comments like: I dont
know why they want you coming in here and messing around with our procedures.
What do you know about our operations? These procedures have worked for years
and everyone knows how to follow them. Of course, everyone probably ignores the
written procedures and possibly doesnt even know that they exist, but its often
hard to convince management of that.
Since you are extracting the policy content, the procedure and task outline
components are being put aside and the managers may think that the policy
statements are incomplete. It will be necessary to educate them so that they
understand the new approach. However, dont make a big issue of it! If you can
go quietly and make changes without a great song and dance, then you will be far
more successful in the long term.
Write the procedures

Having written and understood the various functional policies of the organi
sation, you are now in a position to start on the procedures that show the flow of
work between people. These are quite different to the task outlines that cover the
fine detail of one persons work. Follow the format described in Chapters 3 and 4.
Write the task outlines

Having written the overall procedures for a function, you will be able to work
on related task outlines. You will need to write these carefully. They are not just
broad outlines, but are highly detailed step-by-step work instructions. Chapter 5
describes the approach in detail.
Review
Review the procedures and task outlines carefully, rewriting if necessary. Make
sure they are correct before implementation.
Writing procedures for a new system

The procedure-writing component of a system is just as important as any other
phase and should be planned accordingly. The place to start is at the beginning of
the project and this applies to both manual and computer-based systems.
My experience with computer systems has been that the human compo
nentsthe forms and written proceduresare often left until last, or at least a late
stage in the systems development. By that time there are two potentially major
problems.
1. The procedural ideas built into the computer system may be impractical,
cumbersome, or even totally unworkable.
2. Even if the ideas work, there is often insufficient time to develop them
66 adequately and they are rushed throughoften incompletewith all
the resultant problems of blurred meaning, omitted steps, and forgotten
subroutines.
Once the computer part of the project is complete and because computer
systems are expensive to develop, management often does not want to spend any
more. I have seen this happen many times with analysts taken off the project and
put onto a new job before documentation is complete.
procedure writing should appear in the written project plans and charts.
You should make it very clear to management from the beginning of the
project that it will not be complete until the procedure manual is published and
officially implemented.
Develop a broad outline

I like to work on a broad outline at the start so that I can put down ideas in
a logical sequence. This saves a great deal of work later in resorting the material.
It is not unusual for the structure to change as you go about your analysis but,
provided you have an index of your planned structure, reorganising should not be
a long task.
Set up an ideas file

This may be totally unstructured to start with, but will take a more logical
form as the project develops. However, if you have been able to plan your broad
outline efficiently, then you should be able to structure the file accordingly.
Schedule your writing

Plan time throughout the project to work on the manual. Dont just wait until
you get around to it. Analysts frequently get caught up in emergencies, resulting
in matters such as procedures being put off until later; and later often means
never.
Finally, write the procedures

This should follow the format described earlier in this chapter and I strongly
recommend usability testing. This is discussed in Chapter 8.
Documenting current unwritten procedures

You will often find this similar to developing procedures for a new system
and it is really a combination of the two previous approaches.
Working with the people

It will involve all the analytical principles and techniques used in working on
a new system, together with the human relations skills necessary for working with
people, many of whom may resent your interference in their work.
In one sense, the task may be easy, since your aim is just to document
the current practice. But, in another sense, it is the most difficult and perhaps
frustrating of all. Collecting the materials is a tedious and time-consuming exercise
that you cannot carry out alone. You must have the help of both management and
operatives in the relevant departments.
67
The problem is that they have to keep doing their normal work. If this work
gets behind, they will tend to take short cuts or give you only part of the story in
order to get rid of you. Let people know that you need their help. Many people
respond favourably when asked to give of their knowledge. Asking for help builds
the persons self esteema much-valued ingredient in the workplace. Of course,
this can backfire if you are dealing with a person who is antagonistic.
Have a liaison person in the department appointed to work with you. This
could be either the Department Manager or an appointee. It doesnt matter a great
deal who does it as long as the person knows the ropes.
Scheduling the interviews

This type of procedure writing takes careful planning and you will need to
pay particular attention to peak workload periods. For example, you usually wont
have much success trying to interview accounting personnel during July if the
organisations financial year ends in June.
Try to find out if there are any slack periods such as January, but dont let
people use excuses as a pretext for putting you off. If the job has to be done, you
will have to take up their time eventually, so the sooner they realise this and get
it out of the way, the better off everyone will be. You may need a great deal of
wisdom to distinguish genuine timing problems from procrastination.
Where to start
If you deal with the policy components first, you will have a sounder base for
interviewing operatives when writing the detailed procedures and task outlines.
Note that I said you should interview operatives. Experienced analysts will be
familiar with the age-old problem of the supervisors who think they know it all
when in reality they know very little about what really goes on.
Interviewing managers and supervisors only is a bad approach. If you write
up what they say is happeningwhen it isntyou will most likely miss out on
some very important points. This will particularly apply to those exceptions with
which the manager hasnt come in contact. Of course, if you arent allowed to talk
to operatives, then you will just have to do your best with what you are given.
68
Chapter 8
Usability Testing
Traditional methods of testing have included such things as applying

readability formulas, conducting opinion surveys, clerical work measurement, 69
grammatical correction, proofreading, and legal or technical clearance. But we
now know that many of these methods are often unsuccessful in showing the
major problems. Im not suggesting that they should never be usedsome do have
their place in business systems analysisbut they dont provide the fine detail that
comes from methods such as usability testing through observational studies. Even
then, document quality control checks are a mixture of many different factors and
no single procedure supplies all the answers.1
Some common approaches to testing

Before looking at what we can do about improving document quality Id like
to take brief look at some of the more common approaches.
Treating people as machines

Industrial Engineering and Organisation and Methods approaches usually
treat people as if they are machines, neglecting such matters as the human mind,
creativity, the ability to reason and a great range of social complexities.2
1 Wright P (1979) The quality control of documents. Information Design Journal, Vol 1, 33-42.
2 Shulman A, Penman R and Sless D (1989) Putting information technology in its place: organisational
communication and the human infrastructure. In J Carroll (ed.) Applied social psychology and
organisational settings. Hillsdale, New Jersey: Laurence Erlbaum.
For example, the following, taken from a book on systems analysis, places the
emphasis on machine performance as a test of system efficiency, but provides no
useful information about whether or not the data being produced is reliable.
today, the Accounting Department has to manually prepare a list of all overdue
accountsbecause the current system does not automatically produce a report with that
information. The current system has obvious shortcomings. The new systems performance
could be evaluated by comparing how soon this information is available or how much time
was saved by automatically identifying all these overdue accounts.
Both of these comparisons (how quickly the information is available and the amount of time
saved) are objective and measurable, can easily be determined, and would satisfactorily
serve as an objective method of evaluating the new systems performance.[emphasis mine]
Now this might help us to evaluate the speed of the computer, but it will tell
us nothing about how effective the system is in providing accurate information,
whether the reports are understandable or whether the data they report is
useable. The book is typical of the approach taken by many information systems
professionals. While taking almost 600 pages to tell analysts how to develop
business systems, it does not even cover the problems of human communication. In
the implementation phase, it concentrates on testing and evaluating the programs
with not even a mention of human needs. Even when it talks about finding bad
data in the system it takes a simplistic view of how to deal with itif people
make mistakes, retrain them!
70 If the analysis reveals that the user has been inputting bad data, then retraining the user
and perhaps a revision of the user reference manuals will be required. This is one of the
simplest types of changes to make. Similarly, if operational instructions are incorrect, it is
very easy to change them. [emphasis mine]
Instructions may be easy to changebut to what? Communication is not just
putting words on paper in the right sequence. The developers of computer systems
frequently transfer this type of thinking to the development of manual systems. Its
bad enough that it frequently fails with computer systems, but it creates a shambles
when applied to the highly variable nature of human communication.
Human communication is generally neglected with an almost total
concentration on physical matters such as effort, paper flow, aesthetics, equipment
efficiency, movement and other aspects of ergonomics. While not wrong in
themselves, they do not determine whether the procedure actually works.
Milwards classic book Organisation and Methods a service to management3
typifies the British experience of the post World War II period, dealing almost
entirely with people, equipment, work place and timing. The introduction sets the
tone:
There are variations from company to company in the remit (or scope and authority)
of those entrusted with O & M work, because of different conceptions of the responsibilities
3 Milward G (1967) Organisation and Methods: A Service to Management: London: The Macmillan Press
Ltd.
Chapter 8 Usability Testing
which the work should carry. Broadly, these conceptions may involve the simplification of
organisation structure, of management structure and records, of the work of the office, or
(in a few companies) the simplification of any administrative work.
simplification of administration demands an essentially constructive ability and this
particular ability in methods work demands a wide knowledge of alternative means,
machines, and procedures, and in organisation studies of alternative forms of groupings and
arrangements of work, or of staff.
Perhaps the most telling statements come from the chapter on The Assignment.
For example, we find the following under the heading Fact-Finding:
What is done? What is the broad process and its purpose?
Why is the work done? Is any part not essential?
Who does the work?
Where is the work done? Should it be done centrally or locally?
When is the work done? A time cycle of the procedure is needed.
How often? Get the work load in detail.
How is the work done? This includes method, movement equipment and supervision.
How much does it cost?
The aim will be to discover as much as necessary about:
organisation structure relationships with other departments duties assigned skill
required purpose of each procedure user or consumer attitudes work load time
taken programming of work statutory requirements
Later in the chapter: 71
It is useful to look out for bad procedures, including:
Excessive number of stages making the procedure return too often to the same point
insistence on a single procedure too many movements of people too many records
required for reference or noting Too many documents travelling along the line of the
procedure. Duplicate records. Unused material seeking at excessive cost to eliminate
the smallest error.
George Terry4 takes a similar approach.
Suggested Questions for Improving Office Procedures.
1. Purpose of operation:
2. Design:
3. Process analysis:
4. Inspection:
5. Material handling:
Suggested Questions for Improving Office Methods.
1. Questions regarding setup or workplace layout:
2. Questions regarding tools and equipment:
3. Questions regarding working conditions:
In 1977 the U.S. Commission on Federal Paperwork produced its final report
highlighting the multi-billion dollar wall of paperworkerected between the Government
4 Terry G (1970) Office Management and Control. Homewood, Illinois: Irwin

and the people. While it did talk about psychological burdens, the bulk of the
report dealt with the number of pieces of paper and the cost of paperwork in
time and records management. The repercussions of this emphasis have been far
reaching. For example, instead of concentrating on whether people can fill out
a form accurately, form designers concentrate on reducing the amount of paper.
Paperwork reduction has been the name of the game, but there is little, if any,
emphasis on the real human burden of hard-to-use documents.
Using readability scores

Procedure writers sometimes use readability scores to predict whether or not
the procedures will be understood. The best known is Rudolph Fleschs Reading
Ease yardstick5 that Microsoft has now included in the grammar checker of its
WORD word processing program. Others are Robert Gunnings Fog Index, Frys
Readability Graph, the Dale-Chall Formula, FORECAST formula, the Lensea Write
Formula and the Clear River Test.
Since the Flesch system is the most common it is worth a brief explanation.
To apply the yardstick, you need to count the number of words in the passage, and
the number of syllables and sentences. You then apply the following formula:
RE = 206.835 0.846s 1.015w
where: RE = Reading Ease
s = syllables per 100 words
w = words per sentence
72 The results are compared with the table in Figure 8.1
Figure 8.1 Flesh Reading Ease yardstick
RE value Description of style Typical magazine Potential audience:

School grade completed
0-30 Very difficult Scientific College
30-50 Difficult Academic High school or some college
50-60 Fairly difficult Quality Some high school
60-70 Standard Digests 7th - 8th grade
70-80 Fairly easy Slick fiction 6th grade
80-90 Easy Pulp fiction 5th grade
90-100 Very easy Comics 4th grade
As has been explained by various researchers, applying these to technical

documents is generally a waste of time. While they may provide a means of
filtering out bad text in some circumstances, the formulas dont work with business
documents such as procedures.6
5 Flesch R F (1949) The Art of Readable Writing. New York: Harper and Row
6 Wright P (1979) The quality control of documents. Information Design Journal, Vol 1, 33-42.
Even using them for the purposes for which they were designed is of doubtful
value.7
They were originally developed in the 1920s and 1930s so that publishers of
childrens books could assign them to the most appropriate grade levels. The major
problem with such formulas is that they rely solely on measurable components.
They do not take into consideration context, word comprehension or factors
beyond the sentence level.
Redish and Selzer8 list five important facts about readability formulas:
Fact 1: It is not clear what a readability score means in technical writing for adults.
Fact 2: Studies have shown that readability formulas are not reliable and valid predictors of
how difficult documents are.
Fact 3: Shorter sentences are not necessary clearer sentences: shorter words are not always
easier words.
Fact 4: People are not text-processing machines.
Fact 5: Readability formulas do not measure the most important factors of a document.
To further explain the problem they refer to comments by Duffy.9
the criteria for assigning a reading grade level to a text are arbitrary and are set well
below the level at which they should be to predict that an adult can read and understand
a particular document. In the Kincaid10 revision of the Flesch formula, a tenth-grade level
means that at least 50% of the readers who scored tenth grade or higher on the standardized
reading test can expect to get 35% of the words correct in a cloze test. (In a cloze test, you
leave every fifth word blank and subjects fill in the blanks.) A 35% cloze score equates to 73
getting only 50% of the answers correct on a multiple choice test. If we really want people
to read and understand job instructions, we would expect them to get 90% correct on a
multiple choice test.
Lets look at that again: 50% of readers getting 50% of the answers correctthats a
25% hit ratenot very reliable if were considering quality.
If you are interested in more detail, I strongly advise you to study the papers
listed in the footnotes on this and the previous pages11.
7 Redish J, Selzer J (1985) The Place of Readability Formulas in Technical Communication. Technical
Communication, Fourth Quarter.
Holland V (1981). Psycholinguistic Alternatives to Readability Formulas. Washington D.C.: American
Institutes for Research.
Klare George R (1978). Readability and Comprehension. in Information Design, edited by Easterby R and
Zwaga H, Chichester: John Wiley and Sons Ltd.
8 Redish J, Selzer J (1985) The Place of Readability Formulas in Technical Communication. Technical
Communication, Fourth Quarter.
9 Duffy TM (1985) Readability Formulas: Whats the use? in Designing Usable Texts, ed. Duffy TM & Waller
RM. New York: Academic Press. p. 123
10 Kincaid JP, Fishburne RP, Rogers RL, Chissom BS (1975) Derivation of New Readability Formulas
(Automated Readability Index, Fog Count, and Flesch Reading Ease Formula) for Navy Enlisted Personnel.
Memphis TN: Naval Air Station.
11 Klare GR (1981) Readability Indices: Do they inform or misinform? in Information Design Journal 3/4. pp
251-255
Charting paper flow

Some analysts think that they can improve documents solely by analysing a
chart of the paper flow. Sometimes the claims made for the benefits of these charts
to predict results can only belong in fairyland. The following appeared in a book
on paperwork productivity.
Paperwork elimination occurs mainly from the top down, seldom from the bottom up, and
only when management has a chart or picture of the procedure that it can read, understand,
and derive answers.
Only by these means can answers be given to such questions as, Is this paperwork operation
necessary? What will happen if we eliminate it? Can two or more operations be combined?
Can we take a calculated risk in eliminating paperwork controls? Are the operations being
done in the correct place by the right people? Are authorities and responsibilities correctly
placed?
All these and other questions vital to good management are revealed by the road map type
flow chart in a way that management can understand so that it can take action.
This provides for the all-important qualitative evaluation of paperwork
By tracing the flow of each piece of paper through the chart you should be able to
determine whether or not all the information necessary to the paperwork operation is
included in the form design. [emphasis mine]
74 Now there is a place for flow charts in system developmentespecially in
analysing workflowbut the claim that these are the only way you can determine
if paperwork operations are necessary, or in which you can help management to
understand all the issues, reveals a lack of understanding of human communication.
To compound the problem, any person who is able to determine whether or not
all the information necessary is on the form just by looking at a flow chart would
have the insight of a Divine Being.
The faith that many people have in flow charts is further evidence of the
problems they have in understanding communication. Some analysts think that
because they understand what a symbol or chart means, then everyone else who
uses the system will automatically understand it. Both research and experience
show otherwise.
Flow charts can be a great tool for assisting the individual analyst to see the
logic of a complex set of instructions or for seeing the flow of paper throughout
the organisation. Ever since I was introduced to systems work in the 1960s, I have
been an avid fan of flow charts as an analytical tool but they should never be used
as a replacement for properly written user procedures.
An excellent example of the benefits of effective charting and the relationship
with Playscript can be found in various publications of The Ben Graham Corporation.
More information is available from their web site at www.worksimp.com.
Focus groups
In recent times, many people wanting to test documents have used focus
groups, often as the preferred method. They have become popular among market
researchers due to their relatively low cost and quick results. But their application
to business systems work has proved to be not only of doubtful value, but often
totally counter-productive. They consist essentially of a group of people focussing
their attention on the question at hand under the guidance of an expert facilitator.
However, the use of the term focus testing is a misnomer since this method
doesnt test anythingit gathers opinions and comments.
Joseph Dumas and Janice Redish12 have this to say about focus groups:
Focus groups provide information about users opinions, attitudes, preferences, and their
self-report about their performance, but focus groups do not usually let you see how users
actually behave with the product.
The end of this statement is critical for procedures, since what users do with
the product is of greatest importance.
Even more relevant is the discussion by JoAnn Hackos and Janice Redish13.
For the type of analysis you need to design successful products, focus groups have several
limitations. They dont show behavior. They arent held in the users environment. They often
include gatekeepers, not users. They may be dominated by a few individuals.
Therefore they are usually not a good way to understand how people work or how
they behave on the job. What people report about their work in a focus group and what
happens on the job may differ, perhaps significantly. Much of the work that people do is so
75
automatic that they forget to mention it when just talking about it. But the steps that dont
get mentioned in a focus group may be critical to include in a new design or to document in
a manual for new users.
Focus groups often bypass users. In many cases, we find that market researchers are talking
to gatekeepersthe supervisors, managers and other decision makers
Another limitation of focus groups is that some individuals will be more outspoken than
others and are likely to influence the direction and conclusions of the group.
I strongly recommend both of the publications from which the preceding
quotes were taken.
Observational usability studies

Robert Waller14 pointed out that some long-held traditions dont hold true
when we compare them with actual results, so to produce quality documents
that really work we need a different approach. We need to find a way of testing
12 Dumas J and Redish J (1999) A Practical Guide to Usability Testing. Exeter, England: Intellect,
ISBN 1 84150 020 8
13 Hackos J and Redsish J (1998) User and Task Analysis for Interface Design. New York: John Wiley & Sons,
ISBN 0 471 17831 4
14 Waller R (1984); Designing a government form: a case study; Information Design Journal 4/1, 36-57.
procedures that lets us see them in action; one that lets us find out in advance if
the procedure is going to work. Observational studies are a method whereby you
can find out why people are going wrongwhere you can highlight specific user
problems and fine tune the language to get rid of them.
One of the most valuable aspects of observational studies is that you can
actually see the document improving through the testing stages.
Dr Walter Shewhart of Bell Telephone Laboratories was looking into these
same issues as far back as the 1920s. He proposed the idea that the way to improve
quality in the workplace was to use an iterative style of usability testing: plan a
change that you believe will be an improvement, test it on a small sample, observe
the results, and finally, study the results and decide what youve learned from the
change. Then, in an iterative manner, repeat the cycle a number of times, each
time incorporating the improvements.
The methods we use today are similar, though more refined, and are proving
extremely valuable in reducing errors, often to insignificant levels. Using structured
observational studies you can watch people carrying out the task described in
the procedure and, with appropriate questions, you can learn why they make
mistakes.
They also provide a great amount of fine detail and yet they are relatively
inexpensive. While each round of testing uses only a few peopleperhaps 6 to
10over the course of the study these can add up to a large group.
One aim of an observational study is to collect information about the
76 behaviour of people when using a procedure or other document. For our purposes,
behaviour includes the following:
The way in which the person carries out the task.
Physical things the person does, including the way they move through the
procedure itself.
Facial expression and other mannerisms that might indicate problems,
frustration, lack of understanding, confusion, etc.
What the person says.
Finding out as much as possible about how the person understands the
procedure. What is the cause of any misunderstanding? Do they carry out
instructions or do what is expected with the information given?
The overall approach

In an observational study, you observe the procedure in action in an
environment as close as possible to the real world. However, you cannot fully
simulate the real world. For example, in the real world you wouldnt be there.
Some observers endeavour to simulate the real world by observing secretly with
cameras or one-way glass, but this raises ethical issues of invasion of privacy.
The size of the study

Observational studies are conducted in short rounds, usually six to ten people
in each, depending on the nature of the document, the availability of respondents,
time frame and what you already know about the procedure.
The first round is often small and used to establish the pattern and questioning
approach for the remainder of the study. It will most likely reveal problems with
the document but may not show the reasons, so you will need to make changes and
run the test again. It is common for the second round to reveal different problems,
possibly introduced by any changes you make. This necessitates at least a third
round of testing.
The extent to which you continue testing will be determined by the nature of
any problems found, the time and cost constraints under which you are working
and the seriousness of the problems encountered.
Problems you may encounter

Observing influences behaviour
The people being tested know they are being observed and this will usually
affect their behaviour to some extent. But your approach and manner can counter
many of the negative effects. When people are being watched, one or more of the
following may happen.
Those who have an axe to grind against management may take the
opportunity to use the study to express their opinions or force issues with
a secret agenda.
Some will have an axe to grind on behalf of management.
They may see you as an ally in resolving some grievance.
They may see the tester as an enemya representative of management.
77
They may even sabotage the results.
Giving opinions
Some people want to give opinions rather than get on with the task of reading
the procedure or following its steps. While opinions may be of some valueand
you certainly should make note of themthey are not the primary task of an
observational study. I have found this a particular problem when staff are being
tested and this is particularly relevant to testing procedures. They often like to
think they have a say in the development of the document.
Insecurity
Many people blame their own incompetence, which can lead to insecurity and
a great deal of tension. While this might help if you were trying to test a procedure
being carried out under pressure, it is generally far from reality. Overcome this by
stressing at the outset that you are testing the procedure, not the person.
Leading the respondent
Some testers try to inject their own ideas into the study. It doesnt matter what
you believe is right or should be done, you are there to test the procedure and to
observe the actual behaviour of the usernot the way you would like them to
behave.
Do not ask leading questions such as: Thats a confusing statement, isnt it? It
would be better to say: What did that instruction mean to you? and let the person
volunteer the information that they do or do not find it confusing. They may not
understand it, but they may not know that they dont know and therefore dont feel
confused.
Multiple choice routines
Procedures with steps involving choice mean that you may not be able to test
every possibility with every person. You may need to set up different scenarios to
properly test each choice and this could mean a larger number of users. At the end
of the study you may be able to ask the person how they would have carried out
the procedure if their choice had been different. But this may not be as reliable
since the instruction is out of context and isnt approached in the normal course
of work.
Talkative respondents
You will encounter some people who want to spend more time talking about
side issues than doing the job at hand. Dont get sidetrackedbut dont be rude.
Gently draw the person back to the main task.
If the person fails to cooperate you might have to terminate the test. But this
should very rarely be necessary.
How to conduct the usability study

The notes that follow are only a brief introduction to the subject. I strongly
recommend that you read more detailed material on the subject such as the
78 following two publications (see Appendix 2 for more details):
A Practical Guide to Usability Testing: Joseph S. Dumas and Janice C. Redish
User and Task Analysis for Interface Design: JoAnn T. Hackos and Janice C.
Redish.
Preparation
1 Plan the study
Decide what types of people you want to observe and how many people you
need for each round. Set up a realistic timetable. Some users may take far
longer than would normally be expected.
Make definite appointments and stress the importance of being on time.
This may be a problem if the respondents (or their managers) do not see the
value of what you are doing and the testing is regarded as an intrusion into
their busy schedules.
Prepare your documents and write down the questions that you want to
ask. Give yourself a script so that you say essentially the same thing to each
respondent. This way, comparison of respondents is more reliable.
At the start
2 Put the person at ease
Be friendly and smile! You may feel nervous at first, but try not to let it show.
Remember, the other person is probably far more nervous than you are and
usually doesnt know what to expect. Many respondents approach testing as if

they were undergoing an examination.
3 Say who you are and explain what you are doing
Give whatever background is necessary.
4 Tell the person that you cannot help them
People being tested often want the observers to help them. But this isnt what
would happen in real life, so you need to explain this to people before they
start. Tell them that they need to follow the procedure as if no one else was
present.
The actual study

5 Observe the procedure in action
Look for MISREAD INSTRUCTIONS
Note any resultant behaviour.
Listen for QUESTIONS ABOUT CONTENT
For example: Im wondering what this means.
Make a note if the person makes the comment and goes on, and come
back to the matter later.
If the person asks you what something means, ask them what they think.
If the person says they have no idea about what something means and
asks what they should do, tell them to do what they would do if they were
using the procedure in real life. 79
Look for MISSED INSTRUCTIONS
Make a note and ask them about it later.
Look for BACKTRACKING
Make a note and ask them about it later. This may mean the person has
doubts about the meaning of a previous instruction or that the present
instruction is misunderstood.
Look for MOVING AROUND WITHOUT ANSWERING
Make a note (especially about where they are looking) and ask them about
it later unless the person comes to a stop.
This usually indicates failure to understand the instruction.
Look for SCANNING LOCAL AREA
This usually indicates that the person is uncertain and is looking for local
clues to meaning.
Look for HESITATION or TOTAL SILENCE AND BEWILDERMENT
Dont prompt too soon, but if the person is just sitting there bewildered for
a minute or so and saying nothing, PROMPT them. You could say: You
seem to be having some difficulty and see what sort of response you get.
Look for ANY BEHAVIOUR OTHER THAN STRAIGHT-THROUGH
READING AND ACTION
When the person has finished

6 Talk to the respondent about the procedure
This is the time to examine those areas of the procedure that the person
appeared to have trouble with during the observation. First, ask the person if
they encountered problems with any instructions. Next, ask about any specific
problems you observed that have not yet been dealt with. You could then ask
specific questions about the meaning of particular words and instructions. This
will be something you will have determined before you began the tests. It will
cover problem words and potential ambiguities. You might also ask them how
they found procedure to follow if they havent already told you.
Finally, thank the person for helping.
80
Chapter 9
Implementing Playscript
In this chapter I only want to deal with the procedural parts of systems im
plementation. If you want to know more about other facets, there are many books 81
on the subject. Procedures present their own particular problems when it comes
to implementation.
One of these problems is the relationship between the procedure writer and
the users. I have used the term users in this book to refer to the workers that
put the procedures into action. I realise that some systems people dont like the
term because of its tendency to create a barrier between the analysts and those
users. However, the word is in common use; the analysts have developed the
procedures; and it is the users who will use the procedures for their day-to-day
work. In using the term I do not imply that the systems and procedures people
should be mini-gods who control the rest of the organisationthere is no place
for ego trips in systems workand it is important to remember the service
approach throughout implementation.
Teaching users about Playscript

If your users are already familiar with the Playscript system, then the task of
instructing them in procedural changes will be relatively easy. If they are unfa
miliar with Playscript, then it will be necessary to explain both the concepts behind
it and the structure of the manuals. I have found from experience that a good way
to teach people something new is to talk to them about what is wrong with the
present system and then show them how the new system solves their problems.
Comments about the present system will have to highlight the problems
that they already know about, bearing in mind that people dont like change. No
matter how bad the present system is, if they have lived with it then its quite likely
that theyll be comfortable with it.
Change is uncomfortable and people dont like feeling uncomfortable.
To introduce Playscript, you must present it in a way that helps them. It
is only in this way that you will gain their cooperation. The section at the end
of Chapter 2 on advantages and uses of Playscript would be a good basis for this
initial presentation. Having given them the reasons for its introduction, you will
need to explain how it works and how the manuals are structured. Be basic! Keep
the introductory session simple and give people plenty of time to get used to the
new system.
Leslie Matthies comments that the people who are unfamiliar with Playscript
think that it looks strange the first time they see it. Yet after reading a few
procedures they grow to like its clarity and logical time sequence. I can certainly
back up his comments from my own experience. Users find that its straight-
through sequence and simple step-by-step approach makes learning much easier.
Removing the policy component and writing it separately also helps to clar
ify understanding and reduce arguments about trifling matters of grammar and
punctuation. I dont mean that poor grammar and punctuation are unimpor
tant, but its my experience that when some people cant find anything else wrong,
theyll look for even the most obscure, picky point just for the purpose of finding
82 something to criticise. When we write in appropriate English and in the simple
numbered step sequence, users can easily spot omissions and errors. This helps
them to help us get more useable procedures.
Teaching users about a new procedure or a change

Some managers hand out a procedural change (especially when its a major
change) or just send it to the users with a covering memo and expect it to be
implemented immediately. People need time to absorb changes and think about
the consequences. They also need time to think about possible omissions or
oversights that you have made. You might think you have a perfect procedure or
system, but all systems people are fallible and we all make mistakes from time to
time. Any procedures or systems analyst who does not keep an open mind for new
and better ideas is just not a good analyst.
The initial discussion meeting

Another aspect of the subject that I have very strong views on is the matter of
who should supervise the training of staff. It can be a sound move for the analyst
who developed or wrote the procedures to make the initial presentation. But I
believe that the actual supervision of the implementation should be in the hands
of the supervisor or manager of the particular section carrying out the procedure.
This person needs to be completely familiar with the process so that they can
Chapter 9 Implementing Playscript
carry out proper routine supervision. An ideal way to learn the process is to su
pervise its introduction. I have seen many cases of systems people supervising the
introduction and then handing it over to a manager who knows little, if anything,
about it. This has a detrimental effect on the managers relations with the staff who
realise (or assume) that the manager doesnt understand.
The approach Im suggesting usually makes implementation more tedious
and opens up the possibility of errors, but if the analyst supervises the manager
then these problems will be minimised.
Gaining acceptance
The biggest hurdle to overcome in many organisations is the mistrust that
exists between the systems department and the users of the system. This has
often been brought about by the superior attitude of systems analysts who need
to realise that they exist for the purpose of serving the rest of the organisation,
not vice versa. An attitude of giving service brings many benefits to the Systems
Department. People realise that it is there to help them, rather than fearing that it
will be taking over their operations.
You will have carried out much of the task of gaining acceptance for the new
manual in the investigation phase. If you have done this properly with effective
participation by the users then the actual implementation should be relatively
straightforward. Having started on the right foot, here are some practical steps to
continuing through to the end.
83
Answer questions
Make sure that either your procedures answer all the questions that were
raised during investigation, or that you have answers ready for people when they
ask. In many cases you will have considered questions and possible objections to
your ideas and found them unworkable, but have a logical explanation ready. I
try to bring these matters up long before the users get the chance to do so, thereby
getting the upper hand and showing that I have considered their wishes. But dont
just fob people off. Your reason should be genuine and plausible.
Consider indirectly affected users

These can be vital to the success of a new procedure. They are the people who
may not actually be mentioned in one of the steps but are indirectly affected by
the procedures. This could include such sections as Auditing, Legal, Production
Control, Finance and even the labor unions.
Have users check drafts

I always get some users to check a draft of the manual before I issue it. Dont
just make this a show. If they have genuine complaints, fix them! They are the
ones who will have to use it, so if it isnt right, whats the use of issuing it? The best
people, as always, are the ones who will actually use the procedures in their day-
to-day work rather than the supervisors or managers.
Go back to the users

Dont just hand the manual to the users and let them go their own way. User
managers might be responsible for supervising the implementation, but that
doesnt mean that you can shirk your responsibility.
The implementation must be successful if you are to continue to have a good
working relationship with the user on future procedure development. To do this,
you generally need to go back to the users and find out how they are going. What
problems, if any, are they having? Could you clarify any of the procedure wordings?
Have you omitted any steps? Does the procedure have the wrong people doing the
work?
Dont forget sign-off

Sign-off is where the user department management states their acceptance
of the procedures, but make sure you get the right person to do the signing-off. If
you get sign-off from one manager involved in a system and then find that another
manager wants a change to the same procedure, you will need to take the amended
procedure back to the one who signed it off to get agreement on the change.
One final point about sign-off, dont forget to put a time limit on users. Tell
them exactly when you want the procedures back. Give them a specific date, and
if they dont get it back by that date, follow them up without delay. However, be
realistic in setting your dates. Managers are busy people and reading and checking
procedure manuals can be very time consuming.
84
Encouraging revision
Any dynamic organisation will be constantly changing due to new business
trends, changes in government legislation, new marketing strategies, increases
and decreases in the staff establishment, and so on. A procedure manual is useless
unless it is kept up to date, so it is essential to encourage users to let you know if
there is any change needed. I have often asked people attending my classes and
lectures if they have procedure manuals and, if so, whether or not they are kept
up to date. Frequently, they dont have manuals at all, but in the cases where they
do, there is an almost universal response of NO! They are not kept up to date. If
theyre not kept up to date, then whats the use of writing them in the first place?
Manual production
The most important considerations in the selection of paper and ink are
contrast and readability. Research has shown that the best contrast is obtained
by black ink on pastel (canary) yellow paper. However, you do have to watch
carefully the use of yellow paper. I had a bad experience with one manual where
the printing department inadvertently printed a commonly used section on a very
bright yellow. The result was found to be psychologically disturbing to the users.
Bright yellow has also been found to cause nausea if looked at for long periods.
Considering that copies will normally be made on a photocopier, it will probably
be best to use white paper. As for ink colour, I see no point in using anything but
black. Unlike a form, nothing else has to be added, so there is no need to use any
other colour.
Paper opacity is also important for legibility and for minimising show-
through when the pages are printed on both sides. To avoid any problems I suggest
using 70 gram (US #18) paper at the very least, and preferably 80 to 110 gram
(US #20 to #30). But weight alone is not enough. Paper opacity varies greatly, so I
suggest you make your selection carefully.
If you are producing the pages on a photocopier or laser printer, then you will
probably use the standard paper for your organisation.
You should also see that the original is clear. No matter what reproduction
method you use, you can rarely improve on the quality of the original. The best
results come from either a laser or ink jet printer or, if using a typewriter, a carbon
ribbon and clean keys.
Packaging your manuals

As this book is primarily about Playscript, and not about manuals in general,
Ive left those details to other writers. Most books on procedure writing have
comprehensive sections on construction, and I particularly like the approach of
dAgenais & Carruthers. However, the following points should be noted.
The manual should be in loose leaf form so that it can be updated. Use a
system that resists tearing out of pages. In other words, dont use two-
ring binders. I suggest three or four-ring, or, if you have the punching 85
equipment available, a multi-ring system. But remember that when pages
are updated, you have to be able to remove the old pages, so systems such
as plastic comb binding can be a hidrance to easy upating.
It should be indexed in such a way that the users can easily find relevant
information.
The outside of the manual should clearly state the contents.
every manual should be numbered for control purposes.
The first run

You could have some problems with the first run, so be prepared to make
corrections and reissue pages as necessary. There may even be some adverse
reaction just because its new. The important thing is to react quickly and take
positive action to correct any mistakes. Thorough proofreading of the first run is
most important and it can also be one of the more difficult tasks. I know, from my
experience writing books, how difficult it is to get the errors out. No matter how
careful I am, it seems that there are always errors that get overlooked. The problem
is that if there are too many errors, you can lose credibility with the users, and
youll be starting from behind.
Making changes
If you wish to make changes to a procedure, the users will need to understand
exactly what those changes are and how they will affect the users. Playscript helps,
as it is so easy to follow. In addition to putting the revision date on the procedure,
you should help the reader to find the particular change.
Figures 9.1 and 9.2 show two ways of doing this.
Figure 9.1 Using an asterisk to indicate a change
Claims -----------------
Controller
23. ADVISE the Insurer of the claim.
* 24. ESTABLISH the Insurers requirements for lodging the
claim.
* 25. ARRANGE for an assessor to visit the client.
-----------------
Figure 9.2 Using a vertical line to indicate a change
86 Claims -----------------
Controller
23. ADVISE the Insurer of the claim.
24. ESTABLISH the Insurers requirements for lodging the

claim.
-----------------
In addition to one of the above, you can also point to the change by means of
a note at the bottom of the first page.
You should also indicate clearly any additional steps as distinct from
changed details. If there are substantial amendments then you should also clearly
indicate them.
I also find that it can be a help to list all the paragraph numbers that have
been changed in a covering memo.
Keeping control of changes

Out of date manuals are useless, so that means making sure that amendments
are inserted. I know some organisations where someone goes around and inserts
the new pages for the users to make sure that the manuals are correct at all times.
The problem with this method is that users often do not know that the change has
been made.
Leslie Matthies suggests the use of an information copy on coloured

paper. The user is asked to insert the white copy in the manual and to use the
coloured, unpunched copy for reading and then discarding it. He points out that
it is not a cure all, but people dont always have the time to read the new material
as soon as it arrives. It is advisable to put a note on the bottom of such copies that
they should be destroyed after reading or circulating.
Of course, with todays emphasis on reducing the use of paper, many organ
isations may not accept this idea. Im not making a strong point one way or the
other. Ive never been a great fan of wasting paper, but I believe that practical
considerations should come first.
When I was working in a large systems department and controlled many
manuals, we found it advisable to send a check list around every so often, listing all
the contents that should be in each manual. The holder of the manual was asked to
check off the list to make sure that the manual was up to date and to send back the
checked list. This worked well and we made sure that we followed up any lists not
returned. We also found that people valued the service and very few people took
exception to the extra work. In fact, most users responded very quickly, either to
show us how successfully they had kept the manual up to date or to show us that
we had not sent them an update. We never bothered to argue about whose fault it
was. The most important point was that the manuals were correct.
One final matter

An effective procedures section will keep a procedures file. This is an impor
87
tant part of the control system and is similar to a forms file.
Each procedure should have its own numbered file. This will contain not only
the latest version, but also all memos and comments relating to the procedure plus
any other background material. The best storage medium is a plain tabbed-folder
with coloured numeric end-tabs stored on steel shelving with metal dividers. I
see no point in expensive suspension files or space wasting four drawer filing
cabinets.
This file will be the main control mechanism and should be retained
permanently.
88
Appendix 1
Suggested Reading
A Practical Guide to Usability Testing

Joseph P. Dumas and Janice C. Redish
Intellect, Exeter, England, 1999
89
Achieving 100% Compliance of Policies and Procedures
Stephen Butler Page
Process Improvement Publishing, Ohio, 2000
Best Practices in Policies and Procedures
Stephen Butler Page
Business Policies & Procedures Handbook
Stephen Butler Page
Prentice-Hall, Englewood Cliffs, New Jersey, 1984
Comprehensible insurance documents: Plain English isnt good enough
Robyn Penman
Communication Research Institute of Australia, Canberra, 1990
Control through Communication
JoAnne Yates
The Johns Hopkins University Press, Baltimore, 1989
Creating Effective Manuals
Jean dAgenais & John Carruthers
South-Western Publishing Co., Cincinnati Ohio, 1985
Documents To Manage By
Leslie H. Matthies
Office Publications Inc., Stamford CT, 1982
Establishing a System of Policies and Procedures
Stephen Butler Page
Forms For People: designing forms that people can use

Robert Barnett
Robert Barnett and Associates Pty Ltd, Canberra, 2005
Grammar: Its Nature and Terminology
Robert D. Eagleson, Terry Threadgold, Peter C. Collins
Pitman, Carlton Victoria, 1983
Information and Records Management
Mary F. Robek, Gerald F. Brown & Wilmer O Maedke
Glencoe Publishing Company, Mission Hills CA, 1987
In Search of Semiotics
David Sless
Barnes & Noble Books, Totowa, New Jersey, 1986
Learning and Visual Communication
David Sless
Croom Helm, London, 1981
No Single Measure: a survey of Australian adult literacy
Rosie Wickert
Commonwealth Department of Employment, Education and Training, Canberra,
1989
7 Steps to Better Written Policies and Procedures
Stephen Butler Page
The Complete Plain Words
Sir Ernest Gowers
Penguin Books, Harmondsworth, Middlesex, 1987
90 The New Playscript Procedure

Leslie H. Matthies
Office Publications Inc., Stamford CT, 1977
The People Side of Systems
Keith London
McGraw Hill Book Company, Hampshire England, 1980
User and Task Analysis for Interface Design
JoAnn T. Hackos and Janice C. Redish
Wiley & Sons, New York, 1998
Verbal Information Systems
Clyde W. Jackson
Association for Systems Management, Cleveland Ohio, 1981
What is Plain English Anyway?
Veda Charrow
Document Design Center, American Institutes for Research, 1979
Writing in Plain English
Robert D. Eagleson
Australian Government Publishing Service, Canberra, 1990
Writing Plain English: A guide for writers and designers of official forms, leaflets,
labels and agreements
Martin Cutts & Chrissis Maher
Plain English Campaign, Salford, England, 1980
Writing with Precision
Jefferson D. Bates
Acropolis Books, Washington, 1981
Appendix 2
Decision Tables
Decision Tables are not a common component of procedure manuals but

they can be effective when complex situations need to be analysed and expressed 91
in graph form. They have the following advantages:
1. They clarify problems that are difficult to set down in procedure or flow
chart form.
2. They reduce ambiguity for the user who can see a summary of the various
conditions and courses of action.
3. They illustrate the logic of a situation and provide a proper appreciation of
it without prejudice to the step sequence of the procedure.
4. Errors of omission in logic can easily be picked up and corrected.
5. Concise instructions can be given for many situations and combinations of
factors.
6. They highlight exceptions in a decision making routine.
How decision tables are used

As a simple illustration, here is a situation that you might find yourself in
where you need to make a logical decision:
1. If it is cold and wet, I will take my coat and umbrella.
2. If it is cold but not wet, I will take my coat and leave the umbrella at home.
3. If it is wet but not cold, I will take my umbrella and leave the coat at home.
4. If it is neither cold nor wet, I will leave both the coat and umbrella at home.
This same situation can be expressed in a decision table.
In figure A2.1, Rule Number 1 expresses the condition that it is both cold and
wet, and the action to be taken is indicated in the lower part of that tabletake a
coat and umbrella. You wouldnt use a decision table for such a simple choice, but
it illustrates the principle.
Figure A2.1 A Basic Decision Table
Rule Number
1 2 3 4
Is it cold? YES YES NO NO CONDITIONS
Is it wet? YES NO YES NO
Take coat X X ACTIONS
Take umbrella X X
Take neither X
The same type of table can be used to show more than two conditions.
Consider the following: I will buy petrol if the gauge shows less than 1/4 full,
or if I have more than 100 km to travel. This could be expressed in a decision table
as shown in Figure A2.2
Figure A2.2 Decision table with more than two conditions
Rule Number
92 Tank less than 1/4 full?

1
Y
2
-
3
-
4
N
Greater than 100 km trip? - - Y N
Tank Full? - Y N N
Buy petrol X X
No action X X
Layout of a decision table

Decision tables can be laid out in two basic formats.
1. Multiple conditions
The first method is that shown above. The conditions (in the form of YES/NO
statements) are given in one block at the top.
The actions are then shown in another table underneath, with X indicating
the action to be taken.
2. Two sets of conditions

The other method is designed for situations where there are only two factors
(sets of conditions) to be considered. One factor is shown across the top and
the other down the left hand side. The actions are inserted in the body of the
table.
Appendix 2 Decision Tables
For example, Figure A2.3 shows the cold/wet weather table illustrated earlier
but redrawn by this method.
Figure A2.3 Alternative layout of a decision table
Condition 1 Condition 2
FACTOR 1 WET NOT WET
FACTOR 2
COLD Take coat and umbrella Take coat only
NOT COLD Take umbrella only Leave coat and umbrella at

home
For this particular situation the factors were really too simple for a table such
as this, but it serves to illustrate the principle. However, where each of the factors
has a number of conditions and the actions are simple to explain, this method can
be a great help. This latter method is more applicable as a substitute for procedures
than the first.
Compiling a multiple-condition table

This decision table is similar to the first method described previously, where
the possible conditions are listed in the top section and the actions in the lower
93
section.
The method described here should be used where the decision alternatives
are complex and care is needed to ensure that nothing is left out. On simpler tables
a more piecemeal approach is usually satisfactory.
Method of construction
The results of steps 1 to 7 are illustrated in Figure A2.4.
1. Enter all conditions
Enter all the conditions to the table down the left hand side.
2. Calculate number of decision rules and enter
The maximum number of rules is 2n where n is the number of conditions.
For example: for 2 conditions there are 22 (that is 4) rules.
for 3 conditions there are 23 (that is 8) rules.
Enter appropriate rule numbers across the top of the tables above the columns
where the Y and N answers will go.
Note that in Figure A2.4, rules 19 to 29 have been omitted from the illustration
to save space.
3. Enter yess and nos for first condition
Divide the number of rules in half; enter Ys for the first half and Ns for the
second half.
4. Enter yess and nos for second condition

Following the same pattern as above, divide the number of rules into 4; enter
Ys for the first quarter, Ns for the second quarter, Ys for the third quarter
and Ns for the last quarter.
5. Enter yess and nos for the remainder of the conditions
Continue in this way for each subsequent condition, halving the number of
Ys and Ns at each row so that the final row is a succession of alternating
single Ys and Ns.
6. Enter all the actions
Draw a line across the chart below the conditions and enter the actions down
the left hand side below the conditions.
7. Enter xs against action choices
Complete the rules by marking with an X the actions appropriate to each
rule. This gives us a logically complete set of choices, even if some of them
are nonsense. It also results in a very large table unless few conditions are
present. The next steps take care of this situation.
Figure A2.4 Illustration of steps 1 to 7 in completing a decision table
RULE NUMBERS
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 30 31 32
Account paid to date? Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y N N N N N
94 Goods required today? Y Y Y Y Y Y Y Y N N N N N N N N Y Y N N N
Goods in stock? Y Y Y Y N N N N Y Y Y Y N N N N Y Y N N N
Discount applicable? Y Y N N Y Y N N Y Y N N Y Y N N Y Y Y N N
Show discount on invoice? Y N Y N Y N Y N Y N Y N Y N Y N Y N N Y
Calculate COD invoice X X

Calculate credit invoice X X X X

Post ledger X X X X
Calculate discount X X

Add discount to invoice X

Type invoice X X X X X X

Produce delivery dockets X X X X X X

Advise stock problem X X X X X

File order X X X X X X X X X X X X X

Note that some of these conditions are impossible. For example, if a discount is
not applicable then it cannot be entered on the invoice.
The table should now be redrawn as shown in Figure A2.5, using dashes to
replace impossible situations that confuse the picture.
8. Eliminate impossible condition choices

Replace all symbols that imply an impossible or irrelevant situation with a
dash.
In the example shown in Figure A2.5, if the goods are not required TODAY,
then todays stock level is irrelevant since they dont have to be supplied yet. It
is the stock level on the supply date that is important. Likewise, if theyre not
being supplied yet, there is no need to consider the possibility of a discount
since there is no document to show it on.
Figure A2.5 Illustration of step 8 in completing a decision table

RULE NUMBERS
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 30 31 32
Account paid to date? Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y N N N N N
Goods required today? Y Y Y Y Y Y Y Y N N N N N N N N Y Y N N N
Goods in stock? Y Y Y Y N N N N - - - - - - - - Y Y - - -
Discount applicable? Y Y N N Y Y N N - - - - - - - - - - - - -
Show discount on invoice? Y N - - Y N - - - - - - - - - - - - - - -
Calculate COD invoice X X

Calculate credit invoice X X X X

Post ledger X X X X
Calculate discount

X X

95

Type invoice X X X X X X

Produce delivery dockets X X X X X X

Advise stock problem X X X X X

File order X X X X X X X X X X X X X

9. Combine rules with duplicate action entries

A number of rules are identical and can be combined.
Combine into one rule:
a. any duplicate rules
b. any set of two rules that differ in only one condition while having
identical action entries, and replace the differing symbols by a dash.
Rules 5 and 6 are identical in action but differ by only one condition. These can
also be combined with a dash to replace the differing symbol.
The table would now look like Figure A2.6.
Figure A2.6 Illustration of step 9 in completing a decision table

Revised Rule Numbers
1 2 3 4 5 6 7 8
Account paid to date? Y Y Y Y Y N N N
Goods required today? Y Y Y Y N Y Y N
Goods in stock? Y Y Y N - Y N -
Discount applicable? Y Y N - - - - -
Show discount on invoice? Y N - - - - - -
Calculate COD invoice X
Calculate credit invoice X X X
Post ledger X X X
Type invoice X X X X
Produce delivery dockets X X X X
Advise stock problem X X
File order X X X X
10. Check the table

Contradictions occur when two rules having identical entries lead to differing
actions. Check by inspecting the table.
Redundancies occur when possible simplifications remain unabbreviated.
Check by inspecting the table.
96 Completeness can be checked by comparing the number of rules in the table
against the known maximum. Any rule with one or more dashes represents
2d simple rules, where d is the number of dashes in it. For example, in Figure
A2.6:
RULE 1 = 20 = 1
RULE 2 = 20 = 1
RULE 3 = 1
2 = 2
RULE 4 = 22 = 4
RULE 5 = 23 = 8
RULE 6 = 22 = 4
RULE 7 = 22 = 4
RULE 8 = 23 = 8
TOTAL 32 original rules
Accuracy of descriptions should be checked to ensure that ONLY Yes or No
answers can apply to each condition and that the question is phrased accurately
in the most economical way. For example: Age under 19 is more precise that
Age not more than 18. Age over 18 and under 65 is more economical than Age
not under 18 and Age under 65 as separate questions.
The else rule

This enables you to take short cuts by writing ELSE in place of a number of
Rule Numbers. No entries are made against any of the conditions and actions are
left blank when no rule applies. Note that the checking-rules given above do not
apply. Figure A2.7 shows an example of the ELSE rule.
Figure A2.7 Illustration of the else rule in a decision table
Rule Numbers
1 2 3 4 ELSE
Account paid to date? Y Y Y N
Goods required today? Y Y Y Y
Goods in stock? Y Y Y Y
Discount applicable? Y Y N -
Show discount on invoice? Y N - -
Calculate COD invoice X
Calculate credit invoice X X X
Post ledger X X X
Type invoice X X X X
Produce delivery dockets X X X X
Acknowledge and file order X
97
98
Appendix 3
Subject Index
action by column 24 Bell Telephone Laboratories 76 communication 70

not in Task Outline 41
action performed column 25
Ben Graham Corporation 17, 74
big words 53
effective 48
neglected 70
99
action verb 15 binders 85 research 33
in Task Outline 42 Blake Management Grid 3 Communication Research Institute of
active voice 55 blaming incompetence 77 Australia 16, 47
actor action relationship 54 block effective understanding 48 Complete Plain Words 51
actor column 24 brainstorming 62 complex choice situations 38
adjectives 50 branching instructions defined 63 complex decision making 33
administrative documentation 1 break points in procedure 31 complexity of the procedures 64
adverbs 50 brevity from Playscript 15 computer analysts 53
aesthetics 70 business systems analysts 2 computers 1
agreement from Playscript method 15 change 82 computer system jargon 53
alternative channels 35 introduction simplified 16 computer systems 61
alternatives 36 changes 86 computer systems analysts 2
ambiguity 50, 91 changing format of Playscript 19 computer systems documentation 1
ambiguous language 54 charting paper flow 74 concepts 81
ambiguous words 50 checking drafts 83 confusion 76
analysis helped by Playscript 17 choice questions 78 in procedures 48
appointments 78 choices within a choice 38 contents 85
appropriate language 53 circular letters 1 control 5
arguments 82 clause sequence 50, 54 correctness 54
asking for advice 43 clearance, legal and technical 69 correspondence 41
auditing 83 clear start and finish 48 covering up loopholes 53
audit trail using Playscript 17 clerical errors 2 creative thinking 62
authorising signatures 52 clerical work measurement 69 CRIA 47
average reading age 48 Clyde Jackson 47 cross-referencing 17
axe to grind 77 codes in procedure manual 11 cycle of work 31, 42
backbone of procedure 48 column headings 24 dangling modifiers 51
basic decision table 92 comb binding 85 date of publishing 52
behaviour 76 Commission on Federal Paperwork 71 date of the procedure 21
decision-making point 33 form instruction, changing 70

decision making routines 33 completion details 43 insurance industry 16
decision table 40, 43, 91 filling 52 intent 48
layout 92 history file 11 interpretation 47
multiple conditions 92 number 21 interpreting language in procedure 47
definitions 52, 64 seeing improvement 76 Intimidation 53
delay points in procedure 31 format changing 19 in-tray 42
departmental form-filling instructions 1 introducing change 16
classifications 53 forms 33 ISO paper sizes 19
functions lists 1 finance industry 16 Jackson, Clyde 47
responsibilities 53 government 16 jargon 51, 54
detailed instructions for one individual insurance industry 16 jellyfish
53 forms catalogues 1 approach 48
dictionary habit 54 Forms Under Control 48 procedures 12
direct language 56 frustration 76 job finished 43
documentation 6 function included in procedure 32 Judith Goyen 49
Documents To Manage By 19 functions of a manual 5 Keith London Systems Matrix 3
draft preparation 62 future tense 55 kidlish 48
draft procedures 57 gaining acceptance 83 labor unions 83
drafts checked by users 83 gaps in the action sequence 32 language 42, 53
duplication deleted 63 getting your message across 47 appropriate 47
duplication of effort 17 glossaries in procedure manual 11 skills 48
Eagleson, Robert 50 gobbledegook 54 slanted to one department 58
editing 64 Gowers, Sir Ernest 51 lawyers 50
efficiency 2 Goyen, Judith 49 layout form standards 20
electronic format 16 grammar 48 leading respondent 77
else rule 97 grammatical correction 69 Legal department 83
e-mail 42 Gunning, Robert 49 legal or technical clearance 69
empathy 47 heavy editing 64 legal reasons 2
100 lacking 51
encouraging revision 84
hesitation 79
highlight exceptions 91
length of sentences 54
line managers 4
ending point 12 highlighting linking procedures 16
environment of worker 53 breaks 26 literacy 49
equipment efficiency 70 verbs 26 logic 51, 91
ergonomics 70 human logical thought processes 53
error messages in procedure manual 11 behaviour 76 logo 20
errors of omission 91 mind 62 long lines 41
exceptions 37 human communication 33 long sentences 53
exceptions handling 37 human communication complexities 47 loopholes 53
exchanging information 57 humanise systems 2 machine
explaining the concepts 81 identify major functions 61 people treated as 69
facial expression 76 illogical thought sequence 51 main work channel 42, 61
filling in a form 52 implementation 81 main work flow 61
final procedure 57, 64 improvement visible 76 major branch 36
finance department 83 incompetence blaming 77 major operational functions 61
finance industry 16 indent side channels 34 mannerism 76
finding information in a manual 11 indexing 85 manual
finding information using Playscript 15 procedures 21 format 12
first run 85 index to manual 11 index 11
flag waving 53 indirect language 56 numbering 22
Flesch Reading Ease Scale 49, 72 indirectly affected users 83 packaging 85
Flesch, Rudolph 49 Industrial Engineering 69 table of contents 11
flow charting 74 information copy 87 margins 24
flow of work 2 information finding using Playscript 15 Matthies
focus groups 75 information systems professionals 70 pronunciation 13
Fog Index 49, 72 initial presentation 82 meaning 48
follow the action 30, 60 insecurity 77 memos 1
foreign matter in the procedure 52 instruction 5 middle management 5
Appendix 3 Subject Index
Milward 70 title 20 punctuation 55, 82

mind 62 pages in a procedure 23 purposes 53
mind unique 52 paper flow 70 quality 73
misread instruction 79 charting 74 questionnaire 38
missed question 79 paper flow diagram 17 questionnaire-design research 16
missing steps 42 paper for manuals 85 questionnaires 33
mistrust 48, 83 paperwork questions from users 83
misunderstandings 48 elimination 74 questions in a form 33
modifications of Playscript 19 reduction 72 rare problem exceptions 37
modifiers 50 U.S. Commission 71 readability formulas 49, 69
movement 70 passive voice 55 reading
multiple choice decisions 43 past tense 55 age 48
multiple choices 38 peak workload periods 67 aloud during testing 79
multiple decisions 40 people protocol 79
multiple steps 35 treating as machines 69 Reading Ease Yardstick 72
multiple word meanings 50 philosophy 53 reading long lines 41
narrative 12 plain language 48 reference 5
format and training 17 planning 59 regularly, what people mean 61
new format for older procedures 64 Playscript relationship between writer and users 81
nouns out of verbs 56 columns 23 research 33
numbering 85 forces brevity 15 research, questionnaire design 16
by department 22 in any organisation 17 responsibilities established 56
by project 22 overview 14 responsibilities for work 15
methods 22 problems 14 responsibility clarified 15
number of procedure 21 procedure example 11 retraining 70
objectives of procedure 10 policy 13, 20 review 5, 63
objectives of work 60 conformity to 65 again 63
observational study 76 defined 7 draft procedures 57
aims 76 included in procedure 32 revision, encouraging 84
approach 76
choice questions 78
in procedure manuals 7
rewriting 65
rewriting existing procedures 64
Robert Eagleson 50
101
finish 80 statements 52 Robert Gunning 49
first round 77 policy component 82 role of manuals 2
leading respondent 77 policy statements 1 rough draft 62
preparation 78 political climate 64 scanning local area 79
problems 77 politics 57 scopes 53
reading aloud 79 poor sentence structure 54 secret agendas 77
size 77 position specifications 1, 64 selectivity 61
talkative respondents 78 possibilities considered 63 self esteem 67
observing problem exceptions 37 senior management 5
behaviour 77 procedure 41, 59 sentence
form in action 79 date 21 length 54
office records 41 defined 10 structure 54
O&M 70 indexing 21 separate procedure 37
one-way communication 47 linkage made easy 16 sequence of clauses 50
operatives 4 number 21 service approach 81
opinions 53, 77 objectives 10 shared meaning 48
opinion surveys 69 starting point 30 Shewhart, Walter 76
Organisation and Methods 70 subject 20 short sentences 55
organisation charts 1 title 25 short side channel 33
origin of data 2 writing 62 side channel 33
outline format 13 procedures analysis 64 side channel for one person 33
outline for writing 62 procedures analysts 2, 56 side channels 42
overall procedures first 61 Production Control 83 signatures and initials 32
overview of Playscript 14 professional writers 15 sign off 84
packaging your manuals 85 pronouns 51 simplified writing with Playscript 15
page proofreading 69 skeleton of procedure 48
number 23 publishing dates 52 slanting language to one department 58
spacing between lines and steps 29 test the procedures 64

special cases 43 thought sequence 51
staff training 82 time sequence 15, 42
standard layout form 20 timing arrangements 43
standard paper sizes 19 title 25
standards 1, 6 training 70
standards to be followed 43 helped by Playscript 17
start and end points 60 supervision 82
start and finish 48 trigger action 30, 42, 59
starting point 12, 30 understanding 48
step-by-step approach 82 lack of 76
step-by-step time sequence 15 understanding clarified 82
step number 25 uniform format 16
straight-through sequence 82 usability testing 39
structure U.S. Commission on Federal Paperwork
of manual 13 71
of sentences 54 use active voice 55
structure of the organisation 64 use direct language 56
subconscious mind 62 user help 84
subject categories 52 verbs
subject of procedure 20 highlighted in procedure 26
subroutines 33, 42 turned into nouns 56
subroutines defined 63 vocabulary 47
supervising staff training 82 voice 55
supervisors 4 waffle
switching to separate procedure 37 avoiding in discussion 17
switch to separate procedure 37 what to include 42
system word meaning 50
description 13 work channels
102 narrative 11
objectives 8
identifying 30
work cycle 31, 42, 60
systematic procedure writing 59 work environment 54
system description 2 worker environment 53
systems analysis helped by Playscript 17 work flow 61
table of contents in manual 11 in procedure 10
talkative respondents 78 workflow 2
task finished 43 work mode 53
task objectives 10 work mode of writing 63
task-oriented procedures 53 work objectives 60
Task Outline work responsibilities 15
basic structure 41 World War II 70
defined 10 Wright, Patricia 69, 72
example 12 writers
features 41 professional 15
teaching users about a change 82 writing outline 62
teaching users about a new procedure writing simplified 15
82 writing style 47
team approach to writing 56 Writing With Precision 49
teamwork shown in procedure 10
technical explanation
included in Task Outline 45
technical information 57
technical jargon 48
temporary announcements 1
tense in Playscript 55
testing
common approaches 69
focus groups 75
traditional methods 69

Practical Playscript Writing

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Practical Playscript Writing

Transféré par

Droits d'auteur :

Formats disponibles

Practical Playscript

Writing procedure manuals that people can use

Managing Business Forms

Third Edition 2008

All rights reserved

No part of this publication may be reproduced, stored in any retrieval system, or

Published by Robert Barnett and Associates Pty Ltd

Printed in Canberra, Australia

Chapter 2 Content of Procedure Manuals 7

Chapter 3 Rules of Structure 19

Chapter 4 Subroutines and Side Channels 33

Chapter 5 Task Outlines 41

Chapter 6 Writing Style 47

Chapter 8 Usability Testing 69

Chapter 9 Implementing Playscript 81

Appendix 1 Suggested Reading 89

Appendix 2 Decision Tables 91

Appendix 3 Subject Index 99

Why have a procedure manual?

Procedures Analysts or Business Systems Analysts

Computer Systems Analysts

Figure 1.1 Keith London Systems Matrix

Line Managers and Supervisors

Senior and Middle Management

1 Peters, Tom (1987) Thriving on Chaos, Alfred A. Knopf, New York.

Leslie Matthies5 described the characteristics of policy this way:

Figure 2.1 A Corporate Policy Statement

Forms Management Policy

3.1 FORMS MANAGEMENT DEPARTMENT will maintain a central activity to

3.3 PURCHASING DEPARTMENT will accept requisitions for outside-printed

3.4 REPRODUCTION DEPARTMENT will reproduce only those forms identified

Form usage specification

Index and Table of Contents

Figure 2.2 Page from a Playscript procedure

4. ENTER details into the Purchase Log.

Vendor 6. SHOW the Order Number on the Invoice.

Figure 2.3 Page from a Task Outline

Subject New File Allocation TRM003

Performed by: Records Manager

Frequency: Whenever a new file is requested

1. COLLECT all relevant information about the file subject.

Putting the facets together

Figure 2.4 A Typical Narrative Procedure

Word Processing Request

Many writers produce a highly structured version of the narrativesometimes

The advantages and uses of Playscript

It establishes and clarifies responsibility

It is a tool for getting agreement

It simplifies the finding of information

It provides a uniform format

It provides for easier handling of non-routine procedures

It simplifies the introduction of change

It makes procedure linkage easy

It helps the training of new employees

It assists systems analysis

It can be used in any organisation

Suitability for on-line documentation

Changing the format

Procedures versus other material

Using a standard layout form

Figure 3.1 Examples of preprinted headings

Date of the procedure

Figure 3.2 Layout of a Playscript page

Action by Step Action performed