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.