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.
Subject:Re: Ethical Question - RESPONSE - From:Bill Burns <BillDB -at- ILE -dot- COM> Date:Wed, 6 Jan 1999 10:45:08 -0700
Kim writes:
> What do you do when capable writers and managers do take the time to
> comment on projects, and are not listened to? How would you suggest
> dealing with this situation:
>
I continue to make noise about it. I write a detailed explanation of what's
wrong and how the problem can be alleviated. If I don't get a satisfactory
response, I escalate until someone who can take action responds. If I'm told
just to "shut up and write" (and I have been on occasion), then I consider
my part done, and I do what I can to hold up my end.
> We have a new product that our VPs are developing the product plan on.
> This product is considered mission critical for 1999. The Testing & QA
> and Documentation departments found out about the product this past
> Monday. I was told that the product is due to ship on Jan 31, 1999. The
> program is not written. The printer requires at least a week for turn
> around time. I have two weeks to write the manual, proof it, prepare
> camera-ready copy, and have x number of books ready for shipping by Jan
> 31. Many of the upper level managers have stated that this is not a
> realistic schedule. The deadline stands.
>
Sometimes, the answers are
It can't be done in that time.
No, I can't meet that schedule.
I can do it, but it won't be complete, it won't look very good, and
it will probably have errors.
And some people might throw a fit when you say these. Take the facts with
you. Tell them precisely what has to be done to produce a usable manual,
including estimates for hours and schedules. Point out the number of
resources you have to work on the project, and break that into an
hour-per-week plan. And don't forget the lead time to get the copy to the
printer in time for them to meet the schedule. If you have nothing to
document yet, make sure they know that, and include the estimated schedule
for a beta version. If the UI isn't frozen and won't be until after your
hand-off to the printer, make sure they know that.
If they are unwilling to hire additional resources, then do what you can
within a realistic weekly schedule to do the job. If the schedule is the
critical factor in the process, then quality will likely suffer. But quality
is obviously NOT of utmost importance in the minds of the folks who
scheduled (and if it is, they should have kicked the project off sooner).
You've noted that many of the upper-level managers have said the schedule is
unreasonable. You can give your input to support their opinion.
You're not at fault for their poor planning, but you are responsible for
what you do with the time you're given, as are the rest of the team. Crap is
relative, as is quality. If the team develops a product in one month that
even comes close to doing what it's scoped to do, that's a good one-month,
half-baked product.
Bill Burns
ILE Communications Group
billdb -at- ile -dot- com
Call me fishmeal.
