I’ve written thousands of proposals over the years for projects ranging from $1,000 to $1,000,000. Of course there are strict bid situations where the job will be awarded on the basis of lowest price bid that meets the criteria. But that rigid structure is typically limited to public sector contracts. The bid selection process for almost all private sector contracts gives a bit more latitude. In this situation you do need to remain cost competitive, but you also have a much greater opportunity to win by gaining the confidence of the buyer.
Because I also serve as a consultant from time to time, I’ve also had several opportunities to be on the other side of the table. Reviewing proposals and recommending the best submission has given me the chance to actually see what other bidders are submitting. There’s a wide variety of styles out there — from the simple one page quote, all the way to a lengthy document stuffed with 50 pages of irrelevant fluff. Let me tell you, the vast majority of the proposals I’ve seen are awful. Either they don’t contain enough information to convey the concept of the project, or they go to the other extreme and give so much information that it becomes hard to figure out how it applies to this project.
Most of us no longer start from a blank slate when we write a proposal. There’s a handful of decent software solutions such as D-Tools, BidMagic, and DoveNet that make the process of selecting and pricing products much easier. And once they’re properly configured they can give us a fairly solid boilerplate proposal to work with. Even if we’re still using Word and Excel templates to start with, we still have a decent template to work with. But the key is to recognize this output for what it is: a starting point.
Before going on with the next step, let me expand for a moment on what I mean by having your templates properly set up. Anyone who’s gone through the process of using most line of business software knows very well that one of the most time consuming tasks is creating that list of products, prices and clients, and keeping those lists current. But what many overlook is the importance of the template forms themselves. These forms create the framework that contains the detail from those data lists. It’s within these forms and templates that all your verbiage exists related to scope, execution, expectations, and terms. It’s these parts, much more than the equipment list itself, that communicate to the client what you will do for them, and what they’re expected to do for you. In creating the boilerplate, you should attempt to cover as many different variables and situations as possible. Think of all the various kinds of projects you do. Try to think of all the things you’ve needed to communicate with your customer over the years. Make sure that’s all in the template. When it comes time to refine each proposal it’s much easier and faster to edit sections that don’t apply out of the boilerplate than it is to create new well written text just for this situation. It’s also very useful to sort it all out into logical sections, such as description (or scope) of work, standards of practice, customer expectations, terms, etc. It’s also nice to include a splash of color in your forms. Go ahead and use your logo in color, and use some color in the section headings and such. But, remember that when you email [or even the old fashioned fax] your proposal many people will print it on their black and white printer, so make sure that your color scheme looks good printed that way too.
So now that your software or template process has given you a proposal, now it’s time to read it. Yes, read it. Chances are that it’s not you who wrote the boilerplate in the first place. You’re using something provided to you by your company. Or maybe it’s been a while since it was written. Nonetheless read it in its entirety. Every section, every time — from the introduction to the very last signature line. Often these templates are shared amongst the whole company, and management may adjust the templates from time to time. Don’t expect that it always says the same thing. Try to read it from the client’s point of view. This client may not have done many projects like this. Or they may not be familiar with our industry in general. As you’re reading it, you should insert or clarify points that you don’t think will be obvious to them. You should also at this time remove those sections of the text that don’t apply to this project or client.
A good proposal needs to look professional. It shouldn’t look like a form letter that’s been annotated and marked up to fit. That would just suggest you’ve done it in a hurry and likely missed details.
- Never emphasize text with bold, italicized, underlined or highlighted words. Those tools are there for your reviewing benefit, and for special circumstances such as titles and captioning. They don’t belong in the middle of a paragraph. If you feel you need to emphasize something, do it when you present the proposal, not in the written document.
- Don’t repeat things. I often see something in a scope section that’s also in the terms section. It should only appear once, and it should appear in the proper section of the proposal.
- Keep in mind that most people don’t read documents, they usually skim them. When they’re looking to find something, they go straight to the section where they expect it to be.
- Don’t use too many sections or divisions. A common mistake is to break things up into too many sections. This actually makes things harder to find. Use sections for major divisions or big changes in topic. You might use sections for project description, equipment list, money and payment, who does what, etc.
- Use consistent fonts and formatting throughout the document. Keep like things like. Make spacing consistent. This just helps make it look well-polished. Some companies even recommend or require certain fonts, colors and logos so that all documents are consistent across the whole company. This is an excellent idea.
- Don’t pad or stuff the document. Try not to include references or case studies, or past projects in the body of the document. If you really think such things are useful, select them carefully that they relate specifically to this project, and include them as appendices.
When you’re done, read it again and make any further refinements that you find needed. Next, if you have the time, or if this is a valuable enough proposal, send it to a coworker to read. They’ll often find things missing that you kept in your head and never made it to paper. Since we’re very comfortable with what we do, we forget that we have assumptions that aren’t always obvious.
Lastly, it’s time to present your proposal. Arrange a time to meet with the client and go over the document. It’s at this time when you can walk through the process and emphasize the parts that are most important to them. You can assure them that you understand and have provided for their needs. They have a chance to ask questions and you can show them where it all appears in the document. Since you’ve read it, you’re intimately aware of what’s contained and where to find it. By this point, you will have a customer who’s very comfortable with what you’ve presented, and have a very good probability of turning that proposal into a job.