Februar 17th, 2010
Im vorangegangen Beitrag hatte ich beschrieben, dass in großen Strukturen (Projekte oder Organisationen) der Aufwand bestimmte Parameter zu überwachen sehr schnell ansteigen kann. Diese Schlussfolgerung ergibt sich aus rein kombinatorischen Überlegungen wenn man versucht mögliche Abhängigkeiten und Kausalitätsketten (Was passiert wenn …) zu analysieren. Dieses Phänomen ist in Anwendungen der Systemanalyse wie z.B. der Sicherheitsanalytik wohl bekannt, siehe Literaturhinweis. Eine naheliegende Lösung die Wechselwirkungen einfach zu ignorieren – so wird es z.B. in der technischen Sicherheitsanalytik tatsächlich gemacht wird – hilft in Projekten nicht weiter. Zumindest hilft es nicht weiter, wenn man die schlechte Erfolgsquote großer Projekte verbessern will.
Die kombinatorische überproportional mit der Größe des Projektes oder der Organisation wachsende Lawine macht jeden allumfassenden und mikromanagenden Steuerungsansatz zur vergeblichen Sisyphusarbeit. Die Lawine resultiert aus den Abhängigkeiten, die durch das manchmal zwanghafte Erstellen eines Gesamtprojektplans entstehen. Nebenstehende Abbildung veranschaulicht wie in vielen Projekten aus einer definierten Struktur – Arbeitspakete ermittelt, zusammengeführt und zu einem Gesamtplan zusammengebaut werden. Ein weiteres Problem bei dieser Vorgehensweise besteht darin, dass Vogel und Froschperspektive gemischt werden und am Ende niemand richtig mit dem Plan arbeiten kann. Aus dieser Falle gibt es nur ein Entrinnen. Es müssen echte Teilprojekte definiert werden. Ein echtes Teilprojekt unterscheidet sich von einem Pseudo Teilprojekt dadurch dass es für das Gesamtprojekt wie eine Blackbox ist. Es muss lediglich klipp und klar sein, wann das Teilprojekt was an das Gesamtprojekt liefert. Die Arbeitspakete im Inneren des Teilprojektes haben das Gesamtprojekt nicht zu interessieren. Das klingt trivial – aber Hand aufs Herz – wer hat noch nicht erlebt, dass eine Gesamtprojektleitung auf Arbeitspaketebene doch in ein Teilprojekt hineingreift, von Eingriffen aus der Linienorganisation mal ganz zu schweigen. Ich unterstelle, dass es in den meisten großen Projekten an der Tagesordnung ist in die Teilprojekte durchzugreifen. Zum einen ist das ein heute weit verbreiteter Führungsstil, zum anderen fehlt es oft an Vertrauen. Ja – die Gesamtprojektleitung muss den Teilprojektleitern vertrauen, dass sie das Ergebnis liefern, die Teilprojektleiter müssen im Gegenzug ehrliche Aussagen treffen ob und wann sie liefern können.
Hier schließt sich der Kreis zu dem was ich vor einigen Tagen über die Selbstorganisation und das Vertrauen geschrieben habe. Auch der Teilprojektleiter, der ggf. mit einem selbstorganisierten Team arbeitet, darf nicht in den Fehler verfallen mit Mikromanagement die Arbeit seines Teams im Detail steuern zu wollen. Auch er muss sich auf sein Team verlassen, braucht Vertrauen und muss sein Team nach außen ehrlich und authentisch vertreten. Es ist hierbei unerheblich ob wir jetzt von Scrum-Mastern, Product-Ownern oder anderen Rollenbezeichnungen reden. Es geht immer um das Wechselspiel von Vertrauen, Ehrlichkeit und offener Kommunikation und zwar in alle Richtungen und auf allen Ebenen. Wie sich aus nebenstehender Grafik schon erahnen lässt, landen wir bei konsequenter Anwendung dieses Prinzips bei einer Kapselung und letztendlich selbstähnlichen Struktur des Projekts oder der Organisation. Egal welches Team oder welche Ebene wir herausgreifen, es gibt immer eine Gruppe von Menschen, die einen Vertreter in eine andere Gruppe entsenden, Ziele und Anforderungen erhalten und Ergebnisse liefern. Die Gruppen selbst müssen weitgehend selbstorganisiert sein. Wenn sie nicht selbstorganisiert sind benötigen sie wiederum Steuerung von außen und damit landen wir wieder bei der schlecht funktionierenden Gesamtsteuerung. Mit diesem Prinzip lassen sich auch sehr große Projekte oder Organisationen gestalten. Wenn sehr viele Teams am Projekt arbeiten, müssen mehrere “wolkenartige” Vertretergruppen gebildet werden von denen wiederum jede einen Vertreter in eine Vertreter-Vertreter-Gruppe entsendet. Bei jeweils 6 Personen in einem Team lassen sich mit einer Vertreter-Vertreter-Gruppe schon Organisationen mit ca. 250 Personen abbilden (258 = 6 + 6 * 6 + 36 * 6) – das ist für ein Projekt schon eine ganze Menge. Voraussetzung ist aber, dass sich die Gesamtleitung nicht in die Vertreter-Gremien einmischt und diese wiederum sich nicht in die Teamarbeit einmischen.
Das Ganze funktioniert nur wenn die Teilprojekte als “Black Boxes” betrachtet werden und eine ähnliche Größe haben. Die in der Grafik gezeigte Größe der Teams ist zudem nicht zufällig gewählt. Eine Gruppengröße von 4 bis 8 Personen enthält ein hohes Potential, dass sich bei einem konstruktiven Verlauf der Gruppendynamik voll entfalten kann. Größere Gruppen zerfallen wiederum schnell in Untergruppen. Auf welcher Ebene wir im Projekt auch hinschauen sehen wir lediglich eine Gruppe in einer arbeitsfähigen Größe, die jeweils einen Vertreter entsendet. Selbstähnlichkeit pur. Wenn diese Selbstähnlichkeit durchgehalten wird, wächst der Gesamtprojektplan übrigens nur noch linear mit der Größe der Struktur. Für jedes neue Team das hinzukommt wird im übergeordneten Gantt-Diagramm nur ein Balken benötigt.
Die Basis auf der das Ganze funktioniert, ist das Vertrauen. Sobald das Prinzip “Kontrolle ist besser” Einzug hält ufert der Kontrollaufwand wieder exponentiell aus.
Das mag sich alles sehr provozierend oder idealistisch anhören – ist es aber nicht. Dieses Prinzip wird an vielen Stellen angewendet. Beispiel gefällig: Ein Kapitän auf einem Schiff gibt an den Maschinenraum das Kommando “halbe Kraft voraus” , um die Organisation des Maschinenraums künmert er sich nicht. Er kümmert sich auch nicht um den Zustand der Ladung oder den täglichen Schiffsbetrieb. Jedem ist offensichtlich klar, dass er sich darum nicht kümmern darf sonst würde ihm die Kapazität würde seinen eigentlichen Job fehlen. Für die Umsetzung seiner Anforderung im Maschinraum ist z.B. der LI (Leitender Ingenieur) zuständig. Wenn im Maschinenraum ein Problem auftritt, das nicht im Maschinenraum gelöst werden kann trägt der LI das Problem zum Kapitän.
Meine wirklich provozierende Schlussfrage lautet: Warum soll ausgerechnet in Projekten und Organisationen das Durchgreifen durch mehrere Handlungsebenen eine gute Lösung sein.
Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell – Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”. Er gehört zum Abschnitt 2C, siehe Mindmap zu Inhalt und Struktur.
in Kategorie(n): Buch: Mensch im Projekt, Projektmanagement RT
Schlagworte: Buch: Mensch im Projekt, Organisationen, Planung, Selbstorganisation.
3 Kommentare »
