Der Stage-Gate-Prozess in der Fertigung: Phasen, Gates und Go/Kill-Entscheidungen

Was ist der Stage-Gate-Prozess

Der Stage-Gate-Prozess ist ein Governance-Rahmen für die Steuerung der Entwicklung neuer Produkte, von Investitionsprojekten und anderen risikoreichen Vorhaben, indem er sie in strukturierte Arbeitsphasen unterteilt, die durch Entscheidungspunkte getrennt sind. Sein charakteristisches Merkmal sind nicht die Phasen selbst (viele Methoden nutzen Phasen), sondern die disziplinierten Entscheidungs-Gates zwischen ihnen, an denen ein funktionsübergreifendes Gremium entscheidet, ob das Projekt fortgeführt, beendet, pausiert oder zu früherer Arbeit zurückgeführt wird. Hersteller führten Stage-Gate zuerst ein, weil die Asymmetrie zwischen den Kosten eines frühen Stopps eines schlechten Projekts und den Kosten eines späten Stopps nirgends größer ist als bei der Entwicklung physischer Produkte.

Die wörtliche Definition: Phasen und Gates

Eine Phase ist ein definierter Arbeitsblock mit konkreten zu erstellenden Deliverables. Ein Gate ist ein Entscheidungspunkt, an dem diese Deliverables anhand vorab definierter Kriterien bewertet werden. Alles andere in Stage-Gate ist eine Ausarbeitung dieser beiden Begriffe. Phasen sind keine Projektphasen im gewöhnlichen Sinne des Projektmanagements; es sind Blöcke zur Hypothesenprüfung, die Unsicherheit über ein Produkt in Evidenz für die nächste Entscheidung umwandeln. Gates sind keine Statusmeetings; es sind binäre oder vierwertige Entscheidungen, die genehmigte Ressourcen für die nächste Phase freigeben oder diese Ressourcen an das Portfolio zurückgeben. Die Stärke des Rahmens entsteht aus der strikten Trennung der beiden Begriffe: Arbeit geschieht in Phasen, Entscheidungen fallen an Gates, und beides zu vermischen (während der Arbeit zu entscheiden oder während Entscheidungen zu arbeiten) zerstört die Disziplin, die den Rahmen wertvoll macht.

Ursprung: Robert Cooper und vierzig Jahre Stage-Gate

Stage-Gate wurde von Robert G. Cooper formalisiert, einem kanadischen Innovationsforscher an der McMaster University in Hamilton, Ontario, dessen erste öffentliche Beschreibung des Rahmens 1986 nach Benchmarking-Studien von Hunderten Projekten zur Entwicklung neuer Produkte über Dutzende Unternehmen hinweg erschien. Coopers ursprüngliche Forschung identifizierte Erfolgstreiber der NPD, die zuvor als Glück behandelt worden waren: Portfoliofokus, gründliche Vorarbeit in der Frühphase, funktionsübergreifende Teams und disziplinierte Go/Kill-Entscheidungen. Diese Erkenntnisse wurden zum Stage-Gate-Rahmen, der sich seither über fünf Generationen entwickelt hat. Die erste Generation war die an der NASA orientierte phasenbasierte Projektplanung der 1960er Jahre. Die zweite Generation war Coopers ursprüngliche Version von 1986. Die dritte Generation ergänzte in den 1990er Jahren das Portfoliomanagement. Die vierte Generation ergänzte in den 2000er Jahren die agile Hybridisierung. Die fünfte Generation, formalisiert in Coopers offizieller Version von 2026, die in der PDMA-Community veröffentlicht wurde, ergänzt die vier Fs (fluid, adaptable, focused, flexible), um den Rahmen reaktionsfähiger für schnelllebige Märkte zu machen, ohne die Governance-Disziplin zu opfern. Cooper wurde 2023 von der PDMA für die Bedeutung des Rahmens für die Praxis des Innovationsmanagements weltweit ausgezeichnet.

Warum die Fertigung Stage-Gate zuerst einführte

Die Asymmetrie zwischen Kosten in frühen und späten Phasen ist nirgends größer als in der NPD der Fertigung, weshalb Hersteller Stage-Gate vor anderen Branchen einführten und weshalb es heute laut den Tracking-Daten von Stage-Gate International rund 80 % der nordamerikanischen Unternehmen in irgendeiner Form nutzen. Ein Softwareprodukt, das nach sechs Wochen Entwicklung abgebrochen wird, hat sechs Wochen Engineering-Zeit verbraucht. Ein physisches Produkt, das abgebrochen wird, nachdem Werkzeuge beauftragt wurden, hat sechs- oder siebenstellige Euro-Investitionen in Stahl und Ausrüstung verbraucht, die sich nicht zurückgewinnen lassen. Dieses Kostengefälle macht die Disziplin, schlechte Projekte früh abzubrechen, den Aufwand von Gate-Meetings und Deliverable-Prüfungen wert. Zu den frühen Anwendern Ende der 1980er und in den 1990er Jahren zählten Exxon, Procter and Gamble und DuPont, deren Erfolgsgeschichten die Verbreitung des Rahmens über Branchen hinweg förderten. Die natürliche Passung zu Investitionsfreigabeprozessen und zu Anforderungen an die regulatorische Dokumentation beschleunigte die Einführung in Fertigungsteilbranchen wie Pharma, Medizintechnik und Automobil.

Anatomie einer Phase und eines Gates

Stage-Gate operativ tiefgehend zu verstehen bedeutet, vier Dinge zu verstehen: was innerhalb einer Phase geschieht, was innerhalb eines Gates geschieht, was die möglichen Gate-Ergebnisse bedeuten und wer die Gate-Entscheidung verantwortet. Jeder dieser Punkte verdient sorgfältige Aufmerksamkeit, weil es genau die Elemente sind, die am häufigsten verwässert werden, wenn Organisationen Stage-Gate oberflächlich einführen.

Innerhalb einer Phase: Aktivitäten, Deliverables, funktionsübergreifende Arbeit

Eine Phase ist ein definierter Arbeitsblock mit klar festgelegten Deliverables, die bis zu ihrem Ende zu erstellen sind. Die Arbeit innerhalb einer Phase geschieht parallel über funktionsübergreifende Teams hinweg: Forschung und Entwicklung am Produkt selbst, Engineering an der Herstellbarkeit, Qualität an den Validierungsanforderungen, Einkauf an der Komponentenbeschaffung, Marketing an Positionierung und Launch-Planung. Deliverables sind die Artefakte, an denen der Abschluss der Phase gemessen wird, nicht bloß die Arbeitsergebnisse; sie existieren, um die nächste Gate-Entscheidung zu speisen, nicht um die Arbeit um ihrer selbst willen zu dokumentieren. Phasenarbeit ist auch kein Ausfüllen von Vorlagen; sie ist Hypothesenprüfung. Jede Phase nimmt Hypothesen über das Produkt (Marktpassung, technische Machbarkeit, kommerzielle Tragfähigkeit) und wandelt sie in Evidenz um, die diese Hypothesen stützt oder widerlegt, und genau das braucht das nächste Gate-Gremium, um eine echte Entscheidung zu treffen.

Innerhalb eines Gates: Prüfung der Deliverables, Entscheidungskriterien, Entscheidungsergebnisse

Ein Gate ist ein Entscheidungsmeeting, kein Statusmeeting. Das Projektteam präsentiert die in der vorherigen Phase erstellten Deliverables und begründet, warum das Projekt für die nächste Phase bereit ist. Das Gremium bewertet diese Deliverables anhand vorab definierter Kriterien, die allen im Voraus bekannt sind, nicht anhand während des Meetings erfundener Kriterien. Die Entscheidung wird mit angehängter Begründung festgehalten und in der Projekthistorie archiviert, was bedeutet, dass jeder, der dem Projekt später beitritt, rekonstruieren kann, warum jedes Gate so ausging, wie es ausging. Gates, die diese Disziplin nicht befolgen, verkommen zu Statusmeetings, in denen Sponsoren über den Arbeitsfortschritt berichten und keine echte Entscheidung fällt, was der häufigste Fehlermodus schlecht umgesetzter Stage-Gate-Prozesse ist.

Gate-Ergebnisse: go, kill, hold, recycle

Coopers Rahmen definiert vier mögliche Gate-Ergebnisse, nicht zwei. Go bedeutet, mit den für diese Phase genehmigten Ressourcen in die nächste Phase überzugehen. Kill bedeutet, das Projekt endgültig zu beenden und seine Ressourcen an das Portfolio freizugeben; kill ist nicht dasselbe wie pausieren, und Organisationen, die kill als umkehrbar behandeln, untergraben den Rahmen. Hold bedeutet, das Projekt bis zur Lösung konkreter Probleme innerhalb einer definierten Frist zu pausieren, mit automatischer Beendigung, falls die Probleme nicht gelöst werden. Recycle bedeutet, mit einer konkreten Liste dessen, was überarbeitet werden muss und warum, in die vorherige Phase zurückzukehren. Kill und recycle sind ebenso wichtig wie go; eine gesunde Stage-Gate-Umsetzung zeigt nennenswerte Kill- und Recycle-Raten, und deren Fehlen signalisiert, dass der Rahmen zum bloßen Abnicken verkommt.

Wer die Gate-Entscheidung verantwortet (Governance)

Die Gate-Entscheidung gehört einem funktionsübergreifenden Gate-Gremium, nicht einem einzelnen Sponsor. Zur typischen Besetzung gehören eine Leitung des Betriebs, eine Leitung aus Forschung und Entwicklung oder Engineering, eine Leitung des Marketings, eine Vertretung der Finanzen und bei den größten Gates ein Mitglied der Geschäftsführung. Die Zusammensetzung spiegelt die Funktionen wider, denen das Projekt dienen soll; ein Projekt zur Stärkung der Fertigungsbasis braucht den Betrieb am Tisch, und ein Projekt zum Eintritt in ein neues Marktsegment braucht das Marketing am Tisch. Der Wechsel der Mitglieder ist bewusst langsam (zwei bis drei Jahre), damit sich Portfoliokontext aufbaut und die Gremienmitglieder Projekte über Zyklen hinweg vergleichen können. Eine Quorumsanforderung verhindert Ad-hoc-Entscheidungen mit fehlenden kritischen Funktionen, und das Fehlen einer kritischen Funktion an einem bestimmten Gate bedeutet, dass das Gate verschoben statt fortgeführt wird, eine Disziplin, deren Etablierung Zeit braucht, die aber wesentlich ist, damit der Rahmen wie vorgesehen funktioniert.

Die fünf kanonischen Phasen von Coopers klassischem Modell

Coopers Fünf-Phasen-Fünf-Gate-Modell ist seit 1986 die Referenzumsetzung und bleibt der Ausgangspunkt, von dem die später beschriebenen Varianten abweichen. Fünf durch fünf Gates getrennte Phasen führen ein Projekt von der Identifikation einer Chance bis zum Launch und zum Post-Launch-Review. Jede Phase baut auf den Deliverables der vorherigen Phase auf, und jedes Gate verbraucht diese Deliverables, um die nächste Phase zu genehmigen. Die folgende Beschreibung ist die kanonische Version; einzelne Unternehmen passen Namen und Grenzen an, doch der zugrunde liegende Ablauf ist über Umsetzungen hinweg bemerkenswert konsistent.

Phase 1: Scoping

Scoping ist eine schnelle, kostengünstige Vorabbewertung einer Chance. Ein kleines Team verbringt ein bis vier Wochen mit begrenztem Budget mit Schreibtischrecherche zu Marktchance, technischer Möglichkeit, Wettbewerbsumfeld und vorläufiger geschäftlicher Attraktivität. Deliverables sind ein kurzes Scoping-Dokument, ein vorläufiger Business Case mit groben Zahlen und eine erste Risikoliste. Gate 1 (Idea Screen) filtert eingehende Ideen anhand grundlegender strategischer Passung und Machbarkeitskriterien; Gate 2 (Second Screen) filtert die verbliebenen Ideen nach dem Scoping anhand strengerer Machbarkeitskriterien. Zusammen reduzieren diese beiden Gates typischerweise einen Pool von fünfzig bis zweihundert eingehenden Ideen auf zehn bis zwanzig weiter zu entwickelnde Konzepte, wobei die Überlebenskriterien eher auf strategische Ausrichtung und vorläufige Marktattraktivität gewichtet sind als auf detaillierte Machbarkeit (die Phase 2 ordentlich prüfen wird).

Phase 2: Business Case (Gate 3 „Go to Development“)

Die Business-Case-Phase ist die tiefste analytische Phase, bevor eine große Investition zugesagt wird. Eine detaillierte Marktanalyse quantifiziert das Zielsegment, seine Größe, sein Wachstum und die Wettbewerbsdynamik. Eine Machbarkeitsstudie bestätigt, dass das beabsichtigte Produkt mit akzeptablen Kosten und akzeptabler Qualität gebaut werden kann. Ein detaillierter Projektplan bemisst den Entwicklungsaufwand mit Meilensteinen, Ressourcen und Budget. Finanzprojektionen berechnen NPV, IRR, Amortisationsdauer und Break-even-Volumen mit Sensitivitätsanalyse rund um zentrale Annahmen. Das Product Definition Package spezifiziert Funktionen, Leistungsanforderungen, Zielkosten und Zielpreis. Gate 3 (Go to Development) ist das folgenreichste Gate des Rahmens, weil es die größte einzelne Investitionszusage genehmigt; Kill-Raten von 50 bis 70 % an diesem Gate sind in gesunden Umsetzungen typisch, und Organisationen mit Kill-Raten unter 30 % an Gate 3 haben meist eine weiche Gate-Disziplin statt außergewöhnlicher Ideenqualität.

Phase 3: Development

Development verwandelt das Product Definition Package in ein funktionierendes Produkt. Der Detailentwurf erstellt technische Zeichnungen, CAD-Modelle und Stücklisten. Das Prototyping erzeugt funktionsfähige Einheiten für interne Tests und Iteration. Das Marketing entwickelt Launch-Plan, Positionierung und Preisstrategie. Der Betrieb entwickelt Produktionsplan, Werkzeuganforderungen und Lieferantenvereinbarungen. Zu den Deliverables gehören funktionierende Prototypen, Entwürfe der Marketingpläne, Entwürfe der Produktionspläne und ein aktualisierter Business Case, der widerspiegelt, was in der Entwicklung gelernt wurde. Gate 4 (Go to Testing) bewertet, ob das Produkt für die externe Validierung mit Kunden bereit ist und ob die umgebenden Pläne für die Anforderungen der Testphase bereit sind.

Phase 4: Testing and Validation

Testing and Validation ist der Punkt, an dem das Produkt auf den realen Markt trifft. Feldversuche mit Leitkunden liefern Rückmeldungen zur Leistung unter tatsächlichen Nutzungsbedingungen. Interne Tests decken Sicherheit, Zuverlässigkeit (typischerweise durch beschleunigte Lebensdauertests, die Jahre der Nutzung in Wochen simulieren) und funktionale Leistung ab. Markttests validieren Preis, Positionierung und Botschaft bei Zielsegmenten. Die Pilotproduktion fertigt kleine Mengen auf produktionsrepräsentativem Equipment, um Fertigungsprobleme vor der Vollproduktion aufzudecken. Zu den Deliverables gehören Testergebnisse, ein verfeinerter Business Case, eine Launch-Readiness-Bewertung und etwaige verbleibende Aktualisierungen des Risikoregisters. Gate 5 (Go to Launch) ist die letzte Zusage vor dem Markteintritt; Kills an diesem Gate sind selten, aber nicht null, und an Gate 5 entdeckte Probleme sind immer noch wesentlich günstiger zu beheben als nach dem Launch entdeckte Probleme.

Phase 5: Launch

Launch setzt die in früheren Phasen entwickelten Pläne um. Das Marketing rollt Positionierung, Kommunikation und Kanalstrategie aus. Die Produktion fährt vom Pilot- auf den Vollbetrieb hoch. Vertriebsteams werden geschult und beginnen zu verkaufen. Serviceteams übernehmen Installation, Garantie und Support. Regulatorische Freigaben müssen vor Beginn des Launches bestätigt und dokumentiert sein. Zu den Deliverables gehören der durchgeführte Launch selbst und ein geplantes Post-Launch-Review. Das Post-Launch-Review, sechs bis zwölf Monate nach dem Launch abgehalten, wird nicht immer im strengen Sinne als Gate behandelt, gehört aber kanonisch zum Rahmen, weil es die tatsächliche Leistung mit dem Business Case vergleicht, der das Projekt genehmigte, und seine Lessons Learned speisen ein Repository, das Scoping und Business-Case-Arbeit späterer Projekte verbessert. Organisationen, die das Post-Launch-Review auslassen, verlieren den wichtigsten Lernmechanismus des Rahmens.

Fünf Varianten des Stage-Gate-Prozesses

Das klassische Fünf-Phasen-Fünf-Gate-Modell ist die Grundlage, nicht die einzige Option. Cooper und Praktiker haben Varianten entwickelt, die den Rahmen an unterschiedliche Projekttypen, Branchen und organisatorische Reifegrade anpassen. Die Wahl der richtigen Variante ist ebenso wichtig wie die Umsetzung der gewählten, denn die falsche Anwendung einer für einen anderen Projekttyp gedachten Variante ist eine der häufigsten Ursachen für Frust mit Stage-Gate in Organisationen, die glaubten, den Rahmen korrekt eingeführt zu haben.

Klassisch 5-Phasen-Stage-Gate (Grundlage)

Die klassische Fünf-Phasen-Version ist Coopers Modell von 1986 und bleibt die Referenzumsetzung für die Entwicklung neuer Produkte in den meisten Fertigungsorganisationen. Sie eignet sich für Produkte mit nennenswertem Innovationsgehalt, mittlerem bis hohem Entwicklungsrisiko und einer erwarteten Lebensdauer von mehreren Jahren oder mehr. Die Ende-zu-Ende-Zeiträume liegen typischerweise bei zwölf bis sechsunddreißig Monaten von Gate 1 bis zum Launch, wobei die genaue Dauer von der Produktkomplexität und dem regulatorischen Kontext der Branche abhängt. Organisationen, die sich Stage-Gate zum ersten Mal nähern, sollten standardmäßig zur klassischen Version greifen statt zu einer Variante, weil sich die Disziplin des Rahmens mit der Referenzumsetzung leichter etablieren lässt, bevor man ihn an konkrete Umstände anpasst.

Erweitert 7-Phasen für regulierte Fertigung

Die erweiterte Variante fügt zwei Phasen für regulierte Produkte hinzu: eine Phase Regulatory Approval vor dem Launch und eine Phase Post-Launch Compliance für laufende regulatorische Pflichten. Medizinprodukte unter FDA 510(k) oder CE MDR, Arzneimittel unter FDA oder EMA, Automobilkomponenten unter IATF 16949 und ISO 26262 sowie Luftfahrtkomponenten unter FAA oder EASA profitieren alle von dieser Variante, weil die regulatorische Arbeit umfangreich genug ist, um eine eigene Phase und ein eigenes Gate zu verdienen, statt in bestehende Phasen eingefaltet zu werden. Zu den Deliverables an den zusätzlichen Gates gehören die Fertigstellung des Design History File, Verifikations- und Validierungsberichte, das regulatorische Einreichungsdossier und der Plan zur Marktüberwachung. Die Zeiträume verlängern sich entsprechend, mit typischen Zyklen von drei bis sieben Jahren bei komplexen regulierten Produkten.

Express 3-Phasen für Produktlinienerweiterungen

Die Express-Variante verdichtet den Rahmen für Projekte, die nicht sein volles Gewicht brauchen: Linienerweiterungen, Verpackungsänderungen, kleinere Produktverbesserungen oder SKU-Ausweitungen, die bestehende Plattformen wiederverwenden. Drei Phasen ersetzen fünf: Assessment (Scoping und Business Case kombiniert), Development (Entwicklung und Test kombiniert) und Launch. Zwei Gates ersetzen fünf. Die Zeiträume liegen typischerweise bei drei bis neun Monaten. Der entscheidende Unterschied besteht darin, dass Express eine bewusste Variante mit eigener Disziplin ist, nicht eine Kurzform für das Ad-hoc-Überspringen von Gates im klassischen Modell. Organisationen, die das klassische Modell bei einzelnen Projekten abkürzen („das ist ein kleines, Gate 3 können wir überspringen“), untergraben den Rahmen; Organisationen, die Express als dokumentierte Variante für definierte Projekttypen einführen, wenden Stage-Gate korrekt an.

Agile-Stage-Gate (Coopers Hybrid von 2016)

Agile-Stage-Gate ist Coopers eigene formalisierte Anpassung von Stage-Gate für schnelllebige Produktumgebungen, 2016 veröffentlicht und durch nachfolgende Fallstudien verfeinert. Die äußere Struktur bleibt Stage-Gate mit seinen vertrauten Gates und der funktionsübergreifenden Governance. Innerhalb jeder Phase geschieht die Arbeit in agilen Sprints von zwei bis vier Wochen mit iterativen Reviews mit Kunden oder Stakeholdern. Die Gates werden leichter und akzeptieren agile Artefakte wie Demos und Sprint-Ergebnisse neben traditionellen Deliverables, doch die Governance-Disziplin bleibt. Cooper und Kollegen veröffentlichten 2025 in Research-Technology Management eine Fallstudie über Tetra Pak, die zeigt, wie ein großer Hersteller mit erheblichem Hardware-Anteil Agile-Stage-Gate einführte, und bietet praktische Lehren zu Transformationsmethodik und Change-Management für andere Hersteller, die die Variante erwägen. Am besten passt sie zu Produkten, die Hardware und Software kombinieren, etwa Geräte des Internets der Dinge, Wearables und Unterhaltungselektronik.

Adaptive Stage-Gate (Coopers 5G, 2020er Jahre)

Adaptive Stage-Gate ist Coopers Rahmen der nächsten Generation, veröffentlicht als offizielle Version 2026 in der PDMA-Community. Es baut auf den vier Fs auf: fluid (erlaubt überlappende Phasen und parallele Arbeitsströme dort, wo das klassische Stage-Gate auf strikter Reihenfolge bestand), adaptable (erlaubt Organisationen, den Rahmen je Projekttyp zu konfigurieren, ohne den Rahmen zu verlassen), focused (reduziert bürokratischen Overhead zugunsten der Entscheidungsqualität) und flexible (akzeptiert parallele Verarbeitung und spiralförmige Entwicklung innerhalb der Gesamtstruktur). Adaptive Stage-Gate berücksichtigt zudem Nachhaltigkeit über die verwandte, 2024 von Cooper veröffentlichte Variante Eco-Stage-Gate, die dem Gate-Scoring neben den traditionellen strategischen, marktbezogenen, technischen und finanziellen Dimensionen ökologische Kriterien hinzufügt. Adaptive passt zu reifen Organisationen, die dem klassischen Rahmen entwachsen sind und eine Version brauchen, die sich an moderne Gegebenheiten anpasst, ohne die Governance-Disziplin aufzugeben.

Deliverables und Go/Kill-Kriterien an jedem Gate

Ein Gate bedeutet nur dann etwas, wenn seine Kriterien vorab bekannt sind und konsistent angewendet werden. Ad-hoc-Entscheidungen, die im Raum während eines Gate-Meetings getroffen werden, sind keine Governance; sie sind als Prozess verkleidete Politik. Die drei Unterabschnitte unten beschreiben die Disziplin, die einen funktionierenden Stage-Gate-Prozess vom Schauspiel trennt: was als Deliverable erscheinen muss, wie Deliverables bewertet werden und wann kill die richtige Antwort ist.

Deliverable-Checklisten: must-have versus should-have

Deliverables an jedem Gate teilen sich in must-have und should-have. Must-have-Deliverables sind für die Gate-Entscheidung absolut erforderlich: Business Case an Gate 3, Testergebnisse an Gate 5, regulatorische Freigabe am Regulatory Gate der erweiterten Variante. Ohne ein Must-have-Deliverable geht das Gate ohne Debatte automatisch auf hold; die Entscheidung kann ohne die Information nicht getroffen werden. Should-have-Deliverables stärken die Entscheidung, blockieren sie aber nicht: Muster von Kundenrückmeldungen, Aktualisierungen der Wettbewerbsanalyse, Auffrischungen der Marktdaten. Fehlende Should-have-Deliverables können zu einem bedingten go mit der Vereinbarung führen, die fehlende Position in den ersten Wochen der nächsten Phase zu vervollständigen, oder zu recycle, wenn die fehlende Information die Go-Entscheidung wahrscheinlich ändert. Der Unterschied ist wichtig, weil er beide Extreme verhindert: Gates, die Entscheidungen wegen geringfügiger Deliverable-Lücken verweigern, und Gates, die Projekte ohne die für eine echte Entscheidung nötigen Informationen genehmigen.

Bewertungskriterien: strategische Passung, Marktattraktivität, technische Machbarkeit, finanzielle Rendite

Coopers Standard-Bewertungsmodell nutzt vier Dimensionen: strategische Passung zur Ausrichtung und zum Portfolio der Organisation, Marktattraktivität hinsichtlich Größe, Wachstum und Wettbewerbsposition, technische Machbarkeit angesichts aktueller und erreichbarer Fähigkeiten sowie finanzielle Rendite hinsichtlich erwartetem NPV, IRR und Amortisation gegenüber der erwarteten Investition. Jede Dimension wird auf einer Skala von eins bis zehn mit im Portfolio-Bewertungsmodell definierten Gewichten bewertet, und die gewichtete Gesamtpunktzahl ist der primäre Input für die Gate-Entscheidung. Schwellenwerte für Go-Entscheidungen liegen bei der Gesamtpunktzahl typischerweise im Bereich von 6,5 bis 7,5 von 10; Projekte unterhalb dieser Schwelle an einem Gate werden abgebrochen oder zurückgeführt, statt fortzufahren. Die Punktzahlen selbst sind weniger wichtig als ihre Konsistenz über Projekte hinweg: Der Wert des Rahmens entsteht daraus, dieselbe Bewertungsdisziplin auf jedes Projekt anzuwenden, damit der Portfoliovergleich aussagekräftig ist.

Kill-Kriterien: wann ein Projekt endgültig zu stoppen ist

Kill-Kriterien unterscheiden sich von Hold-Kriterien und müssen separat dokumentiert werden, weil kill Ressourcen an das Portfolio freigibt, während hold sie reserviert. Zu den expliziten Kill-Kriterien gehören: bestätigte strategische Fehlausrichtung auf einer Ebene, die recycle nicht beheben kann, entdeckte technische Nichtmachbarkeit, die sich nicht zu akzeptablen Kosten umgehen lässt, eine Marktchance, die verschwunden oder entschieden vom Positioning des Produkts weggerückt ist, und eine finanzielle Rendite, die so weit unter die Kapitalkosten gefallen ist, dass die Fortführung des Projekts Wert vernichtet. Organisationen ohne dokumentierte Kill-Kriterien entwickeln Zombie-Projekte, die weder vorankommen noch enden; die Disziplin des Rahmens verlangt, dass kill eine routinemäßige, nicht strafende Entscheidung ist, wenn die Evidenz sie stützt, und der Weg, sie routinemäßig zu machen, besteht darin, vorab zu definieren, welche Evidenz sie stützt.

Governance des Gate-Gremiums

Governance ist der Punkt, an dem Stage-Gate-Umsetzungen gelingen oder scheitern. Der Rahmen selbst ist unkompliziert; ihn in einer Organisation zum Laufen zu bringen erfordert eine disziplinierte Governance des Gate-Gremiums, des Rhythmus, in dem es tagt, und der politischen Dynamik, die jede Gate-Entscheidung umgibt. Die drei Unterabschnitte unten decken die drei Governance-Bereiche ab, die ernsthafte Stage-Gate-Umsetzungen von solchen trennen, die Vorlagen, aber keine Entscheidungen produzieren.

Wer im Gate-Gremium sitzt

Zur Mitgliedschaft im Gate-Gremium gehören typischerweise eine Leitung aus Forschung und Entwicklung oder Engineering, eine Leitung des Betriebs, eine Leitung des Marketings, ein CFO oder eine Finanzvertretung und bei den größten Gates ein CEO oder Geschäftsführer, der die Gesamtausrichtung des Geschäfts vertritt. Die Zusammensetzung spiegelt die Funktionen wider, denen das Projekt dienen soll, statt der Funktionen, die das Projekt verbraucht: Ein Projekt zur Stärkung der Fertigungsbasis braucht den Betrieb am Tisch mit der Befugnis, den Plan anzunehmen oder abzulehnen; ein Projekt zum Eintritt in einen neuen Markt braucht ein entsprechend ermächtigtes Marketing. Der Wechsel der Mitgliedschaft ist bewusst langsam, typischerweise zwei bis drei Jahre, damit sich Portfoliokontext und die Fähigkeit zum projektübergreifenden Vergleich in einzelnen Gremienmitgliedern aufbauen. Eine wichtige Regel: Kann eine für eine bestimmte Gate-Entscheidung wesentliche Funktion nicht teilnehmen, wird das Gate verschoben statt fortgeführt, was Ad-hoc-Entscheidungen verhindert, denen die für eine echte Entscheidung nötige Perspektive fehlt.

Der Rhythmus der Gate-Meetings

Funktionierendes Stage-Gate läuft in einem Rhythmus statt als einmalige Ereignisse. Monatliche Portfolio-Review-Meetings umfassen typischerweise die in diesem Monat fälligen Gate-Entscheidungen, wobei einzelne Gate-Reviews dreißig bis sechzig Minuten pro Projekt dauern, wenn die Deliverables ordentlich im Voraus vorbereitet sind. Vierteljährliche strategische Reviews decken die gesamte Portfoliozusammensetzung und die strategische Ausrichtung ab. Das zu vermeidende Antimuster sind Gate-Meetings, die nur stattfinden, wenn sie jemand einberuft, was Projekte treiben lässt und die Gespräche auf Portfolioebene verhindert, die einzelne Gate-Entscheidungen aussagekräftig machen. Das andere Antimuster besteht darin, Gate-Meetings als Statusupdates zu behandeln, in denen der Sponsor über den Fortschritt berichtet, statt dass das Gremium Entscheidungen trifft; der Unterschied zwischen beidem ist im Ton subtil, in der Wirkung aber entscheidend.

Die Politik der Gate-Entscheidungen: wie man Abnicken vermeidet

Abnicken ist der Fehlermodus, bei dem das Gate-Gremium alles genehmigt, was ihm vorgelegt wird, ohne echte Analyse oder Infragestellung. Zu den Signalen für Abnicken gehören Kill-Raten unter zehn Prozent über alle Gates, das Fehlen von Recycle-Entscheidungen über ein ganzes Jahr, Projekt-Briefings, die erst nach dem Meeting statt fünf Werktage vorher verteilt werden, und Gate-Gremien, die aus denselben Personen bestehen, die die geprüften Projekte leiten (ein Interessenkonflikt, der den Rahmen zerstört). Wirksame Gegenmaßnahmen: Bewertungskriterien vorab geschrieben und geteilt, Deliverables mindestens fünf Werktage vor dem Gate-Meeting verteilt, damit die Gremienmitglieder Zeit zur Analyse haben, stille Bewertung durch jedes Gremienmitglied vor der offenen Diskussion (was den Ankereffekt verhindert, bei dem die lauteste Stimme den Ton angibt), und obligatorische kritische Fragen, die in jedes Gate-Meeting eingebaut sind, sodass mindestens ein Gremienmitglied damit beauftragt ist, gegen die Annahmen des Projekts zu argumentieren. Diese Praktiken zu etablieren erfordert Arbeit, aber sie erzeugen den Unterschied zwischen einem Gate-Gremium, das steuert, und einem, das beobachtet.

Wie Stage-Gate konkret zur Fertigung passt

Die Fertigung war die erste Branche, die Stage-Gate breit einführte, und bleibt die Referenzanwendung des Rahmens. Drei konkrete Fertigungskontexte profitieren von Stage-Gate auf Weisen, die eine gewisse Anpassung erfordern, aber den zugrunde liegenden Rahmen bestätigen: regulierte Produkte, Investitionsprojekte und Portfolios zur Entwicklung neuer Produkte.

Regulierte Produkte (Medizin, Pharma, Automobil, Luftfahrt)

Investitionsprojekte sind keine Entwicklung neuer Produkte, doch der Stage-Gate-Rahmen bildet sie fast ebenso sauber ab. Die regulierte Fertigung war eine natürliche Passung für Stage-Gate, weil regulatorische Regime in jeder Phase der Produktentwicklung Dokumentation verlangen und Stage-Gate genau diese Dokumentation als Nebenprodukt seines normalen Betriebs erzeugt. FDA Design Controls für Medizinprodukte bilden sich direkt auf Stage-Gate-Deliverables ab. Aktivitäten des Risikomanagements nach ISO 14971 integrieren sich sauber in Gate-Reviews. Das Automobil-Qualitätsmanagement IATF 16949 und sein Teilprozess APQP (Advanced Product Quality Planning) stimmen im Wesentlichen von vornherein mit den Stage-Gate-Phasen überein. Das Design History File, das Regulierer erwarten, ist genau die Sammlung der Deliverables aus jedem Gate, versioniert und auditierbar geführt. Hersteller regulierter Produkte, die versuchen, Vorschriften ohne einen Stage-Gate-Rahmen einzuhalten, rekonstruieren die erforderliche Dokumentation typischerweise nachträglich, was teuer, fehleranfällig und mitunter von Regulierern nicht akzeptiert wird.

Investitionsprojekte (Investitionen in Fertigungslinien, Werkserweiterungen)

Typische Phasen für Capex-Projekte: Machbarkeit, Konzeptentwurf, Detail-Engineering, Bau, Inbetriebnahme und Hochlauf. Jedes Gate genehmigt die nächste Kapitaltranche: Das Machbarkeits-Gate genehmigt das Budget für den Konzeptentwurf, das Konzeptentwurf-Gate genehmigt das Budget für das Detail-Engineering, das Detail-Engineering-Gate genehmigt die Bauzusage und so weiter. Die Sponsoren im Gate-Gremium verschieben sich von F&E-geführt zu betriebsgeführt, mit zentralerer CFO-Vertretung als beim NPD-Stage-Gate, weil Capex-Projekte Kapitalzusagen betreffen, die an jedem Gate finanzielle Governance brauchen. Die Variante wird manchmal Stage-Gate für Investitionsprojekte oder Capex-Stage-Gate genannt, um sie von der NPD-Version abzugrenzen, doch der zugrunde liegende Rahmen ist derselbe.

NPD in der Fertigung

Stage-Gate ist der Governance-Rahmen, der die Entwicklung neuer Produkte in der Fertigung als organisiertes Portfolio funktionieren lässt statt als Sammlung von Ad-hoc-Projekten. Es ist das Governance-Rückgrat für das Projektmanagement in einem Fertigungsunternehmen in großem Maßstab. Der achtstufige NPD-Prozess, typisch für die Entwicklung physischer Produkte, von der Entdeckung der Chance bis zum Post-Launch-Review, braucht Stage-Gate-Governance, um das Abdriften, das Denken in versunkenen Kosten und die Umfanginflation zu verhindern, die NPD-Portfolios sonst plagen. Fertigungsorganisationen mit fünf bis dreißig parallelen NPD-Projekten brauchen Stage-Gate-Governance auf Portfolioebene, um Projekte zu vergleichen, die schwächsten abzubrechen und Ressourcen zu den stärksten umzuverteilen, Entscheidungen, die einzelne Projekt-Reviews nicht stützen können. Die Kombination aus NPD-Prozess der Fertigung und Stage-Gate-Governance ist einer der Gründe, warum Fertigungsorganisationen Stage-Gate vorantrieben und noch Jahrzehnte später die meisten Erfolgsfälle des Rahmens hervorbringen. Stage-Gate steuert, welche neuen Produkte und Investitionsprojekte durch Entscheidungs-Gates voranschreiten; es unterscheidet sich von Methoden zur Verbesserung der Fertigungshalle wie Lean Management in der Produktion und der SMED-Methode, die bestehende Abläufe verschlanken, statt über neue Produkte zu entscheiden.

Häufige Fallstricke und wie man sie vermeidet

Vier Fehlermuster erklären die meisten Stage-Gate-Umsetzungen, die Vorlagen, aber keine Entscheidungen produzieren. PDMA-Benchmarks zeigen, dass Organisationen im obersten Quartil NPD-Erfolgsraten von rund 76 % erreichen gegenüber etwa 51 % beim Rest, und eine disziplinierte Stage-Gate-Governance ist einer der Hebel, die diese Gruppen trennen. Jeder der vier Fallstricke unten ist vermeidbar, sobald die Organisation ihn benennt und explizite Gegenmaßnahmen in ihre Governance einbaut.

Gates als Gummistempel

Das erste Muster ist das Abnicken: Das Gate-Gremium genehmigt alles, was ihm vorgelegt wird, ohne echte Analyse, und die Kill-Raten über ein ganzes Jahr fallen unter zehn Prozent. Gesunde Stage-Gate-Umsetzungen zeigen kumulative Kill-Raten von dreißig bis fünfzig Prozent über alle Gates, überwiegend getrieben von Kills an Gate 3 (Go to Development) und Gate 5 (Go to Launch). Zu den Signalen für Abnicken gehören null Recycle-Entscheidungen über ein Jahr, Gate-Meetings, die stets binnen zwanzig Minuten enden, und Post-Launch-Reviews, die durchgängig zeigen, dass Projekte den Buchstaben ihrer Business Cases erfüllen, aber ihre strategische Absicht verfehlen. Die Gegenmaßnahme besteht darin, die Kill-Rate als expliziten Leistungskennwert des Gate-Gremiums selbst zu messen und sie regelmäßig auf Vorstands- oder Führungsebene zu prüfen, was die Kill-Rate von einem verborgenen Signal in eine beobachtbare Kennzahl mit angehängter Verantwortung verwandelt.

Deliverables werden nie zurückgewiesen

Das zweite Muster ist die Annahme von Deliverables ohne Disziplin: Das Gate-Gremium akzeptiert unvollständige oder minderwertige Deliverables, statt das Projekt zur Überarbeitung zurückzuschicken. Dieses Muster degradiert den Rahmen, weil Projektteams schnell lernen, dass unvollständige Deliverables durchgehen, was die Qualitätslatte mit der Zeit senkt und schließlich einen Punkt erreicht, an dem Deliverables keine echten Entscheidungen mehr stützen. Die Gegenmaßnahme ist ein Hard-Stop-Mechanismus für Must-have-Deliverables: Fehlt ein Must-have-Deliverable oder erfüllt es die Mindestqualitätsstandards nicht, geht das Gate ohne Debatte automatisch auf hold. Projektteams kalibrieren sich schnell neu, sobald sie den Hard Stop erleben; der Rahmen verlangt, dass das Gremium bereit ist, ihn einige wenige Male durchzusetzen, um das Muster zu etablieren.

Phasen unter Zeitdruck überspringen

Das dritte Muster ist das Überspringen von Phasen unter Terminschritt: das Argument, dass sich ein bestimmtes Projekt offensichtlich lohnt, sodass das Überspringen der Business-Case-Phase Zeit und Geld spart. Die Folge ist, dass der Business Case nachträglich geschrieben wird, um eine bereits zugesagte Investition zu rechtfertigen, was den Zweck des Business Case zunichtemacht. Die Gegenmaßnahme besteht darin, Express Stage-Gate als legitime Variante für Projekte anzubieten, die die klassische Fünf-Phasen-Disziplin wirklich nicht brauchen (Linienerweiterungen, kleinere Verbesserungen, SKU-Ausweitungen mit Wiederverwendung bestehender Plattformen), und zugleich den klassischen Rahmen für Projekte streng durchzusetzen, die in seinen vorgesehenen Umfang fallen. Der Unterschied zwischen Express als dokumentierter Variante und Ad-hoc-Überspringen ist wichtig: Ersteres ist disziplinierte Anpassung, Letzteres ist Zusammenbruch der Disziplin.

Kein Portfolioblick über den Projekten

Das vierte Muster ist Stage-Gate, das auf Projektebene ohne Portfoliokontext operiert: Jede Gate-Entscheidung betrachtet das einzelne Projekt nach seinen eigenen Vorzügen, statt es gegen alternative Verwendungen derselben Ressourcen abzuwägen. Die Folge ist ein Abdriften hin zu inkrementellen Projekten, die einzeln vernünftig sind, aber gemeinsam die strategische Ausrichtung des Herstellers nicht voranbringen, weil kein Forum existiert, in dem Projekte um die endliche Investitionskapazität konkurrieren. Die Gegenmaßnahme besteht darin, Gate-Entscheidungen in Portfolio-Review-Meetings einzubetten, damit das Gremium das vollständige Portfolio-Dashboard sieht, bevor es ein einzelnes Projekt bewertet, und jeder Gate-Entscheidung explizite Fragen auf Portfolioebene hinzuzufügen: Ist dieses Projekt die beste Verwendung der Ressourcen, die es anfordert, oder würden diese Ressourcen bei einem anderen bereits im Portfolio befindlichen Projekt mehr Wert schaffen.

Wie FlexiProject die Umsetzung von Stage-Gate unterstützt

FlexiProject liegt in der Schicht des Projektportfoliomanagements des Technologie-Stacks der Fertigung, oberhalb der operativen Systeme und unterhalb der Schicht der strategischen Ausrichtung. Es setzt die Stage-Gate-Entscheidungen nicht selbst um; es liefert die operative Infrastruktur, die Stage-Gate-Governance in großem Maßstab über ein Portfolio von Projekten hinweg handhabbar macht.

Phasenvorlagen, abgestimmt auf Stage-Gate

FlexiProject bietet Stage-Gate-Phasenvorlagen von Haus aus, konfigurierbar je Projekttyp (NPD, Investitionsprojekte, IT-Initiativen). Jede Vorlage trägt die Phasenstruktur, Deliverable-Checklisten, Gate-Kriterien und Bewertungsdimensionen, die zu ihrem Projekttyp passen, sodass Projektteams innerhalb eines konsistenten Rahmens arbeiten, statt ihn für jedes neue Projekt neu aufzubauen. Vorlagen für die klassische Fünf-Phasen-, die Express-Drei-Phasen- und die erweiterte Sieben-Phasen-Variante sind verfügbar und konfigurierbar, und Organisationen können eigene Varianten hinzufügen, wenn ihre Prozessreife es rechtfertigt.

Freigabe-Workflows für Gate-Entscheidungen

Gate-Entscheidungen werden in FlexiProject als Freigabe-Workflows umgesetzt, mit automatischen Benachrichtigungen an die Mitglieder des Gate-Gremiums und strukturierter Deliverable-Prüfung. Die Entscheidung go, kill, hold oder recycle wird mit angehängter Begründung festgehalten, und die versionierte Historie des Project Charters und der Deliverables bleibt für den späteren Bezug erhalten. Gremienmitglieder können Deliverables vor dem Gate-Meeting über den Workflow prüfen, statt sie zum ersten Mal im Raum zu sehen, was der Praxis entspricht, die echte Entscheidungen statt Abnicken unterstützt.

Versionierung der Deliverables und Audit-Trail

Jedes Deliverable in FlexiProject wird automatisch versioniert, und der Audit-Trail hält fest, wer jede Version eingereicht, geprüft, freigegeben oder abgelehnt hat. Der Audit-Trail erfüllt die Dokumentationsanforderungen regulierter Branchen: FDA Design Controls, Aufzeichnungen zum Risikomanagement nach ISO 14971, die Automobil-Qualitätsdokumentation IATF 16949 und die Audit-Erwartungen der meisten regulatorischen Regime, die NPD-Dokumentation der Fertigung prüfen. Den Zustand eines Projekts an einem beliebigen historischen Gate zu rekonstruieren ist eine routinemäßige Abfrage statt einer archäologischen Übung, was Regulierer erwarten und wovon auch die interne Governance profitiert.

Was FlexiProject nicht tut

FlexiProject trifft keine Gate-Entscheidungen; das ist menschliche Arbeit, die sich nicht automatisieren lässt, und Organisationen, die von einem Werkzeug erwarten, das Urteil des Gremiums zu ersetzen, missverstehen, worum es bei Stage-Gate geht. Es erstellt auch keine Deliverables; Projektteams schreiben weiterhin Business Cases, führen Testprogramme durch und erzeugen die Artefakte, die Gates prüfen. Es ersetzt auch keine domänenspezifischen Systeme wie CAD für den Entwurf, PLM für das Produktdatenmanagement, MES für die Produktionssteuerung oder ERP für Finanztransaktionen. Es liegt in der Schicht der Governance und des Portfoliomanagements und integriert sich mit den operativen Systemen um sich herum, statt zu versuchen, sie zu werden.

Häufig gestellte Fragen

Wie viele Gates sollten wir haben?

Die Antwort hängt vom Projekttyp und von der Stage-Gate-Variante ab. Klassisches Fünf-Phasen-Stage-Gate hat fünf Gates. Express-Drei-Phasen hat zwei oder drei Gates. Erweitert-Sieben-Phasen für regulierte Produkte hat sieben Gates. Mehr Gates hinzuzufügen, als der Projekttyp erfordert, verbessert die Governance nicht; es fügt Bürokratie hinzu, ohne die Entscheidungsqualität zu erhöhen. Weniger Gates als im Variantendesign gefährdet die Disziplin, die der Rahmen durchsetzen sollte. Die richtige Zahl ist die von der für den Projekttyp passenden Variante definierte Zahl, konsistent über Projekte desselben Typs im Portfolio angewendet.

Können wir Gates bei einfachen Projekten überspringen?

Nicht im klassischen Fünf-Phasen-Modell, und das zu tun untergräbt den Rahmen. Für Projekte, die das Gewicht des klassischen Rahmens wirklich nicht brauchen, ist der richtige Ansatz die Express-Drei-Phasen-Variante, eine dokumentierte und disziplinierte Reduktion des Rahmens statt eines Ad-hoc-Überspringens. Der Unterschied ist wichtig: Express ist eine bewusste Variante mit eigenen Gates und Kriterien; Überspringen ist Zusammenbruch der Disziplin, als Pragmatismus verkleidet. Organisationen, die Stage-Gate einführen, sollten vorab entscheiden, welche Projekttypen Classic, welche Express und welche Extended erhalten, und diese Entscheidungen dann streng durchsetzen.

Was ist der Unterschied zwischen Stage-Gate und Waterfall?

Waterfall ist ein linearer Umsetzungsansatz, der Projekte als Abfolgen von Phasen ohne explizite Entscheidungspunkte dazwischen behandelt. Stage-Gate sieht oberflächlich ähnlich aus, weil es Projekte ebenfalls als Abfolgen von Phasen behandelt, doch die Entscheidungs-Gates zwischen den Phasen sind der wesentliche Unterschied. Bei Waterfall schreiten Projekte automatisch von Phase zu Phase voran, weil der Plan es so sagt; bei Stage-Gate schreiten Projekte nur dann von Phase zu Phase voran, wenn das Gate-Gremium entscheidet, dass sie es sollten, und das Gate kann das Projekt stattdessen abbrechen oder zurückführen. Stage-Gate ist faktisch Waterfall plus Governance plus die Option zu stoppen, was den Charakter des Rahmens erheblich verändert, auch wenn die Diagramme gleich aussehen.

Wie wechseln wir von Ad-hoc zu Stage-Gate?

Beginnen Sie mit einem Pilot mit einem oder zwei Projekten, statt das ganze Portfolio auf einmal umzustellen. Kopieren Sie eine bestehende Stage-Gate-Umsetzung (Coopers klassisches Fünf-Phasen-Modell ist gut dokumentiert und frei verfügbar), statt eine eigene von Grund auf zu entwerfen, weil die Disziplin des Rahmens aus Jahrzehnten der Verfeinerung stammt und ihre lokale Neuerfindung meist eine schwächere Version hervorbringt. Etablieren Sie das Gate-Gremium vom ersten Tag an mit echter Befugnis, weil ein Stage-Gate-Rahmen ohne Entscheidungsbefugnis an den Gates zu Vorlagen und Statusmeetings degradiert. Messen Sie die Kill-Rate von Anfang an als explizite Kennzahl der Leistung des Gate-Gremiums, weil die Kill-Rate das früheste Signal dafür ist, ob der Rahmen wie vorgesehen funktioniert oder zum Abnicken verkommt.

Ist Stage-Gate mit Agile vereinbar?

Ja, über Agile-Stage-Gate, Coopers eigenen Hybrid von 2016, der Stage-Gate-Governance mit agiler Umsetzung innerhalb einzelner Phasen kombiniert. Rein agiles Vorgehen ohne Stage-Gate-Governance funktioniert für NPD in der Fertigung selten gut, weil die Iterationszyklen von Hardware zu lang für eine sinnvolle Sprint-Kadenz sind und weil die regulierte Fertigung die Dokumentationsdisziplin braucht, die Stage-Gate natürlich erzeugt. Klassisches Stage-Gate ohne Agile funktioniert gut für reine Hardwareentwicklung, bei der Iteration innerhalb der Phasen nicht viel Wert schafft. Die in reifen Fertigungsorganisationen gut funktionierende Kombination hängt vom Produktmix ab, wobei Agile-Stage-Gate für Produkte aus Hardware plus Software und klassisches Stage-Gate für reine Hardware bevorzugt wird.

Der Stage-Gate-Prozess ist der Referenzrahmen für die Governance bei der Entwicklung neuer Produkte, bei Investitionsprojekten und anderen risikoreichen Vorhaben in der Fertigung, entwickelt von Robert G. Cooper 1986 und heute in der fünften Generation, wobei rund 80 % der nordamerikanischen Unternehmen eine Form davon nutzen. Seine Anatomie ist einfach: Phasen enthalten strukturierte funktionsübergreifende Arbeit mit konkreten Deliverables, Gates enthalten Entscheidungen, die ein funktionsübergreifendes Gremium anhand vorab definierter Kriterien trifft, und die vier möglichen Gate-Ergebnisse (go, kill, hold, recycle) behandeln Abbruch und Überarbeitung als ebenso wichtige Entscheidungen wie die Fortführung. Coopers fünf kanonische Phasen sind Scoping, Business Case, Development, Testing and Validation und Launch, wobei Gate 3 (Go to Development) das folgenreichste ist und Kill-Raten von 50 bis 70 % an diesem Gate in gesunden Umsetzungen typisch sind. Fünf Varianten des Rahmens passen ihn an unterschiedliche Projekttypen an: klassisch 5-Phasen als Grundlage, erweitert 7-Phasen für die regulierte Fertigung, Express 3-Phasen für Linienerweiterungen, Agile-Stage-Gate für Produkte aus Hardware plus Software und adaptiv 5G, veröffentlicht in Coopers offizieller Version 2026 unter Einbeziehung der vier Fs. Governance ist der Punkt, an dem Umsetzungen gelingen oder scheitern: ein Gate-Gremium mit echter Befugnis, Deliverable-Checklisten und vorab bekannte Bewertungskriterien sowie ein monatlicher Rhythmus, der Gates als Entscheidungen statt als Statusupdates behandelt, trennen funktionierendes Stage-Gate vom Schauspiel. Vier häufige Fallstricke (Abnicken, schwache Deliverable-Disziplin, Ad-hoc-Überspringen von Phasen, Fehlen des Portfolioblicks) sind allesamt mit benannten Gegenmaßnahmen vermeidbar. FlexiProject liefert die Projektportfolio-Schicht, die Stage-Gate-Governance in großem Maßstab handhabbar macht, mit Phasenvorlagen, Freigabe-Workflows, versionierten Deliverables und auditfähiger Dokumentation für regulierte Produkte, ohne selbst Gate-Entscheidungen zu treffen oder die operativen Systeme um sich herum zu ersetzen. Wenn die Stage-Gate-Umsetzung eines Herstellers Tabellen und E-Mail entwachsen ist und ein Portfolio-System braucht, das die klassische, die Express- oder die agile Variante unterstützt, sind dreißig Tage voller Zugang ohne Kreditkarte ein praktischer Weg, die Passung zu testen.