Guiding principles of an agile procurement

Both the U.S. Digital Service and 18F provide great overviews of the principles that guide general agile procurement: TechFAR Hub and De-risking custom technology projects. These principles typically fall into the following areas, and each one is fundamental for an agile procurement strategy:

• Keep procurements small and quick
• Buy digital service skillsets, not software
• Embrace a one-team, one-dream mindset

USDS’ principles of procurement are a great launching point for an agency contracting specialist who’s rethinking traditional procurement approaches. The goal is to mirror the procurement process after the way software is delivered in an agile format. For contracting specialists, this means focusing on procuring skillsets that can build software.

How it differs from other procurements

An agile procurement strategy is distinct from other procurement strategies, such as the common waterfall strategy, in these primary areas:

• Size of the contracts being awarded
• Time it takes to award contracts
• Level of early involvement from product stakeholders
• Expectations and timing for requirements gathering

Because contracts are modularized and smaller, it’s essential to have input from the product team (research, design, product, engineering) right from the start to ensure the objectives for each contract are well known. In agile procurement, no one department or stakeholder can function as a silo.

The approach to requirements gathering is also fundamentally different. An agile procurement strategy recognizes that:

• The team’s understanding of the product will develop as the product is being built
• This growing understanding can inform the requirements for the current and subsequent modular contracts

Therefore, the procurement team doesn’t attempt to have all of the technical requirements defined up front. An agile procurement strategy relies on the team having a greater understanding of the product as the product is being built; that new knowledge can be turned into contractual requirements for a modular contract.

Modular contracting

The process of modular contracting matches the natural work streams that arise out of building a product. Let’s use an example to explore the differences between traditional and agile procurement approaches.

Requirement: Move significant portions of DMV services online

Traditional procurement approach:

• Gather 100% of the requirements up front
• Write a Statement of Work against the gathered requirements
• Award the contract to a single prime contractor that could have multiple subcontractors underneath them
• Set a long initial period of performance in which the vendor should deliver working software at the end of it

Agile procurement approach:

• Recognize the complexity of the task (moving DMV services online)
• Identify the different components necessary to accomplish the goal — things like cloud infrastructure, research and design, and back-end development
• Break up the product into discrete parts as they become known, and use modular contracts to procure services against those

There are many benefits to using a modular contracting strategy:

• The government isn’t dependent on a single prime vendor to deliver services
• The period of performance can be shortened to protect the government, since it’s much easier to replace an underperforming vendor for a single component than it is to replace an all-encompassing contractor
• It results in a pool of expert vendors for the product being built, broadening the options available for contracting out new work
• Vendors have to focus on delivering working software in a shorter timeframe, providing tangible benefits much sooner

Of course, with any procurement approach, there are drawbacks. The approach requires a higher level of management effort, since the government will need to:

• Manage more contracts
• Provide strong coordination/leadership to orchestrate the different contracts and vendors on the product
• Involve more people to manage the extra moving pieces introduced through modular contracting.

Vendor lock-in risk mitigation

Traditional procurement cycles for waterfall software development typically require a significant initial investment in both time and money before any working software is delivered. It may even be years before any software is delivered, with the added risk of the software behaving differently than initially expected or not working at all.

This frontloaded time investment — combined with the lack of visibility into the development process — may put the government in a difficult position when the time comes to evaluate the completed software. If the end product doesn’t effectively address users’ needs, the government is on the hook for the resources that have already been sunk into the project.

The smaller, shorter contracts in an agile procurement strategy reduce the government’s risk. With shorter contracts, the period of performance is decreased and the vendor needs to produce value to the government much more rapidly. If the government feels that the vendor’s products aren’t meeting expectations, the government has the flexibility to not extend any option periods.

How to know you’re ready for agile procurement

Testing out or adopting a new procurement strategy takes buy-in and support from a variety of stakeholders. This environmental buy-in is no different for agile procurement. If you’re considering an agile procurement strategy for an upcoming product, these questions can help determine whether the agency is ready:

• Do you have examples of when the current procurement strategy didn’t support a product’s chances of success?
• Is the upcoming product for development risk (for example, high budget, mission-critical service, long development timeline)?
• Does the current procurement strategy help mitigate the risks in product development and delivery?
• Does the current procurement strategy contribute to the probability of success for the product?

By conducting an analysis of alternatives on the different procurement options for a particular product, the product team can involve stakeholders in the decision-making process and increase buy-in if the team opts to test out a new strategy.

As with trying out any new method, start small. This will allow stakeholders to become comfortable with the new process and way of procuring services. Once you have some experience and more buy-in, you can scale up to larger initiatives.

Because procurement is such a vital part of the government’s ability to provide services, changing the current culture of procurement is a long game and not something that can happen overnight. Culture change can be hard, but the effort is worth it given the potential to de-risk service or product delivery by changing how it’s procured.