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.

Probleme und deren Lösung - Wie der Projektleiter der Problemlösung einen Schritt näher kommt

Das Projektteam oder ein Projektmitglied ist an einen Punkt gelangt, bei dem es nicht mehr weiter kommt. Im Statusmeeting fallen Aussagen wie: „ich schaff es nicht“, „ich komme nicht weiter“, „ich habe ein Problem, das ich nicht lösen kann“ etc. 

Bei solchen Fragestellungen ist es am effizientesten, wenn gemeinsam im Team und mit der betroffenen Person selbst nach einer Lösung gesucht wird. Ziel ist es nicht,  dass der Projektleiter das alleine tut, er weiss die Lösung ja auch nicht immer. Zur gemeinsamen Lösungsfindung können folgende Fragetechniken helfen:

• Fragen nach Ausnahmen: Auf „störungsfreie, erwünschte Zeiten lenken
  Beispiel: Wann war das letzte Mal, dass das Problem nicht auftauchte?
• Erklärungs-/Zukunftsfragen: Ziele in Zukunft konkretisieren
  Beispiel: Was wäre das erste Anzeichen, dass es gelöst werden kann?
• Hypothesen Fragen: Loten Möglichkeiten aus (was wäre wenn)
  Beispiel: Wenn ich dir sagen würde, das Problem hätte diese oder jene Ursache, was wäre dann für Dich anders?
• Zirkuläre Fragen: Fordern auf, aus Sicht eines Anderen zu antworten
  Beispiel: Was würde der Technische Lead zu diesem Ergebnis sagen?
• Fragen aus Zukunft/Vergangenheit: Perspektivenwechsel
  Beispiel: Wenn wir uns in 3 Wochen wieder treffen und ich frage, was aus dem Problem geworden ist, was würdest Du mir antworten?

Persönlich finde ich die Erklärungs/Zukunftsfragen und den Perspektivenwechsel sehr effizient. 

[Quelle: Social competence im Projektmanagement - Projektteams führen, entwickeln und motivieren von Christian Majer und Luis Stabauer]