Alle Beiträge
Projektmanagement7 Min.

Status-Slides in Projekten: Die unterschätzte Geheimwaffe

Eine Folie, die niemand liebt und viele unterschätzen: Aufbau, Einsatz im Delivery Risk Management – und warum der Aufwand in keinem Verhältnis zum Nutzen steht.

Das Status-Slide – es klingt beinahe zu banal. Eine Folie, sie alle zu alignen, in das PM-Weekly zu treiben und ewig zu dokumentieren. Vielleicht ist es deshalb ein zäher Kampf der PMOs in vielen Organisationen, dafür zu sorgen, dass alle Projektmanager ihre Statusfolien up to date halten, an einem für alle relevanten Stakeholder zugänglichen Ort ablegen und im Idealfall in einem wöchentlichen Meeting präsentieren.

Aber der Reihe nach.

Inhalt, Aufbau und Zweck

Ein gutes Status-Slide ist einfach und pragmatisch gehalten. Auf einen Blick sollten folgende Informationen erkennbar sein:

  • Projektname, Auftraggeber und Verantwortlicher
  • Gesamtstatus, Status der Timeline, des Scope und des Budgets
  • Projekttyp, falls anwendbar
  • Aktivitäten seit dem letzten Bericht
  • Kommerzielle Übersicht
  • Weitere Erläuterungen zum Status
  • Übersicht über die signifikantesten Risiken
  • Nächste Schritte
Beispiel eines Projektstatus-Slides
Beispiel eines Projektstatus-Slides

Ziel sollte es sein, einem Außenstehenden oder Stakeholdern, die sich nicht täglich mit dem Projekt befassen und daher in den Details nicht oder zumindest nicht tief involviert sind, innerhalb weniger Minuten einen guten und realistischen Eindruck der Gesamtsituation einschließlich der größten Risiken zu vermitteln.

Das Status-Slide ist kein Ersatz für eine RAID-Matrix, einen Risiko- oder Incident-Tracker, einen Business Case, Projektplan, ein Backlog oder dergleichen.

Anwendung und Einbindung in ein Delivery Risk Management

Das Status-Slide sollte jederzeit für relevante Stakeholder verfügbar sein. Es sollte daher an einem zentralen Ort, beispielsweise einem SharePoint, G-Drive-Ordner oder ähnlichem, aufzufinden sein. Es mag Sinn ergeben, hier mit zwei Versionen zu arbeiten, insbesondere dann, wenn man als Projektleiter auf Dienstleisterseite arbeitet. Selbsterklärend, dass nicht alle intern besprochenen Punkte, finanzielle Aspekte und identifizierte Risiken, die möglicherweise mit dem Kunden selbst in Verbindung stehen, mit letzterem geteilt werden sollten.

Innerhalb eines internen Betriebsmodells mit seinen verschiedenen Eskalationsstufen sollte das Status-Slide für jeden zugänglich sein, von der Geschäftsleitung abwärts. Transparenz hilft, Risiken und Issues rechtzeitig zu erkennen und gemeinsam mit den benötigten Rollen gegenzusteuern.

Das ganze Thema Risikomanagement soll in einem gesonderten Beitrag näher beleuchtet werden. Hierzu nur so viel: Die regelmäßige, idealerweise wöchentliche, kurze Vorstellung des Status mag der Ausgangspunkt zur Einstufung des Projektes hinsichtlich des Risikos für die Gesamtorganisation sein. Basierend auf einer kurzen, maximal 10-minütigen Präsentation durch den Projektleiter sollte entschieden werden, ob es Sinn ergibt, hier in einem gesonderten Meeting tiefer einzusteigen.

Dieses Meeting kann beispielsweise ein internes Steering Committee sein, bei dem dann neben dem Status auch das Risiko- und Issues-Log sowie die kommerzielle Situation tiefer analysiert wird. Das weitere Vorgehen zu den wichtigsten Risiken wird dann mittels ROAM (Resolve, Own, Accept, Mitigate) abgestimmt. Dabei mag es durchaus auch opportun sein, das Projekt weiter zu eskalieren, auch von Dienstleisterseite. Es ist wichtig, diese Möglichkeit und die genaue Vorgehensweise eng mit Entscheidern auf Kundenseite vorab abzustimmen. Idealerweise wurde dies bereits in der initialen Phase des Projektes als Teil der vereinbarten Methodik bzw. des Betriebsmodells abgestimmt. Allen Beteiligten muss klar sein, dass eine Eskalation nicht zwingend etwas Negatives oder Wertendes ist, sondern ein weiteres Werkzeug im gemeinsamen Werkzeugkoffer, um im Bedarfsfall wichtige Entscheidungen herbeizuführen.

Fazit und Empfehlungen

Die Liste von Best Practices im Umgang mit Status-Slides könnte hier endlos fortgesetzt werden. Wichtig ist, dass dieses simple Artefakt häufig unterschätzt und ebenso häufig nicht geliebt ist. Dabei ist der Aufwand verhältnismäßig gering, selbst wenn man einmal pro Woche aktualisiert – gerne auch mit KI-Unterstützung. Hier ist Vorsicht geboten, falls sensible Kundendaten von der KI verarbeitet werden sollen. Aber prinzipiell mit oder ohne KI kein unzumutbarer Mehraufwand.

In Relation dazu ist der Effekt groß:

  • Der Projektverantwortliche wird alleine dadurch gezwungen, sich mindestens 30 Minuten intensive Gedanken zum aktuellen Status, möglichen Problemen, Risiken sowie dem finanziellen Status zu machen. Man ist immer wieder überrascht, wie sehr dies hilft.
  • Der Status ist transparent, und Transparenz schafft Vertrauen bei allen Beteiligten.
  • Durch die Abstimmung mit internen und externen Stakeholdern wird sichergestellt, dass alle wichtigen Personen und Rollen denselben Informationsstand und dasselbe Verständnis der Situation haben. Die Wahrscheinlichkeit von Missverständnissen durch fehlende Kommunikation wird dadurch signifikant verringert.
  • Die Dokumentation des jeweiligen Status zu unterschiedlichen Zeitpunkten aus Sicht des PMs kann sich im Nachgang oder in kritischen Phasen des Projektes als unschätzbarer Mehrwert erweisen, speziell dann, wenn klar ersichtlich ist, dass der Status mit allen Beteiligten abgestimmt war.

Damit ist der Status immer noch, wie erwähnt, kein Ersatz für weitere wichtige Artefakte wie RAID, Issues-Tracker, Projektplan usw. Aber es ist ein wichtiges, verbindendes Element – nicht nur zwischen Artefakten und Tools, sondern auch zwischen Menschen.