Common approach to documentation?

Subject: Common approach to documentation?
From: "Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 27 Mar 2003 11:08:10 -0500


Andrew Simpson wonders: <<Has anybody got experience of trying to bring 2
separate authoring departments to a more common approach to documentation.>>

We have an office in Vancouver and one in Montreal, and can't seem to get
either to fully agree on working to the same standard. Seems to be a human
thing to want to put your own stamp on your efforts. That's not necessarily
a bad thing: different contexts require different solutions, and in our
context, you can't get much more different than Quebec French and B.C.
English. (Well, you can, of course, but you take my point.)

<<The company I work for recently merged with a US company. We now have 2
authoring departments; a small team in the US producing books for North
America & Canada, and a larger team in the UK doing the European / rest of
world books & world-wide translations.>>

Sounds like two very different contexts indeed!

<<An immediate problem has been the amount of documentation re-work involved
when taking the US products here in the UK and vice versa. The 2 departments
produce very different documents...>>

U.K./European language differs significantly from American/Canadian
language, so you'll inevitably encounter at least linguistic differences.
There may also be differences in the approach to documentation for the two
(or more) audiences. I'm not aware of these (haven't worked in the European
market yet), but would love to learn more about them if they exist.
Diversity is a wonderful thing, particularly if you take the time to learn
from it and harness its strength.

One thing to keep in mind: the underlying facts that you're trying to
present to the reader are mostly going to be the same (e.g., you print using
the Print menu option no matter which continent your readers are in). So one
thing everyone can agree upon right from the start is that you should
standardize the facts. Once that's done, let the local experts tailor the
presentation of those facts to their specific audiences.

<<... (exaggerated by the fact that one dept uses Framemaker, whilst the
other uses Pagemaker).>>

In a case like this, sometimes it makes an awful lot of sense to do your
authoring in a common package such as Word, which exports nicely to both
Frame and PM and offers really strong revision tracking and collaboration
tools. Once you've got the baseline material standardized in Word, the local
offices can customize it, which should take much less effort and time than
creating it in the first place. Once you have a localized version, move it
into Frame and PM for layout. You could try to insist on standardizing on
one tool at both locations (Frame is much stronger for large, international
efforts), but why bother? If both divisions have a solution that works, play
to that strength rather than fighting it.

<<I have tried to get a discussion going to look at what compromises can be
made and how we can move forward, but have met with stubborn resistance to
any change.>>

Part of this may be how you're selling the need for change. You have to
convince both teams that the benefits for them outweigh the drawbacks so
much that they should begin listening to you. The fear of change is a human
constant, and trying to force a change rarely works. Even with open-minded
colleagues, large-scale changes have to be phased in gradually if you want
to minimize the perceived and actual disruption, and thus, minimize the
resistance to change. A sharp, "all at once" change is often arguably more
efficient, but is much harder to sell and much harder to get working right
the first time. Plus, it leaves scars.

Getting people excited about embracing a change and allaying their fears are
the two keys to persuading them. Start your efforts with a focus on the
problems that annoy everyone (thus, whose solutions offer clear benefits),
and propose painless solutions to those problems (i.e., minimize the fear
and disruption components). Getting those affected by the change to propose
the means of the change empowers them, empowerment builds enthusiasm and
reduces fear, and the combination makes everyone much more willing to
change. Once you've achieved a few successes in this manner, everyone begins
to trust that the process of change will be less frightening and
uncomfortable than they once thought--and at that point, you have the power
to implement more difficult changes.

--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada

"Wisdom is one of the few things that look bigger the further away it
is."--Terry Pratchett

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Order RoboHelp X3 and receive a $100 mail-in rebate, plus FREE
RoboScreenCapture, WebHelp Merge Module and iMarkupSoftware, for a total
giveaway value of $473! Order here: http://www.ehelp.com/techwr-l

Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday TECHWR-L....

---
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.



Follow-Ups:

Previous by Author: 11X17 documentation?
Next by Author: Need feedback?
Previous by Thread: Re: My first attempt at tech marcomm
Next by Thread: RE: Common approach to documentation?


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


Sponsored Ads