Agile acquisition: Why it makes sense to plan from future backward

It is not uncommon in acquisitions of information technology that standard federal procurement practices fail to yield intended results. Often, the final product is quite different than what was envisioned at the beginning of the acquisition process.

Why?

Is it possible for the government to implement better acquisition practices that yield better results and still work within acquisition regulations?

The answer is yes, but current practices will not get us there.

The current system of Acquisition Planning-RFI-RFP-Q&A-Proposal-Contract Award-Implementation represents a staggering administrative cost due to the length of time and documentation required. The time and energy spent to develop these documents create burdens for both government or contractors. In fact, most programs are different after award (compared to the start of acquisition) due to changing circumstances and time delays.

Agile software development’s benefit is that it does not attempt to define detailed steps and requirements at the start. Agile allows (and expects) shifting end user needs toward the end-state vision. Thus, we recommend a “reverse planning” acquisition approach to start with envisioning the outcomes of a system and go backward to define tasks needed using collaborative methods instead of comprehensive documents. This approach lessens the most important risk — the risk that the purpose of the system being acquired will not be achieved. This process is also compliant with Federal Acquisition Regulations (FAR) and even encouraged by it (see how, in a Federal Acquisition Institute training video on the topic).

Reverse planning: Start at the end

Frequently, procurement and contract performance are disconnected. System acquisition would succeed more often if both were viewed as one holistic process from the end of a system’s life all the way back to the start of acquisition planning. The illustration below shows how it could work holistically, starting with a description of what the acquired solution should looks like when it’s operating successfully, not describing each step needed to put it in place. The contracting officer (CO), perhaps a CO designated as an agile expert, should actively engage throughout the contract life cycle, to ensure consistent pursuit of the end vision.

Reverse planning: Start with a vision, work backward

A reverse planning collaboration technique called “Remember the Future” will help. In it, participants imagine a future in which they’re using their envisioned system. Participants write down, from the perspective of every major stakeholder, what the system does to make them successful in achieving mission objectives.

The goal is not to perfectly define the required steps a vendor must take, but instead to define what the system’s contribution to program success should look like. A system requirements document is not the deliverable. Descriptions of system and program performance, user experience and business functions performed are the deliverables. For example, one such description could be: “The new system will reduce the time it takes to perform X process from Y days to Z days, which will save the government $A per year.”

Be ready to collaborate

Once future outcomes are clearly defined, innovative techniques can further the likelihood of success starting at the earliest phases of procurement planning. Imagine the government project team (including the CO) having a pre-solicitation conference and inviting any interested vendor to help them identify facets of that end-state vision. This is encouraged by FAR §15.201, which addresses exchanges with industry.

Also, one facet of the agile method is the “sprint” — a two-to-three week cycle when a specific, discrete and useable function of the system is the team’s focus. We recommend that one sprint serve as the basis for a fixed price, performance-based contract.

The government could require bidders to complete one sprint as the technical evaluation instead of a written proposal or oral presentation. (“Show me, don’t tell me.”) This would, of course, demand that a vision for the sprint’s result be well developed.

Bidders complete that distinct piece of the system using their choice of project team. The government then evaluates the value, and performs user acceptance testing (UAT) to determine software quality based on “Sprint 0.”

The government would benefit from seeing a vendor’s work product, not just reading or hearing about it. Furthermore, bidders would be able to review the level of effort and team capabilities that were needed, and thus be able to set pricing more accurately.

Best value will be clearer based on “Sprint 0” delivery by competing vendors. If one vendor created more or better features than others for the same price, an award decision will be easy and fast. And, that “Sprint 0” product from the winning team could be used to start building the actual system.

Sprint 0 is the proposal and the start of delivery

For agile acquisition to work, three changes must take place:

1. The government should recognize that it is not acquiring a system, but services. These services will produce a system that provides the greatest value to the government at contract completion.
2. Viewing the FAR as the gateway to success instead of a roadblock to innovation. The FAR actually encourages innovation – see FAR §7.102.
3. A system that doesn’t work (or is abandoned) is a greater risk than a vendor’s failure to comply with individual, detailed requirements. Once a contract is complete, if the government does not have a successful system, it has wasted time and money. The downside risk of using agile acquisition techniques is much smaller.

Several Government agencies are already focusing on innovation in their acquisition processes. DHS’ Procurement Innovation Lab and the U.S. Digital Service are at the forefront of this effort, vigorously promoting innovative changes.

Kevin White is director of contracts for REI Systems with experience in both government and commercial contracting. Gissa Sateri is a business development director at REI Systems with experience in operations and general management, capture management, strategic planning and IT consulting. Pawin Chawanasunthornpot is a solution architect at REI Systems who is passionate about the agile approach.

Copyright © 2026 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.