Projektdokumentation

Wer heute Dokumentationen erstellt, muss mehrere Dinge unter einen Hut bringen. Sie sollten verschiedene Phasen eines Projekt begleiten, unterschiedliche Themen mit geeigneter Tiefe beschreiben und modular die Bearbeitung durch mehrere Autoren unterstützen. Dies erreichen Sie natürlich nicht durch ein großes monolithisches Dokument sondern eher durch mehrere Dokumente, die miteinander verbunden sind.

Leser und Autoren

Unterschiedliche Personen erstellen und Pflegen die Dokumentationen. Es ist dabei unerheblich, ob die Person beim Kunde oder Dienstleister arbeitet:

  • Projektleitung und Steuerung
    Organisiert und kontrolliert den Projektfortschritt und muss nicht technisch orientiert sein.
  • Infrastruktur Consultant
    Diese Personen stellen die maßgeblichen Konzepte, stellen Varianten und Alternativen gegenüber und begleiten den Entscheidungsprozess um danach die festgelegten Konzepte auszuarbeiten.
  • Technischer Consultant
    Diese Personen übernehmen die vorgegebenen Konzepte und arbeiten Sie bezüglich der Umsetzung aus. Dazu gehören Server, Sizing, Placement, Migrationswege, Aufbauplanung Desaster-Dokumente.
  • Administrator
    Die Administratoren dokumentieren die aktuelle Konfiguration und pflegen diese weiter. Sie sind zudem für das „Servertagebuch“ zuständig.

Als Leser sehe ich generell alle Personen an. Es gibt keinen Grund, warum nicht alle Personen im Projekt und sogar der Firma Zugang zu den Ergebnisdokumenten haben sollten. Ausnahmen sind natürlich möglich.

Zeit und Projektphasen

Immer wieder höre ich die Frage, wann denn die Dokumentation fertig sei oder wann sie geschrieben werden sollte. Dazu machen ich gerne auch zwei Aussagen

  • Dokumentation beginnt mit dem ersten Tag
    Alles was besprochen, entschieden und letztlich auch getan wird, sollte umgehend dokumentiert werden., Es ist eine denkbar schlechte Idee "nachträglich" dokumentieren zu wollen. Zu viele Informationen sind dann schon nicht mehr präsent. Ideal ist es, wenn ein Team zusammen arbeitet und eine Person die Dokumentation macht. Wir bei Net at Work haben zumindest ein größeren Umgebungen immer gute Erfahrungen gemacht, wenn eine Person mit dem Kunden ein Thema erarbeitet und die zweite Person anhand unserer internen Checklisten die Qualität sichert (nichts vergessen !) und schreibt die Ergebnisse mit. Darauf muss sich ein Kunde natürlich einlassen.
  • Dokumentation ist nie fertig
    Jede Infrastruktur unterliegt permanenten Änderungen und entsprechend gilt es auch die Dokumentation kontinuierlich fort zu schreiben. Insofern gibt es maximal ein "Projektende" aus Budget-Sicht bzw. zur Verrechnung. Wenn die Dokumentation kontinuierlich gepflegt wird, kann Sie auch jederzeit "gelesen" werden und das sollte sogar so sein. Wer die Dokumentation erst am Ende schreiben will, verhindert eine frühere Zusammenarbeit und mögliche Korrekturen.

Wenn Sie diese beiden Aussagen verstanden haben, sollten Sie sich noch heute Gedanken über ihre Dokumentation machen, einen Rahmen und eine Plattform schaffen und die Projektbeteiligten bei der Dokumentation unterstützen.

Auch ein Projekt durchläuft in der Regel mehrere Phasen und so wird auch eine Dokumentation sich kontinuierlich weiter entwickeln. Wenn ihr Projekt dazu noch aus aus "Proof of Concept" und"Pilot"-Phasen besteht, wird einige Dokumente erst als "Rohform" und nicht vollständig beschreiben. ähnlich wie bei einem Hausbau werden am Anfang viele Skizzen und Entwürfe erstellt die erst nach und nach

Die Dokumentationen entstehen parallel zu den unterschiedlichen Projektphasen und sind entsprechend erst gegen Projektend "komplett". Es liegt in der Natur der Dinge, dass die erste Versionen eher als "Entwurf" zu sehen und sollte daher niemand zu vorschneller Kritik verleiten. Die Konzepte müssen so vollständig sein, dass Sie zur aktuellen Projektphase passen., Bei einen "Proof of Concept" und auch einen späteren Pilot können noch nicht alle Ergebnisse feststehen sondern werden erst erarbeitet. So enthält ein Namenskonzept nur die Festlegungen der aktuell schon angelegten Objekten (Server, Benutzer, Gruppen).

Diese Diagramm enthält nur einen Teil der verschiedenen Dokumente. Über die Zeitachse sehen Sie die verschiedenen Projektphasen, die natürlich bei ihnen anders aussehen können. Schon bei den ersten Gesprächen mit dem Kunden entstehen grobe Zeitpläne, Besprechungsnotizen und ein guter Consultant hat schon eine erste Planung im Kopf, die er sich aber als Dokumentation merken sollte. Schließlich ist dies der Startpunkt für die weiteren Schritte. Bei größeren Projekte mit vielen Unsicherheiten wird ein Proof of Concept in einer isolierten Umgebung bereit gestellt, in dem die Anforderungen konkretisiert und die Umsetzung im kleinen demonstriert werden kann. Eventuell wird ein Pilot eingeschoben, um in der Produktion die Funktion zu verifizieren um dann die flächendeckende Einführung zu begleiten. Die meisten "Konzepte" werden natürlich vor dem Rollout, also während oder nach einem Pilot ausgearbeitet.

Aber damit sollten wir uns auf die verschiedenen unterschiedlichen Dokumentationen

Klassifizierung

Dokumente unterscheiden sich natürlich nicht nur bezüglich der technischen Tiefe sondern auch für die Zielgruppe und der Qualifikation des Autors. Ich habe hier vier verschiedene Klassifizierungen vorgenommen:

Klasse Beschreibung Autor Leser
Projektsteuerung

n den Bereich der Projektsteuerung gehören alle unterlagen, die für die Projektdurchführung relevant sind. Das sind z.B. Listen der Ansprechpartner, Termine, Sitzungsprotokolle, Entscheidungen, Offene Posten, Projektpläne, Analysen und Bewertungen etc.

  • Projektleiter
  • Senior Consultant
  • Projektbeteiligte
  • Controlling
Konzeptdokumente

Diese Dokumente beschreiben die große Funktionsblöcke ohne auf die einzelnen Server einzugehen. Sie sind dazu geeignet, dass sich jemand schnall über den prinzipiellen Aufbau einer Umgebung einen Überblick beschaffen kann. Sie beschreiben u.a. wie welche Aufgaben warum umgesetzt wurden aber ohne auf einzelne Server, IP-Adressen etc. einzugehen. Die beschreiben z.B. auch die Informationen, die für ein Sizing heran gezogen wurden oder Namensauflösung, Netzwerkrouting, Datenhaltung, Intranet, Internetzugriff, Netzwerkzugangsschutz, Backup, Storage-Design, Stromversorgung, Administrationskonzept,etc.

  • Senior Consultant
  • Infrastruktur Consultant
  • Kunde
  • Projektleiter
Betriebsdokumente

Diese Dokumente helfen beim Betrieb und  Beschreiben die Zusammenhänge unter Nennung der Server und Nachrichtenflüsse. Sie beschränken sich aber auf die durch die Konzeption festgelegten Zusammenhänge und beschreiben keine Alternativen. Hierzu gehören auch Netzwerkpläne, Serverpläne und Funktionsdiagramme.

  • Technischer Consultant
  • Kunde
  • Kunde
Konfigurationsdokumente Die Konfigurationsdokumente werden meist von den Administratoren selbst erstellt, da sie näher am Objekte sind und diese Dokumente auch Teil der Betriebsunterlagen sind. Es ist auch denkbar, dass ein Großteil dieser Dokumente skriptgesteuert automatisch erstellt wird.
DNS, WINS, NTP, Proxy, SMTP-Relay, Exchange, Lync Einstellungen, etc.
  • Administrator
  • Installateur
  • Per Skript generiert
  • Projektbeteiligte

Die Klassifizierung ist auf "meinem Mist" gewachsen. Sie können natürlich eigene Überlegungen anstellen, beschreiben und umsetzen.

Konzepte

Wenn Sie keine Idee haben, welche Konzepte alles so erstellt werden können, dann möchte ich ihnen gerne ein paar Ansatzpunkte geben, die sowohl konzeptionell als auch bezüglich der Konfiguration erstellt werden können:

Bereich Themen

Netzwerk

IP-Adresse, Routing, WLAN, WAN, IPv6, IP-Adressverwaltung, DHCP, VPN

Infrastruktur

DNS, WINS, NTP, LDAP, Kerberos, Radius, Active Directory, Authentifizierung, Verzeichnisdienste

Client

Installation, Softwaremanagement, Gruppenrichtlinien, Bitlocker, WSUS, Patch-Management, Endpoint Security, Mobile Device Management

Verschlüsselung und Signatur

PKI, SMIME, Zertifikate, Smartcard, RMS, Bitlocker, EFS

Storage

DAS, NAS, SAN, iSCSI, Replikation, Backup und Restore, Versionierung, HSM

Kommunikation

Mail, Spamschutz, IM, VoIP, Konferenz, Präsenz, Lync, Exchange, OWA, Mobile Mail, Fax, SMS, De-Mail

Schutz

Antivirus, Intrustion Detection, Firewall, 802.x1, Zugang

Gebäude

USV, Klimatisierung, Zugangsschutz,

Webservices

Webveröffentlichungen, Zertifikate, Reverse Proxy, Proxy, File Exchange, SharePoint

Monitoring

Services, Eventlog, Performance Counter, Reporting, Auditing, Logmanagement, Funktionstests

File/Print

Dateiservices, NFS, SMB, FTP, Berechtigungen, Versionierung, Archivierung, Druckerfreigaben, Quota

Provisioning

Administrationskonzept, Benutzerverwaltung, Exit/Entry-Management, Metadirectory,

Sicher ist die Liste nicht vollständig und hat noch Luft für ihre eigenen Bausteine. So finden Sie hier z.B.: kein "SQL-Server", da dieser allein keine Funktion hat, sondern nur z.B.: besser in einem ERP-Konzept oder SharePoint-Projekt zu beschreiben ist.

Ob sie solche Dokumentationen nun mit Word, Wordpress, auf einem Wiki, per SharePoint oder partiell per PowerShell erzeugen, überlasse ich ihnen. Letztlich sollte der Zugang "einfach" für jeden möglich sein, der dokumentieren soll, darf oder muss.

Weitere Links