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.
-----Original Message-----
From: Chantel Brathwaite
Sent: Wednesday, June 29, 2011 4:08 PM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Review Processes
>>>
How are reviews handled in your office? Who conducts the reviews and how much time do you typically give a reviewer? Do you have separate reviews for content and grammar/layout? Also, is your documentation reviewed/tested alongside other software or hardware artifacts?
Also, where is your tech writing department in the hierarchy of your company? (I'm asking because I think this sometimes impacts reviews and possibly the quality of reviews.) For example, is your department separate from others, are you part of the programming department, or are you grouped with the QA or marketing departments?
>>>
To start with the last question first, things have always worked best (for me) when the documentation group is part of the engineering team, with the same management representation as other engineers (all the peons need to report to a manager, and all those managers answer to the same manager). That means when you hand an issue up to your manager, they are on an equal level to discuss it with another manager. I've worked as a lone writer as part of a larger engineering team and in separate documentation groups that were part of the larger engineering team - same experience with both. And yes, it does impact getting reviews and also what happens when people don't review... when you're not part of the engineering team it seems like it is much easier to get flung under the bus when SMEs ignore you and don't review.
How reviews are handled depends on how the engineering is done. Lately, it seems to be more typical to have engineers working on portions of a project only and not as many "big picture" people, which means a lot of little reviews (send a PDF of the section they are an expert on ONLY, etc.). As for how to conduct the reviews, I am of the theory that I'm more than happy to have a different process for each SME. Seriously. If they respond best to PDFs in emails, great. If I need to hunt them down with a printed copy of something to get them to look at it, that is fine too. I also usually try to make reviewers know that they are free to review for grammar/layout/etc. if they want, but we are the Grammar Police and that is out job and we will do it (eventually).
Getting involved in the bug/defect system also makes a big difference. If something needs to change and you make the changes and then re-assign to someone for review and it sits there for a year, it's pretty easy to point to the detail that something was never reviewed.
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. http://www.doctohelp.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
