Vom Konzept zum Projektplan — Verdichten, prüfen, iterieren

Ein gutes Konzept beschreibt, was sinnvoll sein könnte. Ein belastbarer Projektplan entscheidet, was als Nächstes geschehen soll, woran Fortschritt erkennbar ist und wann eine Annahme neu geprüft werden muss.

Zwischen einer guten Idee und einem guten Projektplan liegt mehr als Formatierung. Ein Konzept kann überzeugend klingen, viele Möglichkeiten enthalten und trotzdem noch zu offen sein, um daraus zuverlässig Arbeit abzuleiten. Ein Projektplan muss diese Offenheit reduzieren. Er übersetzt Ziele in Entscheidungen, Annahmen in Prüfungen, Abhängigkeiten in Reihenfolgen und Risiken in konkrete Reaktionen.

Genau an diesem Übergang scheitern viele KI-Projekte. Die Recherche war umfangreich, das Konzept wirkt plausibel, und die nächste Reaktion lautet: „Dann lass die KI jetzt einen Projektplan daraus machen." Das Ergebnis ist oft eine lange Liste von Phasen, Aufgaben und Zeiträumen. Sie sieht nach Planung aus, aber sie ist noch keine belastbare Projektarchitektur. Eine belastbare Planung entsteht erst, wenn der erste Entwurf selbst wieder zum Gegenstand der Prüfung wird.

Die Praxis zeigt dafür eine klare Entwicklung. Zuerst wird das Konzept methodisch aufgebaut: vom Problemraum über Recherche und Anforderungen bis zu Varianten, Architektur und Plausibilitätsprüfung. Danach wird das Konzept mit einer strukturierten Projektlogik verbunden: Ziel, Scope, Anforderungen, Machbarkeit, Ressourcen, Risiko, Reporting, Umsetzung und Evaluation. Später wird der erste Plan ausdrücklich nicht als Endprodukt behandelt. Er wird gegen Quellen, Methodenwissen und die tatsächliche Ausführungsform geprüft und überarbeitet.

Der wichtigste Perspektivwechsel lautet deshalb: Ein Projektplan ist keine ausgeschriebene Version des Konzepts. Er ist eine überprüfbare Entscheidung über dessen Umsetzung.

Konzept und Projektplan beantworten unterschiedliche Fragen

Ein Konzept fragt: Welches Problem bearbeiten wir? Für wen ist die Lösung relevant? Welche Anforderungen ergeben sich daraus? Welche Varianten sind denkbar? Welche Architektur erscheint plausibel?

Ein Projektplan fragt dagegen: Was wird tatsächlich umgesetzt? Was bleibt bewusst außerhalb des Scopes? Welche Annahmen müssen zuerst geprüft werden? Welche Ergebnisse brauchen wir, bevor wir weiter investieren? Welche Arbeit kann parallel laufen und welche nicht? Welche Risiken verändern den Plan? Wer oder was darf eine Entscheidung treffen? Wann muss ein Mensch eingreifen?

Diese Unterscheidung ist entscheidend, weil ein Konzept möglichst viel Relevantes sichtbar machen soll, während ein Projektplan bewusst reduziert. Ein gutes Konzept darf Alternativen enthalten. Ein guter Plan kann nicht alle Alternativen gleichzeitig verfolgen. Er muss festlegen, welche Hypothese zuerst getestet wird und welche Optionen vorerst geparkt werden.

Das ist der erste Akt der Verdichtung: aus Möglichkeiten werden Prioritäten.

Verdichten heißt nicht kürzen, sondern entscheiden

Ein Plan wird nicht besser, nur weil er kürzer ist. Verdichtung bedeutet, dass jede Aussage im Konzept eine operative Konsequenz bekommt oder bewusst als noch offene Annahme markiert wird.

Ein Beispiel: Im Konzept steht, dass eine Anwendung für kleine Teams besonders einfach bedienbar sein soll. Im Projektplan reicht es nicht, daraus die Aufgabe „Benutzerfreundliche Oberfläche entwickeln" zu machen. Der Plan muss entscheiden, wie diese Anforderung geprüft wird. Vielleicht lautet die erste operative Übersetzung: einen minimalen Nutzungspfad definieren, mit fünf typischen Aufgaben testen und erst danach weitere Funktionen planen.

Aus „soll sicher sein" wird nicht „Sicherheit implementieren", sondern eine Reihe prüfbarer Anforderungen, Verantwortlichkeiten und Stop-Kriterien. Aus „soll skalierbar sein" wird nicht sofort eine große Infrastruktur, sondern zunächst die Frage, welche Last realistisch erwartet wird und welche technische Entscheidung erst bei einem bestimmten Schwellenwert nötig wird.

Verdichtung ist daher eine Übersetzungsarbeit: Konzeptaussage → Planungsentscheidung → Prüfkriterium → nächste Aktion.

Je häufiger ein Plan diese Kette sichtbar macht, desto weniger Raum bleibt für scheinbar präzise, aber bedeutungslose Aufgabenlisten.

Die Baseline: Wofür dieses Projekt jetzt steht

Bevor Aufgaben erzeugt werden, braucht der Plan eine Baseline. Im Methoden-Mapping wird diese Logik später sehr knapp zusammengefasst: Zieldefinition, Scope und Non-Scope sowie ein kompakter Projektsteckbrief.

Eine gute Baseline beantwortet mindestens sechs Fragen:

1. Welches Ergebnis soll dieses Projekt erzeugen?

2. Für wen entsteht es?

3. Was gehört ausdrücklich dazu?

4. Was gehört ausdrücklich nicht dazu?

5. Welche Annahmen sind so wichtig, dass ihr Scheitern den Plan verändert?

6. Woran erkennen wir, dass die nächste Projektphase überhaupt gerechtfertigt ist?

Der Non-Scope ist dabei kein Nebensatz. Er ist ein Schutzmechanismus gegen das natürliche Wachstum von KI-Projekten. Gerade weil generative Systeme schnell neue Möglichkeiten vorschlagen, kann ein Projekt innerhalb weniger Gespräche von einer klaren Lösungsidee zu einer Sammlung faszinierender Zusatzfunktionen werden. Eine Baseline verhindert nicht, dass sich das Projekt weiterentwickelt. Sie macht sichtbar, wann eine Weiterentwicklung eine bewusste Änderung und nicht nur schleichender Scope Creep ist.

Slice: Tragfähigkeit vor Vollständigkeit

Nach der Baseline folgt die Frage, welcher kleinste belastbare Ausschnitt des Projekts beweisen kann, dass die Grundidee trägt. Im Methoden-Mapping wird dafür der Begriff Slice verwendet: Tragfähigkeitsprüfung, Vertical Slice und Machbarkeitslücken.

Das ist mehr als ein technischer Prototyp. Ein guter Slice prüft die riskantesten Annahmen des Konzepts möglichst früh. Bei einem KI-gestützten Beratungsprodukt könnte der Slice nicht darin bestehen, bereits eine komplette Plattform zu bauen. Er könnte darin bestehen, einen vollständigen Ablauf von Kundeneingabe über KI-Auswertung bis zu einer von einem Menschen geprüften Empfehlung einmal Ende-zu-Ende zu testen.

Der Slice beantwortet damit die Frage: Welche kleine, aber vollständige Erfahrung zeigt uns, ob die Architektur grundsätzlich funktioniert?

Das schützt vor einer typischen Fehlplanung: Man plant viele Wochen Funktionsentwicklung, obwohl eine zentrale Annahme noch gar nicht bewiesen ist. Wenn die Kernannahme später fällt, ist der Plan zwar sauber abgearbeitet worden, aber das Projekt wurde trotzdem falsch gesteuert.

Flow: Planung als Reihenfolge von Erkenntnissen

Viele klassische Projektpläne behandeln Arbeit wie eine lineare Produktionskette. In KI-Projekten ist das oft zu grob. Ein Teil der Arbeit produziert nicht nur Ergebnisse, sondern neue Informationen. Diese Informationen verändern den nächsten Schritt.

Deshalb ist Flow nicht nur eine Frage von Aufgabenreihenfolge, sondern von Erkenntnisreihenfolge. Welche Frage muss beantwortet sein, bevor die nächste Entscheidung sinnvoll wird? Welche Arbeit darf parallel laufen, ohne dass mehrere Teams auf dieselbe unsichere Annahme bauen? Wo brauchen wir Review-Takte? Wo entstehen WIP-Limits, damit zu viele halb fertige Stränge nicht gleichzeitig Aufmerksamkeit binden?

Ein guter Plan ordnet deshalb nicht einfach hundert Aufgaben. Er strukturiert den Fluss von Unsicherheit zu belastbarer Entscheidung.

Das kann so aussehen: Annahme → Test → Evidenz → Entscheidung → nächster Arbeitsblock.

Diese Logik ist besonders wichtig, sobald KI-Agenten oder automatisierte Workflows beteiligt sind. Ein Agent kann sehr viel Arbeit produzieren. Wenn die Reihenfolge falsch ist, produziert er nur schneller Arbeit auf Basis einer falschen Annahme.

Der erste Projektplan ist eine Hypothese

Einer der wertvollsten Momente in der Praxis ist nicht die Erstellung des ersten Plans, sondern seine Zurückweisung. In einem realen Fall entstand aus Konzept und Quellen zunächst eine sehr klassische Roadmap mit langen Zeiträumen. Sie wurde nicht akzeptiert, weil sie nicht zur vorgesehenen Ausführungsform passte. Der Plan musste neu gedacht werden: andere Rollen, andere Zeitlogik, stärkere Automatisierung, klarere menschliche Prüfpunkte.

Das Beispiel ist methodisch wichtiger als die konkrete Dauer. Es zeigt: Ein Plan kann formal vollständig und trotzdem konzeptionell falsch sein.

Der erste Plan sollte deshalb als Hypothese behandelt werden. Er behauptet beispielsweise:

• diese Reihenfolge ist sinnvoll,

• diese Rollenverteilung funktioniert,

• diese Zeitannahmen sind realistisch,

• diese Abhängigkeiten sind bekannt,

• diese Risiken sind ausreichend kontrolliert,

• diese Prüfpunkte reichen aus.

Jede dieser Aussagen kann falsch sein. Planung bedeutet nicht, diese Unsicherheit zu verstecken. Planung bedeutet, sie so sichtbar zu machen, dass sie geprüft werden kann.

Gegen Quellen prüfen, nicht nur gegen das eigene Gefühl

Nach einem ersten Entwurf beginnt die eigentliche Qualitätsarbeit. Der Plan wird gegen das Konzept, die Research-Basis und vorhandenes Methodenwissen geprüft.

Drei Vergleichsebenen sind besonders nützlich:

1. Konzepttreue: Deckt der Plan wirklich die Anforderungen des Konzepts ab? Wurden zentrale Ziele unterwegs stillschweigend durch leichter planbare Aufgaben ersetzt?

2. Evidenztreue: Welche Planungsentscheidungen werden von Quellen gestützt, und welche sind nur plausible Annahmen des Modells oder des Teams?

3. Methodentreue: Fehlen typische Elemente, die in vergleichbaren Projekten immer wieder wichtig waren — etwa Non-Scope, Machbarkeitsprüfung, Review-Takte, Risiko-Trigger oder Abbruchbedingungen?

Hier wird die Verbindung zu Artikel 04 und 05 sichtbar. Eine Wissensbasis hilft nicht nur beim Recherchieren. Ein Methoden-Mapping hilft nicht nur beim Dokumentieren guter Praxis. Beide werden zu Prüfinstrumenten für konkrete Projektpläne.

Prüfen bedeutet auch, Überplanung zu erkennen

KI macht eine neue Form von Überplanung attraktiv. Weil ein Modell sehr schnell hunderte Aufgaben, Unteraufgaben und Abhängigkeiten erzeugen kann, wirkt Detailtiefe wie Qualität. Tatsächlich kann sie Unsicherheit nur verdecken.

Ein Plan ist überplant, wenn er Entscheidungen vorgibt, für die noch keine Evidenz existiert. Typische Anzeichen sind:

• technische Architekturentscheidungen, bevor ein Slice die Notwendigkeit bewiesen hat,

• detaillierte Zeitpläne für Phasen, deren Voraussetzungen noch unsicher sind,

• Rollen und Prozesse, die nur aus einer Standardvorlage übernommen wurden,

• große Parallelisierung, obwohl mehrere Stränge von derselben offenen Annahme abhängen,

• komplette Umsetzungspakete ohne definierte Review- oder Stop-Gates.

In einer späteren Feinschliffphase wird deshalb ausdrücklich zwischen einem praxistauglichen Workflow und einem technischen Prototypen getrennt. Technik soll dort umgesetzt werden, wo Evidenz den Nutzen trägt. Das ist kein Innovationshemmnis. Es verhindert, dass technische Machbarkeit mit Projektwert verwechselt wird.

Iterieren heißt: den Plan verändern dürfen

Ein Plan, der nicht verändert werden darf, ist in unsicheren Projekten oft nur eine eingefrorene Vermutung. Iterative Planung bedeutet jedoch nicht, jede Woche alles neu zu erfinden. Sie braucht stabile Ebenen und veränderbare Ebenen.

Stabil bleiben sollten vor allem Zweck, Verantwortungslogik, Qualitätskriterien und dokumentierte Entscheidungen. Veränderbar bleiben dürfen Reihenfolge, technische Umsetzung, Detailaufgaben, Zeitannahmen und sogar einzelne Lösungsvarianten, wenn neue Evidenz das verlangt.

Dafür eignet sich eine Rolling-Waves-Logik: Der nächste Abschnitt wird detailliert geplant, spätere Abschnitte bleiben zunächst gröber. Sobald neue Informationen vorliegen, wird die nächste Welle konkretisiert.

So entsteht Präzision dort, wo sie verdient ist — und Flexibilität dort, wo noch Unsicherheit besteht.

Gates sind Entscheidungen, keine Kalendertermine

Ein Gate ist nicht einfach ein Meeting am Ende einer Phase. Es ist eine Entscheidungsschwelle. Ein gutes Gate sagt vorher, welche Evidenz vorliegen muss und welche Konsequenzen möglich sind.

Ein Gate kann beispielsweise vier Ergebnisse zulassen:

• weiter: Evidenz reicht für den nächsten Schritt,

• nacharbeiten: Ziel bleibt, aber bestimmte Lücken müssen geschlossen werden,

• umplanen: eine Annahme ist gefallen und die Architektur muss angepasst werden,

• stoppen: Aufwand, Risiko oder Nutzen rechtfertigen keine Fortsetzung.

Diese Klarheit ist besonders wichtig, wenn Teile des Projekts agentisch ausgeführt werden. Ohne Gates kann ein System sehr effizient in die falsche Richtung arbeiten. Mit Gates wird Autonomie begrenzt, ohne jeden Einzelschritt manuell steuern zu müssen.

Artikel 07 wird genau diese Verbindung vertiefen: warum Projektplanung agentische KI überhaupt erst steuerbar macht. Für Artikel 06 genügt die wichtigste Vorarbeit: Ein Plan muss so gebaut sein, dass Entscheidungen und Prüfpunkte erkennbar sind.

Ein guter Projektplan ist lesbar und ausführbar

Projektpläne haben zwei Zielgruppen. Menschen müssen verstehen können, warum das Projekt so aufgebaut ist. Ausführende Systeme — Menschen, Teams, Automationen oder Agenten — müssen erkennen können, was konkret zu tun ist.

Deshalb sollte jeder relevante Arbeitsblock mindestens enthalten:

Ziel: Welchen Zustand wollen wir erreichen?

Input: Welche Informationen oder Vorbedingungen brauchen wir?

Aktion: Welche Arbeit wird ausgeführt?

Output: Welches konkrete Ergebnis entsteht?

Prüfung: Woran erkennen wir ausreichende Qualität?

Entscheidung: Wer oder was darf den nächsten Schritt freigeben?

Fallback: Was passiert, wenn die Prüfung scheitert?

Diese Struktur macht aus einer Aufgabenliste eine kleine Entscheidungseinheit. Viele solcher Einheiten bilden einen Plan, der nicht nur dokumentiert, sondern tatsächlich steuert.

Sieben typische Fehler beim Übergang vom Konzept zum Plan

1. Das Konzept wird nur in Aufgaben zerlegt. Es fehlt die Übersetzung in Entscheidungen und Prüfkriterien.

2. Alle Ideen werden in den Scope übernommen. Der Plan priorisiert nicht, sondern sammelt.

3. Die riskanteste Annahme wird zu spät getestet. Viel Arbeit entsteht vor dem ersten echten Machbarkeitsbeweis.

4. Zeitpläne werden aus Gewohnheit übernommen. Sie passen nicht zur tatsächlichen Teamgröße, Automatisierung oder Ausführungsweise.

5. Detailtiefe ersetzt Evidenz. Der Plan wirkt präzise, obwohl wichtige Voraussetzungen noch offen sind.

6. Reviews sind Termine statt Entscheidungen. Es gibt keine definierten Kriterien für Weiter, Nacharbeit, Umplanung oder Stopp.

7. Der Plan wird nach der Freigabe nicht mehr als lernendes Modell behandelt. Neue Erkenntnisse werden dokumentiert, aber verändern den Plan nicht.

Die Planungs-Schleife

Ein belastbarer Übergang vom Konzept zum Projektplan lässt sich als wiederkehrende Schleife formulieren:

KONZEPT
  ↓
BASELINE: Ziel, Scope, Non-Scope, Annahmen
  ↓
SLICE: riskanteste Annahmen früh prüfen
  ↓
FLOW: Arbeit nach Erkenntnisabhängigkeiten ordnen
  ↓
PLANENTWURF
  ↓
GEGENPRÜFUNG: Konzept + Quellen + Methodenwissen
  ↓
GATES UND KRITERIEN SCHÄRFEN
  ↓
NÄCHSTE PLANUNGSWELLE
  ↺

Die Schleife endet nicht deshalb, weil ein Dokument fertig ist. Sie endet für eine Phase, wenn genügend Evidenz vorliegt, um verantwortbar weiterzugehen.

Plan-Review in acht Fragen

Vor der Freigabe eines Projektplans lohnt sich ein kurzer Review:

1. Ist das gewünschte Ergebnis klarer als die Liste der Aktivitäten?

2. Sind Scope und Non-Scope explizit?

3. Ist die riskanteste Annahme früh genug im Plan sichtbar?

4. Gibt es einen kleinen, vollständigen Slice, der Tragfähigkeit beweisen kann?

5. Sind Abhängigkeiten nach Erkenntnislogik und nicht nur nach Gewohnheit geordnet?

6. Hat jeder wichtige Gate ein vorher definiertes Prüfkriterium?

7. Welche Teile des Plans sind evidenzbasiert und welche noch Hypothesen?

8. Ist klar, wann und wodurch der Plan selbst geändert werden muss?

Wenn diese Fragen nicht beantwortet werden können, fehlt meist nicht noch mehr Detail. Es fehlt eine bessere Planungsentscheidung.

Planung ist kontrollierte Verdichtung

Der Weg vom Konzept zum Projektplan ist kein administrativer Schritt zwischen Ideenphase und Umsetzung. Er ist der Moment, in dem ein Projekt sich festlegt, ohne so zu tun, als wäre bereits alles bekannt.

Ein gutes Konzept hält Möglichkeiten offen. Ein guter Projektplan reduziert sie verantwortungsvoll. Er bestimmt, welche Annahme zuerst geprüft wird, welche Arbeit daraus folgt, welche Evidenz gebraucht wird und wann die nächste Entscheidung fällig ist.

Die Qualität eines Plans zeigt sich deshalb nicht daran, wie viele Aufgaben er enthält. Sie zeigt sich daran, wie gut er Unsicherheit in überprüfbare Entscheidungen verwandelt.

Und genau darin liegt die Grundlage für die nächste Stufe von AI Project Engineering: Erst wenn ein Plan diese Struktur besitzt, kann auch eine agentische KI sinnvoll Autonomie erhalten.

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt: