Definition
Frühes Design-Review in der Entwicklung komplexer Produkte, das die Konzeptentscheidungen und Systemarchitektur prüft, bevor die detaillierte Konstruktion beginnt. Häufig in Luft- und Raumfahrt sowie MedTech als Meilenstein im Entwicklungsprozess verwendet.
In der Praxis
Das PDR ist der Moment, in dem ein Projekt Wahrheit vertragen muss — und genau daran scheitert es oft. Erstes Fehlerbild: Das Review ist eine Präsentation, keine Prüfung. Folien werden gezeigt, Evidenz nicht; am Ende nickt der Raum, und die offenen Architekturfragen wandern in die Detailkonstruktion, wo sie zehnmal teurer werden. Zweites Fehlerbild: Das PDR kommt zu spät — das Konzept ist längst verfestigt, weil Beschaffung und Kundenkommunikation schon laufen; dann ist das Review Theater. Drittes Fehlerbild: weiche Eintrittskriterien. Ohne eingefrorene Anforderungen, dokumentierte Systemarchitektur und einen aktuellen Risikomanagement-Stand gibt es nichts zu prüfen. Normativ ist das PDR kein eigener Pflichtpunkt, sondern die konkrete Ausprägung der geforderten Entwicklungsüberprüfung — in der Raumfahrt nach ECSS-Logik, in der Luftfahrt entlang der ARP 4754A, in der Medizintechnik als Meilenstein im Entwicklungsplan nach ISO 13485. Sein Gegenstück ist das CDR am Ende der Detailkonstruktion.
Häufige Fragen zu PDR
Was unterscheidet das PDR vom CDR?
Das Preliminary Design Review prüft das Konzept: Sind die Anforderungen verstanden, die Systemarchitektur tragfähig, die Schnittstellen definiert — bevor die Detailkonstruktion beginnt. Das Critical Design Review prüft die fertige Konstruktion: Ist jede Anforderung im Design allokiert und verifizierbar, sind die Analysen geschlossen, kann gefertigt werden? Das PDR beantwortet die Frage „Bauen wir das Richtige auf die richtige Weise an?", das CDR die Frage „Ist das Design fertig für die Realisierung?". Zwischen beiden liegt die gesamte Detailkonstruktion. Wer beide zusammenlegt, verliert den frühen Korrekturpunkt, an dem Richtungsänderungen noch billig sind. In der Praxis zeigt sich: Projekte ohne echtes PDR diskutieren im CDR über Grundlagen — und das ist der teuerste Zeitpunkt dafür.
Ist ein PDR normativ vorgeschrieben?
Als benannter Meilenstein nicht — kein Gesetz und keine Managementsystemnorm kennt das „PDR" als Pflichttermin. Der normative Anker ist die Entwicklungsüberprüfung: Die ISO 13485 fordert systematische Bewertungen der Entwicklung in geeigneten Phasen nach geplanten Regelungen, mit dokumentierten Ergebnissen und Teilnehmern aus den betroffenen Funktionsbereichen. In der Luft- und Raumfahrt konkretisieren die ECSS-Standards und die ARP 4754A die Review-Logik entlang des Entwicklungsprozesses; dort sind PDR und CDR etablierte Projektgatter. Für Sie heißt das: Sie brauchen geplante Entwicklungsüberprüfungen mit Evidenz — ob Sie sie PDR nennen, ist Ihre Entscheidung. Der Name ist frei, der Nachweis nicht (ISO 13485:2016, Abschnitt 7.3.5).
Wie gestalten wir ein PDR, das mehr ist als ein Pflichttermin?
Definieren Sie harte Eintrittskriterien: Anforderungen eingefroren und verifizierbar formuliert, Systemarchitektur dokumentiert, Schnittstellen beschrieben, Risikoanalyse nach ISO 14971 auf aktuellem Stand. Besetzen Sie das Review mit Unabhängigkeit — mindestens ein Prüfer ohne Projektbindung, idealerweise mit Kunden- oder Anwendersicht. Prüfen Sie gegen die Anforderungen, nicht gegen die Folien: Jede Kernanforderung braucht eine Antwort im Konzept. Dokumentieren Sie offene Punkte mit Verantwortlichem und Termin; das Exit-Kriterium ist die Freigabe zur Detailkonstruktion, nicht die durchgeführte Sitzung. Und geben Sie dem Review Zeit im Projektplan — ein PDR unter Termindruck ist ein abgenicktes Risiko. Die Ergebnisse gehören als Aufzeichnung in die Entwicklungsakte.