Projektstatusberichte sind ein klassisches Instrument im Projektmanagement, um den Fortschritt eines Projekts zu dokumentieren und die Stakeholder auf dem Laufenden zu halten. In diesem Artikel vergleichen wir klassische Statusberichte mit dem agilen “Pendant” der Team-Dashboards, die durch hilfreiche Metriken die Transparenz und kontinuierliche Verbesserung im agilen Projektmanagement unterstützen.
Die Wahl des richtigen Ansatzes für das jeweilige Projekt hängt von verschiedenen Faktoren ab, darunter die Dynamik des Projekts und die Erwartungen der Stakeholder. Als Projektmanager, Scrum Master oder einer anderen agilen Teamrolle ist es wichtig, beide Methoden zu kennen und ihre jeweiligen Vor- und Nachteile zu verstehen.
Klassische Projektstatusberichte
Im klassischen Projektmanagement sind Statusberichte meist in regelmäßigen Abständen (oft wöchentlich oder monatlich) extra angefertigte, auf bestimmte Weise strukturierte Dokumente. Sie dienen dazu, den aktuellen Stand eines Projekts zu beschreiben, den Fortschritt auf wichtige Meilensteine hin zu überprüfen und aktuelle Risiken sowie Probleme aufzuzeigen.
Statusberichte richten sich dabei meistens an das Management und andere Stakeholder, die nicht direkt im Projektteam arbeiten. Sie bieten eine Übersicht über Zeit, Budget, Ressourcen und geplante nächste Schritte.
Die Erstellung von Statusberichten stellt also einen formalisierten Prozess dar. Der Schwerpunkt liegt dabei auf der Überwachung und Steuerung des Projekts sowie der Sicherstellung, dass Plantermine, Kostenrahmen und Anforderungen eingehalten werden.
Beispiel: Projektstatusbericht für ein Softwareprojekt
Angenommen, wir entwickeln eine neue Funktion für eine Software und erstellen dazu einen klassischen Statusbericht. Ein solcher Bericht würde detailliert den aktuellen Stand des Projekts beschreiben, beispielsweise: ‚Das Projekt ist aktuell zu 60 % abgeschlossen, und der nächste Meilenstein – die Testphase – ist in zwei Wochen geplant.‘ Darüber hinaus würde der Bericht Informationen zum Budget enthalten, etwa: ‚Das Projekt liegt im Budgetrahmen, wobei bisher 70 % des Gesamtbudgets ausgegeben wurden.‘ Zudem würden Risiken klar benannt, wie etwa: ‚Es besteht ein potenzielles Risiko einer Verzögerung der Testphase aufgrund von Ressourcenengpässen.‘ Abschließend werden konkrete nächste Schritte beschrieben, zum Beispiel: ‚Abschluss der Implementierungsphase und Beginn der Testphase.‘ Ein klassischer Statusbericht enthält in der Regel detaillierte Informationen, um die aktuelle Projektsituation klar darzustellen und darüber Rechenschaft abzulegen sowie Unterstützungsmöglichkeiten durch die Stakeholder bei Problemen zu kommunizieren.
Vorteile klassischer Projektstatusberichte
- klare und strukturierte Übersicht über den Projektstand
- Transparenz für alle Stakeholder, insbesondere für das Management
- formale Dokumentation des Projektfortschritts
- Grundlage für Projektunterstützung und für spätere Analysen
Herausforderungen klassischer Projektstatusberichte
- Erstellung kann viel Zeit in Anspruch nehmen, insbesondere bei großen Projekten
- Projektstatusberichte konzentrieren sich oft auf die Vergangenheit und können bei sich schnell ändernden Projektsituationen unzureichend sein
- Anpassungen sind oft schwierig, da die Berichte häufig auf festen Zeitplänen basieren
- Der “Observer Effect”: Sobald ein Bericht regelmäßig erstellt wird, besteht die Gefahr des Gefühls der Kontrolle von außen – manchmal mit der Folge, dass sich ein Team mehr auf die „Inszenierung“ konzentriert als auf den tatsächlichen Fortschritt und vor allem kosmetische Maßnahmen zur Verbesserung durchführt.
Dem gegenübergestellt setzen agile Teams lieber auf mehr Transparenz in der täglichen Umsetzung:
Agile Ansätze – Team-Dashboards, Inspect & Adapt und kontinuierliche Verbesserung
In agilen Teams werden Projektstatusberichte oft durch Team-Dashboards ersetzt, die in Echtzeit aktuelle Metriken und Kennzahlen über den Projektfortschritt darstellen. Diese Dashboards schlagen dabei gleich zwei Fliegen mit einer Klappe: Sie sind nicht nur ein Werkzeug zur Information von Stakeholdern, sondern unterstützen auch die kontinuierliche Verbesserung des Teams und des Prozesses.
Ein Team-Dashboard ist eine visuelle Darstellung der wichtigsten Kennzahlen eines Projekts. Dadurch haben alle Teammitglieder Zugang zu den relevanten Informationen und können besser auf gemeinsame Ziele hinarbeiten. Typische Elemente eines Dashboards sind zum Beispiel (bei Scrum-Teams) ein Produkt- oder Release-Burndown-Chart, das den verbleibenden Arbeitsaufwand im jeweiligen Zeitraum visualisiert oder (bei Kanban-Teams) die durchschnittliche Cycle Time, die zeigt, wie effizient das Team Aufgaben abschließt, sowie die Work in Process (WIP), also die Anzahl der aktuell in Arbeit befindlichen Aufgaben und Themen. Eine zu hohe Anzahl an WIP deutet darauf hin, dass das Team möglicherweise zu viele Dinge gleichzeitig bearbeitet und dadurch ineffizient wird. Deshalb ist es eine bevorzugte Praxis in Kanban, diese Arbeit durch sogenannte WIP-Limits zu begrenzen
Bei Scrum-Teams, die in Sprints arbeiten, kann die Team Velocity dargestellt werden, also die Geschwindigkeit, mit der das Team User Storys abschließt. In Kanban-Teams helfen kumulative Flussdiagramme dabei, Engpässe im Workflow zu identifizieren. Auch Metriken zu Fehlern und Qualität können Bestandteil eines Dashboards sein, um sicherzustellen, dass die Produktqualität nicht beeinträchtigt wird.
Um ein Team-Dashboard zu erstellen, ist es zunächst wichtig, die relevanten Metriken zu identifizieren, die den Fortschritt, die Qualität und die Effizienz des Teams widerspiegeln. Danach sollte ein passendes Tool ausgewählt werden, das die Erstellung und Pflege des Dashboards erleichtert. Beispiele hierfür sind Jira, Trello, Azure DevOps oder spezialisierte Reporting-Tools wie Tableau oder Power BI. Das Design des Dashboards sollte übersichtlich und einfach zu interpretieren sein, sodass alle Teammitglieder die Informationen leicht verstehen können. Eine regelmäßige Aktualisierung der Daten ist ebenfalls notwendig, um die Aussagekraft des Dashboards zu erhalten. Dashboards sollten in regelmäßigen Team-Meetings genutzt werden, um sicherzustellen, dass alle Mitglieder informiert sind und auf aktuelle Entwicklungen reagieren können.
Team-Dashboards sind großartig – wenn sie richtig eingesetzt werden. Doch Vorsicht: Der “Observer Effect” kann auch hier zuschlagen! Sobald ein Team weiß, dass bestimmte Metriken beobachtet werden, können sich Verhaltensweisen ändern, um „gut auszusehen“, anstatt den Prozess tatsächlich zu verbessern.
Stell Dir dazu vor, ein Kanban-Team möchte seine Cycle Time verbessern. Das Dashboard zeigt stolz eine stetig sinkende Zeit pro Ticket – bis das Team entdeckt, dass unliebsame Aufgaben plötzlich länger in der „Ideen“-Spalte hängen bleiben, weil niemand sie anfassen will. Oder noch besser: Ein Teammitglied schließt plötzlich viel mehr Aufgaben an einem Tag ab. Bis das Team bemerkt, dass sich die Zahl lediglich verbessert hat, weil ein Kollege seine Aufgaben in 20 Mini-Tickets zerlegt hat.
Die Lektion? Dashboards sind keine Zielvorlagen und schon gar keine Kontrollmittel, sondern Werkzeuge zur Reflexion. Anstatt Metriken zu manipulieren, sollte das Team regelmäßig hinterfragen, was die Zahlen wirklich bedeuten – und ob sie helfen, den Prozess nachhaltig zu verbessern. So lebt es eine kontinuierliche Überprüfung und Anpassung (Inspect und Adapt).
Und wie sieht es aus, wenn mehrere agile Teams am gleichen Produkt entwickeln? Im Grunde nicht viel anders, bis auf die Tatsache, dass es zusätzlich zur Einzelteam-Betrachtungsebene noch die übergeordnete Ebene gibt. Das Scaled Agile Framework (SAFe) schlägt deshalb zum Beispiel vor, circa einmal im Quartal gleich ein sogenanntes „Inspect & Adapt“ (I&A)-Event für alle alle relevanten Stakeholder des Multiteams (dieses wird in SAFe auch als “Agile Release Train” – ART bezeichnet). Genauer gesagt findet es am Ende jedes Program Increment (PI)-Zyklus statt, der etwa drei Monate dauert. Das I&A dient dazu, den Fortschritt aller Teams im ART zu reflektieren und Verbesserungspotenziale zu identifizieren. Das Event dient der Überprüfung und Anpassen auf mehreren Ebenen und besteht deshalb aus drei Teilen:
- der PI System Demo,
- einer quantitativen und qualitativen Messungsüberprüfung sowie
- einem Retrospektive- und Problemlösungs-Workshop.
Das Ziel des I&A-Events ist es also, den ART zu verbessern, indem Probleme gelöst und Verbesserungsvorschläge sowohl für das Produkt als auch den Prozess für den nächsten PI-Zyklus identifiziert werden.
Vorteile von Team-Dashboards und von Inspect & Adapt
- jederzeit aktuelle Informationen, wodurch das Team schnell auf Probleme reagieren kann.
- die Selbstorganisation des Teams wird unterstützt, sodass es eigenständig Entscheidungen treffen und den Fortschritt kontinuierlich anpassen kann.
- dank kontinuierlicher Überwachung des Fortschritts und fortwährender Überprüfung und Anpassung von Produkt und Prozessen werden Probleme frühzeitig erkannt und Verbesserungen sofort umgesetzt
Herausforderungen von Team-Dashboards und von Inspect & Adapt
- Die Pflege der Daten und die kontinuierliche Nutzung des Dashboards sowie die Durchführung von Events zur Überprüfung und Anpassung von Produkt und Prozessen erfordern viel Disziplin und Engagement des Teams.
- Für externe Stakeholder kann die Darstellung auf Dashboards außerdem schwer zu interpretieren sein – es kommt ihnen nun auch eine neue Rolle zu: Sie müssen sich die Informationen aktiver einholen, als wenn ihnen ein Statusbericht bequem in den Posteingang schwebt. Das ist für viele eine große Umstellung.
- Zudem stellen Dashboards oft eine abstrahierte Sicht dar, die nicht alle Details abbildet, was für das Management manchmal hinderlich sein kann. Gemeinsame Betrachtungen und Diskussionen sowie die Ableitung der geeigneten Maßnahmen sind somit essenziell, damit das Miteinander von Team und Stakeholdern funktioniert. Effektive Kommunikation ist hier der Schlüssel.
Fazit: Wann sollte ich welche Methode wählen?
Die Wahl zwischen klassischen Projektstatusberichten und agilen Team-Dashboards hängt von den Anforderungen und der Kultur des Projekts ab. Klassische Projektstatusberichte sind ideal für Projekte, bei denen eine hohe formale Dokumentation und eine klare, vergangenheitsorientierte Übersicht für das Management benötigt werden. Team-Dashboards und Events wie ein I&A in SAFe oder ähnliches hingegen eignen sich besser für dynamische Projekte, bei denen Echtzeitinformationen, Teamtransparenz und kontinuierliche Anpassungen im Vordergrund stehen.
Nicht immer muss es entweder – oder sein: Ein hybrider Ansatz könnte zum Beispiel darin bestehen, klassische Projektstatusberichte mit Live-Daten aus einem Dashboard zu kombinieren, um sowohl formale Anforderungen zu erfüllen als auch Echtzeittransparenz zu schaffen. Auch die regelmäßige Einbindung von Stakeholdern in agile Reviews oder interaktive Dashboard-Demos kann Brücken zwischen den beiden Welten schlagen und die Kommunikation verbessern.
