Bidding a first contract?

[Geoff Hart <ghart -at- videotron -dot- ca>]

Anonymous reports: <<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.>>

Watch out for potential conflicts of interest, particularly if you 
signed a comprehensive contract with your employer that details 
intellectual property and working hours conditions. And make it clear 
to the potential client that you're employed full-time, and can't do 
24-hour work days to meet their schedule--that is, you can't do 
anything that will endanger your day job.

<<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...>>

For products that don't yet have firm design specs, any bid should 
include an explicit statement similar to the following: "This bid 
applies to X menu choices and Y dialog boxes with a total of Z 
features. Any additional features, and any changes to features that 
have already been documented, will be billed at a rate of $A/hour." 
This protects you against feature creep and change-itis. It also 
rewards the client for good project management.

<<These documents are from other vendors that operate in the same 
technical space as [we do].  They do not, however, cover our product.>>

Then you need to find out what reference material will be available for 
the product you're documenting.

<<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. >>

That's very helpful.

<<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.>>

Don't accept vague claims. As noted above, you need to pin down what 
you'll actually be required to do. Without some kind of blueprint, how 
can you estimate how long it will take? Even a preliminary "proof of 
concept" compilation of the program's menu structure or a "features 
wish list" is better than nothing.

<<Unfortunately, we are starting pretty much from square one here.  Our 
existing documentation is sparse at best, and developed primarily by 
engineers for engineers.>>

That's a warning sign. You'll want to find out how firm their 
blueprints are, or whether they'll be making it up as they go, and 
repeatedly changing things. And you'll need them to guarantee access to 
their engineers for those times when you don't understand what's going 
on.

Speaking of which, start developing a working relationship with the 
developers _now_. Introduce yourself to the key contacts, then tell 
them you want to learn how to make the collaboration easier for them: 
find out how they prefer to be contacted (phone, e-mail, chatroom) and 
when (i.e., are they morning or evening people) and how (e.g., the 
whole manual sent for review or each "topic" as you complete it).

<<I will not have to do graphics (they have a graphic artist who will 
be "at my disposal").>>

That can either save you time, or cost you an enormous amount of time, 
depending on how good this person is and how well they follow 
instructions. But best of all is if the person is both good and 
interesting in discussing how to succeed; you can always dictate terms, 
but graphics people are human too <g> and should be treated as such. 
Start talking to them too to get an idea of what they're capable of and 
whether they prefer to be a lackey (just follow instructions) or a full 
partner. Pin down some graphics specs now so you both agree on the goal 
and the quality standards.

<<There will be as much theory to explain as there will be procedures 
to write.>>

Ask for a list of resources where you can learn the theory if possible. 
Ideally, you want to annoy the engineers as little as possible, and 
that means coming to them with intelligent questions based on research 
rather than "I can't be bothered to research this, so you teach me" 
questions.

<<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.>>

Stick with what you know. Even good tools have a learning curve, and OO 
isn't yet supported as well as Frame. They seem to have a good 
community of users, but is it as helpful as techwr-l is for Frame and 
Word? Probably not yet.

<<I am not familiar with their technology, and they wanted it that 
way.>>

This can be a great advantage if the audience will be similarly new to 
the product. If not, you may need to learn enough about them that you 
can learn to think like them.

<<Their initial time estimate for the job is around 100 hours.>>

Entirely meaningless. Without a firm estimate of what the job involves, 
how can they or anyone else estimate it?

<<From my hours estimate, they will offer me a flat rate for the 
project.>>

Make sure that the flat rate is for a flat quantity of work (see 
above). And explicitly state the number of revisions you're prepared to 
do for that price. My standard contract is "this price includes one 
revision; after that, you pay me by the hour". This is a strong 
incentive for them to freeze the interface and get the reviews right 
the first time. You can be nibbled to death by endless revisions if you 
don't specify a limit.

<<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!>>

Pace Hackos, that figure is entirely meaningless. It represents an 
average for a huge number of projects, and doesn't include a standard 
deviation or other measure of variation. You may hit 1 hour per page 
for some topics, versus days per page for others. This depends on your 
skill and the difficulty of the material (including time required to 
research answers). You know the first part; you don't know anything 
about the second part.

<<My thought is that I would suggest it will take 125-150 pages to 
document their product, and 300 hours of my time>>

Without a firm target, how can you come up with any such estimate? Get 
details nailed down first, and only then should you start coming up 
with estimated lengths and times.

Once you've done this work, come up with a fudge factor: if they seem 
to be really competent project managers, this can be 10 to 15% to cover 
unexpected problems, but if they seem to be real chaos junkies, it 
might not be beyond reason to add 50% to your estimated cost. This part 
of the process is sheer guesswork, but you have to be aware that it's 
necessary guesswork.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart   ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
www.geoff-hart.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.