Lastenheft, Fixpreis, fixer Termin – und bitte agil: Zwei Paradoxien bei IT-Ausschreibungen
Viele IT-Ausschreibungen beginnen ganz klassisch: Anforderungen werden erhoben, abgestimmt und anschließend in einem Lastenheft oder Leistungskatalog festgehalten. Auf dieser Grundlage erstellen die Bieter ihre Angebote.
Im Hearing präsentieren die Anbieter, wie sie die Umsetzung organisieren wollen. Nach meiner Erfahrung präsentieren viele Anbieter ein agiles Umsetzungskonzept: mit Sprints, einem Backlog und den üblichen Scrum-Ritualen. In regelmäßigen Reviews oder sogenannten Show-and-Tell-Sessions präsentieren sie, was im vergangenen Sprint umgesetzt wurde.
Das klingt zunächst nach einer sinnvollen Kombination. Der Auftraggeber erhält einen verbindlichen Preis und einen definierten Leistungsumfang. Der Lieferant kann die Umsetzung trotzdem agil organisieren und regelmäßig Ergebnisse liefern.
In der Praxis entstehen daraus jedoch zwei Paradoxien.
Die erste betrifft das Verhältnis zwischen neuen Wünschen und dem vereinbarten Fixpreis. Die zweite geht noch weiter: Wenn sich der Leistungsumfang während der Umsetzung stark verändert, stellt sich irgendwann die Frage, ob eigentlich noch jener Auftrag umgesetzt wird, für den der Wettbewerb stattgefunden hat.
Paradoxon 1: Je mehr der Auftraggeber lernt, desto stärker gerät der Fixpreis unter Druck
Während einer Show-and-Tell-Session werden Funktionen, Prozesse und Benutzeroberflächen konkret sichtbar. Dabei entstehen fast zwangsläufig neue Erkenntnisse:
- „Diese Maske könnten wir einfacher gestalten.“
- „Hier benötigen wir noch eine zusätzliche Information.“
- „Wenn wir diesen Schritt automatisieren, würde das viel Zeit sparen.“
- „Eigentlich brauchen wir noch eine weitere Schnittstelle.“
Genau dafür sind solche Termine gedacht. Der Auftraggeber soll Feedback geben und die Lösung soll dadurch besser werden.
Häufig entsteht jedoch ein Missverständnis.
Der Auftraggeber sagt: „Das könnten wir doch noch ergänzen. Wir arbeiten schließlich agil.“
Der Lieferant nimmt den Wunsch in das Backlog auf. Das Entwicklungsteam setzt ihn möglicherweise bereits im nächsten Sprint um. Erst später stellt sich heraus, dass die Anforderung nicht vom vereinbarten Leistungsumfang umfasst war.
Es folgt eine Nachforderung. Für den Auftraggeber kommt sie überraschend: Aus seiner Sicht hat er lediglich Feedback in einem agilen Projekt gegeben. Für den Lieferanten handelt es sich dagegen um eine zusätzliche Leistung, die im Fixpreis nicht kalkuliert war.
Beide Seiten haben „agil“ unterschiedlich verstanden.
Der Auftraggeber erwartet Flexibilität. Der Lieferant erwartet trotz agiler Arbeitsweise einen begrenzten Leistungsumfang.
Ein Backlog darf sich verändern. Es ist aber kein Wunschzettel mit Preisgarantie.
Soll eine neue Anforderung ohne Mehrkosten umgesetzt werden, müsste beispielsweise eine andere, ungefähr gleichwertige Leistung entfallen. Sollen dagegen alle bisherigen Anforderungen bestehen bleiben, führt der neue Wunsch zu mehr Aufwand, mehr Zeit oder zusätzlichen Kosten.
Agilität hebt diese Zusammenhänge nicht auf.
Paradoxon 2: Der Auftraggeber darf lernen – der Wettbewerb darf sich nicht nachträglich verändern
Selbst wenn sich Auftraggeber und Lieferant über den zusätzlichen Aufwand einigen, bleibt noch eine zweite Frage.
Was passiert, wenn sich der Leistungsumfang während der Entwicklung so stark verändert, dass andere Unternehmen beim ursprünglichen Vergabeverfahren mitgemacht hätten?
Vielleicht hat ein Anbieter nicht angeboten, weil das ursprüngliche Lastenheft nicht zu seinem Leistungsschwerpunkt passte. Vielleicht hätte ein anderer Bieter für den später entstandenen Leistungsumfang ein besseres Konzept oder einen günstigeren Preis anbieten können.
Dann betrifft die Änderung nicht mehr nur den bestehenden Vertrag. Sie betrifft den ursprünglichen Wettbewerb.
Das österreichische Bundesvergabegesetz nennt genau diesen Fall: Eine Vertragsänderung ist insbesondere dann wesentlich, wenn die geänderten Bedingungen das Interesse weiterer Unternehmen am Vergabeverfahren geweckt oder die Auswahl eines anderen Angebots ermöglicht hätten.
Je weiter sich der Backlog vom ausgeschriebenen Lastenheft entfernt, desto fraglicher wird es, ob noch jener Auftrag umgesetzt wird, für den der Wettbewerb stattgefunden hat.
Eine Einigung zwischen Auftraggeber und Lieferant allein reicht dann nicht aus. Handelt es sich um eine wesentliche Vertragsänderung, ist grundsätzlich ein neues Vergabeverfahren erforderlich, sofern keine gesetzliche Ausnahme greift.
Das ist die zweite Grenze vermeintlicher Agilität: Der Auftraggeber darf während des Projekts lernen. Er darf die Ergebnisse dieses Lernprozesses aber nicht unbegrenzt beim bereits ausgewählten Lieferanten bestellen.
Was bedeutet das für die Praxis?
Neue Wünsche aus einem Show-and-Tell sollten nicht automatisch als Arbeitsauftrag verstanden werden. Vor der Umsetzung braucht es zwei Prüfungen:
Vertraglich: Ist die Anforderung bereits enthalten, wird sie gegen eine andere Leistung getauscht oder entsteht zusätzlicher Aufwand?
Vergaberechtlich: Bleibt die Änderung innerhalb des ausgeschriebenen Auftrags oder wäre der veränderte Auftrag möglicherweise auch für andere Anbieter interessant gewesen?
Für jede neue Anforderung gibt es damit vier Möglichkeiten:
- Sie ist bereits vom vereinbarten Leistungsumfang umfasst.
- Sie ersetzt eine ungefähr gleichwertige Anforderung im Backlog.
- Sie wird zusätzlich und vergaberechtlich zulässig beauftragt.
- Sie muss getrennt ausgeschrieben oder zurückgestellt werden.
Diese Entscheidungslogik sollte nicht erst während des Projekts entstehen. Sie gehört bereits in die Ausschreibungsunterlagen und in den Vertrag.
Eine allgemeine Formulierung wie „Der Backlog kann während des Projekts angepasst werden“ reicht dafür allein nicht aus. Bereits in den Ausschreibungsunterlagen sollte klar, präzise und eindeutig festgelegt sein, welche Änderungen in welchem Umfang und unter welchen Voraussetzungen möglich sind. Der Gesamtcharakter des Auftrags darf dadurch nicht verändert werden.
Fazit
Show-and-Tell-Sessions sind nicht das Problem. Sie machen sichtbar, was bei der Erstellung des Lastenhefts noch nicht bekannt war. Genau darin liegt ihr Wert.
Doch die gewonnenen Erkenntnisse brauchen klare Grenzen:
Ein agiles Vorgehensmodell ersetzt kein Änderungsverfahren. Ein Backlog hebt den vereinbarten Leistungsumfang nicht auf. Und die Zustimmung des bestehenden Lieferanten ersetzt keinen vergaberechtlichen Wettbewerb.
Welche Erfahrungen haben Sie gemacht? Wie werden neue Anforderungen aus Sprint Reviews oder Show-and-Tell-Sessions in Ihren Fixpreisprojekten behandelt?
Zum Nachlesen
Stand der Rechtsgrundlagen: 7. September 2026.
Dieser Beitrag bietet eine allgemeine Einordnung und ersetzt keine rechtliche Prüfung des jeweiligen Einzelfalls.