1. Require iterative development to frequently deliver usable software to users
Services are more likely to succeed if parts of their functionality can be delivered to users as they are developed instead of as a whole after a long period of development. This is the principle of least surprise: structure contracts so delivery happens gradually and frequently instead of a complete solution all at once.
If your RFP is for a large, complex system, rewrite the RFP to require small pieces of functional software as services that will work together over time. Your RFP may already describe these smaller services that could work on their own.
There is less risk in working on smaller pieces iteratively and individually, instead of working on a complete system all at once. There is also less risk in going live with each service to users when it is ready. If you can, break up large RFPs into smaller contracts, for individual services or smaller groups of services.
These smaller contracts may describe discovery, alpha, beta and live phases of service delivery and follow the suggestions of the U.S. Digital Service Playbook to structure budgets and contracts to support delivery.
Your RFP should:
- be the right size: group similar services together and separate custom development from commodity services
- require frequent delivery of working software to users
- describe small services that can be delivered on their own
- remove or simplify organizational layers so that features and improvements can be released multiple times a month
2. Require user research to check and meet user needs
Many big government IT projects end up being digital transformation and organizational change projects that affect lots of people. Services meant to do digital transformation or organizational change must be developed and delivered with and for their users.
This means doing user research throughout the development and delivery of the service to make sure the service is always improving and meeting user needs.
Sometimes RFPs include information like stories of a typical user’s day. Unfortunately, they’re not very helpful. This is because:
- Stories and narratives only describe what typical users do, not real users.
- It’s hard for these accounts to be detailed enough to help the delivery team clearly understand what users need.
- They give the impression that user research only needs to be done once or that no more research is needed.
Doing the work to provide a story doesn’t make up for a user research capability that’s used during the whole development and delivery process. If your government doesn’t have a user research capability, use the RFP to make sure vendors will do user research with you as part of a discovery process.
RFPs also usually require checkpoint builds (delivery of software to check for progress, but not for quality), quality builds (where the reliability and quality are checked) and then phases of user acceptance testing and end-to-end testing. This is also a problem. User needs are often discovered when software is actually being used, so do user research on your software from the start and as often as possible.
Your RFP should require:
- a discovery phase to understand and validate user’s needs
- qualified user researchers in the service team, either in government or from the vendor
- the service team to use qualitative and quantitative user research techniques
- doing user research regularly and frequently with real users during the development process
- development phases that let priorities change because of what’s learned from user research
- that user research is an important way to make services simple and intuitive enough to
3. Allow in-house, custom or commissioned options
RFPs often require commercial off-the-shelf software or “transfer” software (custom software written for a customer that can be used elsewhere). In these RFPs, only a small part of the service or solution can be custom. Sometimes this is done to save money.
Commercial or off-the-shelf software might be cheaper at the start because they already exist. But, a lot of this commercial or off-the-shelf government software doesn’t actually meet user needs - even if it’s being used by other customers.
With a good understanding of user needs, a qualified product or service manager should decide which parts of a system are best delivered by renting commercial software, and which parts need to be custom.
- use a method like mapping to understand what technology is needed to meet your user’s needs
- understand where user needs are well known and unlikely to change
- understand where user needs are unclear and likely to change
Your RFP should:
- require renting software services where user needs are well known
- require custom development using iterative methods where user needs are not well known
- be flexible and allow you to choose the best vendors or different ones for renting and custom development
4. Choose vendors who have delivered large-scale services that meet user needs
Most of the requirements of RFPs are there to reduce the risk of a bad surprise or of a system or solution that doesn’t work.
Some RFPs try to reduce this risk with key staff and certification requirements. These requirements don’t ensure the delivery of working software or services that meet user needs. They just show that certification standards have been met. It also means that “key staff” aren’t really key: they could be replaced by anyone else with the same certification.
Make sure your team can pick a bidder based on their history of delivering large-scale services that meet user needs. Service or product managers who understand digital delivery and user needs should be able to do this.
For example, when creating a federal marketplace for agile delivery services, 18f asked vendors for
“a live or near-live demonstration of their capabilities (e.g., 24-hour product development challenge) as part of the evaluation methodology. Doing it this way will not only help yield high-quality vendors, but also reduce how much “bid & proposal” expense companies have to incur. Very little, if any, in the way of written responses will be required, as is typically the case.”
Your RFP should:
- require vendors to show what they can do through working software, not presentations or mockups
- not waste time on key staff or certification requirements
5. Describe ongoing services, not solutions
Make clear that you are looking for a service that continues to improve, not a product or solution that is bought. This is on top of maintenance to make sure the service keeps working, it means requiring research and development that continues after the service goes live. Use the RFP to make it easy for the service to improve after it goes live, by using open standards and making sure you’re measuring the right data to decide what to work on next.
Your RFP should:
- require open standards and common or commodity platforms so the service can be regularly and frequently improved
- describe a clear and simple way to make changes to the service after it goes live
- make user research an essential part of the team that decides how to improve the service after it goes live
- set key performance indicators for the service
- require the collection of performance data to analyze success and choose features and tasks for improvement