RE: Interesting Article... fewest jobs lost in Tech Writing

Subject: RE: Interesting Article... fewest jobs lost in Tech Writing
From: Kelley <the-squeeze -at- pulpculture -dot- org>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 08 May 2002 22:41:03 -0400


At 09:24 AM 5/8/02 -0700, Ellen Ferlazzo wrote:

Have any of you had experience working on the specs in this manner? If
not, don't you feel like you could contribute a tremendous amount to the
design of a product based on your experiences of trying to explain how
it works?


Kinda sorta related.... This is what the lead engineer for a project I head up wrote and sent to a list I lurk on (Yes, I love him madly. I've been shopping for a special gift to give him, since an employment anniversary is coming up. Any recommends on Absinthe spoons, etc? offlists appreciated!). It was sent as part of a longer post in response to someone's question about project mgmt advice. As an engineer, he doesn't see the docs as useless at all and see tech pubs as an integral part of the process:


What can go wrong in the beginning:

- - Incomplete design specifications.
- - Inaccurate or incomplete market research.
- - Incomplete or nonexistent security requirements for
networked/ multi user applications.
- - Project was "bid" on with insufficient research, resulting
in a bid that was too low, with insufficient time or resources
allotted to the development life cycle.
- - An arbitrary "completion date" was set at some mythical time
in the future. If a project starts, and you "know" the exact
date that you will be done, you're just fooling yourself.
- - Development starts before design specs and development specs
are complete.
- - QC and tech pubs are left out of the initial design loop.
This means that, without a QC review of the design, the
entire concept may be flawed. Tech pubs ensure that
the required documentation is present, and that it conforms
with whatever guidelines the company has for their documentation.
Just this can save hundreds of development man hours.
- - A general lack of initial documentation.

What can go wrong at the midpoint:

- - Anything that went wrong in the beginning, typically
snowballs and really starts biting you in the ass right
about now.

: Due to incomplete design specs, design changes are made
midway through. This means some features get left out
and new ones get added. Generally, it means that new
features get added, but there is no additional development
time allotted. (Incomplete docs intensify this problem)

: Security suffers, as the dev specs should be based on
those requirements - that originate from the original
design specs.

- - QC is still not part of the development cycle, application
errors that could be found at this point are left until
the end when it is very expensive and time consuming to
fix them.
- - QC has insufficient design specs, so it cannot develop
testing plans until the application is nearly complete.


What can go wrong at the end:

- - QC is finally brought in to the loop creating a testing
bottleneck.
- - When development takes longer than expected (as always) that
additional time is not compensated for by moving the "due" date.
This results in a rush to get things finished. The time allotted
for testing is generally the first to get sacrificed to make
the deadline.
- - The initial deadline is often missed because it was, after all,
an arbitrary date decided upon with insufficient information.


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

Buy RoboHelp Office in May and you'll save $100 with our mail-in rebate.
Or switch from Doc-to-Help or ForeHelp to RoboHelp Office for only $499.
Get the help authoring tool PC magazine recently awarded a perfect score!
Go to http://www.ehelp.com/techwr
---
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.



References:
RE: Interesting Article... fewest jobs lost in Tech Writing: From: Grant, Christopher
RE: Interesting Article... fewest jobs lost in Tech Writing: From: Ellen Ferlazzo

Previous by Author: RE: WORD updating Ole-linked and embedded graphics
Next by Author: Antwort: time
Previous by Thread: RE: Interesting Article... fewest jobs lost in Tech Writing
Next by Thread: Re: Interesting Article... fewest jobs lost in Tech Writing


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


Sponsored Ads