Now lone techwriter, startup?

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

Ellen Vanrenen has returned to the techwhirler whirl: <<I am now a lone
techwriter in a fast-paced start-up. We need everything done... I don't know
what to tackle first.>>

First off, take a deep breath, pause, and gather your feet beneath you.
Don't start running until you know where you're going, when, and why;
otherwise, you're just reacting in panic to ongoing crises.

Start by developing a list of what must be done, and characterize each task
well enough that you have a hint at what tools you'll require. Compare, for
example, "write chapter 1--any word processor" with "develop product
specification sheet--must be printable, Web-ready, and able to serve as
online help". Along with this, try to get an idea of how urgent each task is
so you can prioritize each task.

You can't start any project without a good idea of what work needs doing and
(roughly) when; if you're going to run out of time, make sure that the only
things that don't get done are the relatively unimportant ones. To do this,
you need to quickly identify who can provide this information and how you
can persuade them to keep you informed. You also need to rapidly establish a
friendly relationship with the developers, even if it costs you a bit of
time that might seem to be better spent writing; make them understand your
needs and give them a reason to spend some time helping you meet those
needs, and the rest of your work (getting answers, good reviews) becomes
much easier.

The second thing you need to do is determine what steps you can take to make
the job easier. Invest time now to save time later! For example, templates
take a while to develop, but once you come up with good initial styles and
begin using them consistently, any subsequent design changes are a snap: you
simply update the template and refresh the document. Make people aware of
the need for a _simple_ review process, and start reviews as soon as you
complete chunks of the project rather than waiting until the whole project
is done; you'll discover problems with the process, and can fix them now so
they won't trip you up later.

<<document numbering system and file naming conventions>>

Keep it very simple. If the product is called X, name the file "User manul
for X" or "Chapter 1 for X" if you've decided to break a large project into
multiple files. For version control, create a new directory named "Product
Date", with the appropriate information substituted: for example, "Product X
March 14-02 backups". (And do keep good backups!) If you've got a review and
editing process, add the suffix "-e" to indicate a file was edited and "-r"
to indicate it was reviewed; with multiple reviewers or editors, add their
initials to this (e.g., "User manual for X--GH edit March 14-02").

You can number files, but unless your situation is unusually complex, giving
files immediately obvious names works far better for the people who actually
need to use the files.

<<Also, we need to keep informed about new technologies.>>

Nope. When you're starting out, you need to keep informed about how the
existing technologies you already understand can meet your needs. When those
needs change, come here to techwr-l and ask the experts whether there are
newer technologies that will get the job done. Keeping up to date on the
broader field is certainly important, but it's a luxury when you're getting
started. Get the job done first, and worry about advancing your technology
later.

<<I know day-to-day documents have priority>>

Not always. Sometimes dealing with ongoing interruptions severely impedes
your longer-term work. You can't simply ignore these smaller projects, but
you can try to fit them into the larger picture. Ideally, you'll soon have
the kind of relationship with your colleagues that lets you say "I've got a
tight deadline for the next three days; could I do it Monday instead?" One
of the first things you need to learn about scheduling is that once someone
tells you when they _want_ a job done, immediately ask when they _need_ it
done. There's usually a fair-sized gap between the two dates.

<<Do I make a project for myself in Microsoft Project>>

Not necessarily. Project is great for juggling resources in complex
projects, but most of us live quite happily with nothing more sophisticated
than a calendar, a pencil, and the ability to combine the two to provide a
schedule. (Actually, I use Outlook's Calendar and Task functions, and
formerly used a simple Word file with headings by month, to arrange my
schedule. But you get the point: simple tools, powerful results.)

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html

Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law."

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check it out! Get some cool freebies when you buy RoboHelp! You'll receive
SnagIt screen capture software and a 10% discount voucher for RoboHelp
Consulting. This special offers expires March 29, 2002.
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.