Standardisierung kostet

Seit einigen Jahren treffen sich ungefähr ein Dutzend Kolleginnen und Kollegen, die als interne und externe Berater und Projektmanager unterwegs sind, einmal im Monat in Frankfurt am Main (es sind meist sechs bis acht Menschen an einem Abend da). Ich wurde vor knapp zwei Jahren in diesen Kreis eingeladen und bin gestern wieder einmal hocherfreut darüber gewesen, wie inspirierend, lustig und lehrreich dieser interkollegiale Austausch ist. Diesmal ging es um den Sinn und Unsinn von Projekthandbüchern. Wir hatten zwei Monate zuvor einem Kollegen Inhaltsverzeichnisse von Projekthandbüchern zugesendet. Btw: wir unterliegen in diesem Kreis der Schweigepflicht. Das dort in Bezug auf konkrete Unternehmen und Projekte Besprochene und Bearbeitete bleibt auch dort, wie es Standard in jeder guten interkollegialen Intervision und Supervision ist.

Der Kollege untersuchte sieben Handbücher auf Gemeinsamkeiten und Unterschiede. Die Beispiele kamen vor allem aus IT-Projekten in Unternehmen. "Christa hat einen Exoten geschickt." - "Ist ja nichts Neues. Sie kommt immer mal mit Beispielen aus ganz anderen Welten." Meines war auch aus der IT-Welt, allerdings einer etwas anderen. Dazu später mehr.

Es ging um Fragen wie: Welche bemerkenswerten Gemeinsamkeiten und Unterschiede bestehen? Und welche neuen Ideen entstehen durch diese sehr unterschiedlichen Beispiele? Das führt uns zur Frage: Was muss in ein Projekthandbuch oder sollte zumindest hinein? Wozu ist ein Projekthandbuch überhaupt gedacht und warum entstehen Projekthandbücher? Wie immer war der Austausch lebhaft, bunt und kreativ. Unterbrechen ist bei uns schon fast höflich, weil die Ideen sprudeln. Und in Bezug auf die Beratungs- und Projektmanagementwelt stets auch von mehr oder weniger englischem Humor geprägt.

Gestern waren wir dann auch auf einmal mittendrin im Thema "Standardisierung kostet". Warum? Weil es sehr aufwendig ist, überhaupt standardisierte Prozesse zu formulieren und zu implementieren, und weil diese Standards die Dokumentationsflut ins Exorbitante und auch Lächerliche wachsen lassen - "Bitte begründen Sie, warum Sie etwas in Ihrem Projekt xy _nicht_ haben." Zum Beispiel: "Schildern Sie die Regelung des Kantinenessens", wenn es gar keine Kantine gibt. "Und begründen Sie, warum Sie das nicht regeln." Kafka? Ja, erinnert daran. Diesen Dokumentationstsunami gibt es nicht nur in IT-Projekten. Das deutsche Gesundheitswesen kann auch ein Klage-Lied davon singen (Blog vom 7.1.2014 "Patient Sozialversicherung ...")

Die Beispiele der Projekthandbücher zeigten Inhaltsverzeichnisse von acht Zeilen bis mehrere DIN-A 4Seiten. Wir haben dann doch erkannt, dass mein Beispiel nicht so exotisch ist, sondern einfach eine andere Sprache hat, die eines langjährigen Forschungsprojekts. Ein Kollege meinte: "Das kannst Du auch zur Beschreibung einer Organisation verwenden." - "Ja, einer Lernenden Organisation, nicht wahr?" - "Ja. Genau." Das veranlasst mich dazu, dieses Projekthandbuch auch hier vorzustellen. Das Projekt ging über fünf Jahre. Es ist in wissenschaftlichen Publikationen und auch in den Büchern der Reihe Elche fangen ... beschrieben. Das Projekthandbuch ist in der hier vorgelegten Form ein Projektabschlussbericht, der sehr einfach aus dem Projekthandbuch zu generieren war. Es musste nur ein wenig von den Ergebnissen unserer Forschungsgruppe hinein.

In unserem Austausch gestern Abend wurde auch klar, dass es immer noch Projekthandbücher gibt, die als Powerpoint-Folien Anwendung finden, beispielsweise im Kick-off und als mehr oder weniger lebende Dateileichen auf dem Projektserver (das ist meine persönliche Meinung dazu). Projekthandbücher - wie auch andere Projektdokumentationen - webbasiert zum Beispiel als Wiki zu führen, haben wir kurz angerissen. Das brachte mich auf die Idee, hier im Blog das Thema mit den 8+1 W Fragen anzuschauen. Der strukturierten Beantwortung halber.

Die - zunächst - 8 W habe ich aus einem Analyseinstrument, das ursprünglich aus dem Journalismus kommt, entwickelt und im Blog vom 29.03.2012 und dann auch 2013 in "Basiswissen Consulting ..." beschrieben. Inspiriert durch das wissenschaftliche Arbeiten kam dann das neunte W hinzu. Wie Sie mit Nummer 9, dem „Woher?“, umgehen können, habe ich 2015 in "Elche fangen..." [daraus entstand  das Buch Entdecken, 2017] vorgestellt. Die 8+1 W sind hervorragend für Analysen und Reflexionen und damit für die Steuerung von Projekten und anderen Unternehmungen geeignet:

• Wozu: Ziel
• Was: Aufgaben
• Wer: Rollen und Funktionen
• Warum: Motivation, Anlass
• Für wen: Zielgruppe, Klient, Kunde
• Wie: Methoden
• Wann: Zeitraum
• Wo: Orte

Tipp: Verwechseln Sie die Frage nach dem Warum bitte nicht mit der Frage nach dem Wozu. Umgangssprachlich meinen Menschen oftmals das Wozu, wenn sie vom Warum sprechen. Zurück zu den Projekthandbüchern.

Wozu - Sinn und Zweck
In unserem Gespräch nannten wir gestern Aspekte wie Information, Kommunikation, Dokumentation, Reflexion.
Bei der Formulierung des "für wen" (siehe unten) kommt jetzt noch ein Aspekt hinzu. Heute sind Teams oftmals fließend: Menschen treten in das laufende Projekt ein und verlassen es. Außerdem sind viele Teams örtlich verteilt und arbeiten in einem mehr oder minder großem Teil auf virtuellen Plattformen. Umso wichtiger ist es, vor allem die Policy, also Ansatz und Werte des Teams in einem starken Dokument zu hinterlegen und nicht nur auf flüchtigen Folien oder Webpages vorzustellen.

Was - in diesem Kontext
- ist ein Projekthandbuch? Ich möchte es so beschreiben: Ein Projekthandbuch ist ein Dokument, in dem Hintergrund einschließlich (Vor-)Geschichte, Thema, Ziel(e), zeitlicher Rahmen, Ansatz, Werte, Rollen, Aufgaben, Ressourcen, Kommunikation nach innen und außen, Dokumentation und das Sicherheitskonzept enthalten sind.

Wer - schreibt und pflegt das Handbuch?
Verantwortlich ist die Projektleiterin oder der Projektleiter. Sie kann das Verfassen und Pflegen von Teilen oder des gesamten Handbuchs delegieren.

Warum - wer fordert ein Projekthandbuch?
A) ist dies in meinem Augen gute Projektmanagementpraxis, da ein gutes Handbuch ein hervorragendes Projektsteuerungs- und Kommunikationsinstrument nach innen und außen sein kann und sich mit wenig Aufwand als Basis für Projekt(zwischen)berichte und Publikationen verwenden lässt.
B) Auftraggeber wollen etwas "sehen". Im Kontext der Unternehmensberatung, insbesondere in der IT gibt es oftmals nichts zu sehen und schon gar nicht anzufassen. Ein Projekthandbuch ist - ausgedruckt und schön gebunden - eine sehr haptische und damit sinnliche Angelegenheit. Nicht erst seit Paul Watzlawick wissen wir, wie wichtig Gefühle in der Kommunikation sind. Er hat es wunderschön in seinen Büchern beschreiben, zum Beispiel in "The pursuit of unhappiness" (Blog vom 13.04.2016).

Für wen - ergibt sich aus dem Wozu
Zum einen und vor allem ist das Handbuch für die Mitglieder des Projektteams gedacht - siehe auch "wozu". Zum anderen ist das Handbuch für den Auftraggeber und - falls Projektleitung (und mit ihr das Team) und Auftraggeber dies so entscheiden - für weitere Kreise, wie das Unternehmen und vielleicht auch die Öffentlichkeit, sei es in wissenschaftlicher Form oder für das breite Publikum.

Wie - schreiben, hinterlegen, publizieren und pflegen
Ein Projekthandbuch ist - wie jeder Anteil einer guten Projektdokumentation - kein starres sondern ein sich mehr oder weniger stark im Zeitverlauf veränderndes Dokument. Zum einen sollten die Autoren und die Leser aus dem Projektteam das Dokument in ihren regelmäßigen Reflexionen nutzen, um Punkte wie Thema, Ziel(e), zeitlicher Rahmen, Ansatz, Werte, Rollen, Aufgaben, Ressourcen, Kommunikation nach innen und außen, Dokumentation und das Sicherheitskonzept zu hinterfragen. Natürlich hängt die Intensität und Frequenz von der Größe des Projekts und von den Fähigkeiten der Projektleitung und des Teams zur Reflexion ab.
Also gilt es, zunächst die Autoren auszuwählen, das Handbuch zu schreiben und in einer komfortablen Form zu publizieren (mehr zum Schreiben in der Blogrubrik "Schreiben und Publizieren" und im Band 4 der Buchreihe Elche fangen ...). Ich plädiere für ein Wiki auf einem - gerne auch nur dem Projekt zu Verfügung stehenden - Webserver. Das Wiki lässt sich in wenigen Schritten in ein gut lesbares PDF umwandeln. Ausgedruckt können Sie das dann auch gerne schick binden lassen.
Außerdem erfüllen Sie damit gleich die nächste Forderung, nämlich die nach einem Versionssystem und der fortlaufenden Pflege dieses Dokuments. Btw, wenn Sie Powerpointpräsentationen lieben: Versuchen Sie doch mal ein Dokument so zu verfassen, dass Sie einzelne, aussagekräftige Abschnitte, wie Aufzählungen - sind ja sehr beliebt auf Powerpoint - und Grafiken und andere Abbildungen aus dem Webbrowser heraus in einem Vortrag zeigen. Empfehlen möchte ich Ihnen auch Garr Reynolds' "presentation zen" (http://www.presentationzen.com/).

Wann - muss das Handbuch fertig sein?
Vor dem Start des Projekts und dann sollte das gesamte Team das Handbuch möglichst zügig reflektieren (also in den ersten Wochen eines Projekts). Das gemeinsame Nachdenken über Hintergrund einschließlich (Vor-)Geschichte, Thema, Ziel(e), zeitlicher Rahmen, Ansatz, Werte, Rollen, Aufgaben, Ressourcen, Kommunikation nach innen und außen, Dokumentation und das Sicherheitskonzept bringt (a) neue Erkenntnisse und ist (b) sehr förderlich für eine gute Gruppendynamik.
Und wann - muss das Team das Handbuch überprüfen?
In regelmäßigen Abständen von einigen Monaten bis maximal einem Jahr und unmittelbar bei Bedarf, beispielsweise wenn das Sicherheitskonzept geändert werden muss.

Wo - liegt das Handbuch?
Auf einem (Projekt)Server und - schick gebunden und hoffentlich gelesen - auf dem Schreibtisch Ihres Auftraggebers.


Fazit
Projekthandbücher sind in ihrer Erstellung und Pflege aufwändig. Es gilt also, zu entscheiden, ab welcher Größe und Komplexität und Dauer ein Projekthandbuch zu empfehlen ist. Auftraggeber und Projektmanager, also auch Beratungsunternehmen sollten sich davor hüten, solche Dokumente einem Standardisierungswahn zu unterwerfen. Sie sollten vielmehr auf den gesunden Menschenverstand derjenigen vertrauen, die das Projekt verantworten und durchführen - damit niemand sich rechtfertigen muss, warum er die Besuche in der nicht-existierenden Kantine nicht regelt.

Außerdem: Ein Handbuch kann auch klein sein. Manchmal genügen drei bis vier Seiten, um die Punkte Hintergrund einschließlich (Vor-)Geschichte, Thema, Ziel(e), zeitlicher Rahmen, Ansatz, Werte, Rollen, Aufgaben, Ressourcen, Kommunikation nach innen und außen, Dokumentation und das Sicherheitskonzept vorzustellen. Das geht auch bei großen Projekten: in jedes gute Projekthandbuch gehört ein Management Summary. Der von mir der Gruppe überlassene und hier vorgestellte Exot aus der Forschung hat keines - doch. "Introduction" und "Course of the Report" können Sie so lesen. Viel Spaß dabei:

Weßel C. Continued Multi-disciplinary Project-based Learning (CM-PBL) 2002—2007. Project Report. Aachen: RWTH Aachen, Department of Medical Informatics 2007. - pdf

Christa Weßel - Mittwoch, 9. November 2016

Quellen [am 01.01.2018 hinzugefügt]

Weßel C. Elche fangen ... Basiswissen Consulting für Berater und Führungskräfte
Band 1 bis 4

Frankfurt am Main, Weidenborn Verlag 2017

Blogrubriken Schreiben und Publizieren und Organisationsentwicklung
Und natürlich Watzlawick und viele mehr in den Ressourcen

[18 August 2023: Rechtschreibfehler korrigiert.]

< Gestalt_erische Pause   heute   Spuren >