An meine erste Projektmanagement-Aufgabe erinnere ich mich noch wie gestern. Frisch zertifiziert nach fünf Mal drei Tagen Kurs und ähnlich intensiver Arbeit am Transfernachweis hatte ich es endlich geschafft, ich war Projektleiter und trug die Verantwortung für mein erstes Projekt. Ich brannte darauf das Gelernte in die Praxis umzusetzen. Also zog ich mich zurück und plante, optimierte die Auslastung der Mitarbeiter, analysierte Umfeld und Stakeholder und nicht zuletzt die Risiken, ausführlich und mustergültig. Als ich meiner Meinung nach fertig war, schrieb ich allen Beteiligten in einer längeren E‑Mail meine Erkenntnisse und natürlich meinen detaillierten Plan. Jetzt wussten alle was zu tun war, ich fühlte mich klasse und lehnte mich entspannt zurück.
Das gute Gefühl währte nicht allzu lange. Genauer gesagt nur fünf Minuten bis zum Anfruf von Karl, der als erfahrener Entwickler mehr oder weniger die Rolle des Chefdesigners im Projekt inne hatte. Karl fand meinen Plan zwar ganz nett (und wir wissen ja, dass nett die kleine Schwester von scheiße ist), meinte aber, dass ich doch einige technische Abhängigkeiten vergessen hätte. Da gäbe es Arbeitspakete die ich parallel geplant hätte, die aber dieselben Stellen im Code und dieselben Module beträfen und daher nur sequentiell bearbeitet werden könnten. Andere Arbeitspakete hätte ich in der falschen Reihenfolge geplant, weil es beispielsweise sinnvoller wäre das Logging ganz zu Beginn implementieren, damit wir später im Verlauf der weiteren Umsetzung die Logfiles zur Fehlersuche nutzen könnten. In dieser Weise ging unser Telefonat noch etwa eine halbe Stunde und mein schöner Plan löste sich dabei von Minute zu Minute ein Stück mehr auf.
Kurz nach dem Anruf von Karl kam Andrea in mein Büro. Andrea war die GUI-Entwicklerin in meinem Projekt, allerdings nur zu 50%, weil sie noch die Arbeiten in ihrem vorherigen Projekt abschließen musste. Das hatte ich meiner Meinung nach beim Optimieren der Auslastung auch entsprechend berücksichtigt. Das sah Andrea allerdings anders und darum war sie nun gleich Mal vorbei gekommen. Die nächsten zwei Wochen war Endspurt in ihrem alten Projekt angesagt, um den Go-Live nicht zu gefährden. Daher wären die zugesicherten 50% zwar prinzipiell richtig, aber eben nur im Schnitt über die nächsten Monate. Im Moment könne sie unmöglich die für sie in den nächsten Wochen geplanten Arbeitspakete schaffen. Um im Übrigen könne sie sowieso erst mit der GUI beginnen, wenn das Backend ihr die Daten wie spezifiziert lieferte und nicht vorher so wie ich das geplant hatte.
Umplanen und optimieren war also angesagt. Ich beschloss, mich für den Rest des Tages zurückzuziehen. Durch die vielen kleinen Arbeitspakete und die lehrbuchmäßig modellierten Abhängigkeiten gestaltete sich die Überarbeitung des Plans recht mühsam. Als ich spätabends endlich fertig war, verschickte ich den Plan stolz aber auch ein wenig genervt wieder per E‑Mail an das Team.
Diesmal schien der der Plan zu passen, denn erfreulicherweise hatte den Rest der Woche niemand mehr Einwände. Das kam mir sehr entgegen, weil ich ohnehin noch den Statusbericht und das Controlling fertigstellen musste. Ich ging also davon aus, dass nun alle wie geplant ihrer Arbeit nachgingen und ich mir am Montag den Status von allen abholen konnte. Die unschöne Realität holte mich dann am Montag Abend recht schnell ein als immer noch niemand auf meine morgendliche E‑Mail mit der Bitte um Meldung des Status in beiliegendem Formular geantwortet hatte.
Es stellte sich heraus, dass außer Karl und Andrea niemand den Plan genauer angesehen geschweige denn verstanden hatte. Trotzdem waren die Mitarbeiter nicht untätig gewesen. Im Gegenteil hatten sie eigentlich viel mehr erledigt als ich vorgesehen hatte, nur nicht in der Arbeitspaketstruktur, die ich mir mühsam ausgedacht hatte. Es hatte auch niemand ein Problem damit, mir den Status seiner Arbeit im Gespräch zu erklären, nur das Ausfüllen des Formulars, das ging den meisten zu weit.
In preparing for battle I have always found that plans are useless, but planning is indispensable.
Dwight D. Eisenhower
Was war passiert? Mit viel Schwung war ich in meine erste Projektmanagement-Aufgabe gestartet und wollte alles richtig machen. Ich begriff es als meine Aufgabe einen Plan zu erstellen, damit alle wissen, was sie tun sollen. Das war aber, wie bereits Eisenhower erkannte, nicht ganz richtig: nicht der Plan ist entscheidend, sondern der Prozess der Planung. Anstatt ganz tayloristisch das Denken vom Handeln zu trennen und im stillen Kämmerchen zu planen, hätte ich von Anfang an mit dem Team und anderen Stakeholdern einen Dialog über die Vorgehensweise suchen sollen. Eine zusätzliche Lektion aus dieser Episode war für mich der Wert unmittelbarer Kommunikation. Einen Plan, den vorher noch niemand gesehen hatte, per E‑Mail zu verteilen und seine Abarbeitung zu erwarten, war rückblickend dann doch ein wenig naiv. Auch und gerade, weil es eben nur mein Plan war.
Artikelbild: MIKI Yoshihito bei flickr.com (CC BY 2.0)
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
4 Kommentare
Nette Anekdote. Womit Du bestätigst: Projektmanagement lernt man hat nicht im Kurs, sondern nur durch Erfahrung.
Offene Kommunikation in der Planung ist essentiell. Genauso wichtig ist aber, dass der Projektleiter in diese Kommunikation mit eigenen Ideen reingeht und sich nicht nur auf den Input der Experten verlässt. Zumindest ein „early draft high level plan“ sollte in der Tasche stecken, sonst kann (bei einem neuen Team) Akzeptanzprobleme geben. Und manche Mitarbeiter schätzen auch das Gefühl, einen Projektleiter zu haben, der weiss wo die Reise hingeht.
Danke Tonio, ganz wichtige Ergänzung. Als Projektleiter muss ich eine gewisse Vorstellung haben wohin es geht und die auch kommunizieren können. Und sei es nur, damit wir uns alle dann daran reiben können. Die Akzeptanz sehe ich da gar nicht Mal so sehr im Vordergrund, mich treiben ganz pragmatische Gründe: man kommt einfach viel schneller zu einem Ergebnis, wenn man mit einem konkreten Plan startet und den verbessert. Das gilt übrigens auch für viele andere Workshops.
Hallo Marcus,
so ähnlich könnte ich meine ersten Erfahrungen auch zusammenfassen. (Du schreibst aber schöner.)
Deine Erkenntnisse unterschreibe ich sofort. Was ich noch ergänzen möchte ist, dass man besser den zum PM macht, der auch den größten Nutzen vom Ergebnis hat. Diese Person hat nämlich ein höheres Interesse, das Projekt abzuschließen und weiß zudem, wo man Abstriche machen kann, wenn es eng wird mit der Zeit.
Diese Empfehlung wird nicht immer klappen, das weiß ich. Aber ich formuliere das mal als Anspruch.
Beste Grüße, Jan
Hallo Jan, vielen Dank für das liebe Kompliment! Deinen Anspruch teile ich, genauso wie Deine Bedenken, dass er erfüllbar ist in der Praxis. Der Projektleiter sollte nie sein oberster Sachbearbeiter sein. Leider macht man in der Praxis eben doch gerne den Top-Experten zum Projektleiter, der dann das Projekt eben nicht führt, sondern lieber inhaltlich arbeitet, dann dafür bekam er bisher die Anerkennung und dafür wurde er ausgebildet. Dieses Muster ist für mich so etwas wie der Kardinalfehler in der Besetzung von Projektrollen.