a Randstad company
Login

Woran scheitern IT-Projekte Teil 3

Teil 3 - Planungsmängel und Abstimmungsprobleme

18.12.2001
Dr. Elisabeth Schwarz-Mehrens und Frits Fliers
Artikel teilen:

Der dritte und letzte Teil dieser Serie beschäftigt sich hauptsächlich mit den Ursachen und Folgen mangelnder Ressourcen und unzureichender Planung. Für ungeduldige Schnellleser werden abschließend die wichtigsten Scheiterfaktoren nach Auftraggebern und Auftragnehmern sortiert und schlagwortartig zusammengefasst.

Den ersten Teil dieses Artikels, der sich mit den grundsätzlichen Scheiterfaktoren beschäftigt, lesen Sie hier. Im zweiten Teil geht es vornehmlich um die Fußangeln in der täglichen Projektarbeit.

Probleme bei den Ressourcen

Eine Ressourcenplanung kann nie besser sein als die Leistungsspezifikation, und die ist erfahrungsgemäß meist schlecht. Weil sie den Zeitrahmen oder das Budget überschritten oder minderwertige Ergebnisse oder alles zusammen aufwiesen, scheiterten der Standish Group (Chaos '98-Studie) zufolge 72% der amerikanischen IT-Projekte. 49% schlugen in mindestens einer der drei Kategorien fehl. Die restlichen 23% wurden storniert. Lediglich 28% waren erfolgreich in Bezug auf Leistung, Geld und Zeit.

Zeit

Kann der Zeitrahmen nicht eingehalten werden, wird spätestens ab 2 Jahren Laufzeit jedes IT-Projekt von der Technologieentwicklung überrollt. So jedenfalls sieht es der Bundesrechnungshof , der in seinen jährlichen Berichten und Bemerkungen für viele öffentliche IT-Projekte in Deutschland festgestellt hat, dass sie desto eher scheitern, je länger sie dauern.

Rückwärtsterminierung, die Managern und Politikern im Blut zu liegen scheint, erhöht die Scheiterwahrscheinlichkeit. Bei Projekten, die zu spät anfangen, können Termine meist nicht eingehalten werden. Für die dann dringend erforderliche 'Flexibilität' muss extra Geld und extra Personal bereitgestellt werden, was leider nicht immer machbar ist.

Ist kein Ende in Sicht, scheint die 'Quick-and-dirty'-Methode geeignet, doch noch ans Ende zu kommen. Wird unter Zeitdruck zu schnell entwickelt und fallen Testphasen (Pilotprojekte, Prototypen, Anwendertests) unter den Tisch, bringt das den Entwickler aber oft um seine Nerven und manchmal das Projekt um seinen Erfolg. Wer 'Quick-and-dirty' in einer Produktionsumgebung einsetzt, die Zuverlässigkeit und Dauerbetrieb fordert, kann sein Scheitern selbst vorhersehen.

Geld

Durchweg scheint bei Technologie-Investitionen in Unternehmen "Adam Riese" der große Unbekannte zu sein. Die Chaos '98-Studie der Standish Group ergab, dass in den USA IT-Großprojekte mit einem Budget von über $10 Mio. zu 100 Prozent scheitern. In Großbritannien konnten Anfang 2000 bei einer Befragung durch das Chartered Institute of Management Accountants vor allem kleine und mittlere Unternehmen ihre Technologie-Investitionen kostenseitig nicht rechtfertigen. 70% der Verantwortlichen gaben an, dass ihre IT-Ausgaben in diesem Jahr überdurchschnittlich hoch seien. Das kommentiert Tony Dart, Direktor beim CIMA: "Eine Investition muss sich amortisieren. Dies scheint bei anderen Investitionen anerkannt zu werden, aber nicht bei IT."

Unterkapitalisierung ist in deutschen Unternehmen ein häufiges Problem. Eine unrealistische Planung, welche und wie viele Ressourcen im Laufe des Projektes notwendig sind, somit was das Ganze kosten wird, führt wegen fehlender zusätzlicher Geldmittel regelmäßig zu einem Scheitern. Der IT-Freiberufler muss dann zusehen, wie er wenigstens für seine geleistete Arbeit das Geld erhält.

Leistung

Leistung ist in der Definition von Khafre Systems International das, was vertraglich zugesagt ist. Arbeit ist der Weg dahin.

Kaum jemand kann sich mit dem Gedanken anfreunden, dass die Zündungsanlage in seinem Auto von jemandem programmiert wurde, der von Automotoren nichts versteht. Doch leider ist Ähnliches bei Software-Entwicklungen immer wieder der Fall. Informatiker und Programmierer sind oft reine Fachspezialisten, die von den Geschäftsgegenständen und -prozessen der Unternehmen, für die sie arbeiten, kaum Ahnung haben.

Regelmäßig mangelt es dem IT-Spezialisten an Kundenorientierung, weil er zu sehr "verliebt in die eigenen Entwicklungen" ist (Schweizerisches Bundesamt für Berufsbildung und Technologie). Und häufig ist er so ausschließlich auf bestimmte Betriebssysteme, Programmiersprachen, Hardware spezialisiert, dass ein Windows-Server, ein Linux-System, eine AS400 oder ein IBM-Mainframe böhmische Dörfer für ihn sind. Er kann dann selbst kaum beurteilen, welche Programmiersprachen und sonstigen IT-Tools auf das vorliegende fachliche Problem anzuwenden sind, um die Nutzbarkeit des Software-Entwicklungsergebnisses optimal zu gestalten.

Oder es fehlt auf der Auftraggeber- und Anwenderseite das IT-Know-how. Dadurch fehlen die Beurteilungskriterien für die IT-seitige Lösung des fachlichen Problems ebenso wie die Kompetenz bei deren Anwendung. Ein Microsoft-Star-Programmierer äußerte sich hierzu im Microsoft Systems Journal: "Stell Dir vor, Du bist über dem Atlantik, der Autopilot fliegt unter Windows 3.1 und hat eine allgemeine Schutzverletzung..." Hinzu kommen Verständigungsschwierigkeiten bei der Erbringung, Anwendung oder gar Vermarktung der IT-Lösung. Denn Globalisierung ist in den Unternehmen nicht immer von wirklicher Internationalisierung begleitet. Fehlende Internationalisierung wird aber bei international besetzten Projekten zum Problem. Fehlende Mehrsprachigkeit und fehlendes Verständnis für andere Lebens- und Arbeitskulturen blockieren sowohl die Teambildung als auch die Leistungserbringung.

itprojekt3
Die grössten Probleme beim Betrieb einer eCommerce-Webside Quelle: www.idc.de

Keine Akzeptanz & Integration im Unternehmen

Schnittstellen

Bei jedem IT-Projekt gibt es im Unternehmen Schlüsselpersonen, die über dessen Stellenwert und Förderung mitentscheiden oder solche, die selbst vom Projekt betroffen sind. Schlüsselpersonen, die dem Projekt ablehnend gegenüberstehen, können überflüssige Reibungen erzeugen oder blockieren. Es gibt Systemverwalter, die den IT-Freiberufler nur ungern auf Programmbibliotheken, Handbücher und andere Dokumentationen zugreifen lassen.

Kommt es auf Druck von außen nicht mehr zum Small Talk unter Kollegen, schläft die Verständigung über Ziele und Leistungen projektintern wie -extern ein. Oft verstehen die Mitarbeiter in der Buchhaltung oder im Vertrieb gar nicht, weshalb und wofür die Kollegen im IT-Bereich so viel Geld ausgeben. Ebenso wenig weiß die IT-Abteilung, welchen Nutzen (Umsatz, Gewinn) und welche Kosten ihr Bereich oder das aktuelle Projekt dem Unternehmen bringen. Die Notwendigkeit, wichtige IT-Projekte im Unternehmen nach dem Motto 'Tue Gutes und rede darüber' zu kommunizieren, wird oft nicht gesehen. Mancher Entscheidungsträger kommt dann leicht zu dem fatalen Schluss, das Projekt sei entbehrlich im Sinne der Unternehmensstrategie.

Strategische Abstimmung

Wichtig ist für den Auftraggeber die richtige Durchführung des IT-Projekts. Noch wichtiger ist es, das richtige Projekt durchzuführen. IT-Projekte werden auch deswegen auftraggeberseitig eingeschläfert, weil eingesehen wird, dass sie besser nie gestartet worden wären oder weil festgestellt wird, dass ihre Ziele nicht mit den Geschäftszielen des Unternehmens übereinstimmen.

Die IT-Leiter richten ihr Handeln oft nicht an den Geschäftszielen aus, die der Maßstab für alle Management-Maßnahmen im Unternehmen sein sollten. Hinzukommen die Schwierigkeiten der IT-Leiter wie auch der Personalchefs beim Umgang mit den Human Resources. Das Anziehen, Fortbilden und Behalten von fähigen IT-Mitarbeitern gilt als eines der größten Probleme im IT-Management.

Leider fehlt es den IT-Leitern sehr oft an Durchsetzungskraft im Unternehmen. Bob Weiler, CEO der Giga Information Group, meinte dazu beim Giga World IT Forum 2001 Europe, dass vier von zehn Vorstandsvorsitzenden ihren IT-Leitern gar nichts glaubten, egal was sie ihnen vortragen würden. In die gleiche Richtung ging die von Jean Phillippe Courtois, President of Microsoft EMEA, auf demselben Forum gemachte Aussage, dass IT-Leiter in den meisten europäischen Unternehmen keine strategisch wichtige Rolle inne hätten und weder Mitglied des Vorstands noch der Geschäftsführung seien. Das entspricht dem Ergebnis der in 2001 veröffentlichten Bourton Group-Studie , wonach in englischen Unternehmen unter 25 für das Geschäftsergebnis relevanten Faktoren die IT erst Platz 17 belegt. Für Deutschland sagt die Cap Gemini-Studie aus, dass mit zunehmender Größe in den Unternehmen die Unterstützung der IT-Abteilungen durch Geschäftsführung und Vorstand kontinuierlich abnimmt.

Multi-Projekte-Management

Ein IT-Projekt kann ebenfalls daran scheitern, dass das auftraggebende Unternehmen mit der Koordination und dem Management mehrerer nebeneinander her laufender Projekte überfordert ist. Das Software Engineering Institute behauptet, dass 85% aller Organisationen mit der gleichzeitigen Abwicklung von zwei oder mehr IT-Projekten überfordert seien. Mit einem einzigen Projekt werde ein Unternehmen meist noch fertig; mehrere Projekte oder komplexe Projekte mit Unter- oder Oberprojekten führten aber meist zur Katastrophe. Bei der Einschätzung, ein IT-Projekt erfolgreich durchziehen zu können, tendiere fast jede Organisation zur Überbewertung der eigenen Fähigkeiten.

Deutsche Großunternehmen mit über € 5 Mrd. Jahresumsatz bringen es der Cap Gemini-Studie zufolge im Schnitt auf über 50 gleichzeitige eBusiness-Projekte. Mehr als drei Viertel dieser Unternehmen rechnen dabei aber nicht mit kostensenkenden oder umsatz- bzw. gewinnsteigernden Resultaten.

Was sind die Folgen des Scheiterns?

Regelmäßig enden IT-Projekte vorzeitig am Ende eines Geschäfts- oder Budgetjahres, wodurch in der Regel auch die Zusammenarbeit mit dem IT-Freiberufler terminiert ist. Der Freiberufler kann dann zusehen, wie er zu seinem Geld und kurzfristig zu einem Anschlussauftrag kommt. Demotivierung oder Abwanderung sind verständliche Reaktionen. Für neue Aufträge durch denselben Auftraggeber steht er meist nicht mehr zur Verfügung.

Andererseits kann - je größer das Unternehmen mit desto größerer Wahrscheinlichkeit - das Scheitern auch nicht eingestanden werden und das Projekt aus Gründen weiterbetrieben werden, die eher auf Prestigeabsichten als auf ein Verfolgen von Unternehmensinteressen schließen lassen. Der IT-Freiberufler muss dann mit der Frage leben, ob er bereit ist, für den Papierkorb zu arbeiten.

Ist Erfolg das Gegenteil von Scheitern?

Die Kenntnisse von Projektpleiten und scheiterkritischen Faktoren sind gerade für den IT-Freiberufler extrem wichtig. Nur so kann er im aktuellen IT-Projekt die Lage beurteilen und für sich die richtigen Entscheidungen treffen. Er ist ja vom Scheitern direkt betroffen, kann aber selten direkten Einfluss nehmen.

Werden im IT-Projekt die Scheiterfaktoren vermieden oder durch ihr Gegenteil ersetzt, ist dies allerdings noch lange keine Erfolgsgarantie. Beim Versuch, alle festgestellten Negativfaktoren umzukehren, würde das Projekt an Papier und Bürokratie ersticken. Wohl führt in der Mathematik der realen Zahlen die Verneinung negativer Faktoren zu etwas Positivem: Minus mal Minus ist Plus. Hätte das auch in der Projektpraxis Geltung, dann müsste es heute mehr erfolgreiche Projekte geben als gescheiterte. Die sich seit Jahrzehnten türmenden Negativbeispiele und die noch immer vergleichsweise geringe Erfolgsquote bieten genügend Möglichkeiten für Rechenexempel.

Damit ein IT-Projekt erfolgreich und nicht im Sande verläuft, ist es nicht nur notwendig, die Erfolgsfaktoren zu kennen, sondern auch zu wissen, welche davon in welchem Umfang wie und mit welchen möglichen Auswirkungen zu realisieren sind. Und es ist an die oft genannte, doch selten genug eingesetzte Managementmethode zu erinnern, Systematik mit Intuition zu verbinden, um den Erfolg zu gestalten.

Damit scheitern Auftraggeber leicht ...

  • Starrheit und Dogmatik
  • Häufiges Wechseln des IT-Leiters
  • Fehlende oder von den Unternehmenszielen abweichende IT-Strategie
  • Fehlendes Multi-Projekte-Management
  • Keine Unterstützung des speziellen Projekts, Projektmanagers und -teams
  • Unzureichende Definition der Projektziele
  • Fehlendes Verständnis für die Lösungsangebote
  • Zusätzliche Wünsche und Vorgaben

Damit scheitern Projektmanager leicht ...

  • Starrheit und Dogmatik
  • Fehlende Management-Erfahrung
  • Kein oder unzueichender Kontakt mit Führungsebene und Anwendern
  • Kein oder unzureichender Kontakt mit den Mitarbeitern im Team
  • Kein oder unzureichendes Lastenheft
  • Zu wenige oder unklare Meilensteine
  • Keine unterstützenden Managementsysteme
  • Abweichen von den Projektvorgaben und der Ressourcenplanung

Damit scheitern IT-Spezialisten leicht ...

  • Starrheit und Dogmatik
  • Fehlende Soft-Skills
  • Fehlende Kenntnisse des Geschäftsgegenstands und der Organisation des Auftraggebers
  • Kaum Kenntnisse des Anwenderbedarfs
  • Fehlendes Verständnis für das Einfließen der Entwicklung ins Geschäft des Auftraggebers
  • Abweichen von den Projektvorgaben und der Ressourcenplanung
  • 'Learning-by-doing'-Strategie im Projekt
  • Entwicklung mit zu viel Code, zu wenig Kommentaren und zu wenig Tests

 

Teil 1 | Teil 2 des Artikels