Lead Writer: Kieran Morgan | Peer Reviewer/s: Steve Moss | Managing Editor: Kieran Morgan

This chapter details the formation of a review team for technical documents. It highlights the importance of choosing the right mix of roles, such as approvers, editors, and subject matter experts. The chapter guides readers on organizing review processes and stakeholder involvement, featuring examples of review and approval matrices. Defining a review team early in the planning phase is essential for ensuring the accuracy, relevance, and quality of technical documents.

Who Should Read This
• Aspiring Technical Writers • Beginner Technical Writers • Career Advancers • Cross-Domain Professionals
Table of Contents: Technical Writing Process
Previous: Chapter 11: Analyze Audience	Next: Chapter 13: Design Structure
Table of Contents: Project Management for Technical Writers
Previous: Chapter 5: Analyze Audience	Next: Chapter 7: Estimate Scope, Time, and Cost

1. Introduction

“It’s frustrating when you can’t get someone to review your docs because they’re too busy. But if you give them a little nudge then they’ll usually do it. Don’t take it personally.”—Francis, Technical Writer

Ever felt the frustration of hanging in limbo, waiting for someone else to play their part? You’re not alone. Many of the writers we interviewed share this common plight. In technical writing, it’s wise to establish your review team at the outset of your project. The review phase often introduces an element of unpredictability. You might receive unexpected feedback leading to further revisions or come up against the challenge of involving overloaded stakeholders. Such hurdles can sidetrack even the most skilled writers. Many professionals we spoke with echoed this sentiment, citing review-related obstacles as a significant source of frustration.

Selecting the right review team is essential. This step ensures your work is not just accurate and high quality, but also resonates with the expectations of your stakeholders. Formal reviews serve as a testament to the rigor and governance your documents have undergone. These can vary from straightforward email approvals to more complex compliance with organizational document control policies.

This chapter will guide you in defining a review team as we highlight the typical roles and stakeholders involved in document review. We’ll also present an example of a well-structured review matrix. Defining the review team in the early stages of planning can significantly enhance the likelihood of your project’s success.

What Does That Mean?

Review The process of evaluating a document against quality standards such as technical accuracy, consistency with style manuals, templates, branding, and so on. Approval The formal acknowledgment or sign-off by an approver or document owner that a document is fit for publication.

2. [Theory] Who’s Who in a Review?

2.1. Generic Roles in a Review Team

The table below outlines the generic role names for participants in a document review. These role names represent broad categories of reviewers rather than specific job titles like engineering, product management, and so on.

Role	Definition
Approver	An authority with decision-making power on whether to endorse a document for the next phase, usually publication.
Document Owner	Holds responsibility for documents within a specific topic, like electrical engineering, software products, and so on. Usually also an approver.
Editor	Responsible for editing and proofreading the document. This role could be filled by the writer or someone more specialized.
Moderator / Curator	Acts as a gatekeeper reviewing content against organizational standards before publication.
Peer Reviewer	Reviews for adherence to writing and design principles, as well as organizational, team, local, or international standards. They often have substantial general knowledge of the organization and bring significant value to the review process. Peer reviewers are typically members of the technical documentation team or function.
Reviewer	A subject matter expert or stakeholder who uses their expertise to improve and validate the quality of a document through a review process.
Subject Matter Expert	An expert with deep domain knowledge in an area covered in the document, such as technical, marketing, product management, legal, and so on.
Writer	Responsible for orchestrating and executing the planning, designing, writing, review, approval, and publication of a document. Responsible for initiating review and approval requests.

2.2. Typical Stakeholders in a Document Review

This table outlines the usual stakeholders typically involved in a document review. It’s important to note that the precise makeup of the review team will always vary from one project to another. It’s not a “one size fits all” approach—it’s something you need to tailor for each project and document.

Stakeholder	Responsibility
Engineers / Developers	Ensuring technical accuracy and alignment with specifications. Verifying the accuracy of functionality and user interface as depicted in the documents. Making sure the content is appropriate for the intended audience/end users.
Intellectual Property	Proper acknowledgment of trademarks, including third-party ones. Correct assertion of copyright, trademarks, and other intellectual property rights.
Legal / Regulatory	Adherence to relevant regulations, laws, and standards, which may vary depending on the organization, industry, and geographical location. Ensuring the legal terms and conditions are accurate.
Marketing / Communications	Staying in line with company brand guidelines and the style guide. Using the correct branding elements (such as templates, logos, colors).
Process Owner	Verifying the accuracy of process flows in process-based documentation.
Product Managers	Ensuring alignment with product branding and naming conventions. Verifying the accuracy of the representation of product functionality and user interface in the documents. Assessing the suitability of the content for the audience/end users.
Project Manager / Project Sponsor	Ensuring alignment with project objectives and deadlines.
Quality Manager / Process Manager	Compliance with management system standards and templates.
Risk Management	Documenting any health and safety risks inherent in the product (such as sharp edges, small parts). Ensuring safety warnings are appropriately worded and displayed.
Writer’s Line Manager	Mentoring and coaching of writers through the provision of feedback. Quality check against expectations. Ensuring alignment with the writing team’s standards and style. Usage of the correct template.

3. [Practice] Define Review Team

Defining a review team is straightforward. Just follow the steps below, and use the review team section in your Documentation Plan Template to capture all the details.

Tip

Do Your Detective Work Before Diving In Defining a review team is a voyage of discovery, especially if you’re new to an organization. Instead of nominating who does what, it’s a process of investigating and discovering who the appropriate authorities are. In some organizations—particularly government departments—there are well-defined hierarchies of managers and strict procedures that you must follow. In others, such as those using Agile methodologies, this formality might go against the grain! It’s important to take the time to understand your organization’s culture before diving in.

3.1. Step 1: Identify Subject Matter Experts and Stakeholders

In the planning stages of your writing project, consult with your manager or project leader. Ask about who the subject matter experts (SMEs) and stakeholders are for your documentation. It’s key to understand their areas of expertise—for instance, whether they focus on product development or engineering—and their specific specializations within these fields. Figure out their priorities and check if they have any unique requirements or preferences, like needing a longer notice period for reviews.

Insight

Why Define a Review Team in the Planning Phase? Might it seem easier to wait until you’ve finished writing before tackling the review process? Actually, no. Defining your review team in advance helps you avoid the chaos of a poorly planned review and the havoc that can wreak on your project timeline. Doing so enables you to: • Provide busy subject matter experts with adequate notice about their roles as reviewers or approvers. • Guide subject matter experts to offer the most useful feedback, such as comments on technical accuracy, rather than critiques of your grammar and punctuation. • Establish a framework for the scope of reviews, ensuring everyone’s time is well-utilized. For example, you can ask legal reviewers to focus on legal and compliance issues instead of commenting on technical content. • Clarify your responsibilities as the writer. This makes it clear to everyone what you handle and highlights the value your expertise adds in managing the process. • Identify gatekeepers early in the process, ensuring that your review and approval workflow adheres to any specific protocols required.

3.2. Step 2: Classify Reviewers and Approvers

Identify who in your group needs to review the document and who the approvers are. Use the Review Matrix found in your Documentation Plan Template to categorize them accordingly.

Keep in mind, some stakeholders might take on dual roles as both reviewers and approvers. Typically, more senior stakeholders act as approvers, leaving the detailed document review to their less senior colleagues, who often have more time to dedicate to this task.

3.3. Step 3: Identify Lead Times and Sequence

This step is critical: you need to identify the lead times for your review team. Though document reviews might only take an hour or two, people usually need at least a few days’ notice to fit them into their busy schedules.

Also check if any parts of the review and approval process have to be done in sequence, like moving from junior to senior approvers. This is common in traditionally structured organizations, like government agencies, and can significantly extend your timeline.

Tip

Identify Gatekeeping In Advance It’s essential to identify any gatekeeping well in advance. Some teams, especially legal teams, are constantly inundated with document reviews and may only respond to formal requests. This could mean sending a document to a team inbox or submitting a request via a form on an intranet site. Teams like these often have lengthy lead-times they strictly adhere to and might not respond to requests sent through informal channels.

3.4. Step 4: Finalize Review Matrix

Finally, incorporate all this information into the review matrix in your Documentation Plan Template and review it for completeness. You might need to update this section as you progress. Sometimes you’ll find that the person nominated wasn’t the ideal choice or that they’ve moved on to another role or project.

4. [Sample] Sample Review Matrix

We’ve put together a sample review matrix below to give you a feel for how yours might look in your Documentation Plan. This example is set in a fictional scenario where a technical writer is crafting medical documentation.

Team	Name and Job Title	Contact Info	Review Focus Area	Lead Time (Business Days)
Surgical Team	Dr. Jane Smith, Lead Surgeon	[email protected]	Surgical procedures and medical terminology	5
Nursing Team	Emily Johnson, Nurse Coordinator	[email protected]	Equipment setup and nursing procedures	3
Legal	Laura Williams, Legal Advisor	[email protected]	Regulatory compliance	7
Tech Team	Mark Lee, Software Engineer	[email protected]	Software interface and connectivity	4

5. [Sample] Sample Approval Matrix

See the table below for what an approval matrix could look like in the same fictional project. Notice how the approval process is sequential in this example. While this approach ensures thorough review, it can significantly extend the overall project timeline.

Team	Name & Job Title	Contact Info	Approval Sequence (#)	Lead Time (Business Days)
Quality Team	Sarah Brown, Quality Manager	[email protected]	1	6
Medical Board	Dr. Alan Watts, Board Chairman	[email protected]	2	10
Legal	Laura Williams, Legal Advisor	[email protected]	3	7

6. [Template] Review Matrix in Documentation Plan Template

See the Review Matrix in the Documentation Plan Template.