Procure services, not software

Don’t think of procuring custom software as buying a thing. Instead, think of it as buying a service: the service of a team of developers and designers performing work as prioritized by the product owner. This reframing leads to a completely different approach — a much simpler approach — to the RFP and to the contract, and is an important distinction for contracting officers.

Your RFP should describe the overall goal of the work, and should include a first attempt at a product backlog — a list of the work that will be done — put together by the product owner. This should look like a list of user stories — tasks to be performed to address the needs of end users — that the work is likely to address, clearly labeled as indicative of the types of work that’s likely to be involved, rather than a fixed scope of work. The RFP should also acknowledge there will be constant change to the work based on shifting priorities and ongoing user research; change is expected, and it’s easy to change software when it’s built in modern ways.

The RFP should use a Statement of Objectives rather than a Statement of Work — that is, it should state the objectives of the project, rather than the specifics of a product that the vendor should produce. Using a SOO instead of a SOW eliminates "change orders" from vendors, because the scope of work is whatever the team is directed to do. (If an ostensibly "agile" vendor mentions change orders, that’s a red flag.)

To ensure vendors deliver work that meets the needed technical specifications, it is important that the RFP include a Quality Assessment Surveillance Plan (QASP) that is appropriate for agile development methods, requiring that the software be inspected at the end of each sprint to ensure that it is tested, secure, accessible, documented, and deployed.8 (See Appendix B for sample QASP.) Meeting this requirement requires regular demonstrations of actual, working software, not memos or descriptions of what a system is supposed to do in the future.

Historically, there has been pressure to only use firm fixed price contracts, on the assumption that this reduces risk. However, if you are in a position to constantly measure software quality, then a time and materials contract — with a ceiling on total spending — allows for more flexibility for the software development team. A time and materials contract also allows for much easier escape clauses if the direction of the work changes or the vendor team is not producing quality software. If a vendor team’s work is inadequate, or their skills prove inappropriate, then no further work need be assigned to that vendor (effectively terminating the contract), and the vendor can be replaced.

Checklist

  • [] The project has a dedicated, empowered product owner who is an employee of the agency — not a contractor, and not an employee of the state’s IT agency — whose job it is to prioritize work for the development team
  • An agency contracting officer has embraced this project, and is enthusiastic about procuring software in new ways
  • The RFP will be solely about procuring development services, not about procuring a tangible thing
  • The RFP will require a cross-functional team of designers, user researchers, and developers
  • The RFP will be no more than 20 pages in length
  • A backlog of at least a dozen user stories has been created and added to the RFP
  • A time and materials contract (with a cap) will be used
  • The simplest available procurement vehicle that provides access to the targeted vendors will be used

Key questions

  • Is the product owner empowered to rapidly make authoritative decisions on behalf of the agency?
  • Is the product owner prepared to spend most of their work hours fulfilling the requirements of this new role?
  • Is agency leadership prepared to have product decisions led by identified user needs, based on direct conversations with those users, rather than leadership’s personal preferences?
  • Does the RFP establish clear requirements about the regular delivery of working code, documentation, testing, and ownership of all work products remaining with the state?


Footnotes

8. For an example RFP, see the U.S. Tax Court’s 2018 EF-CMS RFQ, which includes a QASP, under the "Deliverables and Performance Standards" section. ↩︎