PCMA Teil 2

tbd

Vorgehen:

• Vorbereitung (Material sammeln)
• Durchführung (Desk Arbeit / Meeting, Befunde erheben / konsolidieren, Bericht erstellen, Massnahmen und Empfehlungen ausabreiten)
• Review Meeting (Ergebnis prüfen, Feststellen aber nicht Lösungen entwicklen, Empfehlungen abgeben)
• Nacharbeit (Protokollierte Befundbearbeitung, Reporting)

Rollen: 

• Moderator (Review Leiter, ordnungsgemässer Ablauf sicherstellen)
• Gutachter (Sachverständiger)
• Schreiber (Sitzungs-Protokoll)
• Manager (Auftraggeber)
• Autor (Urherber)
• Reviewer (Alle Beteiligten ausser Manager und Autor)

Review Meeting Vorbereitung: 

• Analyse mit Checklisten / Fragelisten
• Analyse gemäss Aufrtrag
• Interviews vorberieten / durchführen
• Befunde festhaten
• Fragen festhalten

• Qualitätskosten:
  • Konformitätskosten - Kosten während des Projektes um Fehler zu vermeiden
    • Präventionskosten
      • Training
      • Ausrüstung
      • Zeit es recht zu machen
    • Bewertungskosten 
      • Testing
      • Inspektion
  • Non Konformitätskosten - Kosten während und nach dem Projekt aufgrund von Fehlern
    • Interne Fehler Kosten (Projekt)
      • Rework
      • Abfall
    • Externe Fehler Kosten (Kunde)
      • Garantie
      • Verlohrenes Business
• Wann Projektevaluierung: 
  • Projektevaluierung: Zu jedem Zeitpunkt
  • Gate Review: Phasenende
  • Audit: Zu jedem Zeitpunkt
  • Post Projekt Review: Abschlussphase
  • Benefit Realization Review: Nach ausreichender operatier Erfahrung mit Proj. Ergebnis

Ziele: 

• Laufene Prüfung von Projekt und Produkt
  • wo Fehler vorhanden sind
  • ob das richtige Podukt erstellt wird
  • ob das Produkt richtig erstellt wird
  • ob Vorgaben und Rahmenbedingungen eingehalten werden
  • wo Fehler vorhanden sind

Warum?

• Bestehen Abweichungen beim Vergleich IST und SOLL
• Was sind die Gründe für die Abeichungen?
• Mit welchen Massnahmen können wir IST am effizientesten auf SOLL zurück bringen?
• Lessons Learned

Quantitative Risk Analysis

• Basierend auf Eintrittswarscheinlichkeit und Impact kann monatärer Wert berechnet werden
• Ziel: Risks, Impacts können Verglichen werden
• Tools für die quantitative Risiko Analyse: 
  • Sensivity Analse (Welche Risiken haben grössten Impact)
  • Erwarteter Monatärer Impact
  • Entscheidungsbaum Analyse
  • Modellierung und Simulation (typischerweise Monte Carlo)

Risk Response (Massnahmen): 

• Risk Respone Planning (Contingency Management, Workarounds)
• Risk Mitigation Strategies
• Risk Response Strategien:

1. Avoid
2. Transfer
3. Mitigate
4. Acceptance

• Risiken Top 5 in diesem Case: E = Eintrittswarscheinlichkeit, I = Impact 
  • Datenschutz - E: I: 
  • Know-How - E: 50% I: 100'000 Kosten durch Verzögerungen
  • Schnittstellen / Konnektivität: E: I: 
  • Sicherheit E: I: 
  • Verfügbarkeit E: I: 
  • Anbieter Abhängigkeit E: I: 
  • Vertrauen durch Kunden E: I: 

Massnahmen:

• Know-How: Ausbildung / Schulung, Experten Review, Experten für Projekt einstellen

Risiko Bewertungs-Faktoren:

• Kategorisierung (Contract, Cultural, Management, Technical)
• Klassifizierung (Known, Predicitble, Unpredictible, Positive Risks -> Opportunities)
• Eintrittswarscheinlichkeit
• Priorisierung
• Impact 

Risiko Priorisierung: 

• Risiko Identifizieren, Review und Gruppieren
• Risiko Assessment: Eintrittswarscheinlichkeit, Potentieller Impact, Konsequenzen
• Risiko Faktor Berechnung mit Impact Matrix aufzeigen
  • Eintrittswarscheinlichkeit
  • Opportunities 
  • Threats

Risk Management Prozess:

• Risk Assessment
• Risk Response
• Risk Control

Plan 

• Identify (Brainstorming, SWOT, ..)
• Analysis
• Plan Risk Response

Do

• Do It

Check

• Monitor and Control

Act

• Reasses

• Einsatz eines Schätzungs Notizbuch, niederschreiben von Annahmen und vergabe von parametern und unterschreichen der Schätzung
• Record the requested accuracy
• Sicherstellen dass man die beste input qualität bekommt die möglich ist
• Sicherstellen damm man die kompletest object Beschreibung kriegt, die möglich ist
• Nicht nur Funktion Requirements auch NFR sind wichtig
• Wenn möglich historische Daten nutzen, und beachten von wo sie kommen
• Immer folgendem Ablauf folgen
  1. Scope,
  2. Effort,
  3. Timeline
  4. Cost
• Einholen von mehrere unabhängigen Schätzunge und nutze senkrechte methoden
• Verify and Validate:
  • Verschiedene Experten reviewen die Schätzungen
  • Betroffene Entwickler Reviewen ihren Teil
• Validate: Plausibilisierung von Speziellen Schätzelementen
• Reserven, Contingency einklallkulieren udn dokumentieren
• Genauigkeits-Range angeben

Good Practices:

1. Klare Task Identifizierung
2. Breite Schätz-Beteiligung
3. Solide Datenbasis
4. Standartisierte Struktur für Schätzungen
5. Unsicherheitsn Identifiziert und dokumentiert
6. Ausgeschlossene Kosten dokumentieren
7. Unabhöngige Schätzungs Reviews
8. Signifikate Projekt-Changes sollen zu Schätzungs-Review führen

Schätzverfahren:

1. Analogous: Appliziern von ähnlichen Projekten, welche bereits einmal durchgeführt wurden, Ranges angeben, geht schnell, aber ungenau, 
   1. Three Point Estimate: Pessimistic Value, Optimistic Value, Most Likely Value
   2. Delphy Tecnique: Experten schätzen individuell, varianzen werden analysiert, argumentiert und konsolidiert
   3. Percent Method: basierend auf bisherigen Erfahrugnen, +/- Varianzen in Prozent schätzen
2. Parametric: Function Point: Workbreakdown in Funktionen, Klassifizieren nach Komplexität, Aufwand pro Funktion, geht schnell, aber ungenau, z.B. bei SW Entwicklung
3. Bottom Up: Solider Projektplan als Ausgangslage, Lowest Level Units (Work Packages), Overhead beim Aggregieren nicht vergessen, Riski Contingency für jedes WP, verschiedene Schätzer liefern Schätzungen idr bei Überschaubaren Projekten zur Schätzung des grossen Ganzen

Mit Vortsschritt der Zeit, mit der Schätzung immer genauer werden kann. (Projekt/Portfolio-mngt). Am anfang starke streuung. Am Anfang eines Projektes macht es keinen Sinn genau Schätzungen abzugeben. Keine Zahlen, eher Ranges.

Vorgehen zum Schätzen von Ressourcen und Zeitdauer von Projekten: (Siehe Grafik)

• Schätzung Vorbereiten: Jeder zusätzliche Input hilft (z.B. Historische Projektinformationen, Assumptions)
• Schätzung Erstellen: Verwenden der Schätzmethoden Analogous, Parametric und Bottom Up
• Schätzung Managen: Tools und Techniken anwenden, Schätzung Managen
• Schätzprozess verbessern: Stakeholder Feedback, Actual vs Estimate vergleichen, ... 

Schätzverfahren:

1. Analogous: Appliziern von ähnlichen Projekten, welche bereits einmal durchgeführt wurden, Ranges angeben, geht schnell, aber ungenau
   1. Three Point Estimate: Pessimistic Value, Optimistic Value, Most Likely Value
   2. Delphy Tecnique: Experten schätzen individuell, varianzen werden analysiert, argumentiert und konsolidiert
   3. Percent Method: basierend auf bisherigen Erfahrugnen, +/- Varianzen in Prozent schätzen
2. Parametric: Function Point: Workbreakdown in Funktionen, Klassifizieren nach Komplexität, Aufwand pro Funktion, geht schnell, aber ungenau
3. Bottom Up: Solider Projektplan als Ausgangslage, Lowest Level Units (Work Packages), Overhead beim Aggregieren nicht vergessen, Riski Contingency für jedes WP, verschiedene Schätzer liefern Schätzungen idr bei Überschaubaren Projekten zur Schätzung des grossen Ganzen

Traditionelle Hierarchien und Managementprozesse sind stark mit den täglichen Anforderungen an Steuerung und Effizienzsteigerung des Unternehmens beschäftigt. Sie sind dadurch kaum noch in der Lage, mit immer neuen Situationen Schritt zu halten und kreativ einzigartige Lösungen zur Sicherung von Wettbewerbsvorteilen zu erschaffen, die auch noch dauerhaft erfolgreich sein sollen.

Die Idee des Dualen Betriebssystem ist die Schaffung einer parallene netzwerkartigen Struktur (wie sie meisten bei einer Gründung anzutreffen ist). Dieses Parallelsystem soll die verlorengegangene Agilität und Geschwindigkeit wiederherstellen..

1. Create a Sense of Urgency
    Helfe den Bedarf für Change sichtbar zu machen -> Mitarbeiter sollen Comfort Zone verlassen
2. Form a Powerful Coalition
    Stelle ein Keyplayer Team mit genug Power und Expetrise, Leadershiop und Credibility zusammen
3. Create a Vision for Change
    Entwickle eine Strategie, die Vision zu erreichen
4. Communicate the Vision
    So viele wie möglich sollen die Vision verstehen
5.Remove Obstacles
    Encourage risikoreiche ideen und aktionen, um Viusions-Hindernisse zu Überwinden
6. Create Short-Term Wins
    Planen, Low Hanging Fruits, welche sichtbar sind schnell zu erreichen. Recognize and Reward
7. Build on the Change
    Mehr Ressourcen und Initiativen starten, durch alle Hierarchien Projektleitungen aufsetzen
    Druck aufrecherhalten; Belegen dass der Eingeschlagene Weg funktioniert
8. Embed the Change into the Culture
    Belegen, dass der neue Weg besser funktioniert als der Alte
    Verbinden von Erfolg mit den eingeleiteten Massnahmen herstellen

• Bridges Transformation Model
  • + Implementing Change
  • + Understand how people feel
  • - Kein Ersatz für andere Change Management Ansätze
• Rogers Technology Adaption Curve
  • + Creates Understanding for Change for Audience
  • + Help to Identify Opinion Makers and influencers
  • - People drift from Category to Category, depending on the specific Change
  • - Adaption Terms tell nothing about how population might respond to change
• Kubler-Ross Five Stage Model
  • + Gute Grundlage für Entwicklung einer Kommunikattionsstrategie
  • - Sehr auf Individuum Fokussiert, Schweirig für applizierung auf Gruppe
• Prosci's ADKAR Model
  • + Klare Management Checkliste für Change Management 
  • - Berücksichtigt nicht die Führungsrolle und die grundsätze des Programm Managements zur Erreichung von Klarheit und einer Richtung für Change
• Kotters 8 Steps to Change
  • + Klare Schritte für Prozess Guidance
  • - Top Down Ansatz macht es schwierig für andere Formen von richtiger Teilnahme

M13 29-31

• Globalisierung
• Digitalisierung
• agile Märkte
• Anorganisches Wachstum
• Failure of Success / Adapt or Die
• Trägheit bekämpfen
• Angestrebte / Nötige Organisationsentwicklung

1. Kategorien von Stakeholdern:

a. Corporate Functions (HR, CxO,Program mngt. etc.)

b. End-User Organisation (Executives, Line Management,Data Owners etc.)

c. Project Organisation (Executives, Line Management, Product&Technicalspezialist)

d. System Operations (IT-Service mngt., Service Desk, App. Mngt. etc.)

e. External (Suppliers, Requlatory Bodies)

Interessen:

a. Pogramm Management --> Interessiert an Budgetieren und Priorisieren --> Key players (power/intersset Matrix)

b. Line Management --> Interessiert am Inhalt der IBeacon informationen --> Zufriedenstellen

c. technical Spezialist --> Interessiert an Sotwarekomponenten --> Zufriedenstellen

d. Applikation Management --> Interessiert an release zyklus --> Informiert halten

e. Customer --> Interessiert Message die vermitellt wird --> Zufriedenstellen / Key Players

Unterteilung (Tabellarisch) gemäss Bild.

Warum Stakeholderanalyse: 

• Unterschiedliche Interessen aufgrund von ihren Rollen und Aufgabenstellungen
•  

Vorgehen: 

• Stakeholder Identifizieren (Identity Matrix erstellen mit Befürwortern, Gegnern, neuen Stakeholdern) -> Stakeholderdiagram
  • 5 grobe Kategorien: Corporate Functions, End-User Organisation, Project Organization, System Operations, External)
• Stakeholder Klassifizieren (Einflussfaktoren als Netzdiagramm zur Einordnung)
  • Was erwartet ein Stakeholder?
  • Welche typischen Fragen hat er?
  • Was darf man aus seiner Sicht nicht tun?
  •  
• Ansatz zum Stahkeholder Management festlegen
  •  
• Ergebnisse dokumentieren

Gründe für Widerstand

• Eigeninteressen
• Missverständnisse
• Mangel an Vertrauen
• Untershciedliche Einschätzung der Lage
• Geringe Toleranzschwelle für Change

Situationen und Methoden zum Management von Widerstand

• siehe Grafik

1. Keine Schaffung einer ausreichenden Dringlichkeit
2. Keine Schaffung einer leistungsfähigen Führungskoalition
3. Fehlende Vision
4. Unzureichende Kommunikation der Vision um den Faktor zehn
5. Nicht Beseitigung von Hindernissen für die neue Vision
6. Nicht systematisch Planung und Erstellung, kurzfristiger Gewinne
7. Sieg ist zu früh deklariert
8. Nicht verankern Veränderungen in der Unternehmenskultur

Eigenschaften

• Es kann keine Richtung aufgezwungen werden (Vogelschwarm)
• Im angeregten Zustand organisierne sich die Komponenten selber
• Komplex, nicht deterministisch, adaptiv

Nutzen: 

• Gleichgewicht stören -> in gewünschte Richtung locken
• Ungleichgewiucht hegen
• Kreativität fördern (Grenze zum Chaos)
• Unruhe und Rastlosigkeit im Team nutzen

2, 3

siehe Grafik

• Es gibt keine Veränderung ohne Widerstand!
• Widerstand enthält immer eine verschlüsselte Botschaft!
• Nichtbeachtung von Widerstand führt zu Blockaden!
• Mit dem Widerstand, nicht gegen ihn gehen!

Fragen, um den Konflikt näher zu bestimmen:

1.Was für eine Konfliktart liegt entsprechende der Ursache vor?

2.Wer ist alles am Konflikt beteiligt?
-Wer hat welche Rolle im Konflikt (Treiber, Reagierender, Informant, Verbündeter, Ratgeber)?
-Wer hat ein Interesse daran, dass der Konflikt aufrechterhalten wird?

3. Auf welcher Eskalationsstufe befindet sich der Konflikt?

siehe Grafik

In einem DreamTeam sind alle funktionalen Rollen umgesetzt. (Heterogen)

siehe Grafik

- Wenn gemeinsame Aktivitäten gelingen sollen, müssen diese unbedingt kooriniert werden

- Kommunikationsverlauf gut dokumenterien -> Nachvollziehbarkeit

- Genügend Zeit für kommunikativen Austausch, ausreichende Medienkompetenz der Mitglieder

Verschiedene Rollen sollen abgedekt sein

Gewisses Mass an Freiheit für internen Wettbewerb, Regelmässiges Feedback

... tbd