Fixed price or Time & Material? Over the last few years, I've accompanied dozens of IT projects where this question became a point of contention – often before even a single line of code was written. Purchasing departments insist on fixed prices because budget certainty simply isn't negotiable. Project leaders simultaneously know that requirements in complex software projects will inevitably change. The result: contracts that are formally "successfully" fulfilled but delivered past the actual need.
The Agile Fixed Price is a contract model that addresses this dilemma. The basic idea: an indicative price framework that only becomes binding after a test phase, combined with mechanisms for cost-neutral scope exchange and early termination. The concept was developed by Andreas Opelt, Boris Gloger, Wolfgang Pfarl, and Ralf Mittermayr – documented in the standard work "Der agile Festpreis" (Hanser Verlag, now in its 4th edition).
Whether this model suits your next project depends on factors I want to address openly in this article. Because the Agile Fixed Price is no panacea – but for many situations, it's the more pragmatic path.
📌 The Four Core Mechanisms
The heart of the Agile Fixed Price consists of four mechanisms that work together. Two of them – Change for Free and Money for Nothing – were originally developed by Scrum co-founder Jeff Sutherland.
🔹 Change for Free: Trading Instead of Renegotiating
Your client suddenly wants Feature X instead of Y? With a classic fixed price, the change request battle begins now. Forms, recalculations, tough negotiations. In the end, someone pays extra – usually both parties.
Change for Free works differently: The client may add requirements at sprint boundaries – under one condition. They must simultaneously remove requirements with equivalent effort from the backlog. Do they want to add a feature with 13 story points? Then features worth at least 13 story points must be removed. The total scope remains constant, but the content can adapt.
This fundamentally changes the dynamics. Instead of "that wasn't agreed upon", it becomes "what's more important to you?". Instead of renegotiation, there's a clear process. In practice, I see this mechanism saving projects – not because nothing changes, but because changes are no longer a drama.
Important here: The equivalence must be measurable. Story points, T-shirt sizes, estimated person-days – the main thing is that both sides have the same currency.
🔹 Money for Nothing: The Exit Right
What if your client could terminate a project early – and both sides still win? This sounds paradoxical but is the logic behind Money for Nothing.
In agile development, the most valuable features are implemented first. The marginal benefit decreases with each sprint. At some point, developing new features costs more than they're worth. Money for Nothing gives the client an exit right: they can say "Thanks, that's enough" after each sprint.
The remaining budget is divided – typically 80/20. The client saves 80%, the supplier receives 20% as compensation. Why would the supplier agree to this? They can deploy resources earlier for new contracts, their effective margin often increases significantly, and there's no frustrating working through features that nobody needs.
A documented example: A project with a $10 million budget was terminated early. The client paid only $3.2 million, delivery occurred 17 months earlier than planned. The supplier achieved 60% actual margin instead of the planned 15% – because resources were freed earlier for new contracts.
Honestly speaking: In practice, this mechanism is used less frequently than theory would suggest. Most budgeting processes don't accommodate such flexibility. The finance department asks: "Why are we paying for something we're not getting?" But the mere possibility changes conversations. Suddenly, you're asking: "Do we really still need this?"
🔹 Risk Share: Joint Liability
Who pays when the estimate is off? This question determines whether there will be collaboration or a blame game.
In a classic fixed price, the supplier bears the full risk. This leads to two reactions: Either they calculate massive risk buffers – then you pay too much. Or they calculate tightly and later finance themselves through change requests – then you also pay too much, just later and with more frustration.
Risk Share means: Both parties share additional costs, typically 50/50. This initially sounds like "I'm paying for the supplier's mistakes". But the reality is more complex: Estimation errors often arise from unclear requirements – from both sides. Unforeseen complexity is rarely one party's "fault". And whoever is solely liable hides problems as long as possible.
Risk Share changes the incentives. When both pay, both have an interest in realistic estimates, early communication about problems, and efficient collaboration. In practice, I experience that projects with Risk Share have a different conversation culture. Problems are addressed earlier. The blame game is no longer worthwhile.
🔹 Checkpoint Phase: Test First, Then Fix
Agree on a fixed price for something nobody knows exactly? That works – but not on day 1.
The checkpoint phase solves this dilemma. First, an indicative fixed price framework is agreed upon, not yet binding, typically with a 10-25% risk buffer. Then follows a test phase of two to five sprints in which implementation already begins. During this phase, actual velocity is measured (not estimated), collaboration is tested (not hoped for), and trust is built – or not.
After the checkpoint phase, both parties decide: Do we want to implement the overall project? Under what conditions? At what – now binding – price?
This isn't a stalling tactic. It's an acknowledgement of reality: Nobody knows exactly at the beginning what a complex IT project costs. The checkpoint phase delivers empirical data instead of wishful thinking. And yes – both sides can also say afterwards: "This doesn't fit." Better early than after 18 months.
📌 Special Challenges in ERP Projects
ERP implementations are particularly challenging for agile fixed prices. They affect all business areas, require massive data migration, and fundamentally change processes. The statistics are sobering: 70-75% of ERP projects don't achieve their original objectives, about one in four projects significantly exceeds the budget.
SAP has developed a hybrid methodology with SAP Activate that integrates agile elements. The trend is towards "Clean Core Strategy" – customisations are moved to the SAP Business Technology Platform, the core remains standard. For complex S/4HANA transformations, the Scaled Agile Framework (SAFe) is employed with three to six sprints per Program Increment.
The cautionary example is Lidl: In 2011, the discount retailer started an SAP implementation, invested €500 million over seven years – and cancelled in 2018. Causes were excessive customising, too rapid pace, and lack of willingness to adapt processes. Even the best contract wouldn't have changed that.
💰 For Whom Does the Agile Fixed Price Work?
Time for the honest question.
The model works when a product owner with real mandate and time is available. When project objectives are measurable – "30% faster throughput time" instead of "ideal support". When both sides want genuine collaboration, not just on paper. And when corporate culture permits transparency.
It doesn't work when procurement insists on classic fixed prices without any exception. When management wants to delegate the project without being involved themselves. When no basic trust exists between parties. Or when detailed upfront documentation is mandatory, for example in highly regulated industries.
Red flags during the project: When velocity continuously declines, sprint goals are regularly missed, stakeholders don't attend reviews, or the product owner is unreachable – then the model erodes. It falls back to Time & Material, the blame game begins. In extreme cases, lawyers are brought in, the opposite of the intended partnership collaboration.
📌 Alternatives for True Agility
The Agile Fixed Price is ultimately a transitional construct. For organisations whose procurement demands fixed prices but whose projects need flexibility. It solves a real problem – but it's not the only solution.
For organisations that live true agility, there are alternatives. Fixed price per sprint instead of per project. Value-based contracts with payment according to business value. Managed-Investment Contracts according to SAFe with MVP focus and option periods. Practitioners from it-agile criticise that the Agile Fixed Price "still constrains agile procedures relatively strongly" – the budget fixation can lead to less innovation because the focus is on budget compliance rather than value maximisation.
Which model suits you depends on your organisation. Not on the trend.
📌 Practice Checklist Before Contract Signing
Before signing, you should clarify these questions:
- Are project objectives quantifiably defined?
- Is a checkpoint phase (2-5 sprints) planned?
- Is the risk-share model defined (e.g., 50:50)?
- Is a product owner with real mandate named?
- Is the governance structure documented?
- Are "Change for Free" equivalence rules defined?
- Are "Money for Nothing" exit clauses agreed?
- Is the Definition of Done jointly aligned?
📌 Further Resources
Standard work in German-speaking countries: Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge by Opelt, Gloger, Pfarl, and Mittermayr (Hanser Verlag, 4th edition 2023). Contains contract templates and detailed process descriptions.
Fundamentals: Wikipedia: Agiler Festpreis
Agile Contract Models: it-agile: Agile Verträge
International Perspectives: UK Government Digital Service – Contracting for Agile and the Scaled Agile Framework (SAFe) for Lean-Agile Contracts.
Legal Deep Dive: BITKOM Practical Guide "Balanced Contract Concepts" (available free of charge) as well as "Agile Verträge" by Pieper/Roock (dpunkt.verlag).
---
This article serves general orientation purposes and does not constitute legal advice. For specific contract design, you should consult a lawyer specialising in IT law.