WRITING A TENDER
by Mike Unwalla, MISTC

This article stems from a question that was asked to the IASIG¹. The enquirer had been asked to tender for a job, and since he'd never done this previously, he wanted to know about the potential pitfalls and whether IASIG members could offer him any tips.

Although I have written the article from a personal perspective, many ideas and working practices have also been mentioned by others in the IASIG who contributed to the discussion. The issues addressed are not exhaustive, and on the other hand, some may not apply to your situation. Since I produce software documentation, many of the examples relate to this. Also, this article does not in any way deal with IR35² issues. My understanding is that it is your working practices (and not the content of any contract) that determine whether or not you fall under the IR35 ruling.

Introduction

What is a tender? There are various definitions, depending on whether one takes a legal, a commercial or just a common usage perspective. For practical purposes, we can say that a tender is "an offer to do work". In practice, the offer will be written, and the cost of the work will often be fixed.

Is there a legal requirement to ask for or to supply a written tender? For most organisations that engage writers and for most writers, the answer is no. You could just make a verbal offer to "do the right thing" by the client³. If that works for you and the client, go for it. However, generally it's a rather foolish approach. The problem is that your interpretation of "the right thing" may be very different from the client's interpretation. Problems are compounded by there not being anything written down to which to refer.

So, put it in writing. There is no rigid format that you need to follow. I use the following documents:

• A written quotation. This contains the background to the project, sets limits to the scope and outlines the deliverables. It also shows the price for each of the deliverables.
• Terms and conditions (T&C). This is a standard document which doesn't change. It describes the duties and responsibilities of both parties.
• A letter of agreement. This basically ties the quotation and the T&C together, and specifies variables such as the start date.

These three documents are described in more detail later in this article.

¹The IASIG (Independent Authors Special Interest Group) is a group of freelance technical authors who are all members of the ISTC.

²IR35 is a recent item of legislation that allows the Inland Revenue to treat certain types of contractor as employees of the company in which they are contracting, even though these contractors are operating as limited companies. As an aside, sole-traders have always lived with the possibility of sometimes being classified as self-employed and sometimes being classified as an employee.

³Throughout this article, I use the term "client", even when strictly it should sometimes be "potential client".

There's no fixed order in which to send these documents. Sometimes I send the T&C before producing a quotation, sometimes with the quotation, and sometimes after the quotation has been agreed in principle. Email is a great way of initially sending these documents. If the content is acceptable, I then send paper copies for the client to sign.

The Quotation

Clients typically want fixed-price quotations for specified deliverables. Sometimes, that's not possible, and you will have to provide an estimate. Fine, as long as you and the client are clear about this.

Before producing the quotation, find out as much as possible about what will be documented. For example, I send clients a checklist that asks questions about the product and the users. I then include this information in the quotation.

In the quotation itself, specify these things:

Basis of the quotation or tender. For example, I state that it's based on the software that I've seen and the number of screens specified by the client. If more functionality is added later, or if there turn out to be many more screens than expected, there is a good case for requesting extra payment.

Background to the work. Include a few paragraphs that give a high-level overview of the product and what it's used for. This helps to ensure that you are on the right track; the client can easily see if there are any fundamental misunderstandings.

User experience. This is very useful. Even if a full user analysis is not possible, at least you can specify what they are expected to know or not know.

Peripherals and ancillaries. If the subject is part of a system or process, one IASIG member specifies the inclusion of references to other equipment systems which are necessary to give a complete picture of the subject he is documenting.

Deliverables. Itemise each deliverable. For example, for a small project you might just specify a price for the final deliverable. On the other hand, for a larger project you could specify a draft as being a deliverable. Some IASIG members suggest that you can even ask for money before starting a project.

Sometimes you can give clients a set of options for the deliverables. For example, if cost is an issue, give two options: the cost for a full and comprehensive user guide and the cost for a brief getting started guide. This gives the client some choice, and in any case will certainly make the client think about what is needed.

Format / specification. If there is no formal specification, one IASIG member defines things such as the overall layout (e.g. A4, single-sided) or format (e.g. Microsoft Word, HTML, PDF). Alternatively, you could present this information as part of the deliverables.

Validity period. State for how long the quotation is valid.

Problems with the Quotation

Sometimes, there isn't sufficient information from which to produce a quotation. This is likely to happen with larger projects. One solution is to offer the client a fixed price scoping project in which you spend a few days or weeks investigating the project. Another alternative is to work for a daily or weekly rate, but clients aren't likely to be keen on that, since they want to know for how long they will be engaging you.

NEXT PAGE >>

 

Download Article   

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