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.
Re: More regarding help Project Management, and other stuff (LONG)
Subject:Re: More regarding help Project Management, and other stuff (LONG) From:"Kristine J. Olberg" <kjolberg -at- IX -dot- NETCOM -dot- COM> Date:Thu, 10 Apr 1997 20:06:29 -0500
----------
> From: Susan Brown <sbrown -at- JSCSYS -dot- COM>
>
> Everyone is VERY pleased with what they have seen so far (I was
> required to produce a prototype of the system within one week of starting
-
> but I won't get into that), but is utterly unconvinced that I really
needed
> even the amount of time I have taken to date, let alone what I offered as
a
> bare minimum for something that was marginally acceptable, as opposed to
> even fair. (The ugly $ Monster continually rears it's ugly head.)
Given the information you've supplied, it's hard for me to gauge whether
your estimate is realistic. Have you estimated the number of help topics
that need to be written? How long are the topics, on average? Is the
information complex or highly technical? On the average, I'll assign about
1 hour to a help topic as a starting point. After tallying up the total
number of hours, I step back from the estimate and do a sanity check. I
also have someone else in the profession do a sanity check.
What is the primary reason that your colleagues are balking at your
estimate? Is it because of $$? Or is it because you'd affect the schedule?
If it's $$$, then there isn't much you can do short of convincing your
colleagues that documentation should be a priority, not an afterthought. If
it's the schedule, it's their problem. You should have been working on the
project at the same time it was being developed.
Regarding source code, try asking them to supply you with copies of the
source code. It could be they are balking at giving you access to source
code out of fear that somehow you'll change it. If you ask for copies, you
eliminate that possibility.
Here's another possibility: if $$$ are a problem, ask them for the number
of hours they can afford. Then find and propose a documentation solution
based on that number of hours. It could be that your expectations of the
deliverables are not the same as theirs.
Regards...Kris
----------------------------------
kris -at- olberg -dot- com
kolberg -at- actamed -dot- com
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
