When you work for an entrepreneurial, service-oriented company in any technical profession, you will no doubt someday be asked to write a proposal for supplying services to a prospective customer (from here on out these will be referred to as clients, even though technically they are not a client until they’re actually a paying customer). It will probably be a struggle when you do it for the first time. Someone will throw you a previous proposal submission and tell you to “rewrite this to provide services x to client y.” With luck, that previous proposal was outstanding; otherwise it will be awfully hard to produce one that is. One also hopes that your company has properly vetted the client (see The Proposals Conundrum) so that you don’t waste a lot of time doing all the things I’m about to describe to you; unless of course you just need the practice.

Technical writing courses provided by Universities have probably not prepared you with the skills and information you need to deliver such a technical document. Hopefully, you’ll be segued into this gracefully, perhaps as a contributor at first to a proposal that is actually a group effort, with someone who has more experience guiding you, and the rest of the group, to make outstanding contributions. In the worst case, your mentor on this assignment may not have a clue as to what constitutes an outstanding proposal.

So how do you go about delivering a top notch technical proposal? A good first step is to know what needs to be in it. Today we’ll discuss in general terms how technical proposals should be constructed, give you some guidelines on what content to include and mention a few specific types of content that should be excluded. While I cannot guarantee that the first proposal you produce after you’ve read this article will be outstanding (practice makes perfect), I will promise you that, if you follow the suggestions I’ll make, your results should be better than they are right now.

Form or Content?

I wouldn’t say that there’s a raging debate over which is more important, form or content. It is generally agreed that both are important. But if you were forced to choose your priority, which would it be?

In case you’re wondering what I mean by form, it is the look and feel, including some pretty graphics; the grammar, punctuation and spelling. Graphics should normally be considered content in that they should be telling a story, but if at all possible, make those graphics pretty as well, so that you also have excellent form.

Content is like the meat in your sandwich. If it is thin, the sandwich probably can’t be considered outstanding. If I had to choose, I’d choose content over form every time, but I would always strive to have both.

This article is geared much more towards content, and I will discuss form only in this section. You don’t need a university degree in English (or whatever the language of your proposal) to write English well. Your word processor is your friend; most of these will tell you when you make spelling or punctuation errors, and even warn you when you make egregious grammar errors as (horror of horrors!) when the passive voice is used.

But you know what? Even if a few grammatical errors manage to avoid the grammar-checker, you’ll probably be forgiven for them if both the overall flow of your presentation and the content itself is good. Organize your thoughts in a logical sequence and then order the sections of your proposal to reflect this. Try to make each paragraph lead your reader logically into the next.

At the end, it doesn’t hurt to run your proposal past someone that does have a degree in English (or is simply an excellent proof-reader like my Simple Talk editor), to knock out any of those tiny little errors that will inevitably creep in. Since most proposals are a joint effort, that person should also note, and fix, any stylistic inconsistencies between writers of different sections.

The Executive Summary

The penultimate step when writing a proposal is to compose an executive summary. Even though you do this near the end of the process, where you draft the quotation, this section should actually appear as the leading section of your proposal. You do this work near the end because you’re going to summarize the content that you have already developed in the sections that follow, so you need to tell your audience what they can expect to hear in those details.

In the executive summary section you should follow certain guidelines. These are:

• Keep it short. This section is for busy executives who may not have the time available to read the whole proposal, so in nearly all cases the summary should be limited to no more than two pages, but one page is usually better.
• This section will be read by everybody, so it is important that you choose your words carefully to “grab” and engage the reader so that they’ll want to hear more from you.
• There is no better way to engage the reader than to show that you fully-understand the problems or issues they are currently facing. If you include a summary of the benefits that your solution will deliver, it will show that you have done your homework and “feel the pain” that your solution is designed to alleviate.
• The executive summary should describe, as briefly as possible, how you intend to implement the solution. Any innovative aspects of your proposal should be highlighted, as these are also attention-grabbers.
• You should include the time-frame in which you expect to deliver the work.

The executive summary should clearly and accurately reflect what the client is about to hear from you in the main body of the proposal.

Some may disagree, but I prefer to keep pricing out of the executive summary for two reasons. The first is that you don’t want to distract the client with the price before they understand the deliverables, even though many may do that for themselves anyway, because if you are selling services you should be selling value and not low cost. The second reason is that it makes the proposal easier to maintain should you need to make revisions to it. Keeping it out of the executive summary avoids the possibility of forgetting to update it when pricing changes. You should issue a quotation to accompany the proposal, which is the only place where a price is mentioned. You can refer in the executive summary to the “accompanying quotation” but if you also include a quotation number, remember to maintain it if the price undergoes revisions.

Technical vs. Commercial

Some prospective customers will insist that commercial aspects of your proposal be separated from the technical, so it is important to know what belongs where. Normally your company will have a proposals template that includes company logos and such, so you should ensure that the appropriate sections can be easily stripped out to generate both when that is necessary. There is no sense in maintaining three templates when you can maintain one and easily separate out the terms within the space of twenty minutes or so.

The executive summary need not be different for technical vs. commercial proposals. In fact, it should be the same as long as you’ve kept pricing out of the executive summary.

Technical Proposal Content

The content of a technical proposal is generally pretty consistent across services, with a few minor exceptions in the details that may only be valid when software solutions are being delivered:

• Benefits of the Proposed Solution
• Scope
• Platform
• Roles and Responsibilities
• Process
• Deliverables
• Delivery Schedule

The details of the benefits should be based on an economic analysis that the client has worked with you to develop. Benefits can usually be equated to increasing revenue, reducing, or avoiding, costs and improving customer service. Benefits can often be described as avoidance of the pain points for the client that are suffered in the current way of doing things.

Scope is extremely important, because if it is not well described, it will make or break the profitability of any proposal that ends up being a contract. I often like to describe the scope in terms of what is not in it. It is difficult to argue whether something is in scope or not later, when it has already been clearly ruled out in the proposal in this manner. You should be thorough, clear and as detailed as you can be when describing the scope; however you must strive to keep the overall size of the proposal within a reasonable limit. Scope should also describe how what is being delivered will fit into, augment, replace or become a part of the prospect’s business process.

The technical platform is not invariably something that is specifically software-related: Platform should be considered part of the scope because, if it changes in mid-project, it can have dire consequences for the overall profitability of the project.

Describe the Roles and responsibilities of the project team, and perhaps even include well-crafted resumes of your company’s specific team members. You must not forget that the client is one of the stakeholders, and is therefore a part of the team. Be sure to spell out clearly what their responsibilities will be expected to be, so there will be no surprises later.

The ‘process’ section is often a boilerplate that describes the process by which the project will be delivered to the client. In software development, when you describe the implementation and deployment process, there are some alternative methods available. It may be best to describe the alternatives briefly and make your best recommendation, on which you base your price point, and then state that in the quotation.

Deliverables are the hard and soft work-products that the client can expect from the project. Training is a soft work-product. A more tangible, hard, work-product is the delivery of a functioning software system.

The delivery schedule is a series of clear milestones that will be achieved during the course of the project. Present these with care; avoiding specific dates. All milestone “dates” should be expressed as a week or day number (e.g., +4 may mean 4 weeks into the project) based on a projected project start date that is that date on which the proposal was accepted, the contract was signed or, in some unusual cases, when the prospective customer signed-off the final project requirements.

Commercial Proposal Content

The commercial content within a proposal is about your company, and about the price and payment terms within which you will deliver the work. A separate quotation can be considered a part of the commercial proposal.

• Your Company’s Profile
• Reference Customers
• Effort Estimate
• Payment Terms
• Price (preferably in a separate, attached quotation)

Your company information and the reference customers will hopefully be maintained in a suitable format by your Marketing and/or Sales department. Reference customers should be limited to a list of prior customers for which you have delivered similar work.

The estimate of the extent of the work is arguably the most important part of any proposal, as it is usually the main driver for the calculated price. If you guess too high then you won’t win the business. Guess too low and you may win the business but not make a profit. The word “guess” was not chosen lightly. Unless you are a soothsayer, a guess is all that it will be. Hopefully after you’ve done it a few times, your guesses will get better.

Payment terms and prices may both be relegated to a separate quotation. Usually project pricing is either fixed or based on “Time and Materials” (T&M), which really just means you charge for every hour or day your team actually puts into the work. T&M projects should inherently be profitable, since you should be charging a rate that is a mark-up of your cost. Fixed price projects are the main target of this article, because it is those that may deliver in the red (at a cost to your company).

Risks vs. Reward

Before any proposal is submitted, a risk assessment and analysis should be performed on the work being proposed. You should know well the capabilities of your team and how they will be stretched to deliver on the technical aspects of the work. Make no mistake about it; process does not substitute for qualified, experienced team players. Process can only help to make the delivery better.

More difficult to assess, particularly if you’ve never done business with them before, are the technical skills, process and personalities that the client will engage to deliver on their responsibilities. Critical areas where the client’s support is required should be assessed in terms of worst-case scenarios. Assess all risks in terms of their impacts to effort, project duration and project quality, realizing that some unmitigated risks that materialize may affect you in several ways.

If you’ve never done such risk analysis before submitting a proposal, trust me when I tell you that one day you’ll wish you had. It is important to know what and where the risks lie, so you can then assess what a reasonable reward for the work should be. The higher the risk that you will deliver late (or otherwise impact the cost of delivery), the higher you should assess your fair return.

Should you describe project risks within the proposal? The answer is yes, provided those are risks that are within the control of the client to mitigate. For example, you don’t want to note as a risk that your team is inexperienced in delivering this kind of work. That is something that should be within your control or that you can mitigate in some fashion. If it is something that is within the client’s control, noting the risk within the proposal may lead the client to offer you some mitigation during negotiations on the price. Just be sure you document somewhere what the client offers as part of the mitigation strategy so you can hold them to their responsibilities.

Always include some sort of contingency or buffer on the estimated work effort as a way of generally mitigating the known risks. The amount of contingency to include will depend on how risky you expect the project to ultimately be.

Inappropriate Content

I’ve already mentioned that I believe that it is inappropriate to include the price in a proposal: put it instead into an accompanying quotation. One of the reasons I said this was to avoid having that same price in multiple places. The same is true for any redundant content – remove it. Say it clearly once and you won’t need to say it again. This will save you a lot of time and possible mistakes if your proposal, as is likely, needs revisions.

Content in the technical part of a proposal should not be lecturing, academic or included to show your prospect “how much you know” about a particular business domain or process. Do not include any content that is not laser-focused on describing what the client needs or how your solution is going to meet your clients’ needs.

A lot of people ask me how many pages long a proposal should be. Unfortunately, there is no clear answer to this other than “as short as it can be to describe the requirements.” If you produce a proposal that is 100 pages long, it had better be for a seriously large project. You may need many words to respond to a very detailed Request for Proposal (RFP) in order to address all points that are required by the RFP.

No matter how brilliantly your company is able to deliver work or has in the past delivered to other clients, that brilliance has no place whatsoever in the proposal if it has little or no relevance to the proposed work.

Many proposals embellish on what can be delivered to a certain degree. The amount of embellishment is between you and the people that are running your company. The safest approach, and the one that I recommend, is to under-promise and over-deliver.

A Definition of an Outstanding Proposal

To remain true to the title of this article, I will now offer a definition of what may constitute an outstanding proposal. To quote Steven Covey, you should “begin with the end in mind.”

A proposal could be outstanding if it wins profitable business for your company.

The important thing to note about this definition is that the proposal must both “win the business” and be eventually delivered at a profit for your company. If the project was not successful (see How to Avoid Software Projects Failing), it probably was not profitable either.

Winning the business isn’t particularly helpful to your company’s bottom-line if the subsequent project was not profitable. There are, to be sure, proposals I wouldn’t consider particularly outstanding that went on to win profitable business for the company. They probably couldn’t be considered outstanding because they simply didn’t flow well, or had many errors in form. Regardless, the client in those cases may have overlooked those things, and seen good or adequate content, decided in your favor and your team then went on to deliver a profitable outcome. So a proposal can’t be considered outstanding merely because it meets the profitability component of the definition. You have to assume that your prospect will be more discerning.

On the other hand, a proposal can never be considered outstanding if it does not succeed in winning the business in the first place. In those cases, it doesn’t matter how good your form was, nor how convincing was your content. If you did not win the proposal and the prospect tells you it was because your price point was too high, this is a lesson to learn for future proposals – that you should figure out ways to reduce your risks.

Summary

It can be a challenging, interesting and rewarding task to write outstanding proposals once you actually win some profitable business for your company. As a learned skill, it is something you will improve at over time. Never be disheartened if the first few proposals you submit do not win the business, as not all proposals are winners, and that includes some really good ones I’ve seen. Remember that circumstances beyond your control may ultimately decide the winner and the losers.

When writing any proposal, stick to what is relevant to the client: what are the benefits, what is the solution and how will that solution deliver the stated benefits. Avoid superfluous nonsense in your proposals, keep them short and focused and always, always be prepared to deliver on whatever you promise.