Komplexe Projekte – es geht auch einfach – oder nicht?

Es klingt so einfach: Man kann ein Projekt überschaubarer, einfacher machen, wenn man Komplexität reduziert. Ich frage mich je länger je mehr, wie man das genau macht und ob der Nutzen von Komplexitätsreduktion auch wirklich nachhaltig ist.

Ein Annäherungsversuch zur Reduktion von Komplexität

In einem operativen Projekt gibt es einige komplexe Konstrukte, die man vermutlich vereinfachen kann – Beispiele:

• Zu viele Ansprechpartner
  Oft gibt es zu viele Ansprechpartner und keine klaren Verantwortlichkeiten. Das führt zwangsläufig zu einem (vermeintlich) komplexen Chaos. Ein geübter Projektleiter kann hier aber sehr schnell Abhilfe verschaffen, in dem er die Kommunikationskanäle und Rollen genau definiert und sicherstellt, dass diese auch so gelebt werden.
  --> Weniger Komplexität durch klare Strukturen
  
• Die zu implementierende Software muss alles können
  Die Softwarelösung soll die sogenannte „eierlegende Wollmilchsau“ werden. Der Kunde will alles, alles möglichst bequem, hat aber ein geringes Budget. Ein vermeintlich sehr, sehr komplexes Projekt. Auch hier wird mit wenigen Handgriffen Komplexität rausgenommen: Design to Cost Ansätze oder Scope-Reduktionen, sowie Erwartungsmanagement sind nur einige Punkte, die hier eingesetzt werden können.
  --> Weniger Komplexität durch klaren Projektscope/Projektauftrag.
  
• Zu viele Projekte, die parallel laufen
  Man möchte alles auf einmal: neues Look % Feel, höhere Conversion Rate, Digitalisierung der internen Prozesse, und gleichzeitig noch eine neue Projektmanagement Software einführen, das ganze „möglichst agil“ umgesetzt. Solche Konstrukte sind schwierig zu lösen, da sie oft in den Köpfen der Auftraggeber festsitzen. Auch hier helfen klare Strukturen und vor allem Gesamtprojektpläne, Gesamtprojektleiter und Rollendefintion etc. In solchen Konstrukten gilt es nicht, die einzelnen Projekte zu überwachen, sondern das Gesamtprojekt als Ganzes und vor allem die Abhängigkeiten zwischen den einzelnen Teilprojekten. Verständnis über Vorgehen und Methoden müssen geklärt und festgehalten werden.
  --> Weniger Komplexität durch klare Vorgehensweisen, Templates, Abhängigkeiten, Transparenz – durch Gesamtführung

Das Projekt als komplexes System betrachtet

Oben stehende Beispiele mögen wohl auf der operativen Ebene in einigen Fällen funktionieren. Aber auch nicht unbedingt. Ein klarer Projektauftrag heisst noch lange nicht, dass dieser vom Auftraggeber dann auch so verstanden und ausgelegt wird. 

Wenn man Projekte als komplexe Systeme betrachtet, so wird es um einiges schwieriger, Komplexität rauszunehmen. Projekte leben (und sterben) von den Menschen die involviert sind. Jeder Mensch hat eine eigene Auffassung des Projektes, hat einen individuellen kulturellen und gedanklichen Hintergrund – hat eine eigene Geisteshaltung. Das kann nicht einfach mit ein paar Methoden umgekrempelt werden. Im Gegenteil, die Kunst liegt hier viel mehr darin, wie man mit dem Projekt als komplexes System umgehen kann. Wie werden solche Projekte optimaler Weise geführt?

Meine Antwort dazu lautet: Führung, Führung und nochmals Führung. Hier leitet man nicht mehr einfach ein Projekt, hier führt man Menschen auf ein bestimmtes Ziel hin (wobei die Ziele sehr vielschichtig von individuellen Zielen hin zu den Projektzielen sein können)

Die Erwartungen wurden nicht erfüllt

Der Auftraggeber oder Kunde ist unzufrieden. Wir haben in seinem Projekt seine Erwartungen bei weitem nicht erfüllt.

 

Ein Projektmisserfolg?

Das Projektleiterherz blutet, wenn der Auftraggeber die Aussage macht, dass das Projektteam die Erwartungen nicht erfüllt hat. Gehört doch nebst dem Einhalten der Kosten, Termine und vereinbarten Leistung als weiterer Erfolgsfaktor dazu, dass der Kunde zufrieden ist und im Unternehmen durch dieses Projekt einiges besser geworden ist. In diesem Sinne ist eine solche Aussage tatsächlich ein Misserfolg. Insbesondere wenn man für das Projekt hart gearbeitet hat, ist es umso deprimierender, dass man die Erwartungen nicht erfüllt hat.

 

Der Blick hinter die Kulissen

Wichtig ist es jetzt herauszufinden, warum man die Erwartungen nicht erfüllt hat:

• Hat man unter Umständen vor lauter Arbeitsdruck die Projektziele aus den Augen verloren?
• Oder wurden gar keine Ziele formuliert?
• Hat der Auftraggeber „versteckte“ Erwartungen, die nie ausformuliert wurden?
• Hat der Auftraggeber erst in der Endphase des Projektes gemerkt, dass er sich eigentlich etwas ganz vorgestellt hat?

Grundsätzlich darf man solche Aussagen auch hinterfragen. Gerade bei einem grösseren länger andauernden Projekt ist es erstaunlich, wenn solches Feedback erst ganz am Ende aufkommt. Normalerweise reklamiert der Auftraggeber früher, insbesondere wenn der Projektleiter immer transparent kommuniziert und die Stimmung im Projekt ansonsten auch gut war.

 

Eine Frage der Verantwortung

Unter Umständen hat das Problem bewusst oder unbewusst einen ganz anderen Ursprung. Vielleicht hat der Kunde tatsächlich nie seine internen Ziele konkret ausformuliert und jetzt hat er eine Argumentationsnot gegenüber dem Management. Wie einfach ist es da, die Verantwortung dem Projektteam zu übergeben und dabei den Kopf aus der Schlinge ziehen.

 

Fazit

Das Projektteam soll die Aussage, dass die Erwartungen nicht erfüllt werden auf jeden Fall ernst nehmen und mit dem Auftraggeber ins Gespräch kommen. Es ist wichtig zu wissen, wo die Gründe für diese Aussagen liegen, um daraus Learnings zu ziehen. Vielleicht kann man aber die Aussagen mit wenigen Handgriffen relativieren oder ins Positive umwandeln – was dann eine Win-Win Situation für beide Parteien geben würde.

 

Planlos = unsicher

Dass Pläne zum Projekt gehören weiss jeder Projektleiter. Er weiss auch, dass er ohne Projektplan praktisch nicht in der Lage ist, sein Projekt zu leiten. Doch ein Plan ist mehr, als ein Steuerungsinstrument. Ein Projektplan gibt auch Auskunft darüber, ob ein Projektleiter das Projekt überhaupt verstanden hat. 

Denn wenn der Projektleiter den Plan nur auf dem Papier aufmalen kann, aber die Zusammenhänge der einzelnen Abläufe nicht versteht, ist er nicht in der Lage, das Projekt zu steuern. Die Gründe dafür liegen auf der Hand:

• Souveränität fehlt: beim Auftraggeber oder im Team kann der Projektleiter nicht sofort auf Planabweichungen reagieren und mögliche Alternativen, oder auch Konsequenzen aufzeigen.
• Kreativität fehlt: tauchen Probleme auf, kann der Projektleiter nicht nach kreativen Lösungen suchen, sondern er versucht, mit allen Mitteln seinen „Plan“ durchzubringen. Damit ist aber unter Umständen niemandem geholfen.
• Weitsichtigkeit fehlt: Projektpläne sind unter anderem auch ein Frühwarnsystem. Ist der Projektleiter nicht in der Lage seinen Plan richtig zu interpretieren, kann er auch weitreichende Konsequenzen nicht erkennen

Projektpläne sollen  also nicht einfach nur existieren, damit man ein paar Meilensteine und einen Endtermin hat. Der Projektleiter muss den Plan verstehen und sollte die einzelnen Abhängigkeiten genau kennen. Ansonsten wirkt der Projektleiter gegenüber dem Team und dem Auftraggeber unsicher und eben: planlos.

Das Wassermelonen-Prinzip: Aussen grün, innen rot

Kürzlich hab ich auf PMHut den Bericht über das Wassermelonen Prinzip gelesen. Eigentlich ein ganz einfaches Prinzip: Das Projekt wird gegenüber dem Auftraggeber als „grün – alles on Track“ dargestellt. Aber beim genauen Hinschauen merkt man, dass das Projekt komplett in Schieflage steht – aussen grün, innen rot.

Der Schein trügt

Ich habe solche Projekte schon oft erlebt. Projekte, die schön dargestellt werden, aber eigentlich ein sinkendes Schiff sind. Ich frage mich bei solchen Situationen immer wieder: Wie kann es dazu kommen? Es ist ja nicht im Interesse des PLs, Dinge zu verschönern, obwohl eigentlich Handlungsbedarf da ist. Das wäre eine ziemlich schlechte Eigenschaft des Projektleiters. Und doch kommen solche Situationen vor.

Mögliche Begründung

Mögliche Gründe für das Auftreten des Wassermelonenprinzips könnten sein:

• Mangelnde Erfahrung des Projektleiters: Der Projektleiter sieht das Rote tatsächlich nicht, weil es vielleicht sein erstes Projekt ist und er kein verlässliches Projektteam und/oder Coach hat
• Das Projektteam verschleiert den Fortschritt (siehe auch Beitrag hier). Es kann durchaus mal vorkommen, dass das Projektteam eine komplette Fehleinschätzung des Fortschrittes macht, der Projektleiter aber im Glauben ist, dass alles ok ist. Der Projektleiter muss sein Team sehr gut kennen um zu wissen, ob die Aussagen korrekt sind, oder nicht. Auch hilft, selbst ein Auge auf das Resultat zu werfen ;o)
• „Unangenehme“ Aussagen aus dem Management können auf den Projektleiter (und das Team) einen Druck ausüben, der den Projektleiter dazu verleitet, falsche Aussagen zu machen, nur um einer weiteren Diskussion zu entgehen
• Zu viele Aufgaben wurden parallel eingeplant. Der Projektleiter tut sein Bestes, alles im Griff zu haben, aber das gelingt nur bedingt gut. Er reportet zwar alles auf Grün, da aber so viel gleichzeitig passiert, kriegt er erst zu spät mit, wenn es an einer Stelle eskaliert.
• Inhaltliche Mitarbeit auf dem Projekt: Oft arbeitet der Projektleiter selbst auch inhaltlich im Projekt mit (z.B. Ausarbeitung Konzept oder Designberatung.) Der Projektleiter sieht dann plötzlich vor lauter Bäumen den Wald nicht. Auf Grund der vielen Meetings und der intensiven inhaltlichen Mitarbeit, hatte der PL fast keine Zeit mehr, das Projekt richtig zu steuern. Dass im Hintergrund die Kosten/Zeit massiv überschritten wurde, merkt er erst bei genauerer Auswertung. 

Fazit

Wassermelonen im Projekt sind zu vermeiden, sagen sie doch auch etwas über Ehrlichkeit des Projektleiters aus – eines der wichtigsten Eigenschaften eines PLs. Trotzdem können sich Wassermelonen bilden, ohne das der Projektleiter es merkt. Hier ist es natürlich toll, wenn z.B. erfahrene Leute aus dem Projektteam oder ein Coach auf diese hinweisen und dem Projektleiter helfen, diese raschmöglichst zu eliminieren.

Projektfortschritt: „Wie weit bist du?“ – „Ich arbeite dran“

Das Projekt ist in der Entwicklung und die Implementierungsphase neigt sich langsam dem Ende zu. Der Projektleiter hat ein einigermassen grosses Projektteam und hat sich mit dem Team gut organisiert. Zweimal in der Woche gibt es ein Standup-Meeting, in dem die Arbeitsfortschritte und mögliche Probleme oder Hindernisse besprochen werden.

Jedes Teammitglied erzählt wie der Stand ist, was bei seinem Arbeitspaket noch offen ist und was erledigt wurde. Und nun kommt die klassische Antwort: „Ich arbeite dran“. Der Entwickler trifft weder eine Aussage über das was bereits erledigt wurde, noch eine über die verbleibenden Arbeiten. 

Indiz für Probleme

Solche Aussagen sind ein typisches Anzeichen, dass das Arbeitspaket möglicherweise aus dem Ruder läuft. Für den Projektleiter sind solche Aussagen hinsichtlich der Fortschrittsmessung nicht hilfreich, er kann den Fortschritt und auch den Restaufwand nicht einschätzen. Hinsichtlich Projektsteuerung sind diese  Aussagen aber enorm wichtig, weil der Projektleiter hier Handlungsbedarf erkennen kann. 

Umgang mit nichts aussagenden Antworten

Folgende Tipps für den Projektleitern im Umgang mit nicht aussagekräftigen Statusberichten der Entwickler:

• Vielleicht möchte der Entwickler seinen „Misserfolg“ nicht im Plenum zugeben, deshalb persönliches Gespräch suchen
• Tagesplan mit Entwickler festlegen und kleine Arbeitsschritte und Resultate definieren. Dann jeweils zweimal am Tag die erreichten Ziele überprüfen.
• Expertenwissen organisieren: Manchmal sieht auch der Entwickler vor lauter Bäume den Wald nicht mehr. Hier kann ein Experte vom selben Fach Abhilfe schaffen und mit einem anderen Blickwinkel auf die Arbeit sehen.
•  Regelmässige Reviews durchführen (mit Fachexperten)
•  Im Notfall: Arbeitspaket an jemand anderen Übertragen und für den Betroffenen „überschaubarere“ Aufgaben festlegen (Diplomatisch sein!)
• Motivation: Manchmal liegt es auch einfach an der Motivation und das Projektmitglied hat ein Durchhänger. Hier versuchen mit Motivation das Mitglied wieder ins Boot zu holen.

Fazit:

Praktisch in jedem Projekt gibt es Phasen, in denen einige Teammitglieder nicht richtig vorwärts kommen. Der Projektleiter sollte sich in solchen Situationen für die Betroffenen wirklich Zeit nehmen und gemeinsam mit dem Teammitglied einen Weg finden, aus dieser Situation herauszukommen. Das ist teilweise sehr zeitintensiv, vor allem bei grösseren Teams – Aber wenn das Team und jeder einzelne nicht performen kann, ist dem Projekt auch nicht geholfen.