Practical Playscript Writing procedure manuals that people can use
ALSO BY ROBERT BARNETT
Managing Business Forms Fo...
92 downloads
524 Views
1MB Size
Report
This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form
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 Designer’s Quick Reference Guide
Writing procedure manuals that people can use
Practical Playscript 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 means—electronic, mechanical, photocopying, recording or otherwise—without 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
Chapter 1 The Role of Procedure Manuals
1 2 5
Why have a procedure manual? Functions of a manual
Chapter 2 Content of Procedure Manuals Types of material Putting the facets together An overview of Playscript The advantages and uses of Playscript
Chapter 3 Rules of Structure Changing the format Procedures versus other material Using a standard layout form Procedure layout Sequence of steps
7 7 12 14 14 19 19 20 20 23 29
v
Practical Playscript
Chapter 4 Subroutines and Side Channels Short side channel involving one person Short side channel involving more than one person Two short alternative channels with multiple steps Major branch into two separate activities The rare problem exceptions Choices within a choice Handling multiple decisions
Chapter 5 Task Outlines The basic structure What to include Special cases
Chapter 6 Writing Style Start with a clear structure Avoid confusion Writing procedures as part of a team Slanting the language to one department
vi
Chapter 7 The Writing Cycle What makes up a procedure? Writing the procedures Rewriting existing procedures in a new format Writing procedures for a new system Documenting current unwritten procedures
Chapter 8 Usability Testing Some common approaches to testing Observational usability studies How to conduct the usability study
33 33 35 35 36 37 38 40 41 41 42 43 47 48 48 56 58 59 59 61 64 66 67 69 69 75 78
Practical Playscript
Chapter 9 Implementing Playscript Teaching users about Playscript Teaching users about a new procedure or a change Gaining acceptance Encouraging revision Manual production Making changes One final matter
81 81 82 83 84 84 86 87
Appendix 1 Suggested Reading
89
Appendix 2 Decision Tables
91
Appendix 3 Subject Index
99
vii
Practical Playscript
viii
Practical Playscript
Acknowledgments
M
ost books on management include ideas and principles gathered by the author from predecessors and restructured to suit the author’s 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 Jackson’s 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
ix
Practical Playscript
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 today’s emphasis on computers, this adage is still true. In addition to such practical office work tools as forms, reports, correspondence and memos, there is a vast range of other administrative paper—much of it essential—but 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.
1
Practical Playscript
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 don’t 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
2
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 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 analyst’s 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. Let’s quit putting ourselves and them on. The computer is a machine. That’s 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 user’s 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 don’t 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
3
2 London, Keith (1976) The People Side of Systems, McGraw Hill Book Company (UK).
Practical Playscript
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 department’s 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 doesn’t 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.
4
Operatives 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 don’t 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 we’ll 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. • 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 superior’s time, and he is more independent. • It refreshes a person’s 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.
5
Practical Playscript
• 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 individual’s or a department’s 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 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. I’m 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.
7
Practical Playscript
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.”
8
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 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 doesn’t 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 company’s 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 • 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.
9
Practical Playscript
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. I’m 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.”
10
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 include the how to but usually not in the same detail as a tack outline. The procedure’s emphasis is on teamwork telling all the team members how their work fits into the overall process—or 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.
Chapter 2 • Content of Procedure Manuals
how to fill it in. My experience is that while possibly being of use in a system description, or as part of the form’s 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 can’t 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 won’t need a detailed index. A good computer system should allow you to search for keywords or synonyms. Figure 2.2 Subject
Page from a Playscript procedure Purchasing items for the Association
Action by
Step
Purchaser
1. 2.
Secretary
3.
PPU020
Action performed PHONE the Association office and ask for a purchase order number. DESCRIBE the item and the total amount of money that will be required. 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
Purchaser
ADVISE the person who has authority to order.
4.
ENTER details into the Purchase Log.
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
Vendor
6.
INSTRUCT vendor to send the invoice to the Association, marked ‘Attention Treasurer’.
SHOW the Order Number on the Invoice. -----------------------------
11
Practical Playscript
Figure 2.3
Page from a Task Outline
Subject
New File Allocation
Performed by:
Records Manager
Frequency:
Whenever a new file is requested
TRM003
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 doesn’t fit into an existing subdivision and it appears necessary to open a new group, check with the manager of the department concerned before allocating.
12
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. 767).
-----------------------
Putting the facets together Many systems and administrative people try to combine all the different facets of documentation in one single format—a narrative—but it just doesn’t 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 event—be 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 aren’t left hanging, wonding if there’s anything else to do.
Chapter 2 • Content of Procedure Manuals
Figure 2.4
A Typical Narrative Procedure
Word Processing Request When work of any kind (excluding photocopying) is sent to the Word Processing Services 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 originator’s 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 originator’s 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. Note that if the details of two different standard letters are shown on a Word Processing 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 narrative—sometimes called ‘Outline’ format, and not to be confused with a Playscript task outline—in 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 1960’s 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
13
Practical Playscript
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
14
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 weren’t 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 didn’t differentiate policy from step-by-step detail. • We didn’t 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. 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 didn’t 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.
Chapter 2 • Content of Procedure Manuals
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 people’s 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 doesn’t. 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. 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.
15
Practical Playscript
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 organisation’s 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
16
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 didn’t 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. 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.
Chapter 2 • Content of Procedure Manuals
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. 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 Playscript’s 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 Playscript’s built-in cross-referencing.
17
Practical Playscript
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 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.
19
Practical Playscript
… If you try to modify a proven, effective technique, all you’re 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 don’t separate policy statements and other systems documentation. Procedures are different to other typs of business documents—they are written for a different purpose—and 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 doesn’t work unless this is understood.
Using a standard layout form
20
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 I’m 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 the word ‘procedure’, but this may be redundant. They are the procedures for the organisation, so you may only need to preprint the organisation’s 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 encountered—and one that Matthies also mentions—is ‘Standard Practice Instruction’. On the other hand, some organi sations use the word ‘procedure’ when they aren’t 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 don’t 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.
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 it—the 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
21
Practical Playscript
22
their opinions. The way in which you number the procedures will depend on the size and type of organisation for which they’re 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 doesn’t 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 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 d’Agenais & 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 d’Agenais & Curruthers don’t 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 d’Agenais, Jean & Carruthers, John (1985) Creating Effective Manuals, South-Western Publishing Company, Cincinnati Ohio.
Chapter 3 • Rules of Structure
significance—they 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 company’s 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 don’t 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 don’t get mixed up in reproduction and filing. However, don’t number the pages continuously for the whole manual. Start each procedure at page 1.
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.
23
Practical Playscript
Figure 3.2
Layout of a Playscript page
Action by
Step
Action performed
Secretary
1.
SORT time cards by department, placing in Time Summary Envelope (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
24
Suggested spacing for a Playscript page
A4 page
81/2 x 11 inch page
Left hand margin
25 mm
1 inch
Action By column
40 mm
11/2 inches
Sequence Number column
10 mm
Action Performed column
110 mm
41/3 inches
Right hand margin
25 mm
1 inch
1/3
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.
Chapter 3 • Rules of Structure
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 person’s 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 Facilities Engineer Plant and Facilities Engineer Plant and Facilities Engineer
5.
INDICATE on the form when preliminary action will be taken to investigate the matter.
5.
INDICATE on the form when preliminary action will be taken to investigate the matter.
5.
INDICATE on the form when preliminary action 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
25
Practical Playscript
occur and that the Secretary’s 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 by
Action column with timing break Step Action performed -----------------
Purchaser
Vendor
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’.
7.
SHOW the Order Number on the Invoice and send it to the Association as requested. ON RECEIPT OF INVOICE
26
Association Secretary
8.
CHECK with purchaser to make sure that items have been received and note this on the Invoice. -----------------
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.
Chapter 3 • Rules of Structure
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 verb—something that isn’t 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 isn’t compatible with normal Playscript. Figure 3.6
An action step with built-in timing instructions
Action by Secretary
Step Action performed 1.
Upon receipt of time cards, 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-0404, 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.
27
Practical Playscript
Figure 3.7
Timing instructions removed from action step
Action by
Step Action performed 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’)
Action by
28
Step Action performed
Requestor
1.
PHONE the Records Office to determine whether or not the required Security File is available.
Records Officer
2.
EXAMINE the Security File Reference Record (Form No. 354) to ensure that the file has been cleared by the requestor, and note on the form the name of the requestor, the date of the request and the fact that the question was asked.
Second action
-----------------
Figure 3.9 Action by
Separating a combined action into two steps Step Action performed
Requestor
1.
PHONE the Records Office to determine whether or not the required Security File is available.
Records Officer
2.
EXAMINE the Security File Reference Record (Form No. 354) to ensure that the file has been cleared by the requestor.
3.
NOTE on the form the name of the requestor, the date of the request and the fact that the question was asked. -----------------
Chapter 3 • Rules of Structure
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 Action by
Step combining two totally different actions Step Action performed
Supervisor
----------------4.
Figure 3.11 Action by
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.
Step rewritten to show the two actions Step Action performed
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 should have extra space between them. Figure 3.12 Action by Requestor
Action step forming a block Step Action performed 1.
PHONE the Records Office to determine whether or not the required Security File is available.
2.
EXAMINE the Security File Reference Record (Form No. 354) to ensure that the file has been cleared by the requestor, 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 sequence—one after the other.
29
Practical Playscript
As Matthies2 says: “…some people write their procedures as though this logical time sequence didn’t exist.” For example, if an employee is applying for leave, the steps could occur as follows: MONDAY MONDAY MONDAY TUESDAY TUESDAY
9.00 a.m. 10.30 a.m. 11.00 a.m. 3.00 p.m. 4.30 p.m.
FRIDAY FRIDAY
3.30 p.m. 5.00 p.m.
Employee fills in Leave Application Form. Supervisor signs application form. Manager approves time allocation for leave. Personnel Manager approves leave. Personnel Manager advises Paymaster the person’s leave is approved. Paymaster pays leave pay. 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.
30
The starting point 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 person
1.
PHONE to advise that car has been in an accident and 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.
2 Matthies, Leslie H. (1977) The New Playscript Procedure, Office Publications Inc., Stamford.
Chapter 3 • Rules of Structure
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 procedure—those 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
Action by Claims Controller
Step Action performed ----------------23. ADVISE the insurer of the claim. 24. ESTABLISH the insurer’s 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. 3 Matthies, Leslie H. (1977) The New Playscript Procedure, Office Publications Inc., Stamford.
31
Practical Playscript
Figure 3.15
Break into two procedures at delay point
Action by
Step Action performed
Claims Controller
----------------23. ADVISE the insurer of the claim. 24. ESTABLISH the insurer’s requirements for lodging the claim. 25. ARRANGE for an assessor to visit the client.
Assessor
Delay
Action by Claims Controller
26. VISIT the client and assesses the damage. It is at this point that a delay occurs while the damage is assessed. This is a logical point to divide the procedure into two parts with a new procedure starting at step 1. Step Action performed 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 task’s 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. 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 I’ve mentioned in earlier chapters, in this edition of Practical Playscript I’ve 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.
33
Practical Playscript
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 cashier’s 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 Action by
Handling a short side channel — alternative 1 Step Action performed
Applicant
----------------5.
Cashier
6.
34 7.
Figure 4.2 Action by
6b. If cheques are not acceptable, TELL applicant to go to the enquiry counter. RECORD receipt on Application Form butt and return it to the Applicant.
Handling a short side channel — alternative 2 Step Action performed
Applicant
----------------5.
Cashier
HAND payment and completed Application Form to the Cashier. 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.
6.
HAND payment and completed Application Form to the Cashier. 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 Action by
Side channel involving more than one person Step Action performed
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 Accountant
5c. SHOW the order number on the Invoice and send it to the company as requested. 6.
on receipt of invoice 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 doesn’t 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.
35
Practical Playscript
Figure 4.4 Action by Account Executive
Alternative channels with multiple steps Step Action performed ----------------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.
36
10.
PREPARE Cover Expiry Record (Form No. 45) in duplicate.
11.
FILE original of the Cover Expiry Record in the Register 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.
Chapter 4 • Subroutines and Side Channels
Figure 4.5
Switching out to a subroutine
Action by
Step Action performed
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, go to Procedure 09-08-13.
switch to subroutine 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
Action by
Step Action performed
Cashier Manager
----------------10.
CIRCULATE cash receipts to Account Managers.
11.
RETRIEVE appropriate record from file. 11a. if renewal of policy
switch to separate procedures
Go to Procedure 10-02-01. 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 situation—a more knowledgeable person who has the authority to decide what to do. See Figure 4.7.
37
Practical Playscript
Figure 4.7
Handling problem exceptions
Action by Spare Parts Clerk
handling problem exception
Step Action performed ----------------10.
RETRIEVE Stock Card for each item and record details of supply. 9a. If the item cannot be identified from the description given on the order, refer the matter to the Technical Supervisor.
Choices within a choice
38
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 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, I’ve 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.
Chapter 4 • Subroutines and Side Channels
Figure 4.8 Action by
Complex set of choices Step Action performed -----------------
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 records—go to Step 3e. 3b if not: find out if an Invoice set has been issued and processed. 3c. if so: CORRECT records—go 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 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 aren’t 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.
39
Practical Playscript
Figure 4.9
40
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? 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 person’s task taken out of a procedure. It may be only one step of an overall procedure 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 wouldn’t necessarily disagree with this since it does save paper. There isn’t 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 don’t 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.
41
Practical Playscript
• The description should start with a ‘trigger’ action—something 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 result—either 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?
42
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 day’s mail is received from the post office. • A document is placed in the person’s 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 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. It’s 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 it’s 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, I’d 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 Table—a 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 highlighted—possibly 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. 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 don’t 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.
43
Practical Playscript
Figure 5.1 Action by
Form details in a task outline Step Action performed
Sales Clerk
----------------1.
ENTER the following details on a Sales Enquiry Record (Form No. 1023). • Registered business name Obtain the customer’s 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”. • Customer’s street address Show full street address including State and Postcode. Do not use a Post Office Box address.
44
• Customer’s Postal address Show full postal address including State and Postcode. If the same as street address, write “as above”. • 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 Action by
Technical notes in a task outline Step Action performed
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
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. -----------------
45
Practical Playscript
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 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 can’t place our thoughts automatically into the minds of the readers, we need to come as close to that place as possible—to have empathy with the reader. As Clyde Jackson1 says: “We have to come out of our world into the reader’s 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
47
Practical Playscript
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 doesn’t 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
48
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 person’s intent. Fortunately, with procedure manuals, 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 don’t 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 I’m not talking about the use of what I call ‘kidlish’—writing 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 Britain’s 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 don’t work with technical material and, in fact, are of doubtful 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. Flesch’s Reading Ease Scale and Robert Gunning’s 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.
49
Practical Playscript
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
50
Using a word which has more than one meaning and where the context doesn’t 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. 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.
Chapter 6 • Writing Style
For example: The applicant’s 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 don’t 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 doesn’t say who got the sack, the writer or his wife. The writer is implied, but this couldn’t 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 wasn’t 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: “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.
51
Practical Playscript
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
52
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 organisation’s records can be easily located. Many writers muddle people’s 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 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 doesn’t 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 don’t 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..
Chapter 6 • Writing Style
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 reader’s work environment Many procedure manuals are written from the writer’s viewpoint but in very few cases is the writer also the reader. The writer may be the reader’s 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 there’s 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 and layout to show the system’s background—especially if it is a computer system— and the way in which the analyst’s 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-oriented—written 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 reader’s 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. Don’t 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 don’t also understand them. This has been a constant problem for me in writing this
53
Practical Playscript
book—wondering 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 don’t 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
54
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 aren’t 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 don’t 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. 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 doesn’t become clear until the end of the sentence. Examples (ii) to (iv) are clearer. Figure 6.1
Examples of clause sequencing
BAD (i) GOOD (ii) (iii) (iv)
Before filling in the form, read the instructions. Read the instructions before filling in the form. Read the instructions and then fill in the form. 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.
Chapter 6 • Writing Style
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 • 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 doesn’t 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 Playscript’s short sentences. Use the present tense Past tense is usually not a problem as it doesn’t 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.
55
Practical Playscript
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) GOOD (ii)
Authorisation for all absences is be given by the supervisor. The supervisor authorises all absences.
Writing procedures as part of a team
56
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 be the first to know. But those people—while they may be experts in their dayto-day tasks—are 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 don’t 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:
Chapter 6 • Writing Style
• 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 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 content—not 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.
57
Practical Playscript
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 procedure—as distinct from a task outline—is 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 can’t 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 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.
59
Practical Playscript
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 employee’s leave is approved. • Goods are delivered to a customer. Follow the action!
60
Matthies makes an important point in discussing Playscript when he says: ‘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 don’t 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 won’t 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 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 immediately—or 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
61
Practical Playscript
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 outline—writing the step-by-step instructions as described in Chapters 3 to 5.
Chapter 7 • The Writing Cycle
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 review—firstly 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. I’m 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 doesn’t stop you correcting any obvious errors. Editing the draft The edit stage is the place where you knock the procedure into shape—where 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 don’t 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 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 Government’s 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 aren’t 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 don’t 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 possibility—especially 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.
63
Practical Playscript
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
64
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. 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.
Chapter 7 • The Writing Cycle
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 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 don’t 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 doesn’t even know that they exist, but it’s 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, don’t 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 person’s work. Follow the format described in Chapters 3 and 4.
65
Practical Playscript
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
66
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 nents—the forms and written procedures—are often left until last, or at least a late stage in the system’s 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 adequately and they are rushed through—often incomplete—with 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.
Chapter 7 • The Writing Cycle
Schedule your writing Plan time throughout the project to work on the manual. Don’t 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. 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 person’s self esteem—a 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 doesn’t 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 won’t have much success trying to interview accounting personnel during July if the organisation’s financial year ends in June. Try to find out if there are any slack periods such as January, but don’t 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.
67
Practical Playscript
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 happening—when it isn’t—you will most likely miss out on some very important points. This will particularly apply to those exceptions with which the manager hasn’t come in contact. Of course, if you aren’t 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, 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. I’m not suggesting that they should never be used—some do have their place in business systems analysis—but they don’t 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 I’d 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.
69
Practical Playscript
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 accounts…because the current system does not automatically produce a report with that information. The current system has obvious shortcomings. The new system’s 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 system’s performance.”[emphasis mine]
70
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 it—if people make mistakes, retrain them! “ 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 change—but 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. It’s 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. Milward’s 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: “… 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 paperwork…erected between the Government 4
Terry G (1970) Office Management and Control. Homewood, Illinois: Irwin
71
Practical Playscript
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
72
Procedure writers sometimes use readability scores to predict whether or not the procedures will be understood. The best known is Rudolph Flesch’s ‘Reading Ease’ yardstick5 that Microsoft has now included in the grammar checker of its “WORD” word processing program. Others are Robert Gunning’s Fog Index, Fry’s 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 The results are compared with the table in Figure 8.1 Figure 8.1 RE value
Flesh “Reading Ease” yardstick 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 don’t 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.
Chapter 8 • Usability Testing
Even using them for the purposes for which they were designed is of doubtful value.7 They were originally developed in the 1920’s and 1930’s so that publishers of children’s 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 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.” Let’s look at that again: 50% of readers getting 50% of the answers correct—that’s a 25% hit rate—not very reliable if we’re 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: What’s 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
73
Practical Playscript
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 …
74
…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] Now there is a place for flow charts in system development—especially in analysing workflow—but 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 1960’s, 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.
Chapter 8 • Usability Testing
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 doesn’t test anything—it 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 don’t show behavior. They aren’t 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 automatic that they forget to mention it when just talking about it. But the steps that don’t 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 gatekeepers—the 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 don’t 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.
75
Practical Playscript
76
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 wrong—where 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 1920’s. 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 you’ve 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 people—perhaps 6 to 10—over 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 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 wouldn’t 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,
Chapter 8 • Usability Testing
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 enemy—a representative of management. • 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 value—and you certainly should make note of them—they 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 doesn’t 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 user—not the way you would like them to behave. Do not ask leading questions such as: “That’s a confusing statement, isn’t it?” It would be better to say: “What did that instruction mean to you?” and let the person
77
Practical Playscript
volunteer the information that they do or do not find it confusing. They may not understand it, but they may not know that they don’t know and therefore don’t 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 isn’t 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. Don’t get sidetracked—but don’t 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
78
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 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
Chapter 8 • Usability Testing
usually doesn’t know what to expect. Many respondents approach testing as if they were undergoing an examination. 3 4
Say who you are and explain what you are doing
Give whatever background is necessary.
Tell the person that you cannot help them
People being tested often want the observers to help them. But this isn’t 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: “I’m 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. • 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 Don’t 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
79
Practical Playscript
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 haven’t 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 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 don’t 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 organisation—there is no place for ego trips in systems work—and 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.
81
Practical Playscript
82
Comments about the present system will have to highlight the problems that they already know about, bearing in mind that people don’t like change. No matter how bad the present system is, if they have lived with it then it’s quite likely that they’ll be comfortable with it. Change is uncomfortable and people don’t 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 straightthrough 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 don’t mean that poor grammar and punctuation are unimpor tant, but it’s my experience that when some people can’t find anything else wrong, they’ll look for even the most obscure, picky point just for the purpose of finding 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 it’s 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 manager’s relations with the staff who realise (or assume) that the manager doesn’t understand. The approach I’m 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. 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 don’t 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. Don’t 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 isn’t right, what’s the use of issuing it? The best people, as always, are the ones who will actually use the procedures in their dayto-day work rather than the supervisors or managers.
83
Practical Playscript
Go back to the users Don’t 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 doesn’t 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? Don’t forget sign-off
84
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, don’t 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 don’t 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.
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 don’t 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 they’re not kept up to date, then what’s 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
Chapter 9 • Implementing Playscript
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 showthrough 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, I’ve left those details to other writers. Most books on procedure writing have comprehensive sections on construction, and I particularly like the approach of d’Agenais & 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, don’t use tworing binders. I suggest three or four-ring, or, if you have the punching 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 it’s 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 you’ll be starting from behind.
85
Practical Playscript
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 Action by Claims Controller
Using an asterisk to indicate a change Step Action performed ----------------23.
ADVISE the Insurer of the claim.
* 24.
ESTABLISH the Insurer’s requirements for lodging the claim.
* 25.
ARRANGE for an assessor to visit the client. -----------------
Figure 9.2 Action by
86
Claims Controller
Using a vertical line to indicate a change Step Action performed ----------------23.
ADVISE the Insurer of the claim.
24.
ESTABLISH the Insurer’s requirements for lodging the claim.
25.
ARRANGE for an assessor to visit the client. -----------------
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.
Chapter 9 • Implementing Playscript
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 don’t 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 today’s emphasis on reducing the use of paper, many organ isations may not accept this idea. I’m not making a strong point one way or the other. I’ve 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 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.
87
Practical Playscript
88
Appendix 1
Suggested Reading
A Practical Guide to Usability Testing Joseph P. Dumas and Janice C. Redish Intellect, Exeter, England, 1999 Achieving 100% Compliance of Policies and Procedures Stephen Butler Page Process Improvement Publishing, Ohio, 2000 Best Practices in Policies and Procedures Stephen Butler Page Process Improvement Publishing, Ohio, 2000 Business Policies & Procedures Handbook Stephen Butler Page Prentice-Hall, Englewood Cliffs, New Jersey, 1984 Comprehensible insurance documents: Plain English isn’t 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 d’Agenais & 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 Process Improvement Publishing, Ohio, 2002
89
Practical Playscript 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 Process Improvement Publishing, Ohio, 2001 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 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.
91
Practical Playscript
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 table—”take a coat and umbrella”. You wouldn’t 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? Is it wet?
YES YES
YES NO
NO YES
NO NO
Take coat Take umbrella
X X
X
CONDITIONS ACTIONS
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? Greater than 100 km trip? Tank Full? Buy petrol No action
1
2
3
4
Y X
Y
Y N X
N N N
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 FACTOR 1
Condition 1
Condition 2
WET
NOT WET
Take coat and umbrella
Take coat only
Take umbrella only
Leave coat and umbrella at home
FACTOR 2
COLD NOT COLD
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 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 yes’s and no’s for first condition Divide the number of rules in half; enter Y’s for the first half and N’s for the second half.
93
Practical Playscript
4. Enter yes’s and no’s for second condition Following the same pattern as above, divide the number of rules into 4; enter Y’s for the first quarter, N’s for the second quarter, Y’s for the third quarter and N’s for the last quarter. 5. Enter yes’s and no’s for the remainder of the conditions Continue in this way for each subsequent condition, halving the number of Y’s and N’s at each row so that the final row is a succession of alternating single Y’s and N’s. 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 x’s 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
94
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
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
X X X X X X X X X X
…
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
…
Calculate COD invoice Calculate credit invoice Post ledger Calculate discount Add discount to invoice Type invoice Produce delivery dockets Advise stock problem File order
… …
… … … … …
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.
Appendix 2 • Decision Tables
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 today’s stock level is irrelevant since they don’t have to be supplied yet. It is the stock level on the supply date that is important. Likewise, if they’re 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 …
-
-
-
Y Y N
N
Y
Y
N
N
-
-
-
- - - -
-
-
- …
-
-
-
Y N
-
Y
N
-
-
-
-
-
- - - -
-
-
- …
-
-
-
Discount applicable? Show discount on invoice? Calculate COD invoice Calculate credit invoice Post ledger Calculate discount Add discount to invoice Type invoice Produce delivery dockets Advise stock problem File order
-
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X 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.
95
Practical Playscript
Figure A2.6
Illustration of step 9 in completing a decision table 1
Revised Rule Numbers 2 3 4 5 6 7
8
Y Y Y Y Y
Y Y Y Y N
Y Y Y N -
N Y N -
N N -
Calculate credit invoice
X
X
X
Post ledger Calculate discount Add discount to invoice Type invoice Produce delivery dockets Advise stock problem File order
X X X X X
X X
X
X X
X X
X X
X
Account paid to date? Goods required today? Goods in stock? Discount applicable? Show discount on invoice?
Y Y N -
Y N -
Calculate COD invoice
96
N Y Y X
X 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. 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 = RULE 2 = RULE 3 = RULE 4 = RULE 5 = RULE 6 = RULE 7 = RULE 8 =
20 = 1 20 = 1 1 2 = 2 22 = 4 23 = 8 22 = 4 22 = 4 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.
Appendix 2 • Decision Tables
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
Account paid to date? Goods required today? Goods in stock? Discount applicable? Show discount on invoice? Calculate COD invoice Calculate credit invoice Post ledger Calculate discount Add discount to invoice Type invoice Produce delivery dockets Acknowledge and file order
1
2
3
4
Y Y Y Y Y
Y Y Y Y N
Y Y Y N -
N Y Y X
X X X X X X
X X X
X X
X X
X X
ELSE
X X X
97
Practical Playscript
98
Appendix 3
Subject Index
action by column 24 not in Task Outline 41 action performed column 25 action verb 15 in Task Outline 42 active voice 55 actor action relationship 54 actor column 24 adjectives 50 administrative documentation 1 adverbs 50 aesthetics 70 agreement from Playscript method 15 alternative channels 35 alternatives 36 ambiguity 50, 91 ambiguous language 54 ambiguous words 50 analysis helped by Playscript 17 appointments 78 appropriate language 53 arguments 82 asking for advice 43 auditing 83 audit trail using Playscript 17 authorising signatures 52 average reading age 48 axe to grind 77 backbone of procedure 48 basic decision table 92 behaviour 76
Bell Telephone Laboratories 76 Ben Graham Corporation 17, 74 big words 53 binders 85 Blake Management Grid 3 blaming incompetence 77 block effective understanding 48 brainstorming 62 branching instructions defined 63 break points in procedure 31 brevity from Playscript 15 business systems analysts 2 change 82 introduction simplified 16 changes 86 changing format of Playscript 19 charting paper flow 74 checking drafts 83 choice questions 78 choices within a choice 38 circular letters 1 clause sequence 50, 54 clearance, legal and technical 69 clear start and finish 48 clerical errors 2 clerical work measurement 69 Clyde Jackson 47 codes in procedure manual 11 column headings 24 comb binding 85 Commission on Federal Paperwork 71
communication 70 effective 48 neglected 70 research 33 Communication Research Institute of Australia 16, 47 Complete Plain Words 51 complex choice situations 38 complex decision making 33 complexity of the procedures 64 computer analysts 53 computers 1 computer system jargon 53 computer systems 61 computer systems analysts 2 computer systems documentation 1 concepts 81 confusion 76 in procedures 48 contents 85 control 5 correctness 54 correspondence 41 covering up loopholes 53 creative thinking 62 CRIA 47 cross-referencing 17 cycle of work 31, 42 dangling modifiers 51 date of publishing 52 date of the procedure 21
99
Practical Playscript
100
decision-making point 33 decision making routines 33 decision table 40, 43, 91 layout 92 multiple conditions 92 definitions 52, 64 delay points in procedure 31 departmental classifications 53 functions lists 1 responsibilities 53 detailed instructions for one individual 53 dictionary habit 54 direct language 56 documentation 6 Documents To Manage By 19 draft preparation 62 draft procedures 57 drafts checked by users 83 duplication deleted 63 duplication of effort 17 Eagleson, Robert 50 editing 64 efficiency 2 electronic format 16 else rule 97 e-mail 42 empathy 47 lacking 51 encouraging revision 84 ending point 12 environment of worker 53 equipment efficiency 70 ergonomics 70 error messages in procedure manual 11 errors of omission 91 exceptions 37 exceptions handling 37 exchanging information 57 explaining the concepts 81 facial expression 76 filling in a form 52 final procedure 57, 64 finance department 83 finance industry 16 finding information in a manual 11 finding information using Playscript 15 first run 85 flag waving 53 Flesch Reading Ease Scale 49, 72 Flesch, Rudolph 49 flow charting 74 flow of work 2 focus groups 75 Fog Index 49, 72 follow the action 30, 60 foreign matter in the procedure 52
form completion details 43 filling 52 history file 11 number 21 seeing improvement 76 format changing 19 form-filling instructions 1 forms 33 finance industry 16 government 16 insurance industry 16 forms catalogues 1 Forms Under Control 48 frustration 76 function included in procedure 32 functions of a manual 5 future tense 55 gaining acceptance 83 gaps in the action sequence 32 getting your message across 47 glossaries in procedure manual 11 gobbledegook 54 Gowers, Sir Ernest 51 Goyen, Judith 49 grammar 48 grammatical correction 69 Gunning, Robert 49 heavy editing 64 hesitation 79 highlight exceptions 91 highlighting breaks 26 verbs 26 human behaviour 76 mind 62 human communication 33 human communication complexities 47 humanise systems 2 identify major functions 61 illogical thought sequence 51 implementation 81 improvement visible 76 incompetence blaming 77 indent side channels 34 indexing 85 procedures 21 index to manual 11 indirect language 56 indirectly affected users 83 Industrial Engineering 69 information copy 87 information finding using Playscript 15 information systems professionals 70 initial presentation 82 insecurity 77 instruction 5
instruction, changing 70 insurance industry 16 intent 48 interpretation 47 interpreting language in procedure 47 Intimidation 53 in-tray 42 introducing change 16 ISO paper sizes 19 Jackson, Clyde 47 jargon 51, 54 jellyfish approach 48 procedures 12 job finished 43 Judith Goyen 49 Keith London Systems Matrix 3 kidlish 48 labor unions 83 language 42, 53 appropriate 47 skills 48 slanted to one department 58 lawyers 50 layout form standards 20 leading respondent 77 Legal department 83 legal or technical clearance 69 legal reasons 2 length of sentences 54 line managers 4 linking procedures 16 literacy 49 logic 51, 91 logical thought processes 53 logo 20 long lines 41 long sentences 53 loopholes 53 machine people treated as 69 main work channel 42, 61 main work flow 61 major branch 36 major operational functions 61 mannerism 76 manual format 12 index 11 numbering 22 packaging 85 table of contents 11 margins 24 Matthies pronunciation 13 meaning 48 memos 1 middle management 5
Appendix 3 • Subject Index Milward 70 mind 62 mind unique 52 misread instruction 79 missed question 79 missing steps 42 mistrust 48, 83 misunderstandings 48 modifications of Playscript 19 modifiers 50 movement 70 multiple choice decisions 43 multiple choices 38 multiple decisions 40 multiple steps 35 multiple word meanings 50 narrative 12 format and training 17 new format for older procedures 64 nouns out of verbs 56 numbering 85 by department 22 by project 22 methods 22 number of procedure 21 objectives of procedure 10 objectives of work 60 observational study 76 aims 76 approach 76 choice questions 78 finish 80 first round 77 leading respondent 77 preparation 78 problems 77 reading aloud 79 size 77 talkative respondents 78 observing behaviour 77 form in action 79 office records 41 O&M 70 one-way communication 47 operatives 4 opinions 53, 77 opinion surveys 69 Organisation and Methods 70 organisation charts 1 origin of data 2 outline format 13 outline for writing 62 overall procedures first 61 overview of Playscript 14 packaging your manuals 85 page number 23
title 20 pages in a procedure 23 paper flow 70 charting 74 paper flow diagram 17 paper for manuals 85 paperwork elimination 74 reduction 72 U.S. Commission 71 passive voice 55 past tense 55 peak workload periods 67 people treating as machines 69 philosophy 53 plain language 48 planning 59 Playscript columns 23 forces brevity 15 in any organisation 17 overview 14 problems 14 procedure example 11 policy 13, 20 conformity to 65 defined 7 included in procedure 32 in procedure manuals 7 rewriting 65 statements 52 policy component 82 policy statements 1 political climate 64 politics 57 poor sentence structure 54 position specifications 1, 64 possibilities considered 63 problem exceptions 37 procedure 41, 59 date 21 defined 10 indexing 21 linkage made easy 16 number 21 objectives 10 starting point 30 subject 20 title 25 writing 62 procedures analysis 64 procedures analysts 2, 56 Production Control 83 professional writers 15 pronouns 51 proofreading 69 publishing dates 52
punctuation 55, 82 purposes 53 quality 73 questionnaire 38 questionnaire-design research 16 questionnaires 33 questions from users 83 questions in a form 33 rare problem exceptions 37 readability formulas 49, 69 reading age 48 aloud during testing 79 protocol 79 Reading Ease Yardstick 72 reading long lines 41 reference 5 regularly, what people mean 61 relationship between writer and users 81 research 33 research, questionnaire design 16 responsibilities established 56 responsibilities for work 15 responsibility clarified 15 retraining 70 review 5, 63 again 63 draft procedures 57 revision, encouraging 84 rewriting existing procedures 64 Robert Eagleson 50 Robert Gunning 49 role of manuals 2 rough draft 62 scanning local area 79 scopes 53 secret agendas 77 selectivity 61 self esteem 67 senior management 5 sentence length 54 structure 54 separate procedure 37 sequence of clauses 50 service approach 81 shared meaning 48 Shewhart, Walter 76 short sentences 55 short side channel 33 side channel 33 side channel for one person 33 side channels 42 signatures and initials 32 sign off 84 simplified writing with Playscript 15 skeleton of procedure 48 slanting language to one department 58
101
Practical Playscript
102
spacing between lines and steps 29 special cases 43 staff training 82 standard layout form 20 standard paper sizes 19 standards 1, 6 standards to be followed 43 start and end points 60 start and finish 48 starting point 12, 30 step-by-step approach 82 step-by-step time sequence 15 step number 25 straight-through sequence 82 structure of manual 13 of sentences 54 structure of the organisation 64 subconscious mind 62 subject categories 52 subject of procedure 20 subroutines 33, 42 subroutines defined 63 supervising staff training 82 supervisors 4 switching to separate procedure 37 switch to separate procedure 37 system description 13 narrative 11 objectives 8 systematic procedure writing 59 system description 2 systems analysis helped by Playscript 17 table of contents in manual 11 talkative respondents 78 task finished 43 task objectives 10 task-oriented procedures 53 Task Outline basic structure 41 defined 10 example 12 features 41 teaching users about a change 82 teaching users about a new procedure 82 team approach to writing 56 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
test the procedures 64 thought sequence 51 time sequence 15, 42 timing arrangements 43 title 25 training 70 helped by Playscript 17 supervision 82 trigger action 30, 42, 59 understanding 48 lack of 76 understanding clarified 82 uniform format 16 usability testing 39 U.S. Commission on Federal Paperwork 71 use active voice 55 use direct language 56 user help 84 verbs highlighted in procedure 26 turned into nouns 56 vocabulary 47 voice 55 waffle avoiding in discussion 17 what to include 42 word meaning 50 work channels identifying 30 work cycle 31, 42, 60 work environment 54 worker environment 53 work flow 61 in procedure 10 workflow 2 work mode 53 work mode of writing 63 work objectives 60 work responsibilities 15 World War II 70 Wright, Patricia 69, 72 writers professional 15 writing outline 62 writing simplified 15 writing style 47 Writing With Precision 49