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:FW: bidding a first contract From:Anonymous Poster <techwhirlanonpost -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 3 Nov 2005 06:23:05 -0800 (PST)
This message was forwarded anonymously on request. If
you want the original poster to see your response, you
must reply to the TECHWR-L list. All direct replies to
this message are automatically discarded. Contact Lisa
lisa -at- techwr-l -dot- com with questions.
I am a full-time employee at a company, and have been
asked to bid on a tech writing project for a company
where a friend works. This is my first time bidding on
a project, and I'd like some input.
The company sent me a couple of pdf files, saying,
"This is the kind of documentation we want you to
produce." Since that was the only "scope" information
I got, and the two pdf's were not even comparable in
length (one was 175 pages, one was 310), I had some
questions. This is the list of questions I sent, along
with the hiring manager's responses:
Q - Are these documents about XYZ products, others in
the industry, or something else?
A - These documents are from other vendors that
operate in the same technical space as [we do]. They
do not, however, cover our product.
Q - Will I be using these documents as reference for
the materials I write, or is this a sample of layout
and types of information the documentation will need
to contain, or both?
A - These are simply examples of the documentation for
similar products. They should help you glean the
target audience and the type of information that you
will be providing. Choice of layout will ultimately
be up to you.
Q - Do you anticipate that the documentation I write
will be similar in length to one of these documents?
Shorter? Longer?
A - My gut feeling is that the size of the documention
that you write will be approximately 50-75 percent of
the size of these samples. Our product has a
somewhat lesser degree of configurability.
Q - How much material will be provided to me in hard
copy format and how much will be provided in
electronic format?
A - Unfortunately, we are starting pretty much from
square one here. Our existing documentation is sparse
at best, and developed primarily by engineers for
engineers. All of the materials that we do have will
be delivered in an electronic form.
Q - How much information will I glean from current
docs/code/etc. compared to how much will be gathered
through interviews with employees?
A - I would venture to guess that the existing
documents will get you about halfway there. The rest
will need to be gathered through employee interviews
and system walkthroughs.
(They have offered to fly me out to visit their
facility as part of the contract.)
In addition to this information, I know:
* I will not have to do graphics (they have a graphic
artist who will be "at my disposal").
* There will be as much theory to explain as there
will be procedures to write.
* I can work in FrameMaker, which I'm already familiar
with, or OOo, which I would need to learn, but which I
expect wouldn't be difficult since I know Frame and
InterLeaf already.
* I am not familiar with their technology, and they
wanted it that way.
* Their initial time estimate for the job is around
100 hours.
* I am the only candidate they are considering at this
time. They have seen samples of my work and want me to
do the job. We just have to agree on a price.
* From my hours estimate, they will offer me a flat
rate for the project.
I've seen comments on the list about JoAnn Hackos'
figures of 8 hours per page for research, writing,
editing, graphics, reviews, and production. If that is
correct, even though I won't have to do graphics,
their estimate of 100 hours is far off!
My thought is that I would suggest it will take
125-150 pages to document their product, and 300 hours
of my time (since I do not have to do any of the
graphics, and I think the Hackos estimate is a little
too high), and make adjustments if the number of hours
it really takes is off by more than 15% either way.
My questions are, do you think that they have provided
me adequate information to make a bid, or are there
other questions I should be asking? And do you think
the numbers I've come up with are reasonable?
Thanks for your input!
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
Try WebWorks ePublisher Pro for Word today! Smooth migration of legacy
RoboHelp content into your new Help systems. EContent Magazine Decision-
maker review (October 2005) is here: http://www.webworks.com/techwr-l
Doc-To-Help 2005 converts RoboHelp files with one click. Author with Word or any HTML editor. Visit our site to see a conversion demo movie and learn more. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
