Fast jedes Unternehmen steht vor der Herausforderung zu entscheiden, welche Projekte es umsetzt. Diese Auswahl wird Vorhabenplanung genannt, Portfolio-Planung oder Portfolio-Management und ist nicht einfach. Oftmals funktioniert Portfolio-Planung ungefähr nach folgendem Modell:
Zunächst ist da ein Projekt, das eine Fachabteilung umsetzen möchte oder umsetzen soll. Dafür muss sie einen Business Case für das Projekt aufstellen. Damit er bessere Chancen hat angenommen zu werden, rechnet die Fachabteilung den Business Case eventuell schön.
Das Ergebnis wird dann als Projektantrag verpackt an ein Gremium zur Beurteilung gegeben – typischerweise ein PMO oder ein wie auch immer gearteter Steuerkreis. Unter den eingereichten Vorhaben, die nicht aus formalen Gründen aussortiert wurden, werden dann anhand prognostizierter Wertbeiträge (wie gesagt: typischerweise geschönt) die mit den besten Zahlen ausgewählt und freigegeben. “Freigeben” bedeutet in diesem Zusammenhang, dass die im Business Case angegebenen Kosten als “Budget” genehmigt werden und das Projekt starten darf. All gestarteten Projekte bilden das Projekt-Portfolio.
Problematische Scheingenauigkeit
Dieses Vorgehen birgt mehrere Probleme: Zunächst einmal kann das Entscheidungsgremium den Business Case allenfalls formal, aber kaum inhaltlich prüfen. Wie sollte das Gremium auch die Themen besser beurteilen können als die jeweilige Fachabteilung, die sich intensiv damit beschäftigt hat?
Doch auch für die Fachabteilung ist der Business Case häufig überhaupt nicht sinnvoll abschätzbar – weder die Kosten, noch der Nutzen. Diese Erkenntnis ist absolut naheliegend, wenn man sich vergegenwärtigt, aus welcher Überlegung agile Entwicklungsmethoden entstanden sind: Es war die Einsicht, dass sich im Laufe eines Projektes viel zu viele Dinge ergeben und ändern werden, als dass man es zu Beginn sinnvoll abschätzen könnte.
Dementsprechend haben die freigegebenen Budgets dann auch auffallend häufig nichts mit dem tatsächlichen Budget-Bedarf zu tun. Typischerweise werden sie im Business Case zu niedrig ausgewiesen um ihn schön zu rechnen. Das ist für den Beantragenden allerdings kein Problem, da die meisten Unternehmen dazu neigen, einmal gestartete Vorhaben nicht zu hinterfragen, sondern weiter zu finanzieren, wenn sie ihr Budget überschreiten.
Wenn das Projekt dann irgendwann doch mit Mehrkosten erfolgreich zu Ende geht, sind alle Beteiligten darüber in der Regel so froh, dass auch keine Nachbetrachtungen stattfinden, in denen man die tatsächlichen Kosten und den eingetretenen Nutzen den prognostizierten aus dem Business Case systematisch gegenüberstellt. Dieses Vorgehen begünstigt natürlich das Schönfärben von Business Cases weiter. Auf der anderen Seite werden einmal gestartete Vorhaben auch nicht gestoppt, selbst wenn sie ihre Ziele absehbar verfehlen. Dieses Unterlassen erhöht den Schaden für die Unternehmung weiter.
Am Ende wurde in einem zeitaufwändigen Prozess signifikant Aufwand verbrannt, der kein wirklich optimales Projekt-Portfolio produzierte. Diese Fehler werden im weiteren Verlauf auch nicht korrigiert, sondern ausufernde Projekte weiter finanziert und selten gestoppt.
Wie kann das besser funktionieren?
Ein Portfolio-Prozess im Großen muss natürlich die Einsicht von agilen Methoden im Kleinen berücksichtigen, wonach Projekte in der heutigen komplexen Welt nicht im Voraus plan- und abschätzbar sind. Ein möglicher Ansatz in der Portfolio-Planung damit umzugehen kann das folgende Vorgehen sein:
- Im ersten Schritt muss das Unternehmen natürlich auch hier gewünschte neue Projekte bewerten hinsichtlich der Chancen, die sie bieten. Im Idealfall macht man das anhand einer Kostenbetrachtung, einer Risikoanalyse und ihres Beitrags zur Unternehmensstrategie, so man denn eine hat (Das ist leider nicht selbstverständlich, aber unbedingt zu empfehlen!). Das Ganze sollte aber auf keinen Fall überformalisiert werden. Natürlich müssen zum Beispiel Strategiebeitrag und Kosten quantifiziert werden, aber es reicht vielleicht eine Einschätzung nach Kleidergrößen, d. h. „XS“ für sehr kleine Kosten, „S“ für kleine, „M“ für mittlere und so weiter. Sollten belastbare, objektive Daten fehlen, ist es auch in Ordnung, wenn das Entscheidungsgremium sich auf eine gemeinsame, subjektive Einschätzung einigt.
- Wie man die konkret zu startenden Projekte auswählt, hängt nun im Wesentlichen von zwei Faktoren ab: der Bewertung und der Verfügbarkeit der notwendigen Ressourcen. Natürlich kann man keine Projekte starten, wenn die dafür nötigen Ressourcen nicht verfügbar sind.
- Mit nötigen Ressourcen ist aber keineswegs gemeint, dass alle Ressourcen verfügbar sein müssen, die das Projekt während der gesamten Laufzeit jemals brauchen könnte (Budget) – denn das wissen wir gar nicht! Wichtig ist es mit den für einen sinnvollen Beginn nötigen Ressourcen Projekte agil zu starten. (Was allerdings auch heißt, dass die entsprechenden Mitarbeiter das neue Projekt nicht als dreizehntes zu ihren bisherigen Aufgaben dazu bekommen, sondern ernsthaft Zeit dafür zur Verfügung haben. Scrum fordert, dass alle Rollen Vollzeit im agilen Team an einem Thema arbeiten.)
- Wenn diese Projekte wirklich agil gestartet sind, werden sie fortlaufend Einsichten gewinnen: Welchen Nutzen erzeuge ich wirklich? Welche Dinge funktionieren gut, welche schlecht? Wie haben sich äußere Umstände geändert? Davon abgeleitet: In welche Richtung soll ich mich weiterentwickeln? Welche Ressourcen brauche ich dafür?
- Anhand dieser Erkenntnisse muss das Unternehmen sein bestehendes Projekt-Portfolio reviewen, d. h. neu bewerten.
- Der wichtige Schritt ist nun der, aus dem so Gelernten Konsequenzen abzuleiten: Projekte, die Erwartungen absehbar nicht erfüllen können, müssen gestoppt werden und Ressourcen frei geben. Andere Projekte müssen auf Grund geänderter Marktbedingungen eventuell umsteuern und benötigen andere Ressourcen. Vielleicht tauchen auch neue Projektideen auf, die einen höheren Strategiebeitrag erwarten lassen. Dann müssen andere Projekte pausieren oder verlangsamt werden, die auf den gleichen Ressourcen operieren.
Dieser Prozess ist natürlich kein einmaliger, sondern muss regelmäßig durchgeführt werden. Jedes halbe Jahr kann ein gutes Startintervall sein.
Agil im Großen
Die Vorteile dieses Vorgehens gegenüber dem klassischen Ansatz sind enorm:
- Das Unternehmen erzielt eine kürzere time-to-market, da viel weniger Zeit (und auch Aufwand) nötig ist, bis das Projekt starten kann.
- Frühes Lernen durch agile Umsetzung ermöglicht eine realistischere Sicht auf die Potenziale der Projekte als hypothetische Business-Case-Rechnungen. Wenn im Zeitverlauf neue Erkenntnisse Anpassungen an der Zielrichtung sinnvoll erscheinen lassen, so fördert dieser Ansatz, dass diese Anpassungen auch vorgenommen werden. Nur so kann weiterhin der beste Strategiebeitrag erzielt werden – und damit die Chance optimiert, dass das Projekt weitergeführt wird. Der klassische Ansatz hingegen bestraft eher Änderungen im Vorgehen: Die Erwartung dort ist, dass ein Projekt vom Anfang bis zum Ende gemäß ursprünglich aufgestelltem Kosten-, Ablauf- und Zeitplan durchgeführt wird. Häufig wird die Einhaltung genau dieser Prognose vom Projekt-Controlling (z. B. dem PMO) überwacht.
- Die regelmäßigen Anpassungen des Portfolios führen zu einer viel besseren Nutzung von Ressourcen. Anstatt sie mitunter auf Jahre hin zu blockieren für Vorhaben, die schon lange nicht mehr relevant sind, werden sie regelmäßig für die Projekte mit dem besten Strategiebeitrag verwendet.
- Das Portfolio insgesamt wird auch besser insofern, als fortwährend der beste Strategiebeitrag durch die Projekte im Portfolio erzielt wird.
Man muss dazu sagen, dass solch ein agiler Portfolio-Prozess nicht immer umsetzbar ist. Wenn ein Großteil des Projektvolumens über externe Dienstleister abgewickelt wird, werden häufig Werkverträge – eventuell zum Festpreis – über das Gesamtprojekt abgeschlossen. Solch ein Projekt lässt sich dann nur schwer umsteuern, auch wenn erste Erfahrungen im Projektverlauf Anpassungen nahe legen. Stoppen lässt es sich oftmals gar nicht ohne großen wirtschaftlichen Verlust.
Der Ausweg lautet: Auch externe Beauftragungen sollten agil vergeben werden! Warum das Vorteile hat, trotz der damit verbundenen Unsicherheit über die Gesamtkosten, oder ob ein agiler Festpreis realistisch ist, ist Gegenstand des Beitrags Agil mit Dienstleister.