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'd love some suggestions on how to affect the bottom line.
Caveat techwriter: Be aware that the following bears a superficial
resemblance to the rationale for outsourcing. If, by some sick twist of
fate, you devise a value-adding plan for documentation that lands on the
desk of a superficial manager, setting the wrong wheels in motion, YOYO (yer
on yer own).
You can find some discussion in the literature from professors at U of Wa.
IIRC, Reddish and Ramey are authors on papers about adding value through
technical writing.
In practice, it can be fairly easy to do. I'll give you an example from a
big IT organization. It may not be directly applicable if you don't support
dozens of 24x7 techs/analysts/administrators, but the principle is
bulletproof (in the business sense) and might kickstart some thinking about
how it could apply to your circumstances.
I had a project with a team of Sys Admins -- they're one of the 24x7 groups
who felt they were chronically overworked, and they conceived a plan to give
some of their work to a team lower down in the scheme of things. They had a
good business case for this plan, because the team that would become
responsible for the work was less-well paid than the Sys Admins.
I wasn't involved until later, but I suspect that there had been a
discussion about adding head-count to the Sys Admin team, and someone had
reasoned that adding a lesser-paid head would be more cost effective. By
the time I became involved, a plan had emerged: they wanted to document the
top 10 problems that Sys Admins spend their time on. The documentation
would be a thorough set of descriptions, diagnostics, and fix-it procedures.
It was no big thing for me to do, because the Sys Admins already had a web
site with some broken links and garbled notes about the problem descriptions
and the shell scripts they used. I took it all in and wrote it up in a
document. I drove it through several review cycles before it became final,
because they, like all expert-level workers, had a bunch of details stored
in their heads, and it took a while for me to coax it all out onto paper. I
facilitated that process by methodically breaking down each step of their
procedures into irreducible steps, and feeding any gaps I found back to the
Sys Admins for edification.
In the end, they handed off responsibility for the top 10 time consuming
problems to a less-well paid group. Et voila! Value added through
well-digested documentation. If it needs to be said, I was laid off shortly
thereafter. Don't know if my job was outsourced.
Ned Bedinger
Ed Wordsmith Technical Communications
doc -at- edwordsmith -dot- com http://www.edwordsmith.com
tel: 360-434-7197
