Carl Dickson

In business development, thought leadership is really about trust. That is why thought leadership is best demonstrated, and why simply claiming it can backfire. Thought leadership is about who you trust to guide you through the issues and find solutions. If you want to be a “thought leader,” you should: Show insight that helps your customers achieve their goals in ways they may not have thought of on their own Demonstrate customer service before the project even starts Do your homework so that what you say demonstrates that you are informed Not only identify the trends that could impact the customer, but help them figure out what to do about them In business development, thought leadership requires two-way communication. Thought leadership is not only about what you have to say, it’s also about how well you listen. You must listen so that what you say and recommend will be relevant to the customer. A thought leader who is not relevant is not a thought leader in the customer’s eyes. Relevance is also critical to being a thought leader. In business development, relevance is often a matter of timing. You should anticipate what the customer needs to know so that you provide the right guidance at the right moment. If you make recommendations before the customer is prepared to act on them, it will be premature. If you make recommendations after the customer has reached a decision, they will not want to revisit the topic. You can see how this works during the pre-RFP acquisition process. If you try to influence the RFP when the customer is trying to decide which the best contract vehicle will be, they won’t even know what to do with your recommendations. And no one will want to listen if you try to recommend a different contract vehicle when the customer has already determined their acquisition strategy and is getting ready to release the RFP. However, if you are there to help them figure out what contract vehicle will best meet their needs for what they are trying to procure, and if it requires an RFP you are there with recommendations for the specifications that they can copy and paste right into the RFP, you will be demonstrating: The kind of customer service they can look forward to Your ability to anticipate problems and solve them before they become issues That you listen, understand your customers’ needs, and do your homework That you add value If you want to show the kind of insight that will also make you a thought leader, your recommendations need to anticipate and solve problems that the customer would have struggled with on their own. If the customer doesn’t have the expertise to write the RFP or isn’t sure how to resolve the trade-offs that are inherent in specifying what they want to procure, this is a golden opportunity for you to help them figure it out. If the customer is facing change but is not sure what form it should take, this is a golden opportunity for you to help them figure it out. When you are consistently there, with the right advice at the right moment, then you are the contractor that the customer goes to for answers. You are the contractor that the customer trusts to talk about their issues because they know you’ll have something constructive to say that will help them achieve their goals in spite of the challenges. Whether you use the label “thought leader” or not, being a thought leader can put you in the best possible position to win your customer’s business.

Almost everything I learned about proposal writing early in my career turned out to be wrong. My success with proposal process and techniques started when I grew confident enough to abandon what I had been taught. But what has really advanced my career has been the subjects I learned about while writing proposals. If I had known about them at the start, my early proposals would have been much better. Here are six subjects that I learned about and how they impact the way I do proposals. As those of you who are already experts in them will see, I am not an expert. I know enough to write about them, not enough to get a job doing them. But that just goes to show that learning a little about these things can help you write better proposals. How help desks work. When delivering services, customers expect things to go wrong. They often want to know what you are going to do about it. That’s where being able to describe issue tracking, assignment, escalation, follow-up, reporting, and related matters is really useful. If you take a proposal that doesn’t require a help desk, and insert help desk techniques without ever using the term “help desk,” you can sound really sophisticated in your approach to customer service. ISO 9000. ISO 9000 was a quality methodology that I got some exposure to. Since then they’ve upgraded and changed the numbers. But that doesn’t matter. What matters are the basics. If you have a process, you need to be able to prove that you’ve followed the process. Sign-offs, forms, checklists, etc. can be used to demonstrate that you are delivering the way you said you would. Auditing is also necessary to verify that people have implemented a process. External auditing is even better. Quality must be defined so that you can validate an end product by measuring it against the definition/specifications. How will participants know if what they’ve done is free of defects? How does the organization know that what participants have done is free of defects? Progress must also be measured. You can take any process and if you define quality and add validation and proof of process execution, you can make it better. Six Sigma. Another quality methodology. You are better off building quality in at the beginning than by verifying it at the end. Everything is a matter of statistics and measurements. Hat tip to Peter Drucker who said “If you can’t measure it, you can’t manage it.” Elementary school rubrics. When I went to school we didn’t get rubrics. Grades were subjective. When my kids brought home rubrics I had no clue what they were. Rubrics tell a student exactly what they have to do on an assignment to get an “A,” a “B,” a “C,” etc. What a genius concept! I stole it and built it into our MustWin Process to solve the problem of proposal writers getting to a review and having the reviewers tell them it’s all wrong and to do it again. If you tell proposal writers what criteria their sections will be measured against, they can build the quality in from the beginning. But for it to work, you have to do it in enough detail to take most of the subjectivity out of it. If elementary school kids can have rubrics, proposal contributors can too. Capability Maturity Model. People don’t usually go from a total lack of process and quality systems to a full blown implementation in one step. Process improvement comes in stages. Get something in place that makes people’s lives easier, and then take them to the next level. Repeatability is something important to achieve. I mainly use what I learned here when implementing business development and proposal processes, but being able to describe the level of maturity in your operational processes can enable you to put some detail behind all those unsubstantiated claims about being “committed to the highest levels of quality.” Various engineering and lifecycle models. The systems development lifecycle (requirements, design, build, test, repeat or some variation) can be useful terminology whenever you have any kind of deliverables. Engineering methodologies are also useful. For example, they can enable you to describe in formal terms how you do an alternatives analysis. Being able to drop in a table that shows the possibilities along with the criteria you will use for assessing them and the grading system you will use for selection can make it look like you have a clear, objective, and verifiable approach to decision making. There are many, many methodologies that can probably help your proposal writing. As soon as I publish this article I’ll probably think of some I left out. I find it interesting that many of them work both to help you figure out what to write, and how to improve your proposal process.

You don’t have to be a proposal specialist to win. In fact, a non-specialist can easily beat a specialist. All you need to do is have a better understanding of your customer’s needs and preferences. That is more important than your proposal writing skills. Far more important. If you do a good job at gaining an information advantage regarding the customer’s needs and preferences, you can often win, even though you did a mediocre job of putting it in writing. But if you don’t have an information advantage, then you better do a great job on the proposal. And even then you’ll be at a disadvantage compared to someone whose offering will meet the customer’s needs better because they understand them better. The sweet spot is to have an information advantage and a great proposal. But that’s actually rare. Even for the specialists with lots of resources at their disposal. The specialists usually start off by complaining that they don’t have the information they need to work with. That’s why you have an opportunity to beat them. If you’re not a proposal specialist with a lot of experience, then you have to beat them by being more insightful about the customer, the opportunity, and the competitive environment. Play to your strengths. Your challenge is to gain an information advantage and then build a proposal around it. If you’re starting late, such as after the RFP has been released, the deck is already stacked against you. If you don't have a relationship with the customer before the RFP is released and can’t quickly develop an information advantage, you should consider not bidding. If you think you have a shot because the customer asked you to submit a proposal, then start asking questions. Lots of questions. If you can’t translate your customer relationship into an information advantage, then it’s a shallow relationship, and the opportunity may not be real either. If you think the customer likes you, the way to measure it is by how well you can turn it into an information advantage. If you think they like you, but they won’t share or discuss any insights about what they really need, then it doesn’t translate into any competitive advantage. In fact, anyone else who does have that insight has the competitive advantage over you. If you can gain the insight required to make it worth bidding, then it’s time to think about the proposal. If there is a written RFP with a formal evaluation process, it will drive the structure of the proposal. If there is no written RFP or if the evaluation is informal, then Don’t just start writing. In each section, you will have multiple goals, and you can’t anticipate them all until you’ve mapped them out. If you have a written RFP, you follow the outline suggested by the customer and tailor it for each evaluation according to their evaluation process. If the RFP is not organized according to a point by point or question and answer structure, you will probably need to cross-reference all of the RFP requirements to the sections of the proposal where they will be addressed. If there is no RFP then you should organize it according to how you anticipate the customer will make their decision. Once you have the organization you need to think about all the things that should go into each section, like: Fulfillment of the requirements Win strategies and themes What matters to the customer What you are offering and why it’s their best alternative What the customer will get out of what you are offering Graphics, visual communication, and navigation aids When there is a written RFP with a formal evaluation, compliance with all of the customer’s requirements can be extremely important. Use their terminology and not your own. When the customer publishes written evaluation criteria, proposals are not read, they are scored. So carefully consider their evaluation criteria, and make sure that your response scores the maximum points. Everything you write should be put into the context of the customer and the competitive environment. Even if you do the same thing for every customer, you should position what you do differently. The things you do can have multiple results and benefits. For example, is the result of automation an improvement in speed, quality, or efficiency? Your proposal should reflect the customer’s preferences and how you want to position yourself against the competition. In addition, everything you write about should reflect the customer’s perspective and not your own. The easiest way to achieve this is to make every single sentence about what the customer is going to get out of whatever qualification, approach, or item you are writing about. You should avoid describing things, even when the RFP asks you to, and instead show the results of things. If you are starting most of your sentences with your company name, “we,” or “our,” you are probably writing about yourself instead of writing about what matters to the customer. If you are making bold, unsubstantiated claims like they do on television commercials, you probably aren’t writing from the customer’s perspective. Think about what the customer needs to hear in order to make their decision. That’s what you should focus on. When you write from the customer’s perspective and show insight about them and their requirements, what the customer reads will show how your offering is the best alternative for achieving the results they are looking for. Customers pay less attention to style than they do to picking the proposal that looks like it will give them what they want. That’s why your best chance for beating the competition is to start with an information advantage.

Most people are a mix of all three perspectives. This is especially true in organizations that don’t have someone assigned to each level. You will substantially improve your value if you can at least look at every issue from all three perspectives. People who like the comfort and security of staying within the box of their chosen level are not people needed to drive the organization to win. So what we’ve done is start with the Executive, Manager, and Worker’s perspectives, and then applied them to both business development and proposals. You can really see from the results, the different ways that people look at these functions and their roles in them. If you don’t have someone in your organization (regardless of their title) asking all of these questions, your organization’s ability to win business will be negatively impacted. That is because each organization has to strike the right balance. If a perspective is not present, then you can’t strike the right balance. Even when all three are present, it can be difficult to get them into the right balance. The Executive Perspective: What should we target? Where should I invest resources to get the best ROI? What should I expect? How can I influence events? What should the plan be? How do I measure progress? How do I know if the results are right? The Manager Perspective: How do I achieve my target? How should I coordinate my team? How do I execute the process or plan? How do I make sure everyone is doing what they should? The Worker Perspective: How do I complete my assignment? How am I required to coordinate with others? What process or plan should I follow? What am I supposed to do? Business Development The BD Executive Perspective: What customers and core competencies should we target? Is our pipeline healthy? Where should I allocate resources to improve our win rate? What is our contribution to the company’s strategic plan? How do we implement the company’s strategic plan? Are our bidding strategies profitable? What should we be doing to better position what we offer? How do I know if we are on track to be in position to win our pursuits? The BD Manager Perspective: How do I hit my numbers? Are the leads we’re finding valid and worth pursuing? Where should people prospect and how? What processes do I have to get people to follow? How should I flow down the strategic plan and corporate positioning to our pursuits? What plans and reports do I have to submit? How should I track process toward being in position to win and how do I verify everybody is doing what they should? The BD Worker Perspective: What numbers do I have to hit? How should I go about prospecting? What do I need to do to qualify each of my leads? What will it take to win each of my leads? What do I have to do to comply with our process? How do I know if I’m on track? What do I have to do to pass my reviews? Proposal Development The Proposal Executive Perspective: What bids should we anticipate? What do we need to do to be ready? What information do we need to flow into the proposal process? Where are we going to get it and how? How should proposals reflect the company’s strategic plan and positioning strategies? Does our process match our business needs? Where should we focus to improve our win rates? How should we allocate resources? How do we address issues that cross organizational boundaries? The Proposal Manager Perspective: What bids do I need to prepare winning proposals for? What resources do I have to work with? What information does the company possess that will impact the proposal? Who should I assign what? What can I do to maximize their effectiveness? What channels do I need to go through to coordinate with all of the stakeholders? What strategies and positioning will drive each bid? How do I apply our process to the particular bids I have to pursue? How do I balance process, resources, and my deadlines? What reviews should I plan for and how? How does it all get integrated into the final document? The Proposal Worker Perspective: What are my role, responsibilities, and assignments? How do I fulfill them? How am I required to coordinate with others? What process or plan should I follow? What am I supposed to do? What needs to go into it? When is it due? What is my role in the review process and how will I be impacted?

In our continuing series on how to do proposals The Wrong Way, we’ve seen the power that comes from doing the opposite of what the best practices say you should do. In the webinar we did last week on the topic, we showed 20 different techniques for doing proposals The Wrong Way. These techniques are for dealing with adverse circumstances where the best practices don’t apply. Use them inappropriately and they can cause you to lose. But if you have no choice and may otherwise be unable to submit anything, they can potentially save the day. Or at least let you submit something so that the loss isn’t entirely your fault. One of the benefits of learning how to do proposals The Wrong Way is that forever after, you will recognize when someone else is trying to pull those tricks on you. Most of the time, people do it subconsciously and not on purpose. But either way, you don’t want to see them in a proposal you are trying to win. So now we’re going to turn things around again and talk about what to look for when you are trying to win a proposal and some well meaning fool is taking a shortcut that can undermine your chances of winning. Learn to see what the writer is focusing on and question whether it is the right thing. Most of the techniques are forms of misdirection aimed at avoiding writing about what you don’t know. Are they: Writing about intent and commitment instead of what they will actually do? Writing about experience instead of how they will fulfill the requirements? Writing about capabilities instead of results? Using the words “like, about, nearly, almost, more than, less than, etc.” to avoid commitment? Simply stating that they will comply with the requirements, without saying how? Positioning to hide their weakness, as in "being innovative and bringing fresh insights and new ideas" because in reality they don’t know the customer or their environment? Dropping in words and phrases they found using Google instead of showing real insight? Using things like “flexibility,” being a “partner,” or preparing for “all contingencies” as a way of being everything to everybody and hiding that they don’t know what the customer really wants? Redefining the requirement or limiting it with assumptions because they don’t know the real scope? Writing about things instead of actually identifying them? Using passive voice to hide that they don’t know how something actually happens? Planning to have a plan instead of actually saying what they will do? Focused completely on compliance instead of the customer’s goals? When you’ve used these techniques to cover your own lack of information or weakness, it becomes much easier to recognize them in someone else’s writing. That can help you get rid of them and replace them with something that will help you win. Turn the statements above around and you’ve got a good list of what you should write about in order to win.

This article is another in a series we've written on Doing Proposals The Wrong Way. They describe very powerful, but dangerous, techniques that turn the best practices on their heads. The most powerful proposal writing aligns what you are offering with the customer’s vision. The customer’s vision for themselves is about what they want to become. It tells you how they want to change. If you get their vision wrong, then you could very well be suggesting that they change in a way that is not what they want. This is not a recipe for winning. If you avoid the issue by not writing about how your offering relates to their vision of the future, then what you offer will not be compelling. It will not be a necessary part of that future. You will lose to a competitor who addresses that alignment. So how do you write about the customer’s vision when you aren’t really sure what it is? You can get a glimpse from their website and by doing research, but unless you’re talking to them about it you’re probably not going to learn how they intend to change. It’s not the sort of thing people write down until they’ve turned it into a specific plan. Some customers may even have an internal consensus on their vision. The vision one person shares may be different from the vision the evaluator or decision maker has. If you think you’ll lose to someone who can write about how their offering supports the customer’s vision, but you don’t know enough about that vision to write about it yourself, then one option is to do your proposal The Wrong Way. If you don’t know the customer’s vision for themselves, then write about your vision for them. That’s right, ignore their vision and give them one of your own. If you paint a vision of their future that’s better than any alternatives they are considering, it will be extremely compelling and move your proposal to the top of the ones being considered. It’s hard to do this and be realistic. But it can be done. The reason it can work is that while sometimes the customer has recognized the need for change, they haven’t yet figured out how they should change. If you solve that problem for them, there’s a good chance they’ll select you to make it happen. Another reason it can work is Fear Of Missing Out. If your vision is that good and they can’t get it anywhere else, they’ll be missing out if they don’t select you. You can beat incumbents, larger companies, and better prepared competitors with this strategy. But it’s a long shot. There’s a good chance that your vision won’t take everything into account that the customer is aware of. If it conflicts in any significant way with their other considerations, instead of moving you to the top, it will move you straight to the bottom. It's a very high risk strategy. But then again, if you have stronger competitors who know the customer’s vision better than you do, you probably weren’t going to win anyway. This is not something you can do halfway, or water down. You either paint a bold, unique vision that’s only possible through your offering, or you describe how your offering best supports the customer’s vision. If you try to drop hints, allude to things without saying them directly, hedge your bet by offering them options or in any way make the vision appear optional, then it will be less compelling. Less compelling is no way to win, especially when someone else has the advantage. Customers sometimes pick vendors more for their vision than their offering. In a commodity market or in services where everyone is hiring from the same labor pool, your vision may be your only real differentiator other than price. An ordinary vision is not compelling. If you are going to ignore the customer’s vision and give them one of your own, it better be extraordinary.

This is an article about doing proposals The Wrong Way. That is what you have to do when you are required to submit a proposal your company is not prepared for and you don’t have the information you need to win it. With all the problems and weaknesses that you have to overcome, maybe your company shouldn’t be bidding it at all, but that decision isn’t up to you. The best practices are all about preparation and won’t help you in adverse circumstances like these. So you’ve got some challenges. Of course you do. It’s too late to fix your weaknesses, and you’ll just have to write around them. Ugh. That’s no way to win. It results in an evasive, unimpressive proposal. But sometimes that's all you can do. Sometimes, you just have to get something submitted and survive the experience. We feel your pain, and have been there ourselves, too many times. So here’s a list we put together with a dozen examples of how to take those weaknesses and turn them into strengths in your proposal: If you lack relevant experience, explain how the experience you do have will give you unique insights. Instead of focusing on the quantity of experience, and who has more of it, focus on the relevance of your experience. Show that your experience matters to the new project. Turn your experience into a strength that has prepared you for success instead of a weakness. If you don’t have the required staffing at the time of submission, then talk about how that enables you to right size the project or seek new expertise. If you do this well, you can turn your competition's strengths into weaknesses by showing that their staffing is actually not what is needed. Insufficient knowledge becomes a strength when you double down on what you do know. Who, what, where, how, when, and why. Make your proposal about the ones you know and skip the rest. Even if you only know the same as everyone else, if you describe the importance of it better the customer will conclude that you know more. For this to become a strength, you must demonstrate that what you do know is critical for the success of the project. When you have options for how to respond and aren't sure which to choose, you can still position as an expert on how to choose. Simply focus on both the pros and cons and leave the trade-offs unresolved. Show that you understand the issues and can help the customer make more informed decisions. The more insightful you can be about the trade-offs, the better your chances of making not knowing which to choose a strength. Consider tossing in a little something about how this demonstrates your flexibility and ability to be a trusted advisor. If you don't know anything about the customer's needs beyond what they've told you, you can still position as an expert in relevant matters. This becomes a strength when you can show the impact of your knowledge. What do you know that can affect the results? The bigger the impact, the more important your knowledge becomes and the more likely the customer will see it as a strength. If you can't be an expert, be experienced. If you can't be experienced, be insightful. If you can't be insightful, be capable. If you can't be capable, be compliant. If you can't be compliant, be fun. At each level, be a company the customer would like to work with. That is your strength. If you lack information about the customer and opportunity, position as being innovative (and risk conscious at the same time!). If you don't know what's in the box, think outside of the box. Guessing wrong is better than not guessing at all. If you're not sure what your win strategies should be, steal your competitors' win strategies (or what you imagine they might be). Then be more of whatever they say they are. If they are strong, steal their strengths and present as even stronger. If you can't give the customer what they want (perhaps you don't know), then give them what they should want. Maybe they don’t know what they want and will like the way you describe it better. The relevance of your past performance is what you make of it. If you don’t have relevant past performance, that just means you haven’t thought hard enough about how the experience you do have is relevant. Just hope the customer goes along with your rationalization. If you can't make the size, scope, or complexity relevant, find other attributes (trends, goals, methodologies, terminology, lifecycle, deliverables, services, customer interactions, or anything else) and show that what you did is not only relevant, but that it gives you something special to bring to the new project and will enable you to achieve better outcomes than anyone else. If the customer does not know you, then make it all about reputation. Focus the customer on the fact that others know you and think well of you. Make the evaluation about your reputation so that they have to think about you. By thinking about you, they are getting to know you. While you are at it, make them doubt how well they really know the incumbent. If your weakness is time and you just don't have enough of it, focus on compliance. Roll as many RFP requirements into tables as possible. If you can't describe how you comply, then simply state the RFP requirements that you comply with. This can get you thrown out, but (especially when the proposal pages limit is much lower than the length of the Statement of Work and the evaluation criteria emphasizes price) sometimes you can get away with it. If all of that fails, then go all Sun Tzu and the Art of War on them. Instead of confronting on ground where you are weak, go somewhere else. Find ground where you have strength and make them come to you. If you have less technical capability, emphasize management, and vice versa. Billion-dollar contracts have been won this way. The trick is knowing when to do proposals The Wrong Way. If winning is your highest priority, you should do things the right way by preparing and following the best practices. If you do things The Wrong Way on a bid you think you have a shot at winning, it just might ensure that you lose instead. If you face a real risk that that you might miss your deadline or not have anything to submit, then doing things The Wrong Way may keep things from falling apart and at least preserve a chance of winning, no matter how small. It's always possible that the other companies were struggling even more than you are on their proposals.

Enough of all these best practices already. While we write a lot about them, it’s a lot more fun to write about how to cheat. What do you call it when the best practices no longer apply? Worst practices? That's not right. Best practices for adverse circumstances? That's too long. We call it cheating. But it's not the dishonest kind of cheating. It's the get out of your box and break the rules because that's the only way to survive kind of cheating. When you can't do proposals the right way, you have to do them the wrong way. You have to cheat. Sure, if you want to win you need to do everything you can to achieve the best practices. But what about when you’re starting late on a bid where you don't know the customer, aren't sure what to bid, can't get the information you need to write a winning proposal, have to bid because someone in authority says you must, and it's all you can do just to survive the experience let alone win it? When people tell you that you should “no bid” an opportunity like that, it really doesn’t help you at all. It’s not like it’s your choice. When you're caught in a circumstance like this, the best practices aren't going to help. You have to know how to cheat. Remember, we're not talking about lying, breaking laws, failing to comply with regulations, or ignoring ethical standards. We’re talking about what you can do when the best practices simply don't apply. If the best practices say: Avoid passive voice. This is great advice, but it doesn't apply when you aren’t sure who is going to do what but the RFP asks for your approach. When that's the case, then embrace passive voice and use it on purpose. Let them know that things will happen. Let them know that software will get written, results will be achieved, and requirements will be met. It will sound very business-like while lacking the pesky details that you just don't have. Be direct and specific. You can't be specific about things you don't know. When you know you can't be specific or cite the facts, then it's time to talk about numbers without providing any, have a plan to have a plan instead of providing the plan, and avoid commitment. But when you do, make sure you also sound flexible and enthusiastic. Talk about the benefits of your approach. Which benefits? What matters to this customer on this procurement? If you don’t know what matters to the customer, then just try to sound beneficial. Sound like someone who will work hard to do good things. Whatever they may be. You should exceed compliance, because compliance is not enough. While this is true, how do you exceed compliance when the scope is vague, the RFP is ambiguous, and no one can explain the requirements? If you have no idea how to exceed compliance, then just cite examples from the past where you have exceeded compliance and talk about applying your experience exceeding compliance to this project. Show insight into the statement of work beyond what’s in the RFP. You know you should, but it's hard when you all you have to work with is the RFP and you don’t know anything about the customer or the project. That's when it's time to talk about the kinds of things you do instead of what you actually will do. This stuff is so much more fun to talk about than best practices. It's fun to write too, but only if you've given up on winning. Mandatory warning label. The worst possible outcome for a proposal specialist is not losing. People lose all the time and just blame it on the pricing. The worst possible outcome is failing to submit the proposal on time. Cheating can help you submit on time against an impossible deadline. Just never forget that cheating on a good proposal, one that is winnable, will probably ruin it. Cheating, by definition, means turning the best practices on their head. Cheating means turning your back on the best way to win, in order to get something submitted. If by some quirk of circumstances you cheat and win, that’s just luck. Or having the lowest price. Don't fool yourself into thinking it's anything more than that. You can’t cheat on every proposal and be competitive. At least not against companies that are employing the best practices. The odds favor them, every time. On the other hand, when all the best practices in the world won’t save you, all you can do is cheat. Just have fun with it and don’t be consumed by the dark side.

Ordinary proposal writing is not competitive. Ordinary proposal writing fulfills the customer’s requirements. If you want an ordinary proposal, you can recycle something already written that fulfills the requirements. In competitive proposal writing, fulfilling the requirements only means that you get evaluated and compete against other companies that also fulfill the requirements. In competitive proposal writing, the reason why behind the requirements is more important than the requirement itself. In competitive proposal writing, what will result from the requirement’s fulfillment is more important than the requirement itself. In competitive proposal writing, context is everything. The reasons driving the requirements and the results desired are rarely the same, even when what is being procured is the same. The result is that every proposal is different. Every proposal has a different context. Consider the write-up for one of the most boring parts of a proposal, the “Organization” section within a Management Plan. If you just grab the corporate org chart and drop it in, you may have fulfilled the requirement, but you will not be competitive. Not only should the org chart be redrawn for every proposal, but the explanation of it should be re-written as well. Consider the following questions. Does the RFP require you to name names? Does the RFP require a project level, corporate level, or both? Does the RFP require you to show where the customer fits in? Does the RFP require you to show points of contact? Does the RFP require you to show teaming partners? Does the RFP require you to show all staff? Where does the evaluation criteria provide you with opportunities to score points through how you depict your organization: technical capabilities, experience, management, quality, staffing, or something else? How does the customer’s unwritten requirements impact how the project should be organized? Does the customer prefer a flat chart or hierarchy? Would the customer prefer to see capability, functionality/roles, or qualifications? What does the customer like or not like about their previous vendor relationships that you can address in how you organize for this project? What matters to the customer? Is the customer concerned about authority or lines of communication? Does the customer seek partnership or control? Does the customer see the organizational chart as a demonstration of your functional capability? Is the customer concerned about scalability? Is the customer concerned about coverage? Does the customer care about the corporate level, project level, or both? What will your competitor’s organizational structure look like? How should you position your organization against your competitors? Do you still think you should just drop in a “standard” organizational chart? Can you see why the context matters more to the customer than the fact that you’ve provided an org chart as required? Can you see why every customer will be different? Can you see why even bids to the same customer often have a different context? If you think there is a lot to consider regarding the context of a boring organization write-up, imagine how important the context must be to other sections of the proposal. What should drive your response is what you want the customer to conclude about you when they review it. The answer to this will depend on the: Reasons why driving the customer’s requirements Customer’s preferences Competitive environment Customer’s desired results from the procurement Customer’s evaluation criteria Maybe you can start from an existing write-up and customize it. Or maybe having an existing write-up will prevent you from seeing when the context has changed enough that you should throw it out and create something specific to the context of this bid. It’s safe and easy to recycle something that is compliant. It’s just not competitive.

People sometimes struggle with addressing benefits when they write proposal copy. They stumble over what words to use and how to say things. One way to overcome this is to do away with most of the words. With a features and benefits table you focus on the key items and not sentence construction. And because they are visual and less wordy, they are friendly to the proposal evaluator as well. A features and benefits table itemizes the key elements of your approach or offering, and turns them into reasons why the customer should select your proposal. At first glance, they appear to be simple. They can consist of just two columns, one for the features and one for the benefits. All you have to do is list your features and then write a corresponding benefit to the customer for each. Sounds easy, doesn’t it? It sounds easy until you try it. At some point when writing your benefits, you’ll start to realize that they sound like features. Or vice versa. And how many features should you list? How granular should they be? Should you add other columns? Should it be "Issues, Features, Benefits, Proof?" Should you include RFP references? Behind their deceptively simple appearance, features and benefits tables can lead to mind-numbing confusion. Just simply deciding whether something is a "feature" or a "benefit" can be challenging. So before you hurt your brain over whether something should go in the features or benefits column: Start by defining what a “feature” is. Features are attributes of your offering. They are typically the things you do or offer to fulfill the customer's requirements. The best features are also differentiators, or things that no one else is likely to do or offer. Then define what a “benefit” is. A benefit in a proposal is what the customer gets as a result of the feature. While customers need to have their requirements met, the reason they issue a procurement is because they are seeking certain benefits. Once the requirements are met, they make their decision based on the benefits. If the word benefit troubles you, then think about what the impact of a feature will be or why it matters. Why does your approach or offering include that feature in the first place? Note that some things can be both a feature and a benefit. Speed is an example of something that can be a feature or a benefit. A new computer may have a faster processor. The new processor is a feature with the benefit being that your computer will be faster. But a faster process can also be a feature, with the benefit being that you’ll be more productive. What you include as a feature is less important than that the benefit, impact, or reason why it matters and is compelling to the evaluator. What best determines whether something should be a feature or a benefit is whether it is a requirement or whether it is a result that makes your offering better than your competitors’ offerings. Customers make their decisions based on what an offering will do for them. When they shop for features, it is because they know those features will meet their needs. If something fulfills a customer need, you should explain how or why in the benefits column. To make the right decision you have to understand the customer’s needs. It helps when you are responding to an RFP with written evaluation criteria. In the example above, if the customer is buying a computer and making their selection based on the specifications, then the speed goes in the benefits column because that is what the customer is looking for. If they are seeking to improve their overall systems and your approach might be better because it’s faster (making it a feature), then what the customer will get out of it is improved productivity (the benefit that is the reason they are interested in a new system). In addition to the basic two-column approach, there are other ways to format a “features and benefits” table. And sometimes, they make it easier to understand what goes in each column. Reasons to Select Us/Features of Our Offering. There’s no reason why you should limit yourself to the words “features” and “benefits.” You could also substitute words like “Results” or “Benefits to You.” Features/Advantages/Benefits/Proof. A feature is the attribute, an advantage is what it does, benefit is what the customer gets out of it, and proof is how you substantiate that. Requirements/Features/Benefits. You can include RFP references in the table to demonstrate compliance. This helps link your features and benefits to the RFP, making things easier for the RFP evaluator. It can also help make evaluating RFP compliance as simple as a checklist. You can even expand this one to be Requirement/Features/Benefits/Evaluation Criteria, to show the customer that you are not only compliant, but deserve to receive the best score according to their own criteria. Features and benefits tables (in whatever variation you choose) work best for proposals where you determine what to offer. If you are bidding a solution or a design, then features and benefits tables can make it easy to see the key aspects of what you are proposing and why they matter. However, when the customer tells you exactly what to propose and is seeking to compare apples to apples, the primary difference between bids tends to be price. However, if there are important differences between you and your competitors, such as in how you will deliver what the customer is asking for, then a features and benefits table can help call out the differences and why they should impact the customer’s selection. In some proposals, you might only have one features and benefits table, typically at the beginning. In others, you might have one in every section. Where you use them, or how often, should depend on what the customer has asked for in each section. If a section contains multiple features or presents multiple reasons why they should select you, a features and benefits table can help summarize them. If you have multiple features and benefits tables, you may need to establish a hierarchy and have high-level features identified in the introduction, with each item expanded into multiple more detailed items in each section. In the end, features and benefits tables become more of a thinking and presentation tool than something to make things easier. They help you puzzle through figuring out what you have to offer and what the customer will get out of it by focusing your thoughts like a laser. You can even use them as a pre-writing tool, then convert them to a narrative response and throw away the table. As a presentation tool they help summarize and make things stand out. What you want to avoid is having a features and benefits table just because you think you’re supposed to. If you load it up with unsubstantiated claims, or make RFP compliance the primary benefit, then what stands out is that you are not competitive. When in doubt, focus on differentiators, and don't forget the proof points. When you use them regularly, features and benefits tables end up being something that reinforces the importance of everything you do before you start the proposal. If you are having trouble completing your features and benefits tables, it’s a good indicator that you started the proposal unprepared. When this is the case, features and benefits tables can be used to drive recognition in your company about what information needs to be brought to the start of a proposal. The deceptively simple features and benefits table can become a tool of change management and process adoption.

One of our better ideas has been to replace recycling previous proposals with a win strategy library. A win strategy library can inspire people to prepare more strategic proposals and accelerate their efforts. Recycling previous proposals makes it easy to create proposals that are written for the wrong context. We got the idea when we experienced déjà vu helping a customer plan their proposal. We had done proposals for companies in similar circumstances and were suggesting similar strategies. We realized that a lot of what we do is help customers through situations we’ve seen before, and since we’re a company that focuses on publishing, we had the idea of publishing something that would help them. Thus, the idea for a bid strategy library was born. We’ve already written to introduce the idea here, how to formulate your win strategies here, and how to organize your win strategy library here. Today we’d like to share what’s in our win strategy library. By its very nature, a win strategy library must be company specific. It should reflect your strategic plan and offerings. But we can describe the topics we have in ours that companies use as starting point. The content itself is only for PropLIBRARY Subscribers, but the topics can give you an idea what to put in your win strategy library. Lowest Price Technically Acceptable (LPTA) Evaluations. What strategies can you use to minimize the impact? When the Customer Tells You What to Bid. It’s really hard to stand out and differentiate yourself when everybody must bid the same exact thing. But that’s also where small differences can have a big impact. Strategies for Offering Solutions. Offering a solution is very different from offering a commodity, and that impacts your strategies. 11 Topics That Drive Win Strategies. Where do win strategies come from? You have to look at many different things, so we identified the key items to consider. Differentiation. You can’t be the best without being different. Being the best at complying with the RFP's requirements is not enough to be competitive. So we put a recipe together to help people who are trying to figure out how they should stand out from the pack. Confounding The Competition. Winning a proposal means beating your competitors. If you are in a fiercely competitive market, this can help you out-compete them. How to Tell Your Story in a Proposal. If you are trying to raise the bar beyond simply being descriptive, you need to consider what story you are telling the customer. But how do you write a proposal that tells a story? We created a recipe to help. Transparency. We like it when our vendors, leaders, those we depend on are transparent. We like to know what to expect. Customers are the same way. This recipe will help you build transparency into your proposal as a theme. Escalation Plans. Customers expect things to go wrong and want to know how you will handle them. An escalation plan is a common way of doing that. This recipe will help you figure out what should be in yours. Inspiration for Positioning to Win. How do you get your company and offering into position to win? This recipe provides a number of ideas to help you do just that. What Matters to the Customer About What You Are Proposing. We’ve written a ton about how important it is to focus your proposals on what matters to the customer. But what exactly is that? How do you know what matters to your customers? This recipe contains a bunch of things that matter to most customers that can help you figure out what matters to yours. 23 Topics to Inspire Features. To go along with something we just wrote on creating features and benefits tables, we created a recipe to provide some inspiration for what should go in your features column. We are constantly growing our library. Our “to do” list currently has these win strategy topics on it for development: trust, quality, support, incumbency, new customers, team composition, past performance, resumes, and common RFP requirements and evaluation criteria. The easiest way to approach building a win strategy library is to look at what issues you commonly face and what you typically say or do about them. Then simply capture them at the bullet level. Remember, the idea isn’t to write the words that people will use, but rather to inspire them with ideas about what to do. Once they figure that out, the words come easy and need to be tailored to their circumstances anyway.

Instead of reinventing the wheel every time and having every team start from scratch figuring out what their win strategies should be, you can create a cheat sheet that helps them figure it out faster. The goal is not to identify the wording or control future responses. The goal is to help people more quickly identify the strategy, the approach, or the positioning that fits their particular circumstances. They’ll have to come up with the wording based on the specific issues they need to resolve. Topics: Management plan. What management structures and procedures do you typically respond with for different types of projects? Offering features and benefits. What features do you typically include and what benefits do they typically deliver? You can always expand them later and tailor them for a specific bid. Pricing. How do you typically try to position on pricing, and what strategies do you typically follow in various circumstances? Terms and conditions. When the customer requires a certain term or condition, how do you typically respond? Staffing. Like your offering, what are the features and benefits of your staffing? What are your typical approaches to staffing? Schedule. Too short, too long, or just right? What strategies do you typically employ for various scheduling contingencies? Circumstances and contingencies related to: Customer attributes, preferences, and issues. While each customer is different, they often share some similarities. Which customer attributes, preferences, and issues can you anticipate and how do you typically respond? RFP requirements and evaluation criteria. Some RFP requirements appear frequently. Sometimes the evaluation criteria emphasize this or that, but you can anticipate both. Sometimes RFPs have problems, like when they lack detail or are ambiguous. What do you typically do in response to the things you often see in RFPs? Competitive environment. You may not know the names of the competitors on your next pursuit, but you may know the types. You may not know whether you’ll be on top or the underdog, but you can anticipate being both at some point. How do you position or what do you typically do in each competitive circumstance? Team composition. Sometimes you want a big team. Sometimes you want a little team. And sometimes you go it alone. In each circumstance, you need to explain why and ghost your competitors. And many of the circumstances you can anticipate. External issues and trends. Things go up and things come down. The pendulum swings. People react. Things change. What should you do when faced with things you can anticipate coming up sooner or later? Other. Sometimes things are unpredictable or something completely new comes up. By its very nature it can’t be anticipated. And yet what you do when faced with something new, both good and bad, might be anticipated. Within each topic and circumstance, identify the things you can anticipate coming up and what strategies to employ or ways to position your company and offering in each. Many things come in pairs (big/small, centralized/decentralized, fixed/variable, positive/negative, etc.), so remember to address both possibilities. Basically you’re trying to help people out by telling them that you’ve seen something before or thought something might happen and here are some approaches that may or may not fit. Even when they don’t fit, they can help people zero in on something that does more quickly. One way to approach this is to make it an attachment to your company's Strategic Plan and update it annually. While a Strategic Plan normally deals with positioning at a fairly high level, a Win Strategy Cheat Sheet can show how to connect the high level positioning to what people will face on a day-to-day basis. A little bit of inspiration goes a long way. And since we’re talking about win strategies, anything we do that strengthens them increases your win rate.

We make a distinction between win strategies and themes. Win strategies are what you do in order to win, and themes are what you say in order to win. Win strategies often imply what your themes will be about, and may include delivering certain messages. But sometimes they are action items that have nothing to do with the document. Win strategies are mostly about how you should position yourself and how to get into position. But there are a lot of different ways to position your company and your offering, and many factors to consider. A remarkably simple formula can not only help you figure out what your win strategies should be for a particular bid, but can also show you where your proposals are lacking. Consider: Your "circumstances" is the tricky one. The subtlety of the formula hides the complexity of understanding your circumstances. Are you the incumbent? How well do you know the customer and their preferences? What is the competitive environment? What is happening in the world around the project that might impact it? What is your relevant history and experience? Are you bidding as a team? If so, who’s on it? Are you ready? What issues need to be resolved? What don’t you know? How should you position your company and your offering? What alternatives, choices, preferences, and trade-offs need to be addressed? What does it say in the RFP? How will this customer evaluate and decide on this particular bid? What trends will impact the decision? Pondering these and similar questions about your circumstances is where people often get lost. It’s easy to forget the other parts of the formula. This is especially true about the part dealing with the strategic plan, since a lot of companies don’t have one or ignore it when they write their proposals. You could break down “circumstances” into categories: The customer’s preferences and issues The RFP The nature of the opportunity The competitive environment Your self-awareness, strengths, weaknesses, and history Teaming Any external issues and trends Other But you always have to have that “other” category to cover the unpredictable things that come up. By breaking it down, we’ve made the problem smaller, but haven’t completely eliminated it. That’s okay because we’ve made it easier to make sure we’ve covered everything we should when trying to conceive our win strategies.

Customers don’t see your company as a whole. They only see what you send them, the people they interact with, any products you install, and the results of your efforts. Before they meet you, they might hear about your reputation, but unless what you do is important enough, or widespread enough, they probably haven’t heard about you at all. When they get a proposal from you, they see what you’ve put in writing. And that’s it. All those unsubstantiated claims that you think are credible, they see as unsubstantiated noise. What they see is whether you: Describe yourself or focus on what matters to them Include stuff that’s not relevant to them Are careful and have thought things through Are formal or informal Appear trustworthy Focus on technical details or functional details Have an approach or solution that appears credible Are different from your competitors Follow instructions Can meet their schedule and other requirements Make the right trade-off decisions Have a price that fits their budget Have a better value than your competitors Present the best alternative It’s when they’ve met your staff that things really get interesting. Then what the customer sees is whether you are: Acting as individuals or as a company Making it up as you go along, or you came prepared More concerned with doing or selling Limited in what you can do or acting like a partner Solution oriented Doing the things you said you would Doing the things your proposal said you would (or even know what’s in it) Focused on your own concerns or those of the customer Confident and competent Showing good judgment Trustworthy Helpful and appear to be an asset The kind of people they’d like to work with The kind of people that listen more or talk more The main thing to focus on is whether they see your company the same way you perceive it. You think you know yourself. Putting aside the question of whether you really do, the customer can only perceive what they see. They may have no idea what you are really like, unless you show it to them. Actions do speak louder than words. When there is a disconnect between what you say and what you do, it hurts your credibility. But for that to even be a concern, you actually have to say who you are and what you will do. It all starts with whether who you say you are is actually who you want to be. This, in turn, should be determined by your strategy and positioning. If haven’t thought through your strategy and positioning, you won’t be able to articulate who you want to be so that you can drive that into your literature and proposals. And if you don’t do that, the odds of the customer perceiving a disconnect go way up. The way you prevent this is to look at yourself through your customer’s eyes and make sure they see the right things. Doing this in writing means planning the content before you write it. Doing it in person means having strategies and processes, and training your staff in them. The alternative is simply taking a chance. The alternative means that while you might think of your company one way, you have no idea what the customer will actually see, let alone conclude about you.

When you sit down to write a proposal, you start asking questions so that you know what to write. Inevitably you ask questions that can’t be answered, but that could have been answered had they occurred to you earlier. At the tail end of the process, proposals tell you what you should have been doing all along. When you sit down and write the proposal, you describe your approaches and what you will do if you are selected. This is where one little writer, often at a junior level, can change how the company does things and interacts with its customers. What gets said in the proposal can impact how the company approaches things like quality, transparency, oversight, partnership, collaboration, etc. When you sit down and write the proposal, you need to create bid strategies, put things in context, and position the company and offering. Unless there is direction from The Powers That Be telling how the company should be positioned in the marketplace, the proposal teams usually make it up based on what they think they need to say to win a particular RFP. One of the most important reasons for executives to be involved in proposals before they get written is to prevent the proposal team from reinventing strategy or just making it up to fill perceived gaps. If you don’t tell the team how they should position the company, they’ll figure something out themselves. For the staff involved, it can be a really rewarding experience. It’s fun just being involved in the thinking process and helping to articulating the company's strategies when you normally aren’t experienced enough to even be in the room for those kind of discussions. That basically is what drives the career of a proposal specialist. But if you are The Powers That Be, do you really want people who probably got assigned to the proposal because they were unimportant enough to be available redefining the company’s identity? Then again, you might embrace this. We’ve worked with several companies to help them become more strategic and used their proposals as catalysts to raise the issues and make sure that new approaches actually get implemented. When your proposal review process is based on waiting until a draft is written and then correcting it, you often get a train wreck because the team made up strategies that are in conflict with what The Powers That Be have in mind, but didn’t make part of the proposal plan before the writing started. The approach we recommend for Proposal Content Planning gives you an opportunity to drive this into the proposal from the beginning. It turns proposals into vehicles for strategy implementation. But while the opportunity is there, it’s up to the company to take it. Proposals give your company an opportunity to look at what it will take to win new business, what kind of business you want to be, and how you want to be positioned. Planning what should go into the proposal before you write it gives you a way to make sure that the writing reflects those strategies and positions. If your company is not as strategic as you would like it to be, or isn’t doing a good job of positioning to win, you can use a series of proposals to change all that. If you need help, let us know.

It seems counterintuitive. It sounds like something your boss would never go for. But there is a better way to ensure proposal quality than by having reviews. What do you really get from having a proposal review anyway? Especially if it’s one of those big fat sit around a table reviews? In the name of “making sure it’s correct,” they usually end up rethinking the message. That’s another way of saying they wait until after the proposal is written to figure out the best strategy. Huh? Does that sound like a great way to achieve proposal quality? Let’s try another perspective and look at what you need for a quality proposal. You need input. But you need it on the strategy. And maybe to make sure you’ve covered all the details. You need some validation to ensure you haven’t made any mistakes. In industrial processes, the best way to achieve quality is during the design phase. Instead of adding reviews on top of a process to catch defects, they eliminate defects through design. Why can’t we eliminate defects during the design of our proposals? You might still need a little quality assurance to catch mistakes, but the level of review needed to catch typographical errors and omissions is minor. And it doesn’t need the most expensive labor in the company to spend hours doing it. So how do you design defects out of a proposal? it comes mostly from how you specify and measure what should be written, with a pinch of making sure you deliver the information that people will need to write a winning proposal. That’s right, you can’t just sit down and write about whatever’s on your mind, and writing can be measured. Writing gets measured by comparing it to what was supposed to go into the proposal. What is supposed to go into the proposal needs to be thought through before you start writing. If you do this correctly, you get a feedback mechanism and a tool for validation. The writers can self-assess whether what they have written does everything it was supposed to. Quality assurance reviews become checklist simple. Here are a few articles that describe our approach to planning the content of your proposals: How to make proposal writing faster and easier The secret to solving 14 proposal problems at the same time What is the best way to accelerate proposals? What this really means is that you shift time from reviewing and rewriting at the back end, to making sure you write the proposal the way you need it to be written the first time. Most people would like to achieve that, but aren’t confident enough, so they leave some time on the back end for “risk mitigation” and end up causing what they sought to avoid. Go back and re-read the second paragraph. If you make the most major review of the proposal after it is written, how will you ever achieve quality? But what will really put you in a Catch-22 is when The Powers That Be tell you that “I have to see it before it goes to the customer.” The only people who should be allowed to read the proposal after it is written, are the people who actively participated in defining what the proposal was supposed to be. In other words, only people who reviewed and approved the Proposal Content Plan have any business reading it after it is written. Explain the second paragraph to them and pose the same question to them. If they get it and support you by participating in defining and reviewing the Content Plan, it will go a long way toward shifting the focus of the organization to the front end of the proposal instead of the back end. Then they can see it after it’s written, and while some changes will occur, there shouldn’t be any surprises.

Some things are vital for proposal reviews to be consistently effective, and other things depend on your circumstances. People mix them up all the time because they're focused on their circumstances. They're so focused on how they’re going to get the proposal done that they overlook that what they review is more important than how they review it. Changing your focus to what really matters means changing your whole approach. You can let your circumstances and judgment determine: How many reviews you have How many people are involved in the reviews Whether the reviews are conducted in person or remotely When the reviews are conducted If you put all your attention into the items above, and then leave it up to the reviewers to figure out what to focus on, you’ve got things backwards. What you focus on in a proposal review should be determined by what it will take to win. You review to validate that the proposal reflects what it will take to win and not just to get some opinions about the proposal. What you look at to provide this validation is far more important than the decisions you make on the items above. What it will take to win is discovered by converting what you know about the customer, opportunity, competitive environment, and your own company into bid strategies. These should in turn be converted into review criteria. A lot of people want to spend all their time writing, and just hand the document off to someone for a review. But figuring out the review criteria is part of figuring out what you should write. If you convert what it will take to win into review criteria and give it to those proposal writers, then the writers and the reviewers have the same goals and those goals are far more likely to be achieved. We call this Proposal Quality Validation and it’s part of the MustWin Process that comes with PropLIBRARY. We define proposal quality based on what it will take to win, then we validate that the proposal reflects those criteria. We are far less concerned with how many reviews, how many reviewers, when the reviews are, or how they are conducted than we are with what criteria they use to perform the reviews. Once the review criteria are identified, people can parse them out to different people at different times based on our judgment and the circumstances of the bid. Proposal Quality Validation changes how you approach proposal writing, regardless of whether you have a large team of writers, or it’s just your. Instead of writing, reviewing, and rewriting until you stumble across something that’s good enough to submit and hoping that you discover it before you run out of time, with Proposal Quality Validation you have to think through what it will take to win before you start writing. The good news is that you can write much more quickly (and better) when you know how it’s supposed to turn out. Within the MustWin Process Library we provide the forms, sample criteria, and instructions to implement this approach to reviewing proposals.

Some companies do too much teaming, and some do too little. What’s usually missing in both cases is the right teaming strategy. Some companies team on every bid. When it becomes routine, there’s a good chance they’re giving away up to half their revenue. Their best growth strategy might not require any new leads. All they may need to do is less teaming. Seriously — I’ve seen companies struggling for year-over-year growth double their goals simply by doing less teaming. But some companies find success through nothing but subcontracting. They are usually product companies with unique offerings, or extremely specialized services providers. Because they are the only ones who can fill a particular set of requirements, they are brought in by the prime contractors and the two don’t have to worry about stepping on each other’s toes or competing with each other. Some companies never team. They do what they do, and it just wouldn’t occur to them to include another company. They probably aren’t government contractors. But they are potentially missing the chance to expand their market reach and offer more complete solutions to their customers. Teaming is full of potential problems and risks. Some of the risks after an award can be mitigated through careful contracts. But not all. Leverage ends up being more important than contracts. Leverage comes from strategy. But your team needs to be in place at the time of proposal submission and well before award. Companies write teaming agreements to try to document their intentions, but if a teaming agreement is merely an agreement to agree later, then it may not even be enforceable. And again, leverage ends up being more important than what it says on the paper. There are really only three times when you should team with another company to win a bid: When you are forced to. Small business set-asides can make it necessary for larger businesses to team if they are going to play at all. Sometimes companies can't do everything that is required by an RFP, so they are forced to team with other companies in order to submit a compliant bid. When it increases your chances of winning enough to justify the risks. Sometimes it’s worth it to give up a slice of the pie in order to improve your odds of winning the rest of it. But this is also the most common reason given for unnecessary teaming. When it increases your chances of winning other/future opportunities enough to justify the risks. If teaming can get you into new markets (new customers, new industries, new territories, etc.), it might be worth it. For leverage, it helps to think in terms of checks and balances: When there is just one contract and one source of revenue at stake, both parties have more incentive to act selfishly. But when they team strategically, on multiple contractors with more than one customer, then neither wants to let something bad happen on one contract because it might affect the others. A truly unique product or extremely specialized service means the prime has to come to you to get it. Most services do not fit in this category, because the prime can hire staff to gain the capability. Just because you might be better qualified doesn’t mean the prime can’t live without you. Whoever owns the customer relationship owns the business. If you are a sub and the customer never sees your face, you can be dropped and they may not care at all. If you are a prime and you let the sub have face time with the customer, you have to worry about them trying to replace you. Are you both incentivized to do things that end up making you both money? If the things you want to do make your partner profit in addition to yourself, and the reverse is also true, there’s a good chance you’ll get along just fine. For other sources of leverage, think about why your teaming partner should care if you are unhappy. If you find yourself resorting to contracts and legal actions, then you don’t have any leverage. But if you can do things that will make them equally unhappy, you have the basis for a nice, smooth, working relationship. You are co-dependent, integrated, and not in a position to even think about being exploitive. In fact, just the opposite becomes true. If you aren’t sure whether to team or not, consider strategies that increase your leverage. If you’re having trouble finding those strategies, you may want to avoid teaming because you don’t have what you need to mitigate the risks.

A company recently contacted me because they weren't winning any business from a new customer. The reason the customer gave them was that their task order responses were being evaluated as high risk. They asked me to review their proposal template and make recommendations to improve it. The proposal was limited to three pages. As I started reading, I started deleting everything that wasn’t vital. That was when I realized that this is a very useful technique for improving proposals. Simply delete everything that isn’t vital. I was doing it to see how much space I had to work with to write something that would add substance to improve their risk score. But every proposal can benefit from the same approach. In the past, we’ve told people to just skip the steps in our process that weren’t needed in order to win. It’s a trick, because we’re confident that they won’t find anything that’s not directly relevant to winning. But it’s a great way to achieve process buy-in. If they can’t find anything that’s not needed to win, then everything left must be crucial to winning. This same approach can be applied to the text of your proposal. If a statement doesn’t absolutely need to be there, it should be deleted. If your introduction says “we are pleased to submit the following proposal,” that’s not information that is vital for the customer to make their decision. Delete it. If you’ve made statements that are universally true and apply to everyone equally like “Quality is critical to the success of this project,” delete it. Some things can go either way, like the year you were founded. If it’s vital, then you should say why. If it’s not vital, then delete it. Whenever you aren’t sure whether something is vital or not, it needs to be fixed. There should not be an ambiguity. Either make it say something vital, or make the reason why it’s vital clear, or delete it. It’s very important to assess what’s vital from the perspective of the customer. It’s not about what you think is vitally important to say. It’s about what the customer thinks is vital to making their decision. Either it’s information they need, or it’s not. What you think is vital really isn’t — unless you can position it as vital to the decision that the customer has to make. If you are struggling with what is vital and what isn't, figuring out the difference may be the most important thing you can do to improve your proposals. If your proposal drops in length because you deleted a significant portion of what you had written, that’s not a bad thing. But it’s also not necessarily the goal. Maybe you’ll make room for something else that is vital. Or maybe you’ll make room so that you can better explain why some of the questionable statements really are vital. Maybe when you’re done, it won’t be any shorter. But what it will be is vital.

Somebody actually said the following in our discussion group on LinkedIn: Saying process is a crutch is like saying education is a crutch. There are definitely ineffective processes, and most processes can be subverted or weakened through lack of management endorsement or oversight. But that doesn't make all processes bad. The best processes add value. To beginners. To experts. To the executives. And to stakeholders especially. If a process is being used as a crutch, then it needs to be reengineered because it is not guiding people to do the right things. If you had no process, do you think that the people using it as a crutch would do any better? People alone are not enough for business development. Recognizing when it's time to reengineer your BD process, and creating one that is effective, are critical skills. Many of the people in charge of the BD process are good at doing BD but really don't know much about creating an effective process. Individuals won't achieve their full potential without a process to inspire, guide, coordinate, validate, and improve efficiency. And companies inevitably degrade over time without processes. Perhaps that is because even if you don't have a process, you still have a process, it's just unwritten and inconsistent. But the worst part of a lack of process comes when you hire people at multiple locations. Over time, they evolve different ways of doing things. Then when you try to make improvements, it becomes like herding cats. We've also written about this business development trap. But process alone is not enough either. Processes won't work without skilled people. But processes are not supposed to make people irrelevant. They are supposed to make people better. Just like education. Instead of asking which is more important, it's better to ask how you can achieve both so that you can beat your competitors. But if your process isn't consistently working, don't blame it on your people or throw it out. Instead, reengineer the process, because people alone will not be able to compete with a company that has effective people supported by an effective process.

It’s important to be able to define proposal quality if you want to make sure that the proposal you develop reflects it. We define it as a proposal that reflects what it will take to win. We define what it will take to win as part of our process, reaching all the way back before the RFP is released so that the questions we ask and information we gather enable us to say what it will take to win. We use Proposal Content Planning to bring what it will take to win together with the other things that should go into writing the proposal. What integrates writing about fulfilling the requirements and addressing what it will take to win is how you position yourself. You must position yourself against several things in a proposal: The RFP The evaluation criteria The competitive environment The customer’s preferences and issues The requirements of the opportunity itself The results desired from what is being procured The resources required Your own strengths and weaknesses Your history and experience The customer’s history and experience Pricing Terms and conditions Depending on how granular you make it, this list could become infinitely long. The short list is positioning against: The customer Opportunity Competitive environment Your strengths and weaknesses The RFP Everything else fits under these five. This makes them easy to remember and use. Because positioning is how you implement what it will take to win in writing, it becomes a shorthand for proposal quality. In the formally identify the elements that drive what it will take to win and then turn them into quality criteria that we use to validate the proposal. But you can do a quick and easy informal assessment just by looking at the positioning. Ask yourself how your proposal is positioned against: The customer’s preferences and issues The requirements and desired results The competitive environment Your own strengths, weaknesses, and history The RFP, especially the evaluation criteria In many of the proposals we have reviewed for our customers, it’s really a question of “if” there is any positioning instead of “how” the proposal is positioned. If you read the proposal and it isn’t clear how it is positioned, then it’s not well positioned. If positioning is hidden or subject to interpretation it isn't positioning. If you read the proposal and it: Doesn’t address the customer’s preferences or issues Only addresses fulfilling the requirements, without addressing the results or benefits you will bring Ignores the competition or the fact that the customer has alternatives to consider Treats the customer like a stranger or only addresses your strengths Positions yourself against the RFP as being (merely) compliant Then your proposal does not reflect what it will take to win and is a low quality proposal. If it reads positively for some, but negatively for others, then it is only partially positioned to reflect what it will take to win. In other words, it's vulnerable to losing. Because positioning is the context for your proposal, it is critical to review your positioning before you begin writing. If you try to change the positioning after the proposal is written as a narrative, it will be extremely labor intensive to change the context of every sentence. If you try to discover the right way to position your bid by writing and re-writing, you will likely run out of time and submit whatever you have, instead of a proposal that reflects what it will take to win. In the a review of the Content Plan before turning it into a narrative, so that we can make sure the positioning is correct. This is also the reason why recycling narratives usually hurts a proposal more than it helps. When you re-use a narrative, it will not be positioned correctly. All five of the key positioning areas described above should be different for every customer, and probably every bid. Changing the positioning means changing the context of the narrative. This requires changing most of the words, and not just some of the words. But the good news is that if you start writing the proposal understanding how you want to position your bid, then it is much easier to know what to say about each requirement. And instead of a proposal that merely meets the requirements and is full of unsubstantiated claims, you get a proposal that substantiates the positioning and shows how your approach to meeting the requirements adds up to the best alternative for the customer.

It’s important to be able to define proposal quality if you want to make sure that the proposal you develop reflects it. We define it as a proposal that reflects what it will take to win. We define what it will take to win as part of our process, reaching all the way back before the RFP is released so that the questions we ask and information we gather enable us to say what it will take to win. We use Proposal Content Planning to bring what it will take to win together with the other things that should go into writing the proposal. What integrates writing about fulfilling the requirements and addressing what it will take to win is how you position yourself. You must position yourself against several things in a proposal: The RFP The evaluation criteria The competitive environment The customer’s preferences and issues The requirements of the opportunity itself The results desired from what is being procured The resources required Your own strengths and weaknesses Your history and experience The customer’s history and experience Pricing Terms and conditions Depending on how granular you make it, this list could become infinitely long. The short list is positioning against: The customer Opportunity Competitive environment Your strengths and weaknesses The RFP Everything else fits under these five. This makes them easy to remember and use. Because positioning is how you implement what it will take to win in writing, it becomes a shorthand for proposal quality. In the formally identify the elements that drive what it will take to win and then turn them into quality criteria that we use to validate the proposal. But you can do a quick and easy informal assessment just by looking at the positioning. Ask yourself how your proposal is positioned against: The customer’s preferences and issues The requirements and desired results The competitive environment Your own strengths, weaknesses, and history The RFP, especially the evaluation criteria In many of the proposals we have reviewed for our customers, it’s really a question of “if” there is any positioning instead of “how” the proposal is positioned. If you read the proposal and it isn’t clear how it is positioned, then it’s not well positioned. If positioning is hidden or subject to interpretation it isn't positioning. If you read the proposal and it: Doesn’t address the customer’s preferences or issues Only addresses fulfilling the requirements, without addressing the results or benefits you will bring Ignores the competition or the fact that the customer has alternatives to consider Treats the customer like a stranger or only addresses your strengths Positions yourself against the RFP as being (merely) compliant Then your proposal does not reflect what it will take to win and is a low quality proposal. If it reads positively for some, but negatively for others, then it is only partially positioned to reflect what it will take to win. In other words, it's vulnerable to losing. Because positioning is the context for your proposal, it is critical to review your positioning before you begin writing. If you try to change the positioning after the proposal is written as a narrative, it will be extremely labor intensive to change the context of every sentence. If you try to discover the right way to position your bid by writing and re-writing, you will likely run out of time and submit whatever you have, instead of a proposal that reflects what it will take to win. In the a review of the Content Plan before turning it into a narrative, so that we can make sure the positioning is correct. This is also the reason why recycling narratives usually hurts a proposal more than it helps. When you re-use a narrative, it will not be positioned correctly. All five of the key positioning areas described above should be different for every customer, and probably every bid. Changing the positioning means changing the context of the narrative. This requires changing most of the words, and not just some of the words. But the good news is that if you start writing the proposal understanding how you want to position your bid, then it is much easier to know what to say about each requirement. And instead of a proposal that merely meets the requirements and is full of unsubstantiated claims, you get a proposal that substantiates the positioning and shows how your approach to meeting the requirements adds up to the best alternative for the customer.

It’s important to be able to define proposal quality if you want to make sure that the proposal you develop reflects it. We define it as a proposal that reflects what it will take to win. We define what it will take to win as part of our process, reaching all the way back before the RFP is released so that the questions we ask and information we gather enable us to say what it will take to win. We use Proposal Content Planning to bring what it will take to win together with the other things that should go into writing the proposal. What integrates writing about fulfilling the requirements and addressing what it will take to win is how you position yourself. You must position yourself against several things in a proposal: The RFP The evaluation criteria The competitive environment The customer’s preferences and issues The requirements of the opportunity itself The results desired from what is being procured The resources required Your own strengths and weaknesses Your history and experience The customer’s history and experience Pricing Terms and conditions Depending on how granular you make it, this list could become infinitely long. The short list is positioning against: The customer Opportunity Competitive environment Your strengths and weaknesses The RFP Everything else fits under these five. This makes them easy to remember and use. Because positioning is how you implement what it will take to win in writing, it becomes a shorthand for proposal quality. In the formally identify the elements that drive what it will take to win and then turn them into quality criteria that we use to validate the proposal. But you can do a quick and easy informal assessment just by looking at the positioning. Ask yourself how your proposal is positioned against: The customer’s preferences and issues The requirements and desired results The competitive environment Your own strengths, weaknesses, and history The RFP, especially the evaluation criteria In many of the proposals we have reviewed for our customers, it’s really a question of “if” there is any positioning instead of “how” the proposal is positioned. If you read the proposal and it isn’t clear how it is positioned, then it’s not well positioned. If positioning is hidden or subject to interpretation it isn't positioning. If you read the proposal and it: Doesn’t address the customer’s preferences or issues Only addresses fulfilling the requirements, without addressing the results or benefits you will bring Ignores the competition or the fact that the customer has alternatives to consider Treats the customer like a stranger or only addresses your strengths Positions yourself against the RFP as being (merely) compliant Then your proposal does not reflect what it will take to win and is a low quality proposal. If it reads positively for some, but negatively for others, then it is only partially positioned to reflect what it will take to win. In other words, it's vulnerable to losing. Because positioning is the context for your proposal, it is critical to review your positioning before you begin writing. If you try to change the positioning after the proposal is written as a narrative, it will be extremely labor intensive to change the context of every sentence. If you try to discover the right way to position your bid by writing and re-writing, you will likely run out of time and submit whatever you have, instead of a proposal that reflects what it will take to win. In the a review of the Content Plan before turning it into a narrative, so that we can make sure the positioning is correct. This is also the reason why recycling narratives usually hurts a proposal more than it helps. When you re-use a narrative, it will not be positioned correctly. All five of the key positioning areas described above should be different for every customer, and probably every bid. Changing the positioning means changing the context of the narrative. This requires changing most of the words, and not just some of the words. But the good news is that if you start writing the proposal understanding how you want to position your bid, then it is much easier to know what to say about each requirement. And instead of a proposal that merely meets the requirements and is full of unsubstantiated claims, you get a proposal that substantiates the positioning and shows how your approach to meeting the requirements adds up to the best alternative for the customer.

The best way to win a proposal is to write about what matters to the customer. But there is another, even more powerful way to win. Unfortunately, it’s dangerous. If you don't get it exactly write, you'll probably lose. If you do, you'll probably win. While writing about what matters to the customer is what everyone aspires to, it is at best the second most powerful form of proposal writing. The most powerful form is writing about what should matter to the customer. Writing about what should matter enables you to sell a story about what is possible for the customer, that they might not even realize themselves. Writing about what should matter means writing about what’s possible, and how the customer can fulfill their destiny. It also means that you can alienate the customer, get their goals all wrong, and appear completely out of touch. That’s why it’s dangerous. The thing is, sometimes you’ve got nothing to lose: If you are not the incumbent, and you think the incumbent has all the advantages, don’t position yourself as the same but a little better or cheaper. Try positioning yourself as delivering something that should really matter to them, that the incumbent will never provide. If you don’t know what matters to the customer, you can play it safe, but it’s hard to be the best alternative that way. Another option is instead of talking about what matters to the customer (because you don’t know what that is), try talking about what should matter. You might get it wrong. But if you get it right, you’re very likely to be the best alternative. If you are a small company competing against much larger competitors you can take risks that they never will. In a big company it’s acceptable to lose with a proposal that looks like every other proposal. You can always blame the loss on price. Big companies can’t bring themselves to take a chance on getting it wrong by proposing what should matter to the customer. Even if they tried, their internal proposal reviewers would all yell at them for proposing something that “might offend” the customer. They just can’t do it. But you can. You can offer the customer something they never will. Something that really, really, matters. At least it should. When you write about what should matter, you can’t think small. It’s not about being a little better. It’s about painting a picture of the future that’s extraordinarily better. It’s not about bringing improvements to the customer. It’s about enabling them to exceed what they thought their maximum potential was. It’s about greatness, pure and simple. When you write about what should matter, write about something great. Greatness has appeal, even when it’s not your flavor. Greatness will get the customer’s attention. Greatness will make the customer want to select you, even if you got some things wrong. It’s entirely possible that you’ll paint a picture of greatness that just doesn’t reflect the customer’s priorities (even though you thought it should), or takes them in a direction they don’t want to go. You may lose because of it. It’s dangerous. When Apple was tiny next to Microsoft, Steve Jobs designed computers around what he thought should matter. He didn’t even ask his customers. But what Apple said should matter about computers resonated with a large share of the market. It also turned some people off. And the things they got wrong (Apple Lisa, the Newton) their customers didn’t hold against them because they weren’t part of what mattered. Had Apple chosen a strategy that didn’t push away some customers, they would never have become great. But it was a dangerous approach. For every Steve Jobs, how many failed visionaries are there? Ultimately, your win rate will be the highest when you discover what matters to the customer and base your proposals on that. But if you don’t know, can’t find out, and have to beat someone who does, you can always take a chance and play dangerously.

Subject matter experts or project managers often write the technical approach in response to the statement of work in a proposal. The Technical Approach volume addresses what you propose to do or deliver to the customer. Writing the technical approach often requires significant technical subject matter expertise. What the subject matter experts may lack in writing and fine art skills, they often make up for with enthusiasm for their subject. When they bring that enthusiasm to the proposal, the result is mostly positive. People debate whether proposal writing specialists interviewing technical subject matter experts is a better approach, but either way, the subject matter experts are involved. They just need to be guided in the right direction to end up with a winning proposal. Project management training helps people understand planning and execution, but doesn't teach how to help someone else make a decision. Throw in a complicated RFP that's difficult to interpret, and it's easy to see why technical staff focus on the wrong things in their proposal contributions. So what should the best technical approach focus on? Technical subject matter experts often come into proposals thinking: It must focus on the technical details. It must be all meat, with no fluff — which to them means be all technical. It must show the right way to do things, regardless of what it says in the RFP. All of these common answers are wrong. Worse, they are wrong on their technical merits. They are a result of enthusiastically sticking to what you know, instead of solving the problem. What the customer needs from a technical approach document is to determine which offering is their best alternative. The technical details play a role in this. But the real focus for a technical approach should be on what the customer will get as a result of what is being offered. They need to see that what they get will fulfill their goals. Accomplish those goals matters more to the customer than the technical details of how those goals are accomplished. They need to see why it is their best alternative. Often the explanation of why you do things or chose what you did matters more to the customer than what you will do or the procedures you will follow. Once the customer sees what they will get, then how the work will be done becomes part of how they assess whether you will deliver as promised. All the technical details are part of establishing your credibility, but that comes after you’ve demonstrated that the technical details deliver what they want. This is also why you shouldn't follow a template to write your technical approach, and why a technical approach example can lead you astray. A technical approach is not a description of something done the same way every time because each customer has different goals. Even if your procedures remain the same, the goals they should accomplish for this particular customer will be different. The technical approach should not be presented the same way or in the same sequence every time. What makes you the customer's best alternative may also be different for each proposal, requiring changes in the reasons why you are proposing what you are. And that's what you should build your technical approach around. You should end up with a highly personalized proof of why your approach is the best way to go for that particular customer, and not a generic template description of what you do. What is the goal? For the customer, they are procuring something to fulfill a purpose. One that they’ve put a considerable amount of effort into pursuing. The goal of a technical approach is to demonstrate fulfilling that customer’s goal better than any alternative. The goal is not to explain how you would do things. The difference is subtle, but it matters. A lot. It's the difference between winning and losing. When you are on the receiving end, do you evaluate a technical solution by the approach or the results? If it delivers the wrong results, who cares about the approach? If you focus on the details instead of the results and a competitor focuses on the results, then their technical approach will likely be seen as the best alternative, even if your approach is technically superior. Your goal in writing a technical approach is not to be technical superior, but to explain why your approach should be chosen. Being technically superior may or may not be part of that rationale. Your technical approach should talk about results because ultimately that is what the customer wants. It should explain what the customer is going to get, why your approach matters, and why you made the choices you did. Understanding “why” you do things is more important to the customer than understanding “how” you do things. The customer will say to themselves, “If I select this proposal, I will get [fill in the blank] because [fill in the blank]. I believe they will be able to achieve that because their approach is credible.” The approach is actually the last thing they consider. Even when the evaluator is technical. It’s easy to understand why people get tricked into believing that the approach is the most important thing. For starters, there’s the name, “Technical Approach.” It does not accurately describe either what information the customer needs or what they are trying to do. Then there’s the way that customers write their RFPs. They ask you to describe your approach for doing what they ask. They really make it sound like they want to hear all about your approach and will make their selection that way. Only they didn’t write the RFP because they want to purchase an approach. They wrote the RFP to fulfill their goals. And their best alternative for achieving those goals will be the proposal that best demonstrates how what the vendor does results in achieving those goals. That is the most important technical requirement. That is what the technical approach should be about.