Der aggregierte Projektplan Multiprojektmanagement leicht gemacht!
Friedrich Hüppe
Weil Wertschöpfung das Ergebnis geistiger Tätigkeiten sein kann, sind die Methoden der Lean Administration auf Entwicklungs- und Konstruktionsbereiche anwendbar. Denn ein "Fluch" unproduktiver Entwicklungsbereiche ist der Umlaufbestand. Es sind zu viele Aufträge (Projekte) im System, zeigt die Erfahrung der CIM Aachen GmbH.
Der Befund in vielen Entwicklungsbereichen ist, losgelöst von der jeweiligen Branche, ähnlich. Alle Mitarbeiter sind im Stress, aber nichts wird fertig. So wurde bei einem Hersteller der Medizintechnik die Belastung mit Projekten pauschal als zu hoch empfunden. Jeder einzelne Entwickler war überlastet, aber wie viele Projekte es insgesamt gab, war schwer festzustellen. In manche Projekte kam plötzlich unheimlicher Druck, so dass alles andere "hinten rüber" fiel. Neue Projekte wurden zusätzlich eingeplant, ohne auf bestehende Kapazitätsengpässe Rücksicht zu nehmen. Und dann noch die Engpässe "Testzentrum" und "Prototypenbau".
Woran erinnern hohe Bestände an "unfertigen Erzeugnissen" bei gleichzeitig geringem Output und durch Feuerwehraktionen frustrierte Mitarbeiter? "Unklare Bearbeitungszustände und schwer planbare Kapazitäten gehören eben zur Entwicklung als kreativem Prozess", wird schulterzuckend kommentiert. Wie "damals", als hohe Fertigwarenbestände zur Lieferbereitschaft gehörten und Puffer die kontinuierliche Auslastung teurer Maschinen sicherstellten, lautet der für den Projektverlauf ermutigende Analogieschluss. Die Projekte müssen "in Fluss" gebracht werden, die Stapel an offenen Projekten sind zu beseitigen.
Stapelverarbeitung ist der "Fluch" unproduktiver
Entwicklungsbereiche
Wie werden aber produktivitätsvernichtende
Stapel beseitigt und in Zukunft vermieden?
Zunächst ist mit dem Mythos der Unplanbarkeit
kreativer Prozesse aufzuräumen.
Projekte sind zu kategorisieren, um damit die
Segmentierung spezieller Abläufe und die
Definition detaillierter Tätigkeitsinhalte zu
ermöglichen. Die Produktprogrammplanung
lässt sich damit in Entwicklungsprojekten
abbilden, wodurch der Kapazitätsbedarf
entlang der Zeitachse transparent und planbar
wird.
Im Ergebnis entsteht ein sog. aggregierter Projektplan, mit dem Engpässe im Voraus erkannt werden und damit der Rückstau (Stapel!) laufender Projekte vermeidbar ist.
Der aggregierte Projektplan wird durch eine Kapazitätsplanung auf Einzelprojektebene im Wochenrhythmus aktualisiert. Hierfür sind die jeweiligen Projektleiter verantwortlich. Gleichzeitig wird das Kapazitätsangebot aus personenbezogenen Jahresplänen ermittelt. Jeder Entwickler aktualisiert dazu seine persönliche Planung. Im konkreten Fall ist damit eine enorme Bewusstseinsbildung in Bezug auf Gesamtzusammenhänge erzeugt worden, Engpässe sind vorhersehbar und es gibt eine verlässliche Planungsgrundlage zur Tätigkeitsverlagerung auf Dritte.
Multi-Projektmanagement mit dem aggregierten
Projektplan
Die im aggregierten Projektplan sichtbar
gemachten Kapazitätsbedarfe sind für jede
Projektkategorie in Sequenz- und Unterstützungsfunktionen
zu unterscheiden. In Analogie
zur physischen Wertschöpfung wird
nur durch die Sequenzfunktion ein kreativer
Wertbeitrag als "Arbeitsfortschritt" erzielt.
Die Unterstützungsfunktionen (Berechnung,
Prüfstandsversuche, Detaillieren von Zeichnungen,...)
dürfen deswegen nicht zum Engpass
(Stapel!) werden, wenn Entwicklungsabläufe
beschleunigt werden sollen.
Bei der Ablaufbeschreibung für jede Projektkategorie sind dann die Zeitpotentiale aufzuspüren. Die Ideen hierzu kommen von den Beteiligten selbst als Antwort auf die Frage "Was ist zu tun, um die Stapel loszuwerden?". Das Stichwort lautet hier Aufgabenintegration. Die Zuständigkeit für die Sequenzfunktionen wird auf funktionsübergreifende Teams übertragen, Wartezeiten im Ablauf werden mit Supportfunktionen gefüllt und Iterationen durch zeitparalleles Arbeiten vermieden.
Maßstab für die erfolgreiche Stapelvernichtung ist das Verhältnis von gleichzeitig bearbeitbaren Projekten (für alle Teams) zu gleichzeitig in der "Pipeline" befindlichen Projekten. Flussorientierte, schnelle Entwicklungsabteilungen zeigen hier ein Verhältnis nahe 1 zu 1. Die Entwickler arbeiten demnach dann am effektivsten, wenn sie zwei Projekte gleichzeitig betreuen. Bei mehr oder weniger Projekten verringert sich der Output pro Zeiteinheit. Geistiges Rüsten bzw. Wartezeiten auf Unterstützungsfunktionen sind "die" Produktivitätskiller.
Im beschriebenen Projekt ist mit der operationalisierten Zielsetzung eine beeindruckende Eigendynamik erzeugt worden. "Was du heute kannst besorgen.....", so unspektakulär können "Erfolgsrezepte" sein.
erschienen in CIM Aktuell, November 2011