Re: Planning tools and techniques (kinda long)

[bmaaks -at- TELLABS -dot- COM]

Chris and fellow techwhirlers,

Boy, it's been a while since I estimated work based on page count. But I
remember the days...

I started with an understanding of the basic project. You have an advantage
in the existing documents: document names, sections, topics, etc. Use this
as a basis for the questions and investigation for the new product. "If
Product A had this, then Product B has ______."

Sometimes working with product developers (often marketing people) can be
frustrating. I think of my favorite Dilbert:

Marketing Guy: The project requirements are forming in my mind.
               Now they're changing...changing...changing...changing...okay...
               no, wait...changing...changing...done.
               Naturally, I won't be sharing any of these new thoughts with
               Engineering.
Dilbert:       I budgeted for some goons to beat it out of you.

I take the tactic that the product developer doesn't know what you need to
know...so your job is to ASK QUESTIONS of EVERYBODY. Does your company have
a methodology for developing new products? Do they write a formal product
specification and ask the customers to verify that it describes the product
they want? Are there meetings of various development groups (marketing, SW,
HW, customer service...) to discuss and identify the new product features?
GET INVOLVED in everything. Invite yourself. Smile a lot while writing copious
notes and then ask more questions.

Get a deadline for when the product is expected to release. Work backward from
that date and align your schedule to development's schedule. When they test
the product, see if you can be one of the reviewers. It's a great way to
preview the working product and do someone a good turn (TWs know a whole
lot about usability so offer your services internally).

When you know what you will write, make a VERY detailed outline. Using your
previous experience and the documents for the Product A, estimate the page
count. LET EVERYONE KNOW that your estimate is based on what you know to
date about Product B, and what you expended on the documents for Product A.
Then as you learn more, or as project dates change, you change your estimate.

In a nutshell:

* Project management = resources (people, equipment...), time, scope and budget
* Estimate scope based on what you know to date, and change it when you know
  more.
* Write down the scope (what you need to do and topics your document needs to
  cover). Show scope changes (use change bars) with each new revision.
* Estimate all of your tasks: researching, writing, editing, administration,
  attending meetings, and other required or anticipated activities.
* Write down the assumptions you are using as a basis for the estimate:
  Examples:
  - Development will provide knowledgeable SMEs as resources with time in their
    schedules for interviews, document testing and document reviews.
  - Estimates are based on previous page counts and work effort expended for
    Product A.
  - Estimates are based on the most current version of the Product Specification
    Documents, which are still in development.
  - There are four writers and one editor assigned full-time to this project.
  - (fill in your own assumptions here)
* If you estimate that you don't have adequate time for the estimated work and
  you can't convince everyone to delay release, look at ways you can (a)
  increase the resources, (b) reduce the scope.
* To reduce the scope, look at streamlining your processes (leveraging existing
  text, writing processes, etc.) or reducing the "elegance" (by setting 2 or 3
  priority levels to the information for the document: 1=have-to-haves, 2=
  really need, but successful use by audience is not affected if it's not
  included, and 3="nice to dos and nice to haves" in the document, but
  aren't necessary for the successful use of the document; then always write
  Priority 1s first, then if there's time, write Priority 2s and then 3s).

I can't think of any other nuggets that may be wisdom and may be foolishness.
I hope that something here will help you, if only to encourage you a little.
Regards,
Betsy Maaks
bmaaks -at- tellabs -dot- com
I speak for myself, not for the company.

---------------begin included message-------------------

Date:    Tue, 10 Jun 1997 08:58:23 -0500
From:    Chris Hamilton <chamilton -at- GR -dot- COM>
Subject: Planning tools and techniques (Was "Juggle Act")

It seems to me that one way we can assure ourselves some time to do
things like walk on the beach is to have a decent idea up front what is
required and how long that would take. (Duh.) Obviously, that's not
possible in all cases, but just winging every time it is a good way to
spend lots of money on Maalox.

So what do you do to keep from from totally winging it? I realize this
is a rather open-ended question and that there are some obvious answers
(get it included in the contract, talk to the project manager and
project members, look at similar products from the same group). But what
do you do when you don't have the benefit of that stuff and even the
project management can give you nothing more than a swag? Even page per
hour metrics are useless when you don't have a clue what the expected
page count is?

Specifically, we're into a new type of products and many of the rules of
our previous products just don't apply to these products. So there's a
lot of guess work and I'm looking to the collective wisdom of the list
to find ways to do more planning and less reacting. Is that even
possible? (Sorry for the vagueness of the question, but my mind is vague
on this.)
--
Chris Hamilton, Technical Writer
Greenbrier & Russel
847.330.4146
chamilton -at- gr -dot- com

---------------end included message-----------------

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html