Executive Summary

State and local governments pay millions to contractors each year for goods and services that keep their agencies running, help the public and shape whether residents think their government is doing a good job.[1] This is particularly true for technology. States depend on contractors for the software that provides people with services they take for granted — and demand.

This means that a failure of procurement — the processes, policies and people behind all this spending — can disrupt services for millions and derail an administration’s ability to deliver its priorities. Problems with these contracts abound. One consulting firm found that only a small portion of large software projects launched by the government and other sectors of the economy are considered successful.[2]

High-profile examples of such problems are all too plentiful. There was the calamitous 2014 rollout of, the Obama administration’s flawed health care web portal. Rhode Island’s Unified Health Infrastructure Project (UHIP) collapsed when it opened in 2016, leaving thousands unable to access health, food and other critical services or get in touch with eligibility specialists for months. 

One reason for these failures is states’ antiquated procurement practices and strategies. Agencies use the same processes to procure a constantly evolving, $100 million software system that they would use to buy a bus that costs less than $500,000.

In addition, officials often gamble that they will fulfill their mission by turning the entire project over to one vendor with a single contract. They might have rigorous oversight of spending, but no way to gauge the quality of software development or ensure that the project is producing the desired outcomes.

This “big bang” approach to technology projects was trendy in the private sector in the 1990s. After a few years they found it led to high rates of failure and largely abandoned it. But most states still use this practice, leaving it harder for them to procure the custom software that industry builds today. 


No state can radically transform its procurement processes in the first 200 days of 2023, but they can set new expectations and start making changes.

Improve rules for the procurement of software

States should consider breaking up large, risky projects into smaller, more manageable contracts spread across multiple vendors. Keep each contract small so that failure will not bring down the entire project. Contracts should call for developing software incrementally, allowing end users to quickly put the improved software to work.

Build teams with the skills and support to succeed

The first step for changing procurement processes is gaining support from state and agency leadership. This includes agency leaders, senior procurement officials and legal offices, including both appointed officials and career staff. States must also ensure that they have modern technology expertise on their procurement teams. States are most effective when they start small and build on what’s working as they grow their teams.

Review ongoing and upcoming large-dollar software procurements

When a new governor takes office, hundreds of millions of dollars of projects are already queued up. If those projects fail, that governor will be blamed, not the prior one. Every existing software procurement project should be reviewed, led by an official from the governor’s office. The review should find contracts that are at risk of failure, and each should be reevaluated for modification or termination.


States pay many millions of dollars every year to the private sector for goods and services that keep their agencies running. These purchases help agencies fulfill their missions and shape whether residents think their government is doing a good job. This is particularly true for technology. States depend on contractors to build and maintain the software used to provide people with services they want — and need.

This means that a failure in procurement — the processes, policies and people that states rely on to buy or build technology — can disrupt services for millions and derail an administration’s ability to deliver on its priorities. State governments have a long history of problems with technology contracts. One consulting firm found that large government technology projects are more likely to fail than to succeed.[3]

High-profile examples of such problems are all too plentiful. There was the calamitous 2014 rollout of, the Obama administration’s flawed health care web portal. Rhode Island’s Unified Health Infrastructure Project (UHIP) failed when it opened in 2016, leaving thousands unable to access health, food and other critical services or get in touch with eligibility specialists for months. 

California canceled its 10-year unemployment modernization project when the vendor failed to produce working software.[4] Michigan is replacing the child welfare computer system it installed seven years ago, which cost more than $200 million, because it was so difficult to use. Staff had to spend more time at their computers and less time in the field on investigations, putting some of the state’s most vulnerable children in danger.[5] When software procurement fails, government fails. These examples are routine, not extraordinary.

States’ acquisition and procurement strategies set projects up to fail from day one. Agencies use the same practices to procure $100 million software systems that they would use to buy a bus that costs less than $500,000. This approach is a poor match for building 21st-century technology. Today’s software must be constantly maintained and improved to match changing customer expectations and program requirements. 

Agencies are most successful when they procure the services of a vendor to build software, rather than focusing on buying a thing. When states approach software contracting as if they are buying a thing, they tend to meticulously document a large set of inflexible requirements and use that as criteria for selecting a vendor. Like a gambler betting everything on a roulette wheel landing on 36, they take a chance on fulfilling their mission by turning the whole project over to one firm with a single contract. They might have rigorous oversight of spending, but no way to gauge the actual quality of the software. These types of agreements also prevent contractors from easily adapting to changing circumstances or priorities without lengthy contract amendments and significant additional cost to the state. 

When procuring a vendor’s services, states detail how they want to work, the skill sets they need and the outcomes they aim to achieve. These types of contracts are most effective when they are small and flexible, prioritize software features based on actual user need and incentivize collaboration between states and vendors. 

Procuring the services of a qualified vendor is not only important when building customized software, but is also crucial when buying “off the shelf” technology tools. When states hire a vendor to make changes to, or “configure,” prebuilt software, they are essentially customizing that software — i.e., making changes that will need to be managed and maintained as long as they use it. 

There are many people in government who want better outcomes for these projects. And there are many who believe that the current procurement process is broken. While no state can radically transform its procurement processes in the first 200 days of 2023, they can set new expectations and make early improvements that will build momentum for long-term change. By leveraging best practices in agile, human-centered procurement, states can adopt proven new approaches to make success far more likely.


Below are meaningful steps that state leaders can take at the beginning of 2023 to improve technology procurement and help government deliver services more effectively. In the first 200 days:

  1. Improve rules for the procurement of software;
  2. Build teams with the skills and support to succeed;
  3. Review ongoing and upcoming large-dollar software procurements.


The first step for improving software procurement is establishing updated rules for doing it. While existing procurement processes may seem inflexible, most state procurement laws and regulations provide the authority and flexibility required to substantially improve the process. 

The most effective rules reflect proven best practices in modern software procurement. States that are most successful break up large, risky projects into smaller, more manageable ones. They keep each contract small so failure will not bring down the entire project.[6] They also ensure that each contract rests with one vendor that will develop software to be delivered incrementally. Delivering working software in stages enables system users to see real improvements in their day-to-day experience and helps the state monitor quality based on what is actually delivered, rather than on planning documents. 

States are more successful at technology procurements when their project approval, contracting and executive branch budgeting processes are aligned around these best practices. 

Here are some best practices to consider:

  • Require that every technology project or budget be backed by rigorous user research. User research is the practice of interviewing state staffers and external customers about their experience with a program or system. The goal is to identify real pain points and then prioritize technology projects that will solve identified problems and improve the user experience. The resulting approach is also known as human-centered design. Ideally states will have the internal resources to conduct this research. States without this capacity can get help from nonprofits like Code for America and U.S. Digital Response to conduct user research side by side with their teams. Alternatively, they can contract with a vendor that offers this service.

  • Simplify approval and oversight processes for projects or contract requests under $1 million. Smaller projects inherently carry less risk and are much likelier to succeed. Streamlining approval processes will incentivize breaking up large projects into small, manageable components that can be delivered more quickly.

  • Limit the number of individual software development contracts that exceed $6 million or take more than three years to complete, including options to extend the length of the contract.[7] Ideally, vendors should be able to deliver working software that improves the user experience and/or solves an existing problem within six months.[8]

  • Require vendors to deliver working software incrementally. Pay them for each piece of working software they deliver, rather than in one lump sum or for planning milestones they complete.

  • Measure a project’s success by the results it produces, rather than how well it is planned. Moving a software project from phase one to phase two is meaningless. What matters is if the project has resulted in a tangible, measurable benefit to the state and the public.

  • Base oversight of budgeting and the evaluation of potential contracts on meeting user needs, not hitting financial goals. Never consider a project more successful for spending all its money — “hitting its budget” — than for accomplishing its goals for a fraction of the possible budget.

  • Require that state-employed software developers approve every line of code produced by a vendor, in coordination with the contracting officer’s representative, before accepting it. This will require hiring software developers with experience performing code reviews.

Make customer experience an explicit priority

States that do not emphasize the needs of end users — the public and state workers — in the vendor proposals they request and the contracts they negotiate are more likely to end up with software products that fail to deliver value. 

The most effective governments prioritize work that addresses specific problems, sets tangible goals and uses data to measure progress toward those objectives. This means getting feedback from the public and state employees about how well a program is working and where improvements should be made before a project is started. It is important to fight the instinct to make assumptions about user needs and to instead ask, “What is the user need?” 

Improving people’s experience can guide how teams make decisions and evaluate vendor performance. For example, a state can help constituents applying for benefit programs if it sets goals for them to be able to:

  • Apply in 20 minutes;

  • Enroll in 24 hours;

  • Only have to share their information once across many benefit programs;

  • Receive services within a week of providing all necessary information.[9]

Developing concrete customer service goals and building them into the formal requests for proposals from contractors can help state staffers and vendors share a clear vision for success and work as partners to achieve it.

Create low-risk ways for teams to try new things

Changing software procurement processes can be unsettling to state workers, so agency leadership should explain the reasoning behind the updates.

Leaders should start with a small procurement project — perhaps a contract worth $1 million or less, that is well defined and not crucial. Make clear to the agency team that it’s an experiment. They should be told to follow the new procedures and document what works and what doesn’t. 

If they follow the prescribed model, there is no way to fail. That is, if the vendor isn’t performing and the agency needs to end the contract early, that’s a success because they avoided wasting money. If the vendor does perform, as determined by ensuring that the software is solving user needs at every step, that’s also a success.

These commitments should be considered:

  • Make clear within the organization that a team will be trying new things. Leaders should consistently show support. If new oversight procedures show that no contractors’ proposals are acceptable, the team should be loudly praised for having identified that. If the new process determines that a vendor’s work is poor and that contract is terminated, the team should be praised for that too.

  • Start early. Ask for a review of procurement rules and major problems right away. Also request a review of state laws and regulations that would let an agency change its procurement process.

  • Declare early and often that decision-making will be steered by the needs of customers, as identified by research. No funding proposal should be considered without documented research about what a system’s users need. Solicitations for bids from contractors on software projects should include a statement of objectives and data about user needs that the software is to address.

  • Push agencies to work together and share data and systems where possible to make related constituent experiences and save money.

Map the existing technology procurement process

A journey map — a visual tool that illustrates a procedure step-by-step — is a powerful way for an agency to understand procurement as state staff and vendors experience it. At each stage, it displays what an individual does, whom they interact with, the time involved and any roadblocks. An example of a journey map created by U.S. Digital Response of families applying for child care services can be found here

The procurement process consists of a web of forms, reviews and approvals. A journey map can help identify problems like common points of confusion, bottlenecks and unnecessary duplication. States can use this information to pilot changes that streamline processes and reduce friction.

Vermont used journey mapping in 2018 to understand its procurement process for its Integrated Eligibility and Enrollment Program, which upgraded its technical systems for health care and other services. The exercise included procurement officials from relevant agencies and program staff, technology specialists and lawyers. Through this exercise, the team piloted a new, more agile procurement process for smaller technology contracts that let Vermont move from soliciting bids from vendors to a contract in 90 days. It is not uncommon for government procurement cycles to take 9 to 12 months or more. 

States with digital services teams, like Georgia and New Jersey, can turn to them for assistance with journey mapping. States without those teams can contact groups like Code for America and U.S. Digital Response for help. There are also web-based tutorials like NYC Service Design Studio’s guide to user journey mapping.

Transforming state procurement processes can take years. By starting with steps that can be accomplished quickly, a state can demonstrate meaningful improvement to staff and vendors early on. It can then use the momentum to focus on other, longer-range improvements.


The first step for changing procurement processes is gaining support from state and agency leadership. This includes agency leaders, senior procurement officials and legal offices, including both appointed officials and career staff. It may include the legislature, particularly budgeting and oversight staff. There is likely to be a well of frustration with existing procurement processes that can be tapped to create support for improvements. But experienced hands may be skeptical of change, having encountered past plans to “fix procurement.” This time, state leaders should start small, experiment and double down on what works. 

Special attention will be needed by procurement professionals deeply familiar with the complex ways that states purchase technology and services. These experts are invaluable partners for innovating and making sure contracts improve how the government works. Their involvement can help ensure that changes comply with laws and regulations. Best in class states empower procurement professionals as partners in innovation

In the first 200 days of 2023, states have an opportunity to create the partnerships and support that procurement leaders need to think outside of the box and lead on modern approaches.

Elevate a chief procurement officer who understands modern technology and brings a spirit of innovation 

Procurement professionals possess a deep familiarity with the complex practices and policies that govern the way states purchase technology and technology services. These experts are invaluable partners in efforts to incorporate innovative methods and steer government purchasing toward improved outcomes. 

However, procurement leaders often exist in a compliance-first culture, asked to enforce myriad outdated rules. A transformation in the way states deliver services will require procurement professionals to be at the table — not as enforcers, but as enablers of change.

The most effective chief procurement officers have credibility within the procurement community and a respect for procurement processes. They help elevate the role of procurement within the state agency. Importantly, they also:

  • Recognize and embrace the need to experiment with new approaches;

  • Understand the costly shortcomings of current practices;

  • Approach their role with a collaborative, customer-centric mindset;

  • Work to build trust across agencies.

If this person does not have experience with modern technology, then they should be paired closely with a technology leader who does. This could be the state’s chief technology officer.

Engage procurement experts in project planning early

Procurement officers often have a reputation for being blockers to innovative procurement approaches. This is in part due to the compliance culture that permeates procurement teams. But it is also because procurement is not often involved in technology strategy conversations. Instead, they are brought in at the final stage when it is time to issue a request for information (RFI), request for proposals (RFP), or request for quotations (RFQ). At that point, it is difficult for a procurement officer to offer alternative approaches that may improve the chances of success. 

Instead, procurement officers need to be involved at the strategy stage — while teams are forming high-level goals for a project or initiative. This involvement allows procurement experts to play an advisory — rather than a compliance — role. It also helps them understand the goals and constraints of the project from day one, allowing them to be partners in thinking through how to overcome obstacles and set up projects for success. 

For example, a procurement lead was the first hire for the State of Colorado Digital Service, beyond the director and the deputy. Not only has this role helped ensure that procurement expertise is engaged from day one, but it also helped influence other areas outside procurement that have a significant impact on success, like legal and fiscal factors.

This kind of tight collaboration allows teams to build mutual trust and a shared language about process and risk. As a result, procurement teams can:

  • Better understand project goals;

  • Explain the intent of procurement rules;

  • Ultimately support procurement processes that will be most effective at reducing cost and building or identifying products and services that meet users’ needs.

And in turn, innovation teams can:

  • Develop a better understanding of the procurement process;

  • Appreciate the valid reasons behind its complexities;

  • Navigate the process more effectively.

Include program leaders in presentations about software improvements 

Leaders are accustomed to receiving reports that projects are going well, then learning that everything is going terribly and always has been. It’s important that instead of reports, leaders are shown demonstrations of live, functioning software. This can be done by inviting them to join “sprint reviews,” presentations run by software development teams every two weeks. It’s important that they join periodically to show support for the project and learn how they can track progress.

At least every two weeks, project teams should send “ship reports” providing updates about what the project has accomplished since the last report, upcoming work and potential stumbling blocks. These reports should go to the highest level of leadership that is willing to review them. They should occasionally respond with short comments or suggest ways to resolve problems so the team understands that their work is valued. 

Train leaders so they can understand what is being asked of staff

It is not enough to ensure that procurement teams include staff who understand modern technology, or for technology teams to comprehend procurement and for everybody to appreciate the importance of user research. Leaders should also understand these areas. Require them to receive basic training in user research and modern software development and contracting practices, like agile. This will help leaders understand why they must not demand specific plans for works still in progress or try to substitute their preferences for the identified needs of end users.


Traditional procurement methods for expensive software projects require years of work before a contract is even signed. The largest government technology projects are often the most likely to fail because they rely on antiquated procurement processes and focus on whether contract requirements are being met, not whether the upgrades help customers. Hundreds of millions of dollars of projects are already queued up when a new governor takes office. If those projects fail, the current governor will be blamed, not the prior one. At the beginning of an administration, it is wise to review current software procurement projects, whether they’re nearly completed or just starting.

A review of these projects should be led by an executive leader who has a deep understanding of modern technology and who has a successful track record of delivering software and negotiating vendor agreements. The review should produce a list of contracts that are at risk of failure, and each should be reevaluated for modification or termination.

Take advantage of existing federal research and resources 

The “de-risking guides” from the U.S. General Services Administration’s 18F program, which provides technology advice to federal agencies and states, are invaluable resources for improving budgeting, oversight and procurement of custom software projects. Documents such as the Defense Department’s Guide to Detecting Agile BS and 18F’s Agile Software Solicitation Guide can help states understand and apply best-practice language and norms to technology contracts. States can also learn from programs such as the federal 10x funding program, which solicits suggested technology improvements from federal workers and develops them as models for fostering innovation.

Define the procurement strategy and standards by which projects will be reviewed

It is important to understand what strategy the state is currently using to procure software and to determine if and how it needs to be modernized.

A contract’s success is typically measured by whether it is completed on time and on budget. While these criteria can be important, they omit the crucial question of whether the software meets users’ needs. Every contract should stem from rigorous research on what users’ problems are and whether the contract, when executed, will solve them. 

The General Services Administration’s “de-risking guides” for states provide a helpful set of initial questions to evaluate projects.

At a minimum, the review should examine:

  • Which user needs the software addresses;

  • Contract cost and timeline;

  • The need for state workers to support the software and their level of experience;

  • How frequently vendors demonstrate working software that can be tested by state staff;

  • How quickly information learned during user research and testing gets incorporated back into a software product;

  • How frequently code is tested (included security) and deployed, so it can be used by the people who need it.

These project standards should be public, because transparency is critical for building trust.

Take a hard look at contracts up for extension or renewal

Contracts reaching their ends are at the perfect point for review. There should be ample evidence that they long ago delivered value to their users. Any major software development contract that a project team intends to renew or extend should be studied for how well it is working. If it does not meet best-practice criteria, the contract should not be renewed, or the need for it should be reevaluated. Modern software procurement language should replace whatever provisions led the previous contract to fail. 

Best practices rules for reviewing contracts up for renewal include:

  • Avoid the sunk cost fallacy — a reluctance to abandon a failed strategy that has cost a substantial investment. Don’t throw good money after bad to save a system that was built without adequately considering users’ needs.

  • Do not extend any contract that isn’t centered on continually upgrading software that addresses users’ needs.

  • Do not extend any contract that doesn’t clearly state goals for serving users, which lets a project team know what the objective is.

  • Encourage opportunities to break work into smaller components, where vendors are rewarded for improving customer experience in increments. This also gives the state flexibility to alter or end the arrangement if it is not meeting those goals.

Include someone on the review team who is familiar with the state’s budget cycles to help the team understand how quickly technology can be purchased. This can reduce the risk that procurement cycles will slow down priorities for the first 200 days. It also helps avoid missing deadlines needed for a state legislature to provide funds or update regulations.


Improving procurement outcomes is a multiyear investment. Beyond an administration’s first 200 days, there are longer-range, systemic changes that can help transform the state’s procurement approach for the long term and improve how the government delivers services digitally.


Using a prequalified vendor pool is one way a state can speed up the contracting process before a critical need arises. As a part of this approach, states competitively award master contracts to a pool of technology vendors and negotiate base agreements for certain skills and services. Vermont is one state that has used this approach to speed up contracting for small technology projects. When an agency has a technology project need that can be filled by vendors in the pool, it submits a statement of work (SOW) to the prequalified pool. The state selects a vendor from the pool after a short bidding process and the SOW is quickly approved. Because the base contracts have been prenegotiated, the contract does not get hung up in traditional approval processes or contract negotiations for months before work can begin. 

States can also use GSA’s Cooperative Purchasing program (formerly Schedule 70) to buy software and hardware more cheaply than if they negotiated them on their own. 


Improving the diversity of vendors a state can turn to, can save money and improve outcomes by encouraging greater competition. A leader looking to use software procurement to improve service delivery must not expect new results from the same vendors.

States generally have requirements that help small businesses and companies operated by people from disadvantaged communities get contracts. States can do other things to increase supplier diversity:

  • Perform deeper research into how vendors get procurement contracts. Consult the procurement journey map, ask people from small and disadvantaged businesses about their problems and address their issues.

  • Increase the simplified procurement threshold for small and disadvantaged businesses. This is the dollar amount below which there is a streamlined process for getting a contract. Some states have not increased this threshold to adjust for inflation for decades. New York’s $20,000 ceiling was raised to $150,000 in 2017 and then to $500,000 in 2019. This means that agencies can buy software rapidly while awarding more contracts to small and disadvantaged businesses.

Further reading: “For Diversity, Equity, Inclusion, and Accessibility in Government, Update Procurement Policies,” from Reconceptualizing Public Procurement to Strengthen State Benefits Delivery and Improve Outcomes.


Creatively improving how procurement works can save time and money and help an administration deliver on policy priorities successfully. To do this, teams need staff and training. Before rolling out big changes, try them with a small test project first.

One example comes from how Washington state awards primary and secondary contracts. If the primary contractor is not meeting expectations, Washington does not have to solicit new bids. Instead, it can switch to a secondary contractor it has lined up. See other ideas from the Tech Transit Lab.

It’s not enough to talk about working differently — procurement and technology staff must be trained to use the improvements. Procurement staff working on technology contracts should be familiar with modern technology principles and practices, like DevOps, human-centered design and product management. Technology staff should be taught about procurement, including how the state seeks bids for custom software and how contracting officers measure contract effectiveness. Only when each group understands the other’s work can they work together effectively. 

Find and train promising workers who are eager to expand their knowledge. This can help leadership build support from staff and improve workers’ understanding of the complexities of existing programs. 

Staff may not be interested in this training or assume they do not have time for it. After all, it is not obvious that a contracting officer should be trained in software development. Leaders should encourage attendance and go to the sessions themselves.


What to read?