Projektdiagnose – auch hinter die Kulissen des Projektes schauen

Ein Überblick von Gero Lomnitz, Referent ZfU

Der Untertitel des Buches von Gero Lomnitz «Projektdiagnose – auch hinter die Kulissen des Projektes schauen» ist programmatisch, hier werden Grundlagen und Methoden dargestellt, wie man nicht an Symptomen hängen bleibt.

Was unterscheidet Diagnose vom Review?
Review ist ein bekanntes Verfahren, um den Zustand des Projektes zu ermitteln. Durch ein Review sollen u.a. der Grad der Zielerreichung, die zeitliche Situation, der Budgetverbrauch, die Personalsituation im Projekt oder Risiken analysiert und bewertet werden. Ganz klar, diese Punkte sind von grosser Bedeutung, um ein Projekt besser zu steuern. Doch reichen Reviews nicht aus, um sich ein Bild über den Zustand des Projektes zu machen? Warum noch von Projektdiagnose reden? Gibt es einen Unterschied zwischen Review und Diagnose oder handelt es sich bei Projektdiagnose um alten Wein in neuen Schläuchen? Sicher nicht, denn eine fundierte Projektdiagnose geht wesentlich weiter und vor allem mehr in die Tiefe als ein Projektreview. Was ist damit gemeint? Schauen wir uns typische Probleme aus dem Projektalltag an.

Einige Probleme aus dem Projektalltag

• Unklarer Projektauftrag
• Zwischenziele werden nicht erreicht
• Termine werden nicht eingehalten
• Mangelnde Verfügbarkeit von Projektmitarbeitern
• Schlechte Planung beeinträchtigt den Projektfortschritt
• Informationen kommen zu spät
• Unklare oder fehlende Entscheidungen
• Anforderungen werden zu häufig geändert
• Risiken werden nicht ermittelt oder falsch eingeschätzt

Die Liste lässt sich mühelos fortsetzen.

Solche Probleme müssen sowohl im Review als auch in der Projektdiagnose gesammelt werden. Doch das allein reicht nicht aus, um die Kernursachen zu erkennen, die entscheidende Voraussetzung für nachhaltige Lösungen. Hinter solchen Problemen (Symptomen) stehen häufig andere Einflüsse wie Interessenkonflikte, Machtprozesse, widersprüchliche Entscheidungen, unklare Zuständigkeiten, Wiederholungsmuster oder verlagerte Probleme, um nur einige zu nennen. Im Unterschied zum Review hat Projektdiagnose die Aufgabe, diese Phänomene gründlich zu ermitteln, zu analysieren und Empfehlungen aufzuzeigen.

Einige Kernfragen für die Projektdiagnose

• Wann lohnt sich eine Projektdiagnose? Welchen Nutzen bietet eine Projektdiagnose in Abgrenzung zum Review?
• Welche Rollen im Rahmen der Diagnose müssen geklärt werden?
• Wer kann und darf die Diagnose durchführen?
• Was müssen Diagnostiker können?
• Wer muss in die Diagnose einbezogen werden?
• Welche Daten sind für eine fundierte Projektdiagnose wichtig?
• Mit welchen Methoden und Instrumenten gewinne ich die Daten?
• Wie bereite ich die Informationen zu einem aussagefähigen Bericht auf?

Diese Fragen müssen beantwortet sein, bevor man mit einer Diagnose startet.

Phasen der Projektdiagnose
Die einzelnen Abschnitte lassen sich übersichtlich darstellen.

• Auftragsklärung
  Ziele, Rollen, Zeitrahmen, Budget, Methode und Regeln für die Diagnose müssen mit dem Auftraggeber der Projektdiagnose geklärt werden. Das ist nicht viel anders als bei der Auftragsklärung im Projekt. Um die Rollen richtig zu klären, darf das Projekt nie mit dem Projektteam gleichgesetzt werden. Das Team ist ein wichtiges Subsystem des Projektes, aber zum Projekt gehören Sponsor, Entscheidungsgremien, Linienmanager und ggfs. externe Kooperationspartner. Das ist bei die Rollenklärung zu beachten.
• Datenerhebung, Informationen systematisch sammeln
  Eine gute Diagnose steht und fällt mit den richtigen Fragen und dem gekonnten Einsatz von Methoden zur Datensammlung. In Interviews müssen geeignete Fragen gestellt werden, auch wenn es sich um unangenehme und politische Themen handelt. Gegen Fragen mit Fingerspitzengefühl ist nichts einzuwenden, doch wenn man wie die Katze zu lang um den heissen Brei herumgeht, erhält man nicht die notwendige Nahrung.
  Datenaufbereitung, Informationen in einen sinnvollen Zusammenhang bringen
• Stärken und Schwächen im Projekt müssen analysiert, Zusammenhänge zwischen Hardfacts und Softfacts verstanden werden, um die Kernursachen zu ermitteln. Analysiert werden müssen die ökonomischen, technologischen, psychologischen und politischen Einflussfaktoren und die damit verbundenen Wechselwirkungen. Das macht die Diagnose erst fruchtbar. Damit sind hohe Ansprüche an den Diagnostiker verbunden.
• Diagnosebericht
  Klare Empfehlungen an die Beteiligten vermitteln.

Wie ermittele ich Kernursachen?
Projektdiagnose erfordert, sowohl die Logik als auch die Psycho-Logik der Probleme zu analysieren. Es ist zu wenig, nur auf unklare Zuständigkeiten hinzuweisen, sondern man muss analysieren, was bisher unternommen wurde, um dieses Problem zu lösen bzw. wieso das Problem noch nicht gelöst ist.

Aus der Vielzahl der Möglichkeiten habe ich für diesen kurzen Beitrag nur einige ungewöhnliche Diagnosefelder ausgewählt, durch die man den Problemen auf den Grund gehen kann.

Wie werden Konflikte nicht gelöst?
Der Diagnostiker analysiert, inwieweit Probleme bzw. Konflikte von einem Subsystem in ein anderes verlagert werden. Beispiel: Interessenkonflikte im Steering Committee werden dort nicht geklärt und werden auf diese Weise in das Projektteam verlagert. Organisationen sind Druckweitergabe-Systeme, was in alle Richtungen zu verstehen ist.

Leidensdruck
Leidensdruck ist oft eine Voraussetzung, um ein Problem zu lösen.
Beispiel: Ressourcen stehen nicht zur Verfügung und dadurch entstehen für das Projektteam erhebliche Probleme. Objektiv ein Problem? Nein, nicht unbedingt. Möglicherweise haben die Entscheider andere Prioritäten und deshalb wird keine Entscheidung getroffen. Wer eine Diagnose machen möchte, sollte nicht davon ausgehen, dass es objektiv ein Problem gibt.

Wiederholungsmuster
Es wird analysiert, wie oft ein Problem bereits im Steering Committee besprochen worden ist und wie es passiert, dass wiederholt über das gleiche Problem gesprochen worden ist, ohne eine Lösung zu erreichen. Wenn wiederholt erfolglos eskaliert wurde, dann müssen Wiederholungsmuster aufgezeigt werden.

Hard Facts und Soft Facts
Der Einfluss von Hard Facts und Soft Facts muss gesammelt werden. Doch mit einer Auflistung ist es nicht getan, sondern die Wechselwirkungen zwischen Hard Facts und Soft Facts müssen verstanden werden. Beispiel: Welche Auswirkungen haben unklare Ziele, Prioritätenänderungen oder fehlende Entscheidungen des Auftraggebers auf die Zusammenarbeit im Projektteam? Weder die einseitige Fokussierung auf Hard Facts noch die zu starke Überbetonung der psychologischen Aspekte der Projektarbeit werden der Sache gerecht.

Wichtige Voraussetzung - die eigenen Annahmen hinterfragen
Von welchen Annahmen ging er aus? Offensichtlich von einer falschen, mit den Folgen muss er leben (oder auch nicht mehr).

Oft gehen wir von Annahmen aus, ohne uns bewusst zu machen, inwieweit diese zutreffen. Der Diagnostiker sollte sich seine eigenen Annahmen kritisch prüfen. Das ist eine Grundvoraussetzung für eine gute Diagnose, denn die Annahmen beeinflussen unsere Wahrnehmung und damit Datensammlung in erheblichem Masse.


Zum ZfU-Seminar «Projektdiagnose - hinter die Kulissen des Projektes schauen» mit Gero Lomnitz: www.zfu.ch/go/pdl