The Christchurch New Zealand Knowledge Management network meeting today featured a presentation from Ian Anderson entitled Policies and Procedures are ‘Special’ Knowledge Assets. Ian is one of the principals at Streamliners. There were about 6 people in attendance.

About Streamliners
Streamliners is a technical writing firm, with a main focus on online help for software, policies and procedures, and for installation manuals (for machines). The common thread is working your way through a myriad of information, and structuring it for a certain audience. The official qualification for technical writers is a degree or diploma in “Information Design”.

The driving factor for Ian is to help businesses give staff the information they need to get on with the job quickly. They don’t just want to deliver “lines on paper”.

Policies and Procedures
How are policies and procedures “special”? There’s a whole class of documents that are “disparate” … they are authored by many people in many applications, they require a document management system, and require taxonomy, training and librarians. Eg, operational reports, tools and templates, letters, contracts, white papers / reports, and project documents and forums. Policies and procedures, however, on the other hand, are different (examples include system documentation and user documentation). Distinguishing factors include:

• They are linked-up documents
• They represent the blueprints of the business, and best practice ways of doing things.
• Must go through the “eye of the needle” (careful review and signoff)
• Must be consistent in structure and style
• Must be easy to access and find

Features of an effective policy and procedure set:

• They are complete and identifiable. You should be able to “see the business” from a process perspective by looking at the collection of policies and procedures.
• They have a consistent writing style, structure and definitions / language / terminology. Eg, structured with rules, concise and familiar. Ian says he isn’t particularly keen on flow charts, because (a) the routing between decision points may only happen a couple of times, (b) the flowchart box leaves too little space for writing instructions, and more.
• Easy navigation and searchable.
• Clear ownership. Documents are owned by people. If they require scheduled reviews, the metadata is attached to the documents in some way. Streamliners generally use “roles” for owners, rather than a specific person.
• Systems for review and update. Eg, there’s a “feedback” button on each policy or procedure, which opens a form for feedback. The form is structured according to the specific needs of the client. For scheduled reviews, Streamliners has a reporting system for notifying document owners when a document is coming up for review.
• There should be online, offline and on-paper options. When a system is not available, critical system information should be accessible in other ways. Eg, in an emergency department at a hospital, if the system is offline, there need to be other ways of getting to the content. Some of the ways that Streamliners support this is to maintain a paper-based set of vital policies, and/or to deliver a version for small-form factor devices.

Often the work that Ian and his team do, is to take a document that is “technically correct”, and make it accessible for people to read. They break down difficult text and hard-to-understand language and distill it into an easy-to-follow and navigate document. Ian showed some examples.

How Do Technical Writers Work with their Audience?
The first step is to determine who the audience is, and how the content will be presented to them. Secondly, they try to generate a map of the processes and policy areas within the business, and how these link together. For each area, they try to determine what content is already in existence, and which areas still need to be developed. Step 3 if for existing content to go to technical writers for re-writing, and areas where there is no content, there is an interview and discovery process for understanding how things are done today, and to try to identify best practices.

Ian said that they generally do things using Author-IT, but they’re not wedded to it. Eg, if a client uses Lotus Notes, they’ll do it in there.

Questions
1. (Dan) What, if anything, should be in an electronic document management system?
(Ian) Everything else. Ian has no problem with the EDMS knowing about the policies and procedures set.

2. (Julian) I think there are some other differences. Eg, the life span of a policy or procedure is much longer than other things.
(Ian) Agreed; and they don’t “expire”, but rather evolve over time.
(Dan) Also, what about them being read more often than other types of documents?
(Julian) Using Dave Snowdon’s framework, policies and procedures are very much in the domain of the “known”. What’s the answer to “X”? We can see the one correct way of doing things. It’s not for things in the domain of the “knowable” or “complex”.
(Julian) Policies and procedures are like the “skeleton” of the organization; it supports all of the other activities in the business. The size of the skeleton in a specific business depends on how repeatable the processes are that make it up.

3. How do you balance benefit and the role of peer production? Eg, wikis.
(Dan) But this is good for dealing with the “unknown” aspects, that have to be created over time.
(Julian) Okay, but is there a case for using wikis within the organization for co-creating and updating policies and procedures?
() If you introduce the idea that policies and procedures are open to interpretation, you tend to introduce chaos.
(Nelly) If you follow the one on Monday, and then it’s different on Friday … you open yourself to doing the wrong thing.
(Dan) It depends on the type of the business, and what skeleton is required.
(Kevin) You could have a base set that everyone works from, and then have a wiki alongside for documenting new ideas. At various points, you could review the wiki contributions and accept certain things that make sense.
(Ian) Is the wiki the place for publishing the policy/procedure, or is it the place for discussion?
(Julian) And also, is peer production sufficient, or is a qualified technical writer required? I guess it depends on the situation.
(Ian) We see our role as technical writers, not subject matter experts. We usually deal with businesses with millions of dollars in revenue, and within these organizations, there needs to be a process owner who makes the final call.
(Julian) One of the government agencies has a very old document management system, which is compulsory to use, but it is extremely clunky. A few people found that if you went home and emailed yourself a blank Word document, you could save the document to your desktop, and then author documents locally and save locally. A definite work around.

4. How do you cope with the balance between policies and procedures and the natural inclination of people to hack systems and get around the accepted ways of doing things?
(Ian) If people are taking shortcuts and there is an accident, if there are accessible policies and procedures, there is little excuse. There are some definite performance management issues.
(Julian) Having the notion that there would be a help desk for policies and procedures is potentially a good thing, even if there role is just to point people back at the documentation.
(Ian) Sometimes build certification and questionnaires into the document set, in order to cultivate the idea that search is available for review.

5. You are talking about “all reference material”? Right?
(Ian) I don’t have a clear answer for that. It depends. Sometimes you can hyperlink to other things, but sometimes not. It’s a call on a client-by-client / situation-by-situation basis.

6. What are your views on “why?” Both (a) Why do we do it at all?, and (b) Why do we do it this way?
(Ian) This probably isn’t something that people want to see all the time, but if the material exists, we will often link to it. But you don’t want to clutter the policy with all of that. It leads to too much complexity and volume.
(Michael) Perhaps you could use a wiki as an adjunct to this, for capturing stories.
(Kevin) There’s two identifiable groups … technical writers want people to be able to follow things they do every day, and then also the people who write specific parts of the policy, they need to know the history of “why”. It’s the basis for re-writing the decision and seeking innovation.
(Phil) Often need a leadership role in the business, for someone to say “We used to do things like this 30 years ago, but it’s no longer relevant. We’re going to change.”

7. I see this as “just-in-time” delivery of information (find the answer now). Do you get involved in learning and development efforts?
(Ian) We frequently find that trainers want to use our technical writing for training courses. So, yes, we do. We often work with the trainers at the same time as writing the material.
(Julian) Or what about call centre staff who go through a scripted set of questions?
(Ian) We haven’t played there yet.

Conclusion
(Julian) Thanks much.
(Ian) I’ve learnt a lot.