EARS-Syntax im Anforderungsmanagement: Präzision statt schwammiger Vorgaben

In der Entwicklung folgen Quellcode, Platine und Logikbausteine strengen Regeln. Das vorausgehende Anforderungsmanagement wird dagegen erstaunlich oft in freier Prosa verfasst. Natürliche Sprache ist jedoch von Natur aus mehrdeutig. Wenn Spezifikationen voller vager Begriffe stecken, müssen Ingenieure Vermutungen anstellen. Die EARS-Syntax schafft hier Abhilfe, indem sie unstrukturierte Wünsche in standardisierte Satzmuster übersetzt. Das setzt von Beginn an klare Leitplanken für das gesamte Projekt.

Missverständnisse am Prüfstand

Später Nachmittag im Testlabor. Das Team steht um den Prüfstand eines Steuergeräts und analysiert die Messdaten am Oszilloskop. Ein Sensorsignal war ausgefallen, doch die Reaktion erfolgte eine halbe Sekunde zu spät. Im Lastenheft stand lediglich ein Satz: „Das System muss bei einem Sensorausfall schnell reagieren.“

Der Softwareentwickler hielt eine halbe Sekunde für völlig ausreichend. Für reine Desktop-Software mag das stimmen, für ein physisches Fahrzeug im Fahrbetrieb ist es unbrauchbar. Johannes Meyer kennt solche Fälle aus seiner Zeit als Head of Technical Project Management bei Fernride und Program Manager bei ZF Mobility Solutions. Heute löst er diese Themen gemeinsam mit Florian Obermeier bei der Honest Guys Consulting GmbH. Es lag kein Programmierfehler vor, sondern eine Spezifikation, die nicht sauber durchdacht war. Man kann das abstellen, wenn Anforderungen vor dem ersten Entwicklungs-Sprint nach festen Regeln formuliert werden.

Wie die EARS-Syntax unstrukturierte Sätze zerlegt

Die EARS-Syntax (Easy Approach to Requirements Syntax) stammt ursprünglich aus der Luftfahrt, wo sprachliche Unklarheiten direkte Ausfälle nach sich ziehen können. Das System basiert auf fünf klaren Satzmustern, die Auslöser, Systemzustände und die geforderte Systemreaktion eindeutig miteinander verknüpfen.

Der wichtigste Grundsatz lautet: Das System ist immer das aktive Subjekt im Satz. Passivkonstruktionen wie „Die Daten müssen gespeichert werden“ sind unzulässig, weil sie offenlassen, welche Komponente die Aktion ausführt.

Ein Beispiel aus der Praxis bei Smart Meter Gateways veranschaulicht den Unterschied:

• Vorher (Unstrukturiert): „Die Datenübertragung zwischen Gateway und Server muss jederzeit sicher sein.“
• Nach EARS-Syntax: „Solange die Datenübertragung aktiv ist, muss das Gateway die Nutzdaten nach AES-256 verschlüsseln.“

Die Entwickler wissen sofort, welches Modul gefordert ist, welcher Algorithmus greift und in welchem Zustand die Vorgabe gilt.

Jedes Satzmuster deckt ein bestimmtes Systemverhalten ab:

1. Universell (Ubiquitous): Beschreibt Eigenschaften, die das System immer und ohne Bedingung aufweisen muss.
   • Formel: Das [System] muss [Systemantwort].
   • Beispiel: „Das Sensorgehäuse muss gemäß Schutzklasse IP67 gegen Staub und Wasser geschützt sein.“
2. Ereignisgesteuert (Event-Driven): Tritt ein bestimmter Auslöser ein, reagiert das System.
   • Formel: Wenn [Trigger], muss das [System] [Systemantwort].
   • Beispiel: „Wenn der Bediener die Not-Aus-Taste drückt, muss das Steuerungsmodul die Stromzufuhr innerhalb von 10 Millisekunden unterbrechen.“
3. Zustandsbasiert (State-Driven): Verhalten während eines bestimmten Operationszustands.
   • Formel: Solange [Zustand], muss das [System] [Systemantwort].
   • Beispiel: „Solange sich das Fahrzeug im autonomen Fahrbetrieb befindet, muss die Warnleuchte durchgehend gelb blinken.“
4. Fehlerfall (Unwanted Behavior): Bestimmt das Verhalten bei einer Störung oder Abweichung.
   • Formel: Falls [Fehler], dann muss das [System] [Systemantwort].
   • Beispiel: „Falls die Verbindung zum Backend für mehr als 5 Sekunden unterbricht, dann muss das Gateway die Messdaten im lokalen Speicher puffern.“
5. Optionale Funktion (Optional Feature): Für Varianten oder spezifische Zusatzausstattungen.
   • Formel: Sofern [Bedingung], muss das [System] [Systemantwort].
   • Beispiel: „Sofern das Modul mit der Kamera-Option ausgestattet ist, muss das System den Videostream vor der Übertragung komprimieren.“

Die Adjektiv-Falle konsequent umgehen

Begriffe wie „benutzerfreundlich“, „performant“, „nahtlos“ oder „skalierbar“ erzeugen in Meetings eine trügerische Einigkeit. Jeder nickt, aber jeder stellt sich etwas anderes darunter vor. Im Anforderungsmanagement sind solche Wörter keine Parameter, sondern versteckte Missverständnisse.

Die Lösung besteht darin, jedes Adjektiv in prüfbare Metriken zu übersetzen:

• Aus „performante Datenbank“ wird: „Das Datenbanksystem muss 10.000 Schreibzugriffe pro Sekunde mit einer Latenz von unter 50 Millisekunden verarbeiten.“
• Aus „intuitives Bedienkonzept“ wird: „Ein geschulter Operator muss die Systemkalibrierung ohne externe Dokumentation in unter drei Minuten fehlerfrei durchführen können.“

Eine Anforderung ist erst dann bereit für das Engineering-Backlog, wenn der zugehörige Testfall binär mit Pass oder Fail bewertet werden kann.

Die Auswirkungen von Scope Creep transparent machen

Unklare Anforderungen führen im Projektverlauf fast immer zu nachträglichen Sonderwünschen. Wenn Zwischenergebnisse nicht den vagen Erwartungen entsprechen, wird nachgebessert. Wer dann planlos auf jeden Zuruf anspringen will, bringt den Zeitplan der Entwickler ins Wanken.

Die Aufgabe der Projektleitung besteht darin, die Auswirkungen transparent zu machen. Wenn mitten im Projekt eine neue Funktion gefordert wird, muss sofort feststehen, welcher andere Gehalt dafür entfällt oder wie sich der Fertigstellungstermin verschiebt. Ein gutes „Nein“ zum richtigen Zeitpunkt schützt das Projekt vor unkontrolliertem Scope Creep und hält den Fokus auf den wesentlichen Funktionen.

Klare Spielregeln für die Entwicklung

Präzision in der Spezifikation ist kein bürokratischer Selbstzweck, sondern der direkte Weg zu verlässlichen Projektergebnissen. Wer die EARS-Syntax nutzt und unstrukturierte Adjektive konsequent streicht, schafft eine verlässliche Brücke zwischen Business-Vision und technischer Umsetzung. Es braucht keine komplexen Software-Landschaften, sondern einfach nur klare Spielregeln für die Satzstruktur.

Der Beitrag EARS-Syntax im Anforderungsmanagement erschien zuerst auf Honest Guys Consulting.

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.

Der Beitrag Anforderungsmanagement in Tech Projekten erschien zuerst auf Honest Guys Consulting.

Wer glaubt, dass ein Projektmanagement-Tool Wechsel von etablierten US-Systemen wie Jira, Asana oder Notion hin zu europäischen Plattformen plötzlich Struktur in komplexe Projekte bringt, wird in der Praxis meist enttäuscht. Die Diskussion über Software-Alternativen ist zwar hochaktuell, verändert aber zunächst nur die Oberfläche. Ein Tool ist am Ende immer nur der Spiegel der eigenen Organisation: Wenn Aufgaben unstrukturiert vergeben werden und keine klaren Leitplanken existieren, hilft auch das übersichtlichste Dashboard in der neuen Software nicht weiter.

Kürzlich saß ich bei einem Kunden im Entwicklungszentrum. Auf dem Tisch lag ein aktueller t3n-Artikel über europäische Software-Alternativen wie MeisterTask, Zenkit oder Tenzu / Biru Scop. Das Team diskutierte intensiv darüber, ob ein Umstieg von Jira auf eine europäische Lösung die festgefahrenen Abläufe in der Entwicklung lösen könnte.

Bei der Durchsicht der aktuellen Boards zeigte sich jedoch das gewohnte Bild: Dutzende Tickets ohne klare Priorisierung, vage Beschreibungen und ständige Scope-Erweiterungen mitten im Sprint. Es wurde schnell deutlich, dass das Problem nicht im Funktionsumfang der bisherigen US-Software lag, sondern an fehlenden Spielregeln in der täglichen Zusammenarbeit.

Die Tool Debatte als Flucht

Frage: Kürzlich berichtete t3n über europäische Alternativen zu US-Giganten wie Asana, Jira oder Notion – darunter MeisterTask, Zenkit oder Tenzu / Biru Scop. Welche Argumente sprechen tatsächlich für diesen Wechsel?

Johannes Meyer: „Die Argumente für europäische Lösungen liegen auf der Hand. Wer sensible Kundendaten verwaltet oder in stark regulierten Bereichen arbeitet, kommt an Hosting in der EU und strikter DSGVO-Konformität kaum vorbei. Zudem bieten viele europäische Anbieter Open-Source-Ansätze, maximale Datensouveränität durch Self-Hosting sowie attraktive, kostenfreie Einstiegsmodelle. Das ist für die Compliance und das Budget absolut nachvollziehbar.“

---

„Ein Tool ist nur ein Spiegel der eigenen Abläufe. Wenn Aufgaben unstrukturiert vergeben werden, bringt auch das übersichtlichste Dashboard nichts.“

– Johannes Meyer

---

Frage: Warum erleben wir in der Praxis dennoch häufig, dass Teams nach dem Wechsel von Jira zu Asana oder Zenkit nach drei Monaten vor genau denselben Engpässen stehen?

Johannes Meyer: „Weil die Tool-Debatte meist das eigentliche Versäumnis überdeckt: unsaubere Anforderungen und fehlende Entscheidungswege. Wenn ein Projekt schiefläuft, liegt das selten an den Features der Software. Es liegt an drei typischen Fehlern:

• Mangelnde Priorisierung: Wenn alles die Priorität eins hat, hilft auch kein benutzerdefiniertes Feld weiter.
• Fehlende Abnahmekriterien: Wenn Aufgaben nicht sauber durchdacht sind, startet die Nacharbeit bereits beim Verfassen des Tickets.
• Planlos auf jeden Zuruf anspringen: Wer ohne klare Spielregeln den Scope laufend erweitert, überfordert jedes System.“

Frage: Wie sollte ein Team vorgehen, das vor der Entscheidung steht, das Projektmanagement-Tool zu wechseln?

Johannes Meyer: „Ein Systemwechsel kann ein sehr guter Anlass sein, um alte Zöpfe abzuschneiden. Wer die Migration aber nicht nutzt, um klare Leitplanken einzuziehen, nimmt die Altlasten einfach mit auf die neue Oberfläche. Man kann das abstellen, indem man die Reihenfolge einhält: Erst die Prozesse aufräumen und die Auswirkungen von Änderungen transparent machen, dann die passenden Werkzeuge auswählen. Egal ob die Software am Ende aus den USA oder aus Europa kommt.“

„Ein gutes „Nein“ zum richtigen Zeitpunkt schützt das Projekt mehr als das beste Dashboard.“

– Johannes Meyer

In der Projektpraxis gilt eine einfache Regel: Erst wenn die Abläufe stehen, lohnt sich der Blick auf die Software.

Wer seinen Projektalltag nachhaltig ordnen möchte, sollte vor der Tool-Auswahl drei klare Spielregeln etablieren:

• Eindeutige Prioritäten setzen: Kapazitäten realistisch planen und das parallele Arbeiten an zu vielen Baustellen stoppen.
• Saubere Abnahmekriterien definieren: Aufgaben erst freigeben, wenn das Ziel für die Entwickler klar verständlich und prüfbar beschrieben ist.
• Scope-Änderungen steuern: Anfragen von außen nicht unüberlegt aufnehmen, sondern deren Auswirkungen auf Termine und Budget transparent machen.

Sind diese Leitplanken verankert, bieten Werkzeuge wie MeisterTask, Zenkit, Asana oder Jira eine hervorragende Unterstützung. Die Struktur entsteht jedoch im Team und nicht in der Software.

Der Beitrag Projektmanagement-Tool Wechsel: Von Jira & Asana zu Zenkit? erschien zuerst auf Honest Guys Consulting.

Mein Telefon klingelt meistens dann, wenn Projekte nicht fertig werden. In den Krisensitzungen, die dann folgen, erlebe ich immer wieder das gleiche Ritual. Wir sitzen am Tisch und jonglieren mit den bekannten drei Säulen des Projektmanagements: Budget, Qualität und Zeit. Aber während man über Budget und Qualität fast immer irgendwie verhandeln kann – durch Nachträge, Umschichtungen oder das Streichen von „Schöner-Wohnen“-Features –, verhält es sich mit der Zeit völlig anders. Die Zeit ist einfach weg. Jede verstrichene Woche ist ein permanenter Verlust, der am Ende doppelt kostet: durch die laufende Verbrennung von Ressourcen im Projekt und durch die massiven, oft unsichtbaren Opportunitätskosten am Markt.

Die Frage, warum Projekte ihre Termine reißen, ist kein theoretisches Problem, sondern eine handfeste operative Baustelle. Nach Jahren im technischen Projektmanagement – von komplexen Automatisierungsanlagen bis hin zu hochdynamischen Automotive-Entwicklungen – zeigt sich: Die Ursachen für Verzug sind fast immer dieselben. Sie sind struktureller Natur. Und das Gute daran ist: Man kann das abstellen. Es braucht dafür keine komplexen Software-Monster, sondern einfach nur klare Spielregeln und ein sauberes, konsequentes Handwerk.

Der unklare Scope: Wie die Reise im Nebel beginnt

Es beginnt meistens ganz harmlos. Eine kleine Funktionserweiterung hier, eine minimale Anpassung da. Langsam sickert die Unschärfe in das Projekt. Die Terminschiene wird in den seltensten Fällen durch eine einzige, große Explosion zerlegt – viel häufiger stirbt sie an vielen kleinen Nadelstichen, weil die Projektziele und Anforderungen von Anfang an unstrukturiert oder hochgradig dynamisch sind.

Wer im Nebel startet, darf sich nicht wundern, wenn er den Weg nicht findet. Um die Terminschiene sauber zu schützen, müssen wir an vier Stellschrauben drehen:

• Die unmissverständliche Produktbeschreibung:
  Bevor das erste CAD-Tool geöffnet oder die erste Zeile Code geschrieben wird, gehört ein gemeinsames, schriftlich fixiertes Verständnis der Anforderungen auf den Tisch. Das klingt banal, wird aber aus vermeintlichem Zeitdruck erschreckend oft übergangen.
• Die Zeit zum Nachdenken:
  Das Team muss die Anforderungen auf ein ausreichend detailliertes Level herunterbrechen dürfen. Diese Analysephase ist die wichtigste risikomindernde Maßnahme überhaupt.
• Die ehrliche Ableitung:
  Erst wenn die technischen Details klar sind, lässt sich der Aufwand realistisch abschätzen. Das ist das einzige Fundament für einen belastbaren Terminplan.
• Ein konsequentes Änderungsmanagement:
  Änderungen kommen, das ist Fakt. Aber jede Änderung braucht einen klaren Prozess. Was kostet sie an Zeit und Geld? Erst wenn diese Auswirkungen transparent sind, darf die Entscheidung getroffen werden. Ein gutes „Nein“ zum richtigen Zeitpunkt schützt das Projekt vor dem schleichenden Kontrollverlust.

„Wir müssen weg von gefühlten Statusmeldungen und hin zu messbaren, physisch oder funktional überprüfbaren Teilergebnissen.“

– Florian Obermeier

Florian Obermeier über die Praxis im Projekt

Florian, in deinen Beiträgen sprichst du oft von der „Illusion des Fortschritts“. Was genau meinst du damit?

Dass wir uns im Projektgeschäft oft selbst in die Tasche lügen. Wir messen fleißig Arbeitsstunden und verwechseln das mit echtem Fortschritt. Ein Projekt, in dem 80 Prozent des Budgets verbraucht sind, ist nicht zu 80 Prozent fertig. Es ist im ersten Schritt einfach nur zu 80 Prozent teuer. Ich habe das selbst bei einem Lieferanten in den USA erlebt: Die wöchentlichen Statusberichte waren über Monate stabil und grün. Als ich unangekündigt in der Werkstatt stand, war noch nicht einmal mit dem physischen Bau der Anlage begonnen worden. Der Fortschritt existierte nur auf dem Papier und im CAD. Wir müssen weg von gefühlten Statusmeldungen und hin zu messbaren, physisch oder funktional überprüfbaren Teilergebnissen.

Wie durchbricht man diesen Blindflug im Alltag?

Indem man den Elefanten in kleine, fertig abgenommene Arbeitspakete zerlegt. Die Frage an das Team darf nie lauten: „Arbeitest du am Konzept?“, sondern: „Ist Kapitel 3.1 in Version 1.0 fertig und freigegeben?“. Zudem müssen wir den Fortschritt jede Woche sichtbar machen – am besten direkt am lebenden Objekt. Das zwingt alle Beteiligten zur Ehrlichkeit und schafft ein gemeinsames Verständnis für den realen Status quo.

Ein weiterer großer Zeitfresser ist das Warten auf Entscheidungen. Wie löst du diesen organisierten Stillstand?

Warten ist ein aktiver Kostenfaktor, der extrem an der Motivation des Teams zehrt. Als Projektleiter darf ich Entscheidungen nicht nur passiv einfordern, ich muss sie aktiv ermöglichen und im Zweifel auch erzwingen. Erstens verhandle ich meine eigenen Entscheidungskompetenzen und Wertgrenzen direkt zum Projektstart sehr genau. Jede Entscheidung, die ich selbst treffen kann, spart Wochen. Zweitens bereite ich Termine so vor, dass die inhaltlichen Bedenken der kritischen Stakeholder bereits im Vorfeld bilateral geklärt sind. Und drittens mache ich die Kosten des Zögerns radikal transparent. Wenn das Management weiß, wie viel Euro jede Woche Verzug konkret kostet, beschleunigt das die Prozesse ungemein.

Du hast auch die Ressourcenplanung als häufige Fehlerquelle genannt. Warum scheitern hier so viele Pläne?

Weil oft an den Kernteams vorbei geplant wird oder völlig überladene Software-Tools eingeführt werden, die am Ende niemand pflegt. Eine ehrliche Excel-Liste, die täglich aktiv gepflegt wird, ist tausendmal wertvoller als ein hochkomplexes ERP-Modul, dessen Datenqualität nicht stimmt. Wir müssen die Ressourcenplanung zudem direkt mit dem Änderungsmanagement verknüpfen. Jede technische Änderung hat Auswirkungen auf die Kapazitäten – das müssen wir sofort abbilden, anstatt nur einmal im Jahr einen statischen Plan zu erstellen.

Lieferantensteuerung: Verzug beim Partner abstellen

Der letzte, aber oft entscheidende Hebel liegt in der externen Wertschöpfung. Viele verwechseln die Vergabe eines Auftrags mit dem erfolgreichen Abschluss der Arbeit. Wer nach dem Prinzip „Fire and Forget“ agiert und darauf vertraut, dass der externe Partner schon geräuschlos liefern wird, baut sich fast immer eine erhebliche Verzugskette auf.

Auch hier hilft nur aktives, engmaschiges Handeln:

• Augen auf bei der Partnerwahl:
  Die Kapazitäten und die historische Termintreue des Lieferanten müssen bereits im Vorfeld kritisch geprüft werden.
• Verträge mit klaren Leitplanken:
  Qualitätssicherungsvereinbarungen, Meilensteindefinitionen und Pönalen sind kein Zeichen von Misstrauen, sondern eine notwendige, professionelle Absicherung für beide Seiten.
• Gesunde Skepsis und Präsenz:
  Man muss den Partnern regelmäßig auf die Finger schauen, Zwischenstände aktiv einfordern und vor Ort präsent sein. Lieferanten priorisieren am Ende immer die Kunden, die den engsten, fachlichen Kontakt halten.

Fazit: Weniger schleichender Verzug, mehr echtes Handwerk

Ein funktionierender Terminplan ist kein Kunstwerk, das man einmal zeichnet und dann an die Wand hängt. Er ist ein lebendes Werkzeug, das auf realen Kapazitäten, klaren Anforderungen und einer lückenlosen Fortschrittskontrolle basiert. Wer den Verzug in anspruchsvollen Technologieprojekten nachhaltig abstellen will, muss die unbequemen Wahrheiten frühzeitig auf den Tisch legen, die Auswirkungen von Änderungen transparent machen und planlos auf jeden Zuruf anspringen unterbinden. Es braucht am Ende einfach nur klare Spielregeln – und die konsequente Disziplin, sie auch einzuhalten.

Der Beitrag Zeit kann man nicht nachverhandeln: Wie wir den schleichenden Verzug im Projekt abstellen erschien zuerst auf Honest Guys Consulting.

Warum chronologische Präsentationen im Lenkungskreis scheitern. Johannes Meyer über das Minto-Prinzip im Projektmanagement und wie wir Fokus zurückgewinnen.

Die Logik umdrehen: Warum wir im Lenkungskreis die wichtigste Botschaft an den Anfang stellen

Wenn im Lenkungskreis über die nächste Generation von autonomen Systemen entschieden werden soll, läuft die Vorbereitung oft nach demselben Muster ab. Projektteams bauen ihre Präsentationen chronologisch auf. Es wird lang und breit erklärt, welche Analysen gemacht wurden, welche Datenreihen das Team ausgewertet hat und wie komplex die Technologie im Detail ist. Die eigentliche Empfehlung für die beste Alternative folgt dann ganz am Ende.

Das Problem dabei ist, dass bis dahin die Hälfte der Entscheider im Raum den Faden verloren hat. In komplexen Vorhaben führt das nicht zu schnellen Entscheidungen, sondern zu neuen Prüfaufträgen und Verzögerungen. Das Management braucht keine Nacherzählung der Arbeitswoche. Es braucht sofort Klarheit, um handlungsfähig zu sein. Um das zu vermeiden und anspruchsvolle Entwicklungen zielgerichtet zu steuern, nutzen wir ein bewährtes Werkzeug: das Minto-Prinzip im Projektmanagement.

Das Minto-Prinzip im Projektmanagement: Die dreistufige Argumentationspyramide

Wer komplexe Projekte steuert, steht regelmäßig vor der Aufgabe, schwierige technische Alternativen für das Management aufzubereiten. Nehmen wir das Beispiel autonomer Shuttles: Sensor-Setups, Software-Architekturen und Lieferantenketten müssen so verglichen werden, dass ein Lenkungskreis innerhalb von Minuten eine fundierte Entscheidung treffen kann. Johannes Meyer hat in seiner früheren Arbeit beim Startup Fernride und als Program Manager bei ZF Mobility Solutions oft erlebt, wie wichtig diese strukturierte Vorbereitung ist.

Das Minto-Prinzip zwingt das Projektteam dazu, die Argumentation top-down aufzubauen. Das bedeutet, dass die Struktur exakt umgekehrt zu einer klassischen Präsentation verläuft. Eine saubere Pyramide besteht aus drei Ebenen:

1. Die Pyramidenspitze: Die Kernbotschaft
   Ganz oben steht die konkrete Empfehlung. Keine lange Einleitung. Bei der Auswahl eines Shuttle-Systems lautet der erste Satz zum Beispiel: „Wir empfehlen Alternative B, weil sie das Zertifizierungsrisiko minimiert und den Zeitplan sichert.“ Damit wissen alle Entscheider sofort, worum es geht.
2. Die mittlere Ebene: Die Hauptargumente
   Darunter liegen die tragenden Säulen der Entscheidung, meistens drei oder vier Kernpunkte. Diese müssen logisch voneinander abgegrenzt und sauber durchdacht sein. Im Shuttle-Beispiel wären das die Kategorien technische Machbarkeit, regulatorische Sicherheit und Gesamtkosten. Jedes Argument stützt direkt die Spitze.
3. Die Basis: Daten und Fakten
   Erst ganz unten folgen die technischen Details, Messreihen, Testergebnisse und Lieferantendaten. Diese Details werden nur aufgerufen, wenn ein Entscheider tiefer in die Validierung einsteigen möchte.

Diese Struktur setzt klare Leitplanken für die gesamte Diskussion im Meeting. Ein Lenkungskreis blockiert Entscheidungen meistens nicht wegen mangelnder Fachkenntnis, sondern weil die Optionen unstrukturiert präsentiert werden.

---

„Wer im Lenkungskreis erst die Historie ausrollen muss, hat die Argumentation nicht sauber durchdacht. Das Management braucht sofort Klarheit, keine Nacherzählung der Arbeitswoche.“

– Johannes Meyer

---

Der Widerstand der Experten: Wenn Entwickler ihre Details verteidigen

Aus der Praxis bei Honest Guys wissen wir, dass dieser strukturierte Ansatz in der Umsetzung oft auf Widerstand stößt. Besonders bei tiefen technischen Experten. Ein Ingenieur, der wochenlang Sensordaten für autonome Shuttles analysiert hat, möchte verständlicherweise zeigen, wie viel Arbeit in den Details steckt. Die Kernbotschaft einfach an den Anfang zu stellen, fühlt sich für viele unvollständig an.

Aber gutes technisches Projektmanagement zeichnet sich dadurch aus, Komplexität für Entscheider handhabbar zu machen, statt sie eins zu eins weiterzugeben. Wer planlos auf jeden Zuruf anspringen will oder jede Detailanalyse im Lenkungskreis ausrollt, verliert den Fokus.

Pragmatismus statt Historie: Die Spielregeln ändern

Man kann das abstellen. Es braucht dafür einfach nur klare Spielregeln in der internen Kommunikation. Wir müssen unseren hochspezialisierten Entwicklern den Rücken freihalten, indem wir schnelle und stabile Entscheidungen herbeiführen und die Auswirkungen von Verzögerungen für das gesamte Projekt transparent machen.

Wenn die Struktur der Argumentation sauber durchdacht ist, konzentriert sich die Diskussion im Meeting auf das Wesentliche: die Abwägung der Risiken statt das Suchen nach der eigentlichen Aussage. Am Ende geht es darum, die Arbeit des Teams zu schützen und die Technologie erfolgreich auf die Straße zu bringen.

Der Beitrag Minto-Prinzip im Projektmanagement erschien zuerst auf Honest Guys Consulting.