Anforderungsmanagement in Tech Projekten

Deep-Tech-Projekte scheitern selten an mangelnder technischer Kompetenz. In den Entwicklerteams sitzen herausragende Ingenieure und Informatiker. Dennoch geraten Zeitpläne ins Rutschen, Budgets laufen aus dem Ruder und Produkte verfehlen nach der Auslieferung ihren eigentlichen geschäftlichen Zweck. Das reale Problem liegt fast immer eine Ebene höher: Anforderungsmanagement wird in der Praxis oft wie ein unstrukturierter Wunschzettel behandelt.

Wenn die Eingangsdaten vage oder widersprüchlich sind, entstehen im Entwicklungsverlauf Missverständnisse und unproduktive Korrekturschleifen. Anforderungen sind im Grunde der Quellcode für das Management. Ist die Syntax dieser Vorgabe ungenau, leidet das gesamte System darunter.

Ein Dienstag im Lenkungskreis.

Auf den Bildschirmen flimmern Präsentationen voller technischer Abkürzungen und bunter Statusampeln. Der Vertrieb fordert kurzfristig eine neue Funktion, weil sie im Kundengespräch zugesagt wurde. Die Entwickler im Raum suchen bereits nach Kompromissen bei der Hardware-Architektur, um den Wunsch irgendwie unterzubringen.

Eine Situation, die Johannes Meyer aus seiner Zeit bei Fernride und ZF Mobility Solutions bestens kennt – und die er heute gemeinsam mit Florian Obermeier bei der Honest Guys Consulting GmbH regelmäßig auflöst. Es fehlen selten noch mehr Tools, sondern sauber durchdachte Entscheidungen und klare Leitplanken. Wirksames Anforderungsmanagement erfordert den Mut, Annahmen zu hinterfragen, bevor die ersten Zeilen Code geschrieben oder Platinen gefertigt werden.

Vom Postboten zum Übersetzer im Projektmanagement

In vielen Unternehmen agieren Projektleiter leider wie Postboten. Sie nehmen E-Mails von Stakeholdern entgegen, kopieren die Wünsche in Jira-Tickets und reichen sie ungesehen an die Entwicklung weiter. Wenn der Vertrieb fordert, dass ein System „schnell und intuitiv“ sein muss, reicht der Projektleiter das ungefiltert weiter. Das Engineering braucht jedoch messbare Parameter wie Latenzzeiten, Datenmengen und genaue Betriebsbedingungen.

Ein exzellenter Projektleiter ist ein Übersetzer. Er versteht, dass Business und Engineering zwei verschiedene Sprachen sprechen. Die Business-Seite redet über Time-to-Market und ROI, die Entwicklung über Latenzen, Schnittstellen und Speicherbedarf. Der Projektleiter dekonstruiert die Aussagen gemeinsam mit beiden Seiten und übersetzt Geschäftsziele in technische Präzision.

„Ein exzellenter Projektleiter ist kein Postbote, der E-Mails durchreicht. Er ist ein Übersetzer, der aus vagen Wünschen überprüfbare Spezifikationen baut.“

– Johannes Meyer

Wünsche hinterfragen und Probleme freilegen

Stakeholder haben selten fertig ausformulierte Anforderungen. Sie haben Schmerzpunkte, unstrukturierte Ideen und manchmal unklare Annahmen. Anforderungsmanagement bedeutet daher aktive Diagnostik. Wenn ein Kunde fordert: „Baut einen teuren LiDAR-Sensor auf das Dach des Fahrzeugs“, hinterfragen wir diese Lösungsvorgabe, bis die eigentliche Anforderung übrig bleibt: Objekterkennung auf 50 Meter Distanz bei Dämmerung.

Wie das Entwicklerteam dieses Ziel erreicht – ob mit Kamera, Radar oder LiDAR –, bleibt der Entwicklung überlassen. Man muss den Experten den Raum geben, die technisch beste Lösung zu gestalten. Wer planlos auf jeden Zuruf anspringen will, verliert den Fokus. Ein gutes „Nein“ zum richtigen Zeitpunkt schützt das Projekt vor ungesteuerter Komplexität.

EARS-Syntax und klare Baselines für echte Agilität

Natürliche Sprache ist von Natur aus mehrdeutig. Wir nutzen daher Werkzeuge wie die EARS-Syntax (Easy Approach to Requirements Syntax). Aus einem vagen Wunsch wie „Die Datenübertragung muss sicher sein“ wird eine eindeutige Systemanforderung: „Während der Datenübertragung zwischen Gateway und Backend muss das Gateway die Nutzdaten nach AES-256 verschlüsseln.“

„Anforderungen sind kein Wunschkonzert, sondern ein Vertrag zwischen Business und Engineering. Wer planlos auf jeden Zuruf anspringen will, verliert den Fokus.“

– Johannes Meyer

Wahre Agilität braucht verbindliche Baselines und klare Übergabepunkte. Wenn ein Team in jedem Sprint die Systemgrenzen verschiebt, entsteht Unruhe. Man muss die Auswirkungen transparent machen: Wenn ein neues Feature gefordert wird, muss sofort klar sein, welches andere Detail dafür entfällt oder wie sich der Zeitplan verschiebt. Man kann das abstellen, indem man Anforderungen vor Entwicklungsstart konsequent auf ihre Messbarkeit prüft.

Die Spielregeln für die Praxis

Wirksames Anforderungsmanagement erfordert keine monumentalen Werkzeuglandschaften, sondern methodische Disziplin. Wer komplexe Deep-Tech-Projekte steuern will, muss vage Adjektive streichen, Lösungsvorgaben von Problemstellungen trennen und saubere Baselines definieren. Struktur schafft am Ende die Freiheit, die Entwickler für echte technische Innovationen benötigen. Es braucht einfach nur klare Spielregeln, damit aus einer Idee ein funktionierendes Produkt wird.