[First Business Systems Home]

Call now for Company Formations: 0800 0345 375
[Techscribe for high-quality, effective documentation]

PAGE 1 OF 2

WRITING A TENDER
by Mike Unwalla, MISTC

Mike Unwalla has been documenting software products since 1994. Two years ago he became a freelance writer. He has a background in both the English language and computer science. Mike can be contacted by email: mike@techscribe.co.uk

 

One of the hardest things to get right is the costing. I don't mean the price that you present to the client, but rather, your estimate of the time it will take to produce the work. Ideally, the estimate and the actual time that you spend should be the same. In practice, that doesn't always happen. I have a tendency to underestimate (call me an optimist), but it's getting better with practice. Keep a record of the time it takes for various jobs, and use those to help you estimate the current job.

Some IASIG members have had occasional problems with unscrupulous potential clients taking their quotation and then not engaging the author. Rather, the clients produced the work themselves or passed it on to others. Although you may not be able to prevent this entirely, there are a few things you can do to protect yourself.

  • Don't go into too much detail. For example, I typically just present estimated page counts for paper-based material and estimated topic counts for online help.
  • Make the detailed document plan a chargeable deliverable. Then even if you are not used for the project proper, you will be paid for the work that you have done.

Standard Terms and Conditions

Your T&C should contain information that applies to all the projects that you are likely to undertake. (You may find that some of these items are better specified in the quotation or in a letter of agreement.) You won't be able to cover all eventualities, but you will be able to produce a clear framework within which to operate.

One advantage of having a separate document for the T&C is that it doesn't contain anything confidential and so can be distributed freely. At least one member of the IASIG publishes his T&C on his web site for anyone to see. The table opposite shows the typical clauses that are contained in T&C.

Letter of Agreement

This can be just a brief letter stating

  • When the project will start.
  • A target date for delivery of each of the various items of documentation.
  • The charges for each of the deliverables (specify whether VAT inclusive or not).
  • Payment terms (you could of course put this into the T&C). Typically 30 days.

Since my T&C specify the responsibilities of the Subject Matter Expert (SME) for the project, I also specify who this person is (often the person who asks me to do the work).

Send two signed copies of the letter and two signed copies of both the other documents to the client. Ask the client to sign one copy of each and return them to you. Make it easy for the client and also enclose an SAE.

Other Issues

Should you start work before the paperwork has been signed by the client? It depends upon how sure you can be that a verbal agreement will be honoured. Sometimes, with the best will in the world, things go wrong. For example, in a large company, the person who initiates the job may be over-ruled.

In some organisations, the accounts department will not part with any money unless there is a purchase order. If this is the case, it is a good idea to obtain one before you start the project. On the other hand, for one client in a large organisation, I regularly start work without a purchase order (and without a signature on T&C etc); quite often, the job is finished before the purchase order is generated.

Professional Indemnity Insurance (PII) may be easier or cheaper to obtain if you have T&C, a standard contract, or something similar.

Should you have the T&C and other standard documents written by a solicitor or lawyer? It's not necessary. Any competent technical writer should be able to say in plain English what his or her conditions are. Nevertheless, it is probably worthwhile to have your material checked by a legal professional. For example, I wrote my T&C, based on others that I'd seen and the problems that I thought might arise with the work that I do. They were checked by a solicitor who showed me areas of omission and items that were ambiguous.

Final Comments

Both you and the client must be happy with the tender. The aim should be to clarify areas of potential confusion. Do not write a one-sided contract. Be fair.

Be prepared to negotiate. If a client doesn't like one of the terms or conditions, consider changing it. However, if it's fundamentally important, don't change it. Walk away from the contract.

Click here to download the TechScribe T&C.

There is some useful information on contracts (although with a US slant) in "Making money in Technical Writing" (reviewed on ISTC web site) by Peter Kent, ISBN 0-02-861883-1.

Finally, remember that although the T&C may state that additional work is an extra chargeable item, this doesn't mean that you always have to do charge more. There may be far more long-term benefit from (casually!) mentioning that you did the work but that you've not bothered to charge extra.

Acknowledgements

Thanks to all the IASIG contributors to the "Invitations to Tender" topic (started December 2000) and the "Terms and Conditions" topic (started August 1999). I have used many of the ideas and comments as a starting point for this article.

<< PREVIOUS PAGE

Clause Deals with

Basis of documentation

General rules or conditions about what will be documented. My T&C state that the documentation will be based on software that was provided at the start of the project. If this changes, then extra charges may apply.

Access to information

Who is responsible to supply information and organise access to these people. One member states that he won't chase reluctant suppliers or contractors, since this can be time consuming and costly.

Provision of materials or equipment

Who provides what. Generally not a contentious area. My T&C state that any third-party software supplied by the client or used in the production of the documentation will be a legal copy.

Approval of deliverables

The review and approval cycle. An important issue. How many revisions of a document are you prepared to make? What is the process for approval of each item?Some IASIG members ask for written approval of the various drafts.

Errors and omissions

Errors on your part. We all make mistakes, and this is an important clause. It's not designed to get you off the hook or excuse sloppy work. However, it will help to prevent disputes after the work has been completed. My T&C state that it's the client's responsibility to check the final documentation carefully, because payment of the invoice indicates that the documentation is acceptable. Doing things this way means that:

  • The final copy is checked carefully (in theory).
  • The client is happy with the work.
  • I know that I won't be faced with any additional workload if mistakes are found (having said that, if it's easy to correct, then just do it).

Additional charges

Charges that you will make in addition to the quotation. Some causes of additional charges are:

  • Additional work. For example, an extra software module was developed.
  • Site visits. You may charge for every site visit, or for none, or there may be some other costing mechanism. It doesn't matter, as long as both parties know in advance.

Timely disclosure

When one party notifies the other of unusual circumstances. Typically this will be "as soon as is reasonably practical". For example, if you badly miscalculate the target delivery date, then it's only fair to tell the client as soon as you know things have gone wrong. Conversely, if the client is not happy with your work, then you should be told early, rather than finding out at the end of the project.

Early termination

The procedure for terminating the contract in exceptional circumstances.

Confidentiality

States that both parties will treat all information supplied in strict confidence.

Copyright

Who owns what. This is usually not a contentious issue. When you produce work as a freelance writer you own the copyright. An easy way of assigning copyright is to state that as soon as final payment has been received, copyright is automatically transferred.

To protect copyright at the approval stage, one IASIG member gives only hard copy that contains his copyright on every page, along with the word "draft" and a print date. He doesn't give computer media at this stage.

If you include your name, company name or trading name anywhere on the documentation, you may want to add the proviso that if changes are made, the name should be removed. Of course, this might be quite hard to verify.

Intellectual property rights

Who owns any discoveries or inventions. Not an issue for the average technical writer.

Liquidated damages or late delivery penalties

One IASIG member works for customers that have late delivery clauses. To protect himself, he includes clauses in his terms stating he is not responsible for delays caused by:

  • Changes to the product.
  • Failure on the part of the client to provide information he has requested.
  • Slowness on the part of the client to review various drafts.

Additionally, he sets a cut-off date for modifications to the publication design.

Law

States the country under whose laws the agreement operates.

Circumstances beyond control

States that neither party will be responsible for factors outside their control.

Terms and Conditions

 

Download Article Microsoft Word document  PDF format

Mike Unwalla, MISTC
TechScribe
24 Spooner Road, Sheffield S10 5BN
E-mail: mike@techscribe.co.uk
Tel: 0114 266 6933

Affiliated to Independent Quality Authors on http://www.qualityauthors.co.uk

Article Disclaimer