Über Hürden zum Erfolg Critical Chain im Praxiseinsatz

Kann Critical-Chain-ProjektmanagementCritical-Chain-ProjektmanagementCritical-Chain-Projektmanagement ist eine auf der Theory of Constraints (TOC) beruhende Methodik zur Planung und Steuerung von Projekten mit dem Ziel, Engpassressourcen optimal einzusetzen und die Projektdauer zu minimieren. (CCPM) in der Praxis funktionieren? Als Kay Schulz die externe ProjektleitungProjektleitungProjektleitung ist die temporäre Organisationseinheit zur Leitung eines Projekts. Die Projektleitung ist im Minimalfall nur mit dem/der Projektleiter(in) besetzt, es kann sich aber auch um eine umfangreiche Organisationseinheit mit eigenem Büro, ggf. sogar um eine eigene temporäre juristische Person handeln (z.B. GdBR oder GmbH). bei einem IT-Dienstleister übernahm, sah er nur mit dem Einsatz der Critical-Chain-MethodeCritical-Chain-MethodeDie Critical-Chain-Methode wird in der Netzplantechnik eingesetzt, um minimale Durchführungsdauern zu erzielen. Im Gegensatz zur Methode des Kritischen Wegs (Critical-Path-Methode) verwendet die Critical-Chain-Methode lediglich eine Pufferzeit für das gesamte Projekt und nicht für einzelne Vorgänge. eine Chance, den sehr ehrgeizig gesetzten TerminTerminEin Termin ist ein durch absolute Zeitangaben festgelegter Zeitpunkt in der Echtzeit. Die DIN 69900:2009-1: "Projektmanagement – Netzplantechnik: Beschreibungen und Begriffe" unterscheidet zwischen Termin und Zeitpunkt, wobei letzterer nicht absolut, sondern nur relativ zu einem Bezugspunkt (z.B. der noch nicht terminlich festgelegte Projektstart) angegeben ist. zu halten. Allerdings musste er hierfür etliche Hürden überwinden. Nicht nur die Teammitglieder waren gegenüber der neuen Methode skeptisch, auch für die Geschäftsführung musste er so tun, als ob er auf traditionelle Art und Weise vorgehen würde. Lesen Sie, wie es ihm gelang, eine innovative TerminplanungTerminplanungBei der Terminplanung werden die Arbeitspakete zu einem realistischen Projektablauf zeitlich angeordnet. Das Projekt selbst, Projektphasen, Arbeitspakete und Meilensteine erhalten Start- und Endtermine. Die zeitliche Anordnung ist abhängig von den Anordnungsbeziehungen zwischen den einzelnen Elementen, den Dauern der Arbeitspakete, Pufferzeiten, von der Verfügbarkeit der Einsatzmittel und Finanzmittel und von vorgegebenen Randbedingungen aus dem Projektumfeld. Die Terminplanung wird deshalb meist in Einheit mit der Einsatzmittel-Planung durchgeführt. nach CCPM in einem sehr komplexen und konservativen Umfeld erfolgreich in die Tat umzusetzen.

Über Hürden zum Erfolg Critical Chain im Praxiseinsatz

Kann Critical-Chain-ProjektmanagementCritical-Chain-ProjektmanagementCritical-Chain-Projektmanagement ist eine auf der Theory of Constraints (TOC) beruhende Methodik zur Planung und Steuerung von Projekten mit dem Ziel, Engpassressourcen optimal einzusetzen und die Projektdauer zu minimieren. (CCPM) in der Praxis funktionieren? Als Kay Schulz die externe ProjektleitungProjektleitungProjektleitung ist die temporäre Organisationseinheit zur Leitung eines Projekts. Die Projektleitung ist im Minimalfall nur mit dem/der Projektleiter(in) besetzt, es kann sich aber auch um eine umfangreiche Organisationseinheit mit eigenem Büro, ggf. sogar um eine eigene temporäre juristische Person handeln (z.B. GdBR oder GmbH). bei einem IT-Dienstleister übernahm, sah er nur mit dem Einsatz der Critical-Chain-MethodeCritical-Chain-MethodeDie Critical-Chain-Methode wird in der Netzplantechnik eingesetzt, um minimale Durchführungsdauern zu erzielen. Im Gegensatz zur Methode des Kritischen Wegs (Critical-Path-Methode) verwendet die Critical-Chain-Methode lediglich eine Pufferzeit für das gesamte Projekt und nicht für einzelne Vorgänge. eine Chance, den sehr ehrgeizig gesetzten TerminTerminEin Termin ist ein durch absolute Zeitangaben festgelegter Zeitpunkt in der Echtzeit. Die DIN 69900:2009-1: "Projektmanagement – Netzplantechnik: Beschreibungen und Begriffe" unterscheidet zwischen Termin und Zeitpunkt, wobei letzterer nicht absolut, sondern nur relativ zu einem Bezugspunkt (z.B. der noch nicht terminlich festgelegte Projektstart) angegeben ist. zu halten. Allerdings musste er hierfür etliche Hürden überwinden. Nicht nur die Teammitglieder waren gegenüber der neuen Methode skeptisch, auch für die Geschäftsführung musste er so tun, als ob er auf traditionelle Art und Weise vorgehen würde. Lesen Sie, wie es ihm gelang, eine innovative TerminplanungTerminplanungBei der Terminplanung werden die Arbeitspakete zu einem realistischen Projektablauf zeitlich angeordnet. Das Projekt selbst, Projektphasen, Arbeitspakete und Meilensteine erhalten Start- und Endtermine. Die zeitliche Anordnung ist abhängig von den Anordnungsbeziehungen zwischen den einzelnen Elementen, den Dauern der Arbeitspakete, Pufferzeiten, von der Verfügbarkeit der Einsatzmittel und Finanzmittel und von vorgegebenen Randbedingungen aus dem Projektumfeld. Die Terminplanung wird deshalb meist in Einheit mit der Einsatzmittel-Planung durchgeführt. nach CCPM in einem sehr komplexen und konservativen Umfeld erfolgreich in die Tat umzusetzen.

Als ich vor einigen Jahren als externer Berater die Projektleitung für ein bereits laufendes SW-Entwicklungsprojekt übernahm, sah ich nur mit dem Einsatz der Critical-Chain-Methode eine Chance, den sehr ehrgeizig gesetzten Termin zu halten. Es gab dabei allerdings etliche Hürden zu überwinden, denn nicht nur die Teammitglieder waren gegenüber der neuen Methode skeptisch, sondern auch für die Geschäftsführung musste ich so tun, als ob ich auf traditionelle Art und Weise vorgehen würde. Nachfolgend lesen Sie, wie es dennoch gelang, eine innovative Terminplanung nach CCPM in einem sehr komplexen und konservativen Umfeld erfolgreich in die Tat umzusetzen.

Als externer Projektleiter vor vollendeten Tatsachen

AuftraggeberAuftraggeberDer Auftraggeber eines Projekts ist der wichtigste Projektbeteiligte ( Stakeholder ). Er erteilt den Auftrag und ist der Vertragspartner, der über den Erfolg des Projekts endgültig entscheidet. für das SW-Entwicklungsprojekt war ein IT-Dienstleister der öffentlichen Hand in einem deutschsprachigen Land. Es ging darum, eine Datenbankanwendung zu erstellen, die sowohl interne Prozesse vereinfachen als auch unter dem Schlagwort "E-Government" Daten über das Internet für alle Bürger zur Verfügung stellen sollte. Direkter Auftraggeber des Projekts war ein anderes Amt, das seinerseits wieder von einer übergeordneten Behörde beauftragt worden war. Der IT-Dienstleister – selbst eine öffentliche Institution – war ebenfalls streng hierarchisch aufgebaut und in Fachbereichen organisiert. Meine direkte Vorgesetzte, nennen wir sie Frau Schmidt, leitete einen Bereich von rund sechs Projektleitern, die jeweils andere Projekte betreuten. Da das Projekt Ressourcen aus mehreren Bereichen des IT-Dienstleisters benötigte, fand ich mich in einer typischen MatrixorganisationMatrixorganisationDie Matrixorganisation ist die häufigste Organisationsform für Projekte innerhalb von permanenten Linienorganisationen. Bei der Matrixorganisation überlagern die temporären Projektorganisationen die Linienorganisation so, dass zwei oder mehr Organisationseinheiten (die Trägerorganisation und die Projekte) zugleich auf die Ressourcen zugreifen. Die Mitglieder des Projektteams bleiben bei einer Matrixorganisation unverändert in die Linienorganisation eingebunden und unterstehen somit sowohl ihrem Vorgesetzten als auch dem Projektmanager. wieder.

Für alle IT-Projekte der öffentlichen Hand war ein strenges WasserfallmodellWasserfallmodellDas Wasserfallmodel ist ein Vorgehensmodell , bei dem der Projektablauf in lineare sequentielle Phasen gegliedert ist, deren deren Teilergebnisse aufeinander aufbauen und zum vorher vollständig spezifizierten Projektergebnis führen vorgeschrieben, das aus einer festgelegten Abfolge von Projektschritten ohne Iterationsmöglichkeit besteht. Frau Schmidt beauftragte mich aber, dieses Projekt nach dem Rational Unified ProcessRational Unified ProcessDer "Rational Unified Process" (RUP) ist ein bei IBM entwickeltes Vorgehensmodell für die Durchführung von Softwareprojekten. Er ist zeitlich in die vier Phasen Vorbereitung (Inception), Software-Strukturierung (Elaboration), Software-Erstellung (Construction) und Software-Übergabe (Transition) gegliedert. Die Projektdurchführung ist in die Arbeitsprozesse (Workflows) Geschäftsmodellierung (Business Modeling), Requirements Engineering, Analyse u. Entwurf (Analysis a. Design), Implementierung (Implementation), Test, Einsatz und Verteilung (Deployment), Konfigurations- und Änderungsmanagement (Configuration a. Change Management), Projektmanagement sowie Entwicklungsumgebung (Environment) gegliedert. (RUP) durchzuführen, da sie diesen an einem Pilotprojekt ausprobieren wollte. Im Wesentlichen ging es darum, die vier Phasen des RUP mit ihren entsprechenden Meilensteinen umzusetzen:

  • Konzeptionsphase (engl.: Inception) mit dem Lifecycle Objectives Milestone
  • Entwurfsphase (engl.: Elaboration) mit dem Lifecycle Architecture Milestone
  • Konstruktionsphase (engl.: Construction) mit dem Initial operational capability milestone
  • Übergabephase (engl.: Transition) mit dem Product Release Milestone

Innerhalb dieser Phasen erfolgt die Entwicklung in Iterationen.

Bis zur ersten Sitzung des Lenkungsausschusses ging ich selbstverständlich davon aus, dass sie diese Vorgehensweise organisationsintern auch mit den anderen Bereichen und ihren Vorgesetzten abgesprochen hätte.

Das Team: hochkompetent und motiviert

Als ich die Mitglieder meines Teams kennen lernte, musste ich als erstes meine pauschalen Vorurteile gegenüber Beamten über Bord werfen: Die zwölf Mitglieder meines Projektteams waren hochkompetente Entwickler, die den persönlichen Ehrgeiz besaßen, gute Projekte abzuliefern. Ich konnte keinen Unterschied zu den mir bisher bekannten Teams aus dem kommerziellen Umfeld feststellen.

Schnell fiel mir auf, dass zwei Teammitglieder besonders einflussreich waren. Es handelte sich dabei zum einen um Herrn Einstein, den die Kollegen als fachliche Koryphäe bei allen technischen Problemen konsultierten, der aber als etwas schwierig im persönlichen Umgang galt. Zum anderen gab es mit Herrn Grau einen erfahrenen Entwickler, der seit Jahrzehnten im Amt arbeitete und den allen Mitarbeiter als integer und vertrauenswürdig ansahen. In Besprechungen vermittelte er bei aufkeimenden Konflikten und steuerte unauffällig die Meinungsbildung. Er war gewissermaßen die "graue Eminenz" des Teams.

Gleich kostenlos weiterlesen!

  • Zum Newsletter anmelden und diesen Artikel freischalten
  • Jede Woche neue Inhalte, Tipps und Tools per E-Mail
Gratis Newsletter bestellen & sofort weiterlesen

 

Hiermit melde ich mich zum Newsletter an. Ich habe die Datenschutzrichtlinien gelesen und akzeptiere diese. Ihre Daten nutzen wir ausschließlich zum Newsletter-Versand. Sie können sich jederzeit abmelden, indem Sie auf den Link in der Fußzeile unserer E-Mails klicken. Informationen zu unserem Datenschutz finden Sie hier.
DownloadDownload

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
4 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 30
Kommentare 4

Alle Kommentare (4)

Martin
Wifling

Der Artikel ist flüssig zu lesen, ganz im Stile Goldratts. Dass er eine ganze Menge an (auch krassen) Fehlern eingesteht, macht ihn menschlich und symphatisch. Neue Ansätze in einer eher verkrusteten Struktur durchzuziehen, egal welche Methode angewandt wird, ist aus meiner Erfahrung durchaus erfolgsversprechend. Das Ganze könnte genauso gut andersherum funktionieren - für mich nicht unbedingt der Nachweis, dass die Methode gegenüber traditionellen Vorgehensweisen (entscheidende) Vorteile bietet. Dass er jedoch gegenüber dem Lenkungsausschuss ein "Potemkinsches Dorf" mit allen Konsequenzen aufbaut (reden die Projekt-MA eigentlich gar nicht mit ihren Vorgesetzten oder Kollegen?) ist nicht zu entschuldigen. Offenbar saßen in diesem Gremium wirklich nur Leute die betrogen werden wollten - womit man natürlich nicht rechnen sollte und was man sich nur als unabhängiger externer PL vielleicht leisten kann.

 

Daniel
Tonagel

Zunächst einmal: Sehr guter Artikel! Praxiserfahrungen sind durch nichts zu ersetzen. Ich nehme als Fazit u.a. mit, dass CCPM wie erwartet tatsächlich die klassischen Planungsfehler (lokale Puffer, Multitasking etc.) vermeidet und mit einem motivierten Team selbst unter ungünstigen Rahmenbedingungen umzusetzen ist. Die beschriebenen Umfeld-Probleme von CCPM als Methode werden von Goldratt übrigens antizipiert. Er empfiehlt daher - nicht ganz uneigennützig - einen beratergetriebenen Top-Down Ansatz, in dem 2 Manager aus unterschiedlichen Bereichen, die von der Methode überzeugt sind, sich ans Top-Management wenden und damit die Methode "von oben" einführen. Die hier beschriebene U-Boot-Methode hat so gerade eben funktioniert. Mich würde interessieren, ob die Mitarbeiter dank ihrer positiven Erfahrungen in der Lage sind, den Einsatz der Methode in zukünftigen Projekten voranzutreiben. Ein Wort noch zu Scrum: Auch hier werden grundlegende Probleme wie Studentensyndrom und Multi-Tasking adressiert, allerdings mit anderen Mitteln. Wie der Autor sehe ich hier wenig Sinn in einer Kombination der Methoden. Meiner Ansicht nach eignet sich Scrum eher für kleinere Projekte bis max. 10 Mitarbeiter, während ich umgekehrt weder natürliche Unter- noch Obergrenzen bei CCPM sehe.

 

Matz
Mattern

Sehr guter Artikel und auch gut geschrieben. Die Einführung von CCPM wird niemals reibungslos verlaufen. Ich sehe jedoch sehr wohl eine Chance Scrum und CCPM zu kombinieren. Allerdings habe ich da auch nur Theorie im Kopf und keine Praxiserfahrung.

 

Kay
Schulz

Liebe Rezensenten, danke für das Feedback. Es freut mich, dass der Artikel gefällt. - Von oben war die Einführung nicht möglich. Das habe ich bedauert, wollte es aber deswegen nicht weglassen - Ob die Mitarbeiter in Zukunft helfen werden, es voran zu treiben, kann ich leider nicht beantworten. Von dem beschriebenen Einstein könnte ich es mir vorstellen. Aber: Da es kein offizielles OK für so etwas gibt, braucht es einen PL der es wieder als U-Boot macht oder intern so stark ist, dass er es offiziell pilotieren darf. - Es gibt nie Belege dafür, ob etwas neues funktioniert oder besser ist im Vergleich zu etwas alten. Jedes Projekt ist eben einmalig. Und ich denke, das Team ist so gut gewesen, dass wir es vielleicht auch ohne CCPM geschafft hätten. Die Fakten sind aber: Wir haben es, wenn auch mit Widrigkeiten, mit der CCPM gut hinbekommen. Und das ist es, was zählt. - Ich bin ein Risiko eingegangen und hatte Glück. Und in vielen Projektausschüssen stelle ich immer wieder fest, nicht nur in der Verwaltung und nicht nur als externer PL, dass die Leute wenig Interesse zeigen, solange es gut geht. Nur wenn etwas schief geht, dann melden sie sich vehement zu Wort auch wenn dann herauskommt, dass sie vorher einiges verschlafen haben. Und ich hatte mit diesem Team das Gefühl, dass wir es hinbekommen und daher habe ich darauf gesetzt, dass ich es als U-Boot machen kann. Lieber wäre mir jedoch gewesen, ich hätte es mit dem Wissen der Entscheider gemacht. Wie heisst es doch so schön: No risk, no fun :-) Sind wir nicht deshalb PLs geworden? Danke nochmals für die positiven Kommentare und den Austausch zu diesem Thema. Ich freue mich darüber. Viel Spass weiterhin beim Lesen im Projektmagazin. Grüsse Kay Schulz