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

This chapter guides you through the process of planning documentation projects using the PADRE method (Purpose, Audience, Design, Review) for effective project execution. The chapter underscores the significance of planning in ensuring project success, particularly in Agile environments, and provides practical tools like checklists and templates. It emphasizes the need for proper planning to create a strong foundation for the success of your technical documentation projects.

Who Should Read This
• Aspiring Technical Writers • Beginner Technical Writers • Career Advancers • Managers of Technical Writers • Cross-Domain Professionals • Consultants
Table of Contents: Technical Writing Process
Previous: Chapter 9: Collect Information	Next: Chapter 11: Analyze Audience
Table of Contents: Project Management for Technical Writers
Previous: Chapter 3: Collect Information	Next: Chapter 5: Analyze Audience

1. Introduction

Ever felt like you’re embarking on a technical writing project with just a vague notion of what’s expected? You’re not alone. Many technical writers begin with minimal guidance and often dive into projects where even managers or organizations haven’t fully grasped the scope of the needed deliverables.

This is where it pays to make a plan. Plans aren’t just documents; they’re like contracts of expectations between you and your organization or client that outline precisely what’s to be delivered and when. Beyond that, they’re your tool for rallying support, gaining buy-in, and guiding stakeholders through the project’s journey.

In this chapter, we’ll guide you through the process of how to make a plan. To keep things manageable, we’ve provided options: a streamlined microplan and a more traditional, comprehensive Documentation Plan. We’ve also provided a tailored option for Agile projects.

Both approaches use our variation of the PAD (purpose, audience, design) method, which is a relatively new method that’s quickly becoming widespread. We call this the PADRE method: purpose, audience, design, and review. We’ve created templates for you to easily apply the PADRE method to your own documentation projects.

By following the instructions in this chapter, you’ll be able to select a planning approach that works best for both your project and your skill level. This will get your documentation project off to a flying start in the minimum possible time.

1.1. Do I Really Need a Plan?

Many technical writers feel the urge to show productivity straight away by diving straight into documenting. Does it really pay to plan? In fact, doesn’t the Agile Manifesto state, “Responding to change over following a plan”?¹ In short: Yes, it pays to plan, even in an Agile project. There are two reasons.

1. Planning creates consensus. Creating a plan is a great way to achieve consensus among your stakeholders on the assumptions you’ve made about your project. This reduces the likelihood of surprises later down the track—for example, if it turns out an assumption has been made that’s later proven to be incorrect. In this way, the process of arriving at a plan irons out many of the potential problems or misunderstandings that will inevitably arise later in the project.
2. Planning is linked to success. Studies on successful projects clearly show that more time spent planning leads to better results.² Having said that, as with any endeavor, it’s important to balance preparation and execution without going overboard and over-engineering things. That’s why we’ve provided options that range from essentials through to advanced for you to use when planning your projects.

As a writer, the pressure to get down to writing straight away can come from your own innate desire to quickly prove your value, or it can be imposed by others who only see the value in your final output rather than in the planning and preparation you put in behind the scenes. Remember that it pays to do a thorough—but not excessive—job in planning and preparation, and that it’s okay to diplomatically but firmly communicate that need to others.

Note

Planning for Agile Projects Agile projects generally have shorter development cycles, and priorities can quickly change as the product team iterates on features. Does it make sense to have a plan in this case? Absolutely yes! The very nature of Agile projects makes it difficult to keep track of what is being developed and when. Having a plan that shows how specific types of documents align with user stories and development sprints goes a long way in establishing trust in your technical writing process. In the case of Agile projects, your plan does not need to be extensive, so we’ve created a customized version of the plan template for you to use.

2. [Theory] The PADRE Method

The PAD method is a relatively new technique for planning technical documentation projects that’s rapidly gaining popularity.³ Why? Because it’s simple—and memorable! It boils down the essence of a technical writing project into three key dimensions: purpose, audience, and design of deliverables.

We’ve created our own version of the PAD method, complete with templates so that you can easily apply it. We call it the PADRE method because it incorporates an additional, but essential, element of planning: the review team. Defining a review team is critical. It’s only through a thorough review process that you can ensure your documentation is high quality and fit for use by its audience.

Here are the key elements of the PADRE method:

• Purpose: What the document aims to do.
• Audience: Who will read it and why they need it.
• Design: What the final documents will look like and when they will be ready.
• Review: Who will review and approve your documents to ensure quality and accuracy.

It doesn’t matter whether your project is straightforward or complex—the PADRE method still applies. It’s the core element in all our documentation plan templates.

Below is an example of the PADRE method in action, based on a fictional scenario: a technical writer developing a suite of documentation for an intra-operative medical device.

Purpose	The primary purpose of the documentation is to provide accurate and easily understandable instructions for surgeons to operate the intra-operative device and its connected software safely and effectively.
Audience	Primary Audience: The primary audience comprises surgeons who will be using the intra-operative device and its connected software during procedures in an operating theatre. Secondary Audience: The secondary audience includes nurses who assist the surgeon by preparing and holding the equipment during the procedure.
Design	The final output should include specific types of documentation tailored for both the primary and secondary audiences, each with its respective format and content. Primary Audience Deliverables: • A comprehensive user manual in PDF format for surgeons that details all functionalities, safety measures, and step-by-step procedures. • Interactive video tutorials that are accessible through a secure portal. Secondary Audience Deliverables: • A quick-start guide in laminated paper format to be kept in the operating theater, to aid nurses in preparing and holding the equipment. • Checklists for setup and maintenance to be included in the nurse training modules.
Review	This section details the teams responsible for reviewing the document for quality and accuracy. Reviewers: • Surgical team: Surgical procedures and medical terminology. • Nursing team: Equipment setup and nursing procedures. • Tech team: Software interface and connectivity. • Tech docs team: Adherence to best-practice document design. Approvers: • Quality team: Sarah Brown, Quality Manager • Medical board: Dr. Alan Watts, Board Chairman • Legal: Laura Williams, Legal Advisor

Note

The Ancient Roots of PAD The PAD method is a rhetorical analysis technique. Rhetoric is the art of effective communication and persuasion. It involves connecting with your audience in a way that encourages them to see things from your perspective. This is an essential skill for any technical writer! By connecting and empathizing with your audience, you enhance your ability to convey complex ideas. Although quite different from its original form, the PAD method has its origins in Aristotle’s teachings.4 Aristotle was a Greek philosopher who lived from 384–322 BCE and made significant contributions to numerous fields, including developing the concept of rhetoric.

3. [Practice] Make a Plan

The following steps take you through the process of making a plan that’s right for your project. Whether it’s straightforward, Agile, or a large, complex waterfall-style project, we’ve got you covered.

Note

Avoid a “Tick-the-Box” Mentality Try to avoid a tick-the-box mentality while you’re making your plan. Remember, the aim of a plan isn’t simply to populate a template. Creating a plan is how you arrive at a comprehensive understanding of what you’re supposed to be delivering, why you’re delivering it, and who you’re delivering it to.

3.1. Step 1. Choose the Right Plan for Your Project

The first step in making a plan is to select the plan that’s suitable for your project’s scope and complexity. To make your choice easier, we’ve developed customizable templates for several common scenarios.

Plan	Description	When To Use
Documentation Microplan Template	A streamlined alternative to traditional Documentation Plans, designed to quickly guide technical writers through the planning stages of a new documentation project. It uses the PADRE method to analyze purpose, audience, design of deliverables, and the review team responsible for ensuring quality and accuracy.	• When you anticipate a relatively straightforward project. • When you’ve been working at an organization for a while and all the usual stuff you’d put in a plan is by now ingrained knowledge. • When you just don’t have the time available to make a detailed plan.
Documentation Microplan Template for Agile Projects	A customized version of the microplan specifically tailored for Agile projects. It’s designed to align with Agile workflows and sprints, helping technical writers quickly navigate through the planning stages of a new documentation project.	• When you’re working on an Agile software development project.
Documentation Plan Template	A comprehensive planning tool that considers multiple variables in addition to PADRE to create a holistic, integrated plan. Similar to a Project Management Plan used by project managers but tailored for technical documentation projects.	• When you want to thoroughly plan for all contingencies in advance, including such things as review and approval responsibilities, lead times, dependencies, assumptions, and constraints. • When you have a more complex project with multiple deliverables. • When you’re unfamiliar with the context or organization and you need to thoroughly understand things before proceeding. • When you’re a consultant developing a scope of work for a client and you need everything thoroughly documented so it can form part of a contract.

3.2. Step 2. Leverage Your Initial Briefing with Your Manager

Your journey as a writer on a new project—or starting a new role—often begins with a one-on-one meeting between you and your manager. This initial briefing is generally set up by your manager, but if not, take the initiative and propose a meeting yourself. During this session, your manager will typically outline their vision for the documentation and provide a wealth of information about the project. You can expect to receive details about the project’s purpose, the key stakeholders involved, the expected timeline, and where to locate essential documents.

Use this meeting as an opportunity to ask questions. Your manager will expect you to be proactive in seeking clarification on any ambiguous points. Use the Briefing Checklist for Technical Writers as a prompt to make sure you’ve asked the right questions. Don’t expect your manager to be able to answer everything at once; you might need to gather this information over the course of several meetings.

Note

Importance of Notetaking Don’t underestimate the importance of taking detailed notes during this briefing. The volume of information shared can be overwhelming, and you’ll rely on these notes as the foundation of your plan. Be prepared with a notepad or your preferred digital notetaking method to jot down critical points discussed during the meeting.

3.3. Step 3. Develop Your Plan

Flesh out the details in your plan template. Start with your notes from the previous step—this will get you off to a flying start. Working through each of the following chapters in Part 4: Plan in sequence will result in a comprehensive plan that sets your documentation project up for success.

If you feel like you’re ready to tackle more advanced project planning techniques like estimating and scheduling, follow the steps below in sequence, then continue on to Chapter 13: Estimate Scope, Time, and Cost and Chapter 14: Develop Schedule.

Topic	Description
Chapter 9: Collect Information	Explains how and where to collect existing information to inform both your plan and your approach to writing. Provides guidance on important setup steps such as securing access to systems.
Chapter 10: Make a Plan	Explains how to consolidate all the information gathered—including the details you will develop in the following steps—into an integrated management plan for your documentation project.
Chapter 11: Analyze Audience	Explains how to analyze your documentation’s audience and break it down into primary, secondary, and hidden audiences so your documentation can be more effective.
Chapter 12: Define Review Team	Explains how to define a review team for documentation projects, an essential step in creating accurate and high-quality documentation.

3.4. Step 4. Refine Your Plan through Stakeholder Meetings

Set up a meeting or workshop with your stakeholders—the ones who have an interest in the documentation or those with whom you’ll need to consult in the writing and review phases. Use this meeting to refine the plan until you’re confident that it accurately captures everyone’s expectations about the project. You may require several meetings to get it fully nailed down. Aim for brevity—there’s no need for padding.

If you’re documenting a product, don’t forget to include the brand gatekeepers: product managers or the marketing team. Technical writers often tend to naturally affiliate themselves with the technical stakeholders, such as the engineering team, but it’s important to recognize the role of the nontechnical players in creating a product as well. Technical writing isn’t just about satisfying technical requirements; it’s also a branding exercise.

Tip

Engaging Stakeholders in Documentation Planning One of the hidden aspects of planning is the time required by subject matter experts and reviewers. Although it’s not normally costed into a project, it’s something you need to keep in mind because it can be a significant burden on the teams you’re working with. Going through the steps of negotiating and agreeing to a plan ensures that the teams you’re going to work with will be aware of—and hopefully supportive of—your future requests.

3.5. Step 5. Secure Approval for Your Plan

Before you proceed to the execution phase of your documentation project, it’s essential to get your plan officially approved by your manager and key stakeholders. Approval is critical, as it serves as a testament that all parties have reached a mutual understanding of the project’s scope, deliverables, and timelines. An approved plan acts as a protective measure and offers a reference point in case of future misunderstandings or disagreements regarding the project.

Additionally, obtaining a sign-off can re-engage stakeholders who may have been preoccupied, giving them the push that’s needed to refocus so they can finally commit to the project officially.

Steps for Securing Approval:

1. Prepare a final draft: Ensure that your plan is free from errors and ambiguities.
2. Circulate for feedback: Share the draft with stakeholders for any last-minute suggestions or corrections.
3. Request formal approval: Ask stakeholders for their official sign-off on the document. This could be a physical signature, an email confirmation, or an approval via a project management tool.
4. File the approved plan: Keep a copy of the signed plan in an easily accessible location, both for your reference and for audit purposes.

By following these guidelines, you can transition smoothly from the planning phase to the design, writing, and reviewing phases, with the confidence that everyone is aligned on the objectives and requirements.

4. [Template] Briefing Checklist for Technical Writers

Use the Briefing Checklist for Technical Writers to help ensure you’ve asked the right questions during your meetings and conversations with your manager and stakeholders. It’ll help you develop your plan.

5. [Template] Documentation Plan Template

Documentation Plan Template

6. [Template] Documentation Microplan Template

Documentation Microplan Template

7. [Template] Documentation Microplan Template for Agile Projects

Documentation Microplan Template for Agile Projects

1. Manifesto for Agile software development. (n.d.). https://agilemanifesto.org/ ↩︎
2. Zwikael, O. (2009). The relative importance of the PMBOK® Guide’s nine Knowledge Areas during project planning. Project Management Journal, 40(4), 94-103, p. 98. ↩︎
3. Weiss, J. S. (2022). PAD Beyond the Classroom: Integrating PAD in the Scrum Workplace (Doctoral dissertation, University of South Florida). ↩︎
4. Weiss, J. S. (2022). PAD Beyond the Classroom: Integrating PAD in the Scrum Workplace (Doctoral dissertation, University of South Florida). ↩︎