Das Wichtigste kurz
  • 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
„Eine Roadmap, die zu detailliert ist, verliert ihre Zielgruppe. Ein Projektplan, der zu abstrakt ist, verliert seine Nützlichkeit. Beides gleichzeitig zu sein, ist keines von beidem."

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?

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.

  1. 1
    Die 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.

  2. 2
    Wenige, 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.

  3. 3
    Lanes 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.

  4. 4
    Regelmäß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.

  5. 5
    Immer 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.

flowlaneapp.de/app — Portfolio-Timeline
flowlane Portfolio-Timeline als Beispiel einer guten Roadmap: Initiatives, Meilensteine, Lanes nach Verantwortung, Quartalsfokus
Anatomie einer guten Roadmap: Initiatives statt Tasks (①), klare Meilensteine (②), Lanes nach Verantwortung (③), aktueller Quartalsfokus (④), direkter Export (⑤).

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.

Praxistipp: Teste deine Roadmap mit dem „30-Sekunden-Test" — zeig sie jemandem aus der Geschäftsführung für 30 Sekunden und frag danach: Was sind die drei wichtigsten Initiativen dieses Quartals? Wenn die Antwort nicht kommt, ist die Roadmap zu detailliert oder zu unstrukturiert.

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.

P
Peter Skurewicz

IT-Portfoliomanager mit über zehn Jahren Erfahrung in der Steuerung komplexer IT-Portfolios in mittelständischen und großen Unternehmen. Entwickler von flowlane — entstanden aus echter Arbeitspraxis.

— Peter
Eigene Roadmap in Minuten erstellen.
Kein Account, kein Setup — direkt im Browser starten.
App starten →