1. 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

2. 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)

3. 1. Darstellung der
Success Driver Analyse (SDA)
SBB • Division • Abteilung oder Bereich • DD.MM.YY3

4. Projects and
SUCCESS DRIVERS … What must be controlled
Risks arise from uncertainty about objectives and situations!

5. Outcomes / Results

6. 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.

7. Drivers are influenced by ...
Focus of SDA

8. Systemic Analysis of Risk

9. Managing the Potential
for Success

10. Twenty Questions (Standard Drivers)
Every Program Manageer should be able to answer

11. Uncertainty Line
shortcomings
SDA: Darstellung der Ergebnisse

12. 2. Das Qualitätssicherungs-System
der IT-Projekte bei der SBB
SBB • Division • Abteilung oder Bereich • DD.MM.YY12

13. Das grösste Transportunternehmen der Schweiz.
13
Personenverkehr
977 000 Reisende/Tag
SBB Cargo
195 000 t Güter/Tag
Infrastruktur
3100 km Netz
Immobilien
3500 Gebäude

14. 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

15. 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

16. 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

17. 3. Von den Q-Gates, Q-Points und anderen
Analysemethoden zur SDA
SBB • Division • Abteilung oder Bereich • DD.MM.YY17

18. Das Modell der Projektsteuerung
SBB • Division • Abteilung oder Bereich • DD.MM.YY 18

19. Erweiterte SWOT- Analyse
SBB • Division • Abteilung oder Bereich • DD.MM.YY 19

20. SDA: Ergebnisprofil: Driver 11 – 20

21. SDA: Streuung Driver 11- 20

22. 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

23. SDA: Verschiedene Sichten im Vergleich
SBB • Division • Abteilung oder Bereich • DD.MM.YY 23

24. SDA: Vergleich zwischen zwei SDA-Runden
Runde 1
Runde 2

25. 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

26. 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 Treiber
Workshop 2-4 h
3 Einschätzung der Treiber
20 – 25 Projektbeteiligte
1h/ 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
…

27. SDA: Vergleich der pilotierten Verfahren
SBB • Division • Abteilung oder Bereich • DD.MM.YY 27
Verfahren
Problem-
früherkennung
Vergleichbarkeit
Ergebnisse
Akzeptanzvon
Massnahmen
Ursachen
erkennen
Aufwand
Projektteam
Aufwand
Auditteam
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

28. 4. Die SDA als Teil eines
Projekt-/ Programm Frühwarnsystems
(Projektradar) SBB • Division • Abteilung oder Bereich • DD.MM.YY28

29. Frühwarn-Indikator-System
Regelmässige Analysen auf Stufe
Gesamtprojekt
Kennzahlen zu
ausgewählte
Indikatoren
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

31. Exempel: Project Control Panel

32. 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

33. 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.