Cookies helfen uns bei der Bereitstellung von ControllingWiki. Durch die Nutzung von ControllingWiki erklärst du dich damit einverstanden, dass wir Cookies speichern. Weitere Informationen

Critical Chain Projekt Management

Aus ControllingWiki

Wechseln zu: Navigation, Suche
Achtung. Sie nutzen eine nicht mehr unterstützte Version des Internet Explorer. Es kann zu Darstellungsfehlern kommen. Bitte ziehen Sie einen Wechsel zu einer neueren Version des Internet Explorer in Erwägung oder wechseln Sie zu einer freien Alternative wie Firefox.

Schaden verspäteter Projekte

Projekte werden nicht rechtzeitig fertig, halten ihre Budgets nicht ein oder liefern nicht die gewünschten Ergebnisse. Dieses Problem wird nicht mehr nur hinter vorgehaltener Hand diskutiert. Suboptimale Performance von Projekten ist nicht nur ärgerlich, belastet den Arbeitsalltag von Mitarbeitern, stresst Führungskräfte und verärgert Kunden, sondern gefährdet auch in erheblichem Maß die Wirtschaftlichkeit und Lebensfähigkeit von Unternehmen:

Zu spät erreichte Meilensteine, zu spät gelieferte Projekte führen zu später eingehenden Zahlungen. Terminüberschreitungen bewirken Vertragsstrafen. Liquidität und Wirtschaftlichkeit sind gefährdet; nicht wenige Unternehmen sind daran bereits zugrunde gegangen.

Ursachenforschung

Sucht man nun im einzelnen Projekt nach den Gründen für Verspätungen, sind Schuldige meistens schnell gefunden : Einzelne habe ihren Job nicht rechtzeitig gemacht, das Management hat Prioritäten verschoben, Lieferanten haben nicht oder das Falsche geliefert, Ressourcen waren – trotz bester Planung – nicht verfügbar, der Kunde hat zu langsam reagiert. Anders ausgedrückt: die Anderen sind schuld, dass das Projekt nicht zuverlässig sein konnte.

Projekt- und Multiprojektmanagement sind von Unsicherheit und dessen großen Bruder Murphy geprägt. „Unsicherheit“ bedeutet: niemand weiß, wie lange etwas tatsächlich dauert und was so alles passieren kann. Und „Murphy“ bedeutet: immer dann, wenn wir es am wenigsten gebrauchen können, geht etwas ganz fürchterlich schief.

Daher muss ein exzellentes Multiprojektmanagement davon ausgehen, dass Unsicherheit und Murphy existieren und Mechanismen entwickeln, die es ermöglichen DENNOCH in time, in budget und in content zu liefern.

Got it! Thnaks a lot again for helping me out!

Now I feel stupid. That's celared it up for me

Regel 2: Sicherheiten bündeln

Hintergrund

Um ein Projektziel zu erreichen, ist eine Vielzahl einzelner Aktivitäten unterschiedlicher Unternehmensbereiche, oft sogar unterschiedlicher Unternehmen erforderlich. Die meisten Ressourcen eines Unternehmens warten allerdings nicht gerade auf neue Projekte, sie haben ohnehin genug zu tun (zumindest sehen sie in Folge der oben dargestellten Effekte so aus). Wenn ohnehin genug zu tun ist, muss man Prioritäten im Tagesgeschäft setzen; und diese Prioritäten werden stets zugunsten der Projekte und Aktivitäten gesetzt, die mit einem gewissen Druck verknüpft sind.

Projektmanager versuchen, diesen Druck auf folgende Art und Weise aufzubauen: Für jede einzelne Aktivität fragen sie den jeweils verantwortlichen Bereich, wie viel Zeit erforderlich ist. Aus den Zeitschätzungen aller Bereiche für alle Aktivitäten wird dann ein Zeitplan entwickelt (meist verbunden mit Verhandlungen über Zeiten und pauschalen Kürzungen), der verbindliche Zwischentermine für jede einzelne Aktivität beinhaltet. Jeder versteht, dass diese einzelnen Termine möglichst eingehalten werden müssen; Folgeaktivitäten sind davon abhängig; nur so kann der Gesamttermin des Projektes gehalten werden.

Allerdings: wie lange eine Aufgabe in einem Projekt dauert, kann vorher niemand genau vorher sagen; man kann es nur grob schätzen. Wenn aber aus der Schätzung ein Termin wird und dieser Termin anschließend eingehalten werden müssen, dann wird jede verantwortliche Führungskraft genau diese Unsicherheit berücksichtigen und Zeitschätzungen abgeben oder veranlassen, die dadurch einhaltbar sind, dass sie Sicherheiten beinhalten.

Diese Sicherheiten verlängern schon im Plan die Dauer des Projektes, helfen aber keineswegs dem Projekt, rechtzeitig fertig zu werden. Denn: wenn jemand (nicht nur einmalig) deutlich früher fertig wird als geplant, werden ihm zukünftig seine Zeitschätzungen nicht mehr geglaubt, sondern gekürzt.


Folgen und negative Auswirkungen

Je stärker ein Unternehmen unter der Unzuverlässigkeit seiner Projekte leidet, umso lauter wird der Ruf nach Verbindlichkeit des einzelnen: noch genauer und detaillierter wird geplant, noch mehr werden einzelne oder Bereich daran gemessen, wie gut ihre Schätzungen sind und ob sie ihre Zusagen einhalten. Damit dreht sich auch hier ein Teufelskreis:


Abb. 3 Teufelskreis der individuellen Sicherheiten.JPG


Abbildung 3: Teufelskreis der individuellen Sicherheiten


Lösungsansatz

Sicherheiten werden explizit als „Projekt-Puffer“ eingeplant und gleichzeitig aus den einzelnen Aufgaben / Projektteilen entfernt. Dadurch sind Sicherheiten vorhanden (für Unsicherheit und Murphy), werden aber nicht unnötig verbraucht.

Die Erfahrung aus vielen Implementierungen dieses Lösungsansatzes zeigt: wenn man die Dauer aller Aufgaben (und damit des gesamten Projektplanes) um die Hälfte reduziert und stattdessen einen globalen Puffer einfügt, der halb so lang ist wie der neue Projektplan, dann hat das Projekt genügend Sicherheit, um dennoch in time fertig zu werden.

Die Konsequenz ist also: obwohl das Projekt – im Plan – 25 % kürzer ist, wird es rechtzeitig fertig.


Abb. 4 Projektplan um 25% gekuerzt.JPG


Abbildung 4: Projektplan um 25% gekürzt


Implementierung

Diesen Lösungsansatz umzusetzen, ist allerdings nicht banal, denn es gibt einige offene Fragen:

• Wenn die Dauer von Aufgaben um 50% reduziert wird, kann man oft den daraus errechneten Termin nicht einhalten. Wie können Mitarbeiter, die daran gemessen werden, ob sie ihre Termine einhalten, zu Mitwirkung gewonnen werden?

• Kann wirklich die Dauer jedes Projektschrittes um 50% reduziert werden? Was ist mit Aufgaben, die eine wirklich feste Laufzeit haben (z.B. der Schiffstransport einer Anlage von Rotterdam nach Shanghai)?

• Wie wird mit Aufgaben umgegangen, die extern vergeben sind? Können auch bei Lieferanten die Aufgaben-Dauern einfach um 50% reduziert und mit einem Puffer abgesichert werden? Diese Fragen müssen schlüssig beantwortet werden, um ein realisierbares Konzept zu erhalten.

Regel 3: Umsetzung managen

Hintergrund

Projektgeschäft ist geprägt von Unsicherheit und Murphy; trotz bester Planung und Vorbereitung kommt es bei der Umsetzung von Projekten anders als geplant: Unerwartete Aufgaben tauchen auf, Kunden haben Änderungswünsche, Aufgaben dauern länger, …

Diese Eigenheiten des Projektgeschäftes können leicht Verwerfungen bei der Abarbeitung von Projekten – insbesondere in Multiprojekt-Organisationen führen. Häufige und hektische Umpriorisierungen von Aufgaben sind die Folge.

Gleichzeitig macht es die gängige Praxis, Aufwandschätzungen in Terminzusagen zu verwandeln, für Projektmanager schwierig, frühzeitig bei der Aufgabenumsetzung zu intervenieren. Wenn sie früher nachfragen, als die Aufgabe abgeschlossen sein soll, werden sie ab- und auf den „vereinbarten“ Termin verwiesen.


Folgen und negative Auswirkungen

Beide vorstehend genannten Phänomene verzögern notwendige Management-Unterstützung und fördern Multitasking.

Management-Unterstützung ist aber – in einigen wenigen, oft nicht vorhersehbaren Situationen eines Projektes – entscheidend dafür, dass Projekt aus einer schwierigen Lage zu befreien. In anderen Situationen dagegen führt Management-Intervention eher zu Verunsicherung und unnötigem Aufwand.

Dadurch verzögern sich Projekte unnütz und die – unter Anwendung von Regel 2 – explizit eingeplanten Sicherheiten werden verschwendet.


Lösungsansatz

Ressourcen und unterstützende Management-Funktionen arbeiten anhand eindeutiger Prioritäten. Die Priorität einer Aufgabe wird anhand ihres Einflusses auf die Fertigstellung des Projektes bestimmt. Oder anders ausgedrückt: Prioritäten für Aufgaben werden danach festgelegt, wie stark die einzelne Aufgabe den Projektpuffer (siehe Regel 2) – verbraucht.

Dazu ein Beispiel: Zwei Projekte benötigen für ihren weiteren Fortschritt die Arbeit der Ressource X.


Beispiel k.jpg


Geplant sind fünf Tage Arbeit für die Ressource X in beiden Projekten. In Projekt 1 sind bereits 50% der Tasks abgeschlossen (15 von 30 Tagen); gleichzeitig wurden 10 Tage des Projektpuffers verbraucht (66%). In Projekt 2 sind erst 33% der Tasks abgeschlossen (10 von 30 Tagen); gleichzeitig wurden 3 Tage des Projektpuffers verbraucht (20%).

Schon auf den ersten Blick erkennt man, dass die Ressource X nun zunächst an Projekt 1 arbeiten muss. Würde sie es nicht tun, wäre dort der komplette Projektpuffer verbraucht, das Projekt wäre verspätet.

Diese einfache Überlegung wird nun in eine Methode für die Berechnung von Task-Prioritäten gegossen: Das Verhältnis zwischen Projektfortschritt und Verbrauch des Projektpuffers ergibt den sogenannten Pufferindex eines Tasks. Je größer diese Pufferindex, umso höher die Priorität:


Pufferindex.JPG


Die so errechnete Priorität gilt nun nicht nur für die Ressourcen bei der Entscheidung, welche Aufgabe zuerst bearbeitet werden soll. Sie gibt auch den Projektmanagern einen Hinweis, auf welche der Tasks in ihren Projekten sie sich konzentrieren sollten, um den Projektfortschritt zu unterstützen. Und schließlich bekommt auch die Geschäftsleitung so den Hinweis auf die wenigen Tasks im Unternehmen, denen sie durch ihre Intervention im Fortschritt helfen können.


Implementierung

Diesen Lösungsansatz umzusetzen, ist allerdings nicht banal, denn es gibt einige offene Fragen:

• Um tagesaktuell Prioritäten für alle aktiven und neu zu startenden Aufgaben berechnen zu können, müssen die Ressourcen täglich melden, wie lange sie noch brauchen. Gleichzeitig ist bekannt, dass Fortschrittsmeldungen in Projektorganisationen nur sehr ungern gemacht werden und schleppend erfolgen. Wie können die Ressourcen motiviert werden, täglich sinnvolle Rückmeldungen zu geben?

• Die Prioritäten können sich täglich ändern. Eine bereits begonnene Aufgabe aber zugunsten einer nun plötzlich höher priorisierten Aufgabe zu unterbrechen, erzeugt schädliches Multitasking. Wie wird dieser Entscheidungskonflikt gelöst?

Diese Fragen müssen schlüssig beantwortet werden, um ein realisierbares Konzept zu erhalten.

That's way the bestest aswner so far!

Internet

AGI - The Goldratt Institute [1]

TOC Institute [2]

TOC4U Theory of Constraints [3]

Wikipedia [4]

Ersteinstellender Autor

Uwe Techt, VISTEM GmbH & Co KG, Mail: uwe.techt@vistem.eu