1 Workshop Risiko-Management in IT-Projekten - copyright Dr. Klaus Röber Baustein: RM-42...

1Workshop Risiko-Management in IT-Projekten - copyright Dr. Klaus RöberBaustein: RM-42 Kommerzielle Methoden: Beispiel S:PRIME Methode - Version 2.0: 06/2001

DKR Unternehmensberatung

Baustein RM-42:

Kommerzielle Methoden:Software Process Risk

Identification, Mapping and Evaluation(S:PRIME)

GrafP Technologies, Inc.

und

Centre de Recherche Informatique de Montreal, Canada

Version 1.6, 1998



Inhalte des Bausteins

S:PRIME Assessment Basis Ziele Ablauf Arbeitsschritte

Die Risikokategorien der SEI Taxonomie Berücksichtigte Praktiken Definitionen Antworten auf die Risikofragen Antworten auf die Praktiken Fragen Modulation der Risiken Erkanntes und wahrscheinliches Risiko Schwellwert Beispiele für Auswertungen Auf die Diagnose folgende Schritte Aktionsplanung



S:PRIME Assessment - Basis

Zwei komplementäre Untersuchungen schlagen

die Balance zwischen dem Risikobewußtsein des

Managements und den angewandten Entwicklungspraktiken Der Risiko-Fragebogen basiert auf der Software Risk Taxonomy

entwickelt vom SEI Sieben Risikokategorien werden betrachtet Insgesamt werden 163 Risiko Faktoren untersucht

Der Praktiken-Fragebogen basiert auf dem

Capability Maturity Model des SEI (CMM) CMM Stufe 2 (Basic) und Stufe 3 (Managed) Praktiken werden

berücksichtigt Unternehmenskultur und Kundendienst werden hinzu gefügt Insgesamt werden 259 Entwicklungspraktiken untersucht



S:PRIME Assessment - Ziele

Identifizieren, bewerten und managen von prozess-abhängigen Risiken (ca. 70% aller Projektrisiken) in Softwareprojekten und Organisationen, die Software-entwicklung und -wartung ausführen, in Abhängigkeit vom Reifegrad der implementierten Entwicklungs-praktiken wiederholbar auf jährlicher Basis (Durchschnitt) schnell und kostengünstig auf Wunsch mit Technologietransfer auf die untersuchte

Organisation bzw. das Projekt



S:PRIME Assessment - Ablauf

1 2 4

5

6

Auswahl: Pro jekte,Teilnehm erVorste llung des VerfahrensAnpassen der F ragebögen

Fragebogen zurR isiko identifikationund -analyse

Fragebogen zurPraktikenidentifikationund -analyse

Datenerfassung,M odulation derR isiken durch denQ uotienten derim plem entiertenPraktiken

Analyse undKonsolid ierung der A ntworten

Präsentationder E rgebnisse

O ptional:Aktionsplanung

Pro jektle iter/M anager

Entw ickler 3

ZeitAktivität J F M A M J J A S O N D

A ktiv ität 1

A ktiv ität 1

A ktiv ität 1

A ktiv ität 1

A ktiv ität 1



S:PRIME Assessments - Arbeitsschritte

Informationen über den Projektstatus sammeln Potentielle Risiken identifizieren Dokumentieren und verifizieren des Reifegrades der momentanen Praktiken Erste vorläufige Verbesserungsmöglichkeiten aufzeigen

Kernteamanalyse Risiken klassifizieren und gruppieren; schwache Praktiken identifizieren Ergebnisse analysieren; Inkonsistenzen beseitigen; fehlende Info beschaffen Ergebnisse zusammenfassen; vorläufige Folienpräsentation erstellen

Konsolidierung & Validierung Gemeinsames Verständnis der Hauptergebnisse herstellen;

Hauptbeobachtungen abstimmen und bestätigen Risikomanagement-Strategie definieren oder adaptieren; Aktionen

vorschlagen; Konsens herstellen Machbarkeit der empfohlenen Aktionen überprüfen; Prioritäten setzen;

Schlussfolgerungen abstimmen Folienpräsentation abstimmen; Ergebnisse kommunizieren



Die Risikokategorien der SEI Taxonomie

R01 - Anforderungen (Projektgegenstand) Stabilität der Spezifikation Offene Fragen (Vollständigkeit) Projektmachbarkeit (technisch & kommerziell) Klarheit der Vereinbarungen (Konsistenz) Gemeinsames Verständnis der Anforderungen

R02 - Design und Produktion Strukturelle Aspekte (Produktkomplexität) Produktmachbarkeit (Technologie;

Anwendungsgebiet) Produktintegrität & -qualität (Integration &

Test)

R03 - Entwicklungsumgebung Eignung von Werkzeugen und Methoden Integrationsgrad Ressourcenverfügbarkeit und Infrastruktur Vertrautheit mit Methoden und Werkzeugen

R04 - Entwicklungsprozess Existenz von (aktuellen) Plänen und Arbeitspapieren Einhalten des abgestimmten Zeitplans Änderungsmanagementprozeduren & Notfallplanung

R05 - Management Statusberichte & Fortschrittskontrolle Problemlösung & Entscheidungsfindung Kommunikation; Kundenbeziehungen

R06 - Team Verfügbarkeit von Schlüsselpersonen;

Fähigkeitsprofile Verpflichtung; Mitarbeitermotivation & Training Teamzusammenhang; Rolle von Lieferanten

R07 - Externe Rahmenbedingungen Zeitplan, Budget, Ressourcen Verhalten des Kunden Firmenpolitik



Berücksichtigte Praktiken (1)

P01 - Management der Anforderungen (Stufe 2)

P02 - Projektplanung (Stufe 2)

Vernünftige Pläne erstellen für die Durchführung der Software Engineering Aktivitäten und desProjektmanagements

P03 - Projektüberwachung und -steuerung (Stufe 2)

Transparenz hinsichtlich des aktuellen Projekt-fortschritts schaffen, so daß das Management geeignete Maßnahmen ergreifen kann, wenn der Projektfortschritt signifikant vom Plan abweicht

P04 - Subkontraktmanagement (Stufe 2)

Geeignete Subkontraktoren auswählen und managen

P05 - Qualitätssicherung (Stufe 2)

Transparenz schaffen für das Management hinsichtlich des Entwicklungsprozesses undder erstellten Ergebnisse

P06 - Konfigurationsmanagement (Stufe 2)

Etablieren und sicherstellen der Integrität der Projektergebnisse während des ganzenLebenszyklus

Zweck dieses Prozesses ist, ein gemeinsames Verständnis zwischen Auftraggeber und Team herzustellen über die Anforderungen, dieim Projekt realisiert werden sollen

P07 - Prozeßorganisation festlegen (Stufe 3)

Verantwortliche für die Aktivitäten des Software-prozesses festlegen, die die generelle Prozeßfägikeitdes Unternehmens verbessern

P08 - Prozesse definieren (Stufe 3)

Entwickeln und pflegen von Prozeßverfahrens-anweisungen, die die Leistungen des Prozesseserhöhen und eine Basis bilden für kumulierten langfristigen Nutzen der Organisation



Berücksichtigte Praktiken (2)

P09 - Training (Stufe 3)

P10 - Integriertes Softwaremanagement (Stufe 3)

Integration der Engineering- und Managementaktivitätenin einen kohärenten definierten Softwareprozeß, der ausdem Standard-Entwicklungsprozeß abgeleitet worden ist

P11 - Softwareprodukt Engineering (Stufe 3)

Ständige Ausführung eines wohldefinierten Software-engineeringprozesses, der alle notwendigen Aktivitätenintegriert, um korrekte und konsistente Produkte ineffizienter Weise zu erstellen

P12 - Koordination zwischen Gruppen (Stufe 3)

Sicherstellen, daß das Entwicklungsteam aktiv mitanderen betroffenen Gruppen zusammenarbeitet,um so die Anforderungen des Auftraggebers zu befriedigen

P13 - Reviews (Stufe 3)

Der Zweck dieses Prozesses ist, Mängel der Ergebnisse frühzeitig zu erkennen und sie ineffizienter Weise zu beheben, um so ein besseresVerständnis dieser Ergebnisse und der Fehler, dieverhütet werden können, zu gewinnen

P14 - Unternehmenskultur (CRIM)

Etablieren einer Menge von gemeinsamen Werten, Verhaltensweisen und unausgesprochenen Regeln, die dabei helfen, Veränderungen der Organisationzu unterstützen

Fähigkeiten und Wissen der Mitarbeiter weiter entwickeln, so daß sie ihre Rollleneffektiv und effizient wahrnehmen können

P015- Kundendienst (CRIM)

Der Zweck dieses Prozesses besteht darin, demAuftraggeber und den Anwendern Qualitäts-produkte und -dienstleistungen zu liefern während der Entwicklung und Wartung sowie während der Operation des fertigen Systems



Einige Definitionen

Erkanntes Risiko

Praktikzufrieden-

heitsgrad Wahrscheinliches

Risiko Erkanntes Risiko

als Funktion des

Praktikzufrieden-

heitsgrads

Risiken (Kostenüberschreitungen,Terminüber-schreitungen,

mangelnde Funktionaliät) deren sich die Manager bewußt sind

Grad zu dem die besten Softwareengineering Praktiken im Projekt

oder in der Organisation angewandt werden

Wahrscheinlichkeit, dass die möglichen Schwierigkeiten eintreten

werden, falls keine Korrekturmaßnahmen ergriffen werden

Die Fähigkeit des Managements, Risiken zu erkennen, hängt sowohl

vom Zufriedenheitsgrad mit einer bestimmten Praktik wie auch von der

Praktik selbst ab



Antworten auf die Risikofragen

Antwortmöglichkeiten YES (immer oder fast immer) NO (nie oder sehr selten) SOMETIMES (zwischen YES und NO) N/A (die Frage ist hier nicht relevant) UNKNOWN (der Teilnehmer hat nicht genug Informationen, um die Frage zu

beantworten) OUT OF SCOPE (Frage ist außerhalb des Rahmens des Projekts)

Die Antworten müssen das reflektieren, was in der Projektpraxis erfahren wird

Erfahrungen aus vorangegangenen Projekten können verwendet werden, um eine für das aktuelle Projekt relevante Bedingung zu bewerten, die noch nicht eingetreten ist

Es ist wichtig, Kommentare zu geben, die die Antworten näher erläutern



Antwortmöglichkeiten YES (immer oder fast immer) NO (nie oder sehr selten) SOMETIMES (zwischen YES und NO) N/A (die Frage ist nicht relevant für die Projekte, mit denen der Praktiker befasst ist) ??? (die Frage ist relevant, aber der Praktiker hat nicht genügend Informationen, um

sie zu beantworten) (auf diesem Gebiet hat der Praktiker keine Erfahrung)

Die Antworten müssen das reflektieren, was in der Projektpraxis erfahren wird (in Bezug auf den Erfahrungshorizont des Praktikers)

Die Praktiker sollten Erfahrungen aus mehreren vergangenen Projekten haben

Es ist wichtig, Kommentare zu geben, die die Antworten näher erläutern

Antworten auf die Praktiken Fragen

/



Modulation der Risiken

Die Risiken sind mit den Reifegraden der Praktiken über eine Matrix verbunden. Die Matrix beantwortet dieFrage: Um wieviel wird ein bestimmtes Risiko durch die Implementierung einer bestimmten Praktik reduziert?Die Abbildung erfolgt auf Basis einer exponentiellen Risikofunktion (Hazard Function), die durch empirischgewonnene Erfahrungswerte adjustiert wurde. Die Matrix ist geistiges eigentum von GRafP Technologies.

R1

P1

R7

P15

R3

P3

R2

P2

Fragebogen von Schritt 2

GewichteteVerbindungen

zwischenRisiken

undPraktiken

Fragebogen von Schritt 3

Höhe der Risiken, wie sie von den Managern für alle 7 Kategorien gesehen werden

Zufriedenheitsgrad mit den implementierten Praktiken für jeden der 15 Bereiche, wie er von den Praktikern gesehen wird



Erkanntes und wahrscheinliches Risiko

R01 Anforderungen

R02 Design und Realisierung

R03 Entwicklungsumgebung

R04 Entwicklungsprozess

R05 Management

R06 Team

R07 Rahmenbedingungen

Reifegrad der Praktiken = 0.69

0

0.25

0.50

0.75

1.00

0 0.25 0.50 0.75 1.00

Erkanntes Risiko

Wah

rsch

ein

lich

es R

isik

o

Durchschnitt = 0.34

Dur

chsc

hnitt

= 0

.25

R01

R07

R03R05

R06R04

R020,40

Schwellwert



Schwellwert

Eine wichtige Kenngröße ist der Schwellwert. Empirische Ergebnisse zeigen, dass offenbar bei einem wahrscheinlichen -Risiko von 40% eine Grenze liegt

Organisationen, die mit über 40% Risiko operieren, werden wahrscheinlich in der Zukunft größere Probleme bekommen

Organisationen, die mit unter 40% Risiko operieren (alles, was über 20% liegt, ist noch zu hoch), werden wahrscheinlich in der Lage sein, sich ausreichend zu verbessern

Ähnliche Erfahrungen wurden im Finanzbereich gemacht. Auch Venture Capital Firmen investieren nicht in eine Firma, die mit über 40% Risiko operiert

Damit haben wir eine griffige Kenngröße für das Management



Beispiel: Risikoprofil eines „unreifen“ Projekts

0,0

0,0

0,0 0,0

0,2

0,2

0,2 0,2

0,4

0,4

0,4 0,4

0,6

0,6

0,6 0,6

0,8

0,8

0,8 0,8

1,0

1,01,0 1,0

Wahrschein-liches Risiko Reifegrad

der Praktiken= 0,1

ErkanntesRisiko

G renzbereich,innerhalb dessen

effiz ientgearbeitet w erden

kann

S chw e llw ert

sehr hoch bisnicht akzeptabel

m ittel bishoch

hoch bis sehr hoch

niedrig bism ittel

sehr niedrigbis niedrig

Unternehmen, die einen niedrigen Reifegrad der Praktiken aufweisen (0,1 entspricht einem Reifegrad am unteren Ende von Stufe 1 des CMM) können in der Regel nur dann erfolgreich operieren, wenn das Management ein sehr hohes Risikobewußtsein hat und entsprechend vorbeugende Maßnahmen ergreift.



Beispiel: Risikoprofil eines „reifen“ Projekts

0,0

0,0

0,0 0,0

0,2

0,2

0,2 0,2

0,4

0,4

0,4

0,6

0,6

0,6 0,6

0,8

0,8

0,8 0,8

1,0

1,01,0 1,0

ErkanntesRisiko

Reifegradder Praktiken

= 0,9

G renzbereich,innerhalb dessen

effiz ientgearbeite t w erden

kann

Wahrschein-liches Risiko

sehr hoch bisnicht akzeptabel

m ittel bishoch

hoch bis sehr hoch

niedrig bism ittel

sehr niedrigbis niedrig

0,4 S chw e llw ert

Unternehmen, die einen hohen Reifegrad der Praktiken aufweisen (0,9 entsprichteinem Reifegrad am oberen Ende von Stufe 3 des CMM) können (müssen aber nicht!) auch dann erfolgreich operieren, wenn das Management ein geringeres Risikobe-wusstsein hat und wenig vorbeugende Maßnahmen ergreift.



S:PRIME-Ergebnisse: Vertrauensgrad

Vertrauensgrad

Ris

iko

Kat

ego

rie

0 10 20 30 40 50 60 70 80 90 100

R 01

R 02

R 03

R 04

R 05

R 06

R 07

Vertrauensgrad

Pra

ktik

enb

erei

ch0 10 20 30 40 50 60 70 80 90 100

P01

P02

P03

P04

P05

P06

P07

P08

P09

P10

P11

P12

P13

P14

P15

D er Vertrauensgrad repräsentiert den P rozentsatz verw endbarer Antw orten



S:PRIME-Ergebisse: Erkannte Risiken

0

10

20

30

40

50

60

70

80

90

100

R01 R02 R03 R04 R05 R06 R07

Risikokategorie

Erk

ann

tes

Ris

iko

R01 Anforderungen 49.2

R02 Design und Realisierung 27.1

R03 Entwicklungsumgebung 36.9

R04 Entwicklungsprozeß 25.5

R05 Management 35.1

R06 Team 29.4

R07 Rahmenbedingungen 38.6

D urchschnittliches R isikobew ußtsein = 33,6



S:PRIME-Ergebnisse: Reifegrade der PraktikenP

rakt

ikre

ifeg

rad

Praktikbereich

0

10

20

30

40

50

60

70

80

90

100

P01 P02 P03 P04 P05 P06 P07 P08 P09 P10 P11 P12 P13 P14 P15

P01 Anforderungsm anagement 77.1

P02 Projektplanung 76.5

P03 Projektüberwachung/-steuer. 77.7

P04 Subkontraktormanagement 71.4

P05 Qualitätssicherung 57.7

P06 Konfigurationsmanagem ent 73.1

P07 Prozeßorg. festlegen 55.3

P08 Prozesse definieren 62.4

P09 Training 48.4

P10 Integr. Softwaremgmt. 54.6

P11 Softwareprodukt Engineering 75.8

P12 Entwicklungskoordination 55.0

P13 Review 71.2

P14 Unternehmenskultur 72.6

P15 Kundendienst 77.5

Durchschnittlicher Reifegrad der Praktiken = 68,8



S:PRIME-Ergebnisse: Wahrscheinliche Risiken

0

10

20

30

40

50

60

70

80

90

100

R01 R02 R03 R04 R05 R06 R07

Risikokategorie

Erw

art

un

gsw

ert

des

Ris

iko

s R01 Anforderungen 6 ,1

R02 Design und Realisierung 27.6

R03 Entwicklungsumgebung 23,8

R04 Entwicklungsprozeß 38,4

R05 Managem ent 27,4

R06 Team 37,8

R07 Rahmenbedingungen 18,7

D urchschnittliches w ahrschein liches R isiko = 25,5



S:PRIME-Ergebnisse: Wahrscheinliche Risiken pro Praktikbereich

Wah

rsch

ein

lich

es R

isik

o

Praktikbereich

0

10

20

30

40

50

60

70

80

90

100


P01 Anforderungsm anagem ent 11,4

P02 Projektplanung 13,9

P03 Projektüberwachung/-steuer. 12,3

P04 Subkontraktorm anagem ent 19,5

P05 Qualitätssicherung 41,2

P06 Konfigurationsm anagem ent 17,4

P07 Prozeßorg. festlegen 50,3

P08 Prozesse definieren 38,5

P09 Training 64,0

P10 Integr. Softwarem gm t. 48,5

P11 Softwareprodukt Engineering 15,7

P12 Entwicklungskoordination 45,3

P13 Review 21,2

P14 Unternehm enskultur 10,2

P15 Kundendienst 11,2

D urchschnittliches w ahrschein liches R isiko = 28,0



Generelle Aussagen (Beispiel)

Das Risikobewusstsein (P = 33,6) ist relativ hoch, das wahrscheinliche Risiko ist moderat (P = 25,5) Ein relativ hohes Risikobewusstsein haben wir in der Kategorie „Anforderungen“

(P = 49,2%)) Ein relativ niedriges Risikobewusstsein haben wir in den Kategorien „Design und

Realisierung“ (P = 27,1 %) und „Entwicklungsprozess“ (P = 25,5%)

Der durchschnittliche Reifegrad der Praktiken ist akzeptabel (68,8%) Besondere Schwächen zeigen sich bei den Prozessen „Qualitätssicherung“ (57,1),

Prozessorganisation festlegen (55,3), Training (48,4), Integriertes Softwaremanagement (54,6) und Entwicklungskoordination (55,0)

Das Risikobewusstsein erscheint realistisch (wahrscheinliches Risiko < erkanntes Risiko)

Die meisten Praktiken sind angemessen implementiert Es ist möglich, die wahrscheinlichen Risiken durch geeignete Maßnahmen

weiter zu reduzieren



Detaillierter Auswerteprozess

Die detaillierten Ergebnisse der S:PRIME Analyse können noch

weiter in systematischer Form ausgewertet werden (Excel) 1. Schritt: Klassifizieren der Risiken

Risikoklasse A: Erkanntes Risiko > 80% Risikoklasse B: Erkanntes Risiko 65% - 80% Risikoklasse C: Erkanntes Risiko 55% - 65%

2. Schritt: Gruppieren der Risiken in Prioritätsklassen Prioritätsklasse 1: Erkanntes Risiko >80% oder <25%, Praktikreifegrad <30% Prioritätsklasse 2: Erkanntes Risiko >65% oder <25%, Praktikreifegrad <40% Prioritätsklasse 3: Erkanntes Risiko >55% oder <25%, Praktikreifegrad <50%

3. Schritt: Identifizieren von schwachen Praktiken pro Prioritätsklasse Dringlichkeitsklasse 1: Praktikreifegrad <30%, Risiko Prioritätsklasse 1 Dringlichkeitsklasse 2: Praktikreifegrad <40%, Risiko Prioritätsklasse 2 Dringlichkeitsklasse 3: Praktikreifegrad <50%, Risiok Prioritätsklasse 1,2,3



Erkannte Risiken (Beispiel)

Risikoklasse A = Erkanntes Risiko ist größer als 80%

I, II, II: Dringlichkeitsklassen für empfohlene Aktionen

1.9 Es gibt Vertraulichkeitsanforderungen in Bezug auf die Software 1.10 Es gibt Sicherheitsanforderungen an die Software 1.16 Der gesamte Entwicklungsaufwand (benötigte Ressourcen) und die Komplexität der Anwendung bereiten dem Team Kopfschmerzen 3.12 Die Entwicklung wird in verschiedenen Standorten durchgeführt 5.13 Politische Überlegungen beeinflussen technische Entscheidungen

6.11.9 Im Konfigurationsmanagement fehlen Kenntnisse 6.14 Das Projekt zeigt eine starke Abhängigkeit von der Expertise von Kunden oder Lieferanten 7.1 Es gibt Rahmenbedingungen, die negative Einflüsse haben können auf den Zeitplan, das Budget oder das fertige Produkt (z. B. zusagen, die miteinander

in Konflikt stehen, zu enge Termine) 7.9 Das Projekt hängt ab von kritischen Komponenten, die von externen Lieferanten geliefert werden müssen

IIIII

IIIIII

II

II

I



Risiken der Prioritätsklasse 1

Erkanntes Risiko > 80%; Praktikreifegrad < 30%; Vertrauensgrad 70%

Erkanntes Risiko < 80%; Praktikreifegrad < 30%; Vertrauensgrad 70%

3.12 Softwareentw icklung w ird an verschiedenen S tandorten ausgeführt5.13 Politische Überlegungen beeinflussen technische Entscheidungen 7 .9 Das Pro jekt hängt ab von kritischen Kom ponenten, d ie von externen L ieferanten geliefert werden m üssen

1 .13 Es g ibt ke ine m ite inander in Konflikt stehenden Anforderungen oder solche, d ie fa lsch interpretiert werden könnten2.14 Es ist m öglich zu verifiz ieren, ob die Anforderungen an Zuverlässigkeit und Verfüg- barkeit erre icht w erden4.10 D ie Team m itg lieder haben Erfahrung m it den e ingesetzten Entw icklungs- m ethoden4.23 Zeitp läne und technische D aten sind problem los von den L ieferanten zu bekom m en5.11 Es ist m öglich, ris ikobehaftete Aktiv itäten zu erkenn en, ohne e ine Lösung parat zu haben6.11.8 D ie Fähigkeiten zum Design der M ensch-M aschine Schnittste lle sind ausre ichend7.5.3 Der Kunde greift n icht über G ebühr e in



Wie liest man die Cross-Reference Matrix?

Ein spezielles Risiko:

Damit verbundene Praktiken:

7.9 D as P ro jekt hängt ab von kritischen Kom ponenten, d ie von externen L ie feranten gelie fert w erden m üssen

R eifegrad = 21R eifegrad = 32

R eifegrad = 36

R eifegrad = 40

R eifegrad = 44

R eifegrad = 44

R eifegrad = 46

E rkanntes = 90 R isiko

9 .1 D as P ro jekt so llte e inen Tra in ingsplan für d ie Team m itg lieder aufste llen12.3 D okum ente, d ie Auskunft über d ie Verantw ortung der e inzelnen G ruppen geben und d ie es erlauben, d ie in E rfü llung d ieser Verantw ortung ausge- führten Aktiv itä ten zu überprüfen, so llten erste llt w erden5.11 Softw are Q S Personal so llte spezifische Instruktionen erhalten, um d ie Anforderungen des P rojekts zu erfü llen2.9.1 R isiken, d ie s ich auf Kosten, R essourcen, Zeitp lan und a ndere technische Aspekte des P ro jekts beziehen, so llten identifiz iert, bew ertet und dokum en- tiert w erden3.7 R is iken, d ie s ich auf Kosten, R essourcen, Ze itp lan und andere technische Aspekte des P ro jekts beziehen, so llten angem essen überw acht w erden5.3 Softw are Q S Personal so llte an R eview s der Entw icklungspläne, S tandards und P rozeduren des P rojekts te ilnehm en12.7 Technische R eview s, an denen Vertreter der verschiedenen am Projekt bete i- lig ten te ilnehm en, so llten period isch durchgeführt w erden



Empfohlene Aktionen - Dringlichkeitsklasse 1

2.20 Software QS Personal sollte daran beteiligt werden zu verifizieren, dass die Pro- jektplanungsaktivitäten auf der Basis von vorgeschriebenen Standards und Pro- zeduren durchgeführt wurde4.10.1 Formelle Reviews mit den Lieferanten, während derer an ausgewählten Meilen- steinen Ergebnisse überprüft werden, sollten auf Basis einer dokumentierten Prozedur erfolgen5.8 Software QS Personal sollte periodisch ihre Aktivitäten und Ergebnisse gemeinsam mit dem QS Personal des Kunden überprüfen9.1 Das Projekt sollte einen Trainingsplan für die Teammitglieder aufstellen12.11 Vertreter jeder Gruppe, die am Projekt mitarbeitet, sollten eine Orientierung über die Methoden, Prozeduren und Standards erhalten, die die anderen Gruppen benutzen12.12 Alle Mitglieder der im Projekt zusammenarbeitenden Gruppen sollten eine Orientierung darüber erhalten, wie man am besten zusammen arbeitet



Vorgeschlagene Aktionen auf Projektebene - Beispiel

Eine unabhängige Instanz sollte damit beauftragt werden zu überprüfen, daß Projektpläne auf Basis von verbindlichen Standards und Prozedurenerstellt werden und daß sie auch respektiert werden.Formelle Reviews mit Lieferanten an bestimmten Meilensteinen zur Über-prüfung der Ergebnisse sollten einer dokumentierten Prozedur folgen.

Vertreter der Gruppen, die am Projekt beteiligt sind, sollten eine Orien-tierung über Methoden, Prozeduren und Standards der anderen Grup-pen erhalten.Für die Teammitglieder sollte ein Trainingsplan erstellt werden.Alle Teammitglieder sollten in Zusammenarbeit geschult werden.

Risiken, die sich auf Kosten, Ressourcen, Zeitplan und andere tech-nische Aspekte des Projekts auswirken, sollten identifiziert, bewertet,dokumentiert und überwacht werden.

Qualitätssicherung

Risiko Management

Team Performance (Integr. Managem ent, Entwicklungs-koordination, Training)



Beispiel: Softwarehersteller

Wa

hrs

che

inlic

hes

Ris

iko

Praktikbereich

0

10

20

30

40

50

60

70

80

90

100


P01 Anforderungsm anagem ent

P02 Pro jektp lanung

P03 Pro jektüberw achung/-steuer.

P04 Subkontraktorm anagem ent

P05 Q ualitä tssicherung

P06 Konfigurationsm anagem ent

P07 Prozeßorg. festlegen

P08 Prozesse defin ieren

P09 Train ing

P10 Integr. Softw arem gm t.

P11 Softw areprodukt Engineering

P12 Entw icklungskoord ination

P13 R eview

P14 U nternehm enskultur

P15 Kundendienst

Die Firma wurde 1987 gegründet. 1990 hatte man 300 Mitarbeiter, 1995 waren es schon 700 (davon 400 IV Professionals).Das Risikoprofil zeigt, dass diese Firma stark gefährdet ist. Das Risiko ist fast überall hoch. Die Balken, bei denen es Nullzu sein scheint, bedeuten, dass hier überhaupt nichts getan wurde.11/2 Jahre später machte die Firma negative Schlagzeilen in der Presse und der Vorstand wurde gefeuert.(Qulle GrafP Techn.)



Beispiel: Private Organisation

Diese Organisation hat beim SEI ein Assessment gemacht und mit einem Reifegrad von fast 3 abgeschnitten. Hier haben wir esmit einer realtiv reifen Organisation zu tun, die ihre Risiken gut im Griff hat (Quelle: GrafP Technologies)

Wah

rsch

ein

lich

es R

isik

o

Praktikbereich

0

10

20

30

40

50

60

70

80

90

100










P09 Tra in ing




P13 R eview


P15 Kundendienst



Beispiel: Sehr kleine private Organisation W

ahrs

chei

nlic

hes

Ris

iko

Praktikbereich

0

10

20

30

40

50

60

70

80

90

100










P09 Tra in ing




P13 R eview


P15 Kundendienst

Diese Firma hat nur 15 Mitarbeiter. Bis auf einige Ausnahmen hat man die Risiken gut im Griff. Der hohe Wert bei Konfigurationsmanagementwar für die Beteiligten überraschend, da man glaubte, dies im Griff zu haben. Die Organisation ist sehr prozessbewusst, deshalb der niedrige Wert bei „Prozessorganisation festlegen“. Auf Grund mangelnder Ressourcen hatte man aber noch keine Zeit, die Prozesse genau zu definieren,deshalb der relativ hohe Wert bei „Prozesse definieren“. (Quelle: GrafP Technologies)



Beispiel: Staatliche OrganisationW

ah

rsch

ein

lich

es R

isik

o

Praktikbereich

0

10

20

30

40

50

60

70

80

90

100










P09 Tra in ing




P13 R eview


P15 Kundendienst

Zu beachten sind die hohen Risiken bei „Qualitätssicherung“ und „Unternehmenskultur“. Dies ist typisch für staatliche Organisationen (inCanada oder USA?, denn hier haben wir das V-Modell!). Dabei ist der schwierigste Bereich die „Unternehmenskultur“. Verbesserungensind hier i. a. kaum möglich, obwohl es in jüngster Zeit einige hoffnungsvolle Ansätze bei kommunalen Behörden gibt, die Umgangsformenmit den Bürgern zu verbessern. Das könnte dann auf den IV Bereich abfärben.



Auf die Diagnose folgende Schritte

Überprüfen der Ergebnisse der Diagnose Bewerten ihrer Relevanz an Hand der geschäftlichen Ziele des Projekts

oder der Organisation Priorisieren der relevanten Ergebnisse Überprüfung der Praktiken, die sich auf diese Ergebnisse beziehen Identifizieren der Praktiken, die schon teilweise implementiert sind und

die deshalb leichter zu verbessern Aufstellen eines Aktionsplans zur Implementierung der Praktiken, die

als geeignet gefunden waren Feststellen, wie erfolgreich die verbesserten oder neu implementierten

Praktiken waren Falls notwendig, zusätzliche benötigte Praktiken implementieren und

solche aus dem Verkehr ziehen, die nicht nützlich sind Erneutes Assessment in 6-12 Monaten



Antriebskraft für Veränderungen als Funktion der Zeit

t 1

t1

t2

t2

t3

t3

tc

tc

tc

Präsentation der Ergebnisse

Zeit

Interesseder Mitarbeiter(Antriebskraft)

Zeitintervallzwischen der Präsentation der Assessment Ergebnisseund dem Beginn der Aktions-planung

= kritischer Zeitpunkt

> > >



Prinzipien der Aktionsplanung

Man beginnt mit den Ergebnissen der Diagnose Entscheider müssen teilnehmen Strikte Vertraulichkeit muss gewahrt bleiben Aktionsplanung muss miteinander und nicht

gegeneinander erfolgen Man validiert zunächst die prozessabhängigen Risiken

und fügt dann projektspezifische Risiken hinzu Man sollte sich auf Lösungen konzentrieren, die von

allen mitgetragen werden und die deshalb auch die Chance haben zu funktionieren



Beispiel: Aktionsplanung für Assessment der Organisationseinheit (1. Woche)

Kick-off Meeting Beschreibung der Schritte der Aktionsplanung Das obere Management sollte teilnehmen, um den Teilnehmern

zu demonstrieren, dass es dahinter steht und um sie zu Offenheit zu nötigen

Interviews mit Projektleitern, Managern und Praktikern Sammeln von Kommentaren zu den vorläufigen Empfehlungen,

ihrer relativen Priorität und von Vorschlägen zu ihrer Implementierung

1. Entwurf des Aktionsplans Enthält Kommentare und Vorschläge, die in den Interviews

gesammelt wurden



Aktionsplanung (1. Woche Fortsetzung)

PP...P

1

1

2

2

k

m

Teilnehm er 1Teilnehm er 2...Te ilnehm er n

Teiln

ehm

er 1

Teiln

ehm

er 2

. . . Teiln

ehm

er n

R R .................R

R isiken

Praktiken

Zuordnung der identifiz ierten R isiken und der em pfohlem enPraktiken

R elative Bedeutungder em pfohlenen Praktiken

R elative Bedeutungder identifiz ierten R isiken

x x x x

x x

Erstellen einer Matrix der Risiken und Praktiken



Aktionsplanung (2. Woche)

Interviews mit Projektleitern, um ihre Kommentare zum Aktionsplan zu sammeln

Ergänzende Interviews mit anderen Teilnehmern, um grobe Schätzungen für die Implementierung zu bekommen

Ggf. weitere Interviews (z. B. mit dem Top Management), um den Aktionsplan zu verfeinern

Erstellung der vorläufigen Version des endgültigen Aktionsplans



Aktionsplanung (3. Woche)

Meeting mit Projektleitern, Managern und Praktikern, um den Aktionsplan zu validieren Aufwands- und Zeitschätzungen verfeinern letztmalige Validierung des Plans Festlegen, wer für die Arbeitspakete des Plans

verantwortlich sein soll

Ggf. überarbeiten des Aktionsplans Endgültige Präsentation der Ergebnisse Kick-off für die nächsten Schritte



Diskussion

S:PRIME Methode

1 Workshop Risiko-Management in IT-Projekten - copyright Dr. Klaus Röber Baustein: RM-42...

Documents

Transcript of 1 Workshop Risiko-Management in IT-Projekten - copyright Dr. Klaus Röber Baustein: RM-42...