
Geschrieben von
Lukas Ebner
•
•
Projekte

Ein Fluglotse am Frankfurter Flughafen koordiniert gleichzeitig bis zu 25 Maschinen. Sein Radar zeigt ihm jeden Flieger, jede Geschwindigkeit, jede mögliche Kollision. Wenn er sich auf eine einzige Maschine konzentriert und den Rest vergisst, sterben Menschen.
Jetzt stell dir den typischen Montag in einer IT-Agentur mit 40 Leuten vor: Acht laufende Kundenprojekte, drei interne Initiativen, zwei Entwickler, die an vier Projekten gleichzeitig arbeiten. Und das Radar? Eine Excel-Tabelle, die zuletzt vor drei Wochen aktualisiert wurde.
Multiprojektmanagement ist im Kern genau das, was ein Fluglotse tut – nur dass die meisten Unternehmen es ohne Radar versuchen.
Die Abgrenzung, die erstaunlich oft fehlt
Der Begriff Multiprojektmanagement klingt erst mal selbsterklärend: mehrere Projekte gleichzeitig managen. Aber die Abgrenzung zu verwandten Disziplinen ist wichtiger, als sie auf den ersten Blick scheint.
Einzelprojektmanagement kümmert sich um ein Projekt – Scope, Timeline, Budget, Team. Alles, was innerhalb der Projektgrenzen passiert.
Multiprojektmanagement beginnt dort, wo Projekte um dieselben Ressourcen konkurrieren. Es geht nicht darum, einzelne Projekte besser zu machen. Es geht darum, die Wechselwirkungen zwischen Projekten sichtbar zu machen. Welcher Entwickler sitzt gerade an drei Projekten? Welches Projekt blockiert ein anderes, weil ein Designer fehlt? Wo entstehen Engpässe, die kein Einzelprojektleiter sehen kann?
Portfoliomanagement wiederum operiert eine Ebene höher. Es entscheidet, welche Projekte überhaupt gemacht werden – basierend auf Strategie, ROI, Risikoverteilung. Während Multiprojektmanagement fragt "Wie schaffen wir diese acht Projekte gleichzeitig?", fragt Portfoliomanagement "Sollten wir überhaupt acht Projekte gleichzeitig machen?"
Disziplin | Kernfrage | Fokus | Typisches Werkzeug |
|---|---|---|---|
Einzelprojektmanagement | "Wie liefern wir dieses Projekt?" | Scope, Timeline, Budget eines Projekts | Jira, Trello, MS Project |
Multiprojektmanagement | "Wie schaffen wir diese acht Projekte gleichzeitig?" | Ressourcenkonflikte, Abhängigkeiten, Engpässe | Leadtime, Meisterplan |
Portfoliomanagement | "Sollten wir überhaupt acht Projekte machen?" | Strategie, ROI, Risikoverteilung | Meisterplan, PLANTA Portfolio |
In der Praxis verschwimmen die Grenzen natürlich. Bei einem IT-Dienstleister mit 30 Mitarbeitern macht vermutlich dieselbe Person beides. Aber die Unterscheidung hilft, weil sie unterschiedliche Fragen aufwirft – und unterschiedliche Werkzeuge braucht.
Warum es ab fünf parallelen Projekten kritisch wird
Der PMI Pulse of the Profession Report 2025 zeigt eine Zahl, die mich stutzig gemacht hat: Nur 18% der Projektprofis weisen hohes Business Acumen auf – also die Fähigkeit, Projekte im Geschäftskontext zu bewerten statt isoliert. Aber genau diese 18% haben eine um 27% niedrigere Projekt-Failure-Rate als der Rest.
Was hat das mit Multiprojektmanagement zu tun? Alles. Denn wer Projekte nur isoliert betrachtet, verpasst die Kollisionen. Die typischen Symptome kennt jeder, der mal mehr als vier Kundenprojekte parallel gesteuert hat:
Der Senior-Entwickler, der in drei Projekten eingeplant ist und in keinem richtig produktiv wird. Context Switching kostet laut einer Studie der American Psychological Association bis zu 40% der produktiven Zeit. Nicht 5%. Nicht 10%. Vierzig Prozent.
Projekte scheitern selten an der Einzelprojekt-Ebene. Sie scheitern daran, dass niemand sieht, wie sie sich gegenseitig die Ressourcen wegnehmen.
Die Deadline eines Projekts verschiebt sich um eine Woche – und plötzlich kollidiert der Go-Live mit dem Sprint Review eines anderen Kunden. Der Vertrieb hat ein neues Projekt verkauft, ohne zu wissen, dass das Team bis Ende des Quartals ausgelastet ist. Klingt vertraut?
Das sind keine Einzelfälle. Das ist der Normalzustand, wenn Multiprojektmanagement ad hoc passiert statt systematisch.
Multiprojektmanagement-Methoden, die tatsächlich funktionieren
Artikel, die "10 Methoden" versprechen, machen mich müde. Meistens sind drei davon relevant und sieben Füllmaterial. Hier die drei, die bei IT-Dienstleistern und Agenturen tatsächlich einen Unterschied machen:
Kapazitätsplanung auf Wochenbasis
Klingt banal, wird aber erstaunlich selten gemacht. Jede Woche wird sichtbar, wer wie viele Stunden auf welches Projekt eingeplant ist. Nicht auf Monatsebene – zu grob. Nicht auf Tagesebene – zu aufwändig. Wochenweise trifft den Sweet Spot.
Wenn Sarah in KW 14 auf drei Projekte mit zusammen 52 Stunden geplant ist, sieht das jemand – und nicht erst Sarah selbst am Montagmorgen. Der Punkt ist nicht die Excel-Tabelle, die das theoretisch auch kann. Der Punkt ist, dass eine ressourcenbasierte Projektplanung diese Konflikte automatisch hochspült, bevor sie die Timeline fressen.
Portfolio-Kanban statt Gantt-Overload
Gantt-Charts sind großartig für Einzelprojekte. Für acht parallele Projekte werden sie schnell unlesbar. Portfolio-Kanban zeigt stattdessen alle Projekte auf einer Ebene: Was ist in Akquise? Was läuft? Was steckt fest? Was wird abgeschlossen?
Die Spalten sind dabei nicht die klassischen "To Do / Doing / Done", sondern projektspezifischer: Angebot → Beauftragung → Setup → Delivery → Abnahme → Abgeschlossen. Jede Spalte hat ein WIP-Limit. Wenn mehr als drei Projekte gleichzeitig in "Delivery" stecken und das Team dafür nicht groß genug ist – stopp, erst eins abschließen.
Warum Gantt für Einzelprojekte funktioniert und für Portfolios nicht, haben wir in einem eigenen Artikel mal auseinandergenommen.
Steering-Meetings mit Portfolio-Blick
Viele Teams haben Jour-Fixe-Meetings pro Projekt. Was fehlt, ist ein Meeting, das alle Projekte gleichzeitig betrachtet – und das bewusst kurz hält. 30 Minuten, einmal pro Woche. Keine Statusberichte (die stehen im Tool), sondern drei Fragen:
Wo gibt es Ressourcenkonflikte? Wo hat sich eine Priorität verschoben? Wo brauchen wir eine Entscheidung?
Wenn dieses Meeting länger als 30 Minuten dauert, ist entweder die Vorbereitung schlecht oder die Datenlage unklar. Beides Symptome desselben Problems: Die Organisation erkennt Projektverzögerungen erst, wenn sie bereits Realität sind – nicht wenn sie sich anbahnen.
Multiprojektmanagement-Software im Vergleich
Was muss eine Software können, die Multiprojektmanagement tatsächlich unterstützt – und nicht bloß Einzelprojekt-Features hinter einem Dropdown versteckt?
Fünf Anforderungen, an denen sich die Spreu vom Weizen trennt:
Projektübergreifende Ressourcensicht. Nicht "wie viele Stunden hat Lisa diese Woche gebucht", sondern "wie viele Stunden ist Lisa nächste Woche über alle Projekte eingeplant". Vergangenheit vs. Zukunft – das ist der entscheidende Unterschied.
Portfolio-Dashboard. Alle Projekte auf einen Blick. Status, Budget-Verbrauch, Timeline. Ohne erst fünf Klicks tief in Unterprojekte abtauchen zu müssen.
Finanzielle Projektsicht. Welches Projekt ist profitabel, welches frisst Marge? Multiprojektmanagement ohne Finanzdaten ist Blindflug mit mehreren Flugzeugen gleichzeitig.
Skalierbare Berechtigungen. Projektleiter sehen ihre Projekte, Geschäftsführer das Portfolio. Klingt selbstverständlich, ist es bei vielen Tools nicht.
Integration in bestehende Workflows. Kein Team wechselt von heute auf morgen alle Tools. Die Software muss sich in vorhandene Infrastruktur einfügen.
Hier ein Überblick über die relevantesten Optionen für IT-Dienstleister und Agenturen im DACH-Markt:
Tool | Schwerpunkt | Ressourcenplanung | Financial Tracking | Zielgruppe | Besonderheit |
|---|---|---|---|---|---|
All-in-One für IT-Dienstleister | Wochenbasiert, projektübergreifend | Projekt-Profitabilität in Echtzeit | IT-Agenturen, 10–100 MA | PM + Zeiterfassung + Finanzen in einem System | |
Strategische Portfolioplanung | Szenariobasiert, langfristig | Nicht im Fokus | Mittlere bis große Unternehmen mit PMO | What-If-Szenarien für Ressourcenkonflikte | |
Open-Source-Projektmanagement | Vorhanden, aber weniger intuitiv | Budgetverwaltung | Unternehmen mit Datenschutz-Fokus | DSGVO-konform, On-Premise möglich | |
Tiefes Multiprojektmanagement | Detailliert, mehrstufig | Umfangreich | Größere Organisationen mit PMO | Breite Feature-Landschaft, steile Lernkurve | |
Hybrides PM (klassisch + agil) | Solide, ressourcenorientiert | Budgetplanung | Mittelstand | "Made in Germany", bewährt seit 30+ Jahren |
Leadtime wurde von einem IT-Dienstleister für IT-Dienstleister gebaut – und genau das merkt man. Statt einzelne Module zusammenzuschrauben, denkt Leadtime Multiprojektmanagement als geschlossenen Kreislauf: Ressourcenplanung zeigt wochengenau, wer auf welchem Projekt eingeplant ist – nicht rückblickend, sondern vorausschauend. Die Zeiterfassung läuft direkt im selben System, sodass Plan- und Ist-Auslastung nebeneinander sichtbar werden. Und das Financial Tracking rechnet in Echtzeit aus, ob ein Projekt noch Marge bringt oder ob der dritte Change Request die Profitabilität gerade auffrisst.
Was das für Multiprojektmanagement konkret bedeutet: Du siehst auf einen Blick, dass Projekt A zwar im Zeitplan liegt, aber bereits 85% des Budgets verbraucht hat – während Projekt B zwei Wochen hinter dem Plan hängt, aber finanziell noch im grünen Bereich ist. Diese Verbindung von Timeline, Ressourcen und Geld in einer Ansicht ist das, was die meisten Insellösungen nicht liefern.
Für Teams zwischen 10 und 100 Mitarbeitern – also genau die Größe, in der Multiprojektmanagement zum ersten Mal richtig wehtut – trifft Leadtime den Nerv. Für reine Softwareentwicklungsteams, die vor allem Ticket-Tracking und Sprint-Boards brauchen, ist es vermutlich nicht das richtige Werkzeug. Leadtime ist dort am stärksten, wo Kundenprojekte parallel laufen, Liefer-Engpässe erkannt werden müssen und die Geschäftsführung wissen will, welche Projekte sich wirklich lohnen.
Meisterplan hat seinen Schwerpunkt auf langfristiger Ressourcenplanung und szenariobasierter Entscheidungsfindung. Stark für Unternehmen, die strategische Portfolioentscheidungen treffen müssen. Weniger geeignet für operative Tagessteuerung.
OpenProject ist Open Source, DSGVO-konform und bietet On-Premise-Installation. Für Unternehmen mit strengen Datenschutz-Anforderungen eine solide Grundlage. Die Multiprojekt-Features sind vorhanden und brauchbar, aber die Bedienung erfordert mehr Einarbeitung als bei spezialisierten Lösungen.
Projektron BCS ist eine deutsche Projektmanagement-Software mit Fokus auf Multiprojektmanagement. Bietet eine tiefe Feature-Landschaft, die allerdings mit einer steilen Lernkurve einhergeht. Gut für größere Organisationen mit dedizierten PMO-Teams.
PLANTA Project positioniert sich als hybride Lösung "Made in Germany" und unterstützt sowohl klassisches als auch agiles Projektmanagement. Bewährt im Mittelstand, mit solider Ressourcenplanung.
Die ehrliche Antwort auf "Welches Tool ist das beste?" lautet: Das kommt drauf an, wie dein Unternehmen arbeitet. Ein 15-Personen-Startup braucht ein anderes Werkzeug als ein 200-Personen-IT-Dienstleister mit PMO. Entscheidend ist weniger der Feature-Vergleich als die Frage, ob das Tool zu den bestehenden Prozessen passt – oder ob man die Prozesse ans Tool anpassen muss.
Der Unterschied zwischen Tool und System
Ich sehe das immer wieder: Teams kaufen Multiprojektmanagement-Software und wundern sich sechs Monate später, dass sich nichts verändert hat. Das liegt fast nie am Tool. Es liegt daran, dass Multiprojektmanagement ein System braucht, nicht nur ein Werkzeug.
Ein Fluglotse wird nicht gut, weil er einen Radarschirm hat. Er wird gut, weil er eine Ausbildung hat, klare Regeln befolgt und in einer Organisation arbeitet, die Überlastung ernst nimmt. Sector Capacity Limits in der Luftfahrt begrenzen, wie viele Flugzeuge ein Controller gleichzeitig betreuen darf – in stark frequentierten Sektoren sind das 18 bis 25 Maschinen. Kein Flughafen würde sagen: "Wir haben wenig Personal, also soll jeder Controller halt 50 Flieger nehmen."
Aber genau das machen Unternehmen mit ihren Projekten. Die Liefer-Engpässe, die daraus entstehen, kann keine Software der Welt lösen.
Die Software macht die Situation sichtbar. Die Entscheidung, was mit dieser Sichtbarkeit passiert – weniger Projekte annehmen, Prioritäten setzen, Nein sagen – die bleibt bei den Menschen.
Wir haben Leadtime gebaut, weil uns genau diese Sichtbarkeit gefehlt hat. Nicht weil wir die perfekte Lösung haben – sondern weil wir das Problem lange genug selbst hatten, um zu wissen, wo der Schuh drückt.


