Diskussion:Critical-Chain-Projektmanagement

Vorschlag zur Überarbeitung von Critical Chain Management:

Critical Chain Management oder Critical Chain Project Management (CCPM)

Ist eine Managementmethode für Multiprojekt-Organisationen und für einzelne Projekte. CCPM ist eine der Standard-Lösungen der Theory of Constraints (ToC) von Dr. Eliyahu M. Goldratt.

Die zentralen Bausteine von CCPM sind:

(1) Projekte staffeln

Multiprojekt-Organisationen leiden oft unter: - De-Synchronisierung (die verschiedenen Organisationseinheiten, die gleichzeitig an mehreren Projekten arbeiten, geben den Projekten unterschiedliche Priorität) - Schädliches Multitasking (Ressourcen wechseln zwischen verschiedenen Projekten hin und her) - Unterbesetzung der Projekte (Projekte erhalten weniger als die optimale Ressourcenbesetzung – d.h. weniger als sie für höchstmögliche Geschwindigkeit bräuchten) Durch diese Mechanismen verlängert sich die Durchlaufzeit von Projekten (schon im Plan) und wird es schwer, die versprochenen Termine (im IST) einzuhalten.

CCPM staffelt daher die Projekte, so dass die obigen Effekte deutlich abnehmen. Dadurch werden Projekte kürzer, was wiederum die Staffelung ermöglicht.

(2) Sicherheiten bündeln

Mitarbeiter in Projekten werden daran gemessen, ob sie ihre individuellen Termine einhalten. Diese Vorgehensweise zwingt sie dazu, individuelle Zeitpuffer einzuplanen (damit sie trotz auftretender Schwierigkeiten und Störungen pünktlich liefern können), diese Zeitpuffer aber auch selbst zu verbrauchen (damit zukünftige Zeitangaben nicht gekürzt werden). Dadurch verlängert sich die Durchlaufzeit von Projekten (schon im Plan) und können auftretende Verspätungen nur schwer wieder aufgeholt werden.

CCPM bündelt daher die Sicherheiten am Ende des Projektes, damit sie dann zur Verfügung stehen, wenn sie tatsächlich benötigt werden.

(3) Eindeutige Prioritäten

Trotz bester Planung wird es bei der Umsetzung von Projekten vorkommen, dass mehrere Projekte gleichzeitig auf eine Ressource zugreifen wollen. Dann besteht wieder das Risiko der De-Synchronisation und des schädlichen Multitaskings.

CCPM setzt daher eindeutige Prioritäten, indem der Projektfortschritt ins Verhältnis zum Pufferverbrauch gesetzt wird. Der daraus errechnete Index bestimmt eindeutig die Priorität einer Aufgabe.

-- Uwe Techt 21:29, 10. Nov. 2007 (CET)

Der Vorschlag wurde mittlerweile Umgesetzt - ist daher angenommen :-) -- Speed4Projects 22:01, 23. Jan. 2010 (CET)

---

Konkretisierung operative Steuerung über Fortschritt zu Pufferverbrauch

Hierbei wird immer das Arbeitspaket des Projektes bevorzugt, das das schlechteste Verhältnis von Fortschritt auf der Kritischen Kette zu Pufferverbrauch aufweist

Frage: Welches ist denn das schlechteste Verhältnis? Das größere? Das kleinere? Welches sonst? Das ist zu mehrdeutig. Könnte man das präzisieren oder mit einem Beispiel unterlegen? -- 89.246.167.137 11:59, 22. Dez. 2010 (CET)

Antwort: das Verhältnis ist einfach der Quotient aus Fortschritt (auf der kritischen Kette) zu Pufferverbrauch. In der Praxis gibt es aber Heuristiken die dies für Arbeitspakete auf Zulieferketten und Zulieferpuffer erweitern. Die Erfahrung zeigt, dass es gar nicht so wichtig ist, dass die Reihenfolge 100%ig stimmt. Das Verfahren hat so viel Reserve und Toleranz, dass es gar nich so genau darauf ankommt.--Speed4Projects 13:50, 19. Mär. 2011 (CET)

Fehlende Belege

Gleich in der Einleitung des Artikels taucht der Satz "Typischerweise steigt hierdurch die Zuverlässigkeit der Termineinhaltung auf über 95 % und die Durchlaufzeiten der Projekte verkürzen sich um mehr als 25 %" auf. Dieser ist aus Wolfram Müllers Text "CCPM der Joker des Lean SW Development" übernommen, wo sich allerdings auch keine zugehörige Referenz einer entsprechenden Studie findet. Da Müllers Dokument, so lesenswert es auch ist, den Anstrich einer Reklame-Information für die Methode hat, ist dies kritisch zu hinterfragen. Auf jeden Fall fehlt eine Referenz und auch inhaltlich eine Aussage, gegenüber was die 25%-Verkürzung erscheinen soll. (nicht signierter Beitrag von Gernotti (Diskussion | Beiträge) 11:04, 1. Mär. 2011 (CET))

Ja leider gibt es noch keine Umfassende Studie, die die Ergebnisse zusammenfasst. Des weiteren sind die Ergebnisse oft nicht vergleichbar (gerade beim Durchsatz aber auch der Termintreue). Bei meinem letzten Projekt habe ich innerhalb von 3 Monate eine Verdopplung der Projektabschlußrate erreicht und eine Termintreue von 86% bezogen auf den ersten zugesagten Termin. Wobei die Projekt die die Termine nicht gehalten haben nicht nach CCPM geführt wurden - also ist die Termintreue eigentlich bei 98% gewesen. Aber so sind Statistiken - sie haben alle ihre Schwächen.

Die Hauptquelle für Testimonials sind aktuell: deutsch: http://www.vistem.eu/de/ergebnisse-fallstudien.html englisch: http://videos.realization.com/results/default.aspx

die 95% Termintreue und 25% Verkürzung sind letzt endlich defensive Zahlen ;-) --Speed4Projects 13:50, 19. Mär. 2011 (CET)

Was spricht gegen Löschung der Werbebehauptung zur Wirkung von CCPM?

• Der Satz "Typischerweise steigt hierdurch die Zuverlässigkeit der Termineinhaltung auf über 95 % und die Durchlaufzeiten der Projekte verkürzen sich um mehr als 25 %." ist meiner Meinung nach einer Enzyklopädie unwürdig. Die Aussage, es handele sich um eine defensive Behauptung ist genauso wenig untermauert wie die ursprgl. Aussage.

Spricht irgend ein Argument gegen eine Löschung? Der Informationswert des Artikels wird m.M. nicht geschwächt.

• Die Verwendung des Wortes "typischerweise" auch an anderen Stellen ist ein zuverlässiger Hinweis auf mangelnde Belege.
• Statt "Das schädliche Multitasking wird vermieden, indem die Menge der Projekte auf ein sinnvolles Maß begrenzt" sollte es m.M. nach heissen "Das schädliche Multitasking soll vermieden werden, indem die Menge der Projekte begrenzt wird" -> damit ist inhaltlich zum CCPM nichts verloren, aber die nicht-belegte Wirksamkeit wird nicht zum Thema und das gerne bemühte aber nicht klar umrissene "sinnvolle Mass" vermieden.

--Gruelz (Diskussion) 16:50, 17. Apr. 2013 (CEST)

Ich bin ebenfalls der Meinung, dass die unreflektierten Werbebehauptungen durch neutrale und verifizierte Fakten ersetzt werden sollten, auch wenn dies einer Streichung eines großen Teils des Textes bedeuten sollte. --Schweigstill (Diskussion) 09:07, 28. Okt. 2013 (CET)

Gegen die Entfernung der unbelegten Behauptungen spricht nichts und ich habe das auch gleich mal umgesetzt. --Millbart talk 13:52, 20. Sep. 2017 (CEST)

Berechnung der Verkürzung für mich nicht nachvollziehbar

Ohne die Wirksamkeit des CCPM in Frage stellen zu wollen, kann ich der Berechnung der 25%en Verkürzung der Durchlaufzeit nicht ganz folgen. Jede Aufgabe verbraucht nach pessimistischer Schätzung Tpess = Topt + Tbuf, wobei Topt die optimistische Schätzung und Tbuf der Sicherheitszuschlag sind. von Topt und Tbuf weiß ich nur, dass sie nicht negativ sind. Wenn ich nun eine Schätzung Tavg abgebe. die ich wohl mit 50%er Wahrscheinlichkeit einhalten kann, dann nährt dass zwar die Unterstellung, dass verfrühte und verspätete Fertigstellungen sich in etwa die Waage halten, sagt aber nichts darüber aus, wie viel kürzer die individuellen Puffer jetzt sind. Ich habe dann nur Topt <= Tavg <= Top + Tbuf = Tpess und damit die Gewissheit, dass die geschätzte Fertigstellung nicht später stattfindet als zu dem für die pessimistischen Werte ermittelten Termin. Jetzt kommen aber noch die akkumulierten eingesparten Puffer hinzu, die hintendran gehängt werden. Da das Akkumulieren linear erfolgt, der vorher mögliche Pufferverbrauch aber möglicherweise Parallelität beinhaltet, kann der zunächst angehängte Pufferpool sogar zu einem späteren vorhergesagten Termin führen, sogar dann, wenn man ihn um 50% oder mehr kürzt. Wenn von allen 11 Aktivitäten eine auf alle anderen warten muss, dann reicht es schon aus, dass nur eine nur die pessimistische Schätzung erfüllt, und schon ist der Zeitvorteil, den alle anderen bei eingetretenem Optimum erreichen, dahin. Natürlich stehe ich dann immer noch als strahlender Held da, weil ich ja immer noch weit vor dem versprochenen Termin bleibe. Aber der ist eben viel später als der, den ich klassisch weitergegeben hätte. Der Punkt ist wohl eher der, dass ich bei Projekten mit einem hohen Maß an Parallelität ohnehin günstigere Voraussetzungen habe, da sich lokale Verzögerungen nicht aufaddieren. Unter dem Strich wird mir dann allerdings ein solches Projekt zum Schuss ins Knie geraten, denn wenn ich einen unrealistisch späten Termin genannt habe, dann wird man mir in Zukunft frühere Termine abverlangen, auch dann, wenn die Projekte viel weniger Parallele Vorgänge aufweisen.

In der englischsprachigen Version ist die Rede nur von den Puffern, die zu den Aktivitäten der Critical Chain gehören, als solchen, die nachher zum Bufferpool beitragen. Ich denke, dass dieser Unterschied wesentlich ist, denn das schließt Parallelismus, so wie ich ihn geschildert habe, aus. Aber auch dann bleibt die Berechnung der 25% Durchlaufzeitverkürzung nicht nachvollziehbar. Wenn ich es richtig sehe, wird unterstellt, dass die erwähnte 50%-Wahrscheinlichkeit mit einer Verringerung von Tbuf um 50% einhergeht. Wo steht, dass der Zusammenhang zwischen Schätzwertqualität (der Wahrscheinlichkeit, dass der Schätzwert eingehalten wird) mit der Puffergröße ein linearer ist?

Da erscheint es mir sinnvoller, sowohl pessimistische als auch optimistische Schätzungen zu verwenden. Die korrekte Art und Weise, entlang der Kritischen Chain einen spätesten Fertigstellungstermin zu ermitteln, liefert mir einen Termin, den ich auch nach außen kommunizieren kann. Der ist dann auf jeden Fall auch nicht später als der mit den pessimistischen Schätzungen ermittelte. Die optimistischen Schätzungen verwende ich, um die die Startzeitpunkte für die einzelnen Aktivitäten aggressiv festzulegen, sodass ich jede Chance nutze, Zeitgewinne mitzunehmen, wenn sie anfallen - so spät wie möglich, so früh wie nötig, um keine Gewinne auszulassen. Die pessimistischen Schätzwerte liefern mir Startzeitpunkte nahe der "Schwarzen Piste", die ich möglichst meiden will. Tatsächlich wird das auch so gemacht. Dann sollte aber auch klar sein, dass hier ein permanentes Monitoring notwendig ist, um aus einer sicheren Position heraus die Startzeitpunkte der einzelnen Aktivitäten nachzuführen. Das ist bei den klassischen Methoden wohl eher nicht der Fall, bei denen dann eher mit Ressourcen jongliert wird.

Ich denke, diese Thema sollte noch einmal überarbeitet werden. Die Erklärungen insgesamt sind weniger verständlich und einleuchtend als die der englischsprachigen Version.