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

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.

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.

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.

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.

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 shows, and for boards, planning in milestones suits, which the article on milestone planning in 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 describes.

Working with Niehues Consulting towards robust supplier relationships

Niehues Consulting 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.