Mandat anfragen
Pierre Kromat  ·  Projektmanagement
Operatives Whitepaper · 04/2026 · DACH

Projekte führen, die wirklich geliefert werden. Aus 20+ Jahren Mandatserfahrung.

Projektmanagement · Methoden · Führung · Steuerung

Sieben Cluster. Ein Ziel: Projekte so aufsetzen und führen, dass sie nicht nur gestartet, sondern abgeschlossen werden — mit dem geplanten Nutzen, nicht nur dem geplanten Budget. Diese Seite ist kein Glossar. Sie ist eine Arbeitskarte für Auftraggeber, die ihr nächstes Vorhaben nicht dem Zufall überlassen wollen.

7Cluster
60+Begriffe
20+Jahre

»We get projects done through people, we deliver projects to benefit people.«

Abschnitt 01 · Grundbegriffe

Worüber wir wirklich reden — das Fundament.

Ein Projekt ist eine zeitlich begrenzte, einmalige Unternehmung mit spezifischem Ziel, definierten Terminen und festgelegter Ressourcenallokation. Diese Begriffe bilden das Fundament — wer sie nicht präzise versteht, steuert am falschen Hebel.

01Start

Initiierung

Charta · Scope · Sponsor · Freigabe

02Planung

Konzeption

WBS · Zeitplan · Budget · Ressourcen

03Umsetzung

Ausführung

Lieferung · Teamarbeit · Backlog

04laufend

Controlling

Monitor · Status · Abweichungen

05Ende

Abschluss

UAT · Übergabe · Lessons Learned

01

Projekt

Zeitlich begrenzte, einmalige Unternehmung mit spezifischem Ziel, definierten Beginn- und Endterminen sowie festgelegter Ressourcenallokation.

02

Programm

Gruppe zusammenhängender Projekte, die gemeinsam verwaltet werden, um Vorteile zu erzielen, die einzeln nicht erreichbar wären. Komplexer und langfristiger als Einzelprojekte.

03

Deliverables

Konkrete Ergebnisse oder Produkte, die im Laufe eines Projekts erstellt und dem Kunden oder den Stakeholdern geliefert werden. Prüfbar, nicht interpretierbar.

04

Milestones

Wichtige Punkte im Projektverlauf, die den Abschluss einer Phase markieren. Dienen als Kontrollpunkte und Entscheidungsmomente — keine Dekorationselemente.

05

Baseline

Festgelegter Zustand von Anforderungen, Budget und Zeitplan zu Projektbeginn. Maßstab für alle späteren Abweichungsanalysen. Ohne Baseline kein nachvollziehbares Controlling.

06

Scope Creep

Unkontrolliertes Wachsen des Projektumfangs durch nicht gesteuerte Zusatzanforderungen. Häufigste Ursache für Budget- und Terminüberschreitungen. Entsteht fast immer durch fehlende Scope-Disziplin.

07

Backlog

Priorisierte Liste von Aufgaben oder Anforderungen, die noch bearbeitet werden müssen. Zentrales Steuerungsinstrument in agilen Projekten — Priorisierung ist keine einmalige Übung.

08

Action List

Zusammengefasste Liste von Aktionsschritten mit Verantwortlichem und Fälligkeit. Kurz- und mittelfristiges Steuerungsinstrument — das Gegenstück zum langfristigen Projektplan.

09

Projektstrukturplan (PSP) / WBS

Hierarchisches Diagramm, das alle Elemente und Aufgaben eines Projekts strukturiert darstellt. Grundlage für Planung, Steuerung und Verantwortungszuweisung.

»Ohne klaren Scope kein klares Ergebnis. Wer Scope-Creep toleriert, akzeptiert Kontrollverlust.«

Abschnitt 02 · Initiierung & Setup

Entscheidungen, die später nicht mehr korrigierbar sind.

Ein sauber aufgesetztes Projekt entscheidet über 80 % des späteren Erfolgs. Scope, Sponsor, Governance und Wirtschaftlichkeit müssen von Anfang an klar sein — nicht erst nach dem Kickoff-Meeting.

01

Projektcharta

Grundlagendokument, das Zweck, Ziele, Umfang, Stakeholder und Budget festlegt. Offizieller Startschuss und Autorisierungsdokument — ohne Charta kein legitimes Projekt.

02

Projektauftrag / Scope

Kritisches Dokument, das Zweck, Ziele und Umfang klar abgrenzt. Verhindert Scope Creep durch explizite Definition dessen, was zum Projekt gehört — und was nicht.

03

Minimal Project Criteria

Vorgaben und Anforderungen, die ein Projekt erfüllen muss, um als machbar und genehmigungswürdig zu gelten. Verhindert das Starten von Projekten ohne belastbare Grundlage.

04

Feasibility Study

Machbarkeitsstudie, die technische, wirtschaftliche und organisatorische Realisierbarkeit prüft — vor dem formellen Start. Teure Projekte, die nicht realisierbar sind, früh stoppen.

05

Cost Estimation

Systematische Schätzung der Kosten für alle Projektaktivitäten. Grundlage für Budgetplanung und ROI-Kalkulation. Eine zu optimistische Cost Estimation ist kein Versprechen — sie ist ein Risiko.

06

Project Value / ROI

Verhältnis von erwartetem Nutzen zu den Projektkosten. Entscheidet über Priorität und Freigabe. Wer ROI nicht kennt, hat kein Entscheidungskriterium für Ressourcenkonflikte.

07

Kickoff-Meeting

Auftaktveranstaltung, bei der Projektteam und Stakeholder Ziele, Rollen und Spielregeln klären. Der erste Termin, der Vertrauen oder Skepsis im Team erzeugt.

08

Executive Summary

Prägnante Zusammenfassung für Führungsebene und Entscheider — fokussiert auf Ergebnisse, Risiken und Empfehlungen. Nicht mehr als eine Seite. Nicht weniger als die Wahrheit.

A

Projektsponsor

Person oder Gruppe, die Projektziele unterstützt, notwendige Ressourcen bereitstellt und die Verantwortung für den Projekterfolg auf Führungsebene trägt. Ohne aktiven Sponsor kein Eskalationsweg, kein politisches Gewicht, kein Entscheidungsrückhalt.

Risiko Formaler Sponsor ohne operatives Engagement ist schlimmer als kein Sponsor — er schließt Eskalationswege, ohne sie zu öffnen.

B

Project Steering Board

Gremium aus Schlüsselstakeholdern, das strategische Ausrichtung und Entscheidungsfindung überwacht und bei Eskalationen entscheidet. Frequenz: mindestens monatlich, bei kritischen Phasen wöchentlich.

Prinzip Ein Steering Board, das nur informiert wird, ist kein Steering Board — es ist ein Reportingempfänger.

C

Sounding Board

Person oder Gruppe, die als Resonanzraum für Ideen und Strategien dient — gibt Feedback zur Qualität von Entscheidungen ohne formelle Weisungsbefugnis. Wertvoll als frühzeitiger Qualitätsfilter.

Einsatz Vor kritischen Entscheidungen, nicht danach. Sounding Board ist kein Zustimmungsorgan.

D

Project Management Office (PMO)

Abteilung, die Projektmanagement-Standards und -Praktiken etabliert, überwacht und weiterentwickelt. Im Carve-out- und Transformationskontext: operative Steuerungsinstanz mit Entscheidungsmacht, nicht nur Methodenhüter.

Unterschied Schwaches PMO verwaltet Berichte. Starkes PMO löst Blockaden und synchronisiert Workstreams.

»Ein schlecht aufgesetztes Projekt lässt sich nicht durch exzellente Ausführung retten — der Schaden entsteht in den ersten zwei Wochen.«

Abschnitt 03 · Methoden & Frameworks

Welches Vorgehen für welches Problem — kein Universalrezept.

Die Methodenwahl hängt von Komplexität, Anforderungsstabilität und Teamstruktur ab. Wer Agile aus Überzeugung einsetzt, wo Waterfall besser wäre, verliert Zeit. Wer Waterfall verteidigt, wo Komplexität iterative Anpassung erfordert, verliert Qualität.

Sequenziell · Wasserfall

Jede Phase abgeschlossen vor der nächsten

Anforderung → Design → Implementierung → Test → Deployment

Ideal bei: stabilen, klar definierten Anforderungen · regulierten Umgebungen · fixem Budget und Termin

Iterativ & inkrementell · Agile

Flexible Anpassung in Zyklen

Sprint Planning → Sprint (1–4 Wo.) → Review → Retrospektive → nächster Sprint

Ideal bei: veränderlichen Anforderungen · hoher Komplexität · enger Kundenzusammenarbeit

Waterfall-Risiken

Späte Fehlerentdeckung · Anforderungsänderungen teuer · Kein Kundenfeedback bis Projektende

Agile-Risiken

Scope-Kontrolle schwieriger · Budgetplanung weniger präzise · Erfordert hohe Teamdisziplin

01

Critical Path Method (CPM)

Netzwerkdiagrammtechnik zur Identifikation des längsten Wegs zur Fertigstellung — bestimmt den frühestmöglichen Endtermin und die Aktivitäten ohne Puffer.

02

Gantt-Chart

Balkendiagramm zur Visualisierung des Projektzeitplans: Aufgaben, Abhängigkeiten, Verantwortlichkeiten und Meilensteine auf einer Zeitachse. Standard-Kommunikationsmittel auf Führungsebene.

03

PERT

Program Evaluation and Review Technique — kombiniert Aktivitäten mit Wahrscheinlichkeiten und drei Zeitschätzungen (optimistisch / realistisch / pessimistisch). Geeignet bei hoher Planungsunsicherheit.

04

Kanban

Projektmanagementmethode mit visueller Workflow-Steuerung in Spalten (To Do / In Progress / Done). Macht Engpässe sichtbar, begrenzt Work in Progress und verbessert Durchlaufzeiten.

05

Design Thinking

Kundenorientierter Ansatz zur Lösung komplexer Probleme in 5 Phasen: Empathize → Define → Ideate → Prototype → Test. Stärke: erzwingt Perspektivwechsel auf Nutzerbedürfnisse.

06

Lean-Methoden

Maximierung des Kundennutzens bei gleichzeitiger Reduktion von Verschwendung. Fokus auf Wertströme, Pull-Prinzip und Kaizen (kontinuierliche Verbesserung). Ursprung: Toyota Production System.

07

MVP — Minimum Viable Product

Einfachste Version eines Produkts, die ausreicht, um die Kernidee zu testen und Kundenfeedback zu sammeln. Verhindert Overengineering und beschleunigt Lernzyklen.

08

Das Cynefin-Modell

Konzeptioneller Rahmen zur Entscheidungsfindung: ordnet Situationen in 5 Kontexte ein (Simple, Complicated, Complex, Chaotic, Disorder). Hilft, die richtige Methode für den jeweiligen Kontext zu wählen.

09

Der GEMBA Walk

Führungskräfte besuchen den Arbeitsplatz, um Prozesse vor Ort zu beobachten. Stärke: verhindert Entscheidungen auf Basis von Berichten statt Realität — Sehen geht vor Hören.

10

Planning Poker

Agile Schätztechnik: Teammitglieder schätzen Aufwände für User Stories anonym. Fördert Konsens, verhindert Anker-Effekte durch frühes Offenlegen einer Meinung.

11

User Stories

Anforderungsbeschreibungen aus Nutzerperspektive: »Als [Rolle] möchte ich [Funktion], damit [Nutzen].« Erzwingen Nutzerfokus statt technischer Beschreibung.

12

Burndown Chart

Visuelles Instrument zur Verfolgung des Sprint-Fortschritts: zeigt verbleibenden Aufwand gegen verbleibende Zeit. Macht Verzögerungen früh sichtbar — nicht erst am Sprint-Ende.

»Die beste Methode ist diejenige, die zum Problem passt — nicht diejenige, mit der man sich am wohlsten fühlt.«

Abschnitt 04 · Führung & Team

Warum Projekte an Menschen scheitern, nicht an Plänen.

Technische Kompetenz allein reicht nicht. Die häufigste Ursache für Projektversagen ist nicht fehlende Methodik — es sind ungeklärte Rollen, fehlende Kommunikation und ein Führungsvakuum in kritischen Momenten.

A

Stakeholdermanagement

Systematische Identifizierung, Einbeziehung und Kommunikation mit allen Personen oder Gruppen, die ein Interesse an oder Auswirkungen auf das Projekt haben. Stakeholder, die sich übergangen fühlen, werden zu Bremsern.

Prinzip Stakeholder-Mapping zu Beginn, nicht nach dem ersten Eskalationsanruf.

B

RACI Chart

Verantwortlichkeitsmatrix: Responsible (macht es), Accountable (trägt Verantwortung), Consulted (wird gefragt), Informed (wird informiert). Verhindert Rollenkonflikte, doppelte Zuständigkeiten und ungeklärte Eskalationspfade.

Regel Jede Aufgabe hat genau einen Accountable. Mehr als einen — und niemand ist verantwortlich.

C

Communication Plan

Definiert, wer welche Informationen wann, in welchem Format und über welchen Kanal erhält. Verhindert Informationslücken, Gerüchte und die klassische Aussage: »Das haben wir nicht gewusst.«

Praxis Lieber zu viel kommunizieren als zu wenig — der Aufwand für Aufräumarbeit nach Kommunikationsversagen ist immer höher.

D

Change Management

Strukturierter Ansatz zur Begleitung von Veränderungen in Organisationen. Stellt sicher, dass Projektveränderungen von Betroffenen angenommen und umgesetzt werden — nicht nur formal genehmigt. Technische Lösung ohne Change Management ist eine halbfertige Lösung.

Risiko Change Management, das erst nach Go-Live beginnt, ist Krisenmanagement.

01

Servant Leadership

Der Projektleiter stellt Bedürfnisse und Wohlergehen des Teams in den Vordergrund. Führen bedeutet hier: Hindernisse aus dem Weg räumen, nicht Kontrolle ausüben.

02

Anforderungsanalyse

Systematische Erfassung, Priorisierung und Dokumentation aller Anforderungen von Stakeholdern. Qualität der Anforderungsanalyse bestimmt direkt die Qualität aller nachfolgenden Deliverables.

03

Konfliktmanagement

Identifizierung, Bewältigung und Lösung von Konflikten im Projektteam oder zwischen Stakeholdern. Ungelöste Konflikte eskalieren — sie verschwinden nie von alleine.

04

Teammanagement

Führung, Motivation und Koordination des Projektteams: Rollen klären, Konflikte lösen, Performance fördern. Ein Team ohne Klarheit über Rollen und Ziele ist kein Team — es ist eine Gruppe.

05

Sprint

Fester Zeitraum (1–4 Wochen), in dem ein definierter Satz von Aufgaben abgeschlossen wird. Schafft Rhythmus, Fokus und regelmäßige Lieferfähigkeit — macht Fortschritt messbar.

»Die besten Pläne scheitern an der ersten Realitätskollision — Führung entscheidet, was danach passiert.«

Abschnitt 05 · Controlling & Steuerung

Frühwarnung statt Nachbetrachtung — das Iron Triangle steuern.

Projektcontrolling bedeutet kontinuierliche Überwachung, Steuerung und Anpassung entlang der drei klassischen Dimensionen. Wer erst beim Statusbericht merkt, dass ein Projekt aus dem Ruder läuft, hat bereits verloren.

S

Scope

Was wird geliefert? Der Umfang ist der am häufigsten unterschätzte Faktor. Jede Erweiterung über den vereinbarten Scope hinaus kostet entweder Zeit oder Geld — oder beides. Scope-Creep ist keine Naturgewalt, sondern ein Governance-Versagen.

Steuerung Jeder Change Request erhält eine formale Bewertung mit Impact auf Kosten, Zeit und Qualität — bevor er genehmigt wird.

K

Kosten

Budget und Ressourcen. Weniger Budget ohne Scope-Reduktion erfordert Zeit-Anpassung oder Qualitätskompromiss. Budgetüberschreitungen entstehen selten plötzlich — sie kündigen sich früh an und werden zu lange ignoriert.

Steuerung Earned Value Analysis: Vergleich von geplantem vs. tatsächlichem Fortschritt gegen den Budgetverbrauch.

Z

Zeit

Termin und Geschwindigkeit. Zeitdruck ohne Budgeterhöhung oder Scope-Reduktion führt zwingend zu Qualitätsverlust. »Schneller und besser mit weniger« ist keine Projektplanung — es ist eine Wunschliste.

Steuerung Critical-Path-Monitoring: Welche Aktivitäten haben Null-Puffer? Dort liegt das echte Terminrisiko.

Q

Qualität

Resultiert aus dem Gleichgewicht der drei anderen Dimensionen. Der unsichtbare vierte Faktor — wird als erstes kompromittiert, wenn Scope, Zeit oder Budget unter Druck geraten. Explizite Qualitäts-SLAs definieren, was Qualität bedeutet.

Steuerung Qualität ist kein Zustand am Projektende — sie wird durch kontinuierliche Reviews während der Ausführung gesichert.

A

Known Knowns

Bekannte Risiken mit bekannter Eintrittswahrscheinlichkeit. Direkt in den Risikoplan aufnehmen, Verantwortlichen zuordnen, Gegenmaßnahmen definieren. Keine Entschuldigung für spätes Reagieren.

Vorgehen Risikoregister mit Eintrittswahrscheinlichkeit, Impact, Gegenmaßnahme und Eskalationsschwelle.

B

Known Unknowns

Bekannte Risiken, deren genaues Ausmaß unklar ist. Puffer und Contingency-Planung einbauen. »Wir wissen, dass es Probleme geben wird bei X — wir wissen nur nicht wie viele.«

Vorgehen Contingency-Budget (typisch 10–20 % des Gesamtbudgets) explizit ausweisen und nur mit formaler Freigabe einsetzen.

C

Unknown Knowns

Wissen, das vorhanden, aber nicht explizit gemacht ist. Gefahr durch implizite Annahmen und undokumentiertes Expertenwissen. In IT-Projekten häufig: Konfigurationswissen das nur einzelne Personen haben.

Abwehr Strukturierter Knowledge-Transfer, explizite Dokumentation von Annahmen, regelmäßige Retrospektiven.

D

Unknown Unknowns

Nicht vorhersehbare Risiken. Erfordern Resilienz, Reaktionsfähigkeit und Krisenplanung. »Schwarze Schwäne« — selten, aber mit hohem Impact. Kein Risikoplan schützt vollständig davor.

Abwehr Rollback-Szenarien, Eskalationswege, War-Room-Bereitschaft und klare Go/No-Go-Kriterien definieren.

01

Monitor and Control Loop

Fortlaufender Prozess der Überwachung und Anpassung: Ist-Zustand messen → mit Plan vergleichen → Abweichung analysieren → Gegenmaßnahme einleiten. Kein einmaliger Vorgang.

02

Projektstatusbericht

Regelmäßige Zusammenfassung von Fortschritt, Performance und Problemen. Frequenz abhängig von Projektphase — täglich im CutOver, wöchentlich im Normalbetrieb.

03

Change Request

Formelle Anfrage zur Änderung von Scope, Zeitplänen oder Ressourcen. Jede Änderung muss dokumentiert, bewertet und mit Impact-Analyse genehmigt werden. Informelle Änderungen gibt es nicht.

04

Project Phase Gate

Formaler Prüfpunkt: Ist das Projekt bereit, zur nächsten Phase überzugehen? Gate-Review mit Sponsor und Steering Board — mit echten Go/No-Go-Kriterien, nicht nur Statusberichten.

05

Risk Appetite

Ausmaß und Art der Risiken, die eine Organisation im Streben nach ihren Zielen übernehmen will — strategisch festgelegt durch das Steering Board. Ohne definiertes Risk Appetite sind alle Risiken gleich behandelt.

06

Qualitätsmanagement

Festlegung von Standards, Richtlinien und Prozessen, um sicherzustellen, dass Deliverables den Stakeholder-Anforderungen entsprechen. Qualität muss definiert sein, bevor sie gemessen werden kann.

»Controlling ist kein Misstrauensbeweis — es ist das einzige Instrument, das Probleme löst, bevor sie Krisen werden.«

Abschnitt 06 · Reife & Maturity

Wo eine Organisation wirklich steht — und wie sie sich systematisch verbessert.

Reifegradmodelle helfen, den aktuellen PM-Stand zu bewerten und Verbesserungsmaßnahmen zu priorisieren. Die ehrliche Standortbestimmung ist häufig unbequem — und trotzdem der einzige valide Ausgangspunkt für strukturelle Verbesserung.

1Initial

Chaotisch

Prozesse nicht definiert · Erfolg personenabhängig · Ad-hoc-Reaktion

2Managed

Reproduzierbar

Grundprozesse definiert · Projektplanung etabliert · Ergebnisse wiederholbar

3Defined

Standardisiert

Organisationsweite Standards · Dokumentierte Prozesse · Wissenstransfer strukturiert

4Quantitative

Messbar

Quantitative Prozesssteuerung · KPI-getrieben · Vorhersagbarkeit hoch

5Optimizing

Optimierend

Kontinuierliche Verbesserung · Innovation aktiv · Organisationales Lernen verankert

01

Project Maturity Management (PMM)

Bewertet den Reifegrad eines Projektmanagementsystems in Bezug auf Prozesse, Methoden und Kompetenz. Ausgangspunkt für gezielte Verbesserung — nicht für Selbstbestätigung.

02

PMMM

PM Maturity Model — bewertet aktuelle PM-Fähigkeiten und liefert einen Rahmen zur systematischen Weiterentwicklung. Fünf Stufen von Ad-hoc bis kontinuierlicher Optimierung.

03

CMMI

Capability Maturity Model Integration — bekanntes Modell aus Softwareentwicklung und PM. Bewertet den Reifegrad von Prozessen in 5 Stufen. Breite Industrieakzeptanz als Benchmark.

04

BPMM

Business Process Maturity Model (Object Management Group) — speziell für Geschäftsprozesse. Ergänzt CMMI um prozessorientierte Sicht jenseits der reinen IT.

05

Wissensmanagement

Praktiken zur Erfassung, Speicherung und Weitergabe von Projektwissen. Lessons Learned sind nur dann wertvoll, wenn sie dokumentiert und in Folgeprojekten angewendet werden.

06

Projekt Governance

Strategische Ausrichtung, Entscheidungsfindung und Überwachung, um sicherzustellen, dass Projekte gemäß Organisationsrichtlinien geführt werden. Governance ist kein Overhead — sie verhindert Kontrollverlust.

»Die meisten Organisationen überschätzen ihren Reifegrad um mindestens eine Stufe — und unterschätzen damit den Aufwand für echte Verbesserung.«

Abschnitt 07 · Abschluss & Übergabe

Wann ein Projekt tatsächlich vorbei ist — und wie der Übergang gelingt.

Der Abschluss ist kein Ende — er ist der Übergang in den Betrieb. Diese Phase entscheidet, ob das Projektergebnis nachhaltig wirkt oder still erodiert. Häufigster Fehler: den Abschluss als Formalität zu behandeln, weil das Team bereits erschöpft ist.

A

User Acceptance Test (UAT)

Abschließender Test, bei dem Endbenutzer prüfen, ob das entwickelte System ihren Anforderungen entspricht — bevor es produktiv geht. UAT ist kein technischer Test. Es ist die formale Bestätigung, dass das Lieferobjekt den vereinbarten Anforderungen entspricht.

Regel UAT-Ergebnis wird schriftlich festgehalten und von Auftraggeber signiert. Mündliche Freigabe ist keine Freigabe.

B

Cutover-Plan & Go / No-Go

Detaillierter Plan zur Koordination der Migration von einem alten zu einem neuen System — mit spezifischen Schritten, Zeitplänen, Verantwortlichkeiten und vorbereiteten Rollback-Szenarien. Die Go/No-Go-Entscheidung basiert auf messbaren Kriterien — nicht auf Optimismus.

Kriterien Alle UAT-Defekte der Kritikalitätsstufe 1–2 geschlossen · Rollback-Szenario vollständig getestet · Eskalationswege bestätigt.

C

Hypercare Phase

Intensiver Support- und Servicezeitraum direkt nach Go-Live: erhöhte Supportbereitschaft, engmaschiges Monitoring, dedizierte Eskalationswege. Typisch: 4–8 Wochen. Wer Hypercare als Optional betrachtet, zahlt die Rechnung als Incident-Kosten.

Struktur Dediziertes Hypercare-Team · tägliches Incident-Review · klares Eskalationsprotokoll · Wochenberichte an Steering Board.

01

Betriebsübergang

Übertragung von Verantwortlichkeiten, Ressourcen und Aktivitäten an den operativen Betrieb. Stellt sicher, dass das Projektergebnis erfolgreich in den Regelbetrieb übergeht — mit vollständiger Dokumentation und Wissenstransfer.

02

Projektabschluss

Formelle Beendigung: Überprüfung der Projektziele, Dokumentationsabschluss, Bewertung des Projekterfolgs und offizielle Auflösung des Projektteams. Schafft rechtliche und organisatorische Klarheit.

03

Lessons Learned

Erfahrungen und Erkenntnisse aus dem Projekt, systematisch dokumentiert und in die Wissensbasis der Organisation überführt. Lessons Learned ohne Änderung der nächsten Projektplanung sind Archivarbeit.

»Ein Projekt ist nicht fertig, wenn der Code deployed ist — es ist fertig, wenn der Betrieb stabil läuft und das Wissen übergeben ist.«

Abschnitt 08 · Fazit

Projekte scheitern nicht an Methoden — sie scheitern an Klarheit, Führung und dem Mut, früh zu entscheiden.

Die meisten Projektprobleme sind keine Überraschungen. Sie kündigen sich früh an — in ungeklärten Anforderungen, fehlender Governance, überfordertem Team und einem Sponsor, der nominell existiert, aber nicht entscheidet. Wer diese Signale ignoriert, zahlt am CutOver-Wochenende oder in der Hypercare-Phase.

Operatives Projektmanagement beginnt dort, wo Methodenhandbücher enden: mit dem Mut, ein schlechtes Projekt früh zu stoppen, mit Eskalationen, die nicht populär sind, und mit Klarheit über das, was wirklich geliefert wird — nicht das, was auf der Folie steht.

Pierre Kromat · Programm-Management & IT-Transformation · April 2026

Mandat

Konkreter Projektfall? Reden wir.

Kurzgespräch, 30 Minuten. Direkteinschätzung, keine Akquise-Schleife. IT-Projekte, Transformationen, Carve-outs — operativ geführt.