Von Wasserfall bis Agile: Projektmethodik im IT-Vertrag
Die Herangehensweise an IT-Projekte ist immer individuell, selbst in ihrer Zielsetzung vergleichbare Projekte laufen im Detail nur selten tatsächlich gleich ab. Wenn es um die Entwicklung oder Anpassung von Software geht, lassen sich IT-Projekte aber regelmäßig jedenfalls grob einer von zwei Fallgruppen zuordnen: Auf der einen Seite stehen Projekte nach dem klassischen „Wasserfallmodell″, auf der anderen Seite „agile″ Methoden. Bei der Wahl der Projektmethodik sollten die Beteiligten die jeweiligen Chancen und Risiken sorgfältig abwägen, um das Projekt von Anfang an auf die richtige Spur zu bringen. Das gilt auch für unternehmensinterne Projekte, in besonderem Maße aber für extern vergebene Auftragsentwicklungen, weil die Wahl der Projektmethodik einen erheblichen Einfluss auf die Gestaltung des Vertrags hat, der die rechtliche Grundlage des Projekts bildet.
Klassische Entwicklung nach Wasserfallmodell
Entwicklungsprojekte liefen historisch meist nach dem sogenannten „Wasserfallmodell″ ab. Dieses hat seinen Namen von der üblichen grafischen Darstellung des Entwicklungsprozesses, der in mehreren Entwicklungsstufen kaskadierend abläuft. Sobald eine Entwicklungsstufe abgeschlossen ist, „fließt″ das Projekt zur nächsten Stufe und verläuft dabei grundsätzlich linear in eine Richtung, grafisch gerne „nach unten″ dargestellt, gleich einem über mehrere Stufen nach unten fallenden Wasserfall. Der Auftraggeber ist dabei lediglich am Anfang und am Ende des Prozesses involviert: Er legt zu Beginn die Anforderungen an die Software fest (in der Regel in einem Lastenheft) und prüft nach Abschluss der eigenständig vom Auftragnehmer durchgeführten Entwicklung das Ergebnis (in der Regel in einem formalisierten Abnahmeprozess). In der Theorie verspricht diese Projektmethodik einen stringenten und unkomplizierten Projektverlauf, der zügig und vor allem planbar zum gewünschten Ergebnis führt.
In der Praxis zeigt sich, dass mit zunehmender Komplexität der zu entwickelnden Software die Anforderungen zu Beginn oft nicht oder nicht vollständig feststellbar sind und vom Auftraggeber erstellte Lastenhefte nicht immer den Kern dessen treffen, was der Auftraggeber für die tatsächliche Verwendung der Software tatsächlich benötigt. Das verursacht mitunter erhebliche Aufwände, weil die sich erst nach Abschluss aller Entwicklungsarbeiten zeigenden Defizite dann auf einen Schlag behoben werden müssen und umfangreiche Neuentwicklung erforderlich werden kann. Wenn die Software die ausdrücklich vertraglich vereinbarten Anforderungen erfüllt, nicht aber den (bei Abschluss des Entwicklungsvertrags gegebenenfalls noch gar nicht bekannten) tatsächlichen Anforderungen gerecht wird, die an diese im Realbetrieb bestehen, wird der Auftragnehmer zudem regelmäßig nur gegen zusätzliche Vergütung dazu bereit sein, im Nachgang noch Änderungen vorzunehmen, da im rechtlichen Sinne eine mangelfreie Leistung vorliegt.
Agile Entwicklung nimmt zu
Schon früh haben Softwareentwickler und Projektmanager diese dem Wasserfallmodell inhärenten Probleme erkannt und versucht, den Entwicklungsprozess aus seinem starren Korsett zu lösen. Unter dem Oberbegriff der „agilen″ Entwicklung existieren heute eine Vielzahl von Frameworks (zum Beispiel „KANBAN″ oder „SCRUM″). Sie alle eint der Ansatz, den Entwicklungsprozess flexibel gestalten zu wollen, den Entwicklungsteams weitgehende Organisationshoheit für ihren Aufgabenbereich zuzugestehen und in einer iterativen Vorgehensweise möglichst schnell eine erste Version der Software zu entwickeln, die danach Version um Version verbessert wird, bis am Ende eine Software steht, die allen tatsächlichen Anforderungen des Auftraggebers genügt. Auf dem Weg zum Endprodukt soll durch die laufende Abstimmung mit dem Auftraggeber sichergestellt werden, dass nicht am Bedarf des Auftraggebers vorbei entwickelt wird.
Im Unterschied zum Wasserfallmodell ist der Auftraggeber bei agiler Entwicklung in den Entwicklungsprozess eng eingebunden und wird regelmäßig über den Stand der Entwicklung, auftretende Herausforderungen und Lösungsmöglichkeiten informiert. Durch regelmäßiges Feedback kann (und muss!) sich der Auftraggeber auch selbst in die Entwicklung einbringen. Durch Auftraggeber wird dabei häufig als herausfordernd erlebt, dass die Beteiligung am Projekt einen nicht unerheblichen Aufwand mit sich bringt und dass auch der Auftragnehmer selbst in einem gewissen Maße Einfluss darauf nehmen kann, wie das Endprodukt letztlich konkret aussehen wird. Zudem bringen agile Projekte einen erheblich erhöhten Projektmanagement-Aufwand mit sich.
Bewusste Wahl der passenden Projektmethodik
Sowohl klassische Ansätze als auch agile Frameworks haben Vor- und Nachteile. Die Entscheidung für die konkrete Projektmethodik ist in den seltensten Fällen zwingend, sondern erfordert regelmäßig eine individuelle Abwägung, insbesondere aus fachlicher Sicht. Die Wahl der Projektmethodik ist für den Verlauf des Projekts von grundlegender Bedeutung, weil sie den fachlichen Rahmen der Zusammenarbeit setzt. Dies gilt für rein unternehmensintern durchgeführte Projekte, aber besonders für Projekte, bei denen externe Softwareentwickler zum Einsatz kommen, weil hier eine sinnvolle und auch im Falle von Meinungsverschiedenheiten belastbare vertragliche Regelung gefunden werden muss.
Für viele Entscheidungsträger ist die Vertragsgestaltung für Projekte nach dem klassischen Wasserfallmodell eingängiger und besser nachvollziehbar. Es bleibt bei dem gewohnten Leitbild des Auftragsverhältnisses, nach dem der Auftraggeber detailliert vorgibt, welches Produkt mit welchen genauen Spezifikationen er am Ende in den Händen halten möchte, und dass der Auftragnehmer für die „Herstellung″ dieses Produkts allein verantwortlich ist.
Die vertraglichen Rahmenbedingungen für agile Projekte sind demgegenüber oftmals ungewohnt. Der Fokus liegt dabei eher auf der Beschreibung der Zusammenarbeit im Projekt. Anstelle eines detaillierten Anforderungskatalog wird zu Beginn des Projekts lediglich eine rudimentäre Produktbeschreibung vereinbart. Die genaue Art und Weise der Umsetzung ergibt sich dann organisch erst im Laufe des Projekts.
Sowohl die starren Strukturen des Wasserfallmodells als auch die laufenden Anpassungen der Entwicklung im agilen Modell kann im Einzelfall problematisch sein. Der unterschiedliche Ansatz der beiden Methoden muss den Vertragsparteien bewusst sein und in der Vertragsgestaltung berücksichtigt werden.
Auswirkungen der Projektmethodik auf die Vertragsgestaltung
Unabhängig davon, welcher Projektmethodik der Vorzug gegeben werden soll, ist entscheidend, dass die tatsächlich gelebte Praxis vertraglich sauber abgebildet wird. Der Projektvertrag darf nicht als bloße formelle Notwendigkeit und Hürde auf dem Weg zum Beginn der eigentlichen Projektarbeit verstanden werden, sondern seine Bedeutung als verbindliches Regelwerk für die Zusammenarbeit sollte beiden Parteien klar sein. Wenn die Entwicklung im Wasserfallmodell erfolgen soll, sollten etwa die konkreten Anforderungen an die Software im Vertrag detailliert dargelegt werden. Zudem sollten sinnvolle Meilensteine vereinbart werden, die eine Kontrolle des Projektfortschritts ermöglichen. Für eine agile Projektmethodik ist dagegen ein besonderes Augenmerk auf eine sinnvolle Rollenverteilung und klare Verantwortlichkeiten zu legen. Sinnvoll ist auch eine klare Benennung des gewünschten Projekt-Frameworks (gegebenenfalls samt Einbeziehung entsprechender Beschreibungen in den Vertrag), damit beide Parteien wissen, wie das Projekt operativ ablaufen wird. Fallen die vertraglich vereinbarte Methodik und das tatsächlich im Projekt praktizierte Vorgehen auseinander, wird der Vertrag den damit verbundenen Herausforderungen nicht angemessen begegnen können, weil er die entscheidenden Aspekte nicht in der gebotenen Tiefe regelt und auf der anderen Seite unnötige Vorgaben enthält, die für das Projekt im Zweifel hinderlich sind.
Typische Probleme in der Vertragsgestaltung
Die verschiedenen Projektmethodiken unterscheiden sich nicht nur in ihrer praktischen Umsetzung, sondern auch mit Blick auf die jeweils typischen Herausforderungen in der Gestaltung der Projektverträge:
Ein in der Praxis häufig zu beobachtendes Problem agiler Projekte ist die Vereinbarung von Vorgehensweisen, die im Projekt dann nicht eingehalten werden. Beispielsweise werden dann in den Verträgen eine agile Entwicklung und entsprechende Verantwortlichkeiten vorgesehen, im Projekt billigt der Auftraggeber dann aber entweder (am einen Ende des Spektrums) den Entwicklungsteams keine Entscheidungshoheit über technische Fragen zu und macht in Überschreitung seiner Projektrolle Detailvorgaben, oder (am anderen Ende des Spektrums) er füllt die ihm zugewiesene Projektrolle nicht aus und wirkt an der Entwicklung der Software nicht wie erforderlich mit. In beiden Fällen ist ein echtes „agiles″ Vorgehen faktisch nicht möglich. Derartige Widersprüchlichkeiten bringen vermeidbare Sollbruchstellen in das Projekt, die nicht selten zum Anlass für Meinungsverschiedenheiten zwischen den Parteien und Verzögerungen im Projektablauf werden. Bei der Vertragsgestaltung ist daher ein besonderes Augenmerk darauf zu legen, dass die Parteien auch tatsächlich bereit sind, die getroffenen vertraglichen Regelungen in die Praxis umzusetzen. Gegebenenfalls muss ansonsten eine angepasste Vorgehensweise vereinbart werden.
Auch nach dem Wasserfallmodell geplante Projekte bedürfen einer durchdachten rechtlichen Regelung. Häufig zu beobachten sind einerseits deutlich zu oberflächliche Beschreibungen der zu entwickelnden Software. Dies bringt das Risiko mit sich, dass der Auftragnehmer eine Software entwickelt, die zwar alle vertraglich vereinbarten Voraussetzungen erfüllt, jedoch Merkmale, von denen der Auftraggeber lediglich angenommen hat, dass diese vorhanden sein werden, in der finalen Software nicht auftauchen oder anders ausgestaltet sind als erwartet. Auf der anderen Seite steigt mit zunehmender Detailtiefe der vereinbarten Leistungsbeschreibung auch das Risiko, dass sich Anforderungen widersprechen, was zu vermeidbarem Abstimmungsbedarf im Projektverlauf führt. In erster Linie kommerziell relevant ist das Risiko, dass zu detailliert beschriebene Anforderungskataloge aufwändige und kostspielige Sonderentwicklungen notwendig machen, obwohl der Auftragnehmer bereits eine Standardlösung parat hätte, die die Anforderungen weitgehend erfüllen würde, aber nicht verwendet werden kann, weil sie in (unwichtigen) Details von den Vorgaben des Anforderungskatalogs abweicht.
Richtungswechsel sind möglich, aber in der Umsetzung komplex
Natürlich ist nicht ausgeschlossen, dass den Parteien auch bei einem zunächst passend gestalteten Vertragswerk im Laufe eines Projekts klar wird, dass die Entwicklung auf Grundlage der zunächst gewählten Projektmethodik nicht sinnvoll abgeschlossen werden kann. Denkbar ist etwa, dass die Parteien bemerken, dass eine Entwicklung nach dem Wasserfallmodell zu unflexibel ist, um auf eine dynamische Änderung der betrieblichen Anforderungen des Auftraggebers zu reagieren oder dass einzelne Stakeholder mit den erhöhten Kommunikationsanforderungen der agilen Entwicklung überfordert sind.
Vor dem Umschwenken auf eine andere Vorgehensweise sind aber regelmäßig umfassende Anpassungen im Projektvertrag erforderlich, um die Rahmenbedingungen für die weitere Zusammenarbeit nach der neuen Projektmethodik zu schaffen. Ein Anpassungsbedarf ergibt sich oft zumindest mit Blick auf die Leistungsbeschreibung, Termine und Meilensteine sowie auf die Rollen und Mitwirkungspflichten der Parteien, aber unter anderem auch auf Abnahmeregelungen und das Haftungsregime. Oft wird jedenfalls eine Partei darauf bestehen, dass für bestehende Streitpunkte aus dem bisherigen Projektverlauf eine abschließende verbindliche Regelung gefunden wird, in der diese beigelegt werden, bevor das Projekt vertraglich und organisatorisch neu aufgesetzt wird.
Unter Umständen kommt auch eine Aufspaltung des Projekts in mehrere Teilprojekte in Betracht, für die jeweils andere Vorgehensweisen sinnvoll sind, z.B. einerseits die Entwicklung des Kernprogramms im Wasserfallmodell nach exakten Vorgaben, um sicherzustellen, dass relevante Schnittstellen zu Drittsystemen spezifikationsgerecht umgesetzt werden, und andererseits die Entwicklung der darauf aufsetzenden Zusatzmodule mit ergänzenden Funktionen nach agiler Projektmethodik. Hierbei ist zusätzlich eine sorgfältige vertragliche Regelung der Abhängigkeiten der verschiedenen Teilprojekte voneinander erforderlich.
In dieser Blog-Serie informieren wir Sie zur erfolgreichen Vertragsgestaltung bei IT-Projekten. Dabei widmen wir zentralen Aspekten eigene Blog-Beiträge zu Themen wie
- Meilensteine und Abnahmen bei IT-Projekten
- Open Source in IT-Projekten
- 6 häufige Fehler in IT-Verträgen
- Change Management als Erfolgsfaktor für IT-Projekte
- Offener Projekt Scope: Erfolgsstrategien für IT-Vertragsgestaltung
- IT-Projekte erfolgreich steuern – Projektabhängigkeiten im Blick
- Mitwirkungspflicht vs. Obliegenheit: Mitwirkungsleistungen im IT-Projekt
- Erfolgreiche IT-Projekte starten mit klaren Projektverträgen
Sie können diese Blog-Serie über den RSS-Feed abonnieren und werden von uns über neue Beiträge informiert.
