Das Lastenheft für ein technisches Review — was ein Auftraggeber definieren muss, damit die richtige Frage beantwortet wird

Review-Lastenheft – die Fragestellung wird vor der Beauftragung eines technischen Reviews definiert
In der Konzern-Vorentwicklung habe ich Reviews erlebt, die technisch einwandfrei waren – und trotzdem nutzlos. Sie haben eine Frage sauber beantwortet. Nur nicht die, auf die es ankam. Der Fehler lag nie im Review selbst. Er lag davor: in einer Fragestellung, die nie präzise definiert wurde.

Die Qualität eines Reviews entscheidet sich davor, nicht darin

Ein technisches Review ist ein Werkzeug zur Beantwortung einer Frage. Wenn die Frage vage ist, ist auch die belastbarste Analyse am Ende vage. „Schauen Sie mal drüber, ob das passt" ist keine Fragestellung – es ist die Abwesenheit einer Fragestellung. Und sie erzeugt zuverlässig ein Ergebnis, das sich niemand zur Entscheidung heranziehen traut: „grundsätzlich plausibel, mit einigen offenen Punkten".

Der teuerste Teil eines Reviews ist deshalb nicht die Analyse. Es ist die halbe Stunde davor, in der jemand aufschreibt, was eigentlich abgesichert werden soll. Diese halbe Stunde wird fast immer übersprungen – weil sie unbequem ist. Sie zwingt dazu, eine diffuse Unsicherheit in einen konkreten Satz zu übersetzen. Genau das ist aber der Punkt, an dem sich entscheidet, ob das Review nützt oder nur beruhigt.

Die folgenden sieben Punkte sind das, was ich im Erstgespräch ohnehin abfrage. Wer sie vorab durchgeht, spart sich eine Iteration – und bekommt ein Review, das die eigene Frage beantwortet, nicht eine benachbarte.

1. Ziel: Was soll abgesichert werden?

Bevor eine Frage formuliert wird, muss klar sein, wozu. Ein Review kann sehr Unterschiedliches leisten: eine Auslegung gegen Anforderungen prüfen, ein Simulationsergebnis auf Belastbarkeit abklopfen, eine Lieferantenaussage gegenlesen oder ein Risiko vor einer Freigabe einordnen. Das Ziel bestimmt die Methode – und den Aufwand.

Häufig verbirgt sich hinter „schau mal drüber" ein sehr konkretes Ziel, das nur nie ausgesprochen wurde: Jemand will vor einem Gremientermin wissen, ob eine Zahl hält. Das ist ein völlig legitimes und klar umrissenes Ziel. Es muss nur benannt werden, damit die Analyse genau darauf zielt.

2. Die eine Frage, die beantwortbar sein muss

Die wichtigste Zeile im ganzen Lastenheft: die Kernfrage in einem Satz. Der Test dafür ist einfach – die Frage muss sich mit ja/nein oder mit einer Zahl beantworten lassen. „Ist die Simulation gut?" besteht diesen Test nicht. „Trägt die Designmarge von 7 K, wenn die Modellunsicherheit ±9 K beträgt?" besteht ihn.

Eine so gestellte Frage tut manchmal weh, weil sie eine unbequeme Antwort zulässt. Aber genau das ist ihr Wert: Sie macht das Ergebnis überhaupt erst entscheidungsfähig. Wie aus dieser Frage dann konkret ein Ablauf wird – Erstgespräch, Unterlagen, Analyse, Ergebnisdokument – habe ich hier Schritt für Schritt beschrieben: Wie läuft ein technisches Review ab?

3. Wo endet das System? Die Systemgrenze

Die meisten Missverständnisse in Reviews entstehen an der Grenze des Betrachtungsraums. Der Auftraggeber meint das Gesamtsystem, geprüft wird die Baugruppe – oder umgekehrt. Deshalb gehört ins Lastenheft explizit beides: was dazugehört und was ausdrücklich nicht.

Das „nicht" ist dabei genauso wichtig wie das „dazu". Wenn die thermische Anbindung ans Gehäuse außen vor bleibt, weil sie in einem anderen Arbeitspaket liegt, muss das im Auftrag stehen. Sonst prüft entweder niemand diese Schnittstelle – oder beide, doppelt und ohne es zu wissen.

Faustregel: Eine Systemgrenze, die man nicht in zwei Listen („dazu" / „nicht") aufschreiben kann, ist noch nicht geklärt. Dann fehlt sie auch im Ergebnis.

4. Welche Unterlagen die Analyse tragen

Ein Review ist nur so belastbar wie die Unterlagen, auf denen es beruht. Zum Lastenheft gehört deshalb eine ehrliche Bestandsaufnahme: Was liegt vor – und in welchem Zustand? Typischerweise sind das Simulationsmodelle und -berichte mit den verwendeten Randbedingungen, Messdaten oder Prüfberichte, Zeichnungen oder CAD-Stände und die relevanten Spezifikationen.

  • Simulationsmodelle/-berichte inklusive der angesetzten Randbedingungen und Annahmen
  • Messdaten oder Versuchsberichte, soweit vorhanden – auch unvollständige
  • Zeichnungen, CAD-Stände, Stücklisten mit klarer Versionierung
  • Spezifikationen, Lastenheft-Auszüge, relevante Normen oder Grenzwerte

Vollständigkeit ist nicht die Bedingung. Ich brauche keine lückenlose Dokumentensammlung – aber ich muss wissen, welche Lücken es gibt. Eine offen benannte Lücke ist bearbeitbar; eine unbekannte nicht.

5. Bekannte Widersprüche und offene Punkte

Fast immer gibt es intern schon ein ungutes Gefühl: Eine Messung, die nicht recht zur Simulation passt. Eine Annahme, die niemand mehr belegen kann. Zwei Berechnungen mit unterschiedlichen Ergebnissen. Diese offenen Punkte gehören ins Lastenheft – nicht, um Schwäche zu zeigen, sondern weil sie die wertvollsten Startpunkte der Analyse sind.

Ein häufiger Fall: Die Reserve gegen einen Grenzwert wirkt komfortabel, aber niemand hat geprüft, wie empfindlich das Ergebnis auf die kritischen Eingangsgrößen reagiert. Warum diese Sensitivität oft über die eigentliche Belastbarkeit entscheidet, habe ich hier vertieft: Sensitivitätsanalyse: wann eine Reserve wirklich trägt.

6. Welche Entscheidung am Ergebnis hängt

Ein Review ohne Entscheidungskontext ist ein akademisches Gutachten. Deshalb steht im Lastenheft, welche konkrete Entscheidung das Ergebnis vorbereiten soll – und bis wann sie fallen muss. Serienfreigabe, Investitionsentscheidung, Lieferantenauswahl, Konzeptwahl: Jede davon verändert, wie tief geprüft werden muss und wie das Ergebnis formuliert sein sollte.

Auch die Deadline ist Teil der Fragestellung, nicht nur der Logistik. Eine Entscheidung, die in zwei Wochen fällt, verträgt eine andere Prüftiefe als eine, die ein Quartal Zeit hat. Wer den Termin nennt, bekommt ein Review, das zum Termin passt – statt eines gründlichen Berichts, der zwei Tage zu spät kommt.

7. In welcher Form Sie das Ergebnis brauchen

Zuletzt: das Ergebnisformat. Eine mündliche Einordnung im Gespräch, ein Kurzbericht von zwei bis drei Seiten, ein ausführliches Gutachten oder eine Präsentation fürs Gremium – das sind vier verschiedene Aufwände und vier verschiedene Nutzungen. Wer das Ergebnis in einem Entscheidungsgremium vertreten muss, braucht etwas anderes als jemand, der intern nur eine Zahl absichern will.

Dieses Format vorab zu klären, verhindert die häufigste Enttäuschung am Ende: ein sauberes Dokument, das nicht in die Situation passt, für die es gebraucht wird.

Weitere Artikel

Der Aufwand liegt vor dem Review

Ich sehe in Erstgesprächen selten das Problem, dass jemand zu wenig Daten hat. Viel häufiger fehlt die eine Seite, auf der steht, was eigentlich entschieden werden soll. Genau diese sieben Punkte gehe ich im Erstgespräch mit Ihnen durch – und aus einem „schau mal drüber" wird ein präziser Auftrag. Wer sie vorab für sich sortiert, verkürzt das Gespräch spürbar; alles Weitere klären wir dann gemeinsam.

Review anfragen?

Bringen Sie Ihre Fragestellung mit – die sieben Punkte gehen wir im Erstgespräch gemeinsam durch. Kostenlos, 45 Minuten, ohne Verkaufsabsicht.

Erstgespräch vereinbaren →

Mehr zur Leistung: Technische Reviews & Gutachten →