IT-Beratung
S-O-S-Methode© für Großprojekte
Kompetenzzentrum Großprojektmanagement (CC GroßPM)
BVA/BIT
Version 2.1
September 2015
Herausgeber
Bundesverwaltungsamt
Ansprechpartner
Herr Thomas Schröder
Kompetenzzentrum Großprojektmanagement
Bundesverwaltungsamt
Stand
September 2015 (generiert am 11.09.15)
Erarbeitung
Das vorliegende Dokument wurde durch die Bundesstelle für Informationstechnik im Bundesverwaltungsamt, IT-Beratung in Zusammenarbeit mit den Firmen McKinsey & Company, Inc., Capgemini Deutschland
GmBH und 4Soft GmbH erstellt.
Autoren
Jörg Magerkurth, Thomas Schröder, Dr. Sebastian Muschter, Silvio Tannert, Bernd Tophoven, Mario Kuhl,
Marc-Ingo Müller
Lizenz/Copyright
Copyright © Bundesverwaltungsamt 2015
Die S-O-S-Methode© darf mit Hinweis auf die Urheberin frei angewendet werden.
Inhaltsverzeichnis
S-O-S-METHODE© FÜR GROSSPROJEKTE
1 Zusammenfassung.....................................................................................................................................10
2 Einleitung...................................................................................................................................................11
2.1 Weiterentwicklung und Abgrenzung der S-O-S-Methode©.................................................................11
2.2 Aufbau und Zweck des Dokuments.....................................................................................................11
2.3 Zielgruppen des Dokuments................................................................................................................15
2.4 Lesehilfe: Schnelleinstieg ins Methodenhandbuch..............................................................................15
2.4.1 Einstieg in die Methode je nach Unterstützungsbedarf................................................................15
2.4.2 Einstieg in die Methode für den V-Modell-Experten...................................................................16
2.5 Endnoten..............................................................................................................................................17
3 Kriterien von Großprojekten....................................................................................................................18
3.1 Definition von Zielprojekten nach Größe............................................................................................18
3.2 Definition von Zielprojekten nach Inhalt.............................................................................................20
3.3 Definition von Zielprojekten nach Lebenszyklusphasen......................................................................21
3.4 Anforderungen an einzelne Projektmanagement-Disziplinen..............................................................22
3.5 Endnoten..............................................................................................................................................24
4 Erfolgsvoraussetzungen von IT-Großprojekten in der öffentlichen Verwaltung..................................25
4.1 Besonderheiten von Großprojekten in der öffentlichen Verwaltung.....................................................25
4.1.1 Was unterscheidet Großprojekte generell von anderen, kleineren Projekten und welche
Konsequenzen ergeben sich daraus für das Projektmanagement?.........................................................25
4.1.2 Welche zusätzlichen Herausforderungen gelten für Großprojekte in der öffentlichen Verwaltung
und welche Konsequenzen ergeben sich daraus für das Projektmanagement?......................................27
4.2 Faktoren des Projekterfolgs.................................................................................................................28
4.3 Statusprüfung der Erfolgsfaktoren.......................................................................................................31
4.4 Endnoten..............................................................................................................................................32
5 Disziplinen zum Management der strategischen Ausrichtung...............................................................34
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen....................................................................34
5.1.1 Ziele: Was soll bei der Festlegung der Rahmenbedingungen erreicht werden?............................34
5.1.2 Rollen: Wer macht was bei der Festlegung der Rahmenbedingungen?........................................39
5.1.3 Ergebnisse: Welche Dokumente sollen erstellt werden?..............................................................39
5.1.4 Prozesse: Wie lassen sich die Rahmenbedingungen festlegen und prüfen?.................................44
5.1.5 Erfolgsmessgrößen: Woran kann der Auftraggeber hinreichend gut definierte
Rahmenbedingungen erkennen?...........................................................................................................54
5.1.6 Grundlegende und weiterführende Literatur................................................................................54
5.2 Vergabe- und Vertragsmanagement......................................................................................................54
5.2.1 Ziele und Rahmenbedingungen: Was soll im Vergabe- und Vertragsmanagement erreicht werden?
..............................................................................................................................................................54
5.2.2 Rollen und Gremien: Wer macht was im Vergabe- und Vertragsmanagement?............................55
5.2.3 Ergebnisse: Welche Ergebnisse sollen erstellt werden?...............................................................56
5.2.4 Prozesse: Wie geht das Vergabe- und Vertragsmanagement vor?.................................................56
5.2.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Vergabe- und Vertragsmanagement
erkennen?.............................................................................................................................................64
5.2.6 Grundlegende und weiterführende Literatur................................................................................64
5.3 Endnoten..............................................................................................................................................64
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter............................66
6.1 Festlegung/Überprüfung der Projektorganisation................................................................................66
6.1.1 Ziele und Rahmenbedingungen: Was soll mit der Projektorganisation erreicht werden?.............68
6.1.2 Rollen: Wer macht was bei der Festlegung der Projektorganisation?...........................................68
6.1.3 Ergebnisse: Welche Dokumente sollen erstellt werden?..............................................................69
6.1.4 Prozesse: Wie wird die Projektorganisation festgelegt/überprüft?...............................................69
6.1.5 Erfolgsmessgrößen: Woran kann der Auftraggeber eine gute Projektorganisation erkennen?......77
6.1.6 Grundlegende und weiterführende Literatur................................................................................77
6.2 Personalmanagement...........................................................................................................................78
6.2.1 Ziele: Was soll das Personalmanagement erreichen?...................................................................78
6.2.2 Rollen: Wer macht was im Personalmanagement?.......................................................................78
6.2.3 Ergebnisse: Welche Dokumente sollen erstellt werden?..............................................................79
6.2.4 Prozesse: Wie geht das Personalmanagement vor, womit beschäftigt es sich inhaltlich?.............79
6.2.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Personalmanagement erkennen?...85
6.2.6 Grundlegende und weiterführende Literatur................................................................................85
6.3 Kommunikationsmanagement.............................................................................................................86
6.3.1 Ziele und Rahmenbedingungen: Was soll mit der Projektkommunikation erreicht werden?.......86
6.3.2 Rollen: Wer macht was in der Projektkommunikation?...............................................................87
6.3.3 Ergebnisse: Welche Dokumente sollen erstellt werden?..............................................................88
6.3.4 Prozesse: Wie geht das Kommunikationsmanagement vor?........................................................88
6.3.5 Erfolgsmessgrößen: Woran kann der Auftraggeber eine gute Projektkommunikation erkennen? 96
6.3.6 Grundlegende und weiterführende Literatur................................................................................97
6.4 Veränderungsmanagement...................................................................................................................97
6.4.1 Ziele und Rahmenbedingungen: Was soll mit dem Veränderungsmanagement erreicht werden? 97
6.4.2 Rollen: Wer macht was im Veränderungsmanagement?.............................................................101
6.4.3 Ergebnisse: Welche Dokumente sollen erstellt werden?............................................................102
6.4.4 Prozesse: Wie geht das Veränderungsmanagement vor?............................................................102
6.4.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Veränderungsmanagement
erkennen?............................................................................................................................................112
6.4.6 Grundlegende und weiterführende Literatur..............................................................................112
6.5 Endnoten............................................................................................................................................113
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen....................................................................114
7.1 Projektplanung...................................................................................................................................114
7.1.1 Ziele und Rahmenbedingungen: Was soll mit der Projektplanung erreicht werden?..................114
7.1.2 Rollen: Wer macht was in der Projektplanung?..........................................................................115
7.1.3 Ergebnisse: Welche Dokumente sollen erstellt werden?............................................................116
7.1.4 Prozesse: Wie wird bei der Projektplanung vorgegangen?.........................................................118
7.1.5 Erfolgsmessgrößen: Woran kann der Auftraggeber eine gute Projektplanung erkennen?..........133
7.1.6 Grundlegende und weiterführende Literatur..............................................................................134
7.2 Anforderungs- und Änderungsmanagement.......................................................................................134
7.2.1 Ziele: Was soll mit dem Anforderungs- und Änderungsmanagement erreicht werden?.............134
7.2.2 Rollen und Gremien: Wer macht was im Anforderungs- und Änderungsmanagement?.............135
7.2.3 Ergebnisse: Welche Dokumente sollen erstellt werden?............................................................136
7.2.4 Prozesse: Wie geht das Anforderungs- und Änderungsmanagement vor?..................................137
7.2.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Anforderungs- und
Änderungsmanagement erkennen?.....................................................................................................145
7.2.6 Grundlegende und weiterführende Literatur..............................................................................145
7.3 Qualitätsmanagement........................................................................................................................145
7.3.1 Ziele und Rahmenbedingungen: Was soll mit dem Qualitätsmanagement erreicht werden?......146
7.3.2 Rollen und Gremien: Wer macht was im Qualitätsmanagement?..............................................146
7.3.3 Ergebnisse: Welche Dokumente sollen erstellt werden?............................................................147
7.3.4 Prozesse: Wie geht das Qualitätsmanagement vor?...................................................................147
7.3.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Qualitätsmanagement erkennen? 151
7.3.6 Grundlegende und weiterführende Literatur..............................................................................151
7.4 Risikomanagement............................................................................................................................151
7.4.1 Ziele und Rahmenbedingungen: Was soll mit dem Risikomanagement erreicht werden?..........151
7.4.2 Rollen und Gremien: Wer macht was im Risikomanagement?..................................................152
7.4.3 Ergebnisse: Welche Dokumente sollen erstellt werden?............................................................154
7.4.4 Prozesse: Wie geht das Risikomanagement vor?.......................................................................156
7.4.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Risikomanagement erkennen?....160
7.4.6 Grundlegende und weiterführende Literatur..............................................................................161
7.5 Endnoten............................................................................................................................................161
8 Erweiterung der Managementdisziplinen..............................................................................................162
8.1 Programmmanagement......................................................................................................................162
8.1.1 Ziele und Rahmenbedingungen: Welche Funktion hat das Programmmanagement?.................162
8.1.2 Rollen: Wer macht was im Programmmanagement?..................................................................165
8.1.3 Ergebnisse: Welche Dokumente sollen erstellt werden?............................................................167
8.1.4 Prozesse: Wie geht das Programmmanagement vor?.................................................................168
8.1.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Programmmanagement erkennen?
............................................................................................................................................................172
8.1.6 Grundlegende und weiterführende Literatur..............................................................................173
9 Projektmanagement-Standards..............................................................................................................174
9.1 Standards...........................................................................................................................................174
9.1.1 Project Management Institute: PMBOK® Guide.......................................................................174
9.1.2 UK Government: Prince2..........................................................................................................175
9.1.3 IPMA/GPM: ICB.......................................................................................................................176
9.1.4 V-Modell XT / V-Modell XT Bund............................................................................................176
9.1.5 ISO / DIN Normenreihe 69901..................................................................................................181
9.2 Sonstige Publikationen und Analysen zum Thema Projektmanagement............................................181
9.2.1 Praxisleitfaden Projektmanagement für die öffentliche Verwaltung..........................................181
9.2.2 Standish Group Chaos 1............................................................................................................181
9.3 Problemspezifische Projektmanagement- und Vorgehensmodelle.....................................................183
10 Abgrenzung und Ausblick.....................................................................................................................184
10.1 Abgrenzung: weitere im Projektmanagement relevante Themenfelder............................................184
11 Anhang....................................................................................................................................................185
11.1 Weitere Klassifizierungen für IT-Projekte........................................................................................185
11.1.1 Projektauslöser.........................................................................................................................185
11.1.2 Vertragsgestaltung....................................................................................................................185
11.1.3 Abrechnungsmodus..................................................................................................................186
11.1.4 Projektstandorte.......................................................................................................................186
11.1.5 Auftraggeber-Auftragnehmer-Konstellation.............................................................................186
11.1.6 Beteiligte Organisationseinheiten.............................................................................................186
11.1.7 Teamzusammensetzung............................................................................................................187
11.1.8 Kritikalität des zu erstellenden Ergebnisses.............................................................................187
11.2 Informationssicherheit in Großprojekten.........................................................................................187
11.2.1 Analyse des Sicherheitsbedarfs................................................................................................188
11.2.2 Ermittlung der Auswirkungen des Sicherheitsbedarfs auf das Projekt.....................................189
11.2.3 Realisierung der Maßnahmen..................................................................................................190
11.2.4 Kontrolle der Maßnahmen.......................................................................................................191
11.2.5 Anpassung der Planung............................................................................................................192
11.3 Training und Ausbildung für Projektleiter für Großprojekte............................................................192
11.3.1 Anforderungen an einen Projektleiter für Großprojekte...........................................................192
11.3.2 Methodenkompetenz Projektmanagement...............................................................................193
11.3.3 Kommunikation.......................................................................................................................194
11.3.4 Grundlegende und weiterführende Literatur............................................................................194
11.4 Ausführliche Liste aller Vorlagen und Checklisten..........................................................................194
11.5 Glossar.............................................................................................................................................195
11.6 Abkürzungsverzeichnis....................................................................................................................199
11.7 Weiterführende Literatur..................................................................................................................199
11.8 Endnoten..........................................................................................................................................200
Abbildungsverzeichnis
Abbildung 1: S-O-S-Methode© für das GroßPM...........................................................................................10
Abbildung 2: Voraussetzung ist Basis-Projektmanagement (z.B. PMI, Prince)..............................................11
Abbildung 3: Struktur des Dokuments............................................................................................................12
Abbildung 4: Unterstruktur in den Kapiteln zur Beschreibung der Disziplinen des Projektmanagements .....13
Abbildung 5: Durch das notwendige Management von Komplexitätstreibern führt erhöhte Komplexität zu
einem erhöhten Aufwand im Projekt..............................................................................................................19
Abbildung 6: Projektmanagement-Charakteristika nach Projektgröße...........................................................19
Abbildung 7: CC GroßPM unterstützt alle Arten von (komplexen) IT-Projekten...........................................21
Abbildung 8: Im Lebenszyklus des Projekts unterstützt das GroßPM von der Projektanbahnung bis zum
Ende der Umsetzung.......................................................................................................................................22
Abbildung 9: Das CC GroßPM ist fokussiert auf große, komplexe Projekte sowie Projekte mit besonderen
Anforderungen an das Projektmanagement ...................................................................................................23
Abbildung 10: Die 13 Erfolgsfaktoren der S-O-S-Methode© zum GroßPM (wiederholt von Abbildung 1). .25
Abbildung 11: Welche Disziplinen des Projektmanagements wirken hauptsächlich auf welche
Erfolgsfaktoren? ............................................................................................................................................30
Abbildung 12: Einschätzung des Projektstatus...............................................................................................31
Abbildung 13: Disziplinen des Projektmanagements mit Fokus auf dem „Management der strategischen
Ausrichtung"...................................................................................................................................................34
Abbildung 14: Ergebnisdokumente der Projektrahmenbedingungen im zeitlichen Ablauf.............................35
Abbildung 15: Sicherstellen der nötigen organisatorischen Reife...................................................................35
Abbildung 16: Zentrale Fragen des Vorprojekts.............................................................................................37
Abbildung 17: Der Zusammenhang zwischen Motivation, Zielen und Nutzen...............................................38
Abbildung 18: Beispiel Projektmotivationen für eine Eigenentwicklung.......................................................42
Abbildung 19: Beispiel für Projektgrundsätze einer Eigenentwicklung..........................................................42
Abbildung 20: Elemente der Projektcharta.....................................................................................................43
Abbildung 21: Prozesse zum Management der Rahmenbedingungen.............................................................44
Abbildung 22: Entscheidungsvorlage über die Weiterführung eines Vorprojekts ..........................................44
Abbildung 23: Detailvorgehen im Stakeholdermanagement...........................................................................46
Abbildung 24: Ziel und Nutzen in der öffentlichen Verwaltung.....................................................................48
Abbildung 25: Frühzeitig Erfolgsvoraussetzungen für das Projekt schaffen...................................................49
Abbildung 26: Berechnungsmodell des Value at Risk....................................................................................50
Abbildung 27: Visuelles Nutzenmanagement.................................................................................................51
Abbildung 28: Prozesse im Vergabe- und Vertragsmanagement.....................................................................57
Abbildung 29: Beziehungswandel: Vom Lieferantenmanagement zur partnerschaftlichen Zusammenarbeit 58
Abbildung 30: Rollen und Prozesse bei einer Generalunternehmer-Konstellation.........................................59
Abbildung 31: Hierarchie der Vergabeverfahrensarten in der öffentlichen Verwaltung .................................60
Abbildung 32: Mindestfristen (in Kalendertagen) bei Vergaben im Oberschwellenbereich – nicht offenes
Verfahren und Verhandlungsverfahren (EN-508)............................................................................................61
Abbildung 33: Disziplinen des Projektmanagements mit Fokus auf dem „Management des organisatorischen
Umfelds".........................................................................................................................................................66
Abbildung 34: Mögliche Varianten für die Beziehung zwischen Projektauftraggeber, internem
Auftragnehmer und externen Auftragnehmern................................................................................................67
Abbildung 35: Prozesse bei der Festlegung und Überprüfung der Projektorganisation..................................70
Abbildung 36: Großprojektorganisation (beispielhaft mit 3 Führungsebenen)...............................................71
Abbildung 37: Prozesse des Personalmanagements........................................................................................80
Abbildung 38: Talente des Gesamtprojektleiters für Großprojekte in der öffentlichen Verwaltung................81
Abbildung 39: Ziele des Kommunikationsmanagements ...............................................................................87
Abbildung 40: Prozesse im Kommunikationsmanagement.............................................................................88
Abbildung 41: Kommunikation als koordinierter Prozess .............................................................................89
Abbildung 42: Beispiel einer Kommunikations-Charta .................................................................................90
Abbildung 43: Priorisieren der Stakeholder/Zielgruppen...............................................................................91
Abbildung 44: Zielsetzungen der Kommunikation ........................................................................................92
Abbildung 45: Elemente des Großprojekt-Berichtswesens.............................................................................95
Abbildung 46: Beispiel für einen Bericht zum Gesamtprojektstatus...............................................................96
Abbildung 47: Die vier Disziplinen des Veränderungsmanagements..............................................................98
Abbildung 48: Zielgruppenrelevanz der Veränderungsmanagementdisziplinen............................................100
Abbildung 49: Das Veränderungsmanagement greift je nach Zielgruppe zu unterschiedlichen Projektphase
...................................................................................................................................................................... 100
Abbildung 50: Prozesse des Veränderungsmanagements..............................................................................103
Abbildung 51: Beispiel einer Schulungsbedarfsmatrix.................................................................................110
Abbildung 52: Beispielhafte Schulungsplanung...........................................................................................111
Abbildung 53: Disziplinen im Projektmanagement mit Fokus auf dem „Management der
Systemunterstützung, der Instrumente und Werkzeuge"...............................................................................114
Abbildung 54: Beispiel eines groben Projektplans .......................................................................................117
Abbildung 55: Prozesse der Projektplanung.................................................................................................118
Abbildung 56: Planungscontrolling durch Vorgaben und Commitment .......................................................120
Abbildung 57: 3 + 9 Schritte zur Abschätzung der Projektkosten einer ERP-Standard-Implementierung....122
Abbildung 58: Beispiel Checkliste/Vorlage zur Aufwandsschätzung einer Individualsoftware-Entwicklung
...................................................................................................................................................................... 123
Abbildung 59: Beispiel einer Projektbudgetübersicht ..................................................................................123
Abbildung 60: Konkretisierung der Anforderungen im Verlauf des Projekts................................................126
Abbildung 61: Beispielbericht zum Fertigstellungsgrad zu erstellender Projektergebnisse..........................131
Abbildung 62: Prozesse des Anforderungs- und Änderungsmanagements...................................................137
Abbildung 63: Beispiel für ein CR-Verfahren mit integriertem Analyseauftrag ...........................................138
Abbildung 64: Anforderungs- und Änderungsmanagement in der öffentlichen Verwaltung ........................141
Abbildung 65: Prozesse des Qualitätsmanagements.....................................................................................147
Abbildung 66: Risikomanagement als „Radar“ der Projektleitung...............................................................152
Abbildung 67: Risikoliste.............................................................................................................................155
Abbildung 68: Risikomatrix.........................................................................................................................155
Abbildung 69: Prozesse des Risikomanagements.........................................................................................156
Abbildung 70: Aufgabenfelder des Programmmanagements........................................................................163
Abbildung 71: Kompetenzverteilung zwischen Programmmanagement und Einzelprojektleitung...............167
Abbildung 72: Prozesse des Programmmanagements ..................................................................................168
Abbildung 73: Standish Group – Softwareprojekt-Erfolgsstatistik 1994 bis 2005........................................182
Abbildung 74: Erfolgsfaktoren bei Softwareprojekten (Chaos 10)...............................................................182
Abbildung 75: Berücksichtigung Informationssicherheit in Großprojekten (Phasen)...................................188
Abbildung 76: Vollständige Liste an Dokumenten und Vorlagen..................................................................195
10
1 Zusammenfassung
1 Zusammenfassung
Das vorliegende Dokument beschreibt das Standardvorgehen beim Projektmanagement von IT-Großprojekten in der öffentlichen Verwaltung. Grundlage ist die für die Bundesverwaltung entwickelte S-O-SMethode© für das Großprojektmanagement (GroßPM). Sie setzt grundsätzlich die Anwendung eines
marktüblichen Projektmanagement-Modells voraus. Schwerpunkte sind dementsprechend die Themen, die
über das normale Projektmanagement hinausgehen und für das GroßPM von Bedeutung sind.
Die S-O-S-Methode© definiert 13 Erfolgsfaktoren für Großprojekte in drei Kategorien: "Strategische Ausrichtung“, "Organisatorisches Umfeld und Projektmitarbeiter“ sowie "System- und Methodenunterstützung“:
Abbildung 1: S-O-S-Methode© für das GroßPM
Auf diese Erfolgsfaktoren kann die Projektleitung mit Hilfe von zehn – in diesem Dokument beschriebenen –
Projektmanagement-Disziplinen einwirken. Die Disziplinen reichen von Standards wie Projektplanung und
Qualitätsmanagement bis hin zu speziellen Maßnahmen und Instrumenten, die für IT-Großprojekte der öffentlichen Verwaltung besonders wichtig sind. Zu Letzteren zählt vor allem die Festlegung der Projektrah menbedingungen, die es z.B. der Projektleitung in einem komplexen Umfeld mit vielen Stakeholdern und
unklaren oder widersprüchlichen Prioritäten ermöglicht, die notwendige Vorabstimmung zu erreichen.
Die S-O-S-Methode© kann auch in kleineren und mittleren sowie in Megaprojekten angewendet werden.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
2 Einleitung
11
2 Einleitung
Auf Grund ihrer Komplexität und spezieller Rahmenbedingungen stellen Groß-projekte in der öffentlichen
Verwaltung besondere Anforderungen an das Projektmanagement. Für diesen Zweck stellt das Bundesverwaltungsamt (BVA) mit dem Kompetenzzentrum Großprojektmanagement (CC GroßPM) kompetentes Personal und eine einheitliche Projektmanagement-Methodik (S-O-S-Methode©) vor.
Das GroßPM-Vorgehen orientiert sich an der durch das Project Management Institute (PMI) vorgegebenen
Struktur, berücksichtigt Inhalte aus dem Praxisleitfaden des Bundesministeriums des Innern (BMI) (siehe
Kapitel Project Management Institute: PMBOK® Guide und Praxisleitfaden Projektmanagement für die öffentliche Verwaltung) und vertieft insbesondere die spezifischen Aspekte des GroßPM in der öffentlichen
Verwaltung.
Die S-O-S-Methode© trägt bei stringenter Anwendung maßgeblich dazu bei, dass die IT-Großprojekte des
Bundes ihre Ziele innerhalb des jeweiligen Zeit- und Budgetrahmens erreichen.
2.1 Weiterentwicklung und Abgrenzung der S-O-S-Methode©
Das CC GroßPM entwickelt die im vorliegenden Dokument beschriebene S-O-S-Methode© kontinuierlich
weiter. So fließen beispielsweise weitere Erfahrungen aus Großprojekten in die Beispiele, Vorlagen und
Checklisten ein. Dadurch wird der Abstraktionsgrad der S-O-S-Methode© in zukünftigen Versionen abnehmen.
Die S-O-S-Methode© wird nicht die Grundlagen des Projektmanagements thematisieren; der Fokus liegt
ausdrücklich auf den für das GroßPM spezifischen Themen.
Abbildung 2: Voraussetzung ist Basis-Projektmanagement (z.B. PMI, Prince)
Zu den hier nicht weiter erläuterten Grundlagen zählen vor allem die Aufgaben der Planung (z.B. Vorgehen,
Projektstrukturplan, Einsatzmittel), der Ausführung (z.B. Erledigen der Aufgabenpakete, Qualitätssicherung),
der Diagnose und Steuerung (z.B. Berichtswesen, Dokumentation, Information), der Führung und Zusammenarbeit (z.B. Projektmarketing, Kommunikation, Führung), des Abschlusses (z.B. Abschlussbericht, Entlastung, Überführung in die Linie) sowie Ansätze zur Auditierung oder Revision von Projekten.
Ebenso wenig thematisiert die Methode die Erstellung der eigentlichen Werk-stücke, also Tätigkeiten wie Er stellung von fachlichen Feinkonzepten, Programmierung, Konfiguration von Standardsoftware oder Tests.
2.2 Aufbau und Zweck des Dokuments
Das vorliegende Dokument ist wie folgt gegliedert:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
12
2 Einleitung
Abbildung 3: Struktur des Dokuments
Kapitel Lesehilfe: Schnelleinstieg ins Methodenhandbuch beschreibt genauer, welche Abschnitte des vorliegenden Handbuchs für welche Einstiegspunkte und Unterstützungsbedarfe relevant sind.
Zunächst werden die Projekte, auf die diese Methode vorrangig anwendbar ist, anhand verschiedener Kriterien eingegrenzt (Kapitel Kriterien von Großprojekten). Anschließend geht das Dokument auf die Besonderheiten von IT-Großprojekten in der öffentlichen Verwaltung ein und leitet daraus Erfolgsfaktoren für das Pro jektmanagement ab, an die in den drei nachfolgenden Kapiteln Disziplinen zum Management der strategischen Ausrichtung, Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter und
Disziplinen zu Systemen, Instrumenten und Werkzeugen die Beschreibung der verschiedenen Disziplinen
des Projektmanagements anknüpft. Die Erweiterung der Managementdisziplinen um das Programmmanagement folgt in Kapitel Erweiterung der Managementdisziplinen. Schließlich werden ProjektmanagementStandards und Vorgehensmodelle für IT-Projekte im Allgemeinen behandelt (Kapitel ProjektmanagementStandards).
In den Beschreibungen der Disziplinen des Projektmanagements folgt die Methode einer einheitlichen Unterstruktur, die in Abbildung 4 dargelegt ist.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
2.2 Aufbau und Zweck des Dokuments
13
Abbildung 4: Unterstruktur in den Kapiteln zur Beschreibung der Disziplinen des Projektmanagements
Das Dokument liefert keine grundlegende und umfassende Beschreibung der Projektmanagement-Disziplinen, sondern baut darauf auf und verweist auf gängige Projektmanagement-Standards sowie einschlägige Literatur.
→ Einzelne Projektmanagement-Disziplinen werden ausschließlich hinsichtlich ihrer Besonderheiten beim
Management von Großprojekten der öffentlichen Verwaltung beschrieben. Diese Besonderheiten sind jeweils durch einen einleitenden Pfeil (→) gekennzeichnet und durch einen grünen Balken eingefasst.
Zusammenfassung der Besonderheit
Das Dokument definiert Mindeststandards für die Projektarbeit in Großprojekten. Schwerpunkte sind:
●
Unterschiede und Gemeinsamkeiten von normalen und Großprojekten
●
Projektmanagementthemen, auf die die Projektleitung eines Großprojekts besonderes Augenmerk legen
muss
●
Lösungsmöglichkeiten für typische Probleme in Großprojekten (z.B. Vorlagen, Checklisten, Methoden,
Großprojekterfahrung des CC-Beraters).
Eine Sammlung von Vorlagen und Checklisten, gegliedert nach Methodendisziplin und Lebenszyklusphase, ergänzt das vorliegende Dokument. Neben typischen Standards (z.B. grober Projektplan, Statusbericht,
Offene-Punkte-Liste) enthält die Sammlung auch Elemente, die sich insbesondere an der hier angewendeten
S-O-S-Methode© orientieren. Hierzu zählen beispielsweise:
●
Ein Fragebogen zur Ermittlung des Projektstatus, der das Projekt an den Anforderungen der Erfolgsfaktoren der S-O-S-Methode© spiegelt
●
Eine Checkliste, anhand derer die konkrete Ausgestaltung einer Methodendisziplin gegen die hier vorgeschlagenen Hinweise geprüft werden kann. So kann eine Checkliste z.B. dazu dienen, die Angemessenheit einer gegebenen Projektplanung für das komplexe Großprojekt zu prüfen.
In der nachfolgenden Abbildung sind alle Vorlagen und Checklisten aufgeführt. Diese sowie das Dokument
selbst stehen unter www.grosspm.bund.de zum Herunterladen zur Verfügung. Eine detaillierte Liste, die die
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
14
2 Einleitung
Vorlagen und Checklisten auf die Phasen des Projektlebenszyklus aufschlüsselt, findet sich in Anhang Ausführliche Liste aller Vorlagen und Checklisten.
Methodenkomponente
Nr.
Dokument
Statusprüfung der
Erfolgsfaktoren
4.3-1
ERP-Fragen zur Ermittlung des Projektstatus
Festlegung/Überprüfung der
Projektrahmenbedingungen
5.1-1
5.1-2
5.1-3
5.1-4
5.1-5
5.1-5
Projektmotivation und Ziele
Projektgrundsätze
Projektcharta
Projekt Grobplanung
V-Vorgehensmodell
Entscheidungsvorlage Vorprojekt
SOS-Methodencheckliste Projektrahmenbedingungen
Vergabe- und
Vertragsmanagement
5.2-1
5.2-2
5.2-3
5.2-4
Abnahmeprotokoll
Checkliste „Abnahmeverfahren"
Vertragsübersicht und Zahlungsplan
SOS-Methodencheckliste Vergabe- und Vertragsmanagement
Festlegung/Überprüfung der
Projektorganisation
5.3-1
5.3-2
Detailliertes Projektorganigramm
SOS-Methodencheckliste Projektorganisation
Personalmanagement
6.2-1
6.2-2
Mitarbeiterverfügbarkeits- und Einsatzplan
SOS-Methodencheckliste Personalmanagement
Kommunikationsmanagement 6.3-1
6.3-2
6.3-3
6.3-4
6.3-5
6.3-6
6.3-7
(U-)LA-Vorlage
Kommunikationsplan
Statusbericht intern
Statusbericht extern
Statusprotokoll
Projekthandbuch
SOS-Methodencheckliste Kommunikationsmanagement
Veränderungsmanagement
6.4-1
6.4-2
6.4-3
6.4-4
6.4-5
Newsletter
Prozessveränderung
Schulungsübersicht
Schulungsplanung
SOS-Methodencheckliste Veränderungsmanagement
Projektplanung
7.1-1
7.1-2
7.1-3
7.1-4
7.1-5
7.1-6
Offene Punkte Liste
Beistellungsliste
Aufwandschätzung
IT-WiBe (Budgetplanung)
Aufwandscontrolling
Checkliste „Aufwands- und Aktivitätsplanung"
SOS-Methodencheckliste Projektplanung
Anforderungs- und
Änderungsmanagement
7.2-1
7.2-2
Änderungsverfahren
SOS-Methodencheckliste Anforderungs- und Änderungsmanagement
Qualitätsmanagement
7.3-1
7.3-2
7.3-3
QS-Konzept
QS-Planung und -Nachweisführung
SOS-Methodencheckliste Qualitätsmanagement
Risikomanagement
7.4-1
7.4-2
Risikoliste und Risikomatrix
SOS-Methodencheckliste Risikomanagement
Programmmanagement
8.1-1
8.1-2
Schnittstellenüberwachung
SOS-Methodencheckliste Programmmanagement
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
2.2 Aufbau und Zweck des Dokuments
Methodenkomponente
15
Nr.
Dokument
8.1-3
8.1-4
Projektbeschreibungen und Abhängigkeiten
Abhängigkeits-Diagramm
Tabelle 1: Liste an ergänzenden Vorlagen und Checklisten zur Methodik
Die vorliegende Methodik beschreibt das notwendige Handwerkszeug des Projektleiters nicht vollständig.
Zu den Kernthemen des Projektmanagements (z.B. Planung, Kommunikation, Qualitätsmanagement) kommen in der Projektarbeit noch – hier am Rande erwähnte – angrenzende Themen (z.B. Softwareentwicklungsmethoden). Dennoch sind sie in den meisten Fällen notwendig, um den Gesamterfolg eines komplexen
IT-Projekts sicherzustellen.
Im vorliegenden Dokument wird in der Regel von Organisationen, Entitäten und Behörden gesprochen. In
allen Fällen sind damit alle Arten von Einrichtungen der öffentlichen Verwaltung gemeint. Die Abstraktion
der Begriffe ist wegen der Vielzahl von Arten der Einrichtungen notwendig.
2.3 Zielgruppen des Dokuments
Das Dokument richtet sich an drei Zielgruppen:
●
Projektauftraggeber, die im Dokument eine Hilfestellung für die Projektanbahnung finden und damit
ein geplantes Vorhaben sowie dessen Auswirkungen besser einschätzen können
●
Projektleiter und -mitarbeiter, die durch das Dokument gezielt unterstützt werden und denen es standardisierte Vorlagen zu den verschiedenen Bausteinen des GroßPM zur Verfügung stellt. Darüber hinaus
schafft das Dokument als „Open Book“ Transparenz und damit weiteres Vertrauen in Kompetenz und
Vorgehen des CC GroßPM.
●
Mitarbeiter des CC GroßPM, denen es Checklisten für die Beratungseinsätze an die Hand gibt sowie
die Aufbereitung und Integration von Wissen in das Wissensmanagement erleichtert.
2.4 Lesehilfe: Schnelleinstieg ins Methodenhandbuch
2.4.1 Einstieg in die Methode je nach Unterstützungsbedarf
Das vorliegende Methodenhandbuch ist umfangreich, obwohl es auf die spezifischen Aspekte von IT-Großprojekten in der öffentlichen Verwaltung fokussiert. Für die unterschiedlichen Einstiegspunkte ins GroßPM
sind die verschiedenen Abschnitte unterschiedlich relevant - z.B. je nach Lebenszyklusphase (Ist das Projekt
erst in der Anbahnungsphase? Läuft das Projekt bereits und soll überprüft werden?). Die nachfolgenden Erläuterungen weisen je Einstiegspunkt auf die wichtigsten Abschnitte hin.
●
Anbahnen und Aufsetzen eines Projekts. Zunächst interessant als Einstieg sind die Besonderheiten
und Erfolgsfaktoren im GroßPM (Kapitel Erfolgsvoraussetzungen von IT-Großprojekten in der öffentlichen Verwaltung). Anschließend erläutert Kapitel Festlegung/Überprüfung der Projektrahmenbedingungen, wie die Rahmenbedingungen für einen optimalen Projektstart gesetzt werden können.
●
Übernahme von Einzelaufgaben im Projekt. Zur Vorbereitung der Übernahme von Einzelaufgaben im
Projekt bieten sich vordringlich die spezifischen Methodenkapitel an – ein Risikomanager konsultiert
vorrangig Kapitel Risikomanagement, in dem das Vorgehen im Risikomanagement erläutert wird. Allerdings sollte auch hier das Kapitel Faktoren des Projekterfolgs mit den Erfolgsfaktoren der S-O-S-Metho-
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
16
2 Einleitung
de© als Einstieg dienen, um eine übergeordnete Perspektive auf den Gesamterfolg des Projekts zu erhal ten.
●
Übernahme des Project Management Office (PMO). Typische Aufgaben eines PMO sind das operative Projektcontrolling (Kapitel Projektplanung mit Fokus Controllingprozesse) und das Qualitätsmanagement oder die Betreuung von Kommunikationsprozessen (einschließlich Berichtswesen, Statusupdates,
Gremienvorbereitungen, Protokollerstellung). Diese werden in Kapitel Kommunikationsmanagement genauer erläutert.
●
Unterstützung bei Phasenübergängen: Insbesondere in den Phasenübergängen von Anbahnung/Vergabe zu Konzeption sowie von Konzeption zu Realisierung benötigen viele Projekte kurzfristige Unterstützung, um einen sauberen Abschluss der alten Phase sicherzustellen und sich auf die andersartigen
Anforderungen der nächsten Phase vorzubereiten. Allgemein empfiehlt die vorliegende Methode hierzu
den Fragebogen zum Projektstatus entlang der S-O-S-Erfolgsfaktoren (Kapitel Statusprüfung der Erfolgsfaktoren), der dann weitere Vertiefungsthemen identifiziert. Für den Übergang zur Konzeption sind
insbesondere die S-O-S-Checklisten zu „Festlegung Rahmenbedingungen“ sowie zum Vertragsmanagement relevant (Kapitel Festlegung/Überprüfung der Projektrahmenbedingungen und Vergabe- und Vertragsmanagement). Im Übergang zur Realisierung ist die S-O-S-Checkliste zum Qualitätsmanagement
(Kapitel Qualitätsmanagement) hervorzuheben. Übergreifend ist die S-O-S-Checkliste zum Veränderungsmanagement (Kapitel Veränderungsmanagement) zu erwähnen.
●
Kontinuierliche Begleitung der Projektleitung: Für das Coaching der Projektleitung dient wiederum
der Fragebogen zu den S-O-S-Erfolgsfaktoren als guter Einstieg und Diskussionsleitfaden. Unterstützungsbedarfe im Coaching liegen vielfach im Stakeholder- und Kommunikationsmanagement (Kapitel
Festlegung/Überprüfung der Projektrahmenbedingungen und Kommunikationsmanagement) sowie im
Veränderungsmanagement (Kapitel Veränderungsmanagement).
●
Projektreviews für Auftraggeber und -nehmer: Als inhaltlichen Leitfaden eines Projektreviews oder
eines Projektaudits schlägt die vorliegende Methode den Fragebogen aus Kapitel Statusprüfung der Erfolgsfaktoren vor. Das Vorgehen und die Enddokumente im Projektreview sollten sich am Risikomanagement orientieren (Kapitel Risikomanagement). Je nach identifiziertem Handlungsbedarf sind dann vertiefende Erläuterungen aus den übrigen Methodenkapiteln zu empfehlen.
●
Neuaufsetzen oder Beenden eines Projekts: Befindet sich ein Projekt nach Ansicht der Auftraggeber in
einer ernsthaften Krise, sollte der Großprojektunterstützer zunächst eine detaillierte Ursachenanalyse an hand des Kapitels Statusprüfung der Erfolgsfaktoren vornehmen. Je nach Ergebnis sind dann unterschiedliche Kapitel relevant: Zur inhaltlichen Neuausrichtung des Projekts (z.B. durch Redefinition der
Ziele) gibt Kapitel Festlegung/Überprüfung der Projektrahmenbedingungen methodischen Input. Erscheint ein Wechsel in der Projektorganisation angezeigt, gibt Kapitel Festlegung/Überprüfung der Projektorganisation Hinweise zu den benötigten Kompetenzen. Zum Beenden eines Projekts erscheint weiterhin eine vertragsrechtliche Prüfung der Folgen ratsam – siehe hierzu Kapitel Vergabe- und Vertragsmanagement.
●
Wissenstransfer und Training: Die Vermittlung des hier versammelten Wissens folgt optimalerweise
der Gesamtstruktur dieses Dokuments – dem Einstieg über die Erfolgsfaktoren der S-O-S-Methode©
folgt eine Vorstellung der Methodendisziplinen, deren Sequenz dem ungefähren chronologischen Ablauf
eines Projekts entspricht. Darüber hinaus ist das Kapitel Veränderungsmanagement zum Thema Veränderungsmanagement ratsam.
2.4.2 Einstieg in die Methode für den V-Modell-Experten
In der öffentlichen Verwaltung ist für die Durchführung von Systementwicklungs-, insbesondere von Softwa reentwicklungsprojekten die Anwendung des V-Modells® XT (siehe EN-201) vorgeschrieben - unabhängig
von der Projektgröße. Das V-Modell definiert dabei je nach Projekttyp und Projektmerkmalen das Vorge hensmodell für die Projektdurchführung und schlägt die anzufertigenden Zwischen- und End-Produkte vor,
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
2.4 Lesehilfe: Schnelleinstieg ins Methodenhandbuch
17
die für die spezifische Systementwicklung insgesamt benötigt werden. Dabei verbleibt das V-Modell methodenneutral und gibt nur vor, welche Produkte in welcher Reihenfolge von wem anzufertigen sind. Es trifft
keine konkrete Aussage darüber, wie und innerhalb welchen Zeitraums diese Produkte anzufertigen sind. Die
vorliegende Methode des CC GroßPM fokussiert dagegen ausschließlich auf Themen des Projektmanagements, insbesondere für IT-Großprojekte, und beschreibt in diesem Themenfeld nicht nur das „Was“, sondern
auch ein mögliches „Wie“. Damit ergänzt die SOS-Methode das V-Modell um konkrete Aspekte des Groß projektmanagements.
Aus diesem Zusammenspiel ergibt sich für den V-Modell-Experten folgende Schrittfolge in der Zusammenstellung des Methodenbaukastens für ein Projekt:
1. Tailoring des V-Modells® XT auf die spezifischen Belange des aktuellen Projekts.
2. Für die Projektmanagementthemen (und einige Unterbereiche der Systementwicklung) bietet die
vorliegende Methode ausformulierte und tiefergehende Vorgehenshinweise sowie Vorlagen und
Checklisten. Die entsprechenden Referenztabellen finden sich in Kapitel V-Modell XT / V-Modell
XT Bund – dort ist für viele Produkte des V-Modells aufgeführt, welches Kapitel des vorliegenden
Handbuchs weiterführende Erläuterungen enthält. Ebenso sollte der V-Modell-Experte die Vorlagen
der vorliegenden Methode daraufhin prüfen, ob sie den V-Modell-Vorlagen auf Grund des Großpro jektcharakters des aktuellen Projekts vorzuziehen sind.
2.5 Endnoten
EN-201
Das „V-Modell® XT“ ist als Leitfaden zum Planen und Durchführen von Entwicklungsprojekten unter Berücksichtigung des gesamten Systemlebenszyklus konzipiert (Dokumentation V-Modell XT, Kapitel 2, Satz1).
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
18
3 Kriterien von Großprojekten
3 Kriterien von Großprojekten
IT-Großprojekte im Sinne dieser Methode werden nach folgenden Kriterien unterschieden:
●
Es handelt sich um ein Groß- oder Megaprojekt mit einem Gesamtaufwand (EN-302) von mehr als 50
Personenjahren (EN-303, siehe Kapitel Definition von Zielprojekten nach Größe).
●
Der Projektinhalt ist komplex (siehe Kapitel Definition von Zielprojekten nach Inhalt).
●
Das Projekt steht im Lebenszyklus zwischen Beginn der Projektanbahnung und Abschluss der Umsetzung (siehe Kapitel Definition von Zielprojekten nach Lebenszyklusphasen). In der Betriebsphase der
neu entwickelten IT-Lösung wird die hier beschriebene Methodik im Regelfall nicht eingesetzt. (EN304)
Der Anhang (Kapitel Weitere Klassifizierungen für IT-Projekte) enthält weitere mögliche Klassifizierungen
von IT-Projekten.
3.1 Definition von Zielprojekten nach Größe
Die Projektgröße kann mit verschiedenen Kriterien gemessen werden, z.B. Aufwand, Dauer, Teamgröße
(Durchschnitt und Maximum), Function Points/Use Case Points oder Budget. Einige dieser Kriterien beleuchten jedoch nur Teilaspekte der Projektgröße oder berücksichtigen nicht alle Komplexitätsfaktoren. So
ist etwa ein lange laufendes Projekt mit zwei Mitarbeitern noch kein Großprojekt.
Die gängigste Größenangabe für IT-Projekte ist der erforderliche Aufwand zum Erreichen des Projektziels,
angegeben in Anzahl der Personenjahre. Personenjahre basieren auf der Schätzung oder vollständigen Kalkulation externen und internen Personals unabhängig von den Tagessätzen Externer (EN-301). Die Information
über die Größenordnung des Aufwands ist darüber hinaus für nahezu jedes Projekt verfügbar. Daher erfolgt
die Einordnung hier nach der Höhe des Aufwands, angegeben in der Anzahl der Personenjahre. Im Aufwand
sind die wesentlichen für die Größe des Projekts relevanten Aspekte und Komplexitätsfaktoren berücksichtigt. Die Komplexitätsfaktoren können auch ein technisch scheinbar einfaches Projekt zu einem Großprojekt
machen (z.B. erhöht die Abstimmung mit sehr vielen lokalen Personalräten die Komplexität der technisch
einfachen Einführung einer Zeiterfassung). Die Angabe des Aufwands berücksichtigt folgende Aspekte:
●
Eigentlicher Projektinhalt (Aufwand zum Erreichen der Projektergebnisse)
●
Querschnittsaufwand (z.B. Projekt-, Qualitäts-, Konfigurationsmanagement, Meetings)
●
Aufwand zum Management sonstiger Komplexitätstreiber, z.B. Anzahl der Schnittstellen zu Nachbarsys temen (erhöhter Abstimmungsaufwand)
●
Anzahl der Stakeholder und Beteiligten (erhöhter Kommunikationsaufwand)
●
Politische Konstellation und Öffentlichkeitswirksamkeit (erhöhter Kommunikationsaufwand)
●
Anzahl der Projektstandorte und Projektsprachen (erhöhter Organisations- und Kommunikationsaufwand)
●
Bedeutung der Projektergebnisse (erhöhter Qualitätssicherungsaufwand, z.B. ausführlichere Reviews
und Tests, komplexere Entscheidungsprozesse).
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
3.1 Definition von Zielprojekten nach Größe
19
Abbildung 5: Durch das notwendige Management von Komplexitätstreibern führt erhöhte Komplexität zu einem erhöhten Aufwand im Projekt
Abbildung 5 veranschaulicht den Zusammenhang zwischen Projektgröße und Komplexität: Je höher die
Komplexität des Projekts (inhaltlich/fachlich, technisch, organisatorisch, politisch etc.), desto größer ist der
Aufwand. Dieser steigt mit zunehmender Komplexität überproportional an. Nur in Ausnahmefällen gibt es
komplexe Projekte mit geringem Aufwand oder Großprojekte mit geringer Komplexität. Die Mehrzahl der
IT-Projekte (hier dargestellt als Kreise) gruppiert sich daher um eine entsprechende überproportional wachsende Funktion.
In Abbildung 6 werden die Änderungen in der Projektmanagement-Methode für verschiedene Projektgrößenklassen beschrieben.
Abbildung 6: Projektmanagement-Charakteristika nach Projektgröße
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
20
3 Kriterien von Großprojekten
Kleine Projekte sind definitionsgemäß solche, die in bis zu zehn Personenjahren erledigt werden können. Sie
erfordern in der Regel ein pragmatisches Vorgehen mit angemessenem organisatorischem Aufwand. Projekte
mittlerer Größe von 10 bis 50 Personenjahren benötigen hingegen bereits ein strukturiertes Vorgehen, für das
dieses Handbuch Leitfaden dienen kann. Ein regelgerechtes formales Management ist für Großprojekte er forderlich. Sie haben eine Größe von 50 bis 500 Personenjahren und benötigen alle Managementdisziplinen,
die in den folgenden Kapiteln beschrieben werden. Megaprojekte mit einer Größe von über 500 Personenjahren sind darüber hinaus auf ein stringentes Programmmanagement (Kapitel Programmmanagement) angewiesen, das unter anderem das Projekt in handhabbare Teile zerlegt und damit steuerbar macht.
Insbesondere für Megaprojekte (oder Teilprojekte davon) gilt: Für einzelne Projektmanagement-Bereiche
müssen Einzelfalllösungen erarbeitet werden, da die meisten dieser Projekte einzigartig sind.
3.2 Definition von Zielprojekten nach Inhalt
Eine weitere relevante Klassifizierung von großen IT-Projekten ergibt sich aus den Projektinhalten, weil diese zumeist mit einem bestimmten Grad an Komplexität einhergehen. Die folgende Tabelle liefert eine solche
grobe Klassifizierung nach Inhalten.
IT-Projekt-Arten
Beschreibung
Strategische IT-Projekte
Ein übergeordnetes IT-Ziel (z.B. IT-Konsolidierung) wird mit einer
Kombination verschiedener Maßnahmen verfolgt - von Infrastruktur- bis zu
Integrationsprojekten.
Integrationsprojekte
Ein System entsteht in einer Kombination aus Einführung einer
Standardkomponente und individueller Anpassung der Schnittstellen und
umliegenden Systeme.
Standardsoftware-Einführung
Ein System entsteht durch Auswahl, Einführung und Konfiguration einer
oder mehrerer Standardsoftware-Komponenten.
Anwendungsentwicklung
Ein System wird individuell entwickelt (und eventuell gewartet).
Infrastrukturprojekte
Es gibt nur Änderungen an der Infrastruktur, ohne dass damit fachliche
Änderungen an den betroffenen Systemen einhergehen (z.B. Austausch
von Rechenzentrumsservern, nachdem der Support für die alten Server
abgelaufen ist).
Tabelle 2: Lebenszyklus eines IT-Projekts
Die unterschiedlichen Projektinhalte haben unterschiedliche Auswirkungen auf das Projektmanagement, wie
Abbildung 7 zeigt.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
3.2 Definition von Zielprojekten nach Inhalt
21
Abbildung 7: CC GroßPM unterstützt alle Arten von (komplexen) IT-Projekten
Das GroßPM unterstützt grundsätzlich IT-Projekte mit allen hier aufgeführten Inhalten. Es gibt aber auch
große Projekte mit geringer Komplexität, z.B. Infrastrukturprojekte für den Austausch von Telefonapparaten
in großen Behörden. Projekte mit solcher geringer Komplexität gelten nicht als Großprojekte. Ein Anzeichen
für eine geringe Komplexität ist z.B. die oft wiederholte Ausführung gleichartiger Tätigkeiten, die einen
Großteil des Projektaufwands ausmachen.
Teile dieses Dokuments thematisieren vorwiegend einzelne Projekttypen. In der Regel handelt es sich dabei
um Softwareprojekte, also Integrations-, Standardsoftware- oder Anwendungsentwicklungsprojekte. Insbesondere die Beziehungen zwischen Auftraggeber und -nehmer spielen in diesen Projekten eine größere Rolle
als in Strategie- und Infrastrukturprojekten. Entsprechend sind die jeweils offensichtlich nicht relevanten In formationen an den entsprechenden Stellen zu vernachlässigen (z.B. ist Vertragsmanagement ohne einen
Auftrag belanglos). Die Grundsätze der jeweiligen Kapitel gelten jedoch in jeder Art von Projekt und sollen
befolgt werden.
3.3 Definition von Zielprojekten nach Lebenszyklusphasen
IT-Projekte durchlaufen einen typischen Lebenszyklus – und lassen sich danach unterscheiden, in welcher
Phase des Lebenszyklus sie sich gerade befinden. Eine solche Klassifizierung ist also nicht konstant, sondern
flüchtig. Die folgende Tabelle beschreibt die sechs wesentlichen Phasen.
Lebenszyklusphase
Beschreibung
Vorphase
Entstehung und Formung des Vorhabens, aus dem letztlich der Bedarf
für ein oder mehrere Projekte erwächst
Projektanbahnung
Festlegung der Rahmenbedingungen, Projektantrag, Mittelbereitstellung
Konzept
Spezifikation des Projektergebnisses (oft in weitere Phasen für Grobund Feinkonzept untergliedert)
Entwurf
Festlegung der technischen Lösung zur Umsetzung der Spezifikation
Umsetzung
Realisierung, Test, Inbetriebnahme
Betrieb
laufender Betrieb, Weiterentwicklung, Fehlerbehebung/Gewährleistung
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
22
3 Kriterien von Großprojekten
Tabelle 3: Lebenszyklus eines IT-Projekts
Die S-O-S-Methode© kann von der Vorphase bis zur Umsetzung herangezogen werden.
Abbildung 8: Im Lebenszyklus des Projekts unterstützt das GroßPM von der Projektanbahnung bis zum Ende
der Umsetzung
Besonders wichtig ist die Berücksichtigung der S-O-S-Methode© bei der Projektanbahnung. Oft werden ge rade hier – bei Festlegung der Rahmenbedingungen und Ausrichtung der Projektziele an den übergeordneten
Zielen der Organisationseinheit bzw. an der politischen Agenda – Fehler begangen, die zum Scheitern eines
Projekts beitragen. Die S-O-S-Methode© kann bereits im Vorfeld des Projekts helfen, die Grundlagen für
den Erfolg zu schaffen.
Weder die Vorphase noch die Phase Betrieb/Wartung sind im engeren Sinne Projektphasen, da wesentliche
Projekteigenschaften fehlen, z.B. (noch) kein inhaltlich festgelegtes Ergebnis, keine festgelegten Endtermine.
●
In der Vorphase ist noch nicht klar, wie sich ein in der Diskussion befindliches Thema in ein Projekt fassen lässt. In dieser Phase sind Beratungsleistungen gefragt, die außerhalb des hier abgesteckten Projektmanagementrahmens liegen. Das CC GroßPM kann in dieser Phase jedoch z.B. bei der Ableitung und
bei der Gestaltung eines Programms aus IT-Projekten zu Rate gezogen werden.
●
Der Betrieb eines IT-Systems wird nicht vom CC GroßPM unterstützt. Allerdings kann die Übernahme
eines bestehenden, komplexen Altsystems in die eigene Wartungsverantwortung als Projekt definiert und
bei Bedarf vom CC GroßPM unterstützt werden. Ebenso kann das CC GroßPM bei Nachbetrachtungen
abgeschlossener Projekte unterstützen, die zeitlich in die Phase Betrieb/Wartung fallen.
3.4 Anforderungen an einzelne Projektmanagement-Disziplinen
Viele der in diesem Dokument beschriebenen Methoden des GroßPM lassen sich auch für Projekte kleinerer
Größe nutzen – insbesondere wenn einzelne Komplexitätsfaktoren die Anforderungen an eine Projektmana gement-Disziplin stark erhöhen, der Gesamtaufwand des Projekts aber wegen ansonsten geringer Komplexitätsfaktoren unterhalb der Schwelle zum Großprojekt bleibt. Beispiele für Komplexitätsfaktoren und deren
Auswirkungen auf Projektmanagement-Disziplinen sind.
●
Öffentlichkeitswirksamkeit (z.B. bei direkten Auswirkungen auf die Bürger → erhöhte Anforderungen
an das Kommunikationsmanagement
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
3.4 Anforderungen an einzelne Projektmanagement-Disziplinen
23
●
Anzahl Stakeholder (z.B. Beteiligung einer Vielzahl von Behörden → erhöhte Anforderungen an das
Kommunikationsmanagement
●
Anzahl Organisationseinheiten/Projektstandorte/Projektsprachen (z.B. bei Abwicklung der Projektumsetzung in einer Offshore-Konstellation → erhöhte Anforderungen an die Projektorganisation und das
Kommunikationsmanagement
●
Technische Komplexität (z.B. hohes Volumen, große Anzahl Schnittstellen → erhöhte Anforderungen an
das Risiko- und Qualitätsmanagement
●
Politische Konstellation (z.B. Bund-Länder-übergreifende Themen → erhöhte Anforderungen an das
Kommunikationsmanagement
●
Bedeutung des Ergebnisses (z.B. bei sicherheitskritischen Anwendungen → erhöhte Anforderungen an
das Risiko- und Qualitätsmanagemen
●
Enge Terminvorgaben (z.B. bei gesetzlichen Anforderungen → erhöhte Anforderungen an Planung und
Anforderungsmanagement.
Ob das CC GroßPM solche Projekte mit besonderen Herausforderungen an das Projektmanagement unterstützt, muss im Einzelfall entschieden werden.
Abbildung 9: Das CC GroßPM ist fokussiert auf große, komplexe Projekte sowie Projekte mit besonderen
Anforderungen an das Projektmanagement
Ein Beispiel ist der Komplexitätsfaktor Öffentlichkeitswirksamkeit: IT-Projekte können Auswirkungen haben, die in der Öffentlichkeit wahrnehmbar sind – und selbst Projekte, bei denen diese Auswirkungen gering
sind, können unter starker öffentlicher Beobachtung stehen, z.B. auf Grund von Medienberichten über Projektinterna. Für das Projektmanagement bedeutet dies einen deutlich erhöhten Kommunikationsaufwand. So
sind beispielsweise Auftraggeber und politischer Sponsor stets so ausführlich wie nötig und so knapp wie
möglich über den Projektstatus zu informieren und in Entscheidungen einzubeziehen, dass sie den Medien
fundierte Auskünfte erteilen können. Zudem erfordert auch eine direkte Kommunikation mit den Medien
eine wesentlich professionellere Kommunikation, als sie projektintern erforderlich wäre.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
24
3 Kriterien von Großprojekten
3.5 Endnoten
EN-301
Bei der Schätzung werden natürlich unterschiedliche Erfahrungen und Fähigkeiten berücksichtigt; so sollte z.B. ein erfahrenes Projektteam, das bereits in ähnlichen Projekten zusammengearbeitet hat, weniger Aufwand benötigen als ein neu zusammengesetztes Team mit
unerfahrenen Mitarbeitern.
EN-302
Aufwand: der für die Lösung eines Problems benötigte Bedarf an Mitarbeiterressourcen, gemessen in Personenjahren (oder -monaten, -tagen). In diesem Dokument wird der Begriff
„Aufwand“ ausschließlich in diesem Sinn gebraucht, also nicht im betriebswirtschaftlichen
Sinn.
EN-303
Personenjahr: Einheit für den Aufwand. Ein Personenjahr entspricht der Arbeitsmenge, die
ein Mitarbeiter durchschnittlich innerhalb eines Zeitjahres – das heißt an rund 200 Personentagen (nach Abzug von Urlaub, Feiertagen etc.) – bewältigt. Es werden interne und externe Mitarbeiter einbezogen.
EN-304
Das CC GroßPM kann jedoch über die aktive Unterstützung eines laufenden Projekts hinaus
sowohl bereits vor der Projektanbahnung zu Rate gezogen werden als auch Nachbetrachtungen (Reviews) abgeschlossener Projekte durchführen, die zeitlich in die Betriebs-/Wartungsphase fallen (siehe Kapitel Definition von Zielprojekten nach Lebenszyklusphasen).
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
4 Erfolgsvoraussetzungen von IT-Großprojekten in der öffentlichen Verwaltung
25
4 Erfolgsvoraussetzungen von IT-Großprojekten in der
öffentlichen Verwaltung
Enormer Umfang, hohe Komplexität, zunehmende Vernetzung und Abhängigkeiten der Verwaltung sowie
besondere (rechtliche) Rahmenbedingungen – das zeichnet IT-Großprojekte in der öffentlichen Verwaltung
aus. Im Folgenden ist deshalb zunächst beschrieben, vor welchen Anforderungen das Management solcher
Projekte steht. Daraus ergeben sich 13 Faktoren, die über Erfolg oder Misserfolg entscheiden. Wie diese Fak toren im konkreten Fall wirken, lässt sich mit Hilfe weniger strukturierter Fragen schnell ermitteln, die anschließend vorgestellt werden. Das Ergebnis ist eine komprimierte Übersicht über den Stand des Projekts, die
zudem auf einen Blick die potenziellen Problemfelder erkennen lässt.
Eine Übersicht über die Erfolgsfaktoren in IT-Projekten der öffentlichen Verwaltung findet sich in Abbildung
10 – diese werden hier als S-O-S-Methode© zum GroßPM zusammengefasst.
Abbildung 10: Die 13 Erfolgsfaktoren der S-O-S-Methode© zum GroßPM (wiederholt von Abbildung 1)
4.1 Besonderheiten von Großprojekten in der öffentlichen Verwaltung
4.1.1 Was unterscheidet Großprojekte generell von anderen, kleineren Projekten und welche
Konsequenzen ergeben sich daraus für das Projektmanagement?
●
Hohe eingesetzte oder auf dem Spiel stehende Werte. Ein Großprojekt verursacht nicht nur unmittelbar hohe Projektkosten (Budget). Erfolg oder Scheitern haben über das Projekt hinaus umfangreiche finanzielle Auswirkungen. Das Beispiel entgangener Einnahmen beim Start von Toll Collect zeigt dies
deutlich.
→Konsequenz: Da das Projekt von Auftraggeber und Investoren genau beobachtet wird, sind Projektstatus und -aussichten genau zu bestimmen und zu kommunizieren. Geeignete Projektmanagement-Prozesse wie ein ausführliches Risikomanagement sollten den Projekterfolg sichern.
Genaue Projektstatusverfolgung sichert Projekterfolg
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
26
●
4 Erfolgsvoraussetzungen von IT-Großprojekten in der öffentlichen Verwaltung
Große Auswirkungen auf Organisation und Öffentlichkeit. Großprojekte verändern oft die Prozesse
in einer Organisation und damit auch die Organisation selbst. In der öffentlichen Verwaltung geht die
Wirkung häufig über die beteiligten Entitäten hinaus in die Öffentlichkeit.
→Konsequenz: Die Projektleitung sollte alle Beteiligten umfassend informieren – vor allem die betroffenen Einheiten und die politische Führung; teilweise aber auch die Medien. Kommunikation ist deshalb eine Kernaufgabe für das Projektmanagement.
Kommunikation als Kernaufgabe
●
Hohe Komplexität. Großprojekte sind nicht nur in fachlicher und technischer Hinsicht vielschichtig, sie
zeichnen sich auch durch eine hohe organisatorische Komplexität aus. Damit ein solches Projekt handhabbar bleibt, braucht es eine innere Struktur: etwa mit Teilprojekten und Hierarchiestufen in der Projektführung. Normale Projektmanagement-Methoden greifen in einer derart hierarchischen Organisation
mit mehreren Ebenen oft nicht.
→Konsequenz: Während technische und fachliche Komplexität sich auch durch entsprechende Vorgehensmodelle bewältigen lässt, ist es Aufgabe des Projektmanagements, die organisatorische Komplexität zu berücksichtigen. Konkret sollte das Projektmanagement vor allem die Aufgaben, Verantwortlichkeiten und Ziele auf allen Ebenen detailliert beschreiben und voneinander abgrenzen, den Informationsfluss von den Entscheidungsträgern bis zur untersten Ebene des Projekts sicherstellen sowie das Gesamtprojektziel und die Rahmenbedingungen auf die einzelnen Ebenen und Teilprojekte aufschlüsseln.
Detaillierte Prozesse und klare Abgrenzungen auf allen Ebenen
●
Viele beteiligte Partner (Firmen und Organisationseinheiten). Typischerweise werden Großprojekte
nicht nur in einer Organisationseinheit abgewickelt, vielmehr sind verschiedene Firmen (Auftragnehmer,
Unterauftragnehmer) und Organisationseinheiten (Auftraggeber, betroffene Entitäten etc.) daran beteiligt.
→Konsequenz: Die Projektleitung sollte eine Organisationsform wählen, die trotz dieser Vielfalt abgestimmte, zeitnahe Entscheidungen ermöglicht.
Flexibilität dauerhaft bewahren
●
Viele beteiligte Mitarbeiter. An Großprojekten sind zahlreiche Mitarbeiter, mit unterschiedlicher Ausbildung, Erfahrung und Motivation beteiligt.
→Konsequenz: Auf die Kommunikation kommt es an. Das Projektmanagement sollte allen Mitarbeitern das Projekt und seine Ziele so klar wie möglich vermitteln – und die Motivation jedes einzelnen
Mitarbeiters für die Projekttätigkeit stärken.
Zielklarheit schafft Motivation
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
4.1 Besonderheiten von Großprojekten in der öffentlichen Verwaltung
27
4.1.2 Welche zusätzlichen Herausforderungen gelten für Großprojekte in der öffentlichen
Verwaltung und welche Konsequenzen ergeben sich daraus für das
Projektmanagement?
(Siehe EN-401)
●
Verlust der Aufmerksamkeit. Projekte sind anfangs ausreichend mit Management-Attention ausgestattet, fallen auf Grund unterschiedlicher Vorkommnisse (Wahlen, Wechsel in der Führung etc.) aus dem
Fokus.
→ Konsequenz: Das Stakeholdermanagement ist von Beginn an zu etablieren und für die dauerhafte
und konsequente Unterstützung und Rückendeckung im Projekt ist Sorge zu tragen.
Dauerhafte Management-Attention sicherstellen
●
Kein „Chef“. Oft fehlt bei Projekten in der öffentlichen Verwaltung das Äquivalent zum CEO (Chief
Executive Officer)/Geschäftsführer in der Wirtschaft. Statt dieses einen Verantwortlichen gibt es oft
mehrere, voneinander unabhängige Beteiligte mit starkem Einfluss. Selten kann jemand autonom ent scheiden, die Konsenskultur ist ausgeprägt.
→Konsequenz: Zu Beginn sind die Ziele mit allen Beteiligten abzugleichen sowie Mechanismen und
Eskalationsprozesse zum Lösen von Problemen im Projekt festzulegen. Bei Entscheidungsträgern/Auftraggebern muss festlegt werden, wer wirklich verantwortlich ist und entscheiden kann.
Verantwortlichkeiten und Eskalationswege definieren
●
Mehrdimensionaler Nutzen. Projekte in der öffentlichen Verwaltung haben oft mehrere Ziele, zwischen
denen Abwägungen zu treffen sind, und kein Entscheider kann die optimale Balance festlegen. Zu den
Zielen gehören häufig auch öffentliche oder immaterielle Güter, die nur schwer zu quantifizieren sind
(z.B. Steigerung der Sicherheit oder der Attraktivität der politischen Maßnahme).
→ Konsequenz: Zu Beginn sind die Projektziele, die Wirtschaftlichkeit und der Projektnutzen zu defi nieren. Hierbei sollten wenigstens Minimalziele festgelegt werden: Nur wenn diese erreicht sind, gilt
das Projekt als erfolgreich.
Konzentration auf Minimalziele
●
Zunächst steht der Endtermin. (Politisch) Verantwortliche neigen besonders dazu, Projektziele schnell
erreichen zu wollen. Deshalb verkünden sie oft zu Beginn eines Vorhabens ehrgeizige Zieltermine oder
schreiben diese fest. Zugleich wird zu diesem Zeitpunkt oft noch nicht der Aufwand erkannt, der nötig
ist, um diese Termine einzuhalten.
→ Konsequenz: Ein Projekt nicht mit unrealistischen Endterminen starten, Projektumfang entsprechend
reduzieren oder Termine verschieben. Die Projektbeiträge des Auftraggebers sind zu definieren und ein zufordern. Sofern dies möglich ist, sollte auch eine qualifizierte Aufwandsschätzung vor der gesetzlichen Festlegung vorgenommen werden.
Realistisches Terminmanagement durch maximale Detaillierung
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
28
●
4 Erfolgsvoraussetzungen von IT-Großprojekten in der öffentlichen Verwaltung
Keine Kompromisse bei Anforderungen. Häufig werden zu viele Anforderungen zu Grunde gelegt,
statt nach einer Teilmenge zu suchen, die für alle Beteiligten zufrieden stellende Ergebnisse verspricht.
→ Konsequenz: Auf das Minimalziel verweisen und die Anforderungen einschränken.
Überflüssige Anforderungen vermeiden
●
Komplexe Entscheidungsstrukturen. In der öffentlichen Verwaltung sind Entscheidungsfindungen oft
hoch komplex und es müssen häufig viele Akteure und Interessen eingebunden werden. Dies resultiert
aus Vorgaben der Politik, aus geltendem Recht oder aus einer Institutionalisierung mit Personalrat, Da tenschutz-, Gleichstellungs-, Schwerbehinderten- und anderen Beauftragten.
→ Konsequenz: Entscheider frühzeitig einbinden, deren unterschiedliche Agenden akzeptieren, mit allen Einflussgruppen feste Prozesse und Meilensteine vereinbaren (Redaktionsschluss-Konzept), Zeit
und Aufwand für Entscheidungsfindung einplanen.
Konstruktiver Entscheidungsfindungsprozess
●
Wenig Expertise im Projektmanagement. Projektmitarbeiter sind oft ausgesprochen fachkompetent,
teilweise handelt es sich sogar um hoch motivierte “Überzeugungstäter“. Häufig haben sie aber nur wenig Erfahrung im Projektmanagement.
→ Konsequenz: Projektmitarbeiter coachen, Experten einbinden, eventuell Rollen anpassen (z.B. Experten als operativen Projektleiter einsetzen und Mitarbeiter mit ausgeprägter Fachkompetenz zum
fachlich Verantwortlichen oder Sponsoren machen).
Zusätzliche Mitarbeiterentwicklung einplanen
●
Wenig Flexibilität im Management interner/externer Mitarbeiter. Vergabe- und Dienstrecht reduzieren die Flexibilität im Lieferanten- und Personalmanagement. Insbesondere dienst- und arbeitszeitrecht liche Regelungen schränken interne Mitarbeiter ein. Es gibt nur wenige Möglichkeiten, finanzielle Anreize für besondere Talente und Leistungen zu schaffen oder Sanktionen für Schlechtleistungen durchzusetzen.
→ Konsequenz: Rahmenverträge ohne Abnahmeverpflichtung abschließen, Projektzuschläge für interne
Mitarbieter vereinbaren.
Incentivierungsmöglichkeiten schaffen
4.2 Faktoren des Projekterfolgs
Warum gelingen bestimmte Projekte, warum scheitern andere? Mit diesen Fragen beschäftigt sich die Pro jektforschung. Sie zeigt, dass aus der Vielzahl denkbarer Ursachen immer wieder einige wenige Erfolgsbzw. Misserfolgsfaktoren hervorstechen – die, wenn sie fehlen (Erfolgsfaktoren) oder wenn sie eintreten
(Misserfolgsfaktoren), ein Scheitern vorprogrammieren.
Zu den wohl wichtigsten Erfolgsfaktoren gehört die konsequente Unterstützung eines Projekts durch die
oberste Organisationsleitung. Ohne deren schützende und leitende Hand ist ein angestrebter Wandel kaum zu
bewerkstelligen.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
4.2 Faktoren des Projekterfolgs
29
Die Erkenntnisse aus der Projektforschung, etwa zu Chaos 10, decken sich weitgehend mit den besonderen
Herausforderungen bei IT-Projekten in der öffentlichen Verwaltung. Im Folgenden listen wir wichtige Erfolgsfaktoren von Projekten auf. Diese lassen sich in drei Kategorien mit insgesamt 13 Faktoren unterteilen
(siehe Kapitel Zusammenfassung) und bilden die S-O-S-Methode© zum GroßPM.
In die erste Kategorie fallen jene Faktoren, die unter dem Stichwort strategische Ausrichtung die Rahmenbedingungen für das Projekt sicherstellen.
●
Klare Projektziele. Sind die Projektziele eindeutig umrissen und formuliert? Sind sie realisierbar? Ermöglichen sie der Projektleitung eine Fokussierung und Priorisierung?
●
Nutzen und Wirtschaftlichkeit sind wohldefiniert. Wurde der Wert bzw. der Nutzen der Lösungen
identifiziert – entweder quantitativ oder qualitativ? Wurden Kosten und quantitative Nutzentreiber finanziell bewertet? Wurden für die qualitativen Nutzentreiber messbare Anspruchsniveaus definiert?
●
Alignment der maßgeblichen Stakeholder. Tragen die maßgeblichen Stakeholder die Projektziele sowie Nutzen und Wirtschaftlichkeit mit? Verfolgen alle die gleichen Prioritäten? Wenn nicht, sind mögli che Konflikte bekannt und entsprechende Entscheidungsregeln benannt? Gibt es Vertreter in der obersten
Hierarchie, die in besonderer Weise einen Nutzen aus dem Projekt ziehen und die sich als „Schirmherren“ verantwortlich fühlen, einen Beitrag zu leisten?
●
Minimaler, stabiler Projektumfang. Ist der Umfang der Lösung so klein wie möglich, zugleich aber
auch so groß wie nötig, um die Projektziele zu erreichen? Gibt es Prozesse, die dazu beitragen, den Umfang des Projekts in dessen Verlauf stabil zu halten und eine schleichende Ausweitung zu vermeiden?
●
Robuste Vertragsgrundlage. Wurden externe Dienstleister einwandfrei und entsprechend den Vergaberichtlinien beauftragt? Sind Rechte und Pflichten der Vertragspartner umfassend und eindeutig definiert?
Sind für den Fall von Konflikten Eskalationsprozesse vorgesehen und eingerichtet?
Zur zweiten Kategorie gehören Treiber, die den Themen organisatorisches Umfeld und Mitarbeiter des
Projekts zuzurechnen sind.
●
Unterstützung durch Organisationsleitung. Ist die oberste Organisationsleitung der beteiligten
Entität(en) regelmäßig in das Projekt involviert? Trägt es wichtige Entscheidungen mit? Stellt es sich vor
den Projektleiter, wenn es zu Krisen im Projekt kommt? Steht die oberste Organisationsleitung als Dis kussionspartner für die Entscheidungsfindung zur Verfügung?
●
Erfahrener Projektleiter. Verfügt der Projektleiter über die nötige Kombination aus fachlicher Kompetenz, Erfahrung als Führungskraft, Energie, Hartnäckigkeit und politischem Fingerspitzengefühl? Hat er
im Rahmen der Projektorganisation den nötigen Spielraum, um seine Rolle erfolgreich ausfüllen zu können?
●
Erfahrenes und motiviertes Projektteam. Sind alle Rollen im Projektteam mit fachlich kompetenten
Mitarbeitern besetzt? Sind die Mitarbeiter der intensiveren Arbeitsbelastung und dem höheren Druck einer Projektsituation gewachsen? Sind sie in der Lage, als überzeugender und gewinnender Botschafter
des Projekts aufzutreten?
●
Ausgewogener Mix aus internen und externen Mitarbeitern. Sind Schlüsselrollen von nachhaltiger
Bedeutung mit internen Mitarbeitern besetzt? Wenn nicht, ist ein Transfer dieser Rollen zu internen Mit arbeitern geplant? Stimmt das „Klima“ im Projekt, wachsen interne Mitarbeiter und externe Dienstleister
zu einem Team zusammen?
●
Einbeziehung der Nutzer. Fließen die profunden Erfahrungen und die detaillierten Anforderungen der
Nutzer in die Konzeption der Lösungen, Prozesse, Schulungen etc. mit ein? Werden die Nutzer rechtzei tig und angemessen auf den Systemwandel vorbereitet?
Die dritte Kategorie schließlich bezieht Treiber ein, die sich auf die Qualität und Verlässlichkeit der unter stützenden Systeme und verwendeten Technologien, Methoden und Verfahren beziehen.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
30
4 Erfolgsvoraussetzungen von IT-Großprojekten in der öffentlichen Verwaltung
●
Verlässliche Schätzungen und Pläne, Mindesttransparenz zum Projektstatus. Wurde das Budget
lückenlos und zuverlässig geschätzt? Sind geplante Meilensteine erreichbar? Gibt es einen hinreichenden
Überblick über die verbrauchten Ressourcen? Sind Restaufwände akkurat geschätzt? Wurden in der Projektplanung wichtige Abhängigkeiten zwischen Teilprojekten identifiziert, um ein Management des kritischen Pfads zu ermöglichen?
●
Angemessene Methoden, Verfahren und Werkzeuge. Ist das Vorgehen bei der Entwicklung oder Einführung einer (Standard-)Softwarelösung auf die Ziele und Rahmenbedingungen des Projekts sowie auf
die verwendete Technologie abgestimmt? Wurden passende Verfahren für die Qualitätssicherung definiert und angewendet? Sind die Tools, etwa zur Projektplanung, angemessen für den Projektumfang und
das Qualifikationsniveau der Projektmitarbeiter?
●
Standardisierte, bewährte Technologien. Ist die vorgeschlagene IT-Architektur in der Lage, die Volumens- und Skalierungsanforderungen der Lösung zu erfüllen? Ist die Lösung flexibel genug, um mit
eventuell steigenden Anforderungen mitzuwachsen? Gibt es Referenzprojekte, die hinsichtlich Größe
und Komplexität vergleichbar sind und in denen die vorgesehenen Technologien bereits erfolgreich zum
Einsatz kamen? Sind die internen Mitarbeiter langfristig in der Lage, die verwendeten Technologien zu
betreuen? Entsprechen die verwendeten oder vorgeschlagenen Technologien den IT-Standards der Organisation (EN-405)? Dieser Abschnitt ist bei Strategieprojekten nicht relevant und kann daher vernachlässigt werden.
Im Folgenden wird beschrieben, welche Disziplinen des Projektmanagements sich wie auf die drei Kategorien sowie deren Erfolgstreiber beziehen. Dabei ist es möglich, dass einzelne Treiber von mehreren Disziplinen angesprochen werden. So ist beispielsweise der Erfolgsfaktor „Einbeziehung der Nutzer“ sowohl bei der
Projektorganisation als auch in der Kommunikation und insbesondere im Veränderungsmanagement ein Thema. Die Abbildung erläutert, welche Disziplinen auf welche Erfolgsfaktoren vordringlich einwirken.
Abbildung 11: Welche Disziplinen des Projektmanagements wirken hauptsächlich auf welche Erfolgsfaktoren?
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
4.3 Statusprüfung der Erfolgsfaktoren
31
4.3 Statusprüfung der Erfolgsfaktoren
Die genannten 13 Erfolgsfaktoren erlauben nun jederzeit eine schnelle und genaue Beurteilung des Projekt status – einschließlich möglicher Risiken. Dafür wurden für jeden Erfolgsfaktor mehrere Prüffragen mit defi nierten Antwortmöglichkeiten entwickelt.
Beispiel: Prüffrage „Ist die initiale Kosten-/Budgetschätzung vollständig?“
Antwortmöglichkeiten:
Alle relevanten Kostentreiber wurden in die Betrachtung einbezogen. Die Antwort signalisiert, dass in diesem
Punkt alles gut läuft – daher Ampelfarbe Grün.
Die meisten relevanten Kostentreiber wurden einbezogen. Offenbar gibt es Beobachtungsbedarf, aber keine
unmittelbare, große Gefahr für den Projekterfolg – daher Ampelfarbe Gelb.
Wesentliche Kostentreiber wurden nicht abgeschätzt. Die Antwort zeigt Risiken für das Projekt und den
Handlungsbedarf, die Schätzung zu vervollständigen – daher Ampelfarbe Rot.
Wünscht ein Auftraggeber bzw. eine Projektleitung mehr Nuancen in der Bewertung, können auch Zwischenstufen definiert werden wie z.B. Grün-Gelb oder Gelb-Rot. Es ist zudem möglich, statt Ampelfarben
Schulnoten zu verwenden: Die Antwortmöglichkeiten entsprechen dann Qualitätsniveaus von 1 (gut/sehr
gut) bis 5 (mangelhaft/kritisch).
Werden später alle Antworten aggregiert (siehe beispielhaft die folgende Abbildung), erhalten Projektleitung
oder Risikomanagement eine Statusübersicht, die sie mit einem Blick erfassen können.
Abbildung 12: Einschätzung des Projektstatus
Damit dem Empfänger der Statusübersicht wirklich kein mögliches Risiko verborgen bleibt, sollten rote Ampelfarben in dieser Statusübersicht nach oben „durchgereicht“ werden. Das heißt, die gesamthafte Bewertung
bei einem Erfolgsfaktor sollte nicht besser als Rot sein, wenn eine einzelne Prüffrage zu diesem Faktor auf
Rot gesetzt wurde.
In einem separaten Dokument (S-O-S-Fragebogen zur Ermittlung des Projektstatus) sind alle 13 Erfolgsfak toren mit wichtigen Prüffragen und Antwortmöglichkeiten aufgeführt. Hier zunächst ein Auszug zur Illustration:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
32
4 Erfolgsvoraussetzungen von IT-Großprojekten in der öffentlichen Verwaltung
Tabelle 4: Prüffragen zur Statusbestimmung von Projekten (Auszug)
4.4 Endnoten
EN-401
Siehe auch Hoch/Leukert/Klimmer: „Erfolgreiches IT-Management im öffentlichen Sektor“,
Gabler Verlag 2005.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
4.4 Endnoten
33
EN-404
Eine Untersuchung der Standish Group, die im Laufe der Jahre im Wesentlichen gleichbleibende Erfolgsfaktoren bei Softwareprojekten nachweist (siehe Programmmanagement).
EN-405
Z.B. SAGA – Standards und Architekturen für E-Government-Anwendungen
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
34
5 Disziplinen zum Management der strategischen Ausrichtung
5 Disziplinen zum Management der strategischen
Ausrichtung
Abbildung 13: Disziplinen des Projektmanagements mit Fokus auf dem „Management der strategischen
Ausrichtung"
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
5.1.1 Ziele: Was soll bei der Festlegung der Rahmenbedingungen erreicht werden?
Eine klare strategische Ausrichtung oder „Marschrichtung“ sind entscheidende Erfolgsfaktoren für ein Groß projekt – sie helfen in allen Phasen des Projektlebenszyklus: In der Anbahnungsphase hilft eine klare Aus richtung, die maßgeblichen Stakeholder auf Ziele einzuschwören, in der Konzeption und Umsetzung kann
der Projektleiter anhand der strategischen Zielsetzung Abwägungsentscheidungen leichter treffen und in der
Betriebsphase helfen die eingangs definierten Nutzentreiber, die Lösung gezielt zu optimieren.
Eine aussagekräftige Vorprüfung des Großprojekts (Vorprojekt), die die Frage des „ob überhaupt“ beantwortet, sollte dabei noch vor der Betrachtung der konkreten Facetten und damit vor der Projektanbahnung erfolgen.
Erst nach dem Vorprojekt beginnt die Arbeit an den verschiedenen Facetten der strategischen Ausrichtung,
die in dieser Methode in vier Erfolgsfaktoren zusammengefasst sind:
●
Klare Projektziele (optimal nach SMART - EN-501), aus denen auch deutlich wird, was das Projekt
bzw. die entstehende Lösung nicht leisten wird
●
Wohldefinierter Nutzen und Wirtschaftlichkeit, der Kosten- und Nutzentreiber benennt, quantifiziert
und, wo möglich, mit Verantwortlichen verknüpft
●
Ein hinreichendes Alignment zwischen den maßgeblichen Stakeholdern und den Projektzielen – werden Ziele und Prioritäten von allen wichtigen Parteien gemeinsam getragen? Besteht Deckungsgleichheit
zwischen den Projektzielen und politischen Zielen der beteiligten Stakeholder?
●
Ein minimaler und stabiler Projektumfang, der die Projektkomplexität begrenzt und „scope creep“
(schleichende Ausweitung des Projektumfangs) verhindert.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
35
Abbildung 14: Ergebnisdokumente der Projektrahmenbedingungen im zeitlichen Ablauf
Zusätzlich geht es nach der Durchführung des Vorprojekts in der Projektanbahnungsphase darum, die nötige
organisatorische Reife herzustellen. IT-Großprojekte scheitern oft wegen mangelnder Vorbereitung der Organisation auf Grund fehlender Aufmerksamkeit der obersten Leitungsebene bereits vor dem eigentlichen
Projektstart. Die folgende Abbildung illustriert das Konzept der organisatorischen Reife.
Abbildung 15: Sicherstellen der nötigen organisatorischen Reife
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
36
5 Disziplinen zum Management der strategischen Ausrichtung
Damit während der Festlegung der Rahmenbedingungen die organisatorische Reife und die dahinter stehenden Erfolgsfaktoren hinreichend erfüllt werden, muss diese Disziplin folgenden operativen Zielen genügen:
●
Präzise Beschreibung von Projektmotivation, Zielen und Prioritäten als Basis einer Definition von
Lösungs- und Projektparametern
●
Abgestimmte Dokumentation der wichtigsten Lösungsparameter (Nutzentreiber und Nutzen, grober
Lösungsumfang in Stufen) als Grundlage einer Grobplanung des Projekts inklusive einer Evaluierung
der Machbarkeit (das „Wie“ der Durchführung)
●
Erstellung einer abgestimmten Grobplanung des Projekts mit den Dimensionen Budget/Aufwand und
wichtigste Termine/Meilensteine, Identifikation der wichtigsten Verantwortlichen/Stakeholder, Definition der Verantwortlichkeiten und Eskalationsprozesse sowie eines groben Vorgehensmodells.
Die operativen Ziele in dieser Disziplin des Projektmanagements werden im Folgenden detailliert erläutert.
Vorprojekt
Vor dem eigentlichen Projektstart ist zu entscheiden, ob das geplante Projekt überhaupt sinnvoll ist. Die
Sinnhaftigkeit kann im Allgemeinen bejaht werden, wenn bei beherrschbaren Risiken der Nutzen eines Projekts dessen Kosten deutlich übersteigt (siehe Abbildung 16). Da in dieser Frühphase viele Einflussfaktoren
noch unbekannt sind, muss die Prüfung auf Basis grober Abschätzungen erfolgen. Diese Feststellungen wer den bei Großprojekten in Vorprojekten getroffen (= mehr als eine Machbarkeitsstudie bei kleinen und mittle ren Projekten).
Die ausführliche Betrachtung der Risiken geschieht im Rahmen des Risikomanagements (siehe Kapitel Risikomanagement). Die detaillierte Betrachtung von Kosten und Nutzen liefert eine Wirtschaftlichkeitsbetrachtung (WiBe) im späteren Verlauf des Projekts (siehe Abbildung 14, Kapitel Ergebnisse: Welche Dokumente
sollen erstellt werden?). Dennoch sollte auch zu diesem frühen Zeitpunkt schon absehbar sein, dass die Fra gen nach einer Beherrschbarkeit des Risikos und einem angemessenen Kosten-Nutzen-Verhältnis positiv zu
beantworten sind. Bestehen hier große Unsicherheiten, lohnen sich tiefere Analysen, bevor das Projekt offiziell gestartet wird – die Erfahrung zeigt, dass sich anfängliche Zweifel eher bestätigen als auflösen.
Das Vorprojekt beinhaltet:
●
Definition von Zielen und zu erwartenden Ergebnissen sowie deren Nutzen
●
Qualität der Ergebnisse und voraussichtlich dafür zu betreibender Aufwand
●
Rahmenbedingungen (z.B. Gesetze, Ressourcen- oder Zeitbeschränkungen, Vorgaben zu Mindestqualität)
●
Zeitrahmen
●
Benötigte Ressourcen
●
Wesentliche Stakeholder
●
Risiken.
Als Ergebnis des Vorprojekts ergibt sich eine Beurteilung der Sinnhaftigkeit des Vorhabens unter Berücksichtigung der oben genannten Punkte, die in einer Entscheidungsvorlage mündet, die dabei hilft, über Stopp
oder Übergang in die Projektanbahnung zu entscheiden. Diese Unterlage sollte in der Folgephase für den
Projektauftraggeber bzw. -sponsor bereitstehen.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
37
Abbildung 16: Zentrale Fragen des Vorprojekts
→ In vielen Projekten des öffentlichen Sektors ist die Frage nach dem Nutzen schwierig zu beantworten.
Insbesondere übergreifende Erwägungen wie Technologieführerschaft oder Befriedung von Anspruchsgruppen sträuben sich gegen quantitative Bewertungen und führen häufig zu einer Negierung von Risiken. Hier
empfiehlt es sich, die angestrebten Nutzentreiber genau zu verstehen (z.B. „Wir wollen einer Schlüsseltechnologie durch praktischen Einsatz zum Durchbruch verhelfen“) und dann Alternativlösungen zum Großprojekt vorzuschlagen (z.B. Vorschaltung einer Pilotierung).
Erfassung von Nutzen auch im politischen Umfeld notwendig
Nach Abschluss des Vorprojekts und einer positiven Entscheidung über die Weiterführung folgt die Projektanbahnungsphase, deren Ziele im Folgenden beschrieben werden.
Dokumentation der wichtigsten Lösungsparameter
Die Ziele werden in Nutzentreiber überführt – welche Lösungselemente helfen auf welche Weise, die Ziele
zu erreichen? Liegt beispielsweise ein Projektziel in der Verbesserung der Informationsversorgung für die
Steuerung der Organisation, muss bei den Nutzentreibern erläutert werden, welche Informationen bei wel chen Mitgliedern der obersten Leitungsebene in welchen Situationen für welche Verbesserungen sorgen. Die se Konkretisierung ist bei qualitativen und quantitativen Treibern möglich.
Quantitative Nutzentreiber können durch Anwendung auf die jeweilige Situation in der Organisation (Erhebung Mengengerüste/Anzahl Fälle, Abschätzung Verbesserungspotenzial je Fall) in einen quantitativen und
häufig sogar finanziellen Nutzen überführt werden.
Der Zusammenhang zwischen Motivation, Zielen und Nutzentreibern ist in der folgenden Abbildung erläutert.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
38
5 Disziplinen zum Management der strategischen Ausrichtung
Abbildung 17: Der Zusammenhang zwischen Motivation, Zielen und Nutzen
Aus den Zielen, Prioritäten und Nutzentreibern leiten sich die groben funktionalen und nicht funktionalen
Anforderungen ab, die die Lösung erfüllen muss. Diese definieren den Projektumfang.
→ Bei Großprojekten bietet sich eine Aufteilung des gesamten Projektumfangs in Stufen an – sie verkürzt
die Zeit bis zum Eintritt des ersten Nutzens und schafft damit durch frühe Erfolge Vertrauen bei den Stakeholdern, was wiederum zur Stabilität des Projektumfangs beiträgt (Quick Wins). Außerdem erlaubt sie eine
Fokussierung auf die dringendsten Elemente und reduziert die Komplexität und damit das Implementie rungsrisiko je Stufe.
Aufteilung des Projekts in Stufen
Erstellung einer Grobplanung für das Projekt
Ein weiteres operatives Ziel der Disziplin „Festlegung/Überprüfung der Projektrahmenbedingungen“ liegt in
der Erstellung einer abgestimmten Grobplanung für das Projekt. Die Grobplanung soll in folgenden Parametern erste Festlegungen enthalten:
●
Abschätzung und Freigabe von Budget bzw. Aufwand. Was ist der grobe Aufwand für Konzeption
und Erstellung der umrissenen Lösung, welche weiteren Kosten (Hardware, Training) entstehen?
●
Wichtigste Termine/Meilensteine. Wann sollen die verschiedenen Ausbaustufen der Lösung in den Betrieb gehen? Wie viel Zeit ist vorzusehen z.B. für die Vergabe, das heißt für Auswahl und Beschaffung
der Lösung (Software, Implementierungsleistungen)?
●
Verantwortlichkeits- und Eskalationsmodell. Wer sind die Verantwortlichen im Projekt (auf Auftraggeber- und -nehmerseite), wofür sind sie genau verantwortlich und wer ist die Eskalationsinstanz, falls
sich der Erfolg nicht einstellt?
●
Vorgehensmodell. Welches Vorgehen ist für die vorgesehene Lösung angemessen?
Die hier beschriebene Disziplin „Festlegung/Überprüfung der Projekt-Rahmenbedingungen“ operiert hauptsächlich zu Beginn des Projekts in der Anbahnungsphase, unterstützt danach aber auch die periodische Über prüfung, die im laufenden Projektmanagement in anderen Disziplinen behandelt wird, z.B. das Management
des Projektumfangs im Anforderungs- und Änderungsmanagement (siehe Kapitel Anforderungs- und Änderungsmanagement).
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
39
5.1.2 Rollen: Wer macht was bei der Festlegung der Rahmenbedingungen?
Im Rahmen der Festlegung und Überprüfung der Rahmenbedingungen sind folgende Rollen vorzusehen:
(Haupt-)Projektsponsor/
Projektauftraggeber
Treibende Kraft der Projektanbahnung – derjenige, der eine ungefähre Idee in eine konkrete
Motivation verwandelt, der das Projekt während der Laufzeit wahrnehmbar fördert, der ggf.
den Prozess der Projektanbahnung initiiert und lenkt - wird später oft Projekteigner
● Stellt meist das Budget
● Zumeist Mitglied der obersten Führungsebene, das (andere) Mitglieder der obersten
Führungsebene für das Projekt begeistert, die Begeisterung am Leben hält und in
Mitwirkung und Verantwortungsübernahme umwandelt
● Gegebenenfalls Präsentation des Projekts
Weitere maßgebliche
Projektstakeholder und
Projektsponsoren
Tragen das Projekt mit; steuern ggf. Budget bei, übernehmen ggf. Verantwortung für die
identifizierten Nutzenpotenziale, sind ggf. Kunden der entstehenden Lösung
● Unterstützen das Projekt bei der obersten Organisationsleitung, z.B. im
Genehmigungsprozess
● Steuern Budget und Ressourcen bei (Projektmitarbeiter, Expertise etc.)
● Übernehmen Verantwortung für die sie betreffenden Nutzenpotenziale
● Sind als Kunden der entstehenden Lösung am Erfolg und an der Ausrichtung des
Projekts an ihren Anforderungen/Bedürfnissen interessiert
Treiber der
Projektanbahnung
Bereitet in Projektleitungsfunktion das Projekt vor – wird später oft Projektleiter
● Prozessmanagement in der Festlegung der Projektrahmenbedingungen (Dokumentation
von Zielen und Lösungsparametern, Abstimmungsprozesse zwischen Stakeholdern)
● Durchführung und Review der Grobplanung (erster Teil)
● Erstellung von Genehmigungsunterlagen
Projekteigner
Verantwortet das Projekt als Ganzes während der Projektlaufzeit - ist häufig identisch mit
dem Projektauftraggeber bzw. (Haupt-)Projektsponsor
● Schnittstelle des Projekts zur Organisation
● Verantwortet Projektbudget während nach der Projektgenehmigung
● Ist erster Ansprechpartner des Projektleiters
Projektleiter
Wird häufig erst im Laufe der Projektanbahnung (offiziell) benannt und übernimmt von da an
Verantwortung für Lösungsdefinition und Grobplanung
● Finalisiert Lösungsdefinition und Grobplanung
● Stellt Kernmannschaft nach Projektgenehmigung zusammen
● Überprüft kontinuierlich die Rahmenbedingungen, initiiert gegebenenfalls einen
Aktualisierungsprozess
Experten und Externe
Werden vom Treiber der Projektanbahnung herangezogen, um Lösungsoptionen
vorzuschlagen und bei Spezialthemen wie Budgetschätzung zu unterstützen
● Steuern z.B. Marktkenntnis zu Lösungsalternativen und Methodenkenntnis zur
Aufwandsschätzung bei
Tabelle 5: Rollen und Verantwortlichkeiten im Rahmen der Festlegung/Überprüfung der Projektrahmenbedingungen
5.1.3 Ergebnisse: Welche Dokumente sollen erstellt werden?
Projektvorstudie
Das Ergebnisdokument eines Vorprojekts, die Projektvorstudie, sollte folgende Fragen beantworten:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
40
5 Disziplinen zum Management der strategischen Ausrichtung
●
Ergibt das Projekt strategisch Sinn für die beteiligte(n) Organisation(en), passt es bezüglich Zielen und
Umfang zur geschäftspolitischen Ausrichtung (oder investiert/investieren die Organisation(en) unverhältnismäßig viele Ressourcen (Zeit und Geld) in „Nebenkriegsschauplätze“)?
●
Wird das Projekt durch gesetzliche Vorgaben erzwungen oder liefern diese lediglich einen Vorwand für
das Projekt?
●
Könnten die Ziele des Projekts auch mit einer deutlich weniger komplexen Herangehensweise erreicht
werden oder erscheint das Projekt als Selbstzweck?
●
Kann der Nutzen des Projekts gemessen werden oder ist er lediglich „strategisch“?
●
Sind die Kosten des Projekts mit hinreichender Sicherheit abzuschätzen (ohne an dieser Stelle bereits
quantifiziert zu werden) oder drohen z.B. wegen notwendiger technischer Pionierleistungen unvorhersehbare Kostenaufschläge?
●
Ist die Organisation in der Lage, ein Projekt mit derartiger Komplexität zu stemmen (Zeit, Ressourcen,
Fähigkeiten)?
●
Gibt es Stakeholder, die ein solches Projekt zum Erfolg treiben wollen und auch operative Verantwor tung dafür übernehmen, auch über die gesamte absehbare Laufzeit des Projekts hinweg?
●
Gibt es Stakeholder, die ein Interesse am Scheitern des Projekts hätten (beispielsweise weil Aufgaben verlagerungen geplant sind) und lassen sich diese politischen Risiken eingrenzen?
Im Rahmen der sich anschließenden Projektanbahnung existieren die folgenden Dokumente:
Machbarkeitsanalyse
Betritt das Projekt technisches Neuland, setzen viele Entitäten darüber hinaus auf eine förmliche Machbar keitsanalyse. Die Machbarkeitsanalyse, gegebenenfalls ergänzt um Antworten aus dem Vorprojekt, beantwortet die Frage nach möglichen Lösungsvarianten, deren Durchführung und gegebenenfalls die Fragen, ob und
welche Teile des Projekts extern vergeben werden sollten und in welchen Fällen eine Eigenentwicklung sinnvoll ist. Darüber hinaus beleuchtet die Analyse, wo mögliche technische Probleme des Projekts liegen, und
beugt so unliebsamen Überraschungen vor.
Eine Machbarkeitsanalyse sollte folgende Fragen behandeln:
●
Wie sollte der optimale Schnitt für die Bestandteile des Projekts aussehen und welche Pakete lassen
sich definieren, für die die Frage des „make or buy“ beantwortet werden kann?
●
Welche fachlichen und nicht fachlichen Anforderungen entscheiden über die Machbarkeit des Projekts?
●
Welche Lösungsvarianten sind denkbar? Welche Sensitivität besteht bei den einzelnen Varianten im
Bezug auf eine mögliche Änderung der Grundannahmen (z.B. Anzahl der Nutzer, gesetzliche Änderun gen)? Ist eine Variante z.B. auch dann noch im Lösungsraum, wenn sich die Nutzeranzahl verdoppelt?
●
Gibt es gegebenenfalls verfügbare Standardsoftware? Wie ist diese zu bewerten gegenüber Individualsoftware? Ist es möglich, unterschiedliche Anbieter zu beauftragen? Wie muss das Vergabeverfahren
aussehen?
●
Welche Anbieter gibt es und was bieten diese an? Welche Mindestanforderungen sind zu stellen? Welche Kriterien gibt es, nach denen der Anbieter ausgewählt werden sollte und in welchem Verhältnis stehen diese zueinander? Wie sind die unterschiedlichen Anbieter in Hinblick auf diese Kriterien zu bewerten?
→ In der öffentlichen Verwaltung muss dabei insbesondere auf die Vergaberichtlinien eingegangen werden.
Insbesondere gilt dies für Anbieterempfehlungen und die Beschreibung der Anforderungen, da Letztere so
präzise sein müssen, dass eine hinreichende Beschreibung des Produktes gegeben ist, aber noch kein bestimmter Anbieter gesetzt ist (siehe Kapitel Vergabe- und Vertragsmanagement).
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
41
Vergaberichtlinien beachten
→ Die Sensitivität der möglichen Lösungsvarianten bezüglich möglicher Änderungen der Grundannahmen
ist in der öffentlichen Verwaltung ein sehr wichtiger Faktor, da gesetzliche Änderungen in kurzer Zeit zu einer enormen Änderung der Annahmen führen können. Beispielsweise kann dies im Bereich der Softwareentwicklung die Anzahl der Nutzer betreffen, wenn durch eine Gesetzesänderung eine Anwendung kurzfristig deutlich mehr Mitarbeitern zur Verfügung stehen muss. Dies kann auch die bereitgestellten Server- oder
Netzkapazitäten betreffen. Ein weiteres Beispiel sind Datenschutzanforderungen, die Sicherheitsanforderungen in kurzer Zeit deutlich verschärfen und somit zu einem starken Mehraufwand führen können.
Sensitivität wichtiger Faktor
Da eine Machbarkeitsanalyse umfangreiche technische Expertise und Marktkenntnis erfordert, wird sie zu meist von externen Experten durchgeführt.
→ Insbesondere bei Großprojekten in der öffentlichen Verwaltung hilft eine externe Machbarkeitsanalyse
auch in der Kommunikation und im Stakeholder-Alignment nach innen und außen, da Chancen und Risiken
von Varianten abgewogen werden und die Entscheidung für eine Lösungsoption klar nachvollziehbar ist.
Machbarkeitsanalyse zur Außenkommunikation nutzbar
Genehmigungsdokumente (Projektauftrag)
Nach Durchführung der Vorprüfung ist ein wesentliches administratives Ergebnis in der Projektanbahnung
die offizielle Genehmigung des Projekts, die oft in Form eines Projektauftrags erfolgt.
→ In vielen Entitäten sind für den Genehmigungsprozess Standardformulare mit festen Gliederungen definiert, die dann wesentliche Ergebnisdokumente (EN-502) sind (z.B. Projektanträge, Projektaufträge, Projekthandbücher, WiBe). Auch der Prozess selbst ist häufig definiert, insbesondere bei Entitäten mit etabliertem Multiprojektmanagement.
Vorgeschriebene Standardformulare einbeziehen
Zusätzlich werden bei dieser Methode vier weitere Dokumente für diese Projektphase empfohlen, die insbesondere der vereinfachten Kommunikation und damit dem Alignment dienen. Je nach Organisation und Projekt können diese Dokumente auch Bestandteil des Projektauftrags sein.
Projektmotivation und Projektziele sowie Projektgrundsätze
Hierbei handelt es sich zum einen um eine kurze Beschreibung, warum die Organisation das Projekt braucht
und wer davon welchen inhaltlichen Nutzen erwarten kann. Zum anderen enthält das Dokument eine Beschreibung der Ziele – was soll im Projekt erarbeitet werden und was ist die erwartete Wirkung der Lösung?
Diese Ziele werden im Dokument priorisiert, z.B. in Muss-, Soll- und Kann-Ziele. Schließlich werden auch
Projektgrundsätze definiert – sie wandeln die Prioritäten in einfache Entscheidungsregeln um, die es dem
Projektleiter später z.B. erlauben, anders lautende Erweiterungswünsche abzulehnen oder zwischen konkur rierenden Zielen abzuwägen.
Abbildung 18 und Abbildung 19 zeigen ein Beispiel von Projektmotivationen und -grundsätzen im Falle einer Eigenentwicklung im öffentlichen Sektor.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
42
5 Disziplinen zum Management der strategischen Ausrichtung
Abbildung 18: Beispiel Projektmotivationen für eine Eigenentwicklung
Abbildung 19: Beispiel für Projektgrundsätze einer Eigenentwicklung
Kosten-Nutzen-Analyse
Die Betrachtung des Nutzens und der Wirtschaftlichkeit fasst die finanziellen Auswirkungen der Lösung zu sammen – bewertete Kostentreiber als Projektbudget, denen bewertete Nutzentreiber der Lösung gegenüberstehen. Bei nicht monetären Nutzentreibern enthält die Betrachtung nur Beschreibungen der – möglichst
messbaren –Verbesserungen, die durch die Lösung entstehen.
Zusätzlich gibt die Betrachtung auch einen Überblick über das Thema und die Ziele, eine zusammenfassende
Definition und Abgrenzung sowie in Übersicht, welches Mitglied der obersten Leitungsebene für welche
Nutzenpotenziale verantwortlich ist – das Mitglied dokumentiert durch seine Unterschrift unter der Betrach tung, dass sie oder er sich persönlich für die Ausschöpfung dieser Potenziale verantwortlich zeigt, sofern eine
Lösung mit den vereinbarten Parametern zur Verfügung gestellt wird.
→ In Großprojekten ist ein gemeinschaftlich getragener Business Case ein wichtiges Mittel, das Alignment
zwischen den maßgeblichen Stakeholdern auch bei längeren Projektlaufzeiten zu sichern.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
43
Kosten-Nutzen-Analyse sichert Alignment
→ In der öffentlichen Verwaltung wird die Betrachtung des Nutzens und der Wirtschaftlichkeit mithilfe der
WiBe durchgeführt. Für die Festlegung weiterer Parameter, mindestens der Ziele, der Abgrenzung und der
Verantwortlichkeiten, werden zusätzliche Dokumente erstellt.
IT-WiBe enthält Kosten-Nutzen-Analyse
Projektcharta
Das Projekt wird in einer Projektcharta beschrieben – eine standardisierte Vorlage mit ca. 10 bis 15 Elemen ten, die den Charakter eines Vertrags zwischen Auftraggeber, Gesamtprojektleiter und weiteren Beteiligten
(z.B. Auftragnehmern für die Umsetzung) besitzt. Eine beispielhafte Projektcharta ist in der folgenden Abbil dung zu sehen.
Abbildung 20: Elemente der Projektcharta
Eine solche knappe Charta (mit den Einzelthemen Motivation, Ziele, wichtigste fachliche Anforderungen
und damit funktionale Lösungskomponenten, Kosten und Nutzen der verschiedenen IT-Lösungsoptionen sowie Projektvoraussetzungen und Abhängigkeiten) ermöglicht einen besseren Überblick und schafft damit
mehr Verbindlichkeit als (detaillierte) Teilbeschreibungen in unterschiedlichen Dokumenten (z.B. Projekthandbuch, Vertrag, zusätzliche Abstimmungsdokumente, vollständige Machbarkeitsanalyse).
Projektorganisation und Projektplan (grob) sowie Stakeholder-Übersicht
Die wichtigsten Stakeholder für das Projekt sowie die ersten Mitglieder des Kernteams werden in einem groben Projektorganigramm und einer Stakeholder-Übersicht aufgeführt, die noch keine Details über die interne
Projektstruktur enthalten. Außerdem fasst dieses Dokument die wichtigsten Termine und Meilensteine in ei ner Übersicht zusammen, in der auch die verschiedenen inhaltlichen Ausbaustufen dargelegt sind. Hier wird
auch das Vorgehen beschrieben, z.B. wesentliche Projektphasen (insbesondere das Vorgehen bis zur ersten
Produktivsetzung).
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
44
5 Disziplinen zum Management der strategischen Ausrichtung
5.1.4 Prozesse: Wie lassen sich die Rahmenbedingungen festlegen und prüfen?
Die Methodik zum Management der Rahmenbedingungen kennt vier Prozesse, die in Abbildung 21 aufgeführt sind: Durchführung Vorprojekt, Erreichen einer gemeinschaftlichen Zielvision, Grobplanung Projekt
sowie die laufende Überprüfung der Rahmenbedingungen.
Abbildung 21: Prozesse zum Management der Rahmenbedingungen
Vorprojekt
Im ersten Schritt muss die Sinnhaftigkeit des Projekts sichergestellt und anhand einfacher Fragen begründet
werden. Dazu können beispielsweise die oben vorgestellten Fragen dienen. Das Vorprojekt mündet in einer
Projektvorstudie und einer Entscheidung über das weitere Vorgehen.
Eine beispielhafte Entscheidungsvorlage zeigt Abbildung 22.
Abbildung 22: Entscheidungsvorlage über die Weiterführung eines Vorprojekts
In fünf Schritten zu einer gemeinschaftlichen Zielvision
1. Motivation und Lösungsvision für das Projekt umreißen
Zu Beginn des Projekts steht eine Idee, die dann in eine prägnante Motivation und Lösungsvision umzuwandeln ist. Eine gute Vision braucht nicht viele
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
45
Worte, wie etwa die Vision „Staufreies Ruhrgebiet“, denn sie vermittelt ein großes Ziel prägnant und auf verständliche Weise.
→ In IT-Großprojekten der öffentlichen Verwaltung steht der Sponsor dabei vor der Frage, ob er das Projektvorhaben als inkrementelle (risikoarme) oder als revolutionäre Verbesserung positionieren soll. Wenn
für den Erfolg (oder die Budgetbereitstellung) eine Mobilisierung von hochrangiger Politik und Öffentlichkeit nötig ist, funktionieren häufig nur revolutionäre Ansätze, die gleichzeitig – angesichts ihres inhärenten
Risikos – innerhalb der Organisation die größten Bedenken und Widerstände erzeugen. Als beste Kombination hat es sich erwiesen, ein Projekt zunächst als revolutionäres Großprojekt in der Mobilisierungsphase zu
positionieren, die Umsetzung und Lieferung dann aber über evolutionäre Schritte risikoarm zu gestalten.
Revolutionär in der Startphase, evolutionäres Vorgehen im Projekt
Motivation und Vision ermöglichen dem Projektsponsor die Mobilisierung von Unterstützung auf der obersten Leitungsebene, was die Voraussetzung dafür ist, in der Organisation überhaupt ein Projekt starten zu kön nen.
2. Treiber der Projektanbahnung identifizieren
Der Sponsor als Mitglied der obersten Leitungsebene benötigt zumeist selbst Unterstützung, um die erhebliche Arbeit erledigen zu können, die mit der Initiierung eines Projekts verbunden ist. Hierzu sucht er einen
Treiber – idealerweise den künftigen Projektleiter. Je nach Anforderungsprofil sind aber auch andere Treiber
denkbar (z.B. ein in Budgetierungs- oder Vergabeprozessen bewanderter Mitarbeiter, wenn zur Projektanbahnung entsprechende Kompetenzen vonnöten sind).
3. Interessen/Ziele/Prioritäten der maßgeblichen Stakeholder analysieren
Auf dem Weg zu gemeinschaftlich verabschiedeten Projektzielen ist es unabdingbar, ein Alignment der maßgeblichen Stakeholder zu erreichen. Transparenz hinsichtlich ihrer jeweiligen Interessenlage ist dabei die Basis: Gewinnen oder verlieren sie bei dem Projekt? Was erhoffen sie sich? Das Alignment lässt sich z.B. durch
die Nutzung eines „Alignment Framework“ erzielen (EN-503) – hier wird allerdings nur eine verkürzte Fassung davon wiedergegeben.
Ein Beispiel aus einem Projekt, dass das Detailvorgehen im Stakeholdermanagement vorstellt, findet sich in
Abbildung 23: Im Rahmen der Projektanbahnung ist ein solches Vorgehen sicherlich zu ausführlich, die Kernideen sollten jedoch erhalten bleiben.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
46
5 Disziplinen zum Management der strategischen Ausrichtung
Abbildung 23: Detailvorgehen im Stakeholdermanagement
Bei der Identifikation der maßgeblichen Stakeholder stehen zwei Fragen im Mittelpunkt:
●
Wer wird als Unterstützer gebraucht, damit das Projekt ein Erfolg wird (z.B. weil er/sie die notwendigen
Änderungen durchsetzen kann)?
●
Wer kann bei Nichteinbindung oder bei offener bzw. verdeckter Opposition den Projekterfolg gefährden?
Die für das Projekt maßgeblichen Stakeholder können etwa mit Hilfe der beiden folgenden Listen identifiziert werden, die allgemeine und spezielle Stakeholder aufführen.Allgemeine Stakeholder sind:
●
Mitglieder der obersten Leitungsebene/Geschäfts- und Behördenleitung
●
Nutzer
●
Direkte und andere Vorgesetzte der Nutzer
●
Betroffene (z.B. Mitarbeiter, deren Aufgaben durch die neue Lösung wegfallen)
●
Beteiligte (alle anderen Mitarbeiter)
●
Lieferanten.
→ Weitere typische Stakeholder für IT-Großprojekte in der öffentlichen Verwaltung sind:
●
Politische Ebene des Auftraggebers/des Sponsors
●
Politische Ebene oberhalb des Auftraggebers/Sponsors
●
Politische Ebene neben dem Auftraggeber/Sponsor
●
Vertreter der Ressorts, der Bundesländer etc.
●
Rechnungshof
●
Interne Revision
●
Personalvertretungen/-räte
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
●
Beauftragte für den Datenschutz/Datensicherheit
●
Gleichstellungsbeauftragte
●
Beauftragte für Menschen mit Behinderung (z.B. wegen Barrierefreiheit)
●
Einzelne Mitarbeiter, die viel Gehör finden.
47
Typische Stakeholder in der öffentlichen Verwaltung
Viele Stakeholder neigen dazu, ihr Beauftragungsgebiet gegenüber anderen Themen und dem Projektziel hö her zu priorisieren als vielleicht objektiv notwendig – in diesen Fällen hilft nur die Definition eines Anspruchsniveaus für die Projektziele (statt „maximale Datensicherheit“ eher „Umsetzung von Sicherheitsstandards, die sich in anderen Projekten von vergleichbarer Komplexität, Sensibilität und Größe bereits bewährt
haben“).
Für jeden identifizierten Stakeholder werden dann dessen Interessen, Ziele und Erwartungshaltungen analysiert und grob dokumentiert (Vorsicht bei der Niederschrift sensibler Sachverhalte!). Hierbei hilft eine Einteilung der Stakeholder in Nutznießer, Neutrale und Opponenten.
Aus der Gegenüberstellung der Stakeholder-Interessen sollten mögliche Zielkonflikte deutlich werden: Wo
steht ein Stakeholder? Wo sollte er stehen, damit das Projektziel erreicht werden kann?
4. Gemeinsame Zielvision und Projektgrundsätze erstellen und abstimmen
Die Stakeholder müssen dann bilateral vom Sponsor oder Treiber bzw. designierten Projektleiter eingeladen
werden, das Projekt zu unterstützen – eventuell mit Ermutigung der obersten Leitungsebene. In bilateralen
Gesprächen gilt es, Erwartungshaltung und Zielkonflikte mit anderen Stakeholdern offen anzusprechen und
den gemeinsamen Umgang damit festzulegen.
In den bilateralen Gesprächen bzw. Interviews sind auch die individuellen Prioritäten und Erwartungen der
Stakeholder an das Projekt (z.B. Grad der Einbindung) und an die Lösung (z.B. spezifische Funktionalitäten)
zu erheben, so dass die anschließende Dokumentation der Zielvision die Interessen aller Stakeholder reprä sentiert.
→ In IT-Großprojekten der öffentlichen Verwaltung stehen Qualitätsziele wie „Verbesserung der Kundenorientierung“ oder „Verringerung der Fehlerrate“ oder sogar politische Ziele („Verbesserung der
Sicherheit“) häufig eher im Mittelpunkt als Effizienzziele, die auf der Einsparung von (Personal-)Ressourcen beruhen. Zumindest Qualitätsziele sollten aber messbar formuliert werden. Bei politisch motivierten
Projekten benennt die Zielvision den „Political Case". Allgemein gilt für die Ziele (und später für den Nutzen) bei Projekten in der öffentlichen Verwaltung: Klarheit siegt! Grundsätze für die Ziel- und Nutzendefi nition sind in Abbildung 24aufgeführt.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
48
5 Disziplinen zum Management der strategischen Ausrichtung
Abbildung 24: Ziel und Nutzen in der öffentlichen Verwaltung
Umgang mit Zielen der Qualität und der Politik
5. Entscheidungsregeln bei Ziel- und Prioritätskonflikten festlegen
Aus dem Kreis der Stakeholder formiert sich anschließend meist auch der LA des designierten Projekts, der
fortan das oberste Entscheidungsgremium darstellt.
Der LA billigt dann z.B. das Dokument mit Projektmotivation, Zielen und Projektgrundsätzen. In diesem
Dokument sollten auch die bei den Stakeholder-Analysen und -Interviews aufgetretenen Konflikte offen dokumentiert werden, ebenso sollte die designierte Projektleitung einen Vorschlag zum Umgang mit diesen
Konflikten machen (z.B. “Über das Minimalmaß hinausgehende Anforderungen zum Berichtswesen werden
erst umgesetzt, wenn die grundlegende Transaktionsplattform etabliert ist“).
Vielfach sind solche Zielkonflikte nicht mit einer einmaligen Entscheidung gelöst. Der LA sollte aus diesem
Grunde ein Eskalationsmodell verabschieden – wer ist zu involvieren, wenn eine Ebene im Projekt keine Ei nigung erzielen kann?
In fünf Schritten zu einer Grobplanung des Projekts
1. Groben Stufen- und Meilensteinplan definieren
In diesem Schritt wird die Frage beantwortet, wann die verschiedenen Stufen der Lösung umgesetzt werden
sollen. Wie viel Zeit ist z.B. für die Vergabe vorzusehen, das heißt für die Auswahl des Lieferanten und die
Beschaffung der Lösung (Software, Implementierungsleistungen)?
Im Idealfall ist die Terminvorgabe entweder durch Inhalt und verfügbare Ressourcen bestimmt oder Inhalt
und Ressourcen richten sich nach der Terminvorgabe. Oft kann dies erst im Rahmen der Grobplanung ge schehen; es dient auch der Überprüfung, ob die durch Stakeholder/Auftraggeber vorgegebenen Termine und
Budgets miteinander in Einklang zu bringen sind.
Bei neuartigen Lösungen wird häufig zu diesem Zeitpunkt eine begleitende Machbarkeitsstudie durchge führt. Sie evaluiert mehrere Lösungsalternativen auf Basis der Projektziele in Bezug auf prinzipielle Eignung
sowie Vor- und Nachteile. Die Ergebnisse einer Machbarkeitsstudie fließen in die weitere Planung ein – sie
können wichtige Vorgaben für das Projekt umfassen, wie z.B. Mindestzeiten, inhaltlicher Lösungskorridor,
mögliche Mengengerüste oder auch Mindestbudgets.
2. Grobes Vorgehensmodell definieren
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
49
Gerade in Großprojekten ist das Vorgehensmodell nicht beliebig wählbar. Evolutionäre oder agile Methoden
eignen sich nicht für die Implementierungsphase eines Großprojekts – aber durchaus für die Spezifikationsphase (z.B. in Form eines Grobentwurfs nur der Benutzerschnittstelle – dieser kann zunächst auch einfach
auf Papier in einem Workshop entworfen werden).
Eine Machbarkeitsanalyse erfolgt im Rahmen des groben Vorgehensmodells und wird in der Regel von Ex perten ausgeführt. Sie beantwortet die Frage, welche der denkbaren Lösungsvarianten verfolgt werden sollte,
welche Risiken zu bedenken sind und wie die präferierte Lösung umgesetzt werden kann, also beispielsweise, in welchem Umfang Externe mit der Lösung beauftragt werden sollten.
In diesem Zusammenhang ist auch ganz allgemein der Umfang festzulegen, mit dem Externe im Projekt mitwirken sollen (siehe Kapitel Vergabe- und Vertragsmanagement).
3. Projektcharta erstellen
Die Projektcharta als Dokument fasst inhaltliche, finanzielle und technische Aspekte der Lösungs- und Pro jektdefinition zusammen und stellt damit eine Detaillierung/Konkretisierung der Projektziele dar.
Der inhaltliche Aspekt der Projektcharta umfasst wichtige funktionale Anforderungen und wird am einfachsten in einem ein- bis zweitägigen Workshop festgelegt. Hierbei definieren die designierte Projektleitung, die
wichtigsten Stakeholder und die Nutzervertreter, die Lösung möglichst greifbar. Wichtig ist dabei nicht nur
die Definition des geplanten Output (Gestalt der Lösung), sondern auch des Outcome (erwarteter, beobachtbarer Nutzen) und der übrigen Elemente einer erfolgreichen Zusammenarbeit im Projekt. Ein entsprechendes
Ergebnis eines solchen Workshops ist in Abbildung 25 aufgeführt.
Abbildung 25: Frühzeitig Erfolgsvoraussetzungen für das Projekt schaffen
Die Projektcharta soll auch die wichtigsten finanziellen Aspekte des Projekts aufnehmen. Hierfür werden die
Informationen aus der Kosten-Nutzen-Analyse herangezogen.
Schließlich zeigt die Charta auch die wichtigsten technischen Aspekte – insbesondere die wichtigsten Lö sungsoptionen, die etwa in der Machbarkeitsstudie evaluiert wurden (z.B. Aufbau einer neuen Lösung und
Identifikation möglicher Anbieter dafür, Weiterentwicklung einer bereits bestehenden Lösung oder organisatorische Umgestaltung ohne Änderungen an der IT).
4. Kosten-Nutzen-Analyse erstellen, Verantwortliche definieren
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
50
5 Disziplinen zum Management der strategischen Ausrichtung
Die Kosten-Nutzen-Analyse besteht aus zwei wesentlichen Teilen – zum einen aus der Kosten- und Budgetschätzung, zum anderen aus der Nutzenspezifikation.
Die Budgetschätzung zeigt, was der grobe Aufwand für Konzeption und Erstellung der umrissenen Lösung
ist und welche weiteren Kosten (Hardware, Training) entstehen. Für die Erstellung einer Budgetschätzung ist
eine detaillierte Methode in Kapitel Projektplanung dokumentiert.
Für die Nutzenspezifikation sind die Treiber des Nutzens zu identifizieren und zu quantifizieren sowie mit
Verantwortlichen (am besten aus dem Kreise der Stakeholder) zu verknüpfen. Eine finanzielle Nutzenbe trachtung ohne Kostenseite wird Brutto-Nutzen genannt.
Dieser wird dem Netto-Nutzen gegenübergestellt (der Nutzen, der nach Abzug der Projektkosten vom Brutto-Nutzen übrig bleibt) – damit beantwortet die Kosten-Nutzen-Analyse auch die Frage, wie viel das Projekt
maximal kosten darf, um noch einen Netto-Nutzen größer null zu produzieren.
Ebenso zeigt die Kosten-Nutzen-Analyse den Value at Risk, das heißt die Schadenssumme aus Kosten und
entgangenem Netto-Nutzen, wenn das Projekt scheitert, seine Kosten überschreitet oder der Nutzen später
oder in verringertem Maße eintritt. Ein Modell zur Berechnung des Value at Risk findet sich in Abbildung
26.
Abbildung 26: Berechnungsmodell des Value at Risk
→ Neben quantifizierbaren Nutzentreibern (z.B. Effizienzsteigerungen gegen eine etablierte Kostenbasis)
weisen IT-Projekte der öffentlichen Verwaltung häufig qualitative Nutzenpotenziale auf. In solchen multidi mensionalen Nutzenfunktionen entstehen dann leicht Zielkonflikte: Die Maximierung einer Dimension li mitiert z.B. die Maximierung einer anderen. Solche Konflikte sind durch die Definition von Anspruchsniveaus in der Kosten-Nutzen-Analyse einzugrenzen. In der Kommunikation und im späteren Management solcher qualitativen Nutzenpotenziale, insbesondere in den operativen Prozessen, bietet sich das visuelle Nut zenmanagement an – hier werden die Verbesserungen visuell in den Geschäftsprozessen verortet und damit
greifbar gemacht. Ein Beispiel findet sich in Abbildung 27.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
51
Abbildung 27: Visuelles Nutzenmanagement
In Zielkonflikten helfen Anspruchsniveaus
→ In großen Projekten ist die neue Lösung nicht für jede Anwendergruppe nur mit Vorteilen verbunden –
für die Verminderung möglichen Widerstands muss das Projekt eine Nutzenkommunikation je Anwendergruppe aufbauen. Im Minimum muss das Projekt eine Anwendergruppe, die selbst keine Vorteile aus dem
Projekt zieht, mit Verweis auf die übergeordnete Sicht überzeugen.
Anwendergruppen durch Kommunikation des Gesamtnutzens überzeugen
→ In Großprojekten allgemein und insbesondere in der öffentlichen Verwaltung werden die Kosten eines
Projekts oft unterschätzt, der Nutzen dagegen überschätzt. Neben den allgemeinen Kostensteigerungen ergibt sich bei Projekten der öffentlichen Verwaltung häufig ein besonders hoher Aufwand für Koordination
und Entscheidungsfindung, auch treten gesetzliche Änderungen häufiger auf. Auf der Nutzenseite ist als
Ursache insbesondere die mangelnde Verankerung allgemeiner wirtschaftlicher Ziele in den Zielvereinbarungen der Manager zu nennen.
Unter- und Überschätzung von Kosten und Nutzen vermeiden
→ Solche Abweichungen zwischen Ziel und tatsächlichem Ergebnis werden oft zu spät erkannt oder sogar
ignoriert. Daher ist in der öffentlichen Verwaltung besonders auf realistische und machbare Vorgaben zu
achten.
Ziele realistisch und machbar gestalten
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
52
5 Disziplinen zum Management der strategischen Ausrichtung
5. Projekt- und Mittelgenehmigung erreichen
Am Ende der Anbahnung steht der förmliche Start für das Projekt durch eine Genehmigung seitens der Poli tik oder der Leitung. Grundlage sind dafür die in den vorausgegangenen Schritten erstellten Dokumente.
→ Großprojekte in öffentlichen Organisationen, die eine Mindestbudgetsumme überschreiten, sind formal
zu genehmigen, z.B. in Organen der Selbstverwaltung, durch übergeordnete Behörden oder in internen Gremien.
Großprojekte sind formal zu genehmigen
→ Damit das Projekt auch während einer langen Laufzeit über ausreichend Mittel verfügen kann, ist zu Be ginn eine vollständige Budgetfreigabe anzustreben. Diese muss sowohl auf der Ebene des Gesamtbetrags
als auch auf der Ebene von Jahresbudgets erfolgen, häufig noch aufgeteilt in haushaltswirksame und nicht
haushaltswirksame Anteile. Ein Teil des Budgets (ca. 20 bis 30%) sollte unbedingt als Risikopuffer für un geplante Änderungen vorgehalten und nicht von vornherein verplant werden.
Budgetfreigabe sollte vollständig sein
→ Stehen Budgetmittel später nicht ausreichend oder zeitnah zur Verfügung, kommt das Projekt ins Stocken, mit ernsthaften Konsequenzen – z.B. kann ein zugesagter Zieltermin nicht eingehalten werden, ob wohl er etwa gesetzlich festgelegt oder politisch zugesagt ist. Können vereinbarte Termine für die Nutzung
von Ressourcen nicht eingehalten werden, verstreichen schnell Verfügbarkeits-Zeitfenster und anderweitig
verplante Ressourcen gehen dem Projekt verloren, verbunden mit Know-how-Verlust (darauf hat das Projekt, gerade bei internen Mitarbeitern, normalerweise keinen Einfluss). Ebenso führt eine Verlängerung der
Laufzeit häufig zu höheren Kosten (mehr Personal für Querschnittsfunktionen, Infrastruktur, Lizenzkosten
etc.).
Fehlende Budgetmittel können ein Projekt verzögern, z.B. wegen Abziehen von Ressourcen
→ Mit der Mittelbeschaffung für ein Projekt ist rechtzeitig zu beginnen, da hier häufig Verzögerungen eintreten. Die Schwerfälligkeit in Bezug auf die Budgetallokation zeigt sich oft auch im Laufe des Projekts: Ist
das Budget einmal im Haushalt reserviert, gibt es wenig Anreiz, ein Projekt auch bei geänderten Rahmenbedingungen und damit ausbleibendem Nutzen zu stoppen. Das Budget ist dann für den Auftraggeber nicht
mehr verfügbar oder kann anderweitig nur schwer verwendet werden. Deshalb ist die Hemmschwelle, ein
Projekt zu stoppen, sehr hoch.
Budgetallokation rechtzeitig beginnen
Laufende Prozesse: periodische Überprüfung der Projektrahmenbedingungen
Im Lebenszyklus eines Projekts wandelt sich der Fokus der Betrachtung: von Zielen über Anforderungen,
Spezifikationen sowie Lösungen hin zu Verhaltensänderungen. Wenn sich Projektrahmenbedingungen ändern, und damit die Ziele nur noch durch andersartige Lösungen erreicht werden können, müssen die Anforderungen, Spezifikationen und Lösungen entsprechend angepasst werden.
Der Prozess der periodischen Überprüfung dient der Projektleitung dazu, einen solchen Änderungsbedarf zu
erkennen und die nötigen Entscheidungsprozesse zur Aktualisierung anzustoßen. Der Prozess gliedert sich in
drei Aufgaben: Projektziele auf Relevanz und Erreichbarkeit prüfen, Alignment der maßgeblichen Stakehol der sichern sowie Ziele, Projektumfänge, Terminpläne und Budgets gegebenenfalls aktualisieren.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.1 Festlegung/Überprüfung der Projektrahmenbedingungen
53
1. Projektziele auf Relevanz und Erreichbarkeit prüfen
Ändern sich die Rahmenbedingungen des Projekts, z.B. durch gesetzliche Änderungen, muss die Projektlei tung die Auswirkungen auf die eigenen Ziele analysieren und überprüfen. Ebenso ist zu prüfen, ob der ge plante Nutzen mit der Erfüllung des Projektziels noch in der ursprünglichen Form gegeben sein wird – eventuell haben Anwender mittlerweile alternative Lösungsmöglichkeiten gefunden oder erhalten, die die Notwendigkeit des Projekts in Frage stellen.
Die Überprüfung der Projektziele erfolgt durch die Projektmanagement-Disziplin Projektplanung, und zwar
im Rahmen der dort laufenden Planungs- und Controllingaktivitäten. Methodisch können hier die entsprechenden Prüffragen hinsichtlich Projektzielen, Kosten-Nutzen-Analyse und Projektumfang zum Einsatz
kommen, die im Kapitel Statusprüfung der Erfolgsfaktoren beschrieben und im Dokument „S-O-S-Fragebogen zur Ermittlung des Projektstatus“ aufgeführt sind.
→ Dieser Prozess wird hier so explizit und detailliert erwähnt, weil es in der öffentlichen Verwaltung häu fig vorkommt, dass Ziele, Anforderungen und Spezifikationen nach Abschluss der entsprechenden Projekt phase nicht mehr in Frage gestellt werden.
Projektziele regelmäßig prüfen
2. Alignment der maßgeblichen Stakeholder sichern
Die Stakeholder auf das gemeinsame Ziel einzuschwören, ist keine einmalige, sondern eine kontinuierliche
Aufgabe, die im Rahmen der Ausführungen zum Kommunikationsmanagement (Kapitel Kommunikationsmanagement) ausführlich erläutert wird.
Neben der zielgerichteten Kommunikation sind allerdings auch regelmäßige bilaterale Gespräche des Pro jektleiters mit den maßgeblichen Stakeholdern unabdingbar, am besten in Form von Jours fixes. In diesen
soll nicht der Projektstatus vorgestellt werden, sondern die gemeinsame Reflexion und Diskussion von Designentscheidungen, Risikofaktoren und Prioritäten im Mittelpunkt stehen. Für den Projektleiter ist das Zuhö ren das wichtigste Mittel, um beginnende Zielkonflikte oder Zweifel an der Sinnhaftigkeit des Projekts früh
erspüren und ergründen zu können.
Zur Überprüfung des Alignment eignen sich wiederum die entsprechenden Prüffragen, die in der S-O-SCheckliste „Festlegung der Projektrahmenbedingungen“ aufgeführt sind.
3. Ziele/Projektumfänge, Terminpläne und Budgets aktualisieren
Müssen Ziele oder sonstige Planungsparameter im Projekt geändert werden, gibt es verschiedene Handlungsmöglichkeiten, z.B. eine Reduzierung der vom Projekt zu liefernden Lösung (Descoping), das Hinterfragen
und Anpassen der (Qualitäts-)Ziele, die Berücksichtigung von Lösungen außerhalb des vorgegebenen Lösungskorridors (und damit eine Änderung der Kosten-Nutzen-Analyse), eine Reduzierung der Kosten, die
nochmalige Prüfung der Lösungsdetaillierung oder die Delegation nach oben an den LA mit dem Auftrag,
geänderte Rahmenbedingungen (z.B. einen gestreckten Terminplan) zu schaffen.
Die Notwendigkeit einer Änderung wird im Rahmen der Projektmanagement-Disziplin Planung erkannt, in
der regelmäßig geprüft wird, ob es zu Abweichungen von den vorgegebenen Rahmenbedingungen gekommen ist.
Letztendlich sollte das Projekt nur bei einer realistischen Erfolgschance weitergeführt werden. Hierfür muss
der Projektleiter die von den Stakeholdern zugesagten Rahmenbedingungen im Projektverlauf allerdings
auch einfordern.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
54
5 Disziplinen zum Management der strategischen Ausrichtung
5.1.5 Erfolgsmessgrößen: Woran kann der Auftraggeber hinreichend gut definierte
Rahmenbedingungen erkennen?
Die Überprüfung, ob die Rahmenbedingungen des Projekts hinreichend gut definiert wurden bzw. definiert
sind, erfolgt am einfachsten über die Prüffragen zur Statusbestimmung des Projekts im Themenfeld „strategische Ausrichtung“ (siehe Kapitel Statusprüfung der Erfolgsfaktoren).
Eine entsprechende Analyse sollte keine roten Warnampeln und auch keine dauerhaft gelben Ampeln aufzei gen.
5.1.6 Grundlegende und weiterführende Literatur
●
John Ward, Elizabeth Daniel: „Benefits Management – Delivering Value from IS & IT Investments“, Wiley Series in Information Systems 2006
●
Peter Weill, Jeanne W. Ross: „IT Governance – How Top Performers Manage IT Decision Rights for Superior Results“, Harvard Business School Press 2004
5.2 Vergabe- und Vertragsmanagement
Das folgende Kapitel enthält Hinweise auf großprojektspezifische Aspekte des Vergabe- und Vertragsmana gements. Vergaberecht und Vertragsgestaltung unterliegen strengen Regularien, die unter anderem in den fol genden Verordnungen und Bestimmungen geregelt sind:
●
VgV: Vergabeverordnung, Verordnung über die Vergabe öffentlicher Aufträge
●
VOL/A, VOL/B, VOF: Verdingungsverordnung für Leistungen
●
EVB-IT (EN-504): Ergänzende Vertragsbedingungen für die Beschaffung von Informationstechnik
Weitere hilfreiche Unterstützung liefert die
●
UfAB: Unterlage für Ausschreibung und Bewertung von IT-Leistung (EN-504).
Für das Vergabe- und Vertragsmanagement muss daher ein Vergaberechtsexperte hinzugezogen werden, der
die oben genannten Regularien und Hinweise kennt.
Die weiterführende Literatur zu den Regularien findet sich in Kapitel Grundlegende und weiterführende Literatur.
5.2.1 Ziele und Rahmenbedingungen: Was soll im Vergabe- und Vertragsmanagement
erreicht werden?
Ein gelungenes Vergabe- und Vertragsmanagement beeinflusst vor allem den Erfolgsfaktor „Robuste Ver tragsgrundlage“. Zu den Aufgaben des Vergabe- und Vertragsmanagements gehören: die Auswahl von externen Auftragnehmern - in der Regel mit Dienst- oder Werkvertrag -, der Vertragsabschluss einschließlich der
Festlegung der vertraglichen, rechtlichen und weiteren Rahmenbedingungen für die Beziehung zwischen
Auftraggeber und externen Auftragnehmern, die Schaffung von Transparenz über die projektrelevanten Verträge und deren Inhalte sowie die Überwachung der Vertragseinhaltung, also der Erfüllung der vertraglich
vereinbarten Leistungen.
●
Auswahl von externen Auftragnehmern (EN-505): Ausgangspunkt ist die Entscheidung, welche Teile
des Projekts an externe Auftragnehmer vergeben werden sollen bzw. müssen. Diese Teile werden ausgeschrieben. Im Zuge des Vergabeverfahrens werden der oder die externen Auftragnehmer ausgewählt.
Eine entscheidende Rolle spielt die Definition des Kriterienkatalogs. Dieser ist so zu gestalten, dass das
wirtschaftlichste Angebot (von AN), das heißt die beste Relation aus Preis und Leistung bezogen auf den
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.2 Vergabe- und Vertragsmanagement
55
Ausschreibungsgegenstand, den Zuschlag erhält. Für Großprojekte sind die Anforderungen an die ausgeschriebene Leistung so zu gestalten, dass nur externe Auftragnehmer in die engere Wahl kommen, die in
der Lage sind ein Projekt von der Art und Größe des ausgeschriebenen mit hoher Wahrscheinlichkeit
zum Erfolg zu führen.
●
Vertragsabschluss einschließlich Festlegung der vertraglichen/rechtlichen Rahmenbedingungen
für die Beziehung zwischen Auftraggeber und externem Auftragnehmer: Es ist dafür zu sorgen, dass
alle relevanten Aspekte der Zusammenarbeit zwischen Auftraggeber und Auftragnehmer vertraglich fixiert werden. Ein klarer Vertrag legt die Basis für eine partnerschaftliche Beziehung, in der kein Vertragspartner bevorzugt oder benachteiligt wird und die beiden Partnern eine erfolgreiche und wirtschaftlich sinnvolle Durchführung des Projekts erlaubt.
●
Transparenz über die projektrelevanten Verträge und deren Inhalte: Das Vergabe- und Vertragsmanagement sorgt dafür, dass die Projektleitung jederzeit eine aktuelle Übersicht über die im Projekt rele vanten Verträge hat. Alle in den Verträgen vereinbarten Inhalte, z.B. Liefertermine, Zahlungsmeilensteine sowie Ablauf- und Erneuerungsfristen, werden übersichtlich aufbereitet.
●
Überwachung der Erfüllung der vertraglich vereinbarten Leistungen: Es wird sichergestellt, dass
die in den Verträgen vereinbarten Leistungen von beiden Vertragspartnern tatsächlich erbracht werden.
Zu diesem Zweck ist dafür zu sorgen, dass sich die vereinbarten Leistungen in den betreffenden Disziplinen des Projektmanagements wieder finden. So gehen die zu liefernden Ergebnisse in die Definition des
Projektumfangs ein, die abzunehmenden Ergebnisse werden im Abnahmemanagement berücksichtigt,
Liefertermine gehen in die Planung ein, vereinbarte Berichtszyklen werden im Kommunikationsmanagement berücksichtigt etc.
5.2.2 Rollen und Gremien: Wer macht was im Vergabe- und Vertragsmanagement?
Folgende Rollen sind für das Vergabe- und Vertragsmanagement relevant:
Projektleiter (des
Auftraggebers)
Verantwortung für Vertragseinhaltung auf Auftraggeberseite, formale Abnahme
● Sicherstellung der inhaltlichen Abnahme der vom externen Auftragnehmer gelieferten
Ergebnisse (siehe Anforderungs- und Änderungsmanagement)
● Formale Abnahme
Projektleiter (des externen
Auftragnehmers)
Gesamtverantwortung für die Vertragseinhaltung auf Seiten des externen Auftragnehmers
● Delegation der Aufgaben des Vergabe- und Vertragsmanagements an weitere
Projektmitarbeiter
Ausschreibungs- und
Vertragsverantwortlicher
Festlegung der ausschreibungsrelevanten Teile des Projekts
● Vorbereitung der Ausschreibung und Festlegung der Auswahlkriterien für die externen
Auftragnehmer
● Auswahl der externen Auftragnehmer
● Vertragsgestaltung und -abschluss unter Einbeziehung der verantwortlichen Mitarbeiter
beider Vertragsparteien
● Die Rolle des Ausschreibungsverantwortlichen ist normalerweise keine Projektrolle, da
dieser in der Projektanbahnungsphase agiert.
Vertragsadministrator (EN506)
Schaffung von Transparenz über Verträge und Vertragsinhalte
● Unterstützung bei der formalen Vertragsabwicklung, z.B. Rechnungsstellung, Anweisung
von Zahlungen, Prüfen von Fristen (z.B. für Lizenzerneuerung)
Tabelle 6: Rollen und Verantwortlichkeiten im Vergabe- und Vertragsmanagement
→ In einem Großprojekt ist der Gesamtprojektleiter verantwortlich für die Vertragseinhaltung. Auf Grund
der möglicherweise umfangreichen und komplexen Vertragswerke delegiert er die Prüfung und das Sicher -
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
56
5 Disziplinen zum Management der strategischen Ausrichtung
stellen der Einhaltung üblicherweise an das Qualitätsmanagement, denn dieses muss das Vertragswerk ohnehin zur Erarbeitung der Qualitätsziele, -kriterien und -maßnahmen kennen und prüfen. Der Vertragsadmi nistrator ist Mitarbeiter im PMO.
QS ist für die Vertragseinhaltung verantwortlich
5.2.3 Ergebnisse: Welche Ergebnisse sollen erstellt werden?
Wesentliche Ergebnisse des Vergabe- und Vertragsmanagements sind:
●
Vergabeunterlagen. Die Vergabeunterlagen (Ausschreibung) enthalten alle Informationen, die ein möglicher externer Auftragnehmer zur Einschätzung der zu liefernden Ergebnisse benötigt. Die Unterlagen
enthalten daher nicht nur die inhaltliche Spezifikation der zu liefernden Ergebnisse, sondern alle weite ren relevanten Rahmenbedingungen wie Termine, einzuhaltende Prozesse und Rahmenbedingungen etc.
Zu den Vergabeunterlagen gehören - je nach Vergabeart - etwa Leistungsbeschreibung, Bewertungsmatrix, Kriterienkatalog und EVB-IT-Vertrag.
●
Verträge. Ein Vertrag enthält Vereinbarungen, die für die Zusammenarbeit zwischen Auftraggeber und
externem Auftragnehmer wichtig sind. Dazu zählen vor allem die für den Vertrag relevanten Teile der
Vergabeunterlagen sowie des Angebots des ausgewählten Auftragnehmers. Ein Vertrag muss die EVB-IT
berücksichtigen (Ergänzende Vertragsbedingungen für die Beschaffung von Informationstechnik, siehe
Grundlegende und weiterführende Literatur).
●
Vertragsübersicht mit kaufmännisch relevanten Details zu Verträgen. Die Vertragsübersicht enthält
alle für das Projekt relevanten Verträge und deren Status (in Arbeit, abgeschlossen), wichtige zu beach tende kaufmännische Inhalte sowie Meilensteine (z.B. vereinbarte Lieferungen, Zahlungsmeilensteine)
und deren Status (offen, verzögert, erledigt). Im Fall von nicht vertragsgemäß erbrachter Leistung ist angegeben, welche Konsequenzen daraus resultieren (z.B. bei verzögerter Lieferung der neue zugesagte
Liefertermin, eventuell Zahlung von vereinbarten Vertragsstrafen).
●
Abnahme. Die Abnahme besteht aus mehreren Schritten und Dokumenten (Prüfprotokolle für die Liefe rungen, Abnahmeerklärungen einschließlich der Beurteilung der Lieferungen). Diese Dokumente belegen die formale Abnahme all jener Ergebnisse, für die eine Abnahme nötig und vorgesehen ist. Die Do kumente enthalten Listen der bei der Abnahme erkannten Fehler und offenen Punkte (Prüfprotokoll Lieferung) sowie die Vereinbarung über die Behebung der Fehler bzw. Lösung der offenen Punkte, z.B. mit
Termine/Versionen für die Fehlerbehebung, Vereinbarungen von Umgehungslösungen (Abnahmeerklärung).
5.2.4 Prozesse: Wie geht das Vergabe- und Vertragsmanagement vor?
Die Prozesse des Vergabe- und Vertragsmanagements sind in Abbildung 28 zusammengefasst.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.2 Vergabe- und Vertragsmanagement
57
Abbildung 28: Prozesse im Vergabe- und Vertragsmanagement
Verantwortlichkeiten und Rollen festlegen
Die Organisation des Vergabe- und Vertragsmanagements im Projekt erfolgt wie im Kapitel Rollen und Gremien: Wer macht was im Vergabe- und Vertragsmanagement? angegeben.
In der Projektanbahnungsphase ist die Vergabe vorzubereiten und durchzuführen. Der Auftraggeber muss
hierfür frühzeitig einen Ausschreibungsverantwortlichen aus seiner Organisation benennen.
→ In der öffentlichen Verwaltung sind die sich aus dem Vergaberecht ergebenden, teilweise erheblichen
Fristen zu beachten (siehe Abbildung 32).
Vergaberechtsfristen beachten
Vertragliche/Rechtliche Rahmenbedingungen festlegen
Vor Beginn der Vergabe ist zunächst festzulegen, welche Teile des Gesamtprojekts externe Auftragnehmer
übernehmen sollen. Im einfachsten Fall handelt es sich um die einmalige Lieferung von Standardprodukten
(Softwarelizenzen, Hardware), die ohne weitere Unterstützung durch den Lieferanten sofort im Projekt eingesetzt werden können. In komplexen Fällen werden Konzeptions- und Implementierungsarbeiten oder Prozessunterstützung ausgelagert, eventuell kombiniert mit einer nach Projektende fortlaufenden Betreuung
(z.B. Wartung einer Software).
Für jede durch externe Auftragnehmer zu erbringende Leistung ist ein Modell für die Zusammenarbeit
festzulegen. Dieses wird später im Vertrag berücksichtigt.
Im Rahmen des Modells muss der Auftraggeber entscheiden, in welcher Form und mit welcher Kapazität er
einen oder mehrere externe Auftragnehmer steuern kann. Eine rein formale Auftraggeber-Auftragnehmer-Beziehung ist sehr starr an vertraglichen Vereinbarungen orientiert, die Verantwortung für zu erbringende Leis tungen kann jedoch besser auf den Auftragnehmer übertragen werden. Dagegen ermöglicht eine Zusammenarbeit in gemischten Teams eine flexiblere Steuerung und engere Abstimmungen, die Übertragung von Ver antwortung auf den externen Auftragnehmer ist jedoch erschwert. Je nach Festlegung ist zu entscheiden, wel che Vertragsart für das Zusammenarbeitsmodell geeignet ist (Werkvertrag oder Dienstvertrag).
Wird im Vertrag ein Festpreis vereinbart, setzt dies voraus, dass alle Informationen für die Vergabe der Leistungen vorhanden sind. Ist dies nicht der Fall, sind also die Rahmenbedingungen und Anforderungen unklar,
ist es sinnvoll, zunächst eine Konzept- oder Spezifikationsphase zu planen und diese nach Aufwand abzurechnen. Auf Basis der dann ermittelten Rahmenbedingungen und detaillierten Anforderungen kann eine
Umsetzung zum Festpreis erfolgen. Wird trotz unklarer Rahmenbedingungen und Anforderungen ein FestS-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
58
5 Disziplinen zum Management der strategischen Ausrichtung
preis vereinbart, sollten die Annahmen, die den Vergabeunterlagen (Ausschreibung) und den zugehörigen
Angeboten und Verträgen zugrunde liegen, genau dokumentiert und im Projektverlauf regelmäßig verifiziert
werden. Außerdem ist bei unklaren Rahmenbedingungen und Anforderungen möglicherweise eine Vielzahl
kostenpflichtiger Änderungsanforderungen zu erwarten.
Unabhängig von den festgelegten Rahmenbedingungen sollte immer eine partnerschaftliche Zusammenarbeit auf Basis einer eindeutigen und klaren Vertragslage mit eindeutig definierten Rechten und Pflichten der
Vertragsparteien angestrebt werden. Nur so lässt sich sicherstellen, dass aufkommende Probleme zwischen
den Vertragsparteien einvernehmlich und fair gelöst werden können.
→ Abbildung 29 gibt einen Überblick über die Aspekte der partnerschaftlichen Zusammenarbeit privatwirtschaftlicher Unternehmen mit öffentlichen Auftraggebern.
Abbildung 29: Beziehungswandel: Vom Lieferantenmanagement zur partnerschaftlichen Zusammenarbeit
Vorteile einer partnerschaftlichen Zusammenarbeit
→ Für ein Großprojekt muss aus Auftraggebersicht explizit entschieden werden, wer die Gesamtverantwortung für die Erarbeitung eines komplexen, da aus mehreren Teilen bestehenden Projektergebnisses
trägt. Die folgenden Konstellationen sind möglich:
●
Ein externer Auftragnehmer fungiert als Generalunternehmer, der für die Lieferung aller Projektergebnisse verantwortlich zeichnet. Er liefert sämtliche Software, Hardware, Lizenzen und eventuell benötigte Unterstützung sowie Betreuung während des Projekts und danach. Da in der Regel ein einzelner
externer Auftragnehmer nicht über alle Kompetenzen verfügt, um eine umfassende Lösung zu liefern,
hat er die Aufgabe, Unterauftragnehmer einzubinden, die Teile der Ergebnisse liefern. Die Gesamtverantwortung bleibt aber für alle Ergebnisse beim Generalunternehmer.
●
Der Auftraggeber behält die Gesamtverantwortung für das Projektergebnis. Er übernimmt damit das
Management des Gesamtprojekts und bindet punktuell externe Auftragnehmer für einzelne Ergebnisse
oder Unterstützungsleistungen in die Projektarbeit ein. Der Auftraggeber übernimmt somit selbst die
Koordinationsaufgaben eines Generalunternehmers.
●
Mischformen, in denen der Auftraggeber die Gesamtverantwortung behält, jedoch größere zusammengehörige Pakete aus mehreren Einzelergebnissen an externe Auftragnehmer vergibt.
Welche Konstellation geeignet ist, hängt sehr stark vom Projekt sowie den Erfahrungen, Fähigkeiten und
der Personalausstattung des Auftraggebers ab. Die Kosten für eine Generalunternehmer-Konstellation sind
abzuwägen gegen Aufwand und Risiko, den bzw. das der Auftraggeber übernimmt. Abbildung 30 illustriert
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.2 Vergabe- und Vertragsmanagement
59
die bei einer Generalunternehmer-Konstellation erforderlichen Rollen und Prozesse.
Verteilung der Gesamtverantwortung zwischen AG und AN
→ In der öffentlichen Verwaltung legt der EVB-IT-System-Vertrag (EN-507) eine GeneralunternehmerKonstellation nahe. Das Zusammenspiel sämtlicher Projektergebnisse sollte bereits vertraglich abgesichert
sein, indem die Verantwortung für die Ergebnisse in eine Hand gelegt wird.
Abbildung 30: Rollen und Prozesse bei einer Generalunternehmer-Konstellation
Aus Auftraggebersicht ist ein projektübergreifendes Lieferantenmanagement erforderlich: Ziel ist es,
die Abhängigkeit von einzelnen Lieferanten zu vermeiden.
Vermeidung einer Lieferantenabhängigkeit
Ausschreibung durchführen
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
60
5 Disziplinen zum Management der strategischen Ausrichtung
Sind die durch externe Auftragnehmer zu erbringenden Leistungen festgelegt, erfolgt die Ausschreibung dieser Leistung. Insbesondere werden Bewertungs- und Ausschlusskriterien im Leistungsbereich festgelegt, die
sicherstellen, dass der externe Auftragnehmer die geforderte Leistung tatsächlich erbringen kann. Dabei wer den nicht nur technische und fachliche Kriterien zugrunde gelegt, die z.B. sicherstellen sollen, dass ein exter ner Auftragnehmer genügend Expertise in der fachlichen Domäne oder mit der vorgesehenen technischen Infrastruktur besitzt. Vielmehr muss der Auftragnehmer auch die Anforderungen an die Zusammenarbeit mit
dem Auftrageber erfüllen. So kann beispielsweise ein Kriterium sein, dass der Auftragnehmer Planungs- und
Controllinginformationen liefern soll.
Anhand der festgelegten Kriterien erfolgt die spätere Auswahl der externen Auftragnehmer.
→ In der öffentlichen Verwaltung wird anhand des Vergaberechts entschieden, in welcher Art und Weise
eine Ausschreibung zu erfolgen hat. Abbildung 31 liefert eine Übersicht über mögliche Vergabeverfahren.
Die Schwellenwerte (Grenze zwischen Unter- und Oberschwellenbereich bzw. zwischen nationaler und
EU-weiter Ausschreibung) liegen für Großprojektbudgets bei relativ niedrigen Euro-Beträgen. Die jeweils
gültigen Schwellenwerte können aus VOL/A und VOL/B ermittelt werden.
Abbildung 31: Hierarchie der Vergabeverfahrensarten in der öffentlichen Verwaltung
Vergaberecht entscheidet über Ausschreibungsart
→ Zu beachten ist insbesondere die Dauer, die für eine öffentliche Vergabe notwendig ist. Für Großprojekte
werden unterschiedliche Verfahren eingesetzt. Das nicht offene Verfahren eignet sich insbesondere bei besonderer Geheimhaltungspflicht (z.B. aus militärischen Gründen) und bei sehr speziellen Produkten, die
nur von wenigen Unternehmen geliefert werden können. Das Verhandlungsverfahren hingegen eignet sich
für komplexe Dienstleistungen, bei denen der Vertragsgegenstand bzw. die zu erbringende Leistung nicht
hinreichend deutlich durch den Auftraggeber beschrieben werden kann. Dieses Verfahren darf ausschließ lich bei Vorliegen eines der in der VOL/A abschließend aufgeführten Ausnahmetatbestände durchgeführt
werden. Abbildung 32 gibt eine Übersicht über die in diesen Verfahren zu beachtenden Fristen (Auszug).
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.2 Vergabe- und Vertragsmanagement
61
Abbildung 32: Mindestfristen (in Kalendertagen) bei Vergaben im Oberschwellenbereich – nicht offenes
Verfahren und Verhandlungsverfahren (EN-508)
Zeitraum für Vergabeverfahren beachten
Externe Auftragnehmer auswählen und Verträge schließen
Schließlich werden die Angebote der potenziellen Auftragnehmer anhand der zuvor festgelegten Kriterien
ausgewertet und die Auftragnehmer ausgewählt.
Wird vor Vertragsabschluss verhandelt, so ist sicherzustellen, dass Auftraggeber und externer Auftragnehmer
auf Augenhöhe verhandeln. Sonst besteht die Gefahr der Benachteiligung einer Partei – im Projektverlauf
kann das zu Problemen und sogar zum Scheitern des Projekts führen. Im Zweifelsfall kann sich der Auftraggeber hier verstärken – z.B. durch externes Know-how (unter anderem aus dem Kompetenzzentrum
GroßPM).
→ In der öffentlichen Verwaltung sollte über die generelle Regelung des Abnahmeprozederes hinaus bei
Bedarf im Vertrag eine Regelung zur Abnahme bei Inbetriebnahme erfolgen. Wird ein IT-System in Betrieb genommen, ohne dass formal die Abnahme erteilt wurde, gilt normalerweise die Abnahme als erteilt
(laut BGB durch konkludentes Handeln). Gibt es jedoch gesetzlich vorgeschriebene Termine, die eine Inbetriebnahme zwingend erfordern, kann im Vertrag festgelegt sein, dass damit keine Abnahme verbunden ist.
In diesem Fall sollte jedoch festgelegt werden, was als „abnahmeverhindernder“ Fehler gewertet wird (normalerweise ist das Attribut „abnahmeverhindernd“ ein Synonym zu „produktionsverhindernd“). Der Einhaltung eines gesetzlich festgelegten Termins kann darüber hinaus durch die Vereinbarung von Vertragsstrafen besondere Bedeutung verliehen werden.
Abnahmekriterien zur Inbetriebnahme sind detailliert festzuhalten
Mit jedem einzelnen externen Auftragnehmer werden schließlich für die zu erbringenden Leistungen Verträge abgeschlossen. Neben der klaren und deutlichen Formulierung der Vertragsinhalte sollen die Verträge so
gestaltet sein, dass ein Geben und Nehmen vereinbart ist und beide Seiten „Freude“ am Projekt haben kön -
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
62
5 Disziplinen zum Management der strategischen Ausrichtung
nen. Letztendlich soll eine partnerschaftliche Zusammenarbeit zwischen den Vertragspartnern gefördert wer den.
Der Ausschreibungsverantwortliche sorgt für die Unterschrift der jeweils verantwortlichen Mitarbeiter beider
Seiten und damit für das Inkrafttreten der Verträge.
→ In der öffentlichen Verwaltung werden Verträge standardmäßig im Rahmen der EVB-IT abgeschlossen.
Die einzelnen Vertragstypen können auf Grund ihrer Vollständigkeit auch als Checkliste für die Vertragsge staltung verwendet werden. Es muss jedoch begründet werden, wenn von den EVB-IT-Verträgen abgewi chen wird.
EVB-IT ist Standardvertragsrahmen
→ In der öffentlichen Verwaltung kommt es bei Großprojekten oft zur Zusammenarbeit unterschiedlicher
Organisationen, die über Kooperationsverträge geregelt werden kann.
Verträge regeln behördenübergreifende Kooperation
Alle abgeschlossenen Verträge sowie ihre kaufmännisch relevanten Inhalte werden in der Vertragsübersicht
dokumentiert, so dass jederzeit Transparenz über die für das Projekt abgeschlossenen Verträge herrscht.
Ein Bestandteil der Vertragsübersicht ist das Lizenzmanagement. Es gibt
einen vollständigen Überblick über die beschafften bzw. zu beschaffenden
Lizenzen, und beantwortet dafür folgende Fragen:
●
Welche Lizenzen sind in welchem Zeitraum vorhanden?
●
Wie sind Lizenzen definiert (z.B. übertragbar, nutzergebunden)?
●
Von welchem Mitarbeiter oder welchem Teilprojekt wird eine Lizenz in welchem Zeitraum eingesetzt
bzw. benötigt.
Mit Hilfe des Lizenzmanagements lässt sich frühzeitig der Bedarf an weiteren Lizenzen ermitteln.
Laufende Vertragsverpflichtungen sicherstellen
Es wird sichergestellt, dass die in den Verträgen vereinbarten Leistungen von beiden Vertragspartnern er bracht werden. Die Vertragsübersicht ermöglicht, dass die vereinbarten Leistungen für die relevanten Projektmanagement-Disziplinen greifbar werden. Die Einhaltung formaler Vertragskriterien kann durch das
PMO unterstützt werden. So kann das PMO beispielsweise regelmäßig das Ende von Lizenzverträgen prüfen
und bei Bedarf die Verlängerung von Verträgen initiieren.
→ In Großprojekten kommt der Einhaltung der im Vertrag vereinbarten Leistungen auf Grund der Höhe des
möglichen Schadens besondere Bedeutung zu. Beispielsweise summieren sich die Personalkosten (interne
Personalkosten und Tagessätze externer Mitarbeiter) in einem Projekt mit 100 Mitarbeitern schon innerhalb
weniger Tage zu einer Größenordnung im Millionen-Euro-Bereich. Daher ist die Einhaltung der vereinbar ten Leistung nicht nur zu kontrollieren, sondern bereits im Vorfeld rechtzeitig sicherzustellen.
Budgeteinhaltung durch Sicherstellen der vereinbarten Leistungen
Im Projektverlauf werden Statusänderungen zu allen kaufmännisch relevanten Vertragsinhalten in der Vertragsübersicht dokumentiert, so dass jederzeit eine aktuelle Übersicht über den Stand der Vertragserfüllung
vorliegt.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.2 Vergabe- und Vertragsmanagement
63
Sind Vertragsstrafen vereinbart, wird in Abstimmung mit dem Risikomanagement während der Projektlaufzeit regelmäßig geprüft, ob eine Vertragsstrafe geltend gemacht werden muss. Deutet sich ein solcher Fall an,
sollten Maßnahmen ergriffen werden, die Gefahr abzuwenden.
Verträge aktualisieren
Nicht selten ergeben sich im Projektverlauf unvermeidbare Änderungen, die sich auf bestehende Verträge
auswirken bzw. den Abschluss neuer Verträge erfordern.
→ In der öffentlichen Verwaltung ist anhand des Vergaberechts festzulegen, ob für Änderungen eine neue
Vergabe erforderlich ist. Bei Änderungen mit erheblicher Auswirkung auf das Projekt kann im Zweifelsfall
auch eine neue Vergabe der gesamten Leistung nötig werden.
(Teil-)Neuvergaben bei Änderungen
Darüber hinaus gibt es oft auch Themen, die vertraglich nicht exakt festgelegt und erst im Projektverlauf ge klärt und detailliert werden. In solchen Fällen verhandeln externer Auftragnehmer und Auftraggeber nach
und legen fest, wie sie sich geeinigt haben. Das Ergebnis wird dokumentiert und hat dadurch Vertragscharakter. Es geht dann in die Vertragsübersicht mit ein. Bei wichtigen Themen sollte die Einigung durch Unter schrift beider Seiten festgehalten werden.
Änderungsanforderungen stellen ebenfalls eine Änderung der vertraglich vereinbarten Leistung dar, die
selbst wiederum vertraglich abzusichern sind.
→ In der öffentlichen Verwaltung machen die EVB-IT-Vertragstypen Formularvorschläge für die vertragliche Vereinbarung von Änderungsanforderungen.
Vertragsformularvorschläge von EVB
Vertragserfüllung prüfen und Abnahme durchführen
Sind alle Vertragsverpflichtungen auf beiden Seiten erfüllt, können die Ergebnisse formal abgenommen werden. Ist die inhaltliche Abnahme, die im Rahmen des Anforderungs- und Änderungsmanagements durchgeführt wird, vollständig abgeschlossen, kann die formale Abnahme ausgesprochen werden.
Die Abnahme wird im Abnahmeprotokoll dokumentiert und in der zugehörigen Abnahmeerklärung formal bestätigt.
Oft erfolgt eine Abnahme unter Auflagen, das heißt mit einer Vereinbarung zur Behebung von Fehlern bzw.
zur Lösung eventuell noch vorhandener Probleme. Erst mit der formalen Abnahme ist der Vertrag erfüllt und
erst dann werden Zahlungen geleistet.
→ In der öffentlichen Verwaltung unterliegen die Zahlungen normalerweise dem Prinzip der Jährlichkeit
der öffentlichen Haushalte – das heißt, unter Umständen kommt ein Auftraggeber in die Situation, die Ab nahme aussprechen zu wollen, da im nächsten Haushaltsjahr kein Budget für die an die Abnahme geknüpfte
Zahlung vorgesehen ist. Sollte dieses Vorgehen gewählt werden, so ist zwischen Auftraggeber und exter nem Auftragnehmer detailliert festzulegen, welche Leistungen der Auftragnehmer trotz formal erteilter Abnahme (unter Vorbehalt oder mit Mängeln) noch zu erbringen hat.
Abnahme im Vorjahr, wenn im Folgejahr kein Budget vorhanden ist
Die Abnahme darf aus Auftraggebersicht nicht zu früh erteilt werden. Zunächst muss das Projektergebnis
ausreichend getestet und geprüft sein, denn die Abnahme markiert den Beginn der Gewährleistungsfrist.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
64
5 Disziplinen zum Management der strategischen Ausrichtung
Ab diesem Zeitpunkt gilt die Beweislastumkehr für Fehler, das heißt, der Auftraggeber muss darlegen, dass
es sich bei einem aufgetretenen Mangel tatsächlich um einen Fehler handelt.
5.2.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Vergabe- und
Vertragsmanagement erkennen?
Qualitative Erfolgsmessgrößen des Vergabe- und Vertragsmanagements sind die folgenden Punkte:
●
Die Verträge enthalten eine Klarstellung der Auftraggeber-/Auftragnehmersituation und damit rechtliche
Verbindlichkeit für beide Seiten.
●
Die Vertragsübersicht ist vollständig, das heißt, sie enthält alle Verträge und relevanten Meilensteine.
●
Transparenz: Es existiert jederzeit ein aktueller Überblick über die für das Projekt abgeschlossenen Verträge.
Zu den quantitativen Erfolgsmessgrößen gehören:
●
Anzahl der externen Auftragnehmer, die erst nach dem eigentlich geplanten Einsatzbeginn ausgewählt
werden
●
Anzahl von Vertragsänderungen (außer Änderungsanforderungen)
●
Anzahl der Tage, die auf den Abschluss von Verträgen oder die Bereitstellung von benötigten Lizenzen
bzw. Produkten gewartet werden muss
5.2.6 Grundlegende und weiterführende Literatur
●
VgV: Vergabeverordnung (Verordnung über die Vergabe öffentlicher Aufträge), siehe http://www.bmwi.de/BMWi/Navigation/Service/gesetze,did=21932.html
●
UfAB V: Unterlage für Ausschreibung und Bewertung von IT-Leistungen, Schriftenreihe der KBSt,
2010, siehe www.cio.bund.de.
●
VOL/A, VOL/B, VOF: Verdingungsverordnung für Leistungen, siehe http://www.bmwi.de/BMWi/Navigation/Service/gesetze,did=191324.html
●
EVB-IT: Ergänzenden Vertragsbedingungen für die Beschaffung von Informationstechnik, siehe www.cio.bund.de.
5.3 Endnoten
EN-501
Specific (spezifisch), Measurable (messbar), Accepted (akzeptiert), Realistic (realisierbar),
Timely (terminierbar). Im Projektmanagement ist SMART ein Kriterium zur eindeutigen
Definition von Zielen.
EN-502
Siehe hierzu auch in Software-Entwicklungsprojekten das V-Modell XT.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
5.3 Endnoten
65
EN-503
Vgl. dazu auch Peter Weill, Jeanne W. Ross: „IT Governance – How Top Performers Manage IT Decision Rights for Superior Results“, Harvard Business School Press 2004. Insbe sondere von Interesse ist hier das Spezialkapitel zur Governance im Public Sector, in dem es
unter anderem um die Balance zwischen IT-Investitionen im Hintergrund (z.B. in ein System zur Aufklärung von Straftaten) und sichtbaren Investitionen (z.B. Erhöhung der Polizeidichte auf der Straße) geht.
EN-504
www.cio.bund.de (01.03.2010)
EN-505
Externe Auftragnehmer: Das V-Modell XT (Bund) versteht unter einem „Auftragnehmer“
einen externen Dienstleister, der ein eigenständiges Auftragnehmer-Projekt durchführt und
der über einen Werkvertrag beauftragt wird. Das V-Modell lässt es prinzipiell zu, dass externe Dienstleister auch über Dienstleistungsverträge beauftragt werden, das Modell gibt hier für aber keine Unterstützung für Ausschreibung und Vertragsschluss. Das Produkt "Vertrag“
im V-Modell meint immer einen Werkvertrag.
EN-506
Im V-Modell existiert die Rolle des Projektkaufmanns, der neben den hier beschriebenen jedoch noch weitere Aufgaben wahrnimmt, die auch in das Projektcontrolling hineinreichen.
EN-507
Siehe http://www.cio.bund.de/DE/IT-Beschaffung/EVB-IT-und-BVB/Aktuelle_EVB-IT/aktuelle_evb_it_node.html (abgerufen am 04.12.2012)
EN-508
Stand Juni 2010 (UfAB V Version 2.0). Für aktuelle Fristen
http://www.cio.bund.de/DE/IT-Beschaffung/UfAB/ufab_node.html
(aufgerufen
04.12.2012)
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
siehe
am
66
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
6 Disziplinen zum Management des organisatorischen
Umfelds und der Mitarbeiter
Abbildung 33: Disziplinen des Projektmanagements mit Fokus auf dem „Management des organisatorischen
Umfelds"
6.1 Festlegung/Überprüfung der Projektorganisation
In diesem Kapitel sind die Begriffe „Auftraggeber“ und „Auftragnehmer“ besonders wichtig. Sie werden im
Allgemeinen und an anderer Stelle auch in den Bedeutungen Projektauftraggeber, interner Auftragnehmer,
externer Auftragnehmer, Auftraggeber-Projekt und Auftragnehmer-Projekt verwendet. Abbildung 34 gibt
einen Überblick über die drei wichtigsten Projektkonstellationen, im Anschluss wird beschrieben, wie die genannten Begriffe in den jeweiligen Situationen und in diesem Kapitel zu verstehen sind:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.1 Festlegung/Überprüfung der Projektorganisation
67
Abbildung 34: Mögliche Varianten für die Beziehung zwischen Projektauftraggeber, internem Auftragnehmer
und externen Auftragnehmern
Variante 1: Die Projektdurchführung erfolgt innerhalb der verantwortlichen Behörde ohne Beteiligung externer Auftragnehmer. Die Verantwortung gegenüber dem Projektauftraggeber für die vom Projekt zu erbringenden Leistungen liegt beim behördeninternen Projekt; die Projektmitarbeiter sind aus Sicht des Projektauf traggebers seine internen Auftragnehmer.
Variante 2: Die Projektdurchführung erfolgt durch interne und externe Mitarbeiter. Dabei läuft innerhalb der
verantwortlichen Behörde ein vom Projektauftraggeber beauftragtes Projekt, das Auftraggeber-Projekt ab,
außerhalb der Behörde läuft ein externes Auftragnehmer-Projekt ab. Aus Sicht des Projektauftraggebers gibt
es daher interne Auftragnehmer (die Mitarbeiter im Auftraggeber-Projekt) und externe Auftragnehmer (die
Mitarbeiter im Auftragnehmer-Projekt).
Variante 3: Die Projektdurchführung erfolgt ausschließlich durch externe Auftragnehmer. Damit liegt auch
die Verantwortung für die Projektergebnisse bei den externen Auftragnehmern. Beim Projektauftraggeber
übernehmen Mitarbeiter ausschließlich steuernde, keine durchführenden Funktionen. Sie sind Ansprechpartner für die externen Auftragnehmer, sorgen für die vereinbarten/geforderten Beistellungen des Auftraggebers
und prüfen die vom externen Auftragnehmer erbrachten Leistungen.
Hinweis: Ist im folgenden Kapitel von der Beziehung zwischen Auftraggeber und Auftragnehmer die
Rede, ist immer die in der Abbildung durch Erteilung des Projektauftrags hergestellte Beziehung vom Pro jektauftraggeber zum Projekt (das heißt zur projektdurchführenden Funktion) gemeint. Ist speziell nur die
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
68
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Beziehung zu einem externen Auftragnehmer (wie in Variante 2 und Variante 3 beschrieben) gemeint, so
wird dies auch explizit erwähnt. Die Herstellung der Beziehung zu einem externen Auftragnehmer ist im Kapitel Vergabe- und Vertragsmanagement beschrieben.
6.1.1 Ziele und Rahmenbedingungen: Was soll mit der Projektorganisation erreicht werden?
Die Projektorganisation ist so auszugestalten, dass alle Beteiligten eingebunden und die vielfältigen Aufga ben dem Zeitplan entsprechend abgearbeitet werden können: Sowohl auf Auftraggeberseite als auch auf Auftragnehmerseite (im Sinne der Projektdurchführung durch interne oder auch externe Auftragnehmer) ist eine
der Projektgröße angemessene Projektorganisation zu etablieren. Darüber hinaus müssen Aufgaben klar verteilt und Verantwortungen abgegrenzt werden.
Festlegung der für die Projektgröße angemessenen Projektorganisation
Auf Auftragnehmerseite ist eine angemessene Projektorganisation ein wesentlicher Faktor für die erfolgreiche Durchführung des Projekts. Die Projektorganisation auf Seiten des Auftraggebers muss so ausgestaltet
sein, dass eine angemessene Begleitung und Steuerung des Projekts möglich ist.
→ Ein Großprojekt wird in der Regel in Teilprojekte und mehrere Projektebenen untergliedert: Eine intelli gente Modularisierung hilft, Komplexität und Umfang der Aufgaben handhabbar zu machen.
Komplexität durch Modularisierung reduzieren
Verteilung der Aufgaben und Abgrenzung der Verantwortlichkeiten
Auftraggeber und Auftragnehmer müssen genau wissen, wer für welche Ergebnisse und Entscheidungen verantwortlich ist. Dazu sind jeweils auf beiden Seiten die Rollen, Aufgaben, Verantwortlichkeiten und Kompe tenzen genau festzulegen. Ziel ist, eine funktionierende Arbeitsteilung zu gewährleisten und alle Projektaufgaben adäquat zu verteilen.
→ In Großprojekten werden spezielle Projektrollen definiert, so dass die umfangreichen und komplexen
Aufgaben mit den entsprechenden Verantwortungen detailliert zugeordnet werden können. In Abgrenzung
zu kleineren Projekten, wo z.B. das Qualitätsmanagement durch den Projektleiter parallel bearbeitet wird,
kann es in großen Projekten erforderlich sein, ein eigenes Team für das Qualitätsmanagement einzusetzen.
Großprojekte kennen viele dedizierte Projektrollen
Darüber hinaus gilt es, die Aufgaben und Verantwortungen an den Schnittstellen zwischen allen Beteiligten
(insbesondere Auftraggeber und -nehmer) klar abzugrenzen. Dabei wird auch sichergestellt, dass das Projekt
auf Auftraggeberseite Unterstützung durch den verantwortlichen Mitarbeiter der Linienorganisation erhält.
Die Festlegung/Überprüfung der Projektorganisation spielt damit also auch eine Rolle bei der Sicherstellung
des wichtigen Erfolgsfaktors von IT-Projekten: der Unterstützung durch die Leitung der Organisation.
6.1.2 Rollen: Wer macht was bei der Festlegung der Projektorganisation?
Eine zentrale Rolle bei der Festlegung der Projektorganisation spielt der Projektleiter auf Auftraggeber- und
-nehmerseite:
Projektleiter (des
Auftraggebers)
Trägt Gesamtverantwortung für die Festlegung der Projektorganisation auf Auftraggeberseite
● Definiert die benötigten Rollen und besetzt sie mit geeigneten Mitarbeitern
● Prüft die Projektorganisation und passt sie bei Bedarf im Projektverlauf an
Projektleiter (des
Hat Gesamtverantwortung für die Festlegung der Projektorganisation auf Auftragnehmerseite
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.1 Festlegung/Überprüfung der Projektorganisation
Auftragnehmers)
●
●
69
Definiert die benötigten Rollen und besetzt sie mit geeigneten Mitarbeitern
Prüft die Projektorganisation und passt sie bei Bedarf im Projektverlauf an
Tabelle 7: Rollen und Verantwortlichkeiten in der Projektorganisation
Der interne Projektleiter entwickelt die Projektorganisation in der Regel in Abstimmung mit dem LA und so fern vorhanden im Rahmen von Vorgaben, z.B. durch Regelungen des Multiprojekt- oder Programmmanagements.
→ In Großprojekten wird die Projektorganisation differenziert nach Projektebenen festgelegt. Der Gesamt projektleiter bestimmt die Projektstruktur auf oberster Ebene sowie die Gesamtprojektrollen. Die Ausgestaltung der Projektorganisation auf den unteren Ebenen des Projekts delegiert er an die jeweils verantwortlichen Mitarbeiter (Projektmanager und Teilprojektleiter). Diese legen Projektstruktur und Rollen in ihrem
Verantwortungsbereich in Abstimmung mit der jeweils nächsthöheren Projektebene fest.
Mehrstufige Projektorganisation
6.1.3 Ergebnisse: Welche Dokumente sollen erstellt werden?
Wesentliche Ergebnisse bei der Festlegung der Projektorganisation sind Projektorganigramm und Rollenbeschreibungen:
●
Das Projektorganigramm dokumentiert die aufbauorganisatorische Projektstruktur und die Abgrenzung
zwischen Auftraggeber und Auftragnehmer sowie weiteren Projektbeteiligten. Es enthält die Aufteilung
des Gesamtprojekts in Verantwortungsbereiche und Teilprojekte (einschließlich Aufgabenabgrenzung
zwischen den Teilprojekten), dokumentiert, wer für welche Teile verantwortlich ist, und gibt an, mit welchen Mitarbeitern die wesentlichen Projektrollen besetzt sind. Die im Projektorganigramm dokumentierte Struktur ist unabhängig von den Aufbauorganisationen der beteiligten Entitäten oder Unternehmen.
Die Aufteilung auf Verantwortungsbereiche und Teilprojekte orientiert sich an Projektinhalten, die in der
Definition des Projektumfangs und letztendlich im Projektstrukturplan (siehe Kapitel Anforderungs- und
Änderungsmanagement) beschrieben sind. Das Projektorganigramm wird im Laufe des Projekts an aktuelle Entwicklungen angepasst.
●
Die Rollenbeschreibungen machen deutlich, welche Projektrolle welche Aufgaben wahrnimmt, welche
Kompetenzen ihr zugeordnet sind und welche Verantwortung sie im Projektkontext hat. Die Rollenbeschreibungen stellen sicher, dass alle benötigten Aufgaben wahrgenommen werden und keine Aufgaben
doppelt oder mit unklarer Verantwortung vergeben werden.
6.1.4 Prozesse: Wie wird die Projektorganisation festgelegt/überprüft?
Die folgende Abbildung 35 gibt einen Überblick über die Prozesse bei der Festlegung und Überprüfung der
Projektorganisation.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
70
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Abbildung 35: Prozesse bei der Festlegung und Überprüfung der Projektorganisation
Initiale Prozesse: Festlegung Projektstruktur
Dem Projekt wird eine innere Struktur gegeben, die sich an der Aufteilung von Aufgaben und Verantwortung
orientiert.
→ Ein Großprojekt ist gekennzeichnet durch intelligente Modularisierung von Inhalten und Verantwortung,
insbesondere durch
●
Aufteilung des Gesamtprojektinhalts in möglichst unabhängige Teile bzw. Teilprojekte
●
Einführung zusätzlicher Projektmanagement bzw. -leitungsebenen, um Umfang und Komplexität
der Aufgaben handhabbar zu machen
●
Einführung spezieller Rollen, die eine genaue Aufschlüsselung von Aufgaben und Verantwortung erlauben.
Intelligente Modularisierung
→ Betrachtet man in großen Projekten je zwei übereinander liegende Ebenen, ist in der Regel eine Ähn lichkeit der Strukturen und Prozesse zu erkennen: Das Prinzip der Modularisierung setzt sich von Ebene zu
Ebene fort bis hin zur Aufteilung der Aufgaben auf Arbeitspakete, die von einzelnen Mitarbeitern übernommen werden. Auch Rollen auf Gesamtprojektebene spiegeln sich mit ähnlicher inhaltlicher Ausrichtung auf
Teilprojektebene wider (z.B. QS-Verantwortlicher auf Gesamtprojektebene und Teilprojekt-QS-Verantwortlicher auf Teilprojektebene). Der Planungsprozess zeichnet sich an Ebenengrenzen jeweils dadurch aus,
dass die Planung von unten nach oben verdichtet wird. Weitere Beispiele für die Ähnlichkeit auf verschie denen Projektebenen sind die Vorgaben, die jeweils von oben nach unten gemacht werden oder die Berichtswege, die typischerweise von unten nach oben laufen. Diese Strukturen werden auch bei der Einfüh rung weiterer Projektebenen bei zunehmender Projektgröße berücksichtigt.
Gleiche Strukturen für übereinander liegende Organsationsebenen
Die folgende Abbildung 36 illustriert eine beispielhafte Projektorganisation für ein Softwareprojekt auf Auftragnehmerseite mit drei Führungsebenen (Gesamtprojektleiter, Projektmanager, Teilprojektleiter) und definierten Rollen. Die Rollenbezeichnungen entsprechen, soweit dort vorhanden, dem V-Modell XT, werden
aber häufig je Organisation individuell gewählt und sind auch hier nicht als verbindliche Vorgabe gemeint
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.1 Festlegung/Überprüfung der Projektorganisation
71
(EN-601). Für andere Projekttypen, insbesondere Strategieprojekte sind die meisten Gesamtquerschnittsrollen in der Regel nicht nötig.
Abbildung 36: Großprojektorganisation (beispielhaft mit 3 Führungsebenen)
Teilprojektschnitt festlegen
Ziel, Ergebnisse und Inhalt des Gesamtprojekts müssen so aufgeteilt werden, dass handhabbare Teile bzw.
Teilprojekte entstehen. Dabei werden auch die Vorgaben, die sich für das Gesamtprojekt aus den Rahmenbedingungen ableiten, auf die einzelnen Teile oder Teilprojekte übertragen bzw. verteilt.
Teilprojekte und ihre Inhalte sind möglichst so aufzuteilen und abzugrenzen, dass Abhängigkeiten minimiert
werden. Ziel ist, eine möglichst autarke Durchführung der einzelnen Teilprojekte zu ermöglichen und den zusätzlichen Managementaufwand (z.B. Kommunikation, Koordination, Planung) so gering wie möglich zu
halten.
Es hat sich bewährt, Teilprojekte in Softwareprojekten nach fachlichen statt nach technischen Merkmalen zuzuschneiden. Dies erlaubt die ganzheitliche Bearbeitung eines fachlichen Themas in einem Teilprojekt und
führt zu einer weiteren Reduzierung von Abhängigkeiten. Strategieprojekte lassen sich nach Organisations einheiten oder auch je nach Anforderung Strategieinhalten zuschneiden. Infrastrukturprojekte benötigen
einen technischen Schnitt.
→ In Großprojekten kann es auch Teilprojekte geben, die sich ausschließlich um Projektmanagementaufgaben kümmern (z.B. Kommunikationsmanagement, Projektcontrolling, Vergabe- und Vertragsmanagement,
Qualitätsmanagement). Sie leisten damit die für die Zielerreichung notwendige Prozessunterstützung, tragen selbst aber nicht direkt zum Projektergebnis bei. Beispielsweise kann ein Teilprojekt „Kommunikationsaufgaben“ in einem Bund-Länder-übergreifenden Projekt sinnvoll sein.
Projektmanagementaufgaben können in Teilprojekte ausgelagert werden
Führungsstruktur festlegen
Kleinere Projekte haben normalerweise nur eine Führungsebene. Der Projektleiter trägt die Gesamtverantwortung für die Projektergebnisse bzw. das Erreichen des Projektziels.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
72
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
→ In Großprojekten richtet sich die Anzahl der notwendigen Führungsebenen nach der Anzahl der zu füh renden Mitarbeiter im Projekt und nach der Art der Tätigkeit. Die Einrichtung zusätzlicher Führungsebenen
ist notwendig, da die Führungsspanne einzelner Projektmitarbeiter nicht beliebig erweiterbar ist. Die Erfahrung zeigt, dass für die Leitung eines siebenköpfigen Teams bei individuell zu planenden Aufgaben bereits
ein Vollzeit-Projektleiter benötigt wird. Die Grenze der Führungskapazität ist bei ca. 15 direkt geführten
Mitarbeitern erreicht (EN-602).
Maximal 15 direkt geführte Mitarbeiter pro Führungskraft
→ Projektmanager können im Großprojekt nicht beliebig viele Teilprojekte verantworten. Insbesondere
dürfen es nicht so viele Teilprojekte sein, dass dem Projektmanager keine Zeit mehr für die Bearbeitung ungeplanter Themen bleibt (z.B. Lösung plötzlich auftretender Probleme, Durchführung von Maßnahmen zur
Risikoreduzierung). Gibt es zu viele Teilprojekte (ca. > 6), müssen weitere Führungsebenen eingeführt wer den.
Begrenzung der Anzahl an Teilprojekten
→ Spezielle Projektmodelle können besondere Anforderungen an die Führungsstruktur stellen. Beispielsweise kann es in Projekten mit mehreren Standorten (z.B. Projekte, bei denen aus Kostengründen oder politischen Gründen oder infrastrukturellen Gründen Teile der Realisierung verlagert sind) sinnvoll sein, auch
Führungsstrukturen an mehreren Standorten aufzubauen.
Dezentrale Führungsstrukturen je nach Anforderung sinnvoll
Einbindung der Nutzer/Fachbereiche organisieren
Know-how-Träger betroffener Fachbereiche bzw. künftiger Nutzer des Projektergebnisses sind in die Projektprozesse einzubinden. Die Projektorganisation legt fest, welche Rollen oder Teilprojekte organisatorisch
für diese Einbindung zuständig sind. Wichtig ist, die Art der Einbindung abzustimmen, Fachbereiche/Nutzer
müssen sich ihrer Aufgaben und Verantwortung bewusst sein. Weitere Entscheidungen über die Einbindung
der Fachbereiche werden in den übrigen Projektmanagement-Disziplinen getroffen, z.B. im Kommunikati onsmanagement (Informationsfluss von und zu den Fachabteilungen), in der Planung (Festlegung und Koordination von Zulieferungen durch den Fachbereich), im Qualitätsmanagement (Abstimmung der Qualitätskriterien) oder im Veränderungsmanagement (Fachbereiche sind ein Ziel des Veränderungsmanagements).
→ Vertreter beteiligter Fachbereiche bzw. künftiger Nutzer stellen in Großprojekten oft einen Engpass dar,
da sie parallel zur Projektarbeit ihren Aufgaben in der Linie nachgehen müssen. Ziel ist daher, entsprechen de Know-how-Träger vollzeitig in die Projektarbeit einzubinden – sie werden Teil der Projektorganisation.
Meist können einzelne Vertreter aber nicht das gesamte Spektrum des für das Projekt notwendigen Wissens
abdecken. Daher sind auf allen Ebenen des Projekts zusätzlich Vertreter von Fachbereichen und Nutzern zu
benennen und in Entscheidungs- und Kommunikationsprozesse einzubinden.
Fachvertreter Vollzeit einbinden, mindestens in Kommunikationsstrukturen einbinden
Projektbeteiligte abgrenzen
Die Festlegung der Projektrahmenbedingungen geht typischerweise mit der Abgrenzung der Verantwortungsbereiche zwischen den Projektbeteiligten, insbesondere zwischen Auftraggeber und (internen/externen) Auftragnehmer(n), einher. Die Projektorganisation muss sicherstellen, dass beide Seiten ihre Verantwortung
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.1 Festlegung/Überprüfung der Projektorganisation
73
wahrnehmen können. Für jede im Projektauftrag enthaltene Anforderung muss geklärt sein, wer für ihre Erfüllung zuständig ist; oft benötigt der Auftragnehmer Zulieferungen des Auftraggebers, die ebenfalls definiert
sein müssen. Die Dokumentation kann z.B. erfolgen im Projekthandbuch oder in der Projektcharta.
Der Auftragnehmer muss die Durchführung des Projekts gewährleisten können, der Auftraggeber eine angemessene Unterstützung, Begleitung und Steuerung des Projekts. Der Auftraggeber muss zugesagte Zulieferungen leisten und auf Anfragen aus dem Projekt zeitnah reagieren können, um den Projekterfolg nicht zu
gefährden. Beim Auftraggeber gibt es normalerweise keine komplette Projektorganisation, jedoch sind spezielle Rollen für die Steuerung definiert (siehe folgender Abschnitt „Projektrollen definieren“).
→ Für ein Großprojekt ist auf Auftraggeberseite die Unterstützung durch einen Mitarbeiter auf hoher Lei tungsebene erforderlich (Leitungsebene der Organisation). Nur so kann gewährleistet werden, dass die für
den Projekterfolg notwendigen Rahmenbedingungen gegeben sind bzw. geschaffen werden.
Unterstützung durch oberste Leitungsebene sichert Projekterfolg
Zusätzlich ist festzulegen, wie und auf welchen Ebenen Auftraggeber- und Auftragnehmerorganisation miteinander kommunizieren. Beispielsweise ist der Gesamtprojektleiter auf Auftragnehmerseite der direkte Ansprechpartner des Projektleiters auf Auftraggeberseite.
Projektrollen definieren
In jedem Projekt sind vorab die wesentlichen Projektrollen festzulegen: Welche gibt es, welche Aufgaben
nehmen sie wahr, welche Kompetenzen sind ihnen zugeordnet und welche Verantwortung im Projektkontext
tragen sie? Es ist darauf zu achten, dass alle Projektaufgaben (siehe Projektstrukturplan aus der Planung) und
-verantwortlichkeiten eindeutig entweder Teilprojekten oder Rollen zugeordnet sind. Für alle Rollen sind
Projektmitarbeiter zu benennen.
→ Umfang und Vielfalt der Aufgaben in Großprojekten erfordern die Einführung spezieller Rollen mit ei nem genau definierten und gegenüber den übrigen Rollen abgegrenzten Aufgaben- und Verantwortungsbereich. Zwar sind bei kleinen und großen Projekten einige Aufgaben und Verantwortungen identisch, den noch ist eine 1:1-Übertragung der Rollen von kleine auf große Projekte nicht möglich, da der Detailgrad
auf den verschiedenen Projektebenen ganz unterschiedlich ist.
Größere Vielfalt von Aufgaben und Verantwortungen in Großprojekten
→ Je nach Projektgröße sind Rollen mit gleichem thematischem Schwerpunkt auf unterschiedlichen Pro jektebenen einzurichten. Beispielsweise gibt es den QS-Verantwortlichen auf Gesamtprojektebene und den
Teilprojekt-QS-Verantwortlichen auf Teilprojektebene.
Einrichtung einer Hierarchie von Projektrollen
→ Folgende Punkte sind bei der Festlegung der Projektrollen im Großprojekt zu beachten:
●
Für alle Schlüsselrollen sind Vertreter zu benennen.
●
Vor allem Gesamtprojektleiter und Projektmanager, aber auch Anforderungsanalytiker, Systemarchitekt
und QS-Verantwortlicher sollten niemals zu 100% verplant werden. Im Gegenteil: In einem Großpro jekt tauchen typischerweise immer wieder neue Fragen und Themen auf, für deren Bearbeitung diese
Mitarbeiter häufig den größten Teil ihrer Kapazität einsetzen müssen. Insbesondere Projektmanager
agieren sehr stark als „Libero“ und können ungeplante Themen angehen.
●
Im Großprojekt können die einer Rolle zugewiesenen Aufgaben derart umfangreich sein, dass ein kleiS-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
74
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
nes Team unterstützend tätig werden muss. Der Rolleninhaber führt dieses Team und übernimmt die
Verantwortung für die zugewiesenen Aufgaben.
●
Aufgabenverteilung und Verantwortungsabgrenzung sind kurzfristig an das gesamte Team zu kommu nizieren. Sie sollten z.B. in der Projektcharta oder im Projekthandbuch schriftlich dokumentiert sein
(z.B. für neue Teammitglieder).
●
Die Verantwortung muss im Projekt gelebt werden. Eine rein formale Verantwortungsübertragung (z.B.
auch an den Auftraggeber), die nicht mit Leben gefüllt wird, ist sinnlos und kontraproduktiv.
●
Rollenbeschreibungen (Aufgaben, Kompetenzen, Verantwortung) geben meist nur einen Überblick,
nicht jedes Detail lässt sich im Voraus planen. Sie entheben den Rolleninhaber daher nicht von einer
verantwortungsbewussten Übernahme seiner Aufgaben. Insbesondere entheben sie ihn nicht der Verantwortung, die mit seiner Rolle in Verbindung stehenden Themen umfassend zu betrachten und alle entsprechenden Aufgaben anzunehmen und zu bearbeiten (oder für deren Bearbeitung im Sinne der Gesamtprojektverantwortung zu sorgen)!
Projektrollen brauchen Vertreter
→ Typische Rollen in IT-Großprojekten
Auf Auftragnehmerseite gibt es in Großprojekten häufig folgende Rollen (EN-603):
Rollen mit Verantwortung im LA
●
LA-Vertreter: für das Gesamtprojekt verantwortlicher Mitarbeiter (in Linienorganisation) des Auftragnehmers
Rollen mit Projektleitungsverantwortung
●
Gesamtprojektleiter: Gesamtprojektverantwortung sowie Gesamtverantwortung für die Projektergebnisse (Termine, Inhalt/Qualität, Budget) und die dafür notwendigen Projektmanagement-Prozesse
●
Projektmanager: verantwortet einen Teilbereich des Projekts gegenüber dem Gesamtprojektleiter, das
heißt alle Ergebnisse der zugeordneten Teilprojekte und Themen
●
Teilprojektleiter: ist für das Ergebnis eines Teilprojekts verantwortlich
Rollen mit fachlicher und technischer Verantwortung
●
Systemarchitekt („Technischer Chefdesigner“): verantwortet adäquate Technik und Architektur im Gesamtprojekt
●
Anforderungsanalytiker („Fachlicher Chefdesigner“): ist für eine gesamtprojektübergreifend konsistente Fachlichkeit zuständig
●
Teilprojekt-System-/Software-/Hardware-Architekt:
ist
Architektur/Hardware-Architektur im Teilprojekt zuständig
●
Teilprojekt-Anforderungsanalytiker: verantwortet fachliches Design/konsistente Fachlichkeit im Teilprojekt
für
technisches
Design/technische
Rollen mit Prozess- oder Themenverantwortung
●
QS-Verantwortlicher: sorgt für die Umsetzung des Qualitätsmanagements im Gesamtprojekt
●
Teilprojekt-QS-Verantwortlicher: verantwortet die Umsetzung des Qualitätsmanagements im Teilprojekt
●
Testmanager: ist zuständig für Planung, Spezifikation und erfolgreiche Durchführung der Tests
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.1 Festlegung/Überprüfung der Projektorganisation
75
●
Release-Verantwortlicher: ist verantwortlich für erfolgreiche Inbetriebnahme eines Release verantwortlich
●
Wartungsverantwortlicher: ist für Wartung einer produktiven Version zuständig
●
Schnittstellenmanager: verantwortet die einheitliche Konzeption der Nachbarsystem-Schnittstellen
●
Sicherheitsbeauftragter: ist verantwortlich für Einhaltung von Sicherheitsauflagen, fungiert als direkter
Ansprechpartner des Sicherheitsbevollmächtigten der Organisation/des Unternehmens.
Weitere Rollen beim Auftragnehmer, die spezielle Projektmanagement-Disziplinen unterstützen (z.B. Projektcontroller), sind in den jeweiligen Kapiteln ausführlich beschrieben.
Auf Auftraggeberseite finden sich in Großprojekten häufig folgende Rollen:
●
LA-Vertreter: für das Gesamtprojekt verantwortlicher Mitarbeiter (in Linienorganisation) des Auftraggebers, typischerweise der Leiter der zuständigen Organisation
●
Projektleiter: dient als direkter Ansprechpartner für den Gesamtprojektleiter des Auftragnehmers und
trifft gemeinsam mit diesem Steuerungsentscheidungen auf Projektebene
●
Verantwortlicher für das Abnahmemanagement: sorgt für Vorbereitung und Durchführung der Abnahme
und dient als Ansprechpartner für QS-Verantwortlichen und Testmanager auf Auftragnehmerseite.
Darüber hinaus werden oft Ansprechpartner für einzelne Teilprojekte benannt oder auch Verantwortliche für
bestimmte Projektmanagement-Themen wie Qualitäts- oder Risikomanagement. In fachliche Entscheidungen sind die betroffenen Fachbereiche einzubeziehen. Auch die Verantwortung für vereinbarte Zulieferungen des Auftraggebers ist im Einzelfall festzulegen.
Jede Projektrolle gehört zu einer bestimmten Ebene der Projektorganisation. Die Beziehung ist in der nachfolgenden Tabelle dargestellt. Nicht alle davon sind für jeden Projekttyp notwendig.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
76
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Tabelle 8: Rollenzugehörigkeiten
Beachtung besonderer Rollen in IT-Großprojekten
Projektorganisation regelmäßig überprüfen und anpassen
Die gesamte Projektorganisation ist regelmäßig zu überprüfen. Haben sich die anfänglichen Rahmenbedingungen geändert, ist auch die Projektorganisation entsprechend anzupassen und die Anpassung zu dokumentieren. Dazu gehören drei wesentliche Punkte:
1) Teilprojektschnitt prüfen und anpassen
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.1 Festlegung/Überprüfung der Projektorganisation
77
Während der Lösungsdetaillierung können sich die in den Teilprojekten zu bearbeitenden Inhalte verändern.
Im Laufe des Projekts sind daher regelmäßig die Rahmenbedingungen zu überprüfen. Bei Bedarf sind die
Teilprojekte neu zu formulieren, um für den zukünftigen Projektverlauf wieder minimierte Abhängigkeiten
zwischen den Teilprojekten sicherzustellen.
2) Führungsstruktur prüfen und anpassen
Ändern sich die Rahmenbedingungen, sind insbesondere Projektorganisation und Führungsstruktur rechtzeitig anzupassen. Häufig startet ein Projekt beispielsweise mit einem kleinen Projektteam, das dann im Laufe
des Projekts deutlich größer wird (z.B. durch die Einbindung Externer nach einer Vergabe oder durch die
Schaffung eines Betriebsreferates zur Überführung eines Systems in die Produktion). Die Teilprojekt- und
Führungsstruktur muss entsprechend weiterentwickelt werden, bevor die für ein kleineres Team ausgelegten
Organisationsstrukturen an ihre Grenze stoßen.
3) Projektrollen prüfen und anpassenIm Projektverlauf ist kontinuierlich dafür zu sorgen, dass Vertreter von
Auftraggeber oder -nehmer eine Rolle ad hoc ohne großen Aufwand übernehmen können. Dafür sind ent sprechende Ausbildungsmaßnahmen zu planen. Alle wesentlichen, vorab bekannten Aufgaben sind eindeutig
bestimmten Rollen oder Teilprojekten zugeordnet. Sollten unerwartete Aufgaben/Themen im Projektverlauf
auftreten, ist die Verantwortung dafür ebenfalls unverzüglich einer Rolle bzw. einem Teilprojekt zuzuordnen.
Es kann im Projektverlauf gute Gründe geben, eine Projektrolle von einem Mitarbeiter auf einen anderen zu
übertragen (z.B. wenn der ursprüngliche Rolleninhaber im Zuge einer vereinbarten Weiterentwicklung neue
Aufgaben übernimmt). In diesen Fällen ist darauf zu achten, dass der Rolleninhaber begonnene Aktivitäten
zum Zeitpunkt des Wechsels abgeschlossen hat oder sie ausreichend dokumentiert vollständig übergibt. Ein
guter Zeitpunkt für einen Wechsel kann z.B. sein, wenn vorbereitende Tätigkeiten abgeschlossen sind und
die weitere Aufgabe eher in der Koordination liegt.
6.1.5 Erfolgsmessgrößen: Woran kann der Auftraggeber eine gute Projektorganisation
erkennen?
Ein Auftraggeber kann den Erfolg bei der Festlegung und Überprüfung der Projektorganisation an qualitati ven und quantitativen Kriterien messen.
Als qualitative Messgrößen sind beispielsweise folgende Prüffragen möglich:
●
Sind die Rollen und Verantwortlichkeiten zwischen Auftragnehmer und Auftraggeber genau definiert und
kommuniziert?
●
Sind die Rollen und Verantwortlichkeiten innerhalb der Projektstruktur genau definiert und kommuniziert?
●
Ist die Einbindung der Nutzer/Fachbereiche sichergestellt?
●
Ist die Abhängigkeit zwischen den Teilprojekten aus fachlicher Sicht minimiert?
Als quantitative Messgrößen sind folgende Kennzahlen denkbar:
●
Führungsspanne der Teilprojektleiter nicht größer als 15 direkt geführte Mitarbeiter
●
Anzahl der Änderungen, die sich auf mehrere Teilprojekte auswirken vs. Gesamtanzahl der Änderungen.
6.1.6 Grundlegende und weiterführende Literatur
●
Johannes Siedersleben (Herausgeber): Softwaretechnik – Praxiswissen für Softwareingenieure, Hanser
Verlag 2003
●
Detlev Hoch, Markus Klimmer, Peter Leukert: Erfolgreiches IT-Management in der öffentlichen Verwaltung – Managen statt verwalten, Gabler Verlag 2005 (ab S. 96)
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
78
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
6.2 Personalmanagement
6.2.1 Ziele: Was soll das Personalmanagement erreichen?
Das Personalmanagement bei Großprojekten verfolgt drei Ziele:
●
Einen erfahrenen Projektleiter finden und ein qualifiziertes Team zusammenstellen. Großprojekte
sind fast immer erfolgreich, wenn ein fachlich kompetentes Projektteam für die ganze Projektlaufzeit
verfügbar ist. Aufgabe des Personalmanagements ist es, geeignete Mitarbeiter auszuwählen. Das gilt vor
allem für die wichtigen Projektrollen und insbesondere für den Gesamtprojektleiter: Er benötigt neben
fachlicher Kompetenz auch Erfahrung im Management großer IT-Projekte in der öffentlichen Verwaltung. Bei der Auswahl z.B. des Systemarchitekten kommt es dagegen vor allem darauf an, dass er Erfahrung mit der für das Projekt vorgesehenen Architektur und Technologie hat. Darüber hinaus sorgt das
Personalmanagement für Kontinuität und Konstanz im Projektteam: Idealerweise stehen die vorgesehenen Mitarbeiter für die gesamte Laufzeit zu 100% zur Verfügung.
●
Das Projektteam motivieren. Der Erfolg eines Projekts hängt entscheidend vom Engagement des
Teams ab. Mit geeigneten Maßnahmen (Einbindung, Transparenz verschaffen, Beitrag des Einzelnen
herausstellen) kann das Personalmanagement die Motivation des Teams und jedes einzelnen Mitarbeiters
stärken.
●
Die Projektmitarbeiter weiterentwickeln. Die Teammitglieder sind für die Dauer des Projekts aus ihrer
normalen Arbeitsumgebung und Organisationsstruktur herausgelöst – in Großprojekten manchmal für
mehrere Jahre. Das Personalmanagement sorgt dafür, dass die Weiterentwicklung der beteiligten Mitarbeiter während des Projekts gewährleistet und an den Projektzielen ausgerichtet ist. Außerdem sichert
das Personalmanagement nach Abschluss des Projekts die Entwicklung der Mitarbeiter, die sich wieder
in die normale Arbeitsumgebung eingliedern.
6.2.2 Rollen: Wer macht was im Personalmanagement?
Der (Gesamt-)Projektleiter ist Gesamtverantwortlicher für das Personalmanagement. In öffentlichen Organisationen jedoch stets in Zusammenarbeit mit der personalbearbeitenden Stelle sowie weiteren Beteiligten
(z.B. Personalrat, Gleichstellungsbeauftragte, Fortbildung). Folgende Rollen sind für das Personalmanagement relevant:
(Gesamt-)Projektleiter
Ist Gesamtverantwortlicher für das Personalmanagement
● Sorgt für die Motivation der Mitarbeiter und des Teams sowie für die
Mitarbeiterentwicklung der Kernmitarbeiter
Ggf. Personalmanager
●
●
Ggf. Personaladministrator ●
●
●
Stellt sicher, dass die Mitarbeiter die für ihre Aufgaben notwendige Erfahrung und
Kompetenz besitzen und dass alle notwendigen Mitarbeiter für den Projekteinsatz
verfügbar sind
Stimmt die Mitarbeiterentwicklung mit den Personalvorgesetzten ab, plant Maßnahmen
zur Mitarbeitermotivation und führt sie durch
Gewährleistet die administrative Unterstützung
Fordert beispielsweise abgestimmte Mitarbeiter-Dispositionspläne und MitarbeiterEntwicklungsvereinbarungen ein und prüft diese
Erstellt Auswertungen (z.B. „Mitarbeitergebirge“ – grafische Darstellung des
Mitarbeiterbedarfs über Zeit) zur Kommunikation von Bedarfen, organisiert
Motivationsmaßnahmen oder koordiniert die Urlaubsplanung
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.2 Personalmanagement
79
●
Ist in großen Projekten häufig Mitglied des PMO
Tabelle 9: Rollen und Verantwortlichkeiten im Personalmanagement
Allerdings sind diese personalmanagementspezifischen Rollen in vielen Projekten nicht dediziert besetzt.
Das Personalmanagement liegt dann in der Verantwortung der Projektleitung.
→ In Großprojekten ist der Gesamtprojektleiter für das Personalmanagement verantwortlich. Er kann jedoch einzelne Themen an weitere Projektrollen mit Führungsverantwortung delegieren. Sinnvoll ist es beispielsweise, wenn Projektmanager und Projektleiter die Personalmanagementaufgaben für ihre Teilprojekte
oder Verantwortungsbereiche übernehmen.
Delegieren von Personalmanagementaufgaben
6.2.3 Ergebnisse: Welche Dokumente sollen erstellt werden?
Zu den Zielen des Personalmanagements gehört, geeignete Mitarbeiter für das Projekt zu finden, sie dort ein zusetzen und ihre Weiterentwicklung zu sichern. Dementsprechend erarbeitet das Personalmanagement vor
allem drei wichtige Ergebnisse:
●
Mitarbeiterverfügbarkeitsplan. Für jeden Mitarbeiter ist dokumentiert und abgestimmt, zu welchem
Anteil und in welchem Zeitraum er für das Projekt zur Verfügung steht.
●
Mitarbeitereinsatzplan. Für jede Projektrolle ist festgelegt, welcher Mitarbeiter die Rolle einnimmt.
Für Mitarbeiter ohne dedizierte Rolle ist dokumentiert, welche Aufgaben sie übernehmen. Zudem werden Informationen aufgenommen, die mit dem Einsatz des Mitarbeiters in Verbindung stehen (z.B. Ein arbeitungsplanung oder Übergabeplanung beim Ausstieg des Mitarbeiters aus dem Projekt).
●
Ausbildungsplan. Für jeden Mitarbeiter ist festgelegt, wie er sich im Projekt weiterentwickeln soll, also
z.B. welche Qualifizierungsmaßnahmen in welchem Zeitraum durchzuführen sind.
Diese Informationen können in unterschiedlichen Projektdokumenten enthalten sein (z.B. Projekthandbuch,
Projekt-Charta, Aufgabenplan).
Weitere für das Personalmanagement relevante Ergebnisse – insbesondere Projektorganigramm und die Definition der Projektrollen – werden im Abschnitt zur Projektorganisation beschrieben (siehe Kapitel Festlegung/Überprüfung der Projektorganisation).
Es ist jedoch dringend darauf zu achten, dass die Führung von parallelen Personalakten in der öffentlichen
Verwaltung nicht legitim ist. Es empfiehlt sich hier die vorherige Abstimmung mit den personalbearbeitenden Stellen sowie weiteren Beteiligten (z.B. Personalrat, Gleichstellungsbeauftragte, Fortbildung).
6.2.4 Prozesse: Wie geht das Personalmanagement vor, womit beschäftigt es sich inhaltlich?
Das Personalmanagement bei IT-Großprojekten sollte schon vor dem Projektstart wichtige Aufgaben lösen
(initiale Prozesse), es ist aber auch während des Projekts wichtig (laufende Prozesse). Das folgende Schau bild gibt einen Überblick.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
80
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Abbildung 37: Prozesse des Personalmanagements
Rollen und Verantwortlichkeiten festlegen
→ Zum Projektstart werden Prozesse und Verantwortung für Personalmanagement-Themen im Projekt festgelegt – gemeinsam mit den Linienorganisationen der eingesetzten Mitarbeiter. Das ist in Großprojekten
besonders wichtig, weil hier das Personalmanagement von unterschiedlichen Mitarbeitern und weiteren Beteiligten (siehe Abschnitt Rollen: Wer macht was im Personalmanagement?) wahrgenommen wird: besonders vom Gesamtprojektleiter, von den Projektmanagern und Projektleitern. Deren Rollen sind genau zu definieren. Ebenso sollte festgelegt werden, für welche Personalmanagement-Themen das PMO verantwort lich ist.
Personalmanagement ist Aufgabe mehrerer Mitarbeiter
Mitarbeiterdisposition im Projekt festlegen
→ Zu klären ist auch der Prozess, mit dem Mitarbeiter für das Gesamtprojekt angefordert oder „zurückgegeben“ werden. Hierbei hat sich folgendes Vorgehen bewährt: Zunächst melden die Teilprojekte ihren Personalbedarf über den Projektmanager an das Gesamtprojekt, dort werden dann frei werdende Mitarbeiter
neu zugeordnet oder zusätzliche Mitarbeiter angefordert.
Anforderungen und Verteilung der Mitarbeiter zentral
Projektleiter und -team auswählen
In der Anbahnungsphase des Projekts kommt es vor allem darauf an, ein erfahrenes und fachlich kompetentes Projektteam auszuwählen. Dazu werden Anforderungsprofile für die wichtigsten Projektrollen erstellt.
Anhand derer lassen sich dann geeignete Mitarbeiter leichter finden.
Das Know-how des Teams sollte alle Aspekte des Projekts abdecken: Fachwissen, Technikkenntnisse, Mana gementerfahrung. Damit das fachliche Know-how ausreichend berücksichtigt wird, ist es sinnvoll, bereits
Mitarbeiter der künftigen Nutzer einzubeziehen. Dies betrifft insbesondere Softwareprojekte. Strategieprojekte können je nach Inhalt ebenfalls eine Einbindung der Fachseite notwendig machen. Bei einer reinen ITKonsolidierung ist dies nicht nötig, eine Reorganisation des Anforderungsmanagements ist jedoch nur unter
Einbindung der Fachseite sinnvoll. Infrastrukturprojekte erfordern keine Einbindung der Fachseite.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.2 Personalmanagement
81
→ Bei Großprojekten in der öffentlichen Verwaltung kommt es besonders auf den richtigen Gesamtprojektleiter an. Er sollte bereits Erfahrung im GroßPM haben und darüber hinaus die in Abbildung 38 dargestellten Anforderungen erfüllen.
Abbildung 38: Talente des Gesamtprojektleiters für Großprojekte in der öffentlichen Verwaltung
Sieben Anforderungen an den Projektleiter
→ Der Gesamtprojektleiter eines Großprojekts sollte sich nur dieser Aufgabe widmen. Denn während die
Leiter kleinerer Projekte zusätzlich noch Linienverantwortung tragen können, braucht ein Großprojekt die
ganze Aufmerksamkeit und Kapazität.
Der Projektleiter sollte dem Projekt zu 100% zur Verfügung stehen
→ Bei Großprojekten kommt es besonders darauf an, erfahrene und weniger erfahrene Mitarbeiter in einem
guten Verhältnis zusammenzubringen. Ist das Team mit zu vielen unerfahrenen Mitarbeitern besetzt, wer den zu viele vermeidbare Fehler gemacht. Sind im Team dagegen zu viele erfahrene Kollegen, behindern
sie sich gegenseitig („stehen sich auf den Füßen“). Das gilt für das Gesamtteam ebenso wie für die Teams
der Teilbereiche bzw. -projekte.
Ausgewogener Mix an erfahrenen und weniger erfahrenen Mitarbeitern
→ Zudem ist bei Großprojekten darauf zu achten, dass interne und externe Mitarbeiter in ausgewogener
Mischung dabei sind. Soll ein Projektteam entstehen, ist ein Mindestanteil an dauerhaft präsenten internen
Mitarbeitern als Know-how- und Kulturträger förderlich. Mit einer solchen ausgewogenen Mischung lässt
sich auch verhindern, dass der Auftraggeber besonders in Schlüsselpositionen langfristig von Externen abhängig wird. Deshalb sollte der Auftraggeber vor allem bei gestaltenden Themen langfristig benötigte
Kompetenzen identifizieren, für die zumindest mittelfristig interne Mitarbeiter aufgebaut werden sollten
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
82
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
(z.B. Architekten, Feinkonzeptionierer, Servicemanager).
Ausgewogener Mix an internen und externen Mitarbeitern
→ Werden besonders viele externe Mitarbeiter eingesetzt, ist auf ausreichende Managementkapazität zu
achten. Nur dann lassen sich sowohl die formalen Prozesse bei der Beschäftigung Externer wahrnehmen als
auch deren Ergebnisse prüfen und sicher übernehmen.
Ausreichend Managementkapazität pro Mitarbeiter bereitstellen
Verfügbarkeit und Rahmenbedingungen für den Projekteinsatz abstimmen
Die Verfügbarkeit der Mitarbeiter für die Projektlaufzeit ist mit deren Linienorganisationen abzustimmen.
Idealerweise sollten sie für die gesamte Zeit zu 100% für das Projekt da sein, auf keinen Fall aber für weni ger als 70%. Bei weniger als 70% treten bereits Probleme auf, weil die Prioritäten nicht klar sind, Mitarbeiter
zu wichtigen Projektterminen und -phasen doch nicht verfügbar sind und sich nicht voll auf die Projektaufgaben konzentrieren.
→ Wer in Großprojekten wichtige Rollen einnimmt, sollte für die gesamte Projektlaufzeit zu 100% verfüg bar sein.
100%-ige Projektverfügbarkeit wichtiger Rollen
Die Rahmenbedingungen für den Einsatz der Mitarbeiter unterscheiden sich teilweise danach, ob es sich
um externe oder interne Mitarbeiter handelt.
●
Rahmenbedingungen für interne Mitarbeiter: Wenn der Mitarbeiter der Organisationseinheit des Auftraggebers angehört, erfolgt die Abstimmung durch interne Vereinbarungen.
→ In der öffentlichen Verwaltung wird die Verfügbarkeit interner Mitarbeiter per Umsetzung, Aufgabenübertragung oder Abordnung formal geregelt. Bei der Abordnung ist die längere Vorlaufzeit zu berücksichtigen; bei der Umsetzung oder Aufgabenübertragung das Herauslösen aus der aktuellen Aufgabe und die entsprechenden Nachbesetzungen.
Beachtung der formalen Regelung interner Mitarbeiter
Sonstige für den Projekteinsatz wichtige Rahmenbedingungen, insbesondere die Führungsverantwortung sowie die Ist-Zeit-Erfassung, werden mit der Linienorganisation des Mitarbeiters vereinbart, insbesondere:
●
Mit den Personalvorgesetzten der eingesetzten Mitarbeiter sind die Verantwortungsbereiche der fachlichen und der disziplinarischen Führung festzulegen. Die fachliche Führung liegt im Projekt.
●
Für ein effizientes Controlling (siehe Kapitel Projektplanung) bedarf es auch bei internen Mitarbeitern
einer Ist-Zeit-Erfassung. (Für externe Mitarbeiter ist diese meist als Basis für die Abrechnung ohnehin
notwendig.)
→ Da in der öffentlichen Verwaltung jede detaillierte Ist-Zeit-Erfassung der Zustimmung des Personalrats bedarf, ist dieser frühzeitig einzubinden.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.2 Personalmanagement
83
Personalrat frühzeitig einbinden
●
Rahmenbedingungen für externe Mitarbeiter: In diesen Fällen ist die Verfügbarkeit vertraglich zu vereinbaren. Der Vertrag regelt beispielsweise die Verpflichtung zur Arbeit „vor Ort“ und den geforderten
Einsatz in Stunden pro Woche. Er enthält aber auch inhaltliche Festlegungen wie die Verpflichtung zum
Know-how-Transfe
→ In Großprojekten ist es sinnvoll, dass der Auftraggeber auch ein Mitspracherecht bei der Auswahl
der einzelnen Mitarbeiter vertraglich vereinbart. So ist es gegebenenfalls ohne Probleme möglich, dass
ein Mitarbeiter auf Wunsch des Auftraggebers ausgetauscht wird.
Mitsprachrecht bei der Auswahl externer Mitarbeiter
Mitarbeiterentwicklungsplan mit Linienorganisation abstimmen
Neben der Verfügbarkeit der Mitarbeiter ist auch ihre Entwicklung während der Projektlaufzeit mit ihrer Li nienorganisation abzustimmen. Hierbei ist darauf zu achten, dass die Entwicklung des Mitarbeiters der geplanten Projektarbeit zugute kommt, also mit den Projektzielen in Einklang steht. Die Planung der Mitarbei terentwicklung sollte auch den Know-how-Transfer von Mitarbeitern berücksichtigen, die den Nutzern des
Projektergebnisses nach Abschluss des Projekts nicht mehr zur Verfügung stehen. Auch die Entwicklung der
Mitarbeiter nach Abschluss des Projekts sollte bedacht werden, da eine ungewisse Zukunft zu Blockadehal tungen der Mitarbeiter führen kann (siehe Kapitel Veränderungsmanagement).
→ Bei lang laufenden Großprojekten ist mit der Linienorganisation und dem Mitarbeiter auch abzustimmen, wie der Mitarbeiter die im Projekt erworbenen Fähigkeiten und Erfahrungen nach dessen Ende sinnvoll nutzen kann. Der Mitarbeiter erhält somit eine langfristige Entwicklungsperspektive. Die Entwicklungsziele sollten messbar sein.
Entwicklungsperspektive des Mitarbeiters aufzeigen
Projektorganisation und -rollen festlegen
Siehe Kapitel Festlegung/Überprüfung der Projektorganisation (Projektorganisation)
Grundlagen für Mitarbeitermotivation legen
Die Projektmitarbeiter werden umso engagierter ans Werk gehen, je besser ihre konkrete Aufgabe im Projekt
auf sie zugeschnitten ist, das heißt je besser sie ihre Erfahrungen und Kenntnisse einbringen können. Aufgaben und Rollen werden so verteilt, dass niemand unter- oder überfordert ist, denn beides könnte Mitarbeiter
demotivieren. Idealerweise sind die Aufgaben vorher mit den Mitarbeitern abgestimmt. Tiefergehende Informationen finden sich im Kapitel Veränderungsmanagement.
→ In lang laufenden Großprojekten sollte die Projektleitung auch bewusst die Mitarbeiterentwicklung zu
ihrer Aufgabe machen, um die Motivation der Mitarbeiter langfristig zu sichern.
Gezielte Mitarbeiterentwicklung fördert Motivation
→ In Großprojekten kommt es darauf an, das ganze Vorhaben (das „Big Picture“) mit den übergreifenden
Projektzielen klar zu kommunizieren und stets präsent zu halten. Sonst besteht auf Grund der hohen Ar beitsteilung die Gefahr, dass Mitarbeiter sich wie kleine Rädchen im Getriebe fühlen, den eigenen Beitrag
zum Erfolg nicht erkennen können und weniger engagiert zu Werke gehen. Es ist also Aufgabe der gesamS-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
84
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
ten Führungsmannschaft (z.B. Gesamtprojektleiter, Projektleiter, Systemarchitekten), jeder kleinen Einheit
und jedem einzelnen Mitarbeiter immer wieder zu verdeutlichen, in welcher Art und Weise sie zum Gesamterfolg beitragen.
Stetige Kommunikation des Erfolgsbeitrags zu den Projektzielen
→ In Großprojekten treffen Mitarbeiter aus verschiedenen Organisationseinheiten und Firmen in einem
Team aufeinander. Sie haben oft extrem unterschiedliche Erfahrungen, Arbeitsweisen und Arbeitsgeschwindigkeiten. Wenn sich Mitarbeiter in der Minderheit befinden, können sie dadurch einen demotivierenden
Kulturschock erfahren. Auch in solchen Fällen hilft es, die Projektziele offensiv zu kommunizieren, so dass
jeder einzelne Mitarbeiter seinen Beitrag zum Projekterfolg kennt und daraus Selbstbewusstsein ziehen
kann. Zudem sollten die Aufgaben von Anfang an nach Erfahrungen und Fähigkeiten der Mitarbeiter verteilt werden. Eine weitere Hilfe gegen den Kulturschock ist die geplante Weiterentwicklung im Projekt.
Kulturschock durch gezielte Interaktion vermeiden
→ Feedbackschleifen mit den Personalvorgesetzten der Mitarbeiter wirken auch motivationsfördernd in
lang laufenden Großprojekten. Auf diese Weise wird die Projektarbeit des Mitarbeiters in seiner Beurtei lung berücksichtigt, auch wenn er lange nicht in seiner Linienorganisation arbeitet.
Regelmäßiges Feedback zur Leistungssicherung
Laufendes Personalmanagement
Auch wenn das Projekt läuft, verfolgt das Personalmanagement die zu Beginn beschriebenen Ziele (siehe
Kapitel Ziele: Was soll das Personalmanagement erreichen?). Dazu prüfen die Verantwortlichen (siehe Kapitel Rollen: Wer macht was im Personalmanagement?), ob und wie sich die zu Projektbeginn herrschenden
Rahmenbedingungen geändert haben. Darauf aufbauend entwickeln sie Maßnahmen, mit denen sich die Zie le auch unter veränderten Bedingungen erreichen lassen, setzen die Maßnahmen um und prüfen deren Wirksamkeit.
Verfügbarkeit eines qualifizierten Teams sichern
Werden im Projektverlauf zusätzliche Mitarbeiter oder Mitarbeiter mit anderen Erfahrungen und Kompeten zen benötigt, so erfolgt erneut ein Auswahlprozess wie bei Projektbeginn. Alternativ können benötigte Kom petenzen im Projekt entwickelt werden.
→ In Großprojekten ist es sinnvoll, jeweils mehrere Mitarbeiter gleichzeitig in das Projektteam zu integrieren. So reduziert sich der Aufwand für die Einarbeitung erheblich.
Projektteams aus mehreren Mitarbeitern zusammensetzen
→ Für die Besetzung wichtiger Rollen und Know-how-Träger (einschließlich ihrer Vertreter) sollte es in
Großprojekten eine Mittel- und Langfristplanung geben. Auf diese Weise lässt sich die Ausbildung und
Aufgabenverteilung so gestalten, dass Mitarbeiter sich im Projektverlauf darauf vorbereiten, künftig zu be setzende Rollen und Aufgaben zu übernehmen. Beispielsweise ist es sinnvoll, Vertreter der Projektleiter
und der Systemarchitekten aufzubauen, die im Laufe der Zeit deren Rollen/Aufgaben verantwortlich übernehmen können.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.2 Personalmanagement
85
Personalplanung mittelfristig gestalten
Motivation des Teams sicherstellen
Das Personalmanagement sorgt dafür, dass das Engagement des Teams und der einzelnen Mitarbeiter hoch
bleibt.
→ In lang laufenden Großprojekten empfinden oft einige Mitarbeiter ihre Aufgaben zunehmend als Routine. Sie sind unterfordert und deshalb weniger motiviert. Im Personalmanagement kommt es also darauf an,
die Aufgaben der Mitarbeiter regelmäßig auf Unterforderungen (aber auch auf latente Überforderungen) zu
prüfen und sie bei Bedarf anzupassen.
Regelmäßige Aufgabenprüfung schützt vor Demotivation
Mitarbeiter entwickeln
Die Aufgaben der einzelnen Mitarbeiter sind regelmäßig mit den für sie vereinbarten Entwicklungszielen abzugleichen. Zeigen sich dabei Abweichungen, sind entweder neue Ziele zu vereinbaren oder die Aufgaben
anzupassen.
→ Sofern Know-how-Transfer zu den Mitarbeitern im Großprojekt notwendig ist, sollte der Erfolg dieses
vereinbarten Transfers geprüft werden – beispielsweise bei den regelmäßigen Mitarbeitergesprächen.
Einrichtung einer Hierarchie von Projektrollen
6.2.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Personalmanagement
erkennen?
Ein erfolgreiches Personalmanagement kann der Auftraggeber an folgenden Kriterien bzw. Prüffragen erken nen:
●
Stehen die erforderlichen Mitarbeiter rechtzeitig für den Projekteinsatz zur Verfügung?
●
Sind die wichtigen Projektrollen mit Mitarbeitern besetzt, die dem Projekt vollzeitig zur Verfügung ste hen?
●
Werden die Mitarbeiter regelmäßig über das Projekt, die Ziele, den Status und ihren eigenen Beitrag
dazu informiert und so motiviert?
●
Müssen Aufgaben und Rollen wegen Über- oder Unterforderung öfter gewechselt werden?
●
Ist für jeden Projektmitarbeiter die Mitarbeiterentwicklung geplant und abgestimmt?
●
Sind die Projektziele in den persönlichen Zielen der Mitarbeiter verankert?
6.2.6 Grundlegende und weiterführende Literatur
●
Tom DeMarco, Timothy Lister: Peopleware – Productive Projects and Teams, Dorset House Publishing
1987
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
86
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
6.3 Kommunikationsmanagement
6.3.1 Ziele und Rahmenbedingungen: Was soll mit der Projektkommunikation erreicht
werden?
Viele Erfolgsfaktoren in IT-Großprojekten der öffentlichen Verwaltung werden maßgeblich (wenn auch nicht
allein) durch Kommunikation bestimmt: Gute Kommunikation hilft, das Alignment der Stakeholder, die kontinuierliche Unterstützung durch die Leitung der Organisation und die Mitarbeit der Nutzer zu sichern. Auch
ein Erfolgsfaktor wie die Motivation des Projektteams wird stark durch (projektinterne) Kommunikationsmaßnahmen bestimmt.
Um diese vielfältigen Wertbeiträge leisten zu können, muss das Kommunikationsmanagement unterschiedlichste operative Ziele erfüllen:
●
Alle Beteiligten innerhalb und außerhalb des Projekts einbinden und dadurch Motivation auf allen Ebe nen der Organisation schaffen/erhalten
●
Informationen bereitstellen, die jeder Beteiligte für die erfolgreiche Bearbeitung seiner Aufgaben bzw.
für die erfolgreiche Übernahme seiner Rolle benötigt
●
Projektziel für alle Beteiligten deutlich kommunizieren, so dass eine Fokussierung eintritt
●
Sicherstellen, dass das Projektziel nicht durch Interessen einzelner Beteiligter/Gruppen (projektintern
wie außerhalb des Projekts) gefährdet wird.
Zu diesem Zweck umfasst das Kommunikationsmanagement folgende Themen: kontinuierliches Stakeholdermanagement (das Erreichen eines initialen Stakeholder Alignment im Rahmen der Projektanbahnung
wurde bereits im Kapitel Festlegung/Überprüfung der Projektrahmenbedingungen erläutert), Projektmarketing und -kommunikation, sowohl projektintern als auch nach außen sowie das Berichtswesen. Für jedes dieser Themenfelder werden im Folgenden detaillierte Ziele vorgestellt:
●
●
Ziele des kontinuierlichen Stakeholdermanagements (insbesondere der maßgeblichen Stakeholder)
●
„Keep your friends close and your enemies closer“ (EN-604) – dicht an Einflussgruppen (und
auch potenziellen Gegnern) bleiben, um frühzeitig deren Interessen, Pläne, Bedenken zu erfahren
●
Verringerung/Vermeidung von Zielkonflikten für das Projekt durch Schaffung von Zieltransparenz und offene Adressierung von Konflikten
●
Steigerung der Projekterfolgswahrscheinlichkeit durch Vermeidung von “Überraschungen“ für
Stakeholder, erreicht durch frühe Hinweise auf mögliche Risiken, sowie durch Schaffung eines
positiven Momentums im Projektumfeld (Schaffung einer „sich selbst verstärkenden Erfolgsstory“)
●
Kontinuierliche Unterstützung der Stakeholder sicherstellen (oder zumindest das Gegenteil von
Unterstützung – Behinderung – verhindern), z.B. für das gemeinsame Bekämpfen von Risiken.
Allgemeine Ziele von Projektmarketing und -kommunikation. Während das kontinuierliche Stakeholdermanagement hauptsächlich auf persönliche Kommunikation (Gespräche) setzt und sich auf maß gebliche Stakeholder fokussiert, hat das Projektmarketing oder die Projektkommunikation im weiteren
Sinne einen breiteren Fokus. Es beantwortet vor allem folgende Fragen:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.3 Kommunikationsmanagement
87
Abbildung 39: Ziele des Kommunikationsmanagements
●
Ziele des Berichtswesens. Das Berichtswesen ist eine spezielle Art der Kommunikation mit standardisierten, periodisch erstellten Berichten, die insbesondere zu den Kerndimensionen des Projektstatus Auskunft geben (Kosten/Budget, Zeit, Qualität/inhaltlicher Fortschritt, Risiken). Einzelziele sind hier:
●
Laufend einen aktuellen Status über das Gesamtprojekt zu vermitteln
●
Motivation über Erfolge zu kommunizieren
●
Handlungsbedarfe an Stellen darzustellen, an denen es nicht gut läuft.
6.3.2 Rollen: Wer macht was in der Projektkommunikation?
In der Projektkommunikation sind die folgenden Rollen zu besetzen:
Projektleiter
Trägt die Gesamtverantwortung für das Kommunikationsmanagement.
● Muss insbesondere sicherstellen, dass alle relevanten Stakeholder und Zielgruppen in
die Kommunikation einbezogen werden.
● Ist selber für Kommunikation verantwortlich, insbesondere in Richtung der
maßgeblichen Stakeholder.
Kommunikationsmanager
Übernimmt die operative Koordination der Kommunikation.
● Erstellt Kommunikationspläne.
● Überwacht Erstellung von Kommunikationsunterlagen, sorgt für Durchführung von
Kommunikationsmaßnahmen.
● Überwacht Erfolg/Effektivität der Kommunikation.
Administratoren
Übernehmen die operative Betreuung oder auch Durchführung von
Kommunikationsmaßnahmen.
● Sind zumeist Mitarbeiter des PMO.
● Organisieren z.B. Informationsveranstaltungen oder verwalten Mailinglisten.
Teilprojektleiter und
Projektmitarbeiter
Sind allesamt als „Botschafter“ des Projekts wissentlich oder unwissentlich in die
Projektkommunikation eingebunden.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
88
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Tabelle 10: Rollen und Verantwortlichkeiten im Kommunikationsmanagement
Die einzelnen Stakeholder und „Empfänger“ von Kommunikationsmaßnahmen werden an dieser Stelle nicht
erwähnt, da es hier um die treibenden Rollen des Kommunikationsmanagements geht. Zu den „Empfängern“
folgen weitere Ausführungen unten.
6.3.3 Ergebnisse: Welche Dokumente sollen erstellt werden?
Die wichtigsten Ergebnisdokumente des Kommunikationsmanagements sind:
●
Stakeholder- und Zielgruppenübersicht
●
Kommunikationsplan je Zielgruppe/je Stakeholder
●
Information durch Kommunikation auf unterschiedlichen Wegen (z.B. Gespräche, Medien, Aushänge,
Newsletter, Präsentationen, Artikel in Mitarbeiterzeitschriften).
6.3.4 Prozesse: Wie geht das Kommunikationsmanagement vor?
Im Kommunikationsmanagement sind vier Prozesse vorgesehen – ein initialer zum Aufsetzen der Kommunikation und weitere drei Prozesse zur Durchführung des Stakeholdermanagement, der allgemeinen Projektkommunikation sowie zum Berichtswesen. Die wichtigsten Schritte bei diesen Prozessen sind in Abbildung
40 aufgeführt.
Abbildung 40: Prozesse im Kommunikationsmanagement
Aufbau Kommunikationsmanagement
Empfehlenswert ist, das Kommunikationsmanagement in zwei Schritten aufzubauen:
●
1. Festlegung der Rollen und Verantwortlichkeiten. Zunächst sind die Rollen zu besetzen und deren
Verantwortlichkeiten zu definieren.
●
2. Festlegung der Prozesse und Periodizitäten. Danach werden die Teilprozesse des Kommunikationsmanagements definiert – hierzu gehört insbesondere die Anpassung der nachfolgend dargestellten laufen-
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.3 Kommunikationsmanagement
89
den Prozesse auf die eigene Organisation. Erfolgreiche Kommunikationsprozesse zeichnen sich durch
folgende Merkmale aus:
●
Keine Zielgruppe wird vergessen.
●
Kommunikation findet adressatengerecht statt – Kommunikation wird aus Empfänger statt aus
Sendersicht gestaltet.
●
Am Anfang einer jeden Maßnahme wird sichergestellt, dass die Mitarbeiter da abgeholt werden,
wo sie stehen.
●
Die Kommunikation umfasst auch „Zuhören und Verstehen“ statt nur Senden.
●
Ungeplante/ungewollte Kommunikation wird eingedämmt (am besten werden Dokumente, die
nicht einem größeren Adressatenkreis zugänglich gemacht werden sollten, gar nicht erst erstellt).
●
Kommunikation wird als koordinierter Prozess durchgeführt (siehe Abbildung).
Abbildung 41: Kommunikation als koordinierter Prozess
→ In großen IT-Projekten hat es sich bewährt, auch für die projektinterne Kommunikation Standards zu definieren und z.B. in einer Kommunikations-Charta niederzuschreiben. Ein Beispiel findet sich in Abbildung
42.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
90
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Abbildung 42: Beispiel einer Kommunikations-Charta
Kommunikationsstandards schriftlich festhalten
Kontinuierliches Stakeholdermanagement
(Neue) Stakeholder identifizieren/priorisieren
Eine (erste) Liste maßgeblicher Stakeholder ist im Rahmen der Projektanbahnung entstanden. Diese Liste ist
kontinuierlich im Rahmen des Stakeholdermanagements anzupassen – so können beispielsweise in späteren
Phasen des Projekts, wenn die Betriebsetzung naht, Linienmanager in tieferen Ebenen der Organisation als
wichtige Einflussgruppe identifiziert werden, die dies zu Beginn des Projekts noch nicht waren.
Die Stakeholder sollten danach priorisiert werden – dies geschieht anhand zweier Fragen: „Wie hoch ist die
Bedeutung eines Stakeholders/einer Zielgruppe?“ sowie „Wann wird der Stakeholder/die Zielgruppe gebraucht?“ Die Abbildung 43 zeigt, wie damit die vordringlichen Stakeholder identifiziert werden können.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.3 Kommunikationsmanagement
91
Abbildung 43: Priorisieren der Stakeholder/Zielgruppen
Interessen/Ziele/Prioritäten der Stakeholder analysieren
Für jede maßgebliche Stakeholder-Gruppe ist zu analysieren, welche Agenda, Interessen und Ziele sie in Bezug auf das Projekt haben – sind sie Nutznießer, Interessierte oder eventuell sogar wahrscheinliche Opponen ten?
→ Stakeholder-Gruppen und Einheiten, die sich in anderen Berichtslinien befinden als die Projektleitung,
können häufig nur über Motivation gesteuert werden. In diesem Fall muss die Projektleitung über positive
Motivation sicherstellen, dass dortige Mitarbeiter bzw. Stakeholder für die Ziele des Projekts arbeiten –
dies geht dann nicht über Dienstaufsicht (Weisung) und Unterstellung, denn Projekte werden meist über
Fachaufsicht gesteuert.
Mitarbeit vieler Stakeholder kann nur über Motivation sichergestellt werden
Kommunikationsmaßnahmen planen und durchführen
Für jede maßgebliche Stakeholder-Gruppe ist danach eine Reihe von Kommunikationsmaßnahmen vorzusehen – diese können von regelmäßigen bilateralen Gesprächen mit den LA-Mitgliedern bis zur Zusendung allgemeiner Projekt-Updates reichen. Bei den Maßnahmen für große Stakeholder-Gruppen (z.B. Anwender) ist
die Grenze zum Projektmarketing (siehe unten) fließend. Die Zielsetzungen einer typischen Projektkommunikation intern und extern sind in Abbildung 44 aufgeführt.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
92
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Abbildung 44: Zielsetzungen der Kommunikation
→ Insbesondere in Großprojekten, die anfangs auf der politischen Ebene beschlossen wurden, dann aber
eher im Hintergrund agieren, ist eine kontinuierliche Wiederholung der Kommunikationsplanung besonders
wichtig. Viele Stakeholder haben eventuell am Anfang eher eine passive Grundeinstellung zum Projekt (sie
wollen „nur mal teilnehmen“) – und zeigen dann umso mehr Widerstand, je konkreter das Projekt wird.
Kommunikationsplanung regelmäßig wiederholen
→ Eine spezielle Gruppe von Stakeholdern sind die Beauftragten der Organisation, z.B. für Gleichstellung,
für Datenschutz oder für Schwerbehinderte – viele IT-Projekte betreffen Kernbelange dieser Beauftragten,
die entsprechend ein hohes Interesse am Projekt entwickeln. Die generellen Regeln zur Kommunikation
treffen hier genauso zu:
●
Genau verstehen, was die Beauftragten wirklich treibt und worauf sie tatsächlich achten müssen
●
Für sie wichtige Punkte prominent und/oder gesondert kommunizieren und nicht an untergeordneter
Stelle in einem Dokument verstecken
●
Nicht nur Konzepte abliefern und Stellungnahmen dazu einfordern, sondern frühzeitig in eine gemeinsame Erarbeitung von Themen mit festen Zulieferterminen eintreten, z.B.: „Wenn diese fünf Fragen
zur Datenhaltung bis Ende der folgenden Woche beantwortet werden, dann kann das Feinkonzept vom
Datenschutz abgenommen werden."
Proaktive Kommunikation mit Sonderbeauftragten der Organisation
→ Insgesamt sollte gerade mit den Stakeholdern in komplexen IT-Projekten eine sehr offene Kommunikati onskultur gepflegt werden, gerade auch bezüglich der Risiken im Projekt – im Sinne eines „Wir arbeiten
hier in einem sehr komplexen Projekt, Projekte dieser Größenordnung bekommen typischerweise irgendwo
Probleme, wir sind aber aufgestellt, diese Probleme zu adressieren“. Dies funktioniert im „Krisenfall“ bes ser als eine zu positive Kommunikation im Sinne von „Wir haben alles im Griff“.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.3 Kommunikationsmanagement
93
Frühzeitige Kommunikation der Herausforderungen im Projekt
Projektmarketing und -kommunikation
Zielgruppen identifizieren, bestehende überprüfen
Im ersten Schritt des Projektmarketing-Prozesses sind die Zielgruppen zu identifizieren, für die Kommunikationsmaßnahmen sinnvoll erscheinen. Für jede Zielgruppe sollte grob die Interessenslage und der Kenntnisstand in Bezug auf das Projekt analysiert werden – eine detaillierte Betrachtung lohnt sich nur für maßgebli che Stakeholder.
Kommunikationsplan je Zielgruppe aufstellen
Je Zielgruppe wird ein Mix von Kommunikationsmaßnahmen zusammengestellt – dieser sollte verschiedene
Medien umfassen (z.B. Präsentationen des Projekts in größeren Workshops und Regelmeetings, Newsletter,
Artikel in Mitarbeiterzeitschriften).
Die Kommunikationsmaßnahmen insbesondere in Bezug auf zukünftige Anwender sollten keine Einbahnstraße sein, das Kommunikationsmanagement muss hier zum „Ohr“ des Projekts werden – haben die zukünf tigen Anwender den Sinn und Nutzen des Projekts verstanden? Was sind ihre konkreten Anforderungen, die
vielleicht noch nicht im Projekt verstanden wurden?
→ In Großprojekten gerade mit potenzieller öffentlicher Aufmerksamkeit ist speziell zu planen, wie das
Projekt mit den Medien umgeht oder umgekehrt, wie man die Aufmerksamkeit der Medien vermeidet.
Kontakt mit öffentlichen Medien speziell planen
→ Ebenfalls speziell für Großprojekte, insbesondere wenn sie Pilot- oder Leuchtturmcharakter aufweisen,
ist die Kommunikation mit und für Lieferanten – Lieferanten sind häufig an einer großen Öffentlichkeit für
derartige Referenzen interessiert. Der Auftraggeber steht da vor einem Zwiespalt – er kann Gegenleistungen aushandeln für solche Zugeständnisse, erhöht aber sofort das Imagerisiko für sich, sollte das Projekt
fehlschlagen.
Kommunikation mit und für Lieferanten/AN gezielt planen
Kommunikationsmaßnahmen planen und durchführen
Die einzelnen Maßnahmen aus dem Plan sind dann zu detaillieren und durchzuführen (z.B. Unterlagen zu er stellen).
Neben den klassischen Kommunikationsmaßnahmen wie z.B. Workshops, Präsentationen oder Regelmeetings eignen sich insbesondere zwei modernere Medien, schnell und unverfälscht größere Zielgruppen zu erreichen:
●
Projekte können einen eigenen Newsletter auflegen, der sich beispielsweise adressatengerecht an die
projektbeteiligten Mitarbeiter oder an interessierte zukünftige Anwender auf freiwilliger Basis richtet.
Als typische Inhalte können neben den erreichten Meilensteinen und Erfolgsmeldungen auch aufkommende Schwierigkeiten und deren Lösung dargestellt werden. Dieses Medium kann genutzt werden, um
Personalia in einem weiten Kreis bekannt zu machen oder auf weitere (klassische) Kommunikationen
hinzuweisen, wie beispielsweise Meetings oder Workshops. Zeitpläne und geplante oder stattfindende
Trainings können abgekündigt werden und generell alle das Projekt betreffende Inhalte, die in kurzer
Zeit einem weiten Kreis an Mitarbeitern zugänglich gemacht werden sollen, kommuniziert werden.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
94
●
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Weiterhin sollte es in Großprojekten stets einen Auftritt im Intranet geben, der sich an Mitarbeiter der
gesamten Organisation wendet und den Nutzen des Projekts für den einzelnen Mitarbeiter klar heraus stellt. Auch an dieser Stelle sollten gegebenenfalls bestehende Fragestellungen, die die gesamte Organi sation betreffen nicht ausgespart werden. Sehr hilfreich ist es, wenn diese Bemühungen durch den jeweiligen Leiter der Organisation unterstützt werden, etwa indem eine Videobotschaft an dieser Stelle online
veröffentlicht wird. Klassische Inhalte sind dabei:
●
Inhalt des Projekts: Worum geht es im Projekt? Welche Geschäftsprozesse sind betroffen, welche
nicht? Wird es Änderungen in der Organisationsstruktur geben?
●
Hintergrund und Perspektive: Wieso soll dieses Projekt durchgeführt werden und was erwartet
man sich davon?
●
Zeitplan: Welche großen Meilensteine hat das Projekt? Welche Termine gibt es in der näheren
Zukunft (z.B. LA- oder Pressetermine)?
●
Aktuelles aus dem Projekt: Was sind die neuesten Entwicklungen? Hier kann beispielsweise auf
einen Newsletter verlinkt werden.
●
Ansprechpartner: Wen kann ein Mitarbeiter kontaktieren, wenn er Informationen sucht? Wer ist
zuständig für welche Aufgaben im Projekt
→ Presse: Vor allem bei Projekten im öffentlichen Sektor sinnvoll, da dort das Interesse der Medien besonders hoch ist. Welche Medienechos gibt es auf das Projekt und seinen Fortgang?
Pressestimmen einbeziehen
→ In sensiblen IT-Projekten der öffentlichen Verwaltung, die ein hohes politisches Risiko aufweisen (z.B.
große Projektsumme, hohe mögliche Stellenverluste) gibt es häufig Gruppen, die ein Interesse daran haben,
(vermeintliche) Probleme an die Öffentlichkeit zu bringen – dies kann z.B. ein politischer Gegner eines der
Beteiligten sein. Aus diesem Grund ist es bei interner und externer Kommunikation besonders wichtig, jedes Dokument aus Sicht potenzieller Empfänger kritisch zu bewerten und so Missverständnisse zu vermeiden.
Sensibilität schriftlicher Unterlagen beachten
→ Während langer projekt-interner Arbeitsphasen, z.B. während der andau-ernden Ausrüstung eines Rechenzentrums oder zwischen der öffentlichen Auslegung von Bauleitplänen bis zum tatsächlichen Baubeginn,
sollten wahrnehmbare Zwischeninformationen erfolgen.
→ Bei der Eigendarstellung des Projekts ist eine ausgewogene Balance nötig: Sie sollte positiv, aber authentisch sein und gleichzeitig deutlich wahrnehmbar, aber nicht übertrieben erfolgen.
- Negativmeldungen erzeugen ein kontraproduktives Momentum, das schon per se die Erfolgswahrscheinlichkeit des Projekts reduziert. Gleichzeitig muss die Kommunikation aber ungeschönt sein, um glaubwürdig
und damit effektiv zu sein. Lösungsvorschlag: Drohen beispielsweise Verschiebungen von Meilensteinen,
sollte die Analysearbeit betont werden, auf deren Basis nunmehr eine realistische Neuplanung möglich wurde.
- Wahrnehmbarkeit, Verständlichkeit und Verhältnismässigkeit sind ebenso eine Grundvoraussetzung für die
Effektivität von Kommunikation. Gleichzeitig ist ein übertriebener Auftritt des Projekts (und häufig schon
das Wort Projektmarketing) im Innenverhältnis zu meiden – zu schnell stehen Ressourcenaufwände im Zu sammenhang mit Kommunikation und Marketing im Verdacht, unnötig zu sein, zu schnell bringt die Aufmerksamkeit Neid bei anderen Mitarbeitern hervor und erzeugt so Widerstände. Lösungsvorschlag: pauscha-
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.3 Kommunikationsmanagement
95
le „Push“-Maßnahmen (wie E-Mails an alle Mitarbeiter, Artikel in Mitarbeiterzeitschriften) sehr selektiv einsetzen und zielgruppengenau kommunizieren.
Erfolgskontrolle der Maßnahmen vornehmen
Kommunikation als reine „Sendeleistung“ erweist sich häufig als nicht effektiv. Insbesondere bei indirekter
Kommunikation, bei der beispielsweise die Anwender über ihre Linienorganisation mit Informationen versorgt werden sollen, ist nachzuprüfen, ob die gewünschten Inhalte tatsächlich bei den geplanten Zielgruppen
angekommen sind und verstanden worden. Hierfür empfiehlt es sich, abseits etablierter Berichtswege ein
paar „Nichtgespräche“ mit Mitarbeitern an den Endpunkten der Kommunikationslinien zu führen – was ist
bei ihnen an Kommunikation angekommen? Welche Nachrichten wurden verstanden, decken sie sich mit den
Zielen der Kommunikation? Welche Misstöne und Missverständnisse sind eventuell entstanden?
Kontinuierliches Berichtswesen
Berichtsanforderungen analysieren/prüfen
Im Berichtswesen ist zunächst zusammen mit den Empfängergruppen der Berichte festzulegen, welche Inhalte (und welche Standardberichte) durch das Projekt regelmäßig beigebracht werden sollten. Viele Organisationen haben beispielsweise Prozesse zum Portfoliomanagement der Projekte, in deren Rahmen Standard berichte definiert wurden.
Berichte definieren und implementieren
Für zusätzliche Berichtsanforderungen müssen danach die genauen Berichte ausgeprägt und möglichst effizi ent bereitgestellt werden – hierfür bietet sich häufig eine Tool-Unterstützung an.
Ein regelmäßiges, übergreifendes Berichtswesen umfasst im Regelfall drei
Elemente, die in nachfolgender Abbildung noch weiter erläutert sind – Berichtserstattung an die höchste Lei tungsebene, wöchentliche Statusberichte sowie Nachhalteberichte für spezielle Aktivitäten.
Abbildung 45: Elemente des Großprojekt-Berichtswesens
Viele Statusberichte verfehlen ihren Zweck – sie sind nicht ergebnisorientiert (Fokus „was haben wir getan“
anstatt „was haben wir erreicht“), sie sind häufig in der Wortwahl generisch (z.B. „Feinkonzeption erstellt“
statt „Anforderungen Berichtswesen definiert“) und sie fokussieren häufig undifferenziert auf Probleme und
Risiken, statt diese zu unterteilen in „was können wir selbst lösen“ vs. „wo brauchen wir Hilfe von außen“
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
96
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
(z.B. Entscheidungsbedarf durch den LA). In einem Bericht sollten zudem jegliche erwähnten Probleme,
auch die selbst lösbaren, mit Maßnahmenplänen versehen sein.
Ein Beispiel für einen Bericht an die höchste Leitungsebene, z.B. im Rahmen des LA, zeigt folgende Abbildung 46.
Abbildung 46: Beispiel für einen Bericht zum Gesamtprojektstatus
Zur Definition des Berichtswesens zählt auch die genaue Definition von Zuliefererleistungen – wer muss
welche Inhalte bis wann in der Berichtsperiode liefern, damit sie pünktlich in die Berichte einlaufen? Wichtig für den Erfolg des Berichtswesens ist eine hohe Qualität der Berichte, und zwar von Anfang an.
Berichte erstellen und übermitteln
Schließlich sind die Berichte in der vereinbarten Periodizität zu erstellen und an die Empfänger zu leiten.
Hierbei sollte regelmäßig geprüft werden, ob die Berichte wirklich gelesen und verstanden werden.
Für die effiziente Erstellung und Verteilung von Berichten existieren vorkonfigurierte Tools, z.B. auf Basis
von Teamservern. Die Nutzerfreundlichkeit insbesondere für die höchste Leitungsebene ist jedoch zu prüfen.
6.3.5 Erfolgsmessgrößen: Woran kann der Auftraggeber eine gute Projektkommunikation
erkennen?
Der Erfolg des Kommunikationsmanagements entsteht hauptsächlich in den Köpfen der Empfänger. Es empfiehlt sich deswegen, die Empfänger direkt zur Effektivität der Kommunikation zu befragen:
●
Fühlen sich die maßgeblichen Stakeholder hinreichend informiert? Sind ihnen Projektstatus und aktuelle
Probleme geläufig? Ist ihnen bewusst, wie sie selber aktuell zum Projekterfolg beitragen können/müssen? Fühlen sie sich dem Projekt nach wie vor verpflichtet?
●
Wissen Anwender über das Projekt Bescheid? Wissen sie, wann die entstehende Lösung zu ihnen kommen wird? Sind ihnen die Konsequenzen und Auswirkungen bewusst?
●
Empfinden die Empfänger der Berichte diese als aussagekräftig und relevant? Orientieren sich die Dis kussionen in Projekt und LA an den Berichten?
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.3 Kommunikationsmanagement
97
6.3.6 Grundlegende und weiterführende Literatur
Keine spezielle Empfehlung.
6.4 Veränderungsmanagement
6.4.1 Ziele und Rahmenbedingungen: Was soll mit dem Veränderungsmanagement erreicht
werden?
Ziele von Großprojekten sind häufig (sofern es sich nicht um reine Infrastrukturprojekte handelt) sichtbare,
nachhaltige Verhaltensänderungen – ein Projekt ist erst erfolgreich, wenn es beispielsweise nicht nur die
neue IT-Lösung bereitstellt, sondern die Anwender diese auch erfolgreich einsetzen und damit die übergrei fenden fachlichen Ziele des Projekts erreicht werden.
Damit haben Großprojekte im Regelfall massive Auswirkungen auf die dahinterstehende(n)
Organisation(en), sie ändern mindestens Arbeitsweisen und Arbeitsmittel, häufig aber auch die Fachlichkeit,
die Aufgabenverteilung, die Aufbauorganisation oder die Geschäftsprozesse. Um ein solches Projekt erfolg reich umsetzen zu können, ist ein effektives und zielgerichtetes Veränderungsmanagement nötig, das die angestrebten Verhaltensänderungen klar definiert, ihre Erreichung sorgfältig plant und begleitet sowie die durch
Unsicherheiten und generelle Bedenken bedingten Widerstände bei den Mitarbeitern bereits im Vorfeld er kennt und ausräumt – oder besser noch, diese gar nicht erst aufkommen lässt.
Das Kapitel Veränderungsmanagement betrachtet vorrangig die Veränderungen innerhalb des Projektes und
innerhalb der öffentlichen Verwaltung. Durch Großprojekte können sich jedoch auch Veränderungen für andere Beteiligte (z.B. Bürger, Unternehmen, Verbände) ergeben. Die Erfahrung aus abgeschlossenen und laufenden Großprojekten zeigt, dass zunehmend Diskussionen zum Datenschutz entstehen, die Notwendigkeit
bestimmter Vorhaben in Frage gestellt wird und Projekte zu gesellschaftlichen Auseinandersetzungen führen
können. Die Grundlagen des Veränderungsmanagements sollten deshalb auch auf andere Beteiligte angewendet werden; die Disziplin Kommunikationsmanagement ist dabei zu berücksichtigen.
Widerstände innerhalb der Organisation können an verschiedenen Stellen entstehen:
●
Unmittelbar Betroffene (z.B. Anwender) müssen sich mit neuen Arbeitsweisen und Anwendungen befassen, die zu Beginn häufig zu Mehraufwand oder zumindest Unsicherheiten führen, da sich eingespielte
Abläufe verändern. Eine grundsätzliche Änderung der Abläufe führt in der Regel auch zu einer Umorganisation, die weitere Unruhe bewirkt, da sich der Einzelne mit neuen Strukturen und Kollegen anfreunden muss. Wenn auch im öffentlichen Sektor seltener Angst vor einem Jobverlust besteht, so doch häufig
die vor einer Versetzung.
●
Mittelbar Betroffene (z.B. Disziplinarvorgesetzte, Personalräte, Gleichstellungsbeauftragte, Datenschutz,
Sicherheitsbeauftragte, Schwerbehindertenvertretung) können sich bei ungenügender Kommunikation
und Einbindung übergangen fühlen und eine Blockadehaltung einnehmen, die auf die unmittelbar Betroffenen ausstrahlt und das Projekt gefährden kann – z.B. indem den Anwendern nicht genügend Zeit eingeräumt wird, sich mit neuen Arbeitsweisen und IT-Systemen auseinanderzusetzen.
Ziel des Veränderungsmanagements muss sein, den unmittelbar oder mittelbar Betroffenen die Notwendigkeit der Veränderung zu verdeutlichen und damit das Bekenntnis der Einzelnen zum Projekt zu fördern. Eine
Organisation und ihre Mitglieder haben ein gewisses Beharrungsvermögen, der Einzelne erkennt oft die
Handlungsnotwendigkeit nicht, denn „bisher ging es ja auch“.
Um eine nachhaltige Verhaltensänderung zu erreichen, muss das Veränderungsmanagement vier Disziplinen
zusammenbringen – es muss im Rahmen der Unternehmenskultur die Vorbildfunktion der Führungskräfte
nutzen und stärken, Verständnis und Selbstverpflichtung bei den Mitarbeitern erreichen, mit klaren StruktuS-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
98
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
ren und Prozessen die Vorbedingungen für Wandel schaffen und die notwendigen Talente fördern und Fähigkeiten aufbauen (siehe Abbildung 47).
Abbildung 47: Die vier Disziplinen des Veränderungsmanagements
Gewährleistung der Vorbildfunktion von Führungskräften im Rahmen der Unternehmenskultur
Führungskräfte aller Ebenen sind Multiplikatoren und müssen durch ihr Verhalten die sich im Rahmen des
Projekts ergebenden Aufgaben und Verhaltensweisen unterstützen. Dies bedeutet, dass sie sich ihrer Vorbildfunktion bewusst werden und diese gezielt wahrnehmen müssen. Liegt ein Erfolgsmerkmal eines Projekts in
der abteilungs- oder behördenübergreifenden Zusammenarbeit auf Arbeitsebene, so kann die Leitungsebene
nicht im Silodenken verharren, sondern muss die Kollaboration vorleben. Dies ist umso schwerer zu errei chen, je mehr die Unternehmenskultur diesem „neuen Denken“ widerspricht. Erreicht werden kann die Vorbildfunktion durch eine zielgerechte Adressierung der Multiplikatoren, beispielsweise durch spezielle Workshops und durch eine fortwährende Kommunikation über den Lebenszyklus des Projekts hinweg, die das notwendige Verhalten im Einklang mit der Unternehmenskultur darstellt und gleichzeitig den Beitrag der nur
mittelbar Betroffenen zum Projekterfolg betont.
Sicherstellung von Verständnis und Verpflichtung bei den Betroffenen
Um das Aufkommen von Widerständen unter den betroffenen Mitarbeitern zu vermeiden, ist es erforderlich,
frühzeitig und vorausschauend das Verständnis für Ziele und Folgen des Projekts zu schaffen sowie die durch
die Führungskräfte vorgelebten Verhaltensweisen als verbindlich auch für die Mitarbeiter darzustellen und
dadurch zu sichern, dass alle Mitarbeiter der Organisation diese unterstützen. Dazu ist es notwendig, ziel gruppenorientiert zu kommunizieren, so dass jeder Beteiligte zu jedem Zeitpunkt ein Verständnis dafür be sitzt, was im Rahmen des Projekts von ihm erwartet wird und was in der Zukunft seine Rolle sein wird. Dazu
müssen die betroffenen Mitarbeiter dort abgeholt werden, wo sie stehen, um ihre Meinungen und Sorgen einbeziehen zu können. Ein zukünftiger Nutzer beispielsweise hat oftmals einen vollkommen anderen Informationsstand als ein am Projekt beteiligter IT-Mitarbeiter. Die Ausgestaltung der Kommunikationsmaßnahmen
muss darauf ausgerichtet sein.
→ Die geringere Flexibilität im Personalmanagement des öffentlichen Sektors führt häufig zu einem wenig
ausgeprägten Konsequenzenmanagement – Mitarbeiter erleben kaum positive Konsequenzen (z.B. monetärer Natur oder offenes Lob), wenn sie Zielvorgaben erfüllen oder übererfüllen, sie erleben aber auch selten
negative Konsequenzen bei Untererfüllung (wie etwa Reduktion des Einkommens, Anwendung der Bundesdisziplinarordnung oder Inregressnahme). Dies limitiert das Instrumentarium des Veränderungsmanagement. Statt Belohnung (Incentivierung - EN-605) oder „Zwang“ sollte deshalb ein stärkerer Fokus auf
Überzeugung gelegt werden. So könnten z.B. Qualitätsverbesserungen für den Endkunden als positive ErS-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.4 Veränderungsmanagement
99
gebnisse des Projekts herausgestellt werden.
Fokus auf Überzeugung legen
Unterstützung durch klare Strukturen und Prozesse
Die naheliegendste und damit häufig zu stark im Mittelpunkt stehende Disziplin des Veränderungsmanagements befasst sich mit der Anpassung von Organisationsstrukturen und Prozessen. Sicherlich müssen betroffene Mitarbeiter durch klare neue Strukturen und Prozesse in den neuen Verhaltens- und Arbeitsweisen un terstützt werden. Die Qualität von Endprodukten und Durchlaufzeiten verbessert sich, wenn strukturell dafür
klare Verantwortung und eine entsprechende Incentivierung geschaffen wurde. Entstehen Unsicherheiten
durch schlecht definierte Prozesse oder unklare Zuständigkeiten, kann die Fehlerrate in der Prozessbearbei tung steigen, gleichzeitig fühlt sich niemand für die Endqualität verantwortlich – beides kann den Erfolg des
Projekts gefährden. Dennoch sind Organisationsanpassungen nicht hinreichend – sie erzeugen besonders
schnell Widerstände, weil es häufig wahrgenommene Verlierer gibt; diese Widerstände müssen durch die anderen Disziplinen des Veränderungsmanagements abgefangen werden.
Besonderes Augenmerk sollten die LA-Mitglieder auf die Zukunft der Projektmitarbeiter richten. Insbesondere gegen Ende des Projekts können andernfalls Zukunftssorgen der bislang im Projekt beschäftigten Mitarbeiter dazu führen, dass diese ein Projekt in die Länge ziehen, um möglichst lange in dieser Aufgabe zu ver bleiben. Auch die plötzliche und nicht rechtzeitig kommunizierte Abordnung in ein anderes Projekt kann zu
erheblichen Motivationsverlusten führen – bei kompetenten Mitarbeitern wäre dies ein schmerzhafter Verlust. Eine offene und frühzeitige Adressierung dieser Herausforderung und das Aufzeigen realistischer Zukunftsoptionen kann das verhindern.
→ Organisationen im öffentlichen Sektor sind häufig noch stärker im Ressort- und damit Silodenken ver haftet. Zugenommen hat auch die Konkurrenz der Behörden untereinander z.B. bei der konkurrierenden
Bereitstellung von Leistungen etwa durch eine dienstleistungsorientierte Ausrichtung. Wo für den Erfolg eines Projekts abteilungs-, behörden- oder sogar ressortübergreifende Zusammenarbeit erforderlich ist, muss
die Kollaboration eingeübt werden. Das Veränderungsmanagement muss Formate schaffen, die persönliche
Kontakte zwischen Abteilungen, Behörden oder Ressorts knüpft, so dass z.B. nicht bei jedem kleinen Problem gleich die Leitungsebene als Eskalationsinstanz eingreifen muss.
Übergreifende Zusammenarbeit stärken
→ Führungskräfte im öffentlichen Sektor sind häufig trainiert, risikovermeidend zu agieren. Wo der Projek terfolg lokale Entscheidungshoheit erfordert (z.B. zur schnellen Problemlösung in der ersten Phase einer
Produktivsetzung), muss diese durch das Veränderungsmanagement explizit eingeräumt und an konkreten
Beispielen bzw. mit Rollenspielen verdeutlicht werden.
Entscheidungshoheit einräumen und stärken
Talentförderung und Entwicklung notwendiger Fähigkeiten
Alle vom Projekt betroffenen Mitarbeiter der Organisation müssen vorausschauend und gezielt auf neue Auf gaben vorbereitet werden. Die dafür nötigen Fähigkeiten sind durch Schulungen und andere Maßnahmen
aufzubauen. Dies erhöht die Bereitschaft des Einzelnen, sich den für ihn neuen Aufgaben und Herausforde rungen zu stellen.Schulungsinhalte und -pfade müssen zielgruppenspezifisch sein und die Formate abwechslungsreich – neben Frontalunterricht sollten sie auch aus E-Learnings und Training on the Job bestehen. Erfolgskontrollen (im öffentlichen Sektor zumeist auf freiwilliger Basis) und Nachschulungen werden gezielt
genutzt, um bei möglichst 100% der Anwender ein hinreichendes Qualifikationsniveau zu erreichen.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
100
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Abbildung 48: Zielgruppenrelevanz der Veränderungsmanagementdisziplinen
Nicht alle Disziplinen des Veränderungsmanagements betreffen alle Ebenen einer Organisation gleicherma ßen. Während Verständnis und Verpflichtung über alle Organisationsebenen hinweg eine wichtige Rolle spielen (bei den unmittelbar und mittelbar Betroffenen, bei Anwendern und Management), sind sowohl der Auf bau von Fähigkeiten als auch die Anpassung von Strukturen und Prozessen relevant, insbesondere für die unmittelbar Betroffenen, das heißt die operativen Mitarbeiter des Projekts sowie die IT-Mitarbeiter und die
künftigen Nutzer. Unternehmenskultur und Vorbildfunktion dagegen sind vor allem wichtig für die mittelbar
Betroffenen, insbesondere die Behördenleitung.
Abbildung 49: Das Veränderungsmanagement greift je nach Zielgruppe zu unterschiedlichen Projektphase
Jedes dieser Ziele erfordert Maßnahmen des Veränderungsmanagements, die auf die jeweilige Mitarbeiterzielgruppe in der Organisation abgestimmt und zum richtigen Zeitpunkt, das heißt frühzeitig, durchgeführt
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.4 Veränderungsmanagement
101
werden. Das bedeutet, dass Maßnahmen für betroffene Mitarbeiter teilweise bereits zwei oder sogar mehr
Projektphasen früher gestartet werden müssen, bevor das eigentliche Projekt und seine Auswirkungen den
Mitarbeiter erreichen. Diese Abhängigkeit ist in Abbildung 49 dargestellt. Man erkennt, dass generell Verständnis und Verpflichtung, beispielsweise durch regelmäßige Kommunikation in Form von Informationsterminen, Workshops und Newslettern, zu einem sehr frühen Zeitpunkt gestartet werden müssen, um die betroffenen Mitarbeiter so weit wie möglich einzubinden.
6.4.2 Rollen: Wer macht was im Veränderungsmanagement?
Das Thema Veränderungsmanagement besitzt viele Schnittstellen zu anderen Managementdisziplinen und ist
daher übergreifend zu betrachten. Folgende Rollen sind für das Veränderungsmanagement relevant:
(Gesamt)Projektleiter
Ist gesamtverantwortlich für das Veränderungsmanagement
● Stellt sicher, dass alle relevanten Beteiligten in das Veränderungsmanagement
einbezogen werden
● Trägt durch eigene Kommunikation entscheidend zur Wahrnehmung des Projekts bei
Veränderungsmanager
Trägt die operative Verantwortung für das Veränderungsmanagement
● Behält den Überblick über alle Maßnahmen des Veränderungsmanagements und
koordiniert diese
● Definiert Zielgruppen
● Erstellt Maßnahmenpläne
● Stellt die Durchführung der Maßnahmen sicher und überwacht diese
● Überwacht die Effektivität der Maßnahmen
Kommunikationsmanager
Sorgt für eine frühzeitige und umfassende Kommunikation, auch im Rahmen des
Veränderungsmanagements
● Überwacht die Erstellung der Kommunikationsunterlagen und sorgt für die Umsetzung
von Kommunikationsmaßnahmen
Personalmanager
Stimmt notwendige und sinnvolle Weiterbildungsmaßnahmen mit den Betroffenen ab
● Erstellt und überwacht die Fortbildungsmaßnahmen und hält deren Erfolg nach
● Gegebenenfalls auch außerhalb der Projektorganisation (z.B. Leiter des
Personalreferats eines Ministeriums)
Administratoren
Unterstützen operativ Organisation und Durchführung von Kommunikations-, Fortbildungsund Motivationsmaßnahmen
● In der Regel Mitarbeiter des PMO
● Organisieren Veranstaltungen und verwalten Zielgruppen, Mailinglisten und Ähnliches
Teilprojektleiter und
Projektmitarbeiter
Sind als „Botschafter“ in das Veränderungsmanagement eingebunden
Multiplikatoren
Sind als „Botschafter“ in das Veränderungsmanagement eingebunden
● In der Organisation verteilt
● Werden als Meinungsmacher bevorzugt angesprochen
Leitung
Verantwortung für Motivation, Befürwortung, Schaffung von notwendigen
Rahmenbedingungen usw. können bzw. müssen auch von diesem Personenkreis
wahrgenommen werden. Hierfür werden abhängig vom Großprojekt eingebunden:
P und VP sowie Fachaufsicht(en), Stab/Stäbe und CIO(‚s) sowie ggf. auch Minister,
Staatssekretär
Tabelle 11: Rollen und Verantwortlichkeiten im Rahmen des Veränderungsmanagements
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
102
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Einige dieser Rollen können in Personalunion von denselben Mitarbeitern wahrgenommen werden – z.B. die
Rolle des Kommunikations- und Veränderungsmanagers. Die einzelnen Stakeholder, die Empfänger dieser
Maßnahmen sind, werden hier nicht aufgeführt. Auf sie wird im Weiteren detailliert eingegangen.
6.4.3 Ergebnisse: Welche Dokumente sollen erstellt werden?
Einige der Ergebnisdokumente, die für das Veränderungsmanagement wichtig sind, werden bereits im Rahmen anderer Managementdisziplinen angesprochen und hier nur der Vollständigkeit halber aufgeführt.
Zielgruppenspezifische Kommunikations- und Maßnahmenpläne
Um die Vorbildfunktion von Führungskräften gewährleisten zu können, bedarf es:
●
Einer Identifikation der wesentlichen Führungskräfte
●
Einer speziell auf diese Führungskräfte zugeschnittenen Kommunikation (z.B. häufigere Informationen, Workshops oder Präsentationen)
●
Eines auf die Führungskräfte zugeschnittenen Maßnahmenplans zur Förderung der Vorbildfunktion.
Dies bedeutet die Schaffung von Bewusstsein der Vorbildfunktion innerhalb der Zielgruppe und den
Ausbau der Fähigkeiten, diese Eigenschaft zu nutzen.
Um das Verständnis sicherzustellen und ein Bekenntnis der Organisation zum Projekt einzuholen, bedarf es:
●
Eines auf die jeweilige Zielgruppe zugeschnittenen Kommunikationsplans und
●
Information durch Kommunikation auf unterschiedlich Wegen (z.B. Gespräche, Medien, Aushänge,
Newsletter, Präsentationen, Artikel in Mitarbeiterzeitschriften)
Analyse von Strukturen und Prozessen
Die Ergebnisse in dieser Disziplin sind:
●
Eine Analyse der bestehenden Strukturen und Prozesse (keine detaillierte Organisationsuntersuchung)
hinsichtlich notwendiger Änderungen
●
Eine Zukunftsplanung für die im Projekt beschäftigten Mitarbeiter.
Schulungsplan zur Entwicklung notwendiger Fähigkeiten
Die Entwicklung notwendiger Fähigkeiten erfordert
●
Eine mit allen Beteiligten abgestimmter und zielgruppengerecht gestalteter Schulungsplan zur frühzeitigen Entwicklung der Fähigkeiten innerhalb der Organisation.
6.4.4 Prozesse: Wie geht das Veränderungsmanagement vor?
Die Prozesse des Veränderungsmanagements sind in Abbildung 50 zusammengefasst:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.4 Veränderungsmanagement
103
Abbildung 50: Prozesse des Veränderungsmanagements
Initialer Prozess: Aufbau des Veränderungsmanagements
Der Aufbau des Veränderungsmanagements erfolgt in drei Schritten:
Festlegung von Verantwortlichkeiten und Rollen
Zunächst sind die im vorherigen Kapitel definierten Rollen zu besetzen und die Verantwortlichkeiten festzulegen.
Nachhaltiges Verständnis der Projektziele entwickeln
Für alle Mitarbeiter, die in Schritt 1 als im Veränderungsmanagement Beteiligte identifiziert wurden, müssen
die Ziele des Projekts jederzeit wiederholbar und reproduzierbar sein – somit können die Ziele leitend für die
weitere Ausgestaltung des Veränderungsmanagements sein. Dies ist besonders wichtig für notwendige Änderungen an Verhaltensweisen – diese müssen genau verstanden sein. Methodisch bieten sich hierfür Workshops an, in denen Mitarbeiter an Beispielen durchdeklinieren, wie die Projektziele in beobachtbaren Verhaltensänderungen resultieren sollten.
Festlegung Prozesse und Periodizität
Im Folgenden sind die Teilprozesse zu konkretisieren und an das jeweilige Projekt und die Organisation an zupassen. Besonders zu beachten ist dabei:
●
Eine genaue Analyse der Organisation und der damit verbundenen Definition der Zielgruppen ist zwingende Voraussetzung.
●
Jeder Teilprozess muss zielgruppengerecht ausgestaltet werden und ist als solcher vielschichtig.
●
Vor Beginn jedes Prozesses muss sichergestellt werden, dass alle Betroffenen auf ihrem derzeitigen
Stand abgeholt werden.
●
Die Teilprozesse müssen eng verzahnt durchgeführt werden.
●
Veränderungsmanagement ist keine Einbahnstraße. Es muss eine ständige Rückkopplung mit der Organisation geben, um mögliche Herausforderungen frühzeitig erkennen zu können.
Laufende Prozesse: Durchführung des Veränderungsmanagements
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
104
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Ein erprobter methodischer Ansatz für die Durchführung ist die Gliederung des Veränderungsmanagements
in drei bis vier Phasen (nach Kurt Lewin 1890 bis 1947):
Auftauphase (unfreezing)
Ausgangspunkt der ersten Phase ist die Einsicht, dass die Erwartungen nicht mehr der Realität entsprechen.
Die Notwendigkeit einer Veränderung tritt langsam als Möglichkeit ins Bewusstsein und altes Verhalten wird
in Frage gestellt. Addiert man nun die gewisse und nötige Flexibilität, kann die Bereitschaft für Veränderun gen entstehen. Das generelle Ziel dieser Phase besteht darin, die nach Veränderung strebenden Kräfte zu stärken und zu unterstützen und so ein Veränderungsbewusstsein zu induzieren. Unfreezing steht dabei bildlich
für das Auftauen des bestehenden (eingefrorenen) Gleichgewichtes oder des zuvor erreichten Zustands, der
auch wiederum aus einem vorangegangenen Veränderungsprozess hervorgerufen worden sein kann.
Bewegungsphase (moving)
In der zweiten Phase, der Moving- oder Veränderungsphase, werden Lösungen generiert, neue Verhaltensweisen ausprobiert und das Problem wird in Teilprojekten gelöst. Der Status quo wird verlassen und es wird
eine verändernde Bewegung zu einem neuen Gleichgewicht vollzogen.
Einfrierphase (refreezing)
Ziel der dritten Phase, dem Wieder-Einfrieren, ist die Implementierung der gefundenen Problemlösungen und
damit der zumindest vorläufige Abschluss des Veränderungsprozesses. Nach dem Episodenschema von Le win bedürfen durchgeführte Veränderungen der Stabilisierung und müssen zur dauerhaften Integration in das
Gesamtsystem wieder eingefroren werden. Der neue Gleichgewichtszustand soll so vor der Macht der Ge wohnheit geschützt und stabilisiert werden. Fazit: Aus „neu“ mach „alt“ im positiven Sinne des Bekannten,
Vertrauten und Funktionierenden.
Nach durchlaufen des Lewinschen Phasenmodells sollte eine Ruhepause „Wait“ erfolgen; umwälzende Änderungen werden von Betroffenen als Belastung wahrgenommen und sollten deshalb mit zeitlichem Abstand
voneinander erfolgen.
Diese Durchführungsanleitung sollte jeweils das Vorgehen in den vier nachfolgend erläuterten Disziplinen
strukturieren.
Vorbildfunktion stärken
Erfolg von Veränderungen hängt stark mit dem Durchdringungsgrad und der „Unausweichlichkeit“ der Ver änderung zusammen – hierfür ist es wichtig, dass es zwischen Arbeits- und Leitungsebene eine gleichmäßige
Lastenverteilung gibt. Um dies zu verdeutlichen, muss das Veränderungsmanagement die Vorbildfunktion
der Führungsebene stärken. Dies geschieht, indem den Führungskräften diese Rolle und die damit verbunde ne Verantwortung für das Projekt bewusst gemacht werden. Durch gezielte Maßnahmen ermöglicht man ihnen eine „Führung durch Beispiel“.
Identifikation wesentlicher Führungskräfte als Multiplikatoren, Definition der Vorbildfunktion
Als erster Schritt zur Stärkung von Vorbildrollen müssen die Mitarbeiter identifiziert werden, die diese im
Projektkontext ausüben. Gleichzeitig muss das Veränderungsmanagement das anzustrebende Verhalten dieser
Führungskräfte definieren (z.B. eine positive Kommunikation bezüglich des Projekts gegenüber anderen
Mitarbeitern). In der Regel handelt es sich dabei um die Führungskräfte der Organisation und in einigen Fällen um weitere einflussreiche Mitarbeiter (z.B. in der Personalvertretung). Diese zusätzlichen Führungskräfte
als Multiplikatoren können direkt angesprochen werden und durch die Schaffung einer informellen Rolle als
„Projektkontaktmann“ gezielt genutzt werden, um z.B. durch ihre Nähe zu den mittel- und unmittelbar betroffenen Mitarbeitern frühzeitig Sorgen zu erkennen und diese durch ihr Wissen um Inhalte des Projekts
auch zu adressieren. Werden solche Projektkontaktleute über die gesamte Organisation verteilt, können sie
durch ihre Vorbildfunktion das Verhalten der übrigen Mitarbeiter positiv beeinflussen.
Motivation der Führungskräfte und Multiplikatoren sicherstellen
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.4 Veränderungsmanagement
105
Die identifizierten Vorbilder und die Gruppe der Projektkontaktleute müssen für das Projekt gewonnen werden. Dazu bietet sich zum einen eine auf sie zugeschnittene Kommunikation an, z.B. durch regelmäßige In formationen oder durch Einladung zu verschiedenen Veranstaltungen (Workshops, Präsentationen). Den Projektsponsoren, die zumeist Linienvorgesetzte der Vorbilder sind, kommt hierbei besondere Bedeutung zu –
sie sind die geeigneten Kommunikationsträger.
Maßnahmen zur Bewusstseinsstärkung der Vorbildfunktion planen und durchführen
Die in den vorhergehenden Schritten identifizierten Personen können und sollen durch zusätzliche Maßnahmen unterstützt werden, ihre Vorbildfunktion im täglichen Geschäft vorzuleben. Dazu eignen sich insbesondere Workshops, in denen Führungskräften, aber in kleinerem Rahmen auch Projektkontaktleuten, gezeigt
wird, wie sie ihre Position nutzen können, um durch ihr Verhalten ihren Mitarbeitern Vorbild zu sein und dadurch deren Verhalten zu beeinflussen. Darüber hinaus bietet sich für Führungskräfte mit besonders zentraler
Rolle gegebenenfalls ein Coaching an, um sie bei dieser Aufgabe zu unterstützen.
Maßnahmen zur Stärkung der Vorbildfunktion sollten sich an den Nutzentreibern und Designprinzipien des
Projekts orientieren. Diese sollten die Führungskräfte und Multiplikatoren auf ihr eigenes Aufgabengebiet
anwenden und die Konsequenzen öffentlich beherzigen. Beispiele:
●
Nutzentreiber „Self-Service, wo immer möglich“: In diesem Fall ist es zwingend notwendig, dass auch
Führungskräfte die neuen IT-Angebote nutzen und ihre Beherrschung der neuen Arbeitsmittel öffentlich
demonstrieren.
●
Nutzentreiber „Automatisierung von Aufgaben“, z.B. Berichterstellung: Führungskräfte sind zumeist
wichtige Nutzer der neuen Berichte. Vorbildfunktion besteht darin, sich auf die neuen Berichte einzulassen und keine manuell erstellten Sonderberichte (mehr) zu verlangen.
●
Nutzentreiber „Serviceverbesserung durch neue Angebote oder bessere Informationen“: Hier zeigt sich
die Vorbildfunktion am ehesten, wenn sich Führungskräfte selbst im Dienst am Kunden beweisen.
Für eine authentische Vorbildfunktion ist eine „persönliche Erfolgsstory“ der Führungskraft sehr effektiv.
Diese ist für jede Führungskraft individuell und enthält als zentralen Punkt die Aussage, warum sie überzeugt
ist, dass das Projekt ein großer Erfolg sein wird, und welchen Nutzen sie persönlich daraus ziehen wird. Diese Erfolgsstory kann dann entweder öffentlich zugänglich gemacht werden (z.B. im Intranet) oder als „per sönliche Anekdote“ der Führungskraft in Gesprächen dienen.
Diese Maßnahmen können in Workshops erarbeitet und in Trainings eingeübt werden. Es empfiehlt sich darüber hinaus, die Führungskräfte anzuhalten, immer wieder auf das identifizierte Nutzen- und Designprinzip
zu verweisen – Konsistenz und Dauerhaftigkeit erhöht den Erfolg der Maßnahme. Eine Erfolgskontrolle
durch Interviews rundet die Disziplin ab – wird die Vorbildfunktion in der Organisation wahrgenommen und
ist sie glaubwürdig?
Verständnis und Verpflichtung schaffen
Das wesentliche Werkzeug zur Schaffung von Verständnis und Verpflichtung ist das in Kapitel Kommunikationsmanagement detaillierte Kommunikationsmanagement. Im Rahmen des Veränderungsmanagements verschiebt sich der Fokus weiter aus dem Projekt heraus in Richtung der Organisation. Die dort eingeführten
Tools (Zielgruppen- und Stakeholderübersicht und die zugehörigen Kommunikationspläne) sind jedoch auch
an dieser Stelle anwendbar.
Zielgruppen identifizieren/bestehende überprüfen
Im Veränderungsmanagement (im Vergleich zum Kommunikationsmanagement) sollten die Zielgruppen im
Regelfall granularer geschnitten werden, da die Kommunikationsinhalte genau da ansetzen müssen, wo die
Mitarbeiter heute stehen. Geschnitten wird damit in der Regel entlang der Hierarchieebenen sowie entlang
der Funktionen, da der Veränderungsmanagementbedarf sich vergrößert mit einer absteigenden Hierarchie
und damit einem größeren Abstand zu den Entscheidungen. Gleichzeitig wird der Inhalt der Kommunikation
stark von der Unternehmensfunktion bestimmt, in der ein Mitarbeiter tätig ist. Es gilt, mittelbar und unmittel-
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
106
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
bar betroffene Mitarbeiter zu unterscheiden, da diese unterschiedlichen Veränderungsmanagementbedarfe haben und somit unterschiedlich adressiert werden müssen.
Insgesamt sollten so wenige Zielgruppen wie möglich unterschieden werden, ohne dabei notwendige Ab grenzungen zu unterlassen. Der Umfang und insbesondere auch der Inhalt der benötigten Veränderungsma nagementmaßnahmen sind die dabei zu Grunde liegenden Abgrenzungskriterien. Beides sollte innerhalb einer Zielgruppe homogen sein.
Mit der Zielgruppendefinition ist damit auch der wesentliche Inhalt der Kommunikationsmaßnahmen bestimmt: Wo stehen die Zielgruppen heute? Was ist das für die Zukunft angestrebte Verhalten? Wie kann der
Weg dahin erläutert werden?
→ Ein wichtiges Element der Analyse einer Zielgruppe ist die Berücksichtigung vergangener Verände rungsinitiativen. Auch im öffentlichen Sektor sind die Mitarbeiter über die Jahre einer Reihe von Initiativen
ausgesetzt oder „unterzogen“ worden, viele Instrumente des Veränderungsmanagements haben sich abgenutzt, viele hehre Ziele haben angesichts eines kläglichen Umsetzungserfolgs ihre Glaubwürdigkeit verloren. Solche „Erbschaften“ haben entscheidenden Einfluss auf die Gestaltung des Veränderungsprogramms.
Im Zweifel sollte das Großprojekt bescheiden in seinen Zielen auftreten und eher die konkreten Änderungen der Arbeitsweisen betonen als strategische Absichten.
„Verbrannte Erde“ pfleglich kultivieren
Kommunikationsplan je Zielgruppe aufstellen
Es wird ein Kommunikationsplan aufgestellt, in dem jede der identifizierten Zielgruppen berücksichtigt
wird. Wie bereits im Kapitel Kommunikationsmanagement (siehe Kapitel 6.3) gezeigt, sollte dieser mehrere
Medien umfassen (beispielsweise Intranet, Newsletter, Präsentationen) und regelmäßig einem Review unter zogen werden, um ihn an aktuelle Veränderungen anzupassen.
Kommunikationsmaßnahmen planen und durchführen
Auf Basis der Pläne müssen Kommunikationsmaßnahmen definiert und umgesetzt werden (z.B. Veranstal tungen durchführen, Schriftstücke erstellen).
Das Ziel ist hierbei, Verständnis und Verpflichtung zu schaffen – im Gegensatz zum Kommunikationsmanagement, das im Regelfall nur Verständnis erzeugen will. Verpflichtung entsteht durch das klare Beschreiben
der gewünschten Verhaltensänderung sowie durch die Begründung der Notwendigkeit, am besten hergeleitet
aus der Geschäftspolitik. Schließlich sollte die Kommunikation den Erfolgsbeitrag des Einzelnen herausstellen und mit einem Appell enden, den Erfolg des Projekts persönlich zu unterstützen.
Erfolgskontrolle
Im Veränderungsmanagement noch mehr als im Kommunikationsmanagement ist Erfolgskontrolle zwingend
– das Ziel des Veränderungsmanagement ist eine Verhaltensänderung, die schwieriger zu erzeugen ist als bei spielsweise ein Wissenszuwachs. Dafür ist sie beobachtbar. Wiederum bieten sich Interviews an den Enden
der Kommunikationslinien an, in denen das Veränderungsmanagement Stimmungen und Meinungen aus der
Organisation aufnehmen und daraufhin untersuchen kann, ob alle Zielgruppen ein richtiges Verständnis des
Projekts besitzen und an welcher Stelle Sorgen und Unverständnis der Mitarbeiter aufgegriffen werden müs sen.
Strukturen und Prozesse überprüfen
IT-Großprojekte müssen über den Tellerrand der Lösungsbereitstellung hinausschauen und die Konsequenzen analysieren, die das Projekt für die betroffene Organisation als ganzes hat – beispielsweise eine neue
Aufgabenzuordnung. Solche Konsequenzen müssen organisatorisch abgestützt werden, das heißt, es müssen
beispielsweise neue Kompetenzen und Mandate offiziell eingeräumt und eventuell muss auch die Entlohnung angepasst werden.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.4 Veränderungsmanagement
107
Diese Disziplin des Veränderungsmanagements beschäftigt sich mit der Struktur. Ein weiterer Aspekt ist die
Zukunftsplanung für die unmittelbaren Projektmitarbeiter. Ein Nebenaspekt ist die periodische Überprüfung
der Projektstrukturen und -prozesse, diese wird bereits im Kapitel Festlegung/Überprüfung der Projektorganisation ausgiebig beschrieben.
Organisatorische Anpassungen sind in der Regel komplex und nicht einfach durchzuführen – sie erzeugen
schnell Widerstände bei den Betroffenen (insbesondere den vermeintlichen Verlierern), müssen zumeist im
Einklang mit Interessenvertretungen durchgeführt werden und können z.B. durch das Höherstufen von Mitarbeitern bei Einräumung zusätzlicher Kompetenzen schnell erhebliche Personalmehrkosten verursachen,
wenn nicht im gleichen Zuge anderweitig Kompensation erreicht wird. Sie müssen daher frühzeitig vorberei tet werden, zunächst durch Identifikation der notwendigen Änderungen, dann durch Analyse der Implikatio nen für jede der identifizierten Zielgruppen.
Die Anpassungen unterteilen wir in zwei Kategorien: Anpassungen von Prozessen (Arbeitsabläufe aus Sicht
der Betroffenen – was ändert sich für jeden persönlich und muss erklärt werden?) und von Strukturen (hier bei sind Aufgabenzuordnung und Berichtslinien gemeint, aber auch „weichere“ Strukturen wie Führungs mandate, Rollendefinitionen, Entlohnungsmodelle und Leistungsanreize).
Durch das Projekt beeinflusste Prozesse prüfen und anpassen
Großprojekte haben zumeist Änderungen an den Geschäftsprozessen zur Folge. Häufig werden diese explizit
zum Bestandteil des Großprojekts gemacht: Projektziele (z.B. Effizienzsteigerungen) wurden in Prozessvorgaben übersetzt (z.B. Senkung Bearbeitungszeit eines Geschäftsvorfalls durch Automatisieren der Ablage)
und entsprechend mit speziellen Aktivitäten hinreichend adressiert.
Doch auch in Projekten, in denen die Projektleitung Prozessveränderungen eher für ein Nebenprodukt hält,
muss dies sauber gemanagt werden. Theoretische Grundlage hierfür ist das Geschäftsprozessmanagement sowie das Qualitätsmanagement. Detailfragen hierzu beantwortet das Organisationshandbuch (www.orghandbuch.de).
Ein erster Schritt ist die Identifikation der notwendigen Veränderungen. Hierfür bietet es sich an, zunächst
die Nutzentreiber und Designprinzipien für das Projekt abzuleiten und deren Konsequenzen für Prozesse und
Organisation durchzuspielen. Dies können beispielsweise sein: Weniger Medienbrüche, ein direkter Zugriff
auf alle in einem Prozessschritt benötigten Informationen oder ein möglichst weitreichender Self-Service.
Werden diese Prinzipien auf die Prozesse angewandt, ergeben sich Veränderungen an den Stellen, an denen
vor Beginn des Projekts Medienbrüche bestehen, Mitarbeiter Informationen „zusammensammeln“ müssen
oder es eine zentrale „Informationsstelle“ gibt.
Eine Herausforderung dabei ist, dass viele Konsequenzen eines Projekts erst mit den Ergebnissen deutlich
werden; gleichzeitig setzt erfolgreiches Veränderungsmanagement frühzeitig an. Eine Lösung liegt in der
Verwendung von Prototypen auch für Tests vor Ort.
Um aus den Konsequenzen die Maßnahmen des Veränderungsmanagements ableiten zu können, ordnet der
zweite Schritt die notwendigen Veränderungen in drei Grade (es ist zu beachten, dass innerhalb eines Projekts für unterschiedliche Mitarbeitergruppen alle drei Grade auftreten können):
●
Eine reine Änderung von Arbeitsmitteln (neue Tools). Werden alte IT-Anwendungen lediglich durch
neue ersetzt, ohne dass sich die zu Grunde liegenden Prozesse ändern, bedeutet dies nur eine relativ ge ringe Veränderung des Arbeitsalltags für die unmittelbar Betroffenen. Die zu ergreifenden Veränderungsmaßnahmen können sich dann auf eine Vermittlung/ Schulung des neuen Tools konzentrieren, sofern die
Vorteilhaftigkeit der Umstellung z.B. durch modernere Oberflächen der neuen Anwendungen evident ist.
Auch ist die Beteiligung von Personalvertretungen bei reinen Änderungen von Arbeitsmitteln häufig einfacher.
●
Eine Prozessveränderung. Ein mittlerer Veränderungsgrad wird erreicht, wenn sich Prozesse innerhalb
der bestehenden Verantwortlichkeiten verändern, das heißt, wenn z.B. manuelle Schritte automatisiert
werden, wenn die Prozessqualität durch bessere Informationsversorgung gesteigert werden soll oder
wenn Aufgaben anders zwischen Systemen aufgeteilt werden. In der Regel geht dies einher mit einer ÄnS-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
108
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
derung der Arbeitsmittel, erfordert aber zusätzlich eine Änderung der gewohnten Abläufe in der Organisation. Schulungsmaßnahmen zu den Arbeitsmitteln sind dann nicht hinreichend, sondern die veränderten Prozesse müssen aus Anwendersicht definiert und erklärt werden.
●
Eine Prozessveränderung in Kombination mit einer Änderung der Verantwortlichkeiten. Ein hoher
Grad an Veränderung besteht dann, wenn sich Aufgabenzuschnitt und Aufgabeninhalte von einzelnen
Mitarbeitern und Organisationseinheiten ändern. Dies ist z.B. der Fall bei IT-Konsolidierungsprojekten
oder bei der Zentralisierung von Aufgaben in Dienstleistungszentren (wobei dezentrale Aufgaben verlagert werden), oder auch auf niedrigerer Ebene, wenn Prozesse auf neue Weise initiiert werden („den
Kunden kontaktieren“ statt „auf den Kunden warten“). Prozessänderungen dieser Kategorie bedeuten zumeist auch Änderungen an den Organisationsstrukturen und werden entsprechend nachfolgend vertieft.
Sind die Veränderungen den Kategorien zugeordnet, kann das Veränderungsmanagement je Kategorie und
Zielgruppe ein geeignetes Maßnahmenpaket definieren.
Organisationsstruktur prüfen und notwendige Änderungen durchführen
Nachdem die Veränderungsanalyse des vorigen Schritts die prinzipielle Notwendigkeit struktureller Veränderungen gezeigt hat, sind diese im Folgenden zu detaillieren.
Hierunter fällt zum einen die Anwendung der Nutzentreiber und Designprinzipien auf die Aufgaben/Verantwortlichkeiten von Organisationseinheiten und Mitarbeitern sowie auf die Berichtslinien.
Gleichzeitig zählt hierzu die Gestaltung „weicherer“ struktureller Faktoren:
●
Führungsmandate. Ändert sich durch das Projekt das Verständnis von Führung, z.B. eigenverantwortliches Gestalten statt Ausführen von Weisungen? Dies ist klar zu artikulieren und durch eigene Führungs kräfte-Entwicklungsprogramme abzustützen.
●
Rollendefinitionen. Ändert sich eventuell der Rollenzuschnitt einzelner Funktionen fundamental? Dies
ist ebenso strukturell zu verankern, durch Neugestaltung von Tätigkeitsprofilen und Neubewertung von
Positionen.
→ Im öffentlichen Sektor ist eine Abwertung von Positionen, die aus dem Wegfall von Aufgaben und
Kompetenzen herrührt, häufig mit größeren Widerständen verbunden, gleichzeitig ist diese Kostensenkung je Position häufig eine Grundvoraussetzung für die wirtschaftliche Vorteilhaftigkeit des Projekts.
Es empfiehlt sich, neue Stellenprofile zu definieren, anstatt bestehende abzuwerten.
Alternative Karriereperspektiven schaffen
●
Entlohnungsmodelle und Leistungsanreize. Eine nachhaltige Verankerung von Veränderungen erfordert kontinuierliche Bestärkung – dies ist am einfachsten durch die Definition/Anpassung des Leistungsmesssystems mit einer entsprechenden Verankerung in den Entlohnungssystemen der Mitarbeiter zu erreichen. Dafür eignen sich insbesondere Zielvereinbarungen.
Perspektiven für Projektmitarbeiter entwickeln
Projektmitarbeiter brauchen eine realistische Zukunftsperspektive, die sie auch selbst mittragen, um ein Pro jekt erfolgreich zum Abschluss zu bringen. Dafür ist es nötig, Entwicklungsgespräche mit den einzelnen Mitarbeitern zu führen und gegebenenfalls mit ihnen zusammen aktiv nach Möglichkeiten für eine attraktive berufliche Option nach Abschluss des Projekts zu suchen.
Typische Zukunftsperspektiven können sein:
●
Betreuung der neuen Lösung im Linienbetrieb
●
Übernahme der IT-Architekturverantwortung rund um die entstandene Lösung
●
Projektleitung für die nächste Projekte
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.4 Veränderungsmanagement
●
109
Erhalt des Projektleitungsteams als „Eingreiftruppe“ für ein weiteres Projekt.
Zukunftsperspektiven sind auch bedeutsam für ins Projekt eingebundene externe Mitarbeiter, die nach Projektende möglicherweise um ihre Jobs fürchten müssen. Auch mit ihnen sollten Gespräche geführt und ihre
Entwicklung sollte im Auge behalten werden.
Talentförderung und Fähigkeiten aufbauen
Ermittlung vorhandener und in Zukunft benötigter Fähigkeiten je Zielgruppe
Jede Mitarbeitergruppe innerhalb der Organisation (und auch im Projekt) benötigt unterschiedliche Fähigkeiten, um die ihr zugeordneten Rollen ausfüllen zu können. Ändern sich Aufgabeninhalt oder -schnitt durch
das Projekt, erfordert dies pro Mitarbeitergruppe neue Fähigkeiten; Schulungen und andere Maßnahmen
müssen dann die Lücken schließen. Da dieser Aufbau von Fähigkeiten auch schon im Projektteam nötig ist,
greift diese Disziplin schon sehr frühzeitig. In jeder Projektphase sind benötigte Fähigkeiten zu analysieren
und es ist festzustellen, welche schon vorhanden sind und welche aufgebaut werden müssen.
Mitarbeiter mit ähnlichem Entwicklungsbedarf sollten zu Zielgruppen zusammengeführt werden. Diese sind
im Regelfall entlang von Hierarchieebenen und funktionalen Grenzen geschnitten.
Entwicklungsplan je Zielgruppe aufstellen
Für jede der auf diese Weise ermittelten Zielgruppen muss ein Entwicklungsplan aufgestellt werden. Dieser
muss neben den aufzubauenden Fähigkeiten auch den optimalen Zeitpunkt und den Weg der Qualifizierung
(z.B. Training on the Job oder externe Schulung) beinhalten.
Für Qualifizierungsmaßnahmen gibt es einen optimalen Zeitraum – Trainings sollten im Regelfall in den acht
Wochen vor dem Zeitpunkt durchgeführt werden, zu dem die trainierte Fähigkeit eingesetzt werden muss.
Mit diesem achtwöchigen Zeitfenster bleibt einerseits genügend Zeit, auch größere Mitarbeitergruppen durch
ihre Schulungspfade zu schleusen, andererseits verlernen die geschulten Mitarbeiter ihre neuen Fähigkeiten
nicht gleich wieder.
Generell sollte die Qualifizierung nicht ausschließlich die technische Qualifikation im Auge haben, sondern
auch die für die Zielgruppen notwendigen so genannten Soft Skills vermitteln, z.B. Kommunikationsfähigkeiten.
Zur Hilfe lässt sich eine Schulungsbedarfsmatrix für jede Zielgruppe erstellen. Ein Beispiel ist in Abbildung
51 gezeigt. Darin werden die Kenntnisse der Mitarbeiter einer Zielgruppe in den Bereichen Fachliche Kennt nisse, Technische Kenntnisse und Soft Skills eingeschätzt und ein „Zielwert“ wird ermittelt. Für jede der Kategorien können in der Folge die notwendigen Schulungsinhalte und -umfänge ermittelt werden.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
110
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Abbildung 51: Beispiel einer Schulungsbedarfsmatrix
Es muss dabei beachtet werden, dass es eine Schnittstelle zum Personalmanagement der Organisation gibt. In
der Regel werden dort generelle Schulungs- und Entwicklungspläne erarbeitet und die Qualifikation der Mitarbeiter wird gesamthaft verfolgt. Dies ist bei der Ausgestaltung der projektspezifischen Schulungsbedarfe zu
berücksichtigen, um eine abgestimmte Vorgehensweise zu erreichen und die entsprechende Stelle gegebe nenfalls einzubinden, um optimale Fortbildungsergebnisse zu erzielen.
Schulungsmaßnahmen und Training on the Job planen und durchführen
Aufbauend auf den so erstellten Fortbildungsplänen, müssen die einzelnen Maßnahmen geplant und durchgeführt werden. Dafür gilt es, das optimale Format auszuwählen.
Ein großer Teil der Qualifikationen findet in der Regel in Workshops und/oder internen Trainings statt. Mit arbeiter können häufig auch durch Trainings on the Job auf die neuen Aufgaben vorbereitet werden. Dabei ist
zu beachten, dass eine ausreichende Anzahl Mitarbeiter zur Verfügung steht, die die neuen Fähigkeiten be reits beherrschen und Kollegen ausbilden können. Das verlangt zudem nach einer sorgfältigen Planung, um
Zeitpläne und Bedürfnisse aufeinander abstimmen zu können. Darüber hinaus kann gerade bei einer großen
Zahl von Gelegenheitsnutzern auf E-Learnings zurückgegriffen werden.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.4 Veränderungsmanagement
111
Abbildung 52: Beispielhafte Schulungsplanung
Einige grundsätzliche Tipps erhöhen die Effektivität von Schulungsmaßnahmen:
●
Je spezifischer, desto besser. Dies betrifft die Abgrenzung von Zielgruppen und die Planung von Schulungspfaden (passgenaues Analysieren von Entwicklungsbedarfen verhindert über- und unterforderte
Teilnehmer) sowie die Schulungsinhalte (insbesondere sollte besondere Sorgfalt auf die Beispiele ver wendet werden, um diese so relevant wie möglich zu machen). Eine besondere Herausforderung liegt
darin, bereits frühzeitig spezifisch zu werden – häufig sind gerade initiale Schulungen des Projektteams
noch sehr generisch.
●
Je modularer, desto besser. Durch modulare Gliederung des Stoffs können viele Entwicklungspfade mit
demselben Material abgedeckt werden.
●
Mehr ist nicht immer besser. Über das notwendige Maß hinaus ausgedehnte Schulungen sind sehr teuer
(direkte Kosten für Trainer, aber vor allem auch indirekte Kosten durch Wegfall von Arbeitszeit) und
führen zu Widerstand bei Führungskräften (deren Mitarbeiter über Gebühr belegt werden) und gelang weilten Teilnehmern.
●
Häufiger ist häufig gut. Dreifache Wiederholung gilt als Grundprinzip nachhaltigen Lernens, vor allem
wenn sich die Formate abwechseln – ein effektiver Schulungspfad kann z.B. bestehen aus einer frühzeitigen Einführungsveranstaltung, danach einem Klassenraumtraining, gefolgt von einem E-Learning zum
Nacharbeiten.
Erfolgskontrolle und -nachhaltung
Nachhalten und Kontrolle der Qualifikationsmaßnahmen ist ein wichtiger Erfolgsfaktor beim Aufbau von
Fähigkeiten. Durch eine zeitnahe Überprüfung der Erfolge lässt sich feststellen, ob die Maßnahmen den gewünschten Effekt haben oder ob in der Folge Korrekturen im weiteren Vorgehen vorgenommen werden sollten. Dies kann zusätzliche Schulungen oder die Veränderung bestehender beinhalten oder auch eine Justie rung des Zeitplans.
→ Im öffentlichen Sektor erlauben Personalräte im Regelfall keine einzelfallbezogene Erfolgskontrolle.
Hier sollte dann eine Kontrolle auf freiwilliger Basis erfolgen, z.B. im Rahmen der Teilnehmerbefragung
am Ende einer Maßnahme. Verneint ein Anwender die Frage „Sehen Sie sich nach diesem Training in der
Lage, die neuen Systeme und Arbeitsweisen mit Hilfe des Ihnen übermittelten Wissens und der Ihnen zur
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
112
6 Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter
Verfügung stehenden Dokumentation selbstständig einzusetzen?“, sollten ihm unmittelbar danach die Möglichkeit gegeben werden, sich unauffällig für eine Nachschulung anzumelden.
Keine einzelfallbezogene Erfolgskontrolle
Doch nicht nur zur Wiederholung im Bedarfsfall sollten Nachschulungen eingeplant werden. Weitere Gründe
für eine Schulung können sein:
●
Mitarbeiter, die die für sie gedachte Schulung nicht wahrnehmen konnten (z.B. wegen Krankheit)
●
Der aus Fluktuation resultierende Eintritt neuer Mitarbeiter in die betroffene Organisationseinheit
●
Sehr frühzeitige Schulungen, die später einer Auffrischung bedürfen. Das ist vor allem bei großen Projekten oft nicht zu vermeiden: Bei großem Schulungsaufwand kann selbst bei sorgfältigster Planung der
Zeitpunkt manchmal nicht optimal gewählt sein. In diesem Fall muss das zuvor vermittelte Wissen durch
eine kurze Auffrischungsschulung reaktiviert werden.
6.4.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Veränderungsmanagement
erkennen?
Ein gutes Veränderungsmanagement zeichnet sich durch einen reibungslosen Ablauf des Projekts aus. Der
größte Teil beschäftigt sich dabei mit der Wahrnehmung des Projekts in der Organisation und mit den zu mi nimierenden Reibungsverlusten durch eine negative Außen- und Innenwahrnehmung. Eine gezielte Befragung der Beteiligten ist daher sinnvoll, um ein differenziertes Bild vom Zustand des Veränderungsmanagements zu bekommen:
●
Verstehen die Beteiligten die durch das Projekt ausgelösten Veränderungen? Finden sie sie sinnvoll und
stehen sie dahinter? Sind dem einzelnen Mitarbeiter seine zukünftige Rolle in der Organisation und die
damit verbundene Veränderung klar und versteht er deren Sinn?
●
Empfinden die Mitarbeiter die vorhandenen Prozesse und die Organisationsstruktur als hilfreich, um die
Veränderung durchzuführen, oder fühlen sie sich durch diese behindert? Werden notwendige Änderungen zeitnah und mit der gebotenen Vorsicht durchgeführt? Haben alle Projektmitarbeiter eine klare und
realistische Vorstellung davon, wie es für sie nach dem Projekt weitergeht?
●
Werden die Führungskräfte als Vorbilder wahrgenommen, die den Umgang mit den zu erwartenden Veränderungen positiv vorleben? Fühlen sich die Betroffenen von ihren Vorgesetzten unterstützt und ermu tigt, das Projekt voranzutreiben?
●
Fühlen sich die Betroffenen durch angemessene Qualifizierungsmaßnahmen unterstützt? Finden die
Maßnahmen zum richtigen Zeitpunkt statt? Sind die Inhalte angemessen?
6.4.6 Grundlegende und weiterführende Literatur
●
Change Management: Anwendungshilfe zu Veränderungsprozessen in der öffentlichen Verwaltung; Internet: www.bmi.bund.de; Artikelnummer: BMI09345
●
Checkliste zum Change Management (Management des geplanten organisatorischen Wandels); www.olev.de/c/cm-check.pdf
●
Kursbuch Unternehmensführung, S. 487 - 488, Walhalla Fachverlag, Regensburg 2008
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
6.5 Endnoten
113
6.5 Endnoten
EN-601
Rollenbezeichnungen, vor allem für die Führungspositionen Gesamtprojektleiter, Projektmanager und Teilprojektleiter, werden häufig je nach Unternehmen unterschiedlich definiert. Teilweise werden z.B. die Bezeichnungen Projektleiter und -manager mit genau gegensätzlicher Bedeutung verwendet. Die Rollenbezeichnungen in diesem Dokument sind
daher nur ein Vorschlag. Wichtig ist im Projekt nicht die Rollenbezeichnung als solche, sondern dass jeder Beteiligte die damit verbundenen Aufgaben und Verantwortungen kennt.
EN-602
Eine Ausnahme bilden Projekte mit geringer Komplexität in allen Komplexitätsdimensionen. Das gilt beispielsweise für Projekte mit immer wiederkehrenden Standardaufgaben
(wie beim Austausch von Telefonen in einer Behörde mit mehreren 1.000 Mitarbeitern an
verschiedenen Standorten). Auch wenn mehr als 15 Mitarbeiter benötigt werden, können
solche gleichartigen Aufgaben dennoch von einem einzelnen Projektleiter geleitet werden.
Diese Art von Projekten wird im CC GroßPM nicht betrachtet (siehe Kapitel Definition von
Zielprojekten nach Inhalt).
EN-603
Für ausführliche Beschreibungen siehe z.B. V-Modell XT, http://www.v-modell-xt.de
EN-604
Aus „Der Pate 2“, 1974
EN-605
Verstärkung der leistungsabhängigen Vergütung, Prämien, etc.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
114
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Abbildung 53: Disziplinen im Projektmanagement mit Fokus auf dem „Management der Systemunterstüt zung, der Instrumente und Werkzeuge"
7.1 Projektplanung
Die Projektmanagement-Disziplin „Projektplanung“ umfasst die Themen Aufwandschätzung, Aufgaben-,
Ressourcen-, Termin- und Budgetplanung sowie Controlling.
7.1.1 Ziele und Rahmenbedingungen: Was soll mit der Projektplanung erreicht werden?
Ein Erfolgsfaktor von Projekten besteht darin, dass die Projektleitung bei ihren Entscheidungen auf verlässlichen Schätzungen und Planungen aufbauen kann sowie ein Mindestmaß an Transparenz hinsichtlich Projektfortschritt, Ressourcenverzehr und notwendiger Restaufwände und -zeiten besitzt. Aufgabe der Planung ist
es, die Projektleitung mit diesen Informationen zu
versorgen. Um diese Aufgabe zu erfüllen, verfolgt die Planung die folgenden operativen Ziele:
●
Koordination aller Projektaufgaben und Ressourcen, die unmittelbar die Kerndimensionen der Planung berühren (Aufwand, Budget, Ressourcen, Termine, Qualität/Inhalt, Nutzen)
●
Sicherstellung der Verlässlichkeit der Informationen, insbesondere zum Ist-Status, durch reproduzierbare Prozesse mit definierten Qualitätsniveaus
●
Sicherstellung der Vorhersagbarkeit in allen Planungsdimensionen, insbesondere hinsichtlich des
Umfangs des benötigten Restaufwands und des noch verbleibenden Zeitrahmens
●
Aufsetzen von Maßnahmen zur Steuerung des Projekts und zur Einhaltung sämtlicher Planungsvorgaben.
Die Planungsziele umfassen im Einzelnen:
Koordination aller Projektaufgaben und Ressourcen
Die Vielzahl von Aufgaben, beteiligten Mitarbeitern und benötigten Ressourcen zur Erreichung eines Projektziels erfordert eine umfassende Koordination. Die Planung gewährleistet diese Koordination über alle
Kerndimensionen hinweg (Aufwand, Budget, Ressourcen, Termine, Qualität/Inhalt, Nutzen). Sie stellt sicher,
dass alle zur Erreichung des Projektziels notwendigen Aufgaben ohne Reibungsverluste erledigt werden.
Gleichzeitig berücksichtigt sie die vorgegebenen Rahmenparameter (z.B. Termin- und Budgetgrenzen) sowie
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.1 Projektplanung
115
weitere beschränkende Faktoren wie z.B. wechselseitige Abhängigkeiten von Aufgaben oder die Verfügbarkeit von Ressourcen.
Sicherstellung der Verlässlichkeit der Informationen
Zu Projektbeginn werden Rahmenparameter festgelegt, die den zur Zielerreichung erforderlichen Aufwand
einschließlich Budget und Ressourcen festlegen, die Laufzeit des Projekts vorgeben und den angestrebten
Nutzen dokumentieren. Diese Rahmenparameter dienen als Basis für die Projektplanung. Während des Projekts ist kontinuierlich zu prüfen, ob die vorgegebenen Werte erreicht bzw. eingehalten werden. Zur effektiven Steuerung benötigt die Projektleitung aktuelle und verlässliche Informationen, die eine genaue Einschätzung des jeweiligen Projektstatus erlauben. Insbesondere benötigt sie zuverlässige Daten zum Projektfortschritt, der besonders schwierig objektiv zu messen ist. Die Planung stellt dazu aktuelle Informationen zum
Ist-Status bereit (z.B. verbrauchtes Budget, benötigter Aufwand) und sichert die Verlässlichkeit, indem sie
für die eingehenden Parameter Standarderhebungsprozesse und Qualitätssicherungsmaßnahmen definiert
(z.B. unabhängige Erhebung auf Basis von zwei Quellen).
Sicherstellung der Vorhersagbarkeit in allen Planungsdimensionen
Neben Informationen zum Ist-Status benötigt die Projektleitung Voraussagen zur zukünftigen Entwicklung,
insbesondere Restaufwandsschätzungen. Diese erlauben Aussagen zu Aufwand, Budget, Ressourcen, Termin,
Qualität und Nutzen, die bis zum geplanten Projektende zu erwarten sind. So können vor allem die Auswirkungen von Änderungen vorausgesagt werden, die sich im Projektverlauf ergeben, wie z.B. Änderungen im
Projektziel bzw. -umfang oder ungeplante Ereignisse, die es zu berücksichtigen gilt.
Aufsetzen von Maßnahmen zur Steuerung des Projekts und zur Einhaltung der Planungsvorgaben
Die bereitgestellten Informationen zum Ist-Status und zur erwarteten Entwicklung ermöglichen einen Abgleich gegen die zu Projektbeginn festgelegten Rahmenparameter. Bei Abweichungen werden steuernde
Maßnahmen aufgesetzt, die das Projekt in den durch die Rahmenparameter festgelegten Korridor zurückführen. Die Planung kann jedoch auch schon im Vorfeld die Einhaltung der Vorgaben wahrscheinlicher machen,
indem sie die Beteiligten (z.B. Teilprojektleiter) über die wichtigsten Aufwands- und Kostentreiber sowie
Planungsziele informiert und ihnen die Verantwortung für diese überträgt.
7.1.2 Rollen: Wer macht was in der Projektplanung?
Die Projektplanung verteilt sich auf die folgenden Rollen und Zuständigkeiten:
Projektleiter
Ist gesamtverantwortlich für die Projektplanung sowie das Konzipieren und Nachhalten
steuernder Maßnahmen
● Delegiert Aufgaben und Verantwortlichkeiten an Rollen in der Projektplanung
● Stellt mit Hilfe der Informationen aus Planung und Controlling sicher, dass steuernde
Maßnahmen konzipiert, durchgeführt und nachgehalten werden
Projektplaner
Macht Vorgaben zu Planungsprozess und -detaillierung auf unterschiedlichen Projektebenen
● Erstellt die Projektplanung und weitere Sichten auf die Planung
● Aktualisiert die Planung nach den aktuellen Schätz- und Controllinginformationen sowie
bei Änderungen des Projektumfangs und bei neu aufgesetzten Maßnahmen
● Stellt sicher, dass die Planung ausgewertet und geprüft wird in Bezug auf die
Projektrahmenbedingungen, insbesondere zur Ermittlung des kritischen Pfads und für
Vorschläge zu steuernden Maßnahmen
Projektcontroller
Macht Vorgaben zum Controllingprozess und zu den von den Beteiligten erwarteten
Zulieferungen
● Erarbeitet Schätz- und Controllingdaten aus dem Gesamtprojekt, führt sie zusammen
und konsolidiert sie
● Wertet Schätz- und Controllingdaten aus, führt insbesondere Soll-Ist-Vergleiche durch,
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
116
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
ermittelt Abweichungen und macht Vorschläge zu steuernden Maßnahmen
Experten und
Teammitglieder
Erstellen Aufwands- und Restaufwandsschätzungen zu Aufgaben des Projekts, über die sie
fundiertes Wissen besitzen bzw. die sie selbst durchführen
● Liefern weitere Controllinginformationen, die für die Ermittlung des Status einzelner
Planungsdimensionen notwendig sind (z.B. Informationen zum Fertigstellungsgrad
einzelner Teilergebnisse)
Tabelle 12: Rollen und Verantwortlichkeiten in der Planung
In kleineren Projekten übernimmt der Projektleiter zugleich auch die Rolle des Planungsverantwortlichen
und Projektcontrollers. Planungsverantwortung und -umsetzung liegen damit komplett in der Hand der Projektleitung.
→ In Großprojekten liegt die Verantwortung für die Projektplanung ebenfalls beim Gesamtprojektleiter.
Die einzelnen Planungsaufgaben müssen jedoch auf Grund der größeren Komplexität an weitere Mitarbeiter delegiert werden. Bei Großprojekten empfiehlt es sich, die Rollen des Planungsverantwortlichen und
des Projektcontrollers auf Gesamtprojektebene einzurichten. Gemeinsam sorgen beide für die konsistente
Zusammenführung und Aufbereitung der Planungs- und Controllinginformationen aus den verschiedenen
Teilprojekten. Administrative Unterstützung wie beispielsweise das regelmäßige Einholen von Daten aus
den Teilprojekten kann im PMO angesiedelt werden. Die Verantwortung für die Planung der Teilbereiche
bzw. -projekte delegiert der Gesamtprojektleiter an die jeweils verantwortlichen Projektmanager und Teil projektleiter.
Einrichtung einer Planungsabteilung
7.1.3 Ergebnisse: Welche Dokumente sollen erstellt werden?
Wesentliche Ergebnisse der Projektplanung sind:
Aufwandsschätzung (inklusive Restaufwandsschätzungen)
Auf Basis des Projektstrukturplans, in dem alle Aktivitäten zur Erreichung des Projektziels enthalten sind,
wird zu Beginn der Aufwand geschätzt und diese Schätzung dokumentiert. Die Aufwandsschätzung dient als
Grundlage für die Erarbeitung der Planung sowie für Soll-Ist-Vergleiche während des Projektverlaufs.
Parallel werden über den gesamten Projektzeitraum regelmäßig Restaufwandsschätzungen durchgeführt, die
aktuelle Erkenntnisse einbeziehen und damit eine genauere Prognose des Gesamtaufwands erlauben.
Projektplan und Planungssichten
Im Allgemeinen setzt sich ein Projektplan zusammen aus
●
Projektstrukturplan (Work Breakdown Structure): vollständige, hierarchische und überlappungsfreie
Gliederung des Projekts in Planungssegmente und Arbeitspake
●
Budget- und Kostenplan: Der Budget- und Kostenplan weist das im Projekt vorhandene Budget sowie
die geplanten Kosten aus. Dazu gehören der in Geldwert umgerechnete Aufwand sowie weitere im Projekt anfallende externe/haushaltswirksame Kosten, beispielsweise für Lizenzen, Hardware oder Reisen,
aber auch interne Kosten wie z.B. Kosten für Fortbildungen. Die initiale Budgetplanung dient als Basis
für Soll-Ist-Vergleiche in Bezug auf die Kosten. Notwendige Änderungen in der Budgetplanung werden
im Projektverlauf dokumentiert.
●
Aufwandsplan: hinsichtlich des Aufwands bewerteter Projektstrukturplan
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.1 Projektplanung
117
●
Ressourcen- und Organisationsplan: enthält alle für das Projekt relevanten Ressourcen mit ihrer terminlichen Verfügbarkeit und ihrer verfügbaren Kapazität, insbesondere die Projektmitarbeiter
●
Termin- und Ablaufplan: enthält die zeitliche Abfolge von Arbeitspaketen mit der Zuordnung von Ressourcen (insbesondere Mitarbeitern) und berücksichtigt dabei fachliche, technische und organisatorische
Abhängigkeiten. Dauer und Termine der Aktivitäten ergeben sich aus dem geschätzten Aufwand und der
Kapazität der Ressourcen. Auf oberster Abstraktionsebene zeigt der Terminplan den Projektablauf mit
den wichtigen Meilensteinen (EN-701).
●
ggf. Produktstrukturplan: enthält in Entwicklungsprojekten die Struktur von Produkten mit Bauteilen,
Modulen, Komponenten etc.
Darüber hinaus existieren verschiedene Sichten auf die Planung, die einzelne Planungsaspekte für spezielle
Zielgruppen hervorheben. In einer solchen Planungssicht können beispielsweise alle Aktivitäten im Zusammenhang mit der Vorbereitung und Durchführung von Schulungen enthalten sein. Die Planungssichten dienen vornehmlich der Übersichtlichkeit und damit der besseren Handhabbarkeit und Kommunikation des Projekts.
→ Im Großprojekt ist die Anzahl der in der Planung enthaltenen Elemente so groß, dass die Erstellung ei nes detaillierten Gesamtprojektplans nicht sinnvoll ist. Detaillierte Pläne werden vielmehr auf Teilprojektebene erstellt. Die Pläne auf höherer Ebene bündeln dagegen die Informationen aus den Plänen der unteren
Ebenen. Sie enthalten im Wesentlichen übergreifende Zusammenhänge und Abhängigkeiten sowie die wesentlichen Meilensteine. Abbildung 54 zeigt ein Beispiel eines groben Projektplans auf Gesamtprojektebene.
Abbildung 54: Beispiel eines groben Projektplans
Teilprojektpläne ergeben den konsolidierten Gesamtprojektplan
Controllinginformationen/Controllingberichte
Als Grundlage für das Controlling werden zahlreiche Daten benötigt, die exakt und übersichtlich zu dokumentieren sind. Dazu gehören relevante Informationen zum aktuellen Status (Ist-Werte) für die unterschiedli chen Planungsdimensionen sowie Informationen, die Aussagen über zukünftige Entwicklungen erlauben.
Diese werden periodisch (meist monatlich) in einem Controllingbericht zusammengefasst.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
118
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
7.1.4 Prozesse: Wie wird bei der Projektplanung vorgegangen?
Die Prozesse in der Projektplanung sind in der folgenden Abbildung im Überblick dargestellt.
Abbildung 55: Prozesse der Projektplanung
Festlegung der Prozesse und Rahmenbedingungen für Planung und Controlling
Bei Projektbeginn sind die Verantwortlichkeiten für den Planungs- bzw. Controllingprozess festzulegen.
Zusätzlich werden der Planungs- und Controllingprozess und weitere Rahmenbedingungen für die Planung
definiert. Es wird insbesondere festgelegt, wer zu welchem Zeitpunkt welche Aufgaben erledigen muss bzw.
wer nach welchen Kriterien und Rahmenbedingungen Informationen liefern muss, um einen reibungslosen
Ablauf zu gewährleisten. Die eigentliche Planungserstellung und das Durchführen des Controllings erfolgen
im Anschluss (siehe folgende Kapitel).
→ Im Großprojekt sind Planung und Controlling so umfangreich, dass sie die Unterstützung auf allen Ebenen des Projekts erfordern. Daher wird der Gesamtprojektleiter die Aufgaben und Verantwortungen an verschiedene Mitarbeiter delegieren, wie bereits im Kapitel Rollen: Wer macht was in der Projektplanung? beschrieben.
Verantwortung nach unten delegieren
→ In Großprojekten sind viele Mitarbeiter auf verschiedenen Ebenen regelmäßig mit Planung und Controlling beschäftigt. Daher bedarf es von Beginn an stringenter Durchgängigkeit ohne Brüche in Werkzeugen
oder Medien. Es ist daher zu empfehlen, die Anforderungen für alle Beteiligten und eine sinnvolle Kaskadierung bzw. Aggregation der Informationen eingangs festzulegen. Insbesondere sollten die Prozesse be reits so weit durchdacht sein, dass sie im Projektverlauf stabil bleiben.
Durchgängigkeit der Planung durch strikte Prozessvorgaben sicherstellen
→ Motivation für Planungs- und Controllingtätigkeiten in Großprojekten schaffen
Für viele Mitarbeiter besitzen Planungs- und Controllingaufgaben oft eine niedrigere Priorität als solche,
die zum Projektergebnis beitragen. Das Projektmanagement muss daher Verständnis dafür schaffen, dass
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.1 Projektplanung
119
Planung und Kostenkontrolle zu den zentralen Aufgaben jedes Mitarbeiters zählen und der damit verbundene Aufwand zwingend notwendig ist. Dies gilt insbesondere für Großprojekte!
Motivierend wirkt hierbei eine ausreichende Transparenz hinsichtlich der Ziele und Auswirkungen der eigenen Tätigkeiten. Diese kann z.B. geschaffen werden, indem über einzelne Ergebnisse des Controllings
Rückmeldung gegeben wird – bis hin zu Einzelrückmeldungen zu Teilprojekten, Phasen oder sogar Feedback an einzelne Mitarbeiter. Durch diese Rückkopplung werden die Mitarbeiter zu Planungs- und Controllingtätigkeiten motiviert.
Dabei ist allerdings festzulegen, welche Informationen tatsächlich zur Kommunikation geeignet sind. Beispielsweise ist es nicht sinnvoll, vorhandene Puffer oder Rückstellungen uneingeschränkt in das Team zu
kommunizieren. Es werden daher entsprechende Vertraulichkeitsstufen definiert, die die Weitergabe von Informationen verbindlich regeln.
Mitarbeitermotivation durch Transparenz
→ Sicherstellen der Planeinhaltung durch Vorgaben und Commitment
Um Planung und Controlling von der Gesamtprojektebene an tiefere Ebenen delegieren zu können, müssen
zunächst die Vorgaben für das Gesamtprojekt auf die Teilbereiche bzw. -projekte aufgeschlüsselt werden.
So erhalten Mitarbeiter auf Teilprojektebene z.B. Aufwandsvorgaben für einzelne Arbeitspakete.
●
Auf den unteren Ebenen des Großprojekts ist es sinnvoll, dass der Projektleiter explizit das Commitment der Ergebnisverantwortlichen zu vorgegebenen (Rest-)Aufwandsschätzungen einholt. Gleichzeitig zeigt er ihnen auf, welche Einflussmöglichkeiten sie auf den Aufwand haben. Beispielsweise holt
der Teilprojektleiter das Commitment der Mitarbeiter zu dem jeweils für ihre Aufgaben vorgesehenen
Aufwand ein. Dies erhöht wesentlich die Wahrscheinlichkeit, dass die Vorgaben eingehalten werden.
●
Auf den höheren Ebenen (Auftraggeber > Großprojekt/Gesamtprojektleiter, Gesamtprojektleiter >
Projektmanager/Teilprojekte) besteht in der Regel keine derart enge Zusammenarbeit. Statt Commitments einzuholen, empfiehlt es sich hier, den Verantwortlichen Vorgaben zu machen, Leitplanken zu
setzen und ein klares Erwartungsmanagement zu betreiben. So kann das Thema als Standard-Agendapunkt im Jour fixe der Projektleitung oder in der LA-Sitzung etabliert werden. Dieses Vorgehen setzt
jedoch genügend Handlungsspielraum und Ergebnisverantwortung auf Seiten derer voraus, die die Vorgaben umsetzen müssen. Für die Teilprojekte wird durch die Vorgaben Budgetverbindlichkeit hergestellt, ohne dass auf Projektmanager-Ebene Mikromanagement betrieben werden muss.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
120
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Abbildung 56: Planungscontrolling durch Vorgaben und Commitment
Commitment auf unteren, Vorgaben auf höheren Ebenen des Projekts
→ Sicherstellen der Planeinhaltung in Konstellationen mit externem Auftragnehmer
Arbeitet das Projekt in einer Konstellation mit einem externen Auftragnehmer (bzw. mehreren externen
Auftragnehmern), unterscheiden sich die Verantwortlichkeiten und Prozesse in der Planung je nach Vertragsart:
●
Der externe Auftragnehmer übernimmt Teilgewerke zum Festpreis: Vertraglich sind normalerweise
Budgets und Termine vereinbart. Eine Zulieferung von Budget- oder Aufwandsdaten für die Gesamtprojektplanung ist daher nicht notwendig und wird auch häufig vom Auftragnehmer abgelehnt. Wesentlich sind jedoch das Festlegen von Meilensteinen im Projektverlauf und die exakte Definition der zu
diesen Meilensteinen zu liefernden Ergebnisse (Definition von „fertig“). Vom Auftraggeber sollten
dann regelmäßig Informationen zu Terminen und Fertigstellungsgrad eingefordert werden.
●
Der externe Auftragnehmer erledigt Arbeitspakete gegen Aufwandsverrechnung: In diesem Fall sollte
der Auftragnehmer in den Planungs- und Controllingprozess eingebunden sein, das heißt, der Auftragnehmer liefert die für Planung und Controlling relevanten Daten, um Planungsrisiken zu vermeiden.
Aufgabenverteilung und Verantwortlichkeiten sollten bereits im Vertrag festgelegt werden, spätestens aber
zu Beginn des Projekts.
Aufgaben und Verantwortlichkeiten in der Planung mit externem AN im Vertrag festlegen
→ Festlegung der Planungsparameter
Im Großprojekt entstehen auf den verschiedenen Projektebenen Planungen unterschiedlicher Granularität. Es ist festzulegen, welche Informationen in der nächsthöheren Planungsebene relevant sind (Meilen steine, Zulieferungen, Abhängigkeiten etc.), wer die Planung auf der nächsthöheren Ebene zusammenführt,
wie die Informationen von Ebene zu Ebene transportiert werden und welche Aktualisierungszyklen gelten.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.1 Projektplanung
121
Diese Parameter stellen sicher, dass die Planung jederzeit aktuell und über die Ebenen hinweg konsistent
ist. Auf der untersten (detailliertesten) Ebene unterscheidet sich die Planung eines großen Projekts dann
nicht mehr von der Planung eines kleinen Projekts. Bei Länder- oder Organisationsübergreifender Abwicklung des Projekts ist im Übrigen darauf zu achten, dass die unterschiedlichen Feiertagsregelungen berück sichtigt werden.
Feste Planungsparameter sichern Konsistenz
→ Definition der Planungssichten
Im Großprojekt ist genau festzulegen, welche Zielgruppen für die Planung relevant sind und welche Planungs- und Controllinginformationen von ihnen benötigt werden. Festgelegt wird auch, wer die Planungssichten in welchen Zyklen aktualisiert und kommuniziert.
Planungssichten existieren beispielsweise zu speziellen Ausschnitten der Planung (z.B. Schulungsplanung
oder Planung einer Stufe), zu Abhängigkeiten und geplanten Zulieferungen oder zu Meilensteinübersichten
für den LA.
Planungssichten zielgruppenspezifisch festlegen
Festlegung der Schätzmethodik
Vor Beginn der Aufwandsschätzung ist zunächst festzulegen, mit welcher Methodik der Aufwand geschätzt
bzw. die Restaufwandsschätzungen durchgeführt werden und wie die Schätzungen zu prüfen sind. Erst danach erfolgt die eigentliche Erstellung und Anpassung der Aufwandsschätzung (siehe dazu die folgenden Kapitel).
→ In Großprojekten werden im Projektverlauf zahlreiche (Rest-)Aufwandsschätzungen in unterschiedli cher Verantwortung für unterschiedliche Teile des Projekts durchgeführt. Diese Teilschätzungen müssen
strukturell und inhaltlich zusammenpassen, damit eine Zusammenführung und Konsolidierung bis auf
Gesamtprojektebene möglich ist. So dürfen beispielsweise Risikopuffer in Teilprojekten nicht mitgeschätzt
werden, wenn diese bereits per Zuschlag im Gesamtprojekt berücksichtigt sind.
Teilschätzungen sind eng an den Gesamtschätzungen angelehnt
Zur Festlegung der Schätzmethodik in Großprojekten sind die folgenden Punkte zu beachten:
●
Festlegung von Standard-Vorgaben und -methoden
●
Berücksichtigung des Kommunikations- und Steuerungsaufwands
●
Berücksichtigung von Aufwandsposten am Rande des Projekts
●
Berücksichtigung von Risikopuffern
●
Festlegung und Verifizierung der Produktivitätsannahme
●
Absicherung der Schätzung.
→ Festlegung von Standard-Vorlagen und -methoden
Nützlich ist die Verwendung von Standardvorlagen und -methoden, die durch Nennung der relevanten AufS-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
122
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
wands- und Kostenfaktoren Vollständigkeit gewährleisten und darüber hinaus Schätzanleitungen geben.
Die Vorlagen berücksichtigen beispielsweise alle für das Projekt relevanten Phasen von der Projektanbahnung bis zur Inbetriebnahme sowie alle Aufwands- und Kostenkategorien, die auch im WiBe-Standard vorgesehen sind (Software, Hardware, Implementierung, Projektmanagement, aber auch weniger offensichtliche Faktoren wie Reisekosten, Trainingskosten, Bezüge, Wartung, Betriebsaufwände für die ersten Jahre
etc.). Hier sind insbesondere auf die beim Bundesministerium für Finanzen ständig aktualisierte Personalkostensätze hinzuweisen.
Bei der Entwicklung von Individualsoftware legen die Schätzanleitungen insbesondere für den Implementierungsaufwand fest, welche Vorgaben für die detaillierten Aufwandsschätzungen zu berücksichtigen sind,
so dass eine einheitliche, konsolidierte Bestimmung des Aufwands auch auf Gesamtprojektebene möglich
wird (z.B. Schätzung zu Use Case Points, Function Points, Anzahl der Dialoge/Batches/Schnittstellen mit
zugehörigen Komplexitätsmaßen).
Die beiden folgenden Abbildungen zeigen Beispiele für Standardvorlagen zur Bestimmung der Projektkosten und des Projektaufwands:
Abbildung 57: 3 + 9 Schritte zur Abschätzung der Projektkosten einer ERP-Standard-Implementierung
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.1 Projektplanung
123
Abbildung 58: Beispiel Checkliste/Vorlage zur Aufwandsschätzung einer Individualsoftware-Entwicklung
Die nachfolgende Abbildung 59 zeigt eine Standardvorlage zur Darstellung des Projektbudgets getrennt
nach haushaltswirksamen und nicht haushaltswirksamen Kosten pro Phase im Projektlebenszyklus und
Jahr.
Abbildung 59: Beispiel einer Projektbudgetübersicht
Fehlervermeidung durch Verwendung von Standardvorlagen
→ Berücksichtigung des Kommunikations- und Steuerungsaufwands
Ein wichtiger Punkt der Schätzanleitung ist der Aufwand für Kommunikationsmanagement und Projektsteuerung. Denn der entsprechende Aufwand für beide Aufgaben steigt mit zunehmender Projektgröße
überproportional an. Daher kann der Kommunikations- und Steuerungsanteil kleiner Projekte nicht ein-
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
124
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
fach auf Großprojekte hochgerechnet werden.
Zunächst müssen die Ideen und Konzepte zu Kommunikation und Steuerung im Großprojekt festgelegt
werden. Auf dieser Basis lässt sich der Aufwand bestimmen. Beispielsweise fließt in einem Großprojekt
viel Arbeit in die Erstellung eines Statusberichts, da auf allen Ebenen Informationen eingeholt, zusammengeführt und konsolidiert werden müssen. Für die Schätzung macht es daher einen erheblichen Unterschied,
ob der Statusbericht monatlich oder zweiwöchentlich erstellt wird.
Generell ist die Erwartung an die Projektmitarbeiter bezüglich der Kommunikations- und Steuerungsmechanismen im Projekt klar zu kommunizieren. Auf diese Weise kann der dadurch induzierte Aufwand in
Aufwandsschätzungen korrekt berücksichtigt werden.
Klare Kommunikationskonzepte erleichtern Aufwandsschätzung für Kommunikationskosten
→ Berücksichtigung spezieller Aufwandsposten in der öffentlichen Verwaltung
In der öffentlichen Verwaltung ist (sind) über den Inhalt des eigentlichen Projektauftrags hinaus häufig
Aufwand (und Kosten) des Auftraggebers zu berücksichtigen (z.B. Aufwand für die Abnahme von Konzepten und Systemen; Aufwand für Schulungsteilnahme). Das gehört in der Regel nicht zum Aufwand der
unmittelbaren Projektmitarbeiter. Aus diesen Daten entstehen jedoch weitere Randbedingungen für die Planung. Deren Erhebung und die sich ergebenden Maßnahmen werden daher Bestandteil des Controllings.
Der Aufwand der Einbettung eines neuen Systems in eine bestehende Systemlandschaft muss berücksichtigt werden. Besonders ausgeprägt ist dieser Aufwand in der öffentlichen Verwaltung, z.B. durch besondere
Anforderungen hinsichtlich Sicherheitsauflagen und Datenschutzbestimmungen.
Anbindung bestehender Systemlandschaften als Teil der Projektkosten
→ Berücksichtigung von Aufwandsposten am Rande des Projekts
IT-Projekte sind häufig nur Teile/Teilprojekte eines Gesamtvorhabens, für das auch Tätigkeiten aus anderen
Teilprojektbereichen anfallen. Bei der Festlegung der Projektrahmenbedingungen wurde eine Grenze zwischen dem IT-Projekt und dem Gesamtvorhaben definiert. Die Aufwandsposten an der Schnittstelle, die als
Teil des IT-Projekts definiert wurden, müssen in der Aufwandsschätzung berücksichtigt werden.
Schnittstellen zwischen IT-Projekten klar definieren
→ Berücksichtigung von Risikopuffern
Jede Aufwandsschätzung muss einen Risikopuffer für unvorhergesehene Ereignisse beinhalten.
In Großprojekten behält der Gesamtprojektleiter die Kontrolle über den Risikopuffer. Im Projekt ist festzulegen, wie der Puffer in den Schätzungen auf unterschiedlichen Projektebenen zu berücksichtigen ist. Der
Puffer wird normalerweise nur einmalig auf Ebene des Gesamtprojekts geschätzt.
Zusätzlich muss auch der Auftraggeber einen Puffer einplanen, der dem Projekt nicht zur Verfügung gestellt
wird. Dies hält dem Auftraggeber bei Problemen im Projekt Handlungsoptionen offen. Darüber hinaus entstehen auch beim Auftraggeber Aufwand und Kosten für Änderungen oder ursprünglich nicht berücksich -
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.1 Projektplanung
125
tigte Themen („vergessene Aktivitäten“).
Verwaltung des Risikopuffers durch den Gesamtprojektleiter
→ Festlegung und Verifizierung der Produktivitätsannahme
Zentraler Punkt der Rahmenbedingungen der Schätzung ist die Annahme zur Produktivität der Mitarbeiter
und Teams. Schon geringe Abweichungen zwischen der Produktivitätsannahme und der tatsächlich erreichten Produktivität führen in Großprojekten angesichts des größeren Hebels zu erheblichen Schätzfehlern. Beispielsweise muss ein Experte bei der Schätzung berücksichtigen, dass die Projektaktivitäten nicht
nur durch Experten durchgeführt werden, sondern auch von Mitarbeitern mit wesentlich weniger Knowhow. Die Produktivitätsannahme ist im Projektverlauf anhand von Soll-Ist-Vergleichen unter Einbeziehung
der Restaufwandsschätzungen und unter Berücksichtigung der Erfahrung und Qualifikation der Mitarbeiter
zu verifizieren und zu verfeinern.
Stetige Verbesserung der Produktivitätsschätzungen reduzieren Fehler
→ Absicherung der Schätzung
Ein wesentlicher Erfolgsfaktor für den Schätzprozess in Großprojekten ist die Absicherung der Schätzung
durch Qualitätssicherungsmaßnahmen. Dies verhindert, dass sich durch einseitige Anwendung einer
Schätzmethode systematische Fehler einschleichen, die sich im Großprojekt auf Grund der hohen Anzahl
an Schätzposten zu einem erheblichen Gesamtschätzfehler summieren können. Zur Absicherung haben sich
folgende Maßnahmen bewährt:
●
Schätzung über eine andere Schätzmethodik (z.B. Prüfung über Erfahrungsdatenbank mit Aufwandsdaten zu vergleichbaren Projekten, Use-Case-Point-Methode, Function-Point-Methode)
●
Prüfung durch Experten, die mit der technischen und/oder fachlichen Domäne vertraut sind
●
Prüfung durch Gesamtprojektleiter und Projektmanager mit entsprechendem Erfahrungshintergrund in
Projekten mit ähnlicher Größenordnung, insbesondere im gleichen Umfeld.
Doppelte Überprüfung der Schätzung
Aufwandsschätzung erstellen
Der für das Projekt benötigte Aufwand wird erstmalig in der Projektanbahnungsphase geschätzt. Die Schät zung beruht auf den Informationen, die zu diesem Zeitpunkt über den Projektumfang vorliegen bzw. über die
Aktivitäten, die im Hinblick auf das Projektziel erforderlich sind, und über die Rahmenbedingungen des Projekts. Diese erstmalige Schätzung ermöglicht eine Angabe zum Gesamtaufwand, die im weiteren Verlauf als
Vorgabe für das Gesamtprojekt dient.
→ Zu Beginn von Großprojekten sind die Anforderungen selten vollständig, konsistent und detailliert spezifiziert. Dennoch muss das Großprojekt in Gang gesetzt werden, das heißt, der Prozess zur Aufwandsschätzung (und damit einhergehend die Planung) beruht auf unklaren Anforderungen. Erst mit der Detaillierung der Lösung ergeben sich zunehmend stabile und detaillierte Anforderungen, auf deren Basis sich der
Aufwand stabiler und genauer schätzen lässt. Ziel ist eine Detaillierung und Stabilität in einem Ausmaß,
das eine Steuerung des Projekts erlaubt.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
126
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Angemessene Berücksichtigung unklarer Anforderungen sicherstellen
Der Detaillierungsprozess gliedert sich in folgende Schritte:
●
Vorgaben und Rahmenbedingungen festlegen
●
Erstes Lösungskonzept erarbeiten
●
Lösung detaillieren.
Vorgaben und Rahmenbedingungen festlegen
Als Ausgangspunkt für die Detaillierung dienen die Vorgaben und Rahmenbedingungen, die bei der Projek tanbahnung festgelegt werden. Hierbei handelt es sich insbesondere um den messbaren Nutzen, greifbare
Ziele, den vorgegebenen Lösungskorridor, Termine und Budget. Diese Rahmenbedingungen müssen so gestaltet sein, dass sie eine detaillierte Lösung ermöglichen. Die methodische Vertiefung dieses Aspekts wird
im Kapitel Festlegung/Überprüfung der Projektrahmenbedingungen erläutert.
Erstes Lösungskonzept erarbeiten
Auf Basis der Vorgaben und anhand der Informationen, die im Hinblick auf eine mögliche Lösung vorliegen,
wird eine Lösungsidee skizziert und ein Lösungskonzept erarbeitet. Berücksichtigt werden dabei beispiels weise die Informationen aus einer Machbarkeitsstudie. Das Lösungskonzept ermöglicht eine Schätzung des
Aufwands für das Gesamtprojekt („Top-down-Schätzung“). Aus dieser Schätzung ergeben sich Vorgaben für
Teilbereiche des Projekts oder für Teilprojekte.
Lösung detaillieren
Auf den unteren Ebenen des Projekts wird die Lösung weiter detailliert und für die einzelnen Teile des Pro jekts eine genauere Schätzung erstellt („Bottom-up-Schätzung“). Detaillösungen und Schätzungen werden
auf der Ebene des Gesamtprojekts konsolidiert. Aus dieser detaillierten Gesamtlösung können sich geänderte
Vorgaben für Teile des Projekts ergeben; in diesem Fall ist eine erneute Schätzung und Lösungsdetaillierung
erforderlich.
Abbildung 60 veranschaulicht den Prozess der sukzessiven Lösungsdetaillierung.
Abbildung 60: Konkretisierung der Anforderungen im Verlauf des Projekts
Die sukzessive Detaillierung wirkt der Gefahr des Übersteuerns in frühen Phasen entgegen: Oft wird zu
früh eine kleinteilige Schätzung (und eine darauf aufbauende Planung) für Teile des Projekts vorgenommen,
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.1 Projektplanung
127
die dann in das Gesamtprojekt einfließt. Dadurch kann ein minimaler Fehler, der sich aus noch ungenauen
Anforderungen ergibt, eine erhebliche Ungenauigkeit der Gesamtschätzung bewirken.
Die Aufwands- und Budgetvorgaben, denen das Projekt und seine Teilprojekte unterliegen, beeinflussen die
Qualität bzw. den Umfang der Lösungsdetaillierung. Erforderlich ist eine Rückkopplung mit dem Auftraggeber, wenn die im Rahmen der Vorgaben erreichbare Lösungsqualität oder der erreichbare Lösungsumfang
nicht den Erwartungen entspricht (EN-702).
Für die gesamte Lösungsdetaillierung und die damit einhergehende Detaillierung der Schätzung und Planung
gilt: Die Ungenauigkeit eines Ergebnisses ist stets klar mitzuteilen. Das gilt sowohl innerhalb des Projekts
für Detailschätzungen in Teilprojekten und für die Kommunikation mit dem Gesamtprojekt als auch auf Gesamtprojektebene für die Kommunikation mit dem Auftraggeber. Beide Seiten müssen die Planungsungenauigkeit auf Grund der unklaren Anforderungen akzeptieren und sich dem damit einhergehenden Änderungsbedarf im Laufe der Detaillierung bewusst sein.
Wo möglich, sollten die Ursachen für unklare Anforderungen beseitigt werden. Dies geschieht z.B. durch Benennung der Anzahl anzubindender Nachbarsysteme, Aufzeigen der Einbettung der Lösung in die Anwen dungslandschaft, Quantifizierung der zu bewegenden oder zu erarbeitenden Artefakte, Entwurf des Architek turbilds auf grober Ebene und Bestimmung der wichtigsten Funktionsbausteine oder Quantifizierung des Zusatzaufwands für begleitende Maßnahmen wie Datenschutz oder Barrierefreiheit.
Budgetplanung erstellen
Der geschätzte Aufwand wird in Geldwerte umgerechnet. Dazu erforderlich sind Angaben zur geplanten Zusammensetzung des Teams und zu den Kosten für die Mitarbeiter. Darüber hinaus werden alle in der Anbahnungsphase bekannten sonstigen Kosten ermittelt (z.B. Lizenz-, Hardware- und Reisekosten). Beide Größen
ergeben in Summe das erforderliche Gesamtbudget. Zugleich wird geplant, zu welchen Zeitpunkten das Budget für welche Zwecke abfließt. Beispielsweise werden Meilensteine zu Rechnungsstellungen und zur Be schaffung von Hardware bestimmt.
Bei Projekten mit externen Anbietern von Software- und Implementierungsleistungen enthält die Kostensumme, die im Angebot des Externen erscheint, zumeist nur Lizenzkosten und direkte Implementierungskosten,
viele weitere Kostenfaktoren sind nicht enthalten: In einem Beispielfall bildete der Vertragswert für einen
Vertrag mit einem Softwareanbieter und Implementierer weniger als 25% der Gesamtkosten des Projekts ab.
Im Vertrag war die Mehrwertsteuer nicht ausgewiesen, auch Kosten für die Softwarewartung (ca. 20% der
Lizenzkosten pro Jahr, fällig ab Vertragsabschluss) etc. waren nicht bewertet; hinzu kamen interne Kosten.
Außer den bewerteten Kostenfaktoren enthält der Budgetplan entsprechende Puffer, die sich zum einen aus
dem Puffer in der Aufwandsschätzung berechnen, zum anderen aus dem Puffer für ungeplante sonstige Kos ten.
→ In der öffentlichen Verwaltung ist ein Teil der Budgetplanung in der IT-WiBe enthalten, die externe
(haushaltswirksame) und interne (nicht haushaltswirksame) Kostenfaktoren im Projekt und in den ersten
fünf Jahren des Betriebs berücksichtigt.
IT-WiBe als Teil der Budgetplanung
→ In der öffentlichen Verwaltung sind bei der Budgetplanung die Vorgaben des Haushaltsrechts zu beachten. Zu Beginn des Projekts festgelegte und auf Jahresgrenzen aufgeteilte Budgets schränken die Flexibili tät in der Budgetplanung ein. Das Haushaltsrecht sieht jedoch Mechanismen vor, die auch eine Planung
über mehrere Jahre erlauben, z.B. durch Übertragbarkeit von Budgets oder Verpflichtungsermächtigungen.
Die Vorgaben des Haushaltsrechts müssen als Rahmenbedingungen in die Planung eingehen. So ist beispielsweise darauf zu achten, dass der Risikopuffer nicht nur einmalig zu Projektende in die Budgetplanung
einfließt, sondern realistisch auf die Jahre verteilt ist – andernfalls steht er in frühen Phasen des Projekts
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
128
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
nicht für ungeplante Ausgaben zur Verfügung. Generell sollte an der Budgetplanung ein HaushaltsrechtsExperte beteiligt werden.
Haushaltsrecht erfordert Verteilung von Budgetposten auf einzelne Jahre
→ In einem Großprojekt ist es sinnvoll, das Kostenbewusstsein der Mitarbeiter durch Information über die
Kostentreiber zu aktivieren. Z.B. kann der unachtsame Umgang mit Lizenzen zu einem erheblichen Kostenfaktor werden, ebenso sollte man ein „Viel hilft viel“ vermeiden z.B. in der Planung der Schulungen und
Hardwarelandschaft.
Kostenbewusstsein aller Mitarbeiter aktivieren
Terminplanung erstellen
Auf Basis der vorgegebenen Rahmenbedingungen aus der anfänglichen Aufwandsschätzung sowie der Verfügbarkeit von Ressourcen und der vorgegebenen Termine wird ein erster Projektplan erstellt. Er dient als
Ausgangspunkt für spätere Detaillierungen und Aktualisierungen und zur Prüfung von Abweichungen in späteren Projektphasen.
→ Grundlagen für die Planung sind sauber zwischen den Teilprojekten abgegrenzte Aufgabengebiete sowie
die zentral vorgegebenen Planungsparameter (Detailgrad der Planung auf unterschiedlichen Ebenen, Berücksichtigung von Urlaub, Überstunden, Feiertagen etc.).
Klare Abgrenzung der Aufgaben als Basis der Terminplanung
→ Die erste Planung wird auf Basis der ersten Schätzung des Aufwands erstellt. Daher gilt bei unklaren
Anforderungen analog der Detaillierungsprozess für die anfängliche Aufwandsschätzung (Kapitel Festlegung/Überprüfung der Projektrahmenbedingungen): Zu Beginn wird ein grober Gesamtplan als
Vorgabe/Rahmenbedingung für die Erstellung der Teilprojektpläne erstellt. Die Erkenntnisse aus den detaillierten Teilprojektplänen müssen umgekehrt wieder in den Gesamtplan einfließen. Bei Abweichungen zwischen den Vorgaben aus dem Gesamtplan und den Erkenntnissen aus den Detailplänen werden in Planungszyklen Konsistenz und Stabilität der Gesamtplanung herbeigeführt.
Detailplanungen verbessern Aufwandschätzungen iterativ
→ Ein wichtiger Aspekt bei der Planungserstellung in Großprojekten ist die Konsistenz der Gesamtplanung. Sowohl die Pläne der unterschiedlichen Projektebenen als auch die Pläne der unterschiedlichen Teilprojekte müssen zueinander passen (das gilt nicht nur für die erste Planung, sondern auch für Planungsaktualisierungen während der Projektlaufzeit). Von tieferer zu höherer Ebene werden die Informationen jeweils verdichtet, jedoch nicht verändert. Es muss dabei jederzeit möglich sein, detailliertere
Informationen aus den Planungen tieferer Ebenen zu erhalten, die konsistent zu den Planungsinformationen
der höheren Ebenen sind. Der Status der Planung auf höherer Ebene kann also nur so gut sein wie der
schlechteste Status auf der darunter liegenden Ebene, das heißt, falls ein auf dem kritischen Pfad liegendes
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.1 Projektplanung
129
Teilprojekt nicht im Plan liegt (Ampel auf „rot“), muss auch für das Projekt eine wahrnehmbare Abwertung
erfolgen. Der „Schönfärberei“ von Projektampeln kann durch die gleichzeitige Vorlage von zahlenbasierten
Controllingberichten begegnet werden.
Für die Konsistenz zwischen den Plänen gleicher Ebenen ist dafür zu sorgen, dass die Abhängigkeiten und
wichtigen Meilensteine in der Planung der höheren Ebene sichtbar und erhalten bleiben.
Darüber hinaus dürfen Mitarbeiter und Ressourcen nicht mehrfach verplant werden. Dies kann durch eine
feste Aufteilung auf die Teilprojekte und eine entsprechende Überwachung in einem Gesamtprojekt-Ressourcenpool gewährleistet werden.
Gesamt- und Teilpläne enthalten die gleichen Informationen auf unterschiedlichen Ebenen
→ Die erste Planung muss risikominimierende Maßnahmen berücksichtigen. In Großprojekten haben sich
folgende Maßnahmen bewährt:
●
Stufen bzw. Iterationen einplanen. Deren Einführung ist mit weniger Risiko behaftet als eine Einführung der Gesamtfunktionalität zu einem Termin („Big Bang“).
●
Erfolge in frühen Phasen planen. Dies erhöht die Motivation des Projektteams, steigert das Vertrauen
der Stakeholder und unterstützt das Projektmarketing.
●
Proof of Concept vorsehen. Dies reduziert das Risiko, dass sich Lösungskonzepte zu spät als nicht
tragfähig erweisen, z.B. weil sie Nutzeranforderungen oder Volumenvorgaben nicht erfüllen
Typische Maßnahmen zur Minderung des Planungsrisikos
→ In der öffentlichen Verwaltung sind in der Planung Zeiträume und Fristen zu berücksichtigen, die sich
aus Vergabe-, Haushalts- und Dienstrecht ergeben. Beispielsweise sind bei öffentlichen Vergaben Mindestfristen einzuhalten.
Fest definierte Fristen bei der Planung berücksichtigen
Mit dem ersten Projektplan werden auch die definierten Planungssichten erstmalig erstellt.
Aktuellen Status erheben
Im Projektverlauf ist regelmäßig der aktuelle Status in allen Planungsdimensionen (Ist-Daten) zu erheben.
Ihm werden Informationen gegenübergestellt, die Aussagen über zukünftige Entwicklungen erlauben.
Die ausführlich zu berücksichtigenden Dimensionen sind Aufwand und Budget. Darüber hinaus sind Informationen zu Inhalt und Qualität sowie Nutzen sinnvoll.
→ In Großprojekten liefern die Aussagen zu Aufwand und Budget allein keine ausreichenden Informatio nen zur Steuerung des Gesamtprojekts. Daher werden auch die Dimensionen Inhalt (Fertigstellungsgrad)
und Qualität sowie Nutzen ausführlich betrachtet.
Zusätzliche Statusdimensionen in Großprojekten
Aktuellen Status zu Aufwand und Budget erheben
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
130
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Für das Controlling werden Ist-Aufwand und Ist-Kosten ermittelt sowie Restaufwand und zukünftige Kosten
geschätzt.
→ In komplexen Projekten ist die Schätzung des Restaufwands ab der Integrations- bzw. Testphase schwierig. Es geht um die Einschätzung, wie viel Zeit bzw. Aufwand für die Konsolidierung des Systems und für
die Fehlerbehebung erforderlich sind.
Oft erweist es sich als hilfreich, die Einschätzung der Teilprojektleiter hinsichtlich der erwarteten Fehlerzahl, ihrer Schwere und der Wahrscheinlichkeit, mit der diese Anzahl je Schwerekategorie erreicht wird,
einzufordern. Diese Information fließt in die Schätzung des Restaufwands ein. Die Wahrscheinlichkeit gibt
dem Gesamtprojektleiter einen Hinweis, wie genau die Schätzung des Restaufwands ist. Aus dem Vergleich
dieser Werte in aufeinander folgenden Schätzungen des Restaufwands ergibt sich eine Lernkurve für nachfolgende Stufen, so dass die Schätzung sukzessive genauer wird und damit die Planung exakter.
Zusätzliche Informationen wie z.B. Fehleranzahl verbessern Restaufwandschätzungen
→ In der öffentlichen Verwaltung ist eine detaillierte Erfassung des Ist-Aufwands mit dem Personalrat abzustimmen. Die Rahmenbedingungen im Projekt und in der Linie sind so zu gestalten, dass interne Mitar beiter in Abstimmung mit dem Personalrat ihren Beitrag zum Controlling leisten können.
Abstimmung mit Personalrat über mitarbeiterspezifische Themen
Aktuellen Status von Inhalt und Qualität erheben
→ Der Status von Inhalt und Qualität lässt sich anhand unterschiedlicher Informationen bestimmen. Beispiele dafür sind:
●
Informationen über den Fertigstellungsgrad der Artefakte, die im Projektverlauf geliefert werden müssen („Earned-Value-Analyse“). Dazu ist es notwendig, die unterschiedlichen Stufen der Fertigstellung
eines Teilergebnisses anhand eines Statusmodells genau zu definieren (was bedeutet „fertig“; was muss
bei 80% Fertigstellung erreicht sein etc.), damit alle Beteiligten den Fertigstellungsgrad einheitlich einschätzen.
●
Aktuelle Werte aus dem Qualitätsmanagementsystem, z.B. Informationen aus regelmäßigen oder zu definierten Meilensteinen geplanten Qualitätsreviews (z.B. Anzahl entdeckter Defekte bei Reviews), Informationen über die Anzahl von Fehlern und den Verlauf der Fehlerbehebung.
●
Ergänzende Informationen aus Werkzeugen, z.B. Ermittlung von Aufrufbeziehungen oder Kommentarzeilen durch ein Softwareanalysewerkzeug, die zusätzliche Informationen zur Bewertung einzelner
Qualitätskriterien liefern.
Ein Beispiel für die Statuserhebung des Inhalts zeigt die folgende Übersicht anhand des Fertigstellungsgrads der im Projekt zu erstellenden Dokumente.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.1 Projektplanung
131
Abbildung 61: Beispielbericht zum Fertigstellungsgrad zu erstellender Projektergebnisse
Verschiedene Kriterien helfen zur Statusbestimmung von Inhalt und Qualität
Aktuellen Status der Erzielung des Nutzens erheben
→ Um den bereits erzielten Nutzen zu bestimmen, werden regelmäßig die Rahmenbedingungen überprüft.
Dabei gilt es zu klären, ob die anfangs angenommenen Rahmenbedingungen und Parameter noch gültig
sind oder sich verändert haben. Haben sie sich verändert, ist der Nutzen anhand der in der Projektanbahnungsphase festgelegten Kriterien (Werttreiber) neu zu bemessen.
Regelmäßige Überprüfung der Nutzentreiber
Abweichungen ermitteln und Maßnahmen ableiten
Der aktuelle Status wird anhand von Soll-Ist-Vergleichen mit den ursprünglichen Vorgaben verglichen. Abweichungen bergen die Gefahr, dass das Projekt die ursprünglich vorgegebenen Rahmenbedingungen und
damit den Gesamtplan nicht einhält.
Mit zusätzlichen Trendanalysen lässt sich die Entwicklung in den verschiedenen Planungsdimensionen im
Zeitverlauf betrachten. Die Analysen können Hinweise auf künftige Abweichungen von den vorgegebenen
Rahmenbedingungen geben.
Bei erkannten aktuellen oder zukünftigen Abweichungen werden Gegenmaßnahmen ermittelt, mit denen sich
das Gesamtprojekt wieder in den ursprünglich vorgegebenen Korridor zurücksteuern lässt. Bei erwarteten
zukünftigen Abweichungen sollte die Wahrscheinlichkeit ermittelt werden, mit der eine Abweichung eintritt,
und es sollte eruiert werden, welche Faktoren diese Wahrscheinlichkeit erhöhen oder verringern. Diese Faktoren lassen sich durch explizit geplante Maßnahmen beeinflussen.
Prüfung von Aufwand und Budget
Um Aufwand und Budget zu prüfen, werden die entsprechenden ursprünglichen Vorgaben der Summe aus
Ist-Aufwand bzw. -Kosten und Restaufwand bzw. -kosten gegenübergestellt.
Trendanalysen liefern Hinweise auf mögliche zukünftige Abweichungen, z.B. durch:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
132
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
●
Betrachtung der Aufwands- und Budgetpuffer. Wie schnell verringert sich der Puffer, wann ist der
Puffer bei dieser Geschwindigkeit verbraucht?
●
Betrachtung der Teamkosten. Erhöhen sich die Durchschnittskosten des Teams durch den Einsatz von
Mitarbeitern mit höheren Entgeltstufen bzw. Tagessätzen? Wann ist das Budget verbraucht, wenn sich
dieser Trend fortsetzt?
●
Betrachtung der Ressourcenanfragen, die sich aus den Restaufwandsschätzungen (Mitarbeiter) und
den Restbudgetschätzungen (sonstige Ressourcen) ergeben: Fragen die Teilprojekte zunehmend Ressourcen an?
●
Betrachtung von Terminerreichung und kritischem Pfad; beides ergibt sich aus der Schätzung des
Restaufwands (dies erfolgt insbesondere bei der Planungsaktualisierung).
→ In der öffentlichen Verwaltung muss der Gesamtprojektleiter sicherstellen, dass die Budgetplanung mit
den jährlichen Haushaltsmeldungen und den in der IT-WiBe enthaltenen Angaben konsistent bleibt. Dafür
muss er eventuell die Aufgaben- oder Zeitplanung ändern oder anderweitige Maßnahmen ergreifen (z.B.
bereits zu Beginn Werkzeug des Puffers instrumentalisieren, Puffer auf Jahre verteilen).
Konsistenz von Budgetplanung, Haushaltsmeldungen und IT-WiBe wahren
Prüfung von Inhalt und Qualität
→ Der ermittelte Fertigstellungsgrad lässt sich durch den prozentualen Fertigstellungsgrad plausibilisieren,
der sich anhand von Ist-Aufwand und Restaufwand berechnet.
Mithilfe der Earned-Value-Analyse wird der Fertigstellungsgrad dem mit dem Ist-Aufwand korrelierenden
Soll-Fertigstellungsgrad gegenübergestellt.
Die hinsichtlich der Qualität erhobenen Daten werden anhand von Prognosen mit den Vorgaben abgeglichen. Beispielsweise liefern die erwartete Fehler- und Fehlerbehebungsrate einen Hinweis, ob bis zum geplanten Projektende alle Fehler behoben sind.
Trendanalysen liefern weitere Hinweise auf zukünftig zu erwartende Abweichungen, z.B. durch
●
Betrachtung der Produktivität. Wie hoch war die im letzten Controllingzyklus erwartete Produktivität (z.B. Fehlerbehebungsrate, Anzahl fertig gestellter Artefakte), wie hoch ist die tatsächliche Produktivität?
●
Betrachtung der Qualitätsprognosen. Wie fiel die beim letzten Controllingzyklus erwartete Qualitätsprognose aus (z.B. Anzahl der auftretenden Fehler), wie fiel die tatsächliche Qualitätsprognose aus (wie
viele Fehler traten tatsächlich auf)?
Plausibilisierung des Fertigstellungsgrads
Prüfung des erzielten Nutzens
→ Abweichungen vom erwarteten Nutzen können sich entweder durch im Laufe der Zeit geänderte Rah menbedingungen ergeben (z.B. wenn Nutzentreiber wegfallen, weil Verbesserungen bereits auf anderen
Wegen umgesetzt wurden) oder durch eine Änderung der geplanten Lösung, die nicht mehr auf die gleiche
Weise auf die Nutzenparameter wirkt.
Die Nutzenvorgaben des Projekts wurden zu Beginn in der Kosten-Nutzen-Analyse festgeschrieben, die
von den Stakeholdern gegengezeichnet wurde – Änderungen sind ohne Entschluss des LA nicht zulässig.
Liegt die Ursache für Abweichungen hinsichtlich des erwarteten Nutzens in einer geänderten Lösung, so ist
zunächst projektintern zu klären, ob die ursprüngliche Lösung nicht doch realisierbar ist oder es alternative
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.1 Projektplanung
133
Lösungen mit gleichem Nutzen gibt.
Ist dies nicht möglich oder liegen die Ursachen für die Abweichung im Projektumfeld, so ist der Fall an den
LA bzw. den Auftraggeber zu eskalieren, der notfalls die Kosten-Nutzen-Analyse ändern muss. Im Extremfall muss das Projekt eingestellt werden, wenn der zu erwartende Nutzen zu gering ist.
Abweichungen vom geplanten Nutzen müssen schnellstmöglich nach oben kommuniziert und dort
diskutiert werden
Planung aktualisieren und Maßnahmen durchführen
Maßnahmen, die sich aus den Abweichungen der aktuellen Daten von den vorgegebenen Werten ergeben,
werden in die Planung aufgenommen. Eine Aktualisierung der Planung ergibt sich im Verlauf des Projekts
auch aus weiteren notwendigen Änderungen auf Grund:
●
Aktueller Schätz- und Controllinginformationen, die neue Erkenntnisse enthalten und von den bisher in
der Planung enthaltenen Werten abweichen
●
Von Änderungen des Projektumfangs, z.B. durch genehmigte Änderungsanforderungen
●
Neu initiierter Maßnahmen aus den unterschiedlichen Projektmanagement-Disziplinen.
Bei der Aktualisierung ist darauf zu achten, dass alle relevanten Dokumente konsistent gehalten werden.
Aufwandsschätzung, Budgetplanung, Projektplan, Planungssichten und Controllinginformationen müssen
mit jeder Änderung auf allen Ebenen des Projekts angepasst werden.
→ In Großprojekten ist auf Ebene des Gesamtprojekts der kritische Pfad von Projektebene zu Projektebene basierend auf Detailplanungen zu ermitteln: Der kritische Pfad wird in den Teilprojekten auf der Ebene
der Arbeitspakete eruiert und dann auf den nächst höheren Ebenen anhand von Abhängigkeiten und Meilensteinen nachvollzogen, bis er schließlich in der Gesamtplanung sichtbar ist. Der kritische Pfad ist auf der
Ebene des Gesamtprojekts immer wieder zu betrachten; er liefert wesentliche Hinweise dazu, ob weitere
Maßnahmen zur Sicherung des Projekterfolgs notwendig sind. Regelmäßig muss hinterfragt werden, wo
auf dem kritischen Pfad Risiken zu finden sind und wie die Termineinhaltung der Themen auf dem kritischen Pfad sichergestellt werden kann.
Beobachtung des kritsichen Pfades durch Konsolidierung von Detailplanungen
→ Bei der Planung wird regelmäßig hinterfragt, ob die Gesamtplanung konsistent und vollständig ist
und ob einzelne Elemente bei der Aufteilung auf Teilprojekte oder in den Teilprojekten vergessen wurden.
Hierzu werden regelmäßige Planungsreviews angesetzt.
Konsistenz der Gesamtplanung durch Review sicherstellen
Schließlich werden die initiierten Maßnahmen umgesetzt. Ihre Wirksamkeit wird regelmäßig in den darauf
folgenden Planungszyklen geprüft.
7.1.5 Erfolgsmessgrößen: Woran kann der Auftraggeber eine gute Projektplanung erkennen?
Ein Auftraggeber kann eine erfolgreiche Projektplanung an qualitativen und quantitativen Kriterien messen.
Als qualitative Messgrößen sind beispielsweise folgende Prüffragen möglich:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
134
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
●
Sind alle Planungsdimensionen balanciert? (Passt z.B. der im Projektplan summierte Aufwand zur Aufwandsschätzung?) Sind die in der Projektplanung enthaltenen Ressourcen tatsächlich verfügbar?
●
Wie exakt sind die in der Planung ermittelten Ist-Daten? (Wie genau kann z.B. das aktuell verbrauchte
Budget angegeben werden?)
●
Wie genau sind die in der Planung ermittelten Voraussagen? (Wie genau werden z.B. anvisierte Termine
erreicht?)
●
Enthält die Planung Puffer und ist der kritische Pfad bekannt?
●
Sind die Planungen auf unterschiedlichen Ebenen des Projekts und die verschiedenen Planungssichten
konsistent zueinander?
●
Sind alle Stakeholder hinsichtlich der für sie wichtigen Planungsaspekte auf dem aktuellen Stand?
Als quantitative Messgrößen sind folgende Kennzahlen denkbar:
●
Anzahl der im Projektverlauf gemeldeten „vergessenen“ Aktivitäten und Themen (wie vollständig war
die initiale Schätzung bzw. Planung?)
●
Anzahl der aus dem Projekt heraus induzierten Änderungen an den vorgegebenen Planungsparametern
●
Umfang/Höhe der aus dem Projekt induzierten Änderungen im Vergleich zur Voraussage („goldene Re gel“: die geforderte Terminverschiebung darf niemals größer sein als die benötigte Restlaufzeit, der ge meldete Mehraufwand niemals größer als der geschätzte Restaufwand)
●
Reaktionszeit auf projektextern induzierte Änderungen (wie lange benötigt die Projektleitung zur Aktualisierung des Planungsstands und um mögliche Auswirkungen darlegen zu können?).
7.1.6 Grundlegende und weiterführende Literatur
Keine spezielle empfohlen.
7.2 Anforderungs- und Änderungsmanagement
7.2.1 Ziele: Was soll mit dem Anforderungs- und Änderungsmanagement erreicht werden?
Das Anforderungs- und Änderungsmanagement sorgt für die Sicherstellung der Erfolgsfaktoren "Minimaler,
stabiler Projektumfang“ und "Angemessene Methoden, Verfahren und Werkzeuge“.
Einen minimalen, stabilen Projektumfang sichert das Anforderungs- und Änderungsmanagement durch die
Erreichung der folgenden operativen Ziele:
●
Genaue sowie mess- und nachhaltbare Definition des geplanten Projektumfangs
●
Vermeidung einer schleichenden Erweiterung des Projektumfangs (Vermeidung von sogenanntem „Scope Creep“)
●
Kontrollierte Auswahl sowie kosten- und risikominimierende Aufnahme von notwendigen Änderungen
am Projektumfang (insbesondere Sicherstellung von Änderungen, die die Gesamtkonsistenz des Systems
nicht gefährden)
●
Abnahmeverfahren am Ende der Umsetzungsphase zur Sicherstellung, dass der definierte Projektumfang auch vollumfänglich erbracht wurde.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.2 Anforderungs- und Änderungsmanagement
135
Als Beitrag zum Erfolgsfaktor „Angemessene Methoden, Verfahren und Werkzeuge“ sorgt das Anforderungs- und Änderungsmanagement dafür, dass sich die Änderungen in allen Projektergebnissen, wie z.B.
Zeit- und Budgetplänen, niederschlagen. Besonders relevant ist diese Managementdisziplin für Softwareprojekte, insbesondere, aber nicht ausschließlich, bei der zentralen Einbindung eines Auftragnehmers. Die
Grundzüge und Aussagen sind jedoch für alle Projekttypen relevant und sollten Anwendung finden. Die Ziele des Anforderungs- und Änderungsmanagements beinhalten im Einzelnen:
Messbare Definition des Projektumfangs
Eine wesentliche Grundlage für die Durchführung des Projekts und insbesondere für das Anforderungs- und
Änderungsmanagement ist die anfängliche Festlegung aller zu berücksichtigenden Faktoren, Aktivitäten und
Rahmenbedingungen, an denen die spätere Zielerreichung gemessen werden kann.
Vermeidung einer schleichenden Erweiterung des Projektumfangs („Scope Creep“)
Im Projektverlauf werden intern oder extern Änderungsanforderungen an das Projekt herangetragen, meist in
Form so genannter CRs (Change Requests). Werden alle Änderungen unkontrolliert aufgenommen, ist die
Gefahr groß, dass das Projekt nicht mehr auf das ursprüngliche Ziel fokussiert ist und die vorgegebenen Rahmenbedingungen (insbesondere Budget- und Zeitpläne) verletzt werden, wodurch das Projektziel nicht erreicht werden kann. Das Anforderungs- und Änderungsmanagement vermeidet diese Entwicklung.
Berücksichtigung notwendiger Änderungen
Trotzdem gibt es Änderungsanforderungen, deren Umsetzung zwingend notwendig ist, z.B. wegen neuer gesetzlicher Vorgaben. Das Anforderungs- und Änderungsmanagement filtert diese notwendigen Änderungsanforderungen aus der Menge aller Änderungsanforderungen und sorgt für deren Aufnahme in den Projektumfang, ohne die Gesamtkonzeption des Systems zu gefährden.
Abnahme des Projektergebnisses
Weiterhin definiert das Anforderungs- und Änderungsmanagement die Verfahren für die Abnahme des ent standenen Systems durch den Auftraggeber – insbesondere regelt es Art, Umfang und Anzahl der durch das
Projekt zu erstellenden Projektergebnisse. Hierbei berücksichtigt es zusätzlich alle genehmigten Änderungen.
Konsistente Berücksichtigung der Änderungen im Gesamtprojekt
Sind Änderungsanforderungen für das Projekt genehmigt, sorgt das Anforderungs- und Änderungsmanagement schließlich dafür, dass diese Änderungen in allen relevanten Projektergebnissen und Projektmanagement-Werkzeugen (Planung, Controlling, Reporting etc.) konsistent berücksichtigt werden.
7.2.2 Rollen und Gremien: Wer macht was im Anforderungs- und Änderungsmanagement?
Folgende Rollen sind für das Anforderungs- und Änderungsmanagement relevant:
Projektleiter (Auftraggeber) Trägt Gesamtverantwortung für den Abnahmeprozess auf Auftraggeberseite, damit
insbesondere Verantwortung für die Abnahme der Projektergebnisse.
● Bestimmt den Abnahmeverantwortlichen, delegiert die Konzeption und Durchführung der
Abnahme an diesen.
Projektleiter
(Auftragnehmer)
Ist verantwortlich für das Anforderungs- und Änderungsmanagement.
● Bestimmt die planerischen Auswirkungen von Änderungsanforderungen.
● Legt Prozesse und Organisation des Anforderungs- und Änderungsmanagements fest.
● Delegiert die Analyse von Änderungsanforderungen an einen
Änderungsverantwortlichen.
Änderungssteuerungsgrup ●
pe (Change Control Board)
Entscheidet über Änderungsanforderungen, das heißt Genehmigung und Ablehnung von
Änderungsanforderungen auf Grund der im Projekt erstellten Analyse.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
136
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
●
●
●
●
Änderungsverantwortlicher ●
●
Abnahmeverantwortlicher
Erteilt Budgetfreigabe für die Umsetzung einer genehmigten Änderungsanforderung.
Schaltet den LA ein, falls eine Änderungsanforderung die Erreichung der festgelegten
Projektziele gefährdet, z.B. wenn diese nicht im Rahmen des für solche Änderungen
vorgesehenen Budgetpuffers bearbeitet werden kann.
Entscheidet in der Abnahmephase über die Einordnung gefundener Fehler und über die
Terminsetzung zur Fehlerbehebung.
Ist auf Grund ihrer Verantwortung mit Mitarbeitern von Auftraggeber- und
Auftragnehmerseite zu besetzen, die über die nötigen fachlichen und organisatorischen
Kompetenzen verfügen, über Änderungsanforderungen zu entscheiden und gefundene
Fehler in der Abnahmephase einzuordnen (z.B. müssen sie über das für eine
Änderungsanforderung notwendige Budget entscheiden können).
Analysiert die fachlichen und technischen Auswirkungen einer einzelnen
Änderungsanforderung auf die vom Projekt zu erstellenden Ergebnisse.
Holt alle für die Bewertung der Änderungsanforderung notwendigen Informationen ein,
insbesondere Aufwands- und Kostenschätzungen sowie Abhängigkeiten von anderen
Projektergebnissen.
Konzipiert den Abnahmeprozess.
● Stellt die Voraussetzungen für die Abnahme sicher (z.B. Vorbereitung von
Testumgebungen und Testdaten).
● Plant und koordiniert die Abnahme.
Tabelle 13: Rollen und Verantwortlichkeiten im Anforderungs- und Änderungsmanagement
→ In Großprojekten erfolgt die Einrichtung und Durchführung des Anforderungs- und Änderungsmanagements unter Beteiligung weiterer Projekt- und Teilprojektmitarbeiter:
●
Anforderungsanalytiker und Systemarchitekten unterstützen federführend die Erstellung des initialen
Projektumfangs aus fachlicher und technischer Sicht bei einem Softwareprojekt.
●
Der Anforderungsanalytiker trägt die inhaltliche Verantwortung für die Analyse und Priorisierung von
Änderungsanforderungen. Die eigentliche Durchführung der Analyse wird an den Änderungsverantwortlichen delegiert, der wiederum von weiteren Rollen unterstützt wird: Der Systemarchitekt wirkt
mit an der Bewertung der technischen Prioritäten und Auswirkungen von Änderungsanforderungen.
Für Details werden entsprechende Rollen auf den unteren Ebenen des Projekts hinzugezogen (Teilprojekt-Anforderungsanalytiker oder Teilprojekt-System-/Software-/Hardware-Architekt).
●
Der Planungsverantwortliche unterstützt die Analyse der planerischen Auswirkungen einer Änderungsanforderung.
●
Das PMO trägt die Verantwortung für die formale Abwicklung des CR-Verfahrens, prüft Fristen, fordert Entscheidungen ein und hält aktuelle Übersichten zu Änderungsanforderungen bereit.
●
Der QS-Verantwortliche unterstützt die Integration einer genehmigten Änderungsanforderung in alle
relevanten Projektprozesse und -ergebnisse.
●
Experten und Teammitglieder liefern Aufwandsschätzungen zu Anderungsanforderungen.
Großprojekte erfordern die Abstimmung des Anforderungs- bzw. Änderungsmanagements mit den
verschiedenen Parteien
7.2.3 Ergebnisse: Welche Dokumente sollen erstellt werden?
Wesentliche Ergebnisse des Anforderungs- und Änderungsmanagements sind:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.2 Anforderungs- und Änderungsmanagement
137
●
Definition des Projektumfangs. Detaillierte Festlegung der durch das Projekt zu erstellenden Ergebnisse und aller Aktivitäten, die für die Erstellung dieser Ergebnisse notwendig sind. Es wird dabei Bezug
genommen auf die in der Projektanbahnungsphase festgelegten Rahmenbedingungen und Abgrenzungen
des Projektumfangs von eventuell übergreifenden Vorhaben. Eine strukturierte Dokumentation des Projektumfangs erfolgt im Projektstrukturplan. Die Definition des Projektumfangs dient als Grundlage für
die initiale Aufwandsschätzung und Planung sowie für die Entscheidung zu Änderungsanforderungen.
Im Projektverlauf werden alle abgestimmten und genehmigten Änderungen am Projektumfang dokumentiert.
●
Anforderungsanalysen. Die Anforderungsanalyse (auch: Problem-/Änderungsbewertung) enthält alle
Informationen zu einer Änderungsanforderung, die eine Entscheidung zu ihrer Genehmigung sowie ihre
Umsetzung ermöglichen. Dazu gehören sowohl fachliche und technische Informationen als auch Informationen zu Auswirkungen auf die Projektmanagement-Disziplinen (z.B. Auswirkung auf die Planung).
●
Änderungsverfahren. Detaillierte Beschreibung des Prozesses zur Bearbeitung einer Änderungsanforderung von der Entstehung über eine eventuell notwendige Genehmigung (CR-Verfahren) bis hin zur Integration einer zu berücksichtigenden Änderung in das Projekt (Änderungsmanagement). Dieses Änderungsverfahren kann im Projekthandbuch unter Organisation und Vorgaben zum Problem- und Änderungsmanagement dokumentiert werden.
7.2.4 Prozesse: Wie geht das Anforderungs- und Änderungsmanagement vor?
Die Prozesse in dieser Disziplin sind in der folgenden Abbildung zusammengefasst.
Abbildung 62: Prozesse des Anforderungs- und Änderungsmanagements
Organisation, Prozesse und Rahmenbedingungen des Anforderungs- und Änderungsmanagements festlegen
Um die Grundlagen zu schaffen, werden zunächst Organisationsform, Prozesse und Rahmenbedingungen für
das Anforderungs- und Änderungsmanagement festgelegt. Die dazu notwendigen Schritte werden nachfol gend im Einzelnen dargestellt.
Organisation des Anforderungs- und Änderungsmanagements
Es wird festgelegt, welche Rollen mit welchen Verantwortlichkeiten am Anforderungs- und Änderungsmanagement beteiligt sind.
→ Die Verantwortung für das Änderungsmanagement im Großprojekt muss auf der obersten Ebene des
Gesamtprojekts angesiedelt sein. Sonst besteht die Gefahr, dass Änderungen in einem Teilprojekt berücksichtigt werden, dort aber aus Mangel an übergreifendem Wissen Auswirkungen auf andere Teilprojekte
nicht gesehen werden.
Anforderungsmanagement ist Chefsache
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
138
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Prozesse des Anforderungs- und Änderungsmanagements
Hauptverantwortlich für einen reibungslosen Prozess sind das Änderungsverfahren (1) und das Abnahmema nagement (2). Das Änderungsverfahren besteht aus zwei Teilprozessen:
●
CR- oder Veränderungs-Request-Verfahren (1a): Genehmigungsverfahren für Änderungsanforderungen
●
Änderungsmanagement (1b): konsistente Umsetzung von Änderungen.
Zusätzlich sind die Rahmenbedingungen für das Anforderungs- und Änderungsmanagement (3) festzulegen.
(1) Änderungsverfahren
(1a) CR-Verfahren
Das CR-Verfahren stellt sicher, dass Änderungen des Projektumfangs ausschließlich kontrolliert und abgestimmt in das Projekt übernommen werden. Der Prozess legt detailliert die Schritte bis zur
Genehmigung/Beauftragung oder Ablehnung einer Änderungsanforderung fest. Das CR-Verfahren gewährleistet darüber hinaus die detaillierte Analyse der Änderungsanforderungen unter Einbeziehung der erforderlichen Know-how-Träger, insbesondere der Fachabteilungen bzw. Nutzer. Alle für eine Entscheidung notwendigen Informationen werden zusammengetragen.
→ In Großprojekten ist ein formales, zentrales CR-Verfahren zu definieren, das eine hohe Hürde für die
Berücksichtigung von Änderungsanforderungen bildet, gleichzeitig aber notwendige Änderungen ermöglicht. Die Verantwortung für die formale Abwicklung liegt im PMO, die Verantwortung für die Analyse der
Änderungsanforderungen beim Anforderungsanalytiker. Ein Beispiel für einen formalisierten CR-Prozess
zeigt die nachfolgende Abbildung.
Abbildung 63: Beispiel für ein CR-Verfahren mit integriertem Analyseauftrag
Änderungsprozesse werden formal festgelegt
→ Auf Grund der oft hohen Anzahl an Änderungsanforderungen in Großprojekten ist eine Priorisierung
erforderlich, die es erlaubt, notwendige Anforderungen (z.B. gesetzliche Änderungen) herauszufiltern und
vordringlich anzugehen.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.2 Anforderungs- und Änderungsmanagement
139
Priorisierung schafft Überblick
→ In Großprojekten müssen Änderungsanforderungen in die vorgesehenen Inbetriebnahme-Stufen bzw.
Releases des Projekts eingeplant werden. Kriterien sind die fachliche Abhängigkeit der Änderungsanforderungen von den Release-Inhalten und die Dringlichkeit der Änderungsanforderung.
Gruppierung schützt vor Fehlern
(1b) Änderungsmanagement
Das Änderungsmanagement sorgt dafür, dass im Projekt zu berücksichtigende Änderungen konsistent umgesetzt werden. Dies bedeutet, dass eine Änderung in allen relevanten Projektprozessen und Ergebnissen bis
hin zur Abnahme und Inbetriebnahme durchgängig und vollständig berücksichtigt wird.
→ In Großprojekten ist es auf Grund der komplexen Projektstrukturen oft nicht einfach, alle Ergebnisse
und Prozesse zu identifizieren, in denen eine Änderung zu berücksichtigen ist. Hilfreich sind Checklisten,
die potenziell zu berücksichtigende Ergebnisse und Prozesse enthalten.
Über Checklisten prüfen, welche Komponenten eine Änderung betrifft
→ In einem Großprojekt sind die zu berücksichtigenden Änderungen so zahlreich und die Auswirkungen in
unterschiedlichen Teilen des Projekts so komplex, dass ein administratives Werkzeug notwendig wird
(Änderungsverfolgungswerkzeug). Dieses Werkzeug muss ausgewählt, gegebenenfalls beschafft und konfiguriert werden.
Tracking-Tools vereinfachen die Administration
Weiterhin definiert das Anforderungs- und Änderungsmanagement die Verfahren für die Abnahme des ent standenen Systems durch den Auftraggeber. Dies gestaltet sich folgendermaßen:
(2) Abnahmemanagement
Vorbereitung und Durchführung der Abnahme liegen in der Verantwortung des Auftraggebers. Die Begleitung der Abnahme durch Analyse und Behebung von Fehlern sowie die Bereitstellung fehlerbereinigter Versionen der Projektergebnisse liegen in der Verantwortung des Auftragnehmers.
Die Abnahme der Projektergebnisse erfolgt gegen die in den Projektumfang eingeflossenen, zwischen Auf traggeber und Auftragnehmer abgestimmten Anforderungen. Das Abnahmemanagement stellt somit sicher,
dass der definierte Projektumfang vollumfänglich und in der geforderten Qualität erbracht wurde.
Festgelegt werden die Abnahmekriterien, deren Erfüllung als Maßstab für eine erfolgreiche Abnahme be trachtet wird. Zu bestimmen ist konkret, welche für das Projekt vereinbarten Ergebnisse abgenommen wer den und welche nur zur Information/Abstimmung, aber ohne formale Abnahme geliefert werden.
Zu den Abnahmekriterien gehört auch die genaue Definition von Fehlerklassen, die während der Abnahme
vergeben werden (die höchste Fehlerklasse wirkt abnahmeverhindernd). Darüber hinaus sollte festgelegt
werden, wie viele Fehler pro Fehlerklasse bei der Abnahme erlaubt sind (in der Klasse der schwerwiegends ten Fehler zumeist null). Zu jeder Fehlerklasse werden Fristen zur Behebung festgelegt.
→ Für die öffentliche Verwaltung ist die Festlegung von Fehlerklassen in den EVB-IT enthalten.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
140
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Fehlerklassen nach EVB-IT
→ In Großprojekten, in denen die Abnahme durch viele Mitarbeiter – teilweise aus unterschiedlichen Organisationseinheiten und Firmen – erfolgt, ist die Festlegung von Abnahmekriterien erforderlich. Diese stellen
eine einheitliche Abwicklung der Abnahme im Gesamtprojekt sicher.
Einheitliche Abnahme nach Kriterienkatalog
(3) Rahmenbedingungen für das Anforderungs- und Änderungsmanagement
Die effektive Umsetzung des Anforderungs- und Änderungsmanagements erfordert entsprechende Rahmenbedingungen im Projekt, z.B. die vorherige Festlegung von Entscheidungskriterien zur Abwägung von Änderungsalternativen.
Hilfreich sind zwischen Auftraggeber und Auftragnehmer abgestimmte klare Projektziele, durch die der
Projektumfang inhaltlich begründet werden kann, sowie abgestimmte Projektgrundsätze, die es der Projektleitung erlauben, Änderungsanforderungen abzuwehren und im Zweifel den LA einzuschalten. Dazu gehört insbesondere die Fokussierung des Projekts auf dokumentierte Kernanforderungen sowie die Einrichtung entsprechender Eskalationsmechanismen (siehe Thema Projektcharta im Kapitel Prozesse: Wie lassen
sich die Rahmenbedingungen festlegen und prüfen?).
Ein klares Projektziel und ein definierter Projektumfang bilden die Basis für das Anforderungs- und Änderungsmanagement und müssen allen Projektbeteiligten bekannt sein; zusätzlich müssen sie sich darüber im
Klaren sein, welcher Beitrag von ihnen erwartet wird. Nur so können Änderungsanforderungen korrekt danach bewertet werden, ob sie dem Projektziel untergeordnet werden können und ob die Änderungen Auswir kungen auf den einzelnen Projektbeteiligten haben. Trägt eine Änderung nicht zur Erreichung des Projektziels bei, muss die jeweilige Anforderung separat gerechtfertigt oder abgelehnt werden.
Darüber hinaus sind in den Rahmenbedingungen Regeln festzulegen, nach denen die Kosten und Implementierungsrisiken einer Änderungsanforderung realistisch gegen den Nutzen abgewogen werden können.
Hilfreich ist, wenn die Entscheidungsträger sowohl für das Budget als auch für den Nutzen verantwortlich
sind – eine Änderungsanforderung wird nur dann genehmigt, wenn der Nachteil, der durch den entgangenen
Nutzen entsteht, größer ist als die zusätzlichen Kosten und Implementierungsrisiken.
Zu den Rahmenbedingungen zählen außerdem der Vorhalt eines Teils des Budgets für Änderungsanforderungen und die Einplanung eines Puffers für die Umsetzung genehmigter Änderungen (siehe Kapitel Projektplanung).
→ In der öffentlichen Verwaltung liegt die Budgethoheit oft nicht bei der Person, die über Änderungsanforderungen entscheidet (z.B. Budgethoheit bei IT, Entscheidung über Änderungen beim Fachbereich). Bewährt hat sich die Festlegung eines festen Budgets für Änderungsanforderungen, über das die Fachbereiche
während der Projektlaufzeit verfügen können.
Festlegung eines Budgets für Änderungsanforderungen
→ Abbildung 64 illustriert zusammenfassend die Besonderheiten und Erfolgsfaktoren des Anforderungsund Änderungsmanagements in der öffentlichen Verwaltung.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.2 Anforderungs- und Änderungsmanagement
141
Abbildung 64: Anforderungs- und Änderungsmanagement in der öffentlichen Verwaltung
Zusammenfassung aller Besonderheiten
Projektumfang festlegen
Auf Basis der in der Projektanbahnungsphase verfügbaren Informationen wird der Umfang des Projekts fest gelegt. Dieser berücksichtigt alle Vorgaben und Rahmenbedingungen für das Projekt, referenziert verfügbare
Dokumente (z.B. Lasten- und Pflichtenhefte) und definiert die zu erstellenden Ergebnisse. Insbesondere wird
auch festgelegt und dokumentiert, welche Aufgaben und Verantwortlichkeiten nicht Bestandteile des Projekts
sind. Dies dient auch der Abgrenzung zwischen Auftragnehmer und Auftraggeber.
Als Vertragsbestandteil ist der zwischen Auftraggeber und externem Auftragnehmer abgestimmte und dokumentierte Projektumfang die Basis für die Abnahme der Projektergebnisse durch den Auftraggeber (siehe
Kapitel Vergabe- und Vertragsmanagement).
→ Im Großprojekt wird der Projektumfang meist in mehreren umfangreichen Dokumenten detailliert be schrieben. Hilfreich ist es daher, die Anforderungen strukturiert aufzubereiten; das kann z.B. in einer Liste
oder Datenbank erfolgen, die zwischen Auftraggeber und -nehmer abgestimmt wird. So können Anforderungen eindeutig identifiziert und priorisiert (muss, soll, kann) werden. Darüber hinaus wird auf die Stelle
im Dokument verwiesen, an der die Anforderung ursprünglich beschrieben wurde. Nicht zuletzt erleichtert
die strukturierte Aufbereitung erheblich die Vorbereitung der Abnahme.
Die Strukturierung der Anforderungen erleichtert die spätere Abnahme
Eine Aktualisierung des Projektumfangs erfolgt, wenn Änderungsanforderungen genehmigt und Konzepte
vom Auftraggeber abgenommen werden, die eine neue, detailliertere Basis für die Abnahme schaffen.
Der abgestimmte Projektumfang dient auch der Unterscheidung zwischen Fehler und Änderungsanforderung (Change Request). Ein Change Request ist durch den ursprünglichen Projektumfang nicht abgedeckt.
→ Für Großprojekte existiert zu Beginn meistens keine vollständige, konsistente, detaillierte Spezifikation
der Anforderungen. Daher ist die Erarbeitung und Dokumentation des Projektumfangs genauso wie die darauf basierende initiale Aufwandsschätzung und Planung einem zyklischen Detaillierungsprozess unterworfen (siehe Kapitel Projektplanung).
Zyklische Detaillierung der Anforderungen
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
142
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
→ In Großprojekten der öffentlichen Verwaltung sind das Projektziel oder die dem Projekt zu Grunde liegenden übergeordneten Ziele (z.B. politische Agenda) oft wenig konkret bzw. nur schwer quantifizierbar
(siehe Kapitel Festlegung/Überprüfung der Projektrahmenbedingungen). Daher können Änderungsanforderungen nur selten exakt gegen den ursprünglichen Projektauftrag gemessen werden. Umso bedeutsamer ist
vor diesem Hintergrund eine sukzessive Detaillierung des Projektumfangs.
Sukzessive Detaillierung des Projektumfangs
Projektumfang vollständig auf Teilprojekte aufteilen
Die Umsetzung der im Projektumfang definierten Ziele, Aufgaben und Ergebnisse erfordert eine Strukturie rung des Gesamtumfangs und eine Aufteilung auf planbare Teile. Beides erfolgt im Projektstrukturplan,
der eine vollständige, hierarchische und überlappungsfreie Zerlegung des Projekts in Planungssegmente und
Arbeitspakete vorsieht.
→ Im Großprojekt erfolgt diese Strukturierung in mehreren Schritten. Zunächst werden die Inhalte voll ständig auf Teilprojekte aufgeteilt, an die jeweils die weitere Strukturierung und Aufteilung in ihrem Verantwortungsbereich delegiert wird. Dies geschieht im Rahmen des Teilprojektschnitts (siehe Kapitel Festlegung/Überprüfung der Projektorganisation).
Der Teilprojektschnitt legt durch die Minimierung der fachlichen und technischen Abhängigkeiten ein
wichtiges Fundament für ein effizientes Änderungsmanagement. Bei einem ungünstigen Schnitt erhöht sich
die Wahrscheinlichkeit, dass sich Änderungen auf alle Teilprojekte auswirken.
Richtige Teilprojektschnitte stellen einfache Änderungsprozesse sicher
Änderungsanforderungen steuern
Änderungsanforderungen, die sich im Projektverlauf ergeben, werden über das festgelegte CR-Verfahren bearbeitet. Jede Änderungsanforderung wird priorisiert. Bei Bedarf wird eine detaillierte Analyse durchgeführt.
Die Analyse liefert alle Informationen für eine vollständige Kosten-Risiken-Nutzen-Analyse der Änderungsanforderung. Lässt sich eine Anforderung nicht mit den Projektrahmenbedingungen vereinbaren, so wird sie
abgelehnt oder an den Auftraggeber eskaliert.
Genehmigte Änderungsanforderungen werden zur Umsetzung im Projekt beauftragt (siehe nachfolgenden
Abschnitt, “Änderungen im Projekt durchführen“).
→ In der öffentlichen Verwaltung gehen interne Personalkosten bei der Kosten-Nutzen-Analyse oft mit weniger Gewicht als haushaltswirksame/externe Kosten in die Bewertung ein, da interne Kosten als Fixkosten
betrachtet werden, die unabhängig vom Projekt anfallen. In die Bewertung der Vorteilhaftigkeit sollte dann
aber zumindest das Risiko einer Änderung eingehen – durch zunehmende Berücksichtigung von Änderungsanforderungen kann die Gesamtkomplexität des Projekts schleichend steigen.
Änderungen erhöhen nicht nur die Kosten sondern auch die Komplexität des Projekts
Änderungsanforderungen können nicht beliebig spät im Projekt (bzw. in einer Inbetriebnahmestufe des Projekts) berücksichtigt werden. Erforderlich ist daher die Festlegung eines Termins, ab dem keine Änderung
mehr ohne Auswirkungen auf die Planung aufgenommen werden kann („Feature Freeze“-Termin oder
„Frozen Zone“). Für die Kommunikation an potenzielle Initiatoren von Änderungsanforderungen ist es wichtig, dass die Auswirkungen auf die Planung konkret benannt werden.
→ In Großprojekten kann der Feature-Freeze-Termin je Teilprojekt festgelegt werden. Besser ist jedoch
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.2 Anforderungs- und Änderungsmanagement
143
eine Festlegung für das Gesamtprojekt pro Release. Dies erleichtert die Kommunikation des Termins und
ermöglicht eine stabile Gesamtplanung.
Feature Freezes auf Gesamtprojektebene festlegen
Änderungen im Projekt durchführen
Änderungen, die im Projekt umgesetzt werden müssen, können verschiedene Ursachen haben:
●
Änderungen des Projektumfangs durch abgestimmte und genehmigte Änderungsanforderungen
●
Änderungen im Rahmen des Projektumfangs, die sich aus der normalen Projektarbeit ergeben, z.B.
●
Änderungen auf Grund von Maßnahmen aus den verschiedenen Projektmanagement-Disziplinen
(Berücksichtigung risikominimierender Maßnahmen, Änderung von Ergebnissen und Prozessen
auf Grund von Erkenntnissen aus dem Qualitätsmanagement, Änderungen auf Grund von steuernden Maßnahmen aus Planung und Controlling etc.)
●
Fachliche oder technische Änderungen auf Grund von Lösungsdetaillierung oder der Ergebnisse
eines Proof of Concept.
Das Änderungsmanagement sorgt dafür, dass Änderungen konsistent in alle Projektprozesse und -ergebnisse
einfließen.
Die vollständigen Auswirkungen einer Änderung sind genau zu prüfen und deren Umsetzung auf dieser Basis zu planen. Die Änderung muss dabei nicht nur in der Lösung selbst berücksichtigt werden, sondern auch
in alle Projektprozesse einfließen, beispielsweise in das Qualitäts-, Risiko- oder Kommunikationsmanage ment.
→ In Großprojekten ist die vollständige Integration von Änderungen in alle relevanten Planungsdokumente ebenso entscheidend wie die Kommunikation an sämtliche Projektbeteiligten und Mitarbeiter. Geschieht dies nicht, besteht auf Grund der Komplexität und der Anzahl der Änderungen die Gefahr, dass Än derungen ganz oder teilweise nicht berücksichtigt werden (z.B. in den Schulungsunterlagen). Die Prüfung
der Auswirkungen von Änderungen erfolgt anhand der zuvor erstellten Checkliste.
Änderungen schriftlich dokumentieren und verteilen
Änderungen sind bei Bedarf auch außerhalb der eigentlichen Projektorganisation, beispielsweise an den Auf traggeber oder weitere betroffene Organisationseinheiten, zu kommunizieren (siehe Kapitel Qualitätsmanagement).
Aus dem CR-Verfahren resultierende genehmigte Änderungen werden insbesondere im abgestimmten Projektumfang dokumentiert, der unter anderem die in der Abnahme zu berücksichtigenden Ergebnisse beschreibt.
Abnahme durchführen
→ In Großprojekten ist die Abnahme von Ergebnissen wegen ihres Umfangs langfristig vorzubereiten.
Dabei sind sowohl technische als auch organisatorische bzw. formale Voraussetzungen zu schaffen.
Abnahmeprozess ist zeitintensiv
Vorbereitung der Abnahme
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
144
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Zu den technischen Voraussetzungen gehören z.B. die Vorbereitung und Reservierung einer Abnahmetestumgebung, die Erarbeitung von Testfällen und die Erzeugung oder Bereitstellung von Testdaten. Für die Abnahmetestumgebung ist genau festzulegen, wie realitätsnah/produktionsnah diese ist. Sind die Abweichungen
zur späteren Produktionsumgebung zu groß, können nach der Inbetriebnahme Probleme auftreten. Zur Vor bereitung gehört ferner die exakte Definition der Ergebniskonfiguration (welche Versionen der Ergebnisse
relevant sind, für die die Abnahme durchgeführt wird).
Zu den organisatorischen Voraussetzungen gehört die Erstellung der Abnahmeplanung, insbesondere die Planung der für die Abnahme notwendigen Aufgaben, der beteiligten Mitarbeiter sowie des Abnahmezeitraums,
der mit der Bereitstellung der Ergebnisse zur Abnahme beginnt. In die Planung ist auch die vertragsrechtli che Abnahme aufzunehmen, die das frühzeitige Einbinden der hieran beteiligten Stellen erfordert (z.B. Einkauf).
Im Abnahmetest ist sicherzustellen, dass tatsächlich gegen die vereinbarten Anforderungen getestet wird. Die
im Projektumfang festgelegten Anforderungen sind detailliert an die Abnahmetester zu kommunizieren.
Freie Tests ohne Kenntnis der Abnahmegrundlage sind zu verhindern bzw. einzudämmen, da die Effizienz
des Abnahmeprozesses ansonsten durch permanente Diskussionen über den abgestimmten Umfang des Projekts („CR-Diskussionen“) erheblich reduziert wird.
→ In der öffentlichen Verwaltung sollte für die Abnahme ausreichend viel Zeit verwendet werden, sofern
dadurch für den Auftraggeber keine Mehrkosten entstehen oder kein gesetzlich vorgeschriebener Einführungstermin überschritten wird. Der Abnahmezeitraum sollte zu Beginn zwischen Auftraggeber und Auf tragnehmer abgestimmt sein. Er ist in Konstellationen mit externen Auftragnehmern vertraglich vereinbart.
Abnahmezeitraum frühzeitig festlegen
→ Großprojekte erzeugen komplexe Ergebnisse mit vielen Teilergebnissen und sehen eine Lieferung/Inbetriebnahme in Stufen vor. Die Planung der Abnahme kann dies nachvollziehen, indem (zeitversetzte) Teilabnahmen für Teilergebnisse oder Stufen vorgesehen werden. Mit der Abnahme des letzten
Teilergebnisses/der letzten Stufe erfolgt schließlich die Gesamtabnahme, bei der alle Abnahmekriterien für
das Gesamtsystem erfüllt sein müssen. Sinnvoll ist die Abstimmung (bzw. vertragliche Vereinbarung)
gestaffelter Bereitstellung zur Abnahme (BzA)- und Abnahmetermine zwischen Auftraggeber und (externem) Auftragnehmer. Um einen externen Auftragnehmer auf den Erfolg des Gesamtsystems zu verpflichten, ist die vertragliche Vereinbarung einer Gewährleistungspflicht sinnvoll, die unabhängig von vorherigen
Teilabnahmen erst mit der erfolgten Gesamtabnahme beginnt. An diese kann im Vertrag auch eine größere
Schlusszahlung gekoppelt werden.
Stufenweise Inbetriebnahme vereinfacht Abnahmeprozess und sichert Projekterfolg langfristig
Durchführen des Abnahmetests
Während der Abnahmephase sind die gefundenen Fehler an den Auftragnehmer zu melden, der diese behebt
und korrigierte Ergebnisversionen zurückliefert.
→ In Großprojekten wird normalerweise eine erhebliche Anzahl an Defekten gemeldet, die nicht mehr einfach an die Projektmitarbeiter zur Behebung weitergeleitet werden können. Es ist vielmehr ein Fehlermanagementprozess aufzusetzen, der die Fehlereinordnung und -behebung in einen geordneten Prozess
bringt:
●
Die Änderungssteuerungsgruppe stuft die gefundenen Defekte in die Kategorien Fehler und Ände rungsanforderung ein und legt die Fehlerklasse fest.
●
Die Einordnung der Fehler erfolgt in einem iterativen Prozess, der unter Umständen auch weiter rei-
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.2 Anforderungs- und Änderungsmanagement
145
chende Analysen und Abstimmungen mit weiteren Betroffenen durchläuft, bis eine endgültige Einschätzung möglich ist.
●
Für das Fehlermanagement ist ein Statusmodell sinnvoll, das neben dem Endzustand „behoben“ auch
eine Zurückweisung eines gemeldeten Fehlers oder die Umwandlung in eine Änderungsanforderung
zulässt.
●
Die Verwaltung der Fehler erfordert die Nutzung eines Werkzeugs. Normalerweise wird hier das gleiche Werkzeug verwendet wie bereits zur Verwaltung von Änderungsanforderungen während der Projektlaufzeit.
●
Zur Voraussage, ob die Abnahme innerhalb des festgelegten Zeitraums erfolgreich verlaufen wird, wer den Trendanalysen durchgeführt, in denen die Fehlerauftritts- und die Fehlerbehebungsrate sowie die
offenen Fehler einander gegenübergestellt werden. Lassen die Werte nach einem deutlichen Anstieg der
offenen Fehler zu Beginn der Abnahme keine Prognose einer deutlichen Verbesserung zu, ist das ein
Anzeichen für schwerwiegende Probleme.
Organisation des Fehlermanagements durch definierte Prozesse
Für das Fehlermanagement können gegen Ende der Umsetzungsphase sehr gut die Strukturen und Prozesse
verwendet werden, die auch später in der Nutzerbetreuung zum Einsatz kommen.
7.2.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Anforderungs- und
Änderungsmanagement erkennen?
Ein gutes Anforderungs- und Änderungsmanagement lässt sich mit Hilfe qualitativer und quantitativer Messgrößen erkennen.
Als qualitative Messgrößen sind beispielsweise folgende Prüffragen möglich:
●
Ist der Projektumfang auch für fachliche Laien stringent und nachvollziehbar dargestellt, z.B. in Form einer Excel-Tabelle?
●
Sind die Anforderungen so genau dokumentiert, dass ihre Erfüllung ohne Weiteres geprüft werden kann?
●
Ist der CR-Prozess klar umrissen (mit verbindlichen Formularen und Entscheidungsregeln)?
Als quantitative Messgrößen sind folgende Kennzahlen denkbar:
●
Anzahl unveränderter Anforderungen über Zeit vs. Gesamtzahl der Anforderungen
●
Anzahl der CRs, Budget für CRs
●
Anteil des Budgets für CRs vs. Gesamtbudget.
7.2.6 Grundlegende und weiterführende Literatur
●
Johannes Siedersleben (Herausgeber): „Softwaretechnik – Praxiswissen für Softwareingenieure“, Hanser
Verlag 2003.
7.3 Qualitätsmanagement
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
146
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
7.3.1 Ziele und Rahmenbedingungen: Was soll mit dem Qualitätsmanagement erreicht
werden?
Das Qualitätsmanagement hat im Gesamtprojekt die Hauptaufgabe, die Erfolgsfaktoren „Angemessene Methoden, Verfahren und Werkzeuge" sowie „Standardisierte, bewährte Technologien" zu sichern. Sie
sind damit auch die maßgeblichen Grundlagen bei der Festlegung von Kriterien für das Qualitätsmanagement. Dessen Ziel ist, (1) die Qualität der Projektergebnisse und -prozesse sicherzustellen und (2) Qualitäts standards in der Gesamtprojektorganisation durchzusetzen.
(1) Sicherstellung der Qualität der Projektergebnisse und -prozesse
Das Qualitätsmanagement sorgt dafür, dass die vom Projekt zu liefernden Ergebnisse den Qualitätszielen ge nügen, die vom Auftraggeber gefordert bzw. zu Projektbeginn definiert und abgestimmt werden. Ein wesent liches, vom Qualitätsmanagement zu detaillierendes Qualitätskriterium ist die Nutzung standardisierter, be währter Technologien.
Darüber hinaus sorgt das Qualitätsmanagement für die erforderliche Qualität der Projektprozesse, die zur Er stellung der Ergebnisse und zur Einhaltung der Projektrahmenbedingungen benötigt werden. Dazu wird insbesondere auf angemessene Methoden, Verfahren und Werkzeuge geachtet.
(2) Durchsetzen von Qualitätsstandards in Gesamtprojektorganisation
In großen Projekten mit komplexen Projektstrukturen sorgt das Qualitätsmanagement dafür, dass die für Ergebnisse und Prozesse festgelegten Qualitätsstandards von allen Mitarbeitern und Teilprojekten über alle beteiligten Organisationseinheiten und Firmen eingehalten werden.
7.3.2 Rollen und Gremien: Wer macht was im Qualitätsmanagement?
Folgende Rollen sind für das Qualitätsmanagement relevant:
Gesamtprojektleiter
Trägt Gesamtverantwortung für die Projektergebnisse und -prozesse, damit auch für die
Qualität
● Sorgt für die Einplanung der QS-Maßnahmen
● Delegiert Qualitätsaufgaben an untere Ebenen des Projekts
● Organisiert das Qualitätsmanagement im Projekt (legt Verantwortlichkeiten und Rollen
fest)
● Berücksichtigt die aus dem Qualitätsmanagement definierten Maßnahmen in der
Planung
QS-Verantwortlicher
●
●
●
Erstellt das QS-Handbuch
Erstellt die QS-Planung
Stellt sicher, dass das QS-Handbuch im Projekt berücksichtigt wird und Maßnahmen
aus der QS-Planung durchgeführt werden
Teilprojekt-QSVerantwortlicher
●
Ist verantwortlich für das Qualitätsmanagement im Teilprojekt
Projektmitarbeiter (EN-703) ●
●
Testmanager/-team
●
Führen die in der QS-Planung definierten Aufgaben durch
Erstellen die QS-Nachweise
Sorgen in Abstimmung mit dem QS-Verantwortlichen für Konzeption, Planung,
Vorbereitung und Durchführung der Tests, die Bestandteil des QS-Handbuchs und der
QS-Planung sind
Tabelle 14: Rollen und Verantwortlichkeiten im Qualitätsmanagement
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.3 Qualitätsmanagement
147
7.3.3 Ergebnisse: Welche Dokumente sollen erstellt werden?
Wesentliche Ergebnisse des Qualitätsmanagements sind:
Das QS-Handbuch beschreibt Organisation, Prozesse und Werkzeuge des Qualitätsmanagements im Projekt, identifiziert die vom Qualitätsmanagement zu betrachtenden Projektergebnisse und -prozesse (Betrachtungsgegenstände), definiert Qualitätsziele und -kriterien sowie die je Betrachtungsgegenstand durchzuführenden QS-Maßnahmen.
Der QS-Plan enthält die aus dem QS-Handbuch abgeleiteten konkreten Aufgaben, Termine und verantwortlichen Mitarbeiter für die QS-Maßnahmen.
Die QS-Nachweisakte enthält die Dokumentation zu Status und Ergebnissen aller durchgeführten QS-Maßnahmen (insbesondere QS-Berichte, Prüfspezifikationen und Prüfprotokolle)
7.3.4 Prozesse: Wie geht das Qualitätsmanagement vor?
Die Prozesse im Qualitätsmanagement – initiale und laufende Prozesse – sind in der folgenden Abbildung
zusammengefasst:
Abbildung 65: Prozesse des Qualitätsmanagements
Organisation, Prozesse und Rahmenbedingungen für das Qualitätsmanagement festlegen
Rollen und Verantwortlichkeiten des Qualitätsmanagements festlegen
Die am Qualitätsmanagement beteiligten Rollen und Verantwortlichkeiten werden gemäß Kapitel Rollen und
Gremien: Wer macht was im Qualitätsmanagement? festgelegt.
→ In Großprojekten ist eine auf allen Ebenen und in allen Teilprojekten verankerte durchgängige Organisation zu installieren. Den Teilprojekt-QS-Verantwortlichen obliegt das Qualitätsmanagement für Ergebnisse und Prozesse ihrer jeweiligen Verantwortungsbereiche. Die verantwortlichen Mitarbeiter auf höheren
Ebenen (insbesondere der QS-Verantwortliche des Gesamtprojekts) stellt die Einheitlichkeit der Vorgaben
und Prozesse über die einzelnen Teilprojekte hinweg sicher.
Verantwortlichkeiten und Aufgaben des QM auf verschiedenen Ebenen verankern
→ In Großprojekten wird eine Qualitätsmanagement-Organisation auch auf Auftraggeberseite installiert, die sich sowohl um QS-Aktivitäten auf Auftraggeberseite kümmert (z.B. Abnahmen von Konzepten
und Software) als auch um die Abstimmung der QS-Ziele und -Kriterien mit dem Auftragnehmer.
QM existiert spiegelbildlich bei AG und AN
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
148
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
→ Großprojekte befinden sich typischerweise im Fokus der Aufmerksamkeit der Qualitätsmanager in den
verantwortlichen Organisationseinheiten. Zu Beginn des Projekts ist eine genaue Abstimmung erforderlich,
welche Vorgaben sich aus dem Qualitätsmanagement der Organisationseinheit für das Projekt ergeben
und wie Zuständigkeiten und Verantwortung zwischen Qualitätsmanagement des Projekts und Qualitätsmanagement der Organisationseinheit abzugrenzen sind. Ziel sind verbindliche Rahmenbedingungen und ein
definierter Handlungsspielraum zur Erreichung der Qualitätsziele im Projekt. Typischerweise finden im
Laufe des Projekts Audits durch das Qualitätsmanagement der Organisationseinheit statt, die die Einhaltung
der abgestimmten Vorgaben prüfen.
Klare Abgrenzung des QM zwischen Organisationseinheiten
Prozesse des Qualitätsmanagements definieren
Die für das Qualitätsmanagement notwendigen Prozesse werden bestimmt. Das Zusammenspiel der Planung
der QS-Maßnahmen mit der Projektplanung wird definiert. Die Integration der Qualitätsberichterstattung in
die Statusberichte des Gesamtprojekts wird festgelegt.
→ Im Großprojekt wird zusätzlich festgelegt, wie die Qualitätsberichterstattung innerhalb der Qualitätsmanagement-Organisation, das heißt von Ebene zu Ebene des Projekts organisiert ist, so dass auf
oberster Ebene eine konsolidierte, verdichtete Einschätzung der Gesamtqualität möglich ist. Wichtig ist die
genaue Definition messbarer Kriterien, die für die Einordnung der Qualität in den unterschiedlichen Teil projekten gelten (Definition von „Ampelfarben“).
Berichterstattung anhand von messbaren Kriterien
Rahmenbedingungen für das Qualitätsmanagement
Wichtig ist die Unabhängigkeit des Qualitätsmanagements. Der QS-Verantwortliche hat die Möglichkeit,
Themen zu eskalieren, falls mit der Projektleitung keine Einigung erzielt werden kann. Die Eskalation erfolgt entweder direkt an den für das Projekt verantwortlichen Mitarbeiter in der Linienorganisation (LA-Vertreter) oder an den Qualitätsmanager der zuständigen Organisationseinheit.
→ Im Großprojekt erfolgt die Eskalation jeweils auf die nächsthöhere Ebene des Projekts. Dabei kann an
die verantwortlichen Mitarbeiter der Projektleitung (Projektmanager und Gesamtprojektleiter) und/oder an
die verantwortlichen Mitarbeiter der Qualitätsmanagement-Organisation (QS-Verantwortlicher) eskaliert
werden.
Eskalation nach oben erfolgt schrittweise
Ein wichtiger Faktor für die Erreichung der Qualitätsziele des Projekts ist die Aktivierung des Qualitätsbewusstseins aller Projektmitarbeiter. Jeder Mitarbeiter muss sich seiner persönlichen Verantwortung und
seines Beitrags zur Erreichung der Qualität bewusst sein. Dazu wird im Projekt regelmäßig über Aktivitäten
und Bedeutung des Qualitätsmanagements und über konkrete, messbare Qualitätsziele kommuniziert. Hilfreich ist die Verankerung von Qualitätszielen in Zielvereinbarungen der verantwortlichen Mitarbeiter. Neben
(Teilprojekt-)QS-Verantwortlichen sind das insbesondere Gesamtprojektleiter, Projektmanager und Teilprojektleiter.
Qualitätsziele und -kriterien festlegen
Aus den Vorgaben für das Projekt sind die im Projekt zu erreichenden Qualitätsziele abzuleiten. Nur selten
sind den Vorgaben konkrete, messbare Qualitätsziele direkt zu entnehmen; vielmehr sind diese Ziele implizit
auf sehr abstraktem Niveau in den Vorgaben enthalten.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.3 Qualitätsmanagement
149
Die Qualitätsziele sind für alle Dimensionen der Vorgaben zu formulieren (Aufwand, Budget, Termine, Inhalt, Nutzen) und werden im QS-Handbuch dokumentiert. Zu jedem Qualitätsziel werden messbare Qualitätskriterien angegeben, die es erlauben, die jeweilige Zielerreichung zu ermitteln.
Wichtige Qualitätsziele ergeben sich aus den Erfolgsfaktoren „Angemessene Methoden, Verfahren und
Werkzeuge“ sowie „Standardisierte, bewährte Technologien“. Für alle Projektprozesse und -ergebnisse sollte
genau hinterfragt werden, welche Ziele zu setzen sind, damit die Erfolgsfaktoren erfüllt werden können.
Sind die Qualitätsziele und -kriterien nicht bereits in den Vorgaben für das Projekt verankert, müssen sie zwi schen Auftraggeber und Auftragnehmer abgestimmt werden. Eine Aufnahme in die Projektcharta ist sinnvoll,
so dass im Verlauf des Projekts immer wieder darauf Bezug genommen werden kann.
Betrachtungsgegenstände und QS-Maßnahmen identifizieren
Aus dem definierten Projektumfang (siehe Kapitel Anforderungs- und Änderungsmanagement) ergeben sich
die Betrachtungsgegenstände des Qualitätsmanagements. Es handelt sich sowohl um die vom Projekt zu er stellenden Ergebnisse (Konzepte, Software, Hardware etc.) als auch um die Prozesse, die zur Erstellung der
Ergebnisse aufgesetzt werden. Dazu zählen auch die in diesem Dokument beschriebenen Prozesse der einzelnen Projektmanagement-Disziplinen.
Für die verschiedenen Arten von Betrachtungsgegenständen (z.B. Ergebnistypen wie Softwaremodul und
Spezifikationsdokument oder Prozesstypen wie Stakeholder-Analyse und Risikoidentifikation) werden QSMaßnahmen definiert. Diese ergeben sich aus den Qualitätszielen, die auf die Betrachtungsgegenstände aufgeschlüsselt und anschließend konkretisiert werden.
Es gibt konstruktive und analytische QS-Maßnahmen:
●
Konstruktive QS-Maßnahmen sorgen dafür, dass die Qualitätsziele von Beginn an bei der Erstellung
der Ergebnisse oder dem Aufsetzen der Prozesse berücksichtigt werden. Die Qualität wird sozusagen
„hineinkonstruiert“. Zu diesen Maßnahmen zählt insbesondere die Beachtung angemessener Verfahren,
Methoden und Werkzeuge. Was hier versäumt wird, lässt sich später (bei den analytischen Maßnahmen
oder gar erst im Betrieb) oft nicht mehr oder nur mit sehr hohem Aufwand nachholen. Zu den konstrukti ven Maßnahmen gehört auch die Beachtung der in diesem Dokument enthaltenen Hinweise zum
GroßPM.
●
Analytische QS-Maßnahmen dienen dazu, die tatsächlich erreichte Qualität zu prüfen. Diese Maßnahmen decken nicht nur mögliche Qualitätsmängel auf, sondern dokumentieren auch die Erreichung der
definierten Qualitätsziele. Analytische Maßnahmen werden nicht nur am Ende einer Phase zur Überprüfung des Ergebnisses eingesetzt, sondern auch zur Prüfung von Zwischenergebnissen. Dies verhindert,
dass sich anfängliche Fehler im System ausbreiten.
→ Im Großprojekt sind Ergebnisse und Prozesse den Teilprojekten und Rollen des Projekts zugeordnet
(z.B. wird beim Teilprojektschnitt festgelegt, welche Ergebnisse das Teilprojekt erzeugen soll). Die hier
identifizierten Betrachtungsgegenstände und QS-Maßnahmen müssen daher ebenfalls einzelnen Teilprojekten und Rollen zugeordnet werden.
Verantwortlichkeiten für QS-Maßnahmen festlegen
→ Beträchtlichen Umfang und hohe Komplexität haben in Großprojekten die Testaktivitäten, die zu den
analytischen QS-Maßnahmen zählen. Die Tests müssen langfristig vorbereitet werden. Konzeption, Planung, Vorbereitung und Durchführung der Tests sollte daher in der Verantwortung einer separaten Projek trolle Testmanager liegen. Er wird durch ein Testteam unterstützt.
Test werden von einer separaten Rolle gemanagt
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
150
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Checklisten und Vorgaben erarbeiten
Vorgaben und Checklisten konkretisieren die Qualitätsziele, -kriterien und -maßnahmen.
Vorgaben dienen im Wesentlichen dazu, die konstruktiven QS-Maßnahmen zu unterstützen. Beispielsweise
werden Vorlagen für Dokumenttypen erstellt, die eine vollständige inhaltliche Abdeckung gewährleisten und
zudem eine geeignete Strukturierung vorgeben.
Checklisten unterstützen sowohl konstruktive als auch analytische QS-Maßnahmen. Beispielsweise sorgt
eine Checkliste im Anforderungs- und Änderungsmanagement bereits vor der Umsetzung einer Änderung
dafür, dass sie in allen relevanten Prozessen und Ergebnissen berücksichtigt wird. Analytischen Zwecken
dienen z.B. Checklisten, die beim Review von Dokumenten die Prüfung aller für das Dokument vereinbarten
Qualitätsziele und -kriterien sicherstellen.
→ Im Großprojekt sorgen Vorgaben und Checklisten auch für die Sicherstellung eines einheitlichen Qualitätslevels im Gesamtprojekt, indem deren Anwendung für alle Teilprojekte über Organisationseinheitsund Firmengrenzen hinweg verbindlich vereinbart wird.
Festlegen gesamtprojektübergreifender Qualitätsniveaus
QS-Planung aufstellen und aktualisieren
Die im QS-Konzept enthaltenen Maßnahmen werden schließlich konkret für jeden einzelnen Betrachtungsgegenstand geplant. Die Planung enthält alle Aktivitäten, die verantwortlichen Mitarbeiter und die Termine.
→ Im Großprojekt erfolgt die QS-Planung detailliert in den Teilprojekten und obliegt den verantwortlichen Rollen. Wie bei der Projektplanung ergibt sich der Gesamt-QS-Plan durch Verdichtung und Konsolidierung aus den Detailplänen.
Konsolidierung der QS-Planung von den Teilprojekten aufwärts
Im Laufe des Projekts wird die QS-Planung zur Anpassung an notwendige Änderungen aktualisiert. Solche
Änderungen können sich durch neue Anforderungen (und damit neue Betrachtungsgegenstände) ergeben,
aber auch durch das Verfehlen von Qualitätszielen, das neue QS-Maßnahmen erfordert.
Generell wird die Planung – wie festgelegt – mit der Projektplanung abgestimmt oder in die Projektplanung
integriert.
QS-Maßnahmen durchführen
Die geplanten QS-Maßnahmen werden von den in der QS-Planung vorgesehenen Mitarbeitern durchgeführt.
Durchführung und Ergebnis der QS-Maßnahmen werden in der QS-Nachweisakte dokumentiert. Die QSNachweisführung enthält zum einen die konkreten Ergebnisse einzelner QS-Maßnahmen (z.B. die Review-Anmerkungen, die ein Prüfer erstellt hat). Zum andern gibt die QS-Nachweisakte Auskunft über den Status
der QS-Maßnahmen (offen, in Arbeit oder abgeschlossen).
Erfolg des Qualitätsmanagements prüfen und Maßnahmen aufsetzen
Die erreichte Qualität wird regelmäßig geprüft. Entspricht sie nicht den Qualitätszielen, müssen weitere
Maßnahmen aufgesetzt werden, um die Erreichung der vorgegebenen Qualitätsziele sicherzustellen. Diese
Maßnahmen werden mit den verantwortlichen Mitarbeitern abgestimmt und führen normalerweise zur Anpassung von QS-Planung und Projektplan.
→ Im Großprojekt liefert die QS-Nachweisführung wichtige Hinweise für die Prognose der Erreichung
der Projektziele insgesamt. Dazu werden die Details aus der QS-Nachweisakte auf Gesamtprojektebene
verdichtet. Beispielsweise liefern Anzahl und Schwere der im Test gefundenen Fehler einen Hinweis auf
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.3 Qualitätsmanagement
151
den noch benötigten Restaufwand.
QS-Nachweisführung als Unterstützung zur Gesamtprojektprognose
7.3.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Qualitätsmanagement
erkennen?
Ein Auftraggeber kann ein erfolgreiches Qualitätsmanagement an qualitativen und quantitativen Kriterien
messen.
Als qualitative Messgrößen sind beispielsweise folgende Prüffragen möglich:
●
Sind alle vertraglich vereinbarten Ergebnisse und alle Projektprozesse durch das Qualitätsmanagement
erfasst?
●
Existieren zu wichtigen Prozessen und Ergebnissen Checklisten und Vorlagen?
●
Sind sowohl konstruktive als auch analytische QS-Maßnahmen geplant?
●
Ist das Qualitätsmanagement auf allen Ebenen des Projekts und bei Auftragnehmer und Auftraggeber
durch Verantwortliche verankert?
Als quantitative Messgrößen sind folgende Kennzahlen denkbar:
●
Wie hoch ist die Anzahl der im Projekt geplanten Audits im Vergleich zur Anzahl der Teilprojekte (je
Teilprojekt mindestens beim Aufsetzen und während der Laufzeit sinnvoll)?
●
Wie hoch ist die Anzahl der gefundenen schweren Defekte durch geplante QS-Maßnahmen?
●
Wie hoch ist Anzahl der gefundenen Defekte, die nicht durch geplante QS-Maßnahmen entdeckt wurden?
7.3.6 Grundlegende und weiterführende Literatur
●
Johannes Siedersleben (Herausgeber): „Softwaretechnik – Praxiswissen für Softwareingenieure“, Hanser
Verlag 2003
●
Helmut Balzert (Herausgeber): „Lehrbuch der Softwaretechnik“, Band 2, Spektrum Akademischer Ver lag 1997
7.4 Risikomanagement
7.4.1 Ziele und Rahmenbedingungen: Was soll mit dem Risikomanagement erreicht werden?
Grundsätzlich muss es darum gehen, im Projektrahmen die erforderlichen organisatorischen Veränderungen
zu erreichen. Damit der Veränderungsprozess erfolgreich ist, bedarf es eines genauen Verständnisses des
Ziels der Veränderung, des Ausgangspunkts sowie des möglichen Wegs zwischen beiden. Alle drei Elemente
dieses Prozesses sind im Projektverlauf vielfältigen Veränderungen ausgesetzt: Teils wird dadurch der ange strebte Wandel selbst erschwert; teils sind neue Wege erforderlich, um das (modifizierte) Ziel doch noch zu
erreichen. Das Projekt muss so angelegt sein, dass Auswirkungen solcher Änderungen bewertet und ange messene Gegenmaßnahmen eingeleitet werden können. Unerwünschte Folgewirkungen kann das Projekt
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
152
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
durch frühzeitiges Gegensteuern sogar gänzlich verhindern, z.B. Probleme, die aus einer mangelnden Einbin dung von Stakeholdern erwachsen.
Erfolgreiche Projekte operieren mit Hilfe eines Arsenals angemessener, erprobter und umfassender Methoden und Werkzeuge. Eines davon ist das Risikomanagement: Im Prinzip sollte sich das Risikomanagement
als „Radar“ der Projektleitung für unvorhergesehene Entwicklungen verstehen (siehe Abbildung 66).
Abbildung 66: Risikomanagement als „Radar“ der Projektleitung
Damit stellen sich für das Risikomanagement die nachstehenden operativen Ziele – wenn es seinen Beitrag
zum Projekterfolg leisten will:
●
Risiken umfassend erkennen, das heißt keine Dimension übersehen
●
Risiken angemessen bewerten, das heißt große Risiken nicht kleinmachen, kleine Risiken nicht überbetonen. Ziel ist, die Management-Aufmerksamkeit über alle Führungsebenen auf die Kernrisiken zu fo kussieren.
●
Balance zwischen Analyse und Handeln finden: Zum einen gilt es, Risiken zu analysieren sowie Projektleitung und Auftraggeber auf sie hinzuweisen, zum andern muss sichergestellt sein, dass Gegenmaßnahmen ergriffen werden („Lösungs- statt Problemorientierung“).
●
Risiken vorausschauend minimieren: Risiken sind nicht exogen vorgegeben. Vielmehr muss es darum
gehen, durch aktives Gegensteuern Auswirkungen und Eintrittswahrscheinlichkeiten zu reduzieren.
●
Übersichtliche Kommunikation der Risiken an die Auftraggeber („keine Überraschungen“) sicherstellen.
7.4.2 Rollen und Gremien: Wer macht was im Risikomanagement?
Für das Risikomanagement im Projekt sind folgende Funktionsträger verantwortlich:
Projektleiter
Ist immer auch der oberste Risikomanager des Projekts.
Hat insbesondere die Aufgabe, für die Durchführung der projektinternen Gegenmaßnahmen
zu sorgen sowie dafür die notwendige Unterstützung von den LA-Mitgliedern und den
anderen Stakeholdern einzufordern
● Kommuniziert Risiken aktiv an den LA und andere Stakeholder, um Überraschungen zu
vermeiden
● Fordert Unterstützung bei Stakeholdern ein, um Risikoeintritt zu vermeiden oder
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.4 Risikomanagement
153
●
●
●
Auswirkungen zu mindern
Sorgt für die projektinterne Durchführung von Gegenmaßnahmen
Schafft durch Transparenz und offene Kommunikation eine positive Atmosphäre für das
Risikomanagement („Fehlerkultur“)
Ist bereit, seine eigene Leistung im Projekt offen und soweit möglich objektiv
einzuschätzen: Stellt er selbst ein Risiko dar?
Risikomanager
Ist zuständig für die Analyse und Bewertung der Risiken sowie für die Definition und
Verankerung von Gegenmaßnahmen.
Kann auch Berichterstatter an den LA sein, wenn dieser eine weitere Perspektive neben der
des Projektleiters wünscht.
● Definiert Gegenmaßnahmen und Verantwortliche und verankert die Maßnahmen in
deren Aufgabenportfolio
● Erstellt Berichte (Risikostatus) und steht auf Wunsch dem LA als unabhängiger
Berichterstatter zur Verfügung (kann dann auch extern sein oder aus einem Tandem von
intern und extern bestehen) – hierfür benötigt er uneingeschränkten Zugriff auf
Projektmitarbeiter und Projektinformationen/-dokumente.
Administratoren
●
●
●
Sind Mitglieder des PMO
Halten die Durchführung der Gegenmaßnahmen nach
Leisten operative Unterstützung in der Erstellung der Risikoberichte
Teilprojektleiter und Leiter
der Arbeitspakete
●
Sollten dem Risikomanager für eine periodische Risikosichtung und -bewertung zur
Verfügung stehen
Sind für die Durchführung eines Großteils der projektinternen Maßnahmen
verantwortlich
Leisten Beitrag in der Risikoanalyse: Welche Risiken sehen sie aus ihrer Perspektive?
●
●
Tabelle 15: Rollen und Verantwortlichkeiten im Risikomanagement
→ Mag das Risikomanagement in vielen IT-Großprojekten der öffentlichen Verwaltung auch als separate
Funktion etabliert sein, so bleibt es dennoch eine Königsdisziplin des Projektleiters selbst. Auf Grund seines aktiven, risikovermeidenden Charakters ist das Risikomanagement eine wichtige strategische, voraus schauende Aufgabe. Gleichwohl sind für den Erfolg des Risikomanagements häufig Unterstützungsleistungen des LA und anderer Stakeholder nötig, welche im Regelfall nur der Projektleiter effektiv einfordern
kann. Und schließlich muss der Projektleiter eine offene Kommunikationskultur für Risiken schaffen. Dies
fängt bei ihm selbst an: Geht er z.B. offen mit einer Lücke in seinen Kompetenzen um, die ein Risiko dar stellt? Durch die offene Kommunikation stellt der Projektleiter sicher, dass jeder mithilft bei der Vermeidung/Minderung von Risiken, und dass jeder gehört und ernst genommen wird, wenn er auf Risiken hinweist.
Risikomanagement als Königsdisziplin des Projektleiters - es fängt bei ihm selbst an
Gleichzeitig verhindert der Projektleiter die übermäßige Beschäftigung mit kleinen oder extrem unwahrscheinlichen Risiken: Er muss die Balance wahren zwischen Projektoptimismus und Risikomentalität. Gerade in der öffentlichen Verwaltung muss er dies von Beginn an sicherstellen. Er darf gar nicht erst in die Ge fahr geraten, Risiken kleinzureden oder nicht rechtzeitig genug zu kommunizieren.
→ Einen externen Risikomanager, in Ergänzung zum internen Risikomanager, beizuziehen, kann durchaus
sinnvoll sein: Ein Externer kann befreiter auf Probleme schauen, allerdings fehlt ihm in aller Regel die Lö sungskompetenz für organisatorische Fragen. Er kann Risiken nicht managen, da er Maßnahmen nicht anordnen oder durchsetzen kann. Damit ist er eigentlich nur Risikoberichterstatter, einen Externen allein als
Risikomanager einzusetzen, ist mithin nicht zu empfehlen.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
154
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Interner und externer Risikomanager ergänzen sich, einer allein ist nicht sinnvoll
→ Bei IT-Großprojekten in der öffentlichen Verwaltung kommen politische Risiken als besondere Dimensi on hinzu. Zum Management dieser politischen Risiken bedarf es der speziellen Kompetenz und Erfahrung
des Gesamtprojektleiters: Er muss Sachverhalte auf politischer Ebene so darstellen, dass richtiges Handeln
ausgelöst wird. Gleichzeitig muss er die richtige Ansprache ins Projekt hinein beherrschen. Hierfür muss er
sehr gute verbale Kommunikationsfähigkeiten besitzen: Einerseits muss er Risiken offen ansprechen, um
Überraschungen zu vermeiden und Handeln auszulösen. Andererseits darf er nicht als notorischer „Risikowarner“ erscheinen, sondern muss als Problemlöser auftreten.
Risiken müssen durch den GPL offen adressiert und aktiv angegangen werden
→ Projektleiter, die aus der internen Organisation stammen, haben oft nicht die Erfahrung, um auf Entscheiderebene Risiken kraftvoll zu kommunizieren. Diese Aufgabe kann ein externer Projektleiter übernehmen, damit die „Warnrufe“ nicht ungehört verhallen – oder sich lediglich in Vermerken niederschlagen.
Externe sind oft effektivere „Warner"
7.4.3 Ergebnisse: Welche Dokumente sollen erstellt werden?
Wie effektiv das Risikomanagement ist, entscheidet sich weniger in der Erstellung von Ergebnisdokumenten,
als vielmehr in der Definition und Durchsetzung wirksamer Gegenmaßnahmen.
Gleichwohl haben sich zwei Ergebnisdokumente für die Berichterstattung über Risiken methodisch bewährt,
da sie den Fokus auf die Kernrisiken im Projekt lenken:
Risikoliste
Tabellarische Liste aller Risiken mit den folgenden Informationen (als Beispiel siehe Abbildung 67):
●
Beschreibung der Risiken
●
Beschreibung der Auswirkungen
●
Bewertung hinsichtlich Eintrittswahrscheinlichkeit
●
Bewertung hinsichtlich Schadensausmaß im Falle des Eintretens
●
Gegenmaßnahmen einschließlich Verantwortliche und Termine.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.4 Risikomanagement
155
Abbildung 67: Risikoliste
Risikomatrix
Diese Matrix mit zwei Dimensionen ermöglicht eine grafische Darstellung aller Risiken der Risikoliste:
Kernrisiken werden dabei besonders hervorgehoben, das heißt Risiken mit hoher Eintrittswahrscheinlichkeit
und resultierendem großem Schaden im Falle des Eintretens.
Ein Beispiel für eine Risikomatrix findet sich in Abbildung 68. Eine alternative Darstellung kann der Projektstatus aus dem Kapitel Statusprüfung der Erfolgsfaktoren sein, der das Projekt gegen die allgemeinen Erfolgsfaktoren von IT-Großprojekten spiegelt (siehe Abbildung 12).
Abbildung 68: Risikomatrix
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
156
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
7.4.4 Prozesse: Wie geht das Risikomanagement vor?
Abbildung 69 zeigt die Prozesse des Risikomanagements:
Abbildung 69: Prozesse des Risikomanagements
Festlegung der Verantwortlichkeiten und Rollen, Reservierung Risikobudget
Um das Risikomanagement als Projektfunktion zu etablieren, sind zunächst die oben beschriebenen Rollen
zu besetzen und die Verantwortlichkeiten zu definieren. Ebenso ist ein hinreichendes Risikobudget vorzuse hen.
→ In Großprojekten der öffentlichen Verwaltung wünscht der LA häufig eine unabhängige Perspektive auf
die Risiken im Projekt. In diesem Falle sollte die Position des Risikomanagers mit einem vom Projektleiter
hinreichend unabhängigen Mitarbeiter besetzt werden. Soll diese Rolle extern vergeben werden, sind zwei
Risikomanager als Tandem empfehlenswert.
Unabhängigkeit des Risikomanagers vom Projektleiter
→ Gerade in IT-Großprojekten der öffentlichen Verwaltung ist das Risikomanagement häufig mit erheblichem Aufwand und großen Kosten verbunden. Diese Kosten sind bereits bei der Projektanbahnung zu be rücksichtigen und in die Budgetschätzung aufzunehmen. Konflikte können hier entstehen, wenn Stakeholder – wie häufig der Fall – nicht bereit sind, Risikokosten bzw. Kosten des Risikomanagements zu budge tieren. Und zwar deshalb, weil sie aus ihrer Sicht das Risikomanagement nicht als wertstiftend wahrnehmen. Die entsprechende Projektkalkulation impliziert dann, dass alle Projektziele stets ohne Umwege er reicht werden – eine unrealistische Annahme.
Kosten des Risikomanagements im Budget verankern
→ In Großprojekten gibt es zum Teil spezielle Risikobudgets. Viel Risiko erfordert entsprechend viel Zeit
bzw. Aufwand für das Managen bzw. für die Erarbeitung von Gegenmaßnahmen; z.B. die Kosten für zu sätzliche Projektmitarbeiter. Falls Budgets für Risiken und Risikomanagement auch auf der Ausgabenseite
trotz aller haushalterischer Schwierigkeiten, die solche Eventualbudgets auslösen, nicht entsprechend berücksichtigt werden, entstehen sofort erhebliche Kosten- und Terminrisiken. Das Projekt läuft Gefahr zu
scheitern, weil kein Handlungsspielraum vorgesehen ist. Besser ist deshalb: Von vorneherein akzeptieren,
dass Projekte einen Risikopuffer benötigen – sowohl für Budget/Aufwand als auch für die Terminpläne!
Risikopuffer fangen Unverhersehbarkeiten ab und sichern den Projekterfolg
→ Bei Bedarf sollte das Projektbudget eines Großprojekts in zwei Teilbudgets untergliedert sein:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.4 Risikomanagement
157
●
Budget 1 für „wertstiftende“ Tätigkeiten, das heißt für unmittelbar abschätzbare Projektkosten
●
Budget 2 für Versicherungs- und Risikoprämien.
Das Budget 2 ist abhängig vom Projekt und wird im Regelfall beim Dienstleister zu führen sein. Diese Auf teilung sollte auch für die LA-Mitglieder transparent sein – eine spätere Abbildung des Budgets in einer ITWiBe muss davon abweichen, da diese keine Risikopuffer vorsieht. Hier ist dann eine Verteilung des Risi kopuffers auf Kostenelemente mit hoher Schwankungswahrscheinlichkeit angebracht – wie z.B. externe
Kosten für Implementierungsleistungen.
Aufteilung des Gesamtbudgets in zwei Teilbudgets
→ Um die LA-Mitglieder von der Notwendigkeit eines Budgets für die Durchführung des Risikomanage ments zu überzeugen, lohnt sich eine Gegenüberstellung: Aufwand für das Risikomanagement vs. mögli cher Schaden bei Risikoeintritt.
Risiken managen ist preiswerter als Schäden beheben
→ Risikomanagementbudgets werden insbesondere für die Abstimmung mit den vielen Stakeholdern eines
Großprojekts benötigt: Bei hohen Risiken steigt dabei der Managementaufwand exponentiell. Risiken, die
mit teilweise nicht ausgesprochenen Agenden der Stakeholder einhergehen (z.B. Bewahrung von Einflussbereichen), müssen identifiziert und gemanagt werden, die Abstimmungen dazu nehmen sehr viel Zeit in
Anspruch. Eine Alternative gibt es allerdings nicht: Denn mangels Zeit oder Budget darauf zu verzichten,
ein Vorgehen abzustimmen, kommt schließlich nicht in Frage. Die Projektergebnisse würden schlichtweg
nicht akzeptiert.
Stakeholder-Alignment sorgt für Projektakzeptanz
Festlegung der Prozesse und Periodizitäten
Das laufende Risikomanagement ist anschließend zu definieren: In welcher Periodizität sollen welche Projektmitarbeiter und Stakeholder zu ihren Risikoeinschätzungen befragt werden? Wie häufig sind welche Berichte an wen zu versenden?
→ Ist eine unabhängige Berichterstattung erwünscht, muss der Prozess auch den direkten Zugang zum LA
regeln. Zum einen soll das Risikomanagement eng mit dem LA zusammenarbeiten, um insbesondere die
zeitnahe und koordinierte Vereinbarung effektiver Gegenmaßnahmen zu ermöglichen. Zum andern muss
die Unabhängigkeit des Risikomanagements gewahrt bleiben.
Festlegung der Prozesse zur Berichterstattung des Risikomanagers
Initiale Durchführung
Mit Durchführungsbeginn endet die Etablierung des Risikomanagements: Risiken werden gesammelt und
bewertet in Bezug auf Eintrittswahrscheinlichkeit und Schadensausmaß. Im Falle des Eintritts sind Gegenmaßnahmen und Verantwortliche zu definieren sowie entsprechende Berichte zu erstellen.
Als Instrument zur schnellen Sammlung von Risiken eignet sich der Fragebogen zur Statusbestimmung aus
Kapitel Statusprüfung der Erfolgsfaktoren.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
158
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Risiken sollten in die Risikolisten nur aufgenommen werden, falls sie nicht mit normalen Projektmanagement-Methoden behandelt werden können. Fehlende Beistellungen sind gewiss ein Risiko, ihre Sicherung ist
jedoch typischerweise Aufgabe des Projektmanagements: Sie sollte allenfalls dann als Risiko extra aufgeführt werden, wenn die Wahrscheinlichkeit eines Ausbleibens besonders hoch ist.
Je größer das objektive Risiko, desto mehr Anforderungen werden an die Kompetenz des Gesamtprojektleiters/Risikomanagers gestellt.
→ In Großprojekten der öffentlichen Verwaltung ist die initiale Risikoliste häufig sehr lang. Um zügig den
Fokus für das Gegensteuern zu schaffen, sollte sich das Projekt auf unterschiedliche Arten von Risiken im
Projektlebenszyklus konzentrieren: In den Frühphasen der Anbahnung und Konzeptionierung sind sicherlich Risiken, die aus einem mangelnden Alignment der Stakeholder erwachsen, als vordringlich zu erach ten. In späteren Projektphasen rücken dann technische Risiken mehr in den Vordergrund. Über den gesamten Projektlebenszyklus sind dagegen Risiken im Projektumfeld im Auge zu behalten, denn sie können jederzeit, z.B. aus veränderten gesetzlichen Rahmenbedingung, erwachsen.
Wechselnder Fokus des Risikomanagements im Verlauf des Projektlebenszyklus
Verankerung in der Projektorganisation sichern
Ziel ist, das Risikomanagement im gesamten Projektteam und auf allen Projektebenen zu verankern. Gefordert ist hier vor allem der Projektleiter. Er muss die Bedeutung des Risikomanagements gegenüber allen Teilprojektleitern und Projektmitarbeitern kontinuierlich demonstrieren. Wie bereits in der Rollenbeschreibung
des Projektleiters beschrieben (siehe oben), muss er projektintern für die Etablierung einer offenen Fehler kultur sorgen und die Kollegen anhalten, einmal vereinbarte Gegenmaßnahmen sorgfältig umzusetzen. Empfehlenswert ist, bei eigenen Maßnahmen mit gutem Beispiel voranzugehen.
Methodisch lässt sich die Verankerung z.B. erreichen, indem man das Risikomanagement zum Standard-A gendapunkt in regelmäßigen Meetings macht, insbesondere im Projektmanagement-Meeting der Führungsebene. Dort wird die Risikoliste durchgegangen und über Risiken (durch die für die Gegenmaßnahmen Verantwortlichen) berichtet. Verpflichtet der Projektleiter die Berichterstattenden (zumeist Teilprojektleiter), zu
jedem Meeting über ein jeweils neues Risiko zu referieren, kann kein Routine-Leerlauf entstehen, zudem
werden die Teilprojektleiter angehalten, sich detailliert mit den Risiken auseinanderzusetzen.
Risikoanalyse und -bewertung
In diesem Schritt findet eine strukturierte periodische Erhebung der Risiken im Projekt statt. Ziel ist, „die
Augen zu öffnen“ für die bestehenden Risiken.
Dazu werden Risikoanalyse und -bewertung beispielsweise in periodischen bilateralen Jours fixes zwischen
Risikomanager und den Teilprojektleitern sowie dem Projektleiter durchgeführt. Diese Jour Fixes haben aus
Sicht des Risikomanagers zum einen die Funktion, neue Risiken zu sammeln und zu bewerten. Zum andern
dienen sie dazu, bereits vorher erkannte Risiken gemeinsam zu überprüfen.
Ergänzend dazu sollte der Risikomanager – über alle Projektebenen und -bereiche hinweg – auch direkte Gespräche mit Projektmitarbeitern führen: Einzuschließen sind die Entwickler ebenso wie eventuelle projektexterne Mitarbeiter (z.B. Nutzer).
→ Gerade bei komplexen Projektstrukturen können nur direkte Gespräche verborgene Risiken aufdecken.
So sollte der Risikomanager z.B. fragen, welche Teile des Projekts aus welchen Gründen besonders schwierig sind und systematisch typische inhaltliche Risikokategorien (siehe unten) durchgehen. Bei Anzeichen
von Problemen sollte er mit den Experten ins Detail gehen, um insbesondere verborgene technische Risiken
zu identifizieren.
Als Instrument zur schnellen Identifikation von Risiken eignet sich wiederum der Fragebogen zur Statusbestimmung aus dem Kapitel Statusprüfung der Erfolgsfaktoren.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.4 Risikomanagement
159
Identifikation komplexer Risiken durch Tiefenanalyse
→ Bei IT-Großprojekten in der öffentlichen Verwaltung sind im Rahmen des Risikomanagements fünf Kategorien von Risiken zu betrachten – insbesondere die politische Dimension kommt dabei im Vergleich zu
Großprojekten im privaten Sektor hinzu:
●
Politik/Strategie
●
Fachlichkeit
●
Organisation (bezüglich Projekt-/Programmorganisation)
●
Technik
●
Vertragsmanagement (z.B. externe Auftragnehmer/Generalunternehmer).
Politik als fünfte Kategorie des Risikomanagements
→ Bei der Bewertung der Risiken ist Value at Risk wiederum ein wertvolles Kriterium: Wie hoch ist etwa
der entgangene Nutzen, wenn das Risiko eintritt (vgl. Kapitel Festlegung/Überprüfung der Projektrahmenbedingungen). Oder welche Risiken entstehen für den Sponsor z.B. auf politischer Ebene, wenn der Nutzen
nicht eintritt?
Entgangener Nutzen als zusätzliches Bewertungskriterium
→ Angesichts der erheblichen Größenordnung und Bedeutung von IT-Projekten in der öffentlichen Verwaltung (viele betroffene Personen, sensible Bereiche wie Sicherheit etc.) müssen insbesondere auch Risiken
mit kleiner Eintrittswahrscheinlichkeit, die aber einen hohen Schaden verursachen können, näher betrachtet
werden!
Schadensausmaß vor Eintrittswahrscheinlichkeit
Definition und Durchführung von Gegenmaßnahmen
Für Risiken, deren Eintrittswahrscheinlichkeit oder Schadenshöhe durch proaktive Maßnahmen gemindert
werden kann, werden entsprechende Maßnahmen vereinbart: Dazu gehört es insbesondere auch, Verantwortlichkeiten und Termine festzulegen. (Auf bereits eingetretene Risiken wird meist im Regelgeschäft des Projektmanagements reagiert).
Im Gegensatz zur reinen Risikoadministration umfasst das Risikomanagement auch die Umsetzung wirkungsvoller Gegenmaßnahmen. Diese zeichnen sich unter anderem durch folgende Charakteristika aus:
●
Alternativplan bereithalten für den Fall, das ein Risiko eintritt. Manchmal kann nicht verhindert
werden, dass das Risiko eintritt. Jedoch können Schaden und Folgewirkungen im Voraus abgeschätzt und
Gegenmaßnahmen geplant werden. Beispielsweise ist der Gesamtprojektleiter nicht für den Ausgang von
Wahlen verantwortlich; er kann jedoch verschiedene Wahlausgangsszenarien annehmen und dafür Maßnahmen planen.
●
Umdefinieren des Projekts. Der Einfluss von Risiken soll reduziert werden: Auch wenn die Auswirkung bzw. der Schaden eines Risikos nicht zu beeinflussen sind, kann eventuell das Projekt so modifi ziert werden, dass das Risiko nicht mehr relevant ist. Beispielsweise kann bei Wahlen ein Zwischenziel
mit einem Zieltermin vor der Wahl festlegt werden.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
160
●
7 Disziplinen zu Systemen, Instrumenten und Werkzeugen
Probleme offen analysieren und radikal angehen. Das gilt insbesondere für kritische Probleme (z.B.
eingetretene erhebliche Risiken) und scheinbar aussichtslose Situationen: Die gewonnenen Spielräume
lassen sich nutzen, um Inhalt, Budget bzw. Termine zu prüfen und gegebenenfalls anzupassen.
Wirkungsvolles Risikomanagement erhöht die Realisierungswahrscheinlichkeit vereinbarter Maßnahmen, indem es durch Schaffung von Transparenz Handlungsdruck aufbaut:
●
Wie erreicht der Projektleiter, dass auf LA-Ebene gehandelt wird? Ansatzpunkte: Maßnahmen in die Planung aufnehmen, dem LA Auswirkungen darstellen (auch Auswirkung der Maßnahmen auf die Planung
auf allen Ebenen), Puffer auflösen, Nutzen der Risikomaßnahmen verdeutlichen
●
Wie werden Handlungen in den unteren Projektebenen ausgelöst? Ansatzpunkte: per Änderungsauftrag
ans Projekt, durch Überführung der Maßnahmen aus dem Risikomanagement in die normalen Planungs werkzeuge des Projekts (übergreifendes Aufgabenmanagement/Planung etc.) und durch regelmäßige
Kontrolle der Wirksamkeit der Maßnahmen
●
Für besonders große Probleme kann auch das so genannte Trouble Management genutzt werden – eine
explizit eingerichtete Taskforce, um ein vorhandenes Risiko oder Problem zu lösen. Der Trouble Manager leitet diese Aktivitäten, er muss Seniorität und Durchsetzungsvermögen haben. Vorteil: Stakeholder
und Mitarbeiter, die vorher Teil des Problems waren, lassen sich häufig besser in eine Taskforce mit frischem Ansatz und unverbrauchten Managern einbinden.
Berichterstattung
Die vereinbarten Berichte werden kontinuierlich aktualisiert, mit Zusammenfassungen versehen und den
Empfängern zugeleitet.
→ Bei unabhängiger Berichterstattung im LA trägt der Risikomanager kurz zusammengefasst die wichtigsten Risiken in den LA-Sitzungen vor.
Risikomanager als Berichterstatter des LA
→ Risiken werden gerade in der öffentlichen Verwaltung oft kleingeredet oder gar nicht erst kommuniziert.
Der Grund liegt im „Risiko eines offenen Risikomanagements“: Insbesondere von der politischen Oppositi on können Risiken ausgenutzt oder dramatisiert werden. Um hier im Vorfeld gegenzusteuern, ist die Unterstützung durch die oberste Leitungsebene und die im LA vertretenen Stakeholder wesentlich: Sie müssen
die Vertraulichkeit über die Risikoberichterstattung wahren und gleichzeitig die Projektrisiken gemeinsam
tragen.
Unterstützung der Organisationsleitung wahrt die Effektivität des Risikomanagements
7.4.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Risikomanagement
erkennen?
Wie effektiv das bestehende Risikomanagement ist, kann der Auftraggeber des Projekts z.B. mit Hilfe von
folgenden Kriterien feststellen:
●
Umsetzungsgrad von Gegenmaßnahmen
●
Verfolgung der Entwicklung kritischer Risiken über die Zeit: Sofern nicht exogene Faktoren zu einer Änderung der Bewertungen führen, sollten sich durch das Risikomanagement die Einschätzungen zu Schadensausmaß und Eintrittswahrscheinlichkeit im Laufe der Zeit verbessern
●
Wird die Dokumentation auch überarbeitet, z.B. arbeitspaket-bezogene Risiken auch entfernt?
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
7.4 Risikomanagement
161
7.4.6 Grundlegende und weiterführende Literatur
●
Uwe Schnorrenberg, Gabriele Goebels: „Risikomanagement in Projekten – Methoden und ihre praktische Anwendung“, Vieweg Verlag 1997
7.5 Endnoten
EN-701
Da der Terminplan die Informationen aus Projektstrukturplan, Aufwandsplan und Ressourcenplan integriert, wird der Begriff Terminplan häufig als Synonym für Projektplan verwendet.
EN-702
In diesem Fall gibt es verschiedenste Handlungsmöglichkeiten, z.B. Reduzierung der vom
Projekt zu liefernden Lösung (Descoping), Hinterfragen und Anpassen der (Qualitäts-)Ziele,
Berücksichtigung von Lösungen außerhalb des vorgegebenen Lösungskorridors (damit Änderung der Kosten-Nutzen-Analyse), Reduzierung der Kosten, nochmalige Prüfung der Lösungsdetaillierung („jeden Stein im Projekt umdrehen“), Delegation nach oben mit dem
Auftrag, geänderte Rahmenbedingungen zu schaffen. Letztendlich sollte das Projekt nur bei
einer realistischen Erfolgschance weitergeführt werden, die Risiken sollten in der Risikoliste
dokumentiert werden und die vom Auftraggeber zugesagten Rahmenbedingungen sollten im
Projektverlauf auch eingefordert werden.
EN-703
Im V-Modell ist die Rolle Prüfer definiert. Diese Bezeichnung lässt auf die Durchführung
ausschließlich analytischer, prüfender Maßnahmen schließen, daher wird die Bezeichnung
hier nicht verwendet.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
162
8 Erweiterung der Managementdisziplinen
8 Erweiterung der Managementdisziplinen
8.1 Programmmanagement
Wenn Projekte größer werden und die Schwelle vom Groß- zum Megaprojekt überschreiten, wandelt sich der
Charakter des Projektmanagements: Das eine große Projekt wird unterteilt in Einzelprojekte, die zusammen
ein Programm bilden und vom übergreifenden Programmmanagement koordiniert werden. Die Begriffe Megaprojekt und Programm werden deshalb im Folgenden synonym verwendet. Programmmanagement ist hier
definiert als übergreifende Koordination von Einzelprojekten, die alle einem Ziel dienen (im Multiprojektmanagement steht unmittelbar nicht das eine gemeinsame Ziel im Vordergrund, sondern die standardisierte
Abwicklung von Projekten). Insofern grenzt sich das Programm- vom Portfoliomanagement ab, das unabhängig vom inhaltlichen Zusammenhang der Teilprojekte agiert (und z.B. nur eine übergreifende Ressourcenallokation vornimmt).
8.1.1 Ziele und Rahmenbedingungen: Welche Funktion hat das Programmmanagement?
In der Literatur werden zwei Schulen unterschieden: 1) Programmmanagement als Skalierung des Projektmanagements „nach oben“ (bottom up) auf immer größere, komplexere und langwierigere Anwendungsgebiete und 2) Konkretisierung der Strategieumsetzung „nach unten“ (top down), das heißt Überführung der
Strategieentwicklung in ein oder mehrere Umsetzungsprogramme. Entsprechend unterscheidet sich das Instrumentarium des Programmmanagements: Entweder liegt der Fokus auf der zentralisierten Kontrolle des
Geschehens in immer größeren Vorhaben oder auf der Sicherung der Reaktionsfähigkeit des Programms angesichts der Tatsache, dass bestimmte Faktoren wie die externe Umwelt oder wankelmütige Stakeholder
nicht kontrolliert werden können. Im Einklang mit der S-O-S-Methode© soll hier ein Mittelweg gefunden
werden, der beiden Schulen Rechnung trägt:
●
Für den „von oben“-Ansatz aus der Strategieumsetzung sind viele der beschriebenen Disziplinen des
GroßPM geeignet, z.B. das Management der Projektrahmenbedingungen mit kontinuierlicher Prüfung
der Relevanz und Erreichbarkeit der Projektziele, das Kommunikationsmanagement zum Alignment von
Stakeholdern oder das Risikomanagement als Radar für externe Einflussfaktoren. Diese Disziplinen der
S-O-S-Methode© lassen sich unmittelbar im Programmkontext anwenden. Ein grundsätzlicher philosophischer Unterschied wurde jedoch bisher nicht thematisiert: Programmmanagement als das Management eines Portfolios von Initiativen, bei dem z.B. bewusst redundante Einzelprojekte lanciert werden,
wenn der beste Ansatz erst im Laufe der Zeit identifiziert werden kann.
●
Für den „von unten“-Ansatz aus der Hochskalierung des Projektmanagements fehlen noch einige Instrumente, insbesondere das Schnittstellenmanagement und das Anforderungsprofil des Programmmanagers,
das sich klar vom Projektmanager abgrenzen lässt. Auch wenn die Rahmenbedingungen in komplexen
Programmen noch weniger beherrschbar sind als in Großprojekten, darf das nicht dazu führen, dass nicht
geplant wird. Vielmehr sind die notwendigen Flexibilitäten mit einzukalkulieren, z.B. in Form von verschiedenen Szenarien oder Puffern.
Für beide Ansätze gilt die goldene Regel, dass das Programm in möglichst kurze Phasen mit klaren Endprodukten aufzuteilen ist (z.B. in einem Softwareprojekt einen ersten Produktivstart nach einem Jahr vorzuse hen, gefolgt von halbjährlichen Releases). Ein derartiges Vorgehen reduziert nicht nur das Risiko von externen Störfaktoren, gleichzeitig sinkt auch die Planungskomplexität.
Dennoch: Auch in kurz getakteten Vorhaben ist das Programmmanagement durch die hohe Zahl „beweglicher Teile“ sehr komplex. Zwischen den einzelnen Projekten, die für sich weitgehend autonom sind (und sein
sollten), müssen Abhängigkeiten erkannt und gemanagt werden. In jedes der Einzelprojekte können – müssen aber nicht – externe Auftragnehmer eingebunden werden (siehe auch Kapitel Festlegung/Überprüfung
der Projektorganisation). Das erhöht die Komplexität des Programmmanagements weiter, da auch multiple
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
8.1 Programmmanagement
163
Auftraggeber-Auftragnehmer-Beziehungen zu managen sind. Für jedes Thema und jedes Projekt muss das
Programmmanagement die angemessene „Eindringtiefe“ bestimmen: Die Verantwortung des Projektleiters
für sein Einzelprojekt zu wahren, gleichzeitig ist aber auch die Koordination und die damit einhergehende
Beschränkung der Freiheitsgrade der Einzelprojekte notwendig.
→ Im öffentlichen Umfeld gilt es darüber hinaus häufig, ein Megaprojekt oder Programm in einem Umfeld
mit mehreren Chefs nicht nur organisatorisch, sondern auch politisch so zu steuern, dass sich die diversen,
oft gleichberechtigten LA-Mitglieder mit unterschiedlichen Interessen nicht gegenseitig blockieren. Eine
Eskalationsinstanz ist häufig nicht vorhanden und auch nicht gewünscht (beispielsweise bei Bund-Län der-Projekten), so dass eine solche Situation nur durch geschicktes Verhandeln gelöst werden kann. Gleichzeitig sind die Programme plötzlichen und umwälzenden Änderungen besonders ausgesetzt – politische
Veränderungen (Gesetzesänderungen, Verfassungsgerichtsurteile, Machtwechsel) können Projektumfang,
Zielsetzung oder Interessenlage im LA massiv verändern. Das Programmmanagement muss vor diesem
Hintergrund kontinuierlich daran arbeiten, sichere von gefährdeten Grundannahmen zu unterscheiden und
das Programm primär an den sicheren auszurichten.
Steuerung in einem Multi-CIO-Umfeld beachten
Das Programmmanagement besteht aus vier Elementen:
Abbildung 70: Aufgabenfelder des Programmmanagements
●
Inhaltliche Steuerung. Portfoliosteuerung der Einzelprojekte (Welche Projekte mit welcher Zielsetzung
sind nötig, um das Gesamtziel zu erreichen?), übergreifendes Nutzenmanagement (Spielen alle Einzelprojekte zusammen, so dass das angestrebte Endergebnis erreicht wird?), Sicherstellung eines einheitli chen Qualitätsstandards über die Einzelprojekte hinweg, inhaltliche Koordination der Schnittstellen zwischen den Einzelprojekten und dem Umfeld (Wer liefert wann was?)
→ Viele kritische Projekte außerhalb der IT setzen bewusst auf Redundanzen, um den Gesamterfolg
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
164
8 Erweiterung der Managementdisziplinen
unabhängiger von Einzelaktivitäten zu machen. Zwei Beispiele aus jüngster Zeit: Bei der Ölkatastrophe
im Golf von Mexiko und beim Minenunglück in Chile wurden gleichzeitig redundante Entlastungs- und
Rettungsbohrungen vorangetrieben, um beim Scheitern einer Bohrung nicht den Gesamtzeitplan zu verzögern. In hochriskanten IT-Programmen kann dieser Ansatz ebenfalls sehr hilfreich sein, z.B. um Al ternativen für neue technische Lösungen parallel zu erproben.
Mehr Redundanz wagen
●
Technische Steuerung. Koordination der Einzelprojekte auf Grundlage der Kerndimensionen Termine
und Meilensteine, Budgets sowie Risiken. Wichtig ist hierbei die übergreifende Steuerung des Gesamt budgets einschließlich der Allokation des Risikopuffers – der Puffer sollte nicht in Verantwortung der
Einzelprojektleiter liegen. Darüber hinaus von Bedeutung ist ein sorgfältig ausgearbeiteter Migrationsplan von der „alten“ in die „neue“ Welt. Dieser ist insbesondere in Programmen mit dezentraler Imple mentierung zwingend nötig, da diese schon allein durch die große technische Komplexität und die Vielzahl der Stakeholder in der Regel keine „big bang“-Lösung erlauben.
→ Im öffentlichen Sektor ist dies umso wichtiger, da oftmals unterschiedliche politische Einheiten be troffen sind (z.B. Bundesländer, Kommunen, Ressorts, Behörden), von denen in der Regel jede ihr eigenes Migrationstempo hat, so dass „alte“ und „neue“ Welt in einer Übergangszeit nebeneinander existieren müssen.
Vielzahl betroffener, politischer Einheiten beachten
●
Übergreifende Kommunikation. Erarbeitung, Durchsetzung und Umsetzung einer übergreifenden
Kommunikationsstrategie, die aus Sicht der betroffenen Zielgruppen konsistent ist, einschließlich des
Alignment von Stakeholdern in einem Umfeld mit multiplen Chefs.
●
Veränderungsmanagement. Übergreifende Analyse der anzustrebenden Verhaltensänderung in der Organisation/in den beteiligten Organisationen; Koordination der Einzelprojekte auf dieses übergreifende
Ergebnis; auch hier muss das angestrebte Ergebnis aus Sicht der Betroffenen konsistent sein.
Es zeigt sich, dass Programmmanagement mehr ist als die Summe seiner Einzelprojekte. Das wird insbesondere im Portfoliogedanken deutlich: Das Programmmanagement entscheidet selbst, welche Einzelprojekte zur Erreichung des Gesamtziels nötig sind. Auch auf der operativen Ebene unterscheiden sich Projektund Programmmanagement:
●
Streben nach Stabilität vs. Management von Unsicherheit. Programme sind größer, länger und komplexer als Großprojekte. Erfolgsfaktoren eines Großprojekts (z.B. der minimale stabile Projektumfang)
sind auf Programmebene noch schwerer zu gewährleisten. Statt Stabilität zu erzwingen, sollte das Pro grammmanagement flexibel auf den Wandel reagieren: z.B. durch eine Analyse von Szenarien, auf die
jeweils mit teilweise parallelen Einzelprojekten reagiert wird, durch das Ermöglichen dezentraler Auto nomie statt durch starres Durchsteuern oder durch das Aufgreifen von Stakeholder-Ideen statt durch das
reine Ausrichten auf von oben vorgegebene Ziele. Auf Einzelprojektebene hingegen muss das Programmmanagement die Erfolgsfaktoren sicherstellen.
●
Temporär vs. Dauerfunktion. Projekte sind von ihrem Grundverständnis temporär, Programme müssen
das nicht sein: Strategieumsetzung ist eine Dauerfunktion und auch ein auf fünf bis zehn Jahre angelegtes Programm sollte sich als solche verstehen. Damit ist die Verknüpfung des Programms mit der übrigen
Organisation (bzw. den übrigen Organisationen) um das Programm herum von größerer Bedeutung,
ebenso der Aufbau von internen Fähigkeiten, die im Rahmen des Programms und seiner Projekte benö tigt werden.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
8.1 Programmmanagement
●
165
Projektleiter liefern, Programmmanager ermöglichen. Die Rolle des Programmmanagers unterscheidet sich deutlich von der des Projektleiters. Vereinfacht gesagt soll der Projektleiter die Projektziele
durch eigenes Wirken erreichen, der Programmmanager hingegen indirekt, durch das Wirken von ande ren. Einen fähigen Programmmanager zu finden, ist eine große Herausforderung: Zum einen muss er
über umfangreiche Projektleitungserfahrung verfügen, um entsprechend auf die Einzelprojekte einwirken
zu können (z.B. sollte er intuitiv wissen, wo er wie tief einsteigen muss, um einen realistischen Eindruck
vom Status der Einzelprojekte zu erhalten). Ohne diese Erfahrung könnte der Programmmanager leicht
zum „Frühstücksdirektor“ werden. Gleichzeitig muss er die nötige Gelassenheit besitzen, um dezentrale
Autonomie in den Einzelprojekten zulassen zu können. Gerade diese Gelassenheit fehlt vielen erfolgreichen Projektleitern, die vor allem wegen ihrer Hartnäckigkeit und Omnipräsenz im Projekt erfolgreich
sind.
Angesichts der zusätzlichen Aufgaben im Programmmanagement sollte die Organisation eine gewisse Größe
haben: Werden typischerweise 10 bis 20% eines Projektbudgets für Projektmanagement aufgewendet, sind
für das Programmmanagement zusätzliche 5 bis 10% zu veranschlagen. Die Größe der Programmorganisati on kann weiter zunehmen, wenn Querschnittsfunktionen aus den Einzelprojekten herausgelöst und auf Programmebene gebündelt werden. Entsprechend reduziert sich gleichzeitig der Managementaufwand in den
Einzelprojekten. Hierfür geeignete Querschnittsfunktionen sind Projektadministration, Projektcontrolling,
Risikomanagement, Lieferanten- und Vertragsmanagement sowie Teile des Kommunikations-, Test- und
Qualitätsmanagements. Wichtig ist, dass das Programmmanagement zentralisierte Funktionen nicht monopolisiert, sondern die Dienstleistungen weiter den Einzelprojekten zur Verfügung stellt.
→ Insbesondere in einem Umfeld mit multiplen Chefs fehlen Programmen noch häufiger als Großprojekten
klare Eskalations- und Entscheidungsinstanzen. Umso wichtiger ist es, ein übergreifendes Lenkungsgremium mit klaren Entscheidungsbefugnissen einzurichten, dass optimalerweise auf Basis von Mehrheitsentscheidungen statt Einstimmigkeit arbeitet. Die dafür nötigen Grundsatzentscheidungen sollten im Vorfeld
des Programms getroffen werden (z.B. wer befürchtet, bei Mehrheitsentscheidungen „untergebuttert“ zu
werden und benötigt deswegen Sicherheit bezüglich von Kernparametern wie Standortsicherheiten?).
Klare Eskalationsinstanz schaffen
8.1.2 Rollen: Wer macht was im Programmmanagement?
Die zentrale Rolle im Programmmanagement ist die des Programmmanagers, der die Gesamtverantwortung
trägt und gleichzeitig nicht (mehr) operativ die Einzelprojekte steuern kann. Dem Programmmanager sollte
ein Schnittstellenmanager zur Seite stehen, der die Abhängigkeiten der Einzelprojekte untereinander analysiert und managt; dieser kann gleichzeitig den übergeordneten Migrationsplan verantworten. Der Programmmanager wird außerdem vom Programmmanagementbüro (PMO) unterstützt, das Dienstleistungen für die
Einzelprojekte erbringt und Querschnittsfunktionen bereitstellt.
Rolle
Beschreibung
Programmmanager
Trägt die Gesamtverantwortung für das Programm
● Bestimmt Portfolio und Schnitt der Einzelprojekte (und damit deren Projektumfänge)
sowie die daraus folgenden Verantwortlichkeiten
● Definiert die Zielarchitektur
● Definiert Arbeitsweisen und Standards
● Managt das Gesamtbudget und alloziert den Risikopuffer (in Abstimmung mit dem LA)
● Oberster Nutzenmanager: sorgt dafür, dass die Einzelprojekte gesamthaft die
angestrebten Veränderungen erreichen
● Gewährleistet eine konsistente übergeordnete Kommunikation insbesondere mit dem LA
und den wichtigsten (programmexternen) Stakeholdern
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
166
8 Erweiterung der Managementdisziplinen
Rolle
Beschreibung
Steuert die externen Lieferanten, managt die Verträge
Steuert das PMO und die zentral angesiedelten Querschnittsfunktionen, prüft die
Programmorganisation und passt sie bei Bedarf im Programmverlauf an
Zusätzlich nimmt der Programmmanager bestimmte Aufgaben gemeinsam mit den
Einzelprojektleitern wahr:
● Kommunikation mit den Anwendern bzw. Nutzern (insbesondere wenn diese von
mehreren Einzelprojekten betroffen sind)
● Abstimmung des Programms mit den Managern der Dauerfunktionen in den beteiligten
Organisationen
Folgende Aufgaben sollte der Programmmanager nicht selbst wahrnehmen, sondern den
Einzelprojektleitern überlassen:
● Management von Zeitplänen und Detailbudgets der Einzelprojekte
● Mitarbeiterführung in den Einzelprojekten
●
●
Schnittstellenmanager
Stellt sicher, dass Zusammenhänge zwischen den Projekten erkannt und gemanagt werden
● Identifiziert Schnittstellen und Abhängigkeiten zwischen den Einzelprojekten (und
programmexternen Aktivitäten), definiert diese und stimmt sie mit den Einzelprojekten ab
● Interveniert bei Projektänderungen, die Auswirkungen auf andere Projekte haben
könnten
● Definiert den Migrationsplan
● Überwacht die Einhaltung der Projektmeilensteine bei Zulieferleistungen, um
Verspätungen für das Gesamtprogramm rechtzeitig zu erkennen und reagieren zu
können
Projektmanagementbüro
(PMO)
Unterstützt den Programmmanager bei administrativen Aufgaben und stellt (sofern
zentralisiert) Dienstleistungen für die Einzelprojekte bereit
● Erstellt und aktualisiert den Meilensteinplan des Programms und die Schnittstellenpläne
● Erstellt gesamthaften Fortschrittsbericht
● ...
Tabelle 16: Rollen und Verantwortlichkeiten im Programmmanagements
Die nachfolgende Abbildung zeigt, wie die Kompetenzen des Programmmanagements und die der Einzelprojektleitung voneinander abgegrenzt werden könnten:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
8.1 Programmmanagement
167
Abbildung 71: Kompetenzverteilung zwischen Programmmanagement und Einzelprojektleitung
Für eine ausführliche Beschreibung des Kompetenzprofils eines Programmmanagers siehe zusätzlich Pelle grinelli 2008.
8.1.3 Ergebnisse: Welche Dokumente sollen erstellt werden?
Das Programmmanagement kann viele Dokumente nutzen, die bereits in anderen Disziplinen eingeführt wurden. Zusätzliche Dokumente werden in den Bereichen Schnittstellenmanagement und Migrationsplanung benötigt.
Schnittstellenmanagement
●
Liste der wichtigsten Module bzw. Arbeitspakete, zwischen denen einzelprojektübergreifend inhaltliche Zusammenhänge bestehen können. Wichtig ist, dass die Module nach Kritikalität unterschieden werden.
●
Schnittstellenmatrix. Die Abhängigkeiten der Module untereinander werden in einer Schnittstellenmatrix abgebildet. Ein Modul mit vielen Abhängigkeiten hat eine hohe Kritikalität. Gelingt es dem Pro grammmanager, alle Einzelprojekte zur konsistenten Nutzung von Tools wie MSProjekt Enterprise zu
verpflichten, kann das auch toolgestützt erfolgen. So wird es deutlich leichter, Folgen von Terminver schiebungen zu analysieren.
●
Liste der möglichen Ereignisse und Risiken. In Anlehnung an das operative Risikomanagement werden die möglichen Ereignisse und Risiken erfasst mit ihren Auswirkungen auf die Module. Auf diese
Weise erlangt man in einem komplexen Programm schnell eine Übersicht darüber, wie verschiedene Er eignisse und Risiken die einzelnen Projekte beeinflussen können. Ist ein Modul besonders vielen mögli chen Beeinträchtigungen ausgesetzt, kann das auf eine kritische Stelle im Projekt hinweisen, vor allem
dann, wenn das Modul eine große Zahl von Schnittstellen hat.
Migrationsplanung
●
Der Migrations- oder Rollout-Plan zeigt die Produktivsetzung der Einzelprojekte über Zeit und dient
der übergreifenden Steuerung aus Anwendersicht.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
168
8 Erweiterung der Managementdisziplinen
8.1.4 Prozesse: Wie geht das Programmmanagement vor?
Das Programmmanagement kann viele Prozesse verwenden, die auf Großprojektebene bereits in anderen Kapiteln erläutert wurden. Insofern beschränken sich die Ausführungen im Folgenden auf die Neuigkeiten und
Unterschiede.
Abbildung 72: Prozesse des Programmmanagements
Aufbau des Programmmanagements
Gemeinschaftliche Zielvision entwickeln
Es gelten die Ausführungen aus dem Kapitel Prozesse: Wie lassen sich die Rahmenbedingungen festlegen
und prüfen?. In Programmen sind vielfach noch mehr unabhängige Organisationseinheiten involviert als in
Großprojekten, insofern ist eine prägnante Zielvision, die von allen Beteiligten getragen wird, noch wichti ger. Das Programmmanagement muss dabei sicherstellen, dass jede Einheit auch die Implikationen der Zielvision verstanden hat – eine IT-Konsolidierung führt unweigerlich spätestens langfristig zur Verlagerung von
Stellen. Wenn dies für eine Einheit nicht akzeptabel ist, lohnt sich deren Involvierung ins Programm nicht.
Einzelprojektportfolio und -schnitt festlegen
Die vielleicht wichtigste Aufgabe des Programmmanagements liegt in der Freiheit, Einzelprojekte zu lancieren, inhaltlich zu definieren und auch wieder zu beenden. Folgende Grundprinzipien sollten beim Schneiden
der Einzelprojekte beachtet werden:
●
Insgesamt vollständig. Alle zur Erreichung der Programmziele nötigen Arbeitsergebnisse müssen in
mindestens einem Einzelprojekt verankert sein.
●
„Lebensfähig“, aber nicht zu komplex. Die Einzelprojekte sollten eine gewisse Mindestgröße aufweisen, um ein eigenständiges Projektmanagement zu verdienen und die Koordination im Programmkontext
effizient abbilden zu können. Miniprojekte sind im Zweifelsfall zusammenzufassen. Gleichzeitig ist es
aber ein Grundprinzip des Programmmanagements, die große Komplexität des Gesamtprogramms durch
sinnvolle Teilung einzugrenzen – die Einzelprojekte dürfen nicht zu groß werden.
●
Klar abgegrenzt und überschneidungsfrei. Der Projektumfang der Einzelprojekte sollte nach Möglichkeit thematisch logisch zusammengefasst sein (für interne Synergien) und so wenige Außenschnittstellen
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
8.1 Programmmanagement
169
wie möglich erfordern (ebenfalls, um den Koordinierungsaufwand gering zu halten). Überlappungen
sind zu vermeiden – sie führen zu Dopplungen und Inkonsistenzen. Eine Ausnahme ist hierbei der be wusste Versuch, bei hochriskanten Vorhaben (z.B. bei der Erprobung neuer Technologien) redundante
Einzelprojekte mit unterschiedlichen Vorgehensweisen zu lancieren (z.B. zwei Prototypen mit unterschiedlichen Architekturen).
Häufig sind diese Prinzipien nicht konfliktfrei umsetzbar – bei einem zu granularen Schnitt sinkt zwar die
Komplexität im Einzelprojekt, gleichzeitig steigt jedoch der Koordinierungsaufwand zwischen den Projekten.
Standards definieren, Programmstruktur festlegen
Grundsätzlich sind die Ausführungen zur Projektorganisation (Kapitel Festlegung/Überprüfung der Projektorganisation) analog auch für das Programmmanagement anzuwenden. Zusätzlich muss jedoch der „gemeinsame Kern“ der Einzelprojekte definiert werden.
Hierzu zählen zum einen Standards im Projektmanagement: Vorgehen und Methode, Standards zu Tools (insbesondere Projektmanagementsoftware, Entwicklungswerkzeuge), Dokumentations- und Ablagestandards,
Qualitäts- und Teststandards. Aber auch gemeinsame Lieferanten z.B. für Software, Hardware, Implementierungs- und Projektmanagementleistungen.
Entscheidungsstrukturen, mit denen beispielsweise die Rechte des Programmmanagements gegenüber den
Einzelprojekten definiert sind. Hier ist der Wunsch nach zentraler Kontrolle zu balancieren mit der notwendigen Autonomie der Einzelprojekte.
→ Auch wenn die genauen Strukturen je Programm angepasst werden müssen, gelten einige grundsätzliche
Empfehlungen für Programme im öffentlichen Sektor:
●
Für das Gesamtprogramm muss ein LA eingerichtet werden mit Verantwortlichen aus allen beteiligten Organisationen. Für die Einzelprojekte ist dies im Einzelfall zu entscheiden. Es ist sinnvoll, wenn
sich die Einzelprojekte mit abgrenzbaren Spezialthemen beschäftigen, für die jeweils eigene Sponsoren
verantwortlich sein können. Der Programmmanager sollte dann jeweils Mitglied in den Einzelprojekt-LAs sein.
●
Dezentrale Budgetverantwortung, aber in einem zentralen Rahmen. Die Einzelprojekte sollten alle
eigenverantwortlich ihre Budgets managen, diese sollten aber in einem zentralen Gesamtbudget konsolidiert werden – so wird beispielsweise vermieden, dass die gleichen Komponenten in mehreren Einzel projekten eingeplant werden. Der Risikopuffer sollte in der Verantwortung des Programmmanagers liegen.
●
Ähnliches gilt für die Meilensteinverantwortung – die Einzelprojekte sind für die Einhaltung von
Meilensteinen verantwortlich, müssen aber den Gesamtrahmen mit dem Programm abstimmen.
●
Die Verantwortung für den Gesamtnutzen des Programms sollte überwiegend zentralisiert sein –
selten können Einzelprojekte für sich alleine eine wirtschaftliche Vorteilhaftigkeit nachweisen.
Standards für zentrale Verantwortung im Programmmanagement
→ Eine besondere Bedeutung in Programmen mit komplexen Stakeholder-Strukturen kommt den Entscheidungsrechten zu. In einem Programm mit mehreren Chefs gibt es häufig diverse gleichberechtigte LA-Mitglieder mit unterschiedlichen Interessen, die sich schnell gegenseitig blockieren können. Eine Eskalationsinstanz ist häufig nicht vorhanden und auch nicht gewünscht (beispielsweise bei Bund-Länder-Projekten),
so dass die Auflösung eines solchen Zustands nur durch geschicktes Verhandeln zu erreichen ist. Die Ver handlungsmacht des Programmmanagements ist vor Beginn des Programms am größten: „Ohne eine tragfähige Entscheidungsstruktur ist es nicht sinnvoll, das Programm zu starten“. Einstimmigkeit als Entschei dungsregel bewährt sich nicht – Mehrheitsentscheidungen mit „Minderheitenschutz“, bei dem gewisse zu -
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
170
8 Erweiterung der Managementdisziplinen
vor definierte Mindestinteressen der Einzelnen nicht überstimmt werden dürfen, haben sich als tragfähige
Struktur erwiesen.
Mehrheitsentscheidungen ermöglichen
Schließlich ist noch zu entscheiden, ob und welche Querschnittsfunktionen auf Programmebene angesiedelt
werden. Sollen die Einzelprojekte z.B. selbst Projektbüros oder ein Projektcontrolling aufbauen oder wird
dies zentral aus dem Programmbüro erledigt/als Dienstleistung zur Verfügung gestellt?
Grobplan Programm festlegen
Für die Grobplanung des Programms gelten die Ausführungen des Kapitels Festlegung/Überprüfung der Projektrahmenbedingungen analog.
→ Gleichzeitig sind Programme häufig plötzlichen und umwälzenden Änderungen ausgesetzt. Politische
Veränderungen (Gesetzesänderungen, Verfassungsgerichtsurteile, Machtwechsel) können für massive Veränderungen bezüglich Projektumfang, Zielen oder Interessenlage im LA sorgen. Das Programmmanage ment muss vor diesem Hintergrund schon in der Grobplanung (und danach kontinuierlich) versuchen, sichere von gefährdeten Grundannahmen zu unterscheiden und das Programm primär an den sicheren auszurichten – und beispielsweise Einzelprojekte, für die wichtige Grundannahmen noch nicht sicher sind, später
im Meilensteinplan anzusiedeln.
Planung auf sichere Annahmen stützen
Inhaltliche Programmsteuerung
Einzelprojektportfolio und -schnitt prüfen/anpassen
Das Programmmanagement muss sich nicht an eine einmal gewählte Struktur der Einzelprojekte halten, sondern sollte diese periodisch überprüfen. Die Einzelprojekte sollten bezüglich Komplexität und Größe ungefähr einheitlich sein; dies kann z.B. bedeuten, ein zentrales Design- und Implementierungsprojekt in ver schiedene dezentrale Umsetzungsteams zu zerteilen, sobald eine Lösung bereit für den Flächen-Rollout ist.
Nutzenerreichung kontrollieren, Endproduktqualität prüfen
Die Überwachung der übergeordneten Nutzenerreichung ist eine der vordringlichsten Aufgaben des Programmmanagements, da die Einzelprojekte häufig nur Teilkomponenten bereitstellen und das Gesamtbild
nicht sehen können.
Hierfür muss das Programmmanagement die Werttreiber aus der übergeordneten Kosten-Nutzen-Analyse auf
die einzelnen Projekte aufschlüsseln und in messbare Vorgaben überführen, die dann zentral kontrolliert werden können. Eine große Herausforderung ist es, wenn der Nutzen erst entsteht durch das Zusammenspiel der
Ergebnisse aller Einzelprojekte – dann obliegt die Prüfung der Endproduktqualität dem Programmmanagement, das in diesem Fall eine sehr operative Rolle übernehmen muss.
Schnittstellen identifizieren/koordinieren
Zwischen den Einzelprojekten eines Programms bestehen zahlreiche Zulieferbeziehungen und Abhängigkei ten – Komponenten bauen aufeinander auf, eine Produktivsetzung kann erst geplant werden, wenn Anwenderzahlen und grobe Schulungsinhalte, -formate und -dauer etc. festgelegt sind. Auch zwischen den Einzel projekten und den übrigen Aktivitäten der beteiligten Organisationen bestehen Abhängigkeiten – z.B. Bereitstellen von Linienmitarbeitern oder Räumen.
Diese Abhängigkeiten sind durch das Programmmanagement zu identifizieren, aufzunehmen und zu koordinieren, das heißt, Übergabepunkte sind zwischen den Einzelprojekten zu definieren und bei Terminverschie bungen sind die Auswirkungen auf andere Einzelprojekte zu analysieren.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
8.1 Programmmanagement
171
Eine besondere Form der Abhängigkeit ist die von exogenen Ereignissen, die das Projekt gefährden können.
Aus Synergiegründen können Schnittstellen und operative Risiken im Rahmen der gleichen Managementfunktion überwacht werden.
●
Erster Schritt im Schnittstellenmanagement ist die Identifikation der Arbeitspakete oder Module, zwischen denen Abhängigkeiten bestehen. Module sind Aufgabenbündel, die jeweils einem Einzelprojekt
zuzuordnen und gegenüber anderen Aufgabenbündeln klar abgrenzbar sind. Um einen unmittelbaren Be zug zum Terminmanagement der Einzelprojekte herzustellen, sollten Abhängigkeiten auf Ebene von Modulen, nicht auf Ebene der Einzelprojekte gemanagt werden. Die operative Koordinierung erleichtert es
ebenfalls, wenn für alle Module die Verantwortlichkeiten und die Bedeutung für die Durchführung des
Einzelprojekts erfasst werden, wenn also klar ist, ob ein Modul unmittelbar auf dem kritischen Pfad des
Einzelprojekts liegt.
●
Im zweiten Schritt werden dann die Abhängigkeiten zwischen Modulen dokumentiert sowie die Art der
Abhängigkeit – am häufigsten sind Startabhängigkeiten, die besagen, dass die Arbeit an Modul Y nicht
beginnen kann, bevor sie an Modul X beendet ist. Hierbei kann sich das Programmmanagement auf einzelprojektübergreifende Abhängigkeiten beschränken, die anderen kontrolliert jede Projektleitung selbst.
Die Anzahl der Abhängigkeiten eines Moduls ist dabei eine gute Maßzahl für die Kritikalität des Moduls.
●
Sofern es sich bei der Zulieferbeziehung um mehr als eine Meldung im Sinne von „Vorarbeiten abge schlossen“ handelt, sollte zwischen Projekten ein fester Übergabepunkt vereinbart und dokumentiert
werden. Insbesondere bei technischen Schnittstellen spezifiziert die Dokumentation Inhalte (z.B. Felder),
Formate (z.B. XML-Spezifikation), Periodizität (wie oft die Lieferung stattfindet, wodurch sie angestoßen wird) sowie Fehlbehandlungsroutinen (welche Rückmeldungen es geben sollte, wenn die Bearbeitung im nachfolgenden Schritt nicht erfolgreich ist). Doch auch bei nicht technischen Schnittstellen (z.B.
Übergabe eines Konzepts) sollten vorher die genauen Inhalte festgelegt werden, um Missverständnisse
zu vermeiden.
→ In vielen Großprojekten entstehen an den Schnittstellen große Reibungsverluste, weil sich beide beteiligten Einzelprojekte auf die Lieferung an die/von der Schnittstelle fokussieren und keine ganzheitli che Sichtweise einnehmen (sondern in ihren „Silos“ verharren). Missverständnisse oder Definitionslücken werden so erst ganz am Ende deutlich und führen häufig zu Verzögerungen. Das Programmmanagement muss hier gegensteuern – entweder wird ein Schnittstellenverantwortlicher benannt oder es
werden frühzeitig durchgängige Tests durchgeführt.
An den Schnittstellen früh durchgängige Tests durchführen
●
Für ein operatives Risikomanagement kann das Schnittstellenmanagement weiterhin Ereignisse strukturiert erheben, die Auswirkungen auf Module haben. Die Auswirkungen sollten möglichst quantitativ abgeschätzt werden (z.B. als Zeitverzögerung oder als Bedarf an zusätzlichen Ressourcen).
Schnittstellen und Abhängigkeiten verknüpfen Arbeitspakete inhaltlich und zeitlich; Verschiebungen bei einem vorgelagerten Modul verzögern nachfolgende. Aus diesem Grunde sollten Module mit Abhängigkeiten
hinsichtlich der Einhaltung des Zeitplans genau kontrolliert werden, z.B. durch die monatliche Erfassung von
prognostizierten Start- und Endterminen sowie Ressourcenbedürfnissen. Die von den Teilprojekten gemeldeten Daten müssen untereinander mit Hilfe der identifizierten Schnittstellen abgeglichen und gegebenenfalls
korrigiert werden, betroffene Projekte müssen von Verschiebungen in Kenntnis gesetzt werden.
Technische Programmsteuerung
Standards prüfen, Programmstruktur prüfen/anpassen
Hierzu zählt die regelmäßige Überprüfung der Standards auf Einhaltung sowie eventuell die Anpassung bei
neuen Versionen oder Anforderungen. Ebenso gehört hierzu die Überprüfung der Entscheidungsregeln sowie
der Struktur der Programmgremien – sind diese noch effektiv? Gerade in lang laufenden Programmen sind
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
172
8 Erweiterung der Managementdisziplinen
periodische Änderungen an den Gremienstrukturen oder den Mitgliedern empfehlenswert, um den Arbeits willen und die Aufmerksamkeit der Mitglieder hoch zu halten.
Planung/Controlling Meilensteine, Migrationsplanung
Das Programmmanagement muss versuchen, aus den Teilprojektplänen der Einzelprojekte einen kritischen
Pfad für das Gesamtprogramm abzuleiten. Das Termincontrolling kann sich an diesem übergreifenden Pfad
orientieren. Die Ableitung erfordert allerdings ein recht tiefgreifendes Verständnis der Einzelprojekte.
Das Thema Migrationsplanung befasst sich mit der Orchestrierung der dezentralen Produktivsetzungen. Zu
klärende Fragen sind:
●
Welche Voraussetzungen sind für lokale Einheiten zu schaffen, damit die jeweilige Migration problemlos
ablaufen kann?
●
In welcher Reihenfolge muss ein Rollout bei den beteiligten Einheiten ablaufen? Welche sollten Piloteinheiten werden? Welche Abhängigkeiten gibt es im Ablauf der Rollouts? Ist es beispielsweise nötig, zuerst in einer Entität zu starten, bevor eine andere an der Reihe ist?
●
Gibt es limitierende Faktoren, die eine Migration bei einzelnen Einheiten verhindern oder stark verzö gern können? (Diese sollten nicht zu früh im Gesamtplan liegen, wenn das Rollout-Team noch nicht viele Erfahrungen gesammelt hat.)
●
Welche Konsequenzen hat die Migrationsplanung auf die beteiligten Einheiten (beispielsweise Parallelbetrieb von Anwendungen)? Wie wird deren Kompatibilität sichergestellt? Welche zusätzlichen Kosten
werden verursacht? Sind sich die Stakeholder dieser Zusammenhänge bewusst und tragen sie diese mit?
Planung/Controlling Budget, Allokation Risikopuffer
Die Einzelprojekte sollten weiterhin für ihre Einzelbudgets verantwortlich sein, allerdings im Rahmen eines
Gesamtbudgets, für den das Programmmanagement verantwortlich ist. Um ein finanzielles Incentive für die
Involvierung des Programmmanagements zu schaffen, sollten die Risikomittel, aus denen beispielsweise
Change Requests bezahlt werden, zentral beim Programmmanagement liegen.
Übergreifendes Risikomanagement
Auch hier gilt, dass die Einzelprojekte weiterhin für ihre Risiken verantwortlich sein sollten. Allerdings müssen die Dokumente des Risikomanagements übergreifend durch das Programmmanagement konsolidiert
werden, um Gesamtauswirkungen gerade von Änderungen im Umfeld abschätzen zu können.
Übergreifendes Kommunikations- und Veränderungsmanagement
Stakeholder-Alignment sichern
Übergreifende Kommunikation planen/durchführen
Übergreifende Maßnahmen des Veränderungsmanagements durchführen
Für alle diese Aufgaben gelten die Ausführungen der Kapitel Kommunikationsmanagement und Veränderungsmanagement analog.
8.1.5 Erfolgsmessgrößen: Woran kann der Auftraggeber ein gutes Programmmanagement
erkennen?
Ein erfolgreiches Programmmanagement berücksichtigt alle Disziplinen des GroßPM. Ein besonderer Fokus
liegt dabei auf der Programmorganisation und dem Stakeholdermanagement. Darüber hinaus sind ein leistungsfähiges Schnittstellenmanagement und eine stringente Migrationsplanung erfolgsentscheidend. Hilfreich sind folgende Fragen:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
8.1 Programmmanagement
173
●
Gibt es eine der Größe des Projekts angemessene Programmorganisation, die auch in den Einzelprojek ten ein durchgängiges Management zulässt?
●
Stehen Ressourcen und Mitarbeiter zum richtigen Zeitpunkt bereit?
●
Sind die Rollen im Programm klar definiert, insbesondere zwischen Programm und Einzelprojekten?
Sind jedem Projektleiter die Standards bewusst, die einzuhalten sind?
●
Sind die Teilprojekte so geschnitten, dass eine weitgehende Autonomie sichergestellt ist und es eine minimale Anzahl an Schnittstellen gibt?
●
Sind die Module der Einzelprojekte erfasst und ihre Schnittstellen zueinander definiert?
●
Gibt es eine Erfassung möglicher Ereignisse, die den Fortgang des gesamten Projekts oder von Teilen
davon beeinflussen können, und werden die Auswirkungen bereits im Vorfeld bedacht?
●
Gibt es eine mit allen Beteiligten abgestimmte Migrationsplanung? Sind deren Konsequenzen bekannt
und werden sie von allen mitgetragen?
8.1.6 Grundlegende und weiterführende Literatur
●
Pellegrinelli, Sergio: „Thinking and acting as a great programme manager“, Palgrave McMillan 2008
●
Strategie als Portfolio von Initiativen, vorgestellt in Bryan, Lowell L.: „Just-in-time strategy for a turbu lent world“, McKinsey Quarterly, Juni 2002
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
174
9 Projektmanagement-Standards
9 Projektmanagement-Standards
Das Kapitel enthält Verweise auf verbreitete Standards und Analysen zum Projektmanagement. Die in diesen
Standards enthaltenen allgemeingültigen Aspekte des Projektmanagements werden in diesem Dokument
nicht weiter beschrieben. Für den Einsatz der in diesem Dokument beschriebenen Besonderheiten des Managements von Großprojekten wird vorausgesetzt, dass der Nutzer die Inhalte eines dieser normalen Projekt management-Standards kennt und als Basis anwendet.
9.1 Standards
9.1.1 Project Management Institute: PMBOK® Guide
Link
●
http://www.pmi.org
Organisation
●
●
Non-Profit-Organisation
Hauptsitz in den USA/1969 gegründet
Verbreitung/Fokus
●
●
Weltweiter Fokus; US-Zentrik stark abnehmend
Lokal in 70 Ländern repräsentiert durch so genannte Chapters (z.B. in Deutschland:
FRA, MUC, CGN)
Mitglieder
●
●
> 265.000 weltweit; plus 10 - 15% p.a.
Nur Personenmitgliedschaft
Standard
●
A Guide to the Project Management Body of Knowledge (PMBOK® Guide), mittlerweile
in der 4. Ausgabe, in 10 Sprachen (auch Deutsch), erschienen; 3. Auflage > 2 Mio.
Exemplare
42 Prozesse, 5 Prozessgruppen, 9 Wissensgebiete
Auftragnehmer-SI- und IEEE-Standard
●
●
Zertifizierung
●
●
●
CAPM (Certified Associate in PM)
PMP (PM Professional), 260.000 weltweit, 150.000 USA, 23.000 Europa, 14.000 Indien
(ca. 15 BT für erfahrenen Projektleiter/PM). PMI hat als erste ProjektmanagementOrganisation weltweit die Auftragnehmer-SI/ISO/IEC-17024-Akkreditierung für das PMPZertifizierungsprogramm erhalten
PgMP (Program Management Professional)
Tabelle 17: Informationen zu PMI
Der PMBOK® Guide definiert neun Wissensgebiete zum Projektmanagement. Die Struktur der Kapitel Disziplinen zum Management der strategischen Ausrichtung, Disziplinen zum Management des organisatorischen Umfelds und der Mitarbeiter und Disziplinen zu Systemen, Instrumenten und Werkzeugen des vorliegenden Dokuments orientiert sich an diesen Wissensgebieten, mit folgenden Ausnahmen:
●
Ergänzt wurde ein Kapitel zum Thema Festlegung/Überprüfung der Projektrahmenbedingungen. Die
Projektrahmenbedingungen werden in der Projektanbahnungsphase festgelegt und bestimmen entscheidend über Erfolg oder Misserfolg eines IT-Großprojekts. Aus diesem Grund werden die wesentlichen
Prozesse zur Festlegung der Rahmenbedingungen in einem separaten Kapitel aufgeführt. Dieses Kapitel
enthält auch Aspekte des Wissensgebiets Integrationsmanagement.
●
Ergänzt wurde ein Kapitel zum Thema Projektorganisation. Große, komplexe IT-Projekte zeichnen sich
unter anderem durch eine entsprechend komplexe Projektorganisation aus mit mehreren Führungsebenen, einer Vielzahl von Teilprojekten sowie einer differenzierten Definition der Projektrollen. Diesem
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
9.1 Standards
175
Umstand wird durch die Beschreibung der Projektorganisation in einem eigenen Kapitel Rechnung getragen. In PMI ist die Projektorganisation Gegenstand des Personalmanagements.
●
Die Wissensgebiete Kosten- und Terminmanagement wurden in diesem Dokument zu einem Kapitel Planung zusammengefasst. Grund sind die engen Verknüpfungen zwischen den Planungsdimensionen des
Terminmanagements (im Wesentlichen Aufwand, Termine, Ressourcen) und der Planungsdimension
Kosten.
●
Das Wissensgebiet Integrationsmanagement wurde nicht in einem separaten Kapitel aufgenommen. Die
Inhalte dieses Wissensgebiets sind im Wesentlichen in den übrigen Kapiteln, insbesondere im Kapitel
Festlegung/Überprüfung der Projekt-Rahmenbedingungen, berücksichtigt.
Es ergibt sich folgende Zuordnung der PMI-Wissensgebiete zu den Methodik-Kapiteln dieses Dokuments:
Integrationsmanagement
●
Festlegung/Überprüfung der Projektrahmenbedingungen
Inhalts- und
Umfangsmanagement
●
Anforderungs- und Änderungsmanagement
Terminmanagement,
Kostenmanagement
●
Projektplanung
Qualitätsmanagement
●
Qualitätsmanagement
Personalmanagement
●
●
Personalmanagement
Festlegung/Überprüfung der Projektorganisation
Kommunikationsmanagem
ent
●
Kommunikationsmanagement
Risikomanagement
●
Risikomanagement
Beschaffungsmanagement
●
Vergabe- und Vertragsmanagement
Tabelle 18: Zuordnung der PMI-Wissensgebiete zu den Methodik-Kapiteln dieses Dokuments
9.1.2 UK Government: Prince2
Link
●
●
http://www.ogc.gov.uk/methods_prince_2.asp
http://www.prince2-deutschland.de
Organisation
●
UK Government: OGC (Office of Government Commerce)
Verbreitung/Fokus
●
●
●
Prüfungen in 56 Ländern
Lokale/nationale Vereinigungen (z.B. Prince2 Deutschland e.V.)
Der Standard in GB, sehr stark im Bereich Public (GB, DK, Projektleiter, …)
Mitglieder
●
●
Mitgliedschaft in zentraler Best-Practice User Group (BPUG®)
Mitgliedschaft in lokalen/nationalen Vereinigungen (z.B. 18 Firmen in D)
Standard
●
●
OGC-Manual „Managing Successful Projects with PRINCE2“ – In vielen Sprachen
erhältlich
8 Prozesse, konkrete Vorlagen
●
●
●
PRINCE2 Foundation (Basis)
PRINCE2 Practitioner (> 200.000 weltweit)
Aufwand je 2 - 3 BT
Zertifizierung
Tabelle 19: Informationen zu Prince2
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
176
9 Projektmanagement-Standards
9.1.3 IPMA/GPM: ICB
Link
●
●
http://www.ipma.ch
http://www.gpm-ipma.de
Organisation
●
●
Non-Profit-Organisation
Hauptsitz in CH/1965 gegründet
Verbreitung/Fokus
●
●
Hauptfokus in Europa
40 nationale Projektmanagement-Organisationen (in D: GPM) unter internationalem
Dach (IPMA)
Mitglieder
●
●
> 40.000 weltweit
Personen- und Firmenmitgliedschaft, in der Regel nur auf nationaler Ebene
Standard
●
●
ICB (IPMA Competence Baseline) – nur auf Englisch; deutsche Übersetzung im
Rahmen der NCB (National Competence Baseline)
3 Kompetenzfelder mit 46 Kompetenzen; adressiert auch persönliche Kompetenzen
●
●
●
4 Level (A bis D; D höchstes)
Weltweit ca. 12.000 Level C (≈ PMI PMP)
Aufwendiges Verfahren mit Studienarbeit, Interview, schriftlicher Prüfung etc.
Zertifizierung
Tabelle 20: Informationen zu IPMA/GPM
9.1.4 V-Modell XT / V-Modell XT Bund
Link
●
http://www.v-modell-xt.de
Organisation
●
Eingetragene Marke der Bundesrepublik Deutschland gepflegt durch den WEIT e.V.
Verbreitung/Fokus
●
Systementwicklungsprojekte in der Industrie und Verwaltung
Mitglieder
●
Siemens AG, EADS AG, 4Soft GmbH, Fraunhofer Gesellschaft, IABG mbH, TU
Clausthal, TU München, Bundesrepublik Deutschland
Standard
●
V-Modell XT 1.4: Standard zur Planung und Durchführung von
Systementwicklungsprojekten
Vorgabe standardisierter Vorgehensweisen, zugehöriger Aktivitäten, Ergebnisse und
verantwortlicher Rollen
●
Zertifizierung
●
Umfassendes Verfahren mit schriftlicher Prüfung zur Personenzertifikation mit den
Stufen Pro, Ping und Asor, sowie Zertifikate für konforme bzw. äquivalente
Vorgehensmodelle (Konf) und V-Modell-XT-konforme Projektdurchführung (Pur)
Tabelle 21: Informationen zu V-Modell XT
Nutzung der S-O-S-Methode© im Zusammenspiel mit dem V-Modell XT
In der öffentlichen Verwaltung ist für die Durchführung von IT-Systementwicklung, insbesondere von Soft wareentwicklungsprojekten, die Anwendung des V-Modells XT vorgeschrieben. Das V-Modell definiert je
nach Projekttyp und -merkmalen das Vorgehensmodell für die Projektdurchführung. Es beschreibt die möglichen durchzuführenden Aktivitäten, die festzulegenden Projektrollen und deren Verantwortlichkeiten sowie
die zu erstellenden Zwischen- und End-Produkte. Die vom V-Modell abgedeckten Themen bieten dabei eine
detaillierte Basis für Systementwicklungsprojekte. Gleichzeitig geht die S-O-S-Methodik bei den Projektma-
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
9.1 Standards
177
nagement-Themen tiefer als das V-Modell, da sie sich konkret auf Großprojekte fokussiert und bei diesen
nicht nur das „Was“ vorgibt, sondern auch Vorschläge zum „Wie“ macht.
Das V-Modell XT Bund ist eine behördenspezifische Erweiterung des V-Modell XT. Auftraggeberin war die
Beauftragte der Bundesregierung für Informationstechnik. Da das V-Modell XT sowohl für die öffentliche
Hand als auch für die freie Wirtschaft gilt, kann es organisatorische Besonderheiten in der Öffentlichen Ver waltung nicht berücksichtigen. Das V-Modell XT Bund bietet die Integration mit anderen Bundesstandards,
behördentypische Rollen, Dokumente im Corporate Design des Bundes, Dokumentvorlagen mit vordefinierten Texten und die Abstimmung mit dem IT-Betrieb schon während der Entwicklung.
Das V-Modell XT Bund wurde in die Version 2.0 der S-O-S-Methode integriert und dabei insbesondere die
in beiden Standards definierten Produkte und Rollen vereinheitlicht. Zudem wurde die S-O-S-Methode um
ein zusätzliches Kapitel zur Beschreibung der V-Modell-spezifischen Umfänge ergänzt. Es ist nun auch möglich, direkt im Editor des V-Modell XT die Projektmanagement-Themen der S-O-S-Methode aufzurufen.
Die folgenden Zuordnungstabellen zeigen für jedes Produkt im V-Modell XT Bund, in welchem Kapitel der
vorliegenden S-O-S-Methode ggf. nähere Erläuterungen zum „Wie“ zu finden sind. Das V-Modell XT Bund
lässt sich in die Bereiche Projektmanagement und Systementwicklung gliedern; je Bereich gibt es eine Tabelle.
A.) V-Modell-Bereich Projektmanagement
V-Modell XT Bund
Projektmanagement-Disziplin S-O-S-Methode©
Produkte der V-Modell-Disziplin „Planung und
Steuerung"
Projektauftrag
5.1 Festlegung/Überprüfung Projektrahmenbedingungen
Projektfortschrittsentscheidung
7.1 Projektplanung
Projekthandbuch
5.1 Festlegung/Überprüfung Projektrahmenbedingungen
QS-Handbuch
7.3 Qualitätsmanagement
Projektmanagement-Infrastruktur
sämtliche Projektmanagement-Disziplinen
Schätzung
7.1 Projektplanung
Risikoliste
7.4 Risikomanagement
Projektplan
7.1 Projektplanung
Aufgabenliste
7.1 Projektplanung
WiBe Version 1 (Vorkalkulation)
5.1 Festlegung/Überprüfung Projektrahmenbedingungen
WiBe Version 2 (Zwischenkalkulation)
5.1 Festlegung/Überprüfung Projektrahmenbedingungen
WiBe Version 3 (Freigabekalkulation)
5.1 Festlegung/Überprüfung Projektrahmenbedingungen
Produkte der V-Modell-Disziplin „Berichtswesen"
Besprechungsdokument
6.3 Kommunikationsmanagement
Projektstatusbericht (von AN)
6.3 Kommunikationsmanagement
Projektabschlussbericht (von AN)
6.3 Kommunikationsmanagement
Projekttagebuch
Keine S-O-S-Entsprechung
Messdaten
7.1 Projektplanung
Kennzahlenauswertung
7.1 Projektplanung
Projektstatusbericht
6.3 Kommunikationsmanagement
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
178
9 Projektmanagement-Standards
V-Modell XT Bund
Projektmanagement-Disziplin S-O-S-Methode©
QS-Bericht
7.3 Qualitätsmanagement
Projektabschlussbericht
6.3 Kommunikationsmanagement
Produkte der V-Modell-Disziplin „Konfigurations- und
Änderungsmanagement"
Problemmeldung/Änderungsantrag
7.2 Anforderungs- und Änderungsmanagement
Problem-/Änderungsbewertung
7.2 Anforderungs- und Änderungsmanagement
Änderungsentscheidung
7.2 Anforderungs- und Änderungsmanagement
Änderungsstatusliste
7.2 Anforderungs- und Änderungsmanagement
Produktbibliothek
Keine S-O-S-Entsprechung
Produktkonfiguration
Keine S-O-S-Entsprechung
Produkte der V-Modell-Disziplin „Prüfung"
Prüfspezifikation Dokument
7.3 Qualitätsmanagement
Prüfprotokoll Dokument
7.3 Qualitätsmanagement
Prüfspezifikation Prozess
7.3 Qualitätsmanagement
Prüfprotokoll Prozess
7.3 Qualitätsmanagement
Prüfspezifikation Benutzbarkeit
7.3 Qualitätsmanagement
Prüfprotokoll Benutzbarkeit
7.3 Qualitätsmanagement
Prüfspezifikation Inbetriebnahme
Keine S-O-S-Entsprechung
Prüfprotokoll Inbetriebnahme
Keine S-O-S-Entsprechung
Prüfspezifikation Systemelement
7.3 Qualitätsmanagement
Prüfprozedur Systemelement
7.3 Qualitätsmanagement
Prüfprotokoll Systemelement
7.3 Qualitätsmanagement
Prüfspezifikation Lieferung
5.2 Vergabe- und Vertragsmanagement
Prüfprotokoll Lieferung
5.2 Vergabe- und Vertragsmanagement
Prüfspezifikation Produktkonfiguration
7.3 Qualitätsmanagement
Prüfprotokoll Produktkonfiguration
7.3 Qualitätsmanagement
Nachweisakte
7.3 Qualitätsmanagement
Produkte der V-Modell-Disziplin „Ausschreibungswesen
(Vergabeakte)"
Vergabevermerk
Ausschreibungskonzept
5.2 Vergabe- und Vertragsmanagement
Bewertungsmatrix
5.2 Vergabe- und Vertragsmanagement
Vergabeunterlagen (Ausschreibung)
5.2 Vergabe- und Vertragsmanagement
Angebotsbewertung
5.2 Vergabe- und Vertragsmanagement
Angebot (von AN)
Keine S-O-S-Entsprechung
Produkte der V-Modell-Disziplin „Vertragswesen"
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
9.1 Standards
179
V-Modell XT Bund
Projektmanagement-Disziplin S-O-S-Methode©
Vertragsübersicht
5.2 Vergabe- und Vertragsmanagement
Vertrag
5.2 Vergabe- und Vertragsmanagement
Vertragszusatz
5.2 Vergabe- und Vertragsmanagement
Lieferung (von AN)
Keine S-O-S-Entsprechung
Abnahmeerklärung
5.2 Vergabe- und Vertragsmanagement
Produkte der V-Modell-Disziplin „Angebots- und
Vertragswesen"
Lieferung
Keine S-O-S-Entsprechung
Produkte der V-Modell-Disziplin „IT-Organisation und
Betrieb"
Betriebliche Freigabeerklärung
Keine S-O-S-Entsprechung
IT-Sicherheitskonzept
Keine S-O-S-Entsprechung
Datenschutzkonzept
Keine S-O-S-Entsprechung
Beitrag zum IT-Sicherheitskonzept
Keine S-O-S-Entsprechung
Beitrag zum Datenschutzkonzept
Keine S-O-S-Entsprechung
Leistungsvereinbarung (SLA/OLA/UC)
Keine S-O-S-Entsprechung
Tabelle 22: Gegenüberstellung V-Modell-Produkte des Bereichs Projektmanagement zu ProjektmanagementDisziplinen der S-O-S-Methode©
B.) V-Modell-Bereich Entwicklung
V-Modell XT Bund
Projektmanagement-Disziplin S-O-S-Methode©
Produkte der V-Modell-Disziplin „Anforderungen und
Analysen"
Die in dieser V-Modell-XT-Disziplin enthaltenen
Aktivitäten und Produkte dienen im Wesentlichen der
inhaltlichen Beschreibung eines IT-Systems, nicht der
Festlegung der Projektmanagement-Prozesse. Es gibt
somit in der S-O-S-Methode© nur wenige
Entsprechungen.
Anwenderaufgabenanalyse
Keine S-O-S-Entsprechung
Projektvorstudie
5.1 Festlegung/Überprüfung Projektrahmenbedingungen
Anforderungen (Lastenheft)
7.2 Anforderungs- und Änderungsmanagement
Anforderungsbewertung
7.2 Anforderungs- und Änderungsmanagement
Altsystemanalyse
Keine S-O-S-Entsprechung
Marktsichtung für Fertigprodukte
Keine S-O-S-Entsprechung
Make-or-Buy-Entscheidung
Keine S-O-S-Entsprechung
Lastenheft Gesamtprojekt
7.2 Anforderungs- und Änderungsmanagement
Bewertung Lastenheft Gesamtprojekt
7.2 Anforderungs- und Änderungsmanagement
Produkte der V-Modell-Disziplin „Systemelemente"
Die in den folgenden V-Modell XT Disziplinen enthaltenen
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
180
9 Projektmanagement-Standards
V-Modell XT Bund
Projektmanagement-Disziplin S-O-S-Methode©
Aktivitäten und Produkte dienen der Erzeugung eines ITSystems, nicht der Festlegung der ProjektmanagementProzesse. Es gibt somit in der S-O-S-Methode© keine
Entsprechung.
alle Produkte
Keine S-O-S-Entsprechung
Produkte der V-Modell-Disziplin „Systementwurf"
alle Produkte
Keine S-O-S-Entsprechung
Produkte der V-Modell-Disziplin „Logistikelemente"
alle Produkte
Keine S-O-S-Entsprechung
Produkte der V-Modell-Disziplin „Systemspezifikationen"
alle Produkte
Keine S-O-S-Entsprechung
Tabelle 23: Gegenüberstellung V-Modell-Produkte des Bereichs Entwicklung zu Projektmanagement-Disziplinen der S-O-S-Methode©
Der Vergleich des V-Modells XT Bund mit der S-O-S-Methode© zeigt deutliche Übereinstimmungen in allen Themen des Projektmanagements, jedoch keine Überschneidungen bei Themen, die sich direkt auf die
Systemerstellung beziehen. Letztere sind nur im V-Modell XT Bund ausführlich beschrieben.
Zur methodischen Unterstützung eines IT-Großprojekts schlägt das CC GroßPM für das Zusammenspiel von
V-Modell XT Bund und S-O-S-Methode© folgendes Vorgehen vor:
1. Für jedes Systemerstellungsprojekt der öffentlichen Verwaltung ist zunächst das V-Modell XT Bund
zu konfigurieren, das heißt per Tailoring projektspezifisch anzupassen. Dabei werden anhand des
Projekttyps bzw. einer möglichen Projekttypvariante die anzuwendenden Vorgehensbausteine des VModells XT Bund festgelegt.
2. Das Tailoring liefert dann eine Liste der zu erstellenden Produkte.
3. Zeigen die oben aufgeführten Zuordnungstabellen eine inhaltliche Überschneidung mit der S-O-SMethode©, sollten bei der Durchführung der Aktivitäten bzw. bei der Erstellung der Produkte die in
der S-O-S-Methode© angegebenen Hinweise und Methoden beachtet werden. Ebenso kann die Projektleitung entscheiden, die Gestalt und Struktur der zu erstellenden Produkte an die S-O-S-Methode© anzupassen.
In diesem Sinne ergänzen sich V-Modell XT Bund und S-O-S-Methode: Während das V-Modell sämtliche
Produkte und Aktivitäten des allgemeinen Projektvorgehens definiert, steuert die S-O-S-Methode die Besonderheiten des Managements von IT-Großprojekten bei.
Die mit der S-O-S-Methode© gelieferten Vorlagen und Checklisten unterstützen dabei die Durchführung der
Aktivitäten bzw. die Erstellung der Produkte. Insbesondere liefern sie konkrete, im Projekt direkt anzuwendende Dokumente, die sich mit den V-Modell-Produktvorlagen ergänzen. Sie können
●
entweder anstelle der V-Modell-Produkte genutzt werden - oder -
●
in die V-Modell-Produktvorlagen integriert werden - oder -
●
als Referenz für andere V-Modell Produkte verwendet werden.
Beispielsweise kann die S-O-S-Vorlage zur Risikoliste im Projekt direkt genutzt werden, da sie bereits die zu
füllenden Felder für die Risiko-Identifikation und die Maßnahmenplanung konkret vorgibt, während die VModell-Produktvorlage an dieser Stelle im Sinne der Methodenneutralität nur eine allgemeine inhaltliche Beschreibung liefert.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
9.1 Standards
181
Im Rahmen der Weiterentwicklung des V-Modell XT Bund werden die bereits vereinheitlichten Rollen und
Produkte auch in das V-Modell XT Bund integriert. So wird die Auswahl der für das Management von ITGroßprojekten benötigten Umfänge zukünftig bereits im Tailoring möglich sein.
9.1.5 ISO / DIN Normenreihe 69901
Die DIN-Normenreihe DIN 69901-... beschreibt Grundlagen, Prozesse, Prozessmodell, Methoden, Daten,
Datenmodell und Begriffe im Projektmanagement. Unter dem Haupttitel „Projektmanagement; Projektmanagementsysteme; ...“ enthält diese Normenreihe folgende fünf Teile (alle Ausgabedatum Januar 2009):
DIN 69901-1 “...; Grundlagen"
DIN 69901-2 “...; Prozesse, Prozessmodell"
DIN 69901-3 “...; Methoden"
DIN 69901-4 “...; Daten, Datenmodell"
DIN 69901-5 “...; Begriffe"
DIN 69909-2
Die DIN 69909-2 definiert die Prozesse und das Prozessmodell für das Multiprojektmanagement. Es gilt in
Verbindung mit der zuvor genannten DIN 69901-Reihe
ISO 21500:2012
Seit August 2012 liegt die ISO 21500:2012 vor. Sie enthält ein einheitliches und abgestimmtes Basiskonzept
für Projekte. Die Harmonisierung mit anderen Modellen ist im Dezember 2012 noch nicht abgeschlossen.
Das Projektmanagement-Modell nach ISO 21500:2012 gliedert sich in 5 Prozessgruppen (Initiating, Planning, Implementing, Controlling, Closing) mit ca. 40 dem PMBOK® Guide angenäherten Aktivitäten (siehe
Kapitel Project Management Institute: PMBOK® Guide). Die in der ISO 21500:2012 aufgeführten Kompetenzen gleichen in reduzierter Form der ICB 3.0. (siehe Kapitel IPMA/GPM: ICB)
Link: www.din.de
9.2 Sonstige Publikationen und Analysen zum Thema Projektmanagement
9.2.1 Praxisleitfaden Projektmanagement für die öffentliche Verwaltung
Der Praxisleitfaden gibt Empfehlungen für Fach- und IT-Projekte in der öffentlichen Verwaltung des Bundes.
Er definiert einheitliche Begriffe und Konzepte zum Thema Projektmanagement.
Er ist kostenlos erhältlich über den Publikationsversand der Bundesregierung, Artikelnummer BMI08328.
9.2.2 Standish Group Chaos 1
Die Standish Group untersucht regelmäßig die Erfolgsstatistiken und Erfolgskriterien von IT-Projekten:
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
182
9 Projektmanagement-Standards
Abbildung 73: Standish Group – Softwareprojekt-Erfolgsstatistik 1994 bis 2005
Abbildung 73 zeigt, dass sich die Erfolgsstatistik der untersuchten Softwareprojekte seit 1994 leicht verbessert hat. Gründe dafür können eine Professionalisierung im Vorgehen und in der Projektmanagement-Methodik sein, aber auch stärkere Modularisierung von Großvorhaben, zunehmende Zahl von tendenziell erfolgrei cheren kleineren Projekten etc. Das Ziel muss jedoch eine weitere Steigerung der immer noch überwiegend
negativen Erfolgsquote bleiben.
Eine weitere Untersuchung (Chaos 10, Abbildung 74) zeigt die im Laufe der Jahre im Wesentlichen gleichbleibenden Erfolgsfaktoren bei Softwareprojekten, die wesentliche Grundlage bei der Definition der 13 Erfolgsfaktoren der S-O-S-Methode© sind:
Abbildung 74: Erfolgsfaktoren bei Softwareprojekten (Chaos 10)
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
9.2 Sonstige Publikationen und Analysen zum Thema Projektmanagement
183
Link: www.standishgroup.com
9.3 Problemspezifische Projektmanagement- und Vorgehensmodelle
Die oben angegebenen PM-Standards definieren allgemeingültige Begriffe, Strukturen und Prozesse. Projekte mit speziellen Zielen erfordern dagegen meist spezielle Vorgehens- und darauf abgestimmte PM-Modelle.
Die speziellen Vorgehensmodelle entstehen durch Anpassen aus den allgemeingültigen Vorgehensmodellen
und Standards („Tailoring“). Teile des Modells können, bei Bedarf, während der Anpassung übergangen oder
ergänzt/verfeinert werden.
Für spezielle Problemstellungen existieren bereits vorgefertigte spezialisierte Vorgehensmodelle. Beispielweise gibt es spezielle Vorgehensmodelle zur Einführung oder Erweiterung von SAP-Software (z.B. ASAP –
AcceleratedSAP) oder eine Vielzahl von agilen oder evolutionären Lebenszyklus-Modellen (z.B. SCRUM,
XP).
Die Vorgehensmodelle beschreiben sowohl Projektmanagement-Prozesse als auch produkterstellende Prozesse. Beide Prozessgruppen sind teilweise vermischt. Daher wird in diesem Dokument nicht weiter auf diese
Vorgehensmodelle eingegangen. Einem Projektleiter sollte beim Einsatz eines solchen Vorgehensmodells jedoch immer bewusst sein, welche Themengebiete er für eine ganzheitliche Betrachtung des Projektmanage ments abdecken muss und immer wieder hinterfragen, ob er mit dem Vorgehensmodell alle notwendigen
Themen abdeckt.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
184
10 Abgrenzung und Ausblick
10 Abgrenzung und Ausblick
Im folgenden Abschnitt wird kurz auf die an das Projektmanagement angrenzenden Themen eingegangen,
die in der vorliegenden Methodik nicht erläutert werden. Ebenso gibt das Kapitel einen Ausblick, inwieweit
die vorliegende Methodik im Programmmanagement, das heißt im Multi-Projektmanagement zum Einsatz
kommen kann.
10.1 Abgrenzung: weitere im Projektmanagement relevante Themenfelder
Die vorliegende Methodik beschreibt nicht das vollständige Set an Werkzeugen, das ein Projektleiter benötigt. Für einige Themen im Projektmanagement, die z.B. nicht spezifisch für IT-Großprojekte in der öffentli chen Verwaltung sind, sollten Anleitungen und Experten von außerhalb des CC GroßPM herangezogen werden sollten (vgl. auch Kapitel Aufbau und Zweck des Dokuments):
●
Methoden, die speziell auf im Projekt eingesetzte Technologien angepasst sind: Technologische Aspekte
liegen nicht im Fokus der vorliegenden Methode. Die Verbindung entsteht genau dort, wo technologische Probleme die Planung des Projekts beeinflussen. Experten, die sich mit den technologischen Aspekten auseinandersetzen, liefern daher wichtige Daten für das Projektmanagement, jedoch gehört es nicht
zum Aufgabengebiet des Projektmanagers, sich selbst um technologische Details zu kümmern. (Im Gegensatz dazu ist der Projektmanager sehr wohl dafür verantwortlich, dass technologische Probleme gelöst werden, jedoch nicht dafür, wie diese Probleme gelöst werden.)
●
Rechtsangelegenheiten. Ein Grundverständnis für rechtliche Fragestellungen gehört zum Handwerkszeug jedes Projektmanagers. Für Details sind in Großprojekten jedoch immer Experten notwendig, so
dass das Thema hier nicht weiter vertieft wird.
●
Haushaltsrecht. Die Finanzierung des Projekts ist zu klären. Die im Haushaltsrecht liegenden Probleme
sind jedoch unabhängig von der speziellen Projektmanagement-Thematik in Großprojekten. Typischerweise ist die Klärung haushaltsrechtlicher Fragen Experten überlassen.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
11 Anhang
185
11 Anhang
11.1 Weitere Klassifizierungen für IT-Projekte
Es gibt weitere mögliche Klassifizierungen für IT-Projekte, von denen im Folgenden einige der Vollständigkeit halber aufgeführt sind. Es handelt sich dabei um Projektauslöser, Vertragsgestaltung, Abrechnungsmo dus, Projektstandorte, Auftraggeber-Auftragnehmer-Konstellation, beteiligte Organisationseinheiten, Teamzusammensetzung und Kritikalität des zu erstellenden Ergebnisses.
Das CC unterstützt grundsätzlich Projekte mit einer beliebigen Einordnung bezüglich dieser Klassifikatio nen. Es muss jedoch mindestens eines der Kernkriterien zutreffend sein, siehe Kapitel Kriterien von Großprojekten. Teilweise führen die einzelnen Klassen zu besonderen Implikationen im Projektmanagement, die
jeweils kurz genannt werden.
11.1.1 Projektauslöser
Projektauslöser
Beschreibung
Wesentliche Implikationen für das
Projektmanagement
Technologische Anforderung
Durch die Einführung neuer
Erhöhte Risiken auf Grund neuer
Technologien bzw. technologischer
Technologie, eines damit unerfahrenen
Veränderungen: z.B. neue Server, neue Teams, Gefahr der Technikverliebtheit.
Netzinfrastruktur, neues Betriebssystem;
daraufhin Anpassung Anwendungen,
Schulung Mitarbeiter und Anwender
Gesetzliche Anforderung
Auf Grund neuer gesetzlicher
Rahmenbedingungen, Richtlinien und
Arbeitsanweisungen
Insbesondere ist im Gesetz meist ein
fester, oft extrem früher
Einführungstermin vorgegeben
Fachliche Anforderung
Auf Grund neuer BusinessAnforderungen (fachliche
Anforderungen implementieren; neue
oder veränderte Geschäftsprozesse
unterstützen bzw. überhaupt erst
möglich machen,
Transformationsprojekte mit
erforderlicher Systemunterstützung für
die und nach der
Umgestaltung/Neuausrichtung
kompletter Geschäftsbereiche
Erhöhte Aufmerksamkeit für die
Einbindung der entsprechenden
fachlichen Know-how-Träger
Tabelle 24: Auslöser für IT-Projekte
11.1.2 Vertragsgestaltung
IT-Projekte können nach der Art der Vertragsgestaltung unterschieden werden. Grundsätzlich können einen
Werkvertrag oder einen Dienstvertrag zwischen Auftraggeber und Auftragnehmer abgeschlossen werden.
Projektmanagement-Implikationen ergeben sich im Vertragsmanagement, z.B. ist auf die besonderen Auswirkungen auf die Gewährleistung zu achten. Beispielsweise sind für kritische Systeme Betrieb und Wartung
des Systems ab dem Zeitpunkt der Abnahme/Inbetriebnahme sicherzustellen. Für die Wartung sind entspreS-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
186
11 Anhang
chende Verträge abzuschließen, in denen die Servicelevels für Fehlerbehebung und die Durchführung von
Änderungen vereinbart sind.
Zu weitergehenden Ausführungen siehe Kapitel Vergabe- und Vertragsmanagement.
11.1.3 Abrechnungsmodus
Auch der Abrechnungsmodus zwischen Auftraggeber und Auftragnehmer kann in Projekten unterschiedlich
sein. Es lassen sich unter anderem folgende Abrechnungsmodelle unterscheiden: Abrechnung nach Festpreis,
Abrechnung nach Aufwand bzw. Time & Material, Lizenzmodelle, Preis je Function Point bzw. Use Case
Point und diverse Mischformen.
Je nach Abrechnungsmodus ergeben sich Implikationen für die Projektmanagement-Bereiche Kosten- und
Vertragsmanagement, insbesondere bezüglich des Kostencontrolling und der Verwaltung von Zahlungen.
Festpreisprojekte haben beispielsweise festgelegte Meilensteine, denen Zahlungsmeilensteine zugeordnet
sind. Im Vertragsmanagement ist sicherzustellen, dass der Meilenstein inhaltlich tatsächlich erreicht ist.
11.1.4 Projektstandorte
IT-Projekte können sich durch Anzahl und Art der Entwicklungs-/Durchführungsstandorte unterscheiden.
Das Projekt kann an einem oder mehreren Standorten abgewickelt werden. Sonderfälle ergeben sich aus der
Projektabwicklung an Nearshore- oder Offshore-Standorten, da zusätzlich unterschiedliche Sprachen
und/oder unterschiedliche Zeitzonen eine Rolle spielen.
Das Projektmanagement berücksichtigt unterschiedliche Projektstandorte insbesondere bei der Projektorganisation, beim Kommunikationsmanagement und beim Vorgehensmodell, das auf die Abwicklung an unterschiedlichen Standorten ausgerichtet sein muss.
Für die Arbeit an unterschiedlichen Standorten ist z.B. sicherzustellen, dass alle Projektmitarbeiter zeitnah
mit den für ihre Arbeit notwendigen Informationen versorgt werden.
11.1.5 Auftraggeber-Auftragnehmer-Konstellation
Für das Auftraggeber-Auftragnehmer-Verhältnis gilt: Projekte haben typischerweise einen Auftraggeber, in
Ausnahmefällen können aber auch mehrere Auftraggeber für unterschiedliche Teilergebnisse des Gesamtprojektergebnisses definiert sein. Umgekehrt kann es einen oder mehrere Auftragnehmer geben. Ein Sonderfall
ist die Generalunternehmerschaft eines Auftragnehmers, der damit die Gesamtverantwortung für ein Ergebnis übernimmt und die Zulieferung weiterer Unterauftragnehmer steuert.
Es ergeben sich Implikationen für das Projektmanagement mit unterschiedlichen Schwerpunkten bezüglich
Auftraggeber und -nehmer. Insbesondere die Planung, das Kommunikationsmanagement und das Vertragsmanagement reagieren auf die besonderen Auftraggeber-Auftragnehmer-Konstellationen.
So ist beispielsweise bei einem Auftraggeber-Auftragnehmer-Verhältnis im Kommunikationsmanagement
darauf zu achten, dass der Auftraggeber z.B. über ein entsprechendes Berichtswesen über den aktuellen Sta tus des Projekts informiert bleibt.
11.1.6 Beteiligte Organisationseinheiten
Ein IT-Projekt kann Auswirkungen in einer oder mehreren Organisationseinheiten (Entitäten) haben. Diese
liefern Anforderungen an das Projektergebnis oder übernehmen Tätigkeiten im Rahmen von Test und Abnahme.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
11.1 Weitere Klassifizierungen für IT-Projekte
187
Im Projektmanagement hat dies insbesondere Auswirkungen auf das Kommunikationsmanagement und die
Projektorganisation.
Im Kommunikationsmanagement ist z.B. darauf zu achten, dass jede beteiligte Organisationseinheit das Gesamtziel des Projekts kennt und genau ihren eigenen Beitrag zu diesem Ziel einschätzen kann.
11.1.7 Teamzusammensetzung
Das Team eines Projekts kann sich aus Mitarbeitern einer Organisationseinheit oder Firma zusammensetzen
oder aus Mitarbeitern mehrerer Organisationseinheiten/Firmen, die gemeinsam in einem Teilprojekt ein Ergebnis erzeugen („gemischtes Team“).
Das Projektmanagement reagiert auf unterschiedliche Teamzusammensetzung im Personalmanagement und
im Kommunikationsmanagement. Auch die Planung berücksichtigt unterschiedliche Fähigkeiten und Fertigkeiten der unterschiedlichen Teammitglieder.
Im Personalmanagement ist beispielsweise darauf zu achten, dass Mitarbeiter aus unterschiedlichen Organisationseinheiten durch entsprechende Vereinbarungen mit diesen Organisationseinheiten ausreichend Kapazität für die Projektarbeit einsetzen können.
11.1.8 Kritikalität des zu erstellenden Ergebnisses
Die durch Projekte erzeugten Ergebnisse besitzen eine Kritikalität, die sich danach bemisst, welche Auswir kungen ein fehlerhaftes Verhalten des Ergebnisses hat. Die Bandbreite reicht von der Gefahr für Menschenle ben über den Verlust von Vermögenswerten bis zu geringen Auswirkungen.
Das Projektmanagement reagiert auf unterschiedliche Kritikalität sowohl im Risiko- und Qualitätsmanage ment als auch im Kommunikationsmanagement.
Im Qualitätsmanagement ist beispielsweise besonderer Wert darauf zu legen, dass die Qualitätsziele für die
als besonders kritisch identifizierten Teile des zu erstellenden Ergebnisses diese Kritikalität berücksichtigen.
11.2 Informationssicherheit in Großprojekten
Das Thema Informationssicherheit hat Auswirkungen auf verschiedene Aspekte innerhalb der Projektmanagement-Disziplinen und stellt entsprechend ein Querschnittsthema dar.
Großprojekte betreffen häufig sicherheitskritische Themen oder tangieren diese im Rahmen ihrer Realisierung. Dem korrekten Umgang mit Informationssicherheit kommt nicht zuletzt deshalb eine hohe Bedeutung
zu, da bei Nichtbeachtung eine Verletzung von Projektzielen oder rechtlichen Vorgaben drohen, die sich (je
nach Projektkontext) sogar projektgefährdend auswirken können. So kann beispielsweise das Bürgervertrauen in ein neues eGoverment-Projekt durch einen Informationsverlust bei der Entwicklung so nachhaltig geschädigt werden, dass die spätere Lösung nicht mehr angenommen und damit überflüssig wird – das Projekt
wird zum Misserfolg. Notwendige Sicherheitsüberprüfungen von externen Projektmitarbeitern können zu einer massiven Verzögerung führen, wenn sie in der Projektplanung nicht ausreichend berücksichtigt wurden.
Dieser Anhang gibt Hilfestellungen in Bezug auf das Projektmanagement, wie sicherheitskritische Aspekte in
Großprojekten frühzeitig lokalisiert und berücksichtigt werden können. Ziel ist die Sensibilisierung der Ver antwortlichen in Großprojekten für die Aspekte der Informationssicherheit. Eine vollständige Darstellung aller Aspekte würde den Rahmen an dieser Stelle sprengen. Der Anhang enthält deshalb Verweise auf geeignete, weiterführende Informationen.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
188
11 Anhang
Die folgenden Kapitel definieren anhand eines 5-Phasen-Modells Schritte, mit deren Hilfe Sicherheitsaspekte im Projekt erkannt und mit geeigneten Maßnahmen innerhalb des Projektmanagements adressiert werden
können. Dabei ist es vor der Art des jeweiligen Projektes abhängig, in wie weit bestimmte Aspekte zu berücksichtigen sind. Je nach Projektlage kann es auch notwendig und sinnvoll sein, über die hier angesproche nen Themen hinaus weitere Regelungen und Vorkehrungen zu treffen.
Ergänzt werden diese Phasen durch eine Überprüfung der eingesetzten Maßnahmen (Kontrolle) sowie ggf.
einer notwendigen Anpassung der Planung.
Abbildung 75: Berücksichtigung Informationssicherheit in Großprojekten (Phasen)
11.2.1 Analyse des Sicherheitsbedarfs
(1) Klärung der rechtlichen Rahmenbedingungen
→ Fragestellung: Gibt es im Projektkontext rechtliche Sicherheitsvorgaben die beachtet werden müssen?
Anforderungen: Entsprechende rechtliche Vorgaben sind beispielsweise:
●
Bundesdatenschutzgesetz (BDSG – Anlage zu §9),
●
Sicherheitsüberprüfungsgesetz (SÜG),
●
Abgabenordnung,
●
Sozialgesetzbuch,
●
Verschlusssachenanweisung (Bund/Land).
Je nach Projekt müssen dabei auch internationale Vorgaben in die Betrachtung einbezogen werden. Häufig
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
11.2 Informationssicherheit in Großprojekten
189
setzen diese Gesetzesauflagen die Umsetzung eines IT-Sicherheitsstandards wie z. B. ISO2700 (EN-1101)
oder BSI IT-Grundschutz (EN-1102) einschließlich entsprechender Audits voraus. Neben gesetzlichen Vorgaben sind auch vertragliche Vereinbarungen mit Auftraggebern, Auftragnehmern und sonstigen Partnern
zu beachten (siehe auch Kapitel Vergabe- und Vertragsmanagement).
Rechtlichen Rahmen klären
(2) Ermittlung des Schutzbedarfs
→ Fragestellung: Besteht über gesetzliche Auflagen hinaus ein erhöhter Sicherheitsbedarf im Projekt?
Anforderung: Hierbei hilft die Klassifizierung des Projektes anhand der drei Schutzziele Verfügbarkeit,
Vertraulichkeit und Integrität (angelehnt an den IT-Grundschutz).
●
Vertraulichkeit: Wie sensibel sind die Projektinhalte und -ergebnisse und sind diese ggf. besonders vor
Unbefugten zu schützen? Hierbei ist auch der Schaden zu berücksichtigen, der durch eine unberechtigte
Veröffentlichung von Projektinformationen entstehen kann.
●
Verfügbarkeit: Wie verfügbar müssen Projektinhalte und -ergebnisse sein? Insbesondere ist hier zu bewerten, mit welchen Problemen der Verlust von Projektinhalten und Ergebnissen behaftet ist.
●
Integrität: Wie wichtig ist die Unverfälschtheit und Echtheit von Projektinhalten und -ergebnisse
Schutzbedarf ermitteln
11.2.2 Ermittlung der Auswirkungen des Sicherheitsbedarfs auf das Projekt
(1) Planung und Bereitstellung von Ressourcen
→ Je nach Ergebnis der Prüfungen nach Kap. Analyse des Sicherheitsbedarfs müssen für die Etablierung
eines adäquaten Sicherheitsniveaus mehr oder weniger Ressourcen (Mitarbeiter, technische Maßnahmen,
zeitliche Mehraufwände) eingeplant werden. Durch die Projektleitung (und Teilprojektleitungen?) müssen
gestiegene Zeit- und Kostenaufwände für die nachfolgenden Aspekte bei der Projektplanung berücksichtigt
werden:
●
Sicherheitsüberprüfung von (Fremd-)mitarbeitern
●
Aufnahme von Unternehmen in die Geheimschutzbetreuung
●
Planung und Umsetzung von IT-Sicherheitsmaßnahmen
●
Zertifizierung von Systemen und Organisationen (z. B. nach BSI IT-Grundschutz)
●
Planung und Umsetzung von materiellen Sicherungsmaßnahmen (z. B. Einbruchmeldeanlagen, Härtung der Schließsysteme)
●
Durch Sicherheitsvorgaben bedingte Mehraufwände (z. B. Im Einzelfall Wegfall der Telearbeitsmöglichkeit)
●
Beschaffung und Einbindung von externen Know-how zum Thema Sicherheit in das Projekt
●
Komplexere Arbeitsabläufe (z. B. Registraturverfahren bei der Verschlusssachenverarbeitung)
●
Beschaffung geeigneter Mitarbeiter
●
Einbindung unterstützender Stellen (z. B. Behörden)
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
190
●
11 Anhang
Planung und Koordination des Themas Sicherheit
Die zur Berücksichtigung des Projektaufwandes notwendigen Maßnahmen können sich an Punkt 3 dieses
Anhangs orientieren.
Projektauswirkungen ermitteln und Planung anpassen
11.2.3 Realisierung der Maßnahmen
(1) Entwicklung und Implementierung eines Klassifizierungsschemas für sensible Dokumente, Unterlagen
und Informationen im Projekt
→ Um Informationen korrekt schützen zu können, müssen diese auch als sensibel für Mitarbeiter und Ver antwortliche erkennbar sein. Diese Maßnahme dient auch der Ressourceneinsparung, da nicht sämtliche Informationen geschützt werden müssen, sondern nur solche mit einem hohen Schutzbedarf.
Richtlinien zur Klassifizierung festlegen
(2) Bestimmung klarer Verantwortlichkeiten für Sicherheit im Rahmen des Projektes
→ Die Verantwortlichkeit für die Informationssicherheit im Projekt muss klar geregelt sein. Nicht immer
müssen dabei Verantwortlichkeiten neu vergeben werden, da viele Organisationen bereits über entsprechende Ansprechpartner (z. B. IT-Sicherheitsbeauftragter, Geheimschutzbeauftragter) verfügen. Im Einzelfall
kann es aber gerade bei Großprojekten zweckmäßig sein, einzelne Mitarbeiter im Rahmen des Projektes
mit einer sicherheitsverantwortlichen Rolle zu betrauen.
Verantwortlichkeiten festlegen
(3) Sensibilisierung für das Thema Sicherheit
→ Viele Sicherheitsmaßnahmen sind auf die Mitwirkung der betroffenen Projektmitarbeiter und Stakehol der angewiesen. Regelmäßige Maßnahmen zur Sensibilisierung (Veranstaltungen, E-Mails, …) helfen, die
Aufmerksamkeit der Betroffenen für das Thema wach zu halten. Überdies können die Maßnahmen auch genutzt werden, um auf neue Bedrohungen oder Veränderungen aufmerksam zu machen (siehe auch Kapitel
Veränderungsmanagement).
Sensibilisierung der Stakeholder
(4) Aufbau und Etablierung eines Berechtigungskonzeptes
→ Ein Berechtigungskonzept ist ein elementares Element, um unberechtigten Zugang auf Projektinforma tionen zu verhindern. Ein derartiges Konzept regelt wer Zugang zu sensiblen Informationen und Dokumenten erhalten darf. Als geeignete Form für ein Berechtigungskonzept hat sich eine einfache Tabellenmatrix
erwiesen, die jedem Mitarbeiter bzw. jeder Rolle die entsprechenden Dokumente und Informationen zuord nen kann.
Berechtigungskonzept bzgl. Projektinformationen etablieren
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
11.2 Informationssicherheit in Großprojekten
191
(5) Beachtung von IT-Sicherheit im Projekt
→ Bei der Einrichtung von Sicherheitsmaßnahmen kann auf bestehende Industriestandards wie die ITGrundschutzstandards des BSI (EN-1102) zurückgegriffen werden. Es sollten zumindest die folgenden
Aspekte (abhängig von der in Phase 1 definierten Notwendigkeit) bei einer Umsetzung zusätzlich bedacht
und geprüft werden:
●
Einsatz eines technischen Rechte- und Rollenkonzeptes für IT-Systeme um sicherzustellen, dass jeder
Mitarbeiter nur die notwendigen Zugriffsrechte besitzt.
●
Einsatz von geeigneter Verschlüsselungstechnik bei der Datenübertragung von sensiblen Daten über
das Internet oder andere schwach geschützte Netze.
●
Einsatz von geeigneter Verschlüsselungstechnik zur Sicherung von Clientfestplatten bei Verlust (Dieb stahl).
●
Regelmäßige Sicherung relevanter Daten um Verlust auszuschließen (optimal umfassende Berücksichtigung des Themas im Rahmen eines IT-Notfallkonzeptes nach BSI Standard 100-1).
●
Beschränkung von Administrationsrechten auf IT-Systemen.
●
4-Augen-Prinzip für hochsensible Administrationsvorgänge
IT-Sicherheit im Projektmanagement berücksichtigen
(6) Absicherung der Räumlichkeiten
→ Die Sicherheit eines Projektes hängt auch vom räumlichen Umfeld (Gebäude, Liegenschaften, …) ab.
Generell sollte sich die Absicherung von Gebäuden, Rechenzentren und der Dokumentenaufbewahrung an
den Sicherheitsbedürfnissen des Projektes ausrichten. Ggf. müssen zusätzliche räumliche Sicherheitsmaßnahmen (z. B. Sicherheitstüren, Vereinzelungsanlagen, Einbruchmeldeanlagen, …) getroffen werden.
Räumlichkeiten absichern
(7) Personelle Sicherheit
→ Projekte im öffentlichen Bereich können unter die Regularien des Geheimschutzes fallen. Hier sind u.a.
Mitarbeiter einer entsprechenden Sicherheitsüberprüfung zu unterziehen, die mit besonderen Zeitaufwänden verbunden sind. Neben den Maßnahmen des Sicherheitsüberprüfungsgesetzes (SÜG) kann es auch in
weniger sensiblen Projekten sinnvoll sein, potentielle Mitarbeiter im Rahmen des Arbeitsrechtes vor der
Einstellung zu überprüfen. Diese Überprüfung sollte zumindest die Einsichtnahme in das polizeiliche Führungszeugnis sowie die stichprobenartige Überprüfung von Referenzen (beispielsweise aus Vorprojekten
oder der Kontakt mit früheren Arbeitgebern) beinhalten (siehe auch Kapitel Personalmanagement).
Personelle Sicherheit berücksichtigen
11.2.4 Kontrolle der Maßnahmen
→ Sicherheit ist kein Produkt sondern ein Prozess. Entsprechend müssen einmal getroffene Maßnahmen
auch stetig auf ihre Wirksamkeit hin überprüft werden. Projektumfelder ändern sich schnell und so können
technische Veränderungen an IT-Systemen oder auch Mitarbeiterveränderungen dazu führen, dass Maßnahmen überflüssig sind, nicht mehr gelebt werden oder auch nicht mehr wirksam sind. Eine ständige KontrolS-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
192
11 Anhang
le und Pflege der Sicherheitsmaßnahmen hilft hier, Sicherheitsprobleme und Mehraufwände zu vermeiden
(siehe auch Kapitel Qualitätsmanagement).
Wirksamkeit der Maßnahmen kontrollieren
11.2.5 Anpassung der Planung
→ Final muss regelmäßig überprüft werden, ob die bisher getroffenen Maßnahmen im Rahmen von Projektveränderungen angepasst werden müssen. Eine solche Überprüfung sollte bei größeren Veränderungen
im Projekt jedoch mindestens jährlich erfolgen. Ggf. können Maßnahmen entfallen oder es müssen neue
Maßnahmen getroffen werden (siehe auch Kapitel Projektplanung).
Projektplanung anpassen
11.3 Training und Ausbildung für Projektleiter für Großprojekte
Dieser Anhang soll eine Anregung geben, welche Ausbildung für Projektleiter für Großprojekte sinnvoll bzw.
erforderlich ist, um Großprojekte erfolgreich leiten zu können.
Der Anhang geht zunächst darauf ein, welche Anforderungen an einen Projektleiter von Großprojekten gestellt werden und im Folgenden werden daraus die Trainings- und Ausbildungsschwerpunkte abgeleitet.
Zu den identifizierten Schwerpunkten ist Literatur verfügbar, die geeignet ist, die theoretischen Grundlagen
zu vermitteln. Wichtig ist allerdings, dass das relevante Wissen nicht nur theoretisch erarbeitet, sondern auch
praktisch angewendet und erprobt werden konnte, bevor ein Projektleiter die Verantwortung für ein Großprojekt übernimmt. Dies kann durch Präsenzschulungen unterstützt werden, in denen die praktische Anwendung
der vermittelten Inhalte eingeübt wird und die einen Erfahrungsaustausch mit den anderen Teilnehmern er möglichen. Darüber hinaus sollten die Fähigkeiten zunächst in kleineren Projekten erprobt und verinnerlicht
werden. Insofern ist es erforderlich, potentielle Projektleiter für Großprojekte langfristig zu entwickeln.
11.3.1 Anforderungen an einen Projektleiter für Großprojekte
In folgenden Kapiteln werden Anforderungen an einen Projektleiter für Großprojekte definiert:
●
Kapitel Einleitung / Abgrenzung der S-O-S-Methode©
●
Kapitel Faktoren des Projekterfolgs
●
Kapitel Rollen: Wer macht was im Veränderungsmanagement? / Sieben Anforderungen an den Projektleiter
Die Anforderungen an einen Projektleiter für Großprojekte können in drei Themenkomplexe aufgeteilt werden:
●
●
Methodenkompetenz Projektmanagement
●
Grundlegende Kenntnisse einer Projektmanagement Methodik (beispielsweise nach PMI, PRINCE2 oder der IPMA)
●
„Angemessene Methoden, Verfahren und Werkzeuge“
Kommunikation
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
11.3 Training und Ausbildung für Projektleiter für Großprojekte
●
193
●
„Alignment der maßgeblichen Stakeholder“
●
„Einbeziehung der Nutzer“
●
Mehrsprachigkeit / „Überlegene Kommunikationsfähigkeit in Sprache der Fachbereichsnutzer
und IT-Fachleute besitzen“
●
Orchestrierung / „Alle Projektbeteiligten stets zur konstruktiven und offenen Zusammenarbeit
anhalten und motivieren“
●
Mobilisierung / „Mitarbeiter –auch unter Druck- zu Höchstleistungen motivieren.“
●
Kommunikativer Biss – „Klar verbindlich und unmissverständlich Ziele, Anforderungen und
Fortschritte des Projekt artikulieren“
Motivation / Durchsetzungskraft
→ Nachfolgend wird erläutert, wie Fähigkeiten im Bereich Projektmanagement und Kommunikation erlernt bzw. ausgebaut werden können. Die erforderliche Motivation, um ein Großprojekt erfolgreich zu lei ten, muss beim Projektleiter vorhanden sein – diese kann nicht erlernt werden. Insofern wird auf diesen
Aspekt auch nicht weiter eingegangen.
Projektmanagement-Methodik, Kommunikation und Motivation muss vorhanden sein
11.3.2 Methodenkompetenz Projektmanagement
Ein Projektleiter eines Großprojekts muss über eine ausreichende Kompetenz in einer Projektmanagementmethodik verfügen.
→ Er muss eine anerkannte Projektmanagement-Methode im Detail beherrschen, sie auch bereits in Projekten praktisch angewandt haben und sollte in der Lage sein, die PM-Methoden bedarfsgerecht anpassen und
skalieren zu können.
Die folgenden drei Projektmanagement-Methoden können, aufgrund ihres Reifegrades und ihrer Verbreitung, als anerkannt angesehen werden:
●
Project Management Body of Knowledge (PMBOK Guide) / PMI
●
PRINCE2 / AXELOS
●
IPMA Competence Baseline (ICB) / IPMA, GPM
Die entsprechenden Kenntnisse können im Selbststudium und in Seminaren erworben und durch einen abschließenden Test, der in einer Zertifizierung mündet, nachgewiesen werden.
Zusätzlich werden folgende Methodenkenntnisse für Großprojekte in der öffentlichen Verwaltung empfohlen:
●
S-O-S Methode©
●
V-Modell XT (Bund)
Anerkannte Projektmanagement-Methodik beherrschen
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
194
11 Anhang
11.3.3 Kommunikation
In Großprojekten ist die Kommunikation eine Kernaufgabe für das Projektmanagement (siehe auch Kapitel
Was unterscheidet Großprojekte generell von anderen, kleineren Projekten und welche Konsequenzen ergeben sich daraus für das Projektmanagement?). Hierbei ist zwischen der Projektmanagementdisziplin „Kommunikationsmanagement“ und der persönlichen Kommunikationsfähigkeit des Projektleiters zu unterscheiden. Diese Kapitel fokussiert auf die persönliche Kommunikationskompetenz des Projektleiters. Kommunikationsmanagement wird als Teil der Projektmanagement Methodik durch das vorangegangen Kapitel abge deckt.
Ein Großteil der Kommunikation zu Stakeholdern, beteiligten Parteien und Projektmitarbeitern wird durch
den Projektleiter wahrgenommen. Entsprechend wichtig ist es, dass er über eine entsprechende Kommunikationsfähigkeit verfügt.
→ Für einen Projektleiter von Großprojekten ist es erforderlich, sich mit dem Thema Kommunikation professionell auseinanderzusetzen und seine Kommunikationsfähigkeit zu prüfen und weiterzuentwickeln.
Im Bereich der Weiterentwicklung der persönlichen Kommunikation sind Präsenzschulungen von großem
Nutzen, da Formen/Methoden der Kommunikation praktisch geübt (z.B. in Form von Rollenspielen) und
auch eine direkte Rückmeldung erfolgen kann. Hierzu gibt es eine Reihe von Schulungsangeboten im Be reich der Kommunikation (beispielsweise zum Thema Präsentation, Moderation, Rhetorik, NLP etc.).
Professionelle Auseinandersetzung mit Kommunikation
11.3.4 Grundlegende und weiterführende Literatur
●
Project Management Institute (PMI): „A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fünfte Ausgabe”, PMI 2014
●
Office of Government Commence: “Erfolgreiche Projekte managen mit PRINCE2”, The Stationery
Office Ltd 2009
●
International Projectmanagement Association (IPMA): IPMA Competence Baseline (ICB) 3.0, IPMA
2006
●
Friedemann Schulz von Thun: „Miteinander reden“, Band 1-4, rororo 2014
●
Joseph O'Connor, John Seymour: „Neurolinguistisches Programmieren: Gelungene Kommunikation und
persönliche Entfaltung“, VAK 2010
11.4 Ausführliche Liste aller Vorlagen und Checklisten
Die Methodik des CC GroßPM besteht zum einen aus dem vorliegenden Handbuch, zum anderen aus einer
umfangreichen Liste an Vorlagen und Checklisten, mit denen die hier beschriebenen Endprodukte schnell
und konsistent erstellt werden sollen. Die Dokumente sind in der folgenden Abbildung aufgelistet.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
11.4 Ausführliche Liste aller Vorlagen und Checklisten
Abbildung 76: Vollständige Liste an Dokumenten und Vorlagen
11.5 Glossar
Abnahme
A) Prozess der Prüfung eines Projektergebnisses gegen die für das Ergebnis
geforderten Anforderungen bzw. Eigenschaften; B) formale Bestätigung, dass das
Projektergebnis die geforderten Anforderungen erfüllt.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
195
196
11 Anhang
Agenda Shaping
Häufig wird durch den externen Auftragnehmer, insbesondere bei fortgeschrittenen,
partnerschaftlichen Zusammenarbeiten, die Lösung mitgestaltet („to shape“).
Alignment (engl. für Ausrichtung)
Bezeichnung aus der Biologie, die das Verhalten von Individuen in natürlichen
Schwärmen beschreibt: Die Mitglieder eines Schwarms beobachten ihre Nachbarn
und richten ihre Bewegung an diesen aus. So erreicht der Schwarm eine
geschlossene, gleichgerichtete Fortbewegung. Im GroßPM bezeichnet Alignment der
Stakeholder, dass alle wichtigen Beteiligten die Projektziele und die Kosten-NutzenAnalyse mittragen und dass Kongruenz zwischen den Projektzielen und den Zielen
der Stakeholder besteht. Für mögliche Konflikte sind Entscheidungsregeln festgelegt.
Änderungsmanagement
Prozesse, Methoden und Werkzeuge zur Behandlung bzw. Umsetzung von
Änderungen im Projekt.
Anforderungsanalytiker (fachlicher Rolle im IT-Großprojekt. Der Anforderungsanalytiker ist für die
Chefdesigner)
gesamtprojektübergreifend konsistente Fachlichkeit zuständig.
Anforderungsmanagement
Prozesse, Methoden und Werkzeuge zur Definition des Projektumfangs sowie zur
Behandlung von im Projektverlauf entstehenden Anforderungen, die im
ursprünglichen Projektumgang nicht enthalten sind.
Auftraggeber-Projekt
Ist das vom Projektauftraggeber beauftragte Projekt, das die im Projektauftrag
definierten Ziele des Projektauftraggebers erreichen soll.
Auftragnehmer-(Teil-)Projekt
Ist ein eigenständiges (Teil-)Projekt, das in der Verantwortung eines externen
Auftragnehmers steht und das vertraglich an ein Auftraggeber-Projekt gebunden ist.
Auftragnehmer-Projekt (V-Modell
XT)
Das V-Modell XT verbindet mit dem externen Auftragnehmer ein per Werkvertrag
beauftragtes eigenständiges Auftragnehmer-Projekt (das Produkt „Vertrag“ im VModell meint deshalb immer einen Werkvertrag).
Aufwand
Die für die Lösung eines Problems benötigten Mitarbeiterressourcen, gemessen in
Personenjahren, -monaten oder -tagen. (In diesem Dokument wird der Begriff
ausschließlich im Informatikkontext gebraucht. Es ist explizit nicht der
betriebswirtschaftliche Aufwandsbegriff gemeint.)
Aufwandschätzung
Schätzung des für die Lösung eines Problems nötigen Aufwands (gemessen in
Personentagen); bei IT-Projekten insbesondere die Schätzung des Aufwands, der zur
Erreichung der Projektziele benötigt wird – in Abgrenzung zur Budgetschätzung oder
Zeitschätzung, die die Größe/Länge des Projekts in Euros oder Laufzeit misst.
Betrieb
Phase der produktiven Nutzung eines IT-Systems nach der Inbetriebnahme.
Change Request
Änderungsanforderung
Drill-down
In IT-gestützten Berichten die Möglichkeit, entlang vorgezeichneter Pfade in immer
detailliertere Schnitte und Aufrisse der Daten vorzudringen.
Earned-Value-Analyse
Kennzahlenbasierte Fortschrittsbewertung eines Projekts. Gegenüberstellung von
Planwerten mit Ist-Kosten und definierten Leistungswerten. Verfolgung des Trends im
Zeitverlauf.
Eh-da-Kosten
Fixkosten. Meist verwendet für Personalkosten.
Entwurf
Projektphase, in der die technische Lösung zur Umsetzung der Spezifikation
festgelegt wird.
Fachlichkeit
Summe der fachlichen Anforderungen/das von einem Projekt zu liefernde Ergebnis.
Feinkonzept
Detaillierte Spezifikation eines vom Projekt zu liefernden Ergebnisses.
Function Points
Maß für Aufwand/Größe eines IT-Projekts.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
11.5 Glossar
197
Gesamtprojekt
Projekt, das mehrere Teilprojekte, Führungsebenen und Projektrollen umfasst.
Gesamtprojektleiter
Rolle im IT-Großprojekt. Der Gesamtprojektleiter trägt die operative
Gesamtprojektverantwortung sowie die Gesamtverantwortung für die
Projektergebnisse (Termine, Inhalt und Qualität, Budget) sowie die dafür notwendigen
Projektmanagement-Prozesse.
Grobkonzept
Spezifikation eines vom Projekt zu liefernden Ergebnisses auf hohem
Abstraktionslevel.
Großprojekt
Projekt mit einer Größe von 50 bis 500 Personenjahren.
Großprojektmanagement
Prozesse, Methoden und Werkzeuge zur zielgerichteten Steuerung von
Großprojekten, so dass die Projektziele innerhalb der vorgegebenen
Rahmenbedingungen erreicht werden.
Hardware
physische IT-Güter
Inbetriebnahme
Beginn des produktiven Einsatzes eines IT-Systems/Projektphase, in der die
Inbetriebnahme vorbereitet wird.
Integration
Zusammenfügen von Teilen des Gesamtergebnisses und Sicherstellen, dass die
Einzelteile im Zusammenspiel funktionsfähig sind und die Anforderungen an das
Gesamtergebnis erfüllen.
Key Performance Indicator
Kennzahl, mit der der Fortschritt bzw. der Erfüllungsgrad hinsichtlich der Ziele und
kritischen Erfolgsfaktoren gemessen wird.
Konzeptphase
(Spezifikationsphase)
Projektphase, in der die Spezifikation des Projektergebnisses erarbeitet wird (oft in
weitere Phasen für Grob- und Feinkonzept untergliedert).
Kosten
In Geldeinheiten (Euro) bewerteter Bedarf an Ressourcen, die zur Lösung eines
Problems bzw. zur Erreichung der Projektziele benötigt werden. (In diesem
Dokument wird der Begriff ausschließlich in diesem Sinn gebraucht. Es ist explizit
nicht der betriebswirtschaftliche Kostenbegriff gemeint.)
Lenkungsausschuss
Entscheidungs- und Kontrollgremium des IT-Projekts, in dem Vertreter von
Auftraggeber und -nehmer sowie wesentliche Stakeholder versammelt sind.
Megaprojekt
Projekt mit einer Größe von über 500 Personenjahren.
Nearshore
Auslagerung (von Teilen) der Projektarbeit ins nahegelegene Ausland.
Offshore
Auslagerung (von Teilen) der Projektarbeit ins Ausland.
Personenjahr, -monat, -tag
Maß für den Aufwand: Zeit, die ein Mitarbeiter für ein Projekt bzw. die Lösung eines
Problems einsetzt innerhalb eines Zeitjahres (-monats, -tags).
Programmmanager
Verantwortlicher eines Programms oder eines Megaprojekts.
Project Management Office
(Projektbüro)
Im Project Management Office werden Unterstützungsfunktionen für
Projektmanagement und -abwicklung gebündelt.
Projektanbahnung (Anbahnung,
Anbahnungsphase)
Phase vor Beginn des Projekts, in der dessen Rahmenbedingungen festgelegt
werden.
Projektauftraggeber
Ist die Person oder die Stelle, die das Projekt will, die Gelder bereitstellt und den
Projektauftrag erteilt.
Projektgrößenklassen
Dienen der Einstufung von Projekten nach Aufwand (Min- und Max-Größe).
Projektleiter
Leitet kleine und mittelgroße Projekte.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
198
11 Anhang
Projektmanager
Im Allgemeinen mehrere Bedeutungen: 1.) Oft als Synonym zu Projektleiter
verwendet 2.) Im V-Modell XT Hauptverantwortlicher des Projekts “über“ dem
Projektleiter 3.) In IT-Großprojekten: Der Projektmanager verantwortet einen
Teilbereich des Projekts (alle Ergebnisse der zugeordneten Teilprojekte und Themen)
gegenüber dem Gesamtprojektleiter. Berichtet direkt an den Gesamtprojektleiter.
QS-Verantwortlicher
Rolle im IT-Großprojekt. Der QS-Verantwortliche sorgt für die Umsetzung des
Qualitätsmanagements im Gesamtprojekt.
Qualitätsmanagement
Projektmanagementdisziplin, die für die geforderte Ergebnisqualität sorgt.
Qualitätsmanager
Verantwortlicher für Qualitätsmanagement in der Organisation, der Entität oder dem
Unternehmen.
Request for Change
Änderungsanforderung
Risikomanagement
Projektmanagementdisziplin, die für die Identifikation und Eindämmung von
Projektrisiken sorgt.
Risikomanager
Rolle im IT-Großprojekt. Der Risikomanager ist zuständig für die Analyse und
Bewertung der Risiken sowie für die Definition und Verankerung von
Gegenmaßnahmen.
Scope Creep
Schleichende Ausweitung des Projektumfangs durch eine zunehmende Anzahl von
Änderungsanforderungen im Projektverlauf.
Skill
Fähigkeit
Sponsor
siehe Projektsponsor
Stakeholder
siehe Projektstakeholder
Strategie-Organisation-Systeme
Die drei Erfolgskomponenten des Großprojektmanagements: klare strategische
Ausrichtung, definiertes organisatorisches Umfeld sowie angemessene Systeme,
Methoden und Verfahren.
Systemarchitekt (technischer
Chefdesigner)
Rolle im IT-Großprojekt. Der Systemarchitekt verantwortet die adäquate Technik und
Architektur im Gesamtprojekt.
Teilprojekt
Als Projekt geführter Teil eines Gesamtprojekts, in dem ein Teil der
Gesamtprojektergebnisse erarbeitet wird und/oder der einen Teil der
Gesamtprojektprozesse verantwortet.
Teilprojektleiter
Rolle im IT-Großprojekt. Der Teilprojektleiter ist für das Ergebnis eines Teilprojekts
verantwortlich und berichtet an einen Projektleiter, der wiederum an den
Gesamtprojektleiter berichtet.
Test
Projektphase, in der ein Projektergebnis gegen die Anforderungen geprüft wird.
Trouble Management
Prozess bzw. Organisation zur Behebung eines spezifischen Problems.
Trouble Manager
Rolle im IT-Großprojekt. Der Trouble Manager verantwortet das Ergebnis der ihm
zugeordneten Aufgaben des Trouble Managements.
Umsetzung (Realisierung)
Projektphase, in der die Projektergebnisse erarbeitet werden.
Use Case Points
Maß für Aufwand/Größe eines IT-Projekts.
Veränderungsmanagement
Vorgehen, Methoden, Werkzeuge zur erfolgreichen Einführung umfangreicher
Veränderungen in Fachlichkeit, Organisation und Prozessen.
Vorgehensmodell
Beschreibt Organisation und Prozesse zur Erreichung der einem Projekt gesetzten
Ziele.
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
11.5 Glossar
Vorphase
199
Phase im Vorfeld der Projektanbahnung, in der ein Vorhaben entsteht und geformt
wird, aus dem letztlich der Bedarf für ein oder mehrere Projekte erwächst.
11.6 Abkürzungsverzeichnis
BIT
Bundesstelle für Informationstechnik
BVA
Bundesverwaltungsamt
BzA
Bereitstellung zur Abnahme
CC GroßPM
Kompetenzzentrum Großprojektmanagement
CR
Change Request
EVB-IT
Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen in der
öffentlichen Verwaltung
HW
Hardware
KPI
Key Performance Indicator
LA
Lenkungsausschuss
PL
Projektleiter
PM
Projektmanagement
PM-MTG
Projektmanagement-Meeting
PMO
Project Management Office
Prog-M
Programmmanager
QS
Qualitätssicherung
RFC
Request for Change
S-O-S
Strategie-Organisation-Systeme
SW
Software
TP
Teilprojekt
TPL
Teilprojektleiter
WiBe
Wirtschaftlichkeitsbetrachtung
11.7 Weiterführende Literatur
[Bal1997]
Helmut Balzert (Herausgeber): „Lehrbuch der Softwaretechnik“, Band 2, Spektrum
Akademischer Verlag 1997
[DeM1982]
Tom DeMarco: „Controlling Software Projects – Management Measurement & Estimation“,
Yourdon Press Computing Series 1982
[DL1987]
Tom DeMarco, Timothy Lister: „Peopleware – Productive Projects and Teams“, Dorset House
Publishing 1987
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
200
11 Anhang
[FS2008]
Jan Friedrich, Marc Sihling: Paulas pragmatische Projektführung, erschienen in
Objektspektrum 02/2008, Online-Version
[HKL2005]
Detlev Hoch, Markus Klimmer, Peter Leukert: „Erfolgreiches IT-Management in der
öffentlichen Verwaltung – Managen statt verwalten“, Gabler Verlag 2005
[Mer2008]
Prof. Dr. Dr. h.c. mult. Peter Mertens: „Fehlschläge bei IT-Großprojekten der Öffentlichen
Verwaltung – ein Beitrag zur Misserfolgsforschung in der Wirtschaftsinformatik“, Universität
Erlangen-Nürnberg 2008
[SG1997]
Uwe Schnorrenberg, Gabriele Goebels: „Risikomanagement in Projekten – Methoden und
ihre praktische Anwendung“, Vieweg Verlag 1997
[Sie2003]
Johannes Siedersleben (Herausgeber): „Softwaretechnik – Praxiswissen für
Softwareingenieure“, Hanser Verlag 2003
[WD2006]
John Ward, Elizabeth Daniel: „Benefits Management – Delivering Value from IS & IT
Investments“, Wiley Series in Information Systems 2006
[WR2004]
Peter Weill, Jeanne W. Ross: „IT Governance – How Top Performers Manage IT Decision
Rights for Superior Results“, Harvard Business School Press 2004
11.8 Endnoten
EN-1101
ISO/IEC
27001:
standards/iso27001.htm
http://www.iso.org/iso/home/standards/management-
EN-1102
IT-Grundschutzstandards: https://www.bsi.bund.de/DE/Themen/ITGrundschutz
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)
11.8 Endnoten
201
S-O-S-Methode© für Großprojekte, Version 2.1 (generiert am: 11.09.2015)

Was hat Stuttgart 21 mit der Krise in Europa zu tun?

Schulden – was wirklich auf uns zukommt

Preiskategorien Platzbezeichnung

Wissenschaftlicher Mitarbeiter/​wissenschaftliche Mitarbeiterin am

Das Bewerbungsformular steht hier zum zur Verfügung

PDF erstellen

Informationen für Schulleiter

Verein “bi de Lüüt“ Generalversammlung

Vorschlagsbogen - Stiftung Cusanuswerk

max. 2.000 Zeichen