Projekt-Management | Veränderungsmanagement | Methodik

(In-)Transparenz in Projekten

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.

Photo by Gabriel Sollmann on Unsplash

Bewusst oder unbewusst?

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.

Wie schaffe ich Transparenz?

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:

  • Interessengruppen (Stakeholders)
  • Team
  • Entwicklungsansatz und Lebenszyklus (Development Approach und Life Cycle)
  • Planung (Planning)
  • Projektarbeit (Project Work)
  • Lieferung (Delivery)
  • Messung (Measurement)
  • Unsicherheiten (Uncertainty)

Aber auch die alten Knowledge Areas haben weiterhin ihre Berechtigung. Selbstverständlich können auch Strukturen von anderen PM-Methoden verwendet werden. Neben der Bewährtheit einer Methode gibt mir diese die Sicherheit, dass ich mit dieser Struktur im Projekt sowohl thematische Ausgewogenheit wie auch Vollständigkeit erreiche. Mit einer allgemein bekannten Methode kann ich davon ausgehen, dass die Interessengruppen die Strukturen auch verstehen und akzeptieren.

Im Produktentwicklungsprozess verwende ich im Sinne von WBS immer zuerst die Ergebnisstruktur (Produktstruktur) und integriere dann die Prozessschritte/Aufgaben. Damit erreiche ich einen ergebnisorientierten Ansatz, wo zuerst definiert wird, was erreicht werden muss, und dann wie es erreicht werden kann. Leider gibt es immer noch Projekte, die umgekehrt nach den Projektentwicklungsphasen (z.B. Design, Build, Test) strukturiert sind, was immer zu Problemen führt.

Grundsätzlich soll die angewendete Struktur selbst nicht zu kompliziert sein, ganz im Sinne von Albert Einstein: «So einfach wie möglich, aber nicht einfacher».

Wie wende ich diese Strukturen an?

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.

Fazit

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.

Über den Autor


Gründer und Geschäftsführer OMEGA IT-Consulting GmbH

Peter Roth ist ein unabhängiger, selbstständiger Projektleiter und Business Engineer mit über 20-jähriger Erfahrung in internationalen, komplexen Projekten und Programmen. Damit unterstützt er als externer Spezialist seine Kunden sehr erfolgreich in grossen, wichtigen Vorhaben.

Bekannte Unternehmen wie Roche und UBS, welche als globale Marktführer agieren, wirtschaftlich sehr erfolgreich sind und die weltweit besten Mitarbeiter beschäftigen, zählen über Jahre auf seine Expertise in komplexen Projekten und Veränderungen. Aber auch kleinere Firmen und Organisationen, welche weniger bekannt, aber trotzdem grossen Herausforderungen ausgesetzt sind, vertrauen auf sein breites Wissen und seine langjährige Erfahrung sowohl in der Projektleitung und im Projektmanagement, aber auch in der wirkungsvollen Gestaltung von Strategien, Organisationen, Services, Prozessen und IT-Systeme.

Die Firma OMEGA IT-Consulting GmbH ist zertifizierter PQFORCE Consulting Partner.

Verwandte Artikel

Nicht verpassen

Mit PQFORCE Insights bekommen Sie unsere neuesten Nachrichten, Best Practices, Tipps und Angebote direkt in Ihre Mailbox geliefert.
Wir werden Ihnen nur relevante, spamfreie E-Mails senden.
Sie können sich jederzeit mit einem Klick wieder abmelden.
Jetzt ausprobieren

Durch die Nutzung dieser Website stimmen Sie der Verwendung von Cookies zur Verbesserung des Angebots sowie zum Zweck der Nutzungsanalyse zu.Datenschutzerklärung