Woran scheitern IT-Projekte

Teil 2 - Tücken im Projekt

Hier lesen Sie den ersten Teil dieses Artikels.

Das Erreichen definierter Projektziele erfordert Klarheit und Anschaulichkeit der Anforderungen. Fehlen konkrete Beispiele (vorhandene Lösungen, Muster), ist selbst bei gleicher Formulierung die Gefahr groß, dass Auftraggeber, Projektleiter und IT-Spezialist nicht das Gleiche denken und dementsprechend unterschiedliche Bewertungen vornehmen.

Mangelnde Visualisierung ist ebenfalls ein Königsweg zum Scheitern. Jeder Konstrukteur oder Architekt lernt, dass zur technischen Darstellung neben der Spezifikation mindestens drei Zeichnungen notwendig sind: Draufsicht, Vorderansicht und Seitenansicht. Bei einem Baukastensystem wiederholt sich die Forderung nach Zeichnungssätzen auf jeder Ebene. Änderungen in der Spezifikation ziehen zwingend Änderungen in den Zeichnungen nach sich. Der Softwarehersteller Rational Rose hat für die Entwicklung von IT-Lösungen und Softwareobjekten ermittelt, dass außer einer Spezifikation Diagramme in circa 8 Dimensionen notwendig sind. Aber selten erhält ein IT-Freiberufler vom Auftraggeber eine ausreichende mehrdimensionale Visualisierung der Angebotsaufforderung oder der Leistungsbeschreibung in Form von UML-Tools (Unified Modelling Language-Diagramme). Dieser Mangel an visueller Darstellung bedeutet meist auch einen Mangel an Präzision. Viele Denkfehler und Ungenauigkeiten würden beim Vorliegen einer visuellen Darstellung direkt ins Auge springen. Und dem IT-Freiberufler bliebe das undankbare Realisieren unausgegorener Vorhaben erspart.

Angebotskalkulation

Viele Auftraggeber sind weder bereit noch fähig, eine genaue Angebotsspezifikation etwa in Form eines abnahmefähigen Lastenheftes mit vollständigen Mengengerüsten vorzulegen. Muss der IT-Freiberufler ein verbindliches Angebot abgeben, ohne ein vollständiges Lastenheft erhalten zu haben, dann wollen aber nur die wenigsten potentiellen Auftraggeber für das zeit- und Know-how-intensive Erstellen dieses Angebots zahlen. Er wird im Gegenteil vom Auftraggeber oder von Dumping-Angeboten des Mitbewerbs oft so unter Druck gesetzt, dass er das eigene Angebot zu niedrig kalkuliert. Macht er aber am Anfang ein vergleichsweise hohes Angebot, ist er sofort aus dem Rennen.

Wird dem IT-Freiberufler eine Leistungsbeschreibung vorgelegt, zeichnet diese sich meist durch das Fehlen selbstdokumentierender Quelltexte und selbstdokumentierender Hilfen oder selbstdokumentierende Benutzerschnittstellen (Menüs) aus. Damit wird eine Anwendung schnell wartungsunfreundlich. In einem Wartungsprojekt muss der Freiberufler beim Fehlen von Quelltext oder Dokumentation - was in der PC-Welt durchaus häufig ist - erst einmal ein Reverse Engineering durchführen, damit er das Programm überhaupt warten kann. Hat er das Wartungsprojekt als Höchstpreis- oder Höchstaufwand-Projekt abgeschlossen, ohne Spielraum für das zeitaufwändige Reverse Engineering mit einzukalkulieren, kann ihn das teuer zu stehen kommen.

Soll der IT-Freiberufler ein Lösungskonzept ohne genaue Angebotsspezifikation und nur aufgrund des mündlichen Briefings durch den Auftraggeber erstellen, werden eine effiziente Spezifikation der Abnahme und der Tests ebenso fraglich wie eine solide Projektsteuerung und Qualitätssicherung. Ohne den Einsatz eines Requirement-Managementsystems (wie Spreadsheets, Rational Rose, Together Soft) während des gesamten Projektverlaufes riskiert er ein ständiges Nachtarocken des Auftraggebers, meist mit der Begründung, dass die neuen Forderungen ja in den Anfangsgesprächen mitenthalten gewesen seien.

Projektmanager wie IT-Freiberufler lassen sich bei der Projektdurchführung immer wieder auf Ad-hoc-Änderungen ohne zusätzliche Ressourcen (Zeit, Geld, Personal, Räumlichkeiten, Hardware, Software, Rechenkapazität, Dokumentation) ein, gegebenenfalls auch ohne Änderung des Angebots bzw. der Leistungsbeschreibung. Das macht die Lage im Projekt schnell unübersichtlich. Tad Haas, Vice President of Account Management bei Artemis sagt dazu, dass in vielen Organisationen ein Mitarbeiter gleichzeitig an neuen Projekten, in der Wartung und im Support arbeite. Es sei nicht unüblich, dass 50% der Arbeit von Programmierern fälschlich Neuprojekten zugeordnet werde.
Generell gehen in den Großprojekten Übersicht und Steuerungsmöglichkeiten bald da verloren, wo Managementsysteme wie MS Project (Low-end-Produkt) oder Artemis (High-end-Produkt) fehlen oder die Projektverantwortlichen nur ungenügend darin geschult sind. Kleine Projekte mit Ad-hoc-Abwicklung und Real-time-Experimenten geraten ohne die Verwendung von Aktionslisten oder Spreadsheets in eine ähnlich unangenehme Lage.

Ein Projekt ist gescheitert, wenn für einen seiner Hauptaspekte (Leistung, Zeit, Geld) die Soll-Vorgabe vom Ist-Wert nicht erreicht wird. Sind für einen Hauptaspekt keine überprüfbaren Soll- und Ist-Werte in Form eines Angebotes oder einer Leistungsbeschreibung vorhanden, ist das Projekt im mathematischen Sinn 'nicht definiert'. Für ein nicht eindeutig definiertes Projekt, bei dem eine Soll-Ist-Analyse nicht vorgenommen werden kann, ist wie bei der Division durch 0 (z. B. 5/0=?) nicht eindeutig ermittelbar, welchen Wert sein Ergebnis hat und somit ob es ein Erfolg oder Misserfolg ist. Der META Group zufolge scheitern bereits 80% der US-Unternehmen bei der Ermittlung des Erfolgs oder Misserfolgs von IT-Projekten daran, dass messbare Soll-Vorgaben, Mess-Instrumente usw. fehlen.

Zu den Projekten gehören Leistungsscheine und abnahmefähige Meilensteine. Ohne unterschriebenen Leistungsschein und ohne abgenommenen Meilenstein kann es dem IT-Freiberufler passieren, dass er kein Honorar erhält oder seine Mitarbeit beim nächsten Arbeitspaket nicht mehr gefragt ist.

Je größer die Arbeitspakete, desto schwieriger wird es, klare abnahmefähige Meilensteine zu definieren. Das entspricht der Erfahrung mit Großprojekten. So konnten der Standish Group zufolge US-Großunternehmen ihre Erfolgsquote bei IT-Projekten von 9% in 1994 auf 23,6% in 1998 dadurch steigern, dass sie wenige Großprojekte durch viele Kleinprojekte ablösten.

"Wie will man es schaffen, daß die Komplexität eines IT-Projekts von nicht "IT'schen" Auftraggebern verstanden/akzeptiert/berücksichtigt wird und demnach dann die Ressourcen/Aufwendungen für ein Projekt geplant werden? Viele Unternehmer/Auftraggeber stehen auf dem Standpunkt, daß, von der Anwendungsentwicklung evt. abgesehen, "der Rest der Technik" schließlich durch "kurzes Aufstellen mit anschließender Installation und Konfiguration" zum Laufen gebracht werden kann... "