“Do I really need a tech writer?”

Well…no, actually.  But do you really want to do this nasty job yourself?

I’ve lost count of the number of people to whom I have offered my technical writing services, who look at me like I must be crazy. After all, they have smart people working for them…people who understand the content that needs to be written, who have great computer skills, who know how to write a sentence. Why would they pay someone from the outside to do what they could do themselves?

The only honest response I have come up with is: “Great! Enjoy the experience.” The truth is, these organizations probably do have people with skills, and with some effort they could probably turn out a  manual, procedure, or other document. However, further down the road they may wish they had brought in an expert.

Writing a manual or procedure is not simply the process of putting a series of steps into words. And a tech writer is not simply a person who writes sentences. Typically, a capable and experienced “technical communicator” (the correct description of the role) performs most of the following tasks in the process of producing documentation:  assesses the clients documentation needs, analyzes the content/tasks/etc to be documented, determines the scope of the project (especially if multiple documents are involved), gathers resources, identifies subject matter experts (SME), designs the document format and style, does research, writes the content, works with SMEs to verify and edit one or more drafts, publishes a final draft, maintains records, files, style guides, document plans, and many more aspects of the project. Throughout this process the technical communicator often assumes the role of project manager/leader and, if the project is large, may manage several personnel with specialized skills (illustrators, photographers, IT support, etc). If the project is smaller, most of these tasks still have to be handled at some level, and the person handling them needs to know how not to get bogged down in them.

So if you have someone who can handle these tasks, and you are willing to free the person up to become your in-house technical writer…good for you. But don’t expect that person to manage a documentation project AND do the job they were doing before. Something will break, and chances are you won’t end up with documentation at the level of quality that you had hoped for.

Access to SMEs a key ingredient in a successful project

One of the most important steps that a client can take to ensure the successful and timely completion of a writing project is to make sure the technical documentation team has good access to subject matter experts (SME). All SMEs needed for the project should be considered part of a resource team that meets periodically and is kept up-to-date on the project. If management takes the project seriously, and intends to make sure it is successful, they will communicate by word and example that attendance at these meetings is a high priority. They will also make sure that team members are allocated time to spend working with the documentation team and given clear instructions that they are expected to cooperate and support the tech writers’ efforts.

Ideally, the documentation team is able to spend adequate time on-site, working directly with the SMEs. Several factors must be in place to make sure on-site time is used effectively. The SMEs must be available, and know they are expected to cooperate. From the tech writer’s perspective, having full-time access to an SME who has a wide range of knowledge and experience would be ideal. Sometimes that is possible. For example, I have worked closely with an experienced plant operator who was on a work accommodation. Unfortunately, he was often pulled away from working with me to assist with other projects and situations as they arose.

It’s important to remember that one SME does not have all the answers. SMEs participate in several phases of the project. In the data gathering phase the doc team brings together information about the plant and how it is operated. This includes facts, specifications, how equipment and systems work, tasks and procedures. The next phase includes fact verification, but also verification of policies. A third phase–validation–involves confirmation that the document is acceptable. A plant operator may be able to answer questions about facts and procedures, but he or she probably cannot provide definitive rulings on operating policies. Those answers may have to come from supervisory or management staff. Sometimes there can be differences of opinion on best practices. Who makes the final ruling on what is the best practice for a given procedure? Who validates a procedure as complying with company policy? Without access to the appropriate SME the technical writer’s hands are tied.