I. Einführung in die Projektarbeit

Als kurze Einführung in die Thematik werden in den folgenden Abschnitten die wichtigsten Projektbegriffe, -arten und -rollen vorgestellt.

A. Projektdefinition

In Wikipedia wird ein "Projekt" etwas abstrakt definiert: "Ein Projekt ist ein zielgerichtetes, einmaliges Vorhaben, das aus einem Satz von abgestimmten, gesteuerten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Vorgaben bezüglich Zeit, Ressourcen [.] und Qualität ein Ziel zu erreichen." (Wikipedia, Projekt, 2018)

Eine konkretere, anschaulichere Umschreibung des Projektbegriffes liefert Ann-Kathrin Rillox in ihrem Buch "Die Kunst, ein Notizbuch zu führen":

- "Das Ziel wird durch eine Vielzahl von Aufgabenerledigungen erreicht.

- Projekte können zeit-, kosten- und arbeitsintensiv sein.

- Meist können sie nicht von einem Einzelnen umgesetzt werden.

- Sie sind an Rahmenbedingungen gebunden und auch Externe können Interesse am Projekt haben.

- Ihre Umsetzung erstreckt sich über einen längeren Zeitraum.

- Sie können eine Reise ins Ungewisse sein, weil man nicht weiss, ob das Projekt funktioniert.

- Sie haben eine gewisse Tragweite und ein gewisses Risiko.

- Einzelne Aufgaben sind interdependent: ob und wie die vorherige Aufgabe erledigt wird, entfaltet Konsequenzen für die nachfolgende." (Rillox, 2014:2212)

Kurz gesagt, geht es im Projektgeschäft um ein paar wenige, aber entscheidende Dinge:

- Verantwortlichkeit innerhalb klarer Strukturen,

- Planung und Koordination von Aufgaben,

- Kommunikation nach innen und aussen,

- Verständnis des Projektes als komplexes System mit Elementen, Beziehungen und dem Systemumfeld.

Die Grenze zwischen einem normalen Projekt und einem Grossprojekt legt jedes Unternehmen für sich selbst fest. In grossen Schweizer Banken spricht man ab einer Budgethöhe zwischen 15 und 20 Mio. Franken von einem grossen Projekt.

B. Die Stunde der Wahrheit

Jedes Projekt hat einen Start- und einen Endtermin. Hauptaufgabe des Projektleiters ist es, zusammen mit seinem Team die zahlreichen Einzelaktivitäten sorgfältig zu planen, diese den bestgeeigneten Mitarbeitern anzuvertrauen und die Ausführung nach dem Prinzip "so wenig Kontrolle wie möglich, so viel wie nötig" zu beaufsichtigen.

Im Unterschied zum Tagesgeschäft kann jede falsche Entscheidung im Projektverlauf unmittelbare und manchmal fatale Konsequenzen für Termin, Kosten und/oder die Qualität des Projektes haben. Deshalb erfordert Projektarbeit eine detailliertere Aktivitäten- und Ressourcenplanung, als dies bei der Linienführung der Fall ist.

Ein weiteres Unterscheidungsmerkmal zwischen Projekt- und Linienaufgaben ist das Verhalten gegenüber Hindernissen. Während diese im Tagesgeschäft als Störungen empfunden werden, gehören sie im Projektgeschäft zum Alltag. Projekte sind per definitionem erst- und deshalb auch einmalige Vorhaben. Art und Umfang von Hindernissen lassen sich vor allem bei Grossprojekten nicht voraussehen. In der Regel gilt, dass je grösser oder wichtiger ein Projekt, umso anspruchsvoller sind die zu bewältigenden Schwierigkeiten. Dass ein Projektleiter für die Überwindung grosser, oftmals 'politischer' Hürden auf die Unterstützung des Managements angewiesen ist, versteht sich dabei von selbst. Siehe dazu auch verschiedene Abschnitte im Kapitel "Governance: Wer mitreden will, muss Verantwortung übernehmen".

In jedem IT-Projekt kommt unweigerlich die "Stunde der Wahrheit". Die Software läuft oder läuft nicht (zufriedenstellend). Jeder erfahrene Projektleiter kann aus dem Stegreif ein halbes Dutzend unerwartete Schwierigkeiten aufzählen, welche für Termin- und Kostenüberschreitungen verantwortlich sind. Tief im Innern wird er aber wissen, dass unerwartete Hindernisse das Wesen der Projektarbeit ausmachen und er als Projektleiter für das Überwinden dieser Hindernisse zuständig ist. Oder wie es Michail Gorbatschow im Januar 1987 vor dem ZK4-Plenum in Bezug auf die Perestroika treffend formulierte: "[.] ist kein Spaziergang auf einem planierten Weg. Es ist die Besteigung eines Berges, häufig auf Pfaden, die noch nie jemand begangen hat." (Webbeler, 2003)

"Ich staune oft über das hohe Mass an kreativer Fähigkeit, das Chefs [.] entwickeln, wenn es darum geht, den eigenen Misserfolg [.] zu begründen." Dr. Christoph Blocher, Alt-Bundesrat (Blocher, 2000)

"There is always the unexpected5" gilt wohl nirgends so passend wie bei der Projektarbeit. Nur zum Teil scherzhaft bezeichne ich deshalb meinen stets aktivierten Hindernis-Radarschirm als "Projektleiter-Gen" (was von meiner Ehefrau jeweils mit Augenrollen quittiert wird; aber das ist eine andere Geschichte).

C. Die Verantwortung steht im Zentrum

Ich stimme weiter mit Christoph Blocher überein, dass Verantwortung grundsätzlich unteilbar ist:

"[.], denn verantwortlich sind Sie nicht nur für Erfolge, sondern auch für Misserfolge, egal ob Sie schuld sind oder nicht. Insofern ist Verantwortung nicht teilbar. Jeder hat seinen Auftrag und damit seinen klar definierten Verantwortungsbereich. Bei einem Misserfolg liegt die Verantwortung auch dann beim Vorgesetzten, wenn der Untergebene die Schuld trägt." (Ackeret, 2007:4)

Das Konzept der persönlichen Verantwortung - insbesondere des Projektleiters - ist ein zentrales Element dieses Buches. Ich bin davon überzeugt, dass sich eine Person ohne ihr direkt zugewiesene Verantwortung im täglichen Projektleben anders verhält als jemand, der sich persönlich für eine Aufgabe verantwortlich fühlt. Die persönliche Verantwortung der Projektleiterin umfasst:

- ihre Entscheidungen, Handlungen und Unterlassungen,

- die von ihr und dem Team erzielten Projektergebnisse,

- ihr Verhalten gegenüber dem Team, den Vorgesetzten und den Stakeholdern6 sowie

- ihre mündlich oder schriftlich formulierten Äusserungen.

Nicht zuletzt am Beispiel von INSIEME hat sich gezeigt, wie wichtig eine klare Abgrenzung der Verantwortlichkeiten ist und wie fatal sich Kompetenzstreitigkeiten, Interessenkonflikte, Vetorechte, sogenannte "Beobachterstati" und Missverständnisse zwischen Lieferanten und Empfängern auf ein Projekt auswirken können.

D. Was macht IT-Projekte aussergewöhnlich?

Grosse IT-Projekte im Allgemeinen und Softwareentwicklungen im Speziellen weisen ein paar Eigenheiten auf, die sie häufiger als andere Vorhaben in Schwierigkeiten geraten lassen. Die Hauptursachen dafür sind Abstraktion und Komplexität.

Bei Softwareprojekten wird nicht mit festen Stoffen, sondern fast ausschliesslich mit gedanklicher Arbeit an abstrakten Konzepten und Lieferergebnissen gearbeitet. Gedankliche Arbeit lässt sich kaum messen, normieren oder standardisieren. Daraus resultieren - etwa im Vergleich zu Bauprojekten - kürzere Planungsphasen, welche wiederum eine der Ursachen für Termin- und Kostenüberschreitungen bei IT-Projekten sind.

Auf das Thema Komplexität werde ich in Kapitel VIII "IT-Projekte als komplexe Systeme" (s. Seite 309) näher eingehen.

E. IT-Projektarten

An dieser Stelle sei nicht näher auf reine Fachprojekte, Produktentwicklungen oder Organisationsprojekte eingegangen. Ich werde mich stattdessen auf die wichtigsten Informatikvorhaben konzentrieren. Diese lassen sich grob unterteilen in Hard- und Softwareprojekte. Auf Erstere werde ich hier mangels eigener Praxiserfahrung ebenfalls nicht weiter eingehen, sondern mich auf die Kurzbeschreibung der verschiedenen Arten von Softwareprojekten beschränken: Eigenentwicklung, Softwarekauf, Migration und Decommissioning.

Abbildung 1: Projektarten in Banken (Auswahl)

Selbstverständlich sind auch Mischformen zwischen den einzelnen Projektarten möglich. Beispielsweise wird die Entwicklung eines neuen Bankproduktes in den wenigsten Fällen ohne Software-Anpassungen möglich sein.

1. Entwicklungsprojekte (MAKE)

Software-Entwicklungsprojekte erfordern eigene Analyse- und Programmierleistungen zur Erzielung der gewünschten Funktionalität. Die Software wird als integrierte, auf die bestehende Systemumgebung ausgerichtete Lösung entwickelt und hat Schnittstellen von/zu anderen Applikationen.

Die als Sonderfall bezeichnete "Entwicklung auf der grünen Wiese" mit keiner oder nur wenigen Schnittstellen zur bestehenden Systemumgebung kommt in der Bankpraxis nur noch selten vor.

2. Software-Kauf und Implementierung (BUY)

Damit ist der Kauf einer Drittsoftware zur Einbettung in die bereits bestehende Systemlandschaft gemeint. Eigene Programmierleistungen sind vor allem zur Anpassung der internen Schnittstellen an das neue System erforderlich.

Ein Sonderfall sowohl bei selbst entwickelter wie auch bei eingekaufter Software ist die damit verbundene Ablösung einer bereits existierenden Applikation: Je mehr Unterhaltsarbeiten und kleine Weiterentwicklungen an dieser nötig werden - manche davon zwingend aufgrund regulatorischer Anpassungen -, desto schwieriger wird es für das neue Projekt, dem "fahrenden Zug hinterherzurennen".

3. Migrationsprojekte

Damit wird die...