- Eine Roadmap kommuniziert Richtung und Timing — ein Projektplan steuert Umsetzung und Ressourcen
- Beide Formate sind nötig, aber für unterschiedliche Zielgruppen und Entscheidungsebenen
- Die häufigste Fehlerquelle: einen Projektplan als Roadmap präsentieren — und damit Führungskräfte zu verlieren
- 5 Kernpunkte machen den Unterschied zwischen einer Roadmap, die funktioniert, und einer die nur Arbeit macht
Ich kenne kaum einen IT-Bereich, in dem nicht beide Formate gleichzeitig existieren — und dennoch herrscht regelmäßig Verwirrung darüber, was wann wozu passt. In Jour-Fixe-Terminen sehe ich Projektpläne, die als Roadmaps verkauft werden. In Lenkungsausschüssen werden Roadmaps präsentiert, die so detailliert sind, dass Führungskräfte nach zehn Minuten abschalten. Das Ergebnis: Niemand hat das Bild, das er braucht.
Dieser Artikel klärt den Unterschied — nicht theoretisch, sondern so wie er sich in der Praxis zeigt.
Was ist eine Roadmap — und was nicht?
Eine Roadmap beantwortet eine strategische Frage: Was planen wir zu tun, in welcher Reihenfolge und in welchem Zeitrahmen? Sie richtet sich an Entscheider, Stakeholder und Führungskräfte, die kein Interesse an Arbeitspaketen haben — aber sehr wohl wissen wollen, wann welche Initiative live geht, welche Teams wann ausgelastet sind und ob der Kurs noch zur Unternehmensstrategie passt.
Eine Roadmap hat keine Zeilen für Aufgaben, keine Verantwortlichkeiten auf Personenebene und keine Stundenplanung. Sie ist absichtlich unscharf in den Details — das ist keine Schwäche, sondern ihr Zweck. Wer eine Roadmap mit Aufgabenebene befüllt, hat keinen neuen Dokumenttyp geschaffen — er hat einen Projektplan schlechter gemacht.
Was ist ein Projektplan?
Ein Projektplan beantwortet operative Fragen: Wer macht was bis wann? Was sind die Abhängigkeiten? Welche Ressourcen werden benötigt? Er richtet sich an Projektleiter, Teamleiter und Entwickler — Menschen, die auf Basis dieser Information konkrete Arbeit planen und erbringen.
Projektpläne sind zu Recht detailliert. Sie müssen es sein, damit Arbeit koordiniert werden kann. Aber dieser Detailgrad ist auch ihr Nachteil auf Führungsebene: Ein Gantt-Chart mit 200 Vorgängen sagt einem CIO nichts über die strategische Gesundheit des Portfolios.
Der direkte Vergleich
| Roadmap | Projektplan | |
|---|---|---|
| Zielgruppe | CIO, Geschäftsführung, Stakeholder | Projektleiter, Teamleads, Entwickler |
| Zeithorizont | Quartale bis Jahre | Tage bis Monate |
| Granularität | Initiativen, Phasen, Meilensteine | Arbeitspakete, Aufgaben, Stunden |
| Kernfrage | Was machen wir wann — und warum? | Wer macht was bis wann — und wie? |
| Änderungsfrequenz | Quartalsweise bis halbjährlich | Wöchentlich bis täglich |
| Erfolgskriterium | Alle verstehen die Richtung | Alle Aufgaben sind erledigt |
| Typisches Tool | flowlane, Miro, PowerPoint | Jira, MS Project, Asana |
Wann brauche ich welches Format?
Die Faustregel, die ich nach zehn Jahren verwende: Mit wem sitze ich im Raum, und welche Entscheidung soll getroffen werden?
- Lenkungsausschuss, CIO, Geschäftsführung: Immer Roadmap. Keine Aufgabenlisten, keine Ressourcenplanung. Strategisches Bild, kritische Meilensteine, Kapazitätsengpässe auf Teamebene.
- Projektteam, Sprint Planning, Retrospektive: Immer Projektplan. Klare Aufgaben, Verantwortlichkeiten, Abhängigkeiten.
- Abteilungsleiter-Runde, Jour Fixe IT-Management: Meistens Roadmap als Ausgangspunkt, dann bei Bedarf in Projektdetails reinzoomen.
- Budget-Planung, Ressourcendiskussion: Roadmap für die Gesamtperspektive, Projektplan zur Untermauerung einzelner Positionen.
Die 5 Kernpunkte einer wirksamen Roadmap
Nicht jede Roadmap ist eine gute Roadmap. In der Praxis sehe ich immer wieder dieselben Muster, die eine Roadmap unwirksam machen — oder sie zu einem echten Kommunikationsinstrument werden lassen. Diese fünf Punkte machen den Unterschied.
-
1Die richtige Granularität wählen
Eine Roadmap zeigt Initiativen und Phasen — keine Aufgaben. Die goldene Regel: Wenn ein Balken kürzer als zwei Wochen ist, gehört er wahrscheinlich in den Projektplan, nicht in die Roadmap. Je kürzer die Balken, desto mehr leidet der strategische Überblick unter operativem Rauschen.
-
2Wenige, klare Meilensteine setzen
Meilensteine sind die wichtigsten Signale auf einer Roadmap — deshalb dürfen es nicht zu viele sein. Ich empfehle maximal zwei bis drei Meilensteine pro Initiative: Kick-off, entscheidende Lieferung und Go-Live. Alles andere übersetzt sich nicht in strategische Sichtbarkeit.
-
3Lanes nach Planungsverantwortung strukturieren
Swimlanes repräsentieren in den besten Roadmaps nicht das Organigramm, sondern die Planungsverantwortung: Wer trägt Verantwortung für welche Gruppe von Initiativen? Das macht Ressourcenkonflikte und Auslastungsengpässe sofort sichtbar — was bei rein organisatorischer Strukturierung oft unsichtbar bleibt.
-
4Regelmäßig aktualisieren — aber nicht täglich
Eine Roadmap, die nicht aktuell ist, verliert jedes Vertrauen. Eine Roadmap, die täglich geändert wird, verliert ihre Planbarkeit. Der richtige Rhythmus für die meisten IT-Portfolios liegt bei einem monatlichen Kurzcheck und einer quartalsweisen Vollaktualisierung. Mit einem Tool wie flowlane dauert der Monatscheck erfahrungsgemäß unter zehn Minuten.
-
5Immer exportierbar halten
Eine Roadmap, die man vor jedem Meeting erst aufwendig aufbereiten muss, wird nicht genutzt. Das Format muss in unter zwei Minuten in eine Präsentation oder ein E-Mail überführbar sein. Ein PNG-Export, der den relevanten Zeitraum automatisch ausschneidet, ist dafür der effektivste Weg — ohne manuelle Anpassung, ohne Screenshot-Chaos.
Die drei häufigsten Fehler — und wie man sie vermeidet
1. Die Roadmap zu früh einfrieren
Viele IT-Leiter erstellen eine Roadmap zu Jahresbeginn — und aktualisieren sie dann nicht mehr. Das Ergebnis: Spätestens im zweiten Quartal stimmt die Realität nicht mehr mit dem überein, was auf der Folie steht. Die Roadmap verliert Glaubwürdigkeit, und niemand schaut mehr drauf. Eine Roadmap ist ein lebendiges Dokument, kein Archivstück.
2. Einen Projektplan als Roadmap verkaufen
Das passiert häufiger als man denkt: Projektmanager exportieren ihren Jira-Backlog oder MS-Project-Plan und nennen das Ergebnis „Roadmap". Führungskräfte sehen 40 Zeilen mit Aufgabennamen, Verantwortlichen und Deadlines — und schalten nach drei Minuten ab. Das Format wählt die Zielgruppe, nicht der Absender.
3. Zu viele Meilensteine setzen
Wenn jeder Sprint-Abschluss und jedes interne Review ein Meilenstein ist, verlieren die wirklich kritischen Termine ihre Sichtbarkeit. Meilensteine sollten Ereignisse sein, die auch für Stakeholder außerhalb des Projekts bedeutsam sind: Lieferungen, Entscheidungspunkte, externe Releases.
Wie flowlane beim Roadmap-Erstellen hilft
flowlane ist von Grund auf für genau diesen Anwendungsfall gebaut: eine IT-Roadmap, die sich leicht erstellen, leicht aktualisieren und leicht kommunizieren lässt. Keine Aufgabenverwaltung, kein Ressourcenmanagement auf Personenebene — nur der strategische Überblick.
Die drei Ansichten von flowlane entsprechen den drei Situationen, in denen man eine Roadmap typischerweise einsetzt: die Portfolio-Timeline für den Lenkungsausschuss, das Kanban-Board für den Statusüberblick im Jour Fixe, der Meilensteinplan für die Terminübersicht mit dem Programmmanagement. Alle drei arbeiten auf demselben Datenbestand — ohne Copy-Paste, ohne Synchronisationsaufwand.