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.
Subject:Working locally vs. on the server? From:Geoffrey Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA> Date:Wed, 31 Mar 1999 08:17:39 -0500
Beth Kane is <<...really irritated with tech writers who refuse
to store/work with their docs on the server everyone is
supposed to be using... For some reason they don't feel right
unless they're working with the docs residing on their hard
drives. When questioned they'll tell you they back it up to
floppy (!) or some other drive.>>
The usual reason is a lack of understanding of how the
company's system works. Perhaps an explanation of your
company's data storage and backup system would reassure
them? For example, could you provide them with the MTBF
(mean time between failure) estimates for their desktop hard
drive and the server's disk array? Could you indicate how the
typical two-level backup (daily incremental, weekly
complete) is much more secure than their process?
<<I figure the IS guys have lots of recovery processes in
place for the server, too, since it holds so much important
data for lots of people in the company.>>
Probably, but it never pays to assume... I've worked places
where backups were somewhat desultory, to be kind to the
MIS people. Maybe your colleagues know something you
don't? <g>
<<What can I do to convince them to use the server we're
supposed to use?>>
The "boss says so" stick is usually a sure bet, because it's the
only way to persuade some people to do what they otta. <g>
But the carrot approach can work well too, particularly if you
use your annoyance with the behavior to motivate you to
identify and implement a practice that would make you all
work more effectively; then it becomes a win-win situation
rather than a law imposed from on high. For example, how
about suggesting that the last hour of each day be spent doing
peer review on each other's work for the day? That certainly
takes time away from your own projects, but that investment
should be more than repaid by the advantages of the
approach: you catch ongoing problems early, before someone
has to go back and correct them globally; you share solutions
to these problems as you identify and solve the problems; you
produce cleaner drafts for your own first revision and for
subsequent technical review; you build a sense of teamwork
and "we're all in this together"; etc. Worth a shot?