TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: How do you ensure document quality? From:Steven Jong <stevefjong -at- comcast -dot- net> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Fri, 14 Sep 2012 20:54:13 +0000 (UTC)
This is a topic I know something about, having studied documentation quality in the past and having retained my interest in it...
The original poster asked about ensuring documentation quality. Using the term correctly means that you want to look at the processes by which documents are produced (as opposed to editing and testing them afterwards). Two excellent general resources for this topic are Hackos's _Information Development_ and Hargis et al's _Developing Quality Technical Information_ (op cit).
In turn, "quality" can mean either the quality of the information product, which is the way we as practitioners tend to think of it, or the quality of the process, which is the way clients tend to think of it. (We like to produce masterpieces; our bosses like to get good stuff cheap.) It's possible to turn out an excellent product with a hideous level of effort (calling in contractors, working nights and weekends, an all-hands-on-deck final push), but it's not something you want to do regularly, and the boss doesn't want to see what should be routine delivery turn into a near-death experience! This need to balance efficiency with effectiveness results in conflict over, for example, whether to add the extra polish or ship it out on time with holes. So it's good to get a sense of which kind of quality you're interested in up front.
Even assuming we're talking about quality assurance (before) and product quality, some process considerations have an effect. For example, in most organizations, there either isn't a formal review and approval cycle, or it's not enforced. The result is products sometimes shipping without sufficient review and approval or maybe without review and approval at all. Or some writers send drafts to review and some don't. A formal review/approval process is Thing One to ensure quality. The metric for this is to plan and track the milestones for review and approval. Was the product reviews? Yes, and here's how many days it took. That adds QA, covers your butt, and gathers data useful for planning purposes. (For example, I can tell you with great, um, assurance how long it takes us to write release notes, and how long the document spends in each stage. It doesn't take me long to draft or produce them, but it takes a very long time to get them through review.)
Assuming you don't have it, Thing Two is a style sheet. Even if you're a lone writer, it's useful to jot down those design points you tend to forget. (For me, I can never do it consistently: in a bulleted list, do I introduce terms with a colon or a dash?) If you have two writers, you must have a style sheet or you'll find yourselves wasting effort over trivial feuds. (At one place I worked, when I did a release I fixed the period-space-space errors; when the next writer took over, she put them right back in.) Style sheets can cover much more important points, such as how procedures are presented. (Try having a contractor come in to work on a document with 100 procedures and do a few completely differently... 8^(
Thing Three is an editor, or a peer-editing process. One of the reviewers (you DO have reviewers, don't you?) should be an editor or a peer, or at least someone with a feel for the subject and a good eye. If you're lucky enough to have an editor you can get help from the design stage (developmental editing) right through to production. We tend to forget how important this is. (A good editor will immediately compile a style sheet...)
You can do other things, but their effectiveness drops off compared to these three. Quality is consistency; consistent, repeatable processes tend to deliver consistent quality.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
