Was ist eigentlich nötig, um ein Projektportfolio wirksam zu steuern?

Ein Projektportfolio zu steuern klingt zunächst nach einer überschaubaren Aufgabe. Projekte sichtbar machen, Status einsammeln, Prioritäten festlegen und regelmäßig berichten. In der Praxis reicht das nicht. Je größer ein Portfolio wird, je mehr Bereiche beteiligt sind und je stärker Projekte um dieselben Ressourcen konkurrieren, desto wichtiger wird die Frage, was auf Portfolioebene überhaupt gesteuert werden soll.

Denn Portfoliosteuerung ist keine zusätzliche Kopie der Projektsteuerung. Sie ist eine eigene Ebene mit einem eigenen Zweck. Sie soll Zusammenhänge sichtbar machen, Entscheidungen vorbereiten und Auswirkungen über einzelne Projekte hinaus betrachten. Damit das funktioniert, muss zunächst klar sein, welches Portfolio überhaupt gemeint ist, wer es steuert und welche Entscheidungen auf dieser Ebene getroffen werden sollen.

---

---

Wie definiere ich mein Projektportfolio?

Ein Projektportfolio kann sehr unterschiedlich geschnitten sein. Es kann alle wesentlichen Projekte eines Unternehmens umfassen. Es kann sich ausschließlich auf IT-Projekte beziehen, auf Kundenprojekte, Engineering, Investitionen oder strategische Initiativen. Diese Abgrenzung ist keine Formalität. Sie bestimmt, welche Informationen benötigt werden, welche Abhängigkeiten relevant sind, welche Personen eingebunden werden müssen und wie nah die Portfoliosteuerung an den eigentlichen Entscheidungen sitzen sollte.

Ein IT-Projektportfolio mit 30 oder 40 Vorhaben braucht eine andere Steuerungslogik als ein unternehmensweites Portfolio, in dem gleichzeitig IT-Projekte, Standortvorhaben, Kundenprojekte, Reorganisationen, strategische Programme und möglicherweise Unternehmenszukäufe zusammenlaufen. Gerade strategische oder vertrauliche Projekte zeigen, warum diese Abgrenzung wichtig ist.

Nehmen wir beispielsweise den Zukauf eines Unternehmens. In einer frühen Phase ist der Kreis der Beteiligten bewusst klein. M&A-Experten, Geschäftsführung, Legal, HR oder weitere ausgewählte Funktionen sind eingebunden. Die Informationen sind hochsensibel und können nicht ohne Weiteres in einem regulären Projektportfolio auftauchen.

Wenn es lediglich ein IT-Projektportfolio gibt, muss die Portfolioleitung zu diesem Zeitpunkt möglicherweise gar nicht alle Details kennen. Relevant kann zunächst nur sein, dass bestimmte Schlüsselressourcen in einem vertraulichen strategischen Vorhaben gebunden sind und deshalb für andere Projekte nicht oder nur eingeschränkt zur Verfügung stehen. Mit fortschreitender Integration verändert sich das. Weitere Bereiche kommen hinzu, Systeme werden konsolidiert, Mitarbeitende integriert und operative Abhängigkeiten entstehen.

Bei einem unternehmensweiten Portfolio wäre das Vorhaben dagegen deutlich früher relevant, weil seine Auswirkungen auf andere Bereiche und Projekte zentral gesteuert werden müssen. Der entscheidende Punkt ist deshalb: Portfoliosteuerung beginnt mit der Definition ihres eigenen Steuerungsraums. Ohne diese Festlegung lässt sich weder ein sinnvolles Reporting noch eine passende Governance aufbauen.

---

Portfolio-Reporting ist mehr als Projekt-Reporting

Viele Reporting-Strukturen entstehen nicht mit der Entscheidung, die getätigt werden soll, sondern genau andersherum. Zunächst wird gesammelt, welche Daten aus den Projekten verfügbar sind. Anschließend werden Felder, Statusberichte und Dashboards aufgebaut. Und erst später wird überlegt, was mit all diesen Informationen eigentlich passieren soll.

Aus meiner Sicht sollte man die Logik umdrehen: Zuerst muss klar sein, welche Entscheidungen auf Portfolioebene getroffen werden sollen. Erst daraus ergibt sich, welche Informationen dafür benötigt werden.

Wenn ein Gremium beispielsweise über Prioritäten, Ressourcen oder Eskalationen entscheiden soll, braucht es andere Informationen als ein Projektteam, das den nächsten Meilenstein vorbereitet. Das Reporting sollte deshalb von der Entscheidung rückwärts gedacht werden.

Eine der häufigsten Fehlentwicklungen entsteht dann, wenn auf Portfolioebene einfach dieselben Informationen wie auf Projektebene abgefragt werden. Jede zusätzliche Information erzeugt Aufwand. Sie muss erhoben, geprüft, aktualisiert und oft mehrfach anders aufbereitet werden. Deshalb lohnt sich bei jedem Reportingfeld eine einfache Prüfung: Was machen wir mit dieser Information?

Wenn daraus weder eine Entscheidung noch eine konkrete Handlung entsteht und die Information auch sonst keinen klaren Nutzen hat, sollte hinterfragt werden, warum sie regelmäßig erhoben wird. Reporting ist kein Selbstzweck.

Auf Projektebene werden viele Details benötigt, um das einzelne Vorhaben tatsächlich steuern zu können. Auf Portfolioebene geht es dagegen stärker um die übergreifenden Zusammenhänge: um kritische Abhängigkeiten zwischen Projekten, gemeinsame Ressourcenengpässe, wesentliche Risiken und Veränderungen, die Auswirkungen auf andere Vorhaben haben. Ebenso muss sichtbar werden, wo ein Projekt Unterstützung oder eine Entscheidung außerhalb seines eigenen Mandats benötigt.

Auch innerhalb der Portfolioebene hängt die notwendige Granularität davon ab, wer das Portfolio steuert. Ein CIO mit einem überschaubaren IT-Bereich ist häufig vergleichsweise nah an den Projekten. Dort kann das Reporting für das Projektportfolio anders aussehen als auf C-Level. Auf Geschäftsführungsebene müssen möglicherweise völlig unterschiedliche Vorhaben gemeinsam eingeordnet werden. Entsprechend verändert sich auch der Informationsbedarf. Nicht, weil die Details unwichtig sind. Sondern weil auf dieser Ebene andere Entscheidungen getroffen werden.

---

Belastbare Daten brauchen eine offene Berichtskultur

Die beste Reportinglogik hilft wenig, wenn die zugrunde liegenden Informationen nicht belastbar sind. Gerade Statusberichte zeigen sehr schnell, wie eine Organisation mit Problemen umgeht. Ein Projekt wird auf gelb gesetzt, weil ein relevantes Risiko besteht. Kurz darauf beginnt die Diskussion, ob der Status nicht doch wieder grün sein könne. Ein roter Status wird möglichst vermieden, weil er auf Managementebene unangenehme Aufmerksamkeit erzeugt.

Damit kann keine Portfoliosteuerung sinnvoll arbeiten. Denn Entscheidungen können immer nur so gut sein wie die Informationen, auf denen sie basieren. Das Problem muss dabei nicht zwingend eine schlechte Unternehmenskultur sein. Manchmal reichen bereits über Jahre gewachsene Reportingregeln, um falsche Anreize zu setzen.

Wenn beispielsweise ein Projekt, das einmal auf Rot stand, danach nicht mehr auf Gelb oder Grün wechseln darf, wird sehr genau überlegt, ob Rot überhaupt gemeldet wird. Dabei sollte ein Projektstatus immer die aktuelle Handlungsfähigkeit abbilden.

Wenn die angeforderte Unterstützung erfolgt ist und das Problem gelöst wurde, muss sich auch die Statusfarbe wieder verändern können. Sonst beschreibt das Reporting nicht mehr die aktuelle Situation, sondern die Vergangenheit.

Entscheidend ist deshalb nicht nur die Definition einer Ampellogik. Entscheidend ist, ob eine Projektleitung tatsächlich sagen kann: Unter den aktuellen Voraussetzungen schaffen wir das nicht. Und ob diese Aussage anschließend zu Unterstützung und einer Entscheidung führt – statt zur Suche nach einem Schuldigen.

---

Priorisierung im Projektportfolio

Portfoliosteuerung betrachtet nicht nur einzelne Projekte, sondern deren Wechselwirkungen. Ein neues strategisches Vorhaben, eine regulatorische Anforderung oder ein großes Transformationsprojekt kann erhebliche Auswirkungen auf bereits laufende Projekte haben. Ressourcen werden verschoben, neue Abhängigkeiten entstehen, Termine verändern sich oder bisherige Prioritäten müssen neu bewertet werden.

Dabei ist nicht jede Veränderung für jedes Projekt relevant. Ein weitgehend eigenständiges internes Optimierungsprojekt kann beispielsweise unabhängig weiterlaufen, obwohl an anderer Stelle im Unternehmen ein strategisches Großprojekt startet.

Es geht nicht darum, einen künstlichen Zusammenhang zwischen sämtlichen Projekten im Portfolio zu erzeugen. Wichtig ist, dass die tatsächlichen Auswirkungen von Veränderungen bekannt sind und in die Portfoliosteuerung einfließen. Genau hier wird Priorisierung Teil der Portfoliosteuerung.

Wie neue Prioritäten, begrenzte Ressourcen, WIP und das bewusste Pausieren oder Stoppen von Projekten zusammenhängen, habe ich im Beitrag „Wenn alles Priorität hat: Wann Projektportfolios nicht mehr steuerbar sind“ ausführlicher beschrieben.

---

Governance soll unterstützen

Eine Portfoliosteuerung kann übergreifende Standards schaffen und Projekte gezielt unterstützen. Das ist sinnvoll, wenn dadurch nicht nur zusätzliche Anforderungen entstehen, sondern tatsächlich ein konkreter Nutzen. Zentral geregelt werden können beispielsweise Statusdefinitionen, Eskalationswege, regulatorische Anforderungen oder bestimmte Mindeststandards.

Gerade bei Themen wie Datenschutz, IT-Security, Betriebsratsbeteiligung, AI Act, Produkthaftung oder branchenspezifischen regulatorischen Vorgaben kann es sinnvoll sein, Anforderungen zentral aufzubereiten und den Projekten eine verlässliche Grundlage zur Verfügung zu stellen.

Daneben gibt es Themen, bei denen eine zentrale Unterstützung hilfreich sein kann, ohne die operative Projektarbeit vollständig zu standardisieren. Dazu gehören beispielsweise Methoden, Vorlagen, Schulungen, zentrale Tools oder Wissenstransfer.

Bevor zusätzliche zentrale Vorgaben eingeführt werden, sollte man sich aber immer im Klaren darüber sein, welchen konkreten Mehrwert diese für die einzelnen Projekte oder die gesamte Portfoliosteuerung haben. Standards sollten nämlich nicht nur zum Selbstzweck entstehen. Sie sollten dort eingesetzt werden, wo sie die Arbeit erleichtern, Vergleichbarkeit schaffen oder Risiken reduzieren.

Wie wichtig tragfähige Rahmenbedingungen, klare Rollen und Entscheidungswege für die einzelnen Projekte sind, habe ich im Beitrag „Erfolgreiche Projekte beginnen mit den richtigen Rahmenbedingungen“ ausführlicher beschrieben.

---

Lessons Learned müssen nutzbares Wissen erzeugen

Lessons Learned sind ein gutes Beispiel dafür, wie schnell eine grundsätzlich sinnvolle Methode zum Selbstzweck werden kann.

Ein großes Projekt ist abgeschlossen. Das Kernteam trifft sich noch einmal für einen halben Tag. Projektleitung, Sponsoren, Teilprojektleitungen und weitere Schlüsselpersonen diskutieren mehrere Stunden darüber, was gut lief und was beim nächsten Mal besser gemacht werden sollte.

Nehmen zehn Personen vier Stunden an diesem Workshop teil, entstehen bereits 40 Arbeitsstunden – noch ohne Vorbereitung und Nachbereitung. Dieser Aufwand kann absolut sinnvoll sein. Aber nur, wenn aus den Ergebnissen anschließend etwas entsteht.

Wenn am Ende allgemeine Aussagen dokumentiert werden wie „Ressourcen früher sichern“, „Termine rechtzeitig planen“ oder „Kommunikation verbessern“, stellt sich die Frage, welchen zusätzlichen Erkenntniswert diese Punkte für das nächste Projekt tatsächlich haben.

Eine relevante Lesson Learned wäre deutlich konkreter. Zum Beispiel: Ein SAP-Projekt stellt fest, dass die zwei geplante Testmigrationen für die Größe und Komplexität des Vorhabens nicht ausreichend waren. Kurzfristig musste eine dritte Testmigration ergänzt werden und der Go-live verschob sich.

Die übertragbare Erkenntnis könnte dann lauten: Für zukünftige SAP-Projekte vergleichbarer Größe werden von Beginn an drei Testmigrationen eingeplant. Das ist konkret, übertragbar und handlungsrelevant. Genau daraus entsteht organisationales Lernen.

Entscheidend ist dabei auch, auf welcher Ebene eine Erkenntnis überhaupt relevant ist. Manche Erfahrungen helfen ausschließlich dem aktuellen Projektteam. Andere sind für ein mehrjähriges Programm oder mehrere vergleichbare Projekte wichtig. Wieder andere sollten zu einer übergreifenden Vorgabe oder einem neuen Standard im Portfolio führen.

Eine Portfoliosteuerung sollte deshalb nicht möglichst viele Lessons Learned zentral sammeln. Sie sollte dabei helfen, die wenigen Erkenntnisse herauszufiltern, die über das einzelne Projekt hinaus wirklich relevant sind.

Genau hier liegt heute eine zusätzliche Chance in KI-gestützten Wissenssystemen.

Gerade bei großen Programmen, die über mehrere Jahre oder mehrere Waves laufen, kann ein abgegrenztes digitales Projektgedächtnis sinnvoll sein. Relevante Entscheidungen, Besprechungen, Projektdokumente und ausgewählte Lessons Learned werden dort strukturiert zugänglich gemacht. Statt später Ordner, Präsentationen und Protokolle durchsuchen zu müssen, kann gezielt auf bereits vorhandenes Projektwissen zugegriffen werden. Zum Beispiel: Was wurde zum Standort X in der Vergangenheit bereits entschieden oder festgelegt? Wo sind in der letzten Welle Verzögerungen entstanden? Welche Ursachen lagen dahinter? Und welche Punkte sollten wir deshalb bei der Planung der nächsten Welle von Beginn an berücksichtigen?

Dabei geht es nicht darum, möglichst alles ungefiltert zu speichern. Auch hier gilt: Nur Wissen, das später wieder auffindbar, einordenbar und nutzbar ist, schafft Mehrwert.

Wie KI sinnvoll in Unternehmensprozesse eingebettet werden kann, beschreibe ich ausführlicher im Artikel „KI-Einführung im Mittelstand: Prozess vor Technologie, Menschen im Mittelpunkt“.

---

Portfolioleitung braucht ein eigenes Kompetenzprofil

Eine wirksame Portfoliosteuerung braucht nicht nur eine klare organisatorische Verankerung, sondern auch eine Person, die zur Aufgabe passt. Wo die Funktion angesiedelt ist, hängt vom jeweiligen Portfolio ab. Entscheidend ist aber ebenso, wer diese Rolle übernimmt.

Eine gute Projektleitung ist nicht automatisch eine gute Portfolioleitung. Und auch eine gute disziplinarische Führungskraft bringt nicht automatisch alles mit, was für diese Aufgabe benötigt wird. Portfoliosteuerung verlangt ein eigenes Kompetenzprofil.

Die Anforderungen gehen damit deutlich über reine Koordination hinaus. Die Portfolioleitung muss komplexe Zusammenhänge über mehrere Projekte hinweg einordnen, verdichten und in eine Form bringen, die Steuerung und Entscheidungen ermöglicht.

Gerade bei Themen mit hoher Management Attention muss die Portfolioleitung sicher mit Geschäftsführung und C-Level kommunizieren können. Dort geht es nicht darum, zwanzig operative Detailprobleme zu berichten, sondern die Situation so aufzubereiten, dass Entscheidungen möglich werden. Relevant sind eine klare Einordnung der Veränderung, ihre Auswirkungen auf das Portfolio, realistische Handlungsoptionen und eine eindeutige Entscheidungsvorlage.

Gleichzeitig bewegt sich die Portfolioleitung zwischen Projektleitungen, Fachbereichen, Linienorganisation und Management. Unterschiedliche Interessen und Perspektiven müssen zusammengeführt werden, ohne dass die übergreifende Portfoliosicht verloren geht.

Deshalb sollte vor der Besetzung einer Portfoliofunktion bewusst geklärt werden, welche Fähigkeiten für genau dieses Portfolio benötigt werden. Erst danach sollte entschieden werden, wer die Rolle übernimmt. Die Portfolioleitung ist damit keine administrative Zusatzaufgabe, sondern eine Schlüsselrolle für die Steuerungsfähigkeit des gesamten Portfolios.

---

Unterstützung für Ihr Projektportfolio

Vielleicht möchten Sie ein Projektportfolio neu aufsetzen und sind unsicher, welche Struktur, Reportinglogik und Governance zu Ihrem Unternehmen passen. Oder es gibt bereits eine Portfoliosteuerung, die jedoch viel Aufwand erzeugt, ohne die gewünschten Entscheidungen und Transparenz zu liefern.

Genau dort lohnt sich ein gemeinsamer Blick auf den aktuellen Steuerungsansatz: Welche Ebene soll gesteuert werden? Welche Informationen werden wirklich benötigt? Wo entstehen unnötige Schleifen? Und was muss angepasst werden, damit aus Reporting und Strukturen tatsächlich bessere Entscheidungen entstehen?

Im 4-Wochen-Intensiv „Projektchaos beenden“ betrachten wir Projektportfolio, Prioritäten, Ressourcen, Entscheidungswege und die bestehende Steuerungslogik gemeinsam und leiten daraus konkrete nächste Schritte ab.