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.
On a recent contract, the managers were all being driven nuts by a
requirement that Microsoft Project be used as the main planning tool. Not
only that, every department's schedules were imported into one Master
Schedule, which of course was always broken.
It may be possible to use Microsoft Project to do something useful without
devoting all your waking hours to tinkering with it, but I've never seen it
happen. It was very ugly.
When I plan projects, I need only a handful of dates to do the whole thing.
Mostly, I do semiconductor documentation, so it's a matter of:
"When can I have a vaguely complete spec?" (or a completely vague spec)
"When's tape-out?"
"When will the evaluation board look good on paper?" (I don't need the real
board except for a photo, eventually)
"When will you make up your mind about the product's name?"
"When's product announcement?"
"What are your major sales/marketing/PR milestones?"
That's about it, really. I don't much care about when the actual silicon
comes back, since the product announcement is always well in advance of
working silicon.
Anyway, the goal is to put the documentation plan on a Procrustean bed sized
to the major milestones, and chop it or stretch it accordingly. With less
time, they get less stuff. With more time, they get more stuff. Complex
project plans mostly just get in the way, since they hide the crucial
milestones in a sea of irrelevant ones.
This is not elegant, but the end product isn't determined to any great
extent by the elegance of the paperwork, any more than a sculptor with a
carefully waxed and swept floor turns out better statues to one who lets the
chips fall where they may.
For my part, I kick out a small number of milestones, mostly the dates of
reviews, and a table of contents for the finished document. Possibly a
mock-up as well. The rest is free-form.
I once tried to handle projects in a more formal manner, but every
documentation project exploded into a constellation of milestones which did
not repay the effort of tracking. I also discovered that trying to track
projects in a reasonably detailed way generated floods of excuses and
rationalizations from all sides, which were painful to listen to and not
worth writing down. So I gave it up and switched to simpler methods. Nothing
bad happened when I did this.
When a client is big on management paperwork such as Gantt charts, I try to
bite my tongue and go along, since no one is very interested in my corporate
management tips. But it's hard.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Purchase RoboHelp X3 in April and receive a $100 mail-in
rebate, plus FREE RoboScreenCapture and WebHelp Merge Module.
Order here: http://www.ehelp.com/products/robohelp/
Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday 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.
