Verträge für Projekte mit agilem Vorgehen (Teil 2/4)

Ein Thema, mit dem agile Projektmanager Abende füllen können, ist die Frage: Wie gestalte ich die Vertragsbeziehung zwischen Kunde und agilem Dienstleister? Im ersten Teil haben wir uns die möglichen Vertragsarten angesehen (/1/). Für ein Projekt ist ein Dienstvertrag an guter Startpunkt. Aber wie gehen wir denn nun genau vor, wenn wir Leistungen nicht von vorn herein spezifizieren können? Dazu sollten wir erstmal einen Blick auf die Natur des Projekts werfen, dass beide Parteien planen. Darum geht es in diesem Beitrag.


In unseren Seminaren, an denen häufig Mitarbeiter von Lieferantenseite teilnehmen, hören wir immer wieder die gleiche Klage: Es gibt kein klares Ziel und keine festen Anforderungen für das Projekt. Die Anforderungen sind unklar und verändern sich.

Interessant ist jetzt die Frage, ob der Kunde die Anforderungen überhaupt festlegen kann. Auf Lieferantenseite wird ja häufig vermutet, dass der Kunde keine Lust oder Kompetenz dazu hat.

Wer das eine oder andere Buch über Scrum oder agiles Projektmanagement gelesen hat, weiß, dass es nur in sehr speziellen Kontexten möglich ist, Anforderungen festzulegen. Es gibt dazu zwei Modelle, die uns weiterhelfen. Beide treffen ähnliche Aussagen (in Bezug auf Projekte).

1. Das Rautenmodell von Shenhar und Dvir (/2/): Die beiden Wissenschaftler haben in den letzten 20 Jahren 600 Projekte profiliert. Ihr Modell bewertet die Unsicherheit von Projekterfolgen auf vier Achsen (Neuheit, Technologie, Komplexität, Zeitdruck).
2. Ein Modell von Ralph Douglas Stacey (/3/), der viel über Komplexität und Management geschrieben hat - das sog. Stacey-Diagramm. (Professor Robert Geyer von Lancaster University erklärt das Diagramm in einem Video bei Vimeo.)

Complexity and the Stacey Diagram from Brightmoon Media on Vimeo.

Ich fasse es mal so zusammen: Stellen wir uns ein Koordinatensystem mit 2 Achsen vor. Eine Achse steht für die Unsicherheit der Anforderungen, die andere für die Unsicherheit im Umgang mit Technologie.

Unsicherheit der Anforderungen:

• Stufe 1 - Der Kunde versteht genau, was der Lieferant liefert, z. B. ein Update einer bestehenden Software.
• Stufe 2 - Der Kunde versteht höchstens die Hälfte von dem, was der Lieferant liefert, z. B. eine ganz neue Software mit ganz anderer Oberfläche oder Bedienkonzept. Aber die Probleme, die die Software löst, sind im wesentlichen bekannt.
• Stufe 3 - Der Kunde hat das, was der Lieferant liefert, noch nie gesehen oder erlebt. Er kann sich das Ergebnis nicht vorstellen. Dies wäre ein IT-System, das sich der Kunde gar nicht vorstellen kann, sozusagen der Segway unter den IT-Systemen (/4/).

Unsicherheit der Technologien:

• Stufe 1 - Der Lieferant kennt die Technologien, die er einsetzt ganz genau und hat sich schon mehrfach verwendet.
• Stufe 2 - Der Lieferant will zur Hälfte Technologien nutzen, die er vorher gar nicht kannte.
• Stufe 3 - Der Lieferant nutzt nur neue Technologien, die er vorher nicht kannte.
• Stufe 4 - Der Lieferant muss die Technologien, die er zur Lösung des Problems braucht, erst einmal selbst entwickeln. Es gibt sie bisher gar nicht. Für typische IT-Projekten in Unternehmen blende ich diese Stufe aus.

Für ein Projekt eignet sich ein Werkvertrag, wenn wir uns auf beiden Achsen in Stufe 1 befinden. Kunde und Lieferant haben viel Erfahrung und können sich schnell auf den Liefergegenstand einigen. Genau genommen ist so etwas kein Projekt für mich. Wenn beide Seiten sich so gut auskennen, ist es vermutlich eher ein Routineauftrag.

Abb. 1: Bereiche, in denen Werkverträge möglich sind

Ein Werkvertrag ist auch möglich, wenn man sich in einem Bereich auf Stufe 1 und im anderen auf Stufe 2 befindet (siehe Abb. 1). In allen anderen Bereichen wird es sehr schwer für die Vertragsparteien werden, sich auf ein Ergebnis und ein Vorgehen zu einigen. Beiden ist nicht klar, was rauskommen soll und der Lieferant hat eine steile Lernkurve vor sich, die keine präzisen Vorhersagen über Zeit und Kosten zulassen.

In den anderen Stufen ist eine agile Arbeitsweise besser geeignet, um sich an das richtige Ergebnis heranzutasten. Bei der Chaos-Stufe - d. h. hohe Unsicherheit bei Anforderungen und Technik - möchte ich mal wissen, wozu man eigentlich einen Vertrag braucht.

Fassen wir also zusammen, dass es viele Projektsituationen gibt, in denen sich die Anforderungen gar nicht festlegen lassen. Da bleibt nur der Dienstvertrag und iteratives Vorgehen. Tatsächlich empfehlen dies auch Shenhar und Dvir:

• Je neuer ein Ergebnis ist (also je weniger der Kunde das Ergebnis beschreiben kann), desto später dürfen erst die Anforderungen festgelegt werden. 
• Je unbekannter die Technologie für den Lieferanten ist, desto später wird das Design festgelegt.

Es gibt dennoch eine Methode, mit der beide Seiten herausfinden, was das Projekt genau liefern soll. Und zwar unabhängig von der IT-Lösung. Wie das geht, erkläre ich im nächsten Teil.

Anmerkungen

• /1/Jan Fischbach: Verträge für Projekte mit agilem Vorgehen (Teil 1/4), Teamworkblog, erschienen am 06. Mai 2013, abrufbar unter http://www.teamworkblog.de/2013/05/vertrage-fur-projekte-mit-agilem.html
• /2/ Shenhar, Aaron J., and Dov Dvir. Reinventing Project Management: The Diamond Approach to Successful Growth & Innovation. 1st ed. Mcgraw-Hill Professional, 2007.
• /3/ Wikipedia, Stichwort "Ralph Douglas Stacey", abrufbar unter http://en.wikipedia.org/wiki/Ralph_Douglas_Stacey 
• /4/ Shenhar und Dvir berichten in Reinventing Project Management über das Segway-Project. Eine besondere Schwierigkeit war, dass die Kunden überhaupt nicht wußten, was sie mit dem Segway anfangen sollten. Die Entwickler dachten in ihren Business-Case, dass der Segway als  ernsthaftes Verkehrsmittel vom Markt angenommen wird. Heute wissen wir, das er vor allem als Mode- oder Spassfahrzeug benutzt wird.