Projekte scheitern zu Beginn

Pro­jek­te schei­tern nicht am Ende, Pro­jek­te schei­tern zu Beginn. Der Pro­jekt­start erfor­dert die gan­ze Füh­rungs­er­fah­rung des Pro­jekt­lei­ters. Anstatt aber das Pro­jekt mit sei­nem Umfeld aktiv zu gestal­ten, anstatt also am Sys­tem zu arbei­ten, wird sofort los­ge­legt, ein­fach mal gemacht, also im Sys­tem gear­bei­tet. Selbst wenn die Zie­le und der Umfang noch gar nicht so genau bekannt sind. Eini­ge weni­ge Tage Pro­jekt­in­itia­li­sie­rung brin­gen erstaun­li­chen Nut­zen: unaus­ge­spro­che­ne Annah­men kom­men früh­zei­tig auf den Tisch anstatt sich in der Tie­fe des Pro­jekts gärend anzu­stau­en. Die fol­gen­den Vor­ge­hens­wei­se hat sich für mich bewährt.

Am Anfang eines Work­shops zur Pro­jekt­in­itia­li­sie­rung steht die Fra­ge nach dem Nut­zen und den Zie­len: War­um soll das Pro­jekt gemacht wer­den? Die Grün­de sind viel­fäl­tig und rei­chen von der Erfül­lung neu­er gesetz­li­cher Vor­ga­ben über die Ablö­se ver­al­te­ter Tech­no­lo­gien bis hin zu einer völ­lig neu­en stra­te­gi­schen Aus­rich­tung eines Unter­neh­mens. In der Pra­xis fin­det sich meist aber eine Mischung aus meh­re­ren Grün­den, z.B. wenn eine alte Soft­ware auf dem Main­frame nach SAP migriert wer­den soll und die gesetz­li­chen Anfor­de­run­gen eine will­kom­me­ne Begrün­dung dafür lie­fern. Eine sol­che Ver­mi­schung von ver­schie­de­nen Nut­zen­aspek­ten des Pro­jekts führt meist zu Abhän­gig­kei­ten und teil­wei­se zu Wider­sprü­chen. Das ist völ­lig nor­mal und auch beherrsch­bar, aber nur wenn man die­se Abhän­gig­kei­ten kennt und in der Pla­nung berück­sich­ti­gen kann. Um im Bei­spiel der SAP-Migra­ti­on auf­grund gesetz­li­cher Anfor­de­run­gen zu blei­ben, wäre es viel­leicht sinn­voll eine ers­te Pha­se so zu pla­nen, dass auf jeden Fall die gesetz­li­chen Bestim­mung erfüllt wer­den auch wenn ande­re Funk­tio­nen noch feh­len und die Migra­ti­on noch nicht abge­schlos­sen ist.

Nach dem Nut­zen geht es zu den Pro­jekt­in­ter­es­sen­ten: Wer ist direkt oder indi­rekt vom Pro­jekt oder den Ergeb­nis­sen des Pro­jekts betrof­fen oder hat Inter­es­se am Pro­jekt? Auch die­se Umfeld­ana­ly­se ist kein Hexen­werk, birgt aber erheb­li­che Risi­ken wenn sie schlam­pig oder gar nicht durch­ge­führt wird. Die Alarm­glo­cken schril­len bei mir immer dann, wenn es heißt: „Ist doch eh alles klar!“ Ist es näm­lich meist nicht. Oder ist jeden­falls nicht deckungs­gleich. Wie beim Nut­zen und den Zie­len des Pro­jekts liegt der Mehr­wert einer sau­be­ren Umfeld­ana­ly­se in einen Pro­jekt­in­itia­li­sie­rungs-Work­shop nicht nur im kon­kre­ten Ergeb­nis, also einer Lis­te von Zie­len oder einer Stake­hol­der-Matrix, son­dern haupt­säch­lich dar­in, dass expli­zit dar­über dis­ku­tiert wird und sich ein gemein­sa­mes Ver­ständ­nis einstellt.

Wäh­rend der Dis­kus­si­on über Nut­zen, Zie­le und Inter­es­sen­ten wer­den nor­ma­ler­wei­se jede Men­ge Risi­ken ent­deckt, die im drit­ten Teil des Work­shops auf­ge­sam­melt und bewer­tet wer­den. Für sich genom­men auch nicht schwie­rig, aber lei­der oft sträf­lich ver­nach­läs­sigt: Wer beschäf­tigt sich zu Beginn vol­ler Taten­drang schon ger­ne mit dem was schief gehen kann.

Sobald Nut­zen und Zie­le, das Umfeld und die Risi­ken aus­rei­chend ver­stan­den sind, kann mit der gro­ben Pha­sen­pla­nung begon­nen wer­den. Im oben genann­ten Bei­spiel der SAP-Migra­ti­on könn­te sich z.B. ein Vor­ge­hen in zwei Pha­sen erge­ben: die ers­te Pha­se hät­te das Ziel die gesetz­li­chen Bestim­mun­gen zu erfül­len, wäh­rend die zwei­te Pha­se, viel­leicht sogar ite­ra­tiv in klei­nen Sprints, die feh­len­de Funk­tio­na­li­tät lie­fert. Es geht in die­sem Schritt dar­um das Pro­jekt top-down zu pla­nen und die gro­ßen Pha­sen, ihre Zie­le und ihren Umfang grob zu definieren.

Nach einem Tag Work­shop ist das Pro­jekt damit grob umris­sen und es herrscht ein gemein­sa­mes Ver­ständ­nis des Pro­jekts. Der Anfang ist damit gemacht. Nun kann die ers­te Pha­se genau­er geplant wer­den und ein Pro­jekt­team zusam­men­ge­stellt werden.

Für eine Pro­jekt­in­itia­li­sie­rung ist es nie zu spät. In abge­wan­del­ter Form lohnt sich ein sol­cher Work­shop auch für bereits lau­fen­de Pro­jek­te zur Jus­tie­rung oder auch zur Neuausrichtung.

Bild­nach­weis: Das Arti­kel­bild wur­de von Nor­lan­do Pob­re unter dem Titel „Start your engi­ne“ auf Flickr unter eine Crea­ti­ve Com­mons Lizenz (CC BY 2.0) veröffentlicht.

Share This Post

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.

Schreibe einen Kommentar