6. Änderungsmanagement
Lernziele
Nach diesem Kapitel können Sie: - Den Zweck und die Notwendigkeit von Änderungsmanagement in IT-Projekten erklären - Den Change-Management-Prozess systematisch durchführen - Ein Change Control Board (CCB) effizient organisieren - Change Requests professionell analysieren, bewerten und entscheiden - Scope Creep erkennen und verhindern - Die Auswirkungen von Änderungen auf das Magische Dreieck (Zeit, Kosten, Qualität) beurteilen
Modul Übersicht
Modul 11 - Kapitel 6
Lesezeit: ~15-20 Min
Quelle: 11 - Projektsteuerung in IT-Projekten.pdf, FS-ITB-11_Steuerung-01_v0c.pdf
1. Einführung: Warum Änderungsmanagement entscheidend ist
1.1 Die Realität von IT-Projekten
Kein IT-Projekt verläuft exakt nach Plan. Änderungen sind unvermeidlich. Die Herausforderung ist nicht, Änderungen zu verhindern, sondern sie professionell zu steuern.
Projektsteuerung unter Einflüssen
"Kein Projekt verläuft wie geplant, deshalb muss korrigierend eingegriffen werden."
1.2 Warum Änderungsmanagement notwendig ist
| Aspekt | Erklärung | Konsequenz ohne Änderungsmanagement |
|---|---|---|
| Ungewissheit | Anforderungen sind nicht immer vollständig oder korrekt bei Projektstart | Missverständnisse, Fehlentwicklungen, teure Nacharbeiten |
| Ändernde Anforderungen | Kunden und Stakeholder ändern Anforderungen im Projektverlauf | Scope Creep, Budgetüberschreitungen, Zeitverzögerungen |
| Technische Erkenntnisse | Neue technische Erkenntnisse führen zu Änderungen | Falsche Architektur, ineffiziente Lösungen |
| Marktveränderungen | Marktbedingungen ändern sich während der Projektlaufzeit | Veraltete Lösungen bei Projektabschluss |
| Regulatorische Änderungen | Gesetze und Vorschriften ändern sich | Compliance-Verletzungen, Projektabbruch |
1.3 Definition: Änderungsmanagement
Sollten Änderungen vom Auftraggeber gewünscht oder als Reaktion auf Planabweichungen notwendig sein, so ist vor der Durchführung sicherzustellen, dass die Auswirkungen dieser Änderungen analysiert und bewertet werden, eine klare Entscheidung über das weitere Vorgehen getroffen wird und (erst dann) mit der konsequenten Umsetzung begonnen wird.
Kernprinzip
"Keine Änderung ohne Analyse, Bewertung und formale Freigabe."
2. Der Change-Management-Prozess
2.1 Übersicht des Prozesses
Der Änderungsmanagement-Prozess folgt einem strukturierten Ablauf:
flowchart TD
A[Änderungsbedarf erkannt] --> B[Change Request erstellen]
B --> C[Erste Analyse & Kategorisierung]
C --> D{Klein & Routine?}
D -->|Ja| E[Projektleiter entscheidet<br/>im Rahmen seiner Kompetenzen]
D -->|Nein| F[Change Control Board<br/>bewertet und entscheidet]
E --> G{Entscheidung}
F --> G
G -->|Genehmigt| H[Auswirkungen auf Zeit, Kosten, Qualität analysieren]
G -->|Abgelehnt| I[Antragsteller informieren<br/>Gründe kommunizieren]
H --> J[Projektplan anpassen]
J --> K[Änderung umsetzen]
K --> L[Dokumentation & Freigabe]
L --> M[Mögliche Nachforderungen sichern]
style G fill:#fff9c4
style I fill:#ffcdd2
style M fill:#c8e6c92.2 Detailanalyse des Prozesses
Phase 1: Änderungsbedarf erkennen
Der Änderungsbedarf kann aus verschiedenen Quellen kommen:
| Quelle | Beispiele |
|---|---|
| Auftraggeber / Kunde | Neue Anforderungen, Änderungswünsche |
| Projektteam | Technische Erkenntnisse, Verbesserungsvorschläge |
| Stakeholder | Feedback von Fachbereichen, Key Usern |
| Projektüberwachung | Abweichungen im Soll-Ist-Vergleich |
| Planabweichungen | Verzögerungen, Budgetüberschreitungen |
| Externe Faktoren | Marktveränderungen, regulatorische Änderungen |
Phase 2: Change Request erstellen
Ein Change Request (CR) ist ein formeller Antrag auf Änderung:
| CR-Attribute | Beispiel |
|---|---|
| CR-ID | CR-2026-001 |
| Titel | Hinzufügen einer Export-Funktion für Berichte |
| Beschreibung | Anwender möchten Berichte exportieren können (PDF, Excel) |
| Begründung | Wichtig für Kundenservice und Compliance-Audits |
| Antragsteller | Leiter Kundenservice |
| Priorität | P2 (Hoch) |
| Kategorie | Neue Funktion |
| Status | Neu |
| Eingangsdatum | 15.01.2026 |
Tipps für gute Change Requests
- Klar und präzise: Beschreiben Sie die Änderung eindeutig und konkret
- Begründet: Erklären Sie, warum die Änderung notwendig ist
- Priorisiert: Weisen Sie eine Priorität zu (P0-P3)
- Kategorisiert: Geben Sie die Art der Änderung an (Neue Funktion, Fehlerbehebung, Anpassung)
- Visualisiert: Nutzen Sie Skizzen, Wireframes oder Beispiele zur Verdeutlichung
Phase 3: Erste Analyse & Kategorisierung
Eine erste Analyse und Kategorisierung entscheidet über den weiteren Prozess:
| Kriterium | Entscheidung |
|---|---|
| Auswirkung auf Projektumfang (Scope) | Große Erweiterung vs. kleine Anpassung |
| Auswirkung auf Zeitplan | Zeitverzug vs. kein Einfluss |
| Auswirkung auf Budget | Kostenüberschreitung vs. im Rahmen |
| Komplexität | Technisch einfach vs. komplex |
| Risiko | Gering vs. hoch |
| Routine-Charakter | Wiederkehrende, ähnliche Änderung vs. einmalig |
| Kategorisierung | Weiteres Vorgehen |
|---|---|
| Routine, klein, geringes Risiko | Projektleiter entscheidet im Rahmen seiner Kompetenzen |
| Kritisch, groß, hohes Risiko | Change Control Board entscheidet |
Phase 4: Entscheidung
Die Entscheidung kann sein:
| Entscheidung | Erklärung | Konsequenzen |
|---|---|---|
| Genehmigt | Änderung wird umgesetzt | Projektplan angepasst, Budget/Termin angepasst, Umsetzung |
| Genehmigt mit Änderungen | Änderung wird umgesetzt, aber mit Modifikationen | Anforderungen angepasst, dann Projektplan angepasst |
| Abgelehnt | Änderung wird nicht umgesetzt | Antragsteller informiert, Gründe kommuniziert |
| Zurückgestellt | Änderung wird zu einem späteren Zeitpunkt erneut geprüft | CR gespeichert, zu späterem Zeitpunkt erneut evaluiert |
Entscheidung transparent kommunizieren
Jede Entscheidung (Genehmigt, Abgelehnt, Zurückgestellt) muss transparent kommuniziert werden. Insbesondere bei Ablehnung ist eine klare Begründung wichtig, um Frustration zu vermeiden.
Phase 5: Auswirkungsanalyse
Bei Genehmigung muss eine detaillierte Auswirkungsanalyse durchgeführt werden:
| Auswirkungsaspekt | Fragen | Beispiele |
|---|---|---|
| Scope | Wie verändert sich der Projektumfang? | Neue Funktion hinzugefügt, Bestehende Funktion angepasst |
| Zeit | Wie verändert sich der Zeitplan? | Verzögerung um 2 Wochen, Meilenstein verschoben |
| Kosten | Wie verändern sich die Kosten? | Zusätzliche 10.000 € Aufwand, Lizenzkosten erhöht |
| Qualität | Wie verändert sich die Qualität? | Höhere Qualität durch zusätzliche Tests, aber auch Risiko von Fehlern |
| Ressourcen | Welche Ressourcen werden benötigt? | Zusätzlicher Entwickler, zusätzlicher Testzeitraum |
| Risiken | Welche neuen Risiken entstehen? | Technische Komplexität erhöht, Integrationsprobleme möglich |
| Abhängigkeiten | Welche Abhängigkeiten gibt es? | Integration mit Modul X notwendig, Schnittstelle zu System Y |
| Nachforderungen | Gibt es Nachforderungen gegenüber dem Auftraggeber? | Zusätzliche Kosten, Verlängerung der Projektdauer |
Phase 6: Projektplan anpassen
Der Projektplan wird entsprechend der Änderung angepasst:
| Plan-Element | Anpassung | Beispiel |
|---|---|---|
| Projektstrukturplan (PSP) | Neue Arbeitspakete hinzufügen | AP: "Entwicklung Export-Funktion" |
| Terminplan | Termine anpassen, Meilensteine verschieben | Meilenstein "Testing Export-Funktion" auf 15.03. |
| Kostenplan | Budget anpassen | Gesamtbudget erhöht um 10.000 € |
| Ressourcenplan | Ressourcen zuweisen | Entwickler A für 2 Wochen zugewiesen |
| Risikoregister | Neue Risiken hinzufügen | Risiko: "Export-Funktion performance-intensiv" |
| Qualitätsplan | QM-Maßnahmen anpassen | Zusätzliche Tests für Export-Funktion |
Phase 7: Änderung umsetzen
Die Änderung wird entsprechend den angepassten Plänen umgesetzt:
| Umsetzungsschritt | Beschreibung |
|---|---|
| Arbeitspakete erstellen | Detaillierte Aufteilung in Arbeitspakete |
| Ressourcen zuweisen | Zuweisung von Verantwortlichen |
| Umsetzung durchführen | Entwicklung, Konfiguration, Anpassung |
| Testing durchführen | Tests der Änderung |
| Dokumentation erstellen | Dokumentation der Änderung |
| Freigabe | Freigabe der Änderung durch CCB oder Projektleiter |
Phase 8: Dokumentation & Freigabe
Die Änderung wird dokumentiert und freigegeben:
| Dokumentation | Inhalte |
|---|---|
| Change Request | Originalantrag, Entscheidung, Begründung |
| Auswirkungsanalyse | Auswirkungen auf Scope, Zeit, Kosten, Qualität, Ressourcen |
| Implementierungsplan | Detaillierter Plan der Umsetzung |
| Test-Ergebnisse | Ergebnisse der Tests |
| Release Notes | Dokumentation der Änderung für Benutzer |
| Aktualisierter Projektplan | Angepasster Projektplan |
3. Change Control Board (CCB)
3.1 Definition und Zweck
Das Change Control Board (CCB) ist ein besonderes Gremium zur Überwachung und Steuerung von Änderungswünschen. Es entscheidet über kritische, große Änderungen mit hohem Risiko.
Charakteristik
"Change Control Board - Das Gericht über Änderungen."
3.2 Wann ist ein CCB notwendig?
| Bedingung | Beispiel |
|---|---|
| Große Änderungen | Neue Funktionen, die erheblichen Aufwand erfordern |
| Hohe Kosten | Änderungen, die das Budget signifikant erhöhen |
| Zeitliche Auswirkungen | Änderungen, die den Zeitplan erheblich verschieben |
| Hohes Risiko | Änderungen mit signifikanten Risiken |
| Interdepartementale Auswirkungen | Änderungen, die mehrere Abteilungen betreffen |
| Strategische Bedeutung | Änderungen mit strategischer Bedeutung |
| Vertragliche Auswirkungen | Änderungen, die vertragliche Vereinbarungen beeinflussen |
3.3 Zusammensetzung des CCB
| Rolle | Verantwortung | Typische Mitglieder |
|---|---|---|
| Vorsitzender | Leitung des CCB, Entscheidung bei Stimmengleichheit | Projektleiter oder Senior Manager |
| Auftraggeber | Kunden- oder Stakeholder-Vertretung | Kunde, Lenkungsausschuss |
| Projektleiter | Projektspezifische Expertise | Projektleiter |
| Fachbereichsvertreter | Fachliche Bewertung | Key User, Fachexperten |
| Technische Experten | Technische Bewertung | Architekten, Senior Entwickler |
| Qualitätsmanager | Qualitätsbewertung | QM-Verantwortlicher |
| Finanzvertreter | Bewertung der Kosten | Finanzabteilung |
Größe des CCB
Ein CCB sollte nicht zu groß sein (ideal 5-7 Mitglieder), um Entscheidungseffizienz zu gewährleisten. Zu viele Mitglieder führen zu langen Diskussionen und verzögerten Entscheidungen.
3.4 CCB-Meetings
| CCB-Meeting | Frequenz | Dauer | Agenda |
|---|---|---|---|
| Regelmäßiges CCB-Meeting | Wöchentlich oder 14-tägig | 60-90 Minuten | Review offener CRs, Entscheidungen, Status-Update |
| Ad-hoc CCB-Meeting | Bei kritischen CRs | 30-60 Minuten | Schnelle Entscheidung zu kritischen Änderungen |
| CCB-Review | Monatlich | 60 Minuten | Review vergangener Entscheidungen, Prozess-Verbesserung |
3.5 Entscheidungsprozess im CCB
flowchart TD
A[CR vorgelegt] --> B[CCB-Meeting]
B --> C[CR präsentiert]
C --> D[Diskussion und Fragen]
D --> E{Entscheidung}
E -->|Einstimmig| F[Genehmigt]
E -->|Mehrheit| F
E -->|Keine Einstimmung oder keine Mehrheit| G{Entscheidung des Vorsitzenden}
G -->|Ja| F
G -->|Nein| H[Abgelehnt]
F --> I[Protokoll und Kommunikation]
H --> I| Entscheidungsregel | Erklärung |
|---|---|
| Einstimmig | Alle Mitglieder stimmen zu (strengste Regel) |
| Mehrheit | Mehrheit der Mitglieder stimmt zu (Standardregel) |
| Qualifizierte Mehrheit | z.B. 2/3-Mehrheit (bei besonders kritischen Entscheidungen) |
| Veto-Recht | Bestimmte Mitglieder (z.B. Auftraggeber) haben Veto-Recht |
| Entscheidung des Vorsitzenden | Bei Stimmengleichheit entscheidet der Vorsitzende |
4. Scope Creep: Die unterschätzte Gefahr
4.1 Was ist Scope Creep?
Scope Creep (Umfangsschwemme) ist das unkontrollierte Anwachsen des Projektumfangs durch kleine, schleichende Änderungen.
Gefahr des Scope Creep
"Scope Creep ist der Hauptgrund für Budgetüberschreitungen und Zeitverzögerungen in IT-Projekten."
4.2 Typen von Scope Creep
| Typ | Erklärung | Beispiel |
|---|---|---|
| Kunden-getriebener Scope Creep | Kunden fügen ständig neue Anforderungen hinzu | "Können wir noch diese kleine Funktion hinzufügen?" |
| Projektteam-getriebener Scope Creep | Projektteam fügt "Nice-to-have"-Funktionen hinzu | "Das wäre noch eine schöne Ergänzung..." |
| Technologie-getriebener Scope Creep | Neue Technologien führen zu ungewollten Erweiterungen | "Diese neue Bibliothek macht das auch noch..." |
| Gold-Plating | Füge "goldene" Features hinzu, die nicht gefordert wurden | Überperfektionierung, unnötige Zusatzfeatures |
4.3 Vermeidung von Scope Creep
| Strategie | Maßnahmen |
|---|---|
| Klare Scope-Definition | Detaillierte und klare Definition des Projektumfangs zu Projektstart |
| Change-Management-Prozess | Strukturierter Prozess für alle Änderungen |
| Kommunikation | Transparente Kommunikation über Auswirkungen von Änderungen |
| Kunden-Schulung | Aufklärung über Auswirkungen von Änderungen auf Zeit, Kosten, Qualität |
| Trade-off-Analyse | Gegenüberstellung von Kosten und Nutzen |
| Kategorisierung von Anforderungen | Muss-Haben vs. Kann-Haben vs. Sollte-Haben |
| Priorisierung | Priorisierung von Anforderungen nach geschäftlichem Nutzen |
| Budget- und Zeitpuffer | Puffer für unerwartete Änderungen |
| Regelmäßige Reviews | Regelmäßige Überprüfung des Scope im Projektverlauf |
4.4 Umgang mit Scope Creep
| Situation | Reaktion |
|---|---|
| Kleine Änderung, geringe Auswirkung | Genehmigen, aber dokumentieren und aufsummieren |
| Mittlere Änderung, moderate Auswirkung | Auswirkungsanalyse, Trade-off-Analyse, Entscheidung |
| Große Änderung, hohe Auswirkung | CCB entscheidet, möglicherweise neues Projekt |
| Häufige kleine Änderungen | Kumulative Auswirkungen analysieren, ggf. Stopppunkt definieren |
| Scope Creep bereits passiert | Umfang realistisch neu definieren, Budget und Zeitplan anpassen, Stakeholder informieren |
5. Auswirkungen von Änderungen auf das Magische Dreieck
5.1 Das Magische Dreieck
Das Magische Dreieck (Projektmanagement-Dreieck) beschreibt den Zielkonflikt zwischen:
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:#ffcdd25.2 Auswirkungsanalyse nach dem Magischen Dreieck
| Änderungstyp | Auswirkung auf Zeit | Auswirkung auf Kosten | Auswirkung auf Qualität | Mögliche Kompromisse |
|---|---|---|---|---|
| Zusätzliche Funktion | + Zeit | + Kosten | ? (höhe Qualität durch Testing, aber auch Risiko) | Zeit verlängern, Budget erhöhen, andere Funktion entfernen |
| Fehlerbehebung | + Zeit (für Fix und Testing) | + Kosten (für Fix) | + Qualität (Fehler behoben) | Zeit verlängern, Budget erhöhen |
| Performance-Verbesserung | + Zeit (für Optimierung) | + Kosten (für Optimierung) | + Qualität | Zeit verlängern, Budget erhöhen, Scope reduzieren |
| Anpassung an Gesetze | + Zeit (für Umsetzung) | + Kosten (für Umsetzung) | + Qualität (Compliance) | Zeit verlängern, Budget erhöhen (Muss-Haben) |
| Technologiewechsel | +++ Zeit | +++ Kosten | ? (neue Technologie kann Qualität verbessern oder gefährden) | Zeit stark verlängern, Budget stark erhöhen, ggf. Projekt neu planen |
5.3 Trade-off-Analyse
Eine Trade-off-Analyse hilft bei der Entscheidung:
| Option | Zeit | Kosten | Qualität | Bewertung |
|---|---|---|---|---|
| Änderung durchführen | +2 Wochen | +10.000 € | Gleich | Mittel |
| Änderung nicht durchführen | - | - | Gleich | Gering |
| Änderung durchführen, aber Scope reduzieren | +1 Woche | +5.000 € | - (weniger Funktionen) | Hoch |
| Änderung auf späteres Projekt verschieben | - | - | - | Hoch (zukünftiges Projekt) |
Trade-off-Prinzip
"Trade-off-Analyse" bedeutet, die Alternativen gegeneinander abzuwägen. Die beste Entscheidung ist nicht immer die mit den geringsten Kosten oder der kürzesten Zeit, sondern die mit dem besten Gesamtwert für das Unternehmen.
6. Best Practices für Änderungsmanagement
6.1 Prävention
| Präventionsmaßnahme | Beschreibung |
|---|---|
| Gute Anforderungsanalyse | Gründliche Analyse zu Projektstart reduziert Änderungsbedarf |
| Stakeholder-Management | Frühe und kontinuierliche Einbindung aller Stakeholder |
| Klare Scope-Definition | Detaillierte und klare Definition des Projektumfangs |
| Kommunikation | Transparente Kommunikation über Projektstatus und Änderungen |
| Agile Methoden | Iteratives Vorgehen ermöglicht schrittweise Anpassungen |
| Prototyping | Frühzeitige visuelle Darstellung reduziert Missverständnisse |
| MVP (Minimum Viable Product) | Fokus auf Kernfunktionen, weniger Änderungsdruck |
6.2 Prozesseffizienz
| Prozess-Verbesserung | Beschreibung |
|---|---|
| Standardisierte CR-Vorlagen | Reduziert Zeit für Erstellung von Change Requests |
| Automatisierte Workflows | Tool-gestützte Änderungsanträge und Workflows |
| Regelmäßige CCB-Meetings | Reduziert Ad-hoc-Meetings, verbessert Planbarkeit |
| Klare Entscheidungswege | Klar definierte Zuständigkeiten und Eskalationspfade |
| Dokumentation | Ausreichende Dokumentation für Transparenz und Nachvollziehbarkeit |
| Metriken | Tracking von CRs, Entscheidungszeit, Abgablerate zur Prozessverbesserung |
| Lessons Learned | Regelmäßige Analyse des Änderungsmanagement-Prozesses |
6.3 Kommunikation
| Kommunikations-Aspekt | Maßnahmen |
|---|---|
| Transparenz | Offene Kommunikation über Änderungen und deren Auswirkungen |
| Begründung | Klare Begründung für Entscheidungen (Genehmigt, Abgelehnt) |
| Kunden-Einbindung | Aktive Einbindung des Kunden in den Änderungsprozess |
| Erwartungsmanagement | Realistische Erwartungen an Kunden und Stakeholder |
| Timely Updates | Schnelle Updates zu Entscheidungen und Statusänderungen |
| Multi-Channel | Nutzung verschiedener Kommunikationskanäle (E-Mail, Meetings, Dashboards) |
| Feedback-Kultur | Offene Feedback-Kultur für Verbesserung des Prozesses |
7. Zusammenfassung
7.1 Kernpunkte des Kapitels
- Änderungsmanagement ist unverzichtbar - Kein Projekt ohne Änderungen
- Strukturierter Prozess - Change Request, Analyse, Entscheidung, Umsetzung
- CCB für kritische Änderungen - Change Control Board für große, kritische Änderungen
- Scope Creep verhindern - Unkontrolliertes Anwachsen des Umfangs vermeiden
- Auswirkungen auf das Magische Dreieck - Jede Änderung hat Auswirkungen auf Zeit, Kosten, Qualität
- Trade-off-Analyse - Alternativen gegeneinander abwägen
- Kommunikation und Transparenz - Klare Kommunikation über Änderungen und Entscheidungen
7.2 Erfolgsfaktoren
| Erfolgsfaktor | Maßnahmen |
|---|---|
| Gute Anforderungsanalyse | Reduziert Änderungsbedarf von vornherein |
| Stakeholder-Management | Frühe und kontinuierliche Einbindung |
| Klare Scope-Definition | Detaillierte Definition des Projektumfangs |
| Strukturierter Prozess | Klare Prozesse und Zuständigkeiten |
| CCB-Kompetenz | Erfahrene und kompetente CCB-Mitglieder |
| Metriken & Monitoring | Tracking von CRs und Entscheidungszeiten |
| Kommunikation | Transparente und klare Kommunikation |
| Tool-Unterstützung | Nutzung von Projektmanagement-Tools |
| Flexibilität - Flexibel, aber strukturiert | |
| Erwartungsmanagement | Realistische Erwartungen an alle Beteiligten |
8. Schlüsselbegriffe
| Begriff | Definition |
|---|---|
| Änderungsmanagement (Change Management) | Systematischer Prozess zur Behandlung von Änderungen im Projektverlauf |
| Change Request (CR) | Formeller Antrag auf Änderung |
| Change Control Board (CCB) | Gremium zur Überwachung und Steuerung von Änderungswünschen |
| Scope Creep | Unkontrolliertes Anwachsen des Projektumfangs |
| Auswirkungsanalyse | Analyse der Auswirkungen einer Änderung auf Zeit, Kosten, Qualität |
| Magisches Dreieck | Zielkonflikt zwischen Leistung/Qualität, Zeit und Kosten |
| Trade-off-Analyse | Gegenüberstellung von Alternativen und Abwägung der Vor- und Nachteile |
| Genehmigt mit Änderungen | Änderung wird genehmigt, aber mit Modifikationen |
| Zurückgestellt | Änderung wird zu einem späteren Zeitpunkt erneut geprüft |
| Abgelehnt | Änderung wird nicht umgesetzt |
| Routine-Änderung | Kleine, routine-mäßige Änderungen, die vom Projektleiter entschieden werden |
| Kritische Änderung | Große Änderung mit hohem Risiko, die vom CCB entschieden werden |
| Gold-Plating | Hinzufügen von Features, die nicht gefordert wurden (Überperfektionierung) |
| Stakeholder | Alle Personen oder Gruppen, die ein berechtigtes Interesse am Projektverlauf oder -ergebnis haben |
| Kritische Erfolgsfaktoren (KEF) | Die 3-5 wichtigsten Faktoren, die über Erfolg oder Misserfolg des Projekts entscheiden |
9. Verständnisfragen
Frage 1: Change Management Prozess
Ein Kunde meldet einen Change Request für eine neue Funktion im CRM-System. Die Funktion würde 2 Wochen Entwicklungsaufwand erfordern und das Budget um 5.000 € erhöhen. Der Projektleiter hat Budgetkompetenz bis zu 3.000 €.
a) Sollte der Projektleiter oder das CCB entscheiden? Warum? b) Welcher Prozess sollte durchlaufen werden? c) Was sollte bei der Auswirkungsanalyse berücksichtigt werden?
Lösung: a) Entscheidung: Change Control Board (CCB)
Begründung: - Die Kosten von 5.000 € liegen über der Kompetenz des Projektleiters (Budgetkompetenz bis 3.000 €) - Die Änderung erfordert 2 Wochen Entwicklungsauswurf, was den Zeitplan beeinflusst - Die Änderung ist keine Routine-Änderung, sondern eine neue Funktion mit Auswirkungen auf Scope - Die Kriterien für CCB-Entscheidung (große Änderung, hohe Kosten, zeitliche Auswirkung) sind erfüllt
b) Prozess: 1. Change Request erstellen: Kunde füllt CR-Vorlage aus (Titel, Beschreibung, Begründung, Priorität) 2. Erste Analyse & Kategorisierung: Projektleiter bewertet CR und kategorisiert als kritisch (groß, hohe Kosten) 3. CCB-Meeting: CR wird im CCB präsentiert und diskutiert 4. Entscheidung: CCB entscheidet (Genehmigt, Genehmigt mit Änderungen, Abgelehnt, Zurückgestellt) 5. Auswirkungsanalyse: Detaillierte Analyse der Auswirkungen auf Zeit, Kosten, Qualität 6. Projektplan anpassen: PSP, Terminplan, Kostenplan angepasst 7. Änderung umsetzen: Entwicklung, Testing, Freigabe 8. Dokumentation: CR dokumentiert, Release Notes erstellt
c) Auswirkungsanalyse sollte berücksichtigen:
| Aspekt | Fragen |
|---|---|
| Scope | Wie verändert sich der Projektumfang? Neue Funktion hinzugefügt? |
| Zeit | Wie verändert sich der Zeitplan? 2 Wochen Verzögerung? Meilensteine verschoben? |
| Kosten | Wie verändern sich die Kosten? 5.000 € Aufwand? Zusätzliche Lizenzkosten? |
| Qualität | Wie verändert sich die Qualität? Zusätzliche Tests erforderlich? Neue Risiken? |
| Ressourcen | Welche Ressourcen werden benötigt? Entwickler für 2 Wochen? Testzeitraum? |
| Risiken | Welche neuen Risiken entstehen? Integration mit bestehenden Funktionen? Performance-Risiken? |
| Abhängigkeiten | Welche Abhängigkeiten gibt es? Schnittstellen zu anderen Modulen? |
| Nachforderungen | Gibt es Nachforderungen gegenüber dem Kunden? Zeitverlängerung? Kostenübernahme? |
Frage 2: Scope Creep
Ein IT-Projekt läuft seit 3 Monaten. Der Kunde hat währenddessen 15 kleine Change Requests gestellt, die jeweils vom Projektleiter genehmigt wurden. Jede Änderung kostete durchschnittlich 500 € und verursachte 2 Tage Verzögerung. Das ursprüngliche Budget war 50.000 €, die ursprüngliche Projektdauer war 6 Monate.
a) Wie hoch ist die Gesamtkosten- und Zeitverzögerung durch die 15 Änderungen? b) Liegt hier Scope Creep vor? Warum? c) Was hätte anders gemacht werden können?
Lösung: a) Gesamtkosten und Zeitverzögerung: - Kosten: 15 Änderungen × 500 € = 7.500 € (15% des ursprünglichen Budgets) - Zeit: 15 Änderungen × 2 Tage = 30 Tage (ca. 1,5 Monate, 25% der ursprünglichen Projektdauer)
Ergebnis: - Neues Budget: 50.000 € + 7.500 € = 57.500 € (+15%) - Neue Projektdauer: 6 Monate + 1,5 Monate = 7,5 Monate (+25%)
b) Ja, hier liegt Scope Creep vor.
Begründung: - Es gibt 15 Änderungen in nur 3 Monaten (durchschnittlich 1 pro Woche) - Jede Änderung wurde genehmigt, ohne die kumulativen Auswirkungen zu berücksichtigen - Die Gesamtauswirkung (15% Budget, 25% Zeit) ist signifikant - Die Änderungen sind "klein und schleichend", was für Scope Creep typisch ist - Es gibt keine klare Scope-Begrenzung oder Priorisierung
c) Was hätte anders gemacht werden können:
- Klare Scope-Definition: Detailliertere Definition des Projektumfangs zu Projektstart, einschließlich "In-Scope" und "Out-of-Scope"
- Priorisierung von Anforderungen: Unterscheidung in "Muss-Haben", "Kann-Haben", "Sollte-Haben"
- Change-Management-Prozess: Strukturierter Prozess für alle Änderungen, auch kleine
- Kumulatives Tracking: Tracking der kumulativen Auswirkungen aller Änderungen (Budget, Zeit)
- Stopp-Kriterien: Definition von Stopppunkten (z.B. bei 10% Budgetüberschreitung keine weiteren Änderungen ohne CCB-Entscheidung)
- Kommunikation mit Kunden: Transparente Kommunikation über Auswirkungen von Änderungen
- Trade-off-Analyse: Gegenüberstellung von Kosten und Nutzen bei jeder Änderung
- Agile Iterationen: Nutzung agiler Methoden (Sprints, Iterationen) zur Einplanung von Änderungen in geplanten Iterationen
- Budget- und Zeitpuffer: Einplanung von Puffern für unerwartete Änderungen (z.B. 10-20% Budgetpuffer)
- Kunden-Schulung: Aufklärung über Auswirkungen von Änderungen auf Zeit, Kosten, Qualität
Frage 3: Magisches Dreieck und Trade-off
Ein Projektteam hat einen Change Request erhalten, der die Performance des Systems verbessern soll. Die Optionen sind:
- Option A: Performance verbessern, aber Projektdauer um 4 Wochen verlängern, Kosten um 20.000 € erhöhen
- Option B: Performance nicht verbessern, aber Projektdauer und Kosten beibehalten
- Option C: Performance verbessern, aber eine andere Funktion entfernen (spart 2 Wochen und 10.000 €)
Führen Sie eine Trade-off-Analyse durch und machen Sie eine Empfehlung.
Lösung:
Trade-off-Analyse:
| Kriterium | Option A | Option B | Option C |
|---|---|---|---|
| Zeit | +4 Wochen | - | +2 Wochen (netto: +4 -2 = +2) |
| Kosten | +20.000 € | - | +10.000 € (netto: +20 -10 = +10) |
| Leistung/Qualität | + (Performance verbessert) | - (nicht verbessert) | + (Performance verbessert) aber - (andere Funktion entfernt) |
| Bewertung | Hoch (bessere Performance, aber teuer und lang) | Gering (keine Verbesserung) | Mittel bis Hoch (bessere Performance, moderate Kosten und Zeit, aber andere Funktion entfernt) |
Empfehlung: Option C (mit Klarstellung und Kommunikation)
Begründung:
- Business-Value prüfen:
- Ist die Performance-Verbesserung für den Kunden wichtiger als die andere Funktion?
- Wie hoch ist der geschäftliche Nutzen der Performance-Verbesserung?
-
Wie hoch ist der geschäftliche Nutzen der anderen Funktion?
-
Wenn Performance wichtiger ist:
- Option C bietet die beste Balance zwischen Kosten, Zeit und Qualität
- Netto-Kosten (+10.000 €) und Netto-Zeit (+2 Wochen) sind akzeptabel
-
Die entfernte Funktion sollte eine "Kann-Haben"-Funktion sein, kein "Muss-Haben"
-
Wenn die andere Funktion wichtiger ist:
- Option B sollte gewählt werden (keine Änderung)
- Performance-Verbesserung sollte in einem zukünftigen Projekt geplant werden
-
Alternativ: Performance-Optimierung in der Wartungsphase durchführen
-
Kommunikation mit Kunden:
- Transparente Kommunikation über die drei Optionen und deren Auswirkungen
- Kunden-Entscheidung basierend auf geschäftlichem Nutzen
- Klärung, ob die Performance-Verbesserung oder die andere Funktion wichtiger ist
Alternative: Option A (wenn Budget und Zeit keine Beschränkungen sind und Performance kritisch ist) - Wählen Sie Option A, wenn die Performance-Verbesserung kritisch für den Geschäftsbetrieb ist - Die zusätzlichen Kosten (+20.000 €) und Zeit (+4 Wochen) müssen im Budget und Zeitplan berücksichtigt werden - Klären Sie, ob der Kunde bereit ist, die zusätzlichen Kosten und Zeit zu akzeptieren
Nächstes Kapitel: 7. Risikomanagement