Re[2]: lead time? what lead time

["Cayenne Woods" <cwoods -at- purplevoice -dot- com>]

Andrew Plato:
it doesn't seem you actually took the time to read much of what I wrote, but
nevermind. 
I'm not complaining about the lack of specs, but just giving background - and
also mentioned that this is something we (all of us) want to change for next
time. The main problem is that there were no guidelines for docs review, and I'd
like to figure out how to agree some.

Also, I have no problem with making whatever changes necessary, especially the
way we're working at the moment. All I've said is that we need to think through
_big_ changes and have a good reason, and that  I'll have to make decisions
about what things can happen for Wednesday, and what can wait or doesn't need to
happen at all.

We don't have anything longer than 50 pages, which I also mentioned. And I
didn't 'drop documents on them at the last minute.' First, I requested feedback
more than a month ago. Second, the new project manager asked them to have a
look. And none were engineers.

I have no desire to intimidate people, just to communicate more clearly. And
that's part of what my job is. I'm perfectly capable of diplomacy and 'dealing
with them' and still getting my job done.

but hey, thanks anyway ap



____________________Reply Separator____________________
Subject:    Re: lead time? what lead time
Author: intrepid_es -at- yahoo -dot- com
Date:       08/12/00 17:59

"Cayenne Woods" wrote...

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

I hate to say this Cayenne, but this is par for the course at a lot of
high-tech firms. Especially for fairly new products of efforts. 

> Hopefully this won't happen again, but at least I've
> figured out that I'm working semi-miracles, and it shouldn't be this way.
> I've got two main Help files and two small ones, and a 50-page admin guide 
> that have had to be rewritten in two weeks, on my own. We're small, and 
> building for existing and potential customers rather than releasing to the
> public at the moment, but this is still quite a lot.

I'd feel your pain, but what you're enduring is very typical. I've endured this
75 to 100 times over in my career. I've re-engineered docs days before
drop-day. Its just the way it goes. Dynamic, highly volatile engineering
environments have a unique set of challenges. One of them is being able to
handle last minute changes. 

I have clients who routinely change things days before drop date. What are we
going to do? Tell them to go to hell?  We doc it and move on. Hey, its their
product they hold they keys - I either deal with it or throw a tantrum. 

> Also, after asking for feedback since early November and not getting even a
> reply, 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.

But that is the easiest thing to pick at.  People pick on fonts and
capitalization because its EASY.  Opinions about fonts and colors are like
bellybuttons. Everybody has one and they're all full of lint. 

Again, this is very typical. Imagine if somebody dropped a 200 page document on
your desk and said: "read this in a day."  Would you be excited to pile through
100s of pages of esoteric commands and procedures?  I know I wouldn't.  Keep
this in mind when you drop your docs on engineers. They dislike documentation
way more than you.  So reading that document is like torture to them.  

One tactic is to meter out difficult sections to engineers a bit at a time. 
Email them sections or individual paragraphs and ask for their opinion.  Its a
lot easier to read 2 pages of critical text then to read 200 pages of blather. 

> How do people deal with setting some parameters for different levels of docs
> review, and how can I put this semi-delicately??
> thanks for suggestions!

Diplomacy is perhaps the tech writers' most important skill. Keep in mind your
role. You are in a position to make the engineers look good. But they are busy
people with their own set of requirements and pressures.  Telling people that
they are doing things incorrectly and it is hurting you only makes you look
like a whiner.  It may be true, but so what?  Are you a CEO or a tech writer?  

In other words, you're not going to change people and you don't have the
authority to intimidate them. So you have to find a way to deal with them and
still get your job done.  

A couple of tactics: 

1) Lock down simpler docs early on. Get them out of the way quickly.
2) Plan for a week of hell around drop days.
3) Be prepared to move quickly during this week.  
4) Secure your technical contact. Warn him/her in advance that you may be
bothering him/her a lot in that last week. 
5) Set a publication date where you release the docs. All edits after that date
will be shelved until the next release. 
6) Eat more fruit. It won't help you write any better, but its good for you.

Andrew Plato 





__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/




**************************************************************
This communication contains information which is confidential
and may also be privileged.  It is for the exclusive use of the
intended recipient(s).  Please note that any distribution, copying
or use of this communication, or the information in it, is strictly
prohibited.  If you have received this communication in error,
please notify us by email or by telephone (+44 20 8848 6644)
and then delete the email and any copies of it.

This communication is from Purple Voice Ltd., whose principal
office is at Dawley Road, Hayes, Middlesex, England.

This footnote also confirms that this email message has been
checked for the presence of computer viruses.
**********************************************************************

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