2c. RFP writing

This section will help you:

Develop objective and fair criteria and incorporate insights from market research and benchmarking

Incorporate departmental and municipal priorities into the criteria

Write an RFP

Common challenges

You may encounter these frictions as you do the work of RFP writing. These are challenges the Recommended actions are designed to solve, or that may arise as you take those actions.

Culture of Caution

Cities and their procurement teams often assume that procurement law is inflexible, and re-use existing templates for RFPs to “play it safe.” These can unnecessarily constrain and influence the project definition and the resulting product. Start from a good description of the problem and an effective development process, then add in only the legal and procedural details that are necessary.

Writing in legalese

People often write RFPs in “legalese,” assuming that it appears more formal or legitimate. However, writing in a confusing way will only hinder the contracting and development process. It creates a high barrier to participation for small vendors who do not have bid sourcing or legal support. Describe the needs and criteria in clear, plain language.

Narrow and over-specified scope

RFPs often over-specify criteria and requirements, or they jump to describing products rather than problems. This forecloses the possibility of receiving bids that are innovative or exceed expectations. Narrow scoping also reduces the number of eligible vendors, which can leave you choosing between a small number of bad options. Don’t over specify the end product up front. Focus on the problem to solve and find the right vendor—then you can develop a solution.

Recommended actions

1. Mapping existing technical and operational systems

Your goal is to design software that integrates well with the city’s existing technical environment, including cloud services, local servers, open data platforms, end user workflows, and cross-departmental data sharing protocols. Start by mapping the existing landscape.

Meet with technical teams

Review system architecture, existing platforms, and interoperability considerations.

Meet with end users

Review any additional software that they use, and how the proposed software would fit into their daily workflow.

Document the city’s technical and operational environment

This can be a simple overview or list that helps map out a more detailed exploration

2. Designing value- and values-led evaluation criteria

It is important to state the evaluation criteria clearly in the RFP. In fairness to the bidders, criteria should leave little room for subjectivity—but that doesn’t mean you should avoid social or values-based criteria. In fact, stating values explicitly in the RFP means you are completely justified in using them as part of your evaluation.

Your goal, as you write criteria, is to maximize eligible bids. The more responses you get, the higher likelihood that you will find a great solution or vendor.

Consider your criteria in a 2x2 matrix

Include software and vendor evaluation criteria, and mandatory and optional criteria.

Software evaluation: Technical performance (derived from benchmarks and standards), and user experience (derived from user journeys and design ideas revealed in the discovery phase)

Vendor evaluation: Qualities of the organization to be hired

Mandatory: If a software or vendor fails to meet all of these requirements, the bid is eliminated. These are also known as “eliminatory criteria.”

Optional: Software or vendors should satisfy as many of these criteria as possible. These are also known as “points-based criteria.”

Here’s a simple sample matrix:

Open source, licensable under Creative Commons Zero

User privacy must follow OECD guidelines

Software will ideally meet WCAG “AA” level guidelines

We require a local, emerging business which is minority or woman-owned

We prefer Energy Star certified data centers in countries with strong consumer protection laws

Software evaluation criteria

Mandatory

Vendor evaluation criteria

Optional

Outcomes-based procurement

You’ve done a lot of market research, so you are familiar with the technical landscape—but there may be novel solutions you haven’t yet discovered. Outcomes-based procurement is helpful if you don’t know all of the existing solutions to the problem statement.

As you write evaluation criteria, think in terms of the goals and outcomes, rather than a given solution. Vendors might surprise you with unexpected ways to address your problem statement.

With an outcomes-based framework, your RFP can also promote innovation. By describing outcomes, not solutions, you’ll attract vendors who are willing to work with you to co-develop a novel solution.

3. Writing with effective language

Vendors will understand your needs best if they are written clearly, in plain language. A well-written RFP will encourage more and varied vendors to respond.

Much is communicated between the lines of what is written

If you put an RFP out for the minimum required number of weeks, vendors will think you just want to work with incumbents who already contract with the city and have more resources for bidding, as opposed to smaller firms with more innovative, high-quality solutions.

Make it clear and simple

There is no reason why RFPs need to be written in overly formal and confusing language.

Less is more

Focus on the problem (the “why”)—leave the “what” and the “how” up to vendors.

Read a draft of the RFP from the vendor’s perspective

What biases are communicating with the content, format, or criteria of the RFP?

4. Including additional required RFP content

Your colleagues in the legal and procurement departments will specify additional required content that should be added to the RFP. This may include clauses for liability, terms of contract, etc. Discuss with legal and procurement teams to understand what this required content is, and become familiar with it.

Some standard clauses may undermine the desired solution or process

For example, legacy clauses about reviewing for satisfactory performance, or about timing of deliverables, may make it difficult to run an agile development process or to use modular budgeting.

Integrate standard language and legal clauses

Be vigilant about those that get in the way of your goals and project plan.

Takeaways

Technical landscape map

Evaluation criteria

RFP document

Process code for software procurement