Technical Writing in a Quality Management Environment

I was browsing through a long list of contract opportunities for technical writers on the Internet, when I spotted one from a manufacturing company looking for a documentation specialist. It stated that the perfect candidate would have “a working knowledge of TQC, TQM, ISO, QS9000, Kaizen, Gemba, and Hoshin.” If you read between the words, it was obvious that the company was desperately seeking a quality management program in their operations, but had no idea what they wanted! They certainly hadn’t left out many titles, but they had missed the concept of quality management.

A technical writer is indeed an excellent person to document a quality management program. Doing so requires excellent organizational skills, attention to detail, an understanding of business processes, exceptional information-gathering skills, and an ability to translate researched information into useable documents. But, just what is “quality management?” And what does documenting a quality management program involve? This article examines the concept of quality management and describes a ten-phase general process for documenting a quality program. Although this article does not attempt to cover all aspects of documenting a quality program, it aims to

  • Help you determine whether such a project might be of interest to you
  • Help you understand the scope of such a project
  • Help you understand potential obstacles you might encounter
  • Help you understand the types of documents you might develop for such a project
  • Help provide a starting point for finding out more

With that, let’s take a look….

The Concept of Quality Management

Quality management means providing for our customer’s needs in a way that ensures the services or products they receive are the best we can deliver, every time. There are many different methods for achieving quality management within an organization: ISO, Total Quality Control (TQC), Total Quality Management (TQM), Six Sigma, Hoshin, Kaizen, Best Practices, Quality Function Deployment (QFD), and many more.

Although each method has different techniques, tools, and structures, they all have a common purpose: Providing a comprehensive and fundamental strategy–or standards–aimed at continually improving performance by focusing on the needs of customers and all other stakeholders. You might think of standards as being the ruler for measuring the delivery of service or product.

For example, if you hired five professional chefs and told them to make an omelet, you would get five different omelets. If you develop accurate standards for the omelet, you will get five virtually identical omelets. Just because the chefs are experts doesn’t mean they know what you expect in terms of specifications, quality, and performance. In every industry, experts use standards to guide their performance. For example, professors teach to a curriculum, machinists create parts to specifications, and builders follow blueprints.

Standardization starts when every task, procedure, and operation is identified and documented so that anyone who has to perform those tasks will know how to achieve the established “standard of excellence.” This is the basis for the statement: “Say what you do, do what you said, check what you did, fix what you said.” The concept is that if everyone follows the standards and procedures, the products or service will always be the same. When a company establishes a quality management program, they are telling their customers that the products they produce or the services they deliver will be the same every time. Standardization does not necessarily mean that the product has high quality or is constantly being improved. It means that each instance of the product will be virtually the same.

Developing and Documenting a Quality Management Program

Planning and implementing a quality management program is not always easy. In some industries, standards are established and maintained by outside sources, such as American National Standards Institute (ANSI), Society of Automotive Engineers (SAE), Institute of Electrical and Electronics Engineers (IEEE), and other associations. Many organizations find that the best approach is to start with the standardization model and then modify the model to meet the needs of the business.

As a technical writer, you may or may not be involved in selecting a quality management program; however, you can indeed apply your research and analysis skills to the selection process, so take any opportunity to get involved in the selection process. At the very least, doing so will give you some say or knowledge about the documentation processes you will employ, using whatever program is selected. But, as a technical writer, your primary involvement will likely be documenting the processes and procedures within the organization. That is, you will research, document, and organize the processes, procedures, and tasks that–individually and in combination–contribute to the company delivering those quality products or services, every time.

The following sections outline the basic sequence of documenting a quality management program. These steps are particularly useful in an ISO style standardization program, but will work with other systems as well. Remember, these steps are not cast in stone, as they may not work in every project. And, keep in mind that, just because a method worked once, it may not work exactly the same way again, even if applied in similar circumstances. So, use these as a general guide for learning about quality management documentation processes, as well as a guide for adapting the general processes to an organization’s needs:

  1. Understand your role
  2. Get support from management
  3. Get support from workers
  4. Develop your own procedures and distribution system
  5. Research company operations
  6. Establish recording procedures
  7. Develop a master manual
  8. Research existing internal and external practices
  9. Develop the procedure and standards documents
  10. Test your work

Understand Your Role

Planning, designing, creating, and implementing a quality management program requires the combined effort of everyone within the organization, particularly within a project development team. Top management must actively and visibly support the project and ensure that it is implemented. Middle management must encourage research and development of standards and procedures, assisting the development team in obtaining information. Workers and teams that will be affected by the program must understand all of the concepts and be comfortable with them if the process is to succeed.

Technical writers are a key part of a quality management program. Most obviously, technical writers develop documentation that is used to improve processes and ensure quality products and services. As you’ll see in the following sections, documenting a quality program often involves developing a series of documents, including:

  • Resource documents, such as logs, forms, questionnaires, style guides, and other documents to help you record and document procedures
  • A master document that documents general company departments, their purposes, and their personnel
  • Procedure documents that provide step-by-step instructions for completing tasks
  • Standards documents that establish regulations, parameters, and rules

As part of developing such documents, we bring our ability to look at complex processes objectively, ask questions and gather the needed information, identify tasks that comprise the processes, and then distill the processes and tasks into clear and concise procedures. Whereas someone who performs tasks may have key knowledge, a technical writer can often better identify needed information, elicit that information, and then provide it in a way that meets users’ needs.

But in doing this job, we also act as a human liaison between management–which may be imposing the quality standard–and the people who must apply the quality standard. In this way, we can be key to ensuring the success of a quality program. As a bridge between the two sides, we can help management understand worker needs, and help those workers who perform tasks have a voice in how procedures are done. As technical writers documenting a quality system, we don’t have to just research and write; we can–and should–be key to helping foster communication and helping the quality program be a team effort.

Be careful, though, that you don’t get cast into a role that you can’t fulfill. It is not unusual for people to assume that, as a technical writer, you have extensive knowledge of organizational structures, development methods, and processes. If your knowledge in these areas is limited, for example, you may want to team with an experienced quality consultant or with someone within the organization who has such knowledge.

Get Support from Management

It is vitally important that management visibly support the quality program–throughout the entire process. Why? Without visible management support, developing and producing quality processes and documentation would be difficult at best. Communications with management and workers may be hindered. You may not get the information you need, when you need it. You may not get the required signatures on authorization documents. Without this support, you would likely design and produce a nice collection of documents that will gather dust on a shelf, usually at your desk.

If you are coming into a quality management project team as a technical writer, the support issue has probably been resolved. Your primary occupation will be researching, developing, and producing procedure documents. But, for example, if you are hired as a project manager charged with developing the program, you may not–yet–have visible management support. Begin by working with supportive managers to help others understand the need for the quality program. Then work with other managers–individually and in-person–to help them see how their knowledge and input contributes to the program’s success. Developing and documenting a quality system requires working with managers on an ongoing basis, so developing and fostering good relations and communication with them should be an ongoing, positive effort.

Get Support from Workers

When approaching the workers who carry out the tasks you’ll be documenting, you may find some opposition. For example, you may find it very difficult explaining that you are a technical writer who will be documenting procedures, not an efficiency expert who will be cutting jobs. You may find that people mistakenly assume that you are there to write down everything that they do so that they can be replaced by a machine or cheap labor. And you will certainly find that it’s really hard to get people to talk about what they do if they distrust your intentions!

Overcoming the stigma of “efficiency expert” is an important step in becoming comfortable writing for quality programs. Workers are the ones who know the processes and who can contribute valuable input on what works well and what needs to be improved–and how. In my experience, educating people about the purpose of a quality management system is key, as islistening to their concerns, needs, and suggestions.

To that end, I usually give a presentation that is short and lightly-delivered: I introduce the basic concepts of quality management and use supporting slides that are tailored to the audience. I then describe how their role as the “expert” is especially important, how they are the “owners” of the procedures, and how they are most likely to find ways of improving quality through the reduction of errors and complexity. I then conclude with a question and answer session, which not only helps answer their questions, but is a starting point to listening to their concerns and needs.

Develop Your Own Procedures and Distribution System

This is the fun part! The first procedures to develop are those that directly affect the way you do your information-gathering and documentation work. For example, you might:

  • Develop standards that include all font, layout, template, and methodology information
  • Develop a document layout that is both functional and acceptable according to other document standards
  • Design a document numbering system that will allow easy inventory and identification
  • Produce a style guide that describes these standards, as well as other grammar, usage, formatting, and style issues
  • Develop templates for documents you’ll create

Additionally at this point, you would devise (or at least start planning) some other documents that you’ll need, such as forms or questionnaires for gathering information, logs for recording and auditing processes, forms for recording process changes, and signature pages for process sign-offs. Often, you won’t develop these forms during this phase, but will do so as document needs become more apparent as you go through the next two phases.

Some or all of the documents you create may be used by others on the team, so you may need to make them available, yet protect them against uncontrolled changes. You could make them available in hardcopy, through an intranet, in PDF, or through a combination of these methods. You could even make them available in a word processing format used at the organization (Word or Star Office, for example) as long as the documents are change-protected.

In my experience, I’ve found that having an online repository for documents is the most effective method. Users can access them readily and, if they want, can print copies. If you choose this method, you might also include watermarks on the documents that indicate the online repository has the most current document version and that any hardcopy printed or circulated may be outdated. This would be particularly valuable in environments where standards and procedures change frequently.

Research Company Operations

Before you can accurately research and document standard practices, “best practices,” or any procedures, you have to understand how the company does business. By researching the company, you will be able to define the major processes, minor processes, and procedures covering the entire organization.

To begin, you analyze the business as a whole by gathering organization-related documents–descriptions, statements of purpose, general process documents, and charts that illustrate the hierarchical organization of departments, divisions, and teams. By doing so, you can begin to examine the organization’s structure, which usually breaks down into five or six major areas or processes. For example, a manufacturing company may include Engineering, Production, Sales, Shipping/Receiving, Finance, and Resources. Each division may also have distinct departments; for example, a “Resources” division may have Personnel, Warehouse, Physical Plant, and Payroll departments. “Warehouse,” then, may further break down into Purchasing, Inventory Control, Internal Supply, and External Orders.

Then, with that information in mind, you analyze individual jobs by obtaining or developing a list of all job titles and job descriptions within the company, including managers. If the company does not maintain official job descriptions, you should get this information from employees, by using, for example, a questionnaire or interview process to develop a job description for each title. A quick, effective way to do this is to have each person describe, in point form, the jobs they do on a daily basis. For example, a person in the warehouse may list the following in their job description:

  • I pick parts for internal orders
  • I pick parts and pack external orders for shipping
  • I unpack, verify, and stock incoming freight
  • I file incoming stock documents
  • I make stock additions and deletions on the computer
  • I empty garbage containers
  • I clean the floors

Then, match the list of jobs against your organization-related documents. Be careful not to confuse a task with a procedure or process. For example, emptying garbage containers and cleaning floors are tasks. They can be categorized under a process called “Maintaining a Safe Working Environment.” You will often find that people list jobs that you did not identify during your analysis of the operation of the company. By performing both a business analysis and a job analysis, you can identify the gaps.

This research and documentation procedure may take from four to eight weeks, depending on the size of the company and availability of information, but the outcome is very important, as it provides you with the basic structure for the quality management system. If you are thorough in your research, you will complete this phase having a list of titles and descriptions for major processes, minor processes, and procedures covering the entire operation.

Establish Recording Procedures

Developing documentation for a quality program is a complex process, to say the least, and you’ll need to ensure you adequately record the processes you’re documenting. A good recording system will provide a traceable trail in each activity that forms a record of performance and procedure from start to finish. The following suggestions outline some characteristics to strive for:

  • Start a records binder with monthly dividers for forms and logs. Although electronic files are a good recording format, a quality system still requires manual signatures, so you will have to keep paper records.
  • Ensure that all logs, forms, and so on serve a real purpose and have descriptive names. For example, develop forms such as “Request for Change or Corrective Action” and “Procedure Development Form” to record activities. Develop logs such as “Document Revision Log” and “Third Party Documentation Log” to record the occurrence and completion of form-supported activities.
  • Establish and document a change control process so that, as you develop documents, they are corrected periodically and are not in continuous revision.
  • Include minutes from all quality-related meetings, complete with meeting items, responsibilities, and due dates, so that you can validate the outcome in future meetings. This ensures that if people are required to provide information or perform some task between meetings, they know their duties and completion dates. Distribute the minutes to all affected personnel.

Then, use the logs, forms, and other documents that you develop. As you do so, you may need to adjust or reorganize them, but the key is to record procedures so that the information is centrally located, complete, and up-to-date.

Establish the Master Manual

The master manual describes–at a high level–the methods that are used to do business within a company. This is not intended to be a procedural or task-level document, but is actually a public document that is the high-level description of the quality program.

As a starting point, you should research any guidelines and templates available for the quality program you’re developing. For example, if you’re striving for ISO 9000 compliance, then you should consult the international ISO standards appropriate for your needs, and use an ISO template or guide document to provide structure and organization for the documentation you’ll be developing. From there, begin by filling in the information you collected about the company–its organizations, departments, and so on.

Exactly what the master manual includes will depend on the quality program and company. Your goal in this phase is to establish the master manual and to include high-level information about company processes and their purposes, based on the company research you already completed. Now, with a template and general company information, as well as forms and standards you need for collecting and documenting procedures, you can begin to research specific task-level procedures across the company.

Research Internal and External Practices

At last, you get to collect and document task-level procedures. In doing so, you shouldn’t just be re-documenting “official” procedures that are in dusty binders in a closet somewhere, documenting procedures that are actually used but aren’t as effective as they could be, or documenting procedures that are too complex to actually be used. Remember, a goal of a quality system is to provide procedures that are efficient and usable. Therefore, you need to research a variety of resources for your documentation:

Research “best practices” for the industry.  In some industries, “best practices” are established through years of input through societies or associations and are readily available. In other industries, there may not be any references to organized, established practices. Consult with organizations that support the company’s industry and find out what best practices have been established that may apply to the company.

Research existing procedure documents You will find that over time, people within a company have often developed documentation relating to processes and procedures, but they have never been applied. These documents are scattered in various locations, from local hard-drives to binders on a shelf. It takes considerable time and effort to locate all of these documents, but it is time well spent. The content of these documents often provides valuable information and the basis for establishing standards; however, use these documents as guides to your work, not necessarily as the definitive answer or procedures for a step.

Consult with the people who actually perform the tasks.  As mentioned earlier, the workers who complete the procedures are likely your best source of information; they often can tell you what works, what doesn’t work, what’s efficient, and what’s not. More importantly, they can often provide valuable information about how to improve a process, increase efficiency, and decrease waste.

Do the processes yourself, whenever possible.  Just as technical writers should use products they’re documenting, technical writers documenting a quality program should actually do the procedures they’re documenting. Of course, this may not always be possible, but doing so can help identify problems, can provide a new viewpoint, and can be integral to workingwith the workers who will ultimately perform the documented procedures.

As you’re researching these avenues, be sure to use the questionnaires, forms, and logs you developed and modify them as needed according to the procedures you encounter.

Develop the Procedure and Standards Documents

After you’ve researched, gathered, and recorded processes and procedures, you then develop procedure and standards documents, which are the definitive documents that describe and support the task procedures. Developing procedure documents is similar to developing other kinds of documentation. Often, the procedures will include descriptions, definitions, and illustrations as needed for the audience, and they will include sequential steps that complete a task.

Writing a standards document is a different process, in that you must be able to identify regulations, establish parameters, and set rules. This requires careful attention to information from the content experts and the ability to organize the information by content rather than sequence, as there are no steps. Using the ISO numbering system is one method you can use to categorize and organize information. This system generally uses the following structure:

1.0 Purpose
2.0 Scope
3.0 Definitions
4.0 Standards
5.0 Related Documents
6.0 Quality Records
7.0 Ownership and Approvals
8.0 Revision History

You can break each section into subsections containing specific information. For example, a standards document for system security might contain the following subsections:

4.0 Security Standards
4.1 General Security Standards
4.1.1 Statutory Warnings
4.1.2 Use of Passwords

4.2 Internet Use
4.2.1 Web Sites
4.2.2 USENET Newsgroups
4.2.3 Email Capabilities

This structure can be modified to include more sections or appendixes. Once you establish a structure, make sure that it is used in all documentation so that they have an identical “look and feel.” And finally, make sure to reflect any structural changes in your documentation standards, so there is a record of the changes.

Test Your Work

At this point, it would be easy to say, “my work here is done” and leave the content to the experts, but this can be a fatal mistake! Expert review of procedure documentation may ensure that the content is correct, but it does not ensure that the procedure works right. Take the time to apply the procedure in actual operations, not just in a dry run. You will often find errors or missing steps that the technical experts took for granted and assumed everyone knew. Following the test, hold a formal a review meeting to discuss the standards and make any necessary changes. Then, circulate a final copy for approval and sign-off by the workers who actually complete the procedures.

Your work here is still not done! Now, you should establish a schedule to review the standards and procedures at regular intervals to ensure that they are still accurate, up-to-date, and correct over time. All of this information must be recorded and filed for future auditing purposes and to leave an easy-to-follow, traceable history.


Having completed the process, you will have developed

  • Resource documents, such as logs, forms, questionnaires, style guides, and other documents to help you record and document procedures
  • A master document that documents general company departments, their purposes, and their personnel procedure documents
  • Procedure documents that provide step-by-step instructions for completing tasks
  • Standards documents that establish regulations, parameters, and rules

The phases and guidelines offered in this article are by no means complete, but they should give you an overview of the general process and help you determine the scope of such a project. Technical writers are excellent candidates for tackling such a project, as we have the skills necessary to develop the documentation and to act as a bridge between managers who are imposing a change and workers who must implement procedures. Documenting a quality program can apply and hone your skills and provide invaluable experience in a different field of technical documentation. Good luck!

Sponsored Posts

Interested in having a sponsored post on TechWhirl? Learn More >>

Subscribe to TechWhirl via Email