Published
In August’s newsletter, I mentioned that there is a distinction between quality assurance (QA) and quality control (QC). The difference between these terms is not merely semantic—it dramatically affects the way we work. QA is the processes and procedures that are put in place to make sure that work is done on time, to specification, within tolerances, and (hopefully) within budget. QC is checks to ensure that the work is done to specification and within tolerances. QC is done within a system of QA to make sure that the procedures and specifications result in successful projects. Simply put, QC should be the confirmation that QA is working.
Any work that helps with the creation of the product and its delivery should be managed through QA. Publishers should set up their own standards, procedures, tests for tolerances, and feedback loops. In addition to developing house style guides, they should put in place methods to ensure good processes from one project to the next, measure outcomes, and establish other standards. While it may be true that each manuscript requires distinctive attention, the process (including automated procedures for setup and cleanup) and standards should be consistent. Publishers should develop consistent methods to evaluate projects instead of incorrectly reacting to ad hoc situations. This is part of developing QA standards, which directly relate to a publisher’s imprint identity. After all, the discernible standards are what make one recognizable and distinctive, not to mention professional.
QC involves checks performed at critical junctures to verify that work is being done correctly. QC should be short processes that can gauge whether something is up to spec. The QC should involve a checklist that is developed to make sure that the work was done as it should be. QC should never be a full check through the content (i.e., it should not be a proofread). There should be immediately recognizable failure points that account for frequent errors and a feedback loop to inform those who worked on the manuscript of their errors, if any. QC should also rely on set processes that examine publications structurally and visually.
The QC should be performed at the conclusion of each major stage in the publishing chain to confirm that the work is to standard. Notes—on both successes and failures—should be maintained for all QCs. The QC notes should be provided to those performing the work (and overseen by managers responsible for consistent quality). If errors are detected or QC failed, the person who committed the errors should be responsible to redo his or her work. This helps catch current errors and prevents future ones. Again, QC is a process within a QA system and should be treated as such—not as a way to systematically correct errors.
The QC should be limited in scope and short in duration. As an example, Scribe performs QC at the end of composition (applying structure to the manuscript), copyediting, after the author’s review of the manuscript, typesetting, .sam export, and e-book conversion. QC is short (no more than 5 percent of the actual task) and done according to a checklist. We report all errors and deviation in our production system and regularly review them to detect patterns or places where efficiencies can be gained. When performance (in time and against tolerances) increases, we try to determine how to replicate improvement throughout our organization. When it slumps, we try to figure out how to reverse the trend.
With this in mind, let’s consider some of the time-consuming processes in the publishing chain and, whether work is done in-house or not, how to improve the process. Publishers often overlook the distinctions between QA and QC. They treat copyediting and proofreading as types of quality control. However, copyediting is actually a part of the service that publishers perform. They craft the language and set the contents (for electronic or print). Publishers may also develop art, design covers and interiors, create indexes, and perform other work to bring the publication to the market.
In typesetting, there are certain requirements to adhere to—for example, page numbers need to be sequential, running heads correct, typographical standards followed, pages balanced, and so on. When checking typesetting, it’s important to develop a proper systematic review of the files (not on a PDF, because you cannot detect systematic issues within them). Instead of visually checking files alone, the file should be checked to make sure that things are handled correctly (this is one of the reasons why the review of files is important). For components that are frequently incorrect or have limited variation (e.g., copyright information), templates should be set up so that what needs to examined and how much time is spent checking it is limited. And if at any point QC fails tolerances, the work should be immediately returned to the person who produced it. There should never be a full QC performed more than once; if something is not up to standard, it needs to be rejected and returned, but only when there is certainty that the work is capable of passing QC. Following this protocol is important because it saves time and ensures that the QC process actually catches errors. If the person performing QC has to run the process more than once, the likelihood of missing problems increases.
Proofreading is both a separate step in the publishing chain and a form of QC. It is a QC because it catches things that remain within the publication. However, it is a normal service because proofreading is based on the idea that there is a tolerable level of errors (those of grammar and format) that will reside in a book through the end. These errors should be due to the dynamic nature of the text throughout the process, not because things were missed in copyediting or typesetting (or in corresponding QCs). Proofreaders should work with specific guidelines, style sheets, and a knowledge of the editorial choices that were made. It is important that proofreading must never override the conscious decisions of the copyeditor: If the proofreader is making larger corrections, then he or she might be overriding legitimate choices. If the proofreader is catching a large number of “errors,” either the copyeditor did not do his or her work correctly or the QC process failed. No matter what, proofreading reports (usually in the form of corrections reports) should be reviewed with the copyeditors. The result of this review should be that the copyeditor’s attention be drawn to shortcomings of his or her work and that proofreaders should be apprised of conscious decisions made while editing.
No matter who we are, our ability to identify issues is limited. As humans, we are able to really only see one thing at a time. Thus if our attention is drawn to one error, we might miss another. It is also easier and more effective to correct errors in template files, master pages, or globally than it is to catch multiple instances of the same error. Thus if in the course of QC, errors outside of tolerance are caught, they need to be fixed before moving on. This ensures that future checks will be more thorough and that problems are handled efficiently. Often, we hear objections to this due to a limited schedule. However, in every test we have performed, the duration of projects (in both schedule and effort) increases when the rule we have established is broken.
Needless to state, it is important to perform QC on an entire project at the appropriate stage, not chunks of that project. Thus staggering projects is ill advised, since it is difficult to retain all the QC information throughout the project. It’s also problematic when one batch of work has been corrected but another batch has issues that haven’t been addressed.
The point of all this should be fairly clear: within the publishing chain, the work, outcome, methods of checking, and tolerances for each task need to be defined. The validation methods should be systematic and consistent to assure that errors are caught using the tools on hand. And a feedback loop should be created to make sure that mistakes are not repeated. The result of this process will be fewer errors and better publications—not to mention happier staff and authors.
David Rech founded Scribe in 1993, after being Director of External Services for the Center for Computer Analysis of Texts at the University of Pennsylvania. He teaches courses in Religious Studies at The College of New Jersey and is educated in classical history and languages.