Monday, September 3, 2007

Campbell - Chapter 1 Summary

Writing Effective Policies and Procedures: A Step-By-Step Resource for Clear Communication

Nancy J. Campbell

Chapter 1 - What’s a Policy, What’s a Procedure?

In Chapter 1 of Writing Effective Policies and Procedures: A Step-By-Step Resource for Clear Communication, Nancy Campbell begins by defining policies and procedures, and explaining why they are important. She goes on to describe the different forms and formats that policies and procedures may take within an organization. Throughout the chapter, practical tips are offered for crafting policies and procedures effectively, along with pitfalls to be avoided. She concludes with a summary of the chapter and some useful lists and tools for policy and procedure formation.

Campbell divides the content of the chapter into 8 main sections.

Why You Need Policies and Procedures

Policies and procedures provide users in an organization with the information they need to do their job, preventing chaos and frustration. They tell users “what the organization wants done, why it wants it done, and how to do it” (1).

Policies

Campbell defines policies as a form of position statement. As “clear, conscious decisions about its own standards and principles of operation,” policies are meant to guide organizational action (2).

Because policies cannot, and often should not, attempt to cover every conceivable organizational decision, they include some degree of ambiguity. Campbell lists 3 factors that influence the degree of ambiguity allowed for within a policy. These include: the ability of users to understand and cope with the policy, the manager’s competence with the policy and willingness to enforce it (which may necessitate additional training), and the way in which the organization views the issue and its importance.

Procedures

Procedures are “action oriented” and represent a “protocol for implementation, the ‘how to’.” (3). They outline steps in a process in order to effectively guide users through a given task. Procedures often describe consequences for noncompliance, such as damage, loss, injury, or discipline. These help to convey the seriousness of the issue and a users’ responsibility to comply.

Campbell illustrates the issue of ambiguity in policies by giving an example of a highly ambiguous policy. Procedures are typically less ambiguous than policies, but may still include ambiguous elements. This ambiguity may be necessary in order to allow for professional judgments on behalf of its users.

The amount of ambiguity contained within a procedure is a subjective decision on the part of its author. Campbell goes on to assert that total objectivity is an impossible goal, but good procedures should encourage users to exercise “sound business judgment” within the framework of the procedure set forth (5). This requires that policy and procedure writers determine what situations require subjective judgment, how much subjectivity is called for, and what standards or parameters should guide that judgment.

When You Need Policies and Procedures

Policies and procedures are a means to an end, and should serve to accomplish a specific purpose. They can often be a reactionary response to an unforeseen situation. In these cases, policy and procedure writers should pause to ask the following questions before they “jump into the writing fray:

· Has such an incident ever happened before?

· Is it really likely to happen again?

· Is this an isolated, once-every-twenty-years occurrence?

· Are the consequences of the mistake so serious (financially, legally, or operationally) that you need to be sure it never happens again? (6)”

Situations such as personnel, health, and safety demand clear policies and procedures. They are necessary in virtually any situation that is both important, and requires clarification.

Important issues are those that affect the audience or the organization. These can include:

· Efficient use of resources

· Schedules

· Customers

· Finances

· Image or reputation

· Health and safety

· Productivity

· Marketing

· Staffing

· Liability and other legalities

Users are impacted by any issue that affects “their personal circumstances or well-being,” such as:

· Benefits

· Hours

· Working conditions

· Job security

· Stress

· Satisfaction

· Status

· Personal principles

· Personal goals

· Family

In recognizing important issues, it is necessary to look at the issue from all perspectives, and never underestimate different interpretations.

Many important issues require the clarification which a policy or procedure provides. This is important when the subject is:

· Lengthy

· Complex

· Routine but essential for successful operations

· Affects the reader’s ability to function

· Affects the reader’s status

· Affects the reader’s personally

· Involves significant change or high volumes of change

Sometimes, people simply need a reference or reminder to help guide them through a particular process.

Written vs. Unwritten

In most cases, it would be impossible to document every decision and procedure that a person will be required to make when working for an organization. “Organizational culture, like dress and hygiene” is an example of a scenario often governed by unwritten rules. A topic should remain unwritten if it:

  • Involves organizational culture and norms
  • Cannot be enforced consistently
  • Could possibly be offensive or intrusive
  • Is simplified

Policies and procedures that are codified in writing should always reflect:

  • Accountability
  • Clarity
  • Consistency
  • Critical importance
  • Documentation
  • Health or safety
  • Legal liability
  • Licensing or regulatory requirements
  • Serious consequences

Often times, as an organization “grows, change increases, or complexity arises,” it is necessary to transform policies and procedures that were once unwritten into a written form.

Some reasons for doing so include:

  • Accidents
  • Changes
  • Complaints
  • Confusion
  • Cost overruns
  • New laws or regulations

What to Include in Policies and Procedures

As a policy and procedure writer, you need to make a judgment call as to what your audience needs to know, and what you want them to know. When uncertain as to what should be included, you can ask yourself two questions: “Who says so?” and “Why?”.

What Readers Want to Know

Readers of policies and procedures are interested in learning two things: what the policy or procedure will do FOR them, or TO them. It is important to identify with your reader by offering reasons for the policy or procedure and assigning responsibly for compliance. Campbell suggests you “use the writer’s motto: WIIFT…What’s in it for Them?”

Level of Detail

It can be challenging to determine the level of detail that a particular policy or procedure should include. It needs to be sufficient to accomplish its goals, yet remain appropriate to the subject and the audience. When dealing with complex subjects, one should take the experience level of the audience into account and perform a thorough audience analysis to help make good decisions concerning depth of detail.

Manuals and Handbooks

When dealing with multiple policies and procedures, for the sake of convenience it is common to combine them into a manual, handbook, or user guide. Campbell defines these products differently based on certain characteristics. A manual implies restricted circulation, while a handbook implies general distribution. By organizing policies and procedures into a logical structure, their creator will promote increased use among users, thereby increasing their overall effectiveness.

Chapter Summary (and Tools & Resources)

Campbell concludes with a summary of the chapter and several lists and tools that writers can use to create more effective policies and procedures.

Barker Chapter 1 - Understanding Task Orientation

Barker begins this chapter with a series of examples showing effective software documentation. He notes that these examples both explain and show the connections between the user’s professional work and the computer program. Scenarios, examples, and page layout can all contribute to this explanation, and according to Barker, any manual that helps the user manage and communicate information related to his or her task can be described as “task oriented.”

Barker then gives a detailed list of techniques to create a manual that helps users solve a complex task, including:
• Emphasizing problem solving – use introductory paragraphs that preview not only the steps to follow, but the goals and objectives of their software work.
• Providing task-oriented organization – Organize a manual or help system in a way that matches the kinds of tasks a user will perform.
• Encouraging user control of information – The manual should show users how to make key decisions, supply key information or determine key outputs (the user decides what the program does for them).
• Orienting pages semantically – Arrange the elements of the page meaningfully, according to elements of the job the user needs to perform.
• Facilitating both routine and complex tasks – Routine tasks include repeatable tasks that are easily represented by conventional procedures, while complex tasks are not performed the same way every time. The more you can help users apply software to complex tasks the more users will value your manual.
• Designing for users – Manuals should be designed for what the user needs and not from a template. User-drive design should allow users to find what they need, understand what they find, and use what they understand appropriately.
• Facilitating communication tasks – Communication tasks are defined as, “tasks that require the use and manipulation of information to coordinate workplace activities.” Document designers can help users see the why behind the program features by analyzing what kinds of information users need and how they communicate, and then identifying those program features.
• Encouraging user communities – Users often need encouragement to rely on other users of the program; task-oriented documentation encourages users to identify and get help from others.
• Supporting cognitive processing – The task-oriented manual uses principles of knowledge representation, parallelism and analogy to convey software features and applications to workplace tasks.

Next, Barker provides a definition of task orientation, stating that it is “a design strategy for software documentation that attempts to increase user knowledge of and application of a program by integrating the software with the user’s work environment.” He also states that exploring the theory behind task orientation can help with documentation design and provide a foundation for techniques discussed later in the book.

Barker goes on to describe both the default manual and user. The default manual has the following characteristics:
• Covers the features of the program
• Implicit role of technological ignorance imposed on the user
• Ignores the user’s workplace use of the program
• Assumes one way of learning
• Overly simplified approach to program operation
The default user has the following characteristics:
• Perceives job skills as decreasing in importance
• Sees computer use as separate from job goals Becomes isolated from other employees
• Fears remote supervision
• Suffers from information overload

Barker then notes that people often resist using computers and software because
of the inherent complexities of abstraction and information overload.

Next, Barker describes the characteristics of a task-oriented user, which include:
• Challenged by redefined work activities
• Conceptually oriented
• Aware of user communities
• Self-managing
• Supplied with resources

Barker continues the chapter by discussing the different forms of software
documentation, which include tutorial, procedural and reference. Tutorial documentation has the following characteristics:
• The user motivation is to learn
• Intention to teach the features of the program
• Relationship of teacher and learner
• Defines the task through scenarios, cases, examples; narrative structures
• Focus on basic actions
Procedural documentation has the following characteristics:
• The user motivation is to perform routine tasks
• Intention to guide through step-by-step procedures for using the program
• Relationship of guide and mentor
• Defines the task through chronological, step-by-step structures following the menu of choices or fields in a pane or screen
• Focus on operations organized around workplace actions
And, reference documentation has the following characteristics:
• The user motivation is to obtain information “about” the program
• Relationship of resource and client
• Lets the user define the task
• Focus on the program

Barker concludes the chapter by discussing the processes of software documentation. He says that to provide useful task-orientated documentation, one must look at the process of writing and find ways to learn about users. You don’t have to know the user if you are writing a default manual, but to have an effective task-oriented document, you must know the user. The process begins with the analyzing the users instead of the program. The process of writing and testing starts with the exploration of needs, and then requires constant involvement of the user. The process is called a usability process and is defined by the following stages:
• Planning Stages
o User interviews to find out what actions users take using the software
o Focus groups to find out user needs and organized constraints
• Development Stages
o User reviews to see how well the manual fits with workplace tasks
o User lab tests to gauge accuracy of manual and help information
o User field tests to gather additional information about workplace users
• Evaluation Stages
o User field evaluation to assess the overall value of documents
o User usage reports to help adjust writing and research processes for subsequent manual releases