IT-Projekte: Tickende Zeitbomben

Ihr kennt das. Neue oder ver­bes­ser­te Soft­ware für einen neu­en oder ver­bes­ser­ten Geschäfts­pro­zess. Bei­des gleich­zei­tig ent­wi­ckelt und aus­ge­rollt. Des schnel­len Nut­zens wegen. Funk­tio­niert aber in den wen­gis­ten Fäl­len. Und dann? Rich­tig! Schuld ist die IT. Schaf­fen es Mal wie­der nicht den unga­ren Pro­zess in eine rei­fe Soft­ware zu gie­ßen. Ein kur­zer Exkurs über das vor­pro­gram­mier­te Schei­tern von IT-Projekten.

For­scher der Uni­ver­si­tät Oxford und des Bera­tungs­hau­ses McK­in­sey unter­such­ten etwa 1500 Pro­jek­te mit einem durch­schnitt­li­chen Volu­men von 170 Mil­lio­nen US-Dol­lar. Mit erschre­cken­dem Ergebnis:

Jedes sechs­te Pro­jekt spreng­te das vor­ge­ge­be­ne Bud­get um durch­schnitt­lich 200 Pro­zent – und zwar infla­ti­ons­be­rei­nigt. Der geplan­te Zeit­rah­men wur­de in die­sen Fäl­len im Mit­tel um 70 Pro­zent überschritten.
CIO 11.10.2011 aus einer Stu­die von Oxford und McKinsey

Indus­trie­un­ter­neh­men ste­hen heu­te unter sehr gro­ßem Druck bedingt durch schnel­le­re und glo­ba­le­re Märk­te. Die Unter­neh­men müs­sen sehr viel fle­xi­bler und schnel­ler im Markt agie­ren als noch vor 20 oder 30 Jah­ren. Das Ergeb­nis sieht man am Bei­spiel der Auto­mo­bil­bran­che sehr schön. Die Modell­pa­let­te und Vari­an­ten­viel­falt ist in den letz­ten Jahr­zehn­ten deut­lich gewach­sen. BMW bei­spiels­wei­se hat­te Anfang der Sieb­zi­ger Jah­re des letz­ten Jahr­hun­derts eine Pro­dukt­pa­let­te aus drei Modell­rei­hen mit jeweils 2 bis 3 Moto­ri­sie­run­gen; im Jahr 2000 waren es aber bereits 6 ver­schie­de­ne Platt­for­men allein für die 3er Rei­he mit jeweils 3 bis 6 unter­schied­li­chen Motorisierungen. 

Sol­che enor­men Ver­än­de­run­gen wie die­se deut­li­che Zunah­me der Vari­an­ten­viel­falt haben Aus­wir­kung auf eine Viel­zahl von Pro­zes­sen im Unter­neh­men. Und kaum ein Pro­zess kommt ohne IT aus. Jede Pro­zess­ver­än­de­rung bedeu­tet daher in der Regel auch eine Ände­rung in einer hoch­kom­pli­zier­ten und über Jahr­zehn­te gewach­se­nen IT-Landschaft.

Nun wäre ja die Anpas­sung und Opti­mie­rung der Pro­zes­se für sich genom­men schon eine Her­aus­for­de­rung. Rich­tig span­nend wird die Auf­ga­be aber immer dann, wenn man die ers­te halb­ga­re Pro­zess­de­fi­ni­ti­on in das erst­bes­te IT-Sys­tem vom güns­tigs­ten Anbie­ter inte­grie­ren lässt und die Pro­zes­se qua­si neben­bei über die Soft­ware ver­än­dert. Schließ­lich soll ja schnell ein Nut­zen der IT-Inves­ti­on gerech­net wer­den können.

IT-Pro­jek­te sind ticken­de Zeit­bom­ben. Sie zer­stö­ren in unschö­ner Regel­mä­ßig­keit gan­ze Unter­neh­men und rui­nie­ren die Kar­rie­ren der Mana­ger, die für sie ver­ant­wort­lich sind.
CIO 11.10.2011 aus einer Stu­die von Oxford und McKinsey

Bei der­ar­tig kom­ple­xen Pro­blem­stel­lun­gen soll­te unbe­dingt eine ite­ra­ti­ve Vor­ge­hens­wei­se gewählt wer­den. Unbe­dingt abzu­ra­ten ist von einem Big-Bang, also dem Ver­such, alles gleich­zei­tig in einem gro­ßen Wurf ver­än­dern zu wol­len. Viel bes­ser sind klei­ne tas­ten­de Schrit­te mit denen das Neue erkun­det wird. Viel­leicht kann der neue Pro­zess ganz oder teil­wei­se zunächst ohne oder ohne vol­le IT-Unter­stü­zung erprobt wer­den. Viel­leicht kann man anschlie­ßend einen klei­nen Pro­to­ty­pen bau­en für weni­ge Key-User. Viel­leicht kann man die Umset­zung grund­sätz­lich agil in Sprints gestal­ten. Es geht letzt­lich dar­um Erfah­run­gen zu sam­meln, es geht um Feed­back. Und das kon­ti­nu­ier­lich und schnell.

<

p>Foto: Das Arti­kel­bild wur­de von Chris-Håvard Ber­ge unter dem Titel „Ach­tung! Minen!“ auf Flickr unter einer Crea­ti­ve Com­mons CC BY-SA 2.0 Lizenz veröffentlicht.

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.

12 Kommentare

Die­se Schluss­fol­ge­rung: „Bei der­ar­tig kom­ple­xen Pro­blem­stel­lun­gen soll­te unbe­dingt eine ite­ra­ti­ve Vor­ge­hens­wei­se gewählt wer­den.… bis .…. Es geht letzt­lich dar­um Erfah­run­gen zu sam­meln, es geht um Feed­back. Und das kon­ti­nu­ier­lich und schnell.“ ist ja eine bekann­te Erkennt­nis – lässt sich aber nicht mit einem PRO­JEKT-basier­ten Vor­ge­hen ver­ein­ba­ren. Das haben ja auch schon vie­le Leu­te erkannt, so etwa Ayelt Komus (sie­he Kapi­tel „3.2. Kon­zep­te und Prak­ti­ken des agi­len Manage­ments von Pro­jek­ten“ in http://www.korn.ch/archiv/publikationen/Neuer-Wein-in-alte-Schlaeuche-oder-Deja-vu.pdf) oder Dean Leffingwell.
Aber auch Ken Schwa­ber schreibt ganz klar in http://www.jeffsutherland.org/oopsla/schwaber.html das:
„Scrum is con­cer­ned with the manage­ment, enhan­ce­ment and main­ten­an­ce of an exis­ting pro­duct, while taking advan­ta­ge of new manage­ment tech­ni­ques and the axi­oms lis­ted abo­ve. Scrum is not con­cer­ned with new or re-engi­nee­red sys­tems deve­lo­p­ment efforts.“

Es geht also dar­um, sich end­lich davon zu lösen, alles als „Pro­jek­te“ zu mana­gen son­dern bes­ser eine kon­ti­nu­ier­li­che Ent­wick­lung über eine län­ge­re Zeit­span­ne anzustreben.

Dan­ke für die­sen Kommentar! 

Es geht also dar­um, sich end­lich davon zu lösen, alles als “Pro­jek­te” zu mana­gen son­dern bes­ser eine kon­ti­nu­ier­li­che Ent­wick­lung über eine län­ge­re Zeit­span­ne anzustreben.

Wenn man Pro­jekt tat­säch­lich sehr klas­sisch defi­niert, also als fes­ter Umfang / Ziel, fes­te Zeit und Kos­ten, dann stim­me ich dem unein­ge­schränkt zu. Und doch wer­den wei­ter­hin Pro­jek­te gemacht oder sol­che Vor­ha­ben Pro­jek­te genannt, die eigent­lich kei­ne sein soll­ten. Das gilt es zu erken­nen und dann wenigs­tens inner­halb die­ses Rah­mens des „Pro­jekts“ pas­send vorzugehen.

Das gilt es zu erken­nen und dann wenigs­tens inner­halb die­ses Rah­mens des “Pro­jekts” pas­send vorzugehen.“
Pas­send vor­zu­ge­hen könn­te auch bedeu­ten, die bereits seit den 90er-Jah­ren bei PRINCE2 vor­han­de­ne Mög­lich­keit inten­si­ver zu nut­zen, das Gesamt­pro­jekt in meh­re­re – eher kur­ze – „Durch­füh­rungs­pha­sen“ zu unter­tei­len (wobei jede ein „Pro­duktin­kre­ment“ lie­fert), und nach jeder (genau dem PRINCE2 fol­gend) den „Busi­ness Case“ auf sei­ne wei­ter­hin gege­be­ne Berech­ti­gung zu über­prü­fen, eine Retro­spek­ti­ve zur gera­de abge­schlos­se­nen Pha­se zu machen und erst JETZT die fol­gen­de Durch­füh­rungs­pha­se im Detail zu planen.
Offen­bar wird PRINCE2 jedoch gross­mehr­heit­lich nicht so genutzt son­dern als Rah­men für die übli­chen „Was­ser­fall­pha­sen“.
Da fra­ge ich mich schon:
Was müss­te denn anders sein, damit PRINCE2 tat­säch­lich als Rah­men für ein inkre­men­tell-adap­ti­ves Vor­ge­hen genutzt wird? An PRINCE2 als Frame­work kann es nicht lie­gen – die­ses ermun­tert ja genau dazu .… 

Mit der Ant­wort auf die­se Fra­ge könn­te viel­leicht auch erkannt wer­den, wie es denn mög­lich wäre, Scrum bei grös­se­ren Pro­jek­ten nicht erst in der Rea­li­sie­rungs­pha­se von inge­samt „was­ser­fall­ar­ti­gen“ Pro­jek­ten ein­zu­set­zen, also nicht so, wie z.B. hier in sli­de 9 beschrie­ben: http://www.ch-open.ch/fileadmin/user_upload/events/itbeschaffungskonferenz2013/08_DanielWild_AusschreibungAgilerSoftwareprojekte.pdf

Genau dar­um geht es: ite­ra­riv-inkre­men­tell vor­zu­ge­hen war ja noch nie ver­bo­ten und wäre oft ange­ra­ten. Und zwar nicht nur wäh­rend der Rea­li­sie­rung. All das fin­det sich schon seit Jah­ren im Ratio­nal-Uni­fied-Pro­cess (RUP). Das Wis­sen wäre da, wir haben aber ein mäch­ti­ges Umset­zungs­pro­blem. Ins­be­son­de­re in gro­ßen, hier­ar­chi­schen Indus­trie­un­ter­neh­men, also dort wo den 5‑Jah­res-Plä­nen und der Steue­rung über Bud­gets gefrönt wird. Ob und in die­ser feind­li­chen Umwelt ein ver­nünf­ti­ges Vor­ge­hen mög­lich ist, das ist die Frage.

Dan­ke für den guten Blog-Post Mar­cus. Ja, es ist bemer­kens­wert, dass sich immer noch vie­le nicht vor­stel­len kön­nen, dass man Pro­jek­te sinn­vol­ler­wei­se nicht so abwi­ckelt, dass die Dau­men­schrau­ben auf allen Varia­blen des Pro­jekts abso­lut fest­ge­zurrt wer­den. Ich glau­be per­sön­lich, dass in dem Fall sogar die erfolg­rei­chen Pro­jek­te dadurch erfolg­reich sind, indem sie schön gere­det wer­den. Ein­zig sinn­vol­ler Ansatz in gro­ßen Pro­jek­ten (so die über­haupt als sinn­voll erach­tet wer­den) und in kom­ple­xen Umwel­ten: das oben beschrie­ben ite­ra­ti­ve Vor­ge­hen mit kur­zen Feed­back­schlei­fen und ein varia­bler Scope! 

Pro­jekt kann dann durch­aus „Pro­jekt“ hei­ßen. Aber es läuft nicht mehr mit F. Tay­lor, H. Ford oder H. Gantt im Team ab. Es hat Leu­te wie R. Ack­off, E. Deming, P. Dru­cker, H. Mint­z­berg, G. Hamel etc etc an Bord und beginnt erstaun­lich erfolg­rei­che Ergeb­nis­se hervorzubringen.

Da ich gera­de kürz­lich selbst ein Agi­le-Pro­jekt im Auto­mo­ti­ve-Busi­ness abge­wi­ckelt habe – 2 Bei­spie­le in eige­ner Sache: BMW ent­wi­ckelt die Pro­zes­se für die Moto­ren­pro­duk­ti­on unter Ein­satz von Scrum, John­son Con­trols nutzt Scrum, um die neue Fahr­zeug­sit­ze zu engineeren.

Wie’s so schön heißt: der Pla­nungs­pro­zess ist alles, Plä­ne selbst sind wertlos ;)

lg. Mike

Dan­ke Mike für Dei­nen Kom­men­tar. Ich mache ja auch vie­le Pro­jekt im Auto­mo­ti­ve-Umfeld, aller­dings nur IT. Ich fin­de es sehr erstaun­lich und befremd­lich wie fort­schritt­lich Auto­mo­bil­her­stel­ler bei den Fahr­zeug­pro­jek­ten selbst agie­ren und wie anders die Welt im glei­chen Kon­zern bei IT-Pro­jek­ten aus­sieht. Hier gibt es einen deut­li­chen Klas­sen­un­ter­schied zwi­schen Pro­jek­ten die direkt was mit dem Fahr­zeug zu tun haben und sol­chen die nur indi­rekt damit zu tun haben (und das sind ja die meis­ten IT-Pro­jek­te, wenn es nicht gera­de Soft­ware ist, die ins Auto ver­baut wird).

Wahr­schein­lich liegt es dar­an, dass alles was direkt mit dem Fahr­zeug zu tun hat eher greif­bar ist. Daher setzt man da auch sehr schnell neue Metho­di­ken ein. Man sieht das Ergeb­nis direkt.

Bei den IT Pro­jek­ten dau­ert alles ein­fach zu lan­ge und bis die Aus­wir­kung dann tat­säch­lich sicht­bar sind dau­ert es eben noch­mal so lan­ge. Scha­de eigentlich.

Mei­ner Mei­nung nach liegt es dar­an, dass bei einem Auto­mo­bil­her­stel­ler das Auto eben das Pro­dukt ist und das bekommt die aller­höchs­te Auf­merk­sam­keit. Das erkennt man auch gut dar­an wel­che Res­sorts einen eige­nen Vor­stand haben. Und wel­che nicht. Bei­spiels­wei­se die IT.

Ich habe genug Kol­le­gen gehabt, die ihr Selbst­wert­ge­fühl über die Grö­ße des Pro­jek­tes defi­nier­ten, das sie gelei­tet haben. In hier­ar­chi­schen Orga­ni­sa­tio­nen ist die­ser Ansatz nicht sel­ten: Wich­tig ist nur, wer die gro­ßen Räder dreht. Da passt die Emp­feh­lung „start small“ über­haupt nicht ins Schema.

Dazu kommt, dass wir kei­ne „Kul­tur des Schei­terns“ haben. Damit mei­ne ich nicht, dass man Vor­ha­ben gedan­ken­los zunich­te machen soll­te, son­dern dass man nur durch Ver­such und Irr­tum lernt und schließ­lich bes­ser wird. Wer aber den ers­ten Ver­such per Defi­ni­ti­on zur Ide­al­lö­sung erklärt, der wird nie­mals besser.

Zuletzt ist es so, dass in IT-Pro­jek­ten sich jeder befä­higt sieht, in die Pla­nung ein­zu­grei­fen. In die­ser Bran­che ist das tat­säch­lich ver­brei­te­ter als in nicht-digi­ta­len Berei­chen: Wer schreibt schon sei­ner Auto­werk­statt vor, wie die das Fahr­zeug repa­riert? Bei IT-Pro­jek­ten fühlt sich jeder hin­ge­gen ein wenig als Fach­mann. Wenn das mit den zwei oben erwähn­ten Effek­ten zusam­men­kommt, dann ergibt das nar­zis­ti­sche Idio­ten, die Pro­jek­te ver­sau­en und dar­aus nicht lernen.

qed.

Dan­ke für Dei­ne Ergän­zun­gen! „Kul­tur des Schei­terns“ passt eben so gar nicht zu klas­si­schen, hier­ar­chisch orga­ni­sier­ten Industrieunternehmen.

Sehr schö­ner Blog, der end­lich ein­mal ein wich­ti­ges The­ma auf­greift, dass die Ände­rung der IT erst nach dem Abschluss des Chan­ge Pro­jek­tes geplant wer­den soll­te. Ich habe auch die Erfah­rung des öfte­ren machen dür­fen und kann das nur unterstreichen.
Auch gut: Kul­tur des Schei­terns => hier sehe ich die Ver­bän­de gebets­müh­len­ar­tig über Les­sons Lear­ned reden, es macht aber kei­ner! => der Vor­teil der Agi­lis­ten ist oft, dass die Retro­spek­ti­ve Bestand­teil des Pro­jek­tes wäh­rend der Lauf­zeit wird und man nicht erst auf das Ende war­tet, um dann doch nichts zu lernen.

Kul­tur des Schei­terns: Ich habe oft in den Groß­un­ter­neh­men fol­gen­de Spiel­art der „Kul­tur des Schei­terns“ ken­nen gelernt => Je höher der Wert (also die Mie­sen) eines Pro­jek­tes, das geschei­tert ist, war, des­to höher wur­de anschlie­ßend der Pro­jekt­lei­ter beför­dert. => Die­se Kul­tur beflü­gelt das Schei­tern von Pro­jek­ten enorm :-)

Zur Oxfor­d/M­cK­in­sey-Stu­die: Der Fra­ge­bo­gen war zwar sehr gut, aller­dings noch sehr anti­quiert klas­sisch und rein auf Mess­me­tho­den wie z.B. Func­tion Points reduziert.

Dan­ke Roland! Ich ken­ne gro­ße Unter­neh­men in denen sich IT-Pro­jek­te in weni­ger al 12 Mona­ten rech­nen müs­sen, sprich schnell einen Nut­zen brin­gen sol­len. Dann wird eben alles, sprich Chan­ge Pro­jekt und IT Pro­jekt, gleich­zei­tig durchgeführt. 

Je höher der Wert (also die Mie­sen) eines Pro­jek­tes, das geschei­tert ist, war, des­to höher wur­de anschlie­ßend der Pro­jekt­lei­ter befördert.

Das ist ja auch kon­se­quent den­je­ni­gen dann mög­lichst weit vom eigent­li­chen Pro­jekt­ge­sche­hen wegzubefördern …

Schreibe einen Kommentar