07 Ursachenanalyse

Kapitel Übersicht

Kapitel 07 Lesezeit: ~20 Min Quelle: OuP-09_Projekt-Controlling.pdf (Seiten 34-38)

Warum Ursachenanalyse?

Die Aufgabe der Ursachenanalyse

Das Projektcontrolling hat die Aufgabe, die Gründe für die festgestellten Abweichungen aufzuspüren.

         Soll-Ist-Vergleich
                 ↓
         Abweichung erkannt
                 ↓
         Ursachenanalyse
                 ↓
         Gegenmaßnahmen
                 ↓
         Projekt im Griff

Die Herausforderung

Manchmal ist die Ursache offensichtlich

Ein Mitarbeiter wurde krank und konnte seine Aufgaben nicht erledigen. → Keine weitere Analyse erforderlich.

Meist ist es komplexer

Meist lohnt es sich jedoch, eine genauere Ursachenforschung zu betreiben, da oft mehrere Ursachen die Abweichung verursacht haben.

Typische Ursachenkategorien

Folgende Ursachenkategorien lassen sich unterscheiden:

1. Normale Änderungen

Aufgrund von neuen Erkenntnissen in der Durchführung
Anpassungen an sich ändernde Rahmenbedingungen

Beispiel

Während der Entwicklung stellt sich heraus, dass ein technisches Problem eine andere Architektur erfordert. Dies ist eine normale Änderung aufgrund neuer Erkenntnisse.

2. Fehler

Planungsfehler
Zu optimistische Schätzungen
Vergessene Aspekte

Beispiel

Der Aufwand für die Integration wurde vergessen, weil der Planer die Komplexität unterschätzt hat.

3. Fehler bei der Durchführung

Ineffiziente Arbeitsweise
Schlechtes Ressourcenmanagement
Mangelnde Kommunikation

Beispiel

Das Team hat sich an Standards nicht gehalten, was zu vielen Nacharbeiten führte.

4. Unverschuldete Änderungen

Nachträgliche Kundenwünsche
Gesetzesänderungen
Externe Störungen

Beispiel

Eine neue Gesetzgebung erfordert Anpassungen an der Software, die nicht geplant waren.

Ursachen von Abweichungen

Übersicht der typischen Ursachen

Kategorie	Beispiele
Planung	Unterschätzter Aufwand, vergessene Aufgaben, unrealistische Termine
Ressourcen	Fehlende Qualifikationen, Personalengpässe, Ausfälle
Technik	Technische Probleme, Inkompatibilitäten, unerwartete Komplexität
Mitarbeiter	Krankheit, Fluktuation, Motivationsprobleme
Externe Faktoren	Lieferantenprobleme, Änderungen bei Stakeholdern
Qualität	Fehleranfälligkeit, unzureichende Tests
Kommunikation	Missverständnisse, fehlende Informationen

Vermeidbarkeit

Kernerkenntnis

Die Ursachen von Abweichungen im Projektverlauf sind vielfältig. Oft könnten die Abweichungen vermieden werden, wenn im Vorfeld "gutes PM" betrieben wurde.

Beispiele für vermeidbare Abweichungen:

Ursache	Vermeidung durch "gutes PM"
Unterschätzter Aufwand	Detaillierte Aufwandsschätzung, Puffer einplanen
Fehlendes Verständnis	Klare Anforderungen, Review mit Stakeholdern
Technische Überraschungen	Proof of Concept vor vollständiger Entwicklung
Ressourcenprobleme	Verfügbarkeitsplanung, Ausweichpläne
Qualitätsprobleme	Quality Gates, Teststrategie, Code Reviews

Das Ishikawa-Diagramm (Fischgräten-Diagramm)

Definition

Das Ishikawa-Diagramm (auch Fischgräten-Diagramm oder Cause-and-Effect-Diagramm genannt) ist ein Werkzeug zur systematischen Analyse von Problemen und deren Ursachen.

Ursprung

Entwickelt von Kaoru Ishikawa in den 1960er Jahren für die Qualitätskontrolle in der japanischen Industrie.

Das 5M-Modell

Das klassische Ishikawa-Diagramm unterscheidet fünf Hauptkategorien (5M):

Kategorie (5M)	Bedeutung	Beispiele im Projekt
Mensch	Alle personbezogenen Faktoren	Qualifikation, Motivation, Kommunikation
Material	Materialien und Ressourcen	Hardware, Software-Lizenzen, Dokumentation
Maschine	Werkzeuge und Ausrüstung	Entwicklungsumgebung, Server, Tools
Methode	Verfahren und Prozesse	Arbeitsweise, Standards, Prozesse
Mitwelt	Externe Einflüsse	Kunden, Stakeholder, Gesetze

Erweiterte Kategorien

In manchen Kontexten werden zusätzliche Kategorien ergänzt:

Kategorie	Bedeutung
Management	Führung und Entscheidungsprozesse
Milieu	Arbeitsumfeld, Kultur, Atmosphäre
Messung	Messmethoden, Kennzahlen, Controlling

Aufbau des Ishikawa-Diagramms

graph TD
    subgraph "Ishikawa-Diagramm"
        direction TB
        Result["Problem / Abweichung"]
        M1["MENSCH"]
        M2["MATERIAL"]
        M3["MASCHINE"]
        M4["METHODE"]
        M5["MITWELT"]

        Result --> M1
        Result --> M2
        Result --> M3
        Result --> M4
        Result --> M5

        M1 --> U11["Ursache 1.1"]
        M1 --> U12["Ursache 1.2"]
        M1 --> U13["Ursache 1.3"]

        M2 --> U21["Ursache 2.1"]
        M2 --> U22["Ursache 2.2"]

        M3 --> U31["Ursache 3.1"]
        M3 --> U32["Ursache 3.2"]

        M4 --> U41["Ursache 4.1"]
        M4 --> U42["Ursache 4.2"]

        M5 --> U51["Ursache 5.1"]
        M5 --> U52["Ursache 5.2"]
    end

Beispiel: Kostenüberschreitung

Problem: Das Projekt ist 30% über Budget.

                            KOSTENÜBERSCHREITUNG (30%)
                                      |
        +---------------------------+---------------------------+
        |                           |                           |
    MENSCH                     MATERIAL                    MASCHINE
        |                           |                           |
  Unterschätzung            Hardware-            Entwicklungsumgebung
  durch Team                teurer als geplant        ineffizient
        |                           |                           |
  Fehlendes                Lizenzkosten            Performance-
  Fachwissen                vergessen               probleme
        |                           |                           |
        +---------------------------+---------------------------+
                                      |
        +---------------------------+---------------------------+
        |                           |                           |
    METHODE                    MITWELT                    MANAGEMENT
        |                           |                           |
  Mangelnde                 Kundenwünsche          Mangelnde
  Aufwandsschätzung        nachträglich        Lenkung
        |                           |                     (Steuerung)
  Keine Puffer              Gesetzesänderung
        |                           |
  Schlechtes                   Supplier-
  Projektmanagement           probleme

Vorgehensweise zur Ursachenanalyse

Schritt-für-Schritt-Prozess

flowchart TD
    A[Schritt 1<br/>Abweichung identifizieren] --> B[Schritt 2<br/>Ursachenkategorien definieren]
    B --> C[Schritt 3<br/>Mögliche Ursachen brainstormen]
    C --> D[Schritt 4<br/>Hauptursachen identifizieren]
    D --> E[Schritt 5<br/>Lösungen entwickeln]
    E --> F[Schritt 6<br/>Priorisierung der Lösungen]
    F --> G[Schritt 7<br/>Umsetzung der Lösungen]
    G --> H[Schritt 8<br/>Wirksamkeit überwachen]

1. Abweichung identifizieren

Klare Formulierung des Problems
Quantifizierung der Abweichung
Einordnen in die Controlling-Kennzahlen

Beispiel

Abweichung: Das Projekt liegt 15% hinter dem Zeitplan (SPI = 0,85).

2. Ursachenkategorien definieren

Wahl des Analyse-Modells (z.B. 5M)
Anpassung an Projektkontext

3. Mögliche Ursachen brainstormen

Alle möglichen Ursachen erfassen
Keine Kritik oder Bewertung in dieser Phase
Nutzen von Kreativitätstechniken (Brainstorming, Mind Map)

4. Hauptursachen identifizieren

Analyse der brainstormten Ursachen
Bewertung nach Einfluss und Wahrscheinlichkeit
Priorisierung der Hauptursachen

5. Lösungen entwickeln

Für jede Hauptursache Lösungsansätze entwickeln
Berücksichtigung von Ressourcen, Zeit, Machbarkeit

6. Priorisierung der Lösungen

Bewertung nach Nutzen und Aufwand
Auswahl der prioritären Maßnahmen

7. Umsetzung der Lösungen

Festlegung von Verantwortlichkeiten und Terminen
Umsetzung der Maßnahmen

8. Wirksamkeit überwachen

Überprüfung der Wirksamkeit der Maßnahmen
Anpassung bei Bedarf

Analyse-Techniken

1. 5-Why-Methode

Die 5-Why-Methode ist eine einfache aber effektive Technik zur Ermittlung der Ursachen.

Prinzip: Wiederholtes Fragen "Warum?" bis zur Wurzel des Problems.

Beispiel: Software-Fehler

Problem: Software hat einen kritischen Bug.

Warum 1: Warum hat die Software einen Bug? → Ein Entwickler hat einen Fehler im Code eingebaut.

Warum 2: Warum hat der Entwickler einen Fehler eingebaut? → Er war unter Zeitdruck.

Warum 3: Warum war er unter Zeitdruck? → Das Deadline wurde zu kurzfristig verschoben.

Warum 4: Warum wurde das Deadline verschoben? → Ein Stakeholder hat nachträglich eine Anforderung hinzugefügt.

Warum 5: Warum wurde die Anforderung nachträglich hinzugefügt? → Anforderungen wurden nicht vollständig gesammelt.

Wurzelursache: Unzureichendes Requirements-Management.

2. FMEA (Failure Mode and Effects Analysis)

FMEA ist eine systematische Methode zur Identifikation potenzieller Fehler und deren Auswirkungen.

FMEA-Blatt:

Fehlermöglichkeit	Ursache	Auswirkung	Wahrscheinlichkeit	Schweregrad	Risikoprioritätszahl (RPZ)
Datenverlust	Backup fehlgeschlagen	Projektverzögerung	2	10	20
Qualitätsmangel	Keine Tests	Nacharbeiten	5	5	25
Terminverzug	Ressourcenmangel	Projektende verschieben	3	8	24

3. Pareto-Analyse (80/20-Regel)

Die Pareto-Analyse basiert auf dem Prinzip, dass 80% der Probleme durch 20% der Ursachen verursacht werden.

Beispiel

Analyse von 50 Projektabweichungen zeigt:

40% (20 Abweichungen) werden durch schlechtes Requirements-Management verursacht
30% (15 Abweichungen) werden durch Ressourcenprobleme verursacht
30% (15 Abweichungen) werden durch technische Probleme verursacht

Schlussfolgerung: Fokus auf Requirements-Management reduziert 40% der Probleme!

Korrekturmaßnahmen (Gegensteuerung)

Vom Projektleiter wird erwartet

Der Projektleiter muss flexibel auf Störungen, Abweichungen oder Nichtverfügbarkeit vorgesehener Projektmittel reagieren.

Reaktionsmöglichkeiten auf Veränderungen

Option 1: Am Projektziel wird festgehalten

Die Kosten- und Terminpläne sind dann entsprechend zu ändern.
Budgeterhöhung oder Terminverlängerung akzeptieren

Option 2: Priorität auf Termineinhaltung

Wird der Termineinhaltung höchste Priorität eingeräumt, könnte u.U.:
- Der Leistungsumfang reduziert werden (Scope-Management)
- Funktionserweiterungen verschoben werden

Option 3: Am Leistungsumfang und Termin wird festgehalten

Dann wird verstärkter Mitteleinsatz notwendig
Kostensteigerungen müssen akzeptiert werden
Zusätzliche Ressourcen einplanen

Option 4: Kostenüberschreitungen durch Terminüberschreitungen auffangen

Zeit sparen, um Kosten zu sparen
Evtl. Verschiebung von weniger kritischen Aufgaben

Maßnahmen bei Abweichungen

Art der Abweichung	Mögliche Maßnahmen
Terminverzögerung	• Ressourcen erhöhen • Leistungsumfang reduzieren • Parallelisierung erhöhen
Kostenüberschreitung	• Prozessoptimierung • Verhandlung mit Lieferanten • Scope reduzieren
Qualitätsprobleme	• Tests intensivieren • Code Reviews einführen • Qualitätsstandards durchsetzen
Ressourcenengpässe	• Ausweichpläne aktivieren • Outsourcing prüfen • Priorisieren
Kommunikationsprobleme	• Meeting-Frequenz erhöhen • Dokumentation verbessern • Stakeholder-Management

Liste der offenen Punkte (LOP)

Problemstellung

Das Durchführen von Maßnahmen zu

benannten, aber noch nicht gelösten Problemen
Qualitätsfehlern
… muss überwacht werden.

Es besteht Entscheidungsbedarf bei

Änderungsanträgen
eingetroffenen Risiken, deren Auswirkungen noch zu überwinden sind
…

Gefahr: Wichtige Punkte gehen verloren, weil sich aktuell niemand darum kümmern kann.

Lösungsansatz: Führen einer Liste der Offenen Punkte (LOP)

Inhalte der LOP

Feld	Beschreibung
Name des Punkts	Klare Identifizierung
Beschreibung	Detaillierte Beschreibung des Problems/Punktes
Wer hat ihn eingestellt?	Für Nachfragen
Wer kümmert sich?	Verantwortlicher für die Klärung
Bis wann?	Zieltermin
Priorität	Hoch, Mittel, Niedrig
Status	Offen, In Arbeit, Erledigt, Abgelehnt

Verantwortlichkeit

Verantwortlichen für die LOP benennen
Aufgaben:
- Aktualisierung
- Übersicht behalten
- Nachhalten von Terminen

Regelmäßige Bearbeitung

Wöchentliche Team-Meetings:
- Vorbereitung: Punkte durchgehen und bewerten
- Im Meeting Status erheben, Aufgaben verteilen

Einfache Umsetzung

Die LOP kann einfach mit einer Tabellenkalkulation (Excel, Google Sheets) umgesetzt werden.

LOP-Template

ID	Name	Beschreibung	Eingestellt durch	Verantwortlich	Bis wann	Priorität	Status
LOP-01	Integration fehlgeschlagen	API-Schnittstelle nicht stabil	Herr Müller	Frau Schmidt	15.01.	Hoch	In Arbeit
LOP-02	Kunde wünscht neue Funktion	Zusatzfeature in Phase 2	Herr Kunde	Herr Meier	30.01.	Mittel	Offen
LOP-03	Server-Kapazität zu gering	Performance-Probleme	Frau Schmidt	Herr Müller	22.01.	Hoch	Erledigt

Typische Fehler im Projektcontrolling

1. Statt auf den Projektfortschritt wird nur noch auf den Projektplan geachtet

Problem: Der Plan wird als Selbstzweck betrachtet, nicht als Werkzeug.

Lösung: Fokus auf den tatsächlichen Fortschritt und den Wert, der erbracht wird.

2. Messgrößen werden nicht zeitnah zur Verfügung gestellt

Problem: Daten liegen zu alt vor, um sinnvolle Steuerungsentscheidungen zu treffen.

Lösung: Regelmäßige Erfassungsrhythmen und sofortige Berichterstattung.

3. Zwischen Messung und Steuerung ist ein zu großer zeitlicher Abstand

Problem: Wegen der Verzögerung ist die Steuerung zu spät.

Lösung: Kürzere Steuerungszyklen, agile Methoden.

4. Falsche Messgrößen werden verwendet

Problem: KPIs spiegeln nicht die Realität wider.

Lösung: Regelmäßige Prüfung und Anpassung der Kennzahlen.

5. Granularität der Messgrößen ist falsch gewählt

Problem: Zu grob oder zu detailliert.

Lösung: Anpassung an Projektgröße und Anforderungen.

6. Projektcontrolling verkommt zu reinem Kostencontrolling

Problem: Controller fokussieren nur auf Kosten, da dies am einfachsten ist.

Lösung: Integriertes Controlling (Kosten, Zeit, Leistung).

7. Es wird keine Zeit für das Controlling eingeplant

Problem: Controlling wird als "überflüssig" betrachtet.

Lösung: Zeitbudget für Controlling explizit einplanen.

8. Aus dem Personalwesen abgeleitete Größen bedürfen besonders sensibler Betrachtung

Problem: Personenbezogene Daten sind nicht öffentlich.

Lösung: Sensibler Umgang mit Personaldaten, Aggregation auf Team-Ebene.

9. Verwechslung von Rollen: Projektcontroller ≠ Projektmanager

Problem: Der Controller wird für die Beseitigung von Schwachstellen verantwortlich gemacht.

Lösung: Klare Rollenverteilung: Controller zeigt auf, Manager entscheidet.

10. Nichtbeachtung der Verbindlichkeit von Terminzusagen

Problem: Beim Überschreiten der Termine werden keine Gegenmaßnahmen eingeleitet.

Lösung: Terminbindlichkeit und konsequentes Handeln bei Überschreitung.

Zusammenfassung

Kernerkenntnisse

Ursachenanalyse ist essenziell: Ohne Analyse der Ursachen können keine wirksamen Gegenmaßnahmen ergriffen werden.
Systematische Methoden nutzen: Ishikawa-Diagramm, 5-Why, FMEA, Pareto-Analyse.
Rollen klären: Projektcontroller analysiert, Projektmanager entscheidet.
Offene Punkte tracken: LOP als wichtiges Werkzeug für das Projektmanagement.
Typische Fehler vermeiden: Regelmäßige Reflexion der Controlling-Praxis.

Wichtigste Werkzeuge

Werkzeug	Einsatz	Zweck
Ishikawa-Diagramm	Ursachenanalyse	Systematische Ursachenermittlung
5-Why-Methode	Ursachenanalyse	Einfache Tiefenanalyse
FMEA	Risikomanagement	Analyse potenzieller Fehler
Pareto-Analyse	Priorisierung	Fokus auf kritische Ursachen
LOP	Problemmanagement	Tracking offener Punkte

Empfehlung

Nutzen Sie die Ishikawa-Methode als Standard für komplexe Probleme
Ergänzen Sie sie durch die 5-Why-Methode für gezielte Tiefenanalysen
Führen Sie eine Liste offener Punkte (LOP) in jedem Projekt
Vermeiden Sie die typischen Fehler durch regelmäßige Reflexion
Klären Sie die Rollenverteilung zwischen Controller und Manager

Die Ursachenanalyse ist der Schlüssel zu effektivem Projektcontrolling. Nur durch das Verstehen der Ursachen können wir wirksame Maßnahmen ergreifen und Projekte erfolgreich steuern.

Im nächsten Kapitel finden Sie ein umfassendes Quiz, um Ihr Wissen zu testen und zu festigen.