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.
Subject:Re: How to estimate documentation needs? From:Ned Bedinger <doc -at- edwordsmith -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Tue, 17 Feb 2009 03:11:15 -0800
Petko M wrote:
<snip>
> Now, with regards to all this, I have two questions:
>
> 1. What would be your approach to estimating
> the documentation needs for such a
> prospect? (Of course, a lot depends on the
> specifics, but what I am asking here is about
> the general approach and guidelines.)
It sounds like they're expecting you to be familiar with this sort of
project and to do some sort of analysis, since they apparently aren't
going to break it down for you in ways that suggest roles, tasks, and
the other helpful information that a client (or tech communicator!)
would want or need.
Needs analysis is roughly what you are getting at, but most commonly
refers to financial needs analysis. In the context of scoping tech
writing projects, I use it in part to refer to my analysis of the
documentation and training needs of a target audience.
I think you could do needs analysis with a minimum of two things: an
understanding of the specific proficiencies needed to use the product,
and an understanding of proficiency level of your target audience
('users'). Think of it this way: The user's needs are what they don't
have but will need in order to use the product. They need it covered in
the documentation, in order to use the product. This defines what
documentation is needed.
If it sounds simple, remember that there could be more than one role
using this product, and potentially different documentation needs for
each role.
> 2. How do you handle the initial “non-productive” period when staring a new gig
> so that your client/boss does not get nervous waiting for your output?
On a short software project where they're not offering the writer time
to learn about the tech, my personal preference is to be scrupulously
sure I'm getting traction by the time I leave the interview. Then
there's no non-productive time after that--if I can do the project, I'll
be able to outline the documents based on what I learned in the
interview (good quality interview provides traction), and I'll be
filling in the outlines as soon as I begin billable work.
I don't BS around about this. I know what you mean, and I've been there
many times on a job where they sort of throw some stuff over the wall
and tell you to get busy, but I avoid it scrupulously if I can see it
coming. Reputation and references are too big a deal to risk taking just
any flakey assignment.
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
