What Is Your Proposal's Core Theme?

The best proposals have a story to tell. That's the proposal theme, a central narrative that presents the key benefits your firm has to offer. It's the unifying storyline that weaves all proposal elements into a cohesive message. Proposal experts say that a compelling theme is the most important feature of your proposal.

Yet you'll be hard pressed to discern a theme in most technical service proposals. Most appear to be a loosely-related collection of information presented in fill-in-the-blanks fashion in response to the RFP. They are often prepared by multiple writers who have made too little effort to define a common thread among their individual contributions. The results come off as piecemeal and unfocused.

That's your opening. By presenting a clear theme in your next proposal, you can separate your firm's submittal from the pack. When I reflect back on the most rewarding (and surprising) proposal wins in my career as a proposal manager, the common element in all of them was a strong core theme. Here are a few examples:

• National contract for O&M of groundwater remediation sites. Against long odds, we took a bold approach, diverting somewhat from the RFP by offering a strategy for moving as many sites as possible to regulatory closure rather than simply maintaining their operation. Our theme was a game changer that eliminated most of our competition and positioned us as the front-runner. For more of the story, check out this earlier post.

• Open-end environmental services contract for a major airline. Lacking any airport experience, the theme of our proposal centered on how we would provide the client superior service. We knew that four of the five incumbents were not being renewed due to service problems. "Why is no one else talking about this?" the client asked in the interview, "You guys are the only one and this is the primary issue."

• Regional wastewater collection system. The County faced the expensive prospect of having to pump and haul wastewater if the collection system wasn't in place in two years. So we naturally focused on the schedule in our proposal. Other firms did as well, but none went so far in defining creative technical and management strategies for shortening the schedule, nor did anyone provide as much specific proof that they could deliver.

• Civic and performing arts center. Our firm was local, but not as credentialed in this type of project as several of our competitors. So the theme of our proposal centered on our superior knowledge of both the client and the community. We outlined an elaborate process for engaging key community "influencers" in the design process. To make up for any perceived technical shortcomings, we assembled a top-notch team of subconsultants, plus described how they too would interact with the client and community.

The above examples may not sound all that different to you compared to the usual "selling points" included in A/E firm proposals. The key difference is in execution. A proposal theme infuses the entire document while the familiar key messages or "hot buttons" are often limited to a few scattered mentions (e.g, in the executive summary).

What technical professionals, and even some proposal specialists, often overlook is the fact that proposals are more likely to be skimmed than read from cover to cover. A few isolated selling points easily can escape notice, while a proposal theme--presented appropriately--is readily evident. Below are some suggestions for developing and presenting your proposal's core theme:

Start by uncovering the client's real needs and priorities in advance of the RFP. Defining the right proposal theme depends on your understanding of the project from the client's perspective. Last week's post offered advice on what questions to ask during the sales process that will provide your firm with that insight.

Identify your proposal's core theme. This is not your firm's biggest point of differentiation, per se. Keep the focus on the client, not your firm. So your proposal theme in essence defines a distinctive benefit your firm can offer the client. In the examples above, these included (1) a better program strategy with substantial cost savings, (2) a distinct client experience and working relationship, (3) an innovative approach to meet a critical, tight deadline, and (4) a collaborative approach to reach consensus with diverse and crucial stakeholders.

Determine how each major proposal element will tie in with your core theme. These elements are often prescribed by the RFP. But you can distinguish your proposal by making them all resonate with the overall theme. If you have multiple writers contributing different parts of the proposal, give each a clear vision and outline that enables them fit their parts into the central narrative.

Present your theme in a skimmable manner. Skimmability is the overlooked proposal differentiator. Hardly anyone does this! Use graphic elements, bullets, boldface headers, custom dividers, and an economy of text to make your core theme readily discernible, even to the reviewer who skims large portions of your submittal. Indeed, a compelling theme can draw the reviewer deeper into your proposal and encourage more detailed reading.

Proposal themes are a relatively simple concept to grasp, yet just challenging enough in implementation to leave out most of your competitors. I've seen many a proposal, even by the largest, most reputable firms, that lacked a coherent theme. Here's a prime opportunity to help level the playing field.

Proposal Planning Questions

If you're poring over the Request for Proposals trying to learn what the client really wants, you're looking in the wrong place. I've yet to see an RFP that provided the most important information I needed to write a winning proposal. Yet amazingly, many proposals are prepared with little more insight than what can be gleaned from the RFP. My advice: Never trust the RFP!

Why not? First of all, the true selection criteria usually don't appear in the RFP. Most clients are looking for someone they can trust, someone they feel comfortable with, someone who most understands what they want and offers the best solution. Ever see those criteria in an RFP?

Most of the time, the successful firm is the one that has developed the strongest relationship with the client before the RFP was released. No matter how objective clients may try to make the selection process appear, it's not. They hire the firm that "feels" right and score the criteria to get that result. You won't find that mentioned anywhere in the RFP, of course.

Obviously I'm not suggesting that you ignore the RFP. Quite the opposite. You should slavishly respond to every detail of the RFP. Organize your proposal precisely as the RFP specifies, provide all the requested information, and make it easy for the client to evaluate your proposal based on the published selection criteria. Just don't assume that will be enough.

A really strong proposal should answer most of the questions listed below--even though they may not be mentioned in the RFP. That's the feedback I've gotten from clients over the years. There's a catch, of course. Unless you've been talking to the client before the RFP is released, you'll not be able to answer most of these questions with any confidence.

That's why the time to start considering these questions is during the sales process, not just before you start the proposal.

Executive Summary

Here's where I'll generally take exception with the RFP. I almost always include an executive summary, although the RFP rarely calls for one. This is the essence of your proposal, reduced to a few pages. The primary focus of your executive summary should be answering the following question:

What are the 4-5 most important benefits you will deliver on this project? These constitute the key themes that anchor your proposal. Present them from the client's perspective, converting features (e.g., your firm's experience) into client-centered benefits (e.g., shortening the schedule by employing output from a previous project). Apply the "so what?" test to help you identify these core benefits.

Project Understanding

You should demonstrate in your proposal that you understand the underlying issues, concerns, problems, and challenges associated with the project. Key questions to answer include:

What are the needs driving the project? Look beyond technical issues. Consider strategic drivers (economic, competitive, political, operational, mission-critical). Also consider personal needs (human impacts and benefits).

What is the client's vision for the project? What does the completed project need to achieve? What does it look like in the client's mind? Keep in mind that when we speak of "the client" we're usually referring to several decision makers, each of whom will have a different definition of success, as well as different priorities and concerns. Your challenge is to synthesize those different perspectives into a cohesive vision.

What are the client's priorities and concerns? What aspects of the project matter most? Cost, schedule, quality, outcome? What is the client most worried about? What are the critical success factors (the things that absolutely have to happen for the project to be a success)?

What are the greatest challenges? These may link to the client's greatest concerns or to the special challenges the project presents to the consultant or design firm.

What other stakeholders are there and what are their priorities and concerns? In some cases, you may need to elevate this issue in the mind of the client. Regulators, the public, affected land owners, special interest groups, or other third parties can have a crucial role in the success (or failure) of the project.

Project Approach

Writing the project approach should come natural for most technical professionals. But often they overlook important aspects of the project, such as addressed in the following questions:

Why did you select this solution over other possible alternatives? Share your thought process; don't just make a recommendation without offering an explanation of how you got there. Is the client biased towards a specific solution? Do you think it's the right one? If not, how are you going to present what you believe to be a better option?

What are the expected outcomes? Be specific about what the results of your proposed solution will be, expressed in terms that directly link to the clients needs and concerns. Quantify and offer supporting evidence where you can.

How will you execute the work? Many technical professionals focus on what will be done, but say little about how it will be done. Yet this is an important matter for many clients. How will you manage the project to ensure it goes according to plan (assuming you have a plan!)? How will you keep the project on schedule and within budget while meeting quality expectations. How will you effectively allocate and manage staff and other limited resources?

What are the potential risks and how will you address them? This is a critical concern for most clients that is often ignored in our proposals. Don't be afraid to describe what could go wrong as long as you have a plan to prevent and mitigate those risks. That discussion can prove to be a key differentiator because so many competitors avoid the subject.

How will you optimize the working relationship and deliver a great client experience? This is a vital issue that you'll rarely find mentioned in the RFP. What's it going to be like working with your firm? How will you make sure the client has an exceptional experience? Despite the importance of these questions to clients, few firms give much attention to this issue in their proposals. Don't be among them. Ideally, you've already demonstrated how well you serve the client during the sales process.

How will you effectively engage other key stakeholders? The importance of this issue was noted above. Hopefully you've discussed this with the client, because some are reluctant to proactively involve stakeholders (even though they should). Don't address this if you're not sure of the client's position on the matter. But if you are, outline your plan for effectively interacting with and involving those other key parties.

Qualifications & Experience

One of the main reasons not to trust the RFP is the over-emphasis on qualifications and experience. These are considered more objective selection criteria, but in fact they usually fail to meaningfully differentiate competitors. Yet clients rely on them heavily nonetheless--at least publicly--and seduce many technical firms into putting more emphasis here than on the more important factors outlined above. Don't fall into that trap!

Of course, you still want to put your best foot forward in describing your qualifications and experience in your proposal. Answering the following questions will help:

What are the benefits of your past project experience? So you have more relevant experience than your competitor. Can you demonstrate the benefit of that added experience in terms that really matter to the client? Can you do the project faster or for less cost? Can you minimize some risks or eliminate some uncertainties? Don't assume that simply being able to list more projects gives you an advantage. You have to answer the question: "So what?"

How did you add value? I've found that most technical professionals struggle to answer this question. Simply completing the project scope is of limited advantage; most competitors have similar experience. Instead, can you describe how you exceeded expectations? How did you provide benefits beyond the norm? What did you provide that your competitors wouldn't (or couldn't) have? Hint: Look beyond the technical elements of the project. How did you meet the client's strategic and personal needs?

How did members of your project team contribute to the above highlights? Which ones worked on the projects you chose to feature in your proposal? What were their specific contributions? These are important questions for many clients. They want to know that the specific individuals assigned to their project were involved in the past work you offered as most relevant.

If you can answer the questions listed above, you are clearly in position to put together the winning proposal. Part of this is due to the insights you can demonstrate in your submittal. Of still greater importance is the relationship with the client that you must have developed in gaining those insights.

So don't wait on the RFP to learn what needs to go into your proposal. Start asking the most important questions right now.

Preproposal Positioning

The most important steps toward preparing a winning proposal are taken before the writing even begins. Clients generally don't like to admit it, but they usually have a pretty good idea who they want to hire before the RFP goes out. That's because at least one firm has positioned themselves for the win in advance of the proposal.

That's not to say that proposals don't matter. I've been part of several successful proposal efforts where our firm was clearly not the forerunner going in. But positioning your firm before the RFP can give you a virtually insurmountable lead, in part because it enables you to write an unbeatable proposal.

So what can you do to position your firm for the win? Here are some key goals to pursue during the sales process:

Build the relationship. Not every client wants to be your friend, but most will warm up to those who excel in meeting their needs. Those needs extend beyond just the technical scope of work; clients have business challenges and personal preferences that incline them to favor those who are most responsive in addressing these. Bottom line: Become a valuable resource to the client, and demonstrate that you genuinely care.

Manage the complex sale. In virtually all sales scenarios, you're dealing with more than one buyer. That's known as the "complex sale." Simply identifying all the relevant buyers in the client's organization and meeting with all of them will often place you ahead of the competition. Of course, the better you understand their various "personal win-results," the better positioned you are to define the best solution. So build the relationship with as many of the buyers as possible.

Identify key project drivers. Technical professionals are prone to focusing on clients' technical issues without giving appropriate attention to the nontechnical issues that may matter most. Be sure to uncover strategic and personal needs as well, and include them in your solution development. Strategic needs typically drive our technical projects, and personal needs shape preferences for the working relationship.

Uncover the true selection criteria. As a proposal specialist for many years, I learned never to trust the RFP. There are almost always important insights missing in the solicitation, especially relating to subjective or intangible factors that play a key role in selecting a firm. Don't be fooled by seemingly objective grading systems; clients can make the numbers add up to the results they want. Uncover what project issues and selection criteria really matter to the client before the RFP is published.

Develop the winning strategy early. Ever found yourself working on a proposal wondering which project approach or design option the client will prefer? It's kind of silly, isn't it? Those questions should have been answered during the sales process prior to the RFP. Yet A/E firms are often caught flat-footed, with access to the client now curtailed with release of the RFP, resigned to speculating what the winning proposal strategy might be. Determine in advance with the client what it will take to win the job.

Overlooking the Client's Real Problem?

Are engineers good problem solvers? That's a question I often ask when speaking to groups of engineers. Some inevitably fall into my trap.

"Of course, engineers are good problem solvers; that's a core competency for engineers," is a typical response. But then someone usually provides the right answer: "Engineers are good problem solvers if it's an engineering problem."

I want to be careful to avoid stereotypes, but my 38 years in this business offer ample proof that many engineers and other technical professionals are not always the best problem solvers. They may knock it out of the park when dealing with complex technical challenges only to whiff completely on relatively simple nontechnical matters.

Unfortunately, the client's biggest concerns are often nontechnical matters. Yet they may disguise themselves as A/E projects. There's a technical component, of course, but the real problem may have little to do with engineering, architecture, or science. Fail to look beyond the technical issues and you can easily fail to deliver a successful project from the client's perspective.

Years ago, the engineering firm I was working with submitted a proposal for a federally-funded flood control project in eastern Colorado. Our firm was one of two finalists for the job. The client was a small, rural town surrounded by farms and ranches. Our project team went into the shortlist interview prepared to discuss an engineering project and completely missed the point.

The successful team? They focused on the issues that mattered most to the client: How they were going to avoid interrupting the flow of irrigation water during construction. How they would maintain access to farmers' fields. How they would minimize the impact of construction on downtown businesses and traffic flow.

Losing the job is one thing, but what if we would have won? We had very capable engineers, but they weren't always attuned to the nontechnical problems that concerned our clients most. Would our firm have delivered good value from the client's perspective? I doubt it.

I could tell many other similar stories. The disconnect between what matters most to clients and what A/E firms focus on is a common problem. If we only meet technical needs, there's a good chance that we're overlooking problems that motivated the project to begin with. The best A/E firms know how to connect their technical solutions to meeting strategic and personal needs as well.

Common Problem Definition Problems

Delivering superior solutions starts with properly diagnosing the problems. Following are some common shortcomings that I've observed in this regard:

Not adequately engaging the client. The real problems we're addressing don't exist independent of the client. We need to understand their concerns, perceptions, priorities, and--yes--even their feelings. A satisfied client is not an objective standard; it requires exploring the realm of subjectivity. Even technical issues will be viewed differently by different people.

Failing to construct the big picture before analyzing the details. Engineers tend to be analytical thinkers, which is a great asset in breaking down technical problems. But it can be a shortcoming on complex A/E projects where there is a web of interconnected issues that define the problems we're trying to solve. It's helpful to involve people who are good at "synthesis," seeing this larger picture. They don't necessarily have to be strong technically to add value to your problem definition process.

Focusing almost exclusively on technical issues. This is the comfort zone of the average technical professional. But the problems clients expect us to solve aren't always confined to the limits of our expertise. It's critical that we be able to link our technical solutions to addressing human needs, which always extend beyond narrow technical disciplines.

Neglecting an integrated, multidisciplinary approach. Even within the realm of technical expertise, we can suffer shortsightedness by not drawing on multiple perspectives and experiences. The best project teams excel at collaborative problem solving. A good start is to avoid the usual linear project process (planning to design to construction, for example) and engage experts across disciplines in all phases of the project (e.g., involving construction experts in the planning stage).

Favoring a specific solution, biasing your problem definition. Whenever we have a really successful project, what's our natural inclination? To do it again. So we can become the proverbial hammer in search of a nail, trying to force-fit a solution to a problem that would be better addressed in another manner. This happens more often than we'd like to think.

Not addressing the needs of other crucial stakeholders. Most of our projects involve other parties besides the owner who have a stake in determining the ultimate success. It's important to engage them too in problem definition and selection of the best solution. Sometimes this can require that you convince your client of the value of proactively involving other key stakeholders. For example, regulators inevitably are in control, so why not talk to them early to understand their needs?

Identifying and solving problems is such a natural part of what we do in our business that I wonder if we take the process for granted. We assume that we're good at it, when the truth may be a little humbling. Let me encourage you to spend some time evaluating your firm's real problem solving abilities. Are you guilty of any of the above shortcomings? Your problem solving skill may depend on properly diagnosing your own problems first.