Agiles Projektmanagement – Projektentwicklung mit Scrum, Kanban & Co.

9. Vertragsgestaltung bei Webprojekten
Dr. Matthias Orthwein, LL.M. (Boston) / Daniel Meßmer
SKW Schwarz Rechtsanwälte
9.1. Klassisches oder agiles Projektmanagement?
„Agilität" ist auf dem Vormarsch. Im Vergleich zu einem klassischen Projektmanagement
werden agile Vorgehensweisen vor allem als kundengerechter, schneller und
kostengünstiger gepriesen. Warum das klassische Projektmanagement weiterhin eine
Daseinsberechtigung hat und welche rechtlichen und vertragsgestalterischen Stolpersteine
agile Projektmethoden mit sich bringen, wird in dem folgenden Beitrag dargestellt.
Wer plant, ein Webprojekt zu beauftragen oder seinen Online-Shop überarbeiten zu lassen,
hat meist eine gewisse Vorstellung von dem zu erzielenden Ergebnis. Oft stehen dabei zwar
Funktionalitäten im Vordergrund; auch Design, Ergonometrie sowie look-and-feel werden
jedoch eine wesentliche Rolle spielen. Der Detailgrad der Vorstellung vor Vertragsschluss
variiert freilich sehr stark und ist von der (häufig fehlenden) Expertise des Kunden abhängig.
9.2. Probleme des klassischen „Wasserfalls“
Nach einer klassischen Vorgehensweise entsprechend dem Wasserfallmodell steht vor der
eigentlichen Projektumsetzung durch den Entwickler zunächst die Projektplanung. Ergebnis
dieser Planung ist in der Regel ein Feinkonzept (Pflichtenheft), in welchem das Projektziel
vollständig umschrieben wird. Eventuell basiert dieses auf einem Lastenheft, in dem der
Kunde seine Anforderungen an das Projektziel grob beschrieben hat. Das Pflichtenheft wird
dabei in seltenen Fällen vom Kunden selbst, in den meisten Fällen jedoch gemeinsam von
Kunde und Entwickler erstellt. Erst nach Abschluss dieser Planung, also mit Fertigstellung
des Pflichtenheftes, beginnt die eigentliche Realisierung des Webprojektes. Die
Realisierungsphase baut dabei auf dem Ergebnis der Planungsphase auf.
Dieses lineare Vorgehen birgt allerdings eine Reihe systemimmanenter Projektrisiken, die
nicht selten Auslöser von Auseinandersetzungen, Verzögerungen oder sogar
Projektabbrüchen sind. Dem Kunden ist es auf der vorgelagerten, abstrakten Ebene häufig
nicht möglich, vor der Projektumsetzung die wichtigen von den unwichtigen oder
überflüssigen Funktionen und Features zu unterscheiden. Aus Angst, in der Zukunft
erforderliche oder nützliche Funktionen zu übersehen, ist das Pflichtenheft deshalb oft
„überladen“. Das führt nicht nur zu einer Verlängerung des Projektzeitraums, sondern auch
zu unnötig hohen Kosten für den Auftraggeber.
Ein ganz wesentliches Problem der klassischen Projektmethode liegt zudem außerhalb der
Kontrolle von Auftraggeber und Softwareentwickler: Es ist häufig nicht möglich, bereits bei
der Projektplanung vorauszusehen, welche Funktionen oder Schnittstellen zum Zeitpunkt der
Projektbeendigung tatsächlich erforderlich, aktuell und „state-of-the-art“ sind. Seit jeher
werden deswegen vertraglich Prozesse zur Aktualisierung des Vertragsgegenstandes im
Realisierungsprozess vereinbart (sog. Change Management). Damit soll das Projektziel
entsprechend der aktuellen technologischen Entwicklung und den neuen Anforderungen des
Kunden in der Umsetzungsphase angepasst werden. Der im klassischen
Projektmanagement angelegte statische Prozess wird damit flexibler gestaltet.
In der Praxis gibt das Verfahren zur Änderung des Vertragsgegenstandes allerdings häufig
Anlass zu Diskussionen über Machbarkeit, Umfang, Zeitverzögerung und zusätzliche
Kosten. Gerade in einem stark volatilen technologischen Umfeld wie dem von Webprojekten
birgt das Change Management deswegen ein nicht unerhebliches Streit- und Risikopotential.
Der Grund dafür liegt im Change Management als Flexibilisierungsinstrument selbst. Denn
TechDivision GmbH – Agiles Projektmanagement
36