|
Common Errors Can Kill Your Proposal
By Michael Asner
There is only one way to win a fair and open competition: provide
evidence that you offer the best solution with the least risk at an
acceptable price. In contrast, there are many ways to lose.
You can submit an excellent proposal, make the short list, give your
presentation, and even submit a "best and final offer" but still come
in second. This happens all the time.
There are lots of gentle ways to fail: Your proposal simply didn't have
the quality of the winner; your firm lacked enough experience to
justify the increased risk; your management plans, while adequate, were
less detailed than those of the winner; during your presentation, your
project manager failed to impress the evaluators; or your technical
solution simply was not inspiring.
Losing Big Time
There are many ways in which to come in
second. But, losing "big time" means you failed to make even the first
cut. In other words, your proposal - which consumed great amounts of
time, energy, and money - was dismissed early on, well before anyone
created the short list.
In some cases, your efforts simply didn't work - your proposal lacked
the "right stuff." It had such serious deficiencies that the evaluators
didn't get past page two. They knew after reading the summary or the
first few pages that you had missed the mark. The evaluators then read
the remainder of the proposal to collect enough specific evidence to
justify declaring your effort "non compliant" or "unresponsive."
Sometimes, evaluators read the entire document only to discover that
your efforts are spotty. Some parts are excellent; others are vague.
This leaves a lingering impression that the writer is expert in some
relevant areas and badly lacks competence in others. And once an
evaluator questions your competence, you're out of the running. No
evaluator will bet his or her career on a high-risk proposal.
Evaluators do not have to score an entire proposal to declare it
unresponsive. They often identify the weakest section and then spend
their time making notes as to why they scored it so low. These notes
become part of the project file and can be used to defend an evaluation
in the event of protest.
Successful firms know that every section of the proposal must be solid.
Some RFPs require a minimum score for key sections such as project
plans, experience or technical solutions. This ensures that proposals
with a serious weakness in only one section cannot win the competition.
In most jurisdictions, evaluators also may dismiss any proposal they
believe is inadequate, without producing detailed scoring to reach
their conclusion.
In Massachusetts, for example, this authority is identified in the
state's Procurement Policies and Procedures Handbook under
Disqualification of Responses. The handbook states: "... a procurement
team shall disqualify any response that it deems unresponsive ... which
shall include responses that fail to meet, address, or comply with
material requirements." The key word in early dismissal of a proposal
is "material." If it's important, and you treat it inadequately, you're
out!
Fatal Errors
Here are some examples of what most
evaluators would consider material deficiencies or significant failures
in your overall approach or effectiveness.
- Failure to propose excellent
people: Do not include resumes that contain unrelated information or
that do not conform to the stated requirements. Resumes and other
"boilerplate" should be rewritten for each proposal. Evaluators who
read your proposal should conclude that the people on your project team
are experts in the area of the proposal. If the resumes do not support
this conclusion, then propose different people.
- Failure to demonstrate directly-related work: Most RFPs ask
for information about your firm's prior experience and qualifications.
This is an opportunity to highlight your work on similar projects.
Failure to specifically describe directly-relevant work makes
evaluators question your overall competence. If you cannot reference
similar work, then you should identify other specific projects and
explain why they are relevant.
- Altering the schedule: Submitting delivery dates which are
later than the schedule in the RFP is usually fatal. If you are the
only supplier challenging the deadlines, your credibility becomes an
issue. Sometimes, proposing alternatives or redefining deliverables is
acceptable. But if you cannot meet the RFP deadlines, consider a "no
bid."
- Missing a key requirement: Not all RFPs are well written and
well organized. Often, requirements are distributed throughout the
document. Yet missing a key requirement can cause your proposal to be
dismissed as "incomplete." Many organizations create a checklist of all
RFP requirements and use it to ensure that their proposal is complete.
Including this checklist in your proposal is one way of impressing the
evaluators with your thoroughness.
- Failure to understand the problem: Your proposal must prove
that you understand the issues facing the potential customer. Many
proposals are too vague. The writer assumes that somehow evaluators
will know intuitively what he or she means. Repeating the RFP's
definition of the problem does not demonstrate understanding. Instead,
describe your views, insights or experience with this problem. Explain
how you've helped other organizations with similar needs. Assume that
one of your competitors has a deep and thorough understanding of the
issues.
- Failure to connect tasks and deliverables: Show clearly that
the project will produce a measurable outcome. Evaluators want to know
that you have the techniques, tools, staff and organization to ensure
success. They want to know "what," "when" and "how much." Your proposal
must provide sufficient quantitative information to convince evaluators
that your firm can deliver a quality product, on time and within
budget. Remember that most IT projects fail! Discussing risks and
methods of ensuring quality can differentiate your firm from the
competition.
A Unspectacular Win
More often than most suppliers
realize, the winning proposal doesn't have the best product or
technical design, nor the best ideas, nor the best management plans. In
fact, in many cases, the winning proposal is unspectacular. But, the
winning proposal scores among the top three in each evaluation
category; therefore, it represents the best overall proposal with the
least risk.
Many firms lose not because their products or designs are inferior or
deficient. And not because their prices are too high, or because their
management skills are poor. They lose because they have submitted a
poor proposal - one which fails to convey the quality of their firm and
its offerings.
Weak proposals stem from a failure to manage the proposal-writing
process as a project. Proposal writing is just as important as product
quality and technical skills. If you intend to be casual about the
proposal and careless about its writing and contents, then don't bother
preparing it. At least one of your competitors will treat the
opportunity seriously. Don't represent your firm with a weak proposal
that produces a poor impression. This often influences evaluators'
views on issuing your firm the next RFP.
It's ironic that IT organizations - major firms which pride themselves
on their project management skills - neglect to organize the proposal
effort as a legitimate project. This includes failure to provide the
required resources, lack of standards, lack of tools, failure to begin
immediately and poor project management. All of these problems lead to
running out of time to create a first-rate proposal.
A typical scenario goes like this: Little is done in the first two
weeks after receiving the RFP. Activity heats up during the third week
and reaches a frenzy five days before the submission deadline. Trying
to prepare a proposal in too short a time often produces symptoms of
hurry: bad editing, clumsy writing, poor proofreading, inconsistencies
and errors.
The bottom line? Start work on the proposal well ahead of the due date
and devote the time and staff needed to do it properly. In other words,
treat the development of a proposal as a serious project or don't start
at all!
|
