Carl Dickson

Proposal schedules should be about more than just crossing off the items on your outline and counting the days until your deadline. Proposal schedules should be about whether you have achieved your goals and done the things necessary to win. In order to ensure those things get done, you need a Validation Plan to check each item. The following lists put the items you need to win in sequence and provides guidance for when they should be validated. The result is a set of proposal milestones that can be used to trigger reviews and measure progress. Before RFP release, validate that: The opportunity is worth pursuing You have identified what it will take to win so you can measure progress and quality against the list You have defined your win strategies You have identified and taken the actions needed to implement your win strategies You have collected the intelligence you will need to write the winning proposal You have properly positioned your company You have done everything you can to prepare for the proposal You are ready for RFP release At RFP release, validate that: The RFP is what you expected The RFP does not contain any requirements that are show stoppers (including all performance standards, service levels, and other specifications) The contractual terms specified in the RFP are acceptable You are still interested in bidding Before you start writing, validate that: Your proposal plans are ready to implement Your Win Strategies are correct and optimized against the evaluation criteria The compliance matrix includes all response requirements The outline includes all requirements from the compliance matrix in the correct sequence The Content Plan identifies everything needed to produce the right proposal, and can be used as a baseline to evaluate the draft against Each graphic in the Content Plan has the primary objective identified The schedule is the best allocation of time, and deadlines are realistic and enforceable Assignments are correct, no one is overloaded, and everyone who can contribute is included The Validation Plan is sufficient to meet the required quality standards The Production Plan is RFP compliant, properly sized and scoped, and will result in the right deliverable document Upon receipt of early drafts (incomplete), validate that: The draft addresses everything in the Content Plan. Track deficiencies until gone. The draft is compliant with the RFP. Track deficiencies until gone. The draft contains experience citations in every place relevant/possible throughout the document. Make suggestions. The proposed approaches reflect the best cost/benefit trade-offs and the customer’s preferences. In every section, has every opportunity been taken to use graphics to communicate visually? Will you have any problems staying within any page limitations? Upon receipt of later drafts, validate that: Any changes to the RFP have been incorporated. Nothing has changed in the document that might make it non-compliant. The draft will score against the evaluation criteria. The draft properly implements all win strategies. The draft reflects your full awareness of the customer. The draft positions you properly against the competition. The reasons why the customer should select you are clear. Are graphics used to replace text instead of being redundant? Is the primary objective or conclusion of each graphic clear? Is everything in the graphic appropriate for the anticipated audience? Does the graphic answer all of the questions that it should? Does the graphic present the subject matter accurately Are the graphics free of errors? The document is ready for production. Early Pricing Validation The pricing model is properly structured The pricing targets are valid and competitive Assumptions are being collected and tracked Later Pricing Validation The pricing data is compliant, accurate, and properly structured All ODCs and other costs are accounted for Explanations are properly provided for any pricing data that require them All assumptions are fully documented The pricing is compatible with the technical/management proposals The pricing data is competitive while meeting revenue/profit goals Production Validation The document has been edited and proofread The document matches the specifications of the Production Plan The document has been assembled correctly The document is ready to package The packaging and labeling match the specifications of the Production Plan The document is ready to submit The document has been received

Proposals responding to Federal Government RFPs can easily have 20-30 people working on them. It would be rare to do one with less than a half-dozen people involved. The following list shows why there are so many and what do they all do, to help you develop your proposal plan. This list is meant to be a typical break down --- not all companies or proposals will include all of the positions below, and some may add others. Capture Manager. Has overall accountability for the new business development effort. This includes assuring proper corporate support is available when needed. Responds to the lead corporate executive with P&L accountability. Coordinates the efforts of business development, engineering, finance, contracts, program management, and proposal management specialists. The Capture Manager is in charge of the core team and contributes to the development of the proposal plan. Proposal Manager. Has operational control over the proposal plan. Directs Volume Leads, Section Managers, Book bosses, Coordinators, and Production Managers. Implements proposal processes and planning. Sets and manages proposal schedules, plans, deadlines, and progress monitoring. Develops the proposal outline and compliance matrix. Obtains (or advises appropriate managers regarding the need for) proposal staffing and other resources. Oversees the coordination of all proposal activities. Unless specifically requested, the Proposal Manager typically has only coordination involvement in the Cost/Price Business Proposal. Proposal Coordinator. Responsible for administrating proposal processes, providing configuration management, and preparing proposal related reports. Also responsible for administrating proposal related resources. Assists the Proposal Manager in tracking status and ensuring that deadlines are met. The Proposal Coordinator is a management position and not a clerical position. It requires significant understanding of computer applications and proposal processes. Volume Managers, Section Managers, or Book Bosses. Proposals are typically broken down into volumes or sections, each requiring someone to oversee the development of that portion of the proposal. At the direction of the Proposal Manager, oversees the activities of the individual authors who write the proposal. May or may not take part in writing. Responsible for meeting scheduled deadlines, conforming to the proposal outline and compliance matrix, and inclusion of themes/discriminators, illustrations, and other material as directed. Responsible for implementing proposal processes and formats. Coordinates with others as required to ensure that proposal content is satisfactorily and consistently prepared. Usually participates in Review Team debriefs in order to incorporate feedback into their sections of the proposal. A half-dozen or more Section Managers would not be unusually for a typical proposal. Subject Matter Expert. Provides specialized expertise to support the development of the technical approach and related writing. May separately serve as a Review Team Member or as a section author. Author. Writes text and specifies illustrations for the proposal. Responsible for incorporating proposal strategies, themes/discriminators, technical/management features and benefits, and other material into the sections. Participation usually begins during storyboarding and continues through red team or final draft when the core team takes over. Edits text in compliance with the Proposal Manager or Section Leads guidance. Some authors may specialize in writing resumes or project summaries. A half-dozen to a dozen authors would not be unusual. Review Team Leader. Directs the efforts of the Review Team Members and participates in scheduled proposal reviews. While not involved in content development, the review team leader should be identified early in the process and is typically a senior or executive manager. The review team leader establishes the criteria and assignments for each of the reviews, works with the Capture Manager to leverage the review processes to validate approaches and fulfillment, collects and structures Review Team Member comments, and leads the review debriefing. Review Team Member. Review Team Members are assigned specific sections of the proposal to review and are provided direction by the Review Team Lead. Review Team Members are typically asked to review for compliance, clarity of presentation, score with regards to the evaluation criteria, adherence to proposal strategies, use of themes/discriminators, use of illustrations, and technical/management approach merit. Members will document deficiencies, items requiring clarification, and evaluation score according to the direction of the Review Team Lead, and will contribute to and attend debriefings as required. Review Team Members are generally drawn from senior staff who have not participated in the development of the proposal. They should be diligent and constructive. Anywhere from two to a dozen review team members would not be unusual. Cost Strategist. Ensures that the cost volume is compliant, competitive, and compatible with the proposal. Develops the cost strategy and layout of the cost/business volume. Establishes the guidelines for the Basis of Estimates and Bill of Materials if required. Oversees the development of or writes any text required for the cost/business volume. Contracts Specialist. Serves in an advisory role to the Capture Manager and Proposal Manager. Reviews the RFP for contractual matters, participates in strategy development to ensure that it is compliant with RFP clauses, and reviews the proposal for compliance. The Contracts Specialist is generally responsible for preparing required forms, clauses, representations, and certifications (typically found in Section K). These are typically included in the cost/pricing volume. Production Specialist. Supervises production staff, including desktop publishing, layout, graphics, word processing, and editors. Responsible for preparing hard and soft copy from the author’s submissions and maintaining configuration management during the effort. Works with the Proposal Coordinator and the Proposal Manager to ensure deadlines are met and that the final output is compliant with the RFP and proposal plan. Graphic Artist. Prepares illustrations for the proposal. Responsible for meeting deadlines, compliance with RFP formatting instructions, achieving visual consistency, and maintaining configuration management. May work from hand-drawn drafts or take electronic drafts. Desktop Publishing/Layout Specialist. Develops formats and typographic styles that comply with the RFP and proposal plan. Responsible for integrating text and graphics into the finished copy, and for maintaining configuration management. May also perform limited word processing and illustration. Prepares both hard and soft copies as required. Editor. Responsible for validating style, consistency, grammar, and syntax of the final document. Re-writes as needed to clarify and simplify text. Recommends additional graphics or modifications to existing graphics. May play a role in reducing the text to meet page limitations.

The job of a proposal is to persuade a potential customer to do business with you. To achieve this goal it is critical that your proposal anticipate and answer all of your customer's questions. A successful proposal usually results in a contract that sets the terms. Sometimes the proposal is a hurdle to be crossed before contractual negotiations begin. Sometimes the proposal is structured to be incorporated into the contract to facilitate things. In less complex environments, the contract may be included with the proposal to facilitate closing and implementation at award. Because there is usually a distinction between the proposal and the contract, the proposal must answer the client’s questions so that you can get to the contract signing stage. Therefore your proposal should be laid out to provide clear answers and terms for doing business. For this reason, many people lay their proposals out in a question/answer format. However, if your proposal is in response to a written RFP, the RFP may contain formatting instructions that you will have to follow, and these instructions may not permit a question/answer format. Here is a list of typical questions to answer in your proposal: Who are you and why are you sending them this proposal? What the customer will get: products, configurations, capabilities, resources, services, effort, accomplishments/results, deliverables? How it will benefit them? How you will manage delivery/fulfillment? How long will it take? What are the risks and what you will do to mitigate them? Who will work on the project? Who will manage the project? What experience does your company have with similar projects? References/testimonials How you will ensure quality and customer satisfaction? How you will know/measure success? What will the customer will have to do or supply? What options do they have to select from? Future considerations Are there any other relevant capabilities, resources of your company? What assumptions did you make in writing the proposal? How much will it cost? What payment terms do you require? What legal/contractual requirements are there? The customer will also have questions that they don’t expect to be answered in your proposal. It is a good idea to at least imply answers to these questions as well. Here is a list: What are their alternatives to working with you/who are your competitors Are they getting the best price Can they trust you

When customer's release a draft RFP, it makes it considerably easier to prepare ahead of the final RFP release. When they don't release a draft RFP, it is still just as important to prepare ahead of RFP release, but much harder to know exactly what information you need and what format to present it in. This alone is a big reason why many companies make the mistake of waiting until RFP release before putting pen to paper. If the customer doesn't release a draft RFP, you should consider making one yourself. The exercise of creating your own draft RFP will force you to seek answers to key questions. How extensive will the scope of work be? Will there be a past performance review? Will it be a "best value" procurement or a price shoot-out? What will be the most important evaluation considerations? You'll need to ask the customer these questions. In fact, you'll need to ask more than one person at the customer, since one person won't know all the answers and some may have conflicting opinions. Don't worry so much whether their answers match the final RFP exactly --- the differences can often tell you as much about the customers actual preferences and level of internal consensus as would similarities. The key is that it gets you talking to the customer and helps you develop an understanding about what it is they want, separate from what makes it into writing. You should specifically target developing an understanding of what problems the customer would like to see this procurement solve. Going through the effort of creating your own draft RFP also gives you a rallying point for collecting information. For example, you can begin to identify relevant projects and collect contact data based on a high level understanding of the scope of work. You can begin determining your win themes as soon as you develop an understanding of the customer's evaluation considerations and preferences. You can also begin doing competitive assessments based on your strengths and weaknesses while you can still ask the customer about what they consider important and their familiarity with your competition. And don't forget to do a critical self-examination. Does the client know you? What is your past performance record? Get this directly from the client and not from your project staff. Don't drink your own bath water --- no one wants to admit when they've had problems with their customer. Identifying problems early give you a chance to correct them, enables you to prepare your win themes and written material as a defense, and in the worst case might lead you to walk away from a bid that you cannot win. Finally, make sure that your internally developed draft RFP is a written document, and not just someone's "understanding" of the customer's requirement. A written document can be distributed and the level of customer understanding assessed. It can be verified with others who know the customer. And when the final RFP is released, it can be compared, telling you what to keep, what to change, and providing additional insight into the customer.

One day I got a call from a company I had helped prepare a proposal. They are a staffing company that specializes in healthcare workers. They are a small business and had lost their last five bids in a row. They called because they received an email informing them that they did not make the competitive range on the proposal I helped them submit. My stomach leapt into my chest. A decent proposal should always make the competitive range. I was wondering what on earth went wrong and why I didn't catch it. We arranged for an immediate debrief by the customer. The debrief was handled by teleconference, so I was able to listen in. The debrief started with the evaluators introducing themselves. Then each one read the notes from their scoring sheets. There was no discussion, just a presentation of how the proposal was scored. When the past performance evaluator started, he took great pains to emphasize that because they used surveys, the results were a snapshot in time and could be a little different on every bid. He qualified his response so much before he even started that I knew something was up. In 2004, on one of the company's projects, they had not staffed the open positions quickly enough. The customer ultimately issued a cure notice. My client responded by replacing the project manager and adding resources. The project was currently operating within specifications. But it's possible that the customer held a grudge. They responded to a multiple choice survey by selecting the option that they would not choose to do business again with my client if given the choice. In a past performance evaluation, this is the kiss of death. It doesn't matter if the company has fixed the problems. They have a negative mark that's on their "permanent record." The customer maintains a database in which all contract actions are recorded. Every time they look up the project, the negative information is there. Not only that, but the contract was coming up for recompete in just a few months. I met with the head of the company and discussed the potential disastrous impact of the news. We identified several things to do in response: The head of the company should immediately meet face-to-face with the customer To clarify the customer's position and give the company leader a chance to hear it directly from the customer To identify possible corrective actions To demonstrate commitment Even though the problems had been corrected, the company must rededicate efforts to restore customer satisfaction. The goal must be to get the customer to enter into their database that the company has transformed into a superior contractor. The company must be prepared to go well beyond the requirements to achieve this. The company should recognize that "at risk" and low margin performance might be required. Use innovative bid strategies to overcome past performance evaluation issues. Revise/strengthen the past performance write-up to drive home all the things the company has done to fix the problem. Team with companies that have proven positive past performance. Leverage the Mentor Protégé program to use the mentor's references instead of the company's references. Focus on developing business with other customers. Purchase access to market research tools to identify other customers who purchase the services offered by the company. Pursue other customers that do not have access to this customer's past performance database. Give customers true discriminators so they have a reason to select the company that goes beyond price and past performance. Within two weeks, the head of the company had scheduled a face-to-face meeting with the customer whose project had reported the negative past performance (not the potential customer that the bid was submitted to). The customer contact claimed she did not know who had completed the survey or why it was completed that way. The customer contact said she was actually satisfied with the company's current performance. The customer was pleased to see the CEO taking an active interest in customer satisfaction and agreed to work with the CEO on follow-ups. This left us a little confused. Did the survey go to someone else, or was the customer seeking to avoid confrontation? About a month after the debrief, the customer issued a new task order request under the current multiple-award indefinite delivery/indefinite quantity (ID/IQ) contract. The customer had not released any new task orders for the last 18 months. There were 10 companies eligible to bid on the task order. We polished the past performance write-up until it positively shone, while knowing that we had no control over what is in the customer's database. We called the customer to make sure that the right person would receive and respond to any surveys. Ten days after the task order bid was submitted, we found out that we had won. Not only had we overcome any negative past performance, but we had won the only task order issued in 18 months and the last one to be issued before the contract recompete. We also broke the company's losing streak on bids. So was it the past performance write-up that itemized all the corrective actions and tangibly showed that the company is not only a much better company but one with strong current performance, or was it the face-to-face visit by the CEO showing commitment to customer satisfaction? My bet is on the visit, but the write-up put in place the information that the evaluator needed to overcome what was in the database.

Depending on the type of work and how the RFP defines the requirements, you may need to conceptualize your approach as well as your content. This is typically true of proposals to provide solutions or to perform research. If the RFP does not tell you what to propose or how to do the work then you have to determine how you will achieve the goals in addition to what you will say about it. Conceptualizing and validating your approach is basically an engineering problem. If you already have an engineering methodology, then we encourage you to use it. If you do not, then you need to: Define the solution. What are you going to do in order to achieve the goals? What is your approach? Specify the solution. You need to document it so that others can collaborate. But you do not have to do this in a full narrative. We recommend using illustrations. They enable you to identify the components and annotate them where necessary. Simple hand sketches should suffice. Storyboards are a traditional approach to proposal planning that work better for planning solutions than they do for planning content. If your solution is too complex to render with a series of illustrations, then storyboards can be used to document it. If you use storyboards, then take care not to entangle solution planning with content planning. Validate the solution. Are you prepared to commit to this approach? Have all stakeholders provided input? Will it achieve the goals? Is it realistic, feasible, and efficient? Is it compliant? Is it within budget? Does it offer competitive advantages? Your validation plan for the proposal should address validating the solution separately from validating the content. Write the solution into your proposal. This can be as simple as transcribing the illustrations or storyboards into the Content Plan and then following through with the narrative. Regardless of the approach you take to planning the solution, you still need to plan how the content will be developed before you start writing. When both the solution plan and content plan have been validated, then you are ready to start writing. I can’t tell you how many times I’ve seen a proposal thrown into chaos because during a late-stage review someone decided the solution was wrong. When this happens, it’s a double-hit — in addition to the time you spent on the original solution, you also lose the time it took to write about it. That is why it’s critically important to validate the solution before you start writing it. This is why storyboards were invented. Unfortunately, while storyboards work for brainstorming and validating a solution, they don’t work so well for content planning. And since many RFPs tell you the solution, people were trying to plan their content using the wrong tool. Ultimately most gave up, and that is why you hear people talking about storyboards but rarely actually using them. In order to move forward, you must recognize that solution planning is different from content planning, and that not all proposals require solutions. When you do this, you can start using the right tool for the right job and avoid entangling the solution with the writing until after the solution has been validated.

Many proposal problems are the result of having to deal with a bad RFP. Bad RFPs come in a number of different forms: Too much detail. While it is not as big a problem as it used to be, some RFP authors try to document every specification and sub-specification possible for even the most minute requirement. While on one hand, they need to ensure that nobody proposes something sub-standard to reduce the price, specifying the requirements at too granular of a level creates its own problems. RFPs that say “do not simply restate the requirement in the proposal” but then go on to specify in great pain-staking detail exactly what you are to propose are a particular nuisance. Not enough detail. If customer doesn’t sufficiently describe what they want, it can be nearly impossible to write a proposal, let alone price it accurately. Requirements that contradict each other. Large RFPs often have multiple authors. If the right hand doesn’t know what the left is doing, they can insert requirements that are impossible to meet since they contradict each other. Usually the only way to resolve a contradictory requirement is to submit it as a question to the customer. Poor organizational requirements. Service RFPs often specify that certain staffing is required. However, they often include just enough reporting detail to cause problems with creating a rational organization chart. Poor correlation between staffing and activities. Position descriptions provided in an RFP often conflict with the activities required. Either the description has requirements that aren’t necessary for the activities, or they don’t specify who should perform certain required activities. Inconsistent delivery schedules. The delivery schedules specified in the RFP often will not match up with the production requirements. Dependencies are often overlooked. A lack of correspondence between the instructions, evaluation criteria, and statement of work. RFP instructions often specify the outline that you should follow in your response. The evaluation criteria tells you how you will be graded, and should indicate what is important to the customer. Unfortunately they can also introduce new requirements and/or fail to account for portions required in the instructions. Missing or vague instructions, evaluation criteria, or statement of work. If the RFP does not include any instructions for how the proposal is to be formatted or organized, it makes it difficult to provide the information in a way that meets the customer’s expectations. If the evaluation criteria is missing or vague, you won’t know what is important to the customer (although that’s probably better than wrong or misleading evaluation criteria). There are a couple of techniques that you can use to cope with bad RFPs: Make assumptions. If there is not enough detail, create your own and document it as a list of assumptions. Provide options. Providing options in your proposal lets them select how they want things to be interpreted. Ask questions. Ask A LOT of questions. Ask questions you don’t even need the answer to. Ask the same question three different ways. Just ask a lot of questions. And then ask for an extension because there are so many answers and not enough time to incorporate them all. It is a good idea to collect all of your questions for submission at one time, so that you don’t annoy the customer by calling every day with another question. If you have multiple authors, you should designate one person as the “stuck-ee” for consolidating the questions so that you don’t ask the same thing twice. When asking questions, always reference the RFP page and paragraph number. Also, carefully consider how you want the question answered and format your question accordingly. Otherwise, you’ll get the answer they want to give and it won’t even address your question. They’re probably going to do that anyway (remember, they wrote the messed-up RFP to begin with), but at least you’ll have a chance of getting the information you need. Customers have an amazing ability to answer any question, no matter how it is worded, with “yes” or “no.” By carefully wording your question, you can prompt them to provide: a yes/no answer, a numerical answer, a narrative clarification, or a selection from among a list of alternatives that you provide, The right way to cope with all of the above is to have a long-term customer relationship so that you have the information you need before the RFP is even released and know how the customer wants you to interpret what they have written. However, the purpose of this document is to help you do a proposal The Wrong Way, while preserving your chances of winning, as best as is possible.

As quickly as possible, proposal managers try to turn the chaos in which most proposals start into a finite process, with all the parts known and tracked. The goal is to move from total chaos to an itemized “to do” list that you can work through, item by item, to completion. Some people are more organized than others, and as a result, some are more formal in their approach than others. The problem with this approach isn’t that people manage by making lists, it’s that this approach is totally dependent on the subjective decisions and skills of the list maker. If you want to improve the management of your proposals, a good place to start is by formalizing the way you go about making your lists. Most people manage the content by using the outline as their list. They check off each item as it’s written. At this stage, they don’t know whether what was written is useful or not. That’s why they have proposal reviews. They set up another list of action items for implementing reviews, and then another list of action items to correct any issues the reviews discover. From the very first list, they are on the wrong track. Or maybe it’s that they are tracking the wrong things. If you are tracking section by section you are not tracking what you want. What you want is to win. In order to win you need to achieve certain things in writing. Those are the things that you need to track on your list. Instead of asking people to complete a draft of the sections assigned to them, the first thing you should do is identify the items you need the authors to achieve in each section in order to win. In the CapturePlanning.com MustWin Process, we call this creating a Content Plan. A Content Plan acts like a recipe for the proposal. It facilitates the review process by providing a baseline to measure the proposal against. It enables you to verify whether the proposal achieves the goals it was supposed to. It also provides a list that both the authors and the proposal manager can use during writing to measure progress. No more waiting for a draft from the author, then waiting for it to be reviewed, only to find out that it totally missed the mark. With a Content Plan you can check off each goal as it is achieved. In fact, you can validate the fulfillment of each goal in real time, rather than waiting until all the sections are complete and sent off for review. Instead of thinking in terms of proposal reviews that occur at certain milestones, it is better to think in terms of identifying the things you need to validate. When you do this, in addition to providing better scope definitions for the reviews, you can approach your reviews as a list of items to be completed. You have a list of specific proposal attributes to check. Some may happen at sit-around-a-table reviews, and some may not. Instead of trying to orchestrate meetings with unreliable results, your reviews target the items on your list to validate. When you’ve worked through your list, you have a fully validated proposal that you know is ready for submission. The key to using lists to manage a proposal lies in making your lists relate to your goals rather than being simply a random collection of action items. The first step is to identify what it will take to win. Next turn them into instructions for writers, and then validate that that they where carried out in the document. The proposal effort then becomes finite, measurable and, most importantly, focused on achieving everything needed for you to win.

Sometimes what distinguishes different types of proposals isn’t their market, but other characteristics. For example, proposals produced by a single author are very different from proposals that require multiple authors. A large proposal might have over thirty people involved (a proposal manager, production manager, coordinator, several section leaders, a half-dozen subject matter experts, illustrators, layout/production staff, team members, several outside reviewers, contracts/legal specialists, pricing/accounting specialists, executive sponsor, etc.). The processes and planning required for a proposal with thirty people are completely different from what might do on your own. If you are doing your proposal on your own, you must be capable of doing all of the research, writing, and production. If you have multiple authors helping you, you must be capable of managing the collaboration. The number of authors has a significant affect on how the proposal is developed Characteristic Single Author Multiple Authors Processes You’re in control. Multiple hand-offs, notifications, and approvals. Configuration management is necessary. Communications There’s no one to communicate with. Everyone must be kept “in the loop” and up to date. Writing You write. You decide. Collaborative. Production After you write, you illustrate, format, and prepare the final copy. After you write, you hand off to illustrators, desktop publishers, copy, and production staff. Support What support? You’re it. Support may be available, but must be managed. Bottom Line Streamlined, but you’re on your own. You develop the proposal. The management level of effort goes up as the availability of resources goes up. The process develops the proposal.

A solicited proposal is when the customer asks for a proposal. They may ask verbally or they may issue a written Request for Proposals (RFP). An unsolicited proposal is when you send them a proposal they haven’t even asked for because you think they should buy from you or take some action. Solicited proposals are usually sent to customers who issue an RFP. When a customer wants something that is too complicated to pick up at the store or order from a vendor, they often write down a description of it and issue it as an RFP. If it is a commodity, they may issue a Request for Quotations (RFQ). An RFQ usually requires minimal information and a price. An RFP may require an extensive description of your approach or offering, as well as its price. A solicited proposal provides you with a description of what the customer wants. Many also provide you with formatting instructions for your proposal and the evaluation criteria that will be used to make a selection. Sometimes you will make a suggestion to a potential customer and they will ask you to submit a proposal so that they can consider your suggestion. This counts as a solicited proposal because they are expecting it and you have a chance to talk to the customer and gain an understanding of their needs. An unsolicited proposal is sent to a customer who has not requested it. Unsolicited proposals must be especially convincing since the customer has not anticipated, planned, or budgeted for the proposal. With an unsolicited proposal you run the risk that the customer won't even bother to read it, since they didn't ask for it. However, the lack of competitive pressure with an unsolicited proposal often makes up for the risk. If you send the same unsolicited proposal to a bunch of customers, what you really have is a brochure and not a proposal. A proposal should take into consideration the customer's specific environment, needs, and concerns. Proposals have a much higher win rate than brochures, because they better align what you offer with what matters to the customer.

What will it take to win? Start a list. Think about what you need to do for the customer to select you instead of the competition. This list not only provides you with a set of goals to achieve, but it also provides an objective definition for the quality of your proposal. RFP compliance The best score against the evaluation criteria A competitive advantage over your competition that you can articulate Acceptable contract terms in the RFP Proposed contract terms that are acceptable to the customer A set of compelling win strategies Themes that reflect the win strategies and are properly allocated to the document Clear articulation of the reasons why the customer should select you Narrative that reflects an understanding of the customer beyond what is already in the RFP A superior solution for meeting the customer’s needs Recognition of the client’s issues, problems, and challenges to overcome A credible proposal that mitigates risks and has the right processes to achieve quality Highly relevant references that will sing your praises Sufficient staffing/resources to execute a quality proposal Excellent visual communication/graphics A proposal document that is easy to navigate Experience citations and examples throughout the text Proposed approaches that reflect the best cost/benefit tradeoffs and the customer’s preferences Pricing data that is compliant, accurate, and properly structured Explanations and assumptions that are acceptable and persuasive Pricing that is competitive and within budget, while meeting your revenue/profit goals A document that is free from disqualifying errors Now prepare a list of action items based on achieving the items on your list. Make sure you look at each item and think about what it will take to get there. Doing this with some of them will carry you back in time all the way to before the RFP is released. Instead of managing the proposal by simply crossing off the items on the outline and counting the days that remain until the deadline, measure your progress by how many of the items you have fulfilled on your list of what it will take to win. You can also use this list to guide your review process. Instead of simply asking your reviewers whether the proposal is any “good,” ask them to validate that you have achieved the items on your list (and therefore have achieved what it will take to win).

The tips below go beyond the basics for how to format your proposals. They help you take advantage of proposal formatting to win your proposals. Two Headings are Better Than One. Instead of just a normal heading, use a short, descriptive heading plus a theme statement. The theme statement should be the conclusion that you want the customer to reach after reading the section. For example, the heading might say "Management Plan" in 16pt Arial Bold. Right underneath it (no line skip) it might say "XYZ company has the resources, procedures, and staffing in place to start this project immediately without delay or risk" in 12pt Times Italic. Then skip a line and start the narrative. You can do this with every heading, but you may only wish to do it for the first few heading levels. If you include the themes in your Table of Contents, you'll gain the added advantage of having a Table of Contents that tells your story. Make It Easy to Evaluate Compliance. Whereever you can, put the text of the RFP you are responding to into your proposal. An easy way to do this is to drop in a single-cell table and give it a gray background. Put the RFP text in it at a smaller point size (I use 9pt) than the narrative text. Put a small heading in the box that says something like "This section responds to the following RFP requirements:" Under a single numbered section heading in your proposal, you can have a series of RFP tables and responses. Or you can group multiple RFP requirements in a single table and respond to them collectively. How you allocate and respond to the RFP requirements depends on the particular RFP. If you can't include the full text of the RFP, then include paragraph numbers and/or keywords so the customer can easily look it up. Do what makes the most sense and will be the easiest for the customer to evaluate. Keep It Short. In sales letters and advertising, there is an age-old debate between the merits of long copy versus short copy. That debate does not apply to proposals. Nobody wants to read more in a proposal than they have to. Keep your writing style short to the point of being terse. Don't pad it out to make it "sound better." Say what you need to say and then end it. If you can deliver a proposal that is only one page long, don't add another page to make it "look more substantial." If you are worried that your proposal is too short, put your fears to rest. The issue is not whether your proposal is long enough, it's whether you have answered all of the questions that the customer is going to have. You need to do that, but you don't need it to be one page longer than is necessary to do it. If you have said anything that does not impact the evaluation, delete it. If you have unsubstantiated claims, either delete them or substantiate them. Put It In An Appendix. If you must provide supporting documentation, put it in an appendix. Especially if they didn't ask for it. If you want to include resumes and they didn't ask for them, put them in an appendix. If you want to provide commendation letters, put them in an appendix. If you want to provide data sheets, put them in an appendix. If you want to provide proof of insurance, financing, samples, or documents, put them in an appendix. Take everything that is not part of your story and put it in an appendix. That way, those who want to read (or do due diligence) will have all the content they desire, and those who don't want to read will be more likely to get through your story before they start skipping pages. Don't Forget Your Website. Anything that could go into an appendix could go on your website instead. Just give them the links. Any proposal that includes a software component should include a link to a demo on your website. Even if it is just a collection of prototype screen shots, you should invite them to come see it. If the proposal is important to you, make it interactive. If you are early in the process (pre-RFP), you can invite them to a slide show, and on each page ask them if a feature is "Very Important, Moderately Important, or Not Important" to go to the next page. A website gives you the opportunity to exchange information in ways that can't be done with a paper brochure or PowerPoint presentation. Take advantage of it. Don't Bind It Like a School Report. How you bind your proposal isn't that important. Just don't make it look like a school report. A three-ring binder or GBC binding is fine. But a report cover that looks like a school report sends the wrong impression. A staple is better. Black-and-White or Color? These days color printing is fairly inexpensive. You can look professional with a black-and-white proposal when your competitor has color. You just have to work harder at it. But really, it's not a question of what looks "more professional," it's a question of what communicates better. If you are printing in color, make sure that you are using color to communicate. You do this by using color to signal, classify, remind, direct attention, focus, highlight, or achieve some other purpose.

There are a lot of bad examples of proposal outlines out there on the Internet. Often what they teach at universities leads people to lose their business proposals. The nature of the outline depends on the type of proposal and the expectations of the evaluator. Here is an example of a proposal outline that was bad and how we improved it. For business proposals, proposal outlines should be driven by the customer's instructions. What goes into your outline starts with the Request For Proposals (RFP), and then incorporates the things you need to say in order to demonstrate that what you offer is the best alternative for the customer. A typical RFP will require you to respond to the following topics. Different RFPs will use different terminology, so they often change the names. Sometimes they drop a topic or add a new one. But generally they require: An Executive Summary that says what you will do or provide to the customer and how the customer will benefit from what you propose. It is where you introduce your company and any teammates or partners. It is also where you should make your case for why the customer should accept your proposal ahead of any alternatives they may have. A Statement of Work or Technical Approach to describe what you will do or provide to the customer. This will usually include your approaches, an implementation or delivery schedule, and the specifications for any deliverables. If products are being proposed, then product descriptions are usually provided (the amount of detail depends on the customer’s requirements). A Management Plan to describe how you will organize and supervise any work to be performed. A schedule of major milestones and allocation of resources is usually included, as well as your approach to quality assurance and risk mitigation. Your Qualifications to demonstrate your capability to do or provide what you are proposing. Relevant prior experience is usually highlighted. Past Performance and References may also be required. A Staffing Plan to describe how the project will be staffed is sometimes required for service contracts. If particular people are important to the approach, their resumes are usually included. Contracts and Pricing. If the proposal is being used to close a business deal, then business and contractual terms are usually provided. Some RFPs will set a page limit for the length of the proposal. Some don’t. Some RFPs will tell you the format/layout to use, and some won’t. Some RFPs will tell you what evaluation criteria and process the customer will follow. And some won’t. The customer sets the standards and defines the rules. If your proposal is going to be submitted to a Government agency, then the composition and layout of the proposal may have regulatory requirements to comply with. In the case of the Federal Government, these are usually based on the Federal Acquisition Regulation (FAR). Government RFPs can get so complicated that you need to create a compliance matrix in order to determine what the outline should be. But what if there is no RFP and the customer has not given you any instructions for the proposal outline? Then, you should base the outline on what the customer will need to see, and approach it by looking at it from the customer's perspective. Here is a link to something we wrote describing the best way to approach creating a proposal outline so that it reflects the customer's perspective. Going beyond the outline of your proposal There is a lot that goes into the content of a well-written proposal. It involves more than just what the customer requires and what you offer. What should go into your proposal should answer all the questions the customer might have, implement your strategies for winning the proposal, articulate your story and messages, and reflect what matters to the customer. Planning the content of a complex proposal requires going well beyond just an outline. In fact, we've created a whole methodology for figuring out what should go into the content of your proposals.

To give the proposal evaluators what they want, first you have to know what that is. Sounds easy doesn’t it? First you have to recognize that a customer’s organization may have more than one point of view, more than one preference, more than one agenda. The ones that matter most are the ones actually participating in the proposal evaluation, if you can determine who they are. People in your organization bringing you information will interpret the client differently --- project managers, business developers, executives, and others all come with a different bias. The RFP is supposed to tell you what the customer wants, but it often is not written by the evaluators, leading to circumstances where what the customer asks for is not what the evaluators actually want. Assuming the RFP is accurate it may be incomplete. I have seen RFPs with extremely detailed specifications for computer equipment that gave no clue whether the client was trying to centralize IT management at headquarters or empower its field offices. And you might get a different answer depending on whether you talked to some at headquarters or a field office. But opinions that count are the evaluators. Getting the wrong opinion can lead to bidding the wrong solution. One major reason why you should be talking to the customer before RFP release is that the client may not talk to you at all once the RFP hits the street, and if they do answer your questions you can be sure it won’t be on a level that provides real insight. To effectively give the evaluators what they want you have to have a real understanding about the client’s environment, goals, and agendas. On the vast majority of proposals I have worked on, the proposal team desperately wanted to give the evaluators what they wanted. Giving them what you want them to have is a recipe for losing, and most teams understand that. The problem is that knowing what they want requires insight above and beyond what is in the RFP. The only way to do that is to understand your client --- what are their goals, what problems do they face, do they have an internal consensus or competing factions, do they have preferences or bias, do they have constraints they have to work within, standards to comply with, or anything else that may affect their decision and may or may not be in the RFP? If the RFP just came out and you’ve never worked with the customer before you can forget about getting this kind of insight into your submission. Get to know potential customers before RFP release. Build a list of questions such as those above and seek out the answers. When the RFP is released, you can look for ways to demonstrate your insight and stand out from the pack.

The customer. There is no universal standard for layout or composition of proposals. If you think about it, it makes sense. A “proposal” is intended to persuade someone. What is required to do that is up to the person being persuaded. If you want your proposal to succeed, you must know your customer. If your customer wants: If your customer wants details, give it to them. If they don’t want to do a lot of reading, give them a short proposal. If your customer wants references, give it to them. Otherwise, don’t. If your customer wants pricing, give it to them. If they’re not ready for pricing, don’t give it to them. If your customer wants contractual details, give it to them. If they’re not ready to discuss contractual details, don’t force them. If your customer wants to know who will be doing the work, tell them. If they don’t care, don’t tell them. If your customer wants things presented chronologically, organize your proposal that way. If your customer wants information organized functionally, organize your proposal that way. If you don’t know the answers, find them out. If the customer doesn’t know what they want or need, give them criteria to help them figure it out. Never load the customer up with a bunch of paper just because they might want something. Give them what they want. No more, no less.

If you are a consultant, your product is often the services that you will perform yourself. Sooner or later you will need to give your customer a proposal, either because they ask for it, or because it can help you persuade them to approve the project. To approve the use of a consultant, many companies will need a written statement of work and other information. Putting it in their hands can expedite the process. If you are not a consultant, you may still need to prepare a proposal from time-to-time to expedite a decision or persuade someone to take action on your behalf. Your goal will define the content of your proposal. People sometimes write proposals to persuade the reader to take an action, make a selection, reach a decision, spend money, offer a job, or grant a raise. Large, formal proposals are often prepared in response to a written Request for Proposals (RFP). One person proposals often do not have a written proposal to provide guidance. You must anticipate the information that will be required by the reader to take the action you desire and then design a document that will achieve your goal. Your proposal should be more than your resume and a work plan. As an individual, your proposal will be partly an introduction, partly a statement of qualifications, partly a work plan, partly pricing, and partly an articulation of the reasons why the client should approve your recommendations. Your resume only addresses your qualifications, and even these a resume tends to address only in a generic way. You should customize your resume every time you use it to emphasize the qualifications that are most relevant to the person you are trying to persuade. For example, are you a network technician, an administrator, an engineer, or a project manager? Many networking consultants could play all of these roles. But which is more important to this project and this client -- your education, your experience, you certifications, or your capabilities? You should customize your resume to make the relevance clear, to prove that you have the qualifications required to do what you propose, and to support you rationale for why the client should accept your recommendations. In addition to your resume, you have some explaining to do: What will you accomplish for the client? How long will it take? What resources will be required? How will they benefit from the project? How much will it cost? Who are you to be making these recommendations? Why do they need you? Why should they have confidence in your ability to do the work correctly? Why should they accept your recommendations? Here are some additional topics for more complex proposals: Staffing Management and Oversight Allocation of effort Orientation and Phase-In Deliverables Metrics, measurements, and performance standards Quality assurance Communications In order to answer these questions, your proposal should start with an introduction to what you plan to accomplish and how they will benefit (start by explaining what's in it for them). Then provide your work plan, including methodologies, resources, and schedule. You might also provide your resume to support your ability to deliver as promised. Once you've laid this foundation, provide your pricing and rationale, emphasizing the return on investment and value. Depending on the complexity of your work plan, this can usually be accomplished in a couple of pages. You can use any format that will fulfill the client's expectations. Your proposal could be in the form of a letter, memo, report, document, email, or contract. When to require a contract is a matter of personal and legal judgment. When you do, I recommend that you include it as an attachment to your proposal. Contracts tend to be perceived skeptically, so you want the message delivered by the proposal, with your goal being to persuade them to sign the contract. Whether your goal is the signing of a contract or something else, and whether your proposal is delivered in the form of a one page memo or a three-inch binder, the entire proposal should revolve around persuading them to take the action you desire. You must be clear about your goal and turn that into a clear call to action in writing. Because you will probably be producing your own proposal, you should make sure that you design the layout of the document around your own capabilities to produce it. In other words, don't get too fancy. Go for simple elegance instead of complicated sophistication. Just make sure that it fulfills the reader's expectations. This is harder to do when you don't have a written RFP. If you don't know their expectations, make an effort to discuss their expectations and issues such as: Do they want something formal or informal? Does it have to meet the requirements of the purchasing department? Do they need a strong financial justification? Have they already decided and just need something to facilitate completing the paper work? Are there any forms that must be included or formats to follow? Will they follow a formal evaluation process? Remember, your proposal is only a part of how you achieve your goal. If you are a consultant, remember that what they are buying is you — not the proposal. You will need to practice your salesmanship. This is especially true if there is no formal evaluation process. There is a school of thought that says that you shouldn't submit the proposal until you know what the decision will be. If you can't achieve this, then make sure that you have a personal follow-up plan for after the proposal is submitted. The follow-up can be crucial for supplying additional information and validating what you put on paper. You don't have to be pushy to follow-up, just be helpful, and remind them that you can be even more helpful if they accept the proposal.

Layout and design If there is no written RFP, or if the written RFP does not specify outline or format, then there are no rules for the layout and design of your proposal. The only standard to apply to the proposal’s appearance is whether it fulfills the proposal evaluator’s expectations. If they haven’t told you what they are or written them into an RFP, then all you can do is make your proposal legible. Your proposal layout should be highly readable and make it easy to locate information. You should make extensive use of graphics, because they enhance the readability of the document and convey information well. In the absence of instructions to the contrary, your headings, typefaces, margins, headers/footers, and other formatting attributes can be anything that you want that achieves the goal of your proposal. So that you don’t have to study typography, we recommend: A serif typeface such as Times Roman 10-12 point type A column width of 50-60 characters (either double column or “scholar’s margins”) Page margins of at least .5” The use of color whenever possible Extensive use of graphics Full use of front matter (Table of Contents, List of Figures, etc.) “Navigation aids” such as a cross-reference matrix Appendices for data that must be provided, but disrupts your proposal’s story If the page count is large enough, use 3-ring binders or other binding Use tabs that break the content down into sections and make finding material easier Final production Final formatting and polish is often reserved for the end of a proposal effort. Indeed, in some environments they wait until all edits to the content have finished before they apply final formatting and perform reproduction. On a large proposal they may allow several days to a week just for final production. Some organizations use sophisticated desktop publishing and artwork, others use MS-Word for their final output. The value of a better-looking proposal must be weighed against the level of effort it takes to achieve it. We recommend that you format your proposal in a layout that you are comfortable with. Keep it simple, and don't overextend yourself by using an advanced layout that you have difficulty producing. Tips for Proposal Formatting Basic proposal formatting is easy, just keep it simple and elegant. But with a little more effort, you can use your proposal formatting to help you win. Here are some tips for proposal formatting.

If you are like me, you learned the basic five-paragraph essay format (and a bunch of variations) in school. You remember: introduction paragraph, three supporting paragraphs, and conclusion paragraph. Most variations follow the same concept: introduce, support, conclude. Then within each paragraph, you do the same thing at the sentence level. If you are writing a proposal, this is completely backwards. Consider: People read proposals to make a decision — the first thing on their mind is why they should accept what you are proposing. Customers read proposals to find out what they are going to get — tell them what they are going to get or what the result will be so they will want to read about how you will make that happen. The goal of a proposal is to persuade — you need to communicate what you want the reader to conclude and then substantiate it. Nobody wants to read a proposal — if the evaluator quickly sees what you want them to conclude, they may not need to read the details that follow. A winning proposal is easy to evaluate. Picture the evaluator with a checklist in hand going through your proposal — check, check, check. State conclusions that reflect the evaluation criteria, and then substantiate with how or why. Never save the best for last, or build to the finish. Give the reader what they want right up front in firm, positive statements. Don't ease into it by writing around it. If you ever have the opportunity to be the customer reading a proposal, you'll see how annoying it is when you have to dig into the proposal and read deep to find out what the point is. You still need to provide the explanation and proof for due diligence, but if there is anything about your approach that you really want them to know, anything about it that is special, you should call it out first. Tell them what the approach will do for them, what the benefit of it is, and only then tell them what the approach is. The goal is not to deprive them of necessary detail, but to give them what they want, in the order they want it. You have to give them a reason to bother reading the detail. Think about why they are reading — they are evaluating what you are proposing in order to do two things: get through the formal evaluation process (completion of scoring forms) and to make a selection. Unfortunately the former is often the primary reason. In any event, what they are looking for is how to score you and why to select you. If they find those, then they’ll examine what you are proposing to make sure you can deliver. It is always a good idea, in any type of writing, to imagine what it’s like to be the reader.

Here is a simple approach to help you cover all the bases when writing a proposal. You can use it like a formula. For each section or requirement that you must address in the RFP, make sure you answer: who, what, where, how, when, and why. Repeat it like a mantra, until it rolls off your tongue and you have it memorized. Then use it to anticipate and answer all of your customer's questions when writing a proposal. After you have written your proposal, you can use the same formula to review it and help ensure you have addressed everything you should have addressed. In each section of your proposal, simply ask yourself if it answers "who, what, where, how, when, and why?" Who: who will do the work, who will manage the work, who does the customer call if there is a problem, who is responsible for what What: what needs to be done/delivered, what will be required to do it, what can the customer expect, what it will cost Where: where will the work be done, where will it be delivered How: how will be work be done, how will it be deployed, how will it be managed, how will you achieve quality assurance and customer satisfaction, how will risks be mitigated, how long will it take, how will the work benefit the customer When: when will you start, when will key milestones be scheduled, when will the project be complete, when is payment due Why: why have you chosen the approaches and alternatives you have selected, why the customer should select you This simple little phrase (who, what, where, how, when, and why) can help you not only ensure that your proposal says everything it should, but that it answers the customer's questions better than your competitors. You can even use it to exceed the customer's minimum requirements by addressing the questions they forgot to ask. When you read a simple proposal response written to address the customer's requirements, and compare it to one that answers "who, what, where, how, when, and why?" you'll see a dramatic difference in the quality of the proposal. Simply doing a better job of answering your customer's questions can give you a competitive edge when everything else between them is equal. In addition to using it for inspiration when writing, you can also use it like a checklist for reviewing a draft proposal. When you read a draft proposal, consider these questions and pretend to be the customer. Go over the questions and see if the proposal provides all of the answers you would want if you were the customer. All you have to remember is "who, what, where, how, when, and why." And you thought proposal writing was supposed to be hard! When you have this formula memorized and mastered, then you'll be ready to take on more advanced proposal writing techniques.

During the days when I had time to personally write proposals, I was often elected to prepare the management plan. During the past 20 years, I have probably written at least 150. I will never forget the first management plans I wrote. I was a Vice President at Computer Dynamics, a progressive small business in Virginia Beach. The year was 1983; and this was my first experience writing a management plan. If I had had an MBA degree, the work would have been fairly straightforward. However, my degrees were in English, History, and Education, so there was a learning requirement. In order to get over the learning curve and prepare responsive management plans, I found several tools or aids available that would help. First, there were some basic management plans in past proposals. Although these materials were brief and not very strong, they did offer a starting point that could be expanded as time passed. Second, there were employees sitting just down the hall who had a wealth of knowledge on management techniques and who could be consulted. Third, I found that the bookstores had dozens of good college and professional management books, and some of these texts had useful materials. Fourth, we frequently teamed with other companies in bidding, and it was nearly always possible to pick up useful management proposal paragraphs from the teaming partners as time passed. The problem with the approach mentioned above -- teaching yourself on the job -- is that it is slow. It took more than 5 years of experience before writing a management plan became second nature. If your company does not have good management plan materials that address your different products and services, it is probably worth investing in a little consultant time -- to bring in someone who can prepare management plans appropriate to your needs. Depending on the complexity of the requirements, most companies can have significant management plan "boilerplate" prepared based on an investment of between two weeks and two months of time. The consultant could also train your personnel in preparing management plans. A starting point in preparing any management plan is to define the higher-level categories that will be addressed. The requirements of the RFP usually spell out some of the categories. For example, nearly all solicitations require you to describe your proposed program organization and your subcontracting plan. Content of the management plan will vary widely depending on the company, the program, and the circumstances. However, a majority of management plans have in common certain sections. The management plan categories that usually need to be addressed in a proposal include the following: Program Organization - includes an organization chart showing reporting relationships and describes how the proposed program organization functions. Program Management - describes how the overall program is directed by the program management group. Project Management - describes the techniques used to plan, schedule, track, and direct project activities that may take place within the program. Problem management / escalation - provides a concrete means for identifying and handling problems in a reliable, repeatable, and timely manner. Personnel management - contains a description of how personnel-related affairs such as recruiting, retention, time keeping, and benefits are handled. Financial management - describes what financial systems, processes, and safeguards are used to ensure the reliable management of program finances. Quality management - provides a systematic QA/QC approach capable of ensuring that products and services consistently meet quality goals. Risk management - demonstrates a clear understanding of program risks and provides a description of the plans and capabilities you have developed to ensure that risks are held to an acceptable level. Schedule management - provides an overview of the systems and processes your company utilizes to ensure that the program team consistently maintains schedule. Executive management - describes what methods you propose to use for the executive leadership to provide oversight and control over the program to ensure the program team successfully meets challenges and delivers quality performance. Interface between customer and contractor at all levels - typically using a vertical organizational chart of both the contractor and the customer side by side, the bidder draws lines on the chart and describes how he proposes to interface his organization to the customer organization at various levels including the executive, program, project, financial, contractual, and other levels. Contract management - describes the processes, procedures, and systems that you propose to use to ensure that the program team delivers services / products consistently in accordance with both the letter and spirit of the contract. Subcontract management - describes the processes, procedures, systems, and contractual terms you propose to use to ensure that subcontractors are managed in a way that supports program goals and requirements. There is no magic answer to the problem of writing a fine management plan. The basic requirement is to have a word processor and several years of experience. Although the techniques used in a management approach can vary widely, the desired end result is the same - to present a plan the customer can easily see is reliable and sound. It will strengthen your case if you can give concrete examples showing how you have successfully managed similar programs in the past. Assuming your marketers have done their customer research well, you will know what areas of management need the greatest emphasis. If the customer has had recent problems with schedule, for example, then he will expect to see a strong schedule management approach. Likewise, knowledge of the customer situation will help you write highly responsive approaches to the other management areas.

Architecture What are the specifications for the system architecture? What are the specifications for the network architecture? What are the specifications for the hardware architecture? What are the specifications for the software architecture? What is the information model? What are the specifications for the database architecture? What are the benefits to the customer of your architectures? How do you architectural plans account for future needs? What standards do your architectural plans comply with? Supply Chain What kind of relationships do you have with your suppliers? How will you manage your supply chain? What will you keep in inventory? How will you stock it? Where will you warehouse the inventory? Support How will you provide support? What capacity will it have? How will you track issues? What is your response time for problems? How will you manage issue escalation? Will you provide a call center? Will you provide a self-service facility? What support will you provide on-site? What support will you provide off-site? How will you determine whether to fix or replace a defective component? Knowledge Management and Data Warehousing What data will be collected for knowledge management and data warehousing? How will data be collected? What formats will data be collected and stored in? Will data/records conversion be required? What types of analysis will be performed? How will you identify best practice documents? How will you disseminate best practice knowledge? What is your plan for records management? How will records be defined, identified, or received? How will records be disposed of after they are digitized? What is your archival plan for digital records? What is your disposition plan for digital records? Who is responsible for knowledge/records management? How will the customer benefit from your knowledge management/data warehousing approach? How will your approach enable you to better leverage lessons learned? How will your knowledge management approach promote organizational learning and understanding? How will your knowledge management approach lower training costs? How will your knowledge management approach provide access to newer and better information? How will your knowledge management approach contribute to faster/better decision making? Tools How will the customer benefit from the tools that you will use? What tools will you use for development? What tools will you use for computer aided design? What tools will you use for workflow? What tools will you use for configuration management? What tools will you use for process automation/management? What tools will you use for program management? What tools will you use for collaboration? What tools will you use for budgeting? What tools will you use for record keeping/Time keeping? What tools will you use for tracking systems What tools will you use for customer relationship management? What tools will you use for document/knowledge management? Techniques What formal methodologies will you employ? What documented processes/procedures will you follow? Will you perform any process re-engineering? Will you perform any reverse engineering? Will you use any design aids/techniques such as Unified Modeling Language (UML)? Will you use any documentation aids/techniques such as psuedo-code? Will you use any job aids? How will you maintain process documentation? How will you maintain configuration management? Standards and Certifications Are you ISO 9000 certified? Are you certified at any Capability Maturity Model (CMM) levels? Does your company have any other certifications to cite? Does the staff being bid have any relevant certifications to cite? Will you use any specific Application Program Interfaces? What published standards will you comply with? Does the customer have any documented standards or procedures to comply with? Safety What safety precautions may be required on this project? What is the process for reporting an accident? How will you recognize safety hazards and respond? Will you provide safety training? What safety records will you keep? How will be responsible for ensuring safety? How will the customer benefit from your approach to managing safety issues? Capacity issues What types of capacities are important to this project? How did you arrive at the projected capacities? How do you measure capacity requirements? How will you model performance metrics? How will you forecast workload requirements? What is your plan for handling the projected capacities? What is your plan for handling peak and valley work load requirements? How will you achieve the necessary scalability? How will you anticipate and accommodate for changes in capacities? Deliverables What deliverables will you produce? (provide a table) What is the benefit to the customer for each deliverable? Is the scope of each deliverable sufficiently defined? Are the completion points for each deliverable clear? Can you provide samples of deliverables? Does the format of the deliverables fit their intended purposes? How will you manage the production of deliverables? Are there any specific requirements that deliverables must comply with? What media should be used for deliverables? Are there any compatibility requirements for data deliverables? What standards will be used to evaluate the quality of deliverables? What is the review/acceptance process for each deliverable? How will you maintain deliverables after initial production?

How often have we all heard that statement? However, especially in customer service, it is very true. I see evidence of this everyday. How do you feel when you arrive at the bank drive-up window to see signs posted that read, "Commercial Accounts ONLY. Do NOT use this lane for personal banking"? It sounds rather obnoxious, doesn't it? This cliché also holds true for our speech. Just the other day I was told, "We can't cancel that until write a letter". The tone of voice and verbiage the person chose gave a large indication that I was at fault. And of all things... web sites are at fault, too. I could hardly believe my eyes. I visited a site that was encouraging me to list my Ezine to gain some publicity. I decided I would list and clicked the "continue" button. To my surprise (and dismay) the headline on the following page read, "D___IT PEOPLE! READ THE DIRECTIONS BEFORE YOU ENTER YOUR INFORMATION!" How awful! Needless-to-say, I clicked away from that site. One of the core principles of customer service tells us to give a positive before giving a negative. Let's take a look at how we can rephrase the above negatives to make them more pleasing for our customers. The sign at the bank drive-thru could be easily reworded to state, "Commercial Account Holders - This Lane is Reserved for You. Personal Account Holders May Choose From These Lanes". Sounds much nicer when you state it in a positive manner, doesn't it? And what about the woman that told me she couldn't cancel until I wrote a letter. That phrase would have been better received if it was stated, "We'll cancel that just as soon as we receive written authorization". Lastly, the web site with an attitude... that could certainly be improved upon. Evidentially, this web site owner was having trouble getting his instructions across to those entering their ezines. Frustration is understandable, but not excusable. Perhaps his headline could read, "Following Listing Instructions Guarantees Your Ezine Placement in Our Directory". That would have made a much more favorable impression on me. It would have also insured that I read the instructions. Throughout the course of your day, pay attention to the way your wording comes across in writing or verbally. Make a point to practice putting statements in the best possible light. Portraying a positive instead of a negative will help insure your customers stay satisfied.

How do you guarantee that your ads, sales letters, web copy and other marketing materials as hard-hitting as possible? You've heard that when writing promotional copy, you should promote benefits rather than features. Benefits show the genuine value of your products to your customers. They go beyond the specs of your product to tell customers about all they will lose if they don't buy from you now. How do you distinguish between features and benefits? And once you do, how do you communicate those benefits? 1. Write down features and benefits before you start. People don't buy products -- they buy what products do for them. Before you begin, make two columns for a list: One for features (your point of view) and another for benefits (from your customers' points of view). Are they buying telephone service, or connection with their loved ones? Are they buying a portable heater, or in- home comfort and protection from the elements? Are they buying college courses, or the lucrative career that will ensure their financial security? 2. Write the way you speak. Use your company's voice and personality in your copy. Make it sound like a written conversation between your company's personality and your customer. Every company will have its own style and tone, depending on what the you sell. 3. Write in second person point of view. Remember to write that conversation as if it were you and one customer speaking. Be sure to use "you" and "me" a lot - companies don't sell products, people do. Here are a few examples to keep you on track: "You will feel ... " "You'll learn hat ..." "...brings you ... " "As you know,... " 4. Provide a call to action. No, you're not ordering customers around when you tell them what to do -- but without spelling out specific actions to take, you'll risk losing their response. Tell them exactly what you want them to do, and be specific. If you don't ask for the sale, you may not get it. For example: "Please fill out the form and mail it to ..." "Enter by December 13 for your chance to win ..." "Call toll-free today 1-800-..." "Click the blue box to read more ..." Follow these tips when communicating features and benefits and be sure your customers are hearing the message you want them to hear. That way, they will also respond to your call to action the way you want them to, and you make the sale!