TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Re: Planning tools and techniques (Was "Juggle Act")
Subject:Re: Planning tools and techniques (Was "Juggle Act") From:Barb Philbrick <caslonsvcs -at- IBM -dot- NET> Date:Tue, 24 Jun 1997 14:22:11 GMT
Depends if it is software or hardware.
If it's software, think of everything in terms of topics, even if
you're not writing online help. How many windows are there? Is each
one a topic? Is each one several topics? What about other items that
need to be discussed, such as common buttons and concepts? I budget
about two hours per topic (I think - I haven't budgeted an online job
in a while. Other people might have better numbers.)
If it's hardware, I look at the specification and , if it exists, the
breadboard. How many switches? How many terminals? It takes about a
1/4 of page to document each DIP switch and terminal, and two hours
per page to write a manual (assuming I have basic wiring diagrams to
work with). I also know that hardware manuals will include an
introduction, mounting, wiring, setup, startup, operating, and
troubleshooting section. There will be at least two pages in each of
these chapters, and the more complex the product, the bigger. Just
keep breaking things down into smaller chunks. For example, the
mounting chapter - will there be one mounting footprint that will work
for all of the models? Or will you need three or four? Are the steps
the same for all of them or different? The answers to these questions
could result in a page count of from two to eight pages.
Then I get into the wishy-washy stuff. Does the engineer have a
backbone? If not, marketing and the salespeople are going to walk all
over him or her, and the project is going to change direction about
five times. Add another hour per page and don't document much more
than concepts at the beginnning of the project. Does the engineer have
severe ego problems that will require major massaging every time you
change a word from the spec? Add at least 1/2 hour per page.
One last caveat - Know thyself. Keep track of a few projects so you
know what _your_ per page or per topic rates are. It can be a real
eye-opener, and a great help in estimating time for projects. (It also
helped me push for additional help at a previous job.)
Hope this helps -
Barb
On Tue, 10 Jun 1997 08:58:23 -0500, you wrote:
>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
Barbara Philbrick, Caslon Services Inc.
Salutation, by Ezra Pound
O generation of the thoroughly smug / and the thoroughly uncomfortable,
I have seen fishermen picknicking in the sun, / I have seen them with untidy families,
I have seen their smiles full of teeth / and heard ungainly laughter.
And I am happier than you are, / And they were happier than I am; / And the fish swim in the lake / and do not even own clothing.
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