Writing a website RFP a small firm can answer
LSCalado answers RFPs, so we have an interest in this subject. The advice below is meant to get you better proposals from firms of any size, and it points to two public guides you can read yourself: the NIGP practice Request for Proposals (RFP) (2020) and the Harvard Kennedy School Government Performance Lab's Crafting a Results-Driven Request for Proposals (2020). Page numbers refer to those documents. Your own procurement rules come first.
Describe the problem and the people
A website RFP often starts as a feature list: a calendar, a donate button, a member login. A small firm can price a list, but it cannot tell from it what you need. Describe instead who uses the site, what they are trying to finish, and where that goes wrong today. "Members call the office to renew because the form does not recognize them" tells a proposer more than "member portal."
The Government Performance Lab guide makes the same point about scope in general: a narrow statement of the problem produces a narrow set of responses (page 25), and it suggests a problem statement of 200 to 300 words (page 31). If you have numbers, such as calls per renewal season or the share of visits from phones, include them.
Publish the budget, and say what it includes
Without a budget, small firms guess. Some guess high and drop out. Some guess low and propose less than you need. NIGP lists a not-to-exceed budget among the general terms an RFP may include (page 4).
Say whether the budget includes support after launch, and for how long. If you want 12 months of support, training, and hosting inside the figure, say so, and ask for one total. Otherwise one proposal will quote the build alone and another the build plus a year of care, and the cheaper-looking number will not be the cheaper contract.
Use "must" only for real requirements
Every "must" is a pass-or-fail test. NIGP notes that writing "must" instead of "should" makes a requirement mandatory and can discourage qualified firms or disqualify them (page 6). A minimum number of years in business, a minimum count of past clients, or a required office in your state may be legitimate for your organization. Decide that on purpose. If what you care about is the experience of the people who will do the work, ask about the people.
Publish the criteria and the weights
NIGP says the criteria and weights must be stated in enough detail that a proposer knows what to include, and that the RFP must state how proposals will be evaluated, including steps such as demonstrations and interviews (page 3). If you will look at demonstration sites, say so, and say whether a link is allowed. If you will look at other sites a firm has built, say that too. A small firm will spend its limited time on what you said you would read.
Name the systems
If the site has to connect to a membership database, a donor system, a grants portal, or a campus login, name it, say who administers it, and say whether a vendor can get test access. "Integrates with our CRM" cannot be priced. "Reads member status from our association management system, administered by our membership manager, test account available" can.
State the accessibility standard
Name the standard you expect, such as WCAG 2.1 AA or 2.2 AA, and say who will check it. State and local government entities are covered by the Title II web rule, which sets WCAG 2.1 AA; the compliance dates are on ada.gov. If you are not a public entity, your counsel can tell you what applies.
Give proposers time, and one contact
The Government Performance Lab's sample timeline puts the response deadline at least six weeks after release (page 14). That is a sample, not a rule, but two weeks rarely produces a demonstration worth reviewing. In the NIGP practice, the procurement professional designates a single point of contact for all questions about the RFP (page 9). Every proposer then gets the same answers.
After the award
If your rules allow it, tell proposers who won and why. A short note to everyone costs an hour, and the firms that lost will write a better proposal next time. NIGP describes a debrief as covering only that supplier's own proposal (page 12).
Checklist
- A problem statement that names the users and what goes wrong today.
- A budget, and whether it includes support, training, hosting, and licenses.
- The support period you expect, in months.
- Mandatory requirements you have decided are real, and no others.
- Criteria and weights, and whether demonstrations or other sites will be reviewed.
- Each system the site must connect to, with its administrator.
- The accessibility standard, and who checks it.
- A response window long enough for a demonstration, and one contact for questions.