Re: Concurrent writing and revision

Subject: Re: Concurrent writing and revision
From: "Engstrom, Douglas D." <EngstromDD -at- PHIBRED -dot- COM>
Date: Fri, 31 Jul 1998 13:52:26 -0500

Mark:

This is written in reply to:

******************
We need to wake up to the fact that in modern product development,
design changes occur
almost up to the day of release, and that this is not a fault in the
development process but a necessary part of business life for any
company
that wants to maintain a competitive edge.
******************
Sorry, I'm not buying this. Granted, there are cases where a large
vendor revamps a fundamental technology in the middle of your
development project, or your client's underlying business process gets
completely redone. Those situations, legitimately, may introduce the
need for last-minute product changes.

Most of the time, however, making revisions until the last second prior
to release is a symptom of inadequate up-front analysis,
poorly-developed specs, bad project planning, improperly organized
testing, and overall shoddy project management. Unfortunately, these
are very common in software development; so common that they are
sometimes passed off on the unwary as "modern development methods."

If the developers are cramming last-minute changes into the code to
"maintain competitive edge" as the master heads to the disk duplicator,
when are those changes subjected to a rigorous system test? How is
customer reaction to the change evaluated? How is the support staff
prepared for the change? The answer, of course, is that none of those
things happen, and when the "cutting edge" product hits actual
customers, there is a rash of installation failures, system conflicts,
and bizarre product behavior. The documentation, left out of the loop
in the rush to market, is no help. The unprepared support staff is
overwhelmed, and offers a confused and inadequate response. The product
drags behind it an expensive trail of patches, service releases, user
notes and awkward work-arounds. Not to mention unhappy customers.

Combating these problems requires that development organizations face up
to the fact that project management is a distinct discipline, which
requires actual training (not just x years as a programmer or analyst)
management attention, and a different skill set than either coding or
analysis. It requires people to do things (like hammering out specs in
advance) that aren't nearly as much fun as playing with code, and
adopting a more rational attitude toward resource planning. It also
requires customers that are more fascinated by a reliable, maintainable
system than a collection of bright, shiny objects.

While that last item may be a long time coming, I think it's starting to
happen. I recently got to take a vendor out of competition for an
enterprise-wide project because of outrageously shoddy practices on a
departmental system I'm using. In the long run, you will pay the price
for being sloppy--ask the carmakers of Detroit.

All that being said, as the technical writer, there's only so much you
can do to change the corporate culture. One possible answer is to look
into a document control and management system. A good DCMS will allow
you to track changes, maintain versions, assign ownership, and automate
many of the techniques other respondents to this question have
suggested. However, it will extract a price--not only in dollars, but in
forcing your organization to analyze and evaluate its document
development process, and create a rational one.

IF YOU HAVE MANAGEMENT SUPPORT FOR THIS the DCMS can be a catalyst for
beginning a higher-quality development process for the documentation
and, eventually, your product. If you don't have management support,
you will be perceived as overly rigid obstructionists, people will find
ways to chisel around the restrictions in the system, and you'll have a
bigger mess than you do now.

Skoal,

Doug Engstrom "Now, you know a refuge never grows
engstromdd -at- phibred -dot- com from a chin on a hand and a
thoughtful pose; got to tend
the
earth if you want a rose."
-- The Indigo
Girls

####################################################################
My opinions only, not those of Pioneer Hi-Bred International, Inc.
####################################################################

From ??? -at- ??? Sun Jan 00 00:00:00 0000=




Previous by Author: STC Review of Help Tools
Next by Author: FWD: Followup from Original Underpaid
Previous by Thread: Re: Concurrent writing and revision
Next by Thread: Re: Concurrent writing and revision


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


Sponsored Ads