Multiprojektmanagement: Der heilige Gral des Managements

Es ist eine traurige Tatsache, dass in der Wissensarbeit im heutigen VUCA-Umfeld die Matrixstruktur und Projekte immer seltener erfolgreich sind. Dies liegt unter anderem daran, dass …

• Projekte häufig ohne genügende Berücksichtigung der bereits laufenden Projekte geplant werden,
• die Gesamtheit der Projekte die Kapazitäten der beteiligten Ressourcen und Mitarbeiter zu 100% auslasten, manchmal sogar darüber!
• Dadurch bereits kleinste Planänderungen eines Projekts, sehr große Auswirkungen auf die anderen Projekte haben.

Dieses Problem zu lösen, d.h. die Abhängigkeiten zu managen, ist die Aufgabe von Multiprojektmanagement. Hierzu gibt es seit einigen Jahren gut klingende Ansätze, die meist rechner-gestützte Optimierungen nutzen. Leider habe ich aber noch keinen gut funktionierenden Ansatz dazu gesehen.

Das Problem ist, dass Menschen, insbesondere Wissensarbeiter, sich nicht wie Maschinen verwalten lassen. Wir müssen damit aufhören, Menschen prozentweise in effizienz-optimierte Projekte zu stecken! 

Sind stabile Teams die Lösung?

Aus der Verhaltensforschung und aus der Erfahrung wissen wir, dass Menschen am besten in langlebigen Strukturen zusammenarbeiten in denen sie sich gegenseitig gut kennen, schätzen, trauen und respektieren, z.B. in „Sippen“, Tribes oder Cluster mit maximal ca 150 Mitglieder (siehe dazu auch „Dunbar-Zahl„) . Stabile Teams innerhalb der Cluster erhöhen das Zugehörigkeitsgefühl und reduzieren die Einarbeitung.

Wenn wir es nun schaffen, Projekte nicht jedes Mal mit der effizientesten und vermeintlich optimalsten Besetzung auszustatten, sondern Projekte an das am besten geeignete existierende Team zu geben, haben wir die Komplexität des Projektmanagements bereits um eine Größenordnung vereinfacht. Ein stabiles Team wird natürlich nie in Gänze und über längere Zeit komplett unverändert bleiben. Die natürliche Fluktuation der Mitarbeiter sorgt schon im „Normalfall“ für genügend Veränderungen.

Stabile Teams werden ebenfalls nie optimal für ein Vorhaben passen. Es reicht aber, wenn der Kern des Teams (Nucleus) stabil bleibt. Je nach Situation kann der Kern des stabilen Teams durch benötige Experten ergänzt werden. Diese nennen wir im P4-Framework Extended-Team.

Existieren mehrere ähnlich geeignete Teams, können diese aus dem gleichen Projekt-Portfolio mit Arbeit versorgt werden.

Adressieren wir nun das zweite Problem: Zu viele gleichzeitige Projekte. Wie kommt es dazu? Meines Erachtens liegt dies häufig daran, dass niemand genau weiß, wie viel unsere Organisation als Ganzes leisten kann, und so werden, nach dem Motto „Unter Druck entstehen Diamanten“, mehr Projekte gestartet als eigentlich möglich sind, in der Hoffnung wenigstens einige davon rechtzeitig geliefert zu bekommen. Häufig liegt die Ursache des Problems aber auch an der Vielzahl von höheren Managern, internen Kunden und Stakeholdern, von denen jeder seine eigenen Projekte forciert, was zu Verhandlungen der Projektaufwänden und zusätzlicher Konkurrenz unter den Projekten führt. Eine interne Demand/Supply-Organisationsstruktur unterstützt diese Effekt.

Um das Problem zu lösen müssen wir zuerst zwei Dinge tun:

1. Wir müssen den tatsächlichen Aufwand messen, wie viel ein Team, ein Cluster oder die ganze Organisations, in ein Projekt gesteckt hat und
2. wir müssen dies ins Verhältnis der ursprünglichen Schätzung setzen.

Dadurch können wir die ursprüngliche Schätzung mit dem tatsächlichen Aufwand abgleichen. Da wir ja stabile Teams haben, werden sich diese Werte über die Zeit nur wenig verändern.

Nun kommt Trick Nummer 3: Wir lassen die Schätzungen von den bearbeitenden Teams durchführen. Dadurch werden die Schätzungen besser. Wir nutzen dabei eine einheitenlose Größe und lassen die Teams die Projektaufwände relativ zueinander schätzen. Dadurch ist die Aufwandsschätzung nicht direkt mit einer Zeitangabe vergleichbar. Außerdem vermeiden wir, dass Einzelpersonen und Teams unterschiedliche Puffergrößen einbeziehen.

Trick Nr. 4 ist zugegebenermaßen der schwierigste: Wir geben den bearbeitenden Teams nur klare Prioritäten und lassen sie danach selbstbestimmt, in ihrer eigenen Geschwindigkeit arbeiten, d.h. ohne Druck aber stark fokussiert und total transparent. Hierdurch entsteht eine hohe Motivation im Team und eine vorhersagbare Leistung des Teams (auch bekannt als Velocity).

Trick Nummer 5: Die Kapazität des Teams wird niemals komplett verplant. Es gibt einen vereinbarten Puffer für ungeplante Arbeiten und Leistungsschwankungen und einen zweiten Puffer für interne Verbesserungsmaßnahmen. Dieser Puffer wird empirisch ermittelt und angepasst.

Trick Nummer 6: Ist der Anteil der ungeplanten Arbeiten zu groß, stellen wir Gruppen von Mitarbeitern oder ganze Teams ab, die sich dann nur noch um diese „Support-Tätigkeiten“ kümmern.

Ziel all dieser Maßnahmen ist die Verbesserung der Vorhersagbarkeit der Team-Ergebnisse und Lieferungen. Die sich aus den vorigen Maßnahmen ergebende lieferbare Leistung des Team lässt sich mit einiger Sicherheit versprechen und terminlich einplanen. Hierfür verwenden stabile Teams einen festen Lieferrhythmus, z.B. Iterationen, Sprints, Release-Zyklen (Cycles).

Wichtig ist, dass Versprechen erst zugesagt werden, wenn die obigen Bedingungen eingetreten sind, d.h. dass sich eine vorhersagbare Lieferleistung eingestellt hat. Vorher gemachte Versprechen führen wieder zu mehr Druck, mehr Parallelarbeit, Abkürzungen, Fehlern und Demotivation.

Externe Mitarbeiter

Das Gegenteil von stabilen Teams sind hyper-fluide Teams, die sich kurzfristig, je nach Situation ändern können. (Ein weiterer Wunschtraum des klassischen Managements). Wenn sich die Projektsituation ändert werden eben mal schnell externe „Ressourcen“ besorgt.

Ein heute sehr häufig anzutreffender Ansatz ist, die benötigten Mitarbeiter einfach extern einzukaufen, sei es durch Anheuern von freien Mitarbeitern oder durch Vergabe von Teilprojekten.

Dies verspricht, immer zum richtigen Zeitpunkt die richtigen Ressourcen in die Projekte zu holen und auch wieder schnell loszuwerden, wenn das Projekt beendet ist. Beide Beweggründe sind verständlich: Häufig wurde es verpasst, die benötigten Mitarbeiter rechtzeitig aufzubauen (Warum auch, die Budgets kommen ja meist aus den Projekten). Außerdem sollen die Kosten nach dem Projekt wieder möglichst gering sein.

Der kurzfristige Auf- und Abbau von externen Projektmitarbeitern hat einige Nachteile, die aber meist die Projekte ausbaden müssen, nicht die beteiligten Abteilungen:

• Externe Mitarbeiter müssen fachlich und organisatorisch eingearbeitet werden. Das kostet Zeit und Kapazität der einarbeitenden internen Mitarbeiter.
• Externe Mitarbeiter müssen sich (wie auch neue interne Mitarbeiter) in das Projektteam integrieren. Dieses Forming, Norming, Storming, Performing reduziert die Leistung von Teams, zumindest in den ersten Wochen eines Projekts.
• Externe Mitarbeiter dürfen entweder aus gesetzlichen Gründen (Mitarbeiterüberlassung) oder aus internen Sicherheitsgründen (New-to-know) nicht auf alle Datensysteme zugreifen, die interne Mitarbeiter nutzen. Damit überhaupt Arbeit stattfinden kann, gibt es manchmal die abenteurlichsten Konstrukte (Erzeugen und Verwalten von gedoppelten Daten, mehrfaches Eintragen von abzurechnenden Stunden, …). Die sich daraus ergebenden Behinderungen mindern die Leistung und die Moral der Teams zusätzlich
• Daneben verliert die Organisation über die Zeit aber auch viel Fach- und Anwendungswissen, wodurch sie sich noch mehr von Dienstleistern abhängig macht. Insbesondere für Kernkompetenzen und Innovationsbereiche ist das sehr gefährlich für die Organisation.

Die Lösung hier ist relativ einfach, benötigt aber Weitblick. Die Organisation muss eine Strategie entwickeln, welches Wissen intern zu halten bzw. aufzubauen ist. Dafür müssen dann frühzeitige die richtigen Mitarbeiter gesucht und die existierenden Mitarbeiter ausgebildet werden Nur für Wissensbereiche, die langfristig nicht von strategischer Bedeutung sind, macht es Sinn, externe Mitarbeiter und Dienstleister zu beauftragen.

Sind Sie noch auf der Suche nach dem heiligen Gral des Projektmanagements? Ich würde mich über Ihre Fragen in den Kommentaren freuen, aber auch über Lösungen, die Sie vielleicht gefunden haben.

Foto von jcomp auf Freepik