. . . 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
Builders of large-scale systems must continually align what’s being built with the wants and needs of customers and other stakeholders. Moreover, 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 the goal of ensuring customers were getting what they wanted. That was the basis of the contract with the systems provider. Unfortunately, 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 backfired, to the detriment of all stakeholders.
To avoid this, other contract approaches evolved, characterized by more shared risk and reward. In many cases, they worked better. Even then, however, the conventional thinking of fixed requirements tended to influence agreements and expectations.
What is truly needed is a more Agile approach to contracts, one that benefits both parties in the near and long terms. This chapter describes the current state and then provides guidance for an Agile Contract approach, the ‘SAFe Managed-Investment Contract.’
Buyers often outsource complex systems development to suppliers who have the ability to build the kinds of systems that buyers need to run their business. There’s a continuum of approaches to contracting, ranging from firm fixed price to time and materials, and almost every point in between. Figure 1 characterizes these various approaches and highlights the means by which the parties share risk.
Clearly, a wide range of approaches to contracting exist. In general, however, most everyone understands that neither extreme delivers the best overall economic value, as discussed in the following subsections.
On the left end of the scale in Figure 1 are firm-fixed-price contracts, which are quite common in the industry today. The convenience of this approach derives from the assumption that buyers will get exactly what they want and are willing to pay for, as Figure 2 illustrates.
On the surface, this contracting approach makes sense. It also provides an opportunity for competitive bidding, which may be required in many cases. In theory, competitive bidding can potentially provide economic advantages, as the winner of the bid will be 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, 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. If facts subsequently change, both the buyer’s and the 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 best short-term interest to get as much out of the supplier as possible, for as little money as possible
It’s in the supplier’s best short-term interest to deliver the minimum value necessary to meet the contractual obligations and maximize its own 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.
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 organizations. 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 to other concerns. 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 be known only 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].
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 the right end of the scale—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, 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 terms
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 in funding and sufficient notice when funding winds down or stops
Motivate all parties to build the best solution possible within agreed-to economic boundaries
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.
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 the 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 its 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 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. The length of this initial commitment period depends on context, but two PIs or so (20 weeks) may be a reasonable starting point.
Depending on the context, the customer may have discussions with multiple potential suppliers. If technical feasibility is a significant question, it can often be addressed under some form of feasibility contract, whereby each potential supplier is compensated for the efforts to get to commitment. Alternatively, it 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.
After the contract is awarded, development begins, as illustrated in Figure 4.
A description of the activity timeline follows:
PI preparation – Both supplier and customer invest some time and effort in preparing content and logistics for the first PI planning session. Note that in some cases, the first PI planning might actually be 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. During this event, customer and supplier stakeholders plan the first PI in iteration-level detail.
PI execution – Depending on the context, customers participate at various levels in iteration execution. At a minimum, direct customer engagement is usually required for each System Demo. For large solutions, 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.
The Lean Startup Cycle (shown in Figure 5) is also used to manage major product development investments while ensuring sound, Lean economics. This 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 chapters.
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 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 that 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 spending 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
[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. https://www.slideshare.net/JEMILOD/agile-contracts-by-drew-jemilo-agile2015.
