One risk of responding to an RFP as an independent contractor is that the potential client’s decision-making process might last so long that even if you’re awarded the contract, you will have had to accept other work to stay in business. Although turning down an awarded contract isn’t unprecedented, it will probably mean you’ll never work for that company on any project.

Most RFPs set out a timeline for a decision, but some companies take considerably longer than they may have anticipated. They’ll still expect you to start work immediately after notification. To protect your reputation, submit a proposal only when you can either time your work for other clients around the contract award date or when you can afford to wait for a decision.

To give yourself an advantage over such lengthy decision-making processes, consider submitting an unsolicited written proposal even when you don’t have an RFP in hand. Even if the company hasn’t asked you to write a proposal, doing so can set you apart from other consultants being interviewed, present your ideas persuasively, and even convince other decision makers of the need to move ahead with the project.

Think of the proposal as another chance to sell yourself after the initial meeting with the prospective client. For example, after a recent information-gathering meeting about creating a documentation library for a prospective client, I submitted a detailed proposal that analyzed how documentation could satisfy a number of the client’s business needs. Three days later, the client called to ask me to come onboard, not as a documentation specialist but as the product manager for an entire business unit.

When to pass on a proposal

Because a good proposal takes days, if not weeks, to research and prepare, it’s important to know when not to submit a proposal.

If you’re considering using a proposal to further your case after one or more consultations with a client, you need to feel confident that the company is serious about proceeding with the project. (For more on this issue, see my previous article on qualifying potential clients.) On the other hand, you should not submit a proposal if you don’t know the scale of the project or when it’s likely to start.

When reading an RFP, always be on the lookout for signs that something isn’t right. Private companies and government agencies sometimes send out an RFP because they have to do so, either by law or internal bureaucracy, even when they’ve already made their selection. Signs that might warn you away from submitting a proposal include the following:

An excessively vague statement of work: Vagueness is an RFP hallmark because the issuer doesn’t know exactly what it wants (hence the RFP). Nevertheless, the RFP must be sufficient to allow you to estimate your proposed scope of work. If you can’t clearly define the scope, you can’t make an accurate bid. And if you get the contract, you could end up in a nightmare project with no boundaries. An incredibly detailed statement of work: You might find the opposite problem: If the specification is so detailed that it’s clear the company has narrowly defined the technology to be used and the approach to be implemented, this probably means that the company’s mind is already made up about its choice. A restrictive closing date: Watch out if the closing date for proposals is so close to the date of announcement that only someone who’s already prepared could create a decent proposal.

Keeping your ideas safe Whether you submit your proposal in response to an RFP or after a meeting with a client, it’s important to safeguard the information you’re submitting. You can do this in two ways: by copyrighting your proposal and by knowing what to reveal and what to withhold.

Copyrighting Copyright every proposal you send out. On the document’s title page, place the phrase Copyright (Today’s Date) by (Your Name.) On the next line, add All rights reserved. That’s all you need to do to establish copyright. A footer full of copyright symbols (©) makes you look paranoid and amateurish.

Protecting your secrets Unfortunately, shielding your business secrets isn’t as simple as adding some text. To win the contract, you must explain the solution you intend to implement in enough detail that the client understands it and is convinced that it’s the right solution. On the other hand, you don’t want to provide so much detail that the client could implement the solution without you or reveal a valued strategy to competitors.

Although government agencies usually follow strict confidentiality guidelines-often detailed in the RFP-until the contract is awarded, most are bound by law to eventually make the procurement process available for public inspection. It’s likely that your proposal will eventually become public domain.

The best way to sell your solution without giving too much away is to describe your solution as specifically as possible and allude to even more specific information that will follow in the functional specification and detailed design documents, which come only after you’ve been awarded the contract.

To show you what I mean, here’s an excerpt from a proposal I wrote for a client who was bidding to implement a smart-card point-of-sale solution:

"The host will use a DES-based (data encryption standard) algorithm for generating a message authentication certificate (MAC) that is unique for every transaction. The smart card will use the same algorithm to verify the MAC before applying the transaction and returning its own MAC to the terminal.

"To increase both data security and terminal response time, all terminal-to-card communication will use the t=1 command protocol. For security purposes, the algorithm, the data from which the host and the card create their MACs, and the command protocol bytes and status bytes are not noted here but will be specified in the detailed design document."

Phrasing the proposal this way throughout accomplished several goals:

It acknowledged the issuer’s concerns in the RFP about security and transaction time at the point of sale. It conveyed enough detail to establish my client’s credibility about the solution. It created the impression that my client was competent and had thought through the development issues by alluding to the much more detailed information that was to follow.

As you write your proposal, you’ll know when you’re giving away too much information. Don’t be afraid to back up and refer the issuer to those low-level documents; your client will be able to see and request modifications once the project is officially yours.

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам