Lead time? What lead time?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Cayenne Woods reports: <<On this project I've worked with zero specs - as
have the developers. Until early last week, people were still
adding/changing/designing the software, with no prior plan. And the release
is next week, with considerable changes still happening last week.>>

Y'know, it's amazing anything ever gets done with this kind of planning.
Once you've survived the current crush, you need to sit down with the Powers
That Be and explain to them in words of two syllables or fewer why this
doesn't work. Remember the urban legend about the guy who built a sailboat
in his basement and couldn't get it out the door? It's not a legend; I
watched the excavators at work when it happened to a guy in my neighborhood
while I was a kid. Then there was the couple building their own house, who
carefully supervised the contractors day by day. Everything went fine until
the one-piece bath/shower unit arrived--after the door and drywall in the
bathroom had been installed. Down came the walls.

Designing with no target and no recognition of the necessary path to follow
(sequence) is a recipe for disaster in the short term and the long term.
Planning takes time, but that investment is amply repaid in the future.
Teach them to set a spec and stick to it. After all, as Microsoft knows
well, "the money's in the upgrades", and there's lots of years to keep
adding features to your product.

<<... a new project manager has kicked everyone into gear to review the
docs. However, they received absolutely no guidelines on what I'd like to
hear, and now have sent _lots_ of feedback. I should get over the opinions
on colors,
fonts, capitalisation, etc, but it's irritating. The big problem is there's
way too much detail for this stage - and even though I'd ignore half the
"suggestions" and many are simply wrong, it's a big chunk of both their and
my time that is not best-used at this point.>>

It's a question of education. You have to explain to them in terms they can
understand that at this early stage, the only important thing for them to
review is the technical correctness. (Time permitting, you can still do some
editing later in the cycle.) Let them trust _you_ to produce something
readable and usable while they strive to produce a solid product; that's the
teamwork thing. Emphasize that you know the documentation will be easier to
read and more usable next time--with their help--but that for now, you must
concentrate on making it useful (that is, correct and comprehensive).

As a starting point, pick one small chunk of text that's representative of
all the main points you need to cover (e.g., a single task so you can review
formatting of instructions, style for menu vs. button names, content, etc.)
and hold a 1-hour meeting--no more than that, because you don't have the
time--to get everyone to take a kick at it. Ideally, do this next to a
computer so you can make and approve changes immediately and get more
feedback on the results. After only an hour, you won't be completely happy
with the results, but you will have a compromise solution that _everyone_
can live with; don't get hung up on minutae. Once everyone agrees on this
design, make sure that you produce documentation that meets the design in
time for review. If you match a specification that everyone agreed on, then
at least in principle, the only things they should be able to comment on
will be technical accuracy. In reality, some of the reviewers will still
quibble over commas, but you can go back to them with the design that they
agreed to, remind them that it's not going to change right now, and keep
repeating that message until they get the point and start doing what they
need to do: reviewing content.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"Quebits took the art of manual writing to such extremes [that] the first
human scholars who'd tried to decipher their written language had spent a
lifetime working through what they hoped would be a definitive piece of
Quebit culture. No one was quite ready to say it wasn't, but the huge
ancient text had proved to be a manual for installing a sewage system within
a city."--Julie Czerneda, "Changing Vision"

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Take XML and Tech Writing courses online!  Our instructor-led courses
(4-6 hrs/wk) give you "hands on" experience at your convenience. STC members
get 20% off!  http://www.online-learning.com/index.html.
---
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.