The initial part of this chapter serves as a foundation for building a proposal checklist. We leave the details of the checklist to you. To guide the development of a proposal checklist we present four “rules of proposals.” These rules, in our opinion, should guide in a general way all of your actions with regard to proposals. Everything else is an elaboration and refinement of these rules.
The final part of this chapter discusses critiquing your proposal. A well organized critique can be the difference between winning and losing a competition.
Here are the four rules we recommend.
- Rule 1. The physical proposal must comply with all customer instructions. This seems obvious, but sometimes pursuit teams overlook the obvious in their haste to meet the proposal deadline. This rule is often of critical importance because failure to comply may result in all or parts of your proposal being thrown out. To be sure that this rule is observed, the pursuit team should carefully search the customer’s written request for proposal and other customer information and locate all direct or implied instructions that have to do either with the nature of the proposal or the proposal submittal. These should be organized into a database or checklist. Someone reliable on the pursuit team should be designated to monitor the proposal cycle to be sure that all instructions are scrupulously observed. Here are some frequently encountered customer instructions relating to proposals. This list is not comprehensive.
- Overall organization. A typical instruction is to provide separate sections or volumes for management, technical, and cost.
- Size of paper and fonts. The size of paper might be specified, e.g. 8-1/2” x 11”. A particular font (such as Arial 10 point) might be prescribed.
- Allowed maximum page counts. Customers often feel they need to restrict the number of pages in certain areas of the proposal. They do this to avoid being overwhelmed with the effort required to read and digest the proposal in the time available. There may also be limitations on the number of foldout pages, the number of volumes, and other features. Do not exceed any such limits imposed by your customer.
- Graphics and publishing expense. Many customers sincerely want bidders to avoid expensive features such as four-color art, leather binders, etc. If your customer says keep it simple, then keep it simple.
- Distribution. Commonly the customer will specify the number of proposal copies it needs and where they should be sent. Be sure that everyone on the list gets the right number of copies. The customer may declare a different distribution for some of the proposal sections or volumes. Be sure to honor this.
- Method of transmission. The customer often will specify how the proposal will be transmitted. Today a common practice is to require transmission electronically, perhaps even by secure by e-mail. If you send a proposal by e-mail, be sure to confirm that it was received.
- Due date and time. Generally the customer will specify the latest date and time it will receive the proposal. In most proposal situations, failure to deliver by the specified date and time will result in your proposal being thrown out.
- Specific data. The customer may specify particular data from tests or from other sources that it wants. Review such data requests carefully. If the data are proprietary or confidential, be sure the proper safeguards are in place. If you think the customer is asking for the wrong data, ask for clarification.
- Specific commitments. The customer may require specific commitments, such as using small businesses for some fraction of the work, completion of parts of the work by a certain date, etc. If you can fulfill the commitment in your proposal be sure to do so. If not, be sure to explain how you will fulfill it once under contract.
- Rule 2. The physical proposal must clearly show how it complies with all customer instructions. Of course, the customer will want you to comply with all of his instructions for the proposal. And if you are at all clever, you will. In a four page proposal full compliance may be self-evident. But in a 1,000 page proposal, or even in a 20 page proposal, the customer may find it difficult to locate all of the things he asked for. To avoid making difficulties for your customer, you must add a useful feature to every proposal that the customer may not have asked for. Some call it a “compliance matrix.” Others call it a “proposal directory.”
What is it? It’s a page, or a few pages as necessary, where everything the customer asked for is listed in some coherent manner, and adjacent to those listings appears its location in the proposal, by volume number and page number. If there is an appropriate exhibit, table or figure number that should also be noted. The compliance matrix should appear at the beginning of every proposal volume. In an electronically delivered proposal, it may be possible to arrange things so that the customer can bring the proposal up on his computer, click with his mouse on the item wanted and immediately be taken electronically to the material sought. That kind of thoughtfulness will be appreciated.
- Rule 3. The proposal must explain how you will meet each and every project goal. Compliance with the project goals is distinct from compliance with rules regarding the physical proposal. Goals are of two types: positive and negative. As elsewhere explained in this book, a positive goal is something the customer wants the project to accomplish. It could be to create something new, modify something old, or some combination of these. A negative goal is a constraint. It is something the customer is not willing to give up in order to achieve his positive goals. Commonly it is a limitation on cost or duration, but many other types of constraint are possible.
A widespread failing of proposals is that they say they will meet all of the goals, but they don’t say how. Believe it or not, your author has seen the following type of unintelligent response in proposals. You may have, too. The phenomenon is not rare.
Customer goal: “The aircraft shall be able to reach 40,000 feet altitude.”
Proposal response: “The aircraft will be able to reach 40,000 feet altitude.”
Imagine that you are the customer reading the above. Later, you pick up a competitor’s proposal that has a two page analysis citing wind tunnel test results, aerodynamic analyses, and other data proving beyond a reasonable doubt that the aircraft will be able to reach 40,000 feet altitude. Which proposal would you find more credible?
Of course, not every goal is deserving of a multi-page proof. The more important the goal, the more necessary it is to provide a thorough, convincing response. This of course argues for a good understanding of how the customer values his various goals. See chapter 4 for further discussion. A minor goal, such as painting a surface a certain shade of white with a paint meeting a certain specification might simply be acknowledged.
It can be just as important to be convincing about being able to meet negative goals as about positive ones. If the customer has a constraint on completion date that is important to him, it is worthwhile for you to provide a detailed schedule risk analysis that shows a reasonable margin of safety for the critical path.
Your price can be an especially touchy item from a credibility standpoint. If you know the customer’s upper limit, you certainly want to be below it. If you don’t know it, you should try to make a best guess as to what the customer will view as reasonable, and stay below it. The same goes for observing his lower limit. See also chapter 8.
If you know or believe that the customer has a certain way of estimating what he thinks the cost should be, you are wise if you try to estimate it the same way, to be sure you get a result you think the customer will find realistic. For example, if it is known that the customer is partial to a certain commercial parametric estimating model, it would be wise to use that model to create a project estimate.
The best way to be credible about cost goals is to write good bases of estimate (BOEs). See Appendix B for added discussion of this important subject.
You need to pay special attention to areas you think your customer will perceive as risky. If the customer has reason to believe that you are bidding on a high risk basis, he or she may go so far as to arbitrarily adjust your bid upward to account for the risks as they are perceived. This can destroy your chances of winning.
- Rule 4. The proposal must counter known or likely competitive threats. Whatever other meritorious qualities your proposal may have, if you ignore what the competition is likely to say in its proposals, you might well lose. Clever competitors will try to find your weak points and your strong points. To the extent that they can, they will try to exploit your weaknesses and direct attention away from your strengths. If you do nothing to counter this, if you leave their likely claims unanswered, your customer could become their customer.
The process of defending against competitor claims is sometimes called “ghosting” their proposals. Ghosting arises from a situation where you believe a competitor will advocate a certain approach, and you believe the customer, when fully informed, will like yours better. Without naming the competitor, you insert a “trade study” result that shows you considered the approach you believe the competitor will use, then you demolish it point by point, showing how the approach you took is better.
If you can’t demolish a competitor’s claim, you should show that your approach has at least equal merit. If your approach is weaker, you should first ask yourself why you are doing what you are doing. If it’s unavoidable, you need to stay silent and mark the matter down as something to try to fix if you want to propose in this area of technology again.
Critiquing the proposal. Many wonderful things can be done electronically nowadays. A proposal can be stored on a server and accessed by all members of the pursuit team. Comments can be added and identified as to author. That process can be used to eliminate typos and other mistakes, and to make needed improvements. But perhaps because we are old-fashioned we believe that with all the wonderful things that can be done with the computer there is still no substitute for a wall review. A wall review permits face to face conversation between reviewers, and that can be a valuable thing.
In a wall review, every page of the proposal is pinned or pasted on a wall at a height convenient for reading. Members of the team can walk along the wall and read it and mark it up. Important: every markup must bear the initials of the reviewer.
Unfortunately, a wall review can sometimes degenerate into confusion. Here’s how this can happen. A reviewer perceives that a mistake was made and marks the proposal to indicate a needed change. The “proposal coordinator” thinks the change is valid and makes it, putting the new text up on the wall. A second reviewer sees the new text and has a different opinion about what is the right way, and again marks for a change, perhaps back to the original text.
Sometimes this kind of thing will happen in the best organized of pursuit teams, but there is a way to minimize it. The first step is to recognize that in certain areas of the proposal there may be differences of opinion as to how things should be done. But clearly these differences must be resolved before the proposal is submitted. The pursuit manager must decide which approach is best and promulgate that approach as the proposal baseline. By the time the proposal goes up on the wall, no member of the team should have any doubt as to what the baseline is, especially in areas likely to be controversial.
A good thing for the pursuit manager to do is to post the baseline assumptions and ground rules on the proposal wall and make them required reading for all reviewers. Any reviewer who disagrees with any of them should be made to feel free to write his comments, but not to change the baseline.
Thorough reviews by the pursuit team are good, but they have the built-in disadvantage that the pursuit team members are intimately close to the problem and may suffer from “can’t see the forest for the trees” effect. Because of this, it is wise to have the proposal reviewed by others who may have a useful perspective. “Others” should include members of senior management, trusted independent experts in areas of difficult or unique technology, and people who know the customer or the competitors well.
Chapter 15 Review Questions
- In your last proposal, did your team designate someone to be sure that the physical proposal met all customer requirements? If not, why?
- Have you ever been on a team whose proposal was thrown out or almost got thrown out because of failure to meet customer requirements? If so, what happened? What actions would have kept this from happening?
- In your most recent proposal did your team provide a compliance matrix, proposal directory, or equivalent? If not, why not?
- In the rush to get a proposal “out the door,” there is frequently a lot of rewrite, new graphics, and other disturbances of the previously established order. This can make it difficult to maintain the compliance matrix. Has your team ever dealt with this problem? Did you find a satisfactory solution?
- A common problem with proposals is that the management volume will crow loudly about how skilled and experienced the team is with the subject at hand, but when it comes to writing bases of estimate, the usual response is “Engineering judgment.” This leaves the customer wondering why, with all that experience, you have no better basis of estimate than engineering judgment. If you had this problem, how would you try to correct it?