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

Transparenz als Schlüssel zum Erfolg: 20 Reflexionsfragen für moderne Organisationen

Transparenz ist das Herzstück erfolgreicher Teams. Sie schafft Vertrauen und fördert Zusammenarbeit. Wenn alle Zugang zu den notwendigen Informationen haben, können sie fundierte Entscheidungen treffen und gemeinsam Lösungen erarbeiten. Dies führt zu höherer Effizienz, schnelleren Entscheidungsprozessen und besseren Arbeitsergebnissen. Transparenz ist mehr als ein Schlagwort – es gilt, sie greifbar zu machen, ein gemeinsames Verständnis davon zu entwickeln und es in die Praxis umzusetzen. Wie das gelingt und welche Vorteile es für Euer Team und Eure Organisation bringt, erkunden wir im Folgenden.

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.

Zu viel zu tun? Planen Sie Ihre ideale Woche

Wir hören immer wieder, dass Teams zu viel zu tun haben. Aber woher wissen wir eigentlich, was zu viel genau bedeutet? Hier ist ein ungewöhnlicher Tipp: Treffen Sie Annahmen über eine gute Menge. Planen Sie eine ideale Woche.

Wenn dein Team die Anforderungen blockt: 12 Tipps für Product Owner*innen

Liebe Product Owners, wir müssen reden. Schon wieder eine Anforderung, die im Nirgendwo landet? Zeit, das Ganze anders anzugehen. Ihr kennt das Spiel: Anforderungen sind ausgearbeitet, und doch läuft es im Team holprig. Was fehlt? Oft sind es Klarheit, realistische Erwartungen und ein bisschen Fingerspitzengefühl. Doch keine Sorge! Mit ein paar praktischen Tipps könnt ihr Missverständnisse vermeiden, Blockaden umgehen und den Entwicklungsprozess so richtig in Fahrt bringen – natürlich in Zusammenarbeit mit eurem Scrum Master. Hier sind zwölf Regeln, die euch helfen, das Team auf Kurs zu bringen und das Chaos in produktive Zusammenarbeit zu verwandeln. Wir zeigen dabei auch, wo der Scrum Master unterstützen kann, damit ihr eure Rolle als Product Owner noch besser erfüllen könnt. Häufige Stolperfallen: Warum Anforderungen oft scheitern Bevor wir ins Eingemachte gehen, kurz zu den typischen Stolperfallen. „Klare Anforderungen“? Klingt gut, scheitert aber sehr häufig an der realen Praxis. ...

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.

Pragmatisch oder nur “Quick and Dirty”?

“Wir müssen aber pragmatisch vorgehen”, drängt der Kollege. Hm… Im Wörterbuch finde ich für “pragmatisch” in etwa: sachbezogenes, praktisches Handeln. Klingt gut. Leider zeigt sich in meinen Erfahrungen, dass pragmatisch für viele doch eher “quick and dirty” bedeutet. Es soll schnell fertig werden. Aber auf welche oder wessen Kosten? Wo ist die Grenze? Warum steht “praktisch” im Konflikt mit einem langfristigen “Nützlich”? Muss das sein?

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.

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.

5 Gründe, warum wir jetzt über die Zukunft nachdenken sollten

Wer hätte im Jahr 2019 gedacht, dass so viele Menschen heute im Home-Office arbeiten können und dass die Firma trotzdem funktioniert? Wer hätte damals gedacht, dass wir heute wie selbstverständlich KI-Werkzeuge nutzen können? Ich will mich nicht der Aussage anschließen, dass sich die Welt immer schneller dreht. Es ist egal, wie schnell sie sich dreht, weil es sich immer lohnt, über die Zukunft nachzudenken. Und das muss nicht kompliziert sein.

Meetings in Scrum Teams: Mehr Fokus, weniger Kontextwechsel

  Meetings in Scrum Teams: Mehr Fokus, weniger Kontextwechsel  „Wir arbeiten agil“ – das bedeutet für viele von uns: Daily Stand-up am Morgen, dann Refinement, dazwischen eine Demovorbereitung, später noch ein kurzes Scrum of Scrums (SoS) und am Nachmittag ein Community-Meeting. Gleichzeitig soll ich an meinen Sprint-Aufgaben arbeiten. Wenn dir diese Situation bekannt vorkommt, les dir gerne meinen Beitrag an. Hier sprechen wir über den Einfluss von häufigen Kontextwechseln auf die Arbeit in agilen Teams und zeigen Best Practices, um diese Wechsel zu minimieren. Viel Spaß & Let’s grow, Michi.  Foto von Matt Bero auf Unsplash