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

Cookies und externe Dienste erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Dienste verwenden. Weitere Informationen dazu finden Sie in unserer Datenschutzerklärung.