Projektstatusbericht: Das gehört alles rein!

Mit diesem Beitrag möchte ich das Thema Projektreporting ein wenig vertiefen.

Ein wesentlicher Teil des Projekt-Reportings ist der Projektstatusbericht. Un beim Projektstatusbericht sind mir einige Dinge besonders wichtig: Er sollte nämlich standardisiert sein, also immer wieder die gleichen Inhalte haben.

Aber was gehört denn nun so alles in einen Projektstatusbericht? Was kann da drin enthalten sein? Genau darum geht es in diesem Beitrag.

Du wirst dieses Mal erfahren:

• Was meine ich konkret mit Projektstatusbericht,
• Was gehört genau in so einen Projektstatusbericht hinein, also welche Elemente sollte er enthalten
• Wie kannst du das effizient umsetzen

Was meine ich mit Projektstatusbericht

Dann starten wir einmal damit, noch etwas genauer zu beleuchten, was ich eigentlich mit Projektstatusbericht – zumindest hier in diesem Beitrag – meine: Es geht mir dabei weniger um die, ja, zusätzliche Präsentation, die weitere Informationen zum Projekt enthält, und die du mit Sicherheit in deinen Lenkungskreismeetings oder in deinen Berichtsmeetings dabei hast, sondern mir geht es heute in dieser Episode vielmehr um den standardisierten Bericht, also das, in Anführungszeichen, Formblatt, in dem ich immer wieder kurz und bündig – das ist mir wichtig – Informationen eintragen kann, damit sie dann einfach verfügbar und schnell verwertbar, verarbeitbar sind.

Die Vorteile eines Projektstatusberichtes

Ich mag vielleicht noch einmal ganz kurz auf die wesentlichen Vorteile eingehen und auch erinnern.

Ein standardisierter Projektstatusbericht bringt den Leser beziehungsweise die Lenkungskreismitglieder in die Lage, schnell und unkompliziert an die wesentlichen Informationen eines Projektes zu kommen. Das sollte Trends und Verläufe aufzeigen. Wie das geschieht, erkläre ich gleich noch einmal.

Und er sollte Vergleichbarkeit zulassen. Und zwar innerhalb des Projektes, also von Bericht zu Bericht, also von Berichtszeitpunkt zu Berichtszeitpunkt Vergleichbarkeit herzustellen, um dann abzuleiten: Wie hat sich das Projekt entwickelt? Und natürlich auch Vergleichbarkeit zwischen verschiedenen Projekten. Dieses Projekt, hat das einen besseren Stand als ein anderes Projekt?

Und am Ende sollte er durch den Projektleiter schnell auszufüllen und zu aktualisieren sein, weil natürlich der Aufwand für das Reporting sich in möglichst kleinen Grenzen halten sollte.

Du darfst also deinen Projektstatusbericht zunächst einmal überprüfen, ob er diese Projekteigenschaften unterstützt.

Welche Elemente sollte ein Projektstatusbericht enthalten

Gut. Dann kommen wir doch einmal dazu, uns zu überlegen, welche Elemente, welche Inhalte denn in einen standardisierten Projektstatusbericht, also in dieses Formblatt, so gehören könnten. Ich mag für dich eine kleine Liste aufmachen. Und wie immer: Die ist natürlich nicht unbedingt vollständig. Falls du da gerne weitere Informationen in deinem Projektstatusbericht drin hast, ist das völlig okay. Und auch, falls du sagst „Dieser Bereich oder jenes Element, der interessiert in unserem Unternehmen nicht so sehr.“ oder „Wir haben gar keine Informationen dazu.“, kann auch sein, dann macht das natürlich keinen Sinn, das in deinem Projektstatusbericht für dein Projekt einzubauen.

Für mich ist diese Liste das, was ich sehr oft, ja, einmal so im ersten Schritt mit meinen Kunden aufsetze und diskutiere, um es dann eben in weiteren Schritten zu verfeinern. Okay, was gehört also alles drauf?

1. Projektstammdaten

Das ist für mich ein absolutes Muss: Stammdaten, Projektstammdaten, Projektbeschreibung, Zielsetzung. Also, da gehört drauf der Projektname. Die Projektnummer. Wer ist der Projektleiter? Unter Umständen: Zu welcher Projektart, -gruppe oder -kategorie gehört das Projekt? Das ist ja stark abhängig von deinem Unternehmen, welche Projektarten ihr da habt oder wie ihr Projekte kategorisiert.

Und natürlich gehört auch eine kurze Skizzierung des Projektinhaltes und des Projektzieles hinzu, damit sich jemand, der den Projektstatusbericht liest, ja, so einen kleinen Überblick schaffen kann: Was soll denn da eigentlich geschaffen werden? Was ist das Ziel des Projektes? Ich denke, es ist logisch, dass diese Stammdaten auf deinen Bericht sollten. Und es erlaubt eben auch ganz einfach die Klassifikation und auch die Zuordnung des Projektes im Unternehmen.

2. Termine

Das zweite Elemente, das in den Projektstatusbericht darf und aus meiner Sicht auch nicht wirklich fehlen darf, sind Termine.

Und üblicherweise reduzieren wir Termine auf Meilensteine. Das heißt, wir fokussieren uns da zum einen in der Regel auf die Meilensteine, die wir aus dem Produktentstehungsprozess, ja, vorgegeben haben, da können natürlich aber auch weitere projektspezifische Meilensteine hinzugefügt und sozusagen ergänzt werden.

Meilensteine: Es hat sich bewährt, Meilensteine in einer Tabelle darzustellen. Und zwar hat jeder Meilenstein drei, ja, Ausprägungen oder kann drei Ausprägungen haben, nämlich Soll, Plan und Ist.

So, was steckt denn nun dahinter?

Also, Soll ist der Soll-Termin, ist der Termin, wie er in der ursprünglichen Planung einmal vorgesehen war. Also der Meilensteintermin, wie er bei der ersten Planung – und das ist die, mit der dieses Projekt auch freigegeben wurde, also die Planung zur Projektfreigabe – wie es damals vorgesehen war.

Dann gibt es den Plantermin. Das ist dein aktueller Planungsstand, der sich natürlich direkt aus deinem Terminplan ableitet, in dem du sehen kannst „Ich plane den Meilenstein M3 Konzeptfreigabe am soundsovielten Oktober.“

Und der dritte Horizont, den wir bei den Terminen in der Tabelle haben, ist der Ist-Termin. Und das ist der tatsächlich erreichte Termin für – ganz wichtig – bereits abgeschlossene Meilensteine.

Das heißt: Zu Beginn eines Projektes haben deine Meilensteine alle einen Soll-Termin, das sind nämlich die Termine, die sich quasi ableiten oder die vorgestellt wurden bei der Projektfreigabe, und sie haben einen Plantermin, und der ist am Anfang natürlich identisch mit dem Soll-Termin. Wenn du dann nun in deinem Projekt voranschreitest und sich Änderungen ergeben, ändert sich natürlich der Plantermin. Weil Meilensteine werden einmal früher geplant, einmal später, und das hältst du in deinem Plantermin nach.

Und so kannst du einen Soll- und Plan-Vergleich machen, in dem du immer siehst: Wie hat sich denn dein Projekt gegenüber deiner ursprünglichen Planung verändert? Und sobald du einen Meilenstein erreicht hast, hältst du diesen erreichten Termin dann als Ist-Termin fest. Es gibt eine weitere schöne Möglichkeit, diese Termine darzustellen, und das ist mit einer Meilensteintrendanalyse.

Eine Meilensteintrendanalyse – oder MTA – ist eine spezielle Darstellung der Meilensteine, in der erkennbar ist, wie sich eben die Meilensteintermine im Laufe des Projektes verändern. Und manchmal gehen die nach vorne und manchmal gehen die nach hinten, werden also später.

Wie eine Meilensteintrendanalyse funktioniert und was man daraus ablesen kann und was eher weniger, das erkläre ich dir in einer separaten Episode, habe ich schon eingeplant.

3. Projektkosten

Das dritte Element, das aus meiner Sicht in keinem Projektstatusbericht fehlen sollte, sind Projektkosten. Also was sind die Kosten für dein Projekt?

Und auch hier hat es sich eben bewährt, zu unterscheiden zwischen Soll, Plan und Ist.

Noch einmal: Soll ist hier die ursprüngliche Planung, also die Planung, die geplanten Kosten zu dem Zeitpunkt, als du das Projekt freigegeben bekommen hast. Wir nennen das gerne einmal Projektbudget. Das ist das, was du am Anfang an Projektbudget bekommen hast.

Auch hier wird sich natürlich dein Projekt verändern und es gibt eben den Horizontplan, und das ist dein aktueller Planungsstand. Was planst du denn heute, für das gesamte Projekt an Geld auszugeben? Und das setzt sich natürlich zusammen aus dem, was du bereits ausgegeben hast, das ist Ist, also die bisher aufgelaufenen Kosten, plus dem Restplan, also der Kosten, die du noch erwartest.

Es hat sich bewährt, neben diesen Gesamtprojektkosten auch noch eine Tabelle mit etwas detaillierteren Kosten darzustellen. Das heißt, hier brechen wir also diese Gesamtprojektkosten, das Gesamtbudget, in seine Teilbereiche herunter. Das können zum Beispiel sein Personalkosten, Sachkosten, Beratungskosten, Reisekosten und so weiter und so fort. Welche Bereiche hier Sinn machen und welche du auch tatsächlich als Information verfügbar hast, also welche Kosten du in der Lage bist, heraus zu ermitteln, das hängt eben wieder sehr stark von deinem Unternehmen ab. Wie werden hier Kosten geplant und auch verfolgt?

Ja, und jetzt haben wir quasi diese tabellarische Darstellung der Kosten. Und natürlich kannst du das Ganze auch noch schön im Projektstatusbericht als Diagramm darstellen, quasi als Kostenverlauf über der Zeit.

Auch hier wirst du dann am Ende des Tages drei Kurven haben, nämlich einen Soll-Verlauf, wie war es denn ursprünglich geplant, deine Kosten über der Zeit anschwellen lassen? Wie ist der aktuelle Plan? Und wie sind die bereits aufgelaufenen Ist-Kosten?

4. Ressourcensituation

Das vierte Element, das man sehr oft in Projektstatusberichten findet, nicht aber immer, ist die aktuelle Ressourcensituation.

Und du kannst dir vorstellen: Auch hier können wir wieder unterscheiden zwischen Soll, Plan und Ist. Also Soll ist wieder die ursprüngliche Planung: Wie viele Stunden? Wie viele Stunden waren denn ursprünglich einmal eingeplant und freigegeben? Dann haben wir den zweiten Horizont, Plan. Was ist der aktuelle Planungsstand? Das ist auch hier wieder die bereits abgeleisteten Stunden, also der Ist, die verbuchten Stunden plus der Restplan. Und ja, natürlich wieder die bereits aufgelaufenen Stunden.

Und auch hier wieder, analog zu den Projektkosten, macht es Sinn die Gesamtressourcenstunden, die gesamten geplanten Stunden, vielleicht etwas detaillierter darzustellen. Und da macht es natürlich Sinn, das in einzelne Teile herunter zu brechen. Das können Abteilungen sein, Bereiche, wie auch immer.

Hier bekommt man dann eine Information, wie viele der zugesagten Ressourcen tatsächlich auch zur Verfügung standen.

Ja, das sind nun so die wesentlichen Elemente im Projektstatusbericht, die mit Zahlen hinterlegt sind. Die sind wir jetzt eben so ein bisschen durchgegangen. Und jetzt lass uns einmal zu den Elementen kommen, die mehr mit einer – ja, wie soll ich sagen? – qualitativen Bewertung oder einer Einschätzung durch den Projektleiter und das Projektteam zu tun haben.

5. Letzte Schritte und nächste Schritte

Ein Punkt, und das ist das fünfte Element, das ich dir gerne vorstellen möchte, das ich sehr gerne in Projektstatusberichten einsetze, das sind die letzten Schritte zusammen mit den Ergebnissen und die nächsten Schritte.

Also eine kleine Tabelle, eine kleine Übersicht über alle bisher in der letzten Berichtsperiode gelaufenen Aktivitäten und Arbeiten, die im Projekt stattgefunden haben. Also was haben wir zuletzt gemacht und mit welchem Ergebnis? Und was machen wir als nächstes?

So bekommst du einen guten Überblick über die aktuelle Arbeitssituation im Projekt. Woran arbeitet das Projektteam?

6. Highlights und Lowlights

Was sich ebenfalls bewährt hat, ist der sechste Punkt, das sind Highlights und Lowlights. Dieser Punkt schließt sich sehr oft an die letzten Schritte und die nächsten Schritte an. Und ja, manchmal gibt es auch hier Überschneidungen, finde ich aber nicht wirklich schlimm.

Bei den Highlights werden eben Erfolge berichtet, also Dinge, die gut funktioniert haben, Dinge, die uns vorangebracht haben, Dinge, die sehr positiv waren.

Und bei den Lowlights eben genau das Gegenteil: Dinge, die eben Misserfolge waren, die nicht wie geplant stattgefunden haben oder bei denen vielleicht auch das Ergebnis nicht wie erwartet gewesen ist. Und jetzt erkennst du: Das hängt natürlich sehr oft mit den letzten Schritten und deren Ergebnissen zusammen.

Also von daher: Ja, es gibt gelegentlich einmal eine Überschneidung, denke ich ist aber kein großes Problem.

7. Risiken

Der siebte Punkt, das siebte Element von Projektstatusberichten, das ich dir gerne ans Herz legen möchte, sind die Risiken.

Und ja, das hängt da oftmals ein bisschen davon ab, wie viel Platz du auch im Projektstatusbericht hast. Oftmals nimmt man die Top-drei Risiken oder die Top-fünf Risiken. Und hier kannst du dich als Projektleiter direkt aus deiner Risikoanalyse bedienen. Und das macht es natürlich sehr leicht für uns als Projektleiter.

Und zum anderen stellen wir natürlich als Auftraggeber – ich habe jetzt einmal kurz die Sicht gewechselt – sicher, dass sich jedes Projekt auch Gedanken über die Risiken macht. Und wenn es schon keine richtige groß angelegte, in Anführungszeichen, Risikoanalyse ist, dann sind es wenigstens die drei bis fünf Risiken, über die das Projektteam einmal nachgedacht haben sollte. Und da sind drei bis fünf besser als gar nichts.

Und zur Auflistung der Risiken kann man natürlich auch deren Bewertung mit angeben. Du erinnerst dich: Eintrittswahrscheinlichkeit und Auswirkungen bewertet. Ist aber aus meiner Sicht kein Muss.

8. Entscheidungsbedarfe

Ein weiteres Element, das ich gerne in meinen Projektstatusberichten habe, und das aus meiner Sicht da wirklich dort auch hingehört, sind Entscheidungsbedarfe. Sollte irgendwie nicht im Projektstatusbericht fehlen. Also ein Bereich, in dem du Entscheidungsbedarfe auflistest.

Im Statusbericht darf dann zum einen ein kurzes Stichwort sein, damit klar ist, um was es bei diesem Entscheidungsbedarf geht, um was es sich da handelt, und zum anderen vielleicht auch noch einmal so ein Platz für eine kurze Beschreibung mit zwei bis drei Sätzen. Und logisch, das ist uns klar: Das kann nicht ausreichen, um eine Entscheidung einzuholen. Wir brauchen in den meisten Fällen – vor allem, wenn wir über technische Projekte reden – brauchen wir mehr Platz, wir brauchen mehr Informationen, wir brauchen Diagramme, wir brauchen Messergebnisse und so weiter. Und das kannst du dann in einer zusätzlichen Präsentation zur Verfügung stellen.

Also Dinge, die dort ganz genau beschrieben werden sollen. Wie man so eine Entscheidungsvorlage macht und wie man solche Entscheidungen herbeiführt, das erkläre ich dir demnächst auch noch einmal in einer anderen Episode.

So, und nun haben wir eigentlich auch schon die wesentlichen Elemente eines Projektstatusberichts zusammen. Ich wiederhole sie für dich noch einmal:

1. Stammdaten mit Projektbeschreibung, Zielsetzung.
2. Terminen
3. Projektkosten
4. Ressourcensituation
5. letzten Schritte und die nächsten Schritte
6. Highlights und Lowlights
7. Risiken
8. Entscheidungsbedarfe

Mit diesen Elementen haben wir nun einen schnellen und unkomplizierten Überblick über den Status eines Projektes und wir haben eine Idee, wie es sich wohl weiterentwickeln wird.

Der RYG-Status

Ja, und falls du jetzt das Ganze noch weiter zusammenfassen, weiter kondensieren, noch weiter komprimieren möchtest, dann kannst du noch zusätzlich einen RYG-Status einführen.

Ja, RYG – oder red, yellow, green – ist ein Begriff, der sich im Projektmanagement eingebürgert hat. R steht für red, rot, also ein roter Status. Y steht für yellow, also gelb, ein gelber Status. Und G steht für green, grün, also einen grünen Status.

Kurz zusammengefasst: Bei Rot ist es kritisch, bei Grün ist alles okay, und bei Gelb liegen wir irgendwo dazwischen.

Hört sich zunächst einfach an und logisch, hat aber die eine oder andere Tücke. Auch dazu mache ich in Kürze noch einmal eine extra Episode, um dir das so ein bisschen zu erklären, weil ich glaube, da schlummert wirklich eine Falle.

Du kannst nun also für einige Elemente im Projektstatusbericht diesen red-yellow-green Status einführen und durch den Projektleiter bewerten lassen. Ich denke, es macht in der Regel für die Elemente Termine, Ressourcen, Kosten, und manchmal auch Qualität, Sinn. Oftmals gibt es dann auch noch einen red-yellow-green Status für die Inhalte. Also inwieweit erreichen wir die geforderten Funktionen und Leistungsdaten? Für die anderen Elemente macht es meiner Erfahrung nicht so wirklich Sinn, so einen Status zu haben und den auch zu bewerten.

Ja, und wenn du nun möchtest, dann kannst du noch den Gesamtstatus des Projektes aus diesen Einzelstatus, aus den einzelnen Bewertungen heraus ermitteln, filtern, wenn du so möchtest. Und das bringt dann das Projekt auf den Punkt – vereinfacht das Ganze aber natürlich auch schon sehr. Solltest du bitte drüber nachdenken.

Und wie gesagt, ich habe da schon eine extra Episode in der Planung, in der ich dir hier die eine oder andere Falle etwas genauer erklären möchte und diesen RYG-Status etwas auseinandernehme.

So, dann haben wir sie schon, die Elemente des Projekt-Reportings. Haben wir sie schon zusammen.

Den Projektstatusbericht effizient umsetzen

Dann lass uns noch einmal kurz darüber nachdenken, wie du das Ganze vernünftig umsetzen kannst.

Du hast bestimmt schon gemerkt: Ohne Tool kommst du hier nicht richtig weiter. Du brauchst also ein Tool oder Systemunterstützung, um das Ganze vernünftig und mit geringem Aufwand umzusetzen.

Ohne Tool wird es schwierig

Ich glaube, grundsätzlich hast du drei verschiedene Möglichkeiten:

Du kannst den Projektstatusbericht ganz platt im Excel aufbauen und dort alles so gestalten, wie du es gerne möchtest. Ich habe einige Kunden, die mittlerweile dazu übergegangen sind, SharePoint-Lösungen zu entwickeln oder darauf zurückzugreifen, und dort eben die Inhalte abzubilden. Oder du besitzt vielleicht schon eine Projektmanagement Software-Lösung, und die hat in der Regel auch schon so einen Projektstatusbericht integriert. Manchmal heißt es dort auch Projekt Cockpit.

Falls du noch keinen Projektstatusbericht für deine Projekte besitzt, ist meine ehrliche Empfehlung, mit Microsoft Excel zu beginnen. Das hat den Vorteil, dass du schnell selbst Hand anlegen kannst, du kannst den Statusbericht nach deinen Wünschen aufbauen, dein eigenes Wording integrieren, und auch manchmal mit nur weniger Elementen starten. Du kannst es eben ganz so, wie es für dich am besten passt, aufbauen.

Falls du dann ein gutes und für dich funktionierendes Projekt-Reporting hast, von dem du sagst „Das ist stabil, so wollen wir das machen.“, dann darfst du das gerne in eine Projektmanagement Software übertragen lassen. Und dann hast du natürlich ein deutlich geringeres Risiko, immer wieder etwas ändern zu müssen, was natürlich zu erhöhten Kosten führt.

Und solange du noch in der Phase bist, in der du neue Erfahrungen sammelst und rumprobierst – bleib lieber im Excel. Ein weiterer Vorteil hat Excel: Ist nämlich nicht nur deutlich günstiger, es braucht auch nahezu keine Schulung. Denn alle Anwender, die mit dem Projektstatusbericht arbeiten sollten, die arbeiten eigentlich fast täglich mit Excel und wissen, wie es funktioniert.