Auf der First European TOC Results Conference in Amsterdam berichtete Lars de Laat am 16.10.09 über die Erfahrungen, die sein Unternehmen, die Caesar Group, mit Critical Chain Projektmanagement gemacht hat.
Die Caesar Group ist eine mittelgroße ICT Organisation mit 300 Mitabeitern. Seit 1993 bietet das in Privatbesitz befindliche Unternehmen Softwareentwicklung und -wartung auf dem niederländischen Markt an. Das Geschäftsmodell beruhte zunächst auf operativer Effizienz und Weitergabe eines Teils der daraus entstandenen Kostenvorteile an die Kunden. In der Rezession von 2002 (im Anschluss an das Platzen der IT-Blase) zeigt sich, dass dieser Ansatz den Fortbestand des Unternehmens nicht würde sichern können, und so machte man sich auf die Suche nach einer Alternative. Diese sollte ein zentrales Bedürfnis des IT-Marktes adressieren.
Warum TOC und CCPM?
Auf der Suche nach einem konkreten Ansatzpunkt trafen Führungskräfte von Caesar auf Eli Goldratt und die TOC. Der so in Gang gesetzte Denkprozess ergab folgendes:
die TOC bietet mächtige Lösungen für verschiedene generische Probleme
Schlechte Projektleistung ist im IT-Bereich typisch: 60-70% aller IT-Projekte liefern nicht den richtigen Umfang pünktlich und innerhalb des Kostenrahmens
Caesar bot 2004 keine bessere Leistung als der Markt an sich
Folglich:
Das generische Bedürfnis des IT-Marktes liegt in pünktlichem (oder frühzeitigem) Projektabschluss
Die Lösungsrichtung lautete, Ideen aus der Welt der TOC einzusetzen, um eine hohe Liefertreue bei IT-Projekten zu erreichen
Zielsetzung
Caesar setzte sich das ambitionierte Ziel, zu einem IT-Anbieter zu werden, der alle IT-Projekte garantiert pünktlich liefert. Dazu sollte auch eine neue Weise gehören, die Wirkungen pünktlicher bzw. verspäteter Projektabschlüsse für die Kunden auszudrücken:
Bonus für pünktliche oder frühzeitige Fertigstellung
Annahme: Pünktliche oder frühzeitige Lieferung hat einen Wer für den Kunden
Malus für verspätete Lieferung
Worte mit Geld unterlegen
Interner Antrieb, die Arbeitsweise zu verändern (Dauern statt aufgewendete Stunden)
Dementsprechend nannte man das Veränderungsprojekt TimeValue.
Umsetzung von TimeValue
Innerhalb des ersten Halbjahres 2005 wurden die Hauptelemente einer CCPM-basierten Lösung eingeführt:
Critical Chain Projektmanagement, um die negativen Effekte des Studentensyndroms, von Parkinsons Gesetz und des Multitaskings zu beseitigen
Solution for Sales, als neue Marketing- und Vertriebsmethode, um gezielt die Widerstandsebenen auf Seiten der Kunden zu überwinden
Problem Driven Scope Management
CCPM löste zwar einige der Probleme (Verzögerungen) im IT Projektmanagement, aber ist es ausreichend? Einer der wichtigen Gründe für Fehlschläge liegt in unkontrolliertem sogenannten Scope Creep. Durch Zeitpuffer kann ein Teil davon abgefangen werden. Das Puffern des Projektumfangs dagegen verschlechtert die Marktposition.
Hier führte Caesar zwei neue Ansätze ein:
Das sogenannte Problem Driven Scope Management (PDSM) nutzt die Denkprozesse der TOC, um ausgehend vom eigentlichen Kundenbedürfnis zu analysieren, welche Probleme tatsächlich gelöst werden müssen (dies ist Teil des normalen Verkaufsprozesses). Kommt es im Laufe des Projektes zu Änderungswünschen, so werden diese logisch im Licht der ursprünglichen Herausforderung analysiert und bewertet. Auf diese Weise können sinnvolle von sinnlosen Änderungswünschen getrennt werden. Insgesamt wurde auf diese Weise das Ausmaß an schädlichem Scope Creep und damit verbundenen Verzögerungen deutlich reduziert.
Weiterhin kommt nun ein agiler Entwicklungsprozess zum Einsatz
Erkenntnisse und Erfahrungen
Veränderungsmanagement
Werden alle Mitarbeiter mit der neuen Arbeitsweise zurechtkommen und sie annehmen?
Welcher Veränderungsumfang und welche -geschwindigkeit sind möglich?
Welcher Ansatz ist angemessen, Verbesserung oder radikaler Neubeginn?
Grundlegendes Projektmanagement
Effektive Projektteams erfordern Ressourcenpools über Team- und Standortgrenzen hinweg
Um zuverlässige Zeitschätzungen als Planungsgrundlage zu erhalten, wurden Expertenschätzungen durch das Function Point-Verfahren ersetzt
Fluss (Flow) in der Projektumsetzung
Der Constraint muss bewusst gewählt und die Projektpläne daran ausgerichtet werden
Qualitätsverbesserung durch Wechsel von Push zu Pull: Im Push-Verfahren geben Mitarbeiter ihr Arbeitsergebnis an den Folgeschritt weiter, ohne die Qualität zu prüfen; Im Pull-Verfahren muss der folgende Schritt das Arbeitsergebnis des vorangegangen Schrittes akzeptieren. Auf diese Weise findet an den Schnittstellen eine Qualitätsprüfung statt und der aufwärtsgelegene Mitarbeiter achtet stärker auf die Qualität seiner Arbeitsergebnisse
Fluss zwischen Vertrieb und Umsetzung
Erfolg führt zu Überlast durch zu viele neue Projekte und dann zum Verhungern des Constraints; es besteht die Gefahr, dass das System an seinem eigenen Erfolg scheitert. Daher ist es unbedingt erforderlich, dass Vertrieb und Umsetzung aufeinander abgestimmt arbeiten. Mit Hilfe der PDSM-Methode werden unter anderem attraktive von unattraktiven Projekten unterschieden. Dazu wird bereits im Laufe der Akquise eine Analyse des Kundenbedürfnisses durchgeführt.
Ergebnisse
95% der Projekte werden voll umfänglich pünktlich (zu einem Festpreis) geliefert
Die neu erworbenen TOC-Fähigkeiten helfen, begrenzende Faktoren (Probleme, Constraints) zu identifizieren und sie mit allen Beteiligten (ggf. einschl. Kunden) zu beseitigen.
Mit dem PDSM-Prozess wird den Kunden geholfen, ihr Geld sinnvoll auszugeben; etwa 20% der angefragten Projekte werden nach der Analyse durch den Kunden gestrichen, bei fast allen Projekte fällt der Umfang kleiner aus
Kunden sind zufrieden und beauftragen häufig Folgeprojekte
Viele Kunden wollen die positiven Veränderungen im Projektmanagement auch auf ihren eigenen Betrieb übertragen
Heute sind etwa 20% des Geschäftes nach TOC organisiert, dieser Bereich soll nun weiter ausgedehnt werden und auch auf Softwarewartung und TOC-basierte IT-Beratung ausgeweitet werden
