Baustein RM-42: Kommerzielle Methoden: Software Process Risk Identification, Mapping and Evaluation (S:PRIME) GrafP Technologies, Inc. und Centre de Recherche.

Präsentation zum Thema: "Baustein RM-42: Kommerzielle Methoden: Software Process Risk Identification, Mapping and Evaluation (S:PRIME) GrafP Technologies, Inc. und Centre de Recherche."—  Präsentation transkript:

1 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

2 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

3 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

4 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

5 S:PRIME Assessment - Ablauf
Das S:PRIME Verfahren wurde von der kanadischen Firma GrafP Technologies Inc. In Zusammenarbeit dem Centre de Recherche Informatique de Montreal und Vertretern der kanadischen Wirtschaft entwickelt. Es basiert auf dem CMM (Capability Maturity Model) und der Risk Taxonomy des SEI (Software Engineering Institut der Carnegie Mellon Universitä). Das S:PRIME Verfahren verbindet in einzigartiger Weise das CMM und die Risk Taxonomy. Es verwendet zwei orthogonale Fragebögen, um einmal das Risikobewußtsein von Projektleitern und Managern und zum anderen den Reifegrad der implementierten Praktiken zu ermitteln. Grund Ideen sind die folgenden: Ein Risiko ist umso gefährlicher, je weniger man sich seiner bewußt ist. Risiken zu erkennen, ist deshalb der erste wichtige Schritt zum professionellen Risikomanagement. Wenn ein Risiko in einem bestimmten Bereich eintritt, sind die Gefahren dann besonders groß, wenn die Arbeitspraktiken, um es zu managen, nicht hinreichend etabliert sind. Berücksichtigt werden vom Verfahren prozeßabhängige Risiken (70 %) aller Projektrisiken) aus folgenden 7 Kategorien: Anforderungen, Design und Realisierung, Entwicklungsumgebung, Entwicklungsprozeß, Management, Team, Rahmenbedingungen. Projektspezifische Risiken lassen sich mit Hilfe einer derartigen Methode prinzipiell nicht ermitteln. Hier helfen Metaplan- und Brainstorming Techniken. Nielsen+Partner ist gern bereit, Ihnen nähere Informationen über das S:PRIME Verfahren zu liefern oder eine Präsentation in Ihrem Hause durchzuführen bzw. ein derartiges Assessment durchzuführen.

6 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

7 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

8 Berücksichtigte Praktiken (1)
P01 - Management der Anforderungen (Stufe 2) P05 - Qualitätssicherung (Stufe 2) Zweck dieses Prozesses ist, ein gemeinsames Transparenz schaffen für das Management Verständnis zwischen Auftraggeber und Team hinsichtlich des Entwicklungsprozesses und herzustellen über die Anforderungen, die der erstellten Ergebnisse im Projekt realisiert werden sollen P02 - Projektplanung (Stufe 2) P06 - Konfigurationsmanagement (Stufe 2) Vernünftige Pläne erstellen für die Durchführung Etablieren und sicherstellen der Integrität der der Software Engineering Aktivitäten und des Projektergebnisse während des ganzen Projektmanagements Lebenszyklus P03 - Projektüberwachung und -steuerung (Stufe 2) P07 - Prozeßorganisation festlegen (Stufe 3) Transparenz hinsichtlich des aktuellen Projekt- Verantwortliche für die Aktivitäten des Software- fortschritts schaffen, so daß das Management prozesses festlegen, die die generelle Prozeßfägikeit geeignete Maßnahmen ergreifen kann, wenn des Unternehmens verbessern der Projektfortschritt signifikant vom Plan abweicht P04 - Subkontraktmanagement (Stufe 2) P08 - Prozesse definieren (Stufe 3) Geeignete Subkontraktoren auswählen und managen Entwickeln und pflegen von Prozeßverfahrens- anweisungen, die die Leistungen des Prozesses erhöhen und eine Basis bilden für kumulierten langfristigen Nutzen der Organisation

9 Berücksichtigte Praktiken (2)
P09 - Training (Stufe 3) P13 - Reviews (Stufe 3) Fähigkeiten und Wissen der Mitarbeiter Der Zweck dieses Prozesses ist, Mängel der weiter entwickeln, so daß sie ihre Rolllen Ergebnisse frühzeitig zu erkennen und sie in effektiv und effizient wahrnehmen können effizienter Weise zu beheben, um so ein besseres Verständnis dieser Ergebnisse und der Fehler, die verhütet werden können, zu gewinnen P10 - Integriertes Softwaremanagement (Stufe 3) P14 - Unternehmenskultur (CRIM) Integration der Engineering- und Managementaktivitäten in einen kohärenten definierten Softwareprozeß, der aus Etablieren einer Menge von gemeinsamen Werten, dem Standard-Entwicklungsprozeß abgeleitet worden ist Verhaltensweisen und unausgesprochenen Regeln, die dabei helfen, Veränderungen der Organisation P11 - Softwareprodukt Engineering (Stufe 3) zu unterstützen P015- Kundendienst (CRIM) Ständige Ausführung eines wohldefinierten Software- engineeringprozesses, der alle notwendigen Aktivitäten Der Zweck dieses Prozesses besteht darin, dem integriert, um korrekte und konsistente Produkte in Auftraggeber und den Anwendern Qualitäts- effizienter Weise zu erstellen produkte und -dienstleistungen zu liefern während der Entwicklung und Wartung sowie während der P12 - Koordination zwischen Gruppen (Stufe 3) Operation des fertigen Systems Sicherstellen, daß das Entwicklungsteam aktiv mit anderen betroffenen Gruppen zusammenarbeitet, um so die Anforderungen des Auftraggebers zu befriedigen

10 Einige Definitionen Erkanntes Risiko Praktikzufrieden- heitsgrad
Wahrscheinliches Risiko als Funktion des 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

11 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

12 Antworten auf die Praktiken Fragen
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) e (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 /

13 Modulation der Risiken
Fragebogen von Schritt 2 Höhe der Risiken, wie sie von den Managern für alle 7 Kategorien gesehen werden R1 R2 R3 R7 Gewichtete Verbindungen zwischen Risiken und Praktiken P1 P2 P3 P15 Fragebogen von Schritt 3 Zufriedenheitsgrad mit den implementierten Praktiken für jeden der 15 Bereiche, wie er von den Praktikern gesehen wird Die Risiken sind mit den Reifegraden der Praktiken über eine Matrix verbunden. Die Matrix beantwortet die Frage: 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 empirisch gewonnene Erfahrungswerte adjustiert wurde. Die Matrix ist geistiges eigentum von GRafP Technologies.

14 Erkanntes und wahrscheinliches Risiko
Reifegrad der Praktiken = 0.69 0.25 0.50 0.75 1.00 Erkanntes Risiko Wahrscheinliches Risiko Durchschnitt = 0.34 Durchschnitt = 0.25 R01 R07 R03 R05 R06 R04 R02 0,40 R01 Anforderungen R02 Design und Realisierung R03 Entwicklungsumgebung R04 Entwicklungsprozess R05 Management R06 Team R07 Rahmenbedingungen Schwellwert

15 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

16 Beispiel: Risikoprofil eines „unreifen“ Projekts
Ein wichtiges Ergebnis des S:PRIME Verfahrens ist eine Kenngröße, die es auf einen Blick erlaubt zu entscheiden, ob ein Projekt (bzw. eine Organisation) eine ausreichend große Erfolgschance hat oder nicht: das durchschnittliche wahrscheinliche Risiko. Ein Reifegrad bzw. Zufriedenheitsgrad von 0,1 bei den Praktiken bedeutet, daß nur 10% der Praktiken ausreichend implementiert sind. Dies würde bei einem Assessment auf Basis des CMM einem niedrigen Reifegrad der Stufe 1 entsprechen. Eine solche Organisation muß nicht unbedingt erfolglos operieren, aber sie kann nur in einem engen Bereich erfolgreich arbeiten. D. h. in einer solchen Organisation muß ein hohes Risikobewußtsein herrschen und entsprechende Vorkehrungen müssen getroffen sein. Muß eine solche Organisation unbedingt ihre Praktiken verbessern? Nein, es kann teurer sein, die Praktiken zu verbessern, als das Risiko in Kauf zu nehmen. Was bedeutet z. B. 50% Risiko? Eines von zwei Projekten bekommt Probleme bzgl. Kosten, Zeit und Qualität. Eine wichtige Kenngröße ist der Schwellwert: Empirische Ergebnisse zeigen, daß offenbar bei einem wahrscheinlichen Risiko von 40% eine Grenze liegt. Organisationen bzw. Projekte, die mit über 40% operieren werden wahrscheinlich größere Probleme in der Zukunft bekommen. Organisationen, die zwischen 40% und 20% operieren (eigentlich ist alles über 20% zu hoch), werden wahrscheinlich in der Lage sein, sich zu verbessern. Ähnliche Erfahrungen wurden beim Rating auf dem Finanzsektor gemacht (AAA, AB etc.). Venture Capital Firmen arbeiten ebenfalls mit diesem Schwellwert (d.h. investieren nicht in eine Firme, die mit über 40% wahrscheinlichem Risiko arbeitet). 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.

17 Beispiel: Risikoprofil eines „reifen“ Projekts
Ein Reifegrad bzw. Zufriedenheitsgrad von 0,9 mit den Praktiken bedeutet, daß 90% der Praktiken ausreichend implementiert sind. Dies würde bei einem Assessment auf Basis des CMM einem hohen Reifegrad der Stufe 3 entsprechen. Eine solche Organisation hat es sehr viel leichter, erfolgreich zu operieren, muß aber nicht unbedingt erfolgreich sein. Es gilt folgender (allerdings bisher noch unbewiesener Lehrsatz): Für jede Organisation gibt es wenigstens eine Menge von Praktiken, die es dieser Organisation erlauben werden, mit einem gegen 0 gehenden wahrscheinlichen Risiko zu operieren, vorausgesetzt es übersteigt nicht die Fähigkeiten der Organisation (verfügbare Ressourcen, Unternehmenskultur, Know How etc.) , eine solche Menge an Praktiken zu implementieren. Unternehmen, die einen hohen Reifegrad der Praktiken aufweisen (0,9 entspricht einem 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.

18 S:PRIME-Ergebnisse: Vertrauensgrad

19 S:PRIME-Ergebisse: Erkannte Risiken

20 S:PRIME-Ergebnisse: Reifegrade der Praktiken

21 S:PRIME-Ergebnisse: Wahrscheinliche Risiken

22 S:PRIME-Ergebnisse: Wahrscheinliche Risiken pro Praktikbereich

23 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

24 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

25 Erkannte Risiken (Beispiel)
Risikoklasse A = Erkanntes Risiko ist größer als 80% Es gibt Vertraulichkeitsanforderungen in Bezug auf die Software II Es gibt Sicherheitsanforderungen an die Software III Der gesamte Entwicklungsaufwand (benötigte Ressourcen) und die Komplexität der Anwendung bereiten dem Team Kopfschmerzen III Die Entwicklung wird in verschiedenen Standorten durchgeführt I Politische Überlegungen beeinflussen technische Entscheidungen I Im Konfigurationsmanagement fehlen Kenntnisse I Das Projekt zeigt eine starke Abhängigkeit von der Expertise von Kunden oder Lieferanten II 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) II Das Projekt hängt ab von kritischen Komponenten, die von externen Lieferanten geliefert werden müssen I I, II, II: Dringlichkeitsklassen für empfohlene Aktionen

26 Risiken der Prioritätsklasse 1

27 Wie liest man die Cross-Reference Matrix?

28 Empfohlene Aktionen - Dringlichkeitsklasse 1
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 wurde Formelle Reviews mit den Lieferanten, während derer an ausgewählten Meilen- steinen Ergebnisse überprüft werden, sollten auf Basis einer dokumentierten Prozedur erfolgen Software QS Personal sollte periodisch ihre Aktivitäten und Ergebnisse gemeinsam mit dem QS Personal des Kunden überprüfen Das Projekt sollte einen Trainingsplan für die Teammitglieder aufstellen Vertreter jeder Gruppe, die am Projekt mitarbeitet, sollten eine Orientierung über die Methoden, Prozeduren und Standards erhalten, die die anderen Gruppen benutzen Alle Mitglieder der im Projekt zusammenarbeitenden Gruppen sollten eine Orientierung darüber erhalten, wie man am besten zusammen arbeitet

29 Vorgeschlagene Aktionen auf Projektebene - Beispiel

30 Beispiel: Softwarehersteller
Die Firma wurde 1987 gegründet 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 Null zu 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.)

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

32 Beispiel: Sehr kleine private Organisation
Diese Firma hat nur 15 Mitarbeiter. Bis auf einige Ausnahmen hat man die Risiken gut im Griff. Der hohe Wert bei Konfigurationsmanagement war 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)

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

34 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

35 Antriebskraft für Veränderungen als Funktion der Zeit
Zeitintervall > t > t > t c 3 2 1 zwischen der Präsentation Interesse der Assessment Ergebnisse der Mitarbeiter Präsentation der und dem Beginn der Aktions- (Antriebskraft) Ergebnisse planung = kritischer Zeitpunkt t c t 1 t 2 t 3 t c Zeit

36 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

37 Interviews mit Projektleitern, Managern und Praktikern
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

38 Aktionsplanung (1. Woche Fortsetzung)
Erstellen einer Matrix der Risiken und Praktiken

39 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

40 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

41 Diskussion S:PRIME Methode