Was dem Projektleiter der Projektauftrag, ist dem Lösungsarchitekten das Fachkonzept. Warum auch hier einige Projekte ins Wanken geraten.

Oft geraten Projektleiter in Situationen, in denen Sie ein Projekt leiten sollen was in dieser Organisation nicht das erste seiner Art ist. Wie es sich für eine gute Organisation gehört, gibt es hier natürlich mehr oder weniger formale Lessons Learned aus den vorangegangenen Vorhaben.

Eine sehr beliebte – und teils gefährliche – Lektion ist: „Wir brauchen bessere Dokumentation“.

Wer schreibt, der bleibt

Gefährlich wird das Thema Dokumentation immer dann, wenn „gute“ Dokumentation mit „ausführlich“ statt mit „angemessen“ gleichgesetzt wird. Es gibt verschiedene Aufgaben die eine Dokumentation erfüllen muss, keine davon sollte jedoch sein:

Es muss möglichst viel Dokumentation geben.

Die Projektphase in der vorrangig Dokumentation erzeugt wird, ist die Entwicklung des Soll-Konzepts (Design). Hier werden zunächst die Ziele des Projekts in Anforderungen an die Lösung übersetzt, um im zweiten Schritt dann die zukünftige Organisation, die Prozesse und den technischen Aufbau zu definieren.

Demnach haben wir im Normalfall 2-3 Konzepte, die es nacheinander zu erstellen gilt:

• organisatorisches Konzept – enthält Soll-Vorgaben zu künftigen organisatorischen Rahmenbedingungen, Verantwortlichkeiten, Ressourcenbedarf (prozessgenerisch)
• funktionales Fachkonzept – enthält Soll-Vorgaben zu künftigen Prozessen, der Interaktion zwischen den Beteiligten und Prozess-Inputs und -Outputs (implementierungsunabhängig)
• technisches Konzept – enthält Soll-Vorgaben zur technischen Implementierung, oft anhand von bestehenden Development Guidelines (systemspezifisch)

Alle drei sollen die notwendigen Inhalte enthalten, um die Lösung zu bauen, zu testen und final in den Produktivbetrieb zu überführen. Mehr jedoch nicht.

Das richtige Maß

Im Rahmen eines (mehrjährigen) Projekts fallen natürlich Unmengen an Informationen an, und diese sollten möglichst nicht verloren gehen. Das reicht von Gesprächsnotizen bis zu Trainingsunterlagen. Die offizielle Projektdokumentation als Projektgegenstand (neudeutsch: „Deliverable“) sollte sich mit diesen Themen jedoch nur insofern beschäftigen, als sie zur Erbringung der Projektaufgaben zwingend notwendig ist.

Man beachte hierbei selbstverständlich auch die unternehmens-spezifischen Anforderungen, ein kleines Startup mag hier andere Vorstellungen von Methodik und Dokumentationsumfang haben als ein globaler Pharma-Konzern. Von diesen organisatorischen Rahmenbedingungen abgesehen sollten jedoch einzig die funktionalen Anforderungen über das Ausmaß entscheiden:

• im Rahmen des Build (Lösungsimplementierung) soll sie als Leitfaden für die Entwickler und Entscheider dienen, wie die zukünftige Lösung aussieht
• im Rahmen des Tests wird dann die gebaute Lösung mit der dokumentierten Lösung abgeglichen
• im Rahmen des Cutovers (Produktiveinführung) dient die Dokumentation dann als Grundlage der Kommunikation (Basis für Schulungsunterlagen, Prozessanweisungen etc.)

Wird darüber hinaus Form oder Inhalt verlangt, ist es kräftig zu hinterfragen welcher Mehrwert diesem Mehraufwand gegenübersteht. Ihr Projektteam hat schließlich andere Aufgaben, als Text zu schreiben.

Eine berechtige Frage kann lauten: „Werden Sie konkret, Herr Scharr! wie umfangreich sollte sie denn nun werden?“. Die Antwort ist nicht einfach zu geben, da Unternehmen, Projekt und Prozess natürlich sehr individuell sind. Eine Hausnummer will ich Ihnen jedoch nicht vorenthalten:

• für jeden durchschnittlich komplexen Prozess hat sich ein Dokumentationsumfang von 1-2 DIN A4-Seiten als sinnvoll herausgestellt
• mögliche Inhalte der Dokumentation können sein
  • Prozess-Diagramm zur grafischen Darstellung
  • Prozessanforderungen, Prozess-Input und Prozess-Output, Prozessbeteiligte, Prozess-Schritte
  • Technische Umsetzung, Schnittstellen, Berechtigungen
• die Termini können durchaus verkürzend und technisch sein, es geht um eine effiziente und präzise Beschreibung des Soll
• Prosa ist möglichst zu vermeiden, genau so wie redundante Darstellung in Grafik und Text
• Ergo: Projektdokumentation ist keine Anwender-Dokumentation, sondern eine Projekt-Dokumentation von Experten für Experten mit begrenzter Lebensdauer
• Die Projektdokumentation kann später in eine Lösungsdokumentation für den Betrieb erweitert / umgewandelt werden

Und die Ausnahmen?

Die sind natürlich vorhanden, und jedes Projektteam tut gut daran sich an den individuellen organisatorischen und rechtlichen Rahmenbedingungen auszurichten.

Im besten Fall existieren verbindliche Projektvorgaben von einer internen PMO-Organisation, die Ihnen als Projektleiter sehr klar vorgibt welches Maß an Dokumentation erwartet wird. Existiert dies nicht, entwickeln Sie gemeinsam mit dem Team einen Vorschlag und legen Sie ihn dem Sponsor zur Entscheidung vor. Ist hier die Abstimmung hergestellt, sind Sie sich im Rahmen der Projektorganisation zumindest schon einmal einig.

Letztendlich empfiehlt sich bei diesem Thema jedem aufmerksamen Projektleiter mit Hang zur Deeskalation: stimmen Sie sich ab, suchen Sie sinnvolle Lösungen ohne in Dogmatismus zu verfallen.

Sind durch Spontan-Ideen Dritter aber Ihre Projektziele in Gefahr, so machen Sie das sehr früh deutlich damit hier keine Überraschungen entstehen.

Dabei viel Erfolg,