Beratung & Coaching Durchführung & Steuerung Review & Assessment Als externer Projektspezialist werde ich vielfach von Kunden beauftragt, wenn bereits etwas in einem Projekt oder Programm im Argen liegt.
Dabei tauchen immer häufiger schwerwiegende Probleme aus dem Nichts auf und niemand weiss, was die Ursache ist.
Eingeleitete Massnahmen erzielen nicht die gewünschte Wirkung.
Die Zeit rennt, die Kosten explodieren. Es fehlt an Transparenz im Projekt.
Von Peter Roth, 28. Juni 2022
Photo by Gabriel Sollmann on Unsplash
Eigentlich gibt es nichts Schlimmeres für Interessengruppen wie Auftraggeber oder Kunden, wenn sie nicht wissen, was im Projekt läuft, was der aktuelle Stand ist, und wie es weiter geht, oder vieles Schön geredet wird und keine Möglichkeit besteht, Erreichtes zu verifizieren.
Nur selten erlebe ich Projekte, welche bewusst für eine bestimmte Zeit geheim gehalten werden.
Dies kann bei Restrukturierungsprojekten so gewählt werden, wo unterschiedliche Szenarien angeschaut werden, und mit der Geheimhaltung vorübergehend unnötige Verwirrung und Gerüchte in der Organisation vermieden werden sollen.
Aber Vorsicht, man kann nicht nicht kommunizieren. Auch da ist ein Minimum an Transparenz sinnvoll. Vielfach entstehen mehr Gerüchte, wenn etwas geheim ist.
Weiter gibt es Projekte, wo die Transparenz bewusst tief gehalten wird, damit nicht vermeintlich von ‘’aussen’’ kontrolliert und fremdgesteuert wird.
Persönlich halte ich das für keine gute Idee. Denn Projekte haben keinen Selbstzweck, sondern werden für Auftraggeber und Kunden gemacht, mit denen eine vertrauenswürdige Kommunikation betrieben werden soll.
Und Transparenz schafft Vertrauen! Bei den allermeisten Projekten ist die fehlende Transparenz kein bewusster Akt, sondern eine Folge der Komplexität und der Hektik im Projekt, vielfach zeugt es auch von einer gewissen zeitlichen oder fachlichen Überforderung.
Dabei fehlt die Transparenz nicht gänzlich, sondern ist meist ungenügend.
Das Problem der fehlenden oder ungenügenden Transparenz ist die Komplexität in einem Projekt. Alles hängt irgendwie zusammen.
Zum Beispiel wird im Projektsteuerungsgremium ein benötigter Entscheid nicht innert einer bestimmten Frist gefällt, führt das zu Verzögerungen im Projekt.
Verzögerungen haben Auswirkungen auf die Verfügbarkeit von Mitarbeitern, gegebenenfalls müssen neue Mitarbeiter bestehende ersetzen, was zu Mehraufwand führt.
Ist intern kein Ersatz vorhanden, müssen externe Spezialisten beigezogen werden, was Mehraufwand für den Einkauf und für die Integration bedeuten, was wiederum zu Mehrkosten im Projekt führt.
Abhängigkeiten sind in einem Projekt sehr gross und können zu einem Rattenschwanz an Problemen führen.
Transparenz schaffe ich vorwiegend mit der Anwendung von Strukturen (auch Projektstruktur oder Work Breakdown Structures WBS genannt). Mir scheint, dass Strukturen vor allem auch in der agilen Welt in den Hintergrund geraten sind, obwohl auch Scrum, SAFe und Co. klare Strukturen anwenden.
Strukturen reduzieren die Komplexität und fokussieren auf ein kleineres Thema. Deshalb werden auch zum Beispiel Bücher in Bibliotheken nicht nur alphabetisch, sondern übergreifend nach Themen geordnet.
Strukturen können sowohl hierarchisch als auch in Form von Matrix und Netzwerken dargestellt und mit Gruppierungen und Beziehungen ergänzt werden.
Dabei sind Strukturen keine Aufteilung oder Aufspaltung des Projektes, was aufgrund der oben erwähnten projektinternen Zusammengehörigkeit und Abhängigkeiten nicht möglich ist. Strukturen sind Sichtweisen und Zuordnungen auf das Projekt.
Ich empfehle, das Rad nicht neu zu erfinden, sondern für Strukturen auf bewährte Referenzen zu greifen. Dabei unterscheide ich zwischen Projektmanagement (PM) und Produktentwicklung.
Wenn nichts anderes vorgegeben ist, nutze ich persönlich für ersteres die PM-Methodik PMI PMBOK-Guide. Über viele Jahre habe ich die zehn sogenannten Knowledge Areas als Hauptstruktur verwendet.
Mit der neusten, siebten Ausgabe des PMBOK-Guides wurden diese Knowledge Areas zusammen mit den Projektphasen im Jahr 2021 in Leistungsdomänen (Project Performance Domains) überführt, was mir noch besser gefällt. Dies sind:
Wurde initial mal eine passende Struktur für das Projekt gefunden und implementiert, wird das Projekt über diese Struktur gesteuert. Nur die konsequente, wiederkehrende Anwendung der Struktur im Projekt führt zur gewünschten Transparenz und Gewöhnung, und schafft Vertrauen.
Häufig beobachte ich, dass zwar Strukturen implementiert wurden, diese sich jedoch im Laufe des Projektes verwässern, neue hinzukommen und andere weggelassen werden. Dies führt zu einer Vermischung von unterschiedlichen Strukturen, worunter die Transparenz leidet.
Die gewählte (Haupt-)Struktur verwende ich wo immer möglich im ganzen Projekt an. Jedes Strukturelement beinhaltet zahlreiche Unterstrukturen, welche dann auf die spezifischen Bedürfnisse angepasst werden können.
Entsprechend plane und steuere ich das Projekt nach dieser Struktur, und kommuniziere in dieser Struktur. Ein monatlicher Projektstatusbericht zum Beispiel wird genau nach dieser Struktur gestaltet. Auch das Projektcockpit erhält genau diese Struktur.
Es empfiehlt sich, nach der Implementierung und dann von Zeit zu Zeit die Strukturen zu überprüfen, ob sie auch wirklich verstanden und akzeptiert werden, und ob sie immer noch zum Projekt passen, welches sich ja auch verändern kann.
Dann müssten sie innerhalb der Methodik angepasst werden. Dies sollte aber nicht zu häufig und zu stark passieren, dass es sich bei Strukturen um ein grundlegendes Element des Projektes handelt, wo Änderungen grosse Auswirkungen und Verwirrungen nachziehen können.
Das bedeutet doch recht viel Arbeit und Aufwand für den Projektleiter, was leider von aussen nicht immer als solches wahrgenommen wird. Das kommt nicht von selbst, und muss aktiv angewendet und gepflegt werden. Aber das ist eine sehr gute, lohnende Investition.
Projektstrukturen gehen immer einher mit den Projektdaten. Sämtliche Projektdaten sollen sich an der Struktur ausrichten, das heisst den Strukturelementen zugeordnet sein. Sehr hilfreich ist dabei ein Projektmanagement-Tool mit einer zentralen Datenbank.
Das erlaubt dem Projekt jederzeit unterschiedliche Sichten auf das gesamte Projekt und alle Projektdaten zu gewähren.
Bei der Verwendung von einzelnen Dokumenten (z.B. für Kosten, Zeitplanung, Ressourcen) ist die Generierung von übergreifenden Sichten ungleich aufwändiger, ineffizienter und teilweise gar nicht möglich.
Umgekehrt bringt ein solches PM-Tool viel weniger, wird nicht eine geeignete Struktur im Projekt hinterlegt.
Trotz Strukturen gibt es weiterhin Probleme im Projekt und wird es auch immer geben. Mit der durch Strukturen geschaffenen Transparenz können Probleme jedoch frühzeitig erkannt, die Ursachen dafür ermittelt und dadurch nachhaltig behandelt und gelöst werden. Wie erwähnt schafft Transparenz im Projekt Vertrauen bei den Interessengruppen – im und ums Projekt. Vertrauen gewährleistet eine viel bessere und konstruktivere Zusammenarbeit, was allen Beteiligten auch mehr Spass macht und schlussendlich zu besseren Ergebnissen führt.