Gute Projektdokumentation sorgt dafür, dass ein Projekt nicht aus dem Ruder läuft – und hilft dem nächsten Team, aus euren Unterlagen zu lernen. Mit Trupeer könnt ihr euch Stunden beim Schreiben von Projektdokumenten sparen, indem ihr mit einer kostenlosen Projektdokumentations-Vorlage startet, sie mit euren Brand Guidelines anpasst und die Dokumentation in eine klare Video-Übersicht umwandelt, die Stakeholder wirklich ansehen.

Was ist eine Projektdokumentations-Vorlage, und wer liest sie?

Projektdokumentation ist alles, was ein Projekt schriftlich festhält: das Briefing, den Plan, die Anforderungen, Statusberichte, Risiko- und Issue-Logs, Change Requests, Testergebnisse, das Übergabematerial und der Abschlussbericht.

Eine Vorlage gibt euch für jedes Dokument den Rahmen und die Struktur. Sucht man danach, bekommt man entweder eine Ordnerstruktur oder ein einzelnes Dokument mit Abschnitten – je nachdem, ob die Quelle Dokumentation eher als Bibliothek oder als Bericht versteht.

Die sinnvollere Frage ist jedoch, wer sie liest, denn es gibt zwei Zielgruppen – und sie liegen zeitlich weit auseinander.

Die erste Zielgruppe ist das Projekt selbst: das Team, der Sponsor, das Governance-Forum. Sie brauchen Status, Entscheidungen und Freigaben – und zwar diese Woche.

Die zweite Zielgruppe ist, wer das Ergebnis danach betreibt, unterstützt oder verändert. Diese Personen kommen erst nach achtzehn Monaten bis fünf Jahren, wenn niemand mehr aus dem Projektteam verfügbar ist, und sie müssen wissen, was gebaut wurde, warum es so gebaut wurde und was dabei berücksichtigt und verworfen wurde.

Fast alle Projektdokumente werden für die erste Zielgruppe geschrieben. Fast der gesamte Nutzen liegt bei der zweiten.

Projektdokumentation hat zwei Zielgruppen, getrennt durch Jahre

Die Bedürfnisse der ersten Zielgruppe sind gut abgedeckt, weil sie vorgeschrieben sind. Governance verlangt einen Plan, einen Statusbericht, ein Risikolog und einen Change-Prozess – daher werden diese Dinge erstellt, egal ob sie jemand als nützlich empfindet.

Die Bedürfnisse der zweiten Zielgruppe sind hingegen überhaupt nicht vorgeschrieben – und das sieht man.

Fragt man jemanden, der ein System betreibt, das vor drei Jahren gebaut wurde, was er sich gewünscht hätte, dann lautet die Antwort erstaunlich konsistent. Warum ist es so. Was wurde noch in Betracht gezogen. Was wusste das ursprüngliche Team, das wir nicht wissen. Was wurde bewusst weggelassen. Wer hat dem zugestimmt.

Keine dieser Fragen wird durch einen Statusbericht, einen Plan oder ein RAID-Log beantwortet. Statusberichte halten den Fortschritt gegenüber einem Plan fest, der sich geändert hat. Pläne dokumentieren eine Absicht, die später überholt wurde. Risikologs halten fest, wovor sich Menschen gefürchtet haben – selten jedoch, was tatsächlich passiert ist.

So kann ein Projekt dreihundert Dokumente produzieren und später keine einzige der Fragen beantworten, die man an es stellt.

So passt ihr diese Vorlage in Trupeer an

Schritt 1: Öffnet den Bereich „Templates“

Geht im Hauptmenü zum Bereich „Templates“.

Schritt 2: Wählt eine Vorlage aus und öffnet sie

Klickt auf eine beliebige Vorlage, mit der ihr arbeiten möchtet, um sie zu öffnen.

Schritt 3: Ansicht der Vorlage erweitern

Falls nötig, erweitert die Ansicht der Vorlage, um das vollständige Layout und die Details klar zu sehen.

Schritt 4: Bearbeitet die Vorlage

Klickt auf „Edit“, um mit der Bearbeitung der ausgewählten Vorlage zu beginnen.

Im Editor könnt ihr:

• Neue Abschnitte hinzufügen

• Formatierungsregeln definieren oder aktualisieren

• Ein Logo hinzufügen und Position sowie zugehörige Einstellungen anpassen

Schritt 5: Speichert eure angepasste Vorlage

Nachdem ihr alle notwendigen Änderungen vorgenommen habt, klickt auf „Save“, um die aktualisierte Vorlage als eure eigene zu speichern.

Schritt 6: Vorschau ansehen und die Vorlage feinjustieren

Wenn ihr sehen wollt, wie eure angepasste Vorlage aussieht, öffnet die Vorschau.

Ausgehend vom Vorschau-Bildschirm könnt ihr bei Bedarf weiterhin direkt Anpassungen vornehmen – so stellt ihr sicher, dass die Vorlage genau so erscheint, wie ihr es wollt.

Mit einer Projektdokumentations-Vorlage könnt ihr:

• Stunden beim Schreiben sparen: Überspringt die leere Seite – mit einer Struktur, die für jeden Projekttyp ausgelegt ist.

• Stakeholder ausrichten: Integrierte Abschnitte für Scope, Ziele und Deliverables sorgen dafür, dass alle auf derselben Seite sind.

• Im Brand bleiben: Nutzt euer Logo, eure Schriften und Farben mit Trupeer’s Brand Kit – perfekt für Client-Deliverables.

• Schneller onboarden: Neue Teammitglieder kommen schnell in den Kontext, wenn er klar erfasst ist.

• Lessons festhalten: Integrierte Retrospektive-Abschnitte machen es leicht, aus jedem Projekt zu lernen.

• Globale Teams erreichen: Übersetzt Projektdokumentation mit einem Klick in 65+ Sprachen.

Die Dokumente, die niemand vorschreibt, sind die, die Menschen brauchen

Sortiert Projektdokumente danach, ob sie nach dem Abschluss von jemandem gelesen werden – und das Muster ist deutlich.

Vorgeschrieben und danach wertlos: Statusberichte, Plan-Versionen, RAID-Log-Versionen, Meeting-Protokolle, Change-Request-Formulare, Timesheets, Steering Papers.

Optional und danach wertvoll: das Decision Record, die Beschreibung „as-built“, die verworfenen Optionen, die bekannten Einschränkungen, das Übergabematerial, die Gründe für alles, was ungewöhnlich ist.

Diese Asymmetrie ist kein Zufall. Vorgeschriebene Dokumente existieren, um Governance zu erfüllen – also einen Prozess, der sich während des Projekts um Kontrolle kümmert. In diesem Prozess fragt niemand, was die nächste Person brauchen wird, denn die nächste Person sitzt nicht im Raum und wird sich auch nicht zwei Jahre lang beschweren.

Die praktische Antwort ist, ein Dokument zum vorgeschriebenen Set hinzuzufügen und dabei kompromisslos zu sein, was archiviert wird. Das hinzuzufügende Dokument ist ein Decision Log – und das Thema des nächsten Abschnitts.

Das Decision Log – und warum ein RAID-Log keines ist

Die meisten Projekte glauben, dass sie das abgedeckt haben, weil sie ein RAID-Log führen. Das tun sie nicht – und der Unterschied ist entscheidend.

Ein RAID-Log erfasst Risiken, Annahmen, Issues und Abhängigkeiten. Alle vier sind zukunftsgerichtete Zustände, die Anlass zur Sorge geben. Keines davon erfasst eine Entscheidung.

Ein Decision Log erfasst Entscheidungen. Fünf Felder pro Eintrag – und keines davon ist optional.

Was entschieden wurde, so formuliert, dass jemand außerhalb des Projekts es versteht.

Wann, mit Datum.

Wer entschieden hat, namentlich und mit Rolle – nicht „das Projektboard“.

Was verworfen wurde, also die anderen Optionen, die tatsächlich auf dem Tisch lagen.

Warum, in einem oder zwei Sätzen.

Das vierte Feld ist das, was das Log wertvoll macht. Irgendwann kann man durch Reverse Engineering herausfinden, was entschieden wurde – indem man betrachtet, was existiert. Niemand kann jedoch per Reverse Engineering rekonstruieren, was berücksichtigt und verworfen wurde. Genau das braucht jemand, der das System drei Jahre später verändert, denn sein erster Impuls wird sein, die Option vorzuschlagen, die ihr bereits ausgeschlossen habt.

Pflegt es wöchentlich an einem Ort – angehängt statt überarbeitet. Zehn Minuten pro Woche ergeben etwas, das das Projekt um Jahre überdauert, und es ist das einzige Projektdokument, das nach dem Abschluss zuverlässig gelesen wird.

So sortiert ihr eure Dokumentenliste nach dem Wert nach dem Abschluss

Führt das bei eurem eigenen Set zum Abschluss durch – statt alles zu archivieren. Das ist die Standardeinstellung und führt zu einem Archiv, das niemand durchsucht, weil das Signal darin vergraben ist.

Die Zeile, die das Verhalten verändert, sind Meeting-Protokolle. Protokolle halten fest, dass ein Thema besprochen wurde. Fast nie halten sie fest, zu welchem Ergebnis man gekommen ist – deshalb bringt es auch nichts, wenn man in Protokollen sechzig Erwähnungen zu einem Thema findet. Extrahiert Entscheidungen in dem Moment, in dem sie fallen, in das Log – dann hören die Protokolle auf, wichtig zu sein.

Kostenlose Projektdokumentations-Vorlage: das Set, das es wert ist, behalten zu werden

Kopiert von hier. Sieben Dokumente statt einer Ordnerstruktur.

One. Brief. Das Problem, die Rahmenbedingungen und Erfolgskriterien – gemäß unserem Projekt-Briefing-Template. Eine Version, archiviert.

Two. Decision log. Die fünf Felder oben, wöchentlich angehängt, nie überarbeitet. Das wertvollste Artefakt, das das Projekt erzeugen wird.

Three. Plan. Scope, Zeitplan, Ressourcen und Abhängigkeiten – gemäß unserem IT-Projektplan-Template. Während der Umsetzung live, finale Baseline archiviert.

Four. Requirements oder Spezifikation. Was gebaut werden sollte. Finale Version archiviert, frühere Entwürfe verworfen.

Five. As-built description. Was es jetzt tatsächlich gibt – im Unterschied zu dem, was spezifiziert wurde. Enthält alles, was von den Anforderungen abweicht, und warum. Das ist das Dokument, das nicht geschrieben wird – und das Operations-Teams zuerst anfragen.

Six. Known limitations. Was das Ding nicht kann, was es zum Scheitern bringt, und welche Workarounds beim Übergabezeitpunkt verfügbar sind. Kurz, ehrlich und enorm wertvoll.

Seven. Handover pack. Wer es jetzt besitzt, was sie erhalten haben, Betriebs- und Wartungsmaterial sowie Support-Vereinbarungen. Wenn das Projekt ein physisches Asset geliefert hat, deckt unser Operation- und Maintenance-Manual-Template das richtig ab.

Governance-Dokumente – also Statusberichte, Steering Papers und RAID-Versionen – existieren während des Projekts und gelangen nur dann ins Archiv, wenn ein Standard dies verlangt.

Kopiert bis hier.

Die Bausparkasse, die ihr eigenes System nicht erklären konnte

Calderbank, eine Bausparkasse mit etwa vierzehnhundert Mitarbeitenden, hat 2022 ihre Plattform zur Kreditvergabe ersetzt. Vierzehn Monate, ungefähr drei Punkt eins Millionen Pfund.

Das Projekt erzeugte rund dreihundertvierzig Dokumente: achtundfünfzig wöchentliche Statusberichte, einundvierzig Versionen des RAID-Logs, sechsundsiebzig Change Requests, einhundertzwölf Sets von Meeting-Protokollen, dreiundzwanzig Plan-Versionen sowie Anforderungen, Test-Skripte und Trainingsmaterial. Es endete mit einer vollständigen Dokumentations-Freigabe.

Im Jahr 2025 erforderte eine regulatorische Änderung eine Anpassung daran, wie eine bestimmte Kategorie von Einkommen in einer Berechnung der Erschwinglichkeit behandelt wurde. Das bestehende System schloss sie aus, und niemand konnte erklären, warum. War es eine bewusste Policy-Entscheidung, eine Einschränkung des Produkts des Anbieters oder ein Fehler, den niemand bemerkt hatte?

Die Antwort war entscheidend, denn eine bewusste Auslassung mit dokumentiertem Grund ist eine andere regulatorische Position als eine versehentliche.

Sie durchsuchten alle dreihundertvierzig Dokumente. Die Anforderung tauchte als einzelne Zeile im Anforderungsdokument auf. Kein Change Request erwähnte sie. Das Wort „affordability“ erschien einundsechzig Mal in den Protokollen – immer als Diskussionspunkt, nie als Entscheidung.

Die Antwort wurde schließlich in einer privaten E-Mail-Kette gefunden, weitergeleitet von einem Auftragnehmer, der 2023 gegangen war – und nur, weil sich jemand daran erinnerte, dass er beteiligt gewesen war.

Sieben Wochen vergingen, bevor sie den Umfang der Änderung festlegen konnten. Die Änderung selbst dauerte vier. Externe Rechtsberatung wurde hinzugezogen, um die regulatorische Position zu bestätigen, weil sie die ursprüngliche Begründung nicht belegen konnten – Kostenpunkt etwa achtundzwanzigtausend Pfund. Und weil die Begründung nicht festgestellt werden konnte, wurde die Änderung vorsichtig und mit mehr Aufwand als nötig geplant und neu gebaut. Das Programm bezifferte den vermeidbaren Aufwand danach auf ungefähr einhundertvierzigtausend Pfund.

Von den dreihundertvierzig Dokumenten war keines ein Decision Record. Jede Entscheidung, die wirklich zählte, war in einem Meeting getroffen worden, als Diskussion protokolliert und umgesetzt.

Das nächste Programm, ein elfmonatiger Ersatz einer Savings-Plattform, führte ab Woche eins ein Decision Log. Fünf Felder, wöchentlich angehängt – vierundsiebzig Einträge bis zum Abschluss. Insgesamt entstanden einhundertneunzig Dokumente, von denen sie einunddreißig archivierten.

Achtzehn Monate nach Abschluss dieses Programms kamen drei getrennte Fragen auf, warum es so ist. Alle drei wurden innerhalb eines Tages aus dem Log beantwortet.

So erstellt ihr Projektdokumentation Schritt für Schritt

Legt zu Beginn fest, welche Dokumente es geben wird und welche archiviert werden. Das erst am Abschluss zu tun bedeutet, alles zu archivieren – und ein Archiv mit allem ist nicht durchsuchbar.

Startet das Decision Log in Woche eins, bevor es Entscheidungen gibt, die es wert sind, festgehalten zu werden, denn ein später gestartetes Log wird nie nachträglich befüllt.

Schreibt das Briefing und die Erfolgskriterien, bevor ihr den Plan schreibt – damit der Plan das Problem unterstützt und nicht umgekehrt.

Extrahiert Entscheidungen aus Meetings in das Log, sobald sie im Meeting getroffen werden. Zehn Minuten pro Woche. Wenn ihr euch auf Protokolle verlasst, bedeutet das, dass später jemand sechzig Erwähnungen eines Themas liest und daraus eine Schlussfolgerung ableitet.

Erstellt die Beschreibung „as-built“ während der Umsetzung und nicht erst am Ende – und aktualisiert sie, wenn sich Dinge ändern. Wenn sie erst zum Abschluss geschrieben wird, entsteht sie aus dem Gedächtnis – und ist das Dokument, das am wahrscheinlichsten still und leise falsch ist.

Schreibt die bekannten Einschränkungen ehrlich auf. Es gibt die Versuchung, sie bei der Übergabe wegzulassen – und das schadet dem Vertrauen des empfangenden Teams in alles andere im Paket.

Sortiert beim Abschluss das Set anhand der Tabelle oben, archiviert, was seinen Platz verdient, und verwirft den Rest.

Projektdokumentation für Software- und Studentenprojekte

Ein großer Teil der Suchanfragen zu diesem Begriff kommt von Studierenden, die ein Software- oder Website-Projekt für die Abgabe dokumentieren – und die Anforderungen sind tatsächlich anders. Daher lohnt es sich, das direkt anzusprechen, statt so zu tun, als wäre es dasselbe.

Akademische Projektdokumentation folgt normalerweise dem Lebenszyklus der Softwareentwicklung und erwartet ein definiertes Set: eine Einführung und Problemstellung, eine Literatur- oder Analyse des bestehenden Systems, eine Anforderungen-Analyse, Systemdesign mit Diagrammen, Implementierungsnotizen, Tests mit Ergebnissen sowie Schlussfolgerungen mit Ausblick auf zukünftige Arbeiten. Die Spezifikation eurer Institution ist maßgeblich und unterscheidet sich von jeder Vorlage, die ihr online findet – startet daher mit den Bewertungskriterien statt mit einem Beispiel.

Zwei Dinge aus der professionellen Perspektive lassen sich sinnvoll übertragen.

Das Decision Log. Bewertungsschemata belohnen begründete Entscheidungen, und ein Nachweis darüber, was ihr verworfen habt und warum, ist genau die Evidenz, die ein durchdachtes Design von einem beliebigen unterscheidet. Die meisten studentischen Dokumentationen behaupten Entscheidungen, ohne sie zu begründen.

Der Abschnitt zu den bekannten Einschränkungen. Wenn ihr explizit sagt, was euer System nicht tut – und warum – wirkt das wie Kompetenz statt wie Schwäche. Und genau daraus entsteht der Abschnitt zu zukünftigen Arbeiten.

Was sich nicht übertragen lässt, ist das Governance-Material. Statusberichte und RAID-Logs sind nicht das, was eine akademische Abgabe braucht.

Was ihr beim Abschluss archivieren solltet – und was ihr löschen könnt

Alles zu archivieren ist die Standardeinstellung – und es ist eine Entscheidung, nicht zu entscheiden. Das Ergebnis ist ein Ordner, den niemand durchsucht, weil die Suche zu einhundertzwölf Sets von Meeting-Protokollen und einundvierzig Versionen eines Risikologs führt.

Archivieren: das Decision Log, die Beschreibung „as-built“, die bekannten Einschränkungen, das Übergabepaket, das Briefing, die finalen Anforderungen, die finale Plan-Baseline und alles, was eure regulatorischen oder vertraglichen Verpflichtungen vorschreiben.

Verwerfen: Statusberichte, überholte Plan- und RAID-Versionen, Meeting-Protokolle, sobald die Entscheidungen daraus extrahiert wurden, Change-Request-Formulare, sobald die Entscheidungen darin im Log erfasst sind, sowie Entwürfe von allem.

Wenn ein Standard, ein Regulator oder ein Vertrag die Aufbewahrung von Governance-Material verlangt, bewahrt es separat vom Archiv auf, das die Menschen voraussichtlich durchsuchen sollen. Compliance-Aufbewahrung und nutzbare Dokumentation sind unterschiedliche Zwecke – und das Vermischen davon verhindert den zweiten.

Legt das Archiv so ab, dass es für das Team auffindbar ist, das das Ergebnis übernimmt – nicht im Projektbüro. Dort legen Projekte Dinge naturgemäß ab, und zwei Jahre später schaut niemand mehr nach. Unser IT-Dokumentations-Template deckt das fortlaufende Zuhause für das Material „as-built“ ab.

Projektdokumentation oder Prozessdokumentation?

Zwei unterschiedliche Dokumente mit ähnlichen Namen – und der Unterschied hängt davon ab, ob das Ergebnis endet.

Projektdokumentation beschreibt eine Arbeit mit Start und Ende. Sie wird einmal erstellt, beim Abschluss archiviert und danach von Menschen gelesen, die das Ergebnis übernehmen. Ihr Wert ist historisch: Was wurde gebaut, warum, und was wurde verworfen.

Prozessdokumentation beschreibt Arbeit, die sich wiederholt. Sie wird kontinuierlich gepflegt, von Menschen gelesen, die die Arbeit ausführen, und ihr Wert ist aktuell. Unser Prozessdokumentations-Template deckt das ab – inklusive warum die Ausnahmen wichtiger sind als die Schritte.

Ein Projekt produziert häufig Prozessdokumentation als Ergebnis. Das Projekt dokumentiert, wie das neue System gebaut wurde; die Prozessdokumentation beschreibt, wie es heute betrieben wird. Das sind unterschiedliche Dokumente mit unterschiedlichen Verantwortlichen und unterschiedlichen Lebensdauern. Wenn man sie kombiniert, wird die operative Hälfte zusammen mit dem Projekt archiviert – so endet ein Live-Prozess am Ende nur in einem geschlossenen Projektordner.

Wenn das Output des Projekts vollständig an ein anderes Team übergeben wird, deckt unser Knowledge-Transfer-SOP die Übergabe ab, die allein durch diese Dokumentation nicht erreicht wird.

Kann ich eine Projektdokumentations-Vorlage in Word oder Excel bekommen?

Word oder Google Docs für die narrativen Dokumente: Briefing, Beschreibung „as-built“, bekannte Einschränkungen und Übergabepaket. Das sind Fließtexte – und sie werden gelesen statt sortiert.

Excel für zwei Dinge. Das Decision Log ist eine Tabelle und muss durchsuchbar, filterbar und anhängbar sein, ohne dass jemand das Format neu aufsetzen muss. Und das Dokumentenregister listet jedes Dokument mit seinem Owner, seiner Version und ob es beim Abschluss archiviert oder verworfen wurde.

Das Decision Log in einer Tabelle statt als Dokument zu führen, lohnt sich besonders. Denn der Wert liegt vollständig darin, dass man es später durchsuchen kann. Ein Decision Log in einem Dokument wird innerhalb von drei Monaten zur Textwand.

PDF für das archivierte Set beim Abschluss – aus den Quellen exportiert, mit Datum und Version gestempelt.

So haltet ihr fest, was gebaut wurde – während es gebaut wird

Das Dokument mit dem höchsten Wert nach dem Abschluss und der niedrigsten Abschlussquote ist die Beschreibung „as-built“ – und der Grund ist banal. Es bedeutet, dass jemand Konfigurationen und Screens beschreibt, an denen er gerade Monate gearbeitet hat und die er am Ende komplett satt hat – genau dann, wenn das Projekt keine Zeit mehr hat.

Daher wird es beim Abschluss aus dem Gedächtnis geschrieben – oder abgehakt und nicht geschrieben.

Trupeer AI löst das, indem es die Erfassung während der Umsetzung ermöglicht. Wer etwas konfiguriert oder baut, erfasst es einmal, während er es macht – und das Ergebnis ist eine schriftliche Beschreibung mit den Schritten und Screens, die bereits mit erfasst wurden. Die „as-built“-Dokumentation wächst statt am Ende produziert zu werden, und sie ist korrekt, weil sie zum Zeitpunkt der Erstellung aufgezeichnet wurde – statt später rekonstruiert zu werden.

Erfasst es. Brandet es. Übersetzt es. Trupeer es.

Die gleichen Aufzeichnungen dienen auch dem Übergabepaket und dem Betriebsmaterial, das normalerweise im selben Moment gebraucht wird und selten rechtzeitig fertig ist. Technische Dokumentation deckt die interne Aufzeichnung ab, und das Material lebt in eurer Knowledge Base mit konsistenter Brand-Umsetzung. Setup-Anleitungen findet ihr in der document template setup guide.

Häufig gestellte Fragen

Gibt es eine kostenlose Projektdokumentations-Vorlage in Word?

Das sieben Dokumente umfassende Set oben funktioniert in Word oder Google Docs, und die narrativen Dokumente gehören dort hinein. Es gibt keinen gesperrten Download und kein Formular. Führt das Decision Log in einer Tabelle statt als Dokument – denn sein gesamter Wert liegt darin, dass es zwei Jahre später durchsuchbar ist.

Gibt es eine kostenlose Projektdokumentations-Vorlage in Excel?

Excel passt zum Decision Log und zum Dokumentenregister. Das Log braucht fünf Spalten: Entscheidung, Datum, entschieden von, verworfene Optionen und Begründung. Das Register braucht Dokument, Owner, Version und ob es beim Abschluss archiviert oder verworfen wird. Beide sind nützlicher als jede narrative Vorlage.

Wo finde ich ein Projektdokumentations-Beispiel in PDF?

Veröffentlichte Beispiele sind leicht zu finden und unterscheiden sich stark in der Qualität, weil Projektdokumentationsstandards je nach Organisation und Methode variieren. Lest sie für die Dokumentenliste statt für den Inhalt und prüft, ob eines davon ein Decision Record enthält – denn die meisten tun es nicht, und genau das ist der Punkt dieser Seite.

Gibt es ein Website-Projektdokumentations-Beispiel in PDF?

Wenn das für einen Kurs oder ein Projekt im Abschlussjahr gedacht ist, arbeitet mit den Bewertungskriterien eurer Institution statt mit einem Beispiel, da die erforderlichen Abschnitte variieren und die Kriterien das sind, woran ihr gemessen werdet. Der Abschnitt zu Software- und Studentenprojekten oben deckt ab, was sich sinnvoll aus der professionellen Praxis übertragen lässt – vor allem das Decision Log und ein ehrlicher Abschnitt zu Einschränkungen.

Wie viel Projektdokumentation ist genug?

Weniger Dokumente als die meisten Projekte produzieren – und eine zusätzliche Art, die die meisten Projekte nicht haben. Sieben Dokumente sind ein praktikables Set für ein umfangreiches Projekt. Der Test ist nicht das Volumen, sondern ob jemand, der in zwei Jahren ankommt, beantworten kann, warum es so ist – und diese Frage wird durch ein Dokument beantwortet, nicht durch dreihundert.

Wer sollte Projektdokumentation schreiben?

Der Projektmanager ist für das Set und insbesondere das Decision Log verantwortlich, da sie in jedem Meeting dabei sind, in dem Entscheidungen getroffen werden. Die Beschreibung „as-built“ sollte von der Person geschrieben werden, die es gebaut hat – während der Umsetzung. Dokumentation, die vollständig von einem Projektbüro beim Abschluss erstellt wird, beschreibt eher die Projektunterlagen als das Ergebnis.

Wie lange sollte Projektdokumentation aufbewahrt werden?

Das Decision Log, die Beschreibung „as-built“ und die bekannten Einschränkungen – so lange, wie das Ergebnis existiert. Das ist in der Regel deutlich länger als jede Aufbewahrungsrichtlinie annimmt. Governance-Material für alle Standards, Verträge oder Regulatoren, die es verlangen, wird separat von dem Material gespeichert, das die Menschen voraussichtlich durchsuchen sollen.

Projektdokumentation oder Projektplan: Was ist anders?

Der Plan ist ein Dokument innerhalb der Projektdokumentation – und beschreibt, wie die Arbeit umgesetzt wird. Projektdokumentation ist das gesamte Set, inklusive dessen, was entschieden wurde, was gebaut wurde und was übergeben wurde. Ein Projekt mit einem hervorragenden Plan und ohne Decision Log ist gut gemanagt – und lässt sich danach nicht erklären. Das ist der häufigere Fehler.