Whenever I do sales training, I start by asking participants what their immediate impressions are when I mention the word
. As you might imagine,
their responses are overwhelmingly negative. Why are salespeople so widely
disrespected? Because most of us suspect that they put their own self-interest
ahead of the buyer's.
True or not, the perception persists, and you dare not ignore it when selling your own services. Nevertheless, although most technical professionals thrust into the sales role of traditional sellers, they often mirror the same behaviors. Talking too much, listening too little, and focusing the discussion on themselves or their firm are all indicators of a lack of client focus.
When it comes to proposals, this problem is magnified—and clients contribute to the problem. Their RFPs encourage us to write proposals that shift the spotlight to ourselves. It's the little-acknowledged dark side of qualifications-based selection rules, which our industry has fought hard to establish, but which seduce us into thinking that clients actually do select on qualifications alone.
At least our proposals would suggest it. From start to finish, the average A/E firm proposal is one long (in some cases, very long) advertisement. The prevailing theme: Look how wonderful we are! Except to client reviewers the distinctions between competing firms are often barely perceptible. What does stand out is the rare proposal that puts the focus where it belongs—on the client and their project.
I've sought to make writing client-centered proposals my primary advantage over the last 20 years. It seems to work, resulting in a 75% win rate for over $300 million in fees. In this post, I'll highlight the key steps I follow in preparing client-centered proposals:
Why is the client doing this project and what are the desired outcomes? Answering those questions would seem an obvious place to start . But I continue to be amazed how often the teams I work with are unable to give me satisfactory answers. Don't expect the RFP to give you the insight you need. You must engage the client before the RFP to uncover the real needs behind the project.
I break down : (1) strategic needs, (2) technical needs, and (3) personal needs. Responding to all three is key to consistently writing a winning proposal. Most technical professionals understandably focus on technical needs. The RFP usually encourages this. But is the overriding, if unstated, goal. Since there are people involved—client representatives and their stakeholders—addressing their personal needs is also an important part of delivering a successful project.
Doing the upfront work to uncover all three levels of needs gives you an advantage right out of the blocks in competing for the winning proposal.
Most A/E proposals I read are . That's a notable shortcoming, especially in appealing to executive-level decision makers—those who usually have the final say in the selection. They will likely be looking at the business value your solution delivers, an angle typically missing from our proposals.
Connecting your work to the strategic driver(s) behind the project is an easy way to distinguish your submittal. Your proposal should include some formulation of the following:
needs, project history, site conditions, challenges, regulatory context
vision, critical success factors, desired outcomes, business metrics
strategy, project narrative, project management process, client
breakdown structure, contract scope, budget and schedule
The proposals I see commonly neglect or under-develop the first two elements, where the connection to business value is typically made. Keep in mind that minimizing the description of the client's problem and desired outcomes tends to diminish the value of your solution.
Clients in working with you as much as they value your expertise. If you doubt that conclusion, consider the circumstances where you've lost a client. Was it a technical problem or a service deficiency? My informal polling indicates that it is overwhelmingly the latter.
Yet almost no one writes about the client experience (or the working relationship) in their proposals. What steps will you take to provide great service in the course of the project? Answer that question and instantly differentiate your submittal. Don't settle for the typical bromides like "we listen carefully to your needs" or "we are committed to being responsive to our clients." Describe in specific terms how you actually do those things.
I've gotten good mileage out of my . In fact, it has played a key role in winning some large contracts. For example, the selection committee chair for a major airline remarked during the interview, "Why are you guys the only ones talking about this? The reason we're replacing our current consultants is that we're not happy with how they've served us. You're the only ones to tell us what you're going to do differently." We won that national contract despite some serious holes in our resume.
Want a cure for insomnia? Put a stack of proposals beside your bed. Why do our proposals have to be so bereft of humanity and something interesting to say? The problem starts with how we've been taught to write. Technical writing is characteristically impersonal and stuffy. Indeed, it is the .
So you need to stop making your proposals read like technical reports (not that reports should read like that either!). , not just intellectually. Share your opinions, not just dry facts. Use personal language like first and second person ( is the most persuasive word in the English language).
A great . The classic story spine has these elements: (1) reality introduced, (2) conflict arises, (3) struggle ensues, (4) conflict resolved, (5) new reality results. The conflict is the problem you're solving. The struggle is the consequences or potential implications of that problem. The solution is more than a scope of work; it's a description of how the problem is to be resolved and what the new reality will be.
Your proposal story should also satisfy these narrative elements:
- . People drive the story, not organizations. Use first
and second person. Refer to specific individuals where appropriate.
Excessive use of third person tends to result in overuse of passive voice,
which weakens the story's action. And don't ignore how people will
interact—communicating, collaborating, decision making.
- . Share your thought process, even if the final answer
is yet to be determined. Acknowledge people's emotions (e.g., frustrated
client, angry community group, delighted stakeholders). Your solution
ideally addresses both objective and subjective, felt needs.
- . This is perhaps the most important element of a good
story. When you jump to the scope of work (and your qualifications)
without adequately explaining the problem and its consequences, you rob
your proposal story of much of its power.
Because storytelling in proposals is so rare, I'm sure many of you will automatically discount its potential influence on the selection committee. That's fine, because that makes it all the more effective for those of us who decide to build a compelling storyline into our submittals.
Proposals have come a long way in eye appeal since I first started writing them in the 1980s. That has come with the advent of professional marketers, digital technology, and on-demand color printing. But I've generally not seen any notable improvement in the functionality of proposals—that is, how easy they are to read and navigate.
Making your is a powerful, yet routinely ignored, differentiator. On this point, we shift from client-centered content to client-centered presentation. That means you need to go beyond pretty to practical. It's of little value to have the right message (as highlighted above) if it's buried in the pages. The typical A/E proposal is a .
Let's start with document length. I commonly see proposals exceeding 100 pages and wonder what their authors were thinking. Do you know how much time it would take to read a proposal that long? About three hours! Do you think selection committee members will spend that much time with your proposal?
Of course you don't. You know that they'll skim much of it, at least in the first review or two. So why aren't you making your ? Almost no one does. They write page after page of text as if they expect them to be read word for word. If you want to win over the client, make your proposal reader friendly—concise and skimmable.
The . Of course, you must comply with it. But don't mindlessly follow its vague suggestions and implied meanings. Many do, as if the RFP contains all the answers if they could only crack the code. I prefer an uneasy alliance, where I pursue what I think will work best for the client, unless the RFP directs me otherwise. That's because I trust what the client has told me (and the accumulated feedback from other clients) over the repurposed boilerplate that typically comprises the RFP.
One area I find myself frequently pushing back is the order of content. If the client is the centerpiece of my proposal, then I want to put the client-oriented content first (e.g., project background, objectives, approach, and SOW). That is, unless the RFP specifies something different. I typically don't assume that a bulleted list of contents means it must be in that order. But a numbered list probably does.
If that approach sounds too risky, there's another option—include an executive summary that puts the most important (client-centered) content up front. I always include an executive summary unless the RFP specifically precludes it. This summary distills the essence of your proposal, with the client at the heart of the story, in a few hard-hitting pages.
In my debriefs with clients, I've learned that the executive summary is almost always read (even when not requested) and is often a key factor in the selection decision. So if the RFP requires that you open with an overview of your firm (arrgh!), you can counter with a well-written executive summary that immediately makes it clear that the client's interests come first. That sells!