Category : Databases and related files
Archive   : PROPOSAL.ZIP
Filename : SEM.I

Output of file : SEM.I contained in archive : PROPOSAL.ZIP


Proposals that say. "Me too," do not often win
contracts. The winning proposal is usually one
that says, "Here's why you need me."


A proposal is a sales presentation, and it is
essential that you recognize that as a first prem-
ise upon which to base all your ideas about pro-
posal writing. Proposals do not win contracts by
luck; they win by determined and intelligent ef-
fort, and by successful--which means persuasive--
sales strategies.


The essence of proposalmanship, the name assigned
to those proposal-writing methods and philosophies
advocated in these pages, is strategy. Most of
your competitors will deliver proposals which
demonstrate that they can do the job. But the mere
ability to do the job is not justification for the
award and will not win the contract; you must
somehow demonstrate that you can do the job in a
superior manner or otherwise give the customer one
or more compelling reasons to select you as the
winning proposer. Here are a few of the general
categories into which those "compelling reasons"
might fall:

* Costs
* Program design
* Qualifications of staff
* Qualifications of organization
* Special inducements/considerations

Of course, that is not all there is to proposal-
manship, nor to the development of effective
strategies. In fact, those several categories
suggest only the seeds of possible strategies,
mere door-openers. For example, it isn't of much
use to labor long hours designing the lowest-cost NOTES
program if low costs are not a major concern of
the customer. Nor to design an imaginative and
innovative program if the statement of work has
specified the desired program and mandated strict
conformance with overly detailed specifications.
That is to say, a compelling reason is a reason
the customer finds compelling, for it is only the
customer's perceptions that are of value in formu-
lating strategies. Ergo, an critically important
early step is finding out what is important to the
customer (rather than to you). And that comes out
of analysis, to identify what is--or can be made
to be--most important in the customer's perception
of reality. This is the first objective in the
quest for a successful strategy.


The strategy referred to here has been one that
some refer to as "sales strategy," also referred
to by others as "proposal strategy." However,
because there are other possible strategies com-
monly employed in writing effective proposals, it
is more useful here to distinguish the strategy
referred to here as capture strategy, or that main
strategy which is expected to be the kingpin of
the proposal effort--the main reason given the
customer as the inducement to select the proposal
as the winner.

That capture strategy may be any or some combina-
tion of several possible subordinate strategies--
technical or program strategy (the strategy of the
proposed program), cost strategy (appearing to be
the right cost and, in some cases, appearing to be
the lowest bidder), presentation strategy (organ-
izing the proposal itself for greatest impact),
and competitive strategy (coping successfully with
competitors' proposals).

These, too, the strategic approaches and ideas,
are integral parts of that technique we call "pro-


Salesmanship is an act of persuasion--in fact, the
art of persuasion--and we write proposals with the
intent of winning contracts, with the intent, that
is, of persuading others to select us for award.
The successful proposal, therefore, is one that
persuades successfully.

Persuasion is an art, but it has its own rules and NOTES
principles, and these are very much a part of
proposalmanship. In fact, it is fair to say that
proposalmanship is the art of written salesman-

None of this is to say that salesmanship is the
art of deceit, despite the fact that sales organ-
izations sometimes bend the truth rather badly,
nor to suggest for a moment that a proposal should
bend the truth even slightly. (Quite the contrary,
that may itself destroy the effectiveness of the
proposal.) But it is to say that to write an
effective proposal you must keep your eye on the
ball and remember that your main objective is to
convince the customer that your proposal is the
best offer of all of them, from all viewpoints,
and should therefore win the contract. The art of
persuasion has many facets, not the least of which
is the art of writing persuasively, and this, too,
is an important element in proposalmanship.


The proposals you write are almost always competi-
tive: others are also trying to win the contracts,
and they are trying to write better proposals than
you write. There are certain factors to remember,
in connection with this, not the least of which is
to be careful that you neither underestimate nor
overestimate competitors.


The essence of proposalmanship is strategy. Ev-
erything else, and there are many other considera-
tions, is in pursuit of devising and implementing
successful strategies.


The government is "them," not "it"; when you
sell to the government, you sell to people.


Nominally, proposals are requested when the gov-
ernment wants to procure something on a custom
basis, as contrasted with buying an "off the
shelf" (proprietary) service or product. Because
the procurement is on a custom basis, it is neces-
sary to judge somehow which of the many possible
suppliers is best qualified, has the best ap-
proach, and is the most dependable vendor. Theo-
retically, then, the RFP says, "Here is our prob-
lem [or need], with everything we know and can
tell you about it. Give us the benefit of your
knowledge and your ideas about how best to solve
this problem [satisfy this need]. Explain your
proposed solution, program, ideas, and qualifica-
tions to us. And then be sure to explain why we
should award the contract to you." (Sell us, that

Note that there are in general two kinds of situa-
tions or requirements underlying the issuance of
an RFP:

1: The customer has a problem to be solved,
which can be described by the customer only in
terms of symptoms, requiring "outside" help be-
cause the customer lacks the necessary skills,
facilities, or staff in-house.

2: The customer has no problem, in the sense
of requiring help to diagnose symptoms and devise
a solution, but does have a perceived need for
specific outside services which the customer can
easily define.


Knowing what ought to be in an RFP and SOW is
helpful in understanding the whole proposal proc-
ess because it helps you understand the gov-
ernment's overall intent in issuing RFPs, despite
the fact that so many agencies execute and imple-
ment the concept rather badly.

In concept, the statement of work explaining the
problem or need is supposed to provide enough
information to enable the proposer to understand
the problem/need and to conceptualize and plan an
effective and responsive program. But it is not to
be so detailed as to stifle the proposer's freedom
to be flexible and imaginative in response to the

Unfortunately, few RFPs and SOWs achieve that
happy medium between rigidly structured mandates
and uninformative, vague generalities. Instead, we
are often confronted with RFPs that go to one
extreme or the other, either making it quite dif-
ficult to make innovative and imaginative res-
ponses or leaving us highly perplexed as to what
the customer really needs or wants. Still, knowing
as we do that the customer has a problem to solve
and/or a need to satisfy, we must therefore fill
in the gaps for ourselves.

On the other hand, sometimes it becomes apparent
that the customer does not understand the problem,
perhaps cannot even distinguish between the prob-
lem and the symptoms, in fact. Or, as is also
sometimes the case, the customer has a conviction,
but a mistaken one of what the problem is.

We may therefore be confronted with any of these
problems, in addressing the proposal need, and it
is necessary that we have a realistic fix on what
our own chief worry item is, as far as an under-
standing of the requirement is concerned.


Frequently, the text of the RFP (request for pro-
posals) and, especially, the statement of work,
provide clear indications or at least distinct
clues as to the customer's chief "worry item"--
what is of greatest concern. It may be money:
perhaps the customer's budget is rather tight,
leading to concern over whether the job can be
done for the money available. It may be time:
perhaps the customer is deeply concerned over
whether the job can be done in accordance with the
necessary schedule. It may be state-of-the-art or
technical problems, leading to concern over wheth-
er the job can be done at all or, at least, under-
taken with some reasonable assurance of satisfact-
ory results. Or there may be one or more of many
other possible items over which the customer is
losing sleep.

Discovering that chief worry item or those chief
worry items--there may easily be several--is the
key to successful strategy. That makes it an im-
portant function in the proposal process. Unfortu-
nately, however, the RFP and its SOW (statement
of work) are not always sufficiently informative,
either because the customer deliberately withholds
certain information or because the SOW is not
particularly well written--a not unusual circum-
stance, as all experienced proposal writers are
well aware. And, still, despite those problems,
the key to developing successful strategies and
winning contracts lies in the ability to ferret
out the customer's true problem or need and the
worry items (or make the customer painfully aware
of legitimate items about which he/she should be
worried). It is that problem, above all else, that
makes successful proposal writing a creative


The RFP and SOW were written by fallible humans;
that's why the documents are less than perfect.
Other humans--or perhaps even the same ones--will
read your proposal and pass judgment on it. They
are persuaded or dissuaded by the same emotions
and drives that persuade or dissuade them in
making their personal buying decisions. We need
to sell to them as buyers for the government or
for their organizations just as we sell to them in
their personal buying.


The first decision is, of course, whether
you want to write a proposal at all.


Long before work on the proposal can begin a
decision must be made to submit a proposal. Within
the organization there must be study of the sol-
icitation to determine whether you will or will
not risk the expense of submitting a proposal--of
making the bid/no-bid analysis and judgment. That
is usually a command decision, made on "mahogany
row" by the executives responsible for marketing
commitments, although you may very well be called
on to assist in the study and enter some opinions
of your own about specific areas of concern.

The process varies widely in different organiza-
tions, but the basic considerations do not: vir-
tually all organizations, large and small, con-
sider the same factors in deciding whether to
bid--write a proposal, that is--or not to bid. It
is never cheap or easy to prepare a proposal, and
the decision to undertake the expense should never
be made casually, but only after solemn delibera-
tion. There are always pros and cons of the job in
terms of profit, risk, foot-in-the-door for future
work, pioneering new fields for expansion, best
use of company resources, effect on other commit-
ments, and general advantages versus disadvant-
ages. Here are a few of the specific questions to
ask and answer, when making these analyses and

Do we need the contract (new work) at pres-

Would winning this place a burden on our
overall capacity? On other commitments to other

What are our chances for winning?

What are our strengths and weaknesses, vis-a-
vis this requirement?

What are our prospects for overcoming our

Who are our probable competitors? (Can we
beat them?)

What other marketing prospects do we have at
the moment? (How would bidding this one affect our
capabilities for responding to the others? How do
our chances on this one relate to the chances on
the others, and what are the relative win-proba-
bilities of each?)

Is this the kind of work we really want to

All of this is solely to arrive at that bid or no-
bid decision, but if the decision is to bid (pro-
pose, that is) the information developed should be
input to the proposal team to help in the initial
needs analysis.

Note that the factors used in making the final
decision in any single case have no bearing on
future cases. Circumstances and policies change,
and you may very well choose to bid in May on the
job you would not have considered in January--or
vice versa. You must consider all the current
factors and circumstances, if you are to make
intelligent decisions about this. Remember, too,
that your judgments made here are going to be
reflected in your proposal-writing problems later,
should the final decision be to enter the competi-


Proposal writing is only the means; winning
is the end. Let us focus on the end.

If the point has not been made clearly enough
already, let us stipulate here and now: The under-
pinning of proposalmanship, of winning, is strate-
gy, and winning strategies evolve only from effec-
tive, searching analysis of the RFP and SOW,
followed by creative imagination. But who will
make the analysis, and how?

Except for small contracts, proposals are written
by teams of people, usually ad hoc teams assembled
for the purpose and made up of technical, pro-
fessional, and executive staff members. The propo-
sal and all that goes into it is supposedly the
combined and carefully blended distillate of
their best collective thinking.

Unfortunately, the typical proposal-writing condi-
tions too often result in a proposal that is not
that precious distillate, but is a lash-up pack-
age, a compromise among a field of views and

This is chiefly because many proposals are written
by groups of people, who are not really teams
because they have not worked as teams before and
because the typical proposal schedule does not
afford the luxury of enough time to do the job.
Invariably, a proposal must be written without
enough time, and often without enough of every
other resource, and all too often with people
borrowed from other tasks who have not had time to
read the RFP thoroughly and are not prepared for
even the first meeting. And yet, somehow, we must
manage to write winning proposals despite all
these problems.


A method which has proved effective in overcoming
this problem--in assisting such groups to develop
rapidly a concurrence of view and commonness of
purpose, such as is necessary to function smoothly
as a team while still serving as a vehicle for
strategy development--is one based on using graph-
ic methods for analysis, primarily functional
flowcharting and brainstorming.

The necessity for the method arises from the fact
that a great many work statements are poorly writ-
ten, either as a result of having been written by
someone who does not have a firm understanding of
the problem or need or as a result of having been
assembled (rather than written) by an assortment
of individuals without central control. As a con-
sequence of this, it is close to impossible in
many cases to visualize the customer's need from
the words alone. A graphic representation is nece-
ssary to visualize what needs to be done to satis-
fy the requirement.

Presumably, the way to do this is to translate the
words of the SOW directly into the functional
blocks, arranging them in logical sequence. In
fact, this is a good way to begin, when possible.
But it is not always possible. Many work state-
ments are simply too vague, often almost inco-
herent, to lend themselves to this. When that is
the case, more stringent measures are required to
generate something that begins to approach the
functional flowchart idea.

In this latter case, the method is to begin with
whatever the "knowns" are--the end-result and/or
product, for example--and work with those. And in
that latter case, it is often far better to devel-
op even the initial, first-draft flowchart as a
group exercise in the initial meeting.

Either way, the group has a rough-draft functional
flowchart to address as the basis for analyzing
and planning the proposal effort, and to refine
and polish until it represents the program in
graphic form and is the basis for the proposal.


Before beginning the flowchart, and especially
when the SOW is so vague as to make it difficult
to translate it into a chart, an extremely useful
first step is to make up a checklist--three check-

lists, in fact--from the RFP. These are the three
kinds of items to be listed:

* What must be included in the program

* What must be included in the proposal

* What will be the criteria upon which the
proposal will be evaluated and a winner

It usually requires repeated readings of the en-
tire solicitation package to complete these lists
(it is most difficult to get everything in the
first reading). But the objective is to list ev-
erything in each category--not only what is writ-
ten 4on5 the lines in the RFP, but also what can be
gleaned as having been written between the lines.

These lists should guide the drafting of the func-
tional flowchart, the uncovering of problems, the
discussions and development of approaches and
strategies, and the design of the program.


The objective of brainstorming is to generate a
synergy of ideas--a result greater than the sum of
the parts. Brainstorming should, according to its
inventor, advertising executive Alex Osborne,
address only one question or objective at a time.
In this case, these are the objectives that should
be pursued in successive sessions:

* Development/refinement of the functional
flowchart until all are satisfied that it presents
the approach to be adopted and the program to be

* Worry items: what specific items are criti-
cal in importance to the customer and should be
the linchpins of the main or capture strategy.

* Proposal outline reflecting approaches and

* Proposal assignments: who is best suited
and/or in best position to do each part of


The keys to finding worry items and formulating
strategies will be found quite often in redundan-
cies and anomalies in the RFP. Sometimes these
show up plainly in the text, but often they are
much more apparent or suddenly become apparent in
the graphic representations--the flowchart. That
is one of the several benefits of creating that
flowchart. (The singular case is used here, but
for large projects it may be necessary to prepare
more than one flowchart.) It's important to dis-
cover these for two reasons:

1: It's necessary to know all the "downside"
aspects, if you are to design an effective program
that will not become a serious problem later--if,
in fact, you are to be truly responsive with your

2: It is important to utilize these flaws--
tactfully--in explaining your program, and showing
your superiority to competitors. Any inadequacies
in the RFP, and especially any potential problems,
are grist for your strategic mills.

Another important benefit of a good flowchart is
that it is an enormous aid to communication
generally--to explaining your program to the
customer. The more detailed and more explicit your
flowchart is, the fewer the words you need to
explain your program. In short, the writing task
is greatly aided and simplified by a good flow-

This is a general truth about proposal writing
(and, for that matter, all writing): good graphic
presentations are at least as important as good
writing, if not even more important. However, it
is essential that the graphic illustration be
absolutely clear and easy to grasp, and the surest
route to that clarity is to keep it simple. The
figure used as a functional flowchart of the pro-
posalmaship process (in the front matter of this
manual) is an example--nothing "arty" at all; just
simplicity in concept and in execution.


One excellent way to turn up some of these
problems, during the brainstorming sessions, is to
perform a why-it-can't-be-done study. In this
analysis you start with the premise that the job
can't be done, and all participants offer their
reasons to justify the premise. Any reason offered
that cannot be easily discounted by some fairly
obvious fallacy in the reasoning becomes a potent-
ial element in the strategy..

  3 Responses to “Category : Databases and related files
Archive   : PROPOSAL.ZIP
Filename : SEM.I

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: