Organisation
Kommentare 1

Wenn doch jeder nur seinen Job machen würde..

Wir lieben Pläne. Sie geben uns Sicherheit. Alles ist mit Plänen unter Kontrolle. Die Termine sind gefixt, die Meilensteinergebnisse sind für alle klar ersichtlich. Jawoll, so laufen vernünftige Projekte! Aber was sollen wir tun, wenn sich irgendein anderer nicht an den tollen Plan hält? Wir hätten so wenige Probleme, wenn doch nur die Disziplin (der anderen) zur Einhaltung der Termine höher wäre. Wenn sich doch nur jeder an die Verabredungen halten würde… Oder sind wir womöglich nur die Jäger einer Illusion?

In letzter Zeit erhalten wir von V&S vermehrt Mandate von Unternehmen aus dem Maschinen- und Anlagenbau, die ihre Durchlaufzeit und ihren Durchsatz deutlich verbessern wollen – ersteres senken, letzteres erhöhen. Um das hinzukriegen, muss man an das Auftragsmanagement ran; bei der technischen Komplexität und zumeist Einmaligkeit von Aufträgen in dieser Branche darf man das getrost „Projektmanagement“ nennen.

So, jetzt geht’s los: Man legt mal einen typischen Projektplan auf den Tisch. 10 bis 300 einzelne Prozessschritte, je nach Granularität der Planung und Umfang der Anlage. Alle Schritte artig aufgereiht in einem Netzplan. Darin sind alle Abhängigkeiten der Arbeitsschritte von Konstruktion bis Endmontage enthalten, es gibt Meilensteine und Fertigstellungstermine für jeden einzelnen Schritt. Beeindruckend. Am Ende kommt die Inbetriebnahme im Werk und/oder beim Kunden.

Als Berater bekommen wir diesen Plan ausführlichst erklärt und früher oder später – das ist so sicher wie das Amen in der Kirche und das Prost in der Kneipe – kommt der Kommentar, auf den ich jedes Mal so sehnsüchtig warte: »Wissen ’se, wenn sich nur jeder an seine Termine halten würde, dann hätten wir keine Probleme.« Gerne auch in der generalistischen Abwandlung: »Wenn doch alle hier im Laden nur ihren Job machen würden, kämen wir vor Lachen gar nicht mehr in den Schlaf.«

Lösung gefunden, oder? Die große Disziplin-Walze muss also her. Da muss man jetzt halt mal durchgreifen und so richtig auf den Tisch hauen, wenn der Müller mal wieder seine Termine nicht hält. Etwas moderner geben sich die Befürworter von Belohnungen statt Bestrafungen (dabei sind es natürlich nur verschiedene Seiten derselben Münze). Also eine Prämie für Termineinhaltung oder ein überlebensgroßes Portrait in der Kantine mit der Unterschrift „Termineinhalter des Monats“.

Sie merken schon, meine Ironie geht wieder mit mir durch. Dieser Reflex, auf Planeinhaltung zu pochen, ist nämlich typisch und immer wiederkehrend – aber eben völlig wirkungslos. Im Gegenteil: die Lage wird meist noch schlimmer, die Lieferzeiten länger, die Termintreue schlechter und die Stimmung gleicht sich im Trend der Produktivität an: Es geht bergab. Aber warum eigentlich?

Der Fehler liegt in der irrtümlichen Grundannahme, dass man Pläne einhalten kann und muss. Diese Grundannahme kommt aus einer Zeit, wo Pläne vielleicht noch Sinn ergaben. Damals – das war 1911. Das Jahr, in dem Frederik Taylor seine Theorien für eine intelligente Arbeitsteilung veröffentlichte. Damals war die Welt aber noch eine andere. Die Unternehmen haben die Märkte bestimmt und diese haben sich nur sehr träge verändert. Heute – und das brauche ich sicherlich für keinen ausführlich darzulegen – sieht die Sache vollständig anders aus.

Animated-Optical-Illusion-14Gucken wir doch mal den Tatsachen ins Auge: Eine Planung ist immer nur Illusion – eine gedankliche Vorwegnahme der Realität. Oder anders ausgedrückt, eine zeitliche und typischerweise auch personelle Trennung von Denken und Handeln. Und diese Trennung funktioniert nun einmal nur, wenn sich zwischen Planung und Ausführung nichts oder zumindest kaum etwas verändert. Das heißt im Klartext: Entweder sind Projekte so einfach, dass man keine Planung braucht, oder sie sind so komplex, dass keine Planung funktioniert. Von meinem Doktorvater Prof. Wiendahl habe ich immer den Satz eingetrichtert bekommen: »Planung macht aus Zufall Irrtum.« Recht hat er.

Sollte ich mich nicht dennoch auf ein Kundenprojekt anständig vorbereiten? Natürlich sollte ich das, alles andere wäre ja absolut fahrlässig. Aber wenn ich vorbereiten sage, meine ich eben vorbereiten und dann situativ arbeiten und reagieren. Ich meine ganz ausdrücklich nicht planen und hinterher 1:1 umsetzen. Natürlich sollte ich abzuschätzen versuchen, wie lange ein Arbeitsschritt dauert und in welcher kausalen Abfolge die Arbeitsschritte zueinander stehen. Aber eine Abschätzung bleibt nun mal eine Schätzung, es darf daraus nie eine Verpflichtung abgeleitet werden. Denn vor allem die Leistungsverpflichtung macht aus einer vernünftigen Vorbereitung eine illusionäre Planung.
Und dann haben wir den Salat. Denn in der Projektpraxis folgt aus der geschilderten Leistungsverpflichtung nämlich immer das gleiche: Sicherheitspuffer, die in Summe meist größer sind als der eigentliche Zeitbedarf für die Bearbeitung. Machen Sie sich das mal bewusst: Mehr als 50% der geplanten Durchlaufzeit eines Projektes sind typischerweise Sicherheitspuffer. Was für eine Verschwendung. Verschwendung von Zeit, Marktpotenzial und vor allem Energie der beteiligten Personen. Die könnten sich eigentlich alle Projektplaner sparen, wenn, ja wenn sie eben keine Projektpläne mehr machten.

Stattdessen sollte man sich Methoden bedienen, die bewusst auf die destruktiven Elemente von Planung verzichten. Gerade im Maschinen- und Anlagenbau. Das prominenteste Beispiel ist sicherlich die Methode CCPM (Critical Chain Projekt Management). Sie erfordert allerdings ein verändertes Mindset. Und zwar von der Führung, und nicht nur von den Projektleitern.

Ich würde mich freuen, wenn Sie uns hier mal schildern, was Sie für Erfahrungen mit Plänen gemacht haben?

1 Kommentare

  1. Karsten Violka sagt

    In der Software-Entwicklung hat sich mittlerweile die Erkenntnis durchgesetzt, dass das klassische „Wasserfall-Modell“, bei dem ein Projekt vor der Umsetzung bis ins kleinste Detail spezifiziert wird, zumeist nicht funktioniert.

    Bei den neueren Mehoden der „agilen Softwareentwicklung“ oder Scrum (http://de.wikipedia.org/wiki/Agile_Softwareentwicklung, http://de.wikipedia.org/wiki/Scrum) setzen Entwicklerteams kleinere Anforderungspakete in überschaubaren Iterationen um. So lassen sich Features im Projektverlauf flexibel anpassen, erweitern oder auch streichen.

    Allerdings erfordert das auch von Auftraggeberseite eine gewisse Flexibilität: Das Budget für das Endprodukt sollte genügend Spielraum bieten, bzw. sollten Kompromisse beim Funktionsumfang möglich sein, sollte das kalkulierte Zeitbudget nicht genügen.

    Beste Grüße

    Karsten Violka

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.