PM-Nachschlagewerk und Steuerungshilfe

1Grundlagen: 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.

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.

1.3 Ziele nach SMART

Was ist es? Prüfmaßstab für Zielformulierungen: Spezifisch, Messbar, Akzeptiert (durch Auftraggeber), Realistisch, Terminiert. 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).

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.

1.5 RACI-Matrix

Was ist es? Tabelle, die je Aufgabe/Arbeitspaket genau eine Person Accountable (gesamte Verantwortung, genau eine je Aufgabe), ein oder mehrere Responsible (durchführend), Consulted (vor Entscheidung zu hören) und Informed (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).

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

2Planung: 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.

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.

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.

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):

Schritt 1 — Vorwärtsrechnung (früheste Termine)

Schritt 2 — Rückwärtsrechnung (späteste Termine)

Schritt 3 — Puffer und kritischer Pfad

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

2.6 Anforderungen gewichten: MoSCoW

Was ist es? Priorisierung in Muss (Lieferung ohne Muss gilt als Misserfolg), Soll (wichtig, Ersatz möglich), Kann (nice-to-have), Won't-this-time (bewusst diesmal nicht). Regel: Die Muss-Anforderungen müssen allein, innerhalb des Budgets, lieferbar sein — sonst ist der Umfang zu groß.

2.7 Schätzverfahren

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.

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.

3Earned-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 €.

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:

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):

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

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.

3.5 Indizes: SPI und CPI

3.6 Prognosen: EAC, ETC, VAC

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.

3.8 Das Großbeispiel als Monatsreport — alle Kennzahlen auf einen Blick

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:

3.10 EAC-Varianten — vier Annahmen, vier Endkosten

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.

4Burndown, 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.

4.2 Burndown auswerten — das Beispiel gerechnet

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.

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.

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.

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

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

5Risikomanagement: 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

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

5.4 Die 5×5-Matrix (Heatmap)

5.5 Behandlungsstrategien mit Beispielen

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.

5.7 Überwachen: Frühwarnindikatoren mit Folgeaktion

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.

6Reporting 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)

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 …“).

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

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.

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.

6.6 Berichtswesen: Rhythmus und Zielgruppen

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

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.

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

AAnhang: 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

Nachrechnen mit eigenen Zahlen: EVA-Rechner

A.2 Checklisten (im Browser abhakbar — ohne Speicherung)

A.3 Schwellen und Eskalation als Kompendium

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

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.

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)

8Glossar: 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:

WWerkzeuge: vier interaktive Rechner

Alle Rechner laufen ohne Internet, ohne Server, direkt in dieser Datei. Eingaben akzeptieren Komma und Punkt als Dezimaltrenner sowie Tausenderpunkte (z. B. „120.000“ oder „52,5“). Nichts wird gespeichert — beim Neuladen sind die Felder wieder auf Voreinstellung.