# PM-Nachschlagewerk und Steuerungshilfe > **Markdown-Fassung** des Controlling-Handbuchs der App. Interaktive Tools (EVA-Rechner, Risiko-Bewerter, Burndown-Demo, Meilenstein-Trend-Check) und alle Grafiken gibt es nur in der HTML-Fassung: . PDF-Fassung zum Drucken: . *Arbeitshilfe zum Nachschlagen und Durchrechnen: Begriffe und Techniken des Projektmanagements (gegliedert nach PMBOK Guide 8. Edition, ergänzt um PRINCE2 und deutsche Verwaltungspraxis), dazu vollständig durchgerechnete Beispiele, Grafiken und vier interaktive Rechenwerkzeuge. Die Texte ersetzen nicht das Original; zum Nachlesen ist jeweils der passende Teil des Guides genannt.* > **Beispielprojekt für das ganze Werk** > > **„E-Akte 2026“** — Einführung eines Dokumentenmanagementsystems in einer Stadtverwaltung: 8.000 digitale Akten, drei Fachämter, 140 Endanwender. **Gesamtbudget (BAC) 120.000 €**, Laufzeit **Januar bis August 2026 (8 Monate)**, Projektleitung (PL), Lenkungsausschuss (LA) mit Kämmerer, IT-Leitung und Erstem Beigeordneten. Die Kernphase „Migration im Pilotamt“ wird in Teil 2 als Netzplan mit 6 Vorgängen (A bis F) über 14 Wochen durchgerechnet; Teil 3 steuert das Gesamtprojekt monatlich nach Earned-Value-Methode. ## Teil 1: Grundlagen: Controlling-Zielbild, Charta, Ziele, Stakeholder, Rollen Ohne geklärten Auftrag, messbare Ziele und bekannte Beteiligte ist jedes Controlling Zahlenrausch. Teil 1 legt das Fundament, auf dem alle Kennzahlen der Teile 3 bis 7 erst sinnvoll werden. ### 1.1 Was ist Projektcontrolling? **Was ist es?** Projektcontrolling ist das fortlaufende Vergleichen von *Soll* (genehmigter Plan) und *Ist* (gemessener Stand) mit dem Ziel, **frühzeitig** zu erkennen, ob Ziele, Termine oder Budget gefährdet sind, und **rechtzeitig gegenzusteuern**. Es ist Führungsfunktion, nicht Bürokratie: Zahlen dienen Entscheidungen, nicht der Rechtfertigung. **Wofür?** Damit Abweichungen erkannt werden, *solange* noch Handlungsoptionen existieren — ein um zwei Monate erkannter Terminverzug ist eine Plananpassung, ein um acht Monate erkannter ein Projektminenfeld. **So geht's (Kernzyklus, wiederholt monatlich oder pro Sprint):** 1. **Basis schaffen:** genehmigte Baseline für Umfang, Termin, Kosten (Teil 2). Ohne Baseline kein Soll. 2. **Ist messen:** Fertigstellungsgrade und Kosten erfassen, einheitlich und zum Stichtag. 3. **Vergleichen:** Abweichungen und Kennzahlen bilden (SPI, CPI — Teil 3). 4. **Interpretieren:** Ursachen klären — Kennzahlen zeigen *dass*, nie *warum*. 5. **Entscheiden und nachfassen:** Maßnahmen wirken lassen und Wirkung im nächsten Zyklus prüfen. > **Typische Fehler** > > Vergleich gegen den *letzten* Plan statt gegen die Baseline (jede Anpassung „ Normalisierung“); Messstichtage, die jeder Partner anders legt; Controlling als Monatsritual ohne Entscheidung; Zahlen sammeln, aber Ursachen nie vor Ort klären. ### 1.2 Projektcharta (Projektauftrag) **Was ist es?** Eine ein- bis zweiseitige Urkunde, in der der Auftraggeber das Projekt formal bevollmächtigt: Ziel, Nutzen, Umfang, Budgetrahmen, Rollen, Berichtswesen und Entscheidungswege. Beim öffentlichen Sektor oft „Projektbeschluss“ mit Dienstanweisungscharakter. **Wofür?** Die Charta ist die Legitimation der Projektleitung („wer bestimmt hier eigentlich?“) und der Referenzpunkt für jede spätere Änderung (Teil 6). Ohne sie ist jedes Controlling gegen ein bewegliches Ziel. **So geht's — Mindestbestandteile:** Auftrag und Hintergrund · SMART-Ziele · grober Umfang mit Abgrenzung („nicht Gegenstand: …“) · Meilensteine · Budget und Freigabeinstanzen · Organisation (PL, LA, Kernteam) · Berichtspflichten · benannte Risiken am Start · Unterschriften. > **Beispiel: Charta-Auszug „E-Akte 2026“** > > | Feld | Eintrag | > | --- | --- | > | Auftrag | Einführung DMS „Akte24“ in drei Ämtern bis 31.08.2026, Pilotamt Bauamt ab 04.05.2026 | > | Ziel | 8.000 Altakten digital verfügbar; Auskunftsdauer je Akt von 3 Tagen auf 30 Minuten senken | > | Nicht Gegenstand | Akte born-digital neu ab 2027; Umbau des Archivs | > | Budget | 120.000 € Kostenbasis inkl. 23.000 € Risikoreserve; Freigaben > 5.000 € durch LA | > | Organisation | PL: Frau Hoffmann (50 %); LA: Erster Beigeordneter, Kämmerer, IT-Leiter; monatlicher Statusbericht | > > **Typische Fehler** > > Charta ohne Abgrenzung („nicht Gegenstand“) — Tür offen für Scope Creep; Ziele ohne Messgröße; Charta geschrieben und nie wieder gelesen, obwohl sich Rahmenbedingungen ändern. ### 1.3 Ziele nach SMART **Was ist es?** Prüfmaßstab für Zielformulierungen: **S**pezifisch, **M**essbar, **A**kzeptiert (durch Auftraggeber), **R**ealistisch, **T**erminiert. Jedes Ziel muss ohne Interpretation messbar und einem Berichtstermin zuordenbar sein. **Wofür?** Nur messbare Ziele lassen sich controllen; das Ziel ist zugleich Abnahmekriterium (Teil 8 Glossar: Abnahme) und Messlatte für den Nutzen (Business Case). > **Durchgearbeitet: zwei Formulierungen prüfen** > > | Schwach | SMART-verbessert | Prüfung | > | --- | --- | --- | > | „Abläufe werden digitalisiert.“ | „Bis 31.08.2026 sind 8.000 Altakten (Zählung im DMS) eingescannt und mit Aktenplan verknüpft; Stichprobe 200 Akten ohne falsche Zuordnung.“ | SMART | > | „Anwender sind zufriedener.“ | „Bis 30.09.2026 erreichen 70 % der 140 Anwender in der jährlichen Umfrage mindestens 3,5 von 5 Punkten bei „Akte auffindbar“.“ | Messgröße und Termin ergänzt; Realismus aus Vorjahresumfrage (3,1) geprüft | > > **Typische Fehler** > > Messgröße ohne Datenquelle („Woher kommt die Zahl?“); Ziele, die nur das Produkt, nicht die Wirkung beschreiben; sechs „Hauptziele“, von denen keines messbar ist. ### 1.4 Stakeholder-Analyse **Was ist es?** Systematisches Erfassen aller Personen und Gruppen, die das Projekt beeinflussen oder von ihm betroffen sind, und Einordnen nach **Einfluss (Macht)** und **Interesse**. Ergebnis ist ein Stakeholderregister plus Behandlungsstrategie je Quadrant. **Wofür?** Widerstand erzeugt Termin- und Budgetrisiken. Wer die Träger von Entscheidungen kennt, plant Kommunikation und Eskalationswege (Teil 6) gezielt statt diffus „alle zu informieren“. **So geht's:** (1) Brainstorming mit Kernteam und Auftraggeber, auch Kritiker benennen · (2) je Stakeholder: Rolle, Interesse, Haltung (ablehnend bis führend), Erwartung an Information · (3) Einordnung in die Matrix · (4) Maßnahmen je Quadrant · (5) alle 2–3 Monate fortschreiben — Haltungen verschieben sich. **Maßnahmen je Quadrant** ``` Hoher Einfluss + hohes Interesse → eng steuern (persönlich, wöchentlich, in Entscheidungen) Hoher Einfluss + geringes Interesse → zufriedenstellen (kurz, faktisch, keine Überraschungen) Geringer Einfluss + hohes Interesse → informieren (regelmäßig, kanalbasiert) Geringer Einfluss + geringes Interesse → beobachten (auf Abruf) ``` *Abbildung (nur in der HTML/PDF-Fassung): Abb. 1.1 — Einfluss-Interesse-Matrix „E-Akte 2026“. Der Betriebsrat startet mit geringem Interesse, kann aber bei Umorganisationen der Aktenführung in den Quadranten „eng steuern“ wandern — deshalb das Register lebendig halten.* > **Typische Fehler** > > Nur Befürworter analysieren; Analyse einmalig zum Start; Stakeholder als statisch behandeln; heikle Einordnungen (z. B. „ablehnend“) nicht verschriftlichen, sodass Nachfolge-PM das Wissen verliert. ### 1.5 RACI-Matrix **Was ist es?** Tabelle, die je Aufgabe/Arbeitspaket genau eine Person **A**ccountable (gesamte Verantwortung, genau eine je Aufgabe), ein oder mehrere **R**esponsible (durchführend), **C**onsulted (vor Entscheidung zu hören) und **I**nformed (nach Entscheidung zu informieren) zuordnet. **Wofür?** Der häufigste Konflikthebel im Projektcontrolling ist unklare Entscheidungszuständigkeit („dachte, das macht die IT“). RACI macht Verantwortung vorab prüfkbar. **So geht's:** Zeilen = Arbeitspakete/Entscheidungen aus dem Projektstrukturplan (Teil 2.1), Spalten = Rollen. Regel prüfen: je Zeile genau ein A; je Person nicht überall A; C sparsam (jedes C kostet Abstimmungszeit). **RACI „E-Akte 2026“ — Auszug für die Kernphase Migration** | Aufgabe / Entscheidung | PL | Auftraggeber (LA) | IT-Leitung | Fachabteilung Pilotamt | Dienstleister | | --- | --- | --- | --- | --- | --- | | Projektstrukturplan fortentwickeln | A R | I | C | C | I | | Freigabe Baseline (Termin/Kosten) | R | A | C | I | I | | Altdaten bereinigen (AP C) | I | | C | A R | R | | Migration durchführen (AP D) | A | I | C | C | R | | Abnahme Pilotphase | R | A | C | C | I | | Change Requests entscheiden (bis 5.000 €) | A | I | C | C | I | > **Typische Fehler** > > Zwei A in einer Zeile (Doppelverantwortung = keine); Gremien als A eintragen; RACI über 60 Zeilen aufblähen statt auf steuerungsrelevante Aufgaben zu konzentrieren; nie mit Beteiligten durchgesprochen. ### 1.6 Projektorganisation (OBA) **Was ist es?** Die Aufbau- und Ablauforganisation des Projekts: reine, Matrix- oder Einflussprojektorganisation. Im öffentlichen Sektor fast immer **Matrix**: Teammitglieder bleiben fachlich ihrer Behörde zugeordnet, arbeiten projektisch für begrenzte Wochenstunden. **So geht's:** OBA zeichnen (wer berichtet an wen, wer entscheidet was), weekly hours der Projektmitarbeiter schriftlich mit Fachvorgesetzten vereinbaren, Stellvertretungen benennen, Schnittstellen zur Linie definieren (wer macht Betrieb nach Go-live — Teil 8: Übergabe in den Betrieb). > **Beispiel: Matrix-Konsequenz beim „E-Akte 2026“** > > Die zwei Key-User des Bauamts sind zu 60 % für das Projekt eingeplant. Der Amtsleiter reserviert sie im Mai zusätzlich für eine Jahresstatistik. Ohne Abstimmung drohen 2×0,6 Personemonate = **ca. 96 Personentage** Verzug — im Netzplan (Teil 2.3) liegt Vorgang E (Testdaten prüfen) genau dann mit 3 Wochen Puffer. Konfliktlösung: Statistik auf Juni verschoben, weil E Puffer hat. Das ist Controlling vor der Zahl: Organisationswissen wirkt, bevor Kennzahlen es melden. > **Typische Fehler** > > Einplanung „mit 100 %“ obwohl Linie mitzählt (Realistisch: 60–80 % netto); keine Stellvertretung für PL; Betriebsübergabe nicht in der OBA verankert. ## Teil 2: Planung: Strukturplan, Terminplan, Netzplan, Schätzen Planung erzeugt die Baseline — das Soll, gegen das alle Teile 3 bis 7 messen. Kern dieses Teils: ein Netzplanbeispiel mit 6 Vorgängen, das von der Vorwärts- bis zur Rückwärtsrechnung vollständig Schritt für Schritt durchgerechnet wird. ### 2.1 Projektstrukturplan (WBS / PSP) **Was ist es?** Hierarchische, lückenlose Zerlegung des *gesamten* Projektumfangs in steuerbare Arbeitspakete (AP). Die 100-%-Regel: Was nicht im Strukturplan steht, gehört nicht zum Projekt — und was im Strukturplan steht, braucht Kosten, Termin und Verantwortlichen (RACI, Teil 1.5). **Wofür?** Der Strukturplan ist das Fundament für Schätzung (Bottom-up, Teil 2.6), Terminplanung (Netzplan), Verantwortung (RACI) und Leistungsmessung (EVA bewertet Fortschritt je Arbeitspaket). Strukturplanfehler pflanzen sich in jede Kennzahl fort. **So geht's:** (1) Ergebnisorientiert gliedern — nach Phasen, Objekten oder Funktionen, *nicht* nach Abteilungen · (2) hierarchisch nummerieren (1, 1.1, 1.1.1) · (3) auf Arbeitspakete herunterbrechen, bis ein Paket *einem* Verantwortlichen zuordenbar und in 2–10 Personentagen bewertbar ist · (4) je AP: Ergebnis, Aufwand, Termin, Abhängigkeiten, Risiko-Querverweis · (5) Abgrenzungsliste „nicht Gegenstand“ ergänzen. *Abbildung (nur in der HTML/PDF-Fassung): Abb. 2.1 — Projektstrukturplan „E-Akte 2026“. Die Summe der Phasen entspricht exakt dem BAC — das ist keine Formalie, sondern die Prüfung der 100-%-Regel.* > **Typische Fehler** > > Strukturierung nach Organisationschart (Abteilungen) statt nach Ergebnis; „Sonstiges“-Pakete; Pakete zu groß für Verantwortung („Migration“ ist keine AP, sondern eine Phase); Projektmanagementkosten (PM itself) vergessen — im Beispiel steckt PM-Aufwand anteilig in den Phasen. ### 2.2 Balkenplan (Gantt) und Meilensteine **Was ist es?** Zeitliche Darstellung der Vorgänge als Balken auf einer Zeitskala, abgeleitet aus dem Netzplan. Meilensteine sind Ereignisse mit Dauer null, dargestellt als Rauten. Der Gantt *zeigt* den Plan, der Netzplan *rechnet* ihn. **Wofür?** Kommunikation: Kein Lenkungsausschuss liest Netzpläne, jeder liest Balkenpläne. Für Steuerung gilt: Puffer, kritischer Pfad und Abhängigkeiten müssen im Gantt sichtbar bleiben, sonst wirkt jeder Vorgang gleich wichtig. *Abbildung (nur in der HTML/PDF-Fassung): Abb. 2.2 — Balkenplan Phase 2: 14 Wochen, kritischer Pfad A→B→D→F (rot), Vorgänge C und E haben je 3 Wochen Gesamtpuffer. MS1 Analyse abgeschlossen (Ende Wo 3), MS2 Migration technisch fertig (Wo 12), MS3 Pilot freigegeben (Wo 14).* > **Typische Fehler** > > Gantt ohne Abhängigkeiten „gezeichnet“ statt aus dem Netzplan abgeleitet — Puffer stehen dann falsch; Meilensteine ohne Prüfkriterium (woran erkennt der LA „abgeschlossen“?); Puffer unsichtbar, weil in Vorgangsdauern versteckt statt ausgewiesen. ### 2.3 Netzplan und kritischer Pfad — Theorie **Was ist es?** Gerichteter Graph aus Vorgängen (Knoten) und Anordnungsbeziehungen (Kanten). Die Critical Path Method (CPM) berechnet daraus früheste/späteste Termine, Puffer und den kritischen Pfad: die längste Kette abhängiger Vorgänge — jede Verzögerung dort verschiebt das Projektende. **Formeln der Netzplantechnik (Vorgang mit Dauer D)** ``` Vorwärts: ES = max(EF aller Vorgänger) · EF = ES + D Rückwärts: LF = min(LS aller Nachfolger) · LS = LF − D Gesamtpuffer: GP = LS − ES = LF − EF · Projektende = max(EF) ``` *ES frühester Start · EF frühestes Ende · LS spätester Start · LF spätestes Ende · GP Gesamtpuffer. GP = 0 ⇒ kritisch. Kritischer Pfad = Weg vom Start zum Ende nur über GP-0-Vorgänge.* **Wichtig:** „Puffer“ ist kein Eigentum eines Vorgangs, sondern liegt auf dem Weg. Verbraucht C seinen Puffer, kann E ihn nicht mehr nutzen — Puffer wird netzweit neu gerechnet. Deshalb nach jeder Änderung den ganzen Plan neu rechnen (Werkzeuge wie MS Project machen das; das Verständnis hier bleibt nötig, um die Ausgaben zu prüfen). ### 2.4 Netzplan vollständig durchgerechnet (Vollbeispiel, 6 Vorgänge) **Beispiel Phase 2 „Migration im Pilotamt“:** 6 Vorgänge mit Dauer in Wochen und Anordnungsbeziehungen (Ende-Anfang): **Vorgangsliste Phase 2** | Vorgang | Beschreibung | Dauer D (Wochen) | Vorgänger | | --- | --- | --- | --- | | A | Altakten analyserieren, Scanvolumen bestimmen | 3 | — | | B | DMS einrichten (Akte24), Rechte konfigurieren | 4 | A | | C | Altdaten bereinigen (Dubletten, Aktenteile) | 2 | A | | D | Migration durchführen (Import, Verknüpfung Aktenplan) | 5 | B | | E | Testdaten prüfen (Stichproben, Freigabetests) | 4 | C | | F | Gesamtfreigabe Pilot (Präsentation, Abnahmeerklärung) | 2 | D, E | #### Schritt 1 — Vorwärtsrechnung (früheste Termine) > **Rechenweg ES und EF** > > Vorgang A (kein Vorgänger): ES = 0 EF = 0 + 3 = 3 > Vorgang B (Vorgänger A): ES = EF(A) = 3 EF = 3 + 4 = 7 > Vorgang C (Vorgänger A): ES = EF(A) = 3 EF = 3 + 2 = 5 > Vorgang D (Vorgänger B): ES = EF(B) = 7 EF = 7 + 5 = 12 > Vorgang E (Vorgänger C): ES = EF(C) = 5 EF = 5 + 4 = 9 > Vorgang F (Vorgänger D und E): ES = max(EF D, EF E) = max(12, 9) = 12 > EF = 12 + 2 = 14 > > Projektende (frühestens) = max(EF) = EF(F) = 14 Wochen > Lesart: F kann frühestens starten, wenn *beide* Vorgänger fertig sind — D endet bei 12, E bei 9, also wartet F eine Woche auf D. Diese eine Zeile max(12, 9) = 12 ist der gesamte Trick der Vorwärtsrechnung. #### Schritt 2 — Rückwärtsrechnung (späteste Termine) > **Rechenweg LS und LF (Start beim Projektende 14)** > > Vorgang F (Projektende): LF = 14 LS = 14 − 2 = 12 > Vorgang D (Nachfolger F): LF = LS(F) = 12 LS = 12 − 5 = 7 > Vorgang E (Nachfolger F): LF = LS(F) = 12 LS = 12 − 4 = 8 > Vorgang B (Nachfolger D): LF = LS(D) = 7 LS = 7 − 4 = 3 > Vorgang C (Nachfolger E): LF = LS(E) = 8 LS = 8 − 2 = 6 > Vorgang A (Nachfolger B und C): LF = min(LS B, LS C) = min(3, 6) = 3 > LS = 3 − 3 = 0 > Lesart: A darf spätestens bei Woche 3 enden — nicht weil A selbst eng wäre, sondern weil der Nachfolger B (kritisch) bei 3 starten muss. min(3, 6): der strengste Nachfolger schlägt zu. #### Schritt 3 — Puffer und kritischer Pfad > **Gesamtpuffer GP = LS − ES** > > A: 0 − 0 = 0 → kritisch > B: 3 − 3 = 0 → kritisch > C: 6 − 3 = 3 → 3 Wochen Puffer > D: 7 − 7 = 0 → kritisch > E: 8 − 5 = 3 → 3 Wochen Puffer > F: 12 − 12 = 0 → kritisch > > Kritischer Pfad: A → B → D → F mit 3 + 4 + 5 + 2 = 14 Wochen > Sekundärpfad: A → C → E →(F) mit 3 + 2 + 4 = 9 Wochen + 5 Wochen Warte-/Pufferzeit *Abbildung (nur in der HTML/PDF-Fassung): Abb. 2.3 — Netzplan Phase 2 mit ES/D/EF und LS/GP/LF je Knoten. Der kritische Pfad ist rot; graue Knoten tragen 3 Wochen Gesamtpuffer.* > **Sensitivitätsprobe: Was passiert, wenn C 6 statt 2 Wochen dauert?** > > Neu: ES(C) = 3, EF(C) = 9 → E startet bei 9, endet 13 > F startet bei max(EF D = 12, EF E = 13) = 13, endet 15 > Projektende: 15 Wochen (+1) > Der bisherige 3-Wochen-Puffer von C/E ist aufgebraucht und der Nebenweg wird kritisch. Lehre: Ein Vorgang wird nie „auf dem Papier“ kritisch — er wird es durch Verbrauch von Puffer. Deshalb Pufferverbrauch im Bericht ausweisen (Teil 6.1). > **Typische Fehler** > > min/max-Regeln vertauschen (Vorwärts max, Rückwärts min); Puffer als „Reservezeit je Vorgang“ dem Team geschenkt statt zentral gesteuert; Vergessen, dass mehrere Enden existieren (hier nur F — bei mehreren Endknoten an jedem rechnen); Netzplan nach jeder Änderung nicht neu gerechnet. Rechnerisch prüfen: Netzplantechnik folgt denselben max/min-Regeln, die der EVA-Rechner in Teil 3 für kumulierte Werte nutzt — → Direkt rechnen: EVA-Rechner ### 2.5 Meilensteine planen **Was ist es?** Punkte vonnullter Dauer mit *objektiv prüfbarem* Abschlusskriterium. Meilensteine sind die Zeitpunkte, an denen Steuerung sichtbar wird (LA-Sitzungen, Zahlungen, Abnahmen). **Meilensteine „E-Akte 2026“ (Auszug)** | Meilenstein | Prüfkriterium (Auszug) | Termin | Typ | | --- | --- | --- | --- | | MS1 Konzept/Charta genehmigt | LA-Beschluss liegt unterschrieben vor | 31.01.2026 | Pflicht | | MS2 Pilotmigration technisch fertig | 8.000 Akten importiert, Fehlerquote < 0,5 % | Woche 12 der Phase 2 | Pflicht | | MS3 Pilot freigegeben | Abnahmeerklärung Bauamt + Freigabetests E bestanden | Woche 14 der Phase 2 | Pflicht | | MS4 Verlängerter Betrieb | 30 Tage stabil, Service-Desk-Tickets < 10/Monat | +6 Wochen nach MS3 | optional | > **Typische Fehler** > > Meilensteine ohne Kriterium („Schulung gemacht“); zu viele (LA verliert Blick); Datum-Meilensteine ohne Vorgänger im Netzplan, die „gefühlte“ Termine erzeugen. Trend der Meilensteintermine überwacht die Meilensteintrendanalyse (Teil 4.4). ### 2.6 Anforderungen gewichten: MoSCoW **Was ist es?** Priorisierung in **M**uss (Lieferung ohne Muss gilt als Misserfolg), **S**oll (wichtig, Ersatz möglich), **K**ann (nice-to-have), **W**on't-this-time (bewusst diesmal nicht). Regel: Die Muss-Anforderungen müssen allein, innerhalb des Budgets, lieferbar sein — sonst ist der Umfang zu groß. | Prio | Beispiel „E-Akte 2026“ | Steuerungswirkung | | --- | --- | --- | | Muss | 8.000 Altakten suchbar; Aktenplan-Kopplung; 3 Ämter； Datenschutzfreigabe | Basline-fest, Änderung nur per Change Request | | Soll | Mobile Ansicht; Volltextsuche über Anhänge | Erste Kandidaten für Abstraktion bei Termindruck | | Kann | automatische Vorschlagssfunktionen, dunkles Design | Nur wenn Sprintkapazität übrig (Velocity-Puffer) | | Won't | Kommunikationsschnittstelle zum Sitzungsdienst | Dokumentiert, verhindert Scope Creep | > **Typische Fehler** > > 80 % Muss (dann keine Priorisierung); Muss ohne Kostenklärung; Won't-Liste fehlt und jede Idee frisst Puffer. ### 2.7 Schätzverfahren **Verfahren im Vergleich (Genauigkeit steigt mit Detailwissen)** | Verfahren | Prinzip | Typische Genauigkeit | Aufwand | Einsatz | | --- | --- | --- | --- | --- | | Expertenschätzung | Erfahrene schätzen einzeln, Abweichungen werden diskutiert (Delphi-Kernidee: anonym, iterativ) | −25 % bis +75 % (Größenordnung) | gering | frühe Phase, grobe Budgetrahmen | | Analogieschätzung | vergleichbares Vorhaben als Anker, Zuschlag für Unterschiede | −15 % bis +30 % | gering | wenn ähnliche Projekte vorliegen | | Parametrische Schätzung | Kennzahl × Menge (Euro je Einheit) | −10 % bis +20 % | mittel | wiederholte gleichartige Leistungen | | Dreipunkt/PERT | optimistisch (O), realistisch (M), pessimistisch (P), gewichteter Erwartungswert | ±1σ je Güte der O/P-Schätzung | mittel | Vorgangsschätzung im Netzplan | | Bottom-up | Summe der Arbeitspakete aus dem Strukturplan | −5 % bis +10 % | hoch | Baselining, Vertragspreise | **Dreipunkt/PERT-Formeln** ``` Erwartungswert: E = (O + 4·M + P) ÷ 6 Standardabweichung: σ = (P − O) ÷ 6 Projekt (nur kritischer Pfad): σProjekt = √( σA² + σB² + … ) ``` *O best case (alles klappt) · M realistisch-häufigster Fall · P worst case (ohne Katastrophe). Beta-Verteilung: der realistische Fall zählt vierfach.* > **Durchgerechnet: Vorgang B („DMS einrichten“) und der kritische Pfad** > > Schätzung B: O = 3 Wochen, M = 4 Wochen, P = 9 Wochen > E(B) = (3 + 4·4 + 9) / 6 = (3 + 16 + 9) / 6 = 28 / 6 ≈ 4,67 Wochen > σ(B) = (9 − 3) / 6 = 1,0 Woche > > Kritischer Pfad A–B–D–F, Dreipunktschätzungen: > A: O 2 / M 3 / P 4 → σ(A) = (4−2)/6 ≈ 0,33 E(A) = 3,00 > B: σ(B) = 1,00 E(B) = 4,67 > D: O 4 / M 5 / P 8 → σ(D) = (8−4)/6 ≈ 0,67 E(D) = (4+20+8)/6 = 5,33 > F: O 1 / M 2 / P 3 → σ(F) = (3−1)/6 ≈ 0,33 E(F) = 2,00 > > Erwartete Pfadlänge = 3,00 + 4,67 + 5,33 + 2,00 ≈ 15,0 Wochen > σ(Projekt) = √(0,33² + 1,00² + 0,67² + 0,33²) = √1,67 ≈ 1,29 Wochen > > Zusage nach Draufschlagen: 15,0 + 1,29 ≈ 16,3 Wochen ≈ P84 > → nach außen 16–17 Wochen zusagen, intern 15 steuern > Lesart: Die deterministische Dauer im Netzplan (Teil 2.4) lautete 14 Wochen; die PERT-Rechnung mit unscharfen Vorgängen erwartet 15 und empfiehlt, mit rund +1σ zu planen. Der Unterschied ist kein Widerspruch, sondern Risiko-Kapital: Genau dafür gibt es Reserven (Teil 5.6). > **Durchgerechnet: parametrische Schätzung des Scannens** > > Vorjahr „Scan-Teilprojekt Stadtwerke“: 2.500 Akten für 9.500 € > → Kennzahl 3,80 € je Akte (Scan + Barcodierung + Einlagerung) > „E-Akte 2026“: 8.000 Akten × 3,80 € = 30.400 € > Zuschlag schwankende Aktenlagen (+20 %): 36.500 € gerundet > Kennzahlenschätzung ersetzt keine Detailplanung, aber sie ist ein starker Plausibilitätscheck: Weicht die Bottom-up-Summe um mehr als ±30 % von der Analogie ab, liegt meist ein Struktur- oder Aufwandsfehler vor. > **Typische Fehler** > > Schätzen in Sitzungen unter Anwesenheit von Vorgesetzten (Anker- und Autoritätseffekt); P als „unendlich schlimm“ angeben (σ explodiert); Schätzung mit Budget verwechseln — Schätzung wird erst mit Reserven (5.6) zum Budget; keine Abgleichsrechnung zwischen Verfahren. ### 2.8 Kapazität und Ressourcenabgleich — gerechnet **Was ist es?** Gegenüberstellung von *benötigtem* Aufwand (aus den Arbeitspaketen) und *verfügbarer* Kapazität (realistisch, nach Abzug von Urlaub, Krankheit und Linie). Erst danach weiß man, ob der Netzplan mit Menschen begehbar ist. **Kapazitätsformeln** ``` Nettoverfügbarkeit = Bruttotage × Anteil Projekt × Faktor netto Kapazitätslücke = Bedarf − interne Nettoverfügbarkeit (=> externe Beschaffung) ``` *Faktor netto deckt Urlaub, Krankheit, Fortbildung, Linie: Erfahrungswert 0,75–0,85. Mit 100 % zu planen ist der häufigste Kapazitätsfehler überhaupt.* > **Phase 2 „Migration“: 14 Wochen, Bedarf 180 Personentage (PT)** > > Bruttotage im Zeitraum: 14 Wochen × 5 Tage = 70 AT > > Intern verfügbar (Faktor netto 0,8): > 2 Key-User à 60 % Projektanteil: 2 × 70 × 0,60 × 0,8 = 67,2 PT > Projektleitung 50 %: 70 × 0,50 × 0,8 = 28,0 PT > Intern gesamt: = 95,2 PT > > Kapazitätslücke: 180 − 95,2 = 84,8 → 85 PT Dienstleister > Externe Kosten: 85 PT × 480 €/PT = 40.800 € (Kernstück der Phasenkosten 52.000 €) > Probe gegen Phase 2 des Strukturplans (52.000 €): 40.800 € extern + interne anteilige Kosten + Sachkosten (Scanner, Testgeräte) ergibt die Phase — die Kapazitätsrechnung ist damit zugleich eine Plausibilitätsprüfung der Kostenschätzung. **Ressourcenabgleich (Leveling):** Überlastet eine Person zwei Vorgänge gleichzeitig, wird verschoben — liegt Puffer auf dem Weg, verschiebt sich nur *innerhalb* des Projekts (Glättung); ohne Puffer verschiebt sich das Projektende, und der Netzplan muss neu gerechnet werden. Beispiel: Die beiden Key-User sind in Woche 5–9 gleichzeitig für C (Bereinigung) und E (Testdaten) eingeplant. Im Netzplan aus 2.4 laufen C und E parallel — Lösung: E beginnt bedarfsgerecht nach den ersten Migrationschargen (dann sequentialisiert sich die Arbeit von selbst), oder eine Aufgabe weicht auf die im 1.6 genannte Vertretung aus. > **Typische Fehler** > > Netto mit Brutto verwechseln („6 Wochen Zeit, also 6 Wochen Arbeit“); Kapazität über Rollen statt Personen planen (Rollen haben keine Urlaubsplanung); Abgleich nur einmal zur Baseline statt bei jeder Netzplanänderung; Überlast per Überstunde „lösen“ und die Mehrkosten nicht in AC sichtbar machen. ## Teil 3: Earned-Value-Analyse (EVA) — das Herzstück der Steuerung Die Earned-Value-Methode verbindet Umfang, Termin und Kosten in einem Kennzahlensystem. Dieses Teil enthält die Grundgrößen, alle Formeln mit Interpretationssätzen und ein durchgängiges Großbeispiel (BAC 120.000 €, 8 Monate), das über vier Monate vollständig durchgerechnet wird — plus die ehrliche Antwort, wann EVA nichts taugt. Alle Zahlen dieses Teils live nachrechnen: → Direkt rechnen: EVA-Rechner ### 3.1 Grundgedanke **Was ist es?** EVA bewertet die *erbrachte Leistung* zu *Planpreisen* und macht sie so mit Plankosten und Istkosten vergleichbar. Die Kernfrage lautet nicht „Wie viel Geld ist weg?“, sondern „Was haben wir für das Geld bekommen — und was hätten wir bis heute bekommen sollen?“ **Wofür?** Klassische Abweichungsanalyse (Istkosten vs. Budget) verwechselt Fortschritt mit Geldverbrauch: Wer teuer schnell baut, sieht „Kostenüberschreitung“, obwohl der Termin glänzt; wer langsam spart, wirkt gesund, während der Termin kippt. EVA trennt beides in zwei Indizes: SPI für Termin, CPI für Kosten. **So geht's (monatlich):** (1) Baseline mit wertmäßiger Verteilung festlegen (PV-Kurve) · (2) Fertigstellungsgrade der Arbeitspakete erheben → EV · (3) Istkosten je Arbeitspaket zuordnen → AC · (4) Kennzahlen berechnen (3.5) · (5) Prognosen und Steuerungsmaßnahmen (3.6–3.7). ### 3.2 Die vier Basisgrößen: BAC, PV, EV, AC **BAC — Budget at Completion** : Das genehmigte Gesamtbudget der Leistungsbasis („wie viel kostet das Projekt insgesamt, laut Plan“). Im Beispiel: 120.000 €. Die wertmäßige Verteilung des BAC über die Zeit ist die Performance Measurement Baseline. **PV — Planned Value (Planwert)** : Wert der laut Baseline bis zum Stichtag geplant fertigzustellenden Arbeit, bewertet zu Plankosten. Im Beispiel Ende Monat 4: 60.000 € (halbes Projekt — die Verteilung folgt der S-Kurve, nicht dem Kalender). **EV — Earned Value (Fertigstellungswert)** : Wert der tatsächlich fertiggestellten Arbeit, bewertet zu Plankosten. Ende Monat 4 im Beispiel: 50 % des BAC sind nachweislich erbracht → 50.000 €. Der EV ist die eigentliche Erfindung der Methode: Leistung wird planpreisig gemessen und damit von Einkaufspreisen und Verbrauchstempo entkoppelt. **AC — Actual Cost (Istkosten)** : Die tatsächlich angefallenen Kosten für die geleistete Arbeit. Ende Monat 4 im Beispiel: 57.000 €. **Fertigstellungsgrad je Arbeitspaket — die gängigen Verfahren** ``` 0/100-Regel: Paket zählt erst mit Fertigstellung (kleine Pakete) 50/50-Regel: halber Wert bei Beginn, Rest bei Fertigstellung Mengenanteilig: EV = BAC-Anteil × (Istmenge ÷ Planmenge), z. B. 3.200 von 8.000 Akten → 40 % des Pakets Schätzung verbleibender Restaufwand (nur mit erfahrenen Schätzern) ``` *Faustregel zur Objektivierung: kleine Pakete 0/100, mittlere 50/50, große mengenorientiert. Subjektive Restschätzungen sind die größte Manipulationsquelle in der EVA.* ### 3.3 Die S-Kurve lesen Trägt man kumulierte Werte über der Zeit ab, entsteht die typische S-Kurve: langsamer Start (Mobilisierung), steile Mitte (serielle Vollast), flacher Auslauf (Abnahme). Drei Kurven — PV als graue Planlinie, EV und AC als Ist — erzählen in einem Bild, wo das Projekt steht: *Abbildung (nur in der HTML/PDF-Fassung): Abb. 3.1 — S-Kurve „E-Akte 2026“ zum Stichtag Ende Monat 4. Grau die Baseline (PV), rot die Ist-Leistung (EV), anthrazit die Istkosten (AC), rot gekappt gestrichelt die Earned-Value-Fortschreibung bis BAC.* > **Warum die Verteilung keine Gerade ist: der Monatsplan der PV** > > | Monat | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Σ | > | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | > | PV-Zuwachs (T€) | 6 | 14 | 20 | 20 | 20 | 18 | 14 | 8 | **120** | > | PV kumuliert (T€) | 6 | 20 | 40 | 60 | 80 | 98 | 112 | 120 | | > > Die Verteilung folgt dem Strukturplan und dem Netzplan (Teil 2): wenig Wert im Januar (Analyse), Vollast Mitte (Migration), Auslauf mit Abnahme im August. Praktisch leitet man die Monats-PV aus den geplanten Fertigstellungen der Arbeitspakete ab — wer „linear über 8 Monate“ plant, hat meist keinen belastbaren Plan. > **Typische Fehler** > > PV „nach Kalender“ statt nach Planleistung; EV über Fortschritt von Balken („Vorgang 80 % fertig“ ohne Messregel); AC ohne Abgrenzung (z. B. Bestellungen erfasst, Lieferungen nicht, oder umgekehrt); Stichtage von PV und AC klaffen auseinander. #### Herleitung des EV aus Arbeitspaketen — vollständig gerechnet (Stichtag M4) Der Fertigstellungswert entsteht nicht am Schreibtisch, sondern Paket für Paket. Die Tabelle zeigt die Erhebung zum 30.04.2026 — mit Messregel, geplantem Anteil (PV) und geleistetem Anteil (EV). Sie ist zugleich der Beleg für die Basiswerte des Großbeispiels (PV 60.000 / EV 50.000): **EV-Erhebung E-Akte 2026, Stichtag 30.04.2026 (Werte in T€)** | Paket / Phase | BAC-Anteil | Messregel | Fertig | PV (plan) | EV (ist) | | --- | --- | --- | --- | --- | --- | | Phase 1 Vorbereitung | 18 | 0/100 je AP (klein) | 100 % | 18 | 18 | | 2 · A Analyse Altakten | 6 | 0/100 (Abnahme Analyse) | 100 % | 6 | 6 | | 2 · B DMS einrichten | 12 | Meilenstein-abhängig (Installationsfreigabe) | 100 % | 12 | 12 | | 2 · C Altdaten bereinigen | 8 | mengenanteilig (Dubletten-Quote) | 100 % | 8 | 8 | | 2 · D Migration durchführen | 16 | **mengenanteilig: 3 von 8 Chargen = 37,5 %** | 37,5 % | 16 | 6 | | 2 · E Testdaten prüfen | 7 | 0/100 je Testpaket | 0 % | 0 | 0 | | 2 · F Freigabe Pilot | 3 | 0/100 (Abnahmeerklärung) | 0 % | 0 | 0 | | Phasen 3–5 (ab Mai geplant) | 50 | — | — | 0 | 0 | | **Summe** | **120** | | | **60** | **50** | ``` Probe: PV = 18 + 6 + 12 + 8 + 16 = 60 T€ (bis Ende April war Phase 1 und die AP A–D fällig) EV = 18 + 6 + 12 + 8 + 6 = 50 T€ (D nur 37,5 % von 16 T€ = 6 T€) → SPI = 50 / 60 = 0,833 · mit AC 57 T€ → CPI 0,877 (wie in 3.5) ``` Der gesamte Rückstand steckt hier in *einer* Zeile: Von der Migration (D) waren zum Stichtag 8 Chargen à 2 T€ geplant fertig — geleistet wurden 3. Damit ist die Kennzahl bereits Ursachenanalyse: Kein diffuses „Projekt im Verzug“, sondern „Migration hinkt 5 Chargen (10 T€ Wert) hinter dem Plan“ — exakt der SV von −10.000 € aus 3.4. Genau diese Rückrechnung Kennzahl → Arbeitspaket macht EVA im Lenkungsausschuss überzeugend. Zeitliche Einordnung: In der Monats-Baseline (3.3) sind Prüfpakete (E) und Freigabe (F) für Mai/Juni angesetzt, weil die Tests erst nach den ersten Migrationschargen sinnvoll laufen. Der 14-Wochen-Netzplan aus 2.4 zeigt die *logische Verkettung* der Phase (wer hängt von wem ab, wo ist Puffer) — nicht die Kalenderverteilung des Gesamtprojekts. Beide Ebenen braucht man: die Logik im Detailplan, die Wertverteilung in der Baseline. ### 3.4 Abweichungen: SV und CV **Schedule Variance / Cost Variance** ``` SV = EV − PV (Termintreue in Euro) CV = EV − AC (Kostentreue in Euro) ``` *Negativ = hinter dem Plan / über Budget. Null = auf Plan. Die Einheit ist Euro, nicht Zeit: SV = −10.000 € heißt „10.000 € geplante Leistung fehlen“, nicht „x Wochen Verspätung“.* **Interpretationssätze.** SV < 0: Bis zum Stichtag wurde weniger geleistet als geplant — Ursache klären (Kapazität? Verfügung? Blocker beim Vorgänger?). CV < 0: Die geleistete Arbeit kostete mehr als geplant — Ursache klären (Stundenüberschreitung? Teuerere Beschaffung? Nacharbeit?). Beide zusammen zeigen die Lage im S-Kurven-Bild als Fläche zwischen den Kurven. > **Großbeispiel, Monatswerte M1 bis M4 (T€)** > > | Stichtag | PV | EV | AC | SV = EV−PV | CV = EV−AC | > | --- | --- | --- | --- | --- | --- | > | Ende M1 | 6 | 4 | 5 | −2 | −1 | > | Ende M2 | 20 | 16 | 19 | −4 | −3 | > | Ende M3 | 40 | 34 | 40 | −6 | −6 | > | Ende M4 (Stichtag) | 60 | 50 | 57 | **−10** | **−7** | > > Ende M4: SV = 50.000 − 60.000 = −10.000 € > CV = 50.000 − 57.000 = −7.000 € > Zur Story: M1 Anlauf (Schulung des Teams verzögert), M2 hängt die DMS-Einrichtung am Freigabeprozess, M3 Kompensation durch Dienstleister-Überstunden (daher AC-Sprung: Leistung gekauft), M4 Nacharbeit an der Aktenplan-Kopplung. SV wächst trotz allem — der Rückstand kumuliert. ### 3.5 Indizes: SPI und CPI **Schedule / Cost Performance Index** ``` SPI = EV ÷ PV · 1,00 = planmäßig · <1 = im Rückstand · >1 = voraus CPI = EV ÷ AC · 1,00 = kostenplanmäßig · <1 = Mehrkosten je geleisteter Einheit ``` *Indizes sind im Gegensatz zu SV/CV größenunabhängig und damit projektübergreifend und über die Zeit vergleichbar — CPI 0,88 bedeutet: Für 1 € Wert gibt das Projekt aktuell 1,14 € aus.* > **Großbeispiel, alle vier Monate durchgerechnet** > > | Stichtag | SPI = EV/PV | CPI = EV/AC | Rechnung M4 | > | --- | --- | --- | --- | > | Ende M1 | 4/6 = **0,667** | 4/5 = **0,800** | SPI = 50.000 / 60.000 = 0,833 CPI = 50.000 / 57.000 = 0,877 | > | Ende M2 | 16/20 = **0,800** | 16/19 = **0,842** | | > | Ende M3 | 34/40 = **0,850** | 34/40 = **0,850** | | > | Ende M4 | **0,833** | **0,877** | | > > **Interpretationssätze:** SPI 0,833 — „Das Projekt liefert mit 83 % der geplanten Termintreue; ohne Gegenmaßnahme wächst der Rückstand weiter.“ CPI 0,877 — „Je ausgegebenem Euro entsteht nur 88 Cent Wert; hält das an, kostet das Projekt rund 16.800 € mehr als geplant“ (siehe EAC in 3.6). Wichtig ist die *Tendenz*: CPI erholte sich von 0,842 auf 0,877, der SPI fiel wieder auf 0,833 — Kosten stabilisieren sich, der Termin nicht. ### 3.6 Prognosen: EAC, ETC, VAC **Estimate at Completion / To Complete / Variance at Completion** ``` EAC = BAC ÷ CPI (Standard: bisherige Kosteneffizienz hält an) ETC = EAC − AC · VAC = BAC − EAC ``` *EAC Endkostenprognose · ETC erwarteter Restaufwand · VAC erwartete Gesamtabweichung (negativ = Mehrkosten). Weitere EAC-Varianten in 3.10.* > **Großbeispiel M4: Prognose in drei Schritten** > > EAC = BAC / CPI = 120.000 / 0,8772 = 120.000 × 57 / 50 = 136.800 € > ETC = EAC − AC = 136.800 − 57.000 = 79.800 € (Restwert-Annahme: Effizienz bleibt) > VAC = BAC − EAC = 120.000 − 136.800 = −16.800 € (erwartete Mehrkosten) > **Interpretationssatz:** „Bei unverändertem CPI liegt die Endkostenprognose 14 % über dem Budget; der Fehlbetrag von 16.800 € übersteigt meine Entscheidungsgrenze von 10 % — der Lenkungsausschuss muss entscheiden: Umfang kürzen (MoSCoW-Kandidaten), Budget erhöhen oder Qualitätsoption bewerten.“ Genau das ist der Übergang von Kennzahl zu Steuerung (Teil 6). ### 3.7 TCPI — der Preis der Rettung **Was ist es?** Der To-Complete Performance Index sagt, welche Kosteneffizienz der *Rest* des Projekts bräuchte, um doch noch im Budget (oder in einer neuen Obergrenze) zu landen. Er ist die ehrlichste Zahl der EVA, weil sie Wünsche in benötigte Leistung übersetzt. **TCPI-Formeln** ``` Auf BAC: TCPI = (BAC − EV) ÷ (BAC − AC) Auf EAC: TCPIEAC = (BAC − EV) ÷ (EAC − AC) ``` *Restwert ÷ Restgeld. TCPI > 1: Der Rest muss besser laufen als alles bisher. TCPI ≤ CPI: unrealistisch — bisherige Effizienz reicht nicht mal fürs Ziel.* > **Großbeispiel M4: Was müsste das Team jetzt leisten?** > > TCPI(BAC) = (120.000 − 50.000) / (120.000 − 57.000) > = 70.000 / 63.000 = 1,111 > > Vergleich: CPI bisher = 0,877 → Sprung von 0,877 auf 1,111 (+26 %) > > TCPI(EAC) = 70.000 / (136.800 − 57.000) = 70.000 / 79.800 = 0,877 > **Interpretationssatz:** „Um im BAC zu bleiben, müssten die verbleibenden 70.000 € Restwert mit nur 63.000 € Restbudget erbracht werden — Kosteneffizienz 1,111 statt bisher 0,877. Teams steigern ihre Effizienz realistisch um 5–10 %, nicht um 26 %. Anspruch: Budget halten = nicht plausibel. Alternative: EAC-Budget genehmigen — dann genügt die bisherige Effizienz (TCPI 0,877).“ Faustregel: TCPI > 1,10 gilt als Alarmschwelle; Abgleich TCPI vs. CPI zeigt Realismus. > **Typische Fehler** > > SV/CV in Wochen umdeuten wollen (dafür gibt ES/SPI(t), siehe 3.11); Indizes einzeln ohne Trend betrachten; EAC als Zusicherung statt Bandbreite kommunizieren; TCPI ignorieren und „das Team strengt sich jetzt mehr an“ als Steuerungsmaßnahme verkaufen. ### 3.8 Das Großbeispiel als Monatsreport — alle Kennzahlen auf einen Blick > **E-Akte 2026 · EVA-Monatswerte (Basis BAC 120.000 €)** > > | Stichtag | Basisgrößen (T€) | Abweichungen (T€) | Indizes | Prognose (T€) | TCPI (BAC) | > | --- | --- | --- | --- | --- | --- | > | PV | EV | AC | SV | CV | SPI | CPI | EAC | ETC | VAC | | > | Ende M1 | 6 | 4 | 5 | −2 | −1 | 0,667 | 0,800 | 150,0 | 145,0 | −30,0 | 1,009 | > | Ende M2 | 20 | 16 | 19 | −4 | −3 | 0,800 | 0,842 | 142,5 | 123,5 | −22,5 | 1,030 | > | Ende M3 | 40 | 34 | 40 | −6 | −6 | 0,850 | 0,850 | 141,2 | 101,2 | −21,2 | 1,075 | > | Ende M4 | 60 | 50 | 57 | −10 | −7 | 0,833 | 0,877 | 136,8 | 79,8 | −16,8 | 1,111 | > > **Zwei gegenläufige Bewegungen — das ist die eigentliche Lektion:** Die Prognose EAC *verbessert* sich von 150.000 auf 136.800 € (CPI erholt sich), während TCPI *steigt* von 1,009 auf 1,111 — weil mit jedem Monat Restbudget verbraucht wird, wird „im Budget bleiben“ immer unwahrscheinlicher. Wer nur EAC meldet, wirkt optimistisch; wer TCPI mitmeldet, bleibt ehrlich. ### 3.9 Wie lese ich die Zahlen? Entscheidungshilfe mit Schwellenwerten Schwellen sind conventions — sie müssen vorab mit dem Auftraggeber vereinbart und in die Berichtskultur geschrieben werden (Teil 6.2 RAG). Bewährtes Raster für Verwaltungs- und Mittlere-Projekte: **Ampelschwellen für SPI/CPI (Vorschlag, an Organisation anpassen)** | Status | SPI und CPI | Bedeutung | Standardhandlung | | --- | --- | --- | --- | | grün | ≥ 0,97 | im Toleranzband | weiterlaufen, Trend beobachten | | gelb | 0,90 – 0,97 | systematische Abweichung | Ursachenanalyse am Vorgang, Mikromaßnahmen im Team, im Bericht benennen | | orange | 0,85 – 0,90 oder zweimal gelb in Folge | Steuerung greift nicht | Maßnahmenplan mit Terminen, TCPI-Realismusprüfung, LA-Information | | rot | < 0,85 oder TCPI > 1,10 | Ziele gefährdet | Eskalation (6.3): Entscheidung Umfang/Budget/Termin, ggf. Rebaselining nur mit Beschluss | > **Konkret: SPI 0,83 im Projekt — die ersten fünf Handgriffe** > > Merksatz: **Budget erschöpft oder TCPI > 1,10 ist keine Lagemeldung mehr, sondern eine Eskalation.** ### 3.10 EAC-Varianten — vier Annahmen, vier Endkosten **EAC-Formeln nach Annahme** ``` A · Rest läuft planmäßig: EAC = AC + (BAC − EV) B · Kosteneffizienz hält an (Standard): EAC = BAC ÷ CPI C · Kosten- UND Terminabweichung schlagen durch: EAC = AC + (BAC − EV) ÷ (CPI × SPI) D · Bottom-up: EAC = AC + neuer Restaufwand (neu geschätzt) ``` > **Alle Varianten am Stichtag M4** > > A EAC = 57.000 + (120.000 − 50.000) = 57.000 + 70.000 = 127.000 € > B EAC = 120.000 / 0,8772 = 136.800 € > C EAC = 57.000 + 70.000 / (0,8772 × 0,8333) > = 57.000 + 70.000 / 0,7310 = 57.000 + 95.760 = 152.760 € > D Bottom-up: Restpakete neu geschätzt (Migration +5 T€, Test +6 T€, > Rollout +4 T€, Rest planmäßig) ≈ 143.000 € > > Spannweite: 127.000 € (hoffnungsvoll) bis 152.800 € (pessimistisch) > Berichtswert: Bandbreite nennen, B als Leitprognose, C als Worst Case > Wann welche: A nach einmaligem, abgestelltem Sonderereignis (z. B. Startverzug). B als Standardannahme ab ca. 20 % Fortschritt — empirisch stabil. C wenn Termin- und Kostenprobleme dieselbe Ursache haben (z. B. Nacharbeit: kostet Geld UND Zeit). D bei Strukturbrüchen (neue Erkenntnis über den Rest) oder ab 60 % Fortschritt einmal jährlich validieren. ### 3.11 Grenzen der EVA — ehrlich - **EV ist nur so objektiv wie die Fertigstellungsgrade.** Subjektive Restschätzungen sind die Hauptquelle schöner Zahlen; Abhilfe: Messregeln (0/100, mengenanteilig) und Stichprobenprüfungen. - **Qualität ist unsichtbar.** EV zählt auch schlecht erbrachte Arbeit. EVA ohne Abnahme- und Qualitätskennzahlen belohnt Pfusch bis zur Abnahme. - **SPI läuft gegen 1, egal was passiert.** Am Projektende ist per Definition EV = BAC = PV → SPI = 1, auch wenn der Termin um Monate gerissen wurde („falsche Erholung“). Abhilfe: Earned Schedule (ES) — Umrechnung von EV in erreichte Planzeit: ES = Zeitpunkt, an dem die PV-Kurve den aktuellen EV erreicht; SPI(t) = ES ÷ tatsächliche Zeit bleibt am Ende ehrlich unter 1. - **Frühphase ist Rauschen.** CPI/SPI im ersten Fünftel schwanken stark (kleine Nenner); erst ab ~15–20 % Fortschritt trägt die Prognose. - **Rebaselining löscht Spuren.** Jede neue Baseline setzt Abweichungen auf null — ohne Dokumentation der alten Werte verschwindet die Lernkurve. Alte Baselines archivieren. - **Kleinprojekte:** Unter ~3 Monaten oder ~20.000 € übersteigt der Erhebungsaufwand den Nutzen; dann reicht Meilensteintrend + Budgetverbrauch. - **Öffentliche Haushalte:** AC-Zuordnung über Kostenstellen/Haushaltsjahre kann Verzerrungen erzeugen (Bestellungen vs. Mittelabfluss) — Erhebungsregel mit Kämmerei abstimmen. - **EVA erklärt nichts.** Sie zeigt *dass* etwas abweicht; das *warum* liefert nur die Arbeit am Vorgang. Zahlen ersetzen keine Projektleitung. > **Praxisempfehlung** > > EVA nie allein steuern: kombinieren mit Meilensteintrendanalyse (4.4, Termingefühl, Pufferverbrauch aus dem Netzplan (2.3) und Risiko-Triggern (5.7). Diese Viererkombination ist robust gegen jede einzelne Schwäche. ## Teil 4: Burndown, Velocity und Trend: Steuerung in Kurven EVA misst wertmäßig, Burndown misst Restaufwand, Velocity misst Lieferfähigkeit, Trendanalysen messen die Richtung. Zusammen decken sie ab, was einzelne Kennzahlen übersehen: dass Projektsteuerung die Steuerung von *Bewegungen* ist, nicht von Momentaufnahmen. Verläufe selbst erzeugen: → Direkt rechnen: Burndown-Demo und Meilenstein-Trend-Check ### 4.1 Das Burndown-Chart **Was ist es?** Linienchart des *verbleibenden* Aufwands (Story Points, Stunden, Pakete) über der Zeit. Die Soll-Linie fällt linear zum Ziel; die Ist-Linie zeigt, wie viel wirklich übrig bleibt. Abweichungen und Schnittpunkt-Prognosen sind auf einen Blick lesbar. **Wofür?** Sprint- und Release-Steuerung: Werden wir fertig? Was ist die realistische Restdauer? Wirkt eine Maßnahme? Im klassischen Umfeld analog als „Restwert-Burndown“ über Arbeitspakete nutzbar. *Abbildung (nur in der HTML/PDF-Fassung): Abb. 4.1 — Burndown Sprint 7 der „E-Akte 2026“-Schulungspakete. Die Ist-Kurve liegt ab Tag 2 durchgehend über der Soll-Linie; die Fläche zwischen den Kurven ist der aufgelaufene Rückstand.* > **Typische Fehler** > > Restaufwand „gefühlt“ statt aus Task-Status; Kurve nur samstags (vor dem Review) aktualisieren — dann steuert sie nicht; teamfremde Skala (Stunden vs. Punkte mischen). ### 4.2 Burndown auswerten — das Beispiel gerechnet > **Sprint 7: Wird der Sprint-Plan gehalten?** > > Start: 200 SP · Sprintlänge: 10 Arbeitstage · Soll: 20 SP/Tag > Ist-Tagesleistung (Rest-Differenzen): 12, 10, 6, 12, 10, 22, 16, 17, 25, 22 SP > > Durchschnitt gesamt: (200 − 48) / 10 = 15,2 SP/Tag > Durchschnitt letzte 5 Tage: (150 − 48) / 5 = 20,4 SP/Tag (Maßnahme wirkt) > > Prognose Restdauer: 48 / 15,2 ≈ 3,2 Tage → fertig Tag 13,2 > 48 / 20,4 ≈ 2,4 Tage → fertig Tag 12,4 > Sprint endet Tag 10 → Überhang ≈ 48 SP (Bandbreite 44–50 SP) > **Entscheidung im Daily am Tag 10:** 48 SP passen nicht in den Sprint. Optionen nach MoSCoW (2.6): zwei Kann-Pakete (18 SP) zurück ins Backlog, Rest (30 SP) als erste Kandidaten für Sprint 8. Was nicht geht: stillschweigend weiterarbeiten — der Sprint-Review braucht die ehrliche Zahl, sonst frisst sich der Überhang unsichtbar durch die Release-Planung. ### 4.3 Velocity — die Lieferfähigkeit als Bereich **Was ist es?** Summe der *fertiggestellten* (nicht: begonnenen) Story Points je Sprint. Kerneinsicht: Velocity ist keine Zielzahl, sondern eine Messgröße mit Streuung — planen soll man mit einem Bereich, nicht mit einem Durchschnittswert. > **Release-Planung mit Velocity-Bereich** > > Letzte 6 Sprints: 34, 40, 38, 42, 36, 40 SP > Durchschnitt: (34+40+38+42+36+40) / 6 = 230 / 6 ≈ 38,3 SP > Bandbreite (ohne Ausreißer): 34 bis 42 SP > > Release-Rest: 120 SP (DMS-Konfiguration + Rollout-Pakete) > Optimistisch: 120 / 42 = 2,9 → 3 Sprints > Realistisch: 120 / 38,3 = 3,1 → 3 Sprints > Konservativ: 120 / 34 = 3,5 → 4 Sprints > > Zusage nach außen: 4 Sprints (P85), intern steuern gegen 3 > Wer mit dem Durchschnitt („3 Sprints“) nach außen plant, liegt in jedem zweiten Fall daneben. Monte-Carlo-Rechnungen (7.2) machen genau diesen Schluss systematisch. > **Typische Fehler** > > Velocity als Vorgabe („ab jetzt 45!“) — sie ist Messergebnis; Vergleich von Velocities zwischen Teams (Punkte sind teamspezifisch); Punkte nach Größe, aber Abnahme nach Stunden; neu zusammengesetzte Teams mit Altdurchschnitt planen. ### 4.4 Meilensteintrendanalyse (MTA) **Was ist es?** Zu jedem Berichtstermin wird für jeden Meilenstein die *aktuelle Prognose* seines Termins eingetragen. Ergibt sich über die Berichtstermine eine Kurve je Meilenstein, zeigen Steigung und Richtung die Terminentwicklung: nach oben (= immer später) = Verschlechterung, waagerecht = stabil, nach unten = Verbesserung. **Wofür?** MTA ist das deutschsprachige Gegenstück zur EVA-Terminseite: leicht verständlich, ohne wertmäßige Baseline, und im Lenkungsausschuss sofort lesbar. Sie zeigt *Trends*, bevor sie in Terminbrüchen enden. > **Beispiel E-Akte 2026 — Prognosen zu vier Berichtsterminen** > > | Meilenstein (Erstplan) | Ende Feb | Ende Mär | Ende Apr | Ende Mai | Trend | > | --- | --- | --- | --- | --- | --- | > | M1 Konzept genehmigt (KW 11) | KW 11 | KW 12 | KW 13 | KW 13 | stabil verschoben +2 Wo | > | M2 Pilotmigration fertig (KW 22) | KW 22 | KW 22 | KW 23 | KW 24 | verschlechtert sich laufend | > | M3 Schulung abgeschlossen (KW 29) | KW 29 | KW 28 | KW 28 | KW 28 | verbessert, stabil −1 Wo | > *Abbildung (nur in der HTML/PDF-Fassung): Abb. 4.2 — Meilensteintrendanalyse: M2 (rot) verschlechtert sich in jedem Bericht — der klassische „Wandern auf dem Kalender“. M3 profitiert von der abgeschlossenen Analysephase. Eine Quelle der Verzerrung: „mutige“ Erstprognosen, die politisch gewollt sind statt gerechnet.* > **Typische Fehler** > > Prognosen aus Hoffnung statt aus Netzplanrechnung; Meilensteine im Bericht „passend“ machen; Trend nur am aktuellen Bericht statt über die Historie lesen; MTA ohne Konsequenzregel (wann genau eskaliert wird). ### 4.5 Trendanalyse und Frühwarnindikatoren **Was ist es?** Systematische Betrachtung, *wohin* sich eine Kennzahl bewegt: dreiwöchige Richtung, gleitende Mittelwerte, Konstanz von Abweichungen. Eine einmalige Abweichung ist Ereignis, drei in Folge sind System. > **Beispiel: CPI-Trend lesen statt Momentwert bewerten** > > CPI-Verlauf: 0,800 → 0,842 → 0,850 → 0,877 > Richtung: steigend (+0,077 in 3 Monaten), Streuung sinkend > Lesart: Ursache (Anlaufkosten Schulung, Nacharbeit M1) wirkt nach; > Maßnahmenkette M2–M3 greift. Kein Grund zur Entwarnung (CPI < 0,97), > aber Grund, den eingeschlagenen Kurs zu halten — nicht zu eskalieren. > > Kontrast: gleicher CPI 0,877 bei Verlauf 0,950 → 0,920 → 0,890 → 0,877 > wäre ein klarer Abwärtstrend: handeln, obwohl der Wert „besser“ aussieht. **Frühwarnindikatoren (Trigger)** verbinden Kennzahl mit fester Folgeaktion, z. B.: „SPI < 0,90 in zwei aufeinanderfolgenden Berichten → Automatische Lagethema-Stellungnahme im LA“ oder „Pufferverbrauch > 50 % vor Meilenstein → Termin hochrechnen“ (mehr in 5.7). Ein Indikator ohne vereinbarte Folge ist Dekoration. ### 4.6 Burn-up: Scope-Änderungen sichtbar machen **Was ist es?** Gegenstück zum Burndown: zwei aufsteigende Kurven — Gesamtaufwand (Scope) und fertiggestellter Aufwand. Der vertikale Abstand ist der offene Rest; Änderungen am Scope erscheinen als Sprünge der Scope-Linie statt als „schlechtere Leistung“. *Abbildung (nur in der HTML/PDF-Fassung): Abb. 4.3 — Burn-up: die zwei Sprünge sind genehmigte Change Requests (6.5). Nur so lässt sich „Team wurde langsamer“ sauber von „Scope wurde größer“ trennen.* ### 4.7 Kumulierter Fluss (Cumulative Flow) — Flaschenhälse sehen **Was ist es?** Gestapelte Flächen des Backlogs über der Zeit: erledigt (unten), in Arbeit (Mitte), offen (oben). Die *Breite* des mittleren Bandes ist der Work in Progress (WIP); wächst es, arbeitet das Team mehr parallel, als es abschließen kann — der klassische Flaschenhals-Indikator. Die Steigung der unteren Kurve ist die Durchsatzrate (im Gleichgewicht identisch mit der Velocity). *Abbildung (nur in der HTML/PDF-Fassung): Abb. 4.4 — Kumulierter Fluss der Schulungsphase. Durchsatz (Steigung unten) ≈ 38 SP/Woche, konsistent mit der Velocity aus 4.3.* > **Typische Fehler** > > Zustände „in Arbeit“ ohne Statusdisziplin (Band wird zur Beliebigkeit); Diagramm ohne WIP-Grenze diskutieren; Kategorien je Sprint umbenennen (Zeitreihen brechen). ## Teil 5: Risikomanagement: erkennen, bewerten, einpreisen Risikomanagement ist die Versicherung des Plans: Risiken werden identifiziert, bewertet, behandelt — und die verbleibende Unsicherheit als Reserve budgetiert. Alles mit demselben Beispielprojekt gerechnet, inklusive der Brücke in die EVA. Eigene Risiken einstufen: → Direkt rechnen: Risiko-Bewerter ### 5.1 Der Prozess 1. **Identifizieren:** systematisch (Workshops, Checklisten, Lessons Learned, Brainstorming mit Fachbereich und Dienstleister) — das Register lebt vom Zulauf, nicht vom Jahresupdate. 2. **Analysieren:** Ursache → Ereignis → Wirkung formulieren; Eintrittswahrscheinlichkeit und Auswirkung schätzen (qualitativ 1–5, bei großen Risiken quantitativ als Erwartungswert). 3. **Bewerten:** Score bilden, priorisieren, mit Risikotoleranz der Organisation abgleichen (was darf der PM allein verantworten?). 4. **Behandeln:** Strategie je Risiko festlegen (5.5) — mit Maßnahme, Verantwortlichem, Frist und Kosten der Maßnahme. 5. **Überwachen:** Status im Report, Frühwarnindikatoren (5.7), eingetretene Risiken werden Issues (Problemmanagement). Der Prozess läuft zyklisch, nicht einmalig: Jede Planänderung (Change Requests, neue Erkenntnisse) erzeugt neue Risiken. ### 5.2 Das Risikoregister **Risikoregister „E-Akte 2026“ — Auszug mit den sechs Kernrisiken** | ID | Risiko (Ursache → Ereignis → Wirkung) | W | A | Score | Strategie | Maßnahme / Auslöser | Owner | | --- | --- | --- | --- | --- | --- | --- | --- | | R1 | Fachbereich ausgelastet → Key-User fallen aus → Migration verzögert | 4 | 3 | 12 | vermindern | Vertreter einarbeiten (ab Feb, 4 PT); Auslöser: Abwesenheitsplanung > 5 Tage | PL | | R2 | Schwankende Aktenlagen → Mappings fehlerhaft → Nacharbeit Datenkorrektur | 2 | 5 | 10 | vermindern | Probe-Migration 300 Akten vor D; Fehlerquote-Messregel 0,5 % | Dienstleister | | R3 | Sensible Daten → Datenschutzverstoß → Untersagung, Reputationsschaden | 1 | 5 | 5 | vermeiden | DSB ab Kick-off im Team; Vermeidung: keine Scan-Cloud, lokaler Scanner | IT-Leitung | | R4 | Lieferengpass → Scanner-Hardware spät → Scanvolumen fällt zurück | 3 | 3 | 9 | übertragen | Vertragsstrafe + Ersatzlieferant benannt; Zwischenlager 2 Geräte | Vergabestelle | | R5 | Mitbestimmung überhört → Betriebsrat blockiert → Rollout-Stopp | 4 | 2 | 8 | vermindern | Betriebsrat ab Konzeptphase beteiligen (Quadrant „eng steuern“, 1.4) | PL | | R6 | Urlaubssaison → Testkapazität fehlt → Freigabe E verzögert | 2 | 4 | 8 | akzeptieren | Puffer 3 Wo im Netzplan (2.4) reicht; beobachten, keine Maßnahme | PL | Aufbau-Regeln: Risiko als Wirkungskette formulieren (nicht „Termingefährdung“, sondern Ursache→Ereignis→Wirkung); ein Owner je Risiko — namentlich, kein Gremium; Status je Report (offen / Maßnahmen wirken / eingetreten / geschlossen). ### 5.3 Score-Berechnung und Skalen **Risikoscore** ``` Score = W × A (Wahrscheinlichkeitsstufe × Auswirkungsstufe, je 1–5) Klassen: 1–4 gering · 5–9 mittel · 10–15 hoch · 16–25 kritisch ``` *Quantitativ: Erwartungswert EMV = Eintrittswahrscheinlichkeit × Schadenshöhe (für Reserven, 5.6). Ohne schriftliche Skalendefinition bewertet jeder anders — die Skala gehört ins Register.* **Skalendefinition (an Organisation kalibrieren)** | Stufe | Wahrscheinlichkeit W | Auswirkung A (Schaden) | | --- | --- | --- | | 1 | sehr gering (< 10 %) | < 2.000 € / geringe Unannehmlichkeit | | 2 | gering (10–30 %) | 2.000–10.000 € / Teilziel verrutscht | | 3 | mittel (30–50 %) | 10.000–30.000 € / Meilenstein gefährdet | | 4 | hoch (50–70 %) | 30.000–60.000 € / Projektziel gefährdet | | 5 | sehr hoch (> 70 %) | > 60.000 € / Projekt scheitert oder rechtliche Folge | ### 5.4 Die 5×5-Matrix (Heatmap) *Abbildung (nur in der HTML/PDF-Fassung): Abb. 5.1 — Risikomatrix mit den sechs Risiken aus dem Register (R1 bis R6). Die Zahl in jedem Feld ist der Score W×A als zweite Leseebene neben der Farbe.* > **Typische Fehler** > > Alles landet „mittig“ (W3/A3) — Folge fehlender Skalendefinition; Matrix ohne Konsequenzregel (wer schaut bei Score 12 hin?); eingetretene Risiken bleiben im Register statt Issue-Management; keine Neu-Bewertung nach Maßnahmen (Restrisiko eintragen!). ### 5.5 Behandlungsstrategien mit Beispielen | Strategie | Prinzip | Beispiel E-Akte 2026 | Wirkung auf Score | | --- | --- | --- | --- | | Vermeiden | Ursache beseitigen, Plan ändern | R3: keine Cloud-Scan-Dienste für Personaldaten — lokal scannen (Aufwand +, Risiko weg) | W oder A auf 1, Risiko ggf. geschlossen | | Vermindern | W oder A senken (Maßnahmen vor Eintritt) | R1: Key-User-Vertreter (W 4→2); R2: Probe-Migration (A 5→3) | Score z. B. 12 → 6 | | Übertragen | Risikoträger wechselt (Versicherung, Vertrag, Garantie) | R4: Vertragsstrafen + Ersatzlieferant; keine Risikoteilung mit Billig-Anbieter | A wird für uns kalkulierbar (Pauschale) | | Akzeptieren | bewusst hinnehmen, beobachten, Reserve halten | R6: Urlaubsrisiko mit 3 Wochen Puffer im Netzplan abgedeckt | Score bleibt, Ersatzmittel bereitstellen | | Eskalieren | außerhalb eigener Befugnis → höhere Ebene | (Risikofall) Finanzierungslücke > 10 % BAC → Beschluss Geschäftsleitung | Entscheidung verlagert, Zeitdruck dokumentieren | Für Chancen gelten die Spiegelstrategien: ausnutzen, teilen, verbessern (Aufwand erhöhen, um Chance zu vergrößern), akzeptieren (6. Abschnitt Glossar: Reaktionsstrategien). ### 5.6 Reserven: Risiken in der EVA unterbringen **Known Unknowns** — identifizierte, bewertete Risiken. Sie werden als **Risikoreserve (Contingency Reserve)** in die Kostenbasis (BAC) eingerechnet und vom PM auf Freigabe des LA verwaltet. **Unknown Unknowns** — unbenennbare Überraschungen. Sie stehen als **Managementreserve** *über* dem BAC und werden nur von der Geschäftsleitung freigegeben. > **Reserven rechnen: Erwartungswerte und Gesamtbudget** > > EMV je Risiko = Eintrittswahrscheinlichkeit × Schadenshöhe > R1 Key-User-Ausfall: 0,6 × 25.000 € = 15.000 € > R2 Mappings fehlerhaft: 0,2 × 30.000 € = 6.000 € > R3 Datenschutz: 0,05 × 40.000 € = 2.000 € > (R4 trägt vertraglich der Lieferant, R5/R6 wirken terminlich) > > Risikoreserve (Known Unknowns) = 15.000 + 6.000 + 2.000 = 23.000 € > Kostenbasis BAC = 97.000 € Leistung + 23.000 € Risikoreserve = 120.000 € > Managementreserve (Unknown Unknowns) = 8 % × 120.000 € = 9.600 € > Gesamtbudget = 120.000 + 9.600 = 129.600 € > Diese Zahlen sind durchgängig: Die Charta (1.2) nennt die 120.000 € „inkl. 23.000 € Risikoreserve“. Faustgrößen Managementreserve: 5 % bei routinehaften, 8–12 % bei innovativen Vorhaben im öffentlichen Sektor; PERT-gestützte Alternative: Reserve ≈ 1,5 × σProjekt × Kostenrate (2.7). > **Reserven in der EVA:** Reserven zählen nicht zum EV (kein „Fortschritt“), ihr Verbrauch wird separat ausgewiesen. Tritt ein Risiko ein (z. B. R2 Nacharbeit 9.000 €), fließt die Leistung in EV/AC, die Reserve wird frei — der LA sieht beides getrennt. Wichtig für 3.10: EAC sollte unter Reserve-Vorbehalt kommuniziert werden („136.800 €, darin enthalten 8.000 € aus Risikoreserve“). ### 5.7 Überwachen: Frühwarnindikatoren mit Folgeaktion | Indikator | Schwellwert | Folgeaktion (fest vereinbart) | | --- | --- | --- | | Burndown-Abweichung | > 15 % über Soll, 3 Tage | Re-Planung im Daily, Scope-Gespräch Product Owner | | SPI | < 0,90 zwei Berichte | Lagethema in LA, Maßnahmenplan (3.9) | | Pufferverbrauch Netzplan | > 50 % vor Meilenstein | Termin hochrechnen, MTA aktualisieren (4.4) | | Fehlerrate Probe-Migration (R2) | > 0,5 % | D startet nicht; Mapping-Workshop vor Freigabe | | Risikoreserve | > 60 % verbraucht | Eskalation: verbleibende Risiken neu bewerten | > **Typische Fehler** > > Trigger ohne vereinbarte Folge (Dekoration); Schwellen zu eng (Daueralarm → Abstumpfung) oder zu weit (Meldepflicht erst nach dem Schaden); Indikatoren ohne Datenquelle. ### 5.8 Chancen sehen — der andere Blick Risikomanagement im PMBOK ist zweiseitig: Bedrohungen verringern, Chancen nutzen. Beispiel: Die Probe-Migration (R2-Maßnahme) erzeugt als Nebeneffekt belastbare Kennzahlen für das Angebot des Rollouts in zwei weitere Ämter — Chance „Preisvorteil Folgebertrag“ (W 3, Nutzen 15.000 €, EMV 4.500 €). Chancen gehören ins selbe Register, sonst optimiert das Controlling nur nach unten. ## Teil 6: Reporting und Steuerung: Berichten, eskalieren, ändern Kennzahlen wirken nur, wenn sie in einem geordneten Berichtswesen landen, Eskalationsregeln vorab vereinbart sind und Änderungen kontrolliert fließen. Dieser Teil liefert Muster und Schwellen — alles wieder am Beispiel Monat 4 gerechnet. ### 6.1 Der Statusbericht — Muster (eine Seite, RAG) > **Statusbericht E-Akte 2026 · Bericht Nr. 04 · Stichtag 30.04.2026** > > | Bereich | Ampel | Begründung (je 1 Satz, mit Zahl) | Maßnahme bis wann | > | --- | --- | --- | --- | > | Termine | rot | SPI 0,83; MS „Pilotmigration“ rutscht laut MTA auf KW 24 (+2 Wochen), kritischer Pfad A→D ohne Puffer | Netzplan-Neurechnung 06.05., LA-Optionen 08.05. | > | Budget | gelb | CPI 0,88 (erholend), EAC 136.800 €; TCPI 1,111 — Budgeteinhaltung unwahrscheinlich | Bottom-up-Neuschätzung Rest bis 12.05. | > | Umfang | gelb | CR-08 genehmigt (+4.000 €), seit M4 Change-Freeze bis CPI ≥ 0,90 | Freeze prüfen im Bericht 05 | > | Risiken | orange | R1 Score 12 (Vertreter eingearbeitet, Restrisiko 6); R2 Probe-Migration bestanden (0,3 % Fehler) | R2 schließen im Bericht 05 | > > | Kennzahlen (Stichtag) | PV 60,0 T€ | EV 50,0 T€ | AC 57,0 T€ | SPI 0,83 | CPI 0,88 | EAC 136,8 T€ | TCPI 1,11 | > | --- | --- | --- | --- | --- | --- | --- | --- | > | Vormonat zum Vergleich | 40,0 | 34,0 | 40,0 | 0,85 | 0,85 | 141,2 | 1,08 | > > **Entscheidungsbedarfe:** (1) Optionen Termin (verschieben MS2 auf KW 24) vs. Umfang (Soll-Pakete prüfen) — Beschluss 08.05. · (2) Freigabe 8.000 € aus Risikoreserve für Nacharbeit Aktenplan-Kopplung (R2-Folge). > **Nächste Schritte:** Restschätzung Migration (D) verifizieren · Schulungsplan M3 finalisieren · Probeergebnis R2 dokumentieren. **Aufbau-Regeln:** Eine Seite · Ampel mit *einem Satz Begründung inkl. Zahl* (eine Ampel ohne Begründung ist Dekoration, eine Ampel mit Roman liest niemand) · Vorher-nachher-Vergleich · klare Entscheidungsanträge mit Termin (nicht „wird geprüft“, sondern „Beschluss erbeten am …“). **Formulierungshilfen: schwache Aussagen erkennen, starke schreiben** | Schwach (unschuldig, unpräzise) | Stark (zahlengestützt, entscheidungsreif) | | --- | --- | | „Das Projekt macht Fortschritte.“ | „EV 50.000 € von geplanten 60.000 € — Rückstand konzentriert auf Migration (D), 3 von 8 Chargen.“ | | „Es gab Verzögerungen bei der Technik.“ | „D liegt 5 Chargen (10 T€) zurück; Ursache: Freigabeschleife DMS-Rechte, seit 12.04. bei IT-Leitung.“ | | „Wir dran, das Budget im Blick zu behalten.“ | „CPI 0,877 stabil seit zwei Berichten; EAC-Bandbreite 127–153 T€, Leitzahl 136,8 T€ (VAC −16,8 T€).“ | | „Risiken werden beobachtet.“ | „R1 Score von 12 auf 6 gesenkt (Vertreter einsatzbereit); R2 eingetreten, 8 T€ aus Reserve, Restrisiko 4.“ | | „Über den Termin wird noch gesprochen.“ | „Beschluss erbeten am 08.05.: Option A Termin +2 Wochen (Kosten neutral) oder Option B Soll-Paket Volltextsuche streichen (Termin hält, Nutzen −).“ | | „Das Team gibt wieder Vollgas.“ | „Maßnahmen: 1. Freigabeschleife verkürzt (Stufe 2 statt 3), 2. 4 PT Dienstleister für Charge 4–5 — Wirkung prüfbar im Bericht 05 (SPI ≥ 0,85 erwartet).“ | Regel dahinter: Jede Aussage muss eine Zahl, einen Namen oder ein Datum enthalten — sonst ist sie Stimmung. Und jede Maßnahme braucht ein Wiedervorlage-Datum, sonst ist sie ein Wunsch. ### 6.2 RAG sauber definieren Rot/Gelb/Grün ist ein Vertrag, kein Stimmungsbild: Jedem Bereich gehören *vorab vereinbarte* Schwellen (die EVA-Schwellen aus 3.9; Risiken aus 5.3). Zwei Regeln bewähren sich: (1) Ampeln dürfen erst mit Antrag heruntergestuft werden, nicht still leise von rot auf gelb; (2) „Rot“ auszusprechen ist Leistung der Projektleitung, nicht Versagen — wer rot meldet, bekommt Kapazität, wer grün malt, bekommt Nachprüfungen. ### 6.3 Eskalationsregeln — Schwellen und Wege **Eskalationsleiter „E-Akte 2026“ (in der Charta vereinbart)** | Stufe | Wann (Beispiel-Schwellen) | Adressat | Frist | | --- | --- | --- | --- | | 0 · Projekt | SPI und CPI ≥ 0,97 · Budget ±5 % · Termin ±5 Tage · Risiko < 10 | PL steuert im Team | — | | 1 · Lenkungsausschuss | SPI oder CPI < 0,90 · zwei gelbe Berichte in Folge · Termin > 10 Tage · Risiko ≥ 10 · einzelner CR > 5.000 € | LA-Vorsitz (Sitzung oder Umlauf) | 5 Arbeitstage | | 2 · Geschäftsleitung | Budgetüberschreitung > 10 % · Zieltermin des Projekts gefährdet · Risiko ≥ 16 · Mittelabruf über Gesamtbudget hinaus | Erster Beigeordneter + Kämmerer | 10 Arbeitstage | | 3 · Gremium/Politik | Projektabbruch oder Beschluss-Umfang des Vorhabens berührt (Gemeinderat) | Gemeinderat | nach GeschO | > **Merksätze** > > **Budget erschöpft (oder TCPI > 1,10) ist keine Lagemeldung, sondern automatisch Stufe 1.** Eine Eskalation enthält immer: Sachverhalt, Auswirkung auf Ziele, 2–3 Optionen mit Zahlen, Empfehlung, Entscheidung bis wann. Wer nur Probleme meldet, gibt die Steuerung ab; wer Optionen meldet, behält sie. ### 6.4 Entscheidungslog Jede weitreichende Entscheidung mit Datum, Gremium, Begründung und Wirkung — ein Zehnzeiler pro Monat, der bei Personalwechsel oder Prüfung den Projektverlauf erklärt. Der Log ist die Schwester der Baseline: Er erklärt, *warum* der Plan heute so aussieht. | Datum | ID | Entscheidung | Gremium | Basis / Grund | Wirkung | | --- | --- | --- | --- | --- | --- | | 31.01. | E-12 | Baseline freigegeben (120.000 €, 8 Monate) | LA | Charta + Strukturplan + Netzplan | Planung verbindlich | | 28.02. | E-15 | CR-08 Volltextsuche genehmigt (+4.000 €, +10 SP) | LA | CPI 0,84, Terminpuffer > 6 Wochen | BAC +4.000 € → Scope wächst | | 30.04. | E-21 | Change-Freeze ab sofort | LA | CPI 0,88, TCPI 1,111 > 1,10 (3.9) | Keine neuen CRs bis CPI ≥ 0,90 | | 30.04. | E-22 | 8.000 € aus Risikoreserve für Nacharbeit | LA | R2 eingetreten (0,3 % < Schwelle, Restnacharbeit) | Reserve 23.000 → 15.000 € | > **Typische Fehler** > > Entscheidungen nur im Protokoll (nicht auffindbar); ohne Zahlenbasis; „mündlich genehmigt“; Log führt die Vergangenheit, aber niemand prüft ihn bei Planänderungen. ### 6.5 Change Management — der geregelte Fluss **Was ist es?** Jede Anforderungsänderung läuft als Change Request (CR) durch denselben Fluss: Antrag → Vollständigkeitsprüfung → Bewertung (Kosten, Termin, Risiko, Nutzen) → Entscheidung durch die befugte Stelle → Anpassung von Baseline und Plänen oder dokumentierte Ablehnung. Das ist der einzige legitime Weg, den Umfang zu ändern — alles andere ist Scope Creep. *Abbildung (nur in der HTML/PDF-Fassung): Abb. 6.1 — Change-Request-Fluss mit Bewertungsstufe und getrennten Ausgängen. Die Entscheidungskompetenz staffelt sich nach Volumen (hier: PL bis 5.000 €, LA bis 5 % BAC, darüber Geschäftsleitung).* > **Durchgerechnet: CR-11 „Barcode-Etiketten für Altkarten“ (gestellt 28.04.)** > > Aufwand: 5 PT × 480 €/PT = 2.400 € > Termin: liegt auf gepuffertem Weg (E) → +0 Tage Projektende > Risiko: gering (Score 4, kein Eintrag) > Nutzen: Arbeitserleichterung Registro, kein Zielbezug > > Bewertung am 30.04.: budgetär tragbar (2.400 € < PL-Grenze 5.000 €) > ABER: Projekt-Kontext — CPI 0,88, TCPI 1,111 > 1,10, Change-Freeze E-21 > > Entscheidung LA (E-23, 08.05.): abgelehnt für Phase 2, > zurückgestellt ins Backlog Phase 4 mit Auflage: > „neu bewerten, wenn CPI ≥ 0,90 zwei Berichte in Folge“ > Die Lehrstunde: Change-Entscheidungen sind Einzelfall *und* Kontext. Dieselbe Anfrage wäre im Februar (Puffer 6 Wochen, CPI 0,84 aber TCPI 1,03) genehmigt worden — deshalb müssen Entscheidungslog (6.4) und Kennzahlenlage zusammen gelesen werden. ### 6.6 Berichtswesen: Rhythmus und Zielgruppen | Bericht | Rhythmus | Zielgruppe | Inhalt | | --- | --- | --- | --- | | Daily / Stand-up | täglich 15 min | Team | Blocker, Tagesziel, Burndown-Abweichung (4.1) | | Statusbericht | monatlich, Stichtag | LA, PMO | RAG + EVA-Kennzahlen + Entscheidungsbedarfe (6.1) | | Kennzahlenblatt | quartalsweise | Kämmerer/Controlling | Budgetvergleich, Mittelabfluss vs. AC, Prognose EAC | | Ausnahmebericht | bei Trigger (5.7) | LA-Vorsitz | Sachverhalt, Optionen, Empfehlung, Frist — sofort, nicht zum Monatsende | > **Typische Fehler** > > Berichte ohne Stichtagsdisziplin (Zahlen aus verschiedenen Tagen); Bericht als Rechtfertigungschreiben; dieselbe Fassung für Team und LA (unterschiedliche Entscheidungsfragen!); Ausnahmeberichte, die auf die nächste Sitzung warten. ## Teil 7: Agil und hybrid: Sprints steuern, Grenzen setzen Agile Verfahren steuern nicht über eine vorab gebaute Baseline, sondern über kurze Lieferzyklen und empirische Messgrößen. Dieser Teil erklärt Scrum-Kern, Forecasting als Bandbreite (Monte-Carlo-Idee) und wie hybride Projekte beides verbinden. ### 7.1 Scrum in zehn Sätzen (Basics fürs Controlling) **Rollen:** Product Owner (vertritt Nutzen und Priorisierung, eindeutig eine Person), Scrum Master (Prozess und Hindernisse), Entwicklungsteam (5–9 Personen, selbstorganisiert). **Events:** Sprint (2–4 Wochen Zeitbox, Ergebnis ist potenziell lieferbar), Daily (15 min), Sprint Planning, Review (Ergebnis), Retrospektive (Prozess). **Artefakte:** Product Backlog (geordnete Anforderungen), Sprint Backlog (Verpflichtung des Sprints), Increment (Ergebnis, gemessen an der Definition of Done). **Controlling-Anschluss:** Velocity (4.3) ist die Messgröße, Burndown/Burn-up (4.1/4.6) die Kurve, die Sprint-Review der Abnahmeäquivalent, die Retrospektive das Lessons-Learned am Laufband. Ein Scrum-Team braucht keine EVA — ein Programm mit Scrum-Inseln schon (7.5). ### 7.2 Velocity-Forecasting als Bereich — Monte-Carlo-Grundidee **Das Problem:** „Wann sind die 120 Rest-Punkte fertig?“ ist keine Frage mit einer Zahl als Antwort. Jede Zukunftsrechnung aus Velocity streut — wenn man die Streuung ignoriert, plant man mit dem Glücksfall. **Die Idee Monte-Carlo:** Statt einmal mit dem Durchschnitt zu rechnen, zieht man tausendmal zufällig aus den *historischen* Sprint-Ergebnissen (mit Zurücklegen), summiert je Lauf, bis die Restmenge erreicht ist, und liest die Verteilung ab: „In 52 % der Läufe reichten 3 Sprints, in 87 % 4 Sprints.“ Daraus werden Bandbreiten-Angaben (P50 realistisch, P85 zusagbar) statt Festterminen. *Abbildung (nur in der HTML/PDF-Fassung): Abb. 7.1 — Velocity der Sprints 2 bis 7. Der Balken nie über 42, nie unter 34: genau diese Verteilung speist die Monte-Carlo-Rechnung.* > **Forecast 120 Rest-SP — drei Rechenweisen vergleichen** > > 1 · Naiv (letzter Sprint): 120 / 40 = 3,0 Sprints (Annahme: bester Fall hält) > 2 · Durchschnitt: 120 / 38,3 = 3,1 Sprints (wirkt präzise, ist aber P50) > 3 · Monte-Carlo (1.000 Läufe aus {34,40,38,42,36,40}): > 3 Sprints reichten in 52 % der Läufe > 4 Sprints reichten in 87 % der Läufe (P85) > 5 Sprints in 98 % (P98, Worst Case) > > Terminzusage nach außen: 4 Sprints (P85) — mit Datum ≈ 8 Wochen > Interne Steuergröße: 3 Sprints als Ziel, Review-Check je Sprint > Merkregel: **P50 zum Steuern, P85 zum Zusagen.** Wer mit P50 nach außen zusagt, verspricht eine Münzwurf-Chance — und verliert sie in jedem zweiten Projekt. ### 7.3 Hybride Modelle **Was ist es?** Kombination prädiktiver und agiler Anteile in einem Governance-Rahmen: klassisch für Budget, Verträge, Meilensteine, Schnittstellen; agil für Entwicklung und Anforderungen. Kein „Anything goes“, sondern bewusste Zuordnung pro Arbeitspaket. **Beispiel E-Akte 2026:** Rahmen prädiktiv (Baseline 120.000 €, Netzplan Phase 2, LA-Reporting nach Teil 6). Innen agil: Die Trainingspakete (Phase 3) werden in Sprints mit Burndown (4.1) entwickelt; das DMS-Mapping iteriert in Probezyklen (R2). Die Brücke: Sprint-Ergebnisse zählen als Fertigstellung in der EVA (7.5), der Release-Termin MS3 ist der Fixpunkt. | Kriterium | prädiktiv (Wasserfall-artig) | agil (Scrum-artig) | hybrid | | --- | --- | --- | --- | | Anforderungen | stabil, vertraglich fixiert | entstehen, ändern sich | Kern fix, Umfeld iterativ | | Abnahme | am Ende, gegen Spezifikation | je Increment (Review) | beides, je Paket | | Budgetierung | über Baseline/BAC | über Team-Kapazität (fixe Kosten je Sprint) | Baseline je Phase, Sprint-Kapazität innen | | Steuergröße | SPI/CPI, Netzplan | Velocity, Burndown | beides, konsolidiert (7.5) | ### 7.4 Wann was? Entscheidungshilfe 1. **Anforderungsstabilität:** hoch und reguliert (Zahlungsverkehr, Bau) → prädiktiv. Niedrig, lernend (Usability, neue Services) → agil. 2. **Kosten der Fehlerfrüherkennung:** teuer bei Spätentdeckung → agile Kurven (Review je Sprint). Gering, reversibel → prädiktiv. 3. **Vertrags- und Vergaberahmen:** öffentliche Vergabe nach LVergabGG/EVB-IT erzwingt oft deterministische Leistungsbeschreibung → außen prädiktiv, innen iterativ mit Dienstleistern. 4. **Lieferfähigkeit:** Nutzen entsteht erst komplett (Architekturanpassung) → Wasserfall; Nutzen stückweise (Portalanwendung) → agil. 5. **Teamreife:** Scrum ohne Scrum Master/PO-Rollen ist Theater; dann besser klassisch klein steuern. ### 7.5 Agile Zahlen ins klassische Reporting überführen > **Brücke Burndown ↔ EVA am Beispiel** > > Sprint-Backlog Phase 3 (Schulung): 6 Sprints × 38 SP Ø = 228 SP ≙ 20.000 € Paketbudget > → Planwert je SP ≈ 20.000 / 228 ≈ 88 €/SP > > Sprint 7 abgeschlossen: 152 SP fertig (Abb. 4.3) > → EV = 152 × 88 € ≈ 13.400 € > → AC = Iststunden × Satzkostensatz = 15.100 € (Zeiterfassung) > > Damit fließt die agile Insel in EVA des Gesamtprojekts: > CPI(Insel) = 13.400 / 15.100 = 0,89 — passt zur Projektlinie (0,88) > Regeln für die Brücke: (1) **Definition of Done = EV-Anerkennung** — was nicht DoD-reif ist, zählt nicht; (2) SP-zu-€-Umrechnung je Paket festlegen und einfrieren; (3) Sprint-Zeitboxen als Vorgänge im Netzplan führen (Zeitbox bricht nicht den kritischen Pfad); (4) Velocity-Änderungen sind Frühwarnindikator für CPI-Drift (Trigger 5.7). > **Typische Fehler** > > „Agil“ als Ausrede für Planlosigkeit nach außen; Velocity über Teams vergleichen; hybride Doppelstruktur (Wasserfalldokumentation PLUS volle Scrum-Zeremonien ohne Kürzung); SP-preise dynamisch umrechnen, bis jede Kennzahl beliebig wird. ## Anhang: Formeln, Checklisten, Schwellen, Quellenzuordnung Der Anhang bündelt, was im Projektalltag schnell gebraucht wird: alle Formeln auf einer Seite, Checklisten als abhakbare Listen, die Schwellen- und Eskalationslogik im Kompendium und die Zuordnung der Kapitel zu PMBOK Guide 8. Edition und PRINCE2. ### A.1 Formelsammlung auf einen Blick **Alle Rechenformeln dieses Werks (Verweis auf das Kapitel mit vollständiger Herleitung und Beispiel)** | Bereich | Größe | Formel | Kapitel | | --- | --- | --- | --- | | Netzplan | Frühester Start / Ende | ES = max(EF aller Vorgänger) · EF = ES + D | 2.3, 2.4 | | Spätester Start / Ende | LF = min(LS aller Nachfolger) · LS = LF − D | 2.3, 2.4 | | | Gesamtpuffer | GP = LS − ES = LF − EF | 2.4 | | | Projektdauer | max(EF) über alle Endvorgänge | 2.4 | | | Kritischer Pfad | Weg über alle Vorgänge mit GP = 0 | 2.4 | | | Schätzung | PERT-Erwartungswert | E = (O + 4·M + P) ÷ 6 | 2.7 | | PERT-Streuung | σ = (P − O) ÷ 6 | 2.7 | | | Projekt-Streuung | σProjekt = √(σ1² + σ2² + …) über den kritischen Pfad | 2.7 | | | Earned Value | Termintreue | SV = EV − PV · SPI = EV ÷ PV | 3.4, 3.5 | | Kostentreue | CV = EV − AC · CPI = EV ÷ AC | 3.4, 3.5 | | | EAC, Rest planmäßig | EAC = AC + (BAC − EV) | 3.10 A | | | EAC, Standard | EAC = BAC ÷ CPI | 3.6, 3.10 B | | | EAC, beides schlägt durch | EAC = AC + (BAC − EV) ÷ (CPI × SPI) | 3.10 C | | | EAC, Bottom-up | EAC = AC + neu geschätzter Restaufwand | 3.10 D | | | Restaufwand | ETC = EAC − AC | 3.6 | | | Endabweichung | VAC = BAC − EAC | 3.6 | | | Resteffizienz | TCPI = (BAC − EV) ÷ (BAC − AC) | 3.7 | | | Risiko & Budget | Risikoscore | Score = W × A (je 1–5) | 5.3 | | Erwartungswert | EMV = Wahrscheinlichkeit × Schadenshöhe | 5.6 | | | Budgetaufbau | Gesamtbudget = Leistung + Risikoreserve (im BAC) + Managementreserve (über BAC) | 5.6 | | | Agile Forecast | Restdauer aus Burndown | Tage = Rest ÷ Ø-Tagesleistung | 4.2 | | Termin aus Velocity | Sprints = Restmenge ÷ Velocity (P50 steuern, P85 zusagen) | 4.3, 7.2 | | Nachrechnen mit eigenen Zahlen: EVA-Rechner ### A.2 Checklisten (im Browser abhakbar — ohne Speicherung) > **Projektstart (vor Kick-off)** > > - [ ] Auftrag schriftlich, Charta unterschrieben (1.2) > - [ ] Ziele SMART, mit Messgröße und Datenquelle (1.3) > - [ ] Abgrenzung „nicht Gegenstand“ festgehalten (1.2) > - [ ] Stakeholderregister + Matrix erstellt (1.4) > - [ ] RACI für Kernentscheidungen abgestimmt (1.5) > - [ ] Strukturplan vollständig, 100-%-Regel geprüft (2.1) > - [ ] Netzplan gerechnet, kritischer Pfad markiert (2.4) > - [ ] Schätzung gegen Analogie/Parametrik gespiegelt (2.7) > - [ ] Risikoregister mit 6+ Einträgen, Skala definiert (5.2, 5.3) > - [ ] Reserven berechnet und Freigaberegel vereinbart (5.6) > - [ ] Berichtsrhythmus + Eskalationsschwellen in Charta (6.3, 6.6) > - [ ] Meilensteine mit Prüfkriterien (2.5) > **Monatlicher Controlling-Zyklus** > > - [ ] Stichtag gesetzt, alle Meldungen auf denselben Tag (3.2) > - [ ] Fertigstellungsgrade nach Messregel erhoben (3.2) > - [ ] AC gegen Belege/Kostenstellen abgegrenzt (3.2) > - [ ] EVA-Kennzahlen + Vormonatswerte berechnet (3.8) > - [ ] Trend gelesen: Richtung SPI/CPI (4.5) > - [ ] MTA aktualisiert, Verschlechterungen markiert (4.4) > - [ ] Pufferverbrauch Netzplan ausgewiesen (2.3) > - [ ] Risiken neu bewertet, Trigger geprüft (5.7) > - [ ] EAC-Bandbreite (A–C) statt Einzelwert gemeldet (3.10) > - [ ] Statusbericht 1 Seite, Ampel mit Begründungssatz (6.1) > - [ ] Entscheidungsanträge mit Termin formuliert (6.1) > - [ ] Entscheidungslog fortgeschrieben (6.4) > **Change Request — Prüffragen vor der Entscheidung (6.5)** > > - [ ] Nutzen benannt und geprüft? > - [ ] Kosten geschätzt (Aufwand × Satz)? > - [ ] Terminwirkung am kritischen Pfad? > - [ ] Risiko geprüft (W×A)? > - [ ] Entscheidungsbefugnis richtig zugeordnet? > - [ ] Bei Ablehnung: dokumentiert + informiert? > **Projektabschluss (8. Glossar: Projektabschluss)** > > - [ ] Abnahmen vollständig, Abnahmeprotokolle archiviert > - [ ] Schlussrechnung gestellt/freigegeben, Restbudget aufgelöst > - [ ] Reserven-Schlussstand dokumentiert (Verbrauch vs. Planung, 5.6) > - [ ] Ist-EVA zum Abschluss: EAC = AC, CPI gesamt (Lernzahl!) > - [ ] Übergabe Betrieb: Prozesse, Service Desk, Dokumentation > - [ ] Lessons Learned mit Zahlen (Schätzabweichung, Risikoeintritte) > - [ ] Projektdaten für künftige Analogieschätzungen abgelegt (2.7) ### A.3 Schwellen und Eskalation als Kompendium | Kennzahl / Ereignis | gelb ab | orange ab | rot ab / Eskalation Stufe 1 | Kapitel | | --- | --- | --- | --- | --- | | SPI | 0,97 | 0,90 | 0,85 | 3.9 | | CPI | 0,97 | 0,90 | 0,85 | 3.9 | | TCPI | 1,00 | 1,05 | 1,10 | 3.7 | | VAC (erwartete Mehrkosten) | 2 % | 5 % | 10 % | 3.6, 6.3 | | Risikoscore | 5 | 10 | 16 | 5.3 | | Burndown-Abweichung | 10 % | 15 % (3 Tage) | 25 % | 4.1, 5.7 | | Meilenstein-Verschlechterung | +1 Woche | +2 Wochen | 2 Berichte in Folge schlechter | 4.4 | | Pufferverbrauch | 30 % | 50 % | 75 % | 2.3, 5.7 | | Risikoreserve verbraucht | 40 % | 60 % | 80 % | 5.7 | Diese Tabelle ist der Kompaktvorschlag dieses Werks; verbindlich sind nur die mit dem Auftraggeber *vereinbarten* Schwellen (6.2). Ändern sich Schwellen, ändern sich Ampeln rückwirkend nicht — Historie im Entscheidungslog sichern. ### A.4 Zuordnung: Kapitel dieses Werks zu PMBOK Guide 8. Edition und PRINCE2 | Kapitel hier | PMBOK Guide 8. Edition | PRINCE2 | | --- | --- | --- | | 1 Grundlagen | Einleitung, Wertschöpfungssystem, Performance Domain Governance/Stakeholder | Organization (Rollen), Starting up a Project | | 2 Planung | Scope Domain (PSP), Schedule Domain (CPM), Schätztechniken | Plans, Following the plan | | 3 EVA | Finance Domain, Leistungsmessung | Progress (Kosten- und Zeitkontrolle) | | 4 Burndown & Trend | Schedule Domain, adaptive Techniken | Progress (MTA als deutsche Praxis) | | 5 Risiko | Risk Domain, quantitative Analyse | Risk, Change (Budget-Reserven) | | 6 Reporting & Steuern | Governance Domain, Focus Area Überwachung und Steuerung | Directing, Controlling a Stage, Ausnahmeprinzip | | 7 Agil & hybrid | Entwicklungsansätze, Tailoring | Tailoring auf agile Umgebungen | | 8 Glossar | gesamter Guide, mit Quellenangabe je Eintrag | Begriffe aus allen Themenbereichen | Diese Zuordnung ist Orientierung, keine Eins-zu-eins-Abbildung; der PMBOK Guide ist ein Standard („was“), PRINCE2 eine Methode („wie“) — beide ergänzen sich (Glossar: PRINCE2 und PMBOK). ### A.5 Der Monatsdurchlauf in 20 Minuten Diese Routine ist die Kürzung des ganzen Werks auf einen wiederholbaren Arbeitsablauf — Wertermittlung, Kennzahlen, Trend, Bericht. Die Zahlen stammen aus dem Großbeispiel (M4), die Minuten sind Erfahrungswerte aus Mittelprojekten. | Min. | Schritt | Werkzeug / Formel | Ergebnis am Beispiel | | --- | --- | --- | --- | | 0–5 | Stichtag setzen, Fertigstellungsgrade je Arbeitspaket nach Messregel einholen (nicht schätzen lassen — messen) | Tabelle wie 3.2a (EV-Erhebung) | EV 50.000 €; D = 3/8 Chargen | | 5–8 | Istkosten je Paket zuordnen, Belegung gegen Kostenstellen prüfen | AC-Erhebung, Abgrenzungsregel (3.2) | AC 57.000 € | | 8–10 | PV der Baseline zum Stichtag ablesen | S-Kurven-Tabelle (3.3) | PV 60.000 € | | 10–12 | Kennzahlen berechnen | EVA-Rechner (Werkzeug 1); Formeln A.1 | SPI 0,83 · CPI 0,88 · EAC 136.800 · TCPI 1,11 | | 12–14 | Trend gegen Vormonat lesen: Richtung, Konstanz, Cluster (welches Paket treibt?) | 4.5; Monatsvergleichstabelle 3.8 | CPI erholt sich, SPI fällt — Treiber: D | | 14–16 | Terminseite: MTA fortschreiben, Pufferverbrauch ausweisen | Werkzeug 4; 4.4 | M2 +2 Wochen, zweite Verschlechterung → LA-Thema | | 16–18 | Risiken: Status, Trigger, Reserve-Stand | 5.7-Tabelle; Werkzeug 2 bei Neu-Bewertungen | R2 eingetreten, 8 T€ Reserve, Restscore 4 | | 18–20 | Bericht schreiben: 4 Ampeln je 1 Satz mit Zahl, Entscheidungsanträge mit Termin — Aussagen nach der Tabelle in 6.1 | Muster 6.1; Formulierungshilfen | Bericht Nr. 04 (Muster in 6.1 ist genau dieses Ergebnis) | Was diese Routine *nicht* ersetzt: das Ursachengespräch am Arbeitspaket (EVA zeigt dass, nicht warum) und die Viertelstunde, in der man sich überlegt, welche Entscheidung man eigentlich braucht, bevor man Zahlen verschickt. ### A.6 Zwölf Fragen aus der Praxis **1 · SPI ist schlecht, CPI gut — woran zuerst arbeiten?** : Terminproblem mit intakter Kosteneffizienz: zuerst Kapazität und Blocker prüfen (häufigster Fall: Warten auf Freigaben oder Vorgänger). Kostenmaßnahmen bringen hier nichts — Zeit zulegen durch Überstunden würde sogar den CPI beschädigen. Reihenfolge: Ursachencluster (3.9) → Netzplan neu rechnen → Entscheidung Optionen Termin/Umfang. (2.4, 3.9) **2 · CPI ist schlecht, SPI gut — kann das sein?** : Ja: schnelles Arbeiten zu hohen Preisen (Überstunden, teure externe Unterstützung, Nacharbeit unter Zeitdruck). Das Projekt „kauft“ Termintreue. Genau deshalb Trend beider gemeinsam lesen — und die EAC-Variante C (3.10) nutzen, wenn beide Ursachen zusammenhängen. **3 · Darf ich die Baseline ändern?** : Nur über einen dokumentierten Beschluss (Change-Freigabe oder Rebaselining nach LA-Entscheidung), nie zur „Beseitigung“ von Abweichungen. Alte Baseline und die Abweichungshistorie bleiben archiviert — sonst verliert jede spätere Aussage ihre Referenz. (Glossar: Baseline; 3.11) **4 · EV ohne Projektsoftware — wie anfangen?** : Mit einer Tabelle: je Arbeitspaket BAC-Anteil, Messregel, Ist-Status → EV-Summe (Muster in 3.2a). Für Projekte bis ~40 Paketen reicht das vollständig; der Werkzeug-Rechner hier setzt die Kennzahlen darauf. Die Messregel ist wichtiger als das Tool. **5 · Mein Auftraggeber will keine Indizes, „nur kurz sagen wie es steht“.** : Übersetzen statt belehren: SPI 0,83 heißt „von sechs geplanten Wochen Arbeit sind fünf da“; CPI 0,88 heißt „je 100 € ausgegeben entsteht Wert für 88 €“. Im Bericht eine Zeile Laiendeutsch unter die Zahl setzen (6.1) — die Zahl bleibt für Nachvollziehbarkeit stehen. **6 · Ab wann ist EVA-Aufwand gerechtfertigt?** : Faustregel: ab ~3 Monaten Laufzeit und ~20.000 € Volumen, oder wenn mehrere Teilprojekte zusammen gesteuert werden. Darunter reichen Meilensteintrend (4.4) + Budgetverbrauch. (3.11) **7 · Risiko ist eingetreten — was tun ich zuerst?** : Vom Register ins Problemmanagement: Notfallmaßnahme, Auswirkung bewerten, Issue mit Owner; Reserve anfordern über die vereinbarte Freigabe (5.6), Eintritt und Folgen im Statusbericht, Risikoregister-Eintrag schließen oder Restrisiko neu bewerten. (Glossar: Risiko oder Problem) **8 · Wie viele Risiken sind „richtig“?** : Zwischen 10 und 30 aktive Einträge sind bei Mittleren Projekten normal; entscheidend ist nicht die Zahl, sondern: jede Top-5 hat Owner, Maßnahme und Trigger. 80 Einträge ohne Pflege sind wertlos. (5.2, 5.7) **9 · Team liefert konstant weniger als geplant — Velocity erhöhen?** : Velocity ist Messgröße, keine Zielgröße (4.3). Statt Druck: Kapazität prüfen (2.8: Linie? Urlaube?), Story-Größen und Definition of Done prüfen (7.5), Blocker im Daily sammeln. Steigt dann nichts: Planung an die Realität anpassen — nicht umgekehrt. **10 · Ein Stakeholder blockiert — Eskalation?** : Erst die Matrix lesen (1.4): Bei hohem Einfluss hilft persönliche Einbindung meist mehr als formale Eskalation. Eskalieren erst, wenn eigene Mittel erschöpft sind — dann aber mit Sachverhalt, Auswirkung, Optionen, Empfehlung, Frist (6.3). **11 · Change-Freeze — darf der PM das anordnen?** : Ein Freeze ist ein Beschluss des Gremiums, nicht des PM allein. Der PM beantragt mit Begründung (z. B. TCPI > 1,10), der LA beschließt und die Dauer/Bedingung steht im Entscheidungslog. Beispiel E-21 in 6.4. **12 · Was gehört in den Abschlussbericht?** : Soll-Ist gegen Ziele (SMART, 1.3), EVA-Schlussstand (End-CPI als Lernzahl), Kosten- und Terminabweichung mit Ursachen, Risikoeintritte vs. Prognose (Qualität der Reserven!), Lessons Learned mit Zahlen, Übergabestand. Checkliste in A.2. (Glossar: Projektabschluss) ## Teil 8: Glossar: Begriffe von Abnahme bis Wertschöpfung Das Glossar ist das Nachschlagewerk im Nachschlagewerk: jeder Begriff kurz erklärt, mit Quellenhinweis zum PMBOK Guide und Verweisen auf verwandte Einträge. Die Suche oben filtert live, die Kategorie-Chips grenzen ein. Einträge zu Kennzahlen und Schätzverfahren sind um die Werkzeug-Kapitel (Teile 2 bis 7) ergänzt. Filter nach Kategorie: --- ## Glossar 98 Begriffe von Abnahme bis Wertschöpfung, nach Kategorien gegliedert. In der HTML-Fassung ist das Glossar live durchsuchbar. ### Grundlagen - **PMBOK Guide** (A Guide to the Project Management Body of Knowledge) — Standard des Project Management Institute. Er beschreibt, was gutes Projektmanagement ausmacht, ohne eine feste Methode vorzuschreiben. Die 8. Edition erschien Ende 2025 und ist seit Juli 2026 Grundlage der PMP-Prüfung. *(Einleitung des Guides)* - **Aufbau der 8. Edition** (Eighth Edition) — Die 8. Edition verbindet vier Ebenen: sechs Prinzipien als Haltung, fünf Focus Areas entlang des Lebenszyklus, sieben Performance Domains als Handlungsfelder und rund 40 nicht verbindliche Prozesse als praktische Anleitung. Gegenüber der 7. Edition (12 Prinzipien, 8 Domains, keine Prozesse) kehrt damit wieder mehr Struktur zurück. Neu sind unter anderem ausführlichere Inhalte zu KI, PMO und Beschaffung. *(Einleitung und Anhang zur Entwicklung des Guides)* - **Tailoring** — Bewusstes Anpassen von Vorgehen, Werkzeugen und Detailtiefe an Projekt, Organisation und Umfeld. Nicht jede Technik passt zu jedem Projekt; entscheidend ist, die Auswahl zu begründen. *(Kapitel zum Tailoring)* - **Projekt, Programm, Portfolio** (Project, Program, Portfolio) — Ein Projekt ist ein zeitlich begrenztes Vorhaben mit eindeutigem Ergebnis. Ein Programm bündelt zusammenhängende Projekte, deren Nutzen nur gemeinsam entsteht oder die dieselben Ressourcen teilen. Das Portfolio ist die Gesamtheit der Vorhaben einer Organisation, gesteuert nach strategischer Priorität. *(Einleitung, Abschnitt zum Wertschöpfungssystem)* - **Wertschöpfungssystem** (Value Delivery System) — Projekte sind kein Selbstzweck, sondern Teil eines Systems, das Nutzen für die Organisation erzeugt. Ergebnisse (Outputs) sind nur wertvoll, wenn sie zu Wirkungen (Outcomes) führen, etwa stabilerem Betrieb oder geringeren Kosten. *(Kapitel zum Wertschöpfungssystem)* - **KI im Projektmanagement** (AI in Project Management) — Die 8. Edition behandelt KI als Werkzeug, etwa für Risikoanalyse, Ressourcenoptimierung und Terminplanung. Wichtig bleiben Nachvollziehbarkeit, Datenschutz und die Verantwortung beim Menschen. *(Abschnitt zu neuen Themen)* ### Prinzipien - **Die sechs Prinzipien** (Principles) — Die Prinzipien beschreiben, wie man denkt und entscheidet, unabhängig von Methode oder Branche: ganzheitlich betrachten, auf Nutzen ausrichten, Qualität einbauen, verantwortlich führen, Nachhaltigkeit berücksichtigen, eine befähigte Kultur schaffen. Sie ersetzen die zwölf Prinzipien der 7. Edition. *(Standard for Project Management, Prinzipien)* - **Ganzheitliche Sicht** (Adopt a Holistic View) — Ein Projekt ist ein System aus Menschen, Technik, Organisation und Umfeld. Entscheidungen in einem Bereich wirken in andere hinein. Wer nur den eigenen Strang optimiert, verschiebt Probleme, zum Beispiel wenn parallele Projekte ohne gemeinsame Planung auf dieselben Fachkräfte zugreifen. *(Prinzipien)* - **Auf Nutzen ausrichten** (Focus on Value) — Entscheidungen werden daran gemessen, welchen Nutzen sie stiften, nicht daran, ob ein Plan abgearbeitet wurde. Das schließt ein, Arbeit zu stoppen, die keinen Nutzen mehr bringt. *(Prinzipien)* - **Qualität einbauen** (Embed Quality) — Qualität entsteht im Prozess, nicht in der Endkontrolle. Qualität ist in der 8. Edition kein eigener Domain mehr, sondern Prinzip, das in alle Bereiche wirkt. Praktisch heißt das etwa, auch Konfigurationen und Workflows als Abnahmegegenstand zu prüfen, statt sie vorauszusetzen. *(Prinzipien)* - **Verantwortlich führen** (Be an Accountable Leader) — Führung bedeutet Verantwortung für Ergebnisse, Menschen und Umgang mit Ressourcen. Dazu gehört, Probleme früh und offen zu melden, auch wenn sie unbequem sind, also bevor ein Termin oder Budget tatsächlich fällt. *(Prinzipien)* - **Nachhaltigkeit integrieren** (Integrate Sustainability) — Einziges wirklich neues Prinzip der 8. Edition. Projekte berücksichtigen soziale, ökologische und langfristige wirtschaftliche Folgen, zum Beispiel Weiterverwendung von Hardware statt Neubeschaffung oder die Belastung der beteiligten Menschen. *(Prinzipien)* - **Befähigte Kultur aufbauen** (Build an Empowered Culture) — Teams, die Verantwortung übernehmen dürfen und die Ziele verstehen, liefern mehr und melden Probleme früher. Dazu gehören klare Rollen, Vertrauen und psychologische Sicherheit. *(Prinzipien)* ### Performance Domains - **Die sieben Performance Domains** (Performance Domains) — Die Domains sind die Handlungsfelder, in denen Projektleistung entsteht: Governance, Scope, Termine, Finanzen, Stakeholder, Ressourcen und Risiko. Sie ersetzen die zehn Wissensgebiete früherer Editionen und die acht Domains der 7. Edition. Kommunikation, Integration und Beschaffung sind in diese Felder eingegangen. *(Kapitel Performance Domains)* - **Governance** — Wer entscheidet was, auf welcher Grundlage und wie wird eskaliert? Governance umfasst Projektorganisation, Entscheidungsrechte, Berichtswege und das Zusammenspiel mit der Linie. *(Performance Domain Governance)* - **Scope** — Was gehört zum Projekt und was nicht? Der Domain umfasst Anforderungen, Leistungsbeschreibung, Strukturierung der Arbeit und die Kontrolle von Änderungen. *(Performance Domain Scope)* - **Termine** (Schedule) — Planung und Steuerung von Terminen: Vorgänge, Abhängigkeiten, Dauern, kritischer Pfad, Meilensteine. Adaptive Vorgehen planen stattdessen in Iterationen. *(Performance Domain Schedule)* - **Finanzen** (Finance) — Kostenschätzung, Budget, Finanzierung und Kostenkontrolle. Die 8. Edition spricht bewusst von Finanzen statt nur von Kosten, weil auch Finanzierung und Nutzen betrachtet werden. *(Performance Domain Finance)* - **Stakeholder** (Stakeholders) — Identifizieren, verstehen und gezielt einbinden aller, die das Projekt beeinflussen oder davon betroffen sind. Kommunikation ist hier ein Werkzeug, kein eigenes Feld mehr. *(Performance Domain Stakeholders)* - **Ressourcen** (Resources) — Menschen, Material und Ausstattung planen, beschaffen und steuern. Dazu gehören Teamentwicklung, Kapazitätsplanung und der Umgang mit knappen, geteilten Ressourcen. *(Performance Domain Resources)* - **Risiko** (Risk) — Umgang mit Unsicherheit in beide Richtungen: Bedrohungen verringern, Chancen nutzen. Umfasst Identifikation, Bewertung, Reaktionsplanung und Überwachung. *(Performance Domain Risk)* ### Lebenszyklus - **Focus Areas** — Die fünf Focus Areas der 8. Edition folgen dem Lebenszyklus eines Vorhabens von der Initiierung über Planung, Ausführung sowie Überwachung und Steuerung bis zum Abschluss. Sie gehen aus den früheren Prozessgruppen hervor, sind aber nicht als starre Abfolge gemeint: Überwachung und Planung laufen fortwährend. *(Kapitel zu Focus Areas und Prozessen)* - **Prädiktiv, agil, hybrid** (Development Approaches) — Prädiktive Vorgehen planen den Umfang weitgehend vorab, agile liefern in kurzen Zyklen und passen den Umfang an, hybride kombinieren beides. Die Wahl hängt davon ab, wie stabil Anforderungen und Umfeld sind. Ein Rollout in die Fläche ist meist prädiktiv, die Pilotierung einer neuen Lösung profitiert von iterativem Vorgehen. *(Abschnitt zu Entwicklungsansätzen)* - **Rollierende Planung** (Rolling Wave Planning) — Nahe Zeiträume werden detailliert geplant, fernere grob. Der Detailhorizont wandert mit. Das spart Planungsaufwand dort, wo sich ohnehin noch vieles ändert. *(Performance Domain Schedule)* ### Risiko - **Risikoregister** (Risk Register) — Zentrale Liste aller identifizierten Risiken mit Ursache, Auswirkung, Bewertung, Reaktion, Verantwortlichem und Status. Ein Register lebt nur, wenn es regelmäßig überprüft wird. *(Performance Domain Risk)* - **Risikomatrix** (Probability and Impact Matrix) — Bewertung aus Eintrittswahrscheinlichkeit mal Auswirkung, meist auf einer Skala von 1 bis 5. Das Produkt ordnet Risiken in Klassen ein, etwa hoch, erhöht, mittel und gering. Wichtig ist eine eindeutige, schriftliche Skalendefinition, sonst bewertet jeder anders. *(Performance Domain Risk, Techniken der Risikobewertung)* - **Erwartungswert** (Expected Monetary Value) — Schadenshöhe mal Eintrittswahrscheinlichkeit. Macht Risiken monetär vergleichbar und hilft bei der Frage, ob eine Gegenmaßnahme ihr Geld wert ist. Setzt eine belastbare Schadensschätzung voraus. *(Quantitative Risikoanalyse)* - **Reaktionsstrategien** (Risk Response Strategies) — Für Bedrohungen: vermeiden, übertragen, mindern, akzeptieren oder eskalieren. Für Chancen: ausnutzen, teilen, verbessern, akzeptieren oder eskalieren. Eskalieren heißt, das Risiko liegt außerhalb der eigenen Entscheidungsbefugnis, etwa bei ungeklärter Finanzierung oder Zuständigkeit zwischen Organisationen. *(Performance Domain Risk)* - **Risikoverantwortlicher** (Risk Owner) — Eine benannte Person, die ein Risiko beobachtet und die Umsetzung der Reaktion sicherstellt. Ein Gremium oder eine Organisationseinheit als Owner führt oft dazu, dass sich niemand zuständig fühlt. *(Performance Domain Risk)* - **Frühwarnindikatoren** (Risk Triggers) — Messbare Signale, dass ein Risiko eintritt, bevor der Schaden sichtbar wird, zum Beispiel die Wochenleistung gegenüber dem Planwert. Mit festem Schwellwert und klarer Folgehandlung werden sie zu einem echten Steuerungsinstrument. *(Überwachung von Risiken)* - **Risiko oder Problem** (Risk vs. Issue) — Ein Risiko ist ein unsicheres Ereignis in der Zukunft, ein Problem (Issue) ist bereits eingetreten. Eingetretene Risiken wandern ins Problemmanagement, dort geht es um Lösung statt Wahrscheinlichkeit. *(Performance Domain Risk)* - **Reserven** (Contingency and Management Reserve) — Die Risikoreserve deckt bekannte Risiken und gehört zur Kostenbasis. Die Managementreserve deckt Unvorhergesehenes und wird außerhalb der Basis vom Management freigegeben. *(Performance Domain Finance)* ### Stakeholder - **Stakeholderregister** (Stakeholder Register) — Liste aller relevanten Stakeholder mit Rolle, Interessen, Einfluss, Haltung und geplanter Einbindung. Sie wird zu Beginn erstellt und bei Veränderungen fortgeschrieben. *(Performance Domain Stakeholders)* - **Einfluss-Interesse-Matrix** (Power/Interest Grid) — Einordnung in vier Felder: hoher Einfluss und hohes Interesse eng steuern, hoher Einfluss und geringes Interesse zufriedenstellen, geringer Einfluss und hohes Interesse informieren, beides gering beobachten. *(Techniken der Stakeholderanalyse)* - **Engagement-Bewertung** (Stakeholder Engagement Assessment Matrix) — Vergleicht die aktuelle Haltung eines Stakeholders mit der gewünschten, etwa von ablehnend über neutral bis unterstützend. Die Lücke bestimmt, wie viel Einbindungsaufwand nötig ist. *(Performance Domain Stakeholders)* - **Kommunikationsplan** (Communications Management Plan) — Legt fest, wer welche Information in welcher Form, wie oft und von wem erhält. Verhindert, dass wichtige Beteiligte widersprüchlich oder gar nicht informiert werden, etwa wenn mehrere Abstimmungsrunden mit demselben Auftraggeber nebeneinander laufen. *(Performance Domain Stakeholders)* ### Termine und Ressourcen - **Projektstrukturplan** (Work Breakdown Structure (WBS)) — Hierarchische Zerlegung des gesamten Projektumfangs in steuerbare Arbeitspakete. Was nicht im PSP steht, gehört nicht zum Projekt. Grundlage für Aufwand, Termine und Verantwortung. *(Performance Domain Scope)* - **Kritischer Pfad** (Critical Path Method) — Die längste Kette abhängiger Vorgänge ohne Puffer. Jede Verzögerung darauf verschiebt das Projektende. Es lohnt, den kritischen Pfad regelmäßig neu zu bestimmen, weil er sich verschieben kann, bis hin zu einem einzelnen Arbeitspaket mit Lieferproblem. *(Performance Domain Schedule)* - **Meilensteintrendanalyse** (Milestone Trend Analysis) — In der deutschen Praxis verbreitet: Zu festen Berichtsterminen wird die Prognose für jeden Meilenstein eingetragen. Steigende Linien zeigen früh, dass Termine rutschen. Im PMBOK nicht als eigene Technik geführt, passt aber zur Terminüberwachung. *(Ergänzung aus der deutschen PM-Praxis)* - **Kapazitätsplanung** (Resource Planning) — Abgleich von benötigtem und verfügbarem Aufwand über die Zeit. Realistische Planung zieht Urlaub, Krankheit und Linienaufgaben pauschal ab, statt mit voller Mannschaft zu rechnen. *(Performance Domain Resources)* - **Ressourcenabgleich und -glättung** (Resource Leveling and Smoothing) — Beim Abgleich werden Vorgänge verschoben, bis keine Ressource überlastet ist; das kann das Projektende verschieben. Bei der Glättung wird nur innerhalb vorhandener Puffer verschoben, das Ende bleibt. *(Performance Domain Schedule)* - **RACI-Matrix** (Responsibility Assignment Matrix) — Ordnet je Aufgabe zu, wer durchführt (Responsible), wer die Gesamtverantwortung trägt (Accountable), wer beraten (Consulted) und wer informiert wird (Informed). Je Aufgabe genau ein A. *(Performance Domain Resources)* ### Kosten und Leistungsmessung - **Earned Value Management** — Verbindet Umfang, Termin und Kosten. Drei Grundgrößen: Planwert (PV, was bis heute geplant war), Fertigstellungswert (EV, was tatsächlich geschafft wurde, bewertet zu Plankosten) und Istkosten (AC). Daraus lassen sich Abweichungen und Prognosen berechnen. *(Performance Domain Finance, Leistungsmessung)* - **SPI** (Schedule Performance Index) — SPI = EV ÷ PV. Werte unter 1 bedeuten Verzug, über 1 Vorsprung. Gegen Projektende nähert sich der SPI rechnerisch 1, auch wenn Termine verfehlt wurden; dann ist er allein wenig aussagekräftig. *(Leistungsmessung)* - **CPI** (Cost Performance Index) — CPI = EV ÷ AC. Unter 1 bedeutet: Für die erbrachte Leistung wurde mehr ausgegeben als geplant. Ein früh stabiler CPI ist ein verlässlicher Hinweis auf die Endkosten. *(Leistungsmessung)* - **EAC, ETC und VAC** (Estimate at Completion) — EAC ist die Prognose der Gesamtkosten, ETC der noch erwartete Restaufwand, VAC die erwartete Abweichung zum Budget. Eine gängige Formel ist EAC = Budget ÷ CPI, wenn die bisherige Kosteneffizienz anhält. *(Leistungsmessung)* - **Kostendach** (Not-to-exceed / Cost Ceiling) — Vertraglich vereinbarte Obergrenze der Vergütung. Kosten darüber trägt der Auftragnehmer, sofern keine Nachträge vereinbart werden. Eine Annäherung sollte früh und fortlaufend sichtbar gemacht werden. *(Performance Domain Finance, Beschaffung)* ### Scope und Änderungen - **Baseline** — Genehmigter Stand von Umfang, Terminen oder Kosten, gegen den gemessen wird. Änderungen an der Baseline laufen nur über die Änderungssteuerung, sonst verliert jede Abweichungsaussage ihre Grundlage. Typisches Warnsignal: In verschiedenen Dokumenten stehen unterschiedliche Mengen. *(Performance Domain Scope)* - **Scope Creep** — Unkontrollierte Erweiterung des Umfangs ohne Anpassung von Zeit, Budget und Ressourcen. Entsteht oft durch viele kleine, einzeln harmlose Zusagen oder Zusatzthemen, die keinen eigenen Posten in der Planung bekommen. *(Performance Domain Scope)* - **Änderungssteuerung** (Change Control) — Geregelter Weg für Änderungen: Antrag, Bewertung der Auswirkung auf Umfang, Termin, Kosten und Risiko, Entscheidung durch die befugte Stelle, Umsetzung und Dokumentation. *(Performance Domain Scope)* ### Governance und Steuerung - **Lenkungsausschuss** (Steering Committee) — Gremium, das über Ziele, Ressourcen und Eskalationen entscheidet und die Projektleitung trägt. Wirksam ist er nur mit Entscheidungsbefugnis und festen Fristen für Entscheidungen. *(Performance Domain Governance)* - **PMO** (Project Management Office) — Organisationseinheit, die Projekte mit Methoden, Werkzeugen, Berichtswesen und Ressourcenkoordination unterstützt oder steuert. In Großprojekten entlastet es die Projektleitung von Administration. Die 8. Edition behandelt das PMO deutlich ausführlicher als frühere Ausgaben. *(Abschnitt zum PMO)* - **Eskalation** (Escalation) — Übergabe einer Entscheidung an die nächsthöhere Ebene, wenn sie die eigenen Befugnisse übersteigt. Eine gute Eskalation beschreibt Sachverhalt, Auswirkung, Optionen, empfohlene Entscheidung und Frist. *(Performance Domain Governance)* - **Single Source of Truth** — Eine verbindliche, gepflegte Datenquelle für den Projektstand. Parallel geführte Listen erzeugen widersprüchliche Zahlen und kosten Abstimmungszeit. *(Ergänzung aus der Praxis, passt zu Governance)* ### Beschaffung und Vertrag - **Beschaffung im öffentlichen Sektor** (Procurement) — Im öffentlichen Umfeld prägt das Vergaberecht Zeitbedarf und Spielräume: Ausschreibungspflichten, Fristen und Grenzen bei Nachbeauftragungen. Die 8. Edition erweitert das Thema Beschaffung allgemein; die deutschen Rechtsgrundlagen gehören nicht dazu. *(Abschnitt zur Beschaffung)* - **EVB-IT** (Ergänzende Vertragsbedingungen für IT) — Standardisierte Vertragsbedingungen der öffentlichen Hand für IT-Leistungen, mit Typen etwa für Dienstleistung, Kauf oder Systemerstellung. Regeln unter anderem Vergütung, Abnahme und Mängelrechte. *(Keine PMBOK-Quelle, deutsche Vertragspraxis)* - **Nachtragsmanagement** (Claims and Change Orders) — Systematisches Erfassen, Begründen und Verhandeln von Mehrleistungen gegenüber dem Vertrag. Nachträge brauchen eine saubere Leistungsabgrenzung und zeitnahe Dokumentation. *(Abschnitt zur Beschaffung)* ### Abschluss und Übergabe - **Abnahme** (Acceptance) — Formale Bestätigung des Auftraggebers, dass die Leistung vertragsgemäß ist. Abnahmekriterien sollten früh und schriftlich feststehen, auch für zurückgestellte oder ausgegliederte Teile. *(Performance Domain Scope, Abschluss)* - **Projektabschluss** (Closing) — Geordnetes Beenden: Abnahme, Übergabe, finanzielle Schlussrechnung, Freigabe der Ressourcen, Archivierung und Lessons Learned. Offene Punkte werden benannt und an eine verantwortliche Stelle oder ein Folgeprojekt übergeben. *(Focus Area Abschluss)* - **Übergabe in den Betrieb** (Transition to Operations) — Überführung der Ergebnisse in den Regelbetrieb mit geklärten Prozessen, Zuständigkeiten, Dokumentation und Ressourcen. Wird oft zu spät geplant und dann vom Projekt weiter mitgetragen. *(Focus Area Abschluss)* - **Lessons Learned** — Gesammelte Erfahrungen, was funktioniert hat und was nicht, mit Empfehlungen für künftige Vorhaben. Am wirksamsten, wenn laufend statt nur am Ende gesammelt und in Folgeprojekten tatsächlich genutzt, etwa als Quelle für die Risikoidentifikation. *(Wissensmanagement)* ### PRINCE2-Bezug - **PRINCE2 und PMBOK** (PRINCE2) — PRINCE2 ist eine prozessorientierte Methode mit festen Rollen, Themen und Prozessen; PMBOK ist ein Standard, der beschreibt, was gutes Projektmanagement ausmacht. Beide ergänzen sich gut: PRINCE2 für das Wie der Steuerung, PMBOK für Techniken und Begriffe. *(Kein Teil des PMBOK Guide)* - **Lenkungsausschuss in PRINCE2** (Project Board) — Besteht aus Auftraggeber (Executive), Vertretung der Nutzenden (Senior User) und Vertretung der Lieferanten (Senior Supplier). Steuert nach dem Ausnahmeprinzip: Er greift ein, wenn Toleranzen überschritten werden. *(PRINCE2, Organisation)* - **Ausnahmebericht** (Exception Report) — Wird erstellt, wenn eine Toleranz für Zeit, Kosten, Umfang, Qualität, Risiko oder Nutzen voraussichtlich überschritten wird. Enthält Ursache, Folgen, Optionen und Empfehlung für den Lenkungsausschuss. Eine Risikoanzeige an die Leitung erfüllt denselben Zweck. *(PRINCE2, Fortschritt)* - **Offene Punkte in PRINCE2** (Issue: Request for Change, Off-Specification, Problem) — PRINCE2 unterscheidet Änderungsanträge, Spezifikationsabweichungen sowie Probleme und Bedenken. Alle laufen über das Issue-Register und eine geregelte Bewertung. *(PRINCE2, Änderungen)* - **Business Case** — Begründung, warum das Vorhaben sich lohnt, mit Nutzen, Kosten, Risiken und Optionen. In PRINCE2 muss die Rechtfertigung während der gesamten Laufzeit gegeben sein; ändern sich Kosten oder Nutzen erheblich, wird das Projekt angepasst oder beendet. *(PRINCE2, Business Case; PMBOK, Wertschöpfung)* ### Kosten und Leistungsmessung - **BAC** (Budget at Completion) — Das genehmigte Gesamtbudget der Leistungsmessbasis. Alle EVA-Kennzahlen beziehen sich auf den BAC; Reserven: Die Risikoreserve ist im BAC enthalten, die Managementreserve liegt darüber (5.6). *(Leistungsmessung, Finance Domain)* - **PV** (Planned Value) — Wert der bis zum Stichtag laut Baseline geplanten Arbeit, bewertet zu Plankosten. Ergibt über die Zeit aufgetragen die S-Kurve (3.3). Wird oft mit dem Budgetverbrauch verwechselt — PV ist geplante Leistung, nicht geplantes Ausgeben. *(Leistungsmessung)* - **EV** (Earned Value) — Wert der tatsächlich fertiggestellten Arbeit zu Planpreisen. Messregel festlegen (0/100, 50/50, mengenanteilig), sonst ist der EV eine Meinung. Der EV entkoppelt die Leistungsmessung von Einkaufspreisen und Ausgabetempo. *(Leistungsmessung)* - **AC** (Actual Cost) — Tatsächlich angefallene Kosten für die geleistete Arbeit. Erhebungsregel wichtig (Bestellung, Lieferung oder Mittelabfluss), im öffentlichen Dienst mit der Kämmerei abstimmen, sonst verzerrt der CPI. *(Leistungsmessung)* - **ETC** (Estimate to Complete) — Erwarteter Restaufwand bis Projektende, ETC = EAC − AC. Alternativ als Bottom-up-Neuschätzung des Restes, wenn die bisherige Effizienz kein guter Prädiktor mehr ist (3.10, Variante D). *(Leistungsmessung)* - **TCPI** (To-Complete Performance Index) — Kosteneffizienz, die der Rest bräuchte, um im Budget zu enden: (BAC − EV) ÷ (BAC − AC). Faustregel: TCPI über 1,10 ist mit dem bisherigen Team nicht realistisch — dann bleibt nur Umfang, Budget oder Termin anpassen (3.7). *(Leistungsmessung)* - **Earned Schedule** (Earned Schedule / SPI(t)) — Umrechnung des EV in erreichte Planzeit: der Zeitpunkt, an dem die PV-Kurve den aktuellen EV erreicht. SPI(t) = erreichte Planzeit ÷ tatsächliche Zeit läuft am Projektende nicht wie der SPI künstlich gegen 1 und zeigt Verspätung ehrlich in Zeiteinheiten (3.11). *(Leistungsmessung, Ergänzung der Praxis)* - **Fertigstellungsgrad-Regeln** (Progress Rules) — Festlegung, wann ein Arbeitspaket Wert zählt: 0/100 (bei Fertigstellung), 50/50 (bei Beginn und Fertigstellung), mengenanteilig (Istmenge ÷ Planmenge). Ohne feste Regel sind EV und SPI manipulierbar (3.2). *(Leistungsmessung)* ### Schätzung - **PERT / Dreipunkt** (Three-Point Estimating) — Erwartungswert E = (O + 4M + P)/6 aus optimistischer, realistischer und pessimistischer Schätzung; Streuung σ = (P − O)/6. Projekt-σ als Wurzel der Varianzsumme über den kritischen Pfad (2.7). *(Schätztechniken)* - **Analogieschätzung** (Analogous Estimating) — Schätzung aus einem vergleichbaren Vorhaben plus Zuschlag für Unterschiede. Schnell, aber nur so gut wie die Vergleichbarkeit — Abweichung vom Analogon schriftlich begründen (2.7). *(Schätztechniken)* - **Parametrische Schätzung** (Parametric Estimating) — Kennzahl × Menge, etwa Euro je gescannter Akte. Günstig für wiederholte Leistungen und als Plausibilitätscheck gegen Bottom-up-Summen (2.7). *(Schätztechniken)* - **Bottom-up-Schätzung** (Bottom-up Estimating) — Summe der Schätzungen aller Arbeitspakete des Strukturplans. Genau, aber aufwendig und tendiert zu Optimismus am Rand — deshalb gegen Analogie und Parametrik spiegeln (2.1, 2.7). *(Schätztechniken)* ### Agile Praxis - **Sprint** — Feste Zeitbox (1–4 Wochen) mit lieferfähigem Ergebnis am Ende. Der Sprint-Umfang wird im Planning festgelegt und während des Sprints nicht vergrößert — Änderungen gehen ins nächste Planning (7.1). *(Agile Praxis)* - **Backlogs** (Product / Sprint Backlog) — Geordnete Liste aller Anforderungen (Product Backlog) bzw. des Sprint-Umfangs (Sprint Backlog). Ordnung ist Priorisierung, kein Zeitplan — die Menge je Sprint ergibt sich aus der Velocity (7.1, 4.3). *(Agile Praxis)* - **Definition of Done** — Gemeinsamer Fertigkeitsbegriff des Teams (getestet, dokumentiert, abgenommen). Erst DoD-reif zählt Arbeit in Velocity und EV — sonst wird Fertiges doppelt gezählt (7.5). *(Agile Praxis)* - **Velocity** — Summe der fertiggestellten Points je Sprint. Messgröße mit Streuung, keine Vorgabe — planen mit Bandbreite, zusagen mit Perzentil (4.3, 7.2). *(Agile Praxis)* - **Burndown-Chart** (Burndown Chart) — Verbleibender Aufwand über der Zeit, mit Soll-Linie. Abweichungsfläche = Rückstand; Fortschreibung der Ist-Kurve = Endprognose (4.1, 4.2). *(Agile Praxis)* - **Burn-up-Chart** (Burn-up Chart) — Zwei aufsteigende Kurven: Gesamtaufwand (inklusive genehmigter Änderungen) und Fertiges. Macht den Unterschied zwischen „langsamer geworden“ und „größer geworden“ sichtbar (4.6). *(Agile Praxis)* - **Monte-Carlo-Prognose** (Monte Carlo Simulation) — Tausende Zufallsläufe aus historischen Messwerten (z. B. Velocity) statt einer einzigen Durchschnittsrechnung. Ergebnis ist eine Verteilung: P50 zum Steuern, P85 zum Zusagen (7.2). *(Agile Praxis, quantitative Analyse)* - **Timebox** — Fester Zeitrahmen, in dem eine Aufgabe bearbeitet wird — Ergebnis wird geliefert, Umfang notfalls gekürzt. Gegenteil der Scopebox (fester Umfang, flexible Zeit); Sprints sind Timeboxen (7.1). *(Agile Praxis)* - **Refinement** (Backlog Refinement) — Fortlaufendes Zerlegen, Klären und Schätzen kommender Backlog-Einträge mit dem Team. Verhindert das Planning als erste Detaildiskussion (7.1). *(Agile Praxis)* ### Termine und Ressourcen - **Balkenplan** (Gantt Chart) — Vorgänge als Balken über einer Zeitskala, abgeleitet aus dem Netzplan. Zeigt Kommunikation; für Steuerung müssen kritischer Pfad und Puffer sichtbar bleiben (2.2). *(Schedule Domain)* - **Meilenstein** (Milestone) — Ereignis der Dauer null mit objektiv prüfbarem Abschlusskriterium. Steuerungsinstrument der Auftraggeberseite; Entwicklung über die Meilensteintrendanalyse (2.5, 4.4). *(Schedule Domain)* - **Arbeitspaket** (Work Package) — Kleinste steuerbare Einheit des Strukturplans mit genau einem Verantwortlichen, Ergebnis, Aufwand und Termin. 100-%-Regel: Die Summe der Pakete ist das Projekt (2.1). *(Scope Domain)* - **Gesamtpuffer** (Total Float / Slack) — Zeit, um die ein Vorgang verschoben werden kann, ohne das Projektende zu gefährden: GP = LS − ES. Puffer gehört dem Weg, nicht dem Vorgang — Verbrauch neu rechnen (2.3, 2.4). *(Schedule Domain)* ### Grundlagen - **Kick-off** — Gemeinsamer Start: Auftrag, Ziele, Rollen, Spielregeln und erster Plan werden vorgestellt und akzeptiert. Abgeschlossen mit Charta-Unterzeichnung — danach ist das Projekt offiziell unterwegs (1.2). *(Focus Area Initiierung)* - **RAG-Status** (Red Amber Green) — Ampelbewertung im Bericht — nur mit vorab vereinbarten Schwellen und je Bereich einem Begründungssatz mit Zahl gültig (6.1, 6.2). *(Berichtspraxis)* - **Toleranzen** (Tolerances) — Vorab vereinbarter Spielraum für Zeit, Kosten, Umfang, Qualität, Risiko und Nutzen, innerhalb dessen die Projektleitung autonom steuert. Überschreitung triggert Ausnahmebericht/Eskalation — PRINCE2 nennt das Ausnahmeprinzip (6.3). *(PRINCE2, Fortschritt; PMBOK Governance)* - **Projektcontrolling** (Project Controlling) — Fortlaufender Soll-Ist-Vergleich mit dem Ziel früher Gegensteuerung: Baseline schaffen, Ist messen, vergleichen, Ursachen klären, entscheiden, Wirkung prüfen (1.1). *(eigene Zusammenfassung der Focus Areas)* ### Scope und Änderungen - **Change Request** (Change Request (CR)) — Formalisierter Änderungsantrag mit Begründung und Bewertung von Kosten, Termin, Risiko und Nutzen; Entscheidung durch die nach Volumen befugte Stelle, danach Baseline-Anpassung oder dokumentierte Ablehnung (6.5). *(Scope Domain, Änderungssteuerung)* - **MoSCoW** (MoSCoW Prioritization) — Priorisierung in Muss/Soll/Kann/Won’t-this-time. Prüfregel: Muss muss allein im Budget lieferbar sein, sonst ist der Umfang zu groß (2.6). *(Priorisierungstechniken)* ### Governance und Steuerung - **Entscheidungslog** (Decision Log) — Fortlaufende Tabelle von weitreichenden Entscheidungen mit Datum, Gremium, Begründung und Wirkung. Erklärt bei Prüfung oder Personalwechsel, warum der Plan heute so aussieht (6.4). *(Governance-Praxis)* --- *„PM-Nachschlagewerk und Steuerungshilfe“ — eigenständig verfasste Arbeitshilfe, keine Wiedergabe des PMBOK Guide. PMBOK ist eine eingetragene Marke des Project Management Institute. Alle Rechenbeispiele sind fiktiv („E-Akte 2026“). Interaktive Fassung: *