8. Quiz
Lernziele
Nach diesem Quiz können Sie: - Ihr Wissen aus allen Kapiteln dieses Moduls testen und festigen - Verständnislücken identifizieren und gezielt nacharbeiten - Sich auf die Prüfung zum Thema Projektsteuerung in IT-Projekten vorbereiten
Modul Übersicht
Modul 11 - Kapitel 8 Bearbeitungszeit: ~45-60 Min Format: 15 Comprehensive Fragen
Quiz-Anleitung
Hinweise zum Quiz
- Das Quiz besteht aus 15 Fragen zu allen Themen dieses Moduls
- Die Fragen decken alle 7 Kapitel ab
- Klicken Sie auf die Fragen, um die Lösungen anzuzeigen
- Bearbeiten Sie das Quiz zuerst selbstständig, bevor Sie die Lösungen einsehen
- Bei Fragen, die Sie nicht beantworten können, markieren Sie diese zur Nacharbeit
Quiz-Fragen
Frage 1: Projektsteuerungs-Regelkreis
Ein Projektleiter überwacht die Projektdurchführung und stellt fest: - Projektfortschritt: 80% geplant, aber nur 70% erreicht - Termine: Meilenstein M3 ist 2 Wochen überfällig - Kosten: 50.000 € ausgegeben bei einem Budget von 60.000 € (geplant zu diesem Zeitpunkt: 45.000 €) - Qualität: 12 kritische Fehler im Systemtest gefunden (geplant: max. 5)
Der Projektleiter dokumentiert diese Abweichungen im Projektstatusbericht.
a) Welche Schritte des Regelkreises wurden durchgeführt? b) Welche Schritte fehlen noch? c) Welche Maßnahmen sollten ergriffen werden? Nennen Sie für jede Abweichung eine geeignete Maßnahme.
Lösung: a) Durchgeführt: - Phase 1: Datenerfassung (Ist-Werte): Projektleiter hat Ist-Werte erfasst (70% Fortschritt, 2 Wochen Verzögerung, 50.000 € Kosten, 12 Fehler) - Phase 2: Soll-Ist-Vergleich: Projektleiter hat Planwerte mit Ist-Werten verglichen (80% vs 70%, pünktlich vs 2 Wochen überfällig, 45.000 € vs 50.000 €, ≤5 vs 12 Fehler)
b) Es fehlen: - Phase 3: Abweichungsanalyse: Ursachenforschung für jede Abweichung (Warum Fortschritt hinterher? Warum Kostenüberschreitung? Warum so viele Fehler?) - Phase 4: Steuerungsmaßnahmen: Korrekturmaßnahmen einleiten (Projektbeschleunigung, Kostensenkung, Qualitätssteigerung)
c) Geeignete Maßnahmen:
| Abweichung | Maßnahme | Kategorie |
|---|---|---|
| Fortschritt (70% vs 80%) | Projektbeschleunigung: Zusätzliche Ressourcen, Parallelisierung, Priorisierung kritischer Pfade, ggf. Scope-Reduzierung | Projektbeschleunigung |
| Termine (2 Wochen Verzögerung) | Projektbeschleunigung: Crunch-Mode, Weekend-Work, Outsourcing, Meilenstein neu planen, ggf. Deadlines verschieben | Projektbeschleunigung |
| Kosten (50.000 € vs 45.000 €) | Kostensenkung: Aufwandsreduktion, Outsourcing günstiger, Budgeterhöhung beantragen, ggf. nicht kritische Features streichen | Kostensenkung |
| Qualität (12 vs 5 Fehler) | Qualitätssteigerung: Zusätzliche Tests, Code-Reviews, Refactoring, Bug-Fix-Sprint, ggf. Go-Live verschieben | Qualitätssteigerung |
Frage 2: DIN 69901 vs. PMBOK vs. ISO 21500
Ein multinationaler Konzern plant die Einführung eines einheitlichen Projektmanagement-Standards. Der Konzern hat Hauptsitze in Deutschland (München) und USA (New York). Die Projektleiter debattieren über den besten Standard.
a) Erklären Sie die wesentlichen Unterschiede zwischen DIN 69901, PMBOK Guide und ISO 21500. b) Welcher Standard oder welche Kombination von Standards würden Sie empfehlen und warum? c) Wie würde die Projektmanagementphase "Steuerung" in den drei Standards definiert?
Lösung: a) Wesentliche Unterschiede:
| Aspekt | DIN 69901 | PMBOK Guide | ISO 21500 |
|---|---|---|---|
| Herkunft | Deutschland (Deutsche Norm) | International (USA, Project Management Institute) | International (ISO) |
| Struktur | 5 Projektmanagementphasen | 5 Prozessgruppen | 5 Prozessgruppen |
| Phasen/Gruppen | Initialisierung, Definition, Planung, Steuerung, Abschluss | Initiierung, Planung, Ausführung, Überwachung & Steuerung, Abschluss | Initiierung, Planung, Umsetzung, Controlling, Abschluss |
| Steuerungs-Definition | Eigenständige Phase "Steuerung" mit 15 Prozessen | Prozessgruppe "Monitoring and Controlling" mit 11 Prozessen + Prozessgruppe "Executing" mit 8 Prozessen | Prozessgruppe "Controlling" |
| Detailtiefe | Sehr detailliert, spezifisch | Umfassend, weltweit angewendet | Konzeptuell, allgemein |
| Anwendung | Häufig im deutschsprachigen Raum | Weltweit, sehr verbreitet | Zunehmend international |
| Wissensgebiete | Ablauf, Termine, Änderungen, Information, Kommunikation, Kosten, Organisation, Qualität, Ressourcen, Risiko, Projektstruktur, Verträge, Ziele | 10 Wissensgebiete (Integration, Scope, Zeit, Kosten, Qualität, Ressourcen, Kommunikation, Risiko, Beschaffung, Stakeholder) | 9 Themengruppen (Integration, Stakeholder, Inhalte, Ressourcen, Termine, Kosten, Risiko, Qualität, Beschaffung, Kommunikation) |
b) Empfehlung: Kombinierte Herangehensweise
Empfehlung: 1. DIN 69901 als primäre Struktur für den deutschen Hauptsitz und deutschsprachige Standorte 2. PMBOK Guide für Details, Methoden und internationale Zusammenarbeit (USA-Standort, globale Projekte) 3. ISO 21500 als konzeptioneller Rahmen und für Zertifizierungszwecke
Begründung: - DIN 69901 gewährleistet Compliance mit lokalen Anforderungen in Deutschland und ist gut verständlich für deutschsprachige Projektleiter - PMBOK Guide bietet breite Methodenvielfalt, weltweit anerkannt und ideal für internationale Zusammenarbeit - ISO 21500 erleichtert internationale Kommunikation und Standardisierung, sowie Zertifizierung (z.B. ISO 21500-Zertifizierung für Unternehmen) - Die Kombination nutzt die Stärken aller drei Standards und vermeidet die Schwächen der einzelnen Standards
c) Projektmanagementphase "Steuerung" in den drei Standards:
| Standard | Definition der "Steuerung" | Anzahl Prozesse |
|---|---|---|
| DIN 69901 | Eigenständige Projektmanagementphase neben Initialisierung, Definition, Planung und Abschluss | 15 einzelne Prozesse |
| PMBOK Guide | Prozessgruppe "Monitoring and Controlling (Überwachung & Steuerung)" neben Prozessgruppe "Executing (Ausführung)" | 11 Prozesse in Monitoring & Controlling + 8 Prozesse in Executing |
| ISO 21500 | Prozessgruppe "Controlling" (Überwachung & Steuerung) neben Initiierung, Planung, Umsetzung und Abschluss | (genaue Anzahl nicht in ISO 21500 spezifiziert, konzeptuell) |
Frage 3: Kick-off-Meeting vs. Projektstart-Workshop
Ein mittelständisches Unternehmen (250 Mitarbeiter) führt ein neues HR-Management-System ein. Die Projektleitung diskutiert, ob ein Projektstart-Workshop, ein Kick-off-Meeting oder beide durchgeführt werden sollten.
a) Was ist der Hauptunterschied zwischen einem Projektstart-Workshop und einem Kick-off-Meeting? b) Wann finden Workshop und Kick-off im Projektzyklus statt? c) Welche Empfehlung würden Sie für dieses Szenario geben und warum?
Lösung: a) Hauptunterschiede:
| Aspekt | Projektstart-Workshop | Kick-off-Meeting |
|---|---|---|
| Hauptcharakter | Interaktiv, ergebnisorientiert | Informationsorientiert, kommunikativ |
| Zweck | Gemeinsames Erarbeiten wesentlicher Projektgrundlagen | Gemeinsames Verständnis entwickeln & Commitment abgeben |
| Kommunikation | Bidirektional (Dialog) | Unidirektional (Information) mit Diskussion am Ende |
| Teilnehmer | Projektleiter, (Kern-)Team, ggf. Vertreter des Auftraggebers | Alle Stakeholder: Auftraggeber, Projektteam, Lenkungsausschuss, weitere |
| Dauer | Halbtags bis ganztägig (4-8 Stunden) | 2-3 Stunden |
| Ergebnis | Detaillierte Planungen, konzeptionelle Grundlagen | Offizieller Startschuss, verbindliches Commitment |
b) Zeitpunkt im Projektzyklus:
| Veranstaltung | Zeitpunkt im Projektzyklus |
|---|---|
| Projektstart-Workshop | Früh in der Planungsphase (nach Projektinitialisierung, vor oder während der detaillierten Planung) |
| Kick-off-Meeting | Nach Abschluss der Planung (nach PMBOK) bzw. zum Beginn der "Steuerung" (nach DIN 69901) |
c) Empfehlung: Beides durchführen
Empfehlung: 1. Zuerst Projektstart-Workshop mit dem Kern-Team und wichtigen Stakeholdern zur detaillierten Ausarbeitung von Anforderungen, Prozessen und Planungen 2. Danach Kick-off-Meeting mit allen Beteiligten zur offiziellen Verkündung und Commitment-Einhaltung
Begründung: - Projektgröße: 250 Mitarbeiter sind ein mittleres Unternehmen, aber das Projekt ist komplex und betrifft viele Abteilungen - Komplexität: HR-Management-Systeme sind komplex und haben viele Schnittstellen zu anderen Systemen (Payroll, Zeitwirtschaft, etc.) - Stakeholder: Viele Stakeholder sind involviert (HR-Abteilung, Management, IT, alle Mitarbeiter) - Kombination ist ideal: - Workshop ermöglicht detaillierte Zusammenarbeit und gemeinsame Erarbeitung von Grundlagen - Kick-off sichert Commitment aller Beteiligten und Transparenz über das Projekt - Risikominimierung: Workshop reduziert Risiken durch detaillierte Planung, Kick-off reduziert Akzeptanzrisiko
Alternative: Wenn das Projekt besonders klein oder die Planung bereits sehr detailliert ist, könnte ein Kick-off-only ausreichend sein. Wenn das Projekt besonders komplex ist oder viele offene Fragen existieren, könnte ein Workshop-only ausreichend sein, mit einem späteren "Information-Meeting" statt formalem Kick-off.
Frage 4: IT-Projekttypen und Herausforderungen
Ein IT-Dienstleister präsentiert einem Kunden drei Projekttypen für eine geplante Initiative. Der Kunde hat folgende Anforderungen: - "Wir möchten eine neue mobile App für unsere Kunden entwickeln" - "Außerdem müssen wir unsere historischen Kundendaten in das neue System migrieren" - "Und wir möchten unsere bestehenden CRM-Prozesse optimieren"
a) Welcher IT-Projekttyp entspricht welcher Anforderung? b) Nennen Sie für jeden Projekttyp eine spezifische Herausforderung und eine geeignete Maßnahme. c) Wie würden Sie die drei Projekte in einem übergeordneten Programm koordinieren?
Lösung: a) Projekttypen:
| Anforderung | Projekttyp |
|---|---|
| "Neue mobile App für Kunden entwickeln" | Entwicklungsprojekt |
| "Historische Kundendaten in das neue System migrieren" | Migrationsprojekt |
| "Bestehende CRM-Prozesse optimieren" | Optimierungsprojekt |
b) Spezifische Herausforderungen und Maßnahmen:
| Projekttyp | Spezifische Herausforderung | Geeignete Maßnahme |
|---|---|---|
| Entwicklungsprojekt (Mobile App) |
Anforderungsmanagement: Anforderungen sind oft unvollständig oder ändern sich im Projektverlauf | Agiles Requirements Engineering (z.B. Scrum mit Sprints), Stakeholder-Workshops, User Stories, Continuous Feedback |
| Migrationsprojekt (Datenmigration) |
Datenintegrität: Risiko von Datenverlust oder Datenkorruption bei Migration | Datenvalidierung, Hash-Verfahren zur Datenprüfung, Testmigrationen mit Testdaten, Rollback-Plan vorbereiten und testen |
| Optimierungsprojekt (CRM-Prozesse) |
Regressionen: Optimierungen können andere Funktionen brechen | Regressive Tests, Testautomatisierung, Versionsmanagement, Careful Refactoring |
c) Koordination der drei Projekte in einem übergeordneten Programm:
Programmstruktur:
graph TD
A[Programm: Kundensystem-Modernisierung] --> B[Projekt 1: Mobile App<br/>Entwicklungsprojekt]
A --> C[Projekt 2: Datenmigration<br/>Migrationsprojekt]
A --> D[Projekt 3: CRM-Prozesse<br/>Optimierungsprojekt]
B --> E[Meilenstein: App MVP fertig]
C --> F[Meilenstein: Daten migration fertig]
D --> G[Meilenstein: Prozesse optimiert]
E --> H[Programm-Meilenstein: Alle Einzelprojekte fertig]
F --> H
G --> H
H --> I[Integration & Testing]
I --> J[Programm-Go-Live]
style A fill:#ffecb3
style H fill:#c8e6c9
style J fill:#4caf50Koordinationsmaßnahmen:
| Koordinationsaspekt | Maßnahmen |
|---|---|
| Programmmanagement | Programmmanager für übergeordnete Koordination aller drei Projekte |
| Gemeinsame Meilensteine | Definition von gemeinsamen Meilensteinen und Abhängigkeiten |
| Integrations-Tests | Integrierte Tests über alle drei Projekte hinweg (App + CRM-Prozesse + migrierte Daten) |
| Ressourcen-Management | Gemeinsames Ressourcen-Management (Entwickler, Tester, Datenbankexperten) |
| Risikomanagement | Gemeinsames Risikomanagement für das gesamte Programm |
| Kommunikation | Gemeinsame Kommunikation an alle Stakeholder |
| Qualitätsmanagement | Gemeinsame QM-Standards und Teststrategien |
| Change Management | Gemeinsames Change-Management für Änderungen, die mehrere Projekte betreffen |
| Go-Live-Koordination | Koordinierter Go-Live aller drei Projekte (ggf. Phasen-Rollout) |
Frage 5: Rollout-Strategien
Ein Krankenhaus plant die Einführung eines neuen Elektronischen Gesundheitsakten-Systems (EHR). Das System ist: - Kritisch für den klinischen Betrieb - Wird von 800 Mitarbeitern (Ärzte, Pfleger, Verwaltung) genutzt - Ist komplex mit vielen Schnittstellen zu Labor, Radiologie, Apotheke, etc. - Hat hohe Compliance-Anforderungen (Patientenschutz, Datenschutzgesetze)
Die Projektleitung diskutiert verschiedene Rollout-Strategien.
a) Welche Rollout-Strategien kommen in Frage? Nennen Sie alle und charakterisieren sie kurz. b) Welche Strategie(n) würden Sie empfehlen und warum? c) Erstellen Sie einen groben Rollout-Plan für Ihre empfohlene Strategie.
Lösung: a) Rollout-Strategien in Frage:
| Strategie | Charakteristik | Geeignet für dieses Szenario? |
|---|---|---|
| Big Bang (Stichtagseinführung) | Alle Benutzer gleichzeitig zum Stichtag | Nicht empfohlen - Zu hohes Risiko für kritisches System mit 800 Benutzern |
| Pilotierung | Testlauf in einer Region, Abteilung oder einem Funktionsbereich, Erfahrungen sammeln, dann Rollout auf alle Bereiche | Empfohlen - Ideal für kritisches System mit vielen Benutzern, ermöglicht Lernerfahrung und Risikominimierung |
| Sukzessive Einführung (Step by Step) | Schrittweise Einführung (regional, funktional oder prozessorientiert), Ressourcen und Teams geschont | Empfohlen - Gut geeignet, um Ressourcen zu schonen und Schritt für Schritt zu lernen |
| Paralleleinführung | Altes und neues System parallel betrieben, höchste Sicherheit | Nicht empfohlen - Zu hoher Aufwand (doppelte Dateneingabe im Klinikumfeld ist kritisch) |
| Sandbox | Isolierte Testumgebung vor Live-Start | Empfohlen als Vorstufe zu Pilotierung |
b) Empfehlung: Sandbox + Pilotierung + Sukzessive Einführung
Empfohlene Strategie-Kombination: 1. Sandbox-Phase: System in isolierter Testumgebung ausprobieren 2. Pilot-Phase: Pilot in einer Klinik-Abteilung (z.B. Radiologie, 50 Mitarbeiter) für 4-6 Wochen 3. Sukzessiver Rollout: Schrittweise Einführung in weiteren Abteilungen (z.B. 2-3 Abteilungen pro Woche) über 8-12 Wochen
Begründung: - Risikominimierung: Pilotierung und sukzessiver Rollout minimieren Risiko - Lernerfahrung: Erfahrungen aus Pilot und frühen Phasen nutzen - Ressourcen-Schonung: Sukzessiver Rollout schont Ressourcen und Teams - Patientensicherheit: Schrittweise Einführung minimiert Risiko für Patienten - Compliance: Sorgfältiges Vorgehen ist wichtig für Compliance (Patientenschutz, Datenschutz) - Akzeptanz: Schrittweise Einführung erhöht Akzeptanz der Mitarbeiter - Realistisch: Realistische Erwartungshaltung, kein Big Bang mit zu hohem Risiko
c) Grober Rollout-Plan:
| Phase | Dauer | Aktivitäten | Ziel |
|---|---|---|---|
| 1. Sandbox-Phase | 4 Wochen | System in isolierter Testumgebung, Integrationstests, Datenmigrationstests | Technische Machbarkeit prüfen |
| 2. Pilot-Phase | 6 Wochen | Rollout in einer Pilot-Abteilung (Radiologie, 50 Mitarbeiter), Hypercare (2 Wochen), Erfahrungen sammeln | Lernerfahrung, Risikominimierung |
| 3. Erfahrungen sammeln & Anpassung | 2 Wochen | Learnings dokumentieren, Verbesserungen implementieren | Optimierung vor Haupt-Rollout |
| 4. Sukzessiver Rollout - Phase 1 | 2 Wochen | Rollout in 2-3 weiteren Abteilungen (150 Mitarbeiter), Hypercare (1 Woche) | Rollout beginnen |
| 5. Sukzessiver Rollout - Phase 2 | 2 Wochen | Rollout in 2-3 weiteren Abteilungen (150 Mitarbeiter), Hypercare (1 Woche) | Rollout fortsetzen |
| 6. Sukzessiver Rollout - Phase 3 | 2 Wochen | Rollout in 2-3 weiteren Abteilungen (150 Mitarbeiter), Hypercare (1 Woche) | Rollout fortsetzen |
| 7. Sukzessiver Rollout - Phase 4 | 2 Wochen | Rollout in verbleibenden Abteilungen (300 Mitarbeiter), Hypercare (1 Woche) | Rollout abschließen |
| 8. Gesamtsystem-Hypercare | 3 Wochen | Intensive Nachbetreuung aller Abteilungen, Stabilisierung | Stabilisierter Betrieb |
| 9. Nachbetreuung | 8-12 Wochen | Langfristige Stabilisierung, Optimierung, Übergabe an Betrieb | Nachhaltiger Betrieb |
Gesamtdauer: ca. 31-35 Wochen (ca. 8-9 Monate)
Alternative bei Dringlichkeit
Falls gesetzliche Vorgaben oder Dringlichkeit eine schnellere Einführung erfordern, könnte eine beschleunigte Variante gewählt werden: - Kürzere Sandbox-Phase (2 Wochen) - Kürzere Pilot-Phase (4 Wochen) - Größere Phasen im sukzessiven Rollout (z.B. 4 Abteilungen pro Phase statt 2-3) - Aber: Höheres Risiko, mehr Ressourcen in den Phasen erforderlich
Frage 6: Hypercare vs. Nachbetreuung
Ein Unternehmen hat ein neues Supply Chain Management (SCM) System eingeführt und jetzt ist der Go-Live vorbei. Die Projektleitung muss die Hypercare-Phase und die Nachbetreuungsphase planen.
a) Was ist der Hauptunterschied zwischen Hypercare-Phase und Nachbetreuungsphase? b) Welche spezifischen Aktivitäten sollten in der Hypercare-Phase durchgeführt werden? c) Welche spezifischen Aktivitäten sollten in der Nachbetreuungsphase durchgeführt werden? d) Wie lange sollten Hypercare und Nachbetreuung für ein SCM-System mit 200 Benutzern dauern?
Lösung: a) Hauptunterschied zwischen Hypercare und Nachbetreuung:
| Aspekt | Hypercare-Phase | Nachbetreuungsphase |
|---|---|---|
| Zeitpunkt | Kurz nach dem Go-Live, intensiv, technisch fokussiert | Nachgelagerte Phase, stabilisierend und unterstützend |
| Fokus | Reaktive Fehlerbehebung und schnelle Problembehandlung | Proaktive Optimierung und Nutzerbegleitung |
| Team | Projektteam ist stark involviert (Entwickler, Systemadministratoren, Support) | Projektteam reduziert, Supportteam zunehmend aktiv |
| Dauer | Wenige Tage bis Wochen | Einige Tage bis Monate |
| Ziel | Stabiler Start (schnelle Stabilisierung) | Nachhaltige Stabilität und Zufriedenheit |
| Intensität | Sehr hoch (24/7 in kritischen Fällen) | Mittel bis gering (reguläre Arbeitszeiten) |
| Kommunikation | Tägliche Updates, sehr eng | Wöchentliche Updates, moderat |
| Dokumentation | Fokus auf Hotfixes und Troubleshooting | Fokus auf Optimierung, Reports, Lessons Learned |
| Kosten | Hohe Kosten (viel Personal, Überstunden) | Mittlere Kosten (weniger Personal, reguläre Arbeitszeiten) |
b) Spezifische Aktivitäten in der Hypercare-Phase:
| Bereich | Aktivitäten | Verantwortlicher |
|---|---|---|
| Technische Stabilisierung | Überwachung von Systemverfügbarkeit, Performance, Schnittstellen, Backup-Prozessen | Systemadministratoren, DevOps |
| Fehleranalyse & -behebung | Bearbeitung von Tickets, Hotfixes, Nachjustierungen in der Konfiguration | Entwickler, Test-Team |
| Benutzersupport | Ansprechpartner für Anwender, Schulung "on the job", FAQ-Erstellung | Support-Team, Trainer |
| Kommunikation & Koordination | Regelmäßige Hypercare-Meetings, tägliche Statusberichte, Priorisierung von Problemen | Projektleiter, Rolloutmanager |
| Dokumentation | Nachführung von Betriebshandbuch, Troubleshooting-Guides, Lessons Learned | Dokumentationsverantwortliche |
| Übergabevorbereitung | Checklisten, Abnahmeprotokolle, Verantwortungsübergabe an Betrieb oder Support-Level | Projektleiter, Betriebsteam |
c) Spezifische Aktivitäten in der Nachbetreuungsphase:
| Bereich | Aktivitäten | Verantwortlicher |
|---|---|---|
| Stabilisierung des Produktivbetriebs | Überwachung des Systemverhaltens, frühzeitiges Erkennen von Problemen, Optimieren von Abläufen | Systemadministratoren, DevOps |
| Abarbeiten offener Punkte** | Erledigung kleinerer technischer oder organisatorischer Aufgaben ("Open Issues") | Projektteam, Support-Team |
| Unterstützung der Anwender | Zusätzliche Hilfe, Schulung oder Beratung bei Spezialfällen, Erstellen von Quick-Guides | Support-Team, Trainer |
| Wissensübergabe | Einarbeitung des Betriebsteams, gemeinsame Fehleranalysen, Bereitstellung von Dokumentationen | Projektteam, Betriebsteam |
| Bewertung und Feinschliff | Optimierungen: Anpassungen von Reports, kleinere Prozessänderungen, Performance-Verbesserungen | Entwickler, Fachbereich |
| Monitoring & Reporting | Erstellen von Nachbetreuungsberichten, Fehlerstatistiken, Systemnutzungsanalysen | Projektleiter, Support-Team |
| Projektabschluss | Durchführung eines Abschlussmeetings, Kundenzufriedenheitsanalyse, formale Projektabnahme | Projektleiter, Stakeholder |
d) Empfohlene Dauer für SCM-System mit 200 Benutzern:
| Phase | Empfohlene Dauer | Begründung |
|---|---|---|
| Hypercare-Phase | 10-14 Tage (2 Wochen) | Mittleres Projekt (200 Benutzer), kritisches System (SCM), aber nicht so komplex wie ERP oder klinische Systeme |
| Nachbetreuungsphase | 8-12 Wochen (2-3 Monate) | Mittleres Projekt, System muss stabilisiert werden, Optimierungen, Übergabe an Betrieb |
Gesamtnachbetreuungszeit: ca. 10-14 Wochen (2,5-3 Monate)
Detaillierung:
- Hypercare: 2 Wochen intensiver Support (24/7 während Arbeitszeit, evtl. Wochenende bei kritischen Problemen)
- Nachbetreuung: 8-12 Wochen mit wöchentlichem oder 14-tägigem Support-Team, Projektteam reduziert, Betriebsteam übernimmt nach 4-6 Wochen
!!! note "Faktoren für die Dauer: - Projektgröße: 200 Benutzer = mittleres Projekt - System-Kritikalität: SCM ist kritisch, aber weniger kritisch als klinische Systeme oder Finanzsysteme - Komplexität: SCM ist komplex, aber weniger komplex als ERP - Benutzer-Zahl: 200 Benutzer ist mittel, nicht sehr hoch - Geografische Verteilung: Wenn Benutzer an einem Standort oder in wenigen Standorten, kann Hypercare kürzer sein - Erfahrung des Unternehmens:** Wenn das Unternehmen Erfahrung mit ähnlichen Projekten hat, kann die Dauer reduziert werden
Frage 7: Änderungsmanagement und Change Control Board
Ein IT-Projekt für ein Unternehmen hat ein Change Control Board (CCB) eingerichtet. Folgender Change Request wurde eingereicht:
CR-ID: CR-2026-001 Titel: Hinzufügen einer BI-Export-Funktion für Dashboards Beschreibung: Anwender möchten Dashboards als PDF und Excel exportieren können Begründung: Wichtig für Management-Reporting und Kunden-Präsentationen Antragsteller: Leiter Marketing Priorität: P2 (Hoch) Kategorie: Neue Funktion Geschätzter Aufwand: 3 Wochen Entwicklung + 1 Woche Testing Geschätzte Kosten: 15.000 €
a) Sollte der Projektleiter oder das CCB entscheiden? Warum? b) Führen Sie eine Auswirkungsanalyse durch (Scope, Zeit, Kosten, Qualität, Risiken). c) Welche Entscheidung würden Sie empfehlen und warum?
Lösung: a) Entscheidung: Change Control Board (CCB)
Begründung: - Großer Change: Neue Funktion mit 3-4 Wochen Aufwand ist keine kleine Änderung - Hohe Kosten: 15.000 € sind signifikant und müssen im Budget berücksichtigt werden - Zeitliche Auswirkung: 4 Wochen Verzögerung des Projekts oder Parallelentwicklung mit Ressourcenkonflikten - Scope-Erweiterung: Die BI-Export-Funktion war nicht im ursprünglichen Scope enthalten - Kritikalität: BI und Reporting ist für das Unternehmen wichtig, daher hohe strategische Bedeutung - Kriterien für CCB: Alle Kriterien (großer Change, hohe Kosten, zeitliche Auswirkung, strategische Bedeutung) sind erfüllt
b) Auswirkungsanalyse:
| Auswirkungsaspekt | Analyse |
|---|---|
| Scope | Scope-Erweiterung: Die BI-Export-Funktion ist eine neue Funktion, die ursprünglich nicht geplant war. Dies erweitert den Projektumfang. |
| Zeit | Zeitverzug von 4 Wochen: 3 Wochen Entwicklung + 1 Woche Testing. Dies kann zu Verzögerung des Meilensteins "Go-Live" oder Parallelentwicklung mit Ressourcenkonflikten führen. |
| Kosten | Kostenüberschreitung von 15.000 €: Dies entspricht ca. X% des ursprünglichen Budgets (Basis-Information wäre notwendig, z.B. wenn Gesamtbudget 150.000 €, dann +10%). |
| Qualität | Auswirkung auf Qualität: Positiv: Die Export-Funktion erfüllt eine wichtige Anforderung. Negativ: Zusätzliche Entwicklung erhöht das Risiko von Fehlern, Testing muss erweitert werden. |
| Risiken | Neue Risiken: (1) Performance-Risiko bei großen Dashboards, (2) Formatierungsprobleme bei Export, (3) Integration mit BI-Tool, (4) Ressourcenkonflikte mit anderen Aufgaben. |
| Abhängigkeiten | Abhängigkeiten: (1) Integration mit BI-Tool oder Reporting-Framework, (2) Abhängigkeit von Dashboard-Konfiguration, (3) Abhängigkeit von Datensicherheit (Export von sensiblen Daten). |
| Nachforderungen | Nachforderungen: (1) Zeitverlängerung des Projekts, (2) Budgeterhöhung, (3) Ggf. zusätzliche Ressourcen für Testing. |
c) Empfehlung: Genehmigt mit Bedingungen
Empfohlene Entscheidung: Genehmigt mit Bedingungen (Genehmigt mit Änderungen)
Bedingungen: 1. Zeitrahmen: Die Entwicklung sollte in einem definierten Zeitrahmen (z.B. 4-5 Wochen) stattfinden, ohne kritische Meilensteine zu gefährden 2. Budget: Die Kosten von 15.000 € werden akzeptiert, aber müssen im Budget berücksichtigt werden (ggf. Budgeterhöhung oder Einsparungen in anderen Bereichen) 3. Ressourcen: Es müssen ausreichende Ressourcen (Entwickler, Tester) verfügbar sein, ohne andere Aufgaben zu gefährden 4. Testing: Umfassende Testing (Einheitentests, Integrationstests, User Acceptance Tests) ist erforderlich, besonders Performance-Tests 5. Sicherheitsaspekte: Sicherheitsaspekte müssen berücksichtigt werden (Export von sensiblen Daten, Berechtigungsmanagement) 6. Priorisierung: Die BI-Export-Funktion sollte priorisiert werden (z.B. nach kritischen Features, aber vor nice-to-have Features) 7. Dokumentation: Umfassende Dokumentation (Benutzerhandbuch, Admin-Guide) ist erforderlich
Alternative Empfehlung: Falls das Budget knapp ist oder der Zeitplan sehr kritisch ist, könnte eine alternative Entscheidung sein:
| Alternative | Empfehlung | Begründung |
|---|---|---|
| Genehmigt, aber in Phase 2 | Genehmigen, aber erst in Phase 2 (nach Go-Live) | Erfüllt die Anforderung, aber ohne die kritische Phase 1 zu gefährden |
| Zurückgestellt | Zurückstellen bis nach Go-Live | Minimiert Risiko für Phase 1, aber enttäuscht den Antragsteller |
| Teilweise genehmigt | Nur PDF-Export (nicht Excel) | Reduziert Aufwand und Zeit, erfüllt einen Teil der Anforderung |
| Abgelehnt | Abgehnen | Wenn das Budget oder Zeitplan keine Änderungen zulässt |
Frage 8: Risikomanagement und Risikoanalyse
Ein IT-Projekt hat folgende Risiken identifiziert:
| Risk-ID | Risiko | Eintrittswahrscheinlichkeit | Auswirkung |
|---|---|---|---|
| R-001 | Lieferant der Komponente X kann nicht termingerecht liefern | Hoch (4) | Mittel (3) |
| R-002 | Datenbank-Performance bei >100.000 Datensätzen nicht ausreichend | Mittel (3) | Hoch (4) |
| R-003 | Fachbereich X lehnt neue Software ab | Mittel (3) | Kritisch (4) |
| R-004 | Kritischer Mitarbeiter geht während Projektlaufzeit | Gering (2) | Kritisch (4) |
| R-005 | Budget wird nicht genehmigt | Gering (2) | Kritisch (4) |
a) Berechnen Sie die Risikopriorität (RPN) für jedes Risiko. b) Welche Risiken haben die höchste Priorität und sollten prioritär behandelt werden? c) Für jedes der Top-3-Risiken: Nennen Sie eine geeignete Risikobehandlungsstrategie und eine konkrete Maßnahme.
Lösung: a) Risikopriorität (RPN = Wahrscheinlichkeit × Auswirkung):
| Risk-ID | Risiko | Wahrscheinlichkeit | Auswirkung | RPN | Priorität |
|---|---|---|---|---|---|
| R-001 | Lieferant der Komponente X kann nicht termingerecht liefern | 4 (Hoch) | 3 (Mittel) | 12 | Hoch |
| R-002 | Datenbank-Performance bei >100.000 Datensätzen nicht ausreichend | 3 (Mittel) | 4 (Hoch) | 12 | Hoch |
| R-003 | Fachbereich X lehnt neue Software ab | 3 (Mittel) | 4 (Kritisch) | 12 | Hoch |
| R-004 | Kritischer Mitarbeiter geht während Projektlaufzeit | 2 (Gering) | 4 (Kritisch) | 8 | Mittel |
| R-005 | Budget wird nicht genehmigt | 2 (Gering) | 4 (Kritisch) | 8 | Mittel |
b) Top-3-Risiken nach RPN:
| Rang | Risk-ID | Risiko | RPN | Priorität |
|---|---|---|---|---|
| 1 | R-001, R-002, R-003 | Alle drei haben RPN = 12 | 12 | Hoch |
| 2 | R-004, R-005 | Beide haben RPN = 8 | 8 | Mittel |
Höchste Priorität: Alle drei Risiken mit RPN = 12 (R-001, R-002, R-003) sollten prioritär behandelt werden.
c) Risikobehandlungsstrategien und konkrete Maßnahmen für Top-3-Risiken:
| Risk-ID | Risikobehandlungsstrategie | Konkrete Maßnahme |
|---|---|---|
| R-001 (Lieferant kann nicht termingerecht liefern) |
Minderung oder Übertragen | Minderung: Frühzeitige Kommunikation mit Lieferant, Alternativlieferanten identifizieren, Puffer im Zeitplan einplanen, Teil-Lieferungen vereinbaren Übertragen: SLA mit Lieferant, Strafzahlungen bei Verzögerung |
| R-002 (Datenbank-Performance nicht ausreichend) |
Minderung oder Vermeiden | Minderung: Performance-Tests vor Go-Live, Indizes optimieren, Datenbanktuning, Load Balancing, Skalierungsstrategie Vermeiden: Alternative Datenbank-Technologie mit besserer Performance, Archivierungsstrategie für historische Daten |
| R-003 (Fachbereich lehnt neue Software ab) |
Minderung | Minderung: Stakeholder-Management, Early-Bird-Programm, frühzeitige Einbindung des Fachbereichs, Benefits kommunizieren, Training, Schulung, Change-Management, Feedback-Schleifen |
Zusätzliche Strategien für R-001, R-002, R-003:
Kombination von Strategien ist oft optimal:
| Risk-ID | Strategie-Kombination |
|---|---|
| R-001 | Minderung + Übertragen: Frühzeitige Kommunikation + SLA + Strafzahlungen |
| R-002 | Minderung + Vermeiden: Performance-Tests + Optimierung + ggf. Alternative Technologie |
| R-003 | Minderung + Accept: Stakeholder-Management + Training + Kontingenz-Reserve für Widerstand |
Frage 9: Das Magische Dreieck
Ein Projektteam hat einen Change Request für eine neue Funktion erhalten. Die neue Funktion würde die Projektdauer um 3 Wochen verlängern und die Kosten um 25.000 € erhöhen. Die Projektleitung diskutiert verschiedene Optionen.
Option A: Funktion umsetzen (Zeit +3 Wochen, Kosten +25.000 €) Option B: Funktion nicht umsetzen (Zeit unverändert, Kosten unverändert) Option C: Funktion umsetzen, aber eine andere Funktion entfernen (Zeit +1 Woche, Kosten +10.000 €)
a) Erklären Sie das Magische Dreieck und den Zielkonflikt zwischen Zeit, Kosten und Qualität. b) Führen Sie eine Trade-off-Analyse für die drei Optionen durch. c) Welche Option würden Sie empfehlen und unter welchen Bedingungen?
Lösung: a) Das Magische Dreieck (Projektmanagement-Dreieck) beschreibt den Zielkonflikt zwischen den drei zentralen Parametern:
Parameter des Magischen Dreiecks: - Zeit: Termine, Meilensteine, Projektdauer - Kosten/Aufwand: Budget, Ressourcen, Aufwand - Leistung/Qualität: Umfang (Scope), Anforderungen, Qualität der Ergebnisse
Zielkonflikt: - Eine Änderung an einem Parameter hat zwingend Auswirkungen auf mindestens einen anderen Parameter - Kostensenkung führt meist zu Zeitverlängerung oder Qualitätsverlust - Zeitverkürzung führt meist zu Kostensteigerung oder Qualitätsverlust - Qualitätserhöhung führt meist zu Kostensteigerung oder Zeitverlängerung - Umfangserhöhung (neue Funktionen) führt zu Kostensteigerung oder Zeitverlängerung oder Qualitätsverlust
graph TD
A[Zeit<br/>Termine] --- B[Leistung/Qualität<br/>Umfang, Anforderungen]
B --- C[Kosten/Aufwand<br/>Budget, Ressourcen]
C --- A
style A fill:#ffecb3
style B fill:#c8e6c9
style C fill:#ffcdd2b) Trade-off-Analyse:
| Option | Zeit | Kosten | Qualität/Scope | Bewertung |
|---|---|---|---|---|
| Option A (Funktion umsetzen) | +3 Wochen | +25.000 € | + (neue Funktion) | Mittel bis Hoch (neue Funktion, aber höhere Kosten und Zeit) |
| Option B (Funktion nicht umsetzen) | - | - | - (keine neue Funktion) | Gering (keine Verbesserung, aber auch keine Kosten oder Zeit) |
| Option C (Funktion umsetzen, andere entfernen) | +1 Woche | +10.000 € | 0 (Funktion hinzugefügt, andere entfernt) | Mittel bis Hoch (Balance zwischen Kosten, Zeit und Funktionen) |
Analyse der Optionen:
- Option A (Funktion umsetzen):
- Vorteil: Neue Funktion wird implementiert
- Nachteil: Hohe Kosten (+25.000 €), Zeitverzögerung (+3 Wochen)
-
Besser, wenn die neue Funktion sehr wichtig ist und Budget und Zeit kein begrenzender Faktor sind
-
Option B (Funktion nicht umsetzen):
- Vorteil: Keine Kosten- oder Zeitüberschreitung
- Nachteil: Keine neue Funktion, Kundenanforderung nicht erfüllt
-
Besser, wenn Budget und Zeit sehr begrenzt sind oder die neue Funktion nicht kritisch ist
-
Option C (Funktion umsetzen, andere entfernen):
- Vorteil: Neue Funktion wird implementiert, moderate Kosten (+10.000 €), moderate Zeitverzögerung (+1 Woche)
- Nachteil: Andere Funktion wird entfernt (Scope-Reduktion)
- Besser, wenn die neue Funktion wichtiger ist als die entfernte Funktion
c) Empfehlung: Option C unter bestimmten Bedingungen
Empfohlene Option: Option C (Funktion umsetzen, andere entfernen)
Bedingungen für Empfehlung: 1. Die neue Funktion ist wichtiger als die entfernte Funktion (Business-Value-Analyse) 2. Budget und Zeit sind begrenzt (keine Möglichkeit für Option A) 3. Die entfernte Funktion ist nicht kritisch (kein Muss-Haben) 4. Die entfernte Funktion kann in einem zukünftigen Projekt implementiert werden
Alternativ-Empfehlungen:
| Situation | Empfehlung | Begründung |
|---|---|---|
| Neue Funktion ist kritisch (Muss-Haben) | Option A (oder Option C mit anderer Funktion entfernen) | Kritische Funktionen müssen implementiert werden, unabhängig von Kosten und Zeit |
| Budget und Zeit sind sehr begrenzt | Option B (oder Option C mit sehr kleiner Funktion entfernen) | Wenn Budget und Zeit nicht ausreichen, muss auf die neue Funktion verzichtet werden |
| Neue Funktion ist wichtig, aber nicht kritisch | Option C | Balance zwischen Kosten, Zeit und Funktionen: Neue Funktion implementieren, weniger kritische Funktion entfernen |
| Neue Funktion ist Nice-to-have | Option B | Nice-to-have Funktionen können postponed werden |
| Kunde ist bereit, Budget und Zeit zu erhöhen | Option A | Wenn Kunde bereit ist, zusätzliche Kosten und Zeit zu akzeptieren, sollte die neue Funktion implementiert werden |
!!! note "Wichtige Überlegungen: - Business-Value-Analyse: Kunden- und Stakeholder-Erwartungen priorisieren - Muss-Haben vs. Kann-Haben vs. Sollte-Haben: Kategorisierung von Anforderungen - Budget- und Zeit-Rahmen: Berücksichtigung der Restriktionen - Kunden-Kommunikation:** Transparente Kommunikation mit Kunden über Trade-offs
Frage 10: Stakeholder-Management
Ein IT-Projekt hat folgende Stakeholder identifiziert:
| Stakeholder | Rolle | Einfluss | Macht | Einstellung |
|---|---|---|---|---|
| S1 | CEO | Hoch | Hoch | Positiv |
| S2 | CTO | Hoch | Hoch | Neutral |
| S3 | Leiter Marketing | Mittel | Mittel | Negativ |
| S4 | Leiter IT-Operations | Hoch | Mittel | Positiv |
| S5 | Key User (Anwender) | Niedrig | Gering | Neutral |
| S6 | Lieferant (Software-Hersteller) | Mittel | Mittel | Positiv |
a) Erklären Sie die Stakeholder-Matrix (Einfluss/Macht). b) Welche Stakeholder sollten prioritär gemanagt werden? Warum? c) Für den Stakeholder mit negativer Einstellung (S3): Nennen Sie 3 Maßnahmen, um die Einstellung zu verbessern.
Lösung: a) Die Stakeholder-Matrix (auch Power/Interest Matrix oder Einfluss-Macht-Matrix genannt) ordnet Stakeholder basierend auf Einfluss und Macht:
Definitionen: - Einfluss (Interest): Wie stark der Stakeholder das Projekt beeinflussen möchte oder wie stark das Projekt den Stakeholder beeinflusst - Macht (Power): Wie viel Macht der Stakeholder hat, um das Projekt zu beeinflussen (Entscheidungsreichweite)
Stakeholder-Matrix:
graph TD
subgraph "Hoch"
A[Hoch / Hoch<br/>Manage Closely]
B[Hoch / Mittel<br/>Keep Satisfied]
end
subgraph "Niedrig"
C[Niedrig / Hoch<br/>Keep Informed]
D[Niedrig / Niedrig<br/>Monitor]
end
A --- B
C --- D
A --- C
B --- D
style A fill:#f44336
style B fill:#ff9800
style C fill:#4caf50
style D fill:#2196f3Quadranten der Stakeholder-Matrix:
| Quadrant | Macht | Einfluss | Strategie | Stakeholder aus Beispiel |
|---|---|---|---|---|
| Manage Closely (Enges Management) | Hoch | Hoch | Enges Management, kontinuierliche Kommunikation, hohe Aufmerksamkeit | S1 (CEO), S2 (CTO) |
| Keep Satisfied (Zufriedenstellen) | Hoch | Mittel | Zufriedenstellen, regelmäßige Updates, keine Überraschungen | S4 (Leiter IT-Operations) |
| Keep Informed (Informiert halten) | Niedrig | Hoch | Regelmäßig informieren, Feedback einholen, aber nicht zu viele Ressourcen | S3 (Leiter Marketing), S6 (Lieferant) |
| Monitor (Überwachen) | Niedrig | Niedrig | Minimaler Aufwand, gelegentliches Update | S5 (Key User) |
b) Stakeholder, die prioritär gemanagt werden sollten:
Top-Priorität (Manage Closely): - S1 (CEO): Hohe Macht, hoher Einfluss, positive Einstellung. CEO ist entscheidend für Budget-Genehmigung und strategische Unterstützung. - S2 (CTO): Hohe Macht, hoher Einfluss, neutrale Einstellung. CTO ist entscheidend für technische Entscheidungen und Ressourcen-Zuweisung.
Mittlere Priorität (Keep Satisfied): - S4 (Leiter IT-Operations): Hohe Macht, mittlerer Einfluss, positive Einstellung. IT-Operations ist entscheidend für Go-Live und Betrieb.
Niedrige Priorität (Keep Informed): - S3 (Leiter Marketing): Mittlere Macht, mittlerer Einfluss, negative Einstellung. Marketing ist wichtig für Akzeptanz, aber hat nicht so viel Macht wie CEO oder CTO. - S6 (Lieferant): Mittlere Macht, mittlerer Einfluss, positive Einstellung. Lieferant ist wichtig, aber weniger kritisch als interne Stakeholder.
Sehr niedrige Priorität (Monitor): - S5 (Key User): Niedrige Macht, niedriger Einfluss, neutrale Einstellung. Key User sind wichtig für Akzeptanz, aber haben wenig Entscheidungsmacht.
c) Maßnahmen für Stakeholder mit negativer Einstellung (S3 - Leiter Marketing):
Ziel: Einstellung von negativ zu neutral oder positiv ändern.
| Maßnahme | Beschreibung | Verantwortlicher | Zeitrahmen |
|---|---|---|---|
| Maßnahme 1: Stakeholder-Interviews | Persönliche Interviews mit dem Leiter Marketing, um Bedenken und Wünsche zu verstehen | Projektleiter | Sofort |
| Maßnahme 2: Benefits-Kommunikation | Transparente Kommunikation über die Vorteile des Projekts für Marketing (z.B. bessere Daten für Marketing-Kampagnen, Effizienzsteigerung) | Projektleiter, Kommunikation-Team | Sofort |
| Maßnahme 3: Early-Bird-Programm | Marketing als Pilot-Abteilung für neue Funktionen oder Module | Projektleiter, Fachbereich | In 2-4 Wochen |
| Maßnahme 4: Einbindung in Entscheidungen | Aktive Einbindung des Leiters Marketing in Entscheidungen, die Marketing betreffen | Projektleiter, Stakeholder | Laufend |
| Maßnahme 5: Schulung und Training | Umfangreiche Schulung und Training für das Marketing-Team | Trainer, Projektleiter | Vor Go-Live |
| Maßnahme 6: Feedback-Schleifen | Regelmäßige Feedback-Sitzungen mit Marketing, um Bedenken frühzeitig zu adressieren | Projektleiter | Wöchentlich |
| Maßnahme 7: Anpassung von Anforderungen | Berücksichtigung von Marketing-Anforderungen in der Planung, wo möglich | Projektleiter, Fachbereich | Laufend |
| Maßnahme 8: Change-Management | Professionelles Change-Management für das Marketing-Team | Change-Manager | Vor und während Go-Live |
Frage 11: Qualitätsmanagement und Testmanagement
Ein Entwicklungsteam hat eine neue Funktion implementiert und soll sie in die Produktion bringen. Der Projektleiter möchte sicherstellen, dass die Qualität hoch ist.
a) Was ist der Unterschied zwischen konstruktiven und analytischen QM-Maßnahmen? b) Nennen Sie 3 konstruktive und 3 analytische QM-Maßnahmen für diese Situation. c) In welcher Reihenfolge sollten Test-Level (Unit Tests, Integration Tests, System Tests, Acceptance Tests) durchgeführt werden und warum?
Lösung: a) Unterschied zwischen konstruktiven und analytischen QM-Maßnahmen:
| QM-Maßnahme-Typ | Beschreibung | Zeitpunkt | Ziel |
|---|---|---|---|
| Konstruktive QM-Maßnahmen | Maßnahmen, die verhindern, dass Fehler entstehen (präventiv) | Während der Entwicklung oder Planung | Fehler gar nicht erst entstehen lassen |
| Analytische QM-Maßnahmen | Maßnahmen, die erkennen, dass Fehler bereits entstanden sind (reaktiv) | Nach der Entwicklung oder Implementierung | Bereits entstandene Fehler finden und beheben |
b) Konstruktive und analytische QM-Maßnahmen:
Konstruktive QM-Maßnahmen (präventiv):
| Maßnahme | Beschreibung | Verantwortlicher |
|---|---|---|
| Coding Standards | Vereinbarte Coding-Richtlinien einhalten | Entwickler, Tech Lead |
| Code Reviews | Überprüfung von Code durch Kollegen (Peer Reviews) | Entwickler-Team |
| Pair Programming | Zwei Entwickler gemeinsam am Code arbeiten | Entwickler-Team |
| Static Analysis | Automatische Analyse von Code (z.B. SonarQube, ESLint) | DevOps, Entwickler |
| Design Reviews | Überprüfung von Design-Entscheidungen | Architekt, Entwickler-Team |
| Dokumentation | Technische Dokumentation erstellen | Entwickler-Team |
Analytische QM-Maßnahmen (reaktiv):
| Maßnahme | Beschreibung | Verantwortlicher |
|---|---|---|
| Einheitentests (Unit Tests) | Tests einzelner Komponenten, Funktionen, Klassen | Entwickler |
| Integrationstests | Tests der Interaktion zwischen Komponenten | Test-Team, Entwickler |
| Systemtests | Tests des Gesamtsystems (End-to-End Tests) | Test-Team |
| Acceptance Tests (UAT) | Abnahmetests durch Endanwender | Key User, Stakeholder |
| Performance-Tests | Tests von Performance und Skalierbarkeit | Test-Team |
| Security-Tests | Penetrationstests, Security Audits | Security-Team, Test-Team |
c) Reihenfolge der Test-Level und Begründung:
Reihenfolge der Test-Level:
graph LR
A[Unit Tests<br/>Einheitentests] --> B[Integration Tests<br/>Integrationstests]
B --> C[System Tests<br/>Systemtests]
C --> D[Acceptance Tests<br/>Abnahmetests]
style A fill:#e3f2fd
style B fill:#fff9c4
style C fill:#ffecb3
style D fill:#c8e6c9Reihenfolge und Begründung:
| Test-Level | Reihenfolge | Begründung |
|---|---|---|
| 1. Unit Tests (Einheitentests) | Zuerst | Schnellste Tests, isoliertest, finden Fehler in einzelnen Komponenten frühzeitig |
| 2. Integration Tests | Zweitens | Tests der Interaktion zwischen Komponenten, benötigen funktionierende Komponenten (nach Unit Tests) |
| 3. System Tests | Drittens | Tests des Gesamtsystems, benötigen funktionierende Integration (nach Integration Tests) |
| 4. Acceptance Tests (UAT) | Zuletzt | Abnahme durch Anwender, benötigen funktionierendes Gesamtsystem (nach System Tests) |
Begründung der Reihenfolge:
- Effizienz: Unit Tests sind am schnellsten und finden Fehler frühzeitig, was Kosten für spätere Tests und Reparaturen reduziert
- Isolierung: Unit Tests isolieren Fehler in einzelnen Komponenten, was Debugging erleichtert
- Abhängigkeiten: Integration Tests benötigen funktionierende Komponenten (nach Unit Tests), System Tests benötigen funktionierende Integration (nach Integration Tests)
- Kosten: Fehler, die in Unit Tests gefunden werden, kosten deutlich weniger als Fehler, die erst in System Tests oder Acceptance Tests gefunden werden
- Realismus: Jede Test-Stufe erhöht den Realismus und Testumfang, ist aber auch aufwendiger
!!! note "Kosten für Fehler in verschiedenen Test-Stufen: - Unit Tests: Kosten: 1x (sehr gering) - Integration Tests: Kosten: 10x - System Tests: Kosten: 100x - Acceptance Tests: Kosten: 1.000x - Produktion (Post-Deployment):** Kosten: 10.000x (sehr hoch)
Daher: **Früher Testen = Geringere Kosten!**
Frage 12: Projektabschluss und Übergabe
Ein Projekt ist kurz vor dem Abschluss. Die Projektleitung muss die Übergabe an den Betrieb vorbereiten.
a) Was sind die wichtigsten Schritte bei der Übergabe vom Projekt in den Regelbetrieb? b) Welche Dokumentationen sollten übergeben werden? c) Kriterien für einen erfolgreichen Projektabschluss?
Lösung: a) Wichtigste Schritte bei der Übergabe vom Projekt in den Regelbetrieb:
| Schritt | Beschreibung | Verantwortlicher |
|---|---|---|
| 1. Vorbereitung | Planung der Übergabe, Checklisten erstellen, Verantwortliche benennen | Projektleiter, Betriebsteam |
| 2. Wissensübergabe | Training des Betriebsteams, Übergabe von technischem Wissen | Projektteam, Betriebsteam |
| 3. Dokumentationsübergabe | Übergabe aller relevanten Dokumentationen | Projektteam, Betriebsteam |
| 4. Systemübergabe | Technische Übergabe der Systeme, Zugriffsrechte | Systemadministratoren, DevOps |
| 5. Monitoring-Übergabe | Übergabe von Monitoring-Konfiguration und Alerting | DevOps, Betriebsteam |
| 6. Support-Übergabe | Übergabe an Support-Team, SLA finalisieren | Support-Team, Stakeholder |
| 7. Test-Übergabe | Letzte Tests (Integrationstests, Systemtests) | Test-Team |
| 8. Abnahme | Formale Abnahme durch Stakeholder und Betriebsteam | Stakeholder, Betriebsteam |
| 9. Go-Live | Produktivstart | Projektleiter, Betriebsteam |
| 10. Hypercare | Intensive Nachbetreuung | Hypercare-Team |
| 11. Nachbetreuung | Langfristige Stabilisierung | Support-Team, Betriebsteam |
| 12. Projektabschluss | Formaler Abschluss, Lessons Learned, Projektabschluss-Meeting | Projektleiter, Stakeholder |
b) Zu übergebende Dokumentationen:
| Dokumentation | Zweck | Inhalt |
|---|---|---|
| Systemarchitektur | Übersicht über Systemkomponenten und -beziehungen | Architekturdiagramme, Komponentenbeschreibungen, Schnittstellen |
| Betriebsanweisungen | Spezielle Vorgaben für den Betrieb und die Wartung | Start-/Stop-Prozesse, Backups, Recovery, Monitoring |
| Betriebshandbuch | Anleitungen für Betrieb und Wartung | Installation, Konfiguration, Troubleshooting, Wartung |
| Troubleshooting-Guides | Schritt-für-Schritt-Anleitungen zur Fehlerbehebung | Häufige Fehler und ihre Lösungen |
| Benutzerhandbuch | Anleitung für Endanwender | Funktionen, Prozesse, Beispiele |
| FAQ | Häufig gestellte Fragen der Anwender | Fragen und Antworten zu häufigen Problemen |
| Known Issues | Dokumentation bekannter Probleme und Workarounds | Bekannte Fehler und Lösungen |
| Release Notes | Dokumentation von Fixes und Änderungen | Versionshistorie, Änderungen, Fixes |
| SLA-Dokumentation | Service Level Agreements für Wartung und Support | Verfügbarkeit, Reaktionszeit, Lösungszeit |
| Monitoring-Konfiguration | Monitoring- und Alerting-Konfiguration | Metriken, Schwellwerte, Alert-Rules |
| Backup- und Recovery-Dokumentation | Prozesse und Anweisungen für Backup und Recovery | Backup-Frequenz, Recovery-Time, Recovery-Point |
| Lessons Learned | Erfahrungen und Lern-Erfahrungen aus dem Projekt | Was lief gut? Was nicht? Was verbessert werden kann? |
| Projektabschlussbericht | Zusammenfassung des Projekts | Ergebnisse, KPIs, Abweichungen, Empfehlungen |
c) Kriterien für einen erfolgreichen Projektabschluss:
| Kriterium | Überprüfung | Dokumentation |
|---|---|---|
| Projektziele erreicht | Alle Projektziele (oder genehmigte Anpassungen) erreicht | Projektabnahme-Protokoll |
| System stabil | Min. 7-14 Tage ohne kritische Fehler (P0/P1) | Statusberichte, Monitoring-Daten |
| Anwender zufrieden | Kundenzufriedenheits-Analyse > 80% | Zufriedenheits-Report |
| Alle offenen Punkte abgearbeitet | Alle "Open Issues" erledigt | Issue-Liste, Checkliste |
| Support etabliert | Supportteam arbeitet eigenständig | SLA-Metrik-Report |
| Dokumentation vollständig | Alle Dokumentationen erstellt und übergeben | Dokumentations-Checkliste |
| Wissensübergabe abgeschlossen | Betriebsteam eingearbeitet und geschult | Trainings-Protokoll |
| SLA definiert | SLA vertraglich vereinbart | SLA-Dokument |
| Budget akzeptiert | Wartungs- und Support-Budget genehmigt | Budget-Bestätigung |
| Projektformalitäten erfüllt | Alle Projektformalitäten erfüllt (Genehmigungen, Freigaben) | Projektakte |
!!! note "Projektabschluss-Meeting:** Ein formelles Projektabschluss-Meeting mit allen Stakeholdern beendet das Projekt:
**Agenda:**
1. Begrüßung
2. Status-Übersicht
3. Ergebnisse und KPIs
4. Offene Punkte
5. Lessons Learned
6. Kunden-Feedback
7. Übergabe an Betrieb
8. Nächste Schritte
9. Danksagung
10. Formaler Abschluss
Frage 13: Kommunikation und Berichtswesen
Ein Projektleiter muss regelmäßige Projektstatusberichte erstellen. Das Projekt hat folgende Stakeholder: - Lenkungsausschuss (LA) - Projektteam (PT) - Auftraggeber (AG) - Key User (KU)
a) Welche Berichte sollten für welche Stakeholder erstellt werden? b) Welche Inhalte sollte der Projektstatusbericht für den Lenkungsausschuss haben? c) In welcher Frequenz sollten die Berichte erstellt werden?
Lösung: a) Berichte für verschiedene Stakeholder:
| Stakeholder | Berichtstyp | Frequenz | Inhalt |
|---|---|---|---|
| Lenkungsausschuss (LA) | Lenkungsausschuss-Bericht (Management-Summary) | 14-tägig oder monatlich | High-Level Übersicht, KPIs, Risiken, Eskalationen, Entscheidungsbedarf |
| Projektteam (PT) | Team-Statusbericht | Wöchentlich (oder täglich in kritischen Phasen) | Detaillierte Aufgabenliste, Blocker, Ressourcenbedarf |
| Auftraggeber (AG) | Kunden-Statusbericht | Wöchentlich oder 14-tägig | Projektstatus, Fortschritt, Risiken, Zeitplan, Budget |
| Key User (KU) | Anwender-Statusbericht | 14-tägig oder monatlich | Anwender-Relevante Informationen, Schulungstermine, Änderungen |
b) Inhalte des Projektstatusberichts für den Lenkungsausschuss:
Management-Summary (Executive Summary):
| Abschnitt | Inhalte |
|---|---|
| Projektübersicht | Projektname, Version, Zeitraum, Projektmanager |
| Executive Summary | Kurze Zusammenfassung (3-5 Sätze) des Projektstatus |
| Status | Grün (Auf Kurs), Gelb (Warnung), Rot (Kritisch) |
| Projektfortschritt | Gesamtfortschritt (%), Meilenstein-Status |
| KPIs | Zeit (Plan vs Ist), Kosten (Plan vs Ist), Qualität (Fehler, Test-Ergebnisse) |
| Kritische Erfolgsfaktoren | Status der kritischen Erfolgsfaktoren (auf Kurs, Warnung, Gefährdet) |
| Risiken | Top-5 Risiken (P0/P1 Priorität), neue Risiken, geschlossene Risiken |
| Offene Punkte | Offene Decisions, Offene Issues, Blocker |
| Nächste Schritte | Aktivitäten für die kommende Periode, anstehende Entscheidungen |
| Eskalationen | Offene Eskalationen, benötigte Entscheidungen |
| Anlagen | Detaillierte Berichte, Dashboards, Diagramme |
Detaillierte Inhalte:
| Abschnitt | Detaillierte Inhalte |
|---|---|
| Projektfortschritt | Erledigte Arbeitspakete, geplante vs. tatsächliche Meilensteine, Gesamtfortschritt in % |
| Termine | Plan vs Ist für Termine, Verzögerungen, neue Termine, Meilenstein-Status |
| Kosten | Plan vs Ist für Kosten, Budgetverbrauch, Kostenprognose, Abweichungen |
| Qualität | Testergebnisse, Fehlerstatistik, Qualitätstrends, offene Defects |
| Risiken | Risikoregister, Top-Risiken, neue Risiken, Status von Risikomaßnahmen |
| Änderungen | Offene Change Requests, genehmigte Änderungen, abgelehnte Änderungen |
| Ressourcen | Auslastung des Teams, Ressourcenbedarf, Personalprobleme |
| Stakeholder | Stakeholder-Status, Widerstände, Feedback |
| Nächste Schritte | Aufgaben für die kommende Periode, Verantwortliche, Fristen |
| Entscheidungsbedarf | Offene Entscheidungen, benötigte Genehmigungen, Eskalationen |
c) Berichtsfrequenz:
| Berichtstyp | Empfänger | Frequenz | Begründung |
|---|---|---|---|
| Lenkungsausschuss-Bericht | Lenkungsausschuss | 14-tägig oder monatlich | Strategische Ebene, weniger detailliert, weniger häufig |
| Team-Statusbericht | Projektteam | Wöchentlich (oder täglich in kritischen Phasen) | Operative Ebene, detailliert, häufig für schnelle Reaktion |
| Kunden-Statusbericht | Auftraggeber | Wöchentlich oder 14-tägig | Kunden erwartet regelmäßige Updates, aber nicht zu detailliert |
| Anwender-Statusbericht | Key User | 14-tägig oder monatlich | Anwender brauchen weniger frequent Updates, dafür relevant für sie |
| Täglicher Statusbericht | Lenkungsausschuss, Auftraggeber | Täglich (nur in kritischen Phasen) | Nur bei kritischen Situationen (z.B. kurz vor Go-Live, bei Problemen) |
| Meilensteinbericht | Alle Stakeholder | Bei jedem Meilenstein | Wichtige Meilensteine benötigen einen gesonderten Bericht |
!!! note "Faktoren für die Frequenz: - Projektgröße: Größere Projekte benötigen häufigere Berichte - Komplexität: Komplexe Projekte benötigen häufigere Updates - Kritikalität: Kritische Projekte benötigen häufigere Updates - Stakeholder-Anforderungen: Einige Stakeholder erwarten tägliche Updates, andere monatliche - Projektphase: Kritische Phasen (z.B. kurz vor Go-Live) benötigen häufigere Updates - Vertrauen:** Wenn Stakeholder dem Projektleiter vertrauen, können Berichte seltener sein
Frage 14: Projektmanagement-Tools
Ein Projektleiter muss ein Projektmanagement-Tool für ein IT-Projekt auswählen. Das Projekt ist mittelgroß (20-50 Mitarbeiter, Budget 100.000-500.000 €, Dauer 6-12 Monate).
a) Welche Kategorien von Projektmanagement-Tools gibt es? b) Nennen Sie je 2 Beispiele für jede Kategorie mit Vor- und Nachteilen. c) Welches Tool oder welche Tool-Kategorie würden Sie für dieses Szenario empfehlen und warum?
Lösung: a) Kategorien von Projektmanagement-Tools:
| Kategorie | Beschreibung | Beispiele |
|---|---|---|
| Allgemeine PM-Tools | Breites Spektrum an Projektmanagement-Funktionen | Jira, Asana, Monday.com, MS Project |
| Agile PM-Tools | Spezialis auf agile Methoden (Scrum, Kanban) | Trello, Jira Agile, Azure Boards |
| Kollaborations-Tools | Fokus auf Teamkommunikation und Kollaboration | Slack, Microsoft Teams, Notion |
| Gantt-Diagramm-Tools | Spezialis auf Terminplanung und Gantt-Diagramme | MS Project, GanttProject, Smartsheet |
| Enterprise-PM-Systeme | Umfassende Enterprise-Projektmanagement-Lösungen | SAP PM, Oracle Primavera, Microsoft Project Server |
| Open-Source-Tools | Kostenlos und Open Source | Redmine, OpenProject, ProjectLibre |
b) Beispiele mit Vor- und Nachteilen:
Allgemeine PM-Tools:
| Tool | Vorteile | Nachteile |
|---|---|---|
| Jira | Sehr flexibel, viele Integrationsmöglichkeiten, stark bei Software-Entwicklung | Komplex, Einrichtungsaufwand, Lizenzkosten bei großer Benutzerzahl |
| Asana | Benutzerfreundlich, gut für Teams, integrierte Kommunikation | Begrenzte Funktionen für komplexe Projekte, Lizenzkosten |
Agile PM-Tools:
| Tool | Vorteile | Nachteile |
|---|---|---|
| Trello | Sehr einfach, kostenlos für kleine Teams, Kanban-Board intuitiv | Begrenzte Funktionen, nicht für komplexe Projekte geeignet |
| Jira Agile | Umfassend, gut für Scrum/Kanban, starke Integrationen | Komplex, Einrichtungsaufwand, Lizenzkosten |
Kollaborations-Tools:
| Tool | Vorteile | Nachteile |
|---|---|---|
| Slack | Sehr gut für Kommunikation, viele Integrationsmöglichkeiten | Primär Kollaboration, kein vollständiges PM-Tool, Lizenzkosten |
| Microsoft Teams | Integration mit Office 365, umfassende Kollaborationsmöglichkeiten | Primär Kollaboration, PM-Funktionen begrenzt, Lizenzkosten |
Gantt-Diagramm-Tools:
| Tool | Vorteile | Nachteile |
|---|---|---|
| MS Project | Sehr stark bei Terminplanung, Gantt-Diagramm, Ressourcenmanagement | Teuer, komplex, primär für klassisches PM, weniger agil |
| GanttProject | Kostenlos, Open Source, Gantt-Diagramm | Begrenzte Funktionen, veraltetes UI, keine Cloud-Version |
c) Empfehlung für mittelgroßes IT-Projekt:
Empfohlenes Tool: Jira (oder Kombination aus Jira + Slack/Microsoft Teams)
Begründung:
Warum Jira: - IT-Projekt-orientiert: Jira ist sehr stark bei Software-Entwicklungsprojekten - Flexibilität: Sehr flexibel, kann an verschiedene Projektmethoden angepasst werden (Agile, Kanban, klassisch) - Integrationen: Viele Integrationsmöglichkeiten (GitHub, GitLab, CI/CD, Slack, MS Teams, etc.) - Reporting: Umfassende Reporting-Funktionen, Dashboards, Gantt-Diagramme (mit Plugins) - Skalierbarkeit: Skaliert von kleinen bis zu großen Projekten - Agile-Unterstützung: Umfangreiche Unterstützung für Scrum und Kanban - Community: Große Community, viele Plugins, viel Support
Warum Kombination mit Kollaborations-Tool: - Slack oder Microsoft Teams für Team-Kommunikation, schnellere Updates, informelle Kommunikation - Integration: Jira kann mit Slack oder MS Teams integriert werden (Benachrichtigungen, Updates, etc.)
Alternative: - MS Project + MS Teams: Wenn das Unternehmen bereits Microsoft-Tools nutzt (Office 365) - Azure Boards + MS Teams: Wenn das Projekt in Azure DevOps entwickelt wird - Asana + Slack: Wenn das Projekt weniger komplex ist und Asana ausreicht
!!! note "Kriterien für Tool-Auswahl: - Projektgröße: Mittelgroßes Projekt (20-50 Mitarbeiter) benötigt Tool mit mittlerer Komplexität - Budget: Lizenzkosten müssen im Budget sein - Team-Erfahrung: Tool sollte für das Team lernbar sein - Integrationen: Tool sollte mit bestehenden Tools integrierbar sein - PM-Methode: Tool sollte die PM-Methode unterstützen (Agile, klassisch, hybrid) - Skalierbarkeit: Tool sollte für zukünftige Projekte skalieren können - Support:** Verfügbarkeit von Support und Dokumentation
Frage 15: Komplexes Szenario - Gesamtbewertung
Ein mittelständisches Unternehmen führt ein neues ERP-System ein. Das Projekt hat folgende Charakteristika:
- Projektart: Einführungsprojekt (Standardsoftware)
- Projektgröße: Groß (500 Mitarbeiter, 10 Standorte)
- Budget: 1.000.000 €
- Dauer: 18 Monate
- Kritikalität: Sehr hoch (ERP ist kritisch für den Geschäftsbetrieb)
- Stakeholder: Viele Stakeholder (Management, Fachabteilungen, IT, Lieferant)
a) Welches Rollout-Konzept (Kombination aus Strategien) würden Sie empfehlen? b) Wie sollte das Change Control Board (CCB) strukturiert sein? c) Wie lange sollten Hypercare und Nachbetreuung dauern? d) Welche spezifischen Risiken sollten prioritär behandelt werden?
Lösung: a) Empfohlenes Rollout-Konzept:
Empfehlung: Sandbox + Pilotierung + Sukzessiver Rollout (vertikal)
Detailliertes Rollout-Konzept:
| Phase | Strategie | Dauer | Aktivitäten |
|---|---|---|---|
| 1. Sandbox-Phase | Sandbox | 8 Wochen | System in isolierter Testumgebung, Entwicklung, Konfiguration, Testing, Datenmigrationstests |
| 2. Pilot-Phase | Pilotierung | 12 Wochen | Rollout in einem Pilot-Standort (100 Mitarbeiter, 1 Standort), Hypercare (4 Wochen), Erfahrungen sammeln |
| 3. Erfahrungen sammeln & Anpassung | - | 4 Wochen | Learnings dokumentieren, Verbesserungen implementieren, Planung für Haupt-Rollout anpassen |
| 4. Sukzessiver Rollout - Phase 1 | Vertikaler Rollout (Standort 2) | 4 Wochen | Rollout in Standort 2 (50 Mitarbeiter), Hypercare (2 Wochen) |
| 5. Sukzessiver Rollout - Phase 2 | Vertikaler Rollout (Standort 3) | 4 Wochen | Rollout in Standort 3 (50 Mitarbeiter), Hypercare (2 Wochen) |
| 6. Sukzessiver Rollout - Phase 3 | Vertikaler Rollout (Standorte 4-5) | 6 Wochen | Rollout in Standorte 4-5 (100 Mitarbeiter), Hypercare (3 Wochen) |
| 7. Sukzessiver Rollout - Phase 4 | Vertikaler Rollout (Standorte 6-7) | 6 Wochen | Rollout in Standorte 6-7 (100 Mitarbeiter), Hypercare (3 Wochen) |
| 8. Sukzessiver Rollout - Phase 5 | Vertikaler Rollout (Standorte 8-10) | 8 Wochen | Rollout in verbleibenden Standorten 8-10 (100 Mitarbeiter), Hypercare (4 Wochen) |
| 9. Gesamtsystem-Hypercare | - | 6 Wochen | Intensive Nachbetreuung aller Standorte, Stabilisierung, Optimierung |
| 10. Nachbetreuung | - | 16-24 Wochen (4-6 Monate) | Langfristige Stabilisierung, Optimierung, Übergabe an Betrieb |
Gesamtdauer: ca. 74-78 Wochen (18-19 Monate) (inkl. Sandbox, Pilot, sukzessiver Rollout, Hypercare, Nachbetreuung)
Begründung: - Sandbox: Testen der technischen Machbarkeit und Konfiguration vor Pilot - Pilotierung: Lernerfahrung und Risikominimierung in einem kontrollierten Umfeld - Sukzessiver Rollout: Ressourcen-schonend, Schrittweise Einführung, minimiert Risiko für Gesamtunternehmen - Vertikaler Rollout (Standort-basiert): Standort-basierte Einführung ermöglicht geographische Konzentration von Support und Ressourcen
b) Struktur des Change Control Boards (CCB):
Empfohlene CCB-Struktur:
| Rolle | Verantwortung | Typische Mitglieder |
|---|---|---|
| Vorsitzender | Leitung des CCB, Entscheidung bei Stimmengleichheit | CPO (Chief Project Officer) oder CEO |
| Auftraggeber | Kunden- oder Stakeholder-Vertretung | CFO (Finanzvorstand) oder COO (Betriebsvorstand) |
| Projektleiter | Projektspezifische Expertise, Bericht an CCB | Projektleiter ERP-Einführung |
| Fachbereichsvertreter | Fachliche Bewertung | Vertreter aus: Einkauf, Vertrieb, Produktion, HR, Finanz |
| IT-Vertreter | IT-technische Bewertung | CTO oder Leiter IT-Infrastruktur |
| Qualitätsmanager | Qualitätssicherung und -bewertung | QM-Verantwortlicher |
| Finanzvertreter | Bewertung der Kosten und Budget | CFO-Mitarbeiter oder Controller |
| Lieferanten-Vertreter | Bewertung aus Sicht des Software-Lieferanten | Vertreter des ERP-Lieferanten |
CCB-Meeting-Frequenz: - Wöchentlich in kritischen Phasen (Pilot, erste Rollout-Phasen) - 14-tägig in Routine-Phasen - Ad-hoc bei kritischen Change Requests
Entscheidungsprozess: - Einstimmig (strengste Regel) oder Mehrheit (Standardregel) mit Veto-Recht des Auftraggebers und CTO
c) Dauer von Hypercare und Nachbetreuung:
Empfohlene Dauer für ERP-Projekt mit 500 Mitarbeitern:
| Phase | Empfohlene Dauer | Begründung |
|---|---|---|
| Pilot-Hypercare | 4 Wochen | Kritisch, erste produktive Nutzung, intensive Nachbetreuung |
| Rollout-Hypercare (je Phase) | 2-4 Wochen | Standort-basierter Rollout, jede Phase braucht Hypercare |
| Gesamtsystem-Hypercare | 6 Wochen | Alle Standorte im Produktivbetrieb, Stabilisierung |
| Nachbetreuung | 16-24 Wochen (4-6 Monate) | Langfristige Stabilisierung, Optimierung, Übergabe an Betrieb |
Gesamtnachbetreuungszeit: ca. 28-34 Wochen (7-8,5 Monate)
Detaillierung:
- Hypercare: Sehr intensiv, 24/7 während Arbeitszeit, tägliches Meeting, schnelle Reaktion
- Nachbetreuung: Mittlere Intensität, wöchentliches oder 14-tägiges Meeting, proaktive Optimierung
d) Spezifische Risiken, die prioritär behandelt werden sollten:
| Risk-ID | Risiko | Wahrscheinlichkeit | Auswirkung | RPN | Maßnahmen |
|---|---|---|---|---|---|
| R-001 | Datenverlust bei Datenmigration | Mittel (3) | Katastrophal (5) | 15 | Extensive Tests, Hash-Verfahren, Rollback-Plan, Backup vor Migration |
| R-002 | Ablehnung durch Fachabteilungen (Scope Creep oder Widerstand) | Hoch (4) | Kritisch (4) | 16 | Stakeholder-Management, Early-Bird-Programm, Benefits-Kommunikation, Change-Management |
| R-003 | Performance-Probleme bei hohem Datenvolumen (500 Benutzer, große Datenbank) | Mittel (3) | Kritisch (4) | 12 | Performance-Tests, Datenbankoptimierung, Skalierungsstrategie, Load Balancing |
| R-004 | Integration mit bestehenden Systemen (Schnittstellen zu Lieferanten, Banken, etc.) | Hoch (4) | Hoch (4) | 16 | Schnittstellen-Tests, API-Spezifikationen, Puffer, Alternativlösungen |
| R-005 | Budgetüberschreitung durch Scope Creep oder unvorhergesehene Kosten | Hoch (4) | Mittel (3) | 12 | Change-Management, Budget-Puffer (10-20%), regelmäßiges Budget-Monitoring, frühzeitige Eskalation |
| R-006 | Zeitverzögerung durch Komplexität oder Ressourcenengpässe | Mittel (3) | Kritisch (4) | 12 | Puffer im Zeitplan (10-20%), regelmäßiges Monitoring, Ressourcen-Backup, Priorisierung |
| R-007 | Lieferant (ERP-Software) kann nicht termingerecht oder qualitativ liefern | Mittel (3) | Kritisch (4) | 12 | SLA mit Lieferant, frühzeitige Kommunikation, Alternativlieferanten, Puffer |
| R-008 | Critical Mitarbeiter gehen (Projektleiter, Entwickler, Fachexperten) | Gering (2) | Kritisch (4) | 8 | Wissensmanagement, Schulung von Backups, Mitarbeiter-Bindung, Backup-Ressourcen |
Top-3-Risiken nach RPN (sollten prioritär behandelt werden): 1. R-002: Ablehnung durch Fachabteilungen (RPN = 16) 2. R-004: Integration mit bestehenden Systemen (RPN = 16) 3. R-001: Datenverlust bei Datenmigration (RPN = 15)
Besondere Beachtung: - Datenverlust (R-001): Höchste Auswirkung (katastrophal), muss absolut minimiert werden - Integration (R-004): Sehr wichtig für ERP, viele Schnittstellen sind kritisch - Ablehnung (R-002): Widerstand kann zum Projektabbruch führen, intensives Stakeholder-Management erforderlich
Quiz-Auswertung
Herzlichen Glückwunsch!
Sie haben das Quiz zum Modul "Projektsteuerung in IT-Projekten" erfolgreich bearbeitet.
Nächste Schritte: 1. Überprüfen Sie Ihre Antworten und vergleichen Sie sie mit den Lösungen 2. Identifizieren Sie Wissenslücken und markieren Sie Kapitel zur Nacharbeit 3. Wiederholen Sie die Kapitel, bei denen Sie Schwierigkeiten hatten 4. Bereiten Sie sich auf die Prüfung vor
Modul-Übersicht: Zurück zur Modul-Übersicht