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.
The last-minute change (was Re: Structure vs Substance?)
Subject:The last-minute change (was Re: Structure vs Substance?) From:SteveFJong -at- aol -dot- com To:techwr-l -at- lists -dot- raycomm -dot- com Date:Tue, 13 Jun 2000 13:28:42 EDT
Rick Vantour <rvantour -at- mondenet -dot- com> described the dreaded last-minute change:
>> If a client tells me they need me to work on a Sunday
>> to document new features in a manual
>> that is to be released on Monday...
>> I make the change...
>> [F]lexibility at deadline time
>> has served me well.
>> I'm curious as to how to respond to situations with clients when the
process
>> must be neglected? I don't believe that a process will ensure that these
>> situations do not occur.
Within the context of a documentation group, this sort of thing happens all
the time, and your local process is helpless: it seems you just have to bend
(or bend over 8^) to accommodate the event. (Well, maybe you can update the
release notes; do you write release notes?)
However, consider this same scenario from the larger context of a development
organization. What does the last-minute change mean?
o The engineer who made the change may not have had the time to think it
through; it may not solve the problem.
o The change is almost certainly not described in any way--everyone has to
guess at what it does.
o When pressed for time, the writer could make a significant mistake--like
forgetting to rebuild the TOC.
o The change may affect an inordinate number of document pages, or even force
a reprinting.
o The testing group may not have time to test the change--or even be aware of
it.
o If the change is tested and a bug is found, there's no time to fix it.
o If the change affects existing code, there's no time for regression testing.
o In an environment where changes flow from customer requirements, the
customer may not have approved of the change--and may not pay the bill.
Now, each of these consequences is bad; together they are Very Bad. I have
seen each of these consequences happen; I have also seen people fired for
making last-minute changes because of the cumulative negative effects. (I
suppose no one here is arguing *for* last-minute changes!) But can process
help? I think so, if the whole organization buys in to them. In a
customer-focused process, actual contract language can help prevent this sort
of thing from happening. An up-front design process also helps reduce
down-stream surprises.
-- Steve
Steven Jong, Documentation Team Manager ("Typo? What tpyo?")
Lightbridge, Inc., 67 S. Bedford St., Burlington, MA 01803 USA
Jong -at- lightbridge -dot- com -dot- nospam 781.359.4902[V], 781.359.4500[F]
Home Sweet Homepage: http://members.aol.com/SteveFJong
