Chapter 15—Get all of the right things into your proposal
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.
Proposal rules
Here are the four rules we recommend.
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.
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.
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
1. In your last proposal, did your team designate someone to be sure that the physical proposal met all customer requirements? If not, why?
2. 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?
3. In your most recent proposal did your team provide a compliance matrix, proposal directory, or equivalent? If not, why not?
4. 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?
5. 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?