Kostendeckel für IT-Projekte

Roman Lobsiger ist Business Analyst bei der bbv Software Services AG und beschäftigt sich mit Business- und Prozess-Analysen im Healthcare-Markt. Alain C. Boss ist Senior Consultant und Agile Coach im selben Unternehmen. Sobald sich Kunde und Anbieter gefunden haben, müssen Verträge aufgesetzt werden. Dabei achtet jede Firma in erster Linie auf ihre eigenen Interessen und erwartet, dass die andere Firma dasselbe tut. So gesehen könnte man meinen, dass der beste Ansatz darin besteht, einen wasserdichten Vertrag auszuarbeiten. Ist das wirklich der Garant für den Erfolg? Und welches Modell zur Zusammenarbeit soll hier die Grundlage sein? Was sind die Vorteile, was die Nachteile? Entscheiden Sie selbst.

Ein Vertrag mit Fixpreis dient in erster Linie dazu, den Kunden zu schützen. Er versucht, das finanzielle Risiko auf den Anbieter abzuschieben. Bei öffentlichen Ausschreibungen sind Fixpreisverträge laut Gesetz sogar Pflicht. Die Schätzungen der Anbieter basieren auf einem Pflichtenheft, das die Anforderungen dokumentiert. Die Ausschreibungen werden in vielen Fällen vom Anbieter mit dem tiefsten Angebot gewonnen. Dies verführt wiederum die Anbieter dazu, möglichst tief zu bieten und den Gewinn mit der Umsetzung von Change Requests zu machen. Wird ein Fixpreisprojekt nach agilem Vorgehen entwickelt, ist dies für Anbieter mit einem hohen Risiko verbunden. Sobald das Geld auszugehen droht, wird es zunehmend schwie­riger, den Kunden zur Abnahme der geleisteten Arbeit zu bewegen, weil er möglichst viele Funktionalitäten für die vereinbarte Investition erhalten möchte. Da die Funktionalitäten bei Vertragsabschluss mit Sicherheit nicht bis ins letzte Detail definiert sind, ergibt sich ein grosser Ermessensspielraum. Der Kunde wird versuchen, alle Anforderungen ins Pflichtenheft hineinzuinterpretieren. Der Anbieter versucht, sich andererseits zu schützen, indem er unklare Anforderungen als Änderungen betrachtet, strengstens überwacht und peinlich genau Mehraufwände verrechnet. Dies resultiert nicht selten in wesentlich höheren Kosten und/oder einem unzufriedenen Kunden. Nach einem misslungenen Fixpreisprojekt gibt es oft nur Verlierer. Der Kunde wird bei späteren Projekten versuchen, den Vertrag noch strenger zu formulieren, während der Anbieter mit noch schärferen Kontrollen beim Changemanagement reagiert. Eine Win-Win-Situation sieht anders aus. Lesen Sie auf der nächsten Seite: ...nach Aufwand

Bei einem Vertrag nach Aufwand wird den Unsicherheiten im Projekt und der Komplexität der Software mehr Rechnung getragen. Das Risiko wird nicht ausgeschaltet, sondern vom Anbieter zum Kunden übertragen. Aus Sicht des Anbieters besteht bei diesem Vertrag die Gefahr, dass der Kunde vorzeitig aussteigt. Solange der Vertrag bestehen bleibt, ist er aus Sicht des Anbieters ein Gewinn. Der Anbieter hat allerdings wenig Grund, effizient zu arbeiten, denn je länger das Projekt dauert, desto mehr Geld verdient er. Infolgedessen baut der Kunde zum eigenen Schutz ein Projektcontrolling auf, um die Ausgaben besser im Griff zu haben. Der Kunde ist vom Anbieter abhängig, sobald ein Teil des Systems ausgeliefert wurde. Achtet der Kunde nach jeder Iteration auf eine vollständig integrierte und dokumentierte Software, kann der Kunde jederzeit aus dem Vertrag aussteigen und hat schon einen Gegenwert für seine Investitionen erhalten.

Wie oben beschrieben, können Fixpreisverträge zu einer Selbstbedienungsmentalität aufseiten des Kunden und zu einem restriktiven Änderungsmanagement aufseiten des Anbieters führen. Bei Verträgen nach Aufwand sind die Rollen vertauscht. Der Anbieter kann sich bedienen und der Kunde versucht, mit aufwendigem Controlling der Situation gerecht zu werden. Ziel sollte jedoch eine faire Risikoverteilung sein, die beide Seiten in die Pflicht nimmt. Zwar liefert auch ein Vertrag nach Aufwand mit Kostendach kein Patentrezept. Denn kein Vertrag kann vollständig verhindern, dass sich ein
Vertragspartner nicht an die Spielregeln hält. Er bietet aber eine gute Basis für eine funktionierende Zusammenarbeit, bei der beide Parteien Interesse an einer kosteneffizienten Abwicklung eines Projekts haben. Die Idee ist denkbar simpel. Bleiben die Gesamtkosten unter dem Kostendach, so teilen beide Parteien das gesparte Geld untereinander auf. Übersteigen die Aufwände das Kostendach, beteiligen sich beide Parteien an den Mehrkosten. Gegebenenfalls müssen beidseitige Ausstiegsszenarien definiert werden, um beispielsweise zu verhindern, dass der Kunde alle Entwicklungen, die das initiale Kostendach übersteigen, zu einem reduzierten Tarif erhält. Entscheidend ist, dass beide Parteien Interesse an einer zügigen und kosteneffizienten Abwicklung des Projekts haben. Das Kostendach muss beiden Parteien von Anfang an als eine Zielvorgabe dienen, die grossen Einfluss auf die Software-Lösung hat und deren Einhaltung von beiden Seiten jederzeit angestrebt wird. Der Kunde verzichtet auf Nice-to-have-Lösungen, während die Entwickler mit technischen Lösungen zurückhaltend sind, die keinen Mehrwert liefern. Der initiale Aufwand für die Erstellung der Anforderungen ist grösser als beim Modell «Vertrag nach Aufwand», weil zur Berechnung des Kostendachs detailliertere Anforderungen vorhanden sein müssen. Lesen Sie auf der nächsten Seite: Fazit: für beide Seiten interessant

Die agilen Methoden eignen sich hervorragend für die Umsetzung von Projekten mit stetig ändernden Anforderungen. Durch die Verwendung eines Kostendachs kann der Kunde besser vor steigenden Kosten geschützt werden. Das Modell «Agil nach Aufwand mit Kostendach» bietet daher beiden Seiten eine gute Basis für eine befriedigende Zusammenarbeit. Das gegen­seitige Interesse, eine optimale Lösung zu finden, steht dabei im Vordergrund.
Projekte nach Fixpreis eignen sich nicht für agile Software-Entwicklung, da das Reagieren auf Änderungen schnell zum Bumerang werden kann, dessen finanzielle Aufwände voll zulasten des Anbieters gehen.

Vergleich der Modelle

! KASTEN !

Maximaler Nutzen für beide Seiten

! KASTEN !

Weiterführende Literatur

Opelt, Andreas; Gloger, Boris; Pfarl, Wolfgang; Mittermayr, Ralf: «Der agile Festpreis», Hanser, 2012
Poppendieck, Mary und Tom: «Lean Software Development», Addison-Wesley, 2003