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

12 Kommentare

Hans-Peter Korn 29. September 2013 Antworten

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.

Marcus Raitner 29. September 2013 Antworten

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.

Hans-Peter Korn 30. September 2013 Antworten

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

Marcus Raitner 1. Oktober 2013 Antworten

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.

Mike Leber 30. September 2013 Antworten

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

Marcus Raitner 30. September 2013 Antworten

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).

Danijela G. 1. Oktober 2013 Antworten

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.

Marcus Raitner 1. Oktober 2013 Antworten

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.

Christian Aust 1. Oktober 2013 Antworten

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.

Marcus Raitner 1. Oktober 2013 Antworten

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.

Roland Spengler 2. Oktober 2013 Antworten

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.

Marcus Raitner 3. Oktober 2013 Antworten

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