Text production process?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

John Garside reports: <<Our department has been discussing promulgating a
text production process for some months.>>

Process can be a very good thing: it imposes consistency, and once it's been
road-tested for a while, helps you handle documents efficiently. That's
assuming you don't set the process in concrete, tie it to your boots, and go
for a moonlit swim, of course. The ideal process is one that reflects your
proven wisdom at how to do things right, fast, and well.

<<The sticking point is that the commissioners of the text -- typically
other departments -- are treated as 'customers' who, if not always right, do
have the last word.>>

Provided that the last word is on the content, that's perfectly reasonable.
After all, they're the experts. But there's no reason they should inevitably
dictate process to you. You're the expert on producing good documents, and
they need to learn to respect that. Note that "learn" sounds suspiciously
like "earn", and you do indeed have to earn their respect before they'll
accept your expertise and follow your advice.

Of course, the more difficult you make things for the client, the more
annoyed they'll be and the less likely they'll be to respect you. Your
process has to be rigid enough that all the important things get done (e.g.,
reviews) but flexible enough to meet the occasional unique need (e.g.,
lighter edits for documents that will subsequently be revised heavily).
Nobody likes a bureaucrat who slavishly adheres to the rules, even when the
rules don't necessarily apply. Everyone loves the bureaucrat who knows how
the system works and can help them through all the obstacles with the least
possible pain. I try to be the latter type of bureaucrat.

<<How do others reconcile the application of a standard process with
gorillas who want lipstick?>>

I point out that we have moral objections to animal testing of cosmetics,
and withold the lipstick. <g>

<<My problem is that work is _increased_ because each document means a new
process; there is little standardised history to go on, argument and
personality conflict abound, novices sink.>>

Start simple. The most basic documentation process you can come up with is
as follows: write, send for review, revise, finalize. Start with that and
see where it takes you.

<<"Processes convert inputs into outputs." But our inputs enter the process
ad hoc -- at any point, at any time. The output isn't quality controlled.>>

This is where keeping an ear to the ground helps--or bribing the gorillas
with bananas so they learn to warn you when work is coming. Some gorillas
can't be bribed, even with lipstick. Others become really good allies in
helping you impose order on chaos.

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

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A new book on Single Sourcing has been released by William Andrew
Publishing: _Single Sourcing: Building Modular Documentation_
is now available at: http://www.williamandrew.com/titles/1491.html.

Help Authoring Seminar 2003, coming soon to a city near you! Attend this
educational and affordable one-day seminar covering existing and emerging
trends in Help authoring technology. See http://www.ehelp.com/techwr-l2.

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