Die Success Driver Analyse
(SDA) als wirksames
Instrument zur Steuerung
von komplexen IT-Projekten
und -Programmen
Matthias Würgler, SBB IT
Ernest Wallmüller, www.itq.ch
Iqnite 24.09.2013
Inhalt
SBB • Division • Abteilung oder Bereich • DD.MM.YY 2
1. Darstellung der Success Driver Analyse (SDA)
2. Das Qualitätssicherungs-System der IT-Projekte bei der SBB
Informatik
3. Von den Q-Gates Q-Points und anderen Analysemethoden zur
SDA: Erfahrungen und Entwicklungstrends im Projektgeschäft der
SBB IT
4. Die SDA als Teil eines Projekt-/ Programm Frühwarnsystem-/
Indikatorsystems (Projektradar)
1. Darstellung der
Success Driver Analyse (SDA)SBB • Division • Abteilung oder Bereich • DD.MM.YY3
Projects and
SUCCESS DRIVERS … What must be controlled
Risks arise from uncertainty about objectives and situations!
Outcomes / Results
Context of Drivers …
Success factor is the term for an element that is necessary for an organization or project to achieve its mission.
It is a critical factor or activity required for ensuring the success of a company or an organization.
Drivers are influenced by ...
Focus of SDA
Systemic Analysis of Risk
Managing the Potential
for Success
Twenty Questions (Standard Drivers)
Every Program Manageer should be able to answer
Uncertainty Line
shortcomings
SDA: Darstellung der Ergebnisse
2. Das Qualitätssicherungs-System
der IT-Projekte bei der SBBSBB • Division • Abteilung oder Bereich • DD.MM.YY12
Das grösste Transportunternehmen der Schweiz.
13
Personenverkehr977 000 Reisende/Tag
SBB Cargo195 000 t Güter/Tag
Infrastruktur3100 km Netz
Immobilien3500 Gebäude
QM Stufe 1: Projektinterne QS
© SBB • SBB Informatik • 16.08.2011 14
Studie – Detailkonzept: Anforderungen Spezifikationen
Konzipieren, planen wir das Richtige?
Review
Realisierung: SW-Entwicklung
Entwickeln wir richtig (innere SW Qualität)?
Stat. Codeanalyse, Architektur-Review
Realisierung – Einführung: Funktionalität des Systems
Haben wir das Richtige entwickelt?
Test
Studie / Grobkonz. / Detailkonz. / Realisierung/ Einführung
Q-Sicherung
Projekt
Projekt
Sys. Test
Int. Test
Abn. TestCode Assessm.
AR-Rev.Review
Review
QM Stufe 2: Konstruktive QS
© SBB • SBB Informatik • 16.08.2011 15
Methoden, Instrumente, Werkzeuge
Beratungen, Schulungen
Abnahmen, Überprüfungen: Q-Points
Q-Lenkung
Fachbereich
Sys. Test
Int. Test
Abn. TestCode Assessm.
AR-Rev.Review
Review
Methoden / Instrumente / Werkzeuge / Beratung
QP QP QP QP
Studie / Grobk. / Detailk. / Realisierung / EinführungProjekt
Q-Sicherung
Projekt
QM Stufe 3: Steuerung
© SBB • SBB Informatik • 16.08.2011 16
Q-Gates, Projektaudits, SDA
(Q)-Steuerung
Methoden / Instrumente / Werkzeuge / Beratung
QP QP QP QP
Studie / Grobk. / Detailk. / Realisierung / EinführungProjekt
Q-Sicherung
Projekt
Q-Lenkung
Fachbereich
Sys. Test
Int. Test
Abn. TestCode Assessm.
AR-Rev.Review
Review
QG1 QG3 QG4 QG5QG2
3. Von den Q-Gates, Q-Points und anderen
Analysemethoden zur SDASBB • Division • Abteilung oder Bereich • DD.MM.YY17
Das Modell der Projektsteuerung
SBB • Division • Abteilung oder Bereich • DD.MM.YY 18
Erweiterte SWOT- Analyse
SBB • Division • Abteilung oder Bereich • DD.MM.YY 19
SDA: Ergebnisprofil: Driver 11 – 20
SDA: Streuung Driver 11- 20
SDA: Ergebnisse Gesamtübersicht
SBB • Division • Abteilung oder Bereich • DD.MM.YY 22
Zielsetzungen Belastbarkeit
1. Ziele 12. Umgang mit unerwarteten Ereignissen
Vorbereitung Ergebnisse
2. Planung 13. Anforderungen
3. Prozess 14. Design und Architektur
15. Systemfähigkeiten
Umsetzung 16. System-Integration, Zusammenarbeit der Systeme
4. Ausführung der Aufgaben 17. Unterstützung des Betriebs
5. Koordination 18. Akzeptanz
6. Lieferanten und Partner (Ext. Schnittstellen) 19. Vorbereitung des Betriebs (ges. Lebenszyklus)
7. Informationsmanagement 20. Zertifizierung und Zulassung
8. Technologie-/ Werkzeugunterstützung
9. Einrichtung und Ausstattung
Projektspezifische Faktoren
Umfeld 21. Motivation
10. Organisatorisches Umfeld 22. Risiken
11. Compliance (Einhaltung von Vorgaben) 23. Referenzmodelle
SDA: Verschiedene Sichten im Vergleich
SBB • Division • Abteilung oder Bereich • DD.MM.YY 23
SDA: Vergleich zwischen zwei SDA-Runden
Runde 1
Runde 2
SDA: Ergebnis: Planung von SDA, Audits, Q-Gates
SBB • Division • Abteilung oder Bereich • DD.MM.YY 25
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
SDA Assessment SDA
Audit: Risikomanagement
Audit: Software Qualität
Audit: Betrieb und Einführung
Audit: Security
Q-Gate 5 QG5
Q-Point: Testing (TES-01) QP-TES-01
2013 2014 2015
SDA: Vorgehen und Aufwände
SBB • Division • Abteilung oder Bereich • DD.MM.YY 26
1 Einführung in die Methode 1- 2h mit Betroffenen
2 Analyse Projektziele, Risiken
Definition projektspezifische TreiberWorkshop 2-4 h
3 Einschätzung der Treiber
20 – 25 Projektbeteiligte1h/ Person
4 Auswertung der Ergebnisse 4h – 8h (1 Person)
5 Ergebnisse, diskutieren
erste Massnahmen, Risiken identifizieren
Ergebnisse dem Management präsentieren
Workshop 4h
6 Massnahmen umsetzen, Risiken mitigieren
Kontrolle der Umsetzung sicherstellen…
SDA: Vergleich der pilotierten Verfahren
SBB • Division • Abteilung oder Bereich • DD.MM.YY 27
Verf
ah
ren
Pro
ble
m-
frü
herk
en
nu
ng
Verg
leic
hb
ark
eit
Erg
eb
nis
se
Akzep
tan
zvo
n
Ma
ss
na
hm
en
Urs
ach
en
erk
en
nen
Au
fwan
d
Pro
jektt
eam
Au
fwa
nd
Au
dit
tea
m
Projektaudit 30 h 75 h
Erweiterte
SWOT-
Analyse
35 h 20 h
Success
Driver
Analyse
40 h 20 h
Q-Point 6 h 4 h
4. Die SDA als Teil eines
Projekt-/ Programm Frühwarnsystems
(Projektradar)SBB • Division • Abteilung oder Bereich • DD.MM.YY28
Frühwarn-Indikator-System
Regelmässige Analysen auf Stufe
Gesamtprojekt
Kennzahlen zuausgewählteIndikatoren
Projekt-fortschrittZustand der
Erfolgsfaktoren
Status der Arbeitspakete (EV)
Aufwand
Kosten
Erreichte Q-Ziele
Risiken bzw.
Status der Mitigationsmassnahmen
SDA
Zustand bzw. Umsetzungsgrad
der Anforderungen
(Traceability Matrix)
Aufwand für V & V
Testabdeckungsgrad
Abweichungszustand
Fehlerstatistik
Exempel: Project Control Panel
Rechtzeitiges Erkennen einer sich abzeichnenden
Planabweichung
Zeit
Kontrollgrösse
100 %
Verzögerungszeit
Geplanter Verlauf
Unkontrollierter Verlauf
Erkennungszeitpunkte der Planabweichung
1
2
1
2
rechtzeitig
zu spät
Zusammenfassung
SDA bringt bei regelmäßiger Anwendung Transparenz und eine
gute Beurteilung der Erfolgschancen
SDA gibt klare Hinweise auf Abweichungen und mögliche Ursachen
Je grösser, komplexer die Vorgaben, umso früher lohnt sich der
Einsatz von Analysemethoden und hilft rechtzeitig bei der
Kurskorrektur
SDA ist für die SBB Informatik eine ideale Ergänzung der
Projektsteuerung bei grossen IT-Vorhaben
Der Aufwand für eine SDA ist eher kleiner im Vergleich mit andern
Projektassessments oder Audits.