Glossar

4-Level-Certification-System der IPMA. Vier Stufen (A–D) zertifizieren Projektmanagement-Kompetenz abgestuft nach Verantwortung und Erfahrung.

Level D (Certified Project Management Associate) prüft Wissen. Level C (Certified Project Manager) erfordert eigenverantwortliche Projektleitung. Level B (Certified Senior Project Manager) verlangt Komplexität und Führung von Teilprojektleitungen. Level A (Certified Projects Director) deckt die strategische Leitung ganzer Projekt-, Programm- und Portfoliolandschaften ab. Rezertifizierung pflichtig.

Die universelle Prioritäten-Hierarchie der Luftfahrt für Krisen: Aviate (stabilisieren), Navigate (Kurs bestimmen), Communicate (informieren).

Die goldene Regel der Luftfahrt für Prioritäten in Krisensituationen: **Aviate** (Flugzeug fliegen / System stabilisieren), **Navigate** (Kurs bestimmen / Lösung finden), **Communicate** (informieren). Die Reihenfolge ist nicht verhandelbar — erst wenn die vorherige Ebene stabil ist, kommt die nächste. Im Projekt: erst die akute Störung eindämmen, dann den Lösungsweg planen, dann Stakeholder informieren.

Differenz zwischen Soll (Basisplan) und Ist — in Tagen bei Terminen, in € bei Kosten. Positiver Wert = später/teurer als geplant, negativer = früher/günstiger.

Die Abweichung (englisch: Variance) ist der zentrale Messwert der Steuerung: Soll minus Ist, getrennt für Termine und Kosten. In der Abweichungstabelle stehen die geplanten Werte (aus dem Basisplan) neben den aktuellen, daneben die Differenz. Ein positiver Wert bedeutet "später als geplant" oder "teurer als geplant", ein negativer bedeutet "früher" oder "günstiger". Wichtig zu verstehen: **Termin- und Kostenabweichung sind unabhängig**. Ein Projekt kann spät und trotzdem im Budget sein, oder pünktlich und zu teuer. Solange sich nur Termine verschieben, Arbeit und Sätze aber gleich bleiben, ändern sich die Gesamtkosten nicht — der Vorgang wird später fertig, kostet aber dasselbe. Voraussetzung für jede Abweichungsanzeige: ein gesetzter Basisplan.

2001 formulierte Grundlage agilen Arbeitens mit vier Werten und zwölf Prinzipien — das gemeinsame „Warum" hinter allen agilen Frameworks.

Das Agile Manifest wurde 2001 von 17 Software-Praktikern formuliert und begründet, warum agil so arbeitet, wie es arbeitet — etwa, dass Menschen und Interaktionen wichtiger sind als Prozesse und Werkzeuge. Die vier Werte und zwölf Prinzipien werden in Modul 2 vertieft. Quelle: agilemanifesto.org.

Werteorientierte Grundhaltung, auf der agiles Arbeiten beruht: Kundennutzen im Fokus, iteratives Lernen, Zusammenarbeit, Anpassungsfähigkeit, Transparenz.

Das agile Mindset ist die Denkweise, ohne die jedes agile Framework Mechanik bleibt: Kundennutzen vor Output, in kurzen Zyklen lernen und liefern, gemeinsam statt nebeneinander arbeiten, Veränderung als Chance nutzen, Offenheit schafft Vertrauen. Agilität beginnt mit einer Denkweise, nicht mit einem Framework.

Werkzeug aus PRINCE2 Agile, das einschätzt, wie viel Agilität im Projektumfeld sinnvoll ist — basierend auf Faktoren wie Vertrauen, Stabilität und Vorhersagbarkeit.

Der Agilometer ist kein simples Ja/Nein, sondern ein Bild aus mehreren Faktoren: Wie viel Vertrauen besteht im Team und zu den Stakeholdern? Wie stabil sind Anforderungen und Technologie? Wie vorhersagbar ist das Umfeld? Ist die Reife niedrig, rät der Agilometer zu weniger Agilität — eine ehrliche Reality-Check-Schicht vor dem agilen Vorgehen.

Überprüfbare Bedingungen, wann eine User Story als erfüllt gilt. Verbreitetes Muster: Given / When / Then.

Akzeptanzkriterien machen die Erwartung an eine Story konkret und überprüfbar — sie sind Bestandteil der Story, nicht erst nachträglich erfunden. Das Given/When/Then-Muster trennt sauber: Ausgangssituation (Given), auslösende Aktion (When), erwartete Folge (Then).

Beschreibt, wie zwei Vorgänge zusammenhängen — Project kennt vier Typen: Ende-Anfang (EA, Standard), Anfang-Anfang (AA), Ende-Ende (EE), Anfang-Ende (AE).

Eine Anordnungsbeziehung (englisch: Task Dependency, auch Verknüpfung) verbindet zwei Vorgänge logisch miteinander. Project kennt vier Typen: **Ende-Anfang (EA)** — der Nachfolger beginnt, wenn der Vorgänger endet, das ist die natürliche Reihenfolge und der Standard für fast alle Fälle. **Anfang-Anfang (AA)** — beide starten gemeinsam, praktisch für Parallelisierung. **Ende-Ende (EE)** — beide enden gemeinsam, für synchronisierte Abschlüsse. **Anfang-Ende (AE)** — eine Rarität, der Nachfolger endet, wenn der Vorgänger beginnt. Über den Zeitabstand (Lead/Lag) kann eine Verknüpfung Wartezeit oder Überlappung tragen. Eingestellt im Vorgangsdialog → Reiter Vorgänger.

Bestimmt die Darstellungsform der Plandaten — z. B. Gantt, Kalender, Netzplan, Ressourcennutzung. Ändert *wie* die Daten gezeigt werden, nicht *welche*.

Eine Ansicht (englisch: View) ist eine bestimmte Darstellungsform der Plandaten in Microsoft Project. Das Gantt-Diagramm ist die Standardansicht; daneben gibt es u. a. den Kalender (Vorgänge nach Tagen/Wochen), den Netzplan (Vorgänge als Knoten mit Abhängigkeits-Pfeilen) und die Ressourcennutzung (Auslastung über die Zeit). Alle Ansichten greifen auf dieselbe Datenbasis zu — du veränderst nur die Sicht, nicht die Daten. Die Ansicht ist dabei klar zu unterscheiden von Berichten/Dashboards: Ansichten sind die Arbeitssicht *im* Plan, Berichte sind die aufbereitete Außendarstellung (Thema von Modul E9).

Reiner Aufwand in Personenzeit — wie viele Stunden jemand am Vorgang Hand anlegen muss. Unabhängig vom Zeitraum, über den die Arbeit verteilt ist.

Die Arbeit (englisch: Work) ist eine der drei Kerngrößen, mit denen Microsoft Project rechnet — neben Dauer und Einheiten. Sie beschreibt den reinen Aufwand: wie viele Stunden tatsächlich jemand am Vorgang arbeiten muss. Wichtig: Arbeit ist nicht dasselbe wie Dauer. Eine Vollzeit-Ressource (100 %) schafft in 5 Tagen 40 Stunden Arbeit — hier scheinen Dauer und Arbeit zusammenzufallen ("die 100-%-Falle"). Bei einer 50-%-Ressource braucht dieselbe Arbeit aber 10 Tage. Verbunden über die Formel: Arbeit = Dauer × Einheiten (× 8 h/Tag).

Flugsicherung / Flugverkehrskontrolle. Im Projekt entspricht ATC dem Management oder Stakeholdern, die strategische Rahmenbedingungen vorgeben.

Die Flugsicherung koordiniert den Luftraum, erteilt Freigaben und unterstützt bei Notfällen. Im Projektkontext entspricht ATC dem **Management oder Stakeholdern**, die strategische Rahmenbedingungen vorgeben und zwischen verschiedenen "Flügen" (Projekten) koordinieren. Wichtig: Der Pilot hat an Bord das letzte Wort — analog hat der Projektleiter die operative Entscheidungshoheit.

Eingefrorener Schnappschuss des Plans (Soll-Stand): Termine, Aufwände und Kosten zum Zeitpunkt des Einfrierens. Wird als Vergleichsmaßstab für den späteren Soll-Ist-Abgleich gebraucht.

Der Basisplan (englisch: Baseline) ist ein eingefrorener Schnappschuss deines Plans zu einem bestimmten Zeitpunkt — typischerweise gesetzt, bevor die Umsetzung beginnt. Er konserviert alle geplanten Termine (Anfang/Ende), Aufwände (Dauer und Arbeit) und Kosten als unveränderlichen Soll-Stand. Während die laufende Planung sich durch Fortschritt und Änderungen weiterbewegt (das Ist), bleibt der Basisplan stehen — und genau diese Differenz macht den Soll-Ist-Abgleich möglich. Festgelegt wird er über Projekt → Basisplan festlegen. Wichtig: ohne Basisplan kein Vergleichsmaßstab. Wer das Einfrieren vergisst, sieht später in allen Abweichungsspalten nur Nullen, weil Project keinen Soll-Wert kennt, gegen den es das Ist halten könnte. Project erlaubt bis zu 11 Basispläne (Basisplan plus Basisplan 1 bis 10) — etwa für Re-Baselining nach genehmigten Änderungen.

Moderne, grafische Auswertung in Project mit Diagrammen und Kennzahlen — eine Verdichtung der Plandaten zu einer Aussage. Reine Ansicht, verändert den Plan nicht.

Ein Bericht (englisch: Report) in Microsoft Project ist eine grafische Auswertung der Plandaten — mit Diagrammen, Kennzahlen-Leisten und kompakten Tabellen. Project bringt eine Reihe fertiger Berichte mit, geordnet nach Kategorien: Dashboards, Ressourcen, Kosten, Vorgänge in Bearbeitung. Eingestellt werden sie über den Reiter **Bericht** in der Menüleiste. Wichtig zur Einordnung: Berichte erzeugen keine neuen Daten, sie sind reine Ansichten auf den Plan — wer einen Bericht öffnet, verändert nichts. Berichte sind auch nicht starr: über die Feldliste und die Berichtstools lassen sie sich anpassen (Felder wählen, filtern, gruppieren). Faustregel: ein guter Bericht beantwortet genau eine Frage, nicht zehn.

Vor- und Nachbesprechung. Briefing: alle Infos und Risiken vor dem Flug/Projekt teilen. Debriefing: nach dem Meilenstein - was lief gut, was verbessern? Lernen statt Schuldzuweisungen.

**Briefing:** Strukturierte Vorbesprechung vor dem Flug/Projekt. Alle relevanten Informationen werden geteilt, Rollen geklärt, Risiken besprochen. **Debriefing:** Nachbesprechung direkt nach dem Flug/Meilenstein. Fokus auf: Was lief gut? Was können wir verbessern? Keine Schuldzuweisungen — Lernen steht im Vordergrund.

Laufende geschäftliche Rechtfertigung eines Projekts. In PRINCE2 ist er Taktgeber — trägt er nicht mehr, wird das Projekt beendet, auch mittendrin.

Der Business Case beschreibt, warum sich ein Vorhaben lohnt: Nutzen, Kosten, Risiken, erwartete Erträge. In PRINCE2 ist er kein einmaliges Dokument am Anfang, sondern eine fortlaufende Prüfung an jedem Phasenübergang. Bricht die Rechtfertigung weg, wird abgebrochen — eine bewusst harte Konsequenz, die schlechte Projekte früh stoppt.

Einmotoriges Hochdecker-Schulflugzeug von Cessna. Mit über 44.000 gebauten Exemplaren das meistproduzierte Flugzeug der Welt — typische PPL-Trainingsmaschine.

Geschlossene Kommunikationsschleife: Sender gibt Anweisung, Empfänger wiederholt sie, Sender bestätigt. Verhindert Missverständnisse.

Kommunikationstechnik zur Vermeidung von Missverständnissen: **1.** Sender gibt Anweisung, **2.** Empfänger wiederholt die Anweisung, **3.** Sender bestätigt oder korrigiert. Beispiel: "Bitte Budget-Report erstellen." → "Budget-Report erstellen, verstanden." → "Korrekt." Erst dann ist die Kommunikation abgeschlossen.

Trainingskonzept aus den 1970er-Jahren für Teamführung, Kommunikation und Fehlerkultur im Cockpit — über Hierarchien hinweg. In PILOT auf Projektteams übertragen.

In den 1970er-Jahren entwickeltes Trainingskonzept nach mehreren Flugzeugunglücken durch Kommunikationsfehler. Kernprinzipien: **Klare Rollenverteilung**, **offene Kommunikation unabhängig von Hierarchie**, **gegenseitige Überwachung** und **Entscheidungsfindung im Team**. CRM hat die Luftfahrt-Sicherheit revolutioniert und wird heute in vielen Hochrisiko-Branchen eingesetzt — Medizin, Kernkraftwerke, Schifffahrt.

Verdichtete Übersicht mit mehreren Aussagen auf einer Seite — Kacheln, Diagramme, Tabellen zusammen. In Project eine Bericht-Kategorie (z. B. Projektübersicht).

Ein Dashboard ist die verdichtete Form eines Berichts: mehrere Aussagen sind nebeneinander auf einer Seite gebündelt — typisch mit Kacheln (z. B. Gesamtfortschritt), Diagrammen und kurzen Tabellen. In Microsoft Project gibt es Dashboards als eigene Kategorie im Bericht-Reiter; die wichtigste ist die **Projektübersicht** (Bericht → Dashboards → Projektübersicht). Sie zeigt auf einen Blick: Gesamtfortschritt, fällige Meilensteine, verspätete Vorgänge und Fortschritt je Phase. Dashboards eignen sich besonders für die Kommunikation nach außen — sie sind die Sprache für Stakeholder, während die Vorgangstabelle die Sprache des Planers bleibt.

Verstrichene Arbeitszeit im Kalender von Anfang bis Ende des Vorgangs — wie lange sich die Sache hinzieht. Unabhängig davon, wie viel zwischendrin gearbeitet wird.

Die Dauer (englisch: Duration) ist eine der drei Kerngrößen der Project-Rechenlogik. Sie misst die verstrichene Arbeitszeit im Kalender — von Anfang bis Ende des Vorgangs. Project rechnet in Arbeitstagen (Wochenende und Feiertage werden übersprungen, siehe Projektkalender aus E2). Dauer ist nicht gleich Arbeit: Eine 50-%-Ressource an einem 40-Stunden-Vorgang braucht 10 Tage Dauer, nicht 5. Steht hinter der Dauer ein Fragezeichen ("3 Tage?"), ist sie ein Schätzwert. Verbunden über die Formel: Arbeit = Dauer × Einheiten (× 8 h/Tag).

Gemeinsame Kriterien, wann ein Increment „fertig" ist — Commitment des Increments in Scrum.

Die Definition of Done sorgt für Transparenz darüber, was „fertig" bedeutet: Qualitätskriterien, Tests, Dokumentation, Auslieferbarkeit. Ohne sie wandert „fertig" mit der Tagesform; mit ihr ist jedes Increment einheitlich überprüfbar. Sie kann pro Organisation oder Team unterschiedlich aussehen.

Gemeinsame Kriterien, wann eine User Story bereit für den Sprint ist — das Gegenstück zur Definition of Done.

Während die Definition of Done klärt, wann etwas „fertig" ist, definiert die Definition of Ready, wann etwas überhaupt in einen Sprint darf: Ziel und Nutzen klar, Akzeptanzkriterien vorhanden, grob geschätzt, Abhängigkeiten bekannt, nötige Informationen verfügbar. So vermeidet ein Team, im Sprint an unklaren Stories zu scheitern.

Wie viel Kapazität einer Ressource auf einen Vorgang fällt — als Prozentsatz. 100 % = Vollzeit, 50 % = halbe Kapazität.

Die Einheiten (englisch: Units) sind die dritte Kerngröße der Project-Rechenlogik. Sie geben an, wie viel der Kapazität einer Ressource auf den Vorgang fällt — als Prozentsatz (Standard) oder als Dezimalzahl. 100 % bedeutet Vollzeit, 50 % halbe Kapazität, 200 % zwei Vollzeit-Kräfte. Steigen die Einheiten einer Ressource über 100 %, ist sie überlastet — Project zeigt das mit einem roten Indikatorsymbol. Verbunden über die Formel: Arbeit = Dauer × Einheiten (× 8 h/Tag).

Erkenntnis aus Erfahrung — das Fundament von Scrum: Transparenz, Überprüfung und Anpassung.

Empirie heißt: Wissen entsteht aus Beobachtung, nicht aus reiner Vorab-Planung. Scrum stützt sich auf drei Säulen: Transparenz (alle sehen denselben, ehrlichen Stand), Überprüfung (regelmäßig prüfen, wo man steht) und Anpassung (auf Basis dessen nachsteuern). Dieses Fundament macht Scrum zum Gegenentwurf zur sequenziellen Vorab-Planung aus Teil B.

Ein großes Thema oder ein Geschäftswert, der in kleinere Einheiten (Features und User Stories) zerlegt wird.

Epics stehen ganz oben in der agilen Anforderungshierarchie: zu groß, um in einem Sprint umgesetzt zu werden, aber zu wertvoll, um sie zu übersehen. Sie werden über die Zeit zu Features und User Stories zerlegt, bis die Einheiten umsetzbar und wertbringend sind.

Bildliche Darstellung der drei IPMA-Kompetenzbereiche im Zusammenspiel rund um die handelnde Person.

Im Eye of Competence umschließen People, Practice und Perspective die Person in der Mitte. Die Metapher betont: Projektkompetenz ist kein Wissensgebiet, sondern das integrierte Können einer Person — nicht abgrenzbar in einzelne Schubladen.

Aufgabenbereich in Project, der erscheint, wenn du in einen Bericht klickst. Hier wählst du die Felder, filterst, gruppierst oder änderst die Gliederungsebene.

Die Feldliste (englisch: Field List) ist der Aufgabenbereich, der beim Bearbeiten eines Berichts rechts aufklappt. Sie ist das Werkzeug zum Anpassen: hier wählst du, welche Felder der Bericht zeigt (Spalten in Tabellen, Datenreihen in Diagrammen), filterst die Daten, gruppierst nach Kategorien oder änderst die Gliederungsebene (z. B. nur Phasen statt einzelne Vorgänge). Zusammen mit den **Berichtstools** im Menüband (Aussehen, Diagrammtypen, Format) sind die fertigen Berichte damit ein Startpunkt, kein starres Bild. Pragmatische Empfehlung: einen fertigen Bericht öffnen, in die Feldliste klicken und auf das kürzen, was die Zielgruppe wirklich braucht.

Blendet Zeilen nach einem Kriterium ein/aus (z. B. nur Meilensteine). Die Daten bleiben erhalten — der Filter löscht nicht, er blendet nur aus.

Ein Filter in Microsoft Project blendet Vorgänge nach einem Kriterium aus der Anzeige aus — z. B. "nur Meilensteine", "nur noch nicht abgeschlossene Vorgänge" oder "nur kritische Vorgänge" (kritisch im Sinne des kritischen Pfads, der in Modul E5 erklärt wird). Wichtig: Ein Filter **löscht nicht**, er blendet nur aus. Die ausgeblendeten Vorgänge bleiben vollständig im Plan und sind sofort wieder da, sobald der Filter auf "Kein Filter" steht. Du erkennst einen aktiven Filter an springenden Zeilennummern und am Hinweis "Filter angewendet" in der Statusleiste.

Kernprinzip von PRINCE2 Agile: Zeit, Kosten und Qualität werden fixiert — der Umfang bleibt flexibel. Termingerecht das Wichtigste liefern, statt Termine zu verschieben oder Qualität zu opfern.

PRINCE2 Agile wendet Fix & Flex auf die sechs Leistungsdimensionen an. Fix bleiben Zeit, Kosten und Qualität; flexibel sind Umfang, Risiko und Nutzen — letztere werden aktiv gesteuert. So entsteht früh ein nutzbares Ergebnis, und der Kunde bekommt zuerst, was er wirklich braucht.

Eine von fünf Gruppierungen, in denen die rund 40 nicht-präskriptiven Prozesse der PMBOK-8-Ausgabe gebündelt sind.

Die 8. Ausgabe (2025) bringt nach dem prinzipien-getriebenen Schnitt der 7. Ausgabe Prozesse maßvoll zurück: rund 40 Prozesse, gebündelt in fünf Focus Areas. Die Prozesse sind ausdrücklich nicht-präskriptiv — sie geben Orientierung, ohne den Ablauf festzulegen.

Einer der fünf Bereiche in PRINCE2 Agile, die beim Tailoring besondere Aufmerksamkeit brauchen: Agilometer, Anforderungen, Reichhaltige Kommunikation, Häufige Lieferungen, Agile Verträge.

Während die Verhaltensweisen die Haltung beschreiben, markieren die Fokusbereiche konkrete Stellschrauben: Wie schätzen wir die Reife ein (Agilometer), wie arbeiten wir mit Anforderungen, wie kommunizieren wir reichhaltig, wie liefern wir häufig und wie gestalten wir Verträge agil-kompatibel? Diese fünf Bereiche entscheiden in der Praxis darüber, ob das agile Tailoring trägt.

Von der Lufthansa entwickeltes Entscheidungsmodell: Facts, Options, Risks, Decision, Execution, Check. Zwingt zu strukturiertem Vorgehen auch unter Stress.

Von der Deutschen Lufthansa entwickeltes Entscheidungsmodell: **F**acts (Fakten sammeln), **O**ptions (Optionen entwickeln), **R**isks (Risiken bewerten), **D**ecision (Entscheidung treffen), **E**xecution (Umsetzung), **C**heck (Wirkung prüfen). Zwingt zu strukturiertem Vorgehen auch unter Stress.

Ein konkreter, strukturierter Handlungsrahmen — in der agilen Welt z. B. Scrum, Kanban, XP, SAFe, LeSS oder Nexus. Setzt das Manifest in die Praxis um.

Ein Framework ist die oberste Ebene der drei agilen Schichten (Mindset, Manifest, Framework): Es gibt Rollen, Events, Artefakte und Regeln, mit denen ein Team agil arbeiten kann. Ein Framework ohne Mindset bleibt Mechanik; ein Mindset ohne Framework bleibt oft beliebig.

Binäre Fortfahren/Abbrechen-Entscheidung an kritischen Meilensteinen. Klare Kriterien vorab definieren — und sich daran halten.

Kritische Entscheidungspunkte, an denen binär entschieden wird: Weitermachen oder Abbrechen. Vor dem Flug werden klare **Go/No-Go-Kriterien** definiert (z.B. Wetter, technischer Zustand). Im Projekt: Definiere vor kritischen Meilensteinen, welche Bedingungen erfüllt sein müssen — und halte dich daran.

Deutsche Gesellschaft für Projektmanagement — das deutsche Mitglied der IPMA, Träger der ICB4 und der 4-L-C-Zertifizierungen in Deutschland.

Die GPM ist der größte deutsche Fachverband im Projektmanagement. Sie bringt den internationalen IPMA-Standard nach Deutschland, organisiert die Zertifizierungen nach 4-L-C und pflegt die deutschsprachige Fassung der ICB4.

Bewusste Kombination klassischer und agiler Elemente in einem Projekt — etwa klassische Steuerung über agiler Umsetzung.

Hybride Ansätze entstehen nicht zufällig: Sie verbinden gezielt Struktur und Klarheit (klassisch) mit Flexibilität und Anpassungsfähigkeit (agil). Die bekanntesten Vertreter sind PRINCE2 Agile (Governance über agiler Lieferung) und der agile Pfad von HERMES. Risiko: das „Water-Scrum-Fall"-Muster, bei dem ein agiles Team zwischen starren Phasen eingequetscht wird.

Das Spektrum von rein klassisch über hybrid bis rein agil — reale Projekte liegen selten an den Extremen, sondern irgendwo dazwischen.

Auf dem Hybrid-Kontinuum lassen sich die bekannten Ansätze verorten: reiner Wasserfall ganz links (stabil und planbar), PRINCE2 Agile und HERMES Hybrid in der Mitte, „PILOT + Scrum" als ausgearbeitetes Beispiel, reines Scrum ganz rechts (dynamisch und unsicher). Wo ein Projekt liegt, entscheidet der Kontext — der Agilometer aus B8 hilft bei der Verortung.

Individual Competence Baseline 4 — der internationale Kompetenzstandard der IPMA, seit 2016 gültig. Beschreibt rund 28 Kompetenzelemente in drei Bereichen.

Die ICB4 ist das Herzstück des IPMA-Ansatzes: Statt Prozesse oder Wissensgebiete beschreibt sie Kompetenzen — was eine Person können muss, um Projekte, Programme oder Portfolios erfolgreich zu führen. Die rund 28 Elemente gliedern sich in People, Practice und Perspective.

Pilot-Selbstcheck vor jedem Flug: Illness, Medication, Stress, Alcohol, Fatigue, Emotion. Ehrliche Einschätzung der eigenen Leistungsfähigkeit.

Checkliste zur ehrlichen Selbsteinschätzung der eigenen Leistungsfähigkeit vor wichtigen Entscheidungen.

Das nutzbare, integrationsfähige Arbeitsergebnis am Ende eines Sprints. Trägt das Commitment „Definition of Done".

Ein Increment ist ein konkreter Schritt in Richtung Product Goal — fertig im Sinne der Definition of Done und sofort nutzbar. In einem Sprint kann es ein oder mehrere Increments geben; jedes muss unabhängig auslieferbar sein. Mehrere Increments bauen iterativ aufeinander auf.

Qualitätsraster für gute User Stories (Bill Wake, 2003): Independent, Negotiable, Valuable, Estimable, Small, Testable.

INVEST hilft, eine Story auf Qualität zu prüfen: Möglichst unabhängig (Independent), verhandelbar im Detail (Negotiable), wertvoll für Nutzer oder Business (Valuable), schätzbar (Estimable), klein und fokussiert (Small) und über Akzeptanzkriterien testbar (Testable).

In wiederholten, kurzen Zyklen arbeiten statt in einem großen Durchlauf. Jeder Zyklus liefert ein nutzbares Zwischenergebnis und die Möglichkeit, daraus zu lernen.

Iteratives Arbeiten ist eines der Kernprinzipien agilen Arbeitens: Statt einmal alles vorab zu planen und am Ende zu liefern, entsteht das Ergebnis in vielen kleinen Schritten. Nach jedem Schritt wird überprüft und angepasst — das macht agile Teams anpassungsfähig und reduziert das Risiko, am Bedarf vorbei zu bauen.

Eine der drei Gruppen von Kompetenzelementen der ICB4: Menschenkompetenz (People), Methodenkompetenz (Practice), Kontextkompetenz (Perspective).

People umfasst persönliche und soziale Fähigkeiten (Führung, Teamarbeit, Kommunikation). Practice ist die fachlich-technische Seite (Ziele, Anforderungen, Risiken, Planung). Perspective deckt den Kontext ab (Strategie, Governance, Kultur). Erst im Zusammenspiel aller drei entsteht Projektkompetenz.

Der Preis pro Stunde oder Tag, den eine Arbeitsressource verursacht. Multipliziert mit der Arbeit ergibt er die Kosten einer Zuordnung — Arbeit × Kostensatz = Kosten.

Der Kostensatz (englisch: Rate, im Project-UI auch "Standardsatz") ist der Preis pro Stunde oder pro Tag, den eine Arbeitsressource verursacht. Du hinterlegst ihn einmal in der Ressourcentabelle, von da an rechnet Project automatisch: Arbeit × Kostensatz = Kosten. Project unterstützt mehrere Kostensätze pro Ressource (z. B. Standardsatz und Überstundensatz), und der Satz kann sich auch über die Zeit ändern (Tariferhöhung). Für eine Materialressource ist der Kostensatz der Preis pro Einheit (mengenabhängig). Eine Kostenressource hat dagegen keinen Standardsatz — ihr Betrag wird erst bei der Zuordnung am Vorgang eingetragen.

Die längste Kette verknüpfter Vorgänge von Anfang bis Ende — sie bestimmt den Endtermin und hat keinen Puffer. Jede Verzögerung hier verschiebt das Projektende um denselben Betrag.

Der kritische Pfad (englisch: Critical Path) ist die längste durchgehende Kette von Vorgängen vom Projektanfang bis zum -ende. Er definiert die Projektdauer: kürzer geht es nicht. Vorgänge auf dem kritischen Pfad haben eine Pufferzeit von 0 — jede Verzögerung eines kritischen Vorgangs verschiebt den Endtermin um denselben Betrag. Project zeigt den kritischen Pfad auf Wunsch rot (Gantt-Diagramm Format → Kritische Vorgänge). Wichtig: Der kritische Pfad ist nicht in Stein — wird er verkürzt (z. B. durch Parallelisierung), kann ein bisher unkritischer Zweig zum neuen kritischen Pfad werden. Den Endtermin verkürzen kann man nur über den jeweils aktuellen kritischen Pfad.

Beschreibung der Anforderungen aus Auftraggebersicht — das „Was". Definiert, welches Problem gelöst werden soll, ohne die Lösung vorwegzunehmen.

Das Lastenheft ist klassisch der erste schriftliche Schritt eines plangetriebenen Projekts: Der Auftraggeber beschreibt, was er erreichen will, in welchem Rahmen, mit welchen Randbedingungen. Es bildet die Grundlage für Angebote und für das spätere Pflichtenheft des Auftragnehmers.

Zweiter Schalter neben der Vorgangsart — wirkt erst beim Hinzufügen oder Entfernen von Ressourcen an einem bereits besetzten Vorgang. Vertiefung in Modul E6.

Leistungsgesteuert (englisch: Effort-driven) ist ein Schalter im Vorgangsdialog (Reiter "Erweitert"), der zusätzlich zur Vorgangsart wirkt. Sein Effekt zeigt sich erst dann, wenn du Ressourcen zu einem bereits besetzten Vorgang **hinzufügst oder entfernst**: Ist Leistungssteuerung aktiv, hält Project die Gesamtarbeit konstant und verteilt sie auf alle Ressourcen — mehr Leute = kürzere Dauer pro Person. Solange du mit einer Ressource arbeitest, spielt der Schalter keine Rolle. Feste Arbeit ist immer leistungsgesteuert. Die vollständige Behandlung kommt in Modul E6.

Der zweite Schalter neben der Vorgangsart. Greift nur beim Hinzufügen oder Entfernen von Ressourcen und entscheidet: bleibt die Arbeit konstant (Dauer schrumpft) oder wächst die Arbeit?

Die Leistungssteuerung (englisch: Effort-driven, Häkchen "Leistungsgesteuert" im Reiter Erweitert der Vorgangsinformationen) ist der zweite Schalter neben der Vorgangsart. Sie wirkt ausschließlich beim **Hinzufügen oder Entfernen** von Ressourcen an einem Vorgang — bei reinen Änderungen an Dauer oder Einheiten spielt sie keine Rolle. Ihre Logik: **AN** — die Arbeit bleibt konstant und verteilt sich auf alle Ressourcen. Mehr Personen → kürzere Dauer pro Person. **AUS** — jede dazukommende Person bringt eigene Arbeit mit. Mehr Personen → mehr Gesamtarbeit, Dauer bleibt gleich. Bei Vorgangsart "Feste Arbeit" ist die Leistungssteuerung immer an und lässt sich nicht abschalten. Begriff ist synonym zum Adjektiv "leistungsgesteuert".

Gremium auf der Lenkungsebene eines Projekts. Trägt die Gesamtverantwortung, gibt Phasen frei und sichert den Business Case.

In PRINCE2 typischerweise besetzt mit Auftraggeber (Executive), Senior User (vertritt die Nutzer) und Senior Supplier (vertritt die Liefer-Seite). Der Ausschuss entscheidet an den Schlüsselpunkten — Initiierung, Phasenübergänge, Abschluss — und steuert über Toleranzen nach dem Prinzip Management by Exception.

Spannungsfeld aus drei konkurrierenden Zielgrößen: Umfang (Scope), Zeit und Ressourcen. Die Qualität sitzt als abhängige Ergebnisgröße im Zentrum.

Zieht man an einer Ecke des Dreiecks, reagieren die anderen — mehr Umfang bei gleichem Zeit- und Ressourcenrahmen geht in der Regel auf Kosten der Qualität. Die Aufgabe der Projektleitung ist es, dieses Gleichgewicht zu halten und Schieflagen transparent zu machen. Eine persönliche Variante: Wer die Menschen ins Zentrum stellt, bekommt die Qualität oft fast geschenkt.

Steuerung über Toleranzen: Der Lenkungsausschuss greift erst ein, wenn vereinbarte Toleranzen (Zeit, Kosten, Umfang, Qualität, Risiko, Nutzen) überschritten werden.

Statt jede Kleinigkeit zu entscheiden, definiert der Ausschuss Toleranzbänder pro Phase. Innerhalb der Bänder steuert der Projektmanager autonom; bei Überschreitung eskaliert er an den Ausschuss. Das hält die Führung schlank, gibt dem Projektmanager Spielraum und konzentriert die Aufmerksamkeit des Ausschusses auf echte Abweichungen.

Vom Lenkungsausschuss freigegebener Projektabschnitt zwischen zwei Entscheidungspunkten. Erst wenn der Business Case noch trägt, wird die nächste Phase freigegeben.

PRINCE2 zerlegt jedes Projekt in Managementphasen, damit der Lenkungsausschuss zwischen ihnen bewusst entscheiden kann. Eine Managementphase ist eine Steuerungseinheit — unabhängig davon, ob die Lieferung darin sequenziell, iterativ oder agil erfolgt.

Mayday = höchste Notfallstufe (Lebensgefahr). Pan-Pan = dringend, aber keine unmittelbare Gefahr. Im Projekt: zwischen echten Krisen und dringenden Problemen unterscheiden.

**Mayday:** Höchste Notfallstufe — unmittelbare Gefahr für Flugzeug und Insassen. Alle anderen Flugzeuge müssen Frequenz räumen. **Pan-Pan:** Dringende Situation, aber keine unmittelbare Lebensgefahr. Im Projekt: Unterscheide zwischen echten Krisen (Eskalation nötig) und dringenden Problemen (erhöhte Aufmerksamkeit, aber kein Alarm).

Vorgang mit Dauer 0 — markiert ein Ereignis oder Ziel ohne eigene Arbeitszeit. Erscheint im Gantt-Diagramm als Raute.

Ein Meilenstein (englisch: Milestone) ist ein besonderer Vorgang mit Dauer 0. Er steht nicht für Arbeit, sondern für ein Ereignis oder Ziel — "Konzept fertig", "Freigabe erteilt", "Kampagne gestartet". Weil er keine Dauer hat, erscheint er im Gantt-Diagramm nicht als Balken, sondern als kleine Raute. Meilensteine machen einen Plan lesbar und sind die natürlichen Stellen, an denen Lenkungsausschuss oder Auftraggeber den Fortschritt ablesen. Du legst einen Meilenstein an, indem du die Dauer auf 0 setzt — oder im Vorgangsdialog die Option "Vorgang als Meilenstein darstellen" ankreuzt.

Baustein von HERMES: Phase, Rolle, Aufgabe, Modul, Ergebnis oder Meilenstein. Aus diesen Elementen werden Szenarien zusammengestellt.

HERMES versteht sich als Baukasten. Die Methodenelemente sind die kleinsten Bausteine, aus denen die Methode aufgebaut ist: Phasen geben den Lebenszyklus, Rollen die Verantwortung, Aufgaben den Arbeitsschritt, Module die Bündelung, Ergebnisse das Geleistete, Meilensteine den Entscheidungspunkt.

Microsofts vereinte Work-Management-App in M365 — vereint die Stärken von Planner, To Do und dem früheren Project for the Web.

Basisfunktionen sind in vielen M365-Lizenzen enthalten; Profifunktionen (Gantt, Abhängigkeiten, Ressourcen, Portfolio) brauchen Zusatzlizenzen (Planner Plan 1 / Plan 3 / Plan 5). Planner ist heute der zentrale Standard für Team- und Projektarbeit; das klassische Project Online wird abgelöst.

Priorisierungsmethode mit vier Stufen: Must have, Should have, Could have, Won't have (this time). Das „W" heißt diesmal nicht — nicht nie.

MoSCoW ordnet Anforderungen nach Wichtigkeit. Must have ist unverzichtbar, Should have ist wichtig (aber nicht zwingend für den Start), Could have ist nice to have, und Won't have (this time) bedeutet „nicht in dieser Lieferung — evtl. später". Der häufigste Fehler ist, das „W" als „nie" zu lesen.

Internationale Prüfungsorganisation, die PRINCE2 und PRINCE2 Agile zertifiziert (ehemals AXELOS). Bietet Foundation- und Practitioner-Stufen an.

PeopleCert führt seit 2021 die Best-Practice-Methoden, die früher AXELOS verantwortete — darunter PRINCE2, PRINCE2 Agile und ITIL. Die Zertifizierungen sind weltweit anerkannt; in der Praxis sind PRINCE2 Foundation (Methoden-Grundlagen) und Practitioner (Tailoring und Anwendung) die häufigsten Stufen.

Tätigkeitsbereich des Projektmanagements im PMBOK Guide — z. B. Scope, Schedule, Risk. Sieben Domänen umkreisen die Wertschöpfung.

Die 8. Ausgabe des PMBOK Guide (2025) ordnet die Projektarbeit in sieben Performance Domains: Governance, Scope, Schedule, Finance, Stakeholders, Resources und Risk. Sie beschreiben das *worum-man-sich-kümmert*, nicht *wie* man es macht — der konkrete Weg ergibt sich durch Tailoring.

Klare Aufgabenteilung im Cockpit: PF fliegt aktiv und entscheidet, PM überwacht und challenged. Gleichwertig, nur unterschiedliche Aufgaben. PM darf nicht mit "Project Manager" verwechselt werden.

**Pilot Flying (PF):** Fliegt aktiv das Flugzeug, trifft operative Entscheidungen. Im Projekt: der Projektleiter, der die Richtung vorgibt. **Pilot Monitoring (PM):** Überwacht alle Systeme, liest Checklisten, warnt bei Abweichungen. Im Projekt: Controller, QA oder kritischer Sparringspartner. Beide Rollen sind gleichwertig — nur die Aufgaben unterscheiden sich.

Umsetzung der Anforderungen aus Auftragnehmersicht — das „Wie". Konkretisiert, wie das im Lastenheft beschriebene Ziel technisch erreicht wird.

Das Pflichtenheft antwortet auf das Lastenheft: Der Auftragnehmer beschreibt, wie er die Anforderungen umsetzen wird — Architektur, Schnittstellen, Verfahren, Termine. Es ist Vertragsgrundlage und Maßstab für die spätere Abnahme.

Gliederung eines Projekts in aufeinanderfolgende Phasen mit definierten Ergebnissen. Jede Phase wird abgeschlossen, bevor die nächste beginnt.

Strukturierungsprinzip klassischer Methoden. Typische Phasen sind Initiierung, Planung, Umsetzung, Test, Abnahme, Betrieb. Zwischen den Phasen liegen Meilensteine als bewusste Entscheidungspunkte.

Eigenentwicklung der xbank Academy: Project · Incident · Leadership · Operational · Thinking. Pragmatischer Denkansatz für komplexe Projekte und Führung.

PILOT steht für Project, Incident, Leadership, Operational, Thinking. Das Framework ist aus einer Pilotenausbildung (PPL) und über 20 Jahren IT-/PM-Erfahrung entstanden. Kerngedanke: Struktur, Vorbereitung und saubere Entscheidungen aus dem Cockpit auf Projektmanagement übertragen.

Projektansatz, bei dem die Planung weitgehend vor der Umsetzung steht. Das Ziel gilt zu Projektbeginn als bekannt und Änderungen laufen über geregelte Anträge.

Synonym für die klassische, plan-orientierte Projektsteuerung im Gegensatz zu agilen, iterativen Ansätzen. Vorteile: klare Verträge, kalkulierbare Budgets, hohe Nachvollziehbarkeit. Grenze: funktioniert nur, wenn Ziel und Umfang früh ausreichend genau bestimmbar sind.

Schätzmethode, bei der alle Team-Mitglieder verdeckt schätzen und gleichzeitig aufdecken. Verhindert Anchoring durch die erste Zahl.

Ablauf: Story vorstellen, alle schätzen verdeckt, gleichzeitig aufdecken. Bei Abweichungen erklären die Schätzenden ihre Sicht, danach wird neu geschätzt — bis ein Konsens steht. Der eigentliche Wert liegt im Gespräch, das die Abweichungen auslösen.

Private Pilot Licence — Privat-Pilotenschein. Berechtigt zum Führen kleiner Motorflugzeuge der Echo-Klasse (bis 2 t) auf Sicht (VFR).

Die PPL ist die Einstiegs-Pilotenlizenz für Privatpiloten. Sie umfasst etwa 100 Stunden Theorie, mindestens 45 Flugstunden, eine medizinische Klasse-2-Untersuchung und je eine theoretische und praktische Prüfung. Inhaber dürfen Passagiere mitnehmen, aber keine kommerziellen Flüge durchführen.

Grundhaltung der Retrospektive (Norm Kerth): Jeder hat unter den gegebenen Umständen nach bestem Wissen und Gewissen gehandelt — Lernen statt Schuldzuweisung.

Norm Kerth formulierte sie in „Project Retrospectives" als Voraussetzung für ehrliche Reflexion. Erst wenn ein sicherer Raum da ist, sprechen Menschen offen über Probleme. Schuldzuweisung zerstört diese Offenheit; gelernt wird stattdessen aus dem System.

Das langfristige Ziel für das Produkt — Commitment des Product Backlog in Scrum, mit dem Guide 2020 neu eingeführt.

Das Product Goal beschreibt einen zukünftigen Zustand des Produkts und gibt dem Product Backlog Orientierung: Jedes Sprint Goal soll einen Schritt in Richtung Product Goal sein. Erst wenn das Product Goal erreicht oder aufgegeben ist, entsteht ein neues. Ergänzt im Scrum Guide 2020.

Die klassische, voll ausgestattete Microsoft-Project-Anwendung — mit Gantt, Arbeit/Dauer/Einheiten-Logik, kritischem Pfad und Ressourcen-/Kostenplanung. Fokus von Teil E.

Verfügbar als Kauf-Version (Project 2021/2024) oder als abonnierter Desktop-Client in den höheren Plan-Stufen (Planner and Project Plan 3 / Plan 5). Für das Erlernen echten PM-Handwerks die beste Wahl, weil hier alle Werkzeuge greifbar sind, mit denen die Methoden aus Teil A–D umgesetzt werden.

Die Zeile 0 oben in der Vorgangstabelle — fasst alle Vorgänge des Projekts zusammen. Zeigt Gesamtdauer, Gesamtkosten und das Projektbudget.

Der Projektsummenvorgang (englisch: Project Summary Task) ist eine spezielle Zeile in der Vorgangstabelle, die alle Vorgänge des Projekts zusammenfasst. Sie steht ganz oben mit der Nummer 0 und wird oft auch "Projektsummenzeile" oder "Zeile 0" genannt. Project rollt hier alle Werte hoch: Gesamtdauer (Startdatum bis spätestes Enddatum), Gesamtarbeit (Summe aller Vorgänge), und besonders wichtig für die Kostenplanung das **Gesamtbudget** (Summe aller Vorgangskosten). Eingeblendet wird der Projektsummenvorgang über Gantt-Diagramm Format → Projektsummenvorgang. Im Kontext von Modul E4-E6 verhält sich die Zeile wie ein Sammelvorgang, der über dem gesamten Plan steht — sie plant sich nicht selbst, sondern errechnet ihre Werte aus allen darunterliegenden Vorgängen.

Das geteilte Gefühl in einem Team, ohne Angst Fehler ansprechen, Fragen stellen und unbequeme Themen benennen zu können.

Geprägt durch die Arbeiten von Amy Edmondson. Teams mit hoher psychologischer Sicherheit lernen schneller, weil Fehler früh sichtbar werden und Wissen aktiv geteilt wird. Sie ist die Voraussetzung dafür, dass Retrospektiven und Feedback wirken — und spiegelt damit die Prime Directive aus Modul C5.

Wie weit ein Vorgang rutschen darf, ohne den Endtermin (gesamte Pufferzeit) oder den nächsten Vorgang (freie Pufferzeit) zu verschieben. 0 Tage = kritisch.

Die Pufferzeit (englisch: Slack oder Float) gibt an, wie viel Spielraum ein Vorgang hat. Project unterscheidet zwei Spielarten: Die **gesamte Pufferzeit** sagt, wie weit ein Vorgang rutschen darf, ohne den Endtermin des Projekts zu verschieben. Die **freie Pufferzeit** sagt, wie weit er rutschen darf, ohne den unmittelbar nachfolgenden Vorgang zu stören. Vorgänge mit 0 Tagen gesamter Pufferzeit liegen auf dem kritischen Pfad. Sichtbar machen lässt sich der Puffer über die Spalten "Gesamte Pufferzeit" und "Freie Pufferzeit" in der Vorgangstabelle. Für die Steuerung gilt: Puffer ist Handlungsspielraum — bewusst eingesetzt für Risiken, Abstimmungsschleifen oder Qualität.

Meilenstein am Ende einer Projektphase, an dem geprüft wird, ob die Ergebnisse erreicht sind und das Projekt in die nächste Phase übergehen darf.

Quality Gates sind die formalen Übergänge zwischen den Phasen eines plangetriebenen Projekts. Sie verbinden inhaltliche Abnahmekriterien mit einer expliziten Go-/Hold-/Stop-Entscheidung. In HERMES schließt jede der fünf Phasen mit einem Quality Gate ab — das ist die eingebaute Governance des Standards.

Laufende Pflege des Product Backlogs: Einträge präzisieren, schätzen, neu sortieren und in eine umsetzungsreife Form bringen.

Refinement (früher „Grooming") ist keine einzelne Sitzung, sondern eine kontinuierliche Aktivität: Der Product Owner und das Team sorgen dafür, dass die obersten Backlog-Einträge fein genug, klar priorisiert und bereit für einen kommenden Sprint sind. Üblicherweise fließen etwa 10 % der Team-Kapazität ins Refinement.

Bestimmt die Rechenlogik einer Ressource. Project kennt drei Arten: Arbeit (Satz pro Zeit), Material (Satz pro Einheit), Kosten (fixer Betrag pro Zuordnung).

Die Ressourcenart (englisch: Resource Type) gibt es in Microsoft Project in drei Ausprägungen, die unterschiedlich kosten: **Arbeit** sind Personen oder Geräte, deren Kostensatz pro Stunde oder Tag gilt — die Kosten hängen von der eingesetzten Zeit ab. **Material** sind verbrauchbare Mengen (Druckauflagen, Stückzahlen, kg Material) — der Kostensatz gilt pro Einheit, die Kosten hängen von der Menge ab. **Kosten** sind einmalige Beträge (Reisekosten, Lizenzen) — sie haben keinen Standardsatz, sondern bekommen erst bei der Zuordnung am konkreten Vorgang einen festen Betrag. Die Art wird im Ressourcendialog (Reiter Allgemein) gesetzt und bestimmt auch, welche Felder Project anbietet (Einheiten, Mengen, Beträge).

Eine Person ist zur selben Zeit auf mehr Vorgängen oder mit mehr Einheiten eingeplant, als ihre Kapazität hergibt (> 100 %). Project markiert das rot.

Eine Ressourcenüberlast entsteht, wenn die summierte Einplanung einer Person über deren verfügbare Kapazität geht — entweder weil sie zur gleichen Zeit auf mehreren Vorgängen sitzt, oder weil ihre Einheiten auf einem Vorgang über 100 % steigen. Project zeigt die Überlast mit einem roten Indikatorsymbol in der Tabelle und am übersichtlichsten im **Teamplaner**, der die Auslastung Person für Person über die Zeit darstellt. Aufgelöst wird sie über **Ausgleich und Umverteilung**: Vorgänge zeitlich auseinanderziehen, auf andere Personen umverteilen oder Project den automatischen Ressourcenausgleich vornehmen lassen. Vorsicht beim Reflex, einfach mehr Leute draufzuwerfen — wenn diese Leute schon anderswo verplant sind, entsteht nur Überlast an anderer Stelle.

Sprint-Rückblick zur Verbesserung der Zusammenarbeit und der Prozesse — nicht des Produkts (das ist das Review).

Die Retrospektive ist eines der fünf Scrum-Events. Ihr Zweck: Das Team reflektiert die eigene Zusammenarbeit und leitet wenige, konkrete Verbesserungsmaßnahmen für den nächsten Sprint ab. Wichtig: Sie betrachtet *wie* das Team arbeitet, nicht *was* es liefert — das ist Aufgabe des Sprint Reviews.

Übergeordnete Zeile, die untergeordnete Vorgänge zusammenfasst — bildet die PSP-Gliederung ab und plant sich nicht selbst, sondern errechnet sich aus den Untervorgängen.

Ein Sammelvorgang (englisch: Summary Task) fasst mehrere Vorgänge unter einer Phase oder einem Arbeitspaket zusammen. Er wird in Project fett dargestellt und mit einem Dreieck markiert. Wichtig: Ein Sammelvorgang plant sich nicht selbst — du trägst bei ihm keine Dauer von Hand ein. Project errechnet seine Dauer aus den untergeordneten Vorgängen. Sammelvorgänge entstehen durch Einrücken: Markierte Vorgänge werden eingerückt, die Zeile darüber wird automatisch zum Sammelvorgang. So bildet sich der Projektstrukturplan (PSP) aus Teil B im Werkzeug ab.

Ein Team, das seine Arbeit eigenverantwortlich plant und steuert — inklusive der Frage, wer was wann macht.

In selbstorganisierten Teams entscheidet die Gruppe selbst, wie sie ein Ziel erreicht. Das Management gibt das Ziel und die Rahmenbedingungen vor, nicht den Weg. Das Manifest sieht darin eine der wichtigsten Quellen für Qualität: „Die besten Architekturen, Anforderungen und Designs entstehen durch selbstorganisierte Teams" (Prinzip 11).

Dienende Führung: den Rahmen schaffen und Mitarbeitende befähigen, statt befehlen und kontrollieren — etwa der Scrum Master oder die Cockpit-Führung im PILOT.

Servant Leadership stellt die Frage um: Nicht „wie führe ich von oben?", sondern „wie räume ich Hindernisse aus dem Weg und helfe meinem Team, wirksam zu sein?". Der Begriff geht auf Robert Greenleaf (1970) zurück und prägt heute den Scrum Master ebenso wie das PILOT-Cockpit aus Teil A.

Lagebewusstsein über drei Ebenen: wahrnehmen, verstehen, vorhersagen. Verlust von SA ist eine der häufigsten Ursachen für Unfälle und Projektkrisen.

Das Bewusstsein darüber, was um einen herum passiert und was es bedeutet.

Die Wahl des Vorgehens richtet sich nach Situation, Menschen und Ziel — nicht nach Dogma oder Mode.

Situatives Arbeiten ist die Kernhaltung von Teil D: Statt zu fragen „Welche Methode ist die beste?" fragen erfahrene Projektmenschen „Welche passt zu *dieser* Situation, *diesen* Menschen, *diesem* Ziel?". Werkzeuge dafür kennst du bereits — den Agilometer aus B8 und den hybriden Pfad aus PRINCE2 Agile und HERMES.

Dokumentierte, standardisierte Verfahren für wiederkehrende Aufgaben. Reduziert Fehler, spart Denkkapazität, sorgt für Konsistenz.

Dokumentierte, standardisierte Verfahren für wiederkehrende Aufgaben. SOPs reduzieren Fehler, sparen Denkkapazität und sorgen für Konsistenz. In der Luftfahrt gibt es SOPs für jede Phase des Fluges. Im Projekt: Templates, definierte Prozesse, Checklisten für wiederkehrende Aufgaben wie Statusberichte oder Eskalationen.

Der timeboxte Zyklus in Scrum — maximal ein Monat — in dem ein nutzbares Increment entsteht. Klammer um alle anderen Scrum-Events.

Der Sprint ist das Herzstück des Scrum-Frameworks: ein festes Zeitfenster, in dem ein Team das Sprint-Ziel verfolgt und am Ende ein nutzbares Increment liefert. Während des Sprints wird das Sprint-Ziel nicht geändert — Anpassung passiert zwischen den Sprints, nicht mittendrin. Das schafft Fokus und Vertrauen.

Phasen-Tor mit bewusster Go-/Kill-Entscheidung zwischen Projektphasen. Variante des Meilensteins, vor allem aus der Produktentwicklung bekannt.

Das Stage-Gate-Modell (Robert G. Cooper) strukturiert Produktentwicklungen in feste „Stages" (Phasen) und „Gates" (Tore). An jedem Tor entscheidet ein Gremium auf Basis vordefinierter Kriterien über Weiterführen, Nachbessern oder Abbruch. Im Kern eine disziplinierte Wasserfall-DNA, häufig mit hybriden Umsetzungs-Stages.

Relatives Maß für die Größe einer Aufgabe — Komplexität, Aufwand und Unsicherheit zusammen. Nicht in Stunden umrechenbar.

Story Points sind kein Zeitmaß. Sie drücken aus, wie groß eine Aufgabe im Vergleich zu anderen ist. Verbreitet ist die Fibonacci-Reihe (1, 2, 3, 5, 8, 13, 21 …): Je größer die Aufgabe, desto größer die Unsicherheit — die wachsenden Abstände machen das sichtbar. Wer Story Points in Stunden umrechnet, hat sie missverstanden.

Das Zusammenführen des Gelernten zu einem stimmigen, anwendbaren Ganzen — Aufgabe von Teil D der Academy.

Während Teil A, B und C Wissen aufgebaut haben (PILOT, klassisch, agil), bringt Teil D dieses Wissen zusammen. Synthese ist mehr als Addition: Erst durch Verbinden, Anwenden und Reflektieren wird aus einzelnen Methoden eine tragfähige Projektpraxis.

In HERMES eine vorkonfigurierte Zusammenstellung von Methodenelementen für einen bestimmten Projekttyp — etwa für eine IT-Individualentwicklung oder eine Organisationsanpassung.

Statt jedes Projekt von Grund auf zusammenzustellen, wählt eine Organisation in HERMES das passende Szenario und ergänzt es bei Bedarf. Szenarien bündeln Phasen, Rollen, Aufgaben, Module und Ergebnisse sinnvoll vor — sie sind das Tailoring-Werkzeug des Standards.

Bestimmt, welche Spalten in der Tabellenhälfte einer Ansicht angezeigt werden — z. B. Eingabe (Dauer/Anfang/Ende), Kosten, Arbeit. Gleiche Vorgänge, anderer Spalten-Ausschnitt.

Eine Tabelle (englisch: Table) in Microsoft Project bestimmt, welche Spalten in der Tabellenhälfte angezeigt werden. Die Standard-Tabelle "Eingabe" zeigt Dauer, Anfang und Ende; die Tabelle "Kosten" zeigt Kostenspalten; die Tabelle "Arbeit" zeigt Stundenwerte (Arbeit, geplant, verbleibend, % abgeschlossen). Es sind immer dieselben Vorgänge — nur der Spalten-Ausschnitt wechselt. Wechseln über die Registerkarte Ansicht → Tabellen oder per Rechtsklick auf den Spaltenkopf ganz links.

Bewusstes Zuschneiden einer Projektmethode auf Größe, Risiko und Kontext des Vorhabens — anstatt blind dem vollen Methoden-Korsett zu folgen.

Begriff vor allem aus PRINCE2 und PMBOK: Eine Methode liefert das Gerüst, die Organisation wählt aus, was sie für das konkrete Projekt wirklich braucht. Tailoring vermeidet überflüssige Dokumentation und Prozessgewicht, ohne die Steuerungslogik aufzugeben.

In HERMES 2022 die Phase, die im agilen oder hybriden Pfad die drei klassischen Phasen Konzept, Realisierung und Einführung zu einer iterativen Phase zusammenfasst.

HERMES 2022 lässt zwischen Initialisierung und Abschluss zwei Wege zu: den klassischen Dreischritt oder die agile „Umsetzung". Welcher Weg passt, wird bereits in der Initialisierung festgelegt. Damit kann eine Organisation klassische und agile Projekte unter demselben Dach führen — der gemeinsame Rahmen aus Quality Gates und Rollen bleibt erhalten.

Kurze, aus Nutzersicht formulierte Anforderung nach der Schablone „Als ‹Rolle› möchte ich ‹Wunsch›, um ‹Nutzen› zu erreichen."

User Stories stammen aus dem Extreme Programming (Kent Beck, 1999), nicht aus Scrum — Scrum schreibt sie nicht vor, in der Praxis sind sie aber die verbreitetste Form agiler Anforderungen. Wesentlich: Eine Story ist eine Gesprächseinladung, keine Spezifikation. Der „um … zu"-Teil ist der Kern — er macht den Nutzen explizit.

Kritische Geschwindigkeiten beim Start. V1 = Point of No Return: danach wird geflogen, egal was. Im Projekt: definiere klare Abbruchpunkte vor kritischen Meilensteinen.

**V1 (Decision Speed):** Bis zu dieser Geschwindigkeit kann der Start noch abgebrochen werden. Danach wird geflogen — egal was passiert. Der "Point of No Return". **VR (Rotation Speed):** Geschwindigkeit zum Abheben. **V2 (Takeoff Safety Speed):** Sichere Steigfluggeschwindigkeit. Im Projekt: Definiere klare Punkte, bis zu denen ein Abbruch möglich ist — und ab wann durchgezogen wird.

Prüfung, ob das richtige Produkt gebaut wurde — also das, was der Auftraggeber wirklich braucht. Beantwortet die Frage „Have we built the right product?".

Validierung misst gegen die ursprünglichen Anforderungen und damit gegen den Nutzen für den Auftraggeber. Im V-Modell ist der Abnahmetest die klassische Validierungsstufe. Verifikation und Validierung sind komplementär, nicht austauschbar.

Erfahrungswert, wie viele Story Points ein Team pro Sprint schafft. Vorhersage-Werkzeug — kein Leistungsziel, kein Teamvergleich.

Velocity hilft, realistisch zu planen: Wie viele Punkte passen in den nächsten Sprint? Entscheidend ist, was sie *nicht* ist — kein Wettbewerb, kein KPI, kein Maßstab für Teamvergleiche. Sobald Velocity zur Zielvorgabe wird, schätzen Teams, um gut dazustehen, und die Zahl wird wertlos.

Eine der fünf agilen Grundhaltungen in PRINCE2 Agile: Transparenz, Zusammenarbeit, Reichhaltige Kommunikation, Selbstorganisation, Exploration.

Die Verhaltensweisen prägen die Haltung, mit der ein PRINCE2-Agile-Team arbeitet. Sie sind kein Werkzeug, sondern eine Kultur: Offenheit über den Stand, gemeinsame Verantwortung, direkter Austausch statt Dokumenten-Pingpong, Eigenverantwortung im Team und die Bereitschaft, Lösungen explorativ zu erarbeiten.

Prüfung, ob das Produkt korrekt gebaut wurde — also gemäß Spezifikation. Beantwortet die Frage „Have we built the product right?".

Verifikation ist die formale Prüfung gegen den Entwurf: Erfüllt das gebaute System die Vorgaben aus Architektur und Feinentwurf? Im V-Modell verifizieren die unteren Teststufen (Modul- und Systemtest) gegen die jeweilige Spezifikationsebene.

Kleinste planbare Aufgabe in Microsoft Project, mit einer Dauer. Wird zeilenweise in der Vorgangstabelle erfasst.

Ein Vorgang ist die elementare Einheit eines Project-Plans: eine einzelne Aufgabe mit Namen und Dauer. Du legst Vorgänge an, indem du Zeile für Zeile in der Tabelle den Namen einträgst und in der Spalte "Dauer" angibst, wie lange die Aufgabe dauert. Steht hinter der Dauer ein Fragezeichen (z. B. "3 Tage?"), ist das ein noch nicht bestätigter Schätzwert. Mehrere Vorgänge werden durch Einrücken unter einen Sammelvorgang zur Gliederung.

Legt fest, welche der drei Größen (Arbeit, Dauer, Einheiten) Project konstant hält. Drei Optionen: Feste Einheiten (Standard), Feste Dauer, Feste Arbeit.

Die Vorgangsart (englisch: Task Type) ist die zentrale Stellschraube für Projects Rechenverhalten. Sie bestimmt, welche der drei Größen Arbeit, Dauer und Einheiten an einem Vorgang **festgehalten** wird — die anderen beiden bleiben frei und werden bei Bedarf neu berechnet. Drei Vorgangsarten: **Feste Einheiten** (Standard) — die Verfügbarkeit der Ressource ist gesetzt; **Feste Dauer** — der Zeitraum steht (typisch bei harten Terminen wie Go-live); **Feste Arbeit** — der Aufwand ist fix (typisch bei Festpreis-Kalkulation). Eingestellt pro Vorgang in den Vorgangsinformationen → Reiter "Erweitert". Die Wahl der Vorgangsart ist eine planerische Entscheidung: Was ist an diesem Vorgang nicht verhandelbar?

Modularer Baustein des V-Modell XT, der über das Tailoring zu einem projektspezifischen Vorgehensmodell kombiniert wird.

Statt einer einzigen festen Phasenfolge arbeitet das V-Modell XT mit Vorgehensbausteinen — gekapselten Einheiten aus Aktivitäten, Produkten und Rollen. Beim Tailoring wählt die Organisation die Bausteine aus, die das konkrete Projekt wirklich braucht. So passt sich das Modell an Projektgröße, Risikoprofil und Kontext an.

Die „A über B"-Struktur der vier Manifest-Werte: beide Seiten zählen, die linke wird höher gewichtet. „Über", nicht „statt".

Das Agile Manifest stellt in jedem seiner vier Werte zwei Begriffe gegenüber — als Gewichtung, nicht als Entweder-oder. Beispiel: Funktionierende Software über umfassende Dokumentation. Dokumentation verschwindet nicht; sie ordnet sich der Software unter, wenn es zum Konflikt kommt. Wer diese Logik überliest, baut entweder bürokratisches Wasserfall-Denken mit agilem Etikett oder verwechselt Agilität mit Beliebigkeit.

Der gelieferte Nutzen für Organisation und Stakeholder als Maßstab des Projekterfolgs — die Mitte, um die im PMBOK Guide die sieben Performance Domains kreisen.

Mit der 7. und 8. Ausgabe stellt der PMBOK Guide die Wertschöpfung ins Zentrum: Der Erfolg eines Projekts misst sich nicht am Liefer-Output, sondern am Nutzen, der für Organisation und Stakeholder entsteht. Damit verschiebt sich der Blick vom „Was haben wir gemacht?" zum „Was ist daraus geworden?".

Anzeigeformat der Einheiten in Project — als Prozentsatz (100 %) oder als Dezimalzahl (1,0). Einstellung unter Datei → Optionen → Terminplanung.

Die Zuordnungseinheiten (englisch: Assignment Units) sind ein Anzeigeformat: Project kann die Einheiten einer Ressourcenzuordnung entweder als Prozentsatz (z. B. 100 % für Vollzeit) oder als Dezimalzahl (z. B. 1,0) anzeigen. Eingestellt unter Datei → Optionen → Terminplanung. In der Academy verwenden wir den Standard-Modus "Prozentsatz", weil er für PM-Anfänger intuitiver ist. Die zugrunde liegende Rechenlogik (Arbeit = Dauer × Einheiten) ist in beiden Modi identisch.