setting expectations through the doc plan
DESCRIPTION
On any user-assistance or technical-communication project, the project plan - or Documentation Plan - is essential for aligning expectations of the documentation team and all other stakeholders. We explore the outline for the doc plan, the importance of the doc plan for validating your assumptions and for ensuring that your team will receive what it needs from other stakeholders, and a few best practices.TRANSCRIPT
Managing UA projects
Larry Kunz
October 28, 2014 #writersua #techcomm
Setting expectations through the Doc Plan
Oct 28, 2014@larry_kunz
What we’ll cover today
• What’s a Doc Plan?• Why a Doc Plan?• Outline of the Doc Plan• Dos and Don’ts
Oct 28, 2014@larry_kunz
Who Is the Project Manager?
Oct 28, 2014@larry_kunz
What’s a Doc Plan?
• Describes the design for the UA(and other documentation as well)
• Describes the work needed to develop the UA
• Defines the project’s scope• Spells out every stakeholder’s
responsibilities• Sets expectations
Oct 28, 2014@larry_kunz
What’s a Doc Plan?
A “very necessary evil”
Alan Pringle & Sarah O’KeefeTechnical Writing 101
Oct 28, 2014@larry_kunz
Why a Doc Plan?
• Get everyone’s understanding• Get everyone’s buy-in• Spell out assumptions /
contingencies
The Doc Plan functionsas a contract
Image: Ralph F. Stitt [Public domain], via Wikimedia Commons
Oct 28, 2014@larry_kunz
The Doc Plan outline
• Product description• Audience• Documentation products
UA design}
Oct 28, 2014@larry_kunz
The Doc Plan outline
• Product description• Audience• Documentation products• Work to be performed (tasks)• Contingencies
(dependencies, receivables)• Assumptions• Budget• Schedule
} UA design
} Workplan
Oct 28, 2014@larry_kunz
Product description
• Not just the UA – but the product of which the UA is a part
• What does it do?• What customer “pains” is it designed
to address?Purpose• Validate my assumptions about
audience and objectives
Oct 28, 2014@larry_kunz
Audience statement
• Who’ll use the UA?– Background– Objectives– Prior knowledge, etc.
• In what situations will they use it?Purpose• Validate the design of the UA
Oct 28, 2014@larry_kunz
Documentation products• Description of all documentation,
including the UA– Media – Audience– Tasks supported
• Description of how requirements are being satisfied (or not)
Purpose• Put the UA in context – as part of the
overall UX• Validate the project’s scope
Oct 28, 2014@larry_kunz
Tasks (work items)• Major units of work the UA team will
perform – for example:– Design & develop tooltip help for
Configuration Manager– Update HTML help system for Operator
Console
• Estimated effort for each major unitPurpose• Verify that all requirements are being
addressed• Validate assumptions about estimates
Oct 28, 2014@larry_kunz
Contingencies
Scope (Baseline)If your project is to succeed….• What really has to go right?• What do you need, and when?• Whose help do you need?• What schedule checkpoints depend
on other stakeholders?Purpose• Make all dependencies clear
Oct 28, 2014@larry_kunz
Assumptions
• The rules of the road, for example:– The tools we’ll use– The style guide we’ll use– Our process for draft reviews– How we’ll integrate the UA with product
builds
Purpose• Inform other stakeholders• Inform the UA team
Oct 28, 2014@larry_kunz
Budget
• How much I plan to spend on each major part of the project
Purpose• Secure necessary approvals• Form a basis for tracking
the project(along with schedule)
Oct 28, 2014@larry_kunz
Schedule
• How much time my team needs for each major task (work item)
• Checkpoints – for example:–When the first draft will be review ready–When everything will be translated
Purpose• Validate other stakeholders’
dependencies on me• (Again) form a basis for
tracking the project
Oct 28, 2014@larry_kunz
The Doc Plan Outline
• Product description• Audience• Documentation products• Work to be performed (tasks)• Contingencies
(dependencies, receivables)• Assumptions• Budget• Schedule
Tooltip help will be written
using Javascript
Oct 28, 2014@larry_kunz
The Doc Plan Outline
• Product description• Audience• Documentation products• Work to be performed (tasks)• Contingencies
(dependencies, receivables)• Assumptions• Budget• Schedule
Tooltip help will be written
using Javascript
Oct 28, 2014@larry_kunz
The Doc Plan Outline
• Product description• Audience• Documentation products• Work to be performed (tasks)• Contingencies
(dependencies, receivables)• Assumptions• Budget• Schedule
50 Tooltip help strings will require 24
writer-hours
Oct 28, 2014@larry_kunz
The Doc Plan Outline
• Product description• Audience• Documentation products• Work to be performed (tasks)• Contingencies
(dependencies, receivables)• Assumptions• Budget• Schedule
50 Tooltip help strings will require 24
writer-hours
Oct 28, 2014@larry_kunz
The Doc Plan Outline
• Product description• Audience• Documentation products• Work to be performed (tasks)• Contingencies
(dependencies, receivables)• Assumptions• Budget• Schedule
Writers willhave a product
prototype to work with
Oct 28, 2014@larry_kunz
The Doc Plan Outline
• Product description• Audience• Documentation products• Work to be performed (tasks)• Contingencies
(dependencies, receivables)• Assumptions• Budget• Schedule
Writers willhave a product
prototype to work with
Oct 28, 2014@larry_kunz
Do….• Include all relevant content–When in doubt, put it in– But don’t include content just
to fit some “template”
• Leave as little to chance aspossible
• Refer back to the Doc Planas the project moves along
Oct 28, 2014@larry_kunz
Don’t….
• Skip the doc plan (or parts of it)• Assume that someone has all the
answers• Tolerate scope creep
Oct 28, 2014@larry_kunz
The Doc Plan…
• Defines the project’s scope• Functions as a contract between you
and other stakeholders• Provides a road map for the UA team• Serves as a basis for tracking the
project
Oct 28, 2014@larry_kunz
Your Turn
Oct 28, 2014@larry_kunz
Stay in Touch!
Larry KunzTwitter: @larry_kunz
larrykunz.wordpress.com [email protected]