TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Anthony wondered: <<How vague do you think one can be when writing an
Executive Summary and Project Plan for an operational documentation
project?>>
"Vague" is a loaded word. If you're going to be spending any time writing at
all, why would you do anything other than create a clear document that's as
accurate as it can be? Anything "vague" seems to me to be a waste of the
author's and the reader's time. Think of your purpose in writing, and plan
accordingly:
<<I'm working on a set of these right now against a short deadline to get my
current contract extended; however, I am having a devil of a time getting
technical details out of my contacts due to a software release which is
dominating their schedules.>>
In this case, your purpose is to get your contract extended. To do so, you
need to identify the key points your manager will use to justify keeping you
employed, then provide a compelling justification for each point. Obviously,
the more detail you can provide, the more convincing your argument will be.
<<My first instinct is to give a general description of the level of detail
I wish to deliver in the operational documentation, a list of areas to be
documented, point out that a more thorough study will need to be done to
deliver specific subjects, and turn it in as is.>>
That's all a good start. If you need specific details that you can't get
from your developer colleagues, use existing documentation as an example.
(For example: "Version 1 of the software required 10 writer-years to
produce. When my contract ends, the company will have only 9 writer-years
remaining, which means the current docs will take roughly 10% longer to
produce than the previous version.") In addition to providing more
believable figures for the manager, this also shows that you're working
within the company's existing concept of what the documentation should be.
Playing to their prejudices is always a good idea.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out the new release of RoboDemo, our easy-to-use tutorial software.
Plus, buy RoboHelp Office in August and save $100 with our mail-in rebate.
Get details and download free trial versions at http://www.ehelp.com/techwr-l
Acrobat & FrameMaker Seminars: PDF Best Practices, FrameMaker-to-Acrobat
Advanced Techniques, FM Template Design, Single Sourcing with FrameMaker
in Brussels (Oct), and in Montreal & Dallas (Dec): http://www.microtype.com/1
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
