There are a lot of bad examples of proposal outlines out there on the Internet. And many of them come from textbooks!
Here is an example. Take a look at this proposal outline derived from an “Advanced Technical Writing” course offered by a university:
Title
Summary/Abstract
Introduction/Background
Statement of the Project Problem
Recommendation/Solution
Objectives
Scope
Methods
Schedule
Budget/Pricing
Resources/Staffing
Conclusion
References
Then forget you ever saw it. You don’t want your proposal to be organized like this because it:
- Forces the decision maker to read halfway through it before they find out what you are proposing
- Patronizes the decision maker by describing their own background to them and then telling them what their problem is
- Saves the conclusion for the end, when that should be the place where a proposal starts
You see variations on this outline all over the place, probably because that's what people learned in school.
The biggest problem with the outline above, and the reason why it increases the odds of losing your proposal if you follow it, is because it is not written from the decision maker’s point of view. All the headings do is categorize information. The primary goal of a proposal is not to deliver information or to be descriptive. The primary goal is to persuade a decision maker. Instead of delivering information, you need to help the receiver make their decision. This may involve delivering some information, but it is in a specific context and is not simply descriptive. The difference is vital.
The best way to understand how to write a proposal is to put yourself in the shoes of the person making the decision. When someone asks you to do something, what do you need to see in order to reach your decision? The decision maker starts with questions and looks for answers. They don’t read your proposal. They look for answers.
When you are the decision maker, your questions might include:
- What am I going to get or what will the results be?
- What do you want (from me)?
- How much is it going to cost and is it worth it?
- What will it take to make it happen?
- What could go wrong?
- Why should I believe you?
Now pretend that you are receiving a proposal from someone who wants you to do something, approve something, or buy something. Think about the first thing you want to read. If you weren’t expecting to receive a proposal, it might be “What do you want (from me)?” If you were expecting the proposal, then the first thing you'll probably want to know is “What am I going to get?” This is closely followed by “What do I have to do to get it?” and “Is it worth it?” If you agree that it’s worth it, you’ll want to dig deeper and find out what it will take to make it happen. At that point you start looking for things that could go wrong and will want to make sure you can trust the person or company who brought you the proposal to deliver what they promise. If this is what the decision maker is looking for, then that is what your outline should be. You can use the questions above as your outline, but it's even better to use statements that summarize the answers.
If you're writing a proposal in response to a written RFP that specifies how they want the proposal organized, you must follow their outline. However, the evaluator still has the same questions and they still need to find the answers in your proposal. An excellent way to exceed the RFP requirements without increasing the cost of your solution is to do a better job of answering these questions, especially the ones they forgot to ask.
To win your proposal, you need to provide the decision maker with the answers they need and then motivate them to accept your proposal. You outline should be organized to meet their needs.
