Sind agile Methoden (wie Scrum) für alle Projekte geeignet?

Stehen sich agiles und traditionelles Projektmanagement als Gegner gegenüber? Versuchen die neueren Methoden die herkömmlichen zu verdrängen, bis sie ganz verschwunden sind? Gegen diese Art der Darstellung gibt es auch den Standpunkt, dass die traditionellen PM-Methoden wie z.B. PRINCE2 nach wie vor ihre Berechtigung haben und Scrum sie nur ergänzt. Dafür einige Argumente.

Projekte sind immer mit Unsicherheit verbunden

Was ist ein Projekt? Üblich sind so Definitionen wie in Wikipedia: „Ein Projekt ist ein zielgerichtetes, einmaliges Vorhaben, das aus einem Satz von abgestimmten, gesteuerten Tätigkeiten … usw.“ /Anmerkung 1/ Wenn ein Architekt ein Haus baut, ist das dann ein Projekt? „Einmalig“ ist es doch sicher nicht – schließlich ist das sein Brotberuf. Aber trotzdem sprechen Architekten von „Bauprojekten“. Das Kriterium „Einmaligkeit“ bringt uns nicht sehr viel weiter.

Einleuchtender ist mir die Definition, die ich von Jan Fischbach gelernt habe:

Projektarbeit bedeutet, nützliche Ergebnisse unter Unsicherheit zu liefern.

Zwei israelische Autoren haben versucht, diesen Aspekt zu systematisieren /Anmerkung 2/. Aufgrund einer Untersuchung einer großen Anzahl von Projekten sind sie zu der These gekommen,

1. dass alle Projekte durch unhintergehbare Unsicherheiten gekennzeichnet sind, d. h. durch Unsicherheiten, die nicht durch einen höheren Aufwand bei der initialen Projektplanung beseitigt werden können und
2. dass man im Wesentlichen vier Dimensionen von Unsicherheit identifizieren kann.

Daraus ist ihr sog. „Rautenmodell“ entstanden:

Die vier Unsicherheitsdimensionen werden wie folgt definiert:

1. Neuheitsgrad des „Projektprodukts“ für die Projektkunden
2. Grad der Übung des Projektteams mit den zu verwendenden Werkzeugen und Methoden
3. Komplexität des Projektprodukts
4. Zeitdruck.

Im englischen Original von 2016 lauten die detaillierten Definitionen so:

Die vier Abstufungen sollen hier nur bezüglich der Dimension „Neuheitsgrad“ erklärt werden:

• „Ableitung“: Verbesserung eines existierenden Produkts (z.B. eine neue Farboption für einen MP3-Player oder eine verbesserte Suchfunktion in einem DMS)
• „Grundneuheit“: eine neue Generation einer existierenden Produktlinie (z.B. eine neuer Auto- oder Flugzeugtyp)
• „Marktneuheit“: Ein Produkt, das es auf einem Markt schon gibt, auf einen anderen Markt in anpassen  (z. B. der erste PC oder der Mikrowellenherd für Privathaushalte)
• „Weltneuheit“: Ein Produkt, das es vorher überhaupt noch nie gab  (z. B. das erste Post-it).

Jede Dimension von Unsicherheit ist ein Argument für ein iteratives und/oder inkrementelles (letztlich also: agiles) Vorgehen. Im Falle der Produktneuheit muss man sich schnell Feedback von den Kunden besorgen, im Falle neuer Arbeitswerkzeuge muss man die erst einmal anzuwenden lernen oder sie sogar neu entwickeln usw.

Wenn wir ein konkretes Projekt planen, hilft uns deshalb  das Rautenmodell von Shenhar und Dvir bei der Entscheidung, ob es von wenig Unsicherheit gekennzeichnet ist oder ob wir in einer oder mehreren Dimensionen vor großen Unsicherheiten stehen.

Nehmen wir ein Projekt „Einfamilienhaus bauen“. Hier gibt es auch Unsicherheiten, aber sie sind relativ gering. Vermutlich ergibt sich ein Projektprofil wie in Abbildung 2. Solche Projekte kann man mit klassischen Projektmanagement-Methoden („Wasserfall“) nach wie vor gut bewältigen.

Nehmen wir jetzt aber ein Projekt wie „Einführung der E-Akte in einer Kommunalverwaltung“. Nicht umsonst scheitern solche Projekte sehr häufig (Angaben z.B. des Bundesverwaltungsamtes), was nicht nur auf ein hohes Maß an Projektrisiken hinweist, sondern vor allem auf eine deutliche Unterschätzung dieser Risiken durch die Projektverantwortlichen.

Aufgrund unserer Projekterfahrungen gehen wir davon aus, dass in E-Akten-Projekten:

• der Neuheitsgrad für die künftigen Anwender („Projektkunden“) bei Level 3 „Markneuheit“ liegt – die Arbeitsweisen unterscheiden sich stark von denen der Papierwelt;
• die neu zu erlernenden Arbeitsmethoden für die verantwortlichen Administratoren (softwareseitig) und die sog. Strukturredakteure (auf der Seite der Geschäftslogik) mindestens den Neuigkeitsgrad Medium-Tech aufweisen;
• die soziale und technische Komplexität hoch ist (zwischen „Montage“ und „System“), weil sehr viele wechselwirkende Schnittstellen integriert werden müssen und eine hohe soziale Komplexität besteht (widerstreitende Stakeholder-Interessen);
• nur der Zeitdruck ist in der Regel nicht sehr hoch (durch Projektverzögerung wird zwar viel Geld verloren, das ist den verantwortlichen Führungskräften aber meist nicht bewusst – d.h. es herrscht kein subjektiver Wille, das Projekt zügig zum Erfolg zu führen; erst in letzter Zeit gibt es erste, durch den Gesetzgeber verordneten Deadlines).

D.h. für derartige Projekte sind agile Methoden fast unumgänglich, will man sie zum Erfolg führen.

 

Anmerkungen

/1/ Wikipedia, Artikel „Projekt“ (abgerufen am 28.11.2019). Siehe auch DIN 69901.

/2/ Aaron J. Shenhar, Dov Dvir: Reinventing Project Management : The Diamond Approach To Successful Growth And Innovation. Boston, Massachusetts: Harvard Business Press, 2013;

Aaron J. Shenhar, Vered Holzmann, Benjamin Melamed, Yao Zhao: The Challenge of Innovation in Highly Complex Projects: What Can We Learn
from Boeing’ s Dreamliner Experience?, in: Project Management Journal, April/Mai 2016, p. 62-78

Den Hinweis auf diese Studien verdanke ich ebenfalls Jan Fischbach.