Was ist eine Projektlandschaft? Erklärung, Erstellung und Lenkung

Eine Projektlandschaft ist die Gesamtheit aller laufenden, geplanten und beantragten Projekte, Programme und Portfolios eines Unternehmens, einschließlich ihrer Abhängigkeiten, Ressourcenbindungen und strategischen Zuordnung. Sie beschreibt den Ist-Zustand der gesamten Projekttätigkeit und bildet damit die Grundlage für Priorisierung und Multiprojektsteuerung.

Bei der Projektlandschaft Definition kommt es auf eine saubere Trennung zum Projektportfolio an: Das Portfolio ist eine bewusst zusammengestellte, gesteuerte Auswahl von Projekten, die nach strategischen Kriterien ausgewählt und überwacht wird. Die Projektlandschaft umfasst dagegen sämtliche Vorhaben einer Organisation, auch solche außerhalb formaler Portfolio-Governance. Genau darin liegt ihr Wert: Sie zeigt auch das, was im gesteuerten Portfolio nicht auftaucht, aber dennoch Kapazität bindet.

Die Bedeutung der Projektlandschaft erschließt sich aus einer einfachen Beobachtung: Doppelarbeit, verdeckte Abhängigkeiten und Ressourcenengpässe entstehen typischerweise nicht in einzelnen Projekten, sondern zwischen ihnen. Ohne dokumentierte Gesamtübersicht konkurrieren Vorhaben unkoordiniert um dieselben Personen, Budgets und Kapazitäten. Fehlender Überblick über parallele Projekte zählt zu den häufigsten Ursachen für Termin- und Budgetüberschreitungen im Multiprojektumfeld. Studien zeigen, dass Projektarbeit in 74 Prozent der Unternehmen zum alltäglichen Geschäft gehört, wodurch eine systematische Steuerung maßgeblich über den Gesamterfolg entscheidet und die mit der Menge an Parallelprojekten steigende Komplexität messbar abfedert.

Fachlich gliedert sich das Konzept in fünf Aspekte: die Elemente der Landschaft (Projektarten, Programme, Portfolios, Abhängigkeiten), ihre Analyse und Visualisierung bis hin zur Projektlandkarte, die Bewertung und Priorisierung der Vorhaben, die Ressourcenplanung und Methodensteuerung im Multiprojektmanagement sowie die Rollen und Verantwortlichkeiten. Diese Aspekte greifen ineinander: Ohne einheitliche Klassifizierung gibt es keine belastbare Bewertung, ohne Bewertung kein wirksames Projektportfoliomanagement (PPM) im Sinne der systematischen Auswahl, Priorisierung und Überwachung aller Projekte eines Portfolios. Differenzieren lässt sich eine Landschaft nach Projektart (strategische Projekte, Pflichtprojekte aus Compliance und Regulatorik, Kundenprojekte, interne Optimierungsprojekte), nach Methodik (klassisch, agil, hybrid) und nach Organisationsreife, die von der gewachsenen Excel-Landschaft bis zum governance-gesteuerten Portfolio reicht.

Für PMO-Leitungen und Multiprojektmanager im Mittelstand und Konzernumfeld bedeutet der Aufbau einer Projektlandschaft vier konkrete Arbeitspakete: eine einheitliche Projektdefinition, die vollständige Erfassung aller Vorhaben, gemeinsame Kennzahlen und einen festen Aktualisierungsrhythmus. Damit fällt auch eine verbreitete Fehlannahme: Die Projektlandschaft ist keine einmalig erstellte Übersichtsgrafik und keine Projektliste, die nach der Erstaufnahme abgelegt wird. Sie ist ein fortlaufend gepflegtes Abbild der Projekttätigkeit, dessen Aussagekraft vollständig an der Aktualität und Vollständigkeit der Daten hängt. Der Aufwand dafür lohnt sich, sobald Projekte über Abteilungsgrenzen hinweg um dieselben Ressourcen konkurrieren, und nicht erst ab einer bestimmten Unternehmensgröße. Projekttransparenz ist damit weniger eine Frage der Unternehmensdimension als eine Frage der Disziplin.

Inhaltsverzeichnis

1. Aus welchen Elementen besteht eine Projektlandschaft?
2. Worin unterscheidet sich die Projektlandschaft vom Projektportfolio?
3. Warum brauchen Unternehmen einen Überblick über ihre Projektlandschaft?
4. Was sind häufige Ursachen für eine unübersichtliche Projektlandschaft?
5. Wie analysiert und visualisiert man eine Projektlandschaft?
6. Wie bewertet und priorisiert man Projekte innerhalb der Projektlandschaft?
7. Wie plant und steuert man eine Projektlandschaft im Multiprojektmanagement?
8. Wer ist im Unternehmen für die Projektlandschaft verantwortlich?
9. Wie unterstützt eine Projektmanagement-Software die Projektlandschaft?
10. Welche Fehler sollte man beim Aufbau einer Projektlandschaft vermeiden?
11. Fazit zum Aufbau und Steuerung einer Projektlandschaft
12. Häufig gestellte Fragen zur Projektlandschaft

Aus welchen Elementen besteht eine Projektlandschaft?

Eine Projektlandschaft setzt sich aus mehreren Bausteinen zusammen, die erst im Zusammenspiel ein steuerbares Gesamtbild ergeben: von den einzelnen Vorhaben über ihre Bündelung in Programmen und Portfolios bis zu den Abhängigkeiten und der gemeinsamen Ressourcenbasis. Fehlt eine dieser Elementgruppen, bleibt die Projektübersicht lückenhaft und die daraus abgeleiteten Aussagen sind nicht belastbar.

• Einzelprojekte: Alle abgegrenzten Vorhaben mit eigenem Ziel, Budget und Zeitrahmen, unabhängig davon, ob sie klassisch, agil oder hybrid abgewickelt werden. Sie bilden die kleinste Steuerungseinheit der Landschaft.
• Projektarten und Kategorien: Die Projektart bezeichnet die Zuordnung eines Vorhabens nach seinem Zweck, etwa strategisch, Pflichtprojekt, Kundenprojekt oder internes Optimierungsprojekt. Diese Zuordnung macht Projekte vergleichbar und bildet die Basis jeder Priorisierung.
• Programme: Inhaltlich zusammengehörige Projekte mit gemeinsamem übergeordnetem Ziel, die zentral koordiniert werden. Innerhalb eines Programms werden Ergebnisse zwischen den Teilprojekten abgestimmt.
• Portfolios: Gesteuerte Zusammenstellungen von Projekten und Programmen, die nach strategischen Kriterien ausgewählt, priorisiert und überwacht werden. Ein Unternehmen führt häufig mehrere Portfolios parallel.
• Abhängigkeiten: Inhaltliche, terminliche, ressourcenbezogene und finanzielle Verknüpfungen zwischen Vorhaben. Sie bestimmen den kritischen Pfad der gesamten Landschaft und begrenzen den Spielraum für Terminverschiebungen.
• Ressourcen- und Datenbasis: Gemeinsame Personal-, Budget- und Kapazitätsdaten sowie einheitliche Stammdaten je Projekt, also Projektname, Art, Verantwortlicher, Status, Budget, Zeitraum und Ressourcenbedarf. Ohne sie bleiben die übrigen Elemente unverbunden.

Zur Landschaft gehören außerdem alle Vorhaben, die noch nicht gestartet sind. Projektanträge und Ideen aus dem Demand Management, also der strukturierten Erfassung und Vorbewertung von Projektanträgen, müssen in die Übersicht aufgenommen werden, weil sie künftige Kapazitäten binden und die Umsetzungsgrenze des kommenden Planungszeitraums mitbestimmen. Die häufigste Erfassungslücke sind dagegen kleine Abteilungs- und IT-Projekte, die nie formal beantragt wurden, aber reale Arbeitszeit binden: Umstellungen an Prüfsystemen, kleinere Schnittstellenanpassungen, Nachbesserungen an Konstruktionsdaten. Um die Projektlandschaft sinnvoll zu strukturieren, definieren Sie deshalb eine Erfassungsschwelle, etwa ab einem bestimmten Aufwand in Personentagen oder ab abteilungsübergreifender Beteiligung. So bleibt die Übersicht weder unvollständig noch überdetailliert.

Wie weit diese Schwelle gefasst wird, bleibt eine Abwägung. Eine verbreitete Gegenposition lautet, ein PMO solle sich auf die zwanzig größten Projekte beschränken, statt alles zu erfassen. Dieser Ansatz ist nachvollziehbar, aber unvollständig: Er schützt das PMO vor Überlastung, blendet jedoch genau die Ressourcenkonflikte aus, die durch viele kleine, scheinbar unsichtbare Vorhaben entstehen. Praktikabler ist ein gestufter Ansatz, wie ihn etwa der Pharmadienstleister Losan Pharma nutzt: Projekte werden nach Größe kategorisiert und mit unterschiedlicher Planungstiefe erfasst, statt kleine Vorhaben komplett auszublenden oder alle gleich intensiv zu behandeln.

Welche Projektarten gehören zur Projektlandschaft?

Projektarten sind das zentrale Ordnungskriterium der Projektlandschaft, weil sie festlegen, nach welchen Maßstäben ein Vorhaben bewertet wird. Ein regulatorisches Pflichtprojekt, also ein gesetzlich oder behördlich erzwungenes Muss-Projekt ohne Verhandlungsspielraum, konkurriert nicht nach denselben Kriterien wie ein internes Optimierungsprojekt. Ein strategisches Projekt wiederum setzt einen definierten Bestandteil der Unternehmensstrategie um und rechtfertigt seinen Ressourcenbedarf über den Strategiebeitrag, nicht über kurzfristige Wirtschaftlichkeit. Entscheidend ist nicht die Anzahl der Kategorien, sondern ihre Trennschärfe und die einheitliche Anwendung über alle Bereiche hinweg. Jede Organisation braucht dafür eine verbindliche, dokumentierte Zuordnungsregel.

Ergänzend zur Zweckkategorie wird jedes Vorhaben nach Vorgehensmodell (klassisch, agil, hybrid) und nach Größenklasse anhand von Budget oder Personentagen klassifiziert. Wie stark ein solches Klassifizierungsschema die Landschaft prägt, zeigt sich in Pharma und Maschinenbau besonders deutlich: Regulatorische Pflichtprojekte, etwa zur Validierung computergestützter Systeme, werden dort häufig streng nach dem risikobasierten GAMP-5-V-Modell abgewickelt. Sie folgen einer festgelegten Sequenz aus Spezifikation und Test und binden hochspezialisierte Ressourcen bereits früh im Projektverlauf. In der Landschaftssicht müssen solche Vorhaben als eigene Größenklasse mit festen, planbaren Kapazitätsbedarfen abgebildet werden, weil sie große Anteile der verfügbaren Fachkapazität dauerhaft reservieren.

Wie unterschiedlich Projektlandschaften dadurch ausfallen, zeigt der Blick in dokumentierte Kundenfälle: Im Anlagenbau führt Uhde High Pressure Technologies rund 170 Projekte mit ein bis zwei Jahren Laufzeit parallel. In der Elektronik verwaltet KETEK etwa 30 größere Entwicklungsprojekte und zusätzlich über 130 Kleinprojekte. Im Pharmaumfeld sind es bei Dr. Willmar Schwabe rund 300 Projekte mit im Schnitt zwölf Monaten Laufzeit. Die Struktur der Landschaft folgt damit weniger der Unternehmensgröße als dem Zuschnitt der Projektarten: wenige lange Anlagenprojekte, ein breites Feld kleiner Entwicklungsvorhaben oder ein hoher Durchsatz mittlerer Laufzeiten. Genau diese Zusammensetzung bestimmt, wie tief eine Landschaft sinnvoll erfasst wird.

Welche Rolle spielen Programme und Portfolios in der Projektlandschaft?

Programme und Portfolios sind die beiden Bündelungsebenen oberhalb des Einzelprojekts, und sie unterscheiden sich in ihrer Bündelungslogik. Das Programm-Management koordiniert inhaltlich zusammengehörige Projekte auf ein gemeinsames übergeordnetes Ziel und verantwortet dabei die Ergebnisabstimmung zwischen den Teilprojekten. Ein Projektportfolio bündelt dagegen nach strategischem Beitrag und Ressourcenkonkurrenz, unabhängig davon, ob die enthaltenen Vorhaben inhaltlich etwas miteinander zu tun haben. Kurz gefasst: Das Programm bündelt inhaltlich, das Portfolio bündelt strategisch, und die Projektlandschaft umfasst beides.

Diese Unterscheidung entspricht der Systematik internationaler Standards. Das Project Management Institute ordnet dem Portfoliomanagement die Übersetzung von Unternehmens- und Wettbewerbsstrategie in konkrete Werte zu, während das Programmmanagement den Fokus auf die effiziente Ressourcenverteilung und die Nutzung von Synergien über inhaltlich verwandte Komponenten legt. Programme schaffen Wert durch Koordination, Portfolios steuern über strategische Auswahl. Daraus folgt auch der zeitliche Unterschied: Ein Programm hat ein definiertes Ende, sobald das übergeordnete Ziel erreicht ist. Ein Portfolio ist dauerhaft angelegt und wird zyklisch neu zusammengestellt.

Eine Projektlandschaft kann mehrere Portfolios enthalten, etwa ein IT-Portfolio, ein Produktentwicklungs-Portfolio und ein Investitions-Portfolio. Die Landschaft ist die übergeordnete Gesamtsicht über alle Portfolios, alle Programme und zusätzlich über die Projekte, die keinem Portfolio zugeordnet sind. Beide Bündelungsebenen erzeugen jeweils eigene Steuerungsaufgaben: im Programm die inhaltliche Ergebniskoordination, im Rahmen des Projektportfoliomanagements die Auswahl- und Priorisierungsentscheidung.

Welche Abhängigkeiten bestehen zwischen den Projekten?

Abhängigkeiten sind der Grund, warum Projekte nicht isoliert planbar sind. Eine Verzögerung in einem Vorhaben verschiebt Termine, Kapazitäten und Budgets in anderen Projekten, oft mit mehreren Wochen Verzug bis zur Sichtbarkeit. In der Praxis sind vier Abhängigkeitstypen relevant:

• Ressourcenabhängigkeiten: Zwei oder mehr Projekte greifen auf dieselben Personen oder Qualifikationen zu, sodass die Verfügbarkeit zur begrenzenden Größe wird. Beispiel: Derselbe Validierungsexperte ist für drei parallele Qualifizierungsprojekte eingeplant.
• Terminlich-logische Abhängigkeiten: Das Ergebnis eines Projekts ist Voraussetzung für den Start oder eine Phase eines anderen. Beispiel: Die Freigabe der neuen Steuerungssoftware muss vorliegen, bevor die Serienanlage in die Abnahme geht.
• Inhaltlich-technische Abhängigkeiten: Mehrere Projekte nutzen gemeinsame Systeme, Schnittstellen oder Plattformen und müssen ihre Änderungen abstimmen. Beispiel: Zwei Vorhaben ändern parallel dieselbe ERP-Schnittstelle zur Produktionsplanung.
• Finanzielle Abhängigkeiten: Vorhaben werden aus einem gemeinsamen Budgettopf oder Investitionsrahmen finanziert, sodass Mehrkosten in einem Projekt andere verdrängen. Beispiel: Ein überzogenes Werkzeugbudget blockiert die geplante Prüfstandserweiterung.

Ressourcenabhängigkeiten sind dabei die häufigste und zugleich am schlechtesten dokumentierte Form, weil sie in Einzelprojektplänen grundsätzlich nicht sichtbar werden: Jeder Plan geht für sich genommen davon aus, dass die jeweils eingeplanten Personen uneingeschränkt zur Verfügung stehen. Für Multiprojektmanager und PMO-Leitungen empfiehlt sich deshalb ein einfaches Abhängigkeitsregister, in dem jede Verknüpfung mit Typ, betroffenen Projekten, einem namentlichen Verantwortlichen und einem Überprüfungsrhythmus geführt wird. Nicht dokumentierte Abhängigkeiten fallen erst auf, wenn der Terminverzug bereits eingetreten ist, und dann liegt der kritische Pfad, also die Kette von Vorgängen, deren Verzögerung den Endtermin unmittelbar verschiebt, bereits außerhalb des Handlungsspielraums.

Worin unterscheidet sich die Projektlandschaft vom Projektportfolio?

Projektlandschaft und Projektportfolio lassen sich am klarsten entlang ihres Steuerungsanspruchs einordnen: Die Landschaft beschreibt den vollständigen Ist-Zustand aller Vorhaben, das Portfolio ist die bewusst ausgewählte und priorisierte Teilmenge davon.

Die beiden Sichten stehen nicht in Konkurrenz, sondern in einer Reihenfolge. Für Organisationen ohne etablierte Governance, also ohne verbindliche Regeln, Gremien und Entscheidungswege, ist der Aufbau der Projektlandschaft der erste Schritt, weil sie die Datengrundlage liefert. Wo bereits ein Projektportfoliomanagement (PPM) etabliert ist, wirkt die Gesamtlandschaft als Korrektiv: Sie deckt auf, wie viel Kapazität außerhalb des gesteuerten Portfolios gebunden ist. In der Praxis enthält jede Landschaft regelmäßig Vorhaben außerhalb jedes Portfolios, etwa Abteilungsinitiativen, kleine IT-Vorhaben oder Schatten-Projekte, also Vorhaben, die ohne formale Freigabe und ohne Budgetzuordnung laufen und dennoch Arbeitszeit binden. Genau diese gehen in Portfolioentscheidungen nicht ein, verzerren aber jede Kapazitätsaussage. Keine der beiden Sichten ersetzt die andere.

Warum brauchen Unternehmen einen Überblick über ihre Projektlandschaft?

Der Nutzen einer transparenten Projektlandschaft zeigt sich nicht im einzelnen Projekt, sondern genau an den Stellen, an denen Projekte um dieselben Ressourcen, Termine und Budgets konkurrieren: bei der Ressourcenverteilung, der Terminabstimmung und der Investitionsentscheidung. Projekttransparenz bedeutet in diesem Zusammenhang, dass Status, Aufwand, Termine und Ressourcenbindung aller Vorhaben nach einheitlichen Regeln erfasst und zu jedem Zeitpunkt auswertbar sind.

• Ressourcen realistisch verteilen: Erst die Summenbetrachtung über alle Projekte zeigt, welche Rollen tatsächlich überbucht sind. Statt Zusagen nach Verhandlungsgeschick werden Kapazitäten gegen den dokumentierten Gesamtbedarf zugeteilt.
• Prioritäten belastbar begründen: Eine Rangfolge, die auf vergleichbaren Daten aller Vorhaben basiert, hält Rückfragen aus den Fachbereichen stand. Diskussionen verschieben sich von der Frage „wer hat mehr Einfluss“ zur Frage „welcher Nutzen wiegt schwerer“.
• Abhängigkeiten und Risiken früher erkennen: Verknüpfungen zwischen Projekten und kumulierte Risiken werden vor dem Terminverzug sichtbar. Frühwarnindikatoren aus der Gesamtsicht verschaffen Vorlaufzeit für Gegenmaßnahmen.
• Doppelarbeit und Redundanzen aufdecken: Parallel laufende Vorhaben mit überlappendem Inhalt fallen bei einheitlicher Erfassung sofort auf. Zwei Bereiche, die unabhängig voneinander dieselbe Schnittstelle neu bauen, lassen sich zusammenführen, bevor Budget doppelt gebunden ist.
• Strategische Ausrichtung überprüfen: Der Anteil strategischer Projekte am Gesamtaufwand wird messbar. Häufig zeigt sich dabei, dass ein Großteil der Kapazität in Pflicht- und Tagesgeschäftsprojekte fließt, während strategische Vorhaben unterversorgt bleiben.
• Entscheidungen gegenüber der Geschäftsführung nachvollziehbar machen: Projektstarts, Verschiebungen und Stopps lassen sich mit Daten statt mit Einschätzungen begründen. Das verkürzt Abstimmungsschleifen in Aufsichts- und Lenkungsgremien erheblich.

Ohne Gesamtübersicht werden Entscheidungen über Projektstarts auf Basis von Einzelfallbetrachtungen getroffen, und das führt systematisch zur Überlastung des Portfolios, also zu einem Bestand an Vorhaben, dessen Kapazitätsbedarf die verfügbare Kapazität dauerhaft übersteigt. Jede Einzelentscheidung wirkt isoliert betrachtet plausibel. Die typische Ausgangslage in Unternehmen mit gewachsener Projektlandschaft ist entsprechend vertraut: parallel geführte Excel-Listen in den Fachbereichen, voneinander abweichende Statusdefinitionen und ein monatlicher Reporting-Aufwand, der überwiegend aus manueller Zusammenführung besteht. Für PMO-Leitungen, Multiprojektmanager und die kaufmännische Geschäftsführung steigt der Nutzen einer belastbaren Gesamtsicht überproportional mit der Anzahl paralleler Projekte und der Anzahl beteiligter Abteilungen. Der Überblick ist zudem die Voraussetzung dafür, Projekte aktiv zu stoppen oder zu verschieben: In Organisationen ohne Landschaftssicht werden Projekte fast ausschließlich gestartet und selten beendet. Entscheidend ist dabei die Qualität der Grundlage, denn Transparenz entsteht im Multiprojektmanagement nur bei einheitlichen Statusdefinitionen und einem festen Aktualisierungsrhythmus, nicht durch die Erfassung allein.

Was sind häufige Ursachen für eine unübersichtliche Projektlandschaft?

Eine unübersichtliche Projektlandschaft entsteht in der Regel nicht durch mangelnde Dokumentation, sondern durch fehlende Entscheidungsregeln: Die Projektliste ist unvollständig, weil niemand verbindlich festlegt, was als Projekt gilt und wer es freigibt. Die Ursachen lassen sich auf drei wiederkehrende Muster zurückführen, die selten allein auftreten und sich gegenseitig verstärken.

1. Fehlende Priorisierungskriterien: Ohne verbindliche Bewertungsmaßstäbe entscheidet Durchsetzungsstärke statt Nutzen darüber, welche Projekte starten. Die Folge sind zu viele parallele Vorhaben ohne erkennbare Rangordnung.
2. Ressourcenengpässe: Wenn Projekte auf dieselben Schlüsselpersonen zugreifen, ohne dass Kapazitäten abgeglichen werden, entstehen verdeckte Wartezeiten und Terminverschiebungen über die gesamte Landschaft hinweg.
3. Dezentrale Projektsteuerung: Wenn Fachbereiche eigene Vorlagen, Statusdefinitionen und Werkzeuge nutzen, sind Projekte nicht mehr vergleichbar. Die Gesamtsicht muss dann manuell und fehleranfällig zusammengeführt werden.

Der Verstärkungsmechanismus ist dabei immer derselbe: Ohne Priorisierungskriterien werden zu viele Projekte gestartet, die entstehenden Engpässe führen zu Verzögerungen, und die Fachbereiche weichen auf eigene, dezentrale Steuerungswege aus, um wenigstens ihre eigenen Vorhaben planbar zu halten.

1. Fehlende Priorisierungskriterien

Die Symptome sind gut erkennbar: mehrere Projekte tragen gleichzeitig Priorität 1, es existiert keine dokumentierte Ablehnungshistorie, und Projektstopps sind im Prozess faktisch nicht vorgesehen. Wo Vorhaben ohne einheitliche Bewertungsmaßstäbe freigegeben werden, entscheidet die Position des Antragstellers über den Projektstart, nicht der erwartete Nutzen. Auf Landschaftsebene führt das zur Verzettelung: Zu viele parallele Vorhaben verlängern die Durchlaufzeit aller Projekte, weil dieselben Personen laufend zwischen Aufgaben wechseln. Dieser Multitasking-Verlust, also der Produktivitätsverlust durch häufige Wechsel zwischen parallelen Aufgaben, wird in Einzelprojektplänen nie ausgewiesen und trifft die Landschaft dennoch in vollem Umfang.

Ein tragfähiges Kriteriensystem umfasst mindestens strategischen Beitrag, Wirtschaftlichkeit, Dringlichkeit, Risiko und Ressourcenverfügbarkeit, jeweils gewichtet und für alle Projektarten einheitlich angewendet. In der Praxis bewährt es sich, dabei sauber zwischen der Auswahl der Kriterien, ihrer Gewichtung und der eigentlichen Bewertung zu trennen. Für operative Entscheidungen im Team genügen üblicherweise fünf bis acht Kriterien. Nur bei hochkomplexen, stark regulierten Entscheidungen mit weitreichenden Investitionsfolgen lohnt der Aufwand eines mathematisch konsistenteren Verfahrens wie des Analytic Hierarchy Process, der kognitive Verzerrungen bei der Gewichtung systematisch reduziert.

2. Ressourcenengpässe

Ressourcenengpässe entstehen fast immer an wenigen Schlüsselrollen und nicht in der Breite der Belegschaft. Eine Schlüssel- oder Engpassressource ist eine Rolle, deren Qualifikation kurzfristig nicht ersetzbar ist und deren Verfügbarkeit damit den Fortschritt mehrerer Projekte gleichzeitig begrenzt: der Validierungsexperte für regulatorische Prüfungen in der Pharmaproduktion, der Softwarearchitekt für die Steuerungstechnik im Sondermaschinenbau, der Layouter für Hochfrequenzbaugruppen in der Elektronik. Auf Einzelprojektebene bleiben solche Engpässe unsichtbar, weil jeder Projektplan die benötigte Person als verfügbar annimmt. Erst der Kapazitätsabgleich, also die Gegenüberstellung von summiertem Bedarf aller Projekte und tatsächlich verfügbarer Kapazität je Rolle und Zeitraum, macht die Überbuchung sichtbar.

Der zweite Engpasstreiber ist die fehlende Berücksichtigung von Linientätigkeit und Tagesgeschäft. Wird die verfügbare Projektkapazität nicht um Regelaufgaben, Urlaub, Krankheit und Weiterbildung bereinigt, ist jede Planung systematisch zu optimistisch. Ein dauerhaft geplanter Auslastungsgrad von 100 Prozent gilt als kritischer Planungsfehler, weil jeglicher Puffer für Ausfälle fehlt und das Projektnetzwerk bei der ersten unvorhergesehenen Verschiebung sofort in eine Unterdeckung kippt. Als Erfahrungswert aus der Praxis, nicht als Norm: Schon 95 Prozent Planauslastung gelten als hocheffizient und lassen kaum Spielraum. Aussagekräftiger als ein pauschaler Monatsdurchschnitt ist ohnehin eine differenzierte Auswertung nach Standort und Qualifikation, weil sich Engpässe genau dort verstecken.

3. Dezentrale Projektsteuerung

Dezentrale Projektsteuerung bedeutet, dass jeder Fachbereich nach eigenen Regeln plant, dokumentiert und berichtet: mit eigenen Vorlagen, eigenen Statusdefinitionen und eigenen Werkzeugen. Solche Insellösungen, also isolierte Werkzeug- und Datenbestände ohne Verbindung zu einer gemeinsamen Datenbasis, führen nicht zu fehlender Information, sondern zu fehlender Vergleichbarkeit. Ein „gelber“ Projektstatus bedeutet in zwei Bereichen Unterschiedliches, Aufwände werden in Stunden, Personentagen oder Prozentangaben geführt, und Fortschrittsangaben beruhen auf abweichenden Bezugsgrößen. Der Zusammenführungsaufwand verschiebt sich damit auf das PMO oder die Geschäftsführung und wird dort manuell geleistet, mit Zeitverzug und entsprechendem Fehlerrisiko.

Dezentralität ist dabei nicht per se falsch. Operative Projektarbeit gehört in die Fachbereiche, weil dort das inhaltliche Wissen liegt und Entscheidungen schneller fallen. Zentral gehören dagegen die Definitionen: Projektbegriff, Statuslogik, Stammdatenfelder und Berichtszyklus. Genau diese Datenkonsistenz ist die Voraussetzung dafür, eine Projektlandschaft überhaupt auswerten und in einer belastbaren Gesamtsicht darstellen zu können.

Wie analysiert und visualisiert man eine Projektlandschaft?

Wer eine Projektlandschaft analysieren will, folgt einer festen Reihenfolge: von der vollständigen Erfassung über die Vereinheitlichung der Daten bis zur adressatengerechten Darstellung. Jede Visualisierung ist dabei nur so belastbar wie die zugrunde liegende Datenbasis.

1. Vorhaben vollständig erfassen: Alle laufenden, geplanten und beantragten Projekte werden aufgenommen, inklusive Anträge aus dem Demand Management und laufender Kleinprojekte. Ergebnis ist eine erste vollständige Projektübersicht, die auch die bisher nicht dokumentierten Vorhaben enthält.
2. Stammdaten vereinheitlichen: Pflichtfelder, Statuslogik und Aufwandseinheiten werden verbindlich festgelegt und auf alle Einträge angewendet. Danach sind Projekte über Bereichsgrenzen hinweg vergleichbar.
3. Projekte klassifizieren: Jedes Vorhaben erhält eine Projektart, ein Vorgehensmodell und eine Größenklasse. Damit lassen sich Teilmengen der Landschaft gezielt auswerten, etwa alle regulatorischen Projekte eines Standorts.
4. Kennzahlen erheben: Status, Fortschritt, Termin- und Kostenabweichung sowie Ressourcenbedarf werden nach definierten Regeln ermittelt. Ergebnis ist eine quantitative Beschreibung der Gesamtlandschaft statt einer Sammlung von Einschätzungen.
5. Abhängigkeiten und Kapazitäten auswerten: Verknüpfungen zwischen Projekten und kritische Rollen werden identifiziert und in die Zukunft gerechnet. Diese Auswertung ist die Grundlage für eine vorausschauende Kapazitätsplanung im Multiprojektmanagement, mit der Engpässe vor ihrem Eintritt sichtbar werden.
6. Ergebnisse visualisieren und im Zyklus aktualisieren: Für jeden Adressaten werden Format, Detailtiefe und Rhythmus festgelegt. Wer die Projektlandschaft visualisieren will, arbeitet dabei mit der Projektlandkarte, also der grafischen Gesamtdarstellung aller Projekte nach ausgewählten Kriterien.

Als Praxis-Richtwert und nicht als Norm haben sich folgende Rhythmen bewährt: Statusmeldungen wöchentlich bis monatlich, die vollständige Portfoliobewertung quartalsweise. Entscheidend ist weniger die exakte Frequenz als ihre Verbindlichkeit, denn eine Projektlandkarte auf Basis unvollständiger oder veralteter Statusmeldungen erzeugt Scheinsicherheit und untergräbt das Vertrauen in alle weiteren Auswertungen. Die Darstellungsform selbst richtet sich nach dem Adressaten: Die Geschäftsführung braucht verdichtete Portfolio- und Statusansichten, Projektleitung und Ressourcenverantwortliche brauchen Termin- und Auslastungssichten. Rechnen Sie damit, dass die Erstaufnahme einmalig aufwendig ist, während der laufende Betrieb überwiegend Pflegeaufwand bedeutet. Der Nutzen entsteht ausschließlich durch die kontinuierliche Fortschreibung, denn Datenqualität und Aktualisierungszyklus bestimmen gemeinsam, ob aus der Analyse Steuerung wird.

Welche Kennzahlen machen die Projektlandschaft messbar?

Kennzahlen auf Landschaftsebene messen nicht den Erfolg einzelner Projekte, sondern die Verfassung des Gesamtsystems: Auslastung, Balance, Termintreue und Wertbeitrag über alle Vorhaben hinweg. Vier Kennzahlengruppen haben sich dafür etabliert.

Die genannten Größen brauchen jeweils eine eindeutige Rechenregel: Termintreue als Anteil der zum geplanten Termin abgeschlossenen Meilensteine oder Projekte, Kostenabweichung als Differenz zwischen Ist- und Plankosten bezogen auf den Planwert, Auslastungsgrad als Verhältnis von gebundenem Kapazitätsbedarf zur verfügbaren Nettokapazität einer Rolle, Portfolio-Balance als Verteilung des Gesamtaufwands über Projektarten und strategische Ziele. Wie weit sich die Leistung einer Projektlandschaft aggregieren lässt, zeigen die Benchmarking-Studien der TU Darmstadt zum Multiprojektmanagement: Ihr Multiprojektmanagement Performance Index bewertet neben dem Einzelprojekterfolg auch Zusammenarbeits-, Informations-, Entscheidungs- und Allokationsqualität sowie erzielte Synergien und die Portfoliobalance. Für die Praxis gilt trotzdem: Eine kleine, konsistent erhobene Auswahl ist aussagekräftiger als ein umfangreiches Set mit lückenhafter Datenbasis. Begrenzen Sie das Steuerungs-Set auf wenige führende Kennzahlen, und weisen Sie jeder Kennzahl eine Erhebungsregel und einen Adressaten zu. Kennzahlen ohne Entscheidungsbezug erzeugen ausschließlich Erfassungsaufwand.

Welche Darstellungsformen eignen sich für die Projektlandkarte?

Die Projektlandkarte ist keine feste Grafikform, sondern ein Sammelbegriff für mehrere Darstellungen, die jeweils eine andere Steuerungsfrage beantworten. Fünf Formen haben sich in der Praxis etabliert:

• Portfolio-Matrix als Blasendiagramm: Positioniert jedes Projekt nach Nutzen und Aufwand beziehungsweise Risiko, wobei die Blasengröße das Budget abbildet. Geeignet für Portfolio-Entscheidungen in Lenkungsgremien.
• Multiprojekt-Roadmap: Stellt alle Vorhaben als Zeitstrahl mit Meilensteinen und Releases nebeneinander dar und macht terminliche Überlappungen sichtbar. Geeignet für die Terminabstimmung zwischen Projektleitungen und Fachbereichen.
• Status-Dashboard mit Ampelbewertung: Verdichtet Status, Fortschritt sowie Termin- und Kostenabweichung aller Projekte auf eine Seite. Geeignet als Sitzungsgrundlage für das Portfolio-Board und die Geschäftsführung.
• Ressourcen-Histogramm: Balkendarstellung von Kapazitätsbedarf gegen verfügbare Kapazität je Zeitraum und Rolle. Geeignet für Ressourcen- und Linienverantwortliche bei der Kapazitätsfreigabe.
• Netzdarstellung der Abhängigkeiten: Zeigt Verknüpfungen zwischen Projekten als Graph und macht Knotenpunkte mit hoher Verflechtung erkennbar. Geeignet für PMO und Multiprojektmanager bei der Risikobeurteilung.

Gerade die Netzdarstellung ergänzt klassische Dashboards wirkungsvoll. Als Abhängigkeitsmatrix aufgebaut, macht sie zwei Risikotypen unterscheidbar: Projekte mit vielen vorgelagerten Abhängigkeiten tragen ein deutlich höheres Terminrisiko, weil sie auf Ergebnisse anderer warten. Vorhaben mit starken nachgelagerten Effekten, auf deren Ergebnis also andere Projekte warten, benötigen häufig eine bevorzugte Ressourcenfreigabe, um den kritischen Pfad der gesamten Projektlandschaft nicht zu blockieren.

Wiederkehrende Darstellungsfehler lassen sich leicht vermeiden. Zu viele Dimensionen in einer Grafik machen die Aussage unlesbar, uneinheitliche Farbcodierung zwischen Berichten führt zu Fehlinterpretationen, und ein fehlender Stichtag an der Darstellung macht jede Diskussion über Aktualität unnötig langwierig. Die Wahl der Darstellung folgt dem Adressaten und dem Entscheidungszweck, nicht der grafischen Attraktivität.

Wie bewertet und priorisiert man Projekte innerhalb der Projektlandschaft?

Bewertung und Priorisierung sind zwei getrennte Schritte: Die Bewertung misst den Wertbeitrag jedes Projekts an definierten Kriterien, die Projektpriorisierung bringt die Ergebnisse unter Berücksichtigung der verfügbaren Kapazität in eine verbindliche Reihenfolge.

1. Pflichtprojekte aussteuern und Kapazität reservieren: Regulatorische, gesetzliche und vertraglich zugesagte Vorhaben werden vor der Bewertung herausgenommen und ihre Kapazität wird reserviert. Sie binden Ressourcen, konkurrieren aber nicht um Priorität.
2. Bewertungskriterien definieren und gewichten: Das Gremium legt die Kriterien und deren Gewichtung fest, bevor konkrete Projekte betrachtet werden. Als Orientierung genügen fünf bis acht gewichtete Kriterien.
3. Projekte einheitlich bewerten: Jedes Vorhaben wird im Scoring-Modell bewertet, also nach gewichteten Kriterien beurteilt und zu einer Punktsumme verdichtet. Die Bewertungsskala ist für alle Kriterien identisch, üblich sind 1 bis 5 oder 1 bis 10 als Praxis-Richtwerte.
4. Rangfolge mit verfügbarer Kapazität abgleichen: Die Punktsummen ergeben eine Rangliste, die gegen die verfügbare Nettokapazität je Schlüsselrolle gerechnet wird. So wird die Kapazitätsgrenze bestimmt, also der Punkt in der Rangfolge, ab dem kein weiteres Projekt ohne Überbuchung startbar ist.
5. Entscheidung im Gremium treffen und dokumentieren: Für jedes Vorhaben wird festgelegt, ob es startet, verschoben oder gestoppt wird, und diese Entscheidung wird begründet festgehalten. Die dokumentierte Ablehnungshistorie ist später die Grundlage für Nachvollziehbarkeit.

Methodisch entspricht dieses Vorgehen einer Nutzwertanalyse, bei der qualitative und quantitative Kriterien über eine einheitliche Skala vergleichbar gemacht und gewichtet zusammengeführt werden. Welche Kriterien welches Gewicht erhalten, ist eine Entscheidung der jeweiligen Organisation und lässt sich nicht allgemeingültig vorgeben. Die folgende Tabelle zeigt deshalb vor allem, welche Kriterien üblicherweise herangezogen werden und was sie messen. Die dritte Spalte enthält lediglich eine einzelne Beispielverteilung zur Veranschaulichung des Prinzips: Sie ist kein Standard und kein Benchmark, sondern muss vor der ersten Bewertungsrunde im eigenen Haus diskutiert, festgelegt und validiert werden.

Praktisch heißt das: In einem stark regulierten Umfeld wiegt die Umsetzbarkeit deutlich schwerer, in einer Wachstumsphase verschiebt sich das Gewicht zum strategischen Beitrag, und bei knappen Schlüsselrollen rückt die Ressourcenverfügbarkeit nach vorn. Halten Sie die gewählte Gewichtung schriftlich fest und überprüfen Sie sie mit jedem Strategiezyklus.

Der häufigste Fehler in diesem Prozess ist eine Priorisierung ohne die Bereitschaft, Projekte tatsächlich zu stoppen oder zu verschieben. Die Rangliste bleibt dann folgenlos, und die Kapazitätsgrenze wird stillschweigend überschritten. Wie stark dieser Punkt wiegt, zeigen die Untersuchungen zum Multiprojektmanagement der TU Darmstadt: Sie führen die Abbruchqualität, also die Fähigkeit und Entschlossenheit einer Organisation, laufende Vorhaben aktiv und sachlich begründet zu beenden, als zentrales Leistungsmerkmal erfolgreichen Portfoliomanagements. Fehlt diese Konsequenz, akkumulieren sich Projekte und die Landschaft überlastet schleichend. Agile Vorhaben gehen in die Bewertung über ihren Wertbeitrag und die gebundene Teamkapazität ein, nicht über detaillierte Aufwandsschätzungen einzelner Vorgänge. Die Zuständigkeit ist dabei klar zu trennen: Die Entscheidung trifft ein besetztes Portfolio-Board mit Budgetverantwortung, die Vorbereitung und Datenaufbereitung leistet das PMO. Wiederholen Sie die Bewertung in festen Zyklen, üblicherweise quartalsweise, weil sich strategische Ziele und Rahmenbedingungen ändern.

Wie plant und steuert man eine Projektlandschaft im Multiprojektmanagement?

Wer eine Projektlandschaft steuern will, arbeitet im Multiprojektmanagement, also der laufenden Steuerung aller Projekte einer Landschaft über einen gemeinsamen Planungs-, Rückmelde- und Entscheidungszyklus. Dieser Steuerungszyklus ersetzt die Einzelprojektsteuerung nicht, sondern setzt darauf auf. Und er kennt genau drei Stellhebel: Reihenfolge der Projekte, Ressourcenzuordnung sowie Umfang beziehungsweise Termin einzelner Vorhaben. Mehr steht auf Landschaftsebene nicht zur Verfügung.

1. Planen: Termin-, Kapazitäts- und Budgetplanung erfolgen über alle Projekte hinweg auf Basis der priorisierten Reihenfolge. Ergebnis ist ein abgestimmter Gesamtplan, in dem die Ressourcenplanung je Rolle und Zeitraum gegen die verfügbare Kapazität gerechnet ist.
2. Rückmelden: Ist-Aufwände, Fortschritt und Statusänderungen werden in einheitlicher Form und festem Rhythmus erfasst. Diese Ist-Rückmeldung, also die Erfassung tatsächlich geleisteter Aufwände und erreichter Fortschritte, liefert die Datenbasis für jede weitere Auswertung.
3. Auswerten: Plan und Ist werden über Termine, Kosten und Kapazitäten abgeglichen. Ergebnis ist eine Liste konkreter Abweichungen und Engpässe mit Angabe der betroffenen Projekte und Rollen.
4. Entscheiden: Reihenfolge, Ressourcenzuordnung oder Projektumfang werden angepasst. Jede Anpassung wird dokumentiert und an die betroffenen Projektleitungen und Fachbereiche kommuniziert.

Als Praxis-Richtwerte für die Rhythmen haben sich eine wöchentliche oder zweiwöchentliche operative Steuerung, ein monatliches Multiprojekt-Reporting und eine quartalsweise Portfolio-Entscheidung bewährt. Der Steuerungsrhythmus muss zur Änderungsdynamik passen: Wo Projektlaufzeiten kurz sind und Anforderungen häufig wechseln, verkürzen sich die operativen Zyklen entsprechend. Der kritische Erfolgsfaktor ist die Rückmeldedisziplin, denn ohne verlässliche Ist-Daten wird jede Auswertung zur Schätzung und jedes Frühwarnsystem zur Vermutung. Zugleich gilt: Steuerung auf Landschaftsebene arbeitet mit verdichteten Daten. Die Detailtiefe der Einzelprojektplanung ist hier weder nötig noch handhabbar, weil sie den Pflegeaufwand vervielfacht, ohne die Entscheidungsqualität zu verbessern.

Wie werden Ressourcen über alle Projekte hinweg geplant?

Ressourcenplanung auf Landschaftsebene arbeitet zweistufig. Die Grobplanung ordnet Kapazitätsbedarfe auf Skill- beziehungsweise Rollenebene für die mittelfristige Sicht zu, typischerweise über sechs bis achtzehn Monate. Die Feinplanung ordnet konkrete Personen für den kurzfristigen Horizont zu, üblicherweise für die nächsten Wochen bis wenigen Monate. Diese Skill-basierte Planung, also die Zuordnung nach Qualifikation statt nach namentlicher Person, hält die mittelfristige Planung handhabbar und vermeidet Scheingenauigkeit.

Die Grundgleichung ist einfach: Kapazitätsbedarf aller Projekte gegen verfügbare Kapazität je Rolle und Zeitraum. Entscheidend ist die rechte Seite dieser Gleichung. Die Nettokapazität, also die tatsächlich für Projektarbeit verfügbare Zeit, ergibt sich erst nach Abzug von Linientätigkeit, Abwesenheiten, Rüst- und Umschaltzeiten von der Bruttoarbeitszeit. Für Ressourcen- und Linienverantwortliche, die Kapazitäten für Projekte freigeben müssen, ist genau dieser Abzug der wichtigste Hebel für realistische Zusagen. Zeigt der Abgleich eine Überdeckung, stehen vier Ausgleichsmechanismen zur Verfügung:

• Zeitliche Verschiebung von Vorgängen: Verlagert Bedarf in Perioden mit freier Kapazität, setzt aber Pufferzeiten im Terminplan und die Zustimmung des Auftraggebers voraus.
• Umverteilung auf andere qualifizierte Personen: Entlastet die Engpassressource unmittelbar, erfordert jedoch einen ausreichend breiten Ressourcenpool mit vergleichbarer Qualifikation.
• Reduzierung des Projektumfangs: Senkt den Bedarf direkt und schnell, geht aber zulasten des Ergebnisumfangs und braucht eine dokumentierte Änderungsentscheidung.
• Kapazitätsaufbau durch Einstellung oder externe Unterstützung: Erhöht die verfügbare Kapazität dauerhaft oder temporär, wirkt jedoch mit Vorlauf und erhöht Einarbeitungs- und Koordinationsaufwand.

Der häufigste Planungsfehler bleibt die Vollauslastung. Wird jede Person zu 100 Prozent verplant, führt jede kleinste Abweichung zu Verzug in mehreren Projekten gleichzeitig. Planen Sie deshalb mit Puffer und setzen Sie die Planauslastung als Erfahrungswert bei etwa 80 Prozent der Nettokapazität an, in Bereichen mit hohem Störanteil auch darunter. Wo dieser Abgleich für mehrere Standorte, Rollen und Qualifikationen laufend gerechnet werden muss, stößt eine Tabellenkalkulation schnell an ihre Grenzen, und eine professionelle Software zur Ressourcenplanung übernimmt die Summenbildung über alle Projekte hinweg.

Engpässe werden früh sichtbar, wenn Kapazitätsbedarf und verfügbare Kapazität rollierend in die Zukunft gerechnet werden, und nicht erst, wenn Termine bereits gerissen sind. Vier Frühwarnindikatoren, also messbare Signale, die eine Engpasssituation vor ihrem Eintritt anzeigen, sind auf Landschaftsebene aussagekräftig:

• Geplante Auslastung über der Kapazitätslinie: Der summierte Bedarf einer Rolle übersteigt in einer künftigen Periode die Auslastungslinie und zeigt damit eine strukturelle Überbuchung an.
• Wachsende Anzahl paralleler Zuordnungen je Person: Steigt die Zahl gleichzeitiger Projektzuordnungen, deutet das auf Zersplitterung der Arbeitszeit und wachsende Multitasking-Verluste hin.
• Wiederholte Verschiebung derselben Vorgänge: Werden dieselben Arbeitspakete mehrfach in Folge verschoben, fehlt dort dauerhaft Kapazität und nicht nur punktuell.
• Steigende Differenz zwischen geplantem und gemeldetem Fortschritt: Eine wachsende Lücke signalisiert, dass zugesagte Kapazität faktisch nicht geleistet wird.

Szenarienrechnungen machen Engpässe vor der Entscheidung sichtbar statt danach. Eine Szenarioanalyse, also die rechnerische Durchspielung alternativer Annahmen zu Terminen, Umfängen oder Zuordnungen, beantwortet Fragen wie „Was passiert mit der Auslastung der Konstruktion, wenn Projekt X vier Wochen früher startet?“. Der Handlungsspielraum hängt dabei unmittelbar an der Vorlaufzeit: Bei mehreren Monaten Vorlauf sind Umpriorisierung, Umverteilung und Qualifizierung möglich. Bei wenigen Wochen bleiben faktisch nur Verschiebung oder Umfangsreduktion.

Wie lassen sich klassische, agile und hybride Projekte gemeinsam steuern?

In den meisten Projektlandschaften existieren klassische und agile Vorhaben parallel, etwa wenn agile IT- und Produktentwicklungsteams neben klassisch geplanten Investitions- und Compliance-Projekten arbeiten. Die gemeinsame Steuerung gelingt nicht durch Vereinheitlichung der Methodik, sondern durch eine gemeinsame Übersetzungsebene auf Portfolio- und Ressourcenniveau. Drei Verbindungspunkte tragen diese Übersetzung:

• Gemeinsamer Ressourcenpool: Agile Teams werden als gebundene Team-Kapazität geführt, also als feste Kapazitätseinheit über einen definierten Zeitraum, statt über Einzelzuordnungen zu Vorgängen. Praktisch bedeutet das: Ein Team mit sieben Personen erscheint in der Kapazitätsrechnung als reservierter Block, dessen interne Verteilung das Team selbst verantwortet.
• Gemeinsame Statusebene: Meilensteine und Release-Termine dienen als synchronisierbare Fixpunkte zwischen beiden Welten. Diese Meilenstein-Synchronisation, also die Abstimmung agiler Release-Termine mit klassischen Meilensteinen abhängiger Projekte, macht Termine über Methodengrenzen hinweg verhandelbar.
• Gemeinsame Kennzahlen auf Portfolioebene: Wertbeitrag, gebundene Kapazität und Termintreue lassen sich für beide Vorgehensweisen erheben. Damit bleiben agile und klassische Vorhaben in derselben Rangliste vergleichbar, ohne dass agile Teams detaillierte Vorgangspläne liefern müssen.

Hybrides Projektmanagement kombiniert beide Vorgehensweisen innerhalb eines Projekts, typischerweise mit klassischer Rahmenplanung samt Meilensteinen und agiler Umsetzung in einzelnen Teilbereichen. In regulierten Umgebungen wie Pharma oder Finanzwesen hat sich dabei ein bewährtes Muster etabliert: Initiierung und Planung laufen klassisch, um Budget, übergreifende Ziele, Produktvision und Compliance-Anforderungen abzusichern. Die daraus abgeleiteten Anforderungen werden als Epics auf Teamebene verteilt und dort agil in Sprints umgesetzt, wobei ein Backlog als priorisierte Liste offener Anforderungen die Reihenfolge steuert. Ein zentrales PMO koordiniert dabei die teamübergreifenden Abhängigkeiten und synchronisiert die Meilensteine. Wichtig für die Landschaftssicht: Agile Projekte dürfen nicht ausgeklammert werden. Werden sie nicht erfasst, fehlt genau die Kapazität, die dauerhaft an Teams gebunden ist, und jede Kapazitätsaussage der Gesamtlandschaft fällt zu optimistisch aus.

Wer ist im Unternehmen für die Projektlandschaft verantwortlich?

Die Verantwortung für die Projektlandschaft verteilt sich entlang von vier Funktionen: entscheiden, koordinieren, Kapazitäten bereitstellen und umsetzen. Jede dieser Funktionen braucht eine benannte Rolle mit klar abgegrenztem Aufgabenzuschnitt.

Das Portfolio-Board ist dabei das budgetverantwortliche Lenkungsgremium, das über Projektstarts, Stopps und Prioritäten entscheidet. Diese Entscheidungshoheit liegt ausdrücklich nicht beim PMO, also beim Project Management Office, das Entscheidungen vorbereitet und die Datenbasis sicherstellt. Der Ressourcenverantwortliche, meist die Führungskraft der jeweiligen Fachabteilung, gibt Kapazitäten für Projekte frei und verantwortet die Balance zwischen Projekt- und Linienarbeit. Genau an dieser Schnittstelle entsteht der häufigste Rollenkonflikt im Multiprojektmanagement: Das PMO wird für Termin- und Budgetabweichungen verantwortlich gemacht, ohne Weisungsbefugnis über Ressourcen zu besitzen. Die Mindestanforderung lautet deshalb, für jede Entscheidungsart schriftlich festzulegen, wer entscheidet: Projektstart, Priorisierung, Ressourcenfreigabe und Projektstopp. Der Zuschnitt selbst verändert sich mit der Organisationsgröße. In kleineren Organisationen bündelt eine Person mehrere Rollen, in Konzernstrukturen existieren PMO, Portfoliomanagement und Ressourcenmanagement getrennt und teilweise mehrfach je Geschäftsbereich. Ohne benannte Verantwortung für die Pflege der Landschaftsdaten verfällt jede Übersicht innerhalb weniger Monate, unabhängig von der Organisationsform.

Welche Aufgaben übernimmt das PMO?

Das PMO ist die methodische und datenseitige Instanz der Projektlandschaft. Es definiert Standards, sichert die Datenqualität, erstellt das Multiprojekt-Reporting und bereitet Portfolioentscheidungen entscheidungsreif auf. Der Aufgabenkatalog umfasst typischerweise sechs Bereiche:

• Projektmanagement-Standards und Vorlagen: Das PMO entwickelt verbindliche Vorgehensmodelle, Dokumentvorlagen und Freigabeprozesse und hält sie aktuell.
• Einheitliche Klassifizierung und Statuslogik: Es legt Projektarten, Größenklassen, Pflichtfelder und die Bedeutung von Statuswerten fest.
• Betrieb und Weiterentwicklung der Werkzeuge: Es verantwortet die eingesetzten Systeme fachlich, betreut Anwender und steuert Anpassungen an veränderte Prozesse.
• Multiprojektcontrolling und Reporting: Das Multiprojektcontrolling ist die laufende Überwachung von Terminen, Kosten und Kapazitäten über alle Projekte hinweg, aus der das regelmäßige Portfolio-Reporting entsteht.
• Qualifizierung und Coaching von Projektleitungen: Es schult Methoden und Werkzeuge und begleitet Projektleitungen in kritischen Situationen.
• Auswertung von Lessons Learned: Es sammelt Erfahrungen aus abgeschlossenen Projekten und überführt sie in angepasste Standards.

Wie weit die Eingriffstiefe reicht, hängt vom PMO-Mandat ab, also von der formal festgelegten Befugnis des PMO gegenüber Projekten und Fachbereichen. Branchenstandards unterscheiden drei Archetypen: Das unterstützende PMO agiert beratend, stellt Methoden und Vorlagen bereit und übt geringe Kontrolle aus. Das steuernde PMO gibt verbindliche Standards etwa für Reporting und Klassifizierung vor und prüft deren Einhaltung. Das direktive PMO steuert Projekte selbst und besitzt Weisungsbefugnis gegenüber Projektleitungen. Welcher Typ passt, ist eine Organisationsentscheidung, aber sie muss explizit getroffen und dokumentiert werden. Ein PMO ohne verbindliches Mandat und ohne Zugriff auf aktuelle Projektdaten wird zur Berichtsstelle ohne Steuerungswirkung.

Welche Rolle hat der Multiprojektmanager?

Der Multiprojektmanager verantwortet die operative Koordination zwischen den Projekten einer Landschaft, im Unterschied zur Projektleitung, die für das Ergebnis eines einzelnen Vorhabens verantwortlich ist. Zu seinen Kernaufgaben zählen die Überwachung der Abhängigkeiten zwischen Projekten, die Identifikation von Ressourcenkonflikten, also Situationen, in denen mehrere Projekte dieselbe Kapazität zeitgleich beanspruchen, die Erarbeitung konkreter Ausgleichsvorschläge sowie die Bewertung von Termin- und Kapazitätsverschiebungen über mehrere Projekte hinweg. Das Abhängigkeitsmanagement gehört damit ebenso zum Aufgabenprofil wie die Vorbereitung von Entscheidungsvorlagen für das Lenkungsgremium.

Damit diese Rolle wirksam wird, braucht sie zwei Voraussetzungen: Zugriff auf aktuelle Plan- und Ist-Daten aller Projekte sowie ein anerkanntes Mandat gegenüber Projektleitungen und Ressourcenverantwortlichen. Fehlt eines von beiden, bleibt der Multiprojektmanager eine Beobachtungsfunktion, die Konflikte beschreibt, aber nicht auflösen kann. Zum Aufgabenprofil gehört deshalb auch die strukturierte Eskalation, also die geregelte Weitergabe einer Entscheidung an die nächsthöhere Instanz, wenn auf operativer Ebene keine Lösung erreichbar ist. Wie eine Eskalation im Projektmanagement sachlich vorbereitet und ohne Konfliktverschärfung ausgelöst wird, entscheidet maßgeblich über die Akzeptanz der Rolle in den Fachbereichen.

Die Abgrenzung zum PMO verläuft entlang des Rahmens: Das PMO setzt Standards, definiert Kennzahlen und liefert die Datenbasis, der Multiprojektmanager arbeitet innerhalb dieses Rahmens fallbezogen an konkreten Konflikten zwischen bestimmten Projekten. In kleineren Organisationen fallen beide Rollen regelmäßig zusammen, was funktioniert, solange die unterschiedlichen Aufgabenlogiken bewusst getrennt bleiben.

Wie unterstützt eine Projektmanagement-Software die Projektlandschaft?

Eine Projektmanagement-Software ersetzt die Steuerung der Projektlandschaft nicht, sie macht sie wiederholbar: Projektdaten werden zentral gehalten, automatisch verdichtet und Auswertungen stehen ohne manuellen Abgleich zur Verfügung. Sechs Funktionsbereiche sind für die Landschaftssteuerung entscheidend.

• Zentrale Projektdatenbank: Alle Projekte, Programme und Portfolios werden mit einheitlichen Stammdaten in einem System geführt. Diese zentrale Datenhaltung, also die einmalige Speicherung jeder Information an einem definierten Ort, beendet die Abstimmung zwischen konkurrierenden Dateiversionen.
• Multiprojekt-Termin- und Kapazitätsplanung: Termine und Kapazitätsbedarfe werden über alle Projekte hinweg gerechnet. Überbuchungen einzelner Rollen werden dadurch sichtbar, bevor sie in mehreren Projekten wirksam werden.
• Portfolio-Bewertung und Priorisierung: Bewertungskriterien, Gewichtungen und Scoring-Ergebnisse werden im System hinterlegt und fortgeschrieben. Für ein strategisches Projektportfoliomanagement bleibt damit nachvollziehbar, auf welcher Grundlage eine Entscheidung getroffen wurde.
• Ist-Rückmeldung und Multiprojektcontrolling: Aufwände und Fortschritte werden dort erfasst, wo sie entstehen, und fließen unmittelbar in die Auswertungen ein. Der Plan-Ist-Vergleich über Termine, Kosten und Kapazitäten liegt ohne Nacharbeit vor.
• Dashboards und Auswertungen: Verdichtete Sichten für Gremien und Detailsichten für Projekt- und Ressourcenverantwortliche entstehen aus derselben Datenbasis. Der monatliche Aufbereitungsaufwand für Berichte entfällt weitgehend.
• Unterstützung klassischer, agiler und hybrider Vorgehensweisen: Vorhaben unterschiedlicher Methodik werden im selben System geführt und gemeinsam ausgewertet. Agile Teams erscheinen mit ihrer gebundenen Kapazität in der Gesamtsicht, statt außerhalb der Landschaft zu bleiben.

Der entscheidende Unterschied zu Tabellenkalkulationen liegt nicht im Funktionsumfang einzelner Ansichten, sondern in der Konsistenz: Eine Änderung wirkt sich unmittelbar auf alle abhängigen Auswertungen aus, ohne dass Dateien manuell abgeglichen werden müssen. Dabei gilt eine klare Reihenfolge-Regel: Projektbegriff, Statuslogik, Rollen und Entscheidungswege müssen definiert sein, bevor ein Werkzeug ausgewählt wird. Eine Software bildet Prozesse ab, sie erzeugt sie nicht. Bei der Auswahl sind für Unternehmen im gehobenen Mittelstand und Konzernumfeld fünf Kriterien maßgeblich: die Anpassbarkeit an bestehende Unternehmensprozesse, die Skalierbarkeit über Standorte und Abteilungen, das Betriebsmodell als On-Premises- oder Cloud-Variante, Datenschutz- und Compliance-Anforderungen sowie die Unterstützung der tatsächlich eingesetzten Methoden. Ein Rollen- und Rechtekonzept, also die systemseitige Festlegung, welche Rolle welche Daten sehen und ändern darf, gehört ebenfalls zu den Auswahlkriterien, weil Projekttransparenz nicht bedeutet, dass jeder alles sieht. In Pharma und Maschinenbau kommt hinzu, dass Nachvollziehbarkeit und Dokumentation von Entscheidungen regulatorisch relevant sind und im System abgebildet werden müssen.

Multiprojektmanagement mit PLANTA Enterprise und PLANTA Project

Damit Einzelprojektplanung, Ressourcensicht und Portfoliosteuerung auf derselben Datenbasis arbeiten, müssen die beschriebenen Funktionsbereiche in einer integrierten Lösung zusammenlaufen statt über mehrere Systeme verteilt zu bleiben.

PLANTA Project ist die Lösung für Einzel- und Multiprojektmanagement mit Ressourcenplanung, Portfoliomanagement sowie Kosten- und Risikomanagement. PLANTA Enterprise erweitert diesen Funktionsumfang um strategisches Projekt- und Portfoliomanagement und richtet sich damit an Organisationen, die neben der operativen Steuerung auch die strategische Portfolioausrichtung im System führen. Beide Editionen zeichnen sich durch eine führende Funktionalität für hybrides Projektmanagement aus, integrieren klassische und agile Methoden in einem System und lassen sich flexibel an bestehende Unternehmensprozesse anpassen. Die Entwicklung erfolgt durchgängig in Karlsruhe als Software made in Germany, die Lösungen sind DSGVO-konform und sowohl als On-Premises- als auch als Cloud-/SaaS-Version verfügbar. Aktuell sind sie branchenübergreifend in über 800 Installationen mit mehr als 80.000 Nutzern weltweit im Einsatz. Details zu den Funktionen für Einzel- und Multiprojektmanagement zeigt die Seite zum Projektmanagement mit PLANTA Project. Einen Überblick über die Editionen, die Lizenzmodelle und die kostenlose Testversion finden Sie in der Preisübersicht.

Für die Steuerung einer Projektlandschaft bedeutet das konkret: Alle Vorhaben werden auf einer gemeinsamen Datenbasis geführt, sodass Einzelprojektplanung, Ressourcenauslastung und Portfoliobewertung auf dieselben Stammdaten zugreifen. Echtzeit-Übersichten und Frühwarnsysteme machen Kapazitätsengpässe und Terminabweichungen sichtbar, bevor sie in mehreren Projekten wirksam werden. Klassische, agile und hybride Vorhaben werden im selben System geführt und gemeinsam ausgewertet, sodass agile Teams mit ihrer gebundenen Kapazität Teil der Landschaftssicht bleiben.

Wie ein Umstieg auf eine gemeinsame Datenbasis praktisch verläuft, zeigt das Beispiel von Uhde High Pressure Technologies im Anlagenbau: Vorher wurden die Terminpläne von rund 170 Parallelprojekten in Tabellenkalkulationen und verteilten Einzelplanungswerkzeugen geführt, wodurch Liefertermine häufig nicht eingehalten werden konnten. Auswahl und Einführung dauerten insgesamt 20 Monate, davon rund zwölf Monate allein von der Problemdefinition bis zur Systementscheidung. Diese Verteilung ist typisch: Der größere Teil des Aufwands liegt nicht im Werkzeug, sondern in der vorgelagerten Klärung von Begriffen, Prozessen und Entscheidungswegen. Messbar war nach der Einführung eine höhere Planungssicherheit, eine frühzeitigere Erkennung von Verzögerungen und ein deutlich reduzierter manueller Pflegeaufwand.

Technisch werden Projekte, Programme und Portfolios in einer zentralen Struktur abgebildet, aus der sich Auswertungen automatisch verdichten. Ressourcen werden über einen gemeinsamen Pool geplant, wobei die Bedarfe aus allen Projekten gegen die verfügbaren Kapazitäten je Rolle und Zeitraum gerechnet werden. Anpassbare Workflows bilden die unternehmenseigenen Freigabe-, Melde- und Entscheidungsprozesse ab, statt eine fremde Prozesslogik vorzugeben.

• Zentrale Planung, Steuerung und Controlling aller Projekte auf einer Datenbasis.
• Frühzeitige Erkennung von Ressourcenengpässen und Terminrisiken durch Echtzeit-Auswertungen.
• Gemeinsame Steuerung klassischer, agiler und hybrider Projekte in einem System.
• Anpassung an bestehende Unternehmensprozesse statt Anpassung der Organisation an das Werkzeug.

Welche Fehler sollte man beim Aufbau einer Projektlandschaft vermeiden?

Die typischen Fehler beim Aufbau einer Projektlandschaft sind nicht methodischer, sondern organisatorischer Natur. Falsche Reihenfolge, fehlende Verbindlichkeit und zu hohe Detailtiefe verhindern den Erfolg häufiger als fehlendes Fachwissen. Sieben Fehler treten dabei wiederkehrend auf, und jeder von ihnen hat eine Gegenmaßnahme, die ohne zusätzliche Ressourcen umsetzbar ist.

• Unvollständige Erfassung: Kleine Abteilungs- und IT-Projekte fehlen in der Übersicht, obwohl sie reale Arbeitszeit binden. Gegenmaßnahme: eine dokumentierte Erfassungsschwelle definieren und die Fachbereiche in einer strukturierten Erstaufnahme systematisch abfragen.
• Zu hohe Detailtiefe: Die Landschaft wird auf Vorgangsebene geführt statt auf Landschaftsebene verdichtet, wodurch der Pflegeaufwand explodiert. Gegenmaßnahme: die Detailtiefe, also den Grad der Aufgliederung erfasster Informationen, auf Projekt- und Meilensteinebene begrenzen.
• Werkzeug vor Prozess: Eine Software wird eingeführt, bevor Projektbegriff und Statuslogik definiert sind, und das Werkzeug zementiert dann die bestehende Unklarheit. Gegenmaßnahme: Definitionen und Entscheidungswege vorab festlegen, wie es die Einführung von Projektmanagement-Software in ihrer Vorbereitungsphase ohnehin vorsieht.
• Keine feste Aktualisierungsroutine: Daten veralten zwischen den Erhebungen, und die Auswertungen verlieren ihre Glaubwürdigkeit in den Gremien. Gegenmaßnahme: einen verbindlichen Datenpflege-Rhythmus mit benannten Verantwortlichen und festen Stichtagen etablieren.
• Priorisierung ohne Konsequenz: Eine Rangfolge wird erstellt, aber kein Projekt wird gestoppt oder verschoben, sodass die Kapazitätsgrenze stillschweigend überschritten wird. Gegenmaßnahme: jede Priorisierungsrunde mit einer expliziten Stopp- und Verschiebungsentscheidung abschließen und diese dokumentieren.
• Unklare Entscheidungswege: Niemand ist befugt, Ressourcen verbindlich zuzuordnen, wodurch Konflikte ungelöst zwischen Bereichen kreisen. Gegenmaßnahme: die Governance schriftlich fixieren und je Entscheidungsart eine benannte Instanz festlegen.
• Agile Projekte ausgeklammert: Die dauerhaft an Teams gebundene Kapazität taucht in der Landschaft nicht auf, wodurch alle Kapazitätsaussagen zu optimistisch werden. Gegenmaßnahme: agile Teams als feste Kapazitätseinheit im Ressourcenpool führen.

Ein Fehler wirkt allerdings erst nach der Einführung, und er ist der ärgerlichste: die fehlende Pflegeregel. Wenn nicht verbindlich geklärt ist, wer neue Projekte anlegt und die Daten aktuell hält, kehren die alten Muster zurück.

Der teuerste dieser Fehler ist die unvollständige Erfassung, weil eine Landschaft, die nur die großen Projekte enthält, systematisch zu optimistische Kapazitätsaussagen produziert. Für PMO-Leitungen und Projektverantwortliche, die eine Projektlandschaft neu aufbauen oder eine gewachsene Struktur konsolidieren, empfiehlt sich deshalb ein schlanker Einstieg: mit wenigen Pflichtfeldern und einer begrenzten Kennzahlenauswahl starten und den Umfang erst dann erweitern, wenn die Basisdaten verlässlich gepflegt werden. Die Akzeptanz in den Fachbereichen entscheidet dabei über die Datenqualität. Wer meldet, muss einen erkennbaren Nutzen aus der Meldung ziehen, etwa eine realistischere Ressourcenzusage oder eine schnellere Freigabeentscheidung. Eine reine Berichtspflicht ohne Rückfluss senkt die Datenqualität innerhalb weniger Zyklen messbar.

Fazit zum Aufbau und Steuerung einer Projektlandschaft

Alle Vorhaben eines Unternehmens werden erst im Gesamtbild steuerbar, und dieses Gesamtbild entsteht in einer festen Abfolge: vollständige Erfassung als Grundlage, einheitliche Klassifizierung und gemeinsame Kennzahlen als Voraussetzung für Vergleichbarkeit, Bewertung mit anschließendem Kapazitätsabgleich als eigentlicher Wirkmechanismus, klare Rollen und ein verbindlicher Zyklus als Betriebsmodell. Portfolioentscheidungen setzen dabei eine vollständige Landschaftssicht voraus, weil sie andernfalls auf einem lückenhaften Datenstand beruhen. Ressourcenkonflikte lösen sich ausschließlich über die projektübergreifende Kapazitätssicht, nicht über bessere Einzelprojektplanung. Und was einmal aufgenommen wurde, bleibt nur wertvoll, solange es fortgeschrieben wird: Ein Dokument, das nach der Erstaufnahme liegen bleibt, verliert seine Steuerungswirkung innerhalb weniger Monate.

Für PMO-Leitungen, Multiprojektmanager und kaufmännische Entscheider greifen diese Erkenntnisse in drei Situationen unmittelbar: bei der Erstaufnahme aller laufenden und beantragten Projekte, bei der Festlegung einheitlicher Statusdefinitionen und Pflichtfelder sowie bei der Einführung eines festen Priorisierungs- und Reviewzyklus. Beginnen Sie mit der vollständigen Erfassung und einheitlichen Definitionen, denn Analyse, Projektpriorisierung, Ressourcenplanung und Werkzeugunterstützung bauen darauf auf. Eine Projektmanagement-Software wie PLANTA Project oder PLANTA Enterprise bildet diese Schritte im Multiprojektmanagement auf einer gemeinsamen Datenbasis ab und unterstützt so die effektive Steuerung paralleler Projekte.

Häufig gestellte Fragen zur Projektlandschaft

Ab wie vielen Projekten lohnt sich eine strukturierte Projektlandschaft?

Nicht die Projektanzahl entscheidet, sondern die Ressourcenkonkurrenz: Sobald mehrere Projekte auf dieselben Personen und Budgets zugreifen, lohnt sich die strukturierte Erfassung. Als Orientierung gilt ein zweistelliger Projektbestand mit abteilungsübergreifender Beteiligung. In kleineren Organisationen genügt zunächst eine einheitlich gepflegte Übersicht mit wenigen Pflichtfeldern.

Wie oft sollte man die Projektlandschaft überprüfen?

Statusdaten werden wöchentlich bis monatlich aktualisiert, die vollständige Bewertung und Priorisierung des Portfolios erfolgt üblicherweise quartalsweise. Bei hoher Änderungsdynamik oder kurzen Projektlaufzeiten verkürzen Sie den Priorisierungszyklus entsprechend, damit Entscheidungen nicht auf überholten Annahmen beruhen.

Reicht Excel zur Verwaltung der Projektlandschaft aus?

Für einen kleinen, stabilen Projektbestand reicht eine Tabellenkalkulation als Einstieg. Mit steigender Projektanzahl und projektübergreifender Ressourcenplanung wird der manuelle Abgleich fehleranfällig und zeitaufwendig. Sobald mehrere Personen parallel pflegen und Kapazitäten projektübergreifend gerechnet werden, ist eine zentrale Projektmanagement-Software die belastbarere Grundlage.

Wie lassen sich agile Projekte in die Projektlandschaft integrieren?

Agile Vorhaben werden über gebundene Team-Kapazität, Release- oder Meilensteintermine und portfolioweite Kennzahlen eingebunden, nicht über detaillierte Vorgangspläne. Führen Sie agile Teams als feste Kapazitätseinheit im Ressourcenpool, damit ihr Aufwand in der Gesamtsicht sichtbar bleibt.