CONTROLLER Magazin 1/2020

34 Anders verhält es sich mit dem Management allgemeiner Information und vorhandenem so- wie neu erzeugtem Wissen. Hier bietet es sich an, dass der Zugriff nach dem Hol-Prinzip um- gesetzt wird, um einen sog. Information Over- flow zu vermeiden, bei dem Informationen teil- weise ungezielt aus der Sicht des Empfängers bedarfsfrei (Zeit, Inhalt) gestreut werden. Es er- gibt sich der Bedarf nach Anwendung eines ad- äquaten (Projekt-)Wissens-, mindestens jedoch Dokumentenmanagements: ➡ Allgemeine projektbezogene und übergrei- fende Informationen (Wissen) sollten nach dem Hol-Prinzip bereitgestellt werden. Perfektion in Projekten Streben nach Perfektion – das ist ein zentrales Gestaltungsprinzip des Lean Thinkings. Doch was heißt Perfektion im Projektkontext? Kann es pauschal das Ziel eines Projekts sein, (nur) perfekte Lösungen zu erzeugen? Grundlage für die Frage, wieviel Perfektion in einem Projekt zu erzielen ist, liefert der Projektauftrag. Dieser ist das Bindeglied zwischen dem übergeordneten Projektnutzen (Business Case) und den konkre- ten, nach Möglichkeit smart definierten opera- tiven Projektzielen (spezifisch, messbar, akzep- tiert/anwendbar, realistisch und terminiert). Der Projektauftrag umfasst vielfach ein Lasten- und ein Pflichtenheft. In agilen Vorgehensweisen werden die Anforderungen und Lösungsansät- ze in der Regel erst im Verlauf des Projekts kon- kretisiert (und die Projektziele weniger smart werden, wenn diese nachgefragt werden. Also fragt etwa der Projektleiter sein Team nach ei- nem Statusbericht, der daraufhin erstellt wird. Dies erweist sich in der Praxis aus der Sicht der Autoren aber als unpraktikabel, da bei Verzöge- rung eine fehlende und lückenhafte Berichter- stattung vorprogrammiert ist. Daher hat sich in der Praxis auch ein Berichtswesen nach fest etablierten und idealerweise den projektspezifi- schen angepassten Erfordernissen bewährt. Entscheidend ist dabei, dass der Rhythmus projektadäquat ist und der Berichtsempfänger auch zeitnah die erhaltene Information verar- beitet. Konkret: Ein Projekt, das drei Monate dauert, sollte mindestens einen wöchentlichen Status feststellen, ein (großes) Projekt, das drei Jahre dauert, kann hier im Allgemeinen größe- re Abstände zulassen. Auch der übergeordnete „Heartbeat“ der Organisation – etwa monatli- che Steuerkreis-Sitzungen – zieht diesbzgl. an der Informationslieferung. Professionelles Projektmanagement ist durch proaktives Handeln gekennzeichnet. D. h. eine Risikoanalyse wird besser nicht erst durch- geführt, wenn die Krise bereits eingetreten ist; Kommunikation mit den Stakeholdern nicht erst, wenn diese schon Schwierigkeiten erzeu- gen, etc. Insofern ist das Pull-Prinzip im Allge- meinen hier nicht sinnvoll anwendbar. Wichtige Botschaft bleibt aber: ➡ Keine (PM-) Ergebnisse auf Halde produzie- ren, sondern zeitnah, unter Einbeziehung der jeweils aktuellsten Erkenntnisse, an der Folgehandlung orientiert. Work in Progress-Limitierung Das CCPM postuliert im besonderen Maße die Vermeidung schädlichen Multitaskings. Eine mögliche Praktik zur Umsetzung dieses Grund- satzes hat sich aus der Kanban-Methode der Lean Production abgeleitet: der Einsatz von Kanban-Boards zur selbststeuernden Organi- sation des Arbeitsflusses in Projekten. Ein sol- ches Board, das je nach Projektkontext spezi- fisch ausgestaltet werden kann, ist in Abbil- dung 4 dargestellt. Das Pull-Prinzip wird insofern umgesetzt, als dass bei freier Bearbeitungskapazität (d. h. die aktuelle Arbeitslast ist unterhalb der sog. Work in Progress-Limitierung ) die nächste anstehende Aufgabe vom Bearbeiter/-team gezogen wird. Hier wird also ein kapazitätsbe- zogener Pull-Mechanismus umgesetzt, im Ge- gensatz zum bedarfsbezogenen Pull im Lean Production-System. Mit Abbildung 4 erweitern wir das übliche Pro- jekt-Kanban-Board um einen klassischen Pro- jektplan als Taktgeber aus übergeordneter Per- spektive. Aus dem Plan ergeben sich rollierend die Aufgaben, die als „Next to do“ zur Bearbei- tung anstehen. Ein Push-Pull-Mechanismus entsteht im Sinne eines hybriden Projektma- nagements. Was bedeutet das Pull-Prinzip für die PM-Ebene? Auf der Ebene der Projektma- nagementprozesse hieße Pull, dass Informatio- nen (denn um diese geht es in erster Linie in dieser Domäne) dann erzeugt und bereitgestellt Abb. 4: Kanban-Board mit vorgeschaltetem Projektplan im Push-Pull-Prinzip Klassisch oder agil? Hauptsache Lean!