# Agile Contracts with Service Providers: Collaboration Instead of a Requirements Specification

Author: Marin Niehues, Niehues Consulting · Published: 2024-05-27 · Delivery & Steering
Source: https://www.niehuesconsulting.de/en/blog/agile-contracts-service-providers/

Agile contracts with service providers set a product goal, a rhythm for delivery and acceptance and a ceiling on effort, and they leave the detailed scope open. They replace the requirements specification when requirements only become clear during the project. Which model fits is decided by three criteria: how clear the scope is, how strongly requirements change and how closely client and provider work together.

This article compares the common contract models, gives you a checklist for selection and describes how to steer the collaboration while the project runs. The drafting of a contract rests with your legal department and your lawyers. This article provides an overview and does not constitute legal advice.

**A contract with fixed scope and fixed price assumes that both sides know today what will be needed at the end. Where that does not hold, the fixed price moves the dispute into the change requests, and an agile contract gives the collaboration a framework for it.**

## Why do requirements specifications fail in software projects?

Requirements specifications fail because they start from the knowledge available on the first day, and that knowledge grows during the project. The German standard DIN 69901-5 describes the Lastenheft as the totality of the client's requirements and the Pflichtenheft as the contractor's response to it. This model works where requirements are stable, such as a plant with fixed specifications. With software, insights from actual use arrive that nobody knew beforehand.

The software economist Barry Boehm showed in 1981 that effort estimates in early project phases can miss by a factor of around four in either direction, and that the spread narrows as the project progresses. A study of 1,471 IT projects by Flyvbjerg and Budzier found an average cost overrun of 27 per cent, and one project in six overran its costs by 200 per cent on average. A fixed price based on an early estimate does not reflect this uncertainty. It displaces it. The provider builds in buffers, or defends the scope of the specification line by line, and the client receives at the end what the paper said, even if it no longer matches what is needed.

The Agile Manifesto of 2001 captured this conflict in one phrase: customer collaboration over contract negotiation. The task that follows is to write contracts that allow collaboration and give it a binding framework.

## Which contract models exist for agile collaboration?

Four contract models are common for agile collaboration: fixed price with fixed scope, time and materials, team contract and fixed price with variable scope. A phased model comes in as a combination. The models differ in where the risk for scope and effort lies and how much change they can absorb.

**Contract models compared**
Criterion | Fixed price, fixed scope | Time and materials | Team contract | Fixed price, variable scope | With Niehues Consulting
Risk for scope | With the provider, priced in | With the client | Shared through product goal and duration | Shared through ceiling and prioritisation | Risk analysis before choosing the model
Handling change | Change request, often a point of dispute | Possible at any time | Any time, within the team | Swap of scope at the same price | Prioritising the backlog with the client
Incentive for the provider | Deliver as little as possible | As much effort as possible | Stable collaboration | Deliver value within the ceiling | Metrics for value and flow
Fits | Clear scope and stable requirements | Short engagements with an open goal | Long-term product development | Open scope within a fixed ceiling | Selection by the criteria in this article

Fixed price with variable scope is the model described by the "Money for Nothing, Change for Free" pattern of Jeff Sutherland. The price is fixed, the client may swap requirements in the backlog as long as the total volume stays the same, and the client can end the collaboration as soon as the essential value is delivered, with the provider receiving an agreed share of the remaining price. The pattern assumes that the client genuinely lives Scrum, with a product owner who takes decisions. The team contract suits products that grow over years and bills capacity per period and measures the collaboration against goals.

The phased model combines the others. A first short phase on time and materials, or at a limited fixed price, clarifies requirements and architecture, after which both sides decide whether and in which model delivery continues. It fits when goal and solution path are not yet clear enough for an agile framework. How fixed price and flexible scope can be combined in a project is described in the article on [agile fixed-price projects](/en/blog/agile-fixed-price-projects-flexible-scope/).

## How do you choose the right contract model?

The right model follows from five questions that you answer before the tender. Each yes shifts the choice towards an agile model.

1. Are requirements likely to change during the project because users only show in use what they need?
2. Can the goal be described in one sentence while the solution cannot be fully described in advance?
3. Can your company name a product owner with decision authority who has time for the team every week?
4. Is a result in stages, with benefit after a few weeks, worth more to you than a complete result at the end?
5. Do you already work with the provider, or can you build trust in a pilot phase?

With four or five yes answers, a team contract or a fixed price with variable scope fits. With two or three, the phased model is advisable, because a first phase clears the open points before both sides commit. With zero or one yes, the classic fixed price remains appropriate because scope and requirements are stable.

## What belongs in an agile contract?

Seven components belong in an agile contract, regulating the collaboration without fixing the scope in detail. Your specialists will settle how to word them in legal terms.

1. Product goal and measure of value: the aim of the undertaking in a few sentences and the metric by which the benefit is measured. The Product Goal in the 2020 Scrum Guide fills this role.
2. Rhythm: delivery in fixed cycles, with a demonstration at the end of each cycle. The Sprint Review serves as the point at which the client inspects and decides.
3. Definition of Done: a written description of when a result counts as finished, so that acceptance is not renegotiated each time.
4. Roles: the client provides the product owner, the provider the team. Both sides name a contact for escalation.
5. Ceiling and exit points: a sum that is not exceeded without a new decision, and the option to terminate after each cycle.
6. Transparency: access for both sides to the backlog, to work in progress and to metrics.
7. Handling change: a simple way to swap requirements, and a rule for how scope and effort behave when this happens.

**Metrics for steering the provider**
- Lead time from requirement to use
- Number of results accepted in the Sprint Review
- Share of work that returns as rework
- Ratio of delivered benefit to effort invested

## How do you steer a provider in an agile project?

You steer the provider through results in short cycles. The instrument is the Sprint Review: the provider shows working results, and the client's product owner decides on acceptance and order. Dates can be given with probabilities, as the article on [delivery forecasts with Monte Carlo simulation](/en/blog/delivery-forecasting-monte-carlo-simulation/) shows, and for boards, planning in milestones suits, which the article on [milestone planning in agile programmes](/en/blog/milestone-planning-agile-programmes/) describes.

Two patterns throw contracts off balance. The first is a product owner without time or authority. The provider waits for decisions, and the waiting time ends up in effort or in the schedule. The second is a backlog without priority, in which everything is important. Here it helps to ask which delay causes which cost, as the article on [cost of delay](/en/blog/cost-of-delay/) describes.

## Working with Niehues Consulting towards robust supplier relationships

[Niehues Consulting](/en/) is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects from VC-funded scale-ups to DAX 40 groups and in more than 20 countries on six continents. In the service area of delivery management and organisation design, the consultancy takes on roles as delivery manager, project manager or product owner and so steers the collaboration with service providers from the client's side.

The approach follows the Niehues Delivery Model with its three phases. Three test questions count for contracts with service providers: who decides, who delivers, who uses? Which roles, decision paths and interfaces does operation need? Which metric shows after 90 days that the solution has landed? The scope and terms of an engagement are discussed in the free initial consultation, which you can arrange in 30 minutes via the [contact form](/en/#kontakt).

**Conclusion**
An agile contract combines a clear product goal with a fixed rhythm, exit points and a ceiling. It fits when requirements become clear during the project, and it works when the client provides a product owner able to decide. Where scope and requirements are stable, the fixed price remains a good choice.

**Sources**
- DIN 69901-5: Project management, terms and concepts, standard, 2009
- Boehm: Software Engineering Economics, book, 1981
- Flyvbjerg, Budzier: Why Your IT Project May Be Riskier Than You Think, Harvard Business Review, 2011
- Beck et al.: Manifesto for Agile Software Development, 2001
- Schwaber, Sutherland: The Scrum Guide, 2020
- Sutherland: Money for Nothing and Your Change for Free, Agile conference, 2008

## Frequently asked questions

### What is an agile contract?

An agile contract sets a product goal, a delivery rhythm, roles and a ceiling on effort and leaves the detailed scope open. Requirements are prioritised and swapped during the project. The model replaces the requirements specification where requirements only become clear in use.

### Is a fixed price possible in agile projects?

A fixed price is possible in agile projects if the scope stays variable. With a fixed price for variable scope, the price is set and the client swaps requirements in the backlog at the same total volume. Agreeing fixed scope at a fixed price contradicts the idea of adaptation.

### What is Money for Nothing, Change for Free?

Money for Nothing, Change for Free is a contract pattern by Jeff Sutherland for agile fixed-price projects. Backlog changes cost nothing at the same volume, and the client may end early once the essential value is delivered, paying an agreed share of the remaining price.

### How do a team contract and time and materials differ?

A team contract ties a fixed team to the client over a longer period and measures it against goals, while time and materials pays for hours worked. The team contract fosters stable collaboration and product knowledge. Time and materials suits short engagements with an open goal.

### How is acceptance regulated in agile contracts?

Acceptance takes place in short cycles, usually in the Sprint Review, against a written Definition of Done. The client's product owner inspects working results and decides on acceptance and next steps. That leaves no surprises at the end of the project.

### What is the product owner's role on the client side?

The product owner represents the client day to day, prioritises the backlog and decides on acceptance. The role needs authority and weekly time for the team. Without it, the provider waits for decisions, and the waiting time shows up in effort or schedule.

### How do you keep costs under control with agile contracts?

Costs stay manageable through a ceiling, exit points after each cycle and metrics for value and flow. Every overrun needs a new decision. Transparent access to the backlog shows early whether effort follows benefit.

### When does a classic fixed price still make sense?

A classic fixed price makes sense when scope and requirements are stable and hardly change during the project, as when adapting a known standard solution. In that case it secures cost and schedule. With open requirements it displaces the uncertainty into change requests.