Leseprobe
Inhaltsverzeichnis
Abbildungsverzeichnis
I. Ausgangssituation
II. Grundlegende Begrifflichkeiten
A. IT- Projekt
B. Projektmanagement
C. Risikomanagement
D. Vom magischen Dreieck zum erweiterten magischen Fünfeck
III. Schwachstellen von IT- Projekten und ihre Abmilderung
A. Projektinhalt
B. Qualität und Effektivität
C. Projektlaufzeit und Projektaufwand
D. Methoden und Tools
E. Kosten
F. Beteiligte
a. Beteiligte: Lenkungsausschuss und Projektleiter
b. Beteiligte: Projektteam, Benutzermanagement und Endbenutzer
IV. Schlussbetrachtung
Literaturverzeichnis
Selbständigkeitserklärung
Abbildungsverzeichnis
Abb. 1: Erweitertes magisches Fünfeck
Abb. 2: Standish Group Untersuchung
I. Ausgangssituation
“Der Kampf um Erfolg und Misserfolg gehört tatsächlich zum Alltag der meisten IT- Projekte. Je nach Land und Lage liegen die Scheiterquoten bei 50 bis 80 Prozent”. Dies prognostizieren die Autoren Dr. Elisabeth Schwarz-Mehrens und Frits Fliers in ihrem Artikel unter http://www.gulp.de, dem Portal für IT- Projekte.
Die oben genannten Zahlen stammen vor allem aus Studien des angelsächsischen Sprachraums, wo Projektarbeit am weitesten verbreitet ist und Projektmanagement- systeme die längste Tradition haben. Hierbei beziehen sich die Autoren auf bekannte Consultingunternehmen. Nach Untersuchungen der Standish Group scheiterten in den USA 72 Prozent der IT- Projekte im Jahr 2000, mit abnehmender Tendenz bei Großunternehmen.
“Im deutschsprachigen Raum fehlen durchweg die harten Zahlen”, fahren die Autoren fort. So werden bei einer Untersuchung von Cap Gemini mit der Universität Trier zwar keine konkreten Scheiterquoten preisgegeben, jedoch gaben zwei Drittel der Unternehmen mit einem durchschnittlichen Umsatz von € 1,02 Mrd., bei denen eBusiness- Projekte untersucht wurden, an, dass die Projekte weder zur Senkung der Kosten noch zur Steigerung des Unternehmenserfolges beitragen würden.1 Aber gerade im Bereich eBusiness ist die Ernüchterung noch radikaler. So erreichten nach einer Studie im August 2000 von Mummert & Partner 75 Prozent der Projekte nicht das geplante Ziel.2
Dabei haben die hohen Scheiterquoten nach Ansicht der Autoren durchaus noch Steigerungspotential. Als Beispiel werden die immer kürzeren Lebenszyklen von Software genannt. Waren Zyklen von 3 bis 4 Jahren bis in die 90er Jahre die Regel, sind es heute eher Zyklen von 2 Jahren. Beispielsweise 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.
Diese Kurzlebigkeit, die Unternehmen teilweise schon vor ihren Produkten ‘aussterben’ lässt, ist ein gravierendes Merkmal der New Economy und lässt zwangsläufig für IT- Projekte viele Flops erwarten.1
Die nachfolgende Arbeit soll die Ursachen für das Scheitern von IT- Projekten aufzeigen und typische Schwachstellen anhand des erweiterten magischen Fünfecks untersuchen. Nach dieser Schilderung der Ausgangssituation werden im zweiten Kapitel die grundlegenden Begriffe geklärt. Darauf aufbauend werden im dritten Kapitel typische Risiken von IT- Projekten veranschaulicht. Es wird beschrieben, wie sie erkannt und nach ihrem Eintreten abgemildert werden können. Abschließend erfolgt die Schlussbetrachtung der Verfasserin.
II. Grundlegende Begrifflichkeiten
A. IT- Projekt
IT- Projekte definieren sich durch Leistung, Zeit und Geld. Sie sind gekennzeichnet durch ihre Einmaligkeit und damit verbundener Innovation. In der Leistungsbeschreibung oder Spezifikation wird ein Ergebnis vordefiniert, das in einem bestimmten Zeitrahmen und mit begrenzten finanziellen und personellen Ressourcen durchgeführt werden soll.2 Daraus ergibt sich nahezu zwangsläufig, dass Risiken (Probleme) zu einem Projekt dazu gehören3. Projekte sind das Mittel, um technischen und organisatorischen Wandel zu realisieren.4
Die Erfüllung des Projekts wird meist durch die Gründung einer projektspezifischen Organisation erreicht.5 Ziel eines jeden Projekts ist es, die vom Auftraggeber gewünschten Resultate (Zielvorgaben) mit den vorgesehenen Ressourcen innerhalb der vorgegebenen Zeit in der geforderten Qualität zu erreichen. Wurde dies realisiert spricht man von Projekterfolg.6
B. Projektmanagement
Das Projektmanagement ist ein “umfassendes Führungskonzept”1, welches für die erfolgreiche Bewältigung von Projekten eingesetzt werden soll. Es dient zur Planung, Überwachung und Steuerung des Projektverlaufs und ist zentrale Stelle des Projekts.2
Unter der Projektplanung versteht man die Planung der Aktivitäten, der Termine, der Ressourcen und der Kosten des Projekts. Die Projektsteuerung umfasst die permanente Projektkontrolle und die Festlegung und Durchführung der Maßnahmen, die bei einer Abweichung zwischen den Soll- und Ist- Ergebnissen zu ergreifen sind. Bei der Projektabschlusskontrolle wird der gesamte Projektverlauf bewertet, um für zukünftige Projekte Erfahrungen zu sammeln.3
Das Projektmanagement hat auch die Aufgabe eine Risikoabschätzung zu erstellen, die offene und neue Risiken für den Projekterfolg analysiert.4
C. Risikomanagement
In der Ausgangssituation wurde exemplarisch dargestellt, welche Scheiterquoten bei IT- Projekten erreicht wurden und mit welchen Scheiterquoten weiterhin zu rechnen ist. Ebenso wie ein Projekt von bestimmten Faktoren positiv beeinflusst werden kann, gibt es auch Faktoren, die den Projekterfolg verhindern bzw. gefährden können.
Komplexe Projekte enthalten eine Vielzahl unbekannter Risiken, die den Projekt- erfolg in irgendeiner Form gefährden können.5 Gemäß Lehner wird unter Projektrisiko die Höhe des Schadens verstanden, den ein Unternehmen erleidet, wenn die Projektziele nicht erreicht werden.6 Demnach stellt ein Risiko ein potenzielles Problem und Risikomanagement ein kontinuierlicher und dynamischer Prozess dar.7 Je weiter ein Projekt fortgeschritten ist, desto wahrscheinlicher wird der Eintritt von Risiken. In Untersuchungen wurde festgestellt, dass die Ursachen für die meisten Risiken in der Startphase der Projekte zu finden sind1 und deshalb hier die besondere Aufmerksamkeit des Projektleiters erforderlich ist.
Proaktives Risikomanagement bedeutet, dass man über einen festgelegten Risiko- managementprozess verfügt, der wiederholt und auf die Ursachen der Risiken angewendet werden kann.2 Dieser Prozess, die sog. Risikoanalyse, umfasst Entschei- dungen und Maßnahmen, die kontinuierlich bewerten, welche Risiken, in welcher Wahrscheinlichkeit eintreffen. Sie ermittelt, bei welchen Risiken Maßnahmen erforderlich sind und legt fest, welche Strategien zur Begrenzung dieser Risiken eingesetzt werden sollten.3
Deshalb ist eine Risikoanalyse nicht nur beim Start eines Projektes sinnvoll, sondern auch zur Risikoüberprüfung während des gesamten Projektzyklus,4 d.h. die Projektrisiken werden einer Neubewertung unterzogen.
Bei der Risikoanalyse werden zunächst die möglichen Risiken identifiziert, die auf ein Projekt einwirken können. Der zweite Schritt ist die Beschreibung der Ursachen, die zu den jeweiligen Risiken führen. Nach der Bewertung der Eintrittswahrscheinlichkeit einer bestimmten Risikosituation erfolgt die Risikoplanung. Zu dieser Planung gehören die Erarbeitung von Maßnahmen zur Abmilderung oder Verhinderung einzelner Risiken, die Priorisierung dieser Maßnahmen und die Erstellung eines Risikomanagementplans.5
Diese ermittelten Risiken stellen die Schwachstellen und Scheiterfaktoren von IT- Projekten dar und müssen kritisch untersucht werden, damit der Projekterfolg gesichert werden kann. Nachfolgend sollen typische Schwachstellen von IT- Projekten aufgezeigt werden, die den Projekterfolg gefährden. Um diese Schwachstellen, die ein potenzielles Risiko darstellen, abzumildern oder sogar zu verhindern, werden sog. Erfolgsfaktoren eingesetzt.
Jenny versteht unter Erfolgsfaktoren in einem Projekt, “die Voraussetzungen, die wesentlich zur Erreichung der wünschbaren Zustände gemäß Erfolgsermittlungskriterien beitragen. ”6
D. Vom magischen Dreieck zum erweiterten magischen Fünfeck
Bei der Definition von IT- Projekten wurde erkannt, dass sie durch Leistung, Zeit und Geld bestimmt werden. Diese drei Einflussfaktoren lassen sich mit den Knoten des magischen Dreiecks gleichsetzen. Die Kanten des magischen Dreiecks verdeutlichen die gegenseitige Beeinflussung.1 D.h. wenn an einem Knoten etwas verändert wird hat das Auswirkungen auf alle anderen Knoten. Nehmen wir beispielsweise an, dass die Projektlaufzeit verkürzt wird. Wenn kein Qualitätsverlust auftreten soll hat diese Aktion zur Folge, dass der Mitarbeitereinsatz steigt. Eine erhöhte Mitarbeiterzahl führt nun zwangsläufig zu höheren Projektkosten.
Wird das magische Dreieck um die Knoten Methoden/ Tools und Mitarbeiter erweitert, erhält man das magischen Fünfeck. Das erweiterte magische Fünfeck verdeutlicht die Spezialisierung der Beteiligten in Projektleitung, Projektteammitarbeiter, Benutzermanagement und Endbenutzer:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3 Erweitertes magisches F ü nfeck
(in Anlehnung an Etzel, H.-J./ Heilmann, H./ Richter, A. (2000), S.20)
Diese Spezialisierung ist sinnvoll, da so bei der Analyse der Schwachstellen des Projekts alle Projektbeteiligten gesondert betrachtet werden können.
III. Schwachstellen von IT- Projekten und ihre Abmilderung
Die typischen Schwachstellen von IT- Projekten sollen nun in diesem Kapitel, anhand der Knoten, Verbindungen sowie Lenkungsausschuss und Projektinhalt des erweiterten magischen Fünfecks, dargestellt werden. Es soll evaluiert werden, welche Faktoren am meisten beachtet werden müssen und wie man ihnen vorab oder auch nach Risikoeintritt begegnen kann um Krisen oder sogar den Projektabbruch zu verhindern.1
A. Projektinhalt
“Eine exakte Zieldefinition ist einer der wichtigsten Schritte innerhalb der Projekt- initiierung”, dies macht ein Artikel deutlich, der im Dezember 2001 im Projektmagazin erschienen ist. Demnach muss nach Projektabschluss bitter gebüßt werden, was an Vorarbeit versäumt wurde. Nur durch ein eindeutig definiertes Projektziel ist eine realistische Planung möglich. Dabei ist es wichtig, dass die Projektziele mit den zur Verfügung stehenden Mitteln erreichbar und in Einklang mit der IT- Strategie des Unternehmens sind.2 Um eine unrealistische Einschätzung in punkto Zeit, Aufwand und Realisierbarkeit zu vermeiden, was nach Jenny3 nicht selten zu einem Planungsrisiko führt, sollte vorab eine Machbarkeitsanalyse durchgeführt werden. Diese soll verhindern, dass die Projektkomplexität unterschätzt wird.4 Aber nicht nur in Bezug auf die Komplexität sondern auch zur Lösungsfindung kann eine Machbarkeitsanalyse beitragen. Gerade bei der Erstellung eines neuen Systementwurfs für ein neues IT- System gibt es häufig eine Vielzahl von Möglichkeiten, die kritisch auf die Schlüsselfaktoren Qualität, Kosten und Zeit untersucht werden müssen.5
Diese Investition an Vorarbeit zahlt sich absolut aus, wenn man die Kosten betrachtet, die bei einem gescheiterten Projekt wegen Nichterfüllung anfallen. Aber nicht nur die Vorarbeit sondern auch die Überprüfung von Teilzielen (Meilensteinen) ist ein wichtiger Teil zur Erreichung des Projektziels.
In der Risikoanalyse ist auch zu berücksichtigen, in welchem Umfang sich der Inhalt des Projekts nicht nur während der späteren Nutzungszeit, sondern bereits in der Projektlaufzeit verändern kann. Diese Änderung kann durch die Überprüfung von Teilzielen (Meilensteinen) festgestellt werden. Dieser Punkt ist wichtig, da es immer wieder vorkommt, dass der Auftraggeber zum Beispiel nach der ersten Testinstallation mit der Software doch nicht zufrieden ist, obwohl vorher alles eindeutig besprochen wurde und eine Abnahme vom Auftraggeber erfolgte.1 Leider ist dies keine Ausnahmesituation, denn gerade der IT- Bereich ist durch einen rasanten Technologie- und Paradigmenwechsel geprägt. Heidi Heilmann bezieht sich diesbezüglich auf Jones. Er hat beobachtet, dass sich in 90 Prozent aller IT- Projekte Anforderungen während der Projektlaufzeit verändern. Er sieht in diesen “creeping user requirements ” das häufigste Problem der Softwareentwicklung.2 Damit diese inhaltlichen Veränderungen den Projekterfolg nicht gefährden, ist es unverzichtbar, diese Abweichungen und ihre möglichen Auswirkungen zu bewerten, auch wenn dies den Projektfortschritt verzögert.3
Ein weiterer entscheidender Aspekt, der vom Projektinhalt bestimmt wird, ist die Projektgröße. Je größer die Arbeitspakete, desto schwieriger wird es, klare abnahmefähige Meilensteine zu definieren. Dies ist der Fall in Großprojekten. So konnten der Standish Group zufolge US- Großunternehmen ihre Erfolgsquote bei ITProjekten von 9 Prozent in 1994 auf 23,6 Prozent in 1998 dadurch steigern, dass sie wenige Großprojekte durch viele Kleinprojekte ablösten.4
Aber nicht nur die Projektgröße, sondern auch die Koordination und das Management von mehreren nebeneinander her laufenden Projekten, dem sog. Multi- Projektmanage- ment, kann das Unternehmen bei der Durchführung überfordern.5
[...]
1 vgl. Schwarz-Mehrens, E./ Fliers, F. (2001), [Teil 1], S.1
2 vgl. Ronzheimer, M. (2002), S.1
1 vgl. Schwarz-Mehrens, E./ Fliers, F. (2001), [Teil 1], S.1
2 vgl. ebd., S.2
3 vgl. Etzel, H.-J./ Heilmann, H./ Richter, R. (2000), S.3
4 Schelle, H. (1999), S.13
5 vgl. DIN Begriffsnorm 69901 ziteirt nach: Schelle, H. (1999), S.11
6 vgl. Jenny, B. (1998), S.520
1 vgl. Schelle, H. (1999), S.11
2 vgl. Projekthandbuch (2002), [Projektmanagement], S.1
3 vgl. Heilmann, H. (2001), S.28; Heilmann, H. (2001), S.40
4 vgl. Projekthandbuch (2002), [Projektmanagement], S.1
5 vgl. Jenny. B. (1998), S.88
6 vgl. ebd., S.521 zitiert nach: Lehner (1991)
7 vgl. Modulo3 GmbH (2001), S.1
1 vgl. Neumann, R./Bredemeier, K. (1996), S. 125/126
2 vgl. Modulo3 GmbH (2001), S.1
3 vgl. ebd., S.1
4 vgl. Jenny, B. (1998), S.505
5 vgl. ebd., S.506
6 Jenny, B. (1998), S. 85
1 vgl. Etzel, H.-J./ Heilmann, H./ Richter, R. (2000), S.19
1 vgl. Zahrnt, C. (2002), S.5
2 vgl. Wolf, R. (2001), S.1
3 vgl. Jenny, B. (1998), S.91
4 vgl. Etzel, H.-J./ Heilmann, H./ Richter, R. (2000), S.32
5 vgl. Hense, A. (2002)
1 vgl. Wolf, R. (2001), S.2
2 vgl. Etzel, H.-J./ Heilmann, H./ Richter, R. (2000), S.21
3 vgl. Etzel, H.-J./ Heilmann, H./ Richter, R. (2000), S.174
4 vgl. Schwarz-Mehrens, E./ Fliers, F. (2001), [Teil 2], S.3
5 vgl. ebd., [Teil 3], S.4