Woran scheitern IT-Projekte?

Teil 1

Hier lesen Sie den zweiten und dritten Teil dieses Artikels.

Das jedenfalls suggerieren Recrutingbroschüren und Personalanzeigen gerne. Wie nahe die Werbung dabei der Wirklichkeit in IT-Projekten kommt, ahnt der Freiberufler oft nicht. Der Kampf um Erfolg oder Misserfolg gehört tatsächlich zum Alltag der meisten IT-Projekte. Je nach Land und Lage liegen die Scheiterquoten bei 50-80%.

Diese Zahlen stammen vor allem aus Studien des angelsächsischen Sprachraums, wo Projektarbeit am weitesten verbreitet ist und Projektmanagementsysteme die längste Tradition haben. In den USA scheiterten nach Untersuchungen der Standish Group 72% der IT-Projekte im Jahr 2000, mit abnehmender Tendenz bei Großunternehmen. In Großbritannien waren es laut der OASIG-Studie etwa 80% im Zeitraum 1994-1995. Von einem Anstieg in Richtung 90% geht Silicon für 2000 und 2001 aus.

Im deutschsprachigen Raum fehlen durchweg die harten Zahlen. Cap Gemini hat in 2001 zusammen mit der Universität Trier deutsche eBusiness-Projekte untersucht, wobei zwei Drittel der Unternehmen mit einem durchschnittlichen Umsatz von € 1,02 Mrd. angaben, dass die Projekte weder zur Senkung der Kosten noch zur Steigerung des Unternehmenserfolges beitragen würden. Für Österreich greift eine Veröffentlichung der TU Graz auf englische Studien zurück. Das Schweizerische Bundesamt für Berufsbildung und Technologie hat eidgenössische IT-Projekte im Jahr 2000 analysiert und stellt eine Scheiterquote von über 50% fest.

Dabei haben die hohen Scheiterquoten durchaus noch Steigerungspotential. Das lassen die immer kürzeren Lebenszyklen von Software vermuten. Waren Zyklen von 3-4 Jahren bis in die 90er Jahre die Regel, sind es heute eher Zyklen von 2 Jahren. Nach dem bekannten 'grüne Bananen'-Marketingprinzip kommt Software unausgereift auf den Markt und wird unausgereift wieder vom Markt genommen. So wurde das Betriebssystem Windows 2000, das als Servicepack 2 nach Ansicht gewerblicher Nutzer noch nicht in einer ausgereiften Version vorlag, bereits nach 2 Jahren von Windows XP abgelöst. Auch die Pleitewelle in der New Economy und das globale Fusionsfieber, welche die Unternehmen zum Teil kurzlebiger machen als ihre Produkte, lassen für IT-Projekte noch mehr Flops erwarten. All das hat zur Folge, dass kaum mehr ausgetestete Tools und Betriebssysteme für die Entwicklung stabiler Anwendungen zur Verfügung stehen. Khafre Systems International registriert schon für 2001 für die USA, dass das Arbeiten mit unausgereiften Betriebssystemen, Technologien und Tools den Erfolg vieler Projekte verhindert.

IT-Projekte definieren sich durch Leistung, Zeit und Geld. In der Leistungsbeschreibung oder Spezifikation wird ein Ergebnis vordefiniert, das in einem bestimmten Zeit- und Finanzrahmen erreicht werden soll. Am Projektanfang stehen die Freigabe von Geldern, die Zuordnung von Ressourcen und der Kick-off. Für die Durchführung werden Ressourcen wie Arbeit, Soft-Skills, Fach-Know-how, IT-Know-how, Hardware, Software und Immobilien benötigt. Der IT-Freiberufler zählt zur Ressource Arbeit ebenso wie der Projektmanager und die Kollegen. Die zu erbringenden Leistungen haben projektinterne und -externe Schnittstellen und sind mit Hilfe von Meilensteinen abnahmefähig. Am Projektende erfolgt die Abnahme aller Meilensteine, die Schlussabrechnung und die Ressourcenfreigabe.

Weist ein IT-Projekt diesen Satz von Hauptaspekten auf, handelt es sich um ein vollständiges Projekt. Ein Projekt kann in Teilprojekte unterteilt sein, die dann wiederum mit eigenen vollständigen Sätzen von Hauptaspekten beschreibbar sind.

Die nachfolgenden Faktoren bilden das Minenfeld, auf dem IT-Projekte hochgehen und dabei IT-Freiberufler aus den auftraggebenden Unternehmen hinaus katapultieren.

Mangelnde Soft-Skills

John Gage von Sun Microsystems sieht die Bedeutung zwischenmenschlicher Probleme: "Technology is easy - people are hard." Ähnlich urteilen schweizerische Unternehmensberatungen: "Dem Faktor Mensch (was im Menschen ist) und dem Faktor Unternehmenskultur (was zwischen den Menschen abläuft), wird in IT-Projekten oft zuwenig Bedeutung geschenkt. Der Grund dafür ist vielfach mangelndes Wissen sowie mangelnde Methoden und Instrumente. Wer hat schon in seiner Informatikausbildung gelernt, wie man mit Konflikten umgeht? Wie man ein gutes Klima im Team schafft? Wie man mit schwierigen Persönlichkeiten umgeht? Wie man Verbindlichkeit erreicht? Wie man Gärtchendenken überwindet? Wie man auch in hektischen und turbulenten Zeiten effizient kommuniziert?".

Fehlt im Team die Bereitschaft zu teilen - sowohl die Arbeit als auch das projektbezogene Know-how -, dann werden Arbeiten entweder doppelt oder mehrfach ausgeführt oder notwendige Arbeiten bleiben unerledigt. Fällt Schlüsselpersonal aus, muss der einspringende Mitarbeiter häufig ohne die dann dringend nötigen Arbeitsunterlagen von vorne anfangen. Werden Teammitglieder vom Auftraggeber oder Projektleiter allzu bürokratisch gegängelt und zu Dokumentationen und Nachweisen bis ins letzte Detail verpflichtet, ertrinken sie schnell in einer Flut von Papier. Zudem wird ihre Effizienz und Kreativität regelmäßig blockiert, indem auf ihre persönlichen Erfolgsformeln nicht eingegangen wird.

Zwar lösen sich viele Probleme von selbst, auch im Projekt. Doch gibt es IT-Probleme, die sich nicht lösen lassen, indem man beharrlich nichts tut. Und wer möchte bei Schieflagen schon der Überbringer der schlechten Nachrichten sein. Bekanntlich neigen Projektleiter ja zum Wegschauen, wenn eine Katastrophe sich anbahnt. Auch Unternehmensführungen können so handeln. Karen Boucher, Vice President der Standish Group, berichtet von einem Unternehmen, das sich nach vier fehlgeschlagenen Versuchen, ein Projekt zu realisieren, vor dem fünften geplanten Start endlich zu einer Scheiteranalyse durchrang.

Starrheit und Dogmatik sind für Walter Seemayer, Director .Net Strategy & Developer Group der Microsoft GmbH, durchgängig relevante Scheiterfaktoren. Sie können sich beim starren Festhalten der Unternehmensleitung an einmal festgelegten IT-Strategien ebenso zeigen wie beim dogmatischen Einsatz von Programmiersprachen und Tools durch den Entwickler.

So hindert das dogmatische Verfolgen einmal festgelegter Strategien viele IT-Leiter und Personalchefs daran, IT-Talent einzusetzen, das nicht in diese Strategien passt. Weil überall 'jung und dynamisch' angesagt ist, gibt es in weniger als 50% der deutschen Unternehmen noch Mitarbeiter über 50 Jahren. Dieser Dogmatismus wirkt sich auf IT-Projekte durchaus negativ aus. Denn Knappheit an verfügbaren jungen Talenten und Nichteinsatz erfahrener Know-how-Träger führen zur quantitativen Unterausstattung mit Personal und qualitativen Unterausstattung mit Know-how und Erfahrung.

Bei der Definition der Projektziele und bei der Leistungsbeschreibung führt Dogmatismus zu sachfremden Soll-Vorgaben. Überzogene Anforderungen erhöhen hier das Scheiterrisiko und führen auf jeden Fall zu einem vervielfachten Gesamtaufwand und stark erhöhten Endpreis, wogegen bei geringen Abstrichen ein akzeptabler Preis zu erreichen wäre.

Basiert die IT-Architektur im Unternehmen auf Insellösungen und auf individueller Software ohne klar definierte Schnittstellen, erschwert das die Verständigung zwischen den Mitarbeitern. Und ständige personelle Umbesetzungen im IT-Bereich erschüttern jede, selbst eine durchgängige, IT-Architektur bis in die Grundfesten. Nach einer Untersuchung der META Group hat ein IT-Vorstand (CIO) nur eine Lebensdauer von durchschnittlich 18 Monaten im Unternehmen. Das hat auch auf die IT-Architektur des Einzelprojektes und auf den Einsatz des IT-Freiberuflers im Projekt Auswirkungen.

Im Projekt bedingt die Abwesenheit einer durchgängigen IT-Architektur und einer durchgängigen Schlüssigkeit ebenfalls den Misserfolg. Das hat Khafre Systems International bei einer Scheiteranalyse amerikanischer IT-Projekte ermittelt. Aus dem Einsatz unausgereifter Technologien im Projekt resultiere eine 'zerbrechliche Architektur' und daraus spätestens in der Produktionsphase der Absturz des Systems.

Ist im Projekt eine durchgängige IT-Architektur mit in sich schlüssiger Nomenklatur vorhanden, ohne übergreifend angewendet zu werden, liegt ebenfalls ein Scheitern nahe. Fehlt es der Entwicklungsphase an Schlüssigkeit, dann fehlt es der Anwendung an Robustheit und Fehlertoleranz. Spätestens in der Produktionsphase (Gewährleistung) wird es wegen positiver Rückkoppelung bei den Fehlern zu einem Scheitern kommen. So steht auf dem Wunschzettel von Mothercare (UK) für das Christkind 2001 "A robust inventory system". Denn das Materialwirtschaftssystem ließ angelieferte Waren sich im Zentrallager stapeln, statt deren Auslieferung an die 424 Verkaufsniederlassungen für das Weihnachtsgeschäft 2001 zu veranlassen. Marketingfachmann Steven Buckley führt das Desaster auf fehlerhafte Mengengerüste und unzureichende Schulung zurück.