Setting expectations through the Doc Plan
•Als PPTX, PDF herunterladen•
1 gefällt mir•1,342 views
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.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Setting expectations through the Doc Plan
Ähnlich wie Setting expectations through the Doc Plan (20)
Mehr von Larry Kunz
Mehr von Larry Kunz (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Setting expectations through the Doc Plan
- 1. Managing UA projects Setting expectations through the Doc Plan Larry Kunz October 28, 2014 #writersua #techcomm
- 2. What we’ll cover today Oct 28, 2014 @larry_kunz • What’s a Doc Plan? • Why a Doc Plan? • Outline of the Doc Plan • Dos and Don’ts
- 3. Who Is the Project Manager? Oct 28, 2014 @larry_kunz
- 4. 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
- 5. Oct 28, 2014 @larry_kunz What’s a Doc Plan? A “very necessary evil” Alan Pringle & Sarah O’Keefe Technical Writing 101
- 6. 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 functions as a contract Image: Ralph F. Stitt [Public domain], via Wikimedia Commons
- 7. The Doc Plan outline Oct 28, 2014 @larry_kunz • Product description • Audience • Documentation products UA design }
- 8. The Doc Plan outline Oct 28, 2014 @larry_kunz • Product description • Audience • Documentation products • Work to be performed (tasks) • Contingencies (dependencies, receivables) • Assumptions • Budget • Schedule } UA design } Work plan
- 9. 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
- 10. 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
- 11. Documentation products • Description of all documentation, including the UA Oct 28, 2014 @larry_kunz – 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
- 12. 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 unit Purpose • Verify that all requirements are being addressed • Validate assumptions about estimates
- 13. 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
- 14. 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
- 15. 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)
- 16. 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
- 17. The Doc Plan Outline Tooltip help will Oct 28, 2014 @larry_kunz • Product description • Audience • Documentation products • Work to be performed (tasks) • Contingencies (dependencies, receivables) • Assumptions • Budget • Schedule be written using Javascript
- 18. The Doc Plan Outline Tooltip help will Oct 28, 2014 @larry_kunz • Product description • Audience • Documentation products • Work to be performed (tasks) • Contingencies (dependencies, receivables) • Assumptions • Budget • Schedule be written using Javascript
- 19. The Doc Plan Outline 50 Tooltip help strings will require 24 writer-hours Oct 28, 2014 @larry_kunz • Product description • Audience • Documentation products • Work to be performed (tasks) • Contingencies (dependencies, receivables) • Assumptions • Budget • Schedule
- 20. The Doc Plan Outline 50 Tooltip help strings will require 24 writer-hours Oct 28, 2014 @larry_kunz • Product description • Audience • Documentation products • Work to be performed (tasks) • Contingencies (dependencies, receivables) • Assumptions • Budget • Schedule
- 21. The Doc Plan Outline Writers will have a product prototype to work with Oct 28, 2014 @larry_kunz • Product description • Audience • Documentation products • Work to be performed (tasks) • Contingencies (dependencies, receivables) • Assumptions • Budget • Schedule
- 22. The Doc Plan Outline Writers will have a product prototype to work with Oct 28, 2014 @larry_kunz • Product description • Audience • Documentation products • Work to be performed (tasks) • Contingencies (dependencies, receivables) • Assumptions • Budget • Schedule
- 23. 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 as possible • Refer back to the Doc Plan as the project moves along
- 24. 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
- 25. 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
- 26. Oct 28, 2014 @larry_kunz Your Turn
- 27. Oct 28, 2014 @larry_kunz Stay in Touch! Larry Kunz Twitter: @larry_kunz larrykunz.wordpress.com lk81924@gmail.com
Hinweis der Redaktion
- A marriage – a friendship – any human endeavor… …Only works when everyone shares the same set of expectations
- Back in the day, we watched Ed Sullivan on Sundays This is what passed for entertainment The person on the right is pointing to the plates that need attention You’re the guy on the left, running around responding to the needs and keeping all the plates spinning The doc plan sets expectations Makes the plates spin better Keeps anyone from introducing new plates, unexpectedly
- The doc plan, also known as the project plan for the UA team For now, here’s a summary of the doc plan and why it matters This document, simply, describes: The design for the information (description of the deliverables) The work that will go into making the deliverables (the project plan) Spells out the responsibilities of everyone on the project Everyone = your team AND the other stakeholders e.g., “SMEs will provide reviews of docs between March 1 and 15” Your assumptions about the project are correct
- Creating a Doc Plan – and getting it reviewed and approved – might seem hard So hard, it’s not worth the bother Resist the temptation to bypass the doc plan and just start writing Pringle & O’Keefe call the doc plan a “very necessary evil” Wouldn’t it be easier to just start developing the UA and let the chips fall where they may? No – the Doc Plan is necessary It sets expectations It makes clear what your team needs It helps defuse conflicts later on
- As the Marx Brothers said: Why a Duck? Or Why a Doc Plan? The doc plan is your chance to make sure that: Everyone understands who’s doing what Everyone = your team AND the other stakeholders e.g., “SMEs will provide reviews of docs between March 1 and 15” Your assumptions about the project are correct And another reason the doc plan is important: It’s a contract between you and the other stakeholders As you manage the project, you need to be certain that: Your team members have everything they need Your team is delivering everything that’s expected of it You’re not going to be blamed if (when) things go wrong This “contract” will help ensure that those things happen Time and again I find that you can’t assume anything Even when you think that something is obvious to everyone… ….It usually turns out that it was obvious to no one but you Later we’ll cover all the various things you’ll need to put in the doc plan
- We want to validate our assumptions so that there are no surprises later That’s a common theme throughout the doc plan
- Now specifically describe the UA, not the product Also describe other documentation the end user will have access to ….So that the UA is couched in the context of the entire User Experience Also, enumerate the project requirements Define which ones are being met, and which ones are not “Requirements met” defines the project’s scope (Requirements not met are exclusions) This is the part of the Doc Plan where all requirements should be reflected… ….Even if only to identify some of them as exclusions (i.e., outside the scope) In this way, the whole project team has to buy off on your vision of the project’s scope
- Now we turn the corner From describing the UA and how it’s used To describing the internal processes and the work that goes into it
- Let’s do an exercise to see if you know where certain items would go
- This a description of the documentation (which includes the UA) It’s not a description of the product – that would be about the software itself It’s not an estimate of hours – just a statement of what’s included
- Second item in the exercise
- This is a description and sizing of the work to perform It’s not budget (which will include this, converted to dollars and rolled up with other items) It’s not schedule: it doesn’t show where this task fits into the overall plan
- Third item in the exercise
- Let’s do an exercise to see if you know where certain items would go (I wouldn’t mark you wrong if you said Assumptions)
- Best practices Include all relevant content If you’re not sure whether to include it, then include it OTOH every project is different Your doc plan won’t look exactly like my doc plan Don’t be a slave to some kind of template (even if it’s my template) Leave as little to chance as possible Don’t assume other stakeholders will be on board, unless it’s in writing Keep referring back to the Doc Plan as the project moves along The Doc Plan is the road map for the project team It tells them what to do, when, and how And as you manage the project, it helps you…. Remind other stakeholders of your requirements / contingencies Keep the work scope clear Resolve disputes Track the project against budgets & schedules
- Best practices / converse Don’t skip doing the doc plan (or parts of it) It might seem like an evil, but it’s a “very necessary evil” Without it, your project will go awry, expectations will go unmet, and conflict will occur Don’t assume that someone has all the answers Often, your doc plan will prompt questions – Like “Who is responsible for providing the software prototypes” – That no one has thought of, until you asked the question What happens then? Maybe you get to recommend the answer Don’t tolerate scope creep It’s easy to say, “Sure, we’ll help out with that” But remember to be loyal to your team: don’t saddle them with extra work
- Summary 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 Bottom line: it sets expectations equally, for the UA team and for all stakeholders
- Contact information