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: RE: Unsubstantiated and/or false allegations (was RE:Nobodyreviewedthe manuals) From:Steven Jong <stevefjong -at- comcast -dot- net> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Sat, 12 Jun 2010 13:43:58 -0400
There will be plenty of time to analyze all the things that went wrong in the Gulf. I have seen reports of several things that have a tech-comm angle. For one thing, when they initially tried to stop the leak, they did consult the procedure manual (I think the blowout-preventer manual), only to discover after several hours of trying that it was hopelessly outdated. (We are certainly familiar with what happens when you don't keep the documentation up to date, but we rarely hear a horror story this horrible!) For another, there have been reports that documented procedures that might have prevented the disaster were not followed. (Hence the loud argument the day of the explosion.)
I see this as a tremendous opportunity. Look at it this way: If a major corporation decides that a multi-billion dollar accident, plus all its attendant hideous negative publicity, criminal and civil fines, and possible executive jail time) could have been prevented, avoided, or mitigated through creating, maintaining, stocking, or using technical documentation, what do you think should happen--and WILL happen?
Now, the cynic will say that it doesn't matter if the documentation is perfect and up to date if it isn't posted, read, or followed. The cynic will also say the documentation probably wasn't right to begin with (not through the fault of the writer, of course, but through corporate neglect). So the cynic will ignore the opportunity and say that the corporation will conclude that nothing can be done that will work.
But cynicism by its very nature doesn't drive improvement, so I reject that view. No, I say the corporation--which someone in this thread pointed out exists to maximize profit, but also to minimize risk--will look at this and see, not that the manual was unwritten, unshipped, unread, or unfollowed, but that the corporation could have avoided BILLIONS in loss if only the manual HAD been written, shipped, read, and followed. It may be human nature to embrace the likelihood of routine outcomes and ignore the small possibility of disaster, but it's not in the oxymoronic corporate nature to ignore risk.
The right audience to hear the message that technical communication can reduce risk is not engineering vice presidents but the corporate counsels. But we can all help spread the word.
(There's a corollary I'll touch on briefly: we get bored writing mainstream procedures, and readers probably get bored reading them. But we can provide much more value if we also document things that could go wrong and how to avoid or fix them. Work with your support groups!)
-- Steve
Steven Jong ("Typo? What tpyo?")
SteveFJong -at- comcast -dot- net
978-413-2553 [C]
Home sweet home page: StevenJong.net
Gain access to everything you need to create and publish documentation,
manuals, and other information through multiple channels. Choose
authoring (and import) as well as virtually any output you may need. http://www.doctohelp.com/
- Use this space to communicate with TECHWR-L readers -
- Contact admin -at- techwr-l -dot- com for more information -
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
