Jira Cloud Plans und Advanced Roadmaps in der Multi-Team-Steuerung 2026

Am 15. Februar 2024 hat Atlassian die letzten Jira-Server-Lizenzen abgeschaltet. Wer bis dahin keine Migration auf Jira Cloud oder Jira Data Center vollzogen hatte, stand vor einer Werkzeug-Lücke, die sich mit Notlösungen — Tickets in Confluence-Seiten, Excel-Trackern, hastig erworbenen Cloud-Lizenzen — nur unzureichend füllen ließ. Die Migration war für viele DACH-Konzerne ein Kraftakt, der zwischen 2022 und 2024 in koordinierten Mehrphasenprojekten ablief. Die Folge ist, dass im Mai 2026 die übergroße Mehrheit der Jira-Bestände in der Cloud-Variante liegt — und damit die Funktionsentwicklung der vergangenen zwei Jahre, die ausschließlich in der Cloud-Edition erfolgte, breit verfügbar ist.

Das prominenteste Cloud-Werkzeug für die Multi-Team-Steuerung sind die Jira Cloud Plans, die als Nachfolger der früheren Portfolio for Jira und der Advanced Roadmaps der Data-Center-Edition fungieren. Plans sind in der Premium- und Enterprise-Edition enthalten, in der Standard-Edition nur eingeschränkt nutzbar. Wer 2026 Multi-Team-Steuerung in einer mittelgroßen Programm-Organisation verantwortet, kennt Plans als zentrales Werkzeug — und kennt seine Grenzen genauso gut.

Was Plans heute leistet

Die Cloud-Plans aggregieren Tickets über Projektgrenzen hinweg in einer Plan-Hierarchie, die typischerweise drei bis fünf Ebenen umfasst: Initiative → Epic → Story → Subtask, optional erweitert um eine Programm-Ebene oberhalb der Initiative. Die Hierarchie ist konfigurierbar — Atlassian hat die in der Data-Center-Edition statischen Hierarchie-Levels in der Cloud-Edition mit dem 2025er-Release auf bis zu sieben Custom-Levels erweitert. Das gibt Programm-Manager die Möglichkeit, die Hierarchie an die hauseigene Governance-Sprache anzupassen — Workstream, Capability, Outcome — statt sich auf die Atlassian-Standard-Terminologie zu beschränken.

Die Cross-Project-Aggregation ist die zentrale Stärke der Plans. Wo die einzelnen Jira-Projekte den jeweiligen Teams gehören, sammelt der Plan die übergreifende Sicht: Welche Epics sind in welchem Sprint geplant, welche Initiativen ziehen Kapazität aus welchen Teams, wo liegen die Abhängigkeiten zwischen Tickets unterschiedlicher Projekte? Die Visualisierung erfolgt in einer Gantt-ähnlichen Timeline, einem Capacity-Board und einer Dependency-Map.

Das Capacity-Management rechnet auf Story-Point-Basis oder auf Stunden-Basis. Atlassian hat die Story-Point-basierte Capacity 2025 deutlich verbessert: Velocity-Berechnung pro Team über die vergangenen Sprints, automatisierte Übertragung in die Capacity-Planung der kommenden Sprints, Warnhinweise bei Über- oder Unterauslastung. Die Stunden-basierte Variante bleibt für klassisch geführte Teams (Wasserfall, Fixed-Bid-Projekte) relevant — die Berechnung erfolgt über die individuellen Worklog-Eingaben der Teammitglieder.

Das Dependency-Tracking unterstützt die fünf Standard-Issue-Link-Typen (blocks, is blocked by, relates to, duplicates, clones) und visualisiert sie als Graph. Wer 2026 eine Abhängigkeit setzt, sieht die Auswirkung auf den Timeline-Plan unmittelbar: Verschiebt sich die blockierende Aufgabe, verschiebt sich die abhängige Aufgabe automatisch. Die Logik ist aus PERT- und CPM-Tradition vertraut, aber in Jira erstmals in Cloud-Tempo verfügbar.

Was Plans nicht leistet

Die operationale Tiefe der Plans hat zwei sichtbare Lücken, die 2026 weiterhin bestehen.

Erstens: Die Earned Value Management-Integration ist nicht vorhanden. Wer Cost Performance Index oder Schedule Performance Index berechnen will, muss die Plan-Daten in ein externes Werkzeug exportieren — typischerweise Excel, gelegentlich Smartsheet oder MS Project Online. Atlassian hat eine EVM-Integration auf der 2024er-Roadmap gehabt und dann verschoben; im Mai 2026 ist sie weiterhin nicht angekündigt. Für regulierte Industrien (Defense, Bau, Großforschung) ist diese Lücke schmerzhaft.

Zweitens: Das Resource-Leveling über mehrere Plans hinweg ist nur eingeschränkt möglich. Plans rechnen Kapazität innerhalb eines Plans korrekt — wenn aber ein Team in mehreren Plans gleichzeitig auftaucht, wird die Doppelnutzung nicht automatisch erkannt. Die Workaround-Praxis ist die Definition eines Master-Plans, in dem alle Teams aggregiert auftauchen, und in dem die Capacity-Allokation pro Team konsolidiert wird. Das funktioniert, ist aber organisatorisch aufwändig und liegt unterhalb dessen, was MS Project Online in seinem Resource-Pool seit 2010 leistet.

Drittens — und das ist 2026 die größte praktische Reibung — die Berechtigungsstruktur. Plans sind in Jira Cloud nur für Nutzer mit Premium-Lizenz zugänglich. In einem Konzern mit 5.000 Jira-Nutzern, aber nur 200 PM-relevanten Plan-Anwendern, ist die Lizenzmix-Diskussion ein dauerhafter Reibungsfaktor. Atlassian hat 2025 eine „Plan Viewer”-Lizenz angekündigt, die rein lesenden Zugriff zu reduzierten Kosten ermöglicht — der Rollout ist im Mai 2026 in der Beta, aber noch nicht in der allgemeinen Verfügbarkeit.

Konkrete Setup-Praxis 2026

Wer in einer mittelgroßen Programm-Organisation 2026 einen Jira Cloud Plan aufsetzt, durchläuft typischerweise vier Schritte. Erstens: Definition der Hierarchie-Levels in den Jira-Settings — die Custom-Hierarchy muss vor der Plan-Erstellung konfiguriert werden, nachträgliche Änderungen sind möglich aber operativ aufwändig. Zweitens: Auswahl der relevanten Jira-Projekte und Boards — ein Plan kann bis zu 50 Quellen aggregieren, was für die meisten Programme ausreicht. Drittens: Konfiguration der Capacity — Story Points oder Stunden, Velocity-Berechnung über die letzten drei oder fünf Sprints, Holiday-Kalender pro Team. Viertens: Setup der Plan-Views — Timeline, Capacity, Dependencies, Releases — und der Filter, die die Detailtiefe pro Stakeholder-Gruppe steuern.

Die zeitliche Investition für ein sauberes initiales Setup liegt nach Erfahrung der meisten DACH-Implementierungen zwischen 40 und 80 Personenstunden. Wer den Plan in Eigenregie aufsetzt, ist mit der reinen Konfiguration in zwei bis vier Tagen durch — die methodische Vorarbeit (Hierarchie-Definition, Naming-Convention, Capacity-Logik) braucht das Doppelte.

Die laufende Pflege erfordert eine Plan-Owner-Rolle — typischerweise ein dedizierter PMO-Mitarbeiter, der nicht der einzelne Projektleiter ist. Der Plan-Owner ist verantwortlich für die Aktualität der Hierarchie, die Capacity-Konfiguration und die Konsistenz der Issue-Links. Wer diese Rolle nicht hat, erlebt nach drei bis sechs Monaten den klassischen Drift: Plan-Aussagen, die mit der Realität nicht mehr übereinstimmen, weil die Teams ihre Tickets-Hierarchien lokal gepflegt haben.

Asana Goals als Alternative

Asana verfolgt 2026 mit den Goals und Portfolios einen konzeptionell anderen Ansatz. Statt einer Plan-Hierarchie auf Ticket-Ebene baut Asana eine Goal-Hierarchie: Company Goals → Team Goals → Project Goals → Project Tasks. Die Steuerungs-Logik ist OKR-nah (Objectives and Key Results) und richtet sich an Organisationen, die ihre Portfolio-Steuerung weniger über Capacity-Verteilung und mehr über Outcome-Definition organisieren.

Die Goals-Reporting ist in Asana 2026 deutlich besser als in Jira Plans. Asana liefert automatisierte Status-Reports pro Goal, integrierte Updates aus den darunterliegenden Projekten, und eine Goal-Health-Visualisierung mit Ampel-Logik. Wer in einer Organisation arbeitet, die OKRs als Steuerungsinstrument einsetzt — etwa in Tech-Unternehmen, Beratungen, Marketing-getriebenen Organisationen — findet in Asana Goals eine bessere Passung als in Jira Plans.

Die Schwäche von Asana liegt in der Issue-Tracking-Tiefe. Asana-Tasks sind weniger granular als Jira-Issues: Es gibt keine Story Points im engeren Sinne, kein eingebautes Sprint-Konstrukt, keine Bug-vs-Story-Distinktion auf Workflow-Ebene. Für Software-Entwicklungs-Teams, die in Scrum oder Kanban arbeiten und detaillierte Issue-Workflows brauchen, ist Asana unterdimensioniert. Für Programm-Management auf Initiative-Ebene, das die Granularität der einzelnen Teams nicht selbst aggregieren muss, ist es passend.

Die Cross-Tool-Integration ist die häufigste Lösung 2026: Asana für die Goal-Ebene, Jira für die Issue-Ebene, eine API-basierte Synchronisation zwischen beiden. Die Integration ist seit 2024 in beiden Plattformen out of the box verfügbar; die Konfiguration braucht aber Zeit und einen klaren Mapping-Plan.

Monday Portfolio in der DACH-Praxis

Monday.com hat 2026 mit seinen Portfolio-Boards eine in der DACH-Region wachsende Marktposition. Die Stärke von Monday liegt in der visuellen Konfigurierbarkeit: Wer ein Portfolio-Board in zwei Stunden aufsetzen will, mit Custom-Spalten, Farb-Kodierungen und automatisierten Workflows, ist mit Monday schneller als mit Jira oder Asana. Die Schwäche liegt in der methodischen Tiefe: Monday-Boards lassen viele Konfigurationen zu, die methodisch nicht sauber sind — eine Schwäche, die sich in mittelständischen Organisationen ohne PMO-Struktur deutlich rächt.

Die Monday-Capacity-Logik ist 2026 deutlich verbessert gegenüber 2023, bleibt aber hinter Jira Plans zurück. Story-Point-Tracking ist möglich, aber nicht prominent unterstützt; die Velocity-Berechnung erfolgt nicht automatisch. Wer Monday in einer agilen Organisation einsetzt, kombiniert die Boards typischerweise mit einem Scrum-Master-Tracking in Confluence oder Notion.

Die Notion AI PM hat in den letzten zwölf Monaten einen sichtbaren Marktanteil im KMU-Segment gewonnen. Notion bietet 2026 eine PM-spezifische AI-Funktionalität, die Roadmap-Items aus Meeting-Notizen extrahiert, automatisierte Status-Updates aus Slack-Channels zusammenstellt und Capacity-Hinweise aus Kalenderdaten ableitet. Die Qualität dieser Features hängt deutlich von der Disziplin der Datenpflege ab — wer Slack-Channels chaotisch führt, bekommt chaotische Status-Updates. Wer die Datenpflege im Griff hat, bekommt eine bemerkenswert produktive PM-Unterstützung.

MS Project Online und Project for the Web

Microsoft Project Online bleibt 2026 das Werkzeug der Wahl in klassisch geführten Großprojekten — Bau, Defense, regulatorische Pflicht-Programme. Die Stärke liegt in der CPM-Tradition: Kritischer Pfad, Resource-Leveling, Cost-Tracking mit EVM-Integration, Baseline-Management. Wer ein Bauprojekt mit 5.000 Vorgängen und 200 Ressourcen steuert, ist mit MS Project Online besser bedient als mit Jira Plans — die Werkzeug-Tradition kommt aus dieser Welt.

Microsoft Project for the Web ist die leichtgewichtige Cloud-Variante, die für hybride Teams konzipiert ist. 2026 hat sie eine relevante Marktpositionierung im Mittelstand: Wer schon im Microsoft-365-Ökosystem arbeitet, bekommt eine PM-Funktionalität, die mit den vorhandenen Lizenzen kombinierbar ist. Die methodische Tiefe bleibt hinter MS Project Online zurück, die Konfigurations-Geschwindigkeit ist deutlich besser.

Die Integration zwischen MS Project und Azure DevOps ist 2026 das, was die Microsoft-Welt von der Atlassian-Welt unterscheidet: Wer in Azure DevOps Tickets pflegt und in MS Project Vorgänge plant, kann beide Welten über die Standard-Konnektoren synchronisieren. Die Logik ist nicht so geschmeidig wie die Jira-interne Plan-Logik, aber für Microsoft-getriebene Organisationen ist sie passend.

Smartsheet als hybride Alternative

Smartsheet hat sich 2026 als hybrider Werkzeug-Knotenpunkt etabliert, der zwischen klassischer Projekt-Steuerung und agiler Team-Koordination vermittelt. Die Stärke liegt in der Spreadsheet-Vertrautheit kombiniert mit Project-Management-Tiefe: Gantt-Charts, Dependencies, Capacity-Tracking, automatisierte Workflows. Die Schwäche liegt — wie bei Monday — in der methodischen Offenheit: Smartsheet zwingt zu nichts, was in undisziplinierten Organisationen zur Wildwuchs-Tendenz führt.

In DACH-Organisationen, die Smartsheet 2026 einsetzen, dominieren zwei Use-Cases: erstens als Portfolio-Layer über mehrere Jira-Projekte hinweg (mit API-Synchronisation), zweitens als Stand-alone-Tool in Organisationen, die für Jira oder MS Project zu klein sind, aber für reine Trello- oder Asana-Lösungen schon zu komplex.

Tool-Auswahl im Mai 2026

Die Tool-Wahl 2026 folgt in den meisten mittelgroßen Programm-Organisationen einer pragmatischen Logik. Wer Software-Entwicklung mit agilen Teams steuert: Jira Cloud Plans. Wer Outcome-Steuerung über OKRs organisiert: Asana Goals, gegebenenfalls kombiniert mit Jira auf der Team-Ebene. Wer im Microsoft-Ökosystem lebt und Mittelstand-Komplexität bewältigt: MS Project for the Web. Wer Bau, Defense oder regulatorische Pflicht-Programme steuert: MS Project Online. Wer schnell und visuell ein Portfolio-Board braucht: Monday. Wer hybride Strukturen aufsetzt: Smartsheet.

Die Kombinationen sind 2026 die Regel, nicht die Ausnahme. Eine typische DACH-Konzernlandschaft hat Jira Cloud auf der Team-Ebene, Asana oder MS Project on top für die Portfolio-Ebene, Confluence oder Notion für die Dokumentation, Slack oder Teams für die Kommunikation. Wer alle vier Schichten in ein einziges Tool zwingt, hat entweder einen sehr kleinen Use-Case oder ein sehr großes Problem.

Praktische Folgerungen für die Tool-Strategie

Wer 2026 die Tool-Strategie für eine mittelgroße Programm-Organisation verantwortet, hat fünf Bausteine zu beachten.

Erstens: Die Lizenz-Diskussion ist nicht trivial. Jira Premium kostet pro Nutzer und Monat im niedrigen zweistelligen Euro-Bereich, Asana Enterprise im mittleren zweistelligen Bereich, MS Project Online im mittleren zweistelligen Bereich. Bei 200 PM-relevanten Nutzern summiert sich das jährlich in den hohen fünfstelligen Bereich — eine Investition, die methodisch begründet sein muss.

Zweitens: Die Migration-Vermeidung als Strategie. Wer 2024 die Cloud-Migration nicht vollzogen hat und 2026 auf Data Center oder Behelfslösungen sitzt, sollte die Migration jetzt planen — die Funktionslücke wächst. Wer in der Cloud lebt, sollte die nächsten zwei Jahre nicht für Tool-Wechsel nutzen, sondern für methodische Reife.

Drittens: Die PMO-Rolle als Werkzeug-Stewardship. Tools sind 2026 nicht selbst-erklärend. Wer eine PMO-Stabsstelle hat, sollte einen oder zwei Tool-Stewards definieren, die die Konfiguration über alle Plans und Projekte hinweg konsistent halten. Ohne diese Rolle driften die Konfigurationen innerhalb von zwölf Monaten in jede Richtung.

Viertens: Die Schulungs-Investition als Daueraufgabe. Jira-Plan-Schulungen sind 2026 nicht mit einem zweitägigen Kurs erledigt. Die Funktionsentwicklung läuft kontinuierlich, die Tailoring-Optionen sind umfangreich. Halbjährliche Refresher-Sessions sind in disziplinierten Organisationen Standard.

Fünftens: Die Vendor-Abhängigkeit als strategisches Risiko. Wer 2024 die Atlassian-Cloud-Migration aufgrund der Server-Abschaltung erleben musste, weiß, dass Vendor-Entscheidungen mittelfristig revisable Folgen haben können. Eine moderate Diversifizierung über mehrere Plattformen ist 2026 nicht überflüssig, sondern strategisch.

Bilanz

Jira Cloud Plans sind 2026 das beste Werkzeug für die Multi-Team-Steuerung in software-getriebenen Programm-Organisationen — solange Capacity in Story Points gerechnet wird, EVM keine Rolle spielt, und die Plan-Owner-Rolle besetzt ist. Wo eine dieser Voraussetzungen fehlt, ist die Alternative im Werkzeug-Markt verfügbar: Asana für Outcome-Steuerung, MS Project Online für klassische Großprojekte, Monday für visuelle Portfolio-Übersicht, Smartsheet für hybride Strukturen, Notion AI PM für KMU mit AI-Affinität.

Die nächsten zwölf bis achtzehn Monate werden die Funktionslücken der Plans schrittweise schließen — Atlassian hat EVM, Resource-Leveling und die Plan Viewer-Lizenz auf der öffentlichen Roadmap. Bis dahin bleibt die operative Realität: Plans sind sehr gut, nicht perfekt, und in der Kombination mit einem klar definierten PMO-Setup das Werkzeug der Wahl für die meisten DACH-Programm-Organisationen 2026.