. . . select a winning contractor and then expect them to deliver on the requirements within the specified timeframe and budget. However, this traditional approach almost always led to failures—each a spectacular waste of taxpayer dollars.

—Jason Bloomberg, Forbes, Fixing Scheduling with Agile at the VA [1]

Agile Contracts

Builders of large-scale systems must continually align with customers and other stakeholders on what’s being built. And they often must do so in the midst of continuous changes driven by development discoveries, evolving customer needs, changing technologies, and competitor innovations.

Traditionally, requirements and design decisions were made up front with a goal of ensuring the customer was getting what they wanted. That was the basis of the contract with the systems provider. But these early requirements and design decisions constrained system builders, reducing their ability to adapt to emerging data that could have informed a Solution that could have delivered better economic and competitive value. In short, the contract held them back. Thus, attempts to manage risk by requiring early specificity often backfire, to the detriment of all stakeholders.

To avoid this, other contract approaches have evolved, with more shared risk and reward. In many cases they worked better. But even then, the conventional thinking of fixed requirements tends to influence agreements and expectations.

What’s needed is a more Agile approach to contracts, one that benefits both parties in the near and long terms. This article describes the current state, and then provides guidance for one such Agile Contract approach, the SAFe Managed-Investment Contract.


Traditional Approaches to Systems Purchasing Contracts

Buyers often outsource complex systems development to suppliers who have the ability to build the kinds of systems buyers need to run their business. There’s a continuum of approaches to contracting, ranging from “firm fixed price” to “time and materials,” with almost every point in between. Figure 1 characterizes these various approaches, and also highlights the means by which the parties share risk.

Figure 1. A range of traditional contract types
Figure 1. A range of traditional contract types

Clearly there is a wide range of approaches. In general, however, most everyone understands that neither extreme delivers the best overall economic value, as discussed in the sections below.

Firm Fixed-Price Contracts

On the left end of the scale are firm fixed-price contracts, common in industry today. The convenience of this approach is the assumption that buyers will get exactly what they want and are willing to pay for, as Figure 2 illustrates.

Figure 2. Firm fixed price contracts create the "iron triangle" contract
Figure 2. Firm fixed-price contracts create the “iron triangle”

On the surface, this makes sense. In addition, it provides an opportunity for competitive bids, which may be required in many cases. Competitive bids can potentially provide economic advantages, as the bid can go to the supplier with the lowest cost.

However, there are many downsides to this approach:

  • It assumes that the buyer’s needs are well known far in advance of implementation.
  • Those needs must be reflected in requirements specifications and early design details. This triggers Big Upfront Design (BUFD), waterfall-based development, and waterfall-based contracts.
  • The contract is typically awarded to the lowest-cost bidder, who may not be the highest long-term economic value for the buyer.

Moreover, in order to get a fixed bid, critical decisions are made far too early in the “cone of uncertainty” (see Principle #3 – Assume variability; preserve options). The parties have entered into the “iron triangle” of fixed scope, schedule, and cost, as illustrated in Figure 2. And if facts change, both the buyer’s and supplier’s hands are tied to the contract, which may now define something no one wants to build or buy exactly as was stated when written. Much of the rest of the time is spent negotiating contract changes, with much waste in the process.

Worst of all, once the agreement is entered, each party has an opposing economic interest:

  • It’s in the buyer’s short-term interest to get as much out of the supplier as possible, for as little money as possible.
  • Conversely, it’s in the supplier’s best short-term interest to deliver the minimum value necessary to meet contractual obligations and maximize supplier profits.

The net result is that this type of contract often sets up a win-lose scenario, which thereafter influences the entire business relationship between the parties, typically to the detriment of both.

Time and Materials Contracts

It’s clear why many would want to move to the right of the spectrum. But the time-and-materials agreements shown on the far right—which might appear to be extremely Agile on the surface—have their challenges as well. The buyer has only trust to count on. Trust is a precious commodity, indeed, and we depend on it in Lean. But misunderstandings, changes in market or technical conditions, and changes in buyer or supplier economic models can force trust to take a back seat. After all, it’s in the supplier’s best economic interest to continue getting paid for as long as possible. This can drag contracts out for longer than necessary. Coupling this approach with a stage-gate process, whereby real progress can only be known at the end, compounds the problem.

Challenges can exist on the buyer’s side as well. For example, when interviewed during a project postmortem, Stephen W. Warren, executive in charge and CIO of the Department of Veterans Affairs Office of Information and Technology, noted that “according to the project manager, ‘the project was never in crisis’ since they were spending the entire budget every year, and thus were able to renew their funding for the next year. Their measure of success at the time was whether the project would continue to get funding, rather than whether it was able to deliver the necessary functionality.” [1]

A Collaborative Approach to Agile Contracts

Since neither end point on Figure 1 provides much assurance, perhaps the range in the middle is the sweet spot? Possibly, but even then, the biases of traditional contracts—whether from the left or right on Figure 1—will likely creep into these agreements and expectations. What’s needed, then, is a different approach, one that “trusts but verifies” that the system builders are building the right thing in the right way. Ideally, it provides regular and objective governance for the buyer, and yet allows system builders to have confidence in their customers as well as in implied future economic commitments.

Characteristics of such an Agile contract would include the ability to:

  • Optimize the economic value for both parties in the long term as well as the short term.
  • Exploit variability via adaptive responses to requirements as new knowledge emerges.
  • Provide complete and continuous visibility and objective evidence of solution fitness.
  • Provide a measured approach to investment that can vary over time and stop when sufficient value has been achieved.
  • Offer the system builder near-term confidence of funding, and sufficient notice when funding winds down or stops.
  • Motivate both parties to build the best solution possible within agreed-to economic boundaries

SAFe Managed-Investment Contracts

Clearly the industry would benefit by moving toward an Agile contracts paradigm, where the economics benefit both the buyer and the system builder. The Lean-Agile constructs of the SAFe Managed-Investment Contract represent one such approach, as described below.


Prior to engaging in any significant investment contract for developing a complex system with many unknowns, some due diligence is required. In this case, the Customer and Supplier work together to come to terms on the basis of the contract. This is the pre-commitment phase, illustrated in Figure 3.

Figure 3. SAFe Managed-Investment Contract pre-commitment phase

During this phase the customer has specific responsibilities, including understanding the basic constructs and obligations of this form of Agile contract, and defining and communicating the larger program mission statement to the supplier (or potential suppliers).

The supplier does their initial homework as well. This often includes a first analysis of potential feasibility, and alignment of the buyer’s solution needs with the supplier’s core competence. It also demands some understanding of the potential resources that will be required over the initial contract periods, and a rough cost estimate.

The shared responsibilities in the middle, however, start the customer and supplier down a path to a more measured investment, one supported by continuous objective evidence of fitness for use. These responsibilities include:

  • Establishing the initial Vision and Roadmap
  • Identifying the Minimum Viable Product (MVP) and additional (PI) potential Features
  • Defining the initial fixed and variable Solution Intent
  • Prioritizing the initial Program Backlog for PI Planning
  • Establishing execution responsibilities
  • Establishing the Economic Framework, including economic trade-off parameters, the Program Increment funding commitment (number of PIs committed), initial funding levels, and other contractual terms

In some cases, the supplier may need to provide a preliminary estimate to secure the PI funding commitment for completion. In other cases, a pay-as-you-go approach may be suitable. Based on the terms, the customer will agree to fund the supplier for the early PIs. This is the initial commitment period. The length depends on context, but two PIs or so (20 weeks) may be a reasonable starting point.

Depending on context, the customer may have discussions with multiple potential suppliers. If significant technical feasibility is involved, this can often be done under some form of feasibility contract, whereby each potential supplier is compensated for the efforts to get to commitment. Alternately, this may be simply business as usual for the supplier, with these pre-commitment investments occurring as a normal part of presale activities.

At some point, however, the customer can move on to award the contract.

Contract Execution

Thereafter, development begins, as is illustrated in Figure 4.

Figure 4. SAFe Managed-Investment Contract execution phase

A description of the activity timeline follows.

PI 1 preparation – both supplier and customer will invest some time and effort in preparing content and logistics for the first PI planning session. (Note: In some cases, it might be suitable that PI 1 planning is part of the pre-commitment phase, though this route clearly requires significant investment by both parties.)

PI 1 planning – The first PI planning event influences the whole program. There, customer and supplier stakeholders plan the first PI in Iteration-level detail.

PI 1 execution – Depending on context, customers participate at various levels in iteration execution; at a minimum, however, direct customer engagement is usually required for each System Demo. For large solutions, however, the multiplicity of system demos may be replaced by a more fully-integrated Solution Demo, which can occur more frequently than at PI boundaries.

PI evaluation – Thereafter, each PI marks a critical Milestone for both the customer and supplier. At each milestone, the solution demo is held and the solution is evaluated. Agreed-to metrics are compiled and analyzed, and decisions are made for the next PI. The Inspect and Adapt (I&A) session is used to assess progress and plan improvements for the upcoming PI. At that point, the customer may decide to maintain funding levels, increase them, decrease them, or even begin to wind down based on whether sufficient value has or has not been achieved. Thereafter, the next PI planning commences, with the scope based on the outcome of that decision.

Managing Risk with the Lean Startup Approach

The Lean Startup Cycle shown in Figure 5 is also useful to illustrate how major product development investments are managed with sound, lean economics. This process model decreases time to market and helps prevent the system from becoming bloated with unnecessary features that may never be used. It also enforces the Hypothesize->Build ->Measure->Learn process described in the Epic and Continuous Delivery Pipeline articles.


Figure 5. The Lean Startup Cycle for managing large product development investments.

The implication is that Agile contract language is modified to reflect a combination of fixed and variable components. The MVP identified at the pre-commitment stage can establish a high-level definition of fixed scope to be delivered over a proposed number of PIs. Beyond the delivery of the MVP, the contract can also specify a number of option periods consisting of one or more PIs. The goal is to deliver as many additional Weighted Shortest Job First (WSJF) prioritized features as possible within each option time box.

This process continues until the solution has delivered the value the customer requires. At this point the customer stops exercising additional option periods and starts winding down funding commitments in accordance with the agreement. This provides the best of both worlds to customers:

  • Better predictability of estimates associated with a far smaller MVP than the full list of all requirements
  • Total control over the spend required for additional incremental features based on economic outcomes

Clearly such an approach provides the greatest economic benefit to both parties, which will help create stable, long term relationship.

Learn More

[1] Bloomberg, Jason. Fixing scheduling with Agile at the VA. Forbes. October 23, 2014.

[2] Jemilo, Drew. Agile Contracts: Blast Off to a Zone of Collaborative Systems Building. Agile 2015.

Last update: 17 June, 2017