Vom MS-Project-Hype zum Agilitäts-Quickie: Warum Deutschlands Projektmanagement methodisch auf der Stelle tritt...und das nicht nur in Deutschland!
"Deep Method learning!" hinkt inzwischen schon auf einer Framework Prothese!
„Qualifiziertes Projektmanagement“ litt immer schon unter einem „Hinterherhinker Effekt“. Waren es in den 90ern bis ins neue Jahrtausend zwei Tage MS Project, sind es heute zwei Tage agile Frameworks. Tiefgehende Methodenkenntnisse sind immer noch Mangelware.
Leider muss ich nach fast 20 Jahren PMP Trainer immer noch erfahren, dass in den meisten Fällen nur für die Prüfung gelernt wird und nicht für die Umsetzung in der Praxis. So wird zum Beispiel in den meisten Unternehmen das Earned Value Management (Projektcontrolling) nicht umgesetzt, weil der Rollout als zu zeitintensiv wahrgenommen wird. Man setzt lieber Millionen von Euro in den Sand!
Ist ein Krawatten Träger ein Hinterherhinker?
Ich trag öfter mal eine Krawatte…und nicht nur zu Hochzeiten und Beerdigungen! Krawatten sieht man ja kaum noch. Manager und Politiker tragen Hemd fast ausschließlich offen. Sogar Karl Lauterbach hat seine Fliege abgelegt und zeigt Dekolleté. Wie kann das sein? Als ob die sich alle verabredet haben. Hat das was mit Schwarmdenken zu tun? Oder existiert ein politisches Diktat des krawattenlosen Lebens? Nein!
Letztens habe ich erfahren warum. Der bekannteste Philosoph Deutschlands, Professor David Precht sagte in einem Interview: „Krawattenträger bezeichnet man heutzutage als Hinterherhinker! Hinterherhinker sind Menschen, die keine Veränderung wünschen.“
Ich weiß jetzt nicht, ob das die Meinung David Prechts ist, oder ob er da nur eine allgemeine Meinung wiedergegeben hat. Was er sonst so sagt, fand ich mal ganz gut. Aber dieses „Krawattenstigma“, das kann ich so nicht nachvollziehen. Die Krawatte ist doch nur eine Marginalie.
Von daher habe ich mir heute eine Krawatte gegönnt. Ich wollte mal spüren, wie man sich so fühlt, als „Hinterherhinker“.
Mmmh, ne….. eigentlich kein Unterschied.
Genau genommen gibt es ja kaum noch Hinterherhinker. Frauen hinken ja schon per Dresscode nicht hinterher. Und Männer? Ich sehe kaum noch Männer mit Krawatte. Was doch so ein fehlendes Accessoire alles bewirken kann!
Nun ist eigentlich nicht mein Thema. Kommen wir zum eigentlichen Thema.
Qualifiziertes Projektmanagement oder Projektmanagement alter Schule?
Beispiele alter Schule und Träger von Krawatten: Der Deming Zyklus, Ischikawa Diagramm, Use Cases, quantitative Risikoanalyse oder die Theorie of Constraints von Elyuha Goldratt etc. etc. Das gesamte agile Konstrukt basiert auf der Engpasstheorie von Goldratt – also genau genommen, alte Schule. Leider haben viele Projektmanager des prognostizierenden PM, diese Theorie entweder nie kennen gelernt oder nicht richtig verstanden. Ähnliches gilt aber für die agilen Teams. Ich frage mich manchmal, wer die echten Hinterherhinker sind?
Engpass Problematik mit Überkapazitäten kompensieren!
Jedes Projekt verfügt über Engpässe. Nehmen wir als Beispiel ein Fußball Team. Ein Trainer plant jedes Tournier mit Überkapazitäten. Diese Überkapazitäten sitzen auf der Reservebank. Was passiert, wenn einer der Stammspieler ausfällt oder ihm die Luft ausgeht? Man greift auf die Reservebank zu.
Das hat man in Deutschland lange Zeit nicht verstanden, dass man auch in Projekten mit Überkapazitäten, besser gesagt mit „Unterlast“ planen muss. Das widerspricht natürlich eklatant dem schwäbischen Prinzip. Das schwäbische Prinzip kennt nur die Relation, „die Ressourcenkapazitäten äquivalent zur Last“ einzusetzen. Ressourcen, die nicht verplant sind? Wo kommen wir da hin?
Nun, zumindest im Fußball hat man begriffen, dass das schwäbische Prinzip nicht funktioniert!
Aber was bedeutet Unterlast für ein Projekt?
Ein Engpass wird konvergent eingeleitet, also n:1 Netzplanwege oder Arbeitspakete, und divergent weiter geführt, also 1:n Wege oder Arbeitspakete im Nachgang. Vor einem Engpass können sich daher Warteschlangen ergeben und nach dem Engpass Verzögerungen. Hinzu kommt, dass die konvergenten Arbeitspakete unterschiedliche Wahrscheinlichkeiten beinhalten, die auf den Engpass negativ wirken.
Dies ließe sich über die Wahrscheinlichkeitsrechnung ziemlich genau ermitteln. Engpässe werden durch Unterlast beherrscht. Und da es Engpässe gibt, die vorher nicht geplant werden können, greift das Unterlast Prinzip. Auf der Kostenseite erzeugt das Unterlast Prinzip unter dem Strich weit weniger Kosten und Stress, als das Äquivalenzprinzip und die damit verbundenen Pönalen oder die Unzufriedenheit des Kunden.
Das Unterlast Prinzip besagt: Nicht-Engpässe dürfen NIEMALS schneller oder mehr arbeiten, als der Engpass (das Nadelöhr) im System verarbeiten kann.
Um das Gesamtsystem zu optimieren, muss jede andere Ressource, jede vorgelagerte Stelle und jede Führungskraft ihre eigene lokale Auslastung bewusst unterlassen bzw. reduzieren. Ressourcen vor einem Engpass mit 100% Auslastung zu verplanen wiederspricht dem Unterlastprinzip.
Theorie of Constraints (TOC): Gewaltige Methode gegen Terminverschiebungen - auch im agilen PM!
In den agilen Methoden und der Lean/Scrum-Community wird dieses spezifische Phänomen oft als „ConstraintsBut“ oder „TOC-ScrumBut“ bezeichnet.
In der Praxis und in den Fachdiskussionen der agilen Szene passiert genau das: Die Theory of Constraints (TOC) von Eliyahu M. Goldratt wird sehr oft als „neuer Wein in alten Schläuchen“ verkauft – und nur selten transparent als das benannt, was sie ist.
Wenn man es präziser auf die Methodik bezieht, unterscheidet man zwei wesentliche Ausprägungen:
Kanban (bzw. „Scrum mit Kanban-Ergänzung“ / Theory of Constraints Integration): Eliyahu M. Goldratts Theory of Constraints (TOC) verlangt, den Systemengpass (Flaschenhals) zu identifizieren, ihn maximal auszunutzen und alle anderen Prozesse dem Engpass unterzuordnen (Schritt 1–3 der 5 Focus Steps). Wenn Teams Scrum nutzen, aber die starren Sprint-Grenzen durch kontinuierlichen Fluss und explizite WIP-Limits (Work in Process) ersetzen, um den Engpass zu managen, spricht man im agilen Kontext oft von Constraint-Driven Scrum oder TOC-Agile.
Das „ScrumBut“ bezüglich der Puffererstellung (Critical Chain Project Management / CCPM): Goldratts TOC führte im Projektmanagement zur Critical Chain-Methode, die Sicherheitsreserven aus einzelnen Arbeitspaketen streicht und stattdessen zentrale Puffer (Project Buffer / Feeding Buffer) nutzt. Das „ScrumBut“ entsteht hier meist dann, wenn Teams sagen: „Wir machen Scrum, ABER wir schätzen keine Story Points mehr und planen keine festen Sprints, sondern wir steuern das Backlog rein über Engpass-Kapazitäten und Durchsatzpuffer.“
In der Praxis wird diese Kombination – wenn sie positiv und zielgerichtet eingesetzt wird, um Systemengpässe zu steuern – meist unter dem Begriff Agile TOC (Theory of Constraints in Agile) gefasst. Handelt es sich um ein unvollständiges/verbogenes Scrum als Ausrede dafür, den Fluss am Engpass nicht konsequent zu optimieren, fällt es unter den klassischen Oberbegriff ScrumBut (mit TOC-Begründung).