PCMA LB1 + Zusatzfragen

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

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

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

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.

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

• 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

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

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

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

Mit ortsschritt 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.

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

• 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

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

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

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

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

• 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

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

tbd

Agile Methoden: (extreme Programming, Scrum, Feature Driven Development FDD, Kanban, Lean, Dynamic Systems Development Method DSDM)

• Fokus auf nutzbare, funktinierende Ergebnisse
• Selbstorganisierend
• Kontinierlich wachsendes, nutzbares Produkt
• Kurze Zylken, flexibel änderbar
• Kunde stark involviert
• T&M

Traditionelle Methoden: (Wasserfall, V-Modell)

• Fixpreis

- 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

siehe Grafik

siehe Grafik

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

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?

• 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!

siehe Grafik

2, 3

1. Poor Requirements definition -> Businessneeds/Stakeholder besser involvieren/Abholen.

2. Poor Scope def. -> Agile Prozesse (wenn man noch nicht wo die Reise hin geht)  und/oder Clear Business Objectives (keine Scope Change) / Scope Creep

3. Inadekuates Risiko mngt. -> Executive Mngt. Support (Auch hinter den Risiken stehen) / Optimization ( zusätzliche Informationen stetig auswerten & prüfen -> Implikationen auf das Projekt), Poor Monitorin and Controlling,Decision Making Problem

4. Kommunikationsprobleme -> Projekt Management Expertise (gut/richtig/kompetent), Bad Stakeholder Mngt, Lack of Team Planning Sessions, Decision Making Problem, Unsupported Project Culture

5. Fehlendes qualifiziertes Personal/Ressourcen -> externe Ressorucen beiziehen, Weiterbildungen, plannung (Ressourcen stehe nicht zu verfügung)

1. Executive Management Support (Auch hinter den Risiken müssen sie stehen)

2. user Involvement (Business needs abholen)

3. Optimization (Planen und durchziehen aber auch stetig zusätzliehc Informationen Auswerten und prüfen was das für Implikationen auf das Projekt hat)

4. Skilled Resources

5. Project Management Expertise (Projekt Management muss gut/richtig & kompetent durchgeführt werden)

6. Agile Process (Falls man noch nicht genau weiss wo es hingeht)

7. Clear Business Objectives (Kein Scope Change)

8. Emotional Maturity (Unterschiedliche Erwartungen können zu Spannungen führen)

9. Execution

10. Tools and Infrastructure

Der Business Model Canvas zeigt die Zusammenhänge auf der Achse 

• "Strategic Enterprise" -> Strategische Planung und Roadmap
• "Tatical Planning Domain Level" -> Steategic Initiatives Alignment, Project Portfolio
• "Operations System Level" -> Program Management / Project Management
• "Humen Resource Level" -> Change und Transofrmation Management

über die Zeit (Jahre) von "as Is" bis "Visionary Target" auf, kurz: 

Das Projekt und Change Mangement umfasst die strategische Planung bis zur operativen Projekten.

•Wo stehen wir?

•Warum machen wir das Projekt?

•Was soll konkret erreicht werden?

•Wer ist Auftraggeber und wer ist involviert?

•Wie strukturieren wir das Projekt?

•Bis wann müssen Teilziele erreicht werden?

•Wie viel kostet das Projekt?

a: Projekt

b: Projektportfolio

c: Programm

d:  Programm

e: Projekt

f: Programm

g: Portfolio

h:Projekt

i: Portfolio

j: Programm

k: Portfolio

l: Programm

m: Projekt

n: Projekt

o: Portfolio

a. Project Office

b. MultiprojectManagement

c. Project Management Office

d. Project Office

e. Project Management Office

f. Multiprojekt Management

g. Project Office

h. Project Office

i. Project Managmement Office

j. Project Office

1. Unternehmensweiter Stragetieprozess
2. Abgestimmte PRozessarchitektur
3. Organisationsstruktur, Verantwortlichkeiten
4. Anpassung Fähigkeiten, Wertesystem, Unternehmenskultur
5. Verantwortlichkeiten IT Entwicklung, Governance
6. Technologiestrategie

- Strategy Execution Alignment (Konsolidierung, Wachstum mit neuen Services)

- Technology Transformation Alignment (Waschstum mit neuen Service, ) Bsp. Prozesse werden weltweit ausgerollt mit Hilfe von IT

- Service Level Alignment (Schrumpfung, Konsolidierung) Bsp. In grösseren Organisationen -> Technologien werden genutzt, um Business optimal zu unterstützen "Business Anforderungen" werden "extrem gut" abgeholt (Z.B. Ausfallsicherheit etc.) zu Best möglichen Kosten "Service Excellence"

- Competitive Potential Alignment (Wachstum mit neuem Geschäft) Bsp. AI / Google Suchmaschine als neue Technologie bringt neue Business Modelle

tbd

1. Geschäftsmodell

2. Geschäftstrategie (Kundezufriedenheit erhöhen)

3. IT Geschäftsmodell (Wertbeitrag der IT zur Kundenzufridenheit erhöhen ableiten)

4. Identifizierung der Gestaltungstreiber für die IT (Kundenzufriedenheit erhöhen, z.B. schneller Support)

5. IT Zielbild-Design (Gegenüberstellung Gestaltungsdimensionen zu Gestaltungstreiber zu --> Applikations-Architektur - schneller Support)

6. Strategische Massnahmen pro Gestungstreiber & Dimenstion ableiten (einführung CRM)

7. IT Zielbild erstellen pro Business Unit (BU IT Einführung CRM, Prozess Mngt, definierung CRM-Prozesse, etc.)

8. Daraus IT Roadmap ableiten. (Planung) 

Fähigkeit z.B. Kundebetreuung.

Darstellung mit einer Fähigkeitenkarte, Unterteiliung in Dimensionen

• People (Organisation, Fähigkeiten, Kapazitäten)
• Process (Konzept, GEschäftsprozess, Information)
• Material (Infrastuktur, IT, Ausgestaltung)

> Mit Business Strategie abgestimmtes Projektprotfolio

Das Unternehmen in Fähigkeiten unterteilen (Überlappungsfrei). Um dann Projekte den einzelenen Fähigkeiten zuteilen.

Value Contribution --> Hebel wie stark der Wertbeitrag ist.

Overall Condition z.B. Die Fähigkeit ist mit 2 sehr schlecht ausgeprägt. Also schlechtem zustand.

Complexity  --> hohe Komplexität.