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:FW: Documentation planning (was Re: FW: Extreme Technical Writing ) From:SIANNON -at- VISUS -dot- JNJ -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 10 Jan 2002 12:44:44
[Syed Ahmed writes a wonderfully detailed analysis which I'm snipping only
for brevity.]
Excellent posting, thank you! Just because I have a thing for restating
something to see if I understand it correctly, would you say this is an
accurate summary of the methods you described(?):
Given only a software application to work with, to start,
1 -- Use the "knowledge-gathering" phase to create a preliminary document
describing the functional design of the application.
2 -- Using the insights gained from the knowledge-gathering phase, propose
a standardized document set derived from industry standards for the
platform and development tools being used.
3 -- Use the proposed document set as the basis for discussion with both
development and business stakeholders to determine the expected
deliverables, and define scope and depth as applicable.
I'll have to agree with you that "tabula rasa" situations like that can
offer a nice creative stretch after dealing with a more confined and/or
tedious project. I *wish* I could have gotten the business and development
folks together early on in my initial project here, I think that would have
helped. I know that going out of my way to talk with business stakeholders
in later stages has helped tremendously. (Since I inherited some docs in
varying stages of usability, applicability and accuracy, much of my needs
analysis had to be done on the fly, while engaging in technoarchaeological
reconstruction.)
Debating whether a kamikaze visit
to the customer on one new project
might not be a good idea right about now,
Shauna
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Attention ForeHelp and Doc-to-Help Users! Upgrade your existing product to
RoboHelp for FREE, through January 15th. RoboHelp can import your existing
Help projects! Learn how else RoboHelp can benefit you. www.ehelp.com/techwr
---
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.