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.
At 11:06 AM -0700 7/11/2001, Cayenne Woods wrote:
>This week, the company decided to change the name of all the software (4
>pieces
>+ admin guide - not huge/complex software, but enough). The deadline is
>Friday.
Here's the first problem. You're being given a deadline plus changes. You
have no control over the amount of changes, and no control over the date.
>Tonite, Wednesday, I've finally got a build with _some_ of the new names and
>icons (there are new directory paths, dialogs, names of most of the software,
>etc, plus the actual changes in the software).
>
>I just made a stink 'cos I heard someone wanted to change the name, path and
>reference to yet another internal piece in one software. It happened to be the
>one I'd just - finally - spent an hour + trying to create in paintshop, since
>it's not _really_ finished.
>
>I'm now being treated as the heavy, cos I've said we can't change anything
>else.
>This is so far beyond absurd - I've just now got 1 of 4 Help systems
>mostly done
>- but I need to hear it from someone else.
OK, yes, they're nuts for doing this so close to deadline. For all sorts of
reasons, not all of which have anything to do with documentation.
That being said, here is a strategy that has served me well. Don't try to
prevent changes from being made. Instead, say, "Implementing a change to
the name of the application will take N days. Implementing a change to a
component name and/or location will take M days. Implementing a change to
an icon will take L days." (Days may be fractional here - I don't know how
much tsuris making these changes will cause in your particular situation.)
This puts the burden where it belongs - on management which is deciding to
allow these changes, and which needs to prioritize everyone's wants against
the reality of deadlines. Instead of you being cast as the heavy, trying to
control the software, you're merely describing reality. You're not setting
a deadline, and you're not demanding the software not change - you're just
providing information about how changes will impact your work, information
they can then take into account in deciding whether to make changes. If
they change everything Thursday night, fine. It will delay the docs by X
days, and you have documented that it will. Or they can choose to release
with inaccurate docs. Unpleasant outcome, but not your fault. Either way,
you're not taking responsibility for something you have no control over,
which will both help avoid making you look bad, and lower your blood
pressure.
Now, they may still demand that you do all the changes in an hour, and
complain when they don't get done in an hour, but this is a lot less
tenable if you've documented that they'll take longer than that, and can
back up your estimate as reasonable.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
TECH*COMM 2001 Conference, July 15-18 in Washington, DC
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com
---
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.
