Zusammenfassung: Der Blogbeitrag erläutert, warum ein effektives internes und externes Projekt-Reporting in SAP-Projekten entscheidend ist und gibt Empfehlungen zur Erstellung und Überwachung von Reports, um den Projekterfolg sicherzustellen.

 

Mit „internem Projektreporting“ bezeichnen wir das Reporting, das innerhalb des Projektteams stattfindet. Also z.B. die Reports, die Projekt-Teil-Teams erstellen und an die Projektleitung oder das PMO weitergeben. Als „externes Projektreporting“ bezechnen wir das Reporting des Gesamtprojekts, welches die Projektleitung an Projekt Stakeholder oder auch an Kontrollinstanzen wie das Steering Committee weitergibt.

 

Externes Reporting: Hat da jemand was zu verbergen? 

Es ist hierbei insbesondere wichtig, dass man sich über den Zweck des jeweiligen Reportings bewusst ist. So hat das externe Projektreporting einen ganz wesentlichen Beitrag zu leisten zum positiven Image des Projektes. D.h. all das, was aus dem Projekt an externe Stellen reportet und kommuniziert wird, sollte konsistent sein. Wenn ein Projekt immer nur auf Nachfrage Auskunft über einen Status, über Probleme, Risiken oder ähnliches gibt, kommt es sehr schnell zu einem komischen Gefühl bei allen beiteiligten Externen des Projektes, weil sie glauben, man habe im Projekt etwas zu verbergen.

 

Proaktive Kommunikation nach außen

Viel besser und vertrauensbildender ist es, proaktiv von der Projektleitung oder aus dem Projekt heraus zu berichten. Dazu gehört es auch über Probleme zu berichten und Risiken zu reporten und das, was man unternommen hat, um die Risiken in den Griff zu bekommen (und sie eben nicht zum Problem werden zu lassen). Dies gilt auch für das offizielle, nach außen gerichtete Reporting, wie den Bericht an das Steering Committee. In aller Klarheit: Es sollte proaktiv über Riskien und Probleme gesprochen werden. Und es sollte nicht versucht werden, Probleme oder Risiken kleinzureden oder einfach NICHT zu berichten.

 

Projekt-Reporting mit Augenmaß

Und natürlich muss das Reporting mit Augenmaß erfolgen. Dabei ist es wichtig, dass das Projekt in der Organisation als transparent erlebt wird – besonders durch alle Stakeholder des Projektes, sodass hier keiner das Gefühl haben muss, er sei von Informationen ausgeschlossen oder er würde nur auf Nachfrage informiert werden.

 

Internes Reporting: Eine Frage der Orientierung im Team

Das interne Projektreporting sollte hauptsächlich dem Zweck dienen, immer wieder den eigenen Standort zu bestimmen. Damit ist es weniger ein Reporting des aktuellen Status eines Teil-Teams an die Projektleitung, als vielmehr eine Standortbestimmung in dem jeweilgen Teil-Team. Wichtig ist, dass dies alle Beteiligten mit einschließt, um eine einheitliche Sicht auf den aktuellen Stand der Arbeiten zu haben.

Meiner Erfahrung nach geht man da einfach so vor, dass man je nach Berichtsperiode – meistens ist diese wöchentlich oder auch zwei-wöchentlich – die folgenden Fragen stellt:
1. Was sollte in dieser Projektberichtsperiode erreicht werden; Welche Ergebnisse sollten erzielt werden? (Nicht so sehr: Was sollte getan werden?)

Und in dem Zusammenhang die Antworten direkt in die folgenden Kategorien einordnet:

a) Welche deser Ergebnisse, die ich in der Berichtsperiode erzielen wollte, habe ich erreicht?
b) Welche deser Ergebnisse, die ich in der Berichtsperiode erzielen wollte, habe ich NICHT erreicht?

Bei den nicht erreichten Ergebnissen (1.b)) sind dann jeweils die folgenden Fragen zu beantworten:

1.b)-1: Was tue ich, um diese Planungsabweichung wieder in den Griff zu bekommen?
1.b)-2: Hat das insgesamt Auswirkungen auf die Gesamtplanung meines Teil-Projektes?

Die nächste Frage ist:
2. Welche Ergebnisse sind ich in der folgenden Berichtspersiode zu erzielen?

 

Systematisierung durch Wiedervorlage

Wenn ich diese Fragen einmal in einem Berichtszyklus gestellt habe, kann ich jeweils aus der letzten Berichtsperiode mir einfach nur die Ergebnisse und die, die für die künftige Periode geplant waren, herausnehmen, und diese aufteilen in die Ergebnisse, die ich erreicht habe oder nicht erreicht habe. D.h. ich erstelle damit in ein sehr einaches Wiedervorlagesystem, durch das ich immer die Fragen vor Augen habe:

  • Was will ich als nächstes tun?
  • Was habe ich von dem, was ich tun wollte, erledigt?
  • Was habe ich davon nicht erledigt?
  • Und was hat das für Auswirkungen, dass ich etwas nicht erledigt habe?

Aus meiner Sicht hat sich auch sehr bewährt, dass insbesondere an die externen Beteiligten (in der Regel die externen Berater) jedes Mal zusätzlich die Frage gestellt wird:
Wie groß ist der verbleibende Restaufwand?

 

Gleichzeitig das Budget im Auge behalten

Wenn man diese Frage in jeder Berichtsperiode erneut stellt, müsste sich ja ein Abbau des Gesamtbudgets ergeben – je nachdem, was man erreicht hat. Reflektiert man, was man NICHT erreicht hat, wird man schnell feststellen, ob die Arbeiten auch aus Budget-Sicht wie geplant vorankommen. Oder, ob sich langsam ein immer größeres Budget-Reservoire aufbaut (aufgrund der Arbeiten, die nicht erledigt wurden). Dies hat i.d.R. seine Ursachen darin hat, dass man zu optimistisch geplant hat.

 

Auch Risiken und abwehrende Maßnahmen gehören zum Statusreport

Zusätzlich sollten solche Statusreports auch ein Kapitel enthalten, in dem proaktiv nach neuen Risiken gefragt wird, und auch nach entsprechenden Maßnahmen, die aus Sicht des Teams ergriffen werden sollten, um dieses Risiko abzuwenden – also sog. Mitigation Actions. Die so reporteten neuen Risiken können vom PMO in das Risk-Log überführt und entsprechend von der Projektleitung bewertet und konsolidiert werden.

 

Produktivität durch Anwesenheitsplanung

Weiterhin sollte man bei der Festlegung der Tätigkeiten der künftigen Berichtsperiode prüfen, ob die Anwesenheitsplanung aller Beteiligten dazu geeignet ist, um diese auch abzuarbeiten. Wenn man dies gewährleistet, kommt man im Team in ein sehr produktives Miteinander und eine gute Abstimmung. Der Erfolg dieser Vorgehensweise zeigt sich z.B. darin, wenn man ein beliebiges Teammitglied nach dem Status fragt, eine Aussage bekommt, die i.d.R. der des Gesamtteams entspricht. Dies ganz allein, weil es eben einen regelmäßigen Abgleich über diesen Status gibt.

Es kann auch sein, dass ein solcher Abgleich nicht in einem Teammeeting gemacht wird, sondern nur von entsprechenden Teilprojektleitern erstellt wird und mit dem Team abestimmt wird. Das ist sicherlich auch der effektivere Weg.

 

Also, ein Statusbericht sollte bestehen aus:
  • Was wollte ich in der Berichtsperiode tun?
  • Was von dem habe ich erledigt?
  • Was habe ich nicht erledigt?
  • Was will ich in der künftigen Berichtsperiode tun?
Darüber hinaus:
  • Wie ist der geschätzte Restaufwand meiner beteiligten externen Berater?
  • Was sind neue Risikien und Mitigation Actions?
Und ggfs. auch:
  • Was sind Anforderungen oder Integrationspunkte an andere Teams?

Falls das denn soweit fomalisiert werden muss, das kann man i.d.R. aber auch kommunikativ lösen.

Dieses Berichtswesen hat sich für mich in allen Projekten sehr bewährt. Insbesondere deshalb, weil so regelmäßig jedes Team angehalten ist, den eigenen Status und den Stand der Arbeiten und damit das Vorankommen und auch die Validität der eigenen Planung zu verifizieren, kritisch zu hinterfragen und ggfs. anzufassen.

(Ein Beispiel findet sich hier: YYYY-WW_Status_Template.pdf. Den internen Statusbericht können Sie über diesen Link im Digistore24 erwerben und herunterladen.)

 

Berichtswesen des Gesamtprojektes

Das gleiche gilt aus meiner Sicht auch für das Gesamtprojekt. D.h. die Projektleitung sollte vorleben, indem sie in dem gleichen Berichtsrhythmus den gleichen Report erstellt – und zwar aus Gesamtprojektsicht:

  • Welche Ergebnsse wurden erreicht?
  • Welche Ergebnisse wurden nicht erreicht?
  • Und welche Ergebnisse wollen wir in der nächsten Berichtsperiose erreichen?

Ein Teil dieser Fragestellung kann für das Gesamtprojekt auch in das externe Berichtswesen übernommen werden. Es kann durchaus die gleiche Struktur haben. Dies kann man durch Ampelfunktionen (oder Ähnliches) anreichern mit Fragestellungen in dieser Richtung:

  • Wo sind wir qualitätiv?
  • Wie sind wir zeitlich unterwegs?
  • Und wie sind wir kostentechnisch unterwegs?

Das sind die Bestandteile des magischen Dreiecks. Sie bilden im Grunde genommen in jedem Projekt den Spannungsbogen: Zeit, Kosten und Qualität.

(Ein Beispiel findet sich hier: TEMPLATE_Status MM-YYYY.pdf. Den Statusbericht für das Gesamtprojekt können Sie über diesen Link als MS Powerpoint-Vorlage im Digistore24 erwerben und  herunterladen.)

 

Und natürlich sollte auch periodisch der Budgetverbrauch und ein Ausblick reportet werden.

Dazu gehören die folgenden Zahlen:

Planned: Geplantes Projektbudget für den Berichtszeitraum (i.d.R. Jahr, Projektphase oder Gesamtprojekt)

Actual-to-Date: Aktuell aufgelaufene Ist-Kosten (als Rechnungseingang und/Zeiterfassungen)

Estimate-to-Complete: Restschätzung der künftig noch anfallenden Aufwände in dem Berichtszeitraum

Total-to-Complete: Voraussichtlicher Gesamtaufwand: Summe aus Actual-to-Date und Estimate-to-Complete

Estimated Deviation: Voraussichtliche Budgetabweichung: Total-to-Complete – Planned

Actual remaining Budget: Aktuelles Restbudget: Planned – Actual-to-Date

 

Plan Budget Reporting

Budget Form Projekt-Reporting

 

Hier finden Sie eine Übersicht unserer Tools, die Sie im Digistore24 erwerben, herunterladen und für Ihr Projekt nutzen können.