It’s rare when I don’t hear complaints about the technical editing and reviewing of documents and the QA cycle in general. It’s unfortunate because building a document QA process that’s supportable and replicable

Here are some considerations to keep in mind when building a technical editing and QA cycle for your documents:

Establish standards and styles

Technical editing is about standards — you need to put some document writing standards and styles in place if even informally. Writing a style guide can be a major commitment.

Set expectations for document reviews

I always recommend that organizations set expectations for technical editing and reviews. With today’s harried schedules, my recommendation is an iterative review cycle. Just give your reviewers expectations for the document at the end of each review pass.

Manage and use document templates

Microsoft Word documents can be both a boon and a drag on productivity. I recommend that you and your team both manage and use document templates for all your documentation. Managing templates includes documenting the styles writers should use; being responsive to any template issues, and promoting proper template usage.

Use document versioning and workflow

Use Microsoft SharePoint or some other online collaboration platform for document versioning and workflow adds security and transparency over the process that sending email back and forth cannot touch. You can always roll back documents to a previous version.

Have the editors use the technology

Anybody you task to edit your technical documentation needs to use the technology. Nothing can go further to discredit the technical editing of a document than changing the meaning of technical content and the out and out introduction of technical inaccuracies. While this may not always be feasible, being hands-on with technology is one thing I strongly recommend for all technical publications people because it helps them be more self-sufficient among other things.

Instill the importance of technical accuracy

Somewhere along the line, the myth that technical writers and editors don’t need to be technical somehow began to perpetuate itself. This tale is just not practical and wrong on so many levels especially in today’s down economy where all project team members have to carry their weight and then some.

Attention to technical accuracy throughout all phases of the technical editing and quality assurance process means no last-minute rush of having to edit where the editor has changed the technical meaning.

Develop a constructive dialog between editors and writers

Technical communications is a team effort whether it is publishing a user guide, technical article, and about any technical content. Neither the writer or editor is the last bastion of quality (or at least they shouldn’t be), so it is prudent to foster a constructive dialog during a technical editing and QA cycle.

Questions back and forth between the editor and the writer are a good thing. You want them to resolve issues upfront that leads to changes in technical accuracy in the document.

Manage and take ownership of the process. Locking a technical document up in an endless review cycle doesn’t do the document or the team any good. Build a transparent process that is easy for all participants to follow does wonders for putting out a quality document.

My name is Will Kelly. I’m a technical writer and content strategist living and working in the Washington, DC area. My current focus is thought leadership and technical marketing content. I got my start writing user guides, administrator documentation, online help, and later moved into SDLC documentation. My articles about enterprise mobility, BYOD, and other technology topics have been published by IBM Mobile Business Insights, Samsung Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.