Best Practices Documentation

by Pat Alexander on January 25, 2010 · 0 comments

I write a lot about how to define, train, implement and monitor best practices. In talking with agencies that I have worked with I find that one of their biggest challenges is determining the best way to publish their documentation and another is how to keep the information current. This article will discuss the following three topics which I believe address these issues:

1. What is the best way to publish our best practices?

2. How and when do we review and update our best practices?

3. Who edits our best practices?

Question Mark with Man.jpg

Let’s talk first about ways to publish your best practices documentation. You need to consider “How do I make this information the most user friendly possible for our staff?” The staff will not use the best practices information if it takes longer to find what they are looking for than just doing the process their old (own) way.

I always suggest a format that is in a searchable “help authoring tool”. There are a number of software products available for creating this type of documentation. I did two different Google searches to see what the current results are. I search first for “help authoring tools”. Such products as RoboHelp, DocToHelp and a number of others showed up in the search. Then I did “asp help authoring tools” search. In this search I found products such as HelpSmith.com and Helpauthoring.net along with others. Some of my clients decide that they will use Adobe .pdf or a Microsoft Word document. These documents are not as easily searchable as the help authoring tools but can work for you. I would suggest that you research various products to determine which format will work best for your staff.

Reviewing and updating your best practices is a continuous process. Earlier this year it was necessary to amend and update a section of a client’s best practices just a few weeks after that section had been defined and agreed upon. The agency management system vendor made a major change to the functionality for that particular process. Thus, what had just been defined needed to be re-defined, documented, trained and implemented as soon as possible. With older agency managements systems, changes don’t occur as frequently. However, in today’s world of newer developing systems, improvements and modifications to the systems are happening more frequently. Staying ahead of the research, defining, documentation, training and implementing phases are more challenging. Online agency management systems share information with their clients about the next release, however, until its actual release, it is difficult to know exactly what the functionality will be and what changes need to be made.

I have also seen a change to a process made on-the-spot during a conversation or meeting. When this happens, frequently there is not proper documentation or communication to everyone about the change. Each of these events cause confusion and a disintegration of the published best practices. When this occurs, people begin reverting to their own processes.

As you can see there are many occasions that will require a review and editing of your best practices. So who edits? In a recent conversation with some of my colleagues on this subject, they said that they thought the agency’s best practices should be in an open wiki that anyone in the agency can edit. Their basis for this comment is that the staff knows the quickest/simplest way to do all processes, thus they should define the processes and edit them. The definition of a wiki is:

A wiki is a website that uses wiki software, allowing the easy creation and editing of any number of interlinked Web pages, using a simplified markup language or a WYSIWYG text editor, within the browser. Wikis are often used to create collaborative websites, to power community websites, for personal note taking, in corporate intranets, and in knowledge management systems.

As you might imagine, I have a few issues with the self-define, self-edit program. Some of these are:

1. Usually each staff member has their own way of doing a process.

2. When there are such differing opinions on standards and processes, it seems someone would be overwriting in the wiki all the time to show their preference.

3. Will the wiki track what process was in effect at the time an errors & omissions claim questions that process?

4. If everyone is allowed to change a process at will, everyone will have to constantly check for the most current way to perform the process.

My colleagues let me know my ideas were old-fashioned and out-of-date. Well, of course that set me to thinking they might be correct. So I sought out the thinking of some other sources. I checked with insurance agent’s errors & omissions underwriters. This is the combined responses I received. Everyone agrees that those that do the work should help create the procedures, however, the standard best practices documentation should be available to staff in some unalterable format with traceable dates of publication. This creates a time certain during which the process was in place and insures that all employees, including managements are advised and are of the correct procedure at all times.

Now a properly set up wiki is highly searchable and very user friendly and would be as good a solution as the others discussed at the beginning of this article. However, this particular section of an agency’s wiki should not be editable by anyone except the same individuals that would have the authority to edit the other solutions. It is important that when there is a change to your best practices, that a new version be published with a new edition date. The recently retired version should be stored in a permanent location on your network. All previous versions should be retained in accordance with your document retention policy. In this way, you will have the needed documentation should there be questions about the process for an audit; an errors & omissions claim or other instances when you may need to refer back to prior versions.

Technorati Tags:

Previous post:

Next post: