IT Procurement: A Critical Enabler for Improving Government Service Delivery (Ryan Ko)

Very few (less than 15 percent) large government IT projects successfully complete on-time, on-budget, while still on-scope, serving intended needs. At Code for America we have worked with dozens of states across the United States, witnessing this firsthand, and advised and counseled dozens more, particularly in the context of Integrated Benefits (e.g., SNAP, TANF, Medicaid, WIC, LIHEAP) delivery, where IT procurement shows up in many different places, from maintaining benefits applications, backend data systems, to customer support contact centers. Traditional status-quo IT procurement and vendor management often leads to suboptimal service delivery outcomes, in addition to time and budget overruns. Here are five recommendations to combat this, based on our experience.

1. Work towards paying for actual program outcomes, not requirements or technology outputs. Benefits systems, such as integrated application portals, IED (integrated eligibility systems), MMIS (Medicaid management information systems), and many others, are often outsourced to IT vendors, rather than built in-house. This in and of itself is not a problem, however, it leads to a dynamic where vendors are paid for the output of delivering a functional system according to requirements in a contract, which is a different incentive than an in-house delivery team which, by nature of being one step closer to the program, can share in the accountability of program outcomes. This is still possible in an outsourced environment, and we have noticed the field is experimenting and learning together on how to do this better, including building capacity with government IT, finance, and procurement staff to align outcomes and truly partner with vendors. For example:

• Align the vendor to the mission: Instead of procuring technology that meets a list of requirements, procure technology that meets program goals. By focusing vendors on actual desired outcomes, governments can avoid the costly game of telephone that can follow.
• Structure contracts so that vendors are not paid by the work hour—but by the business outcome: Focus on the business outcomes to achieve, using shorter (about six months to one year) firm fixed price contracts that gradually build up to a full system, rather than a monolithic multi-year build.

2. Avoid vendor lock-in.

• Purchase technology that is not vendor-specific: This can be open source technology but doesn’t necessarily have to be. Many private source, off-the-shelf technologies are commonly used (e.g., Salesforce, Airtable, WordPress), and thus, many vendors can build and maintain systems based on them.
• Ask vendors for modularity: This means building the technology in different distinct parts that can be taken out, swapped, and used interoperably. Modularity is important: It allows for best-of-breed operations by having different vendors build different parts of systems. Notably, CMS recently attached modularity requirements to all MMIS systems and noticed that states have started working interoperably with each other, while more vendors have started specializing on various modules.
• Insist on proper documentation of the system: Documentation is useful in case anyone else must maintain or operate the system in a time of emergency—such as in-house technical staff or another vendor.

3. Insist that vendors bring best practices of technology development. Insist that vendors provide best practices from their industry, and ask that they are open and transparent about their practices. These best practices include, but are not limited to:

• Product management: This is not the same as project management traditionally found in government IT. A product manager focuses on building a delightful, easy-to-use, efficient piece of technology, as opposed to overseeing complex project plans, timelines, requirements, and deliverables.
• Usability testing: All vendors must test their products. However, this can often be limited to “user acceptance testing” which is more of a box-checking exercise. Rather, testing should be focused on usability to ensure that the experience for all users (whether that’s public servants, clients, or anyone else who may come into contact with the system) is easy to use and efficient.
• DevOps, release management, modularity, security, and other best practices: There are many industry-proven practices in the field of software development.

4. Insist that vendors work in an agile, iterative, continuously improving manner, while putting people first. These are some of our fundamental Code for America principles:

• Work with an iterative approach: Agile may seem like a buzzword, but at its core it simply means that software should start small, with low-fidelity prototypes, and gradually test and iterate and improve, rather than trying to plan the entire system ahead of time, build it, and launch it all at once.
• Qualitative user research: Qualitative user research is fundamental to developing government services that better and more equitably meet the needs of communities by truly seeking to understand the fundamental needs of people who use government services.

5. Make it easy to work with governments.

• Clearly communicate the end goal: Vendors sometimes find it difficult to understand context about what is really being asked for and why. By communicating the true program outcome, not just the technology requirements, governments can help vendors become collaborative partners.
• Establish shared vision: Work with the vendor to establish a shared vision, which may include values, hopes and dreams, fears, and challenges. Clearly communicating these will help the vendor understand the government context, and solve appropriately for them.
• Eliminate burdens that make it difficult for vendors to participate: There are common procurement requirements written into RFPs that preclude many vendors from bidding on government IT projects. The result is that the same large vendor incumbents keep winning contracts, leaving no room for other vendors—who may be smaller, more local, and have new innovative ideas for solving government technology problems—to compete.