Direkt zum Hauptbereich

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.

Kommentare

Beliebte Posts aus diesem Blog

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

2 Tätigkeiten, bevor man agile Arbeitsweisen nutzt

Wenn Teams und Organisationen sich mit Agilität beschäftigen, hoffen sie auf eine schnelle Lösung für ihre Probleme. Mit Scrum und Kanban sollte es doch sofort und spürbar besser werden. Abgesehen davon, dass diese Teams vielleicht noch nicht wissen, warum Scrum und Kanban funktionieren, sind aus meiner Sicht zwei wichtige Fragen noch nicht beantwortet.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.