PROJEKTMANAGEMENT FÜR PROFIS E-Book

Markus Thüring

• Herausgeber: Omnino Verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch

Seitenzahl: 384

Veröffentlichungsjahr: 2022

Beschreibung

INSIEME, das im Herbst 2012 abgebrochene IT-Grossprojekt der Eidgenössischen Steuerverwaltung hat einen Schaden von 116 Millionen Franken zulasten des Steuerzahlers hinterlassen. IT-Debakel dieser Art sind nicht auf die öffentliche Verwaltung beschränkt. Auch in grossen Schweizer Finaninzstitutionen sind in den letzten Jahren einige Grossvorhaben gescheitert und haben Abschreibungen in dreistelliger Millionengrösse verursacht. Bei der Lektüre des veröffentlichten INSIEME-Untersuchungsberichtes erlebte der Autor zahlreiche déjà-vu-Erlebnisse. Im Laufe seiner mehr als 40-jährigen Berufserfahrung als Business Analyst, Projektleiter und Program Manager für grosse Schweizer Finanzinstitute hat er gleiche oder ähnliche Schwierigkeiten ebenfalls angetroffen. Seine Schlussfolgerung war, dass es sich dabei offenbar um systemische Probleme handelt und es sich lohnt, den tieferliegenden Ursachen für das Scheitern auf den Grund zu gehen und dafür nach Verbesserungsansätzen für alle Aspekte der Projektarbeit zu suchen. Zu der von Markus Thüring entwickelten Projektgovernance gehört die zentrale Bedeutung des Projektmanagers, die Neuordnung der Verantwortlichkeit von Auftraggebern und Projektausschüssen sowie die Möglichkeiten und Grenzen von Aufsichts- und Kontrollorganen. Im Buch vorgestellt wird ausserdem die neue, vom Autor entwickelte Methode der "Pareto-Systemanalyse". Dieses Instrument zur Problemanalyse und Komplexitätsreduktion lässt sich bei Audits oder in kritischen Projektsituationen anwenden. In fünf einfachen Schritten von der visuellen Systemdarstellung bis zur Definition von wenigen, aber fokussierten Massnahmen lassen sich damit für IT-Projekte typische, komplexe Problemstellungen analysieren. Mit praktischen Tipps und Tricks, Checklisten und anschaulich beschriebenen, selbst erlebten Fallbeispielen. „Markus Thüring ist ein erfahrener Schweizer Großprojektmanager und hat dieses "aus der Praxis – für die Praxis"-Buch zwar in erster Linie für aktive und zukünftige Projektmanager geschrieben. Seine zahlreichen Vorschläge zur optimalen Projektgovernance bieten aber auch Anregung und Inspiration für Consultants, Linienvorgesetzte, Auftraggeberinnen, Projektausschussmitglieder und Auditorinnen.“

Leseprobe

Für Walter und Engelbert (†),die besten Lehrmeister,die man sich wünschen kann.

Inhaltsverzeichnis

Inhaltsverzeichnis

Abbildungsverzeichnis

Vorwort

I. Einführung in die Projektarbeit

A. Projektdefinition

B. Die Stunde der Wahrheit

C. Die Verantwortung steht im Zentrum

D. Was macht IT-Projekte aussergewöhnlich?

E. IT-Projektarten

F. Rollenprofile in IT-Projekten

II. Woran IT-Projekte scheitern

A. Beispiele fehlgeschlagener IT-Projekte

B. CHAOS Report der Standish Group

C. Interne und externe Problemursachen

D. Die Folgen des Scheiterns

III. Der Erfolg steht und fällt mit der Projektleitung

A. Projektleitung bei INSIEME

B. Aufgaben, Verantwortung und Kompetenzen

C. Persönlichkeit, Einstellung und Verhalten

D. Mitarbeiterführung: "Vertrauen ist der Anfang von allem"

E. Kritische Führungssituationen

F. Handwerk und Selbstorganisation

G. Spezialfälle der Projektführung

H. Verbesserungsansätze bei der Projektleitung

IV. Projektmanagement als Disziplin

A. Projektmanagement bei INSIEME

B. Organisation: "Alles eine Frage der Führung"

C. Kommunikation

D. Koordination

E. Planung

F.Change Management

G. Termin- und Kostenkontrolle

H. Berichtswesen und Projektreporting

I. Projekt-/Entwicklungsmethodik

J. Verbesserungsansätze beim Projektmanagement

V. Governance: Wer mitreden will, muss Verantwortung übernehmen

A. Governance bei INSIEME

B. Theoretische Grundlagen

C. Begriffsabgrenzung

D. Auftraggeber

E. Projektausschuss

F. Linienführung

VI. Aufsichtsorgane und übrige Stakeholder

A. Projektaudits bei INSIEME

B. Reviews und Audits

C. Verbesserungsansätze bei den Aufsichtsorganen

D. Stakeholder

VII. Rahmenbedingungen und Einflussfaktoren

A. Rahmenbedingungen bei INSIEME

B. Äussere Einflussfaktoren bei INSIEME

C. Typische Projekt-Rahmenbedingungen

D. Typische Äussere Einflussfaktoren

E. Verbesserungsansätze

VIII. IT-Projekte als komplexe Systeme

A. Systemtheorie

B. Einfache, komplizierte und komplexe Probleme

C. Ist Komplexität beherrschbar?

D. Vergleich mit anderen Branchen

IX. Der INSIEME-Untersuchungsbericht

X. Zusammenfassung

A. Projektleitung

B. Projektorganisation

C. Governance

D. Bewertung von Projektrisiken

E. Aufsicht und Kontrolle

F. Komplexität

G. Praktische Empfehlungen zum Projektmanagement

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Projektarten in Banken (Auswahl)

Abbildung 2: Rollen und Einflussfaktoren im Projekt

Abbildung 3: Standish Group CHAOS Report

Abbildung 4: Die Essenz der Projektleitung

Abbildung 5: Wichtigste Aufgaben der Projektleiterin

Abbildung 6: Dimensionen der Entscheidungsqualität

Abbildung 7: Toleranz gegenüber Fehlverhalten

Abbildung 8: Leistungsdynamik

Abbildung 9: Beurteilungsraster nach Probezeit

Abbildung 10: Entscheidungsdiagramm zu Sonderstatus & Privilegien

Abbildung 11: Projektmanagement-Ansatz

Abbildung 12: Micro-/Macromanagement und Fachkompetenz

Abbildung 13: Formansprüche verschiedener Meetingtypen

Abbildung 14: Besprechungsnotizen-Vorlage

Abbildung 15: Vergessenskurve nach Ebbinghaus

Abbildung 16: SWOT-Analysematrix

Abbildung 17: Projektführung mit Doppelspitzen

Abbildung 18: Missachtung der Beschaffungsvorgaben

Abbildung 19: Mangelhafte Projektdokumentation

Abbildung 20: Ursache-/Wirkungsdiagramm "Methodenwechsel"

Abbildung 21: Matrix-Projektorganisation (Beispiel)

Abbildung 22: Organigramm Migrationsprojekt

Abbildung 23: Unzweckmässiges Projektorganigramm (Beispiel)

Abbildung 24: Asymmetrische Lieferverantwortung

Abbildung 25: Kommunikationsstruktur bei Co-Projektleitung (Beispiel)

Abbildung 26: Drei Schritte auf dem Weg zur Terminplanung

Abbildung 27: Zielhierarchie

Abbildung 28: Projektberichte bei INSIEME

Abbildung 29: Das Wasserfallmodell

Abbildung 30: Project Charter zur Projektinitialisierung

Abbildung 31: Führungsmodell ohne Doppelspitze

Abbildung 32: Wahl der Projektmethodik

Abbildung 33: Projektgovernance

Abbildung 34: Entscheidungsraster für Projektstart

Abbildung 35: Entscheidungsraster Projektabbruch

Abbildung 36: Risikomatrix

Abbildung 37: Machtkonzentration & Interessenkonflikt

Abbildung 38: Entscheidungstabelle zur Risikobeurteilung

Abbildung 39: Dreidimensionale Risikobeurteilung

Abbildung 40: Hierarchische Projekt-Zuordnung

Abbildung 41: INSIEME-Projektaudits

Abbildung 42: Eskalationsplan für Review-Befunde

Abbildung 43: Rollenabgrenzung in IT-Projekten

Abbildung 44: Stakeholder-Beteiligung am Projekt

Abbildung 45: Vereinfachte Systemdarstellung

Abbildung 46: Unterschiedliche Problemtypen

Abbildung 47: Einfache, komplizierte und komplexe Probleme

Abbildung 48: INSIEME als Systemdarstellung

Abbildung 49: Pareto-Systemanalyse (INSIEME)

Abbildung 50: Die 20 grössten INSIEME-Probleme

Vorwort

"Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende", mag sich Bundesrätin Eveline Widmer-Schlumpf am 17. September 2012 gedacht haben, als sie INSIEME, das Mega-Projekt der Eidgenössischen Steuerverwaltung (ESTV) mit einem Federstrich stoppte. Das bisher grösste IT-Debakel der Bundesverwaltung verursachte nach einer Laufzeit von rund zwölf Jahren einen Schaden von 116 Mio. Franken zu Lasten des Steuerzahlers und löste deshalb ein erhebliches Medienecho aus.

Während der Lektüre von Zeitungsartikeln zu INSIEME und erst recht beim späteren Studium des Untersuchungsberichtes der parlamentarischen Arbeitsgruppe AGI1 hatte ich ein déjà-vu-Erlebnis. Von allen im Bericht aufgezählten Problemen, die schliesslich zum Abbruch des Vorhabens führten, hatte ich nur ein einziges davon in meiner eigenen Berufslaufbahn als Projektleiter in grossen Schweizer Banken noch nicht angetroffen. Meine Schlussfolgerung war deshalb, dass die meisten Stolpersteine bei solchen Vorhaben offenbar branchenübergreifenden, systemischen Charakter haben. Nach der Publikation des INSIEME-Untersuchungsberichtes habe ich begonnen, mir Notizen zu machen über Führungs- und andere Projektprobleme, deren tiefere Ursachen und mögliche Verbesserungsansätze.

Bereits als junger Business-Analyst und auch später als Projektleiter versuchte ich, möglichst viel von den Kenntnissen und Erfahrungen meiner älteren Kollegen zu profitieren und diejenigen Tipps und Tricks zu übernehmen, welche sich in der Praxis bewährt hatten. Auch während meiner Weiterbildung und bei der Lektüre von Fachliteratur wollte ich vor allem praxisorientierte Hinweise von Führungskräften in Erfahrung bringen. Dies war einer der Gründe, weshalb ich mir vornahm, zum Ende meiner Berufslaufbahn ein Buch aus der Praxis eines Projektleiters zu schreiben und damit zu versuchen, jüngeren Kollegen etwas Inspiration und Hilfestellung bei ihrer herausfordernden Führungsaufgabe zu geben.

Warum aber erst jetzt dieses Buch, wenn viele meiner Beobachtungen doch schon einige Jahre zurückliegen? Dazu eine kurze Geschichte über einen der Defining Moments in meinem Lebenslauf: Jock, ein englischer Arzt, Aussteiger und Weltumsegler auf Pangalusian Island – einer kleinen, abgelegenen Insel auf den Philippinen – veranlasste mich Ende der Achtzigerjahre, etwas tiefer über meinen Beruf und seine Herausforderungen nachzudenken.

Ich hatte als Projektleiter soeben mein erstes Software-Entwicklungsprojekt bei einer grossen Zürcher Privatbank erfolgreich abgeschlossen und befand mich mit meiner Ehefrau auf einer achtmonatigen Weltreise, welche uns auch nach Pangalusian Island führte. Jock fragte mich beim ersten Abendessen, wie ich es mir als IT-Projektleiter denn leisten könne, eine Auszeit von acht Monaten zu nehmen, wo sich doch die Informatik in rasend schnellem Tempo weiterentwickle. Diese Frage hatte ich mir selbst noch nie gestellt. Nach kurzem Nachdenken habe ich Jock geantwortet, dass es wohl zutreffe, dass sich die IT als Fachgebiet sehr rasch weiterentwickle2, aber dass mein Beruf weniger mit der Technik als vielmehr mit den Menschen in der Informatik zu tun habe. Und dass sich das Verhalten der Menschen sehr viel langsamer verändere als die Technik und ich deshalb keine Angst haben müsse, etwas zu verpassen.

In über 40 Berufsjahren im Projektgeschäft habe ich seither kein einziges IT-Vorhaben gesehen, das wegen technischer oder fachlicher Probleme abgebrochen wurde. Bei sämtlichen gescheiterten Projekten lagen die Ursachen entweder bei der inneren Führung durch die Projektleitung oder der äusseren Führung durch das Management. Weil viele Schwierigkeiten in IT-Projekten mit menschlichem (Führungs-)Verhalten zu tun haben, bin ich überzeugt, dass wesentliche Erkenntnisse aus meiner eigenen Projekterfahrung noch immer Gültigkeit haben.

Das vorliegende Buch richtet sich in erster Linie an aktive und angehende Projekt-/Programmleiter, ambitionierte Business-Analysten und Software-Entwickler sowie an Manager aller Stufen, die als Auftraggeber oder Projektausschuss-Mitglieder grosse Vorhaben begleiten. Darüber hinaus hoffe ich, dass es auch Linienvorgesetzten in IT- und Fachbereichen, Stabsmitarbeiterinnen, Consultants und nicht zuletzt auch Projektauditorinnen ein paar Denkanstösse vermitteln kann.

Projektmanagement als Disziplin ist in der Fachliteratur bereits sehr gut abgedeckt. Mit der Herangehensweise, ein abgebrochenes Riesenprojekt vom Scheitern her aufzurollen, nach den Ursachen der Schwierigkeiten zu suchen und darauf basierend Verbesserungsmöglichkeiten zu entwickeln, glaube ich jedoch, neue Ansätze zur Verbesserung der Projektarbeit gefunden zu haben:

1. Die Pareto3-Systemanalyse als nützliches Instrument, um bei Projekten in Schieflage – basierend auf dem "80/20"-Prinzip rasch die Problemursachen zu identifizieren und Verbesserungsmassnahmen mit der grössten Hebelwirkung zu definieren;

2. Der Fokus auf die Projektleitung als entscheidendes Element für Erfolg oder Misserfolg des Vorhabens;

3. Die Neudefinition der strategischen Steuerung durch Projektausschüsse mit den Elementen individuelle Verantwortung, Begrenzung der Anzahl Gremiumsmitglieder sowie fundierteren Entscheidungsprozessen;

4. Die dreidimensionale Risikobeurteilung für grosse und bedeutende IT-Vorhaben und – daraus abgeleitet – deren angemessene Einordnung in der Unternehmenshierarchie.

5. Die vorbereiteten Checklisten und Entscheidungsraster für Standardsituationen im Projektverlauf.

Um Missverständnissen gleich zu Beginn vorzubeugen: Dieses Buch vermittelt kein theoretisches, sondern ausschliesslich eigenes Erfahrungswissen oder mit eigenen Augen im näheren Umfeld Beobachtetes. Auch vor einem falschen Umkehrschluss sei an dieser Stelle gewarnt: Viele der geschilderten Fehler und Unterlassungen stammen zwar aus gescheiterten Projekten; trotzdem darf daraus nicht geschlossen werden, dass umgekehrt das Einhalten meiner Empfehlungen automatisch zum Erfolg führt. Dafür sind grosse IT-Projekte nicht nur zu komplex, sondern einmalige und damit auch erstmalige Vorhaben, denen sich immer wieder neuartige Hindernisse in den Weg stellen.

"Man kann nicht zweimal in denselben Fluss steigen." Heraklit (540–470 v. Chr.)

Dort, wo im Interesse einfacher Lesbarkeit keine geschlechtsneutrale Rollenbezeichnung angezeigt ist, verwende ich abwechslungsweise die weibliche und die männliche Form. Sämtliche Namen von Personen, Unternehmen und Projekten sind anonymisiert.

Markus Thüring, im Herbst 2022

1 Arbeitsgruppe INSIEME der Geschäftsprüfungskommissionen Nationalrat/Ständerat (GPK-N/S) und den beiden Finanzkommissionen aus National- und Ständerat (FK-N/-S)

2 Siehe dazu auch das Interview mit dem Logitech-Gründer Daniel Borel in der NZZaS vom 1. November 2020: "Die IT-Branche ist wie ein Film, der schneller läuft als das wirkliche Leben." (Städeli & Biswas, 2020)

3 Das Paretoprinzip, benannt nach Vilfredo Pareto (1848–1923), auch Pareto-Effekt oder 80-zu-20-Regel genannt, besagt, dass 80% der Ergebnisse mit 20% des Gesamtaufwandes erreicht werden. Die verbleibenden 20% der Ergebnisse erfordern mit 80% des Gesamtaufwandes die quantitativ meiste Arbeit (Wikipedia, 2020d).

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 Überführung von Daten und Prozessen von einer alten auf eine neue Plattform bezeichnet. Ähnlich wie bei BUY-Projekten liegt die grösste Herausforderung in der exakten Datenanalyse und der reibungslosen Migration auf das neue System beziehungsweise die neue Plattform.

Ein Spezialfall ist die vollständige Übernahme eines Konkurrenzinstitutes mit daraus resultierendem Migrationsprojekt für die IT- und Business-Seite. Die Zielsetzung ist relativ einfach und wird sich im Lauf des Projektes in der Regel auch nicht verändern: "Daten, Systeme, Personal und Prozesse von A nach B transferieren".

4. Decommissioning-Projekte

In einer Schweizer Grossbank wurden vor ein paar Jahren mehr als zwei Dutzend Software-Tools gezählt, die Portfoliorenditen berechnen. Kein Wunder, bezeichnet die Neue Zürcher Zeitung (NZZ) in ihrem Artikel "Die Schweizer Grossbanken schwächeln […]" vom 20. Juli 2020 die Applikations- und Prozessvielfalt als "historisch gewachsene Monster-IT-Systeme, komplexe organisatorische Strukturen und Prozesse". (Gallarotti, 2020)

Als Decommissioning wird die Ablösung bestehender Applikationen durch neue, selbst entwickelte oder eingekaufte Software-Tools verstanden. Böse Zungen nennen diese Vorhaben auch "Plus-1-Projekte", weil häufig anstelle der Reduktion um ein bestehendes Tool ein weiteres hinzukommt (vgl. Thüring, 2021). Im Zeitalter von Ransomware-Angriffen erpresserischer Hackerbanden hat diese Bedrohung erheblich zugenommen. Nicht nur die Banken selbst sind ein Ziel von Cyberattacken, sondern auch deren Software-Lieferanten. Bei Programmupdates sind eingekaufte, in die Jahre gekommene Softwarepakete deutlich einfachere Ziele als moderne, sicherheitsmässig auf den letzten Stand gebrachte Applikationen (ebd.).

Ähnlich wie bei der Gesetzgebungs-Maschinerie im Parlament dürfte deshalb auch in der Informatik bald der Ruf nach "one in – one out" ertönen. Damit ist gemeint, dass zwingend für jede neue Applikation eine bestehende abzulösen ist.

F. Rollenprofile in IT-Projekten

Die Übersicht der typischen Projektrollen in Abbildung 2 zeigt von innen nach aussen die verschiedenen Personengruppen und Einflussfaktoren, die für ein Projekt verantwortlich sind oder als Rahmenbedingungen beziehungsweise wichtige Stakeholder auf das Projekt einwirken.

Abbildung 2: Rollen und Einflussfaktoren im Projekt

Der Kern des Projektes besteht aus der Projektleitung, dem Team und den Benutzervertreterinnen. Sie bilden den innersten Kreis der am operativen Projektgeschehen beteiligten Personen.

Unter dem Begriff "Governance" werden diejenigen Personengruppen verstanden, die für die strategische Projektsteuerung verantwortlich sind, das heisst die Auftraggeberin und der Projektausschuss.

Linienvorgesetzte aus IT und Fachbereichen sowie IT-Architekten und Produktmanagement bilden den Kreis der nur indirekt am Projekt beteiligten Personen. In der Regel sind sie ebenfalls im Projektausschuss vertreten und zählen deshalb streng genommen zur Projektgovernance. Weil sie normalerweise aber für mehr als ein Projekt zuständig sind, werden sie hier als "Indirekt Beteiligte" bezeichnet.

Die projektexternen Stakeholder sind interne oder externe Anspruchs- beziehungsweise Interessengruppen, die

- direkt oder indirekt vom Vorhaben betroffen sind und dadurch Ansprüche sowie Erwartungen an das Projekt formulieren oder

- nur zu bestimmten Zeitpunkten am Projektgeschehen teilnehmen (z.B. Procurement7, Audit) oder

- nur eine begleitende Rolle im Projekt haben (Stäbe, IT-Sicherheit, externe Beratungsfirmen) beziehungsweise

- nur indirekt über die Linienführung Einfluss nehmen können.

Zu den Rahmenbedingungen gehören alle (System-)Umweltfaktoren, die das Projekt dauerhaft beeinflussen, umgekehrt vom Projekt aber nicht beeinflusst werden können. Beispiele sind neue oder verschärfte Bankregulatorien (MiFID8, FIDLEG9 usw.) durch den Gesetzgeber oder die Aufsichtsbehörden.

Im Unterschied zu den stabilen Rahmenbedingungen wirken sich "Äussere Einflussfaktoren" nur vorübergehend auf das Projekt aus. Typische Beispiele dafür sind interne Reorganisationen mit neuen Stakeholdern, Medienberichte, Konkurrenzverhalten usw.

4 Zentralkomitee

5 "There is always the unexpected. You plan carefully, you decide on one step after another, and then…well, that is life […]." (Soyinka, 1981)

6 Personen, Gruppen oder Organisationseinheiten, die vom Projekt betroffen sind oder es beeinflussen können (vgl. Angermeier, 2018)

7 Zentrales Beschaffungswesen

8 Markets in Financial Instruments Directive (EU-Richtlinie zur Harmonisierung der Finanzmärkte im europäischen Binnenmarkt)

9 Schweizer Finanzdienstleistungsgesetz (Regeln über die Erbringung von Finanzdienstleistungen und das Anbieten von Finanzinstrumenten)

II. Woran IT-Projekte scheitern

Finanzinstitute bestehen zur Hauptsache aus Mitarbeitenden und der Informatik. Wer das nicht glaubt, soll die zahlreichen Medienberichte über IT-Ausfälle in Grossbanken oder über Probleme bei Datenübernahmen auf eine neue IT-Plattform studieren (vgl. Triebe, 2018a:13). Bereits ein 48-stündiger Systemausfall kann eine Bank an den Rand des Zusammenbruchs bringen. Deshalb nimmt die Abhängigkeit von der Informatik weiter zu und darum sind IT-Projekte so wichtig für Banken.

Abgesehen davon halte ich das Thema gescheiterter IT-Grossprojekte für relevant, weil es sich um eine gigantische Wertvernichtung handelt und den Finanzplatz Schweiz wohl jedes Jahr einen dreistelligen Millionenbetrag kostet.

A. Beispiele fehlgeschlagener IT-Projekte

Grosse IT-Debakel verursachen naturgemäss erhebliches Aufsehen, insbesondere wenn der immense Schaden wie beim Projekt INSIEME vom Steuerzahler zu tragen ist. Auch der Abbruch des Projektes YOU der Zürcher Bank Vontobel mit aufgelaufenen Kosten von rund 250 Mio. Franken (Brenner, 2001) hat es in die Spalten vieler Zeitungen geschafft. Dasselbe gilt auch für das Projekt Magellan der Six-Gruppe, welches mit einem hohen zweistelligen Millionen-Fehlbetrag als "Schiffbruch" bezeichnet wird (Hässig, 2013). Damit sind nur drei Projekte namentlich genannt, während die Liste der Projekt-Flops bei grossen Schweizer Finanzinstituten - trotz weniger Publizität – erheblich länger ist. Zu nennen wären da beispielsweise das europaweite Migrationsprojekt einer Grossbank, das von den ersten Honoraren für teure Strategieberater bis zum Projektabbruch eine mittlere dreistellige Millionensumme gekostet hat, oder die gescheiterte Beschaffung einer neuen Kernversicherungs-Lösung der Bâloise-Versicherung (Hugenschmidt, 2013). Aktuelle Beispiele gefährdeter IT-Grossprojekte betreffen das Zürcher Gesundheitswesen (Hudec, 2022) und die Credit Suisse (Hässig, 2022).

"Der Erfolg hat viele Väter, der Misserfolg ist ein Waisenkind." (Cobden, o. J.)

B. CHAOS10 Report der Standish Group

Die renommierte US-Research- und Beratungsfirma The Standish Group hat seit 1994 mehr als 40'000 Projekte untersucht und veröffentlicht jährlich eine Studie (CHAOS Report) über erfolgreiche, herausgeforderte (challenged) und gescheiterte IT-Projekte (https://www.standishgroup.com/).

"Die untersuchten Projekte wurden in drei Gruppen aufgeteilt:

• Typ 1 – Projekt erfolgreich abgeschlossen: Das Projekt wurde rechtzeitig, ohne Kostenüberschreitung und mit dem ursprünglich geforderten Funktionsumfang abgeschlossen.

• Typ 2 – Projekt teilweise erfolgreich: Das Projekt wurde abgeschlossen, es kam jedoch zu Kosten- und/oder Zeitüberschreitungen oder es wurde nicht der vollständige geplante Funktionsumfang erreicht.

• Typ 3 – Projekt nicht erfolgreich: Das Projekt wurde abgebrochen." (Dietrich, 2021)

Demnach gelten beispielsweise im Jahr 2015 insgesamt 71 Prozent als entweder gescheitert oder herausgefordert.

Abbildung 3: Standish Group CHAOS Report

1. Erfolgsfaktoren

Aus meiner eigenen Praxiserfahrung kann ich die drei Haupterfolgsfaktoren der CHAOS Studie zu 100 Prozent bestätigen:

1. "Einbindung der Endbenutzer

2. Unterstützung durch das obere Management

3. Klare Anforderungen" (ebd.)

2. Misserfolgsfaktoren und Abbruchgründe

Im CHAOS Report für 2020 sind auch die drei hauptsächlichen Misserfolgsfaktoren von IT-Projekten aufgeführt:

1. "Fehlende Zuarbeit durch Benutzer

2. Unvollständige/unklare Anforderungen

3. Häufige Anforderungsänderungen" (ebd.)

Bei den Misserfolgsfaktoren sehe ich auf Platz 1 hingegen andere Ursachen als der Standish Group Report. Mag sein, dass die Benutzer dem Projekt nicht ausreichend zuarbeiten. Die Ursache dafür sehe ich allerdings nicht bei den Benutzern, sondern eher beim Projektleiter. Wenn es gelingt, die Anwender zweckdienlich in die Projektorganisation einzubinden, werden sie erfahrungsgemäss am Projekterfolg interessiert sein und motiviert ihren Beitrag dazu leisten.

Die folgenden Top-Ten-Gründe für gescheiterte Projekte wurden im CHAOS Report 2019 genannt:

1. Unvollständige Anforderungen (Incomplete Requirements)

2. Mangelnde Benutzerbeteiligung (Lack of user involvement)

3. Zu wenig Ressourcen (Lack of resources)

4. Unrealistische Erwartungen (Unrealistic expectations)

5. Mangelnde Management-Unterstützung (Lack of executive support)

6. Veränderte Anforderungen & Spezifikationen (Changing Requirements & Specifications)

7. Ungenügende Planung (Lack of planning)

8. Projekt nicht mehr benötigt (Didn’t need it any longer)

9. Mangelndes IT-Management (Lack of IT management)

10. Mangelndes technisches Fachwissen (Technical illiteracy) (vgl. The Standish Group, 2019)

Mit den meisten der im Standish CHAOS Report genannten Abbruchsgründen stimme ich – wenn auch nicht unbedingt in dieser Reihenfolge – überein. Bei einigen der genannten Punkte (u.a. zu wenig Ressourcen, ungenügende Planung) sehe ich die eigentliche Ursache beim mangelhaften Projektmanagement.

C. Interne und externe Problemursachen

Unabhängig vom Standish CHAOS Report habe ich aufgrund selbst beobachteter Praxisbeispiele nach den tieferen Ursachen typischer Projektprobleme gesucht und dazu in den nachstehenden Kapiteln jeweils auch mögliche Verbesserungsansätze beschrieben. Die Probleme und Ursachen lassen sich auf zwei Ebenen lokalisieren:

1. Projektinterne Faktoren

- Operative Führung durch den Projektleiter (Fach- und Mitarbeiterführung, persönliches Verhalten, Projektorganisation, Handwerk und Selbstorganisation usw.),

- Ungeeignete Governance (Projektausschuss, Auftraggeber, Linienführung).

2. Umfeldfaktoren

- Unklare Verantwortlichkeiten bei den Stakeholdern (Audit, Stäbe, Procurement, Produktmanagement, IT- und Business-Architektur, externe Beratungsfirmen)

- Unternehmens- und Projektkultur (Loyalität, Kontrolle, Sankt-Florian-Prinzip11)

- Managementwechsel (z.B. Philosophie-Änderung von Zentralisierung zu Dezentralisierung)

- Rahmenbedingungen und äussere Einflussfaktoren (Methodikvorgaben, Projektkomplexität).

D. Die Folgen des Scheiterns

INSIEME mag als Beispiel dafür dienen, dass manchmal auch ein Wechsel im obersten Management den Ausschlag dafür geben kann, dass ein in Schieflage geratenes Software-Entwicklungsprojekt vorzeitig abgebrochen wird. Die Folgen gescheiterter Projekte sind vielfältig und gehen über den vordergründig sichtbaren, finanziellen Schaden hinaus:

a) "Zurück zum Start": ein Projektabbruch bedeutet, dass wieder von vorne begonnen werden muss, was wiederum heisst,

o dass die geschätzten Kosten für das Nachfolgeprojekt nochmals aufzuwenden sind und

o dass die Benutzer sich weiter gedulden, das heisst, mit dem alten System weiterarbeiten müssen;

b) Es ist keineswegs sichergestellt, dass der Neuanlauf erfolgsträchtiger ist als das soeben abgebrochene Projekt;

c) Abgesehen vom finanziellen Verlust besteht auch die Gefahr eines Reputationsschadens;

d) Ein nicht zu unterschätzendes Risiko ist ausserdem, dass bewährte, aber vom Misserfolg enttäuschte Projektmitarbeitende das Unternehmen verlassen und empfindliche Lücken hinterlassen.

10 Comprehensive Human Appraisal for Originating Software

11 "[…] bezeichnet Verhaltensweisen, potenzielle Bedrohungen oder Gefahrenlagen nicht zu lösen, sondern auf andere zu verschieben." (Wikipedia, 2021)

III. Der Erfolg steht und fällt mit der Projektleitung

Der Projektleiter steht im Zentrum des Geschehens. Er muss versuchen, ein Gleichgewicht zu finden zwischen den in Abbildung 4 dargestellten Anforderungsdimensionen:

Abbildung 4: Die Essenz der Projektleitung

1.Persönliche Einstellung und Verhalten: Im Zentrum der Anforderungen an einen Projektleiter stehen seine Grundeinstellung zu Menschen und Herausforderungen sowie – davon abgeleitet – sein persönliches Verhalten im Umgang mit Mitarbeitenden, Vorgesetzten und Stakeholdern.

2.Führung der Projektmitarbeitenden: Die Leistung der Projektleiterin wird am Erfolg ihres Projektes gemessen und damit letztlich an der Leistung des Teams. Jede Projektleiterin ist daher gut beraten, Mitarbeitende nach dem "the best and the brightest"-Ansatz (vgl. Halberstam, 1993) zu rekrutieren, diese vertrauensvoll, wertschätzend und vor allem individuell zu führen. Umgekehrt darf sie aber auch nicht davor zurückschrecken, sich von Minderleistern zu trennen.

3.Projektleitungs-Handwerk: Es versteht sich von selbst, dass ein Projektleiter sein Handwerk beherrschen muss, insbesondere im Hinblick auf Planung, Koordination, Entscheidungsfindung und Kommunikation gegenüber den Anspruchsgruppen.

4.Fachliche Führung: In diesem Bereich gilt es, eine Projektleitung weder als "inhaltsbefreiter Excel-Überflieger" noch als detailversessener Control Freak wahrzunehmen, sondern sich nur dann auf tiefe Detailebenen zu begeben, wenn es zeitlich – beispielsweise im Krisenfall – oder für eine folgenschwere Fachentscheidung notwendig ist.

5.Führung nach "oben": Jede Projektleiterin muss gegenüber ihren Linien- und Projektvorgesetzten sowie dem Projektausschuss transparent kommunizieren; sie darf dabei weder beschönigen noch dramatisieren, vor allem aber darf sie sich nicht scheuen, Hilfestellung einzufordern, bevor ihr die Probleme über den Kopf wachsen.

A. Projektleitung bei INSIEME

Im INSIEME-Untersuchungsbericht werden die Führungsdefizite des Gesamtprojektleiters nur in allgemeiner Form als mangelnde "Fach-, Führungs- und Methodenkompetenzen" (AGI, 2014:6472) dargestellt, ohne jedoch im Einzelnen darauf einzugehen oder Beispiele zu nennen. Insbesondere wird im Untersuchungsbericht zwar auf ungenügende Planung, Kommunikation und Dokumentation eingegangen, es fehlen aber konkrete Beispiele zu weiteren Dimensionen der Disziplin "Projektleitung", insbesondere zu:

- Einstellung und Verhalten,

- Mitarbeiterführung,

- Projektorganisation,

- Handwerk und Selbstorganisation,

- Koordination.

Als einziger, relativ konkreter Hinweis wird vom Bundesrat in seinem eigenen Bericht festgestellt, dass sich "infolge mangelhafter Führung" isolierte Teilbereiche innerhalb des Projekts bildeten, "[…] in denen man unkoordiniert agierte". (AGI, 2014:6430)

Der ESTV-interne Gesamtprojektleiter (GPL) trug die "Gesamtverantwortung für INSIEME und war für die Projektergebnisse (Planung, Organisation, Führung und Überwachung) verantwortlich. […] Nach Ansicht des Bundesrates verfügte der GPL offensichtlich nicht über die erforderlichen Projektmanagement- und Managementkompetenzen". Ausserdem "fehlte dem GPL der Überblick über das Projekt". (AGI, 2014:6429)

Auch innerhalb der ESTV und vonseiten des Bundesamtes für Informatik und Telekommunikation (BIT) sowie von Departementsseite wurden die Fähigkeiten des Gesamtprojektleiters wiederholt angezweifelt (vgl. AGI, 2014:6507).

Die externe Beratungsfirma Accenture überprüfte ebenfalls das Projekt-Setup sowie verschiedene Elemente des Projektmanagements und "[…] kam zum Schluss, dass keine realistische Planung und keine vollständige Kostenschätzung vorlagen und Anpassungen an der Organisationsstruktur notwendig waren". (AGI, 2014:6420)

"Auch aus Sicht des Bundesrats ist es rückblickend offensichtlich, dass der GPL (2007–2011) für die Führung von INSIEME nicht geeignet war." (AGI, 2014:6385)

Selbst die vom Gesamtprojektleiter getroffene Wahl der Auditfirma erschien dem Bundesrat rückwirkend als "[…] fragwürdig, da diese nicht auf Projektaudits spezialisiert war". (AGI, 2014:6430)

"Der […] am längsten eingesetzte GPL (3½ Jahre) war lediglich formell GPL, konnte er doch seine Aufgaben, Verantwortungen und Kompetenzen kaum wahrnehmen. Mangels Fach-, Führungs- und Methodenkompetenzen war er permanent auf das Coaching, die Beratung und die Unterstützung externer Experten angewiesen." (AGI, 2014:6472)

Im März 2011 wurde auf Antrag des Vorsitzenden des Gesamtprojektausschusses der als ungenügend qualifizierte Gesamtprojektleiter wegen neuerlichen Termin- und Kostenüberschreitungen, des geringen realisierten Umfangs von INSIEME sowie der nicht wie geplant umgesetzten Audit-Massnahmen abgelöst und die Leitung von INSIEME ab Oktober 2011 einem neuen GPL übergeben (vgl. AGI, 2014:6430; 6433).

B. Aufgaben, Verantwortung und Kompetenzen

1. Aufgaben

Die wichtigsten Aufgaben einer Projektleiterin sind in Abbildung 5 schematisch dargestellt:

Abbildung 5: Wichtigste Aufgaben der Projektleiterin

Die vielfältigen Aufgaben einer Projektleiterin lassen sich in vier Gruppen zusammenfassen:

1) Führen und fördern der Projektmitarbeitenden heisst, ihnen

- das Ziel und den Rahmen vorzugeben,

- dabei aber auch das nötige Vertrauen zu schenken, um den besten Weg zur Zielerreichung selbst zu finden,

- die gröbsten Steine aus dem Weg zu räumen;

2) Gestaltung, Durchsetzung und Unterhalt einer funktionierenden Projektorganisation bedeutet in erster Linie, tragfähige Strukturen zu bilden. Diese sollen sicherstellen, dass

- Beschlüsse rasch und fundiert getroffen werden können,

- keine Missverständnisse über Verantwortlichkeiten entstehen und

- weniger Friktionen im Projektablauf entstehen.

3) Planung und Koordination der Aktivitäten, Kosten und Meilensteine sowie deren aktive und enge Überwachung gehören zu den Hauptaufgaben der Projektleiterin, weil

- nachfolgende Aktivitäten und am Ende der Projekterfolg davon abhängen,

- sie ihre Planung stets im Hinterkopf behalten und dem Rest des Teams planerisch und gedanklich ein paar Schritte voraus sein muss,

- weil sie mögliche Hindernisse antizipieren und sich frühzeitig die Möglichkeiten zu deren Überwindung überlegen muss.

4) Ein qualitativ hochstehendes Reporting für den Projektausschuss und die übrigen Stakeholder gehört zu den Hauptaufgaben der Projektleitung, weil verlässliche und überzeugende Kommunikation für Transparenz sorgt und Vertrauen schafft.

2. Verantwortung

Der Projektleiter als Leistungserbringer trägt die Umsetzungsverantwortung. Er ist zuständig für die qualitäts-, termin- und kostengerechte Ablieferung der vom Auftraggeber in seiner Rolle als Leistungsbezüger geforderten Systemfunktionalität.

Die wichtigsten Verantwortlichkeiten des Projektleiters umfassen im Wesentlichen die folgenden Punkte:

a) Termingerechte Implementierung der vereinbarten Funktionen,

b) Jederzeit aktuelle Kostenübersicht gemessen am bewilligten Budget,

c) Jederzeitige Auskunftsfähigkeit über den Stand des Projektes, der bereits erreichten und der zukünftigen Meilensteine,

d) Übersicht der bereits gelieferten und noch offenen Lieferobjekte,

e) Konstruktive Zusammenarbeit mit Nachbarprojekten, Stäben und weiteren Stakeholdern,

f) Rechtzeitige Eskalation an vorgesetzte Stellen, falls notwendig.

Die Projektleiterin muss bei ihrer Tätigkeit ausserdem sicherstellen, dass die zu erwartende Sorgfalt gewährleistet ist. Im Schweizer Obligationenrecht ist die Sorgfaltspflicht in Artikel 321a wie folgt umschrieben: "Der Arbeitnehmer hat die ihm übertragene Arbeit sorgfältig auszuführen und die berechtigten Interessen des Arbeitgebers in guten Treuen zu wahren." (OR 321a Ziff. 1)

Oder wie im deutschen BGB (Bürgerliches Gesetzbuch, Verkehrsrecht) umgekehrt formuliert: "Eine Sorgfaltspflichtverletzung liegt dann vor, wenn ein Schaden verursacht wurde, weil die im Verkehr zu erwartende Sorgfalt nicht aufgewendet wurde. Wer diese Sorgfalt verletzt, handelt fahrlässig." (Anwal-tOnline, 2019)

3. Kompetenzen

Weil zur Verantwortung auch Kompetenzen gehören, sei an dieser Stelle auf Dr. Götz Schmidt und sein Buch "Grundlagen der Aufbauorganisation" verwiesen. Dort findet sich eine treffende Beschreibung des Zusammenhanges zwischen Aufgaben, Verantwortung und Kompetenzen:

"Jeder Stelleninhaber muss die Kompetenz (Befugnisse) erhalten, die er benötigt, um die Aufgaben erfüllen zu können. […] Seine Verantwortlichkeit soll nicht weiterreichen als seine Kompetenzen; das heisst, er kann nur für Sachverhalte zur Rechenschaft gezogen werden, die im Rahmen seiner Aufgabe liegen und für die er entsprechende Kompetenzen besitzt – es sei denn, er würde sträflich seine Befugnisse überschreiten." (Schmidt, 1985:47)

Weil Projekte aber ein- und damit erstmalige Vorhaben sind und die Projektleiterin immer wieder auf neuartige Hindernisse stossen wird, halte ich es persönlich eher mit Peter Ueberroth, dem Organisator der XXIII. Olympiade 1984 in Los Angeles. Seine Einstellung zum Thema "Authority" (Befugnisse) brachte er damals mit folgendem Satz zum Ausdruck: "Authority is 20 percent given, 80 percent taken." (Huer, 1991)

C. Persönlichkeit, Einstellung und Verhalten

Für den Projekterfolg steht das Thema "Persönlichkeit12 der Projektleiterin" mit den einstellungs- und verhaltensmässigen Anforderungen im Zentrum. Eine Projektleiterin ist ähnlich einem Orchesterdirigenten die zentrale Figur im Ensemble. Auch ein Dirigent beherrscht in der Regel nicht jedes Instrument im Orchester, aber

- er ist trotzdem für dessen Leistung als Ganzes verantwortlich,

- er führt die Mitarbeiter und

- er vertritt das Vorhaben gegenüber den Vorgesetzten, Sponsoren, Aufsichtsorganen und den übrigen Stakeholdern.

Sowohl der Dirigent als auch die Projektleiterin brauchen einen Plan. Sie müssen genau wissen, von wem im Orchester beziehungsweise Team sie wann welchen Beitrag erwarten und in welcher Qualität dieser zu erbringen ist. Ausserdem brauchen sie beide ein gutes Gehör für Misstöne, sei es musikalisch beim Orchester oder zwischenmenschlich bei sich anbahnenden Konflikten innerhalb des Teams.

1. Persönlichkeit

a) Menschenbilder und Selbstwahrnehmung

Erfolgreiche Mitarbeiterführung hat meiner Meinung nach nur beschränkt mit erlernbarem Handwerk zu tun. Entscheidender sind das Menschenbild, welches jemand in sich trägt, und die Wahrnehmung seiner eigenen Person.

Sieht er sich selbst als Primus inter Pares (Erster unter Gleichen) beziehungsweise gar nur als First Servant (erster Diener) innerhalb des Teams oder fühlt er sich allen anderen überlegen?

Ein "Grossmacher" fördert seine Mitarbeiter auch – aber nicht ausschliesslich – indem er sie fordert. Deshalb sind gute Vorgesetzte loyal, fordern und fördern, hören zu, haben Vertrauen und gewähren Entscheidungsspielraum (vgl. Happich, 2011:15).

Ein "Kleinmacher" hingegen ist im tiefsten Innern unsicher und befürchtet, dass jemand aus dem Team den Job besser machen könnte als er selbst und deshalb auf Distanz gehalten werden muss. Er trägt möglicherweise auch ein Menschenbild in sich, welches Mitarbeiter als Hilfskräfte sieht, die nur mit Druck zu besseren Leistungen "motiviert" werden können. Wer Teammitglieder nur als Produktionsfaktoren sieht, sollte besser nicht Projektleiter werden. Ein "Kleinmacher", der Menschen nicht mag oder nicht wertschätzt, wird nie in der Lage sein, ein Team um sich zu scharen, das für ihn "durchs Feuer geht" und – noch wichtiger – gewillt ist, auch im nächsten Projekt wieder mit ihm zu arbeiten.

Ein Musterexemplar für überhebliche Führung habe ich als Business-Analyst bei einer Auslandsbank erlebt. Als typischer old school-Vertreter pflege ich bei analytischer Arbeit meine Gedanken nicht am Bildschirm zu ordnen, sondern mit Stift und Papier13. Der Programmleiter mit einer – wie Angelsachsen sagen würden – "very german attitude" geht an meinem Arbeitsplatz vorbei und lässt dabei mit breitem Berliner Akzent die Bemerkung fallen: "Ick hör' nix klappern!" Der Output von Mitarbeitenden liess sich in seinen Augen offenbar am Tastaturgeklapper messen.

Ein wichtiges persönliches Ziel der Führungsarbeit eines Projektleiters sollte deshalb sein, dass zumindest die Leistungsträger des Teams auch im nächsten Projekt gerne wieder mit ihm zusammenarbeiten. Ein Führungsansatz auf der Basis "verbrannter Erde" ist langfristig kein erfolgversprechendes Konzept.

b) Mut und Entscheidungsfreude

Wenn sich im Winter ein halbes Dutzend Kinder bäuchlings auf ihre Davoser Schlitten14 legen und mit den Füssen beim jeweiligen Hintermann eingehängt den Hang hinunterbrettern, können kleinste Kursänderungen an der Spitze zu grossen Schwingungen am Ende der Gruppe führen. Damit dasselbe nicht im Projektmanagement passiert, müssen wichtige Entscheidungen sorgfältig vorbereitet, zeitnah im richtigen Gremium diskutiert, klar kommuniziert und rasch umgesetzt werden. Vor allem wenn externe Unternehmen am Projekt beteiligt sind, kann es zu Irritationen und Reibungsverlusten kommen, wenn die Qualität der Entscheidungsprozesse im Projekt zu wünschen übrig lässt.

Führung im Projekt findet "unter dem Brennglas" statt. Vor allem bei grossen Informatikvorhaben können sich falsche Entscheidungen fatal auf Kosten, Termine und den Projekterfolg als Ganzes auswirken. Daher ist es im Projektgeschäft nicht empfehlenswert, sich nur um der Entscheidungsfreude willen überhastet festzulegen. Allzu oft muss der vorschnell getroffene Beschluss später wieder umgestossen werden. Zickzack-Kurse im Projekt verunsichern und verärgern nicht nur die Teammitglieder, sondern auch die Stakeholder. Entscheiden erfordert in erster Linie sorgfältiges Abwägen, Abstimmen mit den Leistungsträgern im Team und manchmal auch ganz einfach den Mut, zu einem einmal getroffenen Beschluss zu stehen.

Vor allem dann, wenn ich allein und nicht als Teil einer Doppelspitze ein Projekt leiten durfte, habe ich die "Einsamkeit des Entscheiders" deutlich gespürt und wie es manchmal erheblichen persönlichen Mut braucht, schwierige (Personal-)Entscheidungen nicht nur zu treffen, sondern auch konsequent umzusetzen.

Franz Steinegger, der erfolgreiche Krisenmanager der Expo.02 brachte einst die Anforderung an persönlichen Mut in drastischen Worten zum Ausdruck: "Irgendwie war mir schon bewusst, dass ich je nach dem Erfolg der Expo, um es überspitzt zu sagen, ein Denkmal kriegen oder am Laternenpfahl hängen würde." (Bilanz, 2002)

In einem Artikel über den Schweizer Fussballtrainer Gerardo Seoane beschreibt Benjamin Steffen in der NZZ vom 29. April 2022 den notwendigen Mut des Führenden mit folgenden Worten: "Wenn es um Mut geht im Fussball, ist gern von einer mutigen Spielweise die Rede, von Angriff. Seoane aber spricht eher vom Mut dazu, nicht immer alles gleich zu machen. Und vielmehr noch vom Mut, zu den Spielern eine Nähe zu pflegen. […] Mit einem Spieler persönlich zu reden, braucht Mut. […] Du begibst dich in einen Bereich, wo du nicht weisst, was passiert." (Steffen, 2022)

Abbildung 6 zeigt die beiden wichtigen Dimensionen der Entscheidungsqualität: einerseits das Tempo, basierend auf der Entscheidungsfreude, und andererseits die inhaltliche Qualität, basierend auf der Fachkompetenz des Entscheidungsträgers:

Abbildung 6: Dimensionen der Entscheidungsqualität

Im Idealfall ist die Projektleiterin sowohl kompetent als auch entscheidungsfreudig. Das Gegenteil davon ist ein Vorgesetzter, der nicht nur wenig Fachkompetenz mitbringt, sondern auch nicht entscheiden mag. Ist er fachlich hingegen kompetent, mag sich aber nicht zu Entscheiden durchringen, sollte er besser dem Subsidiaritätsprinzip15 folgen und mehr Entscheidungskompetenz an die Mitarbeitenden abtreten.

Auf der anderen Seite ist eine entscheidungsfreudige Projektleiterin mit wenig Fachkompetenz gut beraten, vor möglicherweise überhastet getroffenen Beschlüssen ihre kompetentesten Mitarbeitenden zu Rate zu ziehen.

c) Nähe und Empathie

Ein Projektleiter muss sein Team "lesen" können, auf Stimmung und Umgangston achten, sich anbahnende Störungen antizipieren, notfalls zum Schutz des Projektes aber auch rechtzeitig die Reissleine ziehen und sich von einer Mitarbeiterin trennen können.

Empathie erfordert nicht nur – aber auch – physische Nähe. Ob ein Projektleiter 500 Meter oder 5000 Kilometer von seinem Team entfernt ist, spielt keine entscheidende Rolle. Er wird in beiden Fällen nicht am Puls des Geschehens sein, das heisst, sein Team weder spüren noch ein Gefühl für unterschwellige Konflikte entwickeln können.

Für team-interne, das heisst in der Regel persönliche Konflikte zwischen zwei oder mehr Teammitgliedern muss die Projektleiterin eine Lösung suchen, welche idealerweise alle Beteiligten das Gesicht wahren lässt. Schliesslich sollen beide Parteien im Projektinteresse weiterhin konstruktiv zusammenarbeiten.

In einem meiner Projekte kriegte ich es mit einem Fall von Meuterei zu tun, bei dem die Mitglieder eines Teilprojektes immer offener gegen den Teilprojektleiter aufbegehrten. Lange (oder vielleicht zu lange) glaubte ich, dem Teilprojektleiter gegenüber loyal sein und ihm den Rücken stärken zu müssen. Erschwerend für den Teilprojektleiter kam hinzu, dass er als externer Berater gegenüber seinem internen Hauptwidersacher von Beginn an die schwächere Position innehatte.

Nach zahllosen Konfliktgesprächen mit ihm, seinem Gegenspieler und auch mit dem gesamten Team musste ich irgendwann erkennen, dass meine Loyalitätsposition nicht länger haltbar war. Als der Teilprojektleiter schliesslich zermürbt von endlosen Streitgesprächen in einem Nebensatz andeutete, seine Position zur Verfügung stellen zu können, ergriff ich die Gelegenheit beim Schopf und nahm das Rücktrittsangebot dankbar an. Sein interner Gegner hatte die menschliche Grösse, den Verlierer bei der anschliessenden Teamorientierung das Gesicht wahren zu lassen, indem er ankündete, seinen Ex-Vorgesetzten weiterhin im Team behalten zu wollen. Beide schafften es anschliessend, trotz schlechter Ausgangslage konstruktiv, respektvoll und auch erfolgreich weiter zusammenzuarbeiten.

d) Grosszügigkeit

Nach meiner (aktiven und passiven) Erfahrung wird Grosszügigkeit gegenüber Mitarbeitenden von diesen doppelt und dreifach zurückgezahlt in Form von Einsatz, Leistungswille und Teamgeist. Misstrauen, Knausrigkeit oder Geiz auf der anderen Seite wird vom Team beantwortet mit Dienst nach Vorschrift, durchschnittlicher Leistung und Paragraphenreiterei, beispielsweise beim Arbeitszeitreglement. An solchem Verhalten der Teammitglieder wird jedes Projekt früher oder später scheitern.

In meinem ersten Projekt in Zürich als Junior-Betriebsorganisator bei einer der damals noch fünf Grossbanken traf ich auf einen Abteilungsleiter, der vor allem gegenüber seinen jungen Mitarbeitenden grosses Misstrauen an den Tag legte. Nicht nur prüfte er unsere Spesenabrechnungen auf Franken und Rappen, sondern er bestand auch darauf, jeweils zum Monatsende die Stempeluhren höchstselbst abzulesen und unsere Zeitabrechnungen minuziös zu kontrollieren. Selbst kleinste Abweichungen wurden von ihm moniert, immer durchsetzt mit dem Unterton des Misstrauens einerseits und des "erwischt!"-Triumphes andererseits.

Die Folge war, dass wir jüngeren Mitarbeiter beim Übertölpeln der Stempeluhr riesigen Ehrgeiz entwickelten und richtiggehende Meisterschaften abhielten, sobald unser Chef ausser Haus war. Und auch bei den Spesenabrechnungen waren wir uns selbst gegenüber sehr grosszügig und nutzten auch die winzigste Unklarheit genüsslich aus.

Bei meinem Ortswechsel von Basel nach Zürich hatte derselbe Vorgesetzte auch mein Salär nicht den deutlich höheren Lebenshaltungskosten in Zürich anpassen wollen. Ein erstes Gespräch über eine Angleichung blockte er so vehement und schroff ab, dass man meinen konnte, er müsse die gewünschte (sehr bescheidene) Lohnerhöhung aus eigener Tasche bezahlen.

Beim zweiten Anlauf wartete ich, bis sein eigener Vorgesetzter zu einer Routinebesprechung mit ihm angekündigt war. Drei Minuten vor dem Termin klopfte ich an die Bürotür des Abteilungsleiters, trat ein und erläuterte ihm mein Problem ein zweites Mal. Natürlich lehnte er meinen Wunsch nochmals ab. Genau zu diesem Zeitpunkt betrat sein Chef das Büro, erfasste sofort die angespannte Situation und fragte, worum es gehe. Ich schilderte ihm kurz mein Problem mit den höheren Lebenshaltungskosten in Zürich. Er hörte aufmerksam zu und versprach, sich darum zu kümmern. Bereits am nächsten Tag erhielt ich Bescheid, dass eine "Ortszulage" in der von mir gewünschten Höhe ausgerichtet werde. Mein finanzielles Problem war zwar gelöst, aber vor dem Abteilungsleiter hatte ich jeglichen Respekt verloren.

Das Wichtigste an dieser Episode war, dass sie mich vier Dinge gelehrt hat:

1. Wie wichtig Zuhören ist,

2. Wie wichtig Grosszügigkeit gegenüber Mitarbeitenden ist,

3. Wie wichtig Kreativität bei der Lösung von Problemen ist,

4. Wie wichtig Vertrauen in der Beziehung zu Mitarbeitenden ist.

e) Schutzpatron der Mitarbeiter

Ein Projektleiter ist auch eine Art Schutzpatron. Er sucht sich seine Mitarbeitenden sehr sorgfältig aus und wird sie – sofern Leistung und Verhalten stimmen – über die Probezeit hinaus behalten und ihnen im eigenen Interesse Vertrauen entgegenbringen. Bei Kritik von aussen – vorerst egal, ob berechtigt oder nicht – wird sich der verantwortungsbewusste Projektleiter vor seine Mitarbeiterin stellen, die Kritik auf sich selbst ziehen und anschliessend im Gespräch mit der Mitarbeiterin die richtigen Schlussfolgerungen ziehen.

Eines meiner denkwürdigsten Meetings habe ich gleich zu Beginn meiner Projektlaufbahn in Zürich erleben dürfen. Derselbe Vorgesetzte, der mir die Lohnerhöhung verweigert hatte, traf sich mit einem anderen Abteilungsleiter sowie einigen Mitarbeitern zum regelmässigen Statusmeeting. Während der Sitzung wurde von der Gegenseite Kritik an der Arbeit eines unserer Mitarbeiter geübt. Mein Vorgesetzter versuchte, sich mit der Bemerkung "Ich habe halt leider schlechte Mitarbeiter" herauszureden, worauf sein Gegenüber kühl erwiderte: "Ja, und du bist ihr Chef." Betretenes Schweigen im Raum, weil alle Sitzungsteilnehmer wussten, dass er recht hatte und unser Chef in dieser Sekunde sehr viel Gesicht verloren hatte.

Im späteren Projekt SIENA wurde einer meiner Business-Analysten während eines Business-Trips in Tokio von einem ebenfalls vor Ort weilenden Projektleiterkollegen kritisiert und bei unserem gemeinsamen Chef angeschwärzt. Mein Mitarbeiter hatte offenbar seinem lokalen Ansprechpartner zweimal eine ähnliche Frage gestellt. Bei meinem nächsten Aufenthalt vor Ort bot sich mir während einer grossen Informationsveranstaltung die Gelegenheit, auf die meines Erachtens ungerechtfertigte Kritik zu sprechen zu kommen. Ich erklärte den Anwesenden unsere Vorgehensweise und wie wichtig es für die analytische Arbeit ist, " solange Fragen stellen, bis man verstanden hat." Und dass dies auch in Zukunft so bleiben werde. Damit war das Thema erledigt.

Erst ein paar Jahre ist es her, dass ich bei einem Finanzinstitut miterleben musste, wie es ein Projektleiter zweimal und ohne Widerspruch zuliess, dass einer seiner Teilprojektleiter öffentlich kritisiert wurde. Obwohl klar war, dass die Kritik jeder Grundlage entbehrte, wagte es der Opportunist in Projektleiter-Verkleidung nicht, sich schützend vor seinen Mitarbeiter zu stellen. Auch dieser Vorgesetzte gehörte danach in meine "Nie wieder"-Kategorie.

f) Respekt, Dankbarkeit und Wertschätzung

Ich bin überzeugt, dass eine Projektleiterin ihrem Team eine gewisse Form von Dankbarkeit entgegenbringen soll. Dies im Wissen darum, dass ihre eigene Leistung am Projekterfolg als Ganzes gemessen wird und deshalb nur so gut sein kann wie die Teamleistung insgesamt.

Vor allem soll sie sich davor hüten, den Leistungsmassstab gegenüber sich selbst auch auf die Mitarbeitenden zu übertragen und dadurch allenfalls Frustration und Enttäuschung auf beiden Seiten hervorzurufen. Grundsätzlich soll sie jedem Teammitglied dankbar sein für die Unterstützung. Falls sie über längere Zeit mit der gezeigten Leistung oder dem Verhalten nicht mehr zufrieden ist, soll sie sich darum bemühen, die Ursachen für den Leistungsabfall aufzuspüren. Möglicherweise gibt es Probleme im privaten Bereich, die sich mit ihrer Hilfe mildern lassen. Schlimmstenfalls muss sie im Projektinteresse konsequent sein und sich von diesem Mitarbeiter trennen.

Hansi Flick, der ehemalige Trainer des Fussballklubs Bayern München, hat eine klare Meinung in Bezug auf Führung und Teamarbeit: "Das Entscheidende ist für mich, dass es letztlich nur über den Teamgedanken geht. Ohne Loyalität, Wertschätzung und Respekt füreinander ist es schwer, sich erfolgreich und sinnvoll zu entwickeln." Für ihn sei es wichtig, dass man Vertrauen schenke, viel kommuniziere und sich gegenseitig wertschätze. "Und: Man muss Spass haben an dem, was man macht. Erfolg hat man nur gemeinsam." (Lämmle, 2020)

Mehr gibt es dazu eigentlich nicht zu sagen.

g) Zuverlässigkeit und Diskretion

Zur Zuverlässigkeit gehören typische persönliche Eigenschaften, wie proaktives Handeln, Termintreue, Qualitäts- und Kostenbewusstsein usw. An dieser Stelle sei jedoch nur auf die spezielle, manchmal aber sehr wichtige Anforderung nach Diskretion eingegangen.

Jede Projektleiterin muss über genügend Selbstdisziplin verfügen, um vertraulich erhaltene Informationen ihrer Vorgesetzten oder über Mitarbeiter für sich zu behalten. Nach meinen Erfahrungen ist dies vor allem dann schwierig, wenn nach einem Trennungsgespräch der entlassene Mitarbeiter frei ist, bei Arbeitskollegen seine Version der Geschichte zu verbreiten, ohne dass die Verantwortlichen ihrerseits etwas Vertrauliches aus den Gesprächen erzählen dürfen. Auch wenn es manchmal schwerfällt: Oft bedeutet Diskretion ganz einfach, sich auf die Zunge zu beissen und den Mund zu halten.

2. Einstellung16 und Ausstrahlung

a) Einstellung zu Führung und Verantwortung

Aus meiner Zeit als Fourier17 beim Schweizer Militär bleibt mir ein prägendes Erlebnis dafür in Erinnerung, dass – wenn es an der richtigen Einstellung fehlt – in der Regel nicht nur in einem einzelnen Bereich (Planung, Kosten, Termine usw.) schlecht geführt wird, sondern in vielen, wenn nicht sogar allen Teilbereichen der Führungsarbeit.