Productivity Gains?

Subject: Productivity Gains?
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: Technical Writing <techwr-l -at- lists -dot- techwr-l -dot- com>, Allan Ackerson <alackerson -at- msn -dot- com>
Date: Wed, 28 Jan 2009 12:37:31 -0500

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.

* For a few thoughts:

Geoff Hart (
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
***Now available*** _Effective onscreen editing_


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.

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!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Please move off-topic discussions to the Chat list, at:


Productivity Gains?: From: Allan Ackerson

Previous by Author: How do I document vaporware?
Next by Author: I had say it because I was afraid no one else would?
Previous by Thread: Re: Productivity Gains?
Next by Thread: Re: Productivity Gains?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads