The Proposal Writing Cheat-Sheet

aka ‘Proposals for the Weary’

So, 2009 is nearly over. Aren’t you thrilled? Even if you’ve had a cracker of a year, it’s been a long one, and pretty much everyone is ready for a break. However… Since 50% of my training enquiry e-mails lately have centred on proposals, proposal writing and proposal writing training, I’ve put together a brief cheat-sheet for you, so that when you go back to work in ’10, you’ll have the right proposal ammo.

(This article is an absolute must-read for salespeople, marketers, management and anyone else who has to persuade prospects, in writing, to part with their money.)

What’s a proposal for?

The proposal writing-and-presentation process is grounded in the belief that a partnership should develop between the supplier and the client: the supplier has the ideas, capacity and products to solve problems, while the client has the financial resources. Bring the two together, and the result is a collaboration. Assuming, of course, that the the client likes what the supplier has to say. So, read on…

Let’s consider three things:

1. The goal of a proposal is to persuade: “Here’s what I want you to conclude, and here’s why…”

2. Most proposal evaluators don’t want to be there: “Here is what I hope you’ll read and here’s the obligatory detail that you’re not going to bother with…”

3. A winning proposal is easy to evaluate. Picture the evaluator with a checklist in hand going through your proposal – check, check, check. State conclusions that reflect the evaluation criteria, and then explain how or why.

There is no universal standard for layout or composition of proposals. If you think about this, it makes sense. A proposal is intended to persuade someone. And what’s required to do that is up to the person being persuaded. In short, if you want your proposal to succeed, you must know your reader. If your reader wants:

• … detail, give it to them. If they don’t want to do a lot of reading, keep it short.
• … references, give it to them. Otherwise, don’t.
• … pricing, give it to them. If they’re not ready for pricing, don’t give it to them.
• … contractual details, give it to them. If they’re not ready, don’t force them.
• … to know who will be doing the work, tell them. If they don’t care, don’t tell them.
• … things presented chronologically, organise your proposal that way.
• … information organised functionally, organise your proposal that way.

If you don’t know the answers, find them out. And if the reader doesn’t know what they want or need (this happens often!), give them criteria to help them figure it out.

So, define your readers

The main aim of any proposal is to compel the reader to do something: purchase goods or services, fund a project or implement a programme. Your reader will evaluate your plan according to how well it answers questions about what you’re proposing, how you plan to do it, when you plan to do it and how much it’ll cost.

To answer these questions, you must uncover the level of knowledge your audience possesses. You must also find out whether your readers are members of your technical community, your language community, or both. So, when putting pen to paper or finger to keyboard, stop for a brief moment and ask yourself:

1. Who will be the primary readers of this document?
2. Who will be the secondary readers? Will there be any other readers?

The key is to focus on the primary readers, with slight attention to the secondary readers. Obviously, there’s no way of knowing who else may stumble across your document. Here are some things to think about when defining your audience:

• Can I describe my readers? Who exactly are they?
• What is their position within the company or in general?
• What is their background?
• How much do they already know about my topic?
• What are their needs?
• Can I guess what their feelings toward my document will be?

Tip: For readers outside your specific area of expertise, you might provide an executive summary written in easily accessible language. Or, you might include a glossary of terms that explains technical language. You can also attach appendices that translate technical information into generally understood language.

Once you have a basic picture of your audience, try to understand how they work.

How your readers read

Proposal readers seldom read proposals word for word. They scan – choosing individual keywords, sentences and paragraphs of interest while skimming over the rest. Morkes and Nielsen have established that 79% of proposal readers scan any new page they come across; only 16% read every word. (Who cares about 16%?)

Why scan?

1. First, it can be uncomfortable for the eyes to read reams of text. Think about it.
2. Second, the reading experience fosters a certain amount of impatience.
3. Third, proposal readers are ‘busy and important’ - they want to get to the facts.

Give them all the facts

Here’s a simple approach to help you cover all the bases in your proposal. For each requirement that you must address, make sure you answer: who, what, where, how, when, and why. Repeat it til you have it memorised. Yes, really.

• Who: who will do the work, who will manage the work, who the customer should call if there is a problem, who is responsible for what…

• What: what needs to be done/delivered, what will be required to do it, what the customer can expect, what it will cost…

• Where: where the work will be done, where it be will delivered…

• How: how work will be done, how it will be deployed, how it will be managed, how you’ll achieve quality assurance and customer satisfaction, how risks will be mitigated, how long it will take, how the work will benefit the customer…

• When: when you will start, when key milestones will be scheduled, when the project will be complete, when payment is due…

• Why: why you have chosen the approaches and alternatives you have, why the customer should select you…

These key areas can help you to ensure that your proposal says everything needed to answer unasked questions. For each customer requirement, go through the list.

What’s it made of?

A typical business proposal might include:

• An Executive Summary… introducing your company, what you will do or provide to the customer, and how the customer will benefit from what you propose.

• A statement of work or technical approach… describing what you will do or provide, with an implementation schedule and description of deliverables.

• A management plan… describing how you will organise any work to be performed. A schedule of milestones or allocation of resources may be provided.

• Corporate qualifications… that describe your capability to do or provide what you are proposing. Relevant prior experience is usually highlighted.

• A staffing plan… that describes how the project will be staffed. If particular people are important to the approach, their resumes are usually included.

• Contracts and pricing... If the proposal is being used to close a business deal, business and contractual terms are usually provided.

• A call-to-action… The closing paragraph of your proposal should contain your ‘call to action’, where you say what you want to happen next.

Some clients set a page limit. Some don’t. Some will tell you the format/layout to use, and some won’t. Some will tell you what evaluation criteria and process they’ll follow. And some won’t. Bottom line: the customer sets the standards and defines the rules.

Tip: If your proposal is going to be submitted to Government (via an RfP), its composition and layout may have regulatory requirements to comply with.

And in the end…

Take as much time as you have available to proof-read the document, have a colleague check it for you, and send it off with confidence. Of course, if you get stuck, or you simply don’t want to have to worry about all this stuff, contact me.

www.tiffanymarkman.co.za