Writing Sample #1
A project plan to create a documentation department for a new software product.
New Documentation Plan
This document outlines a proposed plan to create a technical documentation team for a new product launch. The plan anticipates these needs and expectations:
Team building – New hires – Onboarding and training
Team processes and procedures development
Team production capacity plan
Proposed outline of the new product documentation set
Working Assumptions and Requirements
The technical documentation plan for the new product is based on the following assumptions:
[Product Name] was developed in-house at [Company Name] rather than acquired
[Product Name] already has some preliminary marketing materials and development doc from Product Owners and Engineering
[Product Name] requires the creation of an entirely new documentation set
Forming a new documentation team dedicated to [Product Name] is required and approved
Using the existing technical writing tools, processes, procedures, and writing standards currently in place at the company as a baseline for building the new doc team is required
Adding the new documentation to the existing company web help and knowledge base sites is required
Documentation Team
HR has approved requisitions for three new technical writers to create the new product documentation. The proposed team consists of:
Sr Technical writer – 5+ years experience building and mentoring documentation teams
Sr Technical writer – 3+ years experience writing software documentation
Technical writer – 1 or more years experience as a technical writer
Onboarding
To enable the new documentation team’s rapid productivity, all three team members will participate in these duties and responsibilities:
Attend company new employee orientation – HR – 1 day
Receive laptops and tools setup assistance – Tech Docs – 2 days
Attend [Product Name] training classes (as available) – 3 days
Review (or help write) initial [Product Name] training materials – ongoing
Review [Product Name] marketing materials (as available) – ongoing
Review [Product Name] Engineering specifications – ongoing
Attend Tech Docs processes, procedures, standards, and tools training – ongoing
Analyze [Product Name] audience and documentation needs – ongoing
Conduct meetings with Product Owners and Engineering to determine the focus of their [Product Name] sprint teams – ongoing
Receive assignment to [Product Name] engineering scrum teams – within three weeks of start
Documentation Set
Based on initial input from Marketing and Support and the preliminary Engineering specifications from Product Owners, [Product Name] requires a new documentation set for the identified primary users. The expected delivery method is via content sourced on GitHub, published to the existing company web help site, knowledge base site, and downloadable PDFs:
Audience analysis
Businesses adding [Product Name] to their software systems tool set
Feature A – digital artifact discovery – any user with access to [Product Name]
Feature B – digital artifact options – any user with [Product Name] permissions
Installation, configuration, API, troubleshooting – IT Dev Ops
A new web help section dedicated to [Product Name] at:
What’s New – Product overview article
Main features and benefits
URLs to Getting Started or User Guide
Getting Started – 2 articles
Introduction to product feature A
Introduction to product feature B
User Guide – 2 sections
Main product feature A – artifact discovery – 3 articles
Main product feature B – artifact options – 3 articles
Reference
APIs
Errors and warnings
Training Guide – As required by [Company Name] Training
Baseline – uses the Getting Started guide
Enhancements per input from [Company Name] trainers – TBD
Release Notes – via standard [Company Name] download package
Setting Up – 4 sections
Components / Requirements – 1 article
Installation steps – 1 article
Configuration steps – 1 article
Troubleshooting – 1 article
How-To – 2 articles
Customization for cloud deployment
Customization for industry security compliance
Best Practices – As needed – TBD
Standards, Processes, and Procedures
To ensure a productive and successful documentation team, the essential processes and procedures include the following action items:
Establish ongoing communication with Product Owners and Development scrum teams about the [Company Name] development stories they are actively planning and working on
Weekly [Product Name] documentation team meetings, including story effort estimation
Bi-weekly feedback and end-of-spring story assessments from each writer
Story execution process – per sprint:
Description review (as a team)
Review Dev docs, Testrails, and QA notes assigned to each story
Draft new content or revise existing content
SME review
Peer review
Publish to web help site
Web help review, refinement, and regression testing
Refinement to the story execution process – ongoing
Estimated time to GA publication on company web help and knowledge base sites – 7 sprints
Production Capacity
To enable and scale the product documentation team’s production capacity, the team’s standard operating procedure requires all three team members to:
Attend product kick-off demos and company training focused on product usage
Assist with the documentation writing effort
Attend Engineering demos or end-of-sprint meetings that feature works on product features
Attend [Product Name] planning sessions with Product Owners focused on product features
Review the work of other team members as part of the documentation process
Understand and use the web help publication process
Participate in regression testing of the web help site
Measuring Success
Metrics to measure the success of the new product documentation set with company technical writers and customers include:
Sprint burndown reports – measures story completion and writer productivity
Sprint story completion – number of stories and total estimation points by individual writer and by team
Evaluation of article and topic helpfulness data based on thumbs up or down from the web help
Feedback and data collected from Support:
Tickets based on documentation gaps or errors
Tickets referring users back to the documentation
Direct customer feedback via a web form requesting the user to rate [Product Name] documentation or make improvement suggestions
Last updated