Aufbau und Nutzen einer Dokumentation in ...fiz1.fh-potsdam.de/volltext/diplome/07425.pdf · durch ein Projektmanagement kaum noch vorstellbar. Die Komplexität moderner IT-Projekte

Institut für Information und Dokumentation (IID) PotsdamSchwerpunkt: Wirtschaftsinformatik-GrundlagenKurs A/2007

Abschlussarbeit für dieFortbildung zum Wissenschaftlichen Dokumentar

Projektdokumentation

Aufbau und Nutzen einer Dokumentation ininterdisziplinären IT-Projekten

27. August 2007

Autor: Andreas Dan

Betreuer: Sven Hirsch

Abstract

Die Arbeit beschreibt die Bedeutung und den Aufbau einer Dokumentation in interdiszipli-nären IT-Projekten. Es werden die Aufgaben der Dokumentation im Kontext von Informations-und Wissensmanagement erläutert sowie unterschiedliche Dokumentationstypen identifiziert.Aufbauend hierauf wird eine begrifflich eindeutige Typologie der Dokumentation in IT-Projekten entwickelt. Abschließend werden anhand eines Beispielprojekts konkrete Hinweisezum Aufbau einer Dokumentation gegeben, wobei nur diejenigen Dokumentationstypen be-rücksichtigt werden, die aus Sicht des Projekt- bzw. Anforderungsmanagements von Interessesind (Projektakte bzw. Anforderungsdokumentation).

Inhaltsverzeichnis

1 Einleitung 1

2 Wissensmanagement in interdisziplinären IT-Projekten 32.1 Grundlagen des Wissensmanagements und Bedeutung der Dokumentation . . 42.2 Wissensmanagement in Projektphasen und Konsequenzen für die Dokumentation 5

3 Begriffsklärung und Aufgaben der Dokumentation 103.1 Grundlegende Dokumentationstypen . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Projektdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.2 Produktdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Erweiterte Typologie der Dokumentation . . . . . . . . . . . . . . . . . . . . 13

4 Regeln für den Aufbau einer effektiven Dokumentation 154.1 Entwicklung eines Dokumentationskonzepts . . . . . . . . . . . . . . . . . . 164.2 Struktur der Dokumentation im hr-Projekt . . . . . . . . . . . . . . . . . . . 23

4.2.1 Struktur der Projekt- und der Anforderungsdokumentation . . . . . . 234.2.2 Struktur des Projekthandbuchs . . . . . . . . . . . . . . . . . . . . . 25

4.3 Die Bedeutung von Dokumentationsregeln . . . . . . . . . . . . . . . . . . . 26

5 Schluss 30

Literaturverzeichnis 32

Anhang 33

Tabellenverzeichnis

1 Projektphasen und ihre Auswirkungen auf die Dokumentation . . . . . . . . 82 Checkliste: Dokumente der Projektakte . . . . . . . . . . . . . . . . . . . . 183 Checkliste: Dokumente der Anforderungsdokumentation . . . . . . . . . . . 19

Abbildungsverzeichnis

1 Dokumentationstypen in Projekten . . . . . . . . . . . . . . . . . . . . . . . 112 Erweiterte Typologie der Dokumentation in IT-Projekten . . . . . . . . . . . 143 Ordnungshierarchie Projektakte und Anforderungsdokumentation . . . . . . 244 Struktur des Projekthandbuchs . . . . . . . . . . . . . . . . . . . . . . . . . 255 Muster für Datei-Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1 Einleitung

Die Durchführung von Projekten in der Informationstechnik (IT) ist heutzutage ohne Steuerungdurch ein Projektmanagement kaum noch vorstellbar. Die Komplexität moderner IT-Projekteerfordert immer ausgefeiltere Projektmanagement-Methoden, um einen reibungslosen Pro-jektverlauf und eine termingerechte Abgabe des Produkts gewährleisten zu können. Aufgrunddes zunehmend interdisziplinären Charakters der IT-Projekte wird zudem vermehrt versucht,Informations- und Wissensmanagement-Lösungen in die Projektstruktur einzubinden.

Im Zuge der Etablierung neuer Projektmanagement-Methoden, wie beispielsweise dasevolutionäre oder iterative Projektmanagement1, rückt auch das häufig vernachlässigte Themader „Dokumentation“ verstärkt in den Fokus des Interesses. Denn erst durch den schnellenZugriff auf relevante Projektdokumente ist effektives Projekt- und Wissensmanagement über-haupt möglich. So ist in der Fachliteratur unstrittig, dass die Dokumentation ein wichtigerBestandteil der Qualitätssicherung in Projekten ist.

Allerdings endet bei dieser Feststellung die Einigkeit auch schon wieder. Allein bei denBegrifflichkeiten herrscht bereits ein Durcheinander: Projektdokumentation, Produktdokumen-tation, Programmdokumentation, Software-Dokumentation – zahlreiche Begriffe, die jederAutor etwas anders definiert, finden sich in der Fachliteratur. Für Verwirrung sorgt zudem, dassin vielen Fällen keine klaren Abgrenzungen zwischen Bau-, Forschungs- und Entwicklungs-sowie IT-Projekten gemacht werden. Dabei sind die Anforderungen an die Dokumentation jenach Disziplin ganz unterschiedlich. Ein Bauingenieur, der den Auftrag hat eine Brücke zubauen, wird seine Dokumentations-Strategie völlig anders ausrichten als ein Informatiker, dereine Software zu entwickeln hat.

Auch zum praktischen Aufbau einer Dokumentation findet sich in der Literatur wenigKonkretes. Zumeist beschränken sich die Ausführungen auf Einzelaspekte der Dokumenta-tion. So werden beispielsweise mögliche Ordnungs-Systematiken oder Mustervorlagen fürbestimmte Dokument-Typen vorgestellt.2 Allgemeine Hinweise und Tipps zur Erarbeitungeiner schlüssigen, ganzheitlichen Dokumentations-Strategie sucht man aber vergebens.

Steht man vor der konkreten Aufgabe für ein interdisziplinäres IT-Projekt eine Dokumen-tation aufzubauen, sorgt die Lektüre der Fachliteratur aufgrund der genannten Defizite fürErnüchterung. Es mangelt nicht nur an praktischen Hinweisen zur Planung einer Dokumen-tation; es fehlt letztlich auch eine begrifflich eindeutige Differenzierung unterschiedlicherDokumentationstypen.

Ziel dieser Arbeit ist deshalb die genannten Defizite zum Themenkomplex „Dokumentationin interdisziplinären IT-Projekten“ zumindest teilweise zu beheben. Entsprechend gilt esfolgende zentrale Fragestellungen zu beantworten: Welche Bedeutung hat die „Dokumentation“

1Vgl. hierzu Kapitel 2.1, S. 4.2Hier sind vor allem Burghardt: Projektmanagement und Kitz: IT-Projektmanagement zu nennen.

1

1 Einleitung

in interdisziplinären IT-Projekten? Welche unterschiedlichen Dokumentationstypen gibt esund wie können sie voneinander abgegrenzt werden? Was muss beim konkreten Aufbau einerDokumentation alles bedacht werden?

In Kapitel 2 (Wissensmanagement in interdisziplinären IT-Projekten) wird zunächst erläu-tert, warum gerade in interdisziplinären IT-Projekten Informations- und Wissensmanagementeine wichtige Rolle spielt und welchen Stellenwert die Dokumentation in diesem Kontexthat. Bereits hier lassen sich unterschiedliche Typen der Dokumentation erkennen, die dannin Kapitel 3 (Begriffsklärung und Aufgaben der Dokumentation) definiert und beschriebenwerden, um so zu einer eindeutigen, speziell auf IT-Projekte bezogenen Dokumentations-Typologie zu gelangen. Die erarbeitete Typologie bildet die Grundlage für das praxisorientierteKapitel 4 (Grundregeln für den Aufbau einer effektiven Dokumentation), in dem anhandeines Beispiel-Projekts ausführlich dargestellt wird, was beim Aufbau einer Dokumentationgenerell zu beachten ist. Bei dem Beispiel-Projekt handelt es sich um ein aktuelles Projekt imHessischen Rundfunk (hr), dessen Ziel es ist, eine bandlose Infrastruktur für die Fernsehpro-duktion aufzubauen. Im Schlusskapitel (Kapitel 5) werden die Ergebnisse zusammengefasstund abschließend wird ein Ausblick auf den zukünftigen Stellenwert der „Dokumentation ininterdisziplinären IT-Projekten“ gewagt.

Es sei noch erwähnt, dass diese Arbeit nicht aus Sicht eines IT-Spezialisten, sondern ausder Perspektive eines Projekt- bzw. eines Anforderungsmanagers geschrieben ist.3 Darausfolgt, dass im Rahmen dieser Arbeit vor allem diejenigen Bestandteile der Dokumentationvon Interesse sind, die für das Projekt- und Anforderungsmanagement von Relevanz sind.

3Vgl. zum Begriff des Anforderungsmanagers bzw. des Anforderungsmanagements ausführlich Kapitel 2,S. 3ff.

2

2 Wissensmanagement in interdisziplinärenIT-Projekten

Für jedes IT-Projekt ist die anwendernahe Umsetzung der zu entwickelnden Software eingrundlegendes Ziel. Um die Anforderungen der Anwender exakt umsetzen zu können, werdenin der Regel sogenannte Anforderungsmanager benannt. Sie sollen als Vertreter der Anwenderderen Anforderungen an das System bündeln und den IT-Spezialisten vermitteln. Bei kom-plexen, längerfristigen IT-Projekten, die zudem gleich mehrere Anwendergruppen betreffen,werden die Anforderungsmanager häufig als Projektmitglieder fest in die Projektstrukturintegriert. Wird darüber hinaus auch das Projektmanagement (Projektleiter, Projektassistenz)von Fachspezialisten übernommen, entsteht eine interdisziplinäre Projektgruppe, die ihrerseitsbereits eine Art Wissensmanagement darstellt: Im Interesse eines bestimmten Wissensziels(das Projektziel) versammeln sich Experten aus unterschiedlichen Fachdisziplinen in einerheterogenen Projektgruppe.4 Bei interdisziplinären IT-Projekten können somit drei Experten-gruppen voneinander unterschieden werden: das Projektmanagement, die IT-Systementwicklersowie die Anforderungsmanager.

Die Heterogenität interdisziplinärer IT-Projekte bringt allerdings ein grundsätzliches Pro-blem mit sich. Da die Projektgruppe in vielen Bereichen über keinen gemeinsamen Wissens-stand verfügt, wird die Kommunikation unter den Projektmitgliedern erschwert. Häufig ist ininterdisziplinären IT-Projekten zu beobachten, dass aneinander vorbei gesprochen wird undMissverständnisse entstehen, die schlimmstenfalls direkte, negative Auswirkungen auf dasEndprodukt haben können. Je heterogener die Projektgruppe besetzt ist, umso wichtiger ist es,zumindest ein Grundverständnis für die Sichtweise der anderen Projektmitglieder zu entwi-ckeln. Gelingt es, den Informations- und Wissenstransfer5 im Projekt optimal zu „managen“,gestaltet sich die Kommunikation und damit auch die konkrete Projektarbeit eindeutiger undziehlführender.

Die Vielzahl an „Wissensmanagement-Tools“ (Projektportale, Projektdatenbanken etc.), diemittlerweile in fast jedem Projekt in irgendeiner Weise zum Einsatz kommen, verdeutlichendas gesteigerte Interesse an Informations- und Wissensmanagement-Lösungen. Problematischist allerdings, wenn der Einsatz der „Tools“ an sich bereits als Lösung angesehen wird. Ohne

4Vgl. Sanden: Wissensmanagement, S. 452.5Die Begriffe Informations- und Wissensmanagement werden in dieser Arbeit als Quasi-Synonyme behandelt,da im begrenzten Rahmen eines Projekts Wissensmanagement ohne effektives Informationsmanagement kaummöglich ist. Die reine Vermittlung von Informationen und Wissen (Informationsmanagement) wird also immerim Zusammenhang mit dem Management der konkreten Verstehens- und Erklärungsprozesse (Wissensmana-gement) gesehen. Es sei aber darauf hingewiesen, dass diese Synonymsetzung strengen Definitionsregeln nichtstandhält. Vgl. zu den Unterschieden zwischen Informations- und Wissensmanagement ausführlicher Capurro:Wissensmanagement, Kapitel IV.

3

2 Wissensmanagement in interdisziplinären IT-Projekten

Vorüberlegungen zum Umgang mit dem Faktor „Wissen“ ist effektives Wissensmanagementnicht möglich.

2.1 Grundlagen des Wissensmanagements und Bedeutung derDokumentation

Etablierte Ansätze zum Wissensmanagement, wie beispielsweise die „Bausteine des Wissens-managements“ von Probst/Raub/Romhardt6, haben wichtige Erkenntnisse zum Umgang mitder Ressource „Wissen“ hervorgebracht. Die Autoren betrachten dabei zumeist das gesamteUnternehmen, d. h. sie thematisieren vor allem die unzureichende unternehmensweite Nutzungder Ressource „Wissen“.

In jüngster Zeit rücken aber auch Projekte vermehrt in den Fokus von Wissensmanagement-Ansätzen, nicht zuletzt da sich die Umsetzung eines ganzheitlichen, unternehmensweitenWissensmanagementkonzepts in der Praxis als äußerst schwieriges und aufwendiges Unter-fangen dargestellt hat. Projekte eignen sich aufgrund ihres zeitlich und inhaltlich begrenztenRahmens relativ gut als „Experimentierfeld“ für konkrete Wissensmanagement-Lösungen.Zumal die zunehmend interdisziplinären Aufgabenstellungen sowie die Einführung neuerProjektmanagement-Methoden, wie beispielsweise das „Evolutionäre Projektmanagement“7,vermehrt eines „Vernetzten Denkens“ bzw. eines „Multi-Perspektiven-Denkens“ bedürfen.8

Als grundsätzliche Probleme beim Umgang mit der Ressource „Wissen“ und zwar völligunabhängig davon, ob nun im Rahmen eines Projekts oder unternehmensweit, hat HeikeSanden folgende Punkte identifiziert:9

• Keine systematische Nutzung der Ressource Wissen, da fehlende Transparenz.

• Fehlende Plattformen zum zielorientierten Wissensaustausch.

• Fehlende Methoden für den Transfer von individuellem Wissen zu unternehmensweitverfügbarem Wissen.

• Mehrfacher, jedoch unabhängiger Aufbau von Wissen.

• Wissen ist nicht greifbar, weil es unzureichend dokumentiert ist, nicht schnell genuglokalisiert wird und verstreut ist.

Aus Sandens Erkenntnissen kann im Umkehrschluss abgeleitet werden, dass ein effektivesWissensmanagement in Projekten nur dann möglich ist, wenn:

6Als Bausteine identifizieren die Autoren: Wissensidentifikation, Wissenserwerb, Wissensentwicklung, Wis-sens(ver)teilung, Wissensnutzung, Wissensbewertung, Wissensziele und Wissensbewahrung. Vgl. hierzuausführlich Probst/Raub/Romhardt: Wissen managen, S. 56ff.

7Vgl. hierzu Frick: Evolutionäres Projektmanagement, S. 90f. Frick versteht unter evolutionär vor allem dieständige Einbeziehung der veränderten Projektsituation, was dem sogenannten iterativen Vorgehen entspricht.

8Siehe Litke: Projektmanagement, S. 282.9Vgl. Sanden: Wissensmanagement, S. 453.

4


• Methoden für den Transfer von individuellem zu kollektivem Wissen etabliert werden(z. B. durch Brainstorming, Grafiken, Fragebögen).

• eine Austauschplattform für den Wissenstransfer vorhanden ist (z. B. effektives Berichts-wesen, virtuelles Projekt-Office im Internet/Intranet).

• das erarbeitete Wissen gespeichert und dokumentiert wird, um Wissensverlust zu ver-meiden und um jederzeit schnell auf die erarbeiteten Inhalte zurückgreifen zu können.

• das gespeicherte Wissen auch über das Projektende hinaus verfügbar ist, so dass ausdem projektinternen ein unternehmensweites Wissen wird.

Erst im Zusammenspiel dieser vier zentralen Faktoren, deren konkrete Umsetzung imEinzelfall sehr unterschiedlich ausfallen kann, entfaltet Informations- und Wissensmanagementsein ganzes Potential.10

In der Praxis wird diese wichtige Feststellung allerdings häufig übersehen, d. h. es wird zu-meist immer nur einer der vier Faktoren berücksichtigt: Beispielsweise wird ein Projekt-Wikials Austauschplattform implementiert, es werden aber keine Methoden für den Wissenstransferetabliert und auch die Dokumentation erfolgt nur unzureichend – effektives Wissensmanage-ment lässt sich auf diese Weise aber nicht bewerkstelligen.

Von den vier genannten Faktoren für ein effektives Wissensmanagement sind im Rahmendieser Arbeit vor allem die zwei letztgenannten von Interesse.11 Die grundlegende Bedeu-tung der Speicherung, Dokumentation und schnellen Verfügbarkeit von Informationen undWissen wird hier mehr als deutlich. Was genau gespeichert werden soll und vor allem auchwofür und für wen, darauf wird in den nachfolgenden Kapiteln detailliert eingegangen. Andieser Stelle bleibt zunächst festzuhalten, dass die Dokumentation für das Informations- undWissensmanagement eine grundlegende Bedeutung hat.

2.2 Wissensmanagement in Projektphasen und Konsequenzenfür die Dokumentation

Neben den genannten Grundvoraussetzungen für das Wissensmanagement in Projekten sollteauch berücksichtigt werden, dass im Projektverlauf wechselnde Anforderungen an das Wis-sensmanagement gestellt werden. Dabei kann die Klärung der Frage, zu welcher Projektphase

10Neben diesen eher methodischen Faktoren spielen auch psychologische Faktoren eine zentrale Rolle beimWissensmanagement: Wissenstransfer und Wissensaustausch setzen ein hohes Maß an Kommunikationskom-petenz voraus. Zudem muss die Bereitschaft bestehen, sich auf andere Sichtweisen einzulassen und seinerseitsauch Wissen preiszugeben. Deshalb sollten vor jedem Projekt grundlegende Fragen der Kommunikation unddes Umgangs untereinander geklärt werden (hier wird gerne der Begriff „Projektkultur“ genannt).

11Allerdings leistet die Dokumentation in Form der Dokumentationsregeln auch einen wichtigen methodischenBeitrag für den Transfer von individuellem zu kollektivem Wissen. Vgl. zu den Dokumentationsregelnausführlich Kapitel 4.3, S. 26ff. Eine detaillierte Betrachtung weiterer Methoden und Austauschplattformenfür den Wissenstransfer ist im Rahmen dieser Arbeit nicht möglich.

5


welches Wissen bzw. welche Information benötigt wird, wertvolle Hinweise auf konkreteUmsetzungsstrategien – z. B. bezüglich der Dokumentation – geben.

Ein erster Ansatz zur Klärung der Frage, welches Wissen in welcher Projektphase benötigtwird, findet sich bei Heike Sanden. Sie unterteilt den Projektverlauf recht allgemein in eineKlärungs-, Einarbeitungs-, Umsetzungs- und Evaluationsphase:12

• Klärungsphase: Hier fällt die Entscheidung zur Bildung eines Projekts auf der oberstenManagement-Ebene. Es handelt sich somit um eine Vorprojektphase.

• Einarbeitungsphase: Hier wird das Projekt geplant und die Grundlagen für das Projekt-management werden geschaffen, d. h. es werden die Ausgangssituation, Organisationund konkreten Ziele des Projekts geklärt (Ermittlung der „Wissensziele“).

• Umsetzungsphase: Hier findet sozusagen die eigentliche Projektarbeit statt („Wissensauf-bau“).

• Evaluationsphase: Hier wird das erarbeitete Wissen bewertet („Wissensbewertung“),wobei dies nicht nur am Ende des Projekts, sondern in regelmäßigen Abständen auchwährend des Projekts geschehen sollte. Dies entspricht dem bereits erwähnten evolutio-nären bzw. iterativen Vorgehen.13 Im strengen Sinn handelt es sich also nicht um einePhase, da die Evaluation den gesamten Projektverlauf begleitet.

Überträgt man die von Sanden beschriebenen Projektphasen auf den Bereich interdiszipli-närer IT-Projekte, können die Phasen wie folgt modifiziert werden:

• Die Vorprojekt- und Planungsphase unmittelbar vor bzw. nach dem Kick-Off.14

• Darauf folgen die einzelnen Phasen der Software-Entwicklung15: Anforderungsanalyse,Systemarchitektur, Konzeption, Kodierung, Test.

• Am Ende steht die Projektabschlussphase, in welche die Abnahme, Produktivnahme,Schulungen und bei Bedarf die Wartung fallen.

• Was Sanden unter der „Evaluationsphase“ versteht, sollte besser mit dem im IT-Bereichgeläufigeren Begriff „Iteratives Vorgehen“ bezeichnet werden – zumal der Phasenbegriffohnehin etwas irreführend ist. Durch das iterative Vorgehen werden Probleme undGefahren schnell erkannt, so dass frühzeitig Gegenmaßnahmen entwickelt werdenkönnen.

12Vgl. Sanden: Wissensmanagement, S. 463ff.13Vgl. Frick: Evolutionäres Projektmanagement, S. 90f. und Fußnote 7.14Im Kick-Off-Meeting kommen zum ersten Mal alle Projektmitglieder zusammen, weshalb der Kick-Off

den offiziellen Start des Projekts einläutet. Natürlich bedarf es bereits vor dem Kick-Off vorbereitenderMaßnahmen. Diese Phase kann als Vorprojektphase bezeichnet werden.

15Vgl. Kitz: IT-Projektmanagement, S. 70ff.

6


Beschreibt man nun die Projektphasen detaillierter und bezieht zudem die Perspektive derDokumentation mit ein, werden erste grundsätzliche Anforderungen an eine Dokumentationin Projekten erkennbar:16

• Planungsphase vor und nach dem Kick-Off: Hier werden die organisatorischen Grundla-gen für das gesamte Projektmanagement geschaffen. Dementsprechend sollten hier auchalle grundsätzlichen Fragen der Dokumentation geklärt und ein Dokumentationskonzeptentwickelt werden.17

• Anforderungsanalyse: In dieser Phase werden alle Anforderungen, die das System er-füllen muss, ermittelt. Dies erfolgt in der Regel durch die Zusammenarbeit zwischenIT-Entwickler und Anforderungsmanager. Gerade in dieser Phase stellt das Wissensma-nagement eine besondere Herausforderung dar, weil – je nach Sichtweise – fachfremdePersonengruppen zusammenarbeiten. Dies sollte bei der Planung des Dokumentations-konzepts in jedem Fall berücksichtigt werden.

• Systemarchitektur, Konzeption, Kodierung, Test: In diesen Phasen arbeiten praktischausschließlich die IT-Entwickler miteinander, da hier die Konzeption und die Pro-grammierung bzw. Kodierung des Systems vorgenommen werden. Um den Überblicküber die Arbeiten am Programmkode nicht zu verlieren, Tests zu ermöglichen und einQualitäts- und Änderungsmanagement zu etablieren, wird eine eigenständige, technischeDokumentation benötigt. Da der Programmkode bei komplexer Software immens großwird und sich in unzählige Untergruppen aufteilt, ist eine eindeutige Kommentierungnotwendig. Zudem wird fast immer auf automatische Versionsverwaltungs-Systemezurückgegriffen, so dass problemlos mehrere Programmierer an dem Quellkode arbeitenkönnen.

• Abnahme, Produktivnahme, Schulung und eventuell Wartung: Nachdem das System vonSeiten der IT technisch und von Seiten der Anforderungsmanager auch fachlich abge-nommen wurde, muss die Produktivnahme durch Schulungen begleitet werden. Hierzudient die an den Anwender gerichtete Abschluss-Dokumentation des Produkts, sprich:das Benutzerhandbuch. Das Äquivalent für den IT-Spezialisten stellt das TechnischeHandbuch dar, ohne das eine Wartung des Systems unmöglich wäre. Mit den Wortenvon Sanden gesprochen, wird in Form des Benutzerhandbuchs das „Wissen bewahrt“bzw. durch die Schulungen der Transfer von „kollektivem“ zu „unternehmensweitenWissen“ vollzogen.18

• Projektabschluss: Interesse an einer „Wissensbewahrung“ und der Wandlung zu „unter-nehmensweiten Wissen“ besteht nicht nur bezüglich des entwickelten Produkts, sondern

16Auch für die beiden anderen zentralen Faktoren zur Umsetzung eines effektiven Wissensmanagement –Methoden bzw. Austauschplattformen für den Wissenstransfer – ist eine Analyse nach Projektphasen sinnvoll.Wie bereits erwähnt beschränkt sich diese Arbeit jedoch auf die detaillierte Betrachtung der Dokumentation.

17Vgl. hierzu ausführlich Kapitel 4.1, S. 16ff.18Siehe Sanden: Wissensmanagement, S. 456f.

7


Tabelle 1: Projektphasen und ihre Auswirkungen auf die Dokumentation [Quelle: Eigene Darstellung]

Projektphase Personengruppe Konsequenzen für DokumentationPlanungsphasevor und nach demKick-Off

Alle Projektmitglieder,vor allem aber Projektmana-gement (PM)

Entwicklung eines Dokumentationskonzepts

Anforderungsanalyse IT-Entwickler,Anforderungsmanager

Einheitliche Dokumentation (um Wissen-stransfer und damit gute Zusammenarbeit zugewährleisten)

Systemarchitektur,Konzeption,Kodierung, Test

IT-Entwickler Programmdokumentation (zur eindeutigenKommentierung des Programmkodes), auto-matische Versions- bzw. Releaseverwaltung,Testprotokolle

Abnahme, Produktiv-nahme,Schulung, Wartung

IT-Entwickler,Anforderungsmanager

Technische und Fachliche Abschlussdoku-mentation des entwickelten Produkts (Tech-nisches Handbuch bzw. Benutzerhandbuch)

Projektabschluss Alle Projektmitglieder,vor allem aber PM

Abschlussdokumentation des Projektmanage-ments vor allem hinsichtlich der Erfahrungs-sicherung

Projektmanagement Alle Projektmitglieder,vor allem aber PM

Schneller Zugriff auf alle projektrelevantenInformationen (Terminpläne, Kostenpläne,Besprechungsprotokolle etc.)

Iteratives Vorgehen Alle Projektmitglieder Schneller Zugriff auf projektrelevante Infor-mationen bzw. auf Programmdokumentation

auch bezüglich der Erfahrungen des Projektmanagements. Eine Erfahrungssicherungkann beispielsweise in Form eines Projektabschlussberichts erfolgen, in dem das Pro-jektmanagement abschließend bewertet wird.

Neben diesen Projektphasen müssen noch das Projektmanagement bzw. das iterative Vorge-hen berücksichtigt werden, die den gesamten Projektverlauf begleiten:

• Projektmanagement: Das Projektmanagement ist für alle organisatorischen Fragen desProjekts verantwortlich. Termine, Arbeitsergebnisse, Kostenpläne, Protokolle usw. müs-sen verwaltet werden, um jederzeit den aktuellen Projektstatus evaluieren zu können.Darüber hinaus benötigen alle Projektmitglieder Zugriff auf projektrelevante Informa-tionen wie beispielsweise Terminpläne oder Besprechungsprotokolle.

• Iteratives Vorgehen: Die ständige Hinterfragung, Analyse und Bewertung der erar-beiteten Ergebnisse während des gesamten Projektverlaufs stellt an die Struktur undÜbersichtlichkeit der Dokumentation besondere Ansprüche. Das iterative Vorgehen hatdabei zwei Bezugspunkte:

8


– das Projektmanagement, d. h. es sollte zyklisch überprüft werden, ob der Zeit- undKostenplan noch eingehalten wird, um so Fehlentwicklungen schnell erkennen zukönnen (Projektcontrolling).

– die Software-Entwicklung, d. h. es sollte beispielsweise durch Tests in regelmäßi-gen Abständen überprüft werden, ob die neuesten Änderungen am Programmkodeden gewünschten Effekt haben.

Lange Suchzeiten zur Ermittlung der benötigten Dokumente können beim iterativenVorgehen kaum in Kauf genommen werden, weshalb die schnelle Wiederauffindbarkeitder zur Prüfung relevanten Dokumente von hoher Wichtigkeit ist.

In Tabelle 1 (S. 8) sind die genannten Zusammenhänge zwischen Projektphasen, betroffenerPersonengruppe und der Dokumentation nochmals in verkürzter Form dargestellt.

Die Identifizierung der Anforderungen an das Informations- und Wissensmanagement unddamit auch an die Dokumentation gibt einen ersten wichtigen Anhaltspunkt hinsichtlich derFrage was für wen wann dokumentiert werden muss: Je nach Projektphase und Personengruppegibt es unterschiedliche Erwartungen und Anforderungen, die an die Dokumentation gestelltwerden.

9

3 Begriffsklärung und Aufgaben der Dokumentation

Was genau unter der „Dokumentation“ von Projekten zu verstehen ist, darüber gehen inder Fachwelt die Meinungen weit auseinander. In der Literatur findet sich eine Vielzahlunterschiedlicher Begrifflichkeiten und Definitionen, die letztlich eher für Verwirrung dennfür Aufklärung sorgen. Einer der Hauptgründe dieser Begriffsvielfalt wurde im vorigenKapitel herausgearbeitet: Da je nach Personengruppe und Projektphase ganz unterschiedlicheAnforderungen an eine Dokumentation bestehen, kann mit dem Begriff „Dokumentation“vieles gemeint sein.

Eine Differenzierung des Dokumentationsbegriffs ist zwingend notwendig, um zu klären,was wann wofür und für wen dokumentiert werden soll. Deshalb wird im Folgenden versucht,aufbauend auf den Erkenntnissen des vorigen Kapitels, verschiedene Dokumentationstypen zuidentifizieren und voneinander begrifflich abzugrenzen. Die erarbeitete Typologie ist dabeifreilich nicht der Weisheit letzter Schluss. Sie dient in erster Linie der Begriffseindeutigkeitinnerhalb dieser Arbeit. Generell gilt aber für jedes Projekt, dass darüber Einigkeit hergestelltwerden sollte, was unter dem Begriff „Dokumentation“ verstanden wird – und zwar am bestenbevor mit der Projektarbeit begonnen wird.

3.1 Grundlegende Dokumentationstypen

Gerade bei interdisziplinären IT-Projekten, in denen Vertreter unterschiedlicher Fachbereichezusammenarbeiten, herrscht oft Unklarheit darüber, was eigentlich dokumentiert werden soll.So spricht der IT-Entwickler von der „Dokumentation“ und meint vor allem die technischeBeschreibung des zu entwickelnden Systems (Spezifikationen, Kodierung, Technisches Hand-buch etc.). Der Anforderungsmanager möchte seine Anforderungen verständlich, am bestenin Textform dokumentiert wissen und versteht darüber hinaus unter „Dokumentation“ diestrukturierte Ablage von Berichten und Protokollen. Der Projektleiter wiederum sieht in der„Dokumentation“ vor allem ein Management-Werkzeug, weshalb die zuverlässige Speicherungaller Planungsdokumente für ihn oberste Priorität hat.

Viele Unklarheiten des genannten Beispiels können bereits durch die von Burghardt ge-troffene Unterscheidung von „Projekt-“ bzw. „Produktdokumentation“ beseitigt werden.19

Dabei wird generell die Dokumentation des Projektverlaufs von der Dokumentation desherzustellenden Produkts unterschieden.

19Vgl. Burghardt: Projektmanagement, S. 354f.

10


Abbildung 1: Dokumentationstypen in Projekten [Quelle: Burghardt: Projektmanagement, S. 355]

3.1.1 Projektdokumentation

Zur Projektdokumentation gibt es eine Definition des Deutschen Instituts für Normung (DIN),welche allerdings nicht speziell auf den IT-Bereich ausgelegt ist, sondern Projekte ganzallgemein meint. Nach DIN 69901 beschäftigt sich die Projektdokumentation mit der „Zusam-menstellung ausgewählter, wesentlicher Daten über Konfiguration, Organisation, Mitteleinsatz,Lösungswege, Ablauf und erreichte Ziele des Projektes“.20 Die Projektdokumentation ver-waltet demnach alle für das Projektmanagement relevanten Planungs-, Organisations- undBerichtsdokumente (Projektstrukturplan, Terminpläne, Arbeitsberichte, Besprechungspro-tokolle usw.). Es werden also keine „inhaltlichen“ Dokumente, die das zu entwickelndeProdukt beschreiben, gesammelt, sondern ausschließlich Dokumente, die für die Planung undOrganisation der Projektarbeit relevant sind.

Erst die vollständige, durchgängige und aktuelle Projektdokumentation ermöglicht einwirkungsvolles Projektmanagement, da stets überprüft werden kann, wie es um den aktuellenProjektstand bestellt ist. Gleichzeitig wird gewährleistet, dass alle Projektmitglieder stetsüber den Projektstand bzw. über die zukünftigen Planungen und Termine informiert sind.Darüber hinaus spielt die Projektdokumentation für die Erfahrungssicherung eine wichtigeRolle, da durch sie auch zu einem späteren Zeitpunkt nachvollzogen werden kann, wie dasProjekt entstanden ist, wie es verlief und welche Probleme bzw. Erfolge es bezüglich desManagements gab.

Die primären Aufgaben der Projektdokumentation sind demnach:

• Zusammenstellung und Sicherung aller relevanten Projektdokumente.

• Unterstützung des Projektmanagements und des Informationsflusses innerhalb der Pro-

20Zitiert nach Nursinski: Projektdokumentation, Abschnitt: Definition.

11


jektgruppe durch schnellen Zugriff auf relevante Projektinformationen.

• Speicherung wichtiger Projektdokumente, um auch nach Abschluss des Projekts einenallgemeinen Zugriff auf die Projekterfahrungen zu ermöglichen.

In der Praxis oft problematisch ist die Frage nach der Relevanz bestimmter Projekt-dokumente. Beispielsweise wäre es unvorteilhaft einen veränderten Projektterminplan abzu-speichern, ohne den veralteten zu löschen, da eventuell für andere Projektmitglieder nicht mehrnachvollziehbar ist, welcher Terminplan nun der aktuelle ist. Gerade im Zeitalter der digitalenSpeicherung wird dazu geneigt, jedes Dokument ohne Prüfung seiner Relevanz abzuspeichern.Problematisch wird dieses Vorgehen, wenn gleichzeitig die Pflege der Projektdokumentation,wozu beispielsweise das Löschen nicht mehr relevanter Dokumente zählt, vernachlässigt wird.Tatsächlich werden Projekte oft zu umfangreich und zu wenig Ziel gerichtet dokumentiert,was wiederum den Zugriff auf relevante Dokumente und Informationen erheblich erschwert.

Um besonders wichtige Projekt- und Planungsinformationen nicht im Dickicht einer aus-ufernden Projektdokumentation zu verlieren, hat sich besonders bei komplexen Projekten dieEinführung eines „Projekthandbuchs“ bewährt, das alle „Informationen und Regelungen, diefür die Planung und Durchführung eines bestimmten Projekts gelten sollen“21 aufführt. Übli-cherweise in Form eines Gesamtdokuments werden hier alle wesentlichen Planungsdaten (z. B.Projektstrukturplan, Terminplan, Arbeitspakete) sowie die projektspezifischen Rahmenbedin-gungen (z. B. Projektauftrag, Projektziele, Organisationsstruktur) aufgeführt. Dadurch sind diewichtigsten Projektinformationen stets an zentraler Stelle abrufbar und müssen nicht erst ausden jeweiligen Projektdokumenten zusammengestellt werden.22 Auch wenn bei größeren Pro-jekten das Projekthandbuch durchaus bis zu 100 Seiten stark sein kann, ermöglicht es dennoch,den aktuellen Projektstand bzw. den bisherigen und weiter geplanten Projektverlauf schnell zuerfassen. Voraussetzung ist allerdings eine regelmäßige Aktualisierung des Projekthandbuchs.

Für die Verwaltung der im Projektverlauf entstehenden Dokumente ist nach dieser Lesartspeziell die „Projektdokumentation“ zuständig. Um Verwirrungen mit dem BurghardtschenBegriff „Projektdokumentation“ zu vermeiden, wird dieser im Nachfolgenden durch denBegriff „Projektakte“ ersetzt. „Projektakte“ ist demnach die übergeordnete Bezeichnung für„Projekthandbuch“ und „Projektdokumentation“.23

3.1.2 Produktdokumentation

Die Produktdokumentation beschäftigt sich im Gegensatz zur Projektakte nicht mit der Projekt-organisation und -planung, sondern mit dem eigentlichen Ziel des Projekts, nämlich dem zuentwickelnden Produkt. Sämtliche Unterlagen des herzustellenden Produkts werden hierverwaltet (z. B. Lasten- und Pflichtenheft, Programmkode, Technisches Handbuch etc.).24 DieProduktdokumentation spiegelt damit die Entstehungsgeschichte der Software wider.21Zitiert nach: Angermeier: Projektmanagement-Glossar, Abschnitt: Projekthandbuch.22Zur Gestaltung eines Projekthandbuchs vgl. ausführlicher Kapitel 4.2.2, S. 25f.23Siehe hierzu Kapitel 3.2, S. 13f. sowie Abbildung 2, S. 14.24Vgl. Burghardt: Projektmanagement, S. 354f.

12


Eine speziell auf den IT-Bereich bezogene Darstellung der Produktdokumentation findetsich in der DIN 66230 Programmdokumentation. Hier werden ausführliche Angaben zurDokumentation des Programmkodes gemacht (Programmdokumentation), die für die Pro-grammierarbeit von essentieller Bedeutung sind. Weiterführend werden die Erstellung einesBenutzerhandbuchs und eines Technischen Handbuchs beschrieben, die sozusagen die Ab-schlussdokumentation des Produkts darstellen.25 Während das Benutzerhandbuch an denAnwender der Software gerichtet ist, bildet das Technische Handbuch die Grundlage fürModifizierungs-, Weiterentwicklungs- und Wartungsarbeiten durch IT-Spezialisten. In beidenFällen sollte die Dokumentation verständlich, eindeutig und präzise sein.

Nicht berücksichtigt ist in der DIN 66230 die Anforderungsanalyse, obwohl ihr eine zentraleBedeutung bei der Software-Entwicklung zufällt. Schließlich werden in dieser Phase dieAnforderungen, die das zu entwickelnde System erfüllen muss, im Zusammenspiel zwischenIT-Entwicklern und den Anforderungsmanagern erarbeitet und zwar bevor mit der konkretenProgrammierung begonnen wird. Die ermittelten Anforderungen werden in einem Lastenheftzusammengefasst und dann im Pflichtenheft technisch präzisiert. Im Gegensatz zu den anderenBestandteilen der Produktdokumentation beschreibt das Lasten- bzw. Pflichtenheft somitnicht die in Entwicklung befindliche bzw. bereits entwickelte Software, sondern vielmehr dasProdukt vor seiner Programmierung.

Besonders in komplexen IT-Projekten, die unterschiedliche Fachbereiche betreffen und indenen mehrere Anforderungsmanager vertreten sind, nimmt die Anforderungsanalyse einenGroßteil der gesamten Projektdauer in Anspruch. Es ist höchste Genauigkeit und Eindeutigkeitgefordert, denn wird eine wichtige Anforderung vergessen oder falsch dargestellt, könnenderartige Fehler im späteren Projektverlauf oft nur mit sehr hohem Kostenaufwand behobenwerden.26

Um im vielschichtigen Prozess der Anforderungsanalyse den Überblick über die Ergebnissenicht zu verlieren, empfiehlt sich deshalb der Aufbau einer gesonderten „Anforderungsdoku-mentation“. Hieraus kann dann das Lasten- wie auch das Pflichtenheft generiert werden, wobeidurch Verweise auf die Anforderungsdokumentation die Entstehung jeder einzelnen Anforde-rung nachvollziehbar ist. Zudem bietet die „Anforderungsdokumentation“ eine hervorragendeBasis für die Erstellung eines verständlichen Benutzerhandbuchs.

3.2 Erweiterte Typologie der Dokumentation

Berücksichtigt man die dargestellten Aspekte der Dokumentation in IT-Projekten, kann, wiein Abbildung 2 (S. 14) zu sehen ist, die oben angeführte Typologie von Burghardt um weitereDokumentationstypen erweitert werden.

Für den konkreten Aufbau einer Dokumentation in IT-Projekten gibt diese Typologie bereitseine erste Grundstruktur vor.

25Vgl. hierzu Burghardt: Projektmanagement, S. 355.26Vgl. Kitz: IT-Projektmanagement, S. 72f.

13


Abbildung 2: Erweiterte Typologie der Dokumentation in IT-Projekten [Quelle: Eigene Darstellung]

Da diese Arbeit aus Sicht eines Projektmanagers bzw. eines Anforderungsmanagers undnicht aus Sicht der IT-Entwickler geschrieben wird, konzentriert sich die nachfolgende Darstel-lung ausgehend von obiger Typologie auf den Aufbau einer Projektakte mit seinen Bestand-teilen Projekthandbuch und Projektdokumentation. Dieser Teil der Dokumentation hat fürdas gesamte Projekt eine hervorgehobene Bedeutung, da alle Projektmitglieder stets mit denrelevanten Projektinformationen versorgt werden müssen. Die Bestandteile der vornehmlichtechnisch orientierten Produktdokumentation, insbesondere der Programmdokumentation, wer-den hingegen nicht berücksichtigt. Hier arbeiten ausschließlich die Programmierer/Entwicklerder IT zusammen, die in der Regel eine eigenständige Programmdokumentation mit Kom-mentierungsregeln, automatischen Versions-Verwaltungssystemen, einem Konfigurations- undÄnderungsmanagement, Testprotokollen usw. aufbauen.27 Das Projektmanagement wie auchdie Anforderungsmanager kommen mit diesem Dokumentationstyp so gut wie gar nichtin Berührung. Sie interessieren sich lediglich für die testbaren (Zwischen-)Ergebnisse derEntwicklung sowie für die Einhaltung der terminlichen und fachlichen Vorgaben.

Einen Sonderfall der Produktdokumentation stellt allerdings die Anforderungsdokumenta-tion dar. Denn hier arbeiten die IT-Entwickler nicht autark, sondern in Zusammenarbeit mitden Anforderungsmanagern. Deshalb sollte die Anforderungsdokumentation genau wie dieProjektakte allen Projektmitgliedern zur Verfügung stehen.

27Zur Thematik der Software bzw. Programm-Dokumentation gibt es eine Vielzahl spezieller Literatur. Hierzuzählt u. a. auch Burghardt: Projektmanagement.

14

4 Regeln für den Aufbau einer effektivenDokumentation

Während in vielen Bereichen des Projektmanagements in der Regel eine ausführliche Planungerfolgt, wird das Thema „Dokumentation“ allzu gerne vernachlässigt. Tatsächlich wird oftmalsauf die Erarbeitung eines Dokumentationskonzepts in der Planungsphase gänzlich verzichtet.Verantwortlichkeiten werden ebenfalls eher selten festgelegt. Die Dokumentation erfolgt dannsozusagen „en passant“ während des Projekts, was im Grunde nicht mehr bedeutet, als dassalle anfallenden Dokumente in irgendeiner Weise gesichert werden.

Die stiefmütterliche Behandlung der Dokumentation weicht zwar durch die wachsendeBedeutung von Informations- und Wissensmanagement immer mehr auf. Doch obgleich inder Fachliteratur stets auf die Wichtigkeit einer Dokumentation verwiesen wird,28 mangelt esin vielen Fällen an konkreten Hinweisen zur Erarbeitung eines Dokumentationskonzepts.

Dies mag sicherlich auch daran liegen, dass die Anforderungen an eine Dokumentationsehr unterschiedlich sein können und es daher unmöglich ist, eine Standard-Dokumentationzu definieren. Allerdings gibt es einige grundlegende Fragestellungen, an denen man sichbeim Aufbau einer Dokumentation orientieren kann. Deshalb soll im Folgenden anhand einesBeispiels erläutert werden, wie ein schlüssiges Dokumentationskonzept entwickelt werdenkann und welche Aspekte beim Aufbau einer Dokumentation beachtet werden sollten. Dabeiwird auf die im vorigen Kapitel entwickelte Terminologie zurückgegriffen.

Das Beispiel-Projekt bezieht sich auf ein Projekt im Hessischen Rundfunk (hr), dessenZiel es ist, eine bandlose Infrastruktur29 für die Fernsehproduktion des hr aufzubauen.30

Die Entwicklung des Gesamtsystems wird größtenteils von der IT-Abteilung des hr selbstübernommen. Auf Dienstleistungen externer Anbieter wird nur teilweise zurückgegriffen.Da das Projekt den gesamten Fernsehbetrieb betrifft, sind viele unterschiedliche Fachspe-zialisten in der Projektgruppe vertreten: Eine Projektleiterin und eine Projektassistentin, einSoftware-Architekt, drei Anforderungsmanager (Produktion, Redaktion, Archiv) sowie eini-ge weitere Fachspezialisten vornehmlich aus dem IT-Bereich. Es handelt sich also um eininterdisziplinäres IT-Projekt.

Der erste Schritt hin zur Erarbeitung eines Dokumentationskonzepts war die Verständigungdarauf, was unter der „Dokumentation“ zu verstehen sei. Dabei wurde die in Kapitel 3entwickelte Typologie zu Grunde gelegt. Es wurde beschlossen, dass die Projektakte und dieAnforderungsdokumentation allen Projektmitgliedern stets zugänglich sein muss. Gleiches

28Vgl. beispielsweise Sanden: Wissensmangement, S. 456.29„Bandlos“ bedeutet, dass statt analoger Video-Bänder digitale Video-Files verwendet werden (vom bandbasier-

ten zum filebasierten Fernsehbetrieb).30Nicht alle der nachfolgend aufgeführten Beispiele zum Aufbau der Dokumentation sind tatsächlich im hr-

Projekt umgesetzt worden.

15

4 Regeln für den Aufbau einer effektiven Dokumentation

galt für das Schulungshandbuch. Die Organisation der Programmdokumentation (Versions-und Releaseverwaltungssysteme, Kommentierung des Quellkodes etc.) und der technischenAbschlussdokumentation sollte hingegen ganz in Händen der IT liegen.

Die folgenden Ausführungen zum Aufbau der Dokumentation beschränken sich auf dieProjektakte und die Anforderungsdokumentation.

4.1 Entwicklung eines Dokumentationskonzepts

Grundvoraussetzung für eine effektive Dokumentation ist ein schlüssiges Dokumentationskon-zept. Deshalb sollte in der Planungsphase in jedem Fall auch die Dokumentation berücksichtigtwerden. Bei der Erarbeitung des Dokumentationskonzepts kann man sich an folgendem Fra-genkatalog orientieren:

• Warum wird dokumentiert?

• Für wen wird dokumentiert?

• Was soll dokumentiert werden?

• Wie soll dokumentiert werden und wo werden die Dokumente aufbewahrt?

• Wer darf auf die Dokumente zugreifen und wie wird die Sicherheit der Dokumentegewährleistet?

• Wer kümmert sich um die Dokumentation?

• Wie lange müssen die Dokumente nach Projektschluss aufbewahrt werden?31

Warum wird dokumentiert?

Diese Frage wurde bereits in den vorigen Kapiteln ausführlich erläutert. Allerdings sollenan dieser Stelle dennoch kurz die grundlegenden Aufgaben der Projektakte wie auch derAnforderungsdokumentation aufgeführt werden:

• Zusammenstellung und Sicherung aller relevanten Projektdokumente sowie aller Anfor-derungsdokumente.

• Speicherung wichtiger Projekt- bzw. Anforderungsdokumente, auch über das Projekt-ende hinaus.

• Unterstützung des Projekt- bzw. Anforderungsmanagements und des Informationsflussesinnerhalb der Projektgruppe durch schnellen Zugriff auf relevante Dokumente bzw.Informationen.

31Fragen teilweise entnommen aus Nursinski: Projektdokumentation, Abschnitt: Zielsetzung.

16


• Der schnelle Zugriff auf Informationen wird vor allem durch Dokumentationsregelnerreicht, da diese die Ablage und die Struktur der Dokumente vereinheitlichen.32

Für wen wird dokumentiert?

Auch die Beantwortung dieser Frage ergibt sich aus den vorigen Kapiteln, so dass bezogen aufdas hr-Projekt folgendes gilt: Die Dokumente der Projektakte dienen dem Projektmanagementund -controlling. Zudem werden die Dokumente für die gesamte Projektgruppe gesammelt,damit sich alle Projektmitglieder stets über den aktuellen Projektstand und anstehende Termineinformieren können. Letztlich wird auch „für die Nachwelt“ gesammelt, d. h. zentrale Er-kenntnisse bezüglich des Projektmanagements sollen späteren Projektgruppen zur Verfügunggestellt werden.

Für die Anforderungsdokumentation gilt, dass in erster Linie für die Anforderungsmana-ger und den IT-Entwickler (Software-Architekten) gesammelt wird, wobei natürlich auchandere Projektmitglieder Einblick in die Anforderungsdokumentation nehmen können. DasAbschlussdokument der Anforderungsdokumentation (Lastenheft) enthält alle gewünschtenAnforderungen, die dann in der Pflichtenheftphase technisch spezifiziert werden. Das Pflich-tenheft ist die Grundlage für die konkrete Programmierung und gehört bereits in den Bereichder Programmdokumentation.

Was soll dokumentiert werden?

Dies ist eine der wichtigsten Fragen bei der Erstellung des Dokumentationskonzepts. Denn jegrößer und vielfältiger die zu erwartenden Dokument-Typen sind, desto komplexer muss auchdie Dokumentation sein. Sehr hilfreich zur Ermittlung der benötigten bzw. zu erwartendenDokumente ist das sogenannte „Projekt-Tailoring“33: In einer Checkliste werden alle (theo-retisch) möglichen Dokumente aufgeführt; hieraus wählt man dann diejenigen Dokumente,welche für das eigene Projekt benötigt bzw. erwartet werden.

Im hr existierte eine solche Checkliste noch nicht, weshalb eine eigene Liste, angelehntan ein Muster von Kitz34, entworfen wurde (siehe Tabelle 2, S. 18 und Tabelle 3, S. 19). ImGegensatz zu Kitz, der keine Unterscheidung zwischen Projekt- und Produktdokumentati-on macht, beschränkt sich die hr-Checkliste lediglich auf die Dokumente der Projektakteund der Anforderungsdokumentation. Außerdem wurde erfasst, welche Personengruppenprimär mit dem jeweiligen Dokument arbeiten und mit welchen Dateiformaten insgesamt zurechnen ist. Letzteres vor allem deshalb, um darüber im Bilde zu sein, welche Software dieProjektmitglieder zur Betrachtung und Bearbeitung der einzelnen Dokumente benötigen.

Empfehlenswert ist es, die Checkliste auch anderen Projekten zur Verfügung zu stellen.Außerdem sollte jeder neu ermittelte Dokument-Typ zur Checkliste hinzugefügt werden. Aufdiese Weise gelangt man zu einer unternehmensweiten Checklisten-Vorlage, die nach und nach

32Vgl. hierzu ausführlich Kapitel 4.3, S. 26ff.33Vgl. Kitz: IT-Projektmanagement, S. 99.34Vgl. ebd., S. 100.

17


Tabelle 2: Checkliste: Dokumente der Projektakte [Quelle: Eigene Darstellung]

ProjektakteDokument-Typ Benötigt fürArbeitsberichte Projektmanagement (PM),

alle ProjektmitgliederProtokolle PM, alleChecklisten (Risiko-Management, Projekt-Tailoring etc.) PMOffene-Punkte-Listen PM, alleÄnderungsverzeichnisse PM, alleProjekthandbuch PM, alleProjekt-Tagebuch PMProjekt-Statusbericht PMTerminpläne (Projekt-Termine, Urlaub, etc.) PM, alleAufwandsschätzung, Kosten- und Ressourcenplan PMProjektabschlussbericht PMVerwaltungsratsvorlage PM, alleProjektmarketing-Plan PM, alleFirmenangebote PM, alleInformationen/Dokumente aus anderen hr-Projekten PM, alleInformationen/Dokumente aus anderen Quellen (z. B. anderenRundfunkanstalten)

PM, alle

Dateiformate Microsoft Office (Power-point, Word, Excel), pdf, Mi-crosoft Project, verschiede-ne Bildformate (jpeg, gif)

alle theoretisch möglichen Dokumente aufführt. Besonders effektiv wird die Checkliste, wenndie einzelnen Dokumente mit einer Ordnungs-Systematik verknüpft sind, d. h. wenn für jedenDokument-Typ auch vermerkt ist, in welchem Datei-Ordner er abgelegt werden soll (z. B. Pro-tokolle der Projektgruppe in Ordnerpfad: Projektdokumentation/Protokolle/Projektgruppe).35

Mit der Auswahl aller zu erwartenden Dokumente aus der Checkliste bekommt man dieentsprechende Ordnersystematik automatisch mitgeliefert.36

35Vgl. hierzu teilweise Burghardt: Projektmanagement, S. 361f. Burghardt verfolgt mit seiner sogenannten„Auswahlordnung“ einen ähnlichen Ansatz; allerdings entspricht sein Vorgehen eher einem erweiterten Projekt-Tailoring.

36Auch für das hr-Projekt ist die Erarbeitung einer solchen Checkliste geplant. Siehe hierzu weiter untenKapitel 4.2.1, S. 24f.

18


Tabelle 3: Checkliste: Dokumente der Anforderungsdokumentation [Quelle: Eigene Darstellung]

AnforderungsdokumentationDokument-Typ Benötigt fürLeitfaden für Anforderungsmanagement Anforderungsmanager,

Software-ArchitektÄnderungsverzeichnisse Anforderungsmanager,

Software-ArchitektProtokolle Anforderungsmanager,

Software-ArchitektTerminpläne Anforderungsmanager,

Software-ArchitektIst-Analyse,textlich und modelliert in Swim-Lane Notation

Anforderungsmanager,Software-Architekt

Einzelne Anforderungen,textlich und modelliert in UML

Anforderungsmanager,Software-Architekt

Lastenheft alle Projektmitglieder

Dateiformate Microsoft Office (Powerpoint, Word,Excel), pdf, Microsoft Visio, ARIS,Html, verschiedene Bildformate (jpeg,gif)

Wie soll dokumentiert werden? Wo werden die Dokumente aufbewahrt?

Die Ergebnisse des Projekt-Tailorings haben direkten Einfluss auf das „Wie?“ der Dokumenta-tion. Vor allem hinsichtlich der Frage, ob automatische Dokumentenmanagement-Systeme37

(DMS) eingesetzt werden sollten oder nicht, bietet das Projekt-Tailoring eine erste Entschei-dungshilfe: Je größer die Anzahl der Dokumente, desto sinnvoller der Einsatz eines DMS.

Darüber hinaus ist die Entscheidung für oder gegen ein DMS von weiteren Faktorenabhängig. Existiert beispielsweise bereits ein spezielles Projekt-DMS im Unternehmen, sollteauch bei kleineren Projekten dieses als Grundlage der Dokumentation verwendet werden.Ungeeignet ist der Einsatz eines DMS dagegen, wenn der Mehrzahl der Projektmitglieder dieFunktionsweise eines DMS völlig fremd ist. Nicht zuletzt ist die Anschaffung eines DMSauch immer eine Kostenfrage, weshalb stets eine unternehmensweite Implementierung, d. h.ein gemeinsames DMS für alle Projekte im Haus, angestrebt werden sollte.

Es sei an dieser Stelle betont, dass – bei allen Vorzügen – der Einsatz eines DMS allein noch

37Eine detaillierte Darstellung der Aufgaben und Funktionalitäten von Dokumenten-Management-Systemenwürde zu weit führen, weshalb an dieser Stelle – neben den weiteren Ausführungen in diesem Kapitel – auffolgende Literatur verwiesen sei: Gulbins, Jürgen / Seyfried, Markus / Strack-Zimmermann, Hans, Dokumenten-Management, Berlin 2002 oder Zöller, Bernhard et al., Dokumenten-Management – vom Archiv zum EnterpriseContent Management, Bonn 2005.

19


keine effektive Dokumentation garantiert. Zwar übernimmt ein DMS die reine Dokumenten-ablage nahezu selbständig, doch geschieht dies ohne jegliche Prüfung des Dokumenteninhalts.Die einheitliche Gestaltung der Dokumente ist jedoch für das Informations- und Wissens-management – wie in Kapitel 4.3 noch auszuführen sein wird – von großer Bedeutung.38

Erst durch die Verknüpfung einer durchdachten Dokumentenablage mit einer einheitlichenGestaltung und Strukturierung der Dokumente erreicht die Dokumentation ihr volles Potential.Ein DMS kann diese Verknüpfung nicht leisten – statt dessen verleitet der Einsatz eines DMSvielmehr dazu, alles der „Maschine“ zu überlassen, so dass zentrale Aspekte der Dokumentati-on gänzlich vernachlässigt werden (z. B. Festlegung von Verantwortlichkeiten bezüglich derDokumentation, Regeln für die Strukturierung und Gestaltung zentraler Dokumente usw.).

Im hr-Projekt wurde letztlich beschlossen, dass der Einsatz eines DMS überdimensioniertwäre, vor allem auch da eine unternehmensweite Implementierung nicht zur Debatte stand.Stattdessen sollten die Projektakte und die Anforderungsdokumentation in einer allen Projekt-mitgliedern vertrauten Datei-Ordner-Struktur des Windows-Explorers abgebildet werden.

Wer darf auf die Dokumente zugreifen? Wie wird die Sicherheit derDokumente gewährleistet?

Je nach Projektsituation können hier sehr unterschiedliche Anforderungen bestehen, weshalbzunächst folgende zentrale Punkte geklärt werden müssen:

• Sind die Projektmitglieder räumlich weit verteilt?

• Steht allen Projektmitglieder die benötigte Technik zur Verfügung, um auf die Projek-takte zugreifen zu können?

• Gibt es unterschiedliche Profile hinsichtlich des Lese- und Schreibzugriffs auf Doku-mente?

• Wie „transportabel“ muss die Projektakte sein?

• Benötigen auch Nicht-Projektmitglieder Zugriff auf die Projektakte?

• Wie sicher sind die Daten? Wie sieht die Backup-Strategie aus?

Auch an dieser Stelle kann man zur Einsicht gelangen, dass der Einsatz eines DMS sinnvollist. Denn für sämtliche oben genannte Fälle bieten moderne DMS unkomplizierte Lösungen:Ortsunabhängiger Zugriff über eine Web-Schnittstelle, Administrierungs-Tools zur Vergabeindividuell angepasster Zugriffsrechte, moderne Backup-Systeme zur Gewährleistung einerhohen Datensicherheit.39

Im hr-Projekt sind die einzelnen Mitglieder zwar räumlich verteilt, doch da es sich umein hr-internes Projekt handelt, haben alle Projektmitglieder Zugriff auf das firmeninterne38Vgl. hierzu ebenfalls Abschnitt „Wer kümmert sich um die Dokumentation“, S. 21f.39Weiterführende Literatur zum Thema DMS siehe Fußnote 37.

20


Netzwerk. Um den Projektmitgliedern den Zugriff auf die Projektakte (in Form einer Datei-Ordner-Struktur) zu ermöglichen, wurde ein eigenes Gruppen-Laufwerk eingerichtet, aufwelches alle Projektmitglieder Schreib- und Lesezugriff haben. Im Gegensatz zu einem DMSbesteht allerdings nicht die Möglichkeit auch außerhalb des hr-Netzes auf die Dokumentezuzugreifen und diese zu bearbeiten. „Transportabel“ wird die Projektakte aber dadurch, dassder Gruppenordner bei Bedarf z. B. auf einen USB-Stick kopiert werden kann. Allerdingssollten an solchen Kopien niemals Änderungen vorgenommen werden, da eine Synchronisationmit der Ursprungs-Projektakte auf dem Gruppenlaufwerk nur schwer möglich ist.

Die Sicherung der Projektakte erfolgt über den hauseigenen IT-Betrieb, der standardmäßigalle im hr-Netz abgespeicherten Daten auf ein Backup-System spiegelt. Zusätzlich wird einmalim Monat eine Sicherungskopie auf eine lokale Festplatte vorgenommen.

Wer kümmert sich um die Dokumentation?

Auch diese Frage muss bei der Entwicklung eines Dokumentationskonzepts unbedingt be-rücksichtigt werden. Stehen innerhalb des Projekts keinerlei Ressourcen für die Pflege derDokumentation zur Verfügung, sollte der Einsatz eines DMS erwogen werden, um die Grund-funktionen der Dokumentation (Speicherung und Verfügbarkeit der Dokumente) möglichsteffektiv nutzen zu können. Wesentlich sinnvoller – und beim Verzicht auf ein DMS prak-tisch unvermeidbar – ist es, einen „Dokumentationsbeauftragten“ zu benennen, der für dieDokumentation des Projekts verantwortlich ist.

Der „Dokumentationsbeauftragte“ hat die Aufgabe neu angefallene Dokumente in die be-stehende Ordner-Struktur einzupflegen, Datei-Namen gegebenenfalls anzupassen sowie nichtmehr benötigte Dokumente (nach Rücksprache mit der Projektgruppe) zu löschen. Außerdemist er für alle Änderungen an der Systematik zuständig, wodurch die Einheitlichkeit der Ablagegewährleistet wird. Durch die regelmäßige Prüfung werden mögliche (Ordnungs-)Problemeschnell erkannt. Zudem hält man durch die regelmäßige Kassation die Dokumentation einiger-maßen schlank.

Den größten Vorteil und Nutzen bietet die Benennung eines „Dokumentationsbeauftragten“vor allem dann, wenn er – wie bereits angedeutet40 – zusätzlich die Verantwortung für die Do-kumentationsregeln, wie z. B. die einheitliche formale Gestaltung der Dokumente, übernimmt.Auf diese Weise wird sichergestellt, dass nicht nur die reine Ablage der Dokumente, sondernauch die Strukturierung des Dokumenteninhalts einheitlich und konsistent ist. Selbst bei einemsimplen Dokument wie einem Besprechungsprotokoll kann es verwirrend sein, wenn wichtigeInformationen (z. B. Teilnehmer, Datum etc.) nicht immer an derselben Stelle zu finden sind.41

Hier zeigt die Dokumentation ihre wirkliche Stärke für das Wissensmanagement. Denn jestrukturierter die Dokumente gestaltet sind, desto schneller gelangt man zur gewünschtenInformation. Der Dokumentationsbeauftragte hat deshalb die Aufgabe für regelmäßig anfal-

40Siehe Abschnitt „Wie soll dokumentiert werden?“, S. 20.41Ein Beispiel für eine Protokoll-Vorlage findet sich im Anhang; siehe Anhang: Dokumentvorlage Protokoll,

S. 34.

21


lende Dokumente Vorlagen zu entwickeln.42 Außerdem prüft er neu eingegangene Dokumenteauf ihre formale Gestaltung, bringt sie bei Bedarf in die richtige Struktur und „ermahnt“ dieProjektmitglieder zur Einheitlichkeit.

„Dokumentationsbeauftragter“ bedeutet also sehr viel mehr als reiner Verwalter der Doku-mente. In seinen vielfältigen Aufgaben zeigt sich zudem, warum ein DMS allein noch keineeffektive Dokumentation ausmacht. Für das Informations- und Wissensmanagement ist esnicht nur wichtig schnell an die gewünschten Dokumente zu kommen, sondern auch sich inden entsprechenden Dokumenten schnell zurecht zu finden.

Im hr-Projekt sind zwei Projektmitglieder zusätzlich zu ihrer sonstigen Funktion mit derDokumentation betraut worden.43 Sie sind damit für die Pflege und die einheitliche Gestaltungder Dokumente verantwortlich. Die doppelte Zuständigkeit entlastet zum einen, da die Arbeitverteilt wird; zum anderen wird sichergestellt, dass bei Abwesenheit eines Dokumentationsbe-auftragten die regelmäßige Pflege der Projektakte und der Anforderungsdokumentation nichtins Stocken gerät.

Jedes Projektmitglied ist angehalten, selbst erstellte Dokumente an einen der Dokumentati-onsbeauftragten zu schicken bzw. in einem „Inbox“-Ordner abzulegen.44 Der Dokumentations-beauftragte überprüft die formale Gestaltung des Dokuments, passt es gegebenenfalls an undordnet es schließlich in die bestehende Ordnersystematik ein. Im Übrigen wird durch diesesProzedere auch vermieden, dass neue Dokumente einfach übersehen werden.

Wie lange müssen die Dokumente nach Projektschluss aufbewahrt werden?

Auch diese Frage hat Auswirkungen auf den Aufbau der Dokumentation. So sollten diejenigenDokumente, welche über das Projektende hinaus von Relevanz sein könnten, ermittelt undspeziell berücksichtigt werden.

Viele, auf Projektarbeit spezialisierte Unternehmen haben den Nutzen einer Erfahrungssiche-rung bereits erkannt und zu diesem Zweck eigene Projekterfahrungsdatenbanken aufgebaut, dieeine Vielzahl von Daten zum Projektmanagement beinhalten.45 Existiert im Unternehmen keineProjekterfahrungsdatenbank, wie beim hr-Projekt der Fall, sollte bei Projektabschluss zumin-dest ein Erfahrungsbericht angefertigt werden, in dem alle wichtigen Ergebnisse und Erkennt-nisse zum Projektmanagement gebündelt wiedergegeben werden (z. B. Risiken, Fehler, Erfolgeetc.).46 Der Abschlussbericht kann durch ausgewählte Dokumente, beispielsweise durch dasProjekthandbuch, ergänzt werden. Im hr-Projekt wurden bislang folgende Dokumente alsaufbewahrungswürdig erachtet: Projekthandbuch, Checkliste Risiko-Management, ChecklisteProjekt-Tailoring, Projektmarketing-Plan sowie alle entwickelten Dokument-Vorlagen.42Vgl. hierzu auch Kapitel 4.3, S. 28f. Beispiele für Dokument-Vorlagen sind im Anhang ab Seite 33 vorhanden.43Mit Dokumentation ist hier sowohl die Projektakte als auch die Anforderungsdokumentation gemeint. Da für

die Anforderungsdokumente spezielle Kenntnisse notwendig sind, kann es unter Umständen notwendig sein,einen speziellen „Anforderungsdokumentationsbeauftragten“ zu benennen. Vgl. hierzu ausführlich Kapitel 4.3,S. 29.

44Vgl. hierzu weiter unten Kapitel 4.2.1, S. 23f.45Vgl. Burghardt: Projektmanagement, S. 395.46Vgl. ebd., S. 395.

22


Damit ist der letzte Punkt des Fragenkatalogs beantwortet, so dass nun als Ergebnis ein denprojektspezifischen Bedingungen angepasstes Dokumentationskonzept vorliegt. Auf dieserGrundlage kann der konkrete Aufbau der Dokumentation erfolgen.

4.2 Struktur der Dokumentation im hr -Projekt

Für das hr-Projekt wurde im Dokumentationskonzept festgelegt, dass die Projektakte unddie Anforderungsdokumentation auf einer Datei-Ordner-Systematik im Windows-Exploreraufgebaut werden soll. Hieraus ergibt sich für die Grundstruktur der Dokumentation folgendeKonsequenz: Als Ordnungsprinzip kommt nur eine Klassifikation in Betracht, da nur beiihr Ordnungssystem und Dokumentenspeicher zusammengefasst werden können.47 Bei derKlassifikation wird das zu dokumentierende Sachgebiet in einzelne, getrennte Sachverhalte(Klassen) eingeteilt, was bildlich gesprochen einer Sortierung nach Fächern oder Schubladeneines Schranks entspricht.48 Die Klassifikation ist die einfachste und praktischste Ordnungs-systematik, weil sie sozusagen dem „natürlichen Ordnungsprinzip“ entspricht.49

Da es sich beim hr-Projekt um ein thematisch recht überschaubares Sachgebiet handelt, wardie Ausarbeitung einer hierarchischen Ordnungssystematik nicht allzu aufwendig, zumal siein weiten Teilen der typischen Schriftenablage eines Büros nachempfunden werden konnte.Um die einzelnen Klassen möglichst intuitiv zu gestalten, wurde auf eine Notation bzw. einNummernsystem verzichtet. Dies hat zudem den Vorteil, dass eventuelle Änderungen bzw.Erweiterungen der Ordnungsstruktur relativ problemlos vorgenommen werden können.

4.2.1 Struktur der Projekt- und der Anforderungsdokumentation

In Abbildung 3 (S. 24) ist ein Auszug aus der Ordner-Hierarchie des hr-Projekts abgebildet.Der in Kapitel 3 erarbeiteten Typologie50 Folge leistend, wurde jeweils ein eigener Haupt-Ordner für die Anforderungsdokumentation bzw. für die Projektakte angelegt. Der Haupt-Ordner Projektakte unterscheidet zudem den Unter-Ordner „Projekthandbuch“ von den übrigenUnter-Ordnern, die typologisch gesehen allesamt der Projektdokumentation zuzurechen sind.Sämtliche Projektmitglieder haben auf die Haupt- und ihre Unter-Ordner Zugriff. Währendder Ordner „Projektmanagement“ vornehmlich für die Projektleitung gedacht ist, enthaltenalle anderen Ordner Dokumente, die für alle Projektmitglieder relevant sind bzw. sein können.

Neue Dokumente müssen zunächst im „Inbox“-Ordner abgespeichert werden. Der Doku-mentationsbeauftragte sortiert dann die Dokumente in die entsprechenden Ordner ein.51 Umstets über den aktuellen Projektstand informiert zu sein und um mit der Struktur der Projektakte

47Vgl. Gaus: Ordnungslehre, S. 69.48Vgl. ebd., S. 67.49Vgl. ebd., S. 67.50Vgl. Abbildung 2, S. 14.51Wie die einzelnen Dokumente bzw. Dateien bezeichnet werden sollen, d. h. nach welchen Regeln die Datei-

Namen zu vergeben sind, wird im Themenkomplex „Dokumentationsregeln“ (Kapitel 4.3, S. 27f.) erläutert.

23


Abbildung 3: Ordnungshierarchie Projektakte und Anforderungsdokumentation (Auszug) [Quelle:Eigene Darstellung]

vertraut zu werden, sind alle Projektmitglieder angehalten, in regelmäßigen Abständen zumin-dest das Projekthandbuch und die „Inbox“ aufzusuchen. Bei besonders wichtigen Dokumenteninformiert der Dokumentationsbeauftragte die Projektmitglieder zudem per E-Mail über neueDokumente bzw. Änderungen in der Projektakte.

Es würde an dieser Stelle zu weit führen, die gesamte Ordner-Hierarchie des hr-Projekts zuerläutern, zumal die bislang entwickelte Systematik keinesfalls endgültigen Charakter hat. Dahinsichtlich der Klassifikation auf keinerlei Erfahrungswerte zurückgegriffen werden kann, istdie Wahrscheinlichkeit, dass im Projektverlauf Änderungen an der Systematik vorgenommenwerden müssen, sehr hoch. Aus diesem Grund existieren bei Unternehmen, die vornehmlichProjektarbeit betreiben, in der Regel Standardsystematiken, die je nach Bedarf verkleinertoder erweitert werden können.52

Im hr existiert eine solche standardisierte Vorlage noch nicht. Es ist deshalb geplant, dieerstellte Ordnungssystematik am Projektende abschließend zu bewerten und hieraus eineStandardsystematik zu entwickeln. In einem zweiten Schritt kann dann die Ordnerstruktur,wie oben bereits ausgeführt,53 mit den Dokument-Typen der Checkliste für das Projekt-Tailoring verknüpft werden. Eine solche Checklisten-Vorlage würde nachfolgenden Projektenbeim Aufbau einer Dokumentation eine große Arbeitserleichterung sein: Man wählt die

52Vgl. Burghardt: Projektmanagement, S. 356ff.53Vgl. Kapitel 4.1, S. 18.

24


zu erwartenden Dokument-Typen aus der Checkliste aus, hat damit gleichzeitig die direkteKontrolle, dass keine wichtigen Dokumente vergessen werden und bekommt nach Auswahlder Dokumente die entsprechende Ordnerstruktur automatisch mitgeliefert.

4.2.2 Struktur des Projekthandbuchs

Im Projekthandbuch werden die wichtigsten Projektinformationen in Form eines Gesamt-dokuments zusammengeführt: Alle wesentlichen Planungsdaten (z. B. Projektstrukturplan,Terminplan, Arbeitspakete) sowie die projektspezifischen Rahmenbedingungen (z. B. Projekt-auftrag, Projektziele, Organisationsstruktur) werden hier aufgeführt, so dass die zentralenInformationen nicht jedes Mal aus den Einzeldokumenten der Projektdokumentation zusam-mengesucht werden müssen.

Abbildung 4: Struktur des Projekthandbuchs (Auszug) [Quelle: Projekt „Gesamtkonzept Bandlos“,Hessischer Rundfunk]

Das Projekthandbuch ist eines der wichtigsten projektinternen Dokumente und sollte deshalbregelmäßig aktualisiert bzw. bei wichtigen Ereignissen wie der Erreichung eines Meilensteinsauch versioniert werden.54 Zum Zwecke der Versionierung gibt es im hr-Projekt eine so-genannte „Entwicklungsversion“ des Projekthandbuchs. In diesem Dokument können alleProjektmitglieder bei Bedarf Änderungen vornehmen, wobei jede Änderung in einem Än-derungsverzeichnis dokumentiert werden muss.55 Die „Entwicklungsversion“ stellt somitimmer die aktuelle Version des Projekthandbuchs dar. Steht nun eine Versionierung des Pro-jekthandbuchs an (die Versionierung wird von der Projektgruppe beschlossen), fertigt derDokumentationsbeauftragte eine Kopie der „Entwicklungsversion“ an und vergibt dieser ei-ne Versionsnummer. An diesem Dokument werden dann keine weiteren Änderungen mehr54Vgl. Kitz: IT-Projektmanagement, S. 103.55Eine beispielhafte Vorlage für ein Änderungsverzeichnis ist im Anhang vorhanden, siehe Anhang: Dokument-

vorlage Änderungsverzeichnis, S. 33.

25


vorgenommen. Durch die regelmäßige Versionierung des Projekthandbuchs kann jederzeitnachvollzogen werden, welchen Stand das Projekt zum Zeitpunkt X hatte. Dies kann inbestimmten Situationen, etwa bei der Analyse von Krisensituationen, sehr hilfreich sein.

Da es sich beim Projekthandbuch um eine einzelne Datei (etwa ein Word-Dokument)handelt, wird keine Ordnersystematik benötigt, sondern das Dokument selbst muss strukturiertwerden. Im hr-Projekt konnte hierbei auf die Vorlage eines externen Projektmanagement-Unternehmens zurückgegriffen werden. Wie die Checkliste beim Projekt-Tailoring erleichtertdie vorgegebene Struktur nicht nur den Aufbau des Projekthandbuchs, sondern stellt zugleichsicher, dass keine wesentlichen Punkte übersehen werden. Deshalb sollte die Vorlage unbedingtauch anderen Projekten zur Verfügung gestellt werden und bei Bedarf um neue Punkte erweitertwerden.

Einen Eindruck vom Aufbau des Projekthandbuchs im hr-Projekt gibt die Abbildung 4(S. 25), in dem Teile des Inhaltsverzeichnisses abgebildet sind.56 Sinnvoll ist es übrigens dasProjekthandbuch durch Verweise mit der Projektdokumentation zu verknüpfen. So werdenbeispielsweise bei Punkt 2.2 „Protokolle“ nicht die jeweiligen Protokolle aufgeführt, sondernLinks auf die entsprechenden Dokumente in der Projektdokumentation gesetzt.

Im hr-Projekt noch nicht verwirklicht, generell aber auf jeden Fall empfehlenswert, ist dieAufnahme eines Kapitels zum Thema „Dokumentation“.57 Hierin sollten Sinn und Zweckder Dokumentation sowie die zentralen Aspekte des entwickelten Dokumentationskonzeptsbeschrieben werden. Ebenfalls sollten die grundlegenden Dokumentationsregeln erläutertoder noch besser auf ein „Dokumentationshandbuch“58 verwiesen werden, in welchem dieeinzelnen Dokumentationsregeln aufgeführt sind.

4.3 Die Bedeutung von Dokumentationsregeln

Die Dokumentationsregeln sind das Herzstück einer effektiven Dokumentation. Erst durch dieVorgabe von Regeln, deren Ziel es ist eine einheitliche Ablage und Gestaltung der Dokumentezu gewährleisten, entwickelt sich die Dokumentation von einer reinen Schriftenablage zu einemwichtigen Baustein für das Informations- und Wissensmanagement in Projekten. Ohne dieEtablierung von Dokumentationsregeln ist jede noch so ausgeklügelte Dokumentationsstrukturletztlich zum Scheitern verurteilt.

Dokumentationsregeln können prinzipiell in zwei unterschiedliche Kategorien eingeteiltwerden: „Regeln zur Dokumentenablage“ und „Regeln zur Dokumentengestaltung“. DerGroßteil der wichtigsten Regeln zur Dokumentenablage wurde bereits im Fragenkatalogbeantwortet.59 Zusammengefasst lauten die „Ablage-Regeln“ für das hr-Projekt wie folgt:

56Wie schon bei der Projektdokumentation wird im Rahmen dieser Arbeit auf eine ausführliche Erläuterung dereinzelnen Punkte verzichtet, da die Ausgestaltung des Projekthandbuchs ohnehin je nach Projekt angepasstwerden muss.

57Vgl. Pannenbäcker: Dokumentationsmanagement, S. 1035.58Vgl. hierzu auch Kapitel 4.3, S. 29.59Vgl. Kapitel 4.1, S. 16ff.

26


• Änderungen an der Ordnungs- bzw. Ablagesystematik nimmt nach Absprache mit derProjektgruppe immer der Dokumentationsbeauftragte vor.

• Für die Kassation nicht mehr relevanter Dokumente ist ebenfalls der Dokumentationsbe-auftragte verantwortlich.

• Neue Dokumente werden zunächst im Inbox-Ordner abgespeichert; der Dokumentati-onsbeauftragte nimmt dann die Einordnung in die Systematik vor.

• Beim Eingang wichtiger neuer Dokumente bzw. wichtiger Änderungen an der Systema-tik informiert der Dokumentationsbeauftragte die Projektmitglieder per E-Mail.

• Für regelmäßig anfallende Dokumente, wie z. B. Protokolle, sollte bei der Benennungder Datei ein einheitlicher „Datei-Schlüssel“ verwendet werden.60

Abbildung 5: Muster für Datei-Schlüssel [Quelle: Eigene Darstellung]

60Vgl. Burghardt: Projektmanagement, S. 356.

27


Für die Einhaltung der letztgenannten Ablage-Regel ist ebenfalls der Dokumentationsbeauf-tragte zuständig. Sollte ein Projektmitglied sein Dokument mit einem falschen Datei-Schlüsselin der „Inbox“ abgelegt haben, muss der Dokumentationsbeauftragte diesen entsprechend derKonvention ändern.

Die Gestaltung des Datei-Schlüssels ist beliebig. Wichtig ist letztlich nur, dass er immernach demselben Muster aufgebaut ist. Auf diese Weise wird das Suchen („Browsen“) nachbestimmten Dokumenten erheblich erleichtert, da grundlegende Informationen zum Inhalteines Dokuments schnell im Blick sind. Ein mögliches Muster für den Datei-Schlüssel ist inAbbildung 5 (S. 27) dargestellt.

Im Gegensatz zu den „Ablage-Regeln“ beziehen sich die „Regeln zur Dokumentengestal-tung“ auf die formale Gestaltung des Dokumenteninhalts. Wie bereits am Beispiel einesProtokolls verdeutlicht wurde,61 bringt die einheitliche Strukturierung der Dokumente einenerheblichen Informationsgewinn mit sich. Deshalb sollten für regelmäßig wiederkehrendeDokument-Typen Vorlagen erstellt werden, wobei prinzipiell alle Projektmitglieder Einflussauf die Gestaltung der Vorlage nehmen können. Für die Überwachung der Einheitlichkeitsowie etwaige Veränderungen an der Vorlage sollte aber allein der Dokumentationsbeauftragtezuständig sein.

Einen Spezialfall hinsichtlich der Dokumentengestaltungs-Regeln stellt die Anforderungs-dokumentation dar, wobei die Bedeutung einer einheitlichen Strukturierung der Dokumente fürdas Wissensmanagement hier besonders deutlich wird. Im hr-Projekt werden zur Ermittlungund Dokumentation der Anforderungen mehrere Werkzeuge verwendet. Für die Ist-Analysewerden die Geschäfts-Prozesse sowohl textlich (strukturierte Word-Dokumente) als auchgrafisch (Swim-Lane-Grafiken modelliert mit Microsoft Visio) dargestellt. Für beide Elemente– Text und Grafik – wurden jeweils Vorlagen entwickelt, so dass jeder identifizierte Workflowimmer auf die gleiche Weise dokumentiert wird.62

Auch für die Dokumentation der noch zu ermittelnden, einzelnen Anforderungen (Soll-Analyse) werden sowohl grafische als auch textliche Darstellungsformen verwendet: Diagram-me in Notation der Unified Modeling Language (UML) (modelliert mit Microsoft Visio) bzw.strukturierte Word-Dokumente. Auch hierfür werden einheitliche Vorlagen entwickelt.63

Durch die Mischung von textlichen und grafischen Methoden können die Anforderungensehr detailliert und dennoch verständlich beschrieben werden. Die grafischen Darstellungenwie UML oder Swim-Lane sorgen durch Notations-Regeln bereits für ein hohes Maß anEinheitlichkeit und Verständlichkeit. Durch die strukturierten Textdokumente wird dieserEffekt zusätzlich verstärkt.

Die Vorlagen ermöglichen es, eigenes Wissen verständlicher zu formulieren, da Informatio-nen strukturiert „zu Papier“ gebracht werden müssen. Dies wiederum fördert den Wissens-transfer zwischen Anforderungsmanager und IT-Entwickler, da fremde Prozesse durch dieeinheitliche textliche und grafische Darstellung verständlicher werden. Durch die verbesserte

61Vgl. Kapitel 4.1 „Wer kümmert sich um die Dokumentation“, S. 21.62Siehe hierzu Anhang: Dokumentvorlage Textbeschreibung Swim-Lane-Prozesse, S. 35 bzw. Dokumentvorlage

Swim-Lane-Grafik, S. 36.63Siehe hierzu Anhang: Dokumentvorlage UML-Use-Case, S. 37.

28


Kommunikation wird die Gefahr von Missverständnissen bei der Anforderungsanalyse deut-lich reduziert. Nicht zuletzt bietet die Darstellung in UML eine hervorragende Grundlage fürdie technische Spezifizierung der Anforderungen in der Pflichtenheftphase.

Um eine einheitliche Dokumentation der Anforderungen gewährleisten zu können, ist dieBenennung eines „Anforderungsdokumentationsbeauftragten“ zwingend erforderlich. Ihmfällt hierbei vor allem die Rolle eines „Reviewers“ (Prüfers) zu, der in Abstimmung mit denAnforderungsmanagern und dem Software-Architekten dafür Sorge trägt, dass alle Anforde-rungen eindeutig dokumentiert sind. Der „Anforderungsdokumentationsbeauftragte“ mussmit den entsprechenden Modellierungs-Methoden wie UML bestens vertraut sein. Außer-dem muss bedacht werden, dass für ihn gerade der Prozess des „Reviews“ einen erheblichenZeitaufwand bedeutet. Es kann deshalb notwendig sein, einen speziellen „Anforderungsdoku-mentationsbeauftragten“ zu benennen. Nach Möglichkeit sollte aber darauf geachtet werden,dass der Dokumentationsbeauftragte ebenfalls die Rolle des „Anforderungsdokumentations-beauftragten“ übernehmen kann. Im hr-Projekt sind dementsprechend Dokumentations- undAnforderungsdokumentationsbeauftragter ein und dieselbe Person.

Alle erarbeiteten Dokument-Vorlagen sollten in einem eigenen Ordner abgespeichert wer-den. Gleiches gilt selbstverständlich für die Vorlagen der Projektakte. Außerdem empfiehlt essich die einzelnen Dokumentationsregeln in einem „Dokumentationshandbuch“ zu sammeln,welches bei Unklarheiten zu Rate gezogen werden kann. Ein solches Handbuch erleichtertzudem die Einarbeitung in die Dokumentation, beispielsweise wenn ein neues Projektmitgliedhinzukommt. Letztlich sollte auch erwogen werden, nach Projektabschluss das „Dokumen-tationshandbuch“ und die entwickelten Dokument-Vorlagen zu standardisieren, damit diesenachfolgenden Projekten als Vorlage zur Verfügung gestellt werden können.

29

5 Schluss

Die Untersuchung hat gezeigt, dass die „Dokumentation in interdisziplinären IT-Projekten“nicht nur als Randthema zu betrachten ist. Sie bildet vielmehr einen zentralen Baustein imkomplexen Gefüge des IT-Projektmanagements. Besonders im Kontext von Informations- undWissensmanagement erfüllt die Dokumentation ein großes Spektrum vielfältiger Aufgaben.Sie gewährleistet die Speicherung aller relevanten Dokumente, wodurch effektives Projekt-und Informationsmanagement überhaupt erst möglich wird. Gleichzeitig wird auch sicherge-stellt, dass das erarbeitete Wissen nicht verloren geht, wovon nachfolgende Projekte profitierenkönnen. Einen wichtigen Beitrag zum Wissensmanagement leisten zudem die Dokumentati-onsregeln, durch welche einerseits der schnelle Zugriff auf Informationen gewährleistet wirdund andererseits Wissen in strukturierter, einheitlicher Form dokumentiert wird.

Im Verlaufe dieser Arbeit hat sich gezeigt, wie wichtig eine begriffliche Abgrenzung un-terschiedlicher Dokumentationstypen ist. Denn gerade bei interdisziplinären IT-Projektenbestehen je nach Personengruppe und Projektphase ganz unterschiedliche Anforderungen andie Dokumentation. Erst nach der Erarbeitung einer speziellen Dokumentations-Typologie, mitihren Haupt-Typen Projektakte und Produktdokumentation, konnten diejenigen Dokumentati-onstypen identifiziert werden, die für das Projektmanagement sowie für das Informations- undWissensmanagement von hervorgehobener Bedeutung sind: die Anforderungsdokumentationund die Projektakte, mit ihren Bestandteilen Projekthandbuch und Projektdokumentation.Die Programm- und Abschlussdokumentation hingegen sind vornehmlich für die konkreteSoftware-Programmierung von Relevanz.

Die entwickelte Dokumentations-Typologie kann als erste Diskussionsgrundlage prinzipiellfür jede Art von interdisziplinären IT-Projekt nützlich sein. Es sei hier aber auch erwähnt,dass die Typologie in erster Linie zur Begriffseindeutigkeit innerhalb dieser Arbeit entwickeltwurde und deshalb keinen Anspruch auf Vollständigkeit erhebt.

Beim praktischen Aufbau einer „Dokumentation“ ist vor allem darauf zu achten, dass inder Planungsphase ein stringentes Dokumentationskonzept erarbeitet wird. Hilfreich bei derEntwicklung des Dokumentationskonzepts kann ein Fragenkatalog sein, wie er in Kapitel 4.1vorgestellt wurde. Anhand des hr-Beispielprojekts konnte eine Auswahl möglicher Strategienund Werkzeuge sowie ihre konkrete Ausgestaltung vorgestellt werden (Verzicht auf ein DMS,Projekt-Tailoring, Grundstruktur der Projektakte, Dokumentationsregeln usw.). Zahlreiche wei-tere Varianten sind hier denkbar – entscheidend ist letztlich, dass die Auswahl der Instrumenteden jeweiligen Projektbedingungen optimal angepasst ist.

Eine grundlegende Bedeutung bei der Etablierung einer effektiven Dokumentation kommtdem „Dokumentationsbeauftragten“ zu – und zwar unabhängig davon, ob ein DMS zumEinsatz kommt oder nicht. Denn erst durch die Vorgabe und Überwachung von Dokumenta-tionsregeln kann eine einheitliche Dokumentation garantiert werden. Ein DMS leistet dies

30

5 Schluss

ausschließlich auf der Ebene der Dokumentenablage. Was die einheitliche formale Gestaltungund Strukturierung des Dokumenteninhalts betrifft, kann ein DMS einen Menschen (noch)nicht ersetzen. Ihr volles Potential schöpft die Dokumentation jedenfalls erst aus, wenn einesystematische Ablage und eine einheitliche Gestaltung der Dokumente gewährleistet sind.

Aufgrund der Komplexität moderner IT-Lösungen bei gleichzeitig erhöhten Ansprüchenhinsichtlich der Anwenderfreundlichkeit ist es nicht unwahrscheinlich, dass der interdiszi-plinäre Charakter von IT-Projekten weiter zunehmen wird. Der Bedarf an einem effektivenInformations- und Wissensmanagement wird dadurch ebenfalls steigen. Das kann sich wieder-um positiv auf den (immer noch geringen) Stellenwert der „Dokumentation“ auswirken.

Durchaus vorstellbar ist deshalb, dass das Profil des Dokumentations-Spezialisten vermehrtauch im IT-Projektbereich auf Interesse stößt. Insbesondere wenn zusätzlich Kenntnisse beider Ermittlung und Modellierung von Anforderungen vorgewiesen werden können. Wasdie theoretische Auseinandersetzung mit dem Thema „Dokumentation in Projekten“ betrifft,wären weiterführende Arbeiten gerade aus dem informationswissenschaftlichen Bereich sicher-lich wünschenswert. Besonders in Bezug auf eindeutige Begriffsdefinitionen und praktischeUmsetzungsstrategien besteht in der Fachliteratur ein erhöhter Nachholbedarf.

31

Literaturverzeichnis

Angermeier, Georg, Projektmanagement-Glossar. Projekthandbuch, Eintrag im Glossarder Internetzeitschrift Projektmagazin – Das Fachmagazin im Internet für erfolgreichesProjektmanagement, zuletzt besucht am 16.08.2007,<www.projektmagazin.de/glossar/gl-0329.html>.

Burghardt, Manfred, Projektmanagement. Leitfaden für die Planung, Überwachung undSteuerung von Entwicklungsprojekten, München / Erlangen 31995.

Capurro, Rafael, Grundfragen des Wissensmanagements. Kapitel IV, zuletzt besucht am16.08.2007,<www.capurro.de/WM/bausteine.htm>.

Frick, Andreas, Evolutionäres Projektmanagement – Mit neuem Denken zum Projekterfolg,in: ExperPraxis 2003/2004, S. 90-93.

Gaus, Wilhelm, Dokumentations- und Ordnungslehre. Theorie und Praxis des InformationRetrieval, Berlin 32000.

Hessischer Rundfunk, Dokumentation Projekt „Gesamtkonzept Bandlos“, diverse Dokument-Vorlagen, Frankfurt am Main 2007.

Kitz, Andreas, IT-Projektmanagement, Bonn 2004.

Litke, Hans-D., Projektmanagement. Methoden, Techniken, Verhaltensweisen, München /Ulm 42004.

Nursinski, André / Wagner, Michael / Weinmann, Markus, Projektdokumentation, Eintragim WiKi der Wirtschaftsinformatik der Universität Erlangen-Nürnberg, zuletzt geändert am10.12.2007,<www.wi3.uni-erlangen.de/anwendungen/wiwiki/wiki/Kategorie:Projektdokumentation>.

Pannenbäcker, Klaus, Dokumentationsmanagement, in: RKW (Hrsg.), ProjektmanagementFachmann, Bd. 2, Eschborn 51999, S. 1029-1052.

Probst, Gilbert / Raub, Steffen / Romhardt, Kai, Wissen managen. Wie Unternehmen ihrewertvollste Ressource optimal nutzen, Frankfurt am Main 21998.

Sanden, Heike, Die Rolle von Wissensmanagement in Projekten, in: Bernecker, Michael /Eckrich, Klaus (Hrsg.), Handbuch Projektmanagement, München 2003, S. 452-468.

32

Anhang

Alle nachfolgend aufgeführten Dokumentvorlagen wurden im Rahmen des Projekts „Gesamt-konzept Bandlos“ im Hessischen Rundfunk entwickelt.

Dokumentvorlage Änderungsverzeichnis

ANFORDERUNGSMANAGEMENT ÄNDERUNGSVERZEICHNIS

ÄNDERUNGSVERZEICHNIS DATUM ÄNDERUNG WER

33

Anhang

Dokumentvorlage Protokoll

Ergebnisprotokoll der x. Sitzung der Projektgruppe am Donnerstag, den tt.mm.jjjj Ort und Zeit:

Teilnehmer:Verteiler:

Mitglieder:

Teilnehmer Steuerungsgruppe:

Entschuldigt:

Gäste:

Thema Zuständig-keit

1.

2.

34

Anhang

Dokumentvorlage Textbeschreibung Swim-Lane-Prozesse

LEVEL X – Name

STARTEREIGNIS 1 Textliche Beschreibung PROZESSNAME 2 3 Textliche Beschreibung !!! AUSNAHME-

PROZESS: 4 5 6

35

Anhang

Dokumentvorlage Swim-Lane-Grafik

36

Anhang

Dokumentvorlage UML-Use-Case

37

Documents

Aufbau und Nutzen einer Dokumentation in ...fiz1.fh-potsdam.de/volltext/diplome/07425.pdf · durch ein Projektmanagement kaum noch vorstellbar. Die Komplexität moderner IT-Projekte