Before you take the first step toward creating internal documentation, stop and think about the big picture of what you want to accomplish. Ask yourself and others what size project your company has the resources to undertake—not only people resources, but also time resources. Two months before the launch of a major new product is not the time to undertake this kind of project. Planning could take a year or more, depending on the scope of your plan.

If you truly want to document all processes and information within your company, it could take a year or more to define, develop, test, verify and implement this project. Once you start looking, you’ll be surprised at how much there is to document.

A crucial element of this wide-angle look is to define—albeit broadly at this point—the project goals. What do you want the documentation to do? Shorten the ramp-up time for new employees? Document critical processes in the event that key people leave? Improve productivity? Ideally, the finished project will do all of this. However, if you want to keep the scope small, you’ll need to limit the goals to those that are most important.
In “How to get started on your company’s internal documentation,” we examined the importance of creating and maintaining comprehensive internal documentation on your company’s procedures and critical information. This week, we’ll see how to begin defining the information to document and discuss why such projects fail.
Limiting the scope of a project may also give you a better chance of success, especially if you expect to accomplish the job with existing staff. It might be a good idea to define the most critical processes to document, and then set out to accomplish and implement only those processes.

After doing so, evaluate the documentation process and results, and decide whether to continue the project. Of course, if you take the time to analyze the project, define its components, and make the resources available, you can make the project as comprehensive as you like.

Warning: The number one reason these projects fail
The reason I suggest keeping it small is because I don’t think people realize the degree of work involved in creating comprehensive internal documentation, much less updating and maintaining it. I’ve been involved in several knowledge-management documentation projects, and I’ve seen more than one fail, in that it ends up being so incomplete or obsolete that it doesn’t do anybody any good.

Without exception, the number one reason any of these projects fails is this: Someone in management decides it would be a good idea to document “all the company’s stuff” and assigns the project to someone else without considering the effort involved or getting input from those responsible for providing their time.

Basically, the reason for failure has two components:

The project isn’t well-defined: It seemed like a good idea, so the charge was begun. The processes and procedures to document are never analyzed, and there is little or no thought given to the information itself, its format, or how it will be utilized.

People aren’t on board: The decision was made without the input of the people who have to contribute a lot of their time to the project. In addition, people are not sold on the idea of the project (its benefits haven’t been expressed to them). So, the critical people don’t take the necessary time or make the effort, not because they’re slackers, but rather because they consider documentation to be their very lowest priority.

Obviously, the effort involved is by no means just on the part of the person or persons actually creating the documentation. To get any information that exists only in someone’s head, the documenter has to interview that person.

Obtaining the comprehensive, detailed information necessary for a successful project requires a lot of time from the person who has that information. So don’t think that you can just hire a consultant or team of consultants to undertake the documentation with no impact on your existing staff.

With this caveat out of the way, let’s start looking at the decisions you’ll want to make before embarking on your internal documentation project. The first one is to begin analyzing the content and scope of the project, which will affect the other decisions you need to make.

Get a handle on what needs to be documented
Start by making a rough outline of the information you want to document. A department-by-department approach can work well. Think of the key players in each department and their critical functions, then write that down.

To flesh out your notes, you may find it helpful to hold departmental brainstorming sessions with as many people from that department as is feasible. Before the meeting, send an e-mail memo with questions such as these:

What standard processes do you carry out on a regular basis?

What are the parts of your job that only you know how to do?

If you took a two-month vacation, what would the other people in your department need to know in order to fill in for you?

Also, look at these informal meetings as your first opportunity to sell your staff on the project, but don’t be surprised if a few people seem reluctant or threatened.

Unfortunately, some people don’t want anyone to know exactly what they do or how they do it. They regard the fact that only they know how to do their job as a way of keeping their job secure. People with this attitude are a major stumbling block in the information-gathering process, so you should make it clear that you expect people to share information.

Decide whether to use internal staff or consultants
Once you have a rough idea of the project scope, you’ll know the skill set necessary to carry it out. You can now decide whether to bring in outsiders to undertake the project, or to assign the project to existing staff.

This decision might be quite easy: If your company doesn’t have a dedicated technical writing team with time on their hands, you’ll need to look elsewhere.

If you already have technical writers but they’re busy, you might be able to free them up by adding to your staff. Make sure your existing writers know how to handle a project like this–process documentation and interviewing is a lot different from writing user manuals. You may want to supply them with books or even training on knowledge management.

If your technical writing team includes some folks with experience in knowledge management documentation, you might want to fill out the staff with contractors that you can release after the project. Doing so adds the personnel you need on a temporary basis, but keeps control and direction of the project within your company. Once you account for the need to keep the documentation current, hiring permanent staff may be the way to go.

If you don’t have a technical writing team, don’t make the mistake of assuming that someone currently in your organization can take on a project like this. Although an experienced knowledge-management consultant isn’t a requirement, you do need someone who’s already skilled in process documentation and who knows how to organize and pace large projects.

Whether you decide to use consultants or in-house staff, if your company is sizable and you’re serious about knowledge management, you’ll want to have at least one person dedicated to this project both during and after its initial completion. If you use a consultant or consultants, you may want to team that person up with one of your internal writers who can take on the job of maintaining the documentation.
What have been the greatest barriers to knowledge management in your enterprise? Post your comments or send us an e-mail.