#01 Lean Project Management - Motivation und Ankündigung

Das Projektmanagement unterliegt derzeit einem (vermeintlichen) Paradigmenwechsel: Von einer linearen, sequenziellen Vorgehensweise (Wasserfall) hin zu einer zyklischen, inkrementellen (Agilität). Im Diskurs von Wissenschaft und vor allem Praxis bilden sich dabei zunehmend auch hybride Ansätze heraus, die „das Beste aus beiden Welten“ vereinen sollen.

 

Dabei lässt sich feststellen, dass die vermeintlich gegenüberstehenden Ansätze bei genauer Betrachtung viele Gemeinsamkeiten haben (können) − auch wenn sie ohne Zweifel unterschiedliche Planungs- und Steuerungsphilosophien betonen und hervorheben sowie entsprechende Methoden anbieten (z.B. Scrum).

 

 

„War früher alles schlecht?“ Diese Frage muss man sich unweigerlich stellen, wenn man den aktuellen Hype um das Thema „agile Projekte“ verfolgt. Viele empirische Untersuchungen – allen voran der allseits zitierte CHAOS Report der Standish Group lassen diesen Schluss zu. Immerhin wurden dort nach eigenen Angaben seit 1994 40 bis 50 Tsd. (IT-) Projekte untersucht. Im Report 2015 wird angeben, dass nur 11% der mehr als 10 Tsd. untersuchten Projekte „erfolgreich“ gewesen seien, der Rest in Sachen Termineinhaltung, Leistungserbringung und/oder Kosten nicht im Zielkorridor liegt oder gar gänzlich gescheitert. Anders bei Agilen: Dort beträgt die Erfolgsquote immerhin 39%. Desweitern wird ein Zusammenhang mit der Größe der Projekte aufgezeigt: Unabhängig vom Vorgehensmodell scheitern größere Projekte öfter als kleine. Andere Leuchtturmprojekte wie der ebenfalls vielzitierte Flughafen BER zeugen auch nicht gerade von einem erfolgreichen Reifegrad der (Groß-) Projekte.

 

 

Der einfache Schluss aus dem oben genannten wäre, dass Projekte, welche nach den klassischen Modellen wie z.B. des PMI, der IPMA oder nach PRINCE2 durchgeführt strukturell bedingt schlechtere Erfolgsaussichten hätten. Was aber, wenn schlichtweg die Anwendung der „alten“ PM-Methoden in vielen Fällen nicht zielführend durchgeführt wurde? Immerhin zeugen ausgezeichnete Projekte in Deutschland (GPM) und weltweit (IPMA, PMI) davon, dass Projekte erfolgreich und „mit Plan“ durchgeführt werden können.

 

 

Und lässt sich Agilität so einfach bspw. auf Bauprojekte übertragen?

 

Abbildung 1: "Agiler Hausbau"?
Abbildung 1: "Agiler Hausbau"?

 

Die am meisten im Agilen verwendete Methode ist Scrum. Scrum hat seine Wurzeln in IT-Entwicklungsprojekten und geht im Original von einer Teamgröße von ca. sieben Mitarbeitern aus. Ein solches Projekt gehört also generell zu den kleinen. Insofern haben sich in den letzten Jahren Versuche herausbildet, den Scrum-Ansatz auf größere Projektkontexte, welche in der Praxis großer Organisationen Gang und Gebe sind, zu skalieren. Dazu gehören etwas das Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS) oder Nexus. Auch wird zunehmend die Übertragbarkeit auf andere Projektarten, wie etwa die Produktentwicklung untersucht.

 

 

Sicherlich ist die Erfolgsgeschichte von Scrum auch dessen konzeptioneller Leichtgewichtigkeit verdanken. Immerhin passt das Originalskript von Schwaber und Sutherland in der aktuellen Fassung auf 17 Seiten! Andere Werke, die weniger eine konkrete Methode beschreiben, sondern vielmehr einen „Body of Knowledge“ darstellen kommen da auf viele hundert bis tausende Seiten. Dazu gehören natürlich der Project Management Body of Knowledge von PMI, aber nicht zuletzt auch das PM3 der GPM. Auch die aktuellen Zahlen der PRINCE2-Zertifizierungen, die sich auf über 1,2 Millionen Zertifizierte weltweit belaufen, zeigen auf: Die Praxis verlangt nach leichtfüßigeren PM-Systemen.

 

 

Insbesondere für KMU scheinen die Flaggschiffe des PM oftmals zu schwergewichtig und finden daher lange keine flächendeckende Verbreitung. Da kommen die schlanken Ansätze des Agilen gerade recht, welche in vielen Bereichen als konkrete Anwendung von Lean Thinking zu erkennen sind (auch wenn der Begriff bei Schwaber/Sutherland nicht auftaucht). Allerdings ist leicht festzustellen, dass die bekannten agilen Methoden, zu denen neben Scrum oftmals auch Xtreme Programming und der Einsatz von Kanban gezählt werden, keinen vollwertiges PM-System darstellen, fehlen doch wesentliche Disziplinen wie Risiko-, Stakeholder- oder Vertragsmanagement gänzlich in diesen Konzepten.

 

 

Ein zeitgemäßer PM-Ansatz sollte das „Beste aus diesen Welten“ generalisieren und in einem universelleren − einem „Lean Project Management“-Ansatz − vereinen und operationalisieren. Lean PM spannt dabei den Bogen im Sinne eines modernen, zielgerichteten und flexiblen Projektmanagements (siehe Abbildung 2).

 

Lean Project Management vereint die PM-Welten.
Abbildung 2: Lean Project Management vereint die PM-Welten

 

Anspruch des Lean PM-Ansatzes – der Begriff wurde erstmalig bereits 2003 in einer Veröffentlichung von Ballard erwähnt – ist es, ein vollwertiges PM-System zu liefern, welches es Projekten ermöglicht, mit weniger Aufwand mehr Wert im Sinne des Projektnutzens zu erzielen (vgl. Abbildung 3).

 

Nutzen von Lean PM, Magisches Dreieck
Abbildung 3: Das Magische Dreieck und der Nutzen von Lean PM

Lean PM …

  • hilft durch den Fokus auf das Wesentliche und die Vermeidung von Unnötigem („Verschwendung“), die Projekte zügig ans Ziel zu führen und die Projektebudgets einzuhalten.
  • stellt den Kundenwunsch in den Fokus. Der Kunde definiert Wert und Wertschöpfung. Kundenwünsche werden in konkrete, messbare CTQ-Anforderungen (Critical to Quality) für den Projektalltag übersetzt.
  • ist ressourcenschonend, weil Verschwendung und Unnötiges vermieden wird.
  • stellt alle Anforderungen an Dokumentation, Formalitäten, Quality-Gates etc. auf den Prüfstand und misst diese individuell daran, welchen Mehrwert sie liefern. Was keine Wertschöpfung darstellt, wird nicht gemacht.

 

 Mit dem Lean PM verfolgen wir das Ziel, bestehende Ansätze zum Lean PM weiter zu entwickeln und einen generell einsetzbaren, leichtgewichtigen Ansatz zu formulieren, der leicht adaptierbar ist und der offen ist für eine flexible Anwendung zwischen Planungssicherheit auf der einen und Trial & Error (oder wie die Agilisten es nennen: „Inspect & Adapt“) auf der anderen Seite. Einen (sinnvollen) Plan zu haben wird dabei nicht grundsätzlich als etwas Schlechtes angesehen (vgl. auch Abbildung 1).

 

Es gilt also im ersten Schritt, die grundlegenden Begriffe des Lean Thinkings mit Bezug zum Projektmanagement auszuprägen:

 

·        Kunde und Kundenwert

 

·        Wertstrom

 

·        Fluss

 

·        Pull

 

·        Perfektion

 

Dabei ist davon auszugehen, dass eine differenzierende Betrachtung zwischen den PM-Prozessen im engeren Sinn der Planung und Steuerung des Projektes und der fachlich-fortschreitenden Projektbearbeitung relevant ist. In diesem Zusammenhang wird daher auch der Begriff

 

·        Produkt

 

mit Bezug auf das Projektgeschäft charakterisiert, Ebenso der für das Lean Thinking fundamental Begriff der

 

·        Verschwendung.

 

 

Unser Ziel ist es, das „Beste aus den Welten“ zu generalisieren und in einem universelleren − einem „Lean Project Management“-Ansatz − zu vereinen und zu operationalisieren. Dazu werden an dieser Stelle zukünftig Impulse veröffentlicht. Feedback ist dabei ausdrücklich erwünscht.

 

Kommentar schreiben

Kommentare: 1
  • #1

    Dieter Bertsch (Dienstag, 16 Oktober 2018 16:48)

    Sehr geehrter Herr Prof. Hüsselmann,
    immer wenn es um „hybrides“ Project Management geht, werde ich hellhörig. So stellen Sie in Abbildung 2 plangetriebenes („klassisches“) und agiles (wertegetriebenes) Vorgehen als Gegenpole unter den Schirm „Lean Project Management“ dar.

    Ich gehe davon aus, dass wir uns einig sind, dass agile Methoden den Prinzipien von Lean Management / Lean Software Development (vergl. T. & M. Poppendieck) folgen. Beim plangetriebenen Ansatz ist das nicht der Fall: Es folgt dem Push-Prinzip.

    So sind m.E. das „Push“- bzw. das „Pull“-Prinzip die zwei grundlegenden Paradigmen, die plan- und wertegetriebenes Projektmanagement unterscheiden.

    Und diese beiden konträren Ansätze lassen sich auch nicht in einem „hybriden“ Projekt Management zusammen bringen: Ich muss mich entscheiden, ob ich nach dem Push-Prinzip arbeite oder das Paradigma des Pull-Prinzips zugrunde lege.

    Dementsprechend vertrete ich die Meinung, dass es keinen wirklich hybriden Ansatz gibt!

    Natürlich, kann man den Push-Ansatz durch Techniken & Tools der agilen Methoden anreichern; es bleibt aber ein „klassischer“/plangetriebener Ansatz.
    Und ebenso kann ich (nein: muss ich sogar) Scrum (als Vertreter agiler Methoden) um Disziplinen wie Risiko- und Stakeholder Management anreichern. Es bleibt aber weiterhin ein agiler Ansatz.

    Aber ich muss also eine Entscheidung treffen – kann aber nicht beides/hybrid sein.