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 have a situation here and I'm wondering how any of you handle it. I
> know what I think is the best way, but that doesn't count here.
>
> While anyone can contribute, the situation really applies to Very
> Large Company (VLC) environments where documentation is produced in a
> very distributed manner
>
> In my situation, each department handles documentation differently.
> Some, like my department, have a writer to write documentation.
> Unfortunately, this is a minority. In most departments, "someone" in
> the department writes anywhere from one to several documents. We may
> be talking about over 100 different document authors at one time or
> another.
I feel your pain!
I'll tell a similar story. I'm not directly involved in the project I'm
describing, but I have been keeping a close eye on it for some time.
The 3GPP (www.3gpp.org) is in the process of writing the technical
specifications for the next generation mobile phone system (both the phones
and the network infrastructure). A complete set of the documents contains
30,000 pages or thereabouts. They have an amazing schedule of meetings
culminating in quarterly meetings of 4 top committees together, totalling
500 people or so.
At the last quarterly meeting, they approved about 1200 changes to the
documents (each change being anything from a comma here or there to 100 new
pages being added to a specification). The specs are 2 years late, still
unfinished and still unstable. They are in the tar pit just as you have
described.
Being 2 years late is a serious business for this project. In the UK alone,
the mobile network operators have paid the government about $50bn in license
fees for the radio spectrum the system will use, and are probably facing
interest costs of something like $3m per day on that lost money! Multiply
those figures by 10 to describe the situation across the whole of Europe. If
you have been wondering why telecom stocks have been falling round the world
lately, this is part of the reason.
Their problem as I see it is that they have not created a body whose job is
to ensure that the inconsistencies arising from proposed changes are
discovered and then resolved. It is assumed that the inconsistencies will
become clear in the normal course of things.
Your problem sounds similar, there is nobody looking to ensure that the
document set *as a whole* maintains a high quality and consistency. All the
measurements are in respect of the quality of the individual parts, and
there are few if any with respect to the consistency of one part with the
next.
Now, the issue here is that if you take the time to work out the effects of
a proposed change, and hold up the implementation of it until its wider
effects are known and dealt with, then the immediate appearance is that you
are delaying much-needed change. After all, you can always catch up later
with the consequential changes! Superficially, it is very attractive to get
the immediate task done - it gives the appearance of quick response and
efficiency. Unfortunately, it is bought at the price of coherence and
consistency, and that is a heavy price. eventually, the documents can get so
bad there is little option but to throw away the whole lot and start again.
If that is to be avoided, there needs first to be a cultural change, such
that the documentation set as a whole is considered to be a single product
and included within the circle of things whose quality is critical. Then
there needs to be review of the existing documents, to resolve as many
anomalies as can be found. Finally, there needs to be a process change, such
that no individual documentation change is implemented unless its effects on
other documents have been independently reviewed, and any necessary
consequential changes determined. Then the complete set of changes is
implemented in one go.
Of course, in order to find out the consequences of a change, you have to
have sufficient tools and knowledge to find related documents. However, this
IMO is the easier part of the problem. The hard part is getting people to
believe that it is necessary to look in the first place.
Regards
Jonathan West
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you using Doc-to-Help or ForeHelp? Switch to RoboHelp for Word for $249
or to RoboHelp Office for only $499. Get the PC Magazine five-star rated
Help authoring tool for less! Go to http://www.ehelp.com/techwr
Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com
---
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.
