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.
julie brodeur reports: <<I have a tight deadline coming up (12 working days)
in which to coordinate 4 inexperienced writers (they are technical experts,
not writers, but are writing due to the time constraint).>>
Sympathies. Bad deadline, bad situation.
<<Do any of you have recommendations on how I can make sure I get the
documentation from these "writers" in time for me to format and edit the
data? (And run it past reviewers and update it.)>>
I won't make any suggestions on scheduling; you know how long it'll take to
edit and perhaps rewrite from scratch, so count back from the deadline and
plan accordingly. The biggest problem will be figuring out the human
dynamics. If the writers are on your side, owe you favors, and are eager and
excited, the trick lies in harnessing this energy. If they'd rather be off
somewhere else programming, don't know you from Adam, resent the imposition,
and figure that they can play Solitaire for the next 2 weeks because they
report to someone else, then you need to enlist management support to get
them on your side.
<<I suggested they set a schedule like 4 topics a day to write, but they
seemed amused by this. :(>>
That might be unrealistic. One of them is bound to be a good writer, and
able to write 8 topics per day, while another might only squak out 2 topics
on a good day. What might work better is knowing that you have to accomplish
16 topics per day, and assign new ones as fast as the writers finish the old
ones; plus, give the toughest or longest topics to the most productive
Some of them will end up doing much more work as a result, and should be
compensated accordingly (at a minimum, with a good performance appraisal),
whereas the slower ones shouldn't be penalized in any way unless they're
intentionally dragging their heels; they're _not_ writers, and evaluating
them as if they were simply isn't fair. In either case, you'll need
management support to encourage them and to remove any obstacles to their
<<Their boss has already made it clear that I need their info by an earlier
date to make the final delivery date.>>
Ask him (diplomatically) what he's willing to do to make this happen. At a
minimum, he needs to make it clear that your deadlines are their deadlines,
and heads will roll (not!) if the deadlines aren't met. Ideally, he needs to
provide an incentive that motivates them to work hard.
<<Perhaps I need to do nothing but wait until a couple days before my
deadline for incorporating their data and pester them that their docs are
due to me in 2 days?>>
That's pretty much a recipe for disaster. You'll need to work with each of
them day by day to see how they're doing and to help them through any
problems they're encountering. (You also need to do this without getting in
their collective face.) Any problems you fix on Day 1 are problems they
won't repeat (forcing you to correct them repeatedly) each day until the
project's over. One useful thing to do is sit down with each of them with an
existing topic and explain why you wrote it the way you did (contents,
style, etc.). Leave them that example so they can try to emulate it.
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at http://www.ehelp.com/techwr
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.