Was ist ein Projekt-Dashboard?
Der Begriff „Dashboard“ bedeutet wörtlich „Instrumententafel“. Die Computerwoche beschreibt Dashboards als zentrale Kontrollstationen, die Entscheider:innen die wichtigsten Parameter auf einen Blick bereitstellen. Das Bild aus dem Auto passt gut: Das Armaturenbrett zeigt Geschwindigkeit, den Tankfüllstand und eine Warnleuchte, wenn etwas Aufmerksamkeit erfordert, während die Motordaten unter der Haube bleiben.
Die meisten Teams brauchen zwei Arten von Projektmanagement-Dashboards:
Operatives Dashboard: Das Projektteam nutzt es täglich, um Aufgaben, Verantwortliche und Termine zu koordinieren.
Reporting-Dashboard: Sponsor:innen, Kund:innen und die Geschäftsleitung prüfen es wöchentlich, um zu überprüfen, ob das Projekt im Zeitplan liegt.
Die besten Dashboards für das Projekt-Tracking liefern beide Ansichten aus denselben Daten, damit niemand zwei Datenstände parallel pflegen muss. Ein gutes Dashboard ersetzt Status-E-Mails, ein schlechtes wird zu einem weiteren Dokument, das gepflegt werden muss und niemand liest.
Was sollte ein Projekt-Dashboard zeigen?
Ein gutes Projekt-Dashboard zeigt fünf Dinge: den Gesamtstatus auf einen Blick, den Fortschritt im Zeitplan, anstehende Termine, aktive Risiken oder Blocker sowie projektspezifische KPIs. Mehr Inhalte erzeugen meist Rauschen, das Stakeholder:innen irgendwann überspringen.
Um jedes Element greifbar zu machen, stellen Sie sich ein Marketingteam vor, das die Unternehmenswebsite neu aufsetzt. So entsteht sein Reporting-Dashboard.
Gesamtstatus des Projekts
Beginnen Sie mit einer einzigen Ampel in Rot, Gelb oder Grün und einem Satz, der die Farbe erklärt. Gehen Sie davon aus, dass vielbeschäftigte Führungskräfte diese Zeile zuerst lesen, manchmal sogar als Einzige. Legen Sie vorab fest, was jede Farbe bedeutet, und bleiben Sie ehrlich: Ein grüner Status, der einen ernsten Blocker verschweigt, zerstört das Vertrauen in das gesamte Dashboard.
Beim Website-Relaunch steht die Ampel auf Gelb, weil eine Verzögerung beim Dienstleister den Go-live gefährdet.
Fortschritt im Zeitplan
Zeigen Sie, wie weit das Projekt gekommen ist: die erledigte Arbeit, die erreichten Meilensteine und die kommenden Meilensteine. Ein einfaches Balkendiagramm oder eine Zeitleiste funktioniert für Stakeholder:innen besser als ein detailliertes Gantt-Diagramm mit allen Abhängigkeiten. Wenn Ihr Team im Gantt-Format plant, trennt eine Gantt-Diagramm-Vorlage den detaillierten Plan von der Übersicht. Beim Website-Relaunch sind vier von sechs Phasen abgeschlossen, und die Content-Migration läuft.
Anstehende Termine
Listen Sie die nächsten drei bis fünf Termine mit Datum und verantwortlicher Person auf. So wissen Stakeholder:innen, worauf sie achten sollten, ohne die gesamte Aufgabenliste lesen zu müssen. Beim Website-Relaunch sieht das so aus:
20. Okt.: Content-Freeze, verantwortlich ist die Content-Leitung
27. Okt.: API-Anbindung des Dienstleisters, verantwortlich ist die Entwicklungsleitung
3. Nov.: Abnahmetests, verantwortlich ist die QA-Leitung
10. Nov.: Go-live, verantwortlich ist die Projektleitung
Aktive Risiken oder Blocker
Zeigen Sie die zwei oder drei wichtigsten Risiken, die den Projekterfolg derzeit gefährden, jeweils mit einer Gegenmaßnahme und einer verantwortlichen Person.
Mit einer Risikomatrix bewerten Sie Eintrittswahrscheinlichkeit und Auswirkung einheitlich und entscheiden, welche Risiken aufs Dashboard gehören.
Der Website-Relaunch hat einen Blocker. Die API des Dienstleisters kommt zwei Wochen zu spät, deshalb testet die Entwicklungsleitung eine alternative Anbindung.
Projekt-KPIs
Wählen Sie drei bis fünf Kennzahlen, die den Zustand des Projekts anzeigen, etwa die Termintreue, die Budgetabweichung oder die Zahl der Scope-Änderungen. Welche passen, hängt vom Projekttyp ab: Ein Softwareteam verfolgt vielleicht die Fehlerrate, ein Bauteam die Terminabweichung. Hilfe bei Auswahl und Definition finden Sie in unserem Artikel über Kennzahlen im Projektcontrolling. Wenn sich Ihr Team nicht einigen kann, welche KPIs zählen, sammeln Sie die Kandidaten zuerst in einer MindMeister-Mindmap und behalten nur die, die eine Entscheidung verändern würden.
Der Website-Relaunch verfolgt das verbrauchte Budget im Vergleich zum Plan, pünktlich gelieferte Aufgaben und genehmigte Scope-Änderungen. Jeder KPI zeigt den Zielwert neben dem aktuellen Wert.
Was nicht auf ein Projekt-Dashboard gehört
In der Praxis scheitern Projekt-Dashboards oft daran, dass sie zu viel zeigen. Vier Dinge gehören nicht auf ein Reporting-Dashboard: Aktivitäten auf Aufgabenebene, Vanity-Metriken, historische Daten ohne Konsequenz und nackte Zahlen ohne Kontext.
Jedes zusätzliche Diagramm konkurriert um wenige Sekunden Aufmerksamkeit. Streichen Sie zuerst diese Punkte:
Aktivitäten auf Aufgabenebene. Einzelne Aufgaben-Updates, Kommentarverläufe und verschobene Karten gehören auf das Teamboard. Stakeholder:innen, die diese Details sehen, steuern bald Aufgaben statt Ergebnisse.
Vanity-Metriken. Die Zahl erstellter Aufgaben oder geschriebener Kommentare sieht nach viel Aktivität aus, sagt aber kaum etwas darüber, ob das Projekt pünktlich fertig wird. Wenn eine Zahl steigen kann, während das Projekt in Verzug gerät, gehört sie nicht aufs Dashboard.
Historische Daten ohne Konsequenz. Die Burn-Rate des letzten Quartals oder ein vollständiges Protokoll abgeschlossener Aufgaben sorgt nur für mehr Scrollen, nicht für bessere Entscheidungen. Archivieren Sie diese Daten oder verlinken Sie sie aus einem separaten Bericht.
Nackte Zahlen ohne Kontext. „42 offene Aufgaben“ sagt ohne Zielwert oder Trend nichts aus. Zeigen Sie die Zahl im Vergleich zum Plan oder machen Sie sichtbar, ob sie steigt oder fällt.
Die Faustregel: Wenn das Entfernen einer Kennzahl keine Entscheidung ändern würde, entfernen Sie sie.
Operatives Dashboard vs. Reporting-Dashboard
Ein operatives Dashboard nutzt das Projektteam täglich, um die Arbeit zu koordinieren: Es ist detailliert, arbeitet auf Aufgabenebene und wird laufend aktualisiert. Ein Reporting-Dashboard nutzen Stakeholder:innen wöchentlich, um den Zustand des Projekts zu verfolgen: Es ist verdichtet, zeigt Kennzahlen statt einzelner Aufgaben und wird in einem festen Rhythmus aktualisiert. Beide können dieselben Daten nutzen, brauchen aber unterschiedliche Darstellungen.
Zielgruppe: Die operative Ansicht ist für die Menschen, die die Arbeit erledigen, die Reporting-Ansicht für Sponsor:innen, Kund:innen und die Geschäftsleitung.
Detailgrad: Die operative Ansicht zeigt Aufgaben, Zuständigkeiten und Fälligkeiten, die Reporting-Ansicht Prozentwerte, Trends, Risiken und die nächsten Meilensteine.
Aktualisierung: Die operative Ansicht ändert sich, sobald jemand eine Aufgabe verschiebt, die Reporting-Ansicht nur im festen wöchentlichen Rhythmus.
Beantwortete Frage: Das Team fragt „Was mache ich als Nächstes?“, Stakeholder:innen fragen „Liegen wir im Plan?“.
Das operative Board enthält auch eingehende Arbeit, etwa neue Anfragen und das Product Backlog, aus dem sich das Team die nächsten Aufgaben nimmt. Die Reporting-Ansicht funktioniert wie ein Executive Summary für alle, die die Details nicht lesen.
In MeisterTask liefert das Kanban-Projektboard dem Team die operative Ansicht. Jede Spalte steht für eine Phase, und Aufgaben enthalten Zuständige, Fälligkeitsdaten, Kommentare und Checklisten. Reports und die schreibgeschützte Viewer-Rolle geben Stakeholder:innen die Reporting-Ansicht, gespeist aus denselben Daten.
Projekt-Dashboard in MeisterTask erstellen
Für ein Projekt-Dashboard nutzen Sie in MeisterTask vier Funktionen: Reports für zusammenfassende Kennzahlen, benutzerdefinierte Felder für das KPI-Tracking, gemeinsamen Projektzugriff und die Timeline für eine kalenderbasierte Ansicht geplanter Aufgaben. Stakeholder:innen sehen dieselben Daten wie das Team, ohne separate Reporting-Ebene.
Benutzerdefinierte Felder und Custom Reports sind Teil des Business-Plans, Quick Reports sind in allen Plänen verfügbar. Nehmen wir als Beispiel ein Operations-Team, das eine Umstellung der Produktionslinie in drei Werken ausrollt. Die Werksleiter:innen brauchen eine gemeinsame Sicht auf den Rollout, ohne wöchentliche Foliensätze.
1. Benutzerdefinierte Felder für Ihre KPIs anlegen
Benutzerdefinierte Felder machen aus jedem KPI einen Wert, den Sie direkt an einer Aufgabe verfolgen. Öffnen Sie Projekteinstellungen > Benutzerdefinierte Felder und legen Sie für jede Kennzahl ein Feld an, als Text, Zahl oder Dropdown. Das Rollout-Team legt Zahlenfelder für verbrauchtes Budget, pünktliche Aufgaben und offene Risiken an, dazu ein Status-Dropdown.
Aktualisieren Sie die Werte in Ihrem wöchentlichen Review, damit das Dashboard den aktuellen Stand zeigt. Ein drei Wochen alter KPI schadet mehr als ein fehlender, weil er vertrauenswürdig wirkt.
2. Eine Spalte für die Projektübersicht anlegen
Legen Sie ganz links auf Ihrem Board eine Spalte an und nennen Sie sie Projektübersicht. Erstellen Sie pro KPI eine Aufgabenkarte, also eine Karte für das verbrauchte Budget, eine für pünktliche Aufgaben und eine für offene Risiken. Jede Karte zeigt ihren aktuellen Wert im passenden benutzerdefinierten Feld.
Erklären Sie Abweichungen in den Aufgabenkommentaren in ein, zwei Sätzen. Wenn Werk 2 das Budget überschreitet, steht im Kommentar, warum und wie es weitergeht. Die Werksleiter:innen bekommen Zahl und Hintergrund an einem Ort.
3. Reports für den Fortschritt auf einen Blick nutzen
MeisterTask Reports verwandelt Projektdaten in eine Übersicht, die Stakeholder:innen schnell erfassen. Quick Reports wie „Alle offenen Aufgaben“, „Kürzlich erledigte Aufgaben“ und „Alle fälligen Aufgaben“ decken die häufigsten Fragen von Stakeholder:innen ab. Mit Custom Reports filtern Sie nach Zeitraum, zuständiger Person, Aufgabenstatus oder Tags.
Jeder Report kombiniert ein Balkendiagramm mit einer Aufgabentabelle. Benutzerdefinierte Felder können Sie als Tabellenspalten einblenden, sodass KPI-Werte neben den Aufgaben stehen, die sie beschreiben. Exportieren Sie das Ergebnis als CSV- oder XLS-Datei, oder filtern Sie den Rollout nach Werks-Tag, um die Arbeit je Standort zu sehen.
Kombinieren Sie Reports mit der Timeline, der MeisterTask-Variante des Gantt-Diagramms, für eine kalenderbasierte Ansicht geplanter Aufgaben. Zusammen ersetzen die beiden oft den manuell gepflegten Foliensatz.
4. Mit Stakeholder:innen teilen
Fügen Sie Stakeholder:innen mit der Viewer-Rolle zum Projekt hinzu. Viewer erhalten Lesezugriff auf das Projektboard, und Nutzer:innen mit einer Viewer-Lizenz können Quick Reports öffnen, aber keine Inhalte erstellen oder bearbeiten. Um einen Custom Report zu teilen, exportieren Sie ihn als CSV- oder XLS-Datei.
Beim Werks-Rollout wird jede Werksleitung als Viewer hinzugefügt und prüft die Übersichtsspalte vor dem wöchentlichen Call. So wird aus dem Verschicken von Berichten ein einfacher Zugriff auf aktuelle Daten. Das Dashboard bleibt aktuell, und niemand wartet auf die Freitags-E-Mail.
Projektstatusbericht vs. Projekt-Dashboard
Ein Projektstatusbericht ist ein Dokument, das Stakeholder:innen in einem festen Rhythmus erhalten, meist wöchentlich. Ein Projekt-Dashboard ist eine Live-Ansicht, die Stakeholder:innen jederzeit öffnen können. Das Dashboard ersetzt den Großteil der Arbeit am Statusbericht, weil es dieselben Informationen laufend zeigt.
Statusberichte haben trotzdem ihren Platz. Nutzen Sie diese Aufteilung als Entscheidungshilfe:
Behalten Sie einen Statusbericht, wenn: formale Governance, große Stakeholder-Gruppen oder regulatorische Berichtspflichten eine datierte Dokumentation verlangen.
Ein Dashboard reicht, wenn: Teams eng zusammenarbeiten, agile Projekte durchführen oder operative Vorhaben mit häufigen Abstimmungen steuern.
Nutzen Sie beides, wenn: ein:e Sponsor:in Live-Einblick möchte, die Compliance aber trotzdem ein periodisches Dokument verlangt.
Nehmen wir das Quartalsabschluss-Projekt eines Finanzteams. Die Sponsorin prüft das Dashboard jede Woche, doch die Compliance verlangt einen formalen Monatsbericht. Statt die Zahlen neu aufzubereiten, exportiert die Projektleitung die Reports-Daten als XLS-Datei.
So oder so: Besprechen Sie das Dashboard gemeinsam in einem wöchentlichen Jour fixe, statt einen Bericht vorzulesen. Meister KI kann außerdem aus der jüngsten Aufgabenaktivität einen Entwurf für ein Projekt-Status-Update erstellen (derzeit in der Beta), den Sie vor dem Teilen bearbeiten. Ihr wöchentlicher Lagebericht beginnt so mit einem Entwurf statt mit einer leeren Seite.
Beispiele für Projekt-Dashboards
Welches Dashboard passt, hängt vom Projekt ab. Hier die drei Beispiele aus diesem Artikel im Vergleich:
Website-Relaunch: Ampel auf Gelb, vier von sechs Phasen abgeschlossen, die nächsten vier Termine und ein Blocker, eine verspätete API des Dienstleisters
Umstellung der Produktionslinie: eine Übersichtsspalte mit verbrauchtem Budget, pünktlichen Aufgaben und offenen Risiken für jedes der drei Werke
Quartalsabschluss im Finanzbereich: ein wöchentliches Dashboard für die Sponsorin plus ein monatlicher XLS-Export für die Compliance
Alle drei zeigen dieselben fünf Elemente, nur die KPIs ändern sich mit der Arbeit. Starten Sie mit den fünf Elementen und wählen Sie dann die Kennzahlen, nach denen Ihre Stakeholder:innen tatsächlich fragen.
Zugriff statt Anhänge
Ein nützliches Projekt-Dashboard zeigt fünf Dinge: Gesamtstatus, Fortschritt im Zeitplan, anstehende Termine, aktive Risiken und eine Handvoll KPIs. Streichen Sie alles, was keine Entscheidung verändern würde, und trennen Sie die operative Ansicht des Teams von der Reporting-Ansicht für Stakeholder:innen.
MeisterTask bündelt Aufgaben, Fortschritt und den Zugriff für Stakeholder:innen an einem gemeinsamen Ort, sodass alle mit denselben Daten arbeiten. MeisterTask ist nach ISO 27001 zertifiziert, DSGVO-konform und wird in Deutschland gehostet. Das ist besonders wichtig, wenn Ihre Stakeholder:innen aus dem Finanzbereich oder dem öffentlichen Sektor kommen. Teilen Sie Zugriff statt Anhänge, und lassen Sie Ihr Dashboard das Reporting übernehmen. Starten Sie jetzt mit MeisterTask.
