18
Jul 2014
Meilenstein – Der Projektmanagement-Blog

Mist im Projekt – fünf Finger gegen Projektfallen

"Und Ihr Projekt – alles im grünen Bereich?" Projektleiter fragen mich oft entnervt: "Weiß denn mein… (Auftraggeber, Lenkungsausschuss, Ehepartner…) nicht, dass in keinem Projekt der Welt jemals alles im grünen Bereich sein kann?" Spätestens nach der zweiten Woche ist immer irgendein Arbeitspaket im Verzug – und dann? Viele Projektratgeber propagieren Projektmanagement in der Idealfassung. Was etliche Projektmanager dabei vermissen, ist ein qualifiziertes PM-Troubleshooting.

Anzeige

Ich leite, begleite und berate seit über 30 Jahren Projekte. Was mir und den ProjektmanagerInnen, die ich unterstütze, am meisten geholfen hat, ist ein fünfgliedriges Instrument, das in jüngster Zeit so umfänglich praxisgetestet wurde, dass seine Anwendung und Wirkungsweise inzwischen ein ganzes Buch füllen könnte – was es seit Neuestem tatsächlich tut ("Wenn Manager Mist bauen", Redline-Verlag).

1. Was übersehen wir?

Selbst Projektleiter mit geringer Projekterfahrung sagen oft – hinterher: "Das hätten wir kommen sehen müssen!" Wenn ich im Coaching frage: "Was genau?", kommen immer dieselben Antworten:

  • "Dass der Auftraggeber zu optimistisch ist."
  • "Dass bestimmte Arbeitspakete länger dauern als gedacht."
  • "Dass unsere strukturellen Engstellen (Labor, Vertrieb, Controlling…) uns ausbremsen."

Ex post bemerkt man, was man übersehen hat. Die Kunst besteht darin, das Übersehene ex ante in die Grobplanung zu integrieren: "Wir haben jetzt die Meilensteine geplant – was genau haben wir übersehen? Wie müssen wir die Planung korrigieren? Mit wem müssen wir entsprechend nachverhandeln?" Diese "Daumenfrage" des präventiven Troubleshootings im Projekt ist simpel. Sie wird meist nicht gestellt. Kritiker behaupten, weil manche Projektleiter Unangenehmes lieber verdrängen.

Ich bevorzuge die konstitutive Erklärung: Viele Projektteams stellen bis heute noch keine W-Fragen (Wer macht was bis wann mit welchen Abnahmekriterien?). Sobald diese Fragen jedoch vom Projektleiter als Standard eingeführt werden, werden sie auch gestellt. Dasselbe gilt für die "Daumenfrage" des präventiven PM-Troubleshootings: Was übersehen wir? Was als Standard konstituiert wird, wird auch gefragt.

2. Warum geht das nicht weiter?

Ich erinnere mich an ein Projekt, das massiv ausgebremst wurde. Jedes Mal, wenn ich vor dem Lenkungsausschuss stand, verhedderte sich dieser in den Eigeninteressen seiner Mitglieder. Wir waren mächtig sauer und schimpften wie die Rohrspatzen über "die da oben".

Bis der Team-Benjamin naiv die Frage stellte: "Warum geht das eigentlich nicht weiter?" Die zweite Troubleshooting-Frage, die Zeigefingerfrage. Vor lauter Schimpfen hatten wir sie nie ernsthaft gestellt. Die Antwort war: "Weil die sich nicht einig sind und weil ich als Projektleiter eine Einigung nicht herstellen kann!" Danach wurden wir nie wieder ausgebremst.

Die Lösung war einfach: Vor jeder anstehenden Entscheidung besuchte ich jenes Mitglied des Lenkungsausschusses, das mit allen anderen gut konnte. Er zog hinter den Kulissen die Strippen – in der Sitzung selbst musste ich dann lediglich den gut vorbereiteten Entschluss abholen. Ich plädiere damit nicht für den "kleinen Dienstweg", sondern: Nur wer Hemmnisse aktiv hinterfragt, kann sie beseitigen.

3. Was hilft wirklich?

Was passiert, wenn ein Projekt in die Bredouille gerät? Man stellt eine Mängelliste auf. Eine Projektmitarbeiterin berichtete mir von ihrem Projekt: Mängelliste mit 600 Punkten. Der Projektleiter verteilte diese der Reihe nach ans Team. Geholfen hat das nicht wirklich und vor allem nicht schnell genug. Bis das Team feststellte, dass der Engpass für die meisten Verspätungen bei einer genehmigenden Behörde lag.

Der Projektleiter sprach mit dem Behördenleiter darüber, was seine Leute brauchten, um schneller entscheiden zu können – und zwei Wochen später war das Projekt mehr oder weniger überm Berg. Warum ist das Team da nicht gleich draufgekommen? Listenblindheit (s.o. Punkt 1).

4. Geht's noch einfacher?

Ein Vertriebsleiter erzählte mir von einem Projekt, das sich im letzten Viertel als nicht ganz so genial herausstellte wie die Geschäftsleitung propagiert hatte. Was machte sie? Sie wollte eine Marktforschung in Auftrag geben.

Der Vertriebsleiter bog das ab und berief stattdessen eine 40-köpfige Focus Group von Kunden ein. Sie kostete ein Zehntel der Marktforschung und lieferte nach drei Wochen direkt umsetzbare Ergebnisse. Moral des Vertriebsleiters: "Warum kompliziert, wenn es auch einfach geht?" Die vierte Anti-Mist-Frage. Wie oft stellen Sie sie?

5. Was blockiert die letzte Meile?

Was leider jeder Projektmanager weiß: Von fünf beschlossenen Maßnahmen werden höchstens zwei bis zum Ende durchgezogen: "Ah, Mist – bin noch nicht dazu gekommen!" Was hält dich denn davon ab? Und dann zurück zur zweiten Frage (s.o.).

Was alle wissen, aber wenige machen

Ich kenne kaum Fragen, die trivialer sind als diese fünf Anti-Mist-Fragen. Mir scheint, manchen sind sie zu trivial. Das ist schade. Denn jene, die sie gebetsmühlenartig stellen, kriegen nicht nur ihren Mist schneller vom Hof – sie bauen von vorne herein auch viel weniger Mist im Projekt.

Bisher gibt es 2 Kommentare
Löst dies das "wicked dilemma" ? = Das Problem/Anforderung wird erst ausreichend verstanden, wenn es gelöst wurde.
Wenn es v.a. ein ex post Verständnis gibt (und wenig ex ante) muss die logische Konsequenz lauten möglichst viele ex post Erkenntnisse pro Zeit zu erzeugen (= Empiric Process Control).
Also kleine Teile(small batch size) schnell soweit fertigstellen, dass ich daraus Erkenntnisse für das weitere Vorgehen ziehen kann.
Das widerspricht für mich dem üblichen Phasen-getriebenen Modell, wo man ALLES(large batch size) vorab analysiert, ALLES plant, ALLES umsetzt und erst ganz am Projektende erkennt, dass sich ein Großteil meiner (oft impliziten) Annahmen aus der lange zurückliegenden Analyse sich als falsch herausstellen und mein Plan zum Großteil auf falschen Annahmen beruht.
large batch size = long cycle times = long feedback loops.
Wenn ich jedesmal merke, dass ich stark von meinem ursprünglichen Plan abweiche, muss ich das Kosten/Nutzen Verhältnis einer einmaligen Planung in Frage stellen.
Wenn ich erkenne, dass Plan und Realität ständig auseinanderlaufen, muss ich die Planung über die gesamte Laufzeit verteilen. D.h. ich weiss SICHER, dass es zu unvorhersehbaren Planänderungen kommen wird. Lagen die Änderungen zB im Bereich von 50% , dann hat ein ERSTER Plan für das nächste Projekt wahrscheinlich auch nur eine Zuverlässigkeit von 50%.
Zumindest in der Software-Entwicklung sind i.d.R. weder scope noch Systemverhalten des Business-Kontext zuverlässig vorhersagbar. Ständiges Neubewerten der Situation und Anpassen des nächsten Schrittes sind unausweichlich (short feedback loops). Sind budget, time und quality A PRIORI festgelegt, muss scope variabel sein.
Es geht als nicht mehr darum vergeblich zu versuchen A PRIORI scope festzulegen, sondern über die gesamte Laufzeit Value Delivery zu maximieren.
vor 2 Jahre 9 Wochen Agile Program Manager
Es lebe die Agilität - ich habe eine S-Klasse bestellt und erhalte eine Mittelklasse aber eben eine tolle mit vielen Features? Variable Scopes - so ein Quatsch!
vor 2 Jahre 8 Wochen TR aus B
Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare aus und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.
Kommentar verfassen
Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Bitte geben Sie Ihren Namen an: *
Tech Link