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:How to estimate documentation needs? From:Petko M <yzlpalypvhtc -at- spammotel -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Mon, 16 Feb 2009 11:04:38 +0200
Guys,
What would be your approach to estimating the documentation needs for somebody
who has developed a product but has no user documentation for it and has no
clear idea what this documentation should be?
As a freelancer, I currently have a prospect who fits the above description.
They have developed a product financed by grants from non-profit organizations
for the needs of some scientific circles. The product is a database engine
capable of fast searches that render highly-relevant results based on indexing
and some elements of artificial intelligence. They have no specific user
documentation for it but the system integrators for their clients so far have
somehow managed to cope using the development documentation. (These system
integrators are the actual users of the product.)
Now that the client wants to launch their product to the open market, they feel
they need some real user-oriented documentation but expect me to figure out what
it should be. I told them that I would need at least a month to get into the
specifics of their field and to familiarize myself with the product before I
could make a meaningful documentation proposal.
They agreed but were quite uneasy with the idea of having someone getting paid
for a month for just hanging around in their headquarters without producing
anything tangible. So I proposed to update their existing developer
documentation while reading it (some of this documentation, they told me, was
slightly out of date) and also to rewrite some documents from the user
perspective where this perspective is immediately clear to me.
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.)
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?
(Sure, this initial period is the most crucial part of a project since your
whole understanding of the product depends on it and the longer this period is
the better documentation will be produced, but surprisingly often this is quite
hard to grasp for the person who signs your paycheck and they insist on your
?becoming productive? as soon as possible.)
Petko M
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-
