Erfolgsfaktoren bei IT-Projekten
(Dreiteilige Serie)

Teil 1 | Teil 2 | Teil 3

Nachdem sich die GULP-Reihe "Woran scheitern IT-Projekte" mit den Ursachen eines Projekt-Misserfolgs beschäftigte, sind nun Faktoren an der Reihe, die zu einem erfolgreichen Projektverlauf führen. Die erste Folge dieser dreiteiligen Serie beschäftigt sich mit Visualisierungsaspekten. Der in der KW 14 erscheinende zweite Teil wird den Erfolgsfaktoren Lastenheft, Arbeitsplanung und Selbstkontrolle gewidmet sein.

IT-Projekte werden in den Führungsetagen oft als Fortschritts- und Innovationsmotoren gesehen und dementsprechend gefördert. In der Praxis kommen sie aber immer seltener zu einem erfolgreichen Abschluss. So wurden in USA, dem Mutterland der Projektarbeit, für 2001 die Scheiterquoten bis auf 90% beziffert. Während man im deutschen Sprachraum gerne auf Prognosen und Schätzungen vertraut, werden amerikanische Projekte mit verifizierbaren Kriterien (Soll-Ist-Analysen) gemessen und bewertet. Silicon-Kolumnist David Taylor bringt Projekterfolge auf den Nenner, dass die vereinbarte Leistung innerhalb des vereinbarten Zeit- und Geldrahmens erbracht worden sein muss. An dieser Meßlatte scheiterten Taylor zufolge etwa 90% aller IT-Projekte im Jahr 2001. Dabei war die Zahl der 8 von 10 zugegebenermaßen gescheiterten Projekte um eine Dunkelziffer verschwiegener Projekte oder zu Unrecht als Erfolg deklarierter Projekte zu ergänzen. Ein Jahr zuvor war Taylor noch von einer 40%igen Scheiterquote ausgegangen, während die Standish Group International die Latte bereits auf 72% gelegt hatte.

Diese hohen Scheiterquoten mit steigender Tendenz legen die Annahme nahe, dass IT-Projekterfolg durch ein Vermeiden all der in gescheiterten Projekten gemachten Fehler machbar ist. Das ist ein bedauerlicher Irrtum. Denn für die Projektarbeit erweist sich der Umkehrschluss schnell als Trugschluss. Der erforderliche hohe Vermeidungsaufwand und Perfektionswahn lassen die Projekte dann gar kein Ende mehr finden. Dazu passt der Erfahrungswert, den der kanadische Business Intelligence-Anbieter Cognos für die Installation von Branchenlösungen ermittelt hat: Während 80-90%ige Zielfunktionalität nur 10-20% des klassischen Aufwandes erfordert, ist 100%ige Zielfunktionalität entweder extrem aufwendig oder überhaupt nicht zu erreichen.

Auch im IT-Projekt kann durch Begrenzung des Aufwands die Erfolgswahrscheinlichkeit erhöht werden. Dabei ist auf Seite des Auftraggebers Voraussetzung, dass die Anforderungen, Zielsetzungen und Ressourcen klar definiert sind. Voraussetzung seitens des IT-Freiberuflers ist ein sicheres Verfügen über entwicklungsrelevantes Know-how gepaart mit Branchenkenntnissen.

Für die Zusammenarbeit im Projekt hat sich insbesondere die Verwendung von Beispielen und Visualisierungs-Tools bewährt. Durch Konkretisierung von Abstraktem lässt sich ein gemeinsames Verständnis über Probleme, Prozesse und Lösungen leichter erzielen. Organisatorische und Kommunikationsaufgaben lassen sich mit Projektmanagementsystemen und mit den richtigen Soft-Skills besser in den Griff bekommen.

Formlose Skizzen

"Ein Bild sagt mehr als tausend Worte." So banal, wie diese Redensart ist, liefert sie doch einen wichtigen Schlüssel für erfolgreiche Projektarbeit. Steve Palmer, Direktor von TogetherSoft, baut darauf seine Definition eines guten Beispiels auf, das komplex genug sein muss, übergreifende Lerninhalte zu vermitteln, aber einfach genug, um verstanden zu werden.

Damit ein IT-Projekt positiv zum Geschäftsergebnis des Endkunden beitragen kann, sollte bereits im Antrag der zum Erreichen des Projektziels erforderliche Leistungs-, Zeit- und Geldumfang dargestellt werden. Das setzt natürlich voraus, dass die Beteiligten zumindest grob über Geschäftsgegenstand, Geschäftsziel, Geschäftsmodell, Geschäftsprozess und die projektrelevanten Geschäftsvorfälle informiert sind. Und das erfordert wiederum eine anschauliche Darstellung des Wegs vom Geschäftsgegenstand über das Geschäftsziel und das Geschäftsmodell hin zu den einzelnen Geschäftsvorgängen, um Anwendungsvorfälle und Prozess- bzw. Verfahrensmodelle ableiten und beurteilen zu können. Beispiele, Handskizzen und Software-Tools sind hierbei bewährte Tools.

Die formlose Skizziertechnik ist bei einigen Anbietern von Modellierungs-Software oder bei jedem Projektmanagement-Anbieter erlernbar. Gelegentlich wird in Ausschreibungen eine "Projektskizze" als Angebotsbestandteil gefordert. Schon hier verbessern einfache Farbkodierungen (Ampelfarben rot -gelb-grün etc.) die Übersicht. Ergeben sich im Verhandlungsgespräch Änderungen, dann kann am Notebook schnell aktualisiert werden, was an Leistungen angeboten werden soll, was nicht oder was nur optional.

Genügen bei den Besprechungen zwischen Fachabteilungen und IT-Spezialisten meist Textnotizen und formlose Skizzen, so ist es spätestens für die Weitergabe an Dritte sinnvoll, beides zu formalisieren und standardisieren. Dabei wird zunehmend UML (Unified Modelling Language, Dateiformat: *.mdl) eingesetzt. Diese grafische Modellierungssprache haben Mitarbeiter der Firma Rational Rose konzipiert und gestartet. UML-Standard ist derzeit die Spezifikation 1.3. Die Versionen 1.4 bis 2.0 liegen zwar vor, sind aber noch nicht freigegeben.

Mit UML lassen sich alle relevanten plattformunabhängigen Aspekte eines betriebswirtschaftlichen Modells (z. B. ein Geschäftsmodell oder das Modell eines IT-Projekts) in der Art der objektorientierten Programmierung standardisiert beschreiben. Die Standardisierung erlaubt Bearbeitung, Weiterverarbeitung und Weitergabe. Prozess- bzw. Verfahrensmodelle können in UML erfasst, grafisch abgebildet und in einer relationalen Datenbank abgespeichert werden. IT-Experten empfehlen eine plattformunabhängige Darstellung in UML, für die Anpassung an die Plattform (z. B. OS2, Windows NT, UNIX, Linux) einen Übergang in XML (eXtended Markup Language).

Da UML selbst kein Vorgehensmodell bietet, gehen die Softwarehersteller unterschiedlich vor. So arbeitet TogetherSoft "Feature-driven". Das bedeutet, dass die im Anwendungsfalldiagramm beschriebenen Eigenschaften den Vorgehensschlüssel bilden. Microtool und Rational Rose verwenden die "Use-Case-driven"-Methode. Das heisst, Anwendungsfalldiagramme werden als Ganzes zum Verfahrensschlüssel. Borland wiederum benutzt eine "Model-driven-Architecture", die über eine plattformunabhängige UML-Modell-Umgebung zur Borland-proprietären Anwendungsentwurf-Umgebung Delphi führt. Objecteering von 'Softeam' arbeitet ebenfalls mit einer "Model-driven-Architecture".

Herausragendes Beispiel für ein Vorgehensmodell ist das Capability Maturity Model "The IDEAL Model" vom CMMI Product Team (Software Engineering Institute, Carnegie Mellon University, Pittsburgh, USA).

Das Arbeiten mit diesem Modell erfordert weder erweiterte Rechenfähigkeiten noch ein Projektmanagementsystem. Es lässt in der Diagnosephase, die im Re-Iterationsverfahren immer wieder durchlaufen wird, kritische Vorgänge im Projekt erkennbar werden. Die Zeitdauer der Re-Iterationsschleife bestimmt, wie oft Änderungen erfasst, diagnostiziert und verarbeitet werden können.

UML-Diagramme können im IT-Projekt ab der Leistungsbeschreibung sinnvoll sein. Die UML-Spezifikation 1.3 bietet zahlreiche Diagrammtypen an. Es ist allerdings weder notwendig noch sinnvoll, ständig sämtliche Typen zu verwenden. Es ist dagegen nützlich, alle zu kennen, um sie entsprechend den Anforderungen und den eigenen Vorlieben im Projekt einsetzen zu können. Die nachfolgenden Beispiele sind den Schulungsunterlagen von TogetherSoft Deutschland und dem Online-Tutorial der Universität Magdeburg entnommen.

Mit dem schachtelbaren Anwendungsfalldiagramm (Use Case Diagram) lassen sich die Leistungen im Projekt veranschaulichen. Deckungsgleichheit zwischen den Anwendungsfalldiagrammen (Bild) und der Leistungsbeschreibung (Text) belegt die Konsistenz der Leistungsanforderungen. Voraussichtlich funktioniert dann auch das Requirementsmanagement ausgezeichnet.

Use Case Diagrams sind nach Microtool und Rational Rose der Ausgangs- und Angelpunkt für ein IT-Projekt. TogetherSoft betrachtet die Eigenschaften als Schlüssel, isoliert deshalb einzelne Features aus dem Use Case Diagram.

Für ein IT-Projekt kann mit einem Use Case Diagram dargestellt werden, welche Beteiligten (Actors) es gibt und welche Outputs diese vom System erwarten. Wie das vom System dann realisiert wird, bleibt offen.

Mittels Klassendiagramm (Class Diagram) können die Objekte (Classes, Typen, zentrale Aspekte) des Angebots abgebildet werden. Die Klassen sind schachtelbar.

Die Objekte, die als weniger konsistente Textdatenbank (Data Dictionary) vorliegen, werden bei der grafischen Umsetzung automatisch auf Plausibilität und Konsistenz geprüft. Ist ihre Abbildung vollständig, dann ist eine durchgängige IT-Architektur für das IT-Projekt wahrscheinlich gegeben.

Das Aktivitätsdiagramm (Activity Diagram) visualisiert die dynamischen Aspekte eines Systems. Es zeigt die zu erledigenden Aufgaben (Activities) und deren Bedingungen (Constraints) auf, aber nicht notwendig die Reihenfolge (Sequence).

Mit dem Activity Diagram lassen sich selbst komplexe Vorgänge, z. B. der Ablauf bei der Bedienung eines Getränkeautomaten, strukturiert und leicht überprüfbar darstellen.

Welche Objekte direkt miteinander in Verbindung stehen oder über welche Objekte die mittelbare Kommunikation verläuft, kann mit dem Kollaborationsdiagramm (Collaboration Diagram) spezifiziert werden.

Was in welcher Reihenfolge geschieht, macht das Sequenzdiagramm (Sequence Diagram) deutlich. Die Kommunikation zwischen Objekten ist in der zeitlichen Abfolge darstellbar.

Ein Zustandsdiagramm (State Diagram, State Chart Diagram) formuliert sowohl die möglichen Zustände, die ein Objekt annehmen kann, als auch die möglichen Ereignisse, die einen Übergang in einen anderen Zustand bewirken. Ein Zustand ist genau einer Klasse zugeordnet. Der Wählvorgang beim Telefonieren kann dementsprechend in seine Einzelstadien zerlegt werden.

Sowohl Quellcode-Strukturen als auch Laufzeit-Strukturen können mit dem Komponentendiagramm (Component Diagram) abgebildet werden. Die Komponenten werden dabei nur als Typen erfasst. Für eine Darstellung der Bestandteile als Instanzen ist ein Verteilungsdiagramm (Deployment Diagramm) besser geeignet.

Das Ansichtsdiagramm (View Diagram) gibt eine ‚logische' (virtuelle) Sicht auf das aktuelle Projekt, Teilprojekt oder Paket. Es formuliert eine Übersicht über beliebige Klassen aus beliebigen Paketen nach einem frei gewählten Gesichtspunk

Kostenpflichtige Schulungen in UML offerieren Rational Rose und TogetherSoft. Microsoft schult ebenfalls in UML. Die Entwicklungsumgebung Visual Studio 6.0 enthält eine Lite Version von Rational Rose (Klassendiagramm), was mit zum Bekanntheitsgrad von Rational Rose beigetragen hat. In die Entwicklungsumgebung Visual Studio .Net hat Microsoft acht UML-Diagramme (vom Anwendungsfall- bis zum Einsatzdiagramm) eingebaut, wofür das alte und bislang nicht sonderlich erfolgreiche MS-Grafiktool Visio aktualisiert worden ist.

Diese Unternehmen passen ihre Schulungsunterlagen ständig dem Stand der Softwareentwicklung an. Sie arbeiten Neuerungen erfahrungsgemäß schneller ein als Universitäten, die einen Teil ihres Wissens aber kostenlos ins Internet stellen. So bietet die Universität Magdeburg ein weitgehend theoretisches Online-Tutorial an.

Mitarbeiter in den Unternehmen der Endkunden können selten mit standardisierten Visualisierungs-Tools wie UML umgehen. Das bedeutet für den IT-Freiberufler, dass er sich hier einen Know-how-Vorsprung verschaffen kann, der sich voraussichtlich auszahlt. UML ist nicht nur ein nützliches Tool für die Abwicklung von IT-Projekten. Auch die Auftraggeber honorieren UML-Kenntnisse gut. Das GULP-o-meter gibt im März 2002 für Deutschland einen durchschnittlichen Stundensatz von 76 € an, während Windows-Kenntnisse nur 69 € bringen. Rational Rose-Kenntnisse (Rational Tools) werden mit 82 € pro Stunde besonders gut honoriert. In Großbritannien werden nach der Marktübersicht von ContractorUK UML-Kenntnisse mit 53 GBP nahezu gleich hoch wie in Deutschland eingestuft.

Kommentar zum Artikel

"Eine gute Übersicht mit interessanten Links! (September 2004)"

"Angenehm kurz und bündig, mit wichtigen Links. (März 2004)"