Bidding a first contract?

Subject: Bidding a first contract?
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Thu, 03 Nov 2005 09:53:44 -0500


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.



Follow-Ups:

References:
FW: bidding a first contract: From: Anonymous Poster

Previous by Author: Screenshots: Clearest way to indicate button/link/tab to click?
Next by Author: Project 11: developing a new ISO standard for managers of user documentation.
Previous by Thread: FW: bidding a first contract
Next by Thread: Re: Bidding a first contract?


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads