Das erste Projekt

An mei­ne ers­te Pro­jekt­ma­nage­ment-Auf­ga­be erin­ne­re ich mich noch wie ges­tern. Frisch zer­ti­fi­ziert nach fünf Mal drei Tagen Kurs und ähn­lich inten­si­ver Arbeit am Trans­fer­nach­weis hat­te ich es end­lich geschafft, ich war Pro­jekt­lei­ter und trug die Ver­ant­wor­tung für mein ers­tes Pro­jekt. Ich brann­te dar­auf das Gelern­te in die Pra­xis umzu­set­zen. Also zog ich mich zurück und plan­te, opti­mier­te die Aus­las­tung der Mit­ar­bei­ter, ana­ly­sier­te Umfeld und Sta­ke­hol­der und nicht zuletzt die Risi­ken, aus­führ­lich und mus­ter­gül­tig. Als ich mei­ner Mei­nung nach fer­tig war, schrieb ich allen Betei­lig­ten in einer län­ge­ren E‑Mail mei­ne Erkennt­nis­se und natür­lich mei­nen detail­lier­ten Plan. Jetzt wuss­ten alle was zu tun war, ich fühl­te mich klas­se und lehn­te mich ent­spannt zurück.

Das gute Gefühl währ­te nicht all­zu lan­ge. Genau­er gesagt nur fünf Minu­ten bis zum Anfruf von Karl, der als erfah­re­ner Ent­wick­ler mehr oder weni­ger die Rol­le des Chef­de­si­gners im Pro­jekt inne hat­te. Karl fand mei­nen Plan zwar ganz nett (und wir wis­sen ja, dass nett die klei­ne Schwes­ter von schei­ße ist), mein­te aber, dass ich doch eini­ge tech­ni­sche Abhän­gig­kei­ten ver­ges­sen hät­te. Da gäbe es Arbeits­pa­ke­te die ich par­al­lel geplant hät­te, die aber die­sel­ben Stel­len im Code und die­sel­ben Modu­le beträ­fen und daher nur sequen­ti­ell bear­bei­tet wer­den könn­ten. Ande­re Arbeits­pa­ke­te hät­te ich in der fal­schen Rei­hen­fol­ge geplant, weil es bei­spiels­wei­se sinn­vol­ler wäre das Log­ging ganz zu Beginn imple­men­tie­ren, damit wir spä­ter im Ver­lauf der wei­te­ren Umset­zung die Log­files zur Feh­ler­su­che nut­zen könn­ten. In die­ser Wei­se ging unser Tele­fo­nat noch etwa eine hal­be Stun­de und mein schö­ner Plan lös­te sich dabei von Minu­te zu Minu­te ein Stück mehr auf.

Kurz nach dem Anruf von Karl kam Andrea in mein Büro. Andrea war die GUI-Ent­wick­le­rin in mei­nem Pro­jekt, aller­dings nur zu 50%, weil sie noch die Arbei­ten in ihrem vor­he­ri­gen Pro­jekt abschlie­ßen muss­te. Das hat­te ich mei­ner Mei­nung nach beim Opti­mie­ren der Aus­las­tung auch ent­spre­chend berück­sich­tigt. Das sah Andrea aller­dings anders und dar­um war sie nun gleich Mal vor­bei gekom­men. Die nächs­ten zwei Wochen war End­spurt in ihrem alten Pro­jekt ange­sagt, um den Go-Live nicht zu gefähr­den. Daher wären die zuge­si­cher­ten 50% zwar prin­zi­pi­ell rich­tig, aber eben nur im Schnitt über die nächs­ten Mona­te. Im Moment kön­ne sie unmög­lich die für sie in den nächs­ten Wochen geplan­ten Arbeits­pa­ke­te schaf­fen. Um im Übri­gen kön­ne sie sowie­so erst mit der GUI begin­nen, wenn das Backend ihr die Daten wie spe­zi­fi­ziert lie­fer­te und nicht vor­her so wie ich das geplant hatte.

Umpla­nen und opti­mie­ren war also ange­sagt. Ich beschloss, mich für den Rest des Tages zurück­zu­zie­hen. Durch die vie­len klei­nen Arbeits­pa­ke­te und die lehr­buch­mä­ßig model­lier­ten Abhän­gig­kei­ten gestal­te­te sich die Über­ar­bei­tung des Plans recht müh­sam. Als ich spät­abends end­lich fer­tig war, ver­schick­te ich den Plan stolz aber auch ein wenig genervt wie­der per E‑Mail an das Team.

Dies­mal schien der der Plan zu pas­sen, denn erfreu­li­cher­wei­se hat­te den Rest der Woche nie­mand mehr Ein­wän­de. Das kam mir sehr ent­ge­gen, weil ich ohne­hin noch den Sta­tus­be­richt und das Con­trol­ling fer­tig­stel­len muss­te. Ich ging also davon aus, dass nun alle wie geplant ihrer Arbeit nach­gin­gen und ich mir am Mon­tag den Sta­tus von allen abho­len konn­te. Die unschö­ne Rea­li­tät hol­te mich dann am Mon­tag Abend recht schnell ein als immer noch nie­mand auf mei­ne mor­gend­li­che E‑Mail mit der Bit­te um Mel­dung des Sta­tus in bei­lie­gen­dem For­mu­lar geant­wor­tet hatte.

Es stell­te sich her­aus, dass außer Karl und Andrea nie­mand den Plan genau­er ange­se­hen geschwei­ge denn ver­stan­den hat­te. Trotz­dem waren die Mit­ar­bei­ter nicht untä­tig gewe­sen. Im Gegen­teil hat­ten sie eigent­lich viel mehr erle­digt als ich vor­ge­se­hen hat­te, nur nicht in der Arbeits­pa­ket­struk­tur, die ich mir müh­sam aus­ge­dacht hat­te. Es hat­te auch nie­mand ein Pro­blem damit, mir den Sta­tus sei­ner Arbeit im Gespräch zu erklä­ren, nur das Aus­fül­len des For­mu­lars, das ging den meis­ten zu weit.

In pre­pa­ring for batt­le I have always found that plans are useless, but plan­ning is indispensable.
Dwight D. Eisenhower

Was war pas­siert? Mit viel Schwung war ich in mei­ne ers­te Pro­jekt­ma­nage­ment-Auf­ga­be gestar­tet und woll­te alles rich­tig machen. Ich begriff es als mei­ne Auf­ga­be einen Plan zu erstel­len, damit alle wis­sen, was sie tun sol­len. Das war aber, wie bereits Eisen­ho­wer erkann­te, nicht ganz rich­tig: nicht der Plan ist ent­schei­dend, son­dern der Pro­zess der Pla­nung. Anstatt ganz tay­lo­ris­tisch das Den­ken vom Han­deln zu tren­nen und im stil­len Käm­mer­chen zu pla­nen, hät­te ich von Anfang an mit dem Team und ande­ren Sta­ke­hol­dern einen Dia­log über die Vor­ge­hens­wei­se suchen sol­len. Eine zusätz­li­che Lek­ti­on aus die­ser Epi­so­de war für mich der Wert unmit­tel­ba­rer Kom­mu­ni­ka­ti­on. Einen Plan, den vor­her noch nie­mand gese­hen hat­te, per E‑Mail zu ver­tei­len und sei­ne Abar­bei­tung zu erwar­ten, war rück­bli­ckend dann doch ein wenig naiv. Auch und gera­de, weil es eben nur mein Plan war.

Arti­kel­bild: MIKI Yoshi­hi­to bei flickr.com (CC BY 2.0)

Teile diesen Beitrag

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

4 Kommentare

Net­te Anek­do­te. Womit Du bestä­tigst: Pro­jekt­ma­nage­ment lernt man hat nicht im Kurs, son­dern nur durch Erfahrung.
Offe­ne Kom­mu­ni­ka­ti­on in der Pla­nung ist essen­ti­ell. Genau­so wich­tig ist aber, dass der Pro­jekt­lei­ter in die­se Kom­mu­ni­ka­ti­on mit eige­nen Ideen rein­geht und sich nicht nur auf den Input der Exper­ten ver­lässt. Zumin­dest ein „ear­ly draft high level plan“ soll­te in der Tasche ste­cken, sonst kann (bei einem neu­en Team) Akzep­tanz­pro­ble­me geben. Und man­che Mit­ar­bei­ter schät­zen auch das Gefühl, einen Pro­jekt­lei­ter zu haben, der weiss wo die Rei­se hingeht.

Dan­ke Tonio, ganz wich­ti­ge Ergän­zung. Als Pro­jekt­lei­ter muss ich eine gewis­se Vor­stel­lung haben wohin es geht und die auch kom­mu­ni­zie­ren kön­nen. Und sei es nur, damit wir uns alle dann dar­an rei­ben kön­nen. Die Akzep­tanz sehe ich da gar nicht Mal so sehr im Vor­der­grund, mich trei­ben ganz prag­ma­ti­sche Grün­de: man kommt ein­fach viel schnel­ler zu einem Ergeb­nis, wenn man mit einem kon­kre­ten Plan star­tet und den ver­bes­sert. Das gilt übri­gens auch für vie­le ande­re Workshops.

Hal­lo Marcus,

so ähn­lich könn­te ich mei­ne ers­ten Erfah­run­gen auch zusam­men­fas­sen. (Du schreibst aber schöner.)

Dei­ne Erkennt­nis­se unter­schrei­be ich sofort. Was ich noch ergän­zen möch­te ist, dass man bes­ser den zum PM macht, der auch den größ­ten Nut­zen vom Ergeb­nis hat. Die­se Per­son hat näm­lich ein höhe­res Inter­es­se, das Pro­jekt abzu­schlie­ßen und weiß zudem, wo man Abstri­che machen kann, wenn es eng wird mit der Zeit.

Die­se Emp­feh­lung wird nicht immer klap­pen, das weiß ich. Aber ich for­mu­lie­re das mal als Anspruch.

Bes­te Grü­ße, Jan

Hal­lo Jan, vie­len Dank für das lie­be Kom­pli­ment! Dei­nen Anspruch tei­le ich, genau­so wie Dei­ne Beden­ken, dass er erfüll­bar ist in der Pra­xis. Der Pro­jekt­lei­ter soll­te nie sein obers­ter Sach­be­ar­bei­ter sein. Lei­der macht man in der Pra­xis eben doch ger­ne den Top-Exper­ten zum Pro­jekt­lei­ter, der dann das Pro­jekt eben nicht führt, son­dern lie­ber inhalt­lich arbei­tet, dann dafür bekam er bis­her die Aner­ken­nung und dafür wur­de er aus­ge­bil­det. Die­ses Mus­ter ist für mich so etwas wie der Kar­di­nal­feh­ler in der Beset­zung von Projektrollen.

Schreibe einen Kommentar