---
name: request-for-proposal
description: Use when asked to write a request for proposal (RFP) — a procurement document soliciting competing bids from vendors for a defined need — as distinct from a [[statement-of-work]], which defines what the vendor actually selected will deliver, usually written after the RFP process ends.
---

# Request for Proposal

A request for proposal (RFP) is a procurement document an organization
sends to multiple vendors, inviting each to submit a competing proposal
for how they would meet a defined need. Its job is to let the buyer
compare vendors on a level footing and make a defensible selection
decision, not to describe the work in the level of detail a signed
contract eventually will.

## Key components

- **Background and context** — who's issuing the RFP, why the need
  exists, and any constraints (existing systems, prior vendors,
  organizational context) a bidder needs to write a relevant proposal.
- **Scope of work requested** — what the buyer needs done, stated
  concretely enough that different vendors' proposals can actually be
  compared against each other, without over-specifying the *how* (that's
  the vendor's job to propose).
- **Evaluation criteria** — the factors that will decide the award (price,
  technical approach, experience, timeline, references) and ideally their
  relative weight, disclosed to bidders up front.
- **Submission requirements and deadline** — format, required sections,
  how questions get submitted and answered, and the exact date and time
  proposals are due, along with when a decision will be communicated.
- **Budget range** — if the organization discloses one, it helps vendors
  scope a realistic proposal instead of guessing; some organizations
  withhold this deliberately, which is a legitimate but different
  strategy.

## How it fits in the vendor lifecycle

An RFP comes first: it solicits competing proposals and selects a
vendor. Once a vendor is chosen, the actual deliverables, milestones,
and acceptance criteria get spelled out in a [[statement-of-work]] —
often drawing directly on the winning proposal, but written with far
more binding detail than the RFP itself contained. Confusing the two
leads to RFPs bloated with contract-level specificity, or SOWs vague
enough to relitigate what was actually promised.

## Common pitfalls

- **Evaluation criteria not disclosed to bidders** — vendors can't
  tailor a proposal to what actually matters if they don't know how it
  will be scored, and undisclosed criteria invite later disputes over
  whether the process was fair.
- **Scope so vague that proposals aren't comparable** — if each vendor
  interprets the ask differently, the buyer ends up comparing apples to
  oranges instead of evaluating genuine alternatives on the same basis.
- **No clear decision timeline** — vendors invest real effort preparing
  a proposal; leaving them with no sense of when they'll hear back
  damages the buyer's reputation with vendors it may want to work with
  again.
- **Requirements copied from a previous RFP without adapting them** —
  stale references to old systems, budgets, or timelines confuse bidders
  and signal the document wasn't actually tailored to this need.
- **No process for handling vendor questions** — bidders who can't get
  clarifying answers either guess (hurting comparability) or skip
  bidding altogether.

## Learn more

- [[statement-of-work]] for the binding deliverables document that
  typically follows a completed RFP process.
- [[vendor-management]] for managing the relationship after a vendor is
  selected and under contract.
- [[contract-review]] for evaluating the contract terms before signing
  with the chosen vendor.
- [[project-charter]] for defining a project's own scope and objectives,
  a related discipline when the RFP's need originates from a specific
  internal project.