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.
>
> So, my question (sorry about the long intro):
>
> Do I ask for an official extension to the deadline? Or do I power thru
> this
> and bust my tail to make the original deadline? Obviously, this is
the
> first and only project I've done for them and I'd like more, so I'm
not
> quite sure how to handle it. Is the fact that I need to add material
due
> to
> my inexperience? If so, does that affect how I handle this as far as
"it's
> my mistake so I'll deal with cleaning it up"? Or do I talk to the
contact
> and ask for an extension, citing new material and lack of diagrams?
And,
> if
> I do ask for an extension, how do I go about it w/out looking
completely
> unprofessional?
>
Definition of a "done" manual: However far you get in the writing /
editing process when you reach the deadline. ;-)
Ok, now for a more serious response. First--you're not the first person
this has happened to, and it happens to writers with many more years of
experience. So don't be worried you're committing some horrible mistake
they teach you to avoid in TW school.
Second, a question: does your company have a website accessible by your
customers where you could post .PDF "addenda" to the documentation that
ships with the product?
If so, you might be able to gain an extension without asking for one.
This is one possible solution--others may have better (or more appealing
options):
1. Make sure the documentation is complete enough the users can
initially set up and use the product.
2. Tell your SMEs your concerns about the important features that were
not shared with you until yesterday, but that you have a plan to deal
with it.
3. The plan: you'll make it very clear at key points throughout the
manual (as well as at the beginning and end) that additional
documentation is available online at "www.widgetsUSA.com" [insert
company's website]. You'll write shorter, more detailed instructions and
information for each missing feature and publish it as a separate .PDF
document and place it on the web site.
4. Be sure you use the same template and application for these extra
sections that you used for the entire manual--then as you complete them
you can fold them into the "version 2.0" User Manual and update the ToC
and Index accordingly.
In this way, you can present yourself as a flexible "problem solver" --
though they throw you a major curve at the last minute, you're able to
come up with a plan to deal with it and not impact the production /
release schedule. You can express your disappointment that they did not
provide complete information, but now you're being constructive and not
"whining" or "making excuses" (they may not see it that way, but some
managers might).
The only caveat to this is if the "major features" they revealed
yesterday are something that might pose a health, injury, or damage
hazard to the user or the product or other property if they are not
included in the manual. For instance, if a lawnmower is shipped with
the blade attached but not tightened, you would definitely not want that
left out of the documentation included with the product.
In any case, this is good experience for working with this company in
the future--now that you know some of the things they are likely to
overlook, you're better able to research and complete future projects
with them. Each environment will be different. Some development teams
love sharing knowledge but are not confident of their ability to convey
it to users; other developers assume that everyone else is either "too
stupid" to understand or "too informed" to be told something that a user
may really need to know. It sounds like your guys probably don't despise
users, they are probably just so wrapped up in what they do that they
don't think about it from the user's perspective. The more you work with
them, the better you'll be able to help bridge that gap.
Good luck and let us know how you resolve the deadline issue.
CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l
