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.
Allan Ackerson wondered: <<Management here just popped us with an
annual requirement to show "productivity gains"! I can think of some
tweaks here and there which would make our operation leaner and
meaner, but as far as general document production goes, nothing comes
to mind that will meet the goals they want. Would anyone care to
share initiatives they used in similar circumstances?>>
<cues the music> "To dream, the impossible dream, ..." <g>
There's no good way to do this, but there are a few less sucky ways.
First, ask management what areas they see as problems so you can look
for specific solutions tailored to those problems. That will give you
maximum bang for your buck. (If they don't actually see any problems,
it's up to you whether it would be politically astute to ask them
"then what the frack are you trying to fix?")
One really good solution that you haven't a hope in Hades of
implementing would be the following: "If we made the interface more
intuitive (for example, by using user-centered design combined with
usability testing and by embedding help and affordances in the
interface), we could reduce the amount of documentation required by
20%. That would have obvious implications for productivity."
Other possibilities include creating a style guide that actually gets
used* and thereby reduces the amount of rework, using onscreen editing
to speed up and improve the quality of the review and revision
process, and finalizing design targets for the interface before anyone
actually begins programming. Having to repeatedly revise the
documentation to keep up with a changing interface, or having to wait
to the last possible instant to document the interface (once it's
frozen) is clearly unproductive -- never mind that it's considered a
"best practice" by development managers.
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-
