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.
Anthony,
Being a lone technical writer in a small group with very *tight* deadlines,
I sympathize with your plight.
Here's a mantra that just might help.
1. Accurate
2. Concise
3. Pretty
That's my working order.
When I first get a task to do - I go for accurate. I test it, I get it
tested and I try to beat all the bugs out. The first release is accurate, or
as accurate as it can be.
Then I work on improving the text. Often this means simplifying and to clean
the text to make it clear and concise. The second release is concise.
Pretty. Nice indexes, available in multiple formats, nice formatting,
consistent appearance with other docs, etc - this is the polishing. As much
as I love writing, I love polishing too. I like my work to look good. But as
far as a user is concerned (or a developer for that matter), it really does
come last.
Personally I'm having an absolute devil of a time trying to organize and
plan my time with milestones. My tiny division is trying very hard to get
organized. Planning seems to work for a few weeks, then falls away
completely.
The last time I tried to present a project plan I managed to stick with it
for two whole months (out of a planned 3) before it fell apart. What I did
might help you though.
I positioned my milestones so that a check in/release occurred after each
step in the editing process (about a week apart). I chunked the document (it
was a *huge* help file) into five parts of about 50 pages each. As I
finished a round of review on a part, I would check it in to CVS and
"release" it. It wasn't finished (not by far) but there were no serious
mistakes (lots of little errors that were, I hope, caught in later
revisions). Most importantly, however, everything was covered, at least in
brief.
This allowed developers to compile the project with the latest version of
the online help. Sometimes they even spotted errors in it when they were
black-box testing the product.
All this to say that if your bosses want it every two weeks (or so), then
plan your releases so they can have it every two weeks or so. It's called
iterative improvement. So long as you have a good version control program,
it should be fairly easy to compare previous versions to new to see the
slow, gradual and constant improvement of your documents.
I hope it is something your managers will come to appreciate. Mine did.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Rebecca Downey Senior Technical Writer
ITG:NBM Matrox Electronic System
1055 St Regis, Dorval, Quebec, H9P 2T4
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
---
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.
