What Does Outcome-Based Contracting Require in Federal Government?

The federal government is finally shifting from buying activities to buying outcomes. I’ve been making this case since I co-founded Kessel Run, the Department of Defense’s first software factory, in 2017. The report from the IBM Center for the Business of Government and the Commerce & Contract Management Institute, “Outcome-Based Contracting in U.S. Government: From Policy to Performance,” is one of the most substantive pieces of research on this topic to date.

Authored by Daniel Finkenstadt and Tim Cummins, the report walks through what’s broken in traditional federal contracting and what outcome-based contracts (OBCs) need in order to work. The shift the report is responding to is overdue. The Revolutionary FAR Overhaul, Secretary Hegseth’s software acquisition memo, and the new FAR Companion Guide language on outcome-based approaches are all pointing in the same direction.

The intent is right. The frameworks emerging are mostly right.

But intent and frameworks won’t survive contact with the bureaucracy unless the workforce, the contracts, and the delivery capability all match the policy. That’s where most outcome-based contracts will get stuck. And that’s where the report’s analysis is incomplete in one important way.

What the report gets right: five critical success factors

The report identifies five critical success factors that have to be in place for an outcome-based contract to function:

• Requirements — outcomes have to be defined in measurable, attributable terms before the contract is structured
• Data — you can’t pay for outcomes if your data systems can’t attribute results to contractor performance
• Trust — outcome-based relationships only work when buyer and supplier can rely on each other to manage their own side
• Governance — outcomes require collaborative, adaptive governance, not rigid clauses
• Oversight — outcomes need metrics that measure what users actually do with the software, not just what’s been delivered

Each one breaks the contract if it’s missing. Finkenstadt and Cummins are right to flag them.

The report’s framing of contracts as “value architecture” is also correct. Every requirement, every incentive, every payment term, every metric is a statement about what matters. When the contract’s incentive structure encodes the wrong priorities, the program drifts toward those priorities even when the actual mission is something else. The contract becomes the plan, and the plan becomes the failure.

The five factors are necessary. But they aren’t sufficient.

The first gap: the program has to be able to ship

Here’s the question the report doesn’t ask directly. Can the program actually get software to users?

Outcomes only exist when users use the software. If the program can’t get software to users, there’s nothing to measure. Nothing to pay for. Nothing to be on the hook for. The whole framework of outcome-based contracting assumes the existence of a path to production that works.

Continuous delivery is the precondition that decides whether the rest of the framework matters. Real continuous delivery means code shipping to users on a rapid cadence. Metrics that show what’s happening in production. Feedback loops that close in hours or days, not quarters. Authorization to operate that runs alongside development, not after it.

Without real and continuous delivery underneath the contract, outcome-based contracting becomes “a relabeled fixed-price model rather than a transformative contracting approach” (the report’s own warning). And that warning understates the risk. Most outcome-based contracts will fail this way unless they sit on top of real delivery capability. We will say outcome = checking off all the requirement specs, instead of outcome = operations metrics.

The good news: delivery capability is buildable. Programs that don’t have continuous delivery today can establish it. They can build it internally. They can partner with a contractor who brings it. They can adopt a platform-as-a-service that comes with the path to production already paved. The work is well-understood. The patterns exist. What it requires is treating delivery capability as the precondition for the contract, not an output of it. Unfortunately, enterprise paths-to-production are not outcome-driven and are virtually unusable as it relates to modern, continuous software delivery.

The second gap: governance has to go both ways

There’s another piece the report touches on but doesn’t emphasize enough. If you put a contractor on the hook for outcomes, the government has to commit too.

The pattern in outcome-based pilots is predictable. The contract gets signed with outcomes on the contractor side. Then the government’s normal habits kick back in. Activity-level oversight gets reinserted. Authorizing officials slow-walk approvals. Decision-makers stop showing up to the workshops and demos. Cloud accounts take six months to provision. The recommended path to production gets vetoed in favor of an in-house alternative that doesn’t work.

The contractor is still on the hook for the outcome. But the government has effectively taken away the conditions that make the outcome possible.

Outcomes are co-produced. You can’t write that responsibility one-way and expect it to hold.

The fix is two-sided governance. Specific, time-bounded ‘shall’ statements for the government, too. For example:

• Shall grant GFE, clearances, and credentials within 2 weeks of valid request
• Authorizing officials and control assessors shall respond to submissions within 72 hours
• Shall not mandate a path-to-production without SLAs, or switch it mid-contract
• Decision-makers shall attend the meetings the engagement requires
• Shall mutually agree to outcomes and shall not dictate activities and outputs

These aren’t optional. Without them, outcome-based contracting is one-sided. And one-sided outcome-based contracts fail the same way every time.

The conditional guarantee model

Going forward at Rise8, we won’t take an outcome-based engagement without those terms in the agreement. We are launching a conditional guarantee.

Here’s how it works: we commit to a mission outcome in production within 180 days. The government commits to the conditions that make 180 days possible. If we miss the 180-day mark, we work for free until we hit it. If the government misses its commitments, the timeline resets accordingly.

This isn’t a clever contract trick. It’s an acknowledgment of how outcomes actually work in complex systems. The contractor brings the engineering, the design, the platform, and the path to production. The government brings the mission problem, the access, the authorities, the operating environment, and the people whose decisions move the work forward. Both are required. Both have to hold up their side.

The conditional guarantee model addresses both gaps the report’s framework leaves open. It bakes continuous delivery into the offer (Rise8 brings the platform and the path to production with continuous Authority to Operate). And it bakes two-sided governance into the contract (the ‘shall’ statements on the government side are written into the agreement before work begins).

This is one model. There are others. The point isn’t to mandate any specific structure. The point is that outcome-based contracts only work when both gaps are closed.

What this means for federal acquisition leaders

If you’re a federal acquisition leader looking at outcome-based contracting, here’s what I’d say. The shift is right. Don’t resist it. But before you sign an outcome-based contract on a program, ask these questions:

• Is there a working path to production—either in the program today or brought by a contractor who has shipped to production before?
• Are you willing to write your own commitments into the contract?

If the answer to both is yes, you’re set up for an outcome-based contract that can deliver. If the answer to either is no, address that first.

The work ahead

The IBM Center / CCM Institute report is a real contribution. Finkenstadt and Cummins have written a substantive piece, and the recommendations the report makes are the right next steps for federal policy:

• Elevating outcomes to the requirements stage, before contract structure is selected
• Expanding OBC guidance beyond FAR Part 37 to FAR Parts 2 and 16
• Investing in workforce governance training, not just contract management
• Building a portfolio prioritization schema for outcome-based strategy
• Piloting through low-risk option mechanisms

These are good. They’re necessary.

The work now is making sure the execution matches the intent.

Frequently asked questions

What is outcome-based contracting?

Outcome-based contracting (OBC) is a contracting model that ties payment to measurable mission results rather than activities, hours, or deliverables. The new FAR Companion Guide defines it as “a variation of performance-based contracting that emphasizes delivery of specific, defined outcomes through a collaborative, adaptive performance framework, rather than transactional delivery of specified services or products.”

What does the IBM Center for the Business of Government report on outcome-based contracting say?

The April 2026 report, authored by Daniel Finkenstadt and Tim Cummins, identifies five critical success factors for outcome-based contracts: requirements, data, trust, governance, and oversight. It also distinguishes outcome-based strategy (the broader approach to mission delivery) from outcome-based contracting (the specific contract structure), and recommends elevating outcomes to the requirements stage, expanding OBC guidance beyond FAR Part 37 to FAR Parts 2 and 16, investing in workforce governance training, building a portfolio prioritization schema for outcome-based strategy, and piloting through low-risk option mechanisms.

Why does continuous delivery matter for outcome-based contracts?

Outcomes only exist when users actually use the software. Continuous delivery is the technical capability that gets software to users on a regular cadence so outcomes can be observed, measured, and paid for. Without continuous delivery, an outcome-based contract is a long-horizon bet on assumptions that can’t be tested. The contract structure assumes a path to production that works, and most government programs don’t have one yet.

What is a conditional guarantee?

A conditional guarantee is a contract structure where the contractor commits to a specific mission outcome in a specific timeframe (e.g. Rise8 committing to a mission outcome in production within 180 days) and the government commits to specific conditions that make the timeline possible: e.g. GFE, clearances, and credentials within 2 weeks of a valid request, authorizing officials and control assessors responding within 72 hours, no mandated path-to-production without SLAs (and no switching it mid-contract), and decision-makers attending the meetings the engagement requires. If the contractor misses the deadline, they work for free until they hit it. If the government misses its commitments, the timeline resets accordingly. The model recognizes that outcomes are co-produced and writes both sides' responsibilities into the agreement.

How does the FAR Overhaul change federal contracting?

The Trump administration’s FAR Overhaul aims to give contracting officers greater flexibility, simplify procurement, and shift the federal acquisition system toward outcome-based and performance-driven approaches. The new FAR Companion Guide introduces outcome-based contracting concepts in Parts 11 and 37. The IBM Center / CCM Institute report recommends expanding OBC guidance to Parts 2 and 16 to position outcome-based approaches as a comprehensive contracting philosophy rather than a service-contracting technique.