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 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 . 

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.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

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.

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?

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.

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.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.