guidance-icon

. . . 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 Abstract

Builders of large-scale systems must continually align with Customers and other stakeholders on what is being built. And they must do so in the midst of frequent and continuous changes. For example: discoveries made during development, evolving customer needs, changing technologies, and competitors’ innovations. Traditionally, requirement and design decisions were made up front to ensure that the Customer was getting what they wanted, and that was the basis for the contract. But these early requirements and design decisions constrained systems builders and reduced their ability to adapt to emerging information that could have helped them design a Solution that delivered better economic and competitive value for their Customers. The contract held them back. Thus the attempt to manage risk via early requirement specificity often backfired, to the detriment of all stakeholders.

To avoid this problem, other contract approaches evolved, with more shared risk and reward, and they worked better in many cases. Even then, however, the legacy thinking of fixed requirements tended to influence agreements and expectations.

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

Details

Traditional Approaches to Systems Building Contracts

Traditionally, enterprises have used a variety of approaches to work with vendors in the outsourced procurement of complex systems. Generally, there is a continuum of approaches that range from “firm fixed price” to “time and materials,” with almost every point in between. Figure 1 characterizes these various approaches, and the means by which risk is shared between the parties.

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, there is almost certainly an understanding 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, which are common in industry today. The convenience of this approach is the assumption that the buyer 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”

That makes sense on the surface. 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 should go to the supplier with the highest degree of competence and efficiency.

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 BUFD, waterfall-based development, and waterfall-based contracts.
  • The contract is typically awarded to the lowest-cost bidder. That may or 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. But as facts change, both the buyer’s and supplier’s hands are tied to the contract, which now defines a thing no one wants to build or buy exactly as stated. Much of the rest of the time is spent negotiating contract changes, and there is much waste in the process.

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

  • It is to the buyer’s short-term benefit to get as much out of the supplier as possible, for as little money as possible
  • It is in the supplier’s best interest to deliver the minimum value necessary to meet the contractual obligations

The net result is that the contract type 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

Given the above, it’s clear why many in the industry want to move to the right on the spectrum. But the far right, time and materials—which might appear to be extremely Agile on the surface—has its challenges as well. The buyer has only trust to count on. Trust is a precious commodity indeed, and we lean 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. And after all, it’s in the supplier’s best economic interest to keep being paid for as long as possible. This can drag contracts out longer than necessary. Coupling this approach to 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, will likely creep into these agreements and expectations. What’s needed is a different approach, one that “trusts but verifies” that the system builders are building the right thing in the right way, provides regular and objective governance for the buyer, and yet allows allows systems builders to have confidence in their customers as well as in implied future economic commitments.

Characteristics of such an Agile contract type 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 fixed versus variable requirements and adaptive response to new knowledge
  • 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
  • Provide the system builder with 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

Given all of the above, the industry can benefit by moving toward a more Agile contracts paradigm, one where the optimum economics benefit both the buyer and the systems builder. The Lean-Agile constructs in SAFe can provide one such approach, the SAFe Managed-Investment Contract, which is described below.

Precommitment

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 precommitment phase, illustrated in Figure 3.

Figure 3. SAFe Managed-Investment Contract precommitment phase
Figure 3. SAFe Managed-Investment Contract precommitment phase

During this phase the Customer has specific responsibilities, including understanding the basic constructs and responsibilities 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 maybe even a rough cost estimate. However, these responsibilities are largely routine, and they can be assumed for the most part.

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:

With respect to the PI funding commitment, in some cases the Supplier may need to provide a preliminary estimate for completion. In other cases, a pay-as-you-go approach may be suitable. Based on the agreements, the Customer will agree to fund the Supplier at certain rates for the early PIs. This is the initial commitment period. The length is based on context, but two PIs or so (20 weeks) may be a reasonable starting point.

Depending on context, the Customer may have such discussions with multiple potential Suppliers. If significant technical feasibility is involved, this can often be done under some form of feasibility contract, whereby the Supplier is compensated for the efforts to get to commitment. Alternately, this may be simply business as usual for the Supplier, with these precommitment investments a part of normal presales.

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
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 precommitment phase, though this route clearly requires significant investment by both parties.)
  • PI 1 planning. The first PI planning event is seminal to the 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; as a minimum, however, direct Customer engagement is usually required for each System Demo. For large Value Streams, 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 for the next PI are made. The Inspect and Adapt session is used to assess progress and to plan improvements for the upcoming PI. At that point, the Customer may decide to keep funding steady state, to increase it, or to decrease it—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 input scope based on the outcome of that decision.

This process continues until the Solution has delivered the value the Customer requires, at which point the Customer starts winding down Supplier funding commitments in accordance with the agreement.


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: 15 December 2015