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.
Jeff asked:
"Does anyone have a list of examples of risks that are specifically related
to the technical writing field? I am making creating a risk assessment list
right now and want to make sure not to forget to include any types of
potential risks. My specific area is software documentation and related
technical documentation. I would be willing to provide a summary list of the
risks to TECHWR-L.
Thanks."
----------------------------------------------------------------------------
Jeff,
This is the current list of general requirements, assumptions and risks that
I have in my doc plans. I also add any specific problems I see on the
horizon. It's still a work in progress though:
ASSUMPTIONS:
-Any significant changes to the (name) application will be communicated to
the writer as soon as possible, and may affect the final delivery date.
-Any changes to the documentation plan will affect the final delivery date
and should be discussed.
REQUIREMENTS:
-The writer requires access throughout the project to a stable version of
the system that has been set up and configured to look and behave like the
system the typical primary end-user will have.
-The (name) team will provide the writer with documentation of any changes
to the project specification because they may affect the final
documentation.
-The writer requires a reasonable amount of access to SME's.
-For procedure validation, the writer will need access to an appropriate
individual to perform the procedures.
-For procedure validation, the writer and validator will need access to the
test system.
-The writer will be notified any changes that might impact the
documentation.
-The writer will be notified of any changes that might impact the project
schedule.
DEPENDENCIES & RISKS:
1. Availability of SME's
2. Availability of (Name) System
3. Timely communication of changes to the application.
4. Timely review and return of review copies.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check it out! Get some cool freebies when you buy RoboHelp! You'll receive
SnagIt screen capture software and a 10% discount voucher for RoboHelp
Consulting. This special offers expires March 29, 2002.
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.
