Management-Zusammenfassung dieses Beitrags:
Über Berichte können Projekte überwacht und gesteuert werden. Das Erstellen und Präsentieren von Projektberichten gehört zu den wesentlichen Aufgaben des Projektmanagers und sollte zielgerichtet erfolgen.
In diesem Beitrag werden Berichte und das Berichtswesen in Projekten beschrieben.
Das Erstellen und Überprüfen von Berichten in Projekten ist ein wesentlicher Aufgabenschwerpunkt von Projektmanagern. Das Projektberichtswesen behandelt die Berichte in Projekten systematisch und ist ein Teil des allgemeinen Informations- und Kommunikationswesens in Projekten. Hierüber werden die Projektbeteiligten mit “passenden”, zur Entscheidungsfindung benötigten Informationen versorgt.
Sind die “richtigen” Berichte in Projekten vorhanden, so können Projekte hierüber überwacht und gesteuert werden.
Berichte und das Berichtswesen werden hier als ein Teilgebiet des → Projektmanagements verstanden.
1. Einleitung und Grundlagen
Berichte in Projekten dienen zum Erfassen und zur Weitergabe von Informationen in standardisierten Formaten. Sie werden im Allgemeinen schriftlich verfasst. Wie die jeweiligen Projektberichte aussehen, wer sie erstellt und wie mit ihnen umgegangen werden soll, regelt das Projektberichtswesen, welches wiederum Teil eines übergreifenden Informations- und Berichtswesen ist. Zudem wird das Projektberichtswesen im → Projektmanagement und der dazugehörigen Literatur häufig dem → Projektcontrolling zugeordnet (Abbildung 1.1).
Abbildung 1.1: Einordnung des Berichtswesens in das Projektmanagement
1.1 Definitionen
In der DIN 69901–5:2009 /DIN16/ wird das Informations- und Berichtswesen (engl. Information and Reporting System) recht allgemein definiert:
“Gesamtheit der Einrichtungen und Regeln zur zielgruppenorientierten Information und Berichterstattung – abgestimmt auf die Erfordernisse der Dokumentation.”
Generell können Projekte über Berichte gesteuert werden, indem in jeder Situation ein passender Bericht erstellt oder gelesen wird.
1.2 Wozu ein Projektberichtswesen?
Das Projektberichtswesen …
- stellt sicher, dass alle Projektbeteiligten jederzeit auf die wesentlichen Informationen des Projekts zugreifen können.
- benennt die (notwendigen) Berichte und die (möglichen) Empfänger im Berichtsplan.
- “dient als Grundlage für Kontroll- und Steuerungsmaßnahmen und ist hauptsächlich ergebnisbezogen.” /Jenny19/
- ist “verwandt” mit dem Kommunikations- und Informationswesen sowie dem → Stakeholdermanagement.
In Projekten werden typischerweise die Entscheidungsgremien (im Allgemeinen Lenkungsausschüsse) mittels Berichten auf einen Stand gebracht, der es ihnen erlaubt, Entscheidungen zu fällen.
In den gängigen Standardwerken zum Projektmanagement findet man etwa 10 bis 20 Berichte für das Projektmanagement. In der Praxis kommen je nach Projektgröße unterschiedlich viele Berichte zum Einsatz. Daher ist es sinnvoll, schon vor → Projektstart zu wissen, welche Berichte wann und wie eingesetzt werden (sollen). Hierzu kann einen “Berichtsinventur” durchgeführt werden, die alle Berichte nach einem vorgegebenen Schema erfasst.
1.3 Berichtsarten
Die Projektberichte können in drei Arten unterteilt werden (Abbildung 1.2):
- Zeitorientierte Berichte: Diese werden zu einem bestimmten → Zeitpunkt (z.B. am Monatsende) erstellt und verteilt. Alle Statusberichte sind zeitorientiert
- Ergebnisorientierte Berichte: Die Erstellung erfolgt mit Erreichung eines Ergebnisses, wie beispielsweise das Ende einer Phase oder das Erreichen eines Meilensteins
- Ereignisorientierte Berichte: Wenn bestimmte nicht-planbare Ereignisse auftreten, so werden diese Berichte erstellt. Der Ausnahmebericht fällt in diese Kategorie
Abbildung 1.2: Berichtsarten
2. Der Berichtsplan
Der Berichtsplan gibt Auskunft darüber, welche Berichte im Projekt verwendet werden. Es werden alle Berichte mit den jeweiligen wesentlichen Merkmalen gelistet. Der Berichtsplan wird zu Beginn des Projekts erstellt und ist bindend für alle Projektbeteiligten über die gesamte Projektlaufzeit.
Das Erstellen von Berichten ist aufwendig, ebenso wie das Entwerfen von → Vorlagen für die einzelnen Berichte.
Daher sollte …
- die Anzahl der Berichte begrenzt werden.
- der Berichtsplan mit allen Vorlagen, wenn möglich, durch eine zentrale Stelle (das „→ Project Management Office – → PMO”) vorgegeben werden.
Bei einem “zu hohen” Erstellungsaufwand der Einzelberichte sollten diese zudem nicht mehr durch den → Projektmanager, sondern durch eine separate Stelle umgesetzt und bearbeitet werden. Dies ist typischerweise das “→ Project Office – PO” (seltener auch → Projektbüro genannt).
Der Berichtsplan beantwortet die Fragen (Abbildung 2.1):
- Was?
- Wer?
- An wen?
- Wann und wie oft?
- Wie / In welcher Form?
- Womit?
- Warum?
- Wohin?
Abbildung 2.1: Der Berichtsplan
Aus dem Berichtsplan wird pro Bericht eine Berichtsbeschreibung abgeleitet, die die Angaben zu jedem einzelnen Bericht weiter detailliert. Der eigentliche Berichtsinhalt sollte, falls notwendig, in einer Berichtsinhaltsbeschreibung genauestens benannt werden (Abbildung 2.2).
Abbildung 2.2: Vom Berichtsplan zur Berichtsinhaltsbeschreibung
Pro Bericht(styp) werden die einzelnen Parameter beschrieben — in Abbildung 2.3 ist dies für den Projektstatusbericht beispielhaft wiedergegeben.
Abbildung 2.3: Die Berichtsbeschreibung
Der Inhalt (grüner Pfeil) wird (später) weiter in der Berichtsinhaltsbeschreibung (die Basis der Vorlage ist – oranger Pfeil) detailliert.
2.1 Zum Berichtszeitpunkt und ‑zeitraum
In der Regel wird bei Projektstart festgelegt, wann an den → Lenkungsausschuss berichtet werden soll. Häufig werden dabei monatliche Abstände verwendet. Die einzelnen Zeitpunkte werden als Berichtszeitpunkte bezeichnet. Notiert man die Berichtszeitpunkte hintereinander und versieht sie mit den Meilensteinen für den Projektstart, so erhält man eine Darstellung für eine Berichtsabfolge (Abbildung 2.4).
Abbildung 2.4: Die Berichtszeitpunkte
Typische Berichtsdauern — bei einer Projektlaufzeit von …
- drei Monaten: Wöchentliche Berichte
- 12 Monaten: Monatliche Berichte
- 12 bis 36 Monate: Monatliche Berichte
- mehr als 36 Monaten: Quartalsberichte
Der zeitliche Abstand zwischen zwei Berichtszeitpunkten wird auch als Berichtszeitraum bezeichnet und in der Regel bei den jeweiligen Berichten mitnotiert (Abbildung 2.5).
Abbildung 2.5: Der Berichtszeitraum
3. Die wichtigsten Berichte in Projekten
Folgende zwei Berichte sind in jedem Projekt zu finden und werden hier beschrieben:
- Der Projektstatusbericht
- Der Projektabschlussbericht
3.1 Der Projektstatusbericht
Der Projektstatusbericht ist der wichtigste Bericht im Projekt. Er wird in einem regelmäßigen Abstand (üblicherweise 1*/Monat zum Monatsende) durch den Projektmanager erstellt und dann verteilt. Insbesondere die Mitglieder des Lenkungsausschusses erhalten hierüber Kenntnis über den Stand des Projekts und darüber, ob Entscheidungen von ihnen erforderlich sind, die dann in der korrespondierenden Lenkungsausschusssitzung getroffen werden sollten.
Die typische Verwendung des Projektstatusberichts ist in Abbildung 3.1 wiedergegeben: Der Projektmanager übergibt den Projektstatusbericht an den Lenkungsausschuss und bekommt ein Feedback.
Abbildung 3.1: Der Projektstatusbericht: Informationsfluss zwischen Lenkungsausschuss und Projektmanager
Nach DIN 69901–5:2009 /DIN16/ ist der Projektstatusbericht (auch Projektbericht; engl. Project Report, Project Status Report) ein “zusammenfassender Projektbericht über den aktuellen Stand im Projekt (über alle Teilbereiche)”.
Andere Bezeichnungen sind: Statusbericht, Projektfortschrittsbericht, Fortschrittsbericht, teilweise auch Meilensteinbericht.
Der Projektstatusbericht beantwortet folgende, grundsätzliche Fragen:
- Wo steht das Projekt? Was wurde seit dem letzten Statusbericht erreicht?
- Gibt es aktuelle Probleme?
- Sind Maßnahmen zur Stützung des Projektverlaufs (durch den Lenkungsausschuss oder → Projektsponsor) erforderlich?
Folgender Aufbau ist möglich:
- Berichtsdatum, Berichtszeitraum
- Status zu Leistung, Terminen, → Aufwand / Kosten, Risiko sowie → Qualität (bevorzugt in der → Ampeldarstellung)
- Beschreibung / Darstellung des Gesamtstatus
- Detaillierung der Status mit Problemen, Maßnahmen und notwendigen Entscheidungen (Handlungsbedarf)
- Angaben zum Ersteller und Verteiler
Der Aufbau eines Projektstatusberichts ist in Abbildung 3.2 dargestellt: Typischerweise gibt es einen Kopf- und einen Rumpfbereich. Im Kopfbereich sind alle wesentlichen Angaben zusammenfassend dargestellt. In dieser schnellen kommt dabei häufig eine → Ampeldarstellung zum Einsatz.
Der Rumpfbereich schlüsselt dann die fünf Teilaspekte, die in der Ampeldarstellung zum Gesamtstatus zusammengefasst wurden, weiter auf (hier nur verkürzt wiedergegeben).
Idealerweise wird der Projektstatusbericht aus einem PMS (→ Projektmanagementsystem) vollständig generiert, um so den Interpretationsspielraum zu minimieren.
Abbildung 3.2: Der Projektstatusbericht: Formular
Im Projektstatusbericht können weitere Berichte aggregiert eingebaut sein (Abbildung 3.3). Der Risikobericht ist dabei oftmals ein direkter Bestandteil, während die Informationen aus den Arbeitspaketstatusberichten passend aufbereitet dargestellt werden. Aus dem Qualitätsbericht (mit möglichen, zusätzlichen QM-Berichten) werden nur punktuell Informationen übernommen.
Abbildung 3.3: Der Projektstatusbericht: Verweise
Da die Erstellung eines Projektstatusberichts Zeit benötigt, muss dies auch eingeplant werden (Abbildung 3.4). Bei größeren Projekten muss mit einem Vorlauf von bis zu 14 Tagen gerechnet werden.
Abbildung 3.4: Der Projektstatusbericht: Erstellung im zeitlichen Verlauf
Aus der Vorlaufzeit ergibt sich das → Problem der Aktualität: Im Zweifel sind die Ursprungsdaten bis zu 14 Tage alt. Wird der Projektstatusbericht monatlich verfasst, so ist er nur für die Hälfte des Berichtszeitraums relevant.
Mit Abschluss des Projekts sollten die Projektstatusberichte gesammelt, überprüft und für kommende Projekte zur Verfügung gestellt werden. Aus den in ihnen gespeicherten Informationen kann Wissen extrahiert werden (Abbildung 3.5). Dies bedeutet insbesondere, dass unmittelbar mit → Projektabschluss die Projektberichte durchgeschaut werden sollten. Zusammen mit anderen Informationen (z.B. der abschließenden Befragung der Projektbeteiligten, was besonders gut und was besonders schlecht gelaufen ist) fließen diese Erfahrungen in die “Lessons-Learned-Datenbank” ein.
Abbildung 3.5: Erfahrungssicherung beim Projektabschluss (nach /Zell18/)
3.2 Der Projektabschlussbericht
Nach DIN 69901–5:2009 /DIN16/ ist der Projektabschlussbericht (engl. Project Closing Report) eine “zusammenfassende, abschließende Darstellung von Aufgaben und erzielten Ergebnissen, von Zeit‑, Kosten- und Personalaufwand sowie gegebenenfalls von Hinweisen für mögliche Anschlussprojekte.”
Folgender Aufbau ist möglich:
- → Projektauftrag / → Projektziel
- Planungsunterlagen vor Projektfreigabe
- Ist-Unterlagen bei → Projektende
- Abschlussanalyse (Gegenüberstellung von ursprünglichen und im Projektverlauf aktualisierten Plangrößen mit den Ergebnissen bei Projektende) bezüglich
a) Terminen, Aufwänden, Kosten und
b) inhaltlicher Zielerreichung - Dank an alle Beteiligten für deren Mitwirkung
- Ansprechpartner zur weiteren Betreuung des Projekts
Der Projektabschlussbericht umfasst im Allgemeinen nur wenige Seiten. Da er “das Gegenstück” zum Projektauftrag aus dem Projektstart ist, wird er vom Projektsponsor und vom Projektmanager (beim → Projektabschluss) unterschrieben (grüne Pfeile in Abbildung 3.6).
Abbildung 3.6: Der Projektabschlussbericht: Formular
4. Praktische Aspekte
Zu dem Einsatz von Berichten in Projekten gibt es eine große Anzahl von Tipps und Tricks, die die Verwendung in der Praxis unterstützen. Hier sind einige davon wiedergeben.
4.1 Einfache Sprache und lesbare Schrift
Berichte dienen dazu, einem definierten Zielpublikum die Informationen zu liefern, die es braucht. Daher sollte nur einfache Sprache verwendet und auf sprachliche Ausgestaltungen verzichtet werden. Bei der Schrift ist darauf zu achten, dass diese gut lesbar ist, sowohl online als auch ausgedruckt. Viele Organisationen haben Richtlinien zur Barrierefreiheit bei Dokumenten — diese sollten dann auch beachtet werden.
4.2 Die optische Ausgestaltung von Berichten in Projekten
Zur Verdeutlichung und Hervorhebung bestimmter Sachverhalte können einige Elemente in den Berichten besonders gestaltet werden.
Hierzu können beispielsweise eingesetzt werden:
- Hot-Spots: Es werden einzelne Bereiche umrandet (beispielsweise mit roten Linien), um sofort darauf hinzuweisen, worauf zu achten ist
- Farben: Generell können Farben eingesetzt werden. Allerdings muss klar sein, welche Farben welche Bedeutung haben
- ABC-Bereiche: Der gesamte Bericht wird in drei Bereiche kategorisiert, die (im Allgemeinen über Farben) in den Beschriftungen ersichtlich sind
Abbildung 4.1: Arten von Hervorhebungen in Berichten
Auch die Positionen der Hervorhebungen in den Berichten müssen festgelegt werden. Generell kann
Abbildung 4.2: Positionen von Hervorhebungen in Berichten
4.3 Checklisten für Berichte in Projekten
Zur Überprüfung, ob das Berichtswesen im Projekt etabliert ist, kann folgende Checkliste eingesetzt werden:
Abbildung 4.3: Checkliste: Ist das Berichtswesen etabliert?
Zur Überprüfung, ob die (Berichts-)Formulare (oder Vorlagen) passend zum Projekt gewählt wurden, kann folgende Checkliste eingesetzt werden:
Abbildung 4.4: Checkliste: Sind die Formulare passend für das Projekt?
Zur Überprüfung, ob die Ablagestruktur passend gewählt wurde, kann folgende Checkliste eingesetzt werden:
Abbildung 4.5: Checkliste: Ist die Ablagestruktur passend?
5. Häufig gestellte Fragen und Antworten (FAQ) zu den Berichten
- F: Kann man auf Berichte in der Praxis verzichten?
A: Nein — zumindest der Projektstatusbericht und der Projektabschlussbericht sollten verwendet werden. - F: Wie viele unterschiedliche Berichte benötigt man typischerweise in Projekten?
A: Es gibt keine maximale Anzahl, es sind jedoch mindestens zwei zu verwenden. Bei mehr als 15 verschiedenen Berichten sollte überprüft werden, ob diese tatsächlich benötigt werden. - F: In welcher Form sollten Berichte erstellt werden — reichen elektronische Darstellungen?
A: Generell sollten Berichte so erstellt werden, wie sie der Empfänger benötigt. Sind Ausdrucke notwendig, so sollten diese auch erstellt werden. Werden rein elektronische Berichte verwendet, so muss darauf geachtet werden, dass diese auch archivierbar sind und archiviert werden.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
A.1 Meine öffentliche Präsentation zu den Berichten in Projekten
Meine Präsentation zu den Berichten in Projekten ist in weiten Teilen deckungsgleich mit der Darstellung auf dieser Webseite und kann für eine “Schnelldarstellung” genutzt werden.
Inhalt | Typ |
---|---|
Projektmanagement: Berichte – Eine Übersicht |
Ebenfalls von hoher Relevanz zum Thema Berichte in Projekten sind meine folgenden → Präsentationen:
A.2 Literatur
- /DIN16/ DIN: Projektmanagement. Netzplantechnik und Projektmanagementsysteme. DIN-Taschenbuch 472, Beuth, Berlin 3. Auflage 2016, ISBN 978–3‑410–27041‑6
- /Fiedler20/ Rudolf Fiedler: Controlling von Projekten: Mit konkreten Beispielen aus der Unternehmenspraxis – Alle controllingrelevanten Aspekte der → Projektplanung, → Projektsteuerung und → Projektkontrolle, Springer Fachmedien, Wiesbaden 8. Auflage 2020, ISBN 978–3‑658–28031‑4
- /GPM16/ Deutsche Gesellschaft für Projektmanagement: Kompetenzbasiertes Projektmanagement (PM3), → GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 8. Auflage 2016, ISBN 978–3‑924841–74‑4
- /GPM19/ Deutsche Gesellschaft für Projektmanagement: Kompetenzbasiertes Projektmanagement (PM4), GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 2019, ISBN 978–3‑924841–77‑5
- /Jenny19/ Bruno Jenny: Projektmanagement. Das Wissen für den Profi, Vdf Hochschulverlag, Zürich 4. Auflage 2019, ISBN 978–3‑7281–3967‑2
- /Patzak17/ Gerold Patzak, Günter Rattay: Projektmanagement. Projekte, Projektportfolios, Programme und projektorientierte Unternehmen, Linde, Wien 7. Auflage 2017, ISBN 978–3‑7143–0321‑6
- /PBG17/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Sixth Edition 2017, ISBN 978–1‑62825–184‑5
- /PBG17‑d/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Sechste Ausgabe 2017, ISBN 978–1‑62825–188‑3
- /Peipe10/ Sabine Peipe, Martin Kärner: Projektberichte, Statusreports, Präsentationen, Haufe, München 2. Auflage 2010, ISBN 978–3‑648–00335‑0
- /Schelle08/ Heinz Schelle, Roland Ottmann, Astrid Pfeiffer: Projektmanager, GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 3. Auflage 2008, ISBN 978–3‑9248–4126‑3
- /Schreck13/ Berta C. Schreckeneder: Projekte überwachen, steuern, präsentieren, Haufe, München 4. Auflage 2013, ISBN 978–3‑648–03654‑9
- /Spitczok14/ Niklas Spitczok von Brisinski, Guy Vollmer, Ute Weber-Schäfer: Pragmatisches IT-Projektmanagement. Softwareentwicklungsprojekte auf Basis des → PMI PMBOK Guide führen, dpunkt, Heidelberg 2. Auflage 2014, ISBN 978–3‑86490–045‑7
- /Zell18/ Helmut Zell: Projektmanagement – lernen, lehren und für die Praxis, Books on Demand, Norderstedt 10. Auflage 2018, ISBN 978–3‑8370–0086‑3
A.3 Weblinks
- /PMBOK+IT/ Website mit einigen PM-Dokumenten zum freien Download von /Spitczok14/, die nach kostenfreier Registrierung zur Verfügung stehen: https://pitpm.net/
- /#V‑TPG-Berichte/ Webinar der Firma TPG zu Berichten (deutsch, 13:57 Minuten) vom 13.04.2013 auf Youtube: “Projekte mit Reports steuern — sinnvolle Berichte im Projektmanagement – Teil 1 von 4”: https://www.youtube.com/watch?v=vbYJz8Ht6ZU
- /→ V‑Modell-XT-Berichte/ Berichtswesen im V‑Modell-XT 2.0 (2015), (deutsch)
- /#Wiki-Berichtswesen/ Berichtswesen in der deutschen Wikipedia
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 12.11.2021 © Peterjohann Consulting, 2005–2024