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

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:

Previous by Author: RE: Trip Reports re: presentations
Next by Author: RE: Trip Reports re: presentations
Previous by Thread: RE: know a good tool for web screen caps?
Next by Thread: Re: The last-minute change (was Re: Structure vs Substance?)

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

Sponsored Ads