Woran IT-Projekte scheitern und wie Sie es frühzeitig erkennen

IT-Pro­jek­te schei­tern mit einer Wahr­schein­lich­keit von 20%. Bei gro­ßen Pro­jek­ten von 10.000 func­tion-points oder mehr steigt die Wahr­schein­lich­keit sogar auf 40%. Nicht ein­mal ein Drit­tel aller IT-Pro­jek­te hält Zeit­plan und Bud­get ein und lie­fert die erwar­te­te Funk­tio­na­li­tät und Qua­li­tät. (Quel­le: Stan­dish Group. CHAOS Report, 2004). Wor­an liegt das? Oft las­sen sich die Pro­ble­me und Risi­ken bereits früh­zei­tig erken­nen. In Ihrem Arti­kel Ear­ly War­ning Signs of IT-Pro­ject Fail­ure: The Domi­nant Dozen haben Kap­pel­man, McKee­man und Zhang Früh­in­di­ka­to­ren iden­ti­fi­ziert und zusammengefasst.

Eines vor­weg: IT-Pro­jek­te schei­tern fast nie an der IT. Sicher­lich ist neue Tech­no­lo­gie ein Risi­ko, aber eines, das sich beherr­schen und mini­mie­ren lässt. Die wah­ren Risi­ken und die ent­spre­chen­den Früh­in­di­ka­to­ren lie­gen alle in den bei­den Berei­chen Mensch und Pro­zess. Und ein­mal mehr zeigt sich, dass ein erfolg­rei­cher Pro­jekt­ma­na­ger in ers­ter Linie zwei Din­ge beherr­schen muss: Füh­rung und Kom­mu­ni­ka­ti­on. Im Detail sind in dem Arti­kel die fol­gen­den Früh­in­di­ka­to­ren genannt, wobei früh bedeu­tet, dass die­se bereits in der ers­ten 20% der ursprüng­lich geplan­ten Lauf­zeit des Pro­jekts erkenn­bar sind.

Mensch

  1. Feh­len­de Unter­stüt­zung durch das Top-Management
    Wenn das Top-Manage­ment nicht hin­ter dem Pro­jekt steht, wer­den wich­ti­ge Res­sour­cen feh­len, weil Men­schen in Orga­ni­sa­tio­nen dazu ten­die­ren ihre Auf­merk­sam­keit und ihre Zeit auf das zu rich­ten, was dem Top-Manage­ment wich­tig ist.
  2. Schwa­che Projektmanager
    Pro­jekt­lei­ter die nicht füh­ren oder kom­mu­ni­zie­ren kön­nen wer­den nie alle Stake­hol­der inklu­si­ve dem eige­nen Team rich­tig im Griff haben. Ins­be­son­de­re Pro­jekt­ma­na­ger, die auf­grund ihrer guten Leis­tung als Pro­gram­mier oder Archi­tekt zu Mana­gern wur­den, stel­len ohne aus­rei­chen­de Aus­bil­dung und Coa­ching ein erheb­li­ches Risi­ko dar.
  3. Stake­hol­der nicht aus­rei­chend eingebunden
    Fast eine Fol­ge der vori­gen bei­den Punk­te. Das Pro­jekt benö­tigt die Zuar­bei­ten von Stake­hol­dern, die ihrer­seits auch viel ande­res zu tun haben. Wenn in deren Prio­ri­tä­ten das Pro­jekt nicht weit genug oben ist, wer­den die Zuar­bei­ten aus­blei­ben und das Pro­jekt scheitern.
  4. Pro­jekt­team nicht aus­rei­chend mit dem Pro­jekt identifiziert
    Eben­falls eine Fol­ge der bei­den ers­ten Punk­te. Eine kla­re Füh­rungs­auf­ga­be des Pro­jekt­ma­na­gers ist es, dem Team die Zie­le des Pro­jekts und den Zeit­plan nahe zu brin­gen und es zu ihrem Pro­jekt zu machen.
  5. Feh­len­des Wis­sen oder feh­len­de Fer­tig­kei­ten der Teammitglieder
    Die­ses Risi­ko beein­flusst maß­geb­lich die Fähig­keit des Teams Tech­no­lo­gie-Risi­ken zu beherr­schen. Wie­der eine kla­re Füh­rungs­auf­ga­be des Pro­jekt­ma­na­gers, Defi­zi­te zu erken­nen und dafür zu sor­gen, dass das nöti­ge Wis­sen erwor­ben wird.
  6. Fach­ex­per­ten nicht aus­rei­chend für das Pro­jekt verfügbar
    Fach­ex­per­ten sind eine, aber sehr essen­ti­el­le Grup­pe von Stake­hol­dern. Es muss gelin­gen die­se in aus­rei­chen­der Wei­se für das Pro­jekt zu gewin­nen oder sie vom Top-Manage­ment frei­spie­len zu lassen.

Prozess

  1. Anfor­de­run­gen und Erfolgs­kri­te­ri­en nicht festgelegt
    Ein Pro­jekt ohne aus­rei­chend fixier­te Anfor­de­run­gen und ins­be­son­de­re ohne Erfolgs­kri­te­ri­en kann per Defi­ni­ti­on kei­nen Erfolg haben. Es ist uner­läss­lich, so früh wie mög­lich die Fest­le­gung der Anfor­de­run­gen ein­zu­for­dern. Auch und gera­de bei Widerständen.
  2. Kein Pro­zess zum Manage­ment von Ände­run­gen des Umfangs
    Kon­sens über die Anfor­de­run­gen initi­al her­zu­stel­len ist aber nur die hal­be Mie­te. Im Schnitt ändern sich 2% der Anfor­de­run­gen pro Monat (Jones. Pat­terns of Soft­ware Sys­tem Fail­ure and Suc­cess, 1995). Eine guter Pro­zess zum Manage­ment der Ver­än­de­run­gen ist somit unerlässlich.
  3. Nicht effek­ti­ver Umgang mit Terminplanung
    Es wird oft ver­ges­sen, dass ein Ter­min­plan neben der Pla­nung des Pro­jekt­ma­na­gers auch den Zweck der Ver­mitt­lung des Plans und dem Stand des Pro­jekts an die Stake­hol­der hat. Zu oft bleibt der Plan Pri­vat­ver­gnü­gen des Manage­ments und wird nicht zum Fahr­plan für das gesam­te Team. Ger­ne wer­den auch Ver­zü­ge in frü­hen Pha­sen des Pro­jekts blau­äu­gig igno­riert und nach dem Mot­to ver­fah­ren: „Das holen wir wie­der auf!“.
  4. Feh­len­de Kom­mu­ni­ka­ti­on zwi­schen Stakeholdern
    Sobald die Stake­hol­der nicht regel­mä­ßig mit­ein­an­der arbei­ten und sich aus­tau­schen, beginnt das Pro­jekt in ver­schie­de­ne Rich­tun­gen zu drif­ten. Die­se Kohä­renz her­zu­stel­len erfor­dert nicht nur die rich­ti­gen kom­mu­ni­ka­ti­ven Fähig­kei­ten, es erfor­dert auch pas­sen­de Kommunikationsprozesse.
  5. Wich­ti­ge Res­sour­cen wer­den für höher-prio­ri­sier­te Pro­jek­ten abgezogen
    Ohne die geplan­ten Res­sour­cen wird es unwahr­schein­lich, das Pro­jekt in der geplan­ten Zeit zu bewäl­ti­gen, vor allem wenn der ursprüng­li­che Plan schon sehr opti­mis­tisch war.
  6. Kein Busi­ness-Case für das Projekt
    Pro­jek­te mit einen guten Busi­ness-Case bekom­men in der Regel die nöti­ge Auf­merk­sam­keit des Top-Manage­ment und die benö­tig­ten Ressourcen.

Weitere Artikel zum Thema

PS. Das Bild habe ich bei Geek & Poke gefunden.



Share This Post

Ein Kommentar

Marcus Raitner 10. September 2010 Antworten

Ein sehr inter­es­san­tes Zwi­schen­er­geb­nis der Stu­die von Dr. Eber­hard Huber im pro­jekt (B)log bestä­tigt jeden­falls schon mal den Bereich Pro­zess als wich­ti­gen Erfolgs­fak­tor. Nach­zu­le­sen hier: http://www.pentaeder.de/projekte/2010/09/10/30-erfolgreiche-projekte-standardisiertes-pm-lohnt-sich/

Schreibe einen Kommentar