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

—Jason Bloomberg, ‘Fixing Scheduling with Agile at the VA.’ Forbes

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 customers were getting what they wanted. That was the basis of the contract with the systems provider. But these early requirements and design decisions constrained teams, 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 an Agile Contract approach, the ‘SAFe Managed-Investment Contract.’

Details

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.

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

On the surface, this makes sense. In addition, it provides an opportunity for competitive bids, which may be required in many cases. In theory, 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 understood, far in advance of implementation.
• The buyer’s needs must be reflected in requirements specifications and early design details. This triggers Big Design Up-front (BDUF), waterfall-based development and waterfall-based contracts.
• The contract is typically awarded to the lowest-cost bidder, who may not provide the optimal long-term economic value for the buyer.

Moreover, in order to get a fixed bid, critical decisions are made far too early, when the least amount of knowledge about the solution is known (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 significant 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 of approaches shown in Figure 1. But the time and materials agreements 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 the 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 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 phase-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. The 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 endpoint 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 suppliers are building the right thing, in the right way. Ideally, it provides regular and objective governance for the buyer, and yet allows suppliers 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 all parties in both the short- and long-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 supplier near-term confidence of funding and sufficient notice when funding winds down or stops
• Motivate all 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 approach, where the economics benefit both the buyer and the supplier. The ‘SAFe managed-investment contract’ represents one such approach, as described below.

Pre-commitment

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.

During pre-commitment, 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 potential supplier(s).

The supplier does their initial homework as well. This often includes the 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 personnel and resources that will be required over the initial contract periods and a rough cost estimate.

The shared responsibilities, illustrated in Figure 3, start the customer and supplier toward a more measured investment, 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 Program Increment (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 PI 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

After the contract is awarded, development begins, as is illustrated in Figure 4.

A description of the activity timeline follows:

• PI 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 the first PI planning is part of the pre-commitment phase, though this route clearly requires significant investment by both parties.)
• PI planning – The first PI planning event influences the entire program. There, customer and supplier stakeholders plan the first PI in iteration-level detail.
• PI 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 the 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. Solution progress and program improvements are assessed during the Inspect and Adapt (I&A) event. At this point, the customer may decide to increase, decrease, or maintain funding levels, or even begin to wind down the initiative 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 used to illustrate how major product development investments are managed with sound, Lean economics.

This Lean Startup 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’ cycle described in the Epic and Continuous Delivery Pipeline articles.

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 the number of option periods consisting of one or more PIs. The goal is to optimize the delivery of prioritized features within each PI.

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

Learn More

Last update: 16 December 2021