Some Hard Facts about Executive Summaries

An executive summary is a critical part of your response to an RFP. Even if the customer does not explicitly request one, make sure you prepare it.

The executive summary must address the decision makers’ decisive agenda. You must determine what their central concerns are ─ fast deployment, OPEX savings, increasing revenue, minimizing risk, or whatever the driving issue is that led them to issue the RFP ─ and convince them that you have the appropriate solution that will meet these concerns.

• The executive summary is the only part of your proposal that will be read by senior management and by all of the evaluators ─ the people who make the decisions and the folks who deliver the recommendations. It should provide a clear and concise rationale for choosing your solution. The reader should be able to easily understand your proposed solution and the unique benefits you have to offer.
• The executive summary is, first and foremost, a sales pitch, but you should not make claims of greatness without providing proof, and it should not include anything that is not amplified in the technical response.
• Evaluators are annoyed by an executive summary that is confusing or merely marcom gibberish. A poor Executive Summary will negatively affect final evaluation.
• The executive summary should be brief – about three (3) or four (4) pages. Always keep in mind that these people have another half dozen bids to consider. Don’t make it more laborious for them than it already is.

The following are a few relevant comments about the successfully preparation of executive summaries.

THE OPENING SECTION

You should begin the executive summary by:

• Presenting your company’s explicit experience in the field (expand on this as much as you can).
• Stating that you understand the customer’s requirements, and that you have a solution that meets these requirements.

It should be direct and specific, not abstract and conceptual. The evaluators must walk way with a clear concept of what you are proposing and how good it is. They should be able to grasp what is unique in your solution and, most important, why they should make the decision to go with you.

THE SOLUTION BEING OFFERED

This section should not be more than one page long. It should state concretely what you are offering and how the solution resolves the issues and problems raised in the RFP. Your discussion should center on relating the design of your solution to the customer’s major requirements ─ point by point ─ in simple non-technical language. Make sure that all subjects are balanced in relation to their importance in the RFP.

State your value proposition and competitive advantage in positive terms, not negative ones ─ stress what you can do, not what others can’t. You have to provide real added value in your proposed solution. So focus on the issues that are critical to the customer ─ you will score points.

Vendor selection is almost never about features ─ don’t waste space on describing your features unless they form a true differentiator.

The executive summary can be the best place for introducing “out-of-the-box” options that were not specified in the RFP but can make a lot of sense in resolving the customer’s concerns, e.g. hosting vs. in-network solutions, or benefits that are created by integrating the proposed solution with something the customer has already deployed, where 1+1=3. Another example is to offer a free trial, in the event that it was not required.

COMPANY PROFILE

Many people get bogged down on this section. If you have a working relationship with the company issuing the tender or ─ more important ─ with the department responsible, this section should be limited to a short description of the positive association you have with the customer.

If you have fragile relations with the group that issued the RFP ─ you have just experienced a bout of downtime ─ be very explicit about how your company is actively reorganizing its support department to better contend with such difficulties, without actually mentioning the events around the recent disaster.

Provide information about the team that you have assembled to work with the customer on this project. Don’t state that they have 48 combined years of expertise. Point out that your CTO heads the relevant IEEE standards committee. Don’t regurgitate a shortened form of each person’s resume. Explain why the background of each team member is relevant to the project.

PROJECT MANAGEMENT

A summary of the proposed deployment process is essential. If a Pre-Christmas delivery is important for them, you must present a list of milestones showing how you are going to get there on time. It must be convincing. Whatever you do, avoid dumb statement such as: “Project scheduling will be developed during the detailed design stage”.