The Newsletter of the STC Policies & Procedures Special Interest Group 4th Quarter 2006

 

10 Questions to Ask Before Developing Documentation for Business Processes, Policies, and Procedures

What do users want from their Policies, Processes, and Procedures? They want information that is: easy to access without endless searching; absolutely correct and up to date; and clear and concise.

Developing documentation is a process, not a task, and therefore requires planning and management. There are a few questions that you should ask before you start to develop your documentation.

1. Do your processes cross departments?

The beginning of any documentation process is to prepare a cross-functional process map. You should understand if processes cross departments (e.g. procure to pay) in order to fully understand the context of your content. Although you may only document part of the process, you will gain an understanding of the scope of a process. Furthermore, you will understand critical inputs, outputs, and control points.

2. Do you know the purpose of the content?

Policies, Processes, and Procedures dictate different types of content and, therefore, have different qualities and components. The purpose of the document is extremely important as it defines the potential audiences, end users, learning and work environment, and level of detail.

3. Do you know who your audience is?

Knowing your audience will determine how documentation is structured and written. There are different formats and styles used based on your audience. One size does not fit all. You must know the audience’s needs and wants, and the factors that will contribute to success - and to failure. Documentation must be intuitive for the audience. In addition, part of understanding the audience is knowing how and what they use for search criteria. This understanding highlights inconsistencies between audiences on terminology.

4. Do your content authors know the tools they are using?

Many times authors work within their respective areas of expertise but do not know the tools (i.e. authoring tools, best practices, interview techniques) needed to develop documentation. Having multiple authors is a major reason for inconsistency between documents. You should either train the authors on how to use the tools or hire experts who can develop the documentation better and more efficiently.

5. Do you have predefined templates for the different types of documentation?

Predefined formats not only make it easier for authors to create documentation but also make it easier to convert documentation to a Content Management System (CMS). Predefined formats make content categories consistent so users know the type of information contained in a document, furthering the requirement that documentation be intuitive.

6. Do you have consistent terms between all documents?

Consistency not only allows for easier access to and use of documents, but allows documents to be categorized and more easily moved to a CMS. Documents that use multiple terms when referring to one ‘thing’ cause great confusion for users. In addition, using consistent terms is the cornerstone for taxonomy development.

7. Do you set up review and approval individuals and teams?

Different types of content require different people or teams to review and approve it; for example, content requiring statutory controls (i.e. Sarbanes Oxley) has specific requirements, and the proper people will need to review it. Documentation that is not properly reviewed and approved will certainly be missing key information and, therefore, will not fulfill the Policy, Process, or Procedure purpose. Complex subjects and processes benefit by conducting a walk-thru early during the documentation process with those that are directly involved with the subject (i.e. users, authors, and technical). This allows for potential issues to be discussed and possibly resolved.

8. Do you test and verify your documentation?

A major reason documentation is not used is because it is incorrect. Documentation must be tested to verify that what is written is precisely correct. Testing must always be performed with the user in mind. Testing is not editing; it is a walk-thru of each step using the system, screen, report, or performing the task the documentation is addressing. Although this appears to be a time-consuming task, there is no other way to verify that the documentation is 100% correct. The time spent during testing will be quickly recovered with users not wasting their time deciphering incorrect documentation.

9. Do you use version controls for the documentation?

Documentation must be controlled to ensure correct versions are used. If there is no CMS, the documentation must still be controlled for future updates and access. Version control does not necessarily mean that all documentation is located in a central repository, but it does mean those who author documentation must know who controls it. Lack of version control causes authors to recreate documentation, causing redundancy. In addition, valuable knowledge is lost when existing documents cannot be used and referenced.

10. Do you have an implementation, distribution and training plan?

When your documentation has been completed, you must implement it and train users. Users must be trained in order to ensure the process is understood. In the event of revisions, you must be able to distribute and train on the new content. Part of implementation and training is change management, which enables the user to notify you of errors, omissions, and recommendations.

Preparing for Content Management

If your company is not currently using a content management system, it will probably utilize one in the future. Policies, Processes, and Procedures should be properly prepared before incorporating them into a CMS, as the system will not solve problems caused by poorly planned and prepared documentation. Addressing the creation and development of Policies, Processes, and Procedures as a process will advance you closer to documentation that is easy to access, and that is correct, intuitive, clear, and concise for the user.