Will man den Marktuntersuchungen der amerikanischen Standish Group glauben, so ist der Softwareprojekterfolg ein scheues Reh: 13,1 Prozent der Projekte gehen schief, weil die Anforderungen unvollständig erfaßt werden, 10,6 Prozent durch falsch geplante Ressourcen und 8,7 Prozent wegen nachträglicher Änderungen der Spezifikationen. Nach dieser Rechnung scheitern also 30 Prozent aller Softwareprojekte.

Wenn es hierzulande um Re-Engineering-Projekte geht, ist die Liste der Fehlerquellen und Unzulänglichkeiten in den Unternehmen ebenfalls lang. Zwar weisen die großen Standardpakete funktional kaum noch Lücken auf, doch kungeln IT-Abteilung und Berater nur allzuoft an den betroffenen Fachabteilungen vorbei; häufig werden auch die Konsequenzen von Ablaufveränderungen vernachlässigt; zu kurz kommt gleichfalls die Analyse, welches Know-how an welcher Stelle erforderlich ist etc.

So stellt die Projektlandschaft im Informatikbereich nur in Ausnahmefällen eine heile Welt dar. Wo Projektarbeit geleistet wird, fehlt selten die vielzitierte Karrikatur über die "sechs Vorgehensweisen", die in der Alltagspraxis tatsächlich immer wieder anzutreffen sind:

Phase 1: Begeisterung,

Phase 2: Verwirrung,

Phase 3: Ernüchterung,

Phase 4: Suche des Schuldigen,

Phase 5: Bestrafung des Unschuldigen,

Phase 6: Auszeichnung des Nichtbeteiligten.

Kurz: Projektarbeit vollzieht sich offenbar auf einem einzigen Minenfeld. Außerdem nimmt die Risikohöhe mit der Größe und Komplexität des geplanten Systems überproportional zu.

Da hilft nur Kommunikation, zum Beispiel: ein Besuch bei erfolgreichen anderen Firmen, wöchentliche Manöverkritik mit Fortschrittsfeststellung und "Ab und zu ein Glas Sekt - spaßeshalber." bi