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.
I'm sorry I missed Jane's original post that you responded to, so this
may be out of context. If so, I apologize and offer an Emily Litella
The phrase "risk assessment" contains a land mine for tech writers
because it has two orthogonal meanings, and it is generally unclear
which is meant unless you ask pointed questions.
In an engineering context, risk assessment is a formal process in which
you analyze a product and tabulate what can go wrong, how likely it is
for each of those things to go wrong, and what the consequences are. In
the case of user documentation, having a page break between "push the
red button" and "after cutting the blue wire" would constitute a
low-probability, high-consequence risk.
In a business context, risk assessment has to do with financial business
risk--not environmental risk, the personal safety of product users, or
the health of factory workers making the product. If we release the
product two months later than planned, how much smaller will our market
share be? If we release it on time but without several key features, how
will that affect sales? In the case of user documentation, releasing
poor-quality docs on time is lower risk than releasing tested, edited,
commercially printed docs three weeks late--exactly the opposite of what
an engineering risk analysis would conclude.
The Big Problem is that when a project manager lists "risk analysis" as
a bullet point on a PowerPoint slide at a department meeting, you can't
tell whether the manager is wearing his engineering hat or his corporate
management hat. In fact, the manager may not know which sense of the
phrase applies; he may be listing a requirement from a corporate process
document and the manager may himself be misinterpreting the meaning.
So before you do anything relating to risk analysis, trace the
requirement back up the corporate tree as far as you can--preferably to
the source--and be sure you know which meaning applies before you
actually begin the work.
Jeff Allen wrote:
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.
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.
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.