So you’ve decided to embark on your internal documentation project. What formats and tools should you use to complete the task? How do you initiate, implement and maintain the project? In this article, we’ll take a look at how you should proceed.

Identify the best documentation format
During your department meetings to set the documentation scope, you should also have started to understand how people will use the information. From that, you decide on a format.

Although the document format to use for the project is one of the easiest things to change after the project begins, it’s best to settle on it up front. Here are a few choices:

  • Printed documentation: Having printed documentation can be a good idea if you will be documenting detailed or lengthy procedures. For printed matter you’ll need a central physical location or at least a “team library,” that everyone can access. You probably don’t want to rely on print alone if your procedures are constantly changing.
  • Online documentation: Online documentation can be better if the project is very modular. In other words, if all elements of it can be broken into fairly short pieces that don’t depend much on other pieces.
    This approach works well if much of the documentation will be accessed only occasionally, if the information changes often, or if the information needs to be further customized for use by any individuals or groups. If your company has an existing intranet, online documentation can be a good choice.
    However, the lack of an intranet can make it difficult to implement any documentation project that’s exclusively online. (Navigating a bunch of files without a user interface can make it difficult to find the needed information.)
  • Printed and online: Many companies use a mix of printed and online documentation. This can work well if the most frequently used and updated information is in the form of brief reference material. Anything that needs to be printed out, such as a checklist, can be easily done at a workstation. Longer, less changeable documents can be printed out and stored in a central location.

The first article in this series, “How to get started on your company’s internal documentation,” examined the importance of creating and maintaining comprehensive internal documentation on your company’s procedures and critical information. Last week’s article, “Internal documentation: Avoiding critical mistakes,” looked at the main reason internal documentation projects fail and discussed how to begin analyzing the information to document.
You should also take into account the way people at your company prefer to receive information. Some people don’t like to read anything longer than a few paragraphs onscreen, while others could read a book online. One benefit of online documentation is that it can easily be printed and read. That option can satisfy both camps, as long as it is designed to be legible on the page as well as the screen.

Choose your tools
Once you settle on a format, it’s time to tackle the question of the tools to use for creating the documentation. You can use anything that you think will work, but here are some that are common:

  • Microsoft Word: For print documentation, the default choice is generally Microsoft Word. Despite its many limitations, most people already know how to use it and it’s adequate for the job.
  • Adobe Acrobat: You may want to consider moving the Word documents into PDF format. This enables you to either print the PDF files or display them online.
  • HTML editor of choice: If you want to take the documentation online by posting to the company intranet, you should use the HTML editing program employed for the rest of your site. This familiarity will make it easier for both designers and users. Don’t forget that if you go this route, you’ll need to add Web designers to your list of necessary staff.
  • Version-control software: If more than one person has access and authority to update these documents, some type of version-control software is a must. Most IT companies are already familiar with Microsoft Visual SourceSafe, which is used for programming code. SourceSafe can be adapted to any kind of document to allow it to be checked in and out and to keep a record of who updates what.

Depending on the information you’re documenting, a database arrangement could also work well.
Here are a few of the better books that can help you with your documentation project:

Implementing the documentation within the company
When it comes time to implement the fruits of your labor, it’s crucial to let people know

  • What information is available.
  • Where to find it.
  • How to use it.

It’s surprising how many companies put an enormous amount of time and money into a project like this and then never bother making sure that their employees know it’s there. In some cases, a company-wide e-mail may be all the notification you need. In others, training on the new intranet, database, or online document library may be a more effective way to spread the word.

It isn’t over: Maintaining and updating your library
Finishing the documentation isn’t the end of the project. The information in your company is constantly changing and expanding and so should your documentation. Otherwise, it will slide into obsolescence, and all the hard work will be for nothing.

If internal staff completed the work, a smaller number of people should be tasked with maintaining it. If you had an outside consultant do the project, you could consider an ongoing agreement with that person, depending on how often the documents will need to be updated.

However, if you anticipate many changes, it would probably be more practical to assign the maintenance in-house. Consider asking your consultant to help train the person or people responsible.

Of course, the efforts at updating the documentation will succeed only if the people who hold that information keep the appropriate person or persons apprised of updates, additions, and changes—another good reason to keep the maintenance in-house. You need to make sure that key people in your organization know who the contact person is and that it’s their responsibility to approach that person as necessary.

If your point person is within the company, he or she will often know when a procedure changes and to update the corresponding document, but that person can’t anticipate everything.
What tools did you use to put together your internal documentation? Microsoft Word? HTML? Is your documentation stored on an intranet, or do employees have printouts? How many people are responsible for updating the project and how often? Send us an e-mail or post your comments below.