1: Die Suche nach Klarheit – Unsichtbare Projekte stoppen

Als Honest Guys die Rolle als Leiter des Projektmanagements in einem Startup antrat, haben wir nicht zuerst auf Zahlen geschaut. Wir haben angefangen, mit den Leuten zu reden. In einem wachsenden Startup ist Motivation die wichtigste Ressource. Ohne Fokus wird diese Motivation verschwendet. Unser Job als Technischer Projektmanager war es, diese Motivation zu bündeln. Damals sahen wir kein effizientes Team, sondern viele Leute, die sich im Kreis drehten. Ohne Klarheit ist ein Startup keine Firma, sondern eine Maschine, die Menschen ausbrennt.
Unsere erste Aufgabe war keine komplizierte Planung. Es war die Suche nach dem Status Quo. Wir verbrachten zwei Tage damit, jedem Teammitglied eine einfache Frage zu stellen: „An welcher einen Sache arbeitest du gerade?“ Das Ergebnis war erschreckend: Unsere 35 Ingenieure arbeiteten gleichzeitig an 13 verschiedenen Projekten. Es gab keine klaren Grenzen, keinen zentralen Plan und keine offizielle Roadmap. Wir hatten viele kleine, unsichtbare Projekte, die unsere Zeit und Motivation raubten.

Mein erster Schritt als Technischer Projektmanager war nicht, schneller zu werden, sondern die Bremse zu ziehen. Wir haben unwichtige Projekte gestoppt, um die Wichtigen zu retten. Für jedes verbleibende Projekt erstellten wir einen klaren Plan (eine „Projekt-Charta“). In diesem Kapitel geht es darum, wie wir Chaos ordnen, versteckte Arbeit finden und eine Basis für echten Fortschritt bauen.

Die Suche nach der Wahrheit

Wir können keine Ordnung schaffen, wenn wir das Chaos nicht verstehen. In jungen Firmen entsteht Chaos oft von selbst. Wenn jeder einem Ingenieur mal eben eine „tolle Idee“ zurufen kann, entstehen U-Boot-Projekte. Das sind Aufgaben, die offiziell gar nicht existieren, wie zum Beispiel kleine Verbesserungen, Analysen von Innovationen oder inoffizielle Fehlerbehebungen.

Einzeln wirken diese Aufgaben harmlos. Aber zusammen sorgen sie dafür, dass das Team langsam wird. Das ist der Grund, warum alle arbeiten, aber die großen Ziele nicht erreicht werden. Um diese Arbeit zu finden, helfen keine Tabellen. Wir empfehlen in die Büros zu gehen und zu zuhören.

Symptome: Woran erkennen wir U-Boot Projekte?

U-Boot Projekte zeigen sich oft durch bestimmte Warnsignale im Unternehmen:

• Scheinbare Beschäftigung: Alle tippen und arbeiten hart, aber die wichtigen Ziele (KPIs) werden nicht erreicht. Wenn Termine ständig verschoben werden, ist das Team wahrscheinlich zu stark verzettelt.
• Die „Priorität des Tages“: Wenn sich der Fokus ständig ändert, weil gerade jemand eine neue Idee hatte, gibt es keine Strategie. Dieses ständige Hin- und Herwechseln macht die Arbeit schlecht.
• Helden-Kultur: Es ist kein gutes Zeichen, wenn Leute ständig bis 3 Uhr morgens arbeiten müssen, um Fehler zu retten. Ein stabiles System braucht ein diszipliniertes Team, keine „Helden“, die Brände löschen.
• Verschiedene Antworten: Wenn wir drei Leute fragt, was das wichtigste Ziel des Start ups ist, und drei verschiedene Antworten bekommt, haben die U-Boot Projekte gewonnen.

Die Projekt-Reviews: Entscheidungen treffen

Herauszufinden, was schief läuft, ist der einfache Teil. Die Projekte wirklich zu stoppen, ist schwer. Es braucht Mut. In der Medizin gibt es die Triage. Das bedeutet, dass der Arzt entscheidet, wer zuerst behandelt wird. Im Business bedeutet es, dass Projekte zu beenden, damit die Firma überlebt. Wir empfehlen, Projekte nicht nur zu „verschieben“, sondern sie zu stoppen.

Drei Filter für die Entscheidung:

1. Das Hauptziel (Nordstern): Hilft dieses Projekt direkt dabei, unser wichtigstes Ziel in sechs Monaten zu erreichen? Wenn nicht: Stoppen.
2. Ressourcen: Haben wir genug Leute, um das Projekt wirklich gut und sicher zu Ende zu bringen? Ein bisschen Arbeit an vielen Stellen hilft niemandem.
3. Die Kosten: Jede Stunde, die wir für ein unwichtiges Projekt nutzen, fehlt uns beim Hauptprojekt. Wenn wir die klügsten Köpfe an die wichtigsten Probleme setzen, werden wir sofort schneller.

Die Projekt-Charta: Der Vertrag für den Fokus

Nachdem wir die unwichtigen Projekte gestoppt haben, brauchen wir eine Basis für die Zukunft: die Projekt-Charta. Das ist kein langes Dokument, sondern eine einzige Seite, die den Plan festhält.

Die 5 Säulen einer guten Charta:

1. Das Problem: Welches Problem lösen wir eigentlich?
2. Das Warum: Warum ist dieses Projekt strategisch wichtig?
3. Die Grenzen: Was machen wir nicht? (Das verhindert, dass das Projekt immer größer wird).
4. Definition of Done: Wann genau ist das Projekt fertig? Welche Tests müssen bestanden sein?
5. Erfolg: Woran messen wir, ob wir erfolgreich waren? (Z. B. „Die Fehlerquote sinkt um 20%“).

Struktur tötet keine Kreativität – sie ermöglicht sie. Wenn ein Ingenieur genau weiß, was der Rahmen ist, kann er innerhalb dieses Rahmens frei arbeiten. Die Charta schützt das Team vor ständigen neuen Ideen, die nicht zum Plan passen.

Fazit

Wir haben das Chaos geordnet, Ablenkungen gelöscht und einen klaren Plan erstellt. Aber Klarheit ist kein Ziel, das man einmal erreicht. Es ist eine tägliche Aufgabe. Neue U-Boot Projekte werden immer wieder auftauchen.

Deine Aufgabe als Technischer Projektmanager ist es, das Team zu schützen und den Fokus zu halten. Wer im Rennen um neue Technologien gewinnen will, braucht nicht die meisten Ideen, sondern die meiste Disziplin.

Zusammenfassung:

• Projektreviews müssen regelmäßig gemacht werden.
• Jedes „Ja“ zu einer neuen Idee bedeutet ein „Nein“ zu einer alten Aufgabe.
• Die Projekt-Charta ist der Vertrag, der das Team fokussiert hält.

2. Der technische Projektmanager als Schnittstelle – Den koordinativen Bereich verlassen

Nachdem das Portfolio bereinigt wurde, verschiebt sich der Fokus von der Auswahl der Projekte hin zur Ausführungsgeschwindigkeit (Velocity). In einem Startup ist Klarheit ohne Geschwindigkeit ein Risiko für den Runway. Sobald die Prioritäten feststehen, muss ein System aufgebaut werden, das Ergebnisse liefert.
In vielen Unternehmen wird der Technische Projektmanager (TPM) fälschlicherweise als reiner Koordinator angesehen. Jemand, der Jira-Tickets verwaltet und Meetings plant. In der Deep-Tech-Branche, wie der autonomen Mobilität, ist dieses Verständnis jedoch gefährlich. Ein TPM ist hier nicht der Sekretär des Teams, sondern das technische Bindeglied. Er verbindet spezialisierte Engineering-Teams zu einer funktionierenden Einheit.

Das Risiko mangelnder technischer Tiefe

Ein Projekt kann auf dem Papier „im Plan“ sein, während es technisch auf ein Scheitern zusteuert. Ein Beispiel: Ein Testfahrzeug kollidiert mit einer Barriere. Die Ursache war kein einzelner Software-Bug, sondern ein Kommunikationsfehler zwischen zwei Teams.

• Das Software-Team meldete den Status „Grün“ für ein neues Sensor-Modell.
• Das Hardware-Team meldete den Status „Grün“ für die Integration eines neuen Rechners.

Der technische Projektmanager hakt die Aufgaben ab, übersieht aber das technische Detail: Das Software-Modell benötigt eine Rechenleistung, die die Hardware nicht ohne eine Verzögerung (Latenz) von 200ms liefern kann. Das System war zwar integriert, aber funktional unsicher.

Ein TPM, der nur Zeitpläne versteht, aber die Technologie nicht durchdringt, wird zum Sicherheitsrisiko. In der autonomen Mobilität führt technisches Unverständnis nicht nur zu Fehlern in der Software, sondern zu realen Unfällen.

Die Komplexität von Deep-Tech-Projekten

Der Bau autonomer Fahrzeuge unterscheidet sich grundlegend von Standard-Softwareprojekten durch drei Faktoren:

• Radikale Interdependenz: Die Teams für Wahrnehmung (Perception), Planung (Planning) und Steuerung (Control) sind untrennbar miteinander verbunden. Eine Änderung in einem Bereich hat Auswirkungen auf den gesamten technischen Stack.
• Physikalische Grenzen: Gesetze der Physik (wie Bremswege oder Sensorreichweiten) lassen sich nicht durch agile Methoden umgehen. Latenzzeiten sind hier eine Frage der Sicherheit, keine reine Optimierung.
• Sicherheit als Architektur: Funktionale Sicherheit (ISO 26262) muss von Beginn an in das Engineering einfließen.

Ein TPM muss kein Experte in jedem Bereich sein, aber er muss die Schnittstellen, Eingaben und Ausgaben sowie die Logik hinter den technischen Entscheidungen verstehen.

Technische Kompetenz: Die richtigen Fragen stellen

Ein kompetenter TPM muss nicht der beste Entwickler sein. Es geht vielmehr darum, auf der richtigen Abstraktionsebene zu kommunizieren:

• Fachsprache beherrschen: Verständnis der Vor- und Nachteile von LiDAR gegenüber Kameras in Bezug auf Kosten und Leistung bei Regen.
• Abhängigkeiten erkennen: Wenn das Team für die Fahrzeugsteuerung die Kurvengeschwindigkeit erhöhen will, muss der TPM fragen: „Reicht das Sichtfeld der Seitenkameras bei dieser Geschwindigkeit noch aus?“
• Risiken bewerten: Wenn ein Ingenieur von Datenverlusten berichtet, muss der TPM beurteilen können, ob dies das Sicherheitskonzept gefährdet und sofortige Maßnahmen einleiten.

Technische Kompetenz schafft Glaubwürdigkeit bei den Ingenieuren. Nur wenn das Team dem TPM fachlich vertraut, werden Informationen über tatsächliche Probleme und Unsicherheiten offen geteilt.

Der technische Projektmanager als strategischer Übersetzer

Ingenieure und Führungskräfte sprechen oft unterschiedliche Sprachen. Ingenieure konzentrieren sich auf technische Einschränkungen; Stakeholder auf Meilensteine und Budgets. Ohne Übersetzung entstehen Missverständnisse.

Die Übersetzungsmatrix

Ein TPM nutzt für das Reporting eine klare Struktur:

• Technische Realität: Der LiDAR-Treiber verliert Datenpakete bei über 40°C.
• Auswirkung auf das Programm: Wir können diesen Sommer keine Tests in Wüstenregionen durchführen.
• Strategische Lösung: Wir verlegen die Tests in den Norden. Das kostet 50.000 € zusätzlich, hält aber den Zeitplan für die Software-Validierung ein.

Kommunikation mit Stakeholdern

Statt technischer Details (wie Speicherverwaltung) benötigen Führungskräfte die strategische Einordnung. Jede neue Feature-Anfrage muss in technische Kosten übersetzt werden: „Wenn wir Funktion X jetzt hinzufügen, müssen wir drei Ingenieure von der Sicherheitsprüfung abziehen. Das verzögert den Marktstart um drei Monate.“

Mission Command: Führung durch Zielsetzung

In der Deep-Tech-Entwicklung stoßen lineare Zeitpläne (Gantt-Charts) an ihre Grenzen, da sich Anforderungen durch neue Erkenntnisse ständig ändern. Anstatt jede Aufgabe zentral zu steuern, nutzen wir das Prinzip des Mission Command (Auftragstaktik).

Der TPM definiert die Absicht des Leiters (Commander’s Intent) so präzise, dass die Teams eigenständig entscheiden können:

„Unser Ziel ist eine 99,9%ige Erkennung von Fußgängern bei Regen. Die Rechenlast darf 70% nicht überschreiten. Im Zweifelsfall priorisieren wir die Erkennungsreichweite vor der Latenz.“

Die vier Säulen des Mission Command:

• Klare Ziele: Jedes Team kennt das „Warum“.
• Kompetenz: Vertrauen in die technischen Leiter.
• Technische Leitplanken: Definition der festen Grenzen (Latenz, Thermik, Sicherheitsstufen).
• Feedback-Schleifen: Direkte Informationen von der Teststrecke statt gefilterter Berichte.

Aktives Risikomanagement

Passive technische Projektmanager warten auf Probleme. Aktive TPMs jagen Risiken. Sie fragen nicht: „Ist die Aufgabe fertig?“, sondern: „Warum könnten wir die Sicherheitsprüfung nächsten Monat nicht bestehen?“ In sicherheitskritischen Systemen ist Hoffnung keine Strategie. Es muss für jeden kritischen Pfad einen Plan B geben.

Fazit

Erfolg in der autonomen Mobilität wird nicht durch das Ausfüllen von Tabellen erreicht, sondern durch das Erreichen von Meilensteinen auf der Straße. Der TPM muss den Fokus von der reinen Aktivität auf das tatsächliche Ergebnis lenken. Führung beginnt dort, wo die Technologie auf die Mission trifft.

Kernpunkte:

• TPMs müssen technisch kompetent sein, um Risiken frühzeitig zu erkennen.
• Der TPM übersetzt technische Realitäten in strategische Entscheidungen.
• Führung erfolgt durch klare Zielvorgaben und technische Leitplanken.

Ein TPM versteht die physikalischen Grenzen der Hardware ebenso wie die Logik der Software. Um solche komplexen Schnittstellen professionell zu steuern, setzen wir auf strukturierte Projektleitung für Tech-Teams, die Theorie und Praxis vereinen und Ihr Team spürbar entlasten.

3. Planung für das Unbekannte – Evolution vs. Revolution

Oft scheitern komplexe Projekte bereits mit dem ersten Terminplan. Sowohl in Startups als auch in großen Konzernen beobachten wir das gleiche Muster: Sobald ein Plan auf dem Bildschirm erscheint, werden Zeitpläne zu festen Versprechen. Das Management verlässt sich darauf, obwohl die Machbarkeit noch gar nicht im Detail bewiesen wurde.

In der Deep-Tech-Branche und der autonomen Mobilität folgen wir keinem fertigen Plan – wir erzeugen ihn erst. Diese Phase entscheidet über den Erfolg. Dabei unterscheiden wir bei Honest Guys zwei Arten von Projekten:

1. Evolution: Die Weiterentwicklung bekannter Technologie.
2. Revolution: Die Neuentwicklung von Grund auf.

Diese beiden Ansätze zu verwechseln, ist ein Fehler. Dieses Kapitel bietet einen Rahmen für Pläne, die Unsicherheit einplanen und eine ehrliche Strategie ermöglichen.

Die Copy-Paste-Planungsfalle

Unter dem Druck von Investoren oder der Geschäftsführung greifen viele zu einer gefährlichen Abkürzung: Sie kopieren den Plan eines alten Projekts, ändern den Titel und passen ein paar Daten an. Das sieht professionell aus, ist aber oft eine Lüge.

Dies ist die Copy-Paste-Falle. Wir nehmen an, dass ein Projekt, das zu 90 % dem alten ähnelt, auch den gleichen Zeitplan haben wird. Doch die restlichen 10 % an Neuerungen können 50 % der alten Annahmen ungültig machen. 

Ein Beispiel: Bei der Entwicklung unseres zweiten autonomen Yard Trucks sah alles nach einer einfachen Evolution aus. Doch dieser basierte auf einem anderen Basisfahrzeug mit neuem Drive by Wire. Wir mussten die gesamte State Machine neu entwerfen und zusätzliche Tests durchführen. Das Drive by Wire hatte andere Datenformate, was Auswirkungen auf alle Algorithmen hatte.

Warum „kleine“ Änderungen riskant sind:

• Nicht-Linearität: In autonomen Systemen ist der Austausch einer Komponente kein einfacher Wechsel. Es ist eine „Organtransplantation“. Eine Änderung beeinflusst Stromverbrauch, Kühlung, Treiber und Latenzzeiten.
• Schwindende Puffer: Wenn ein Plan vertraut wirkt, streichen technische eProjektmanager oft Zeitpuffer, um effizienter zu wirken. Damit entfernen sie jedoch die Reaktionsfähigkeit des Projekts.
• Fehlendes Mitdenken: Wenn der Zeitplan unrealistisch ist, hören Ingenieure auf, Bedenken zu äußern. Sie warten einfach darauf, dass der Plan scheitert.

Der Projektstrukturplan durch Experten-Konsens

Um die Copy-Paste-Falle zu vermeiden, empfehlen wir einen Projektstrukturplan (Work-Breakdown-Structure WBS), der auf dem Konsens von Experten basiert. Ein WBS ist hier kein einfacher Einkaufszettel, sondern ein Vertrag zwischen den Teams.

Das Ende des „Solo-Architekten“

Ein Plan, den ein technischer Leiter allein im Büro entwirft, funktioniert selten. Wenn die Ingenieure, die die Arbeit ausführen, den Plan nicht selbst mitgestaltet haben, werden sie sich nicht an die Termine gebunden fühlen. Der TPM schreibt den WBS nicht – er moderiert die Erstellung.

Der „Tag des WBS“-Workshop

Wir bringen die Leiter aller Fachbereiche (Hardware, Software, Sensorik, Steuerung) in einen Raum. Das Ziel ist es, die Schnittstellen zu finden. In der autonomen Mobilität entstehen Fehler meist in den Lücken zwischen den Teams.

Unsere Regeln für den Workshop:

1. Keine „Magie-Boxen“: Jede Aufgabe muss klar definiert und kürzer als zwei Wochen sein.
2. Explizite Abhängigkeiten: „Was brauche ich von einem anderen Team, bevor ich starten kann?“
3. Definition of Done: Eine Aufgabe ist erst fertig, wenn sie auf der Ziel-Hardware verifiziert wurde, nicht nur, wenn der Code geschrieben ist.

Granularität: Wie tief muss die Planung des technischen Projektmanager gehen?

Ein detaillierter Plan ist kein Gegensatz zu „Agilität“. Hardware-Lieferzeiten lassen sich nicht weg-iterieren. Honest Guys empfiehlt eine rollierende Planung (Rolling Wave):

• Nächste 3 Monate: Sehr detailliert. Aufgaben dauern 1 bis 10 Tage. Schnittstellen sind genau definiert.
• 3 bis 9 Monate: Mittlere Detailtiefe. Fokus auf Meilensteine. Aufgaben dauern 2 bis 4 Wochen.
• Ab 9 Monaten: Grobe Planung von Themenblöcken.

Pragmatische Puffer: Sicherheit einplanen

Wenn ein CEO fordert, den Zeitplan um 25 % zu kürzen, geben viele technische Projektmanager nach und streichen Pufferzeiten. In der Deep-Tech-Entwicklung ist das fahrlässig. Ein Puffer ist kein „Fett“, sondern ein Zeichen von organisatorischer Reife.

Drei Arten von Puffern:

1. Technischer Puffer: Für bekannte Risiken (z. B. neue Sensoren).
2. System-Puffer: Zeit für Fehler, die erst bei der Integration der verschiedenen Teams auftreten.
3. Strategische Reserve: Für unvorhersehbare Ereignisse (z. B. Chipmangel).

Ein Puffer verhindert, dass unter Zeitdruck die Sicherheit leidet. Wenn die Zeit knapp wird, ist der Druck groß, wichtige Tests zu überspringen. Ein Puffer ist die Barriere, die das verhindert.

Fazit

In der Entwicklung autonomer Systeme gewinnt nicht derjenige mit dem schönsten Diagramm. Es gewinnt derjenige, dessen Planung die Realität und das Unbekannte berücksichtigt. Wer das Unbekannte einplant, bereitet den Projekterfolg vor.

Zusammenfassung:

• Vermeide die Copy-Paste-Falle; plane jedes Projekt neu.
• Erstelle den Projektstrukturplan gemeinsam mit den Experten, um Verantwortung zu übertragen.
• Verteidige Pufferzeiten aktiv, um die Sicherheit und Qualität des Produkts zu garantieren.

4. Das Unmögliche verhandeln – Lieferzeiten drastisch verkürzen

Software-Entwickler haben es leicht: Code ist geduldig. Er kann über Nacht überarbeitet werden, und Cloud-Server stehen in Sekunden bereit. Doch wer Maschinen für die physische Welt baut, stößt auf eine harte Realität: die Abhängigkeit von der Lieferkette.

Innovation in der autonomen Mobilität ist nicht nur ein Software-Problem. Es ist ein Hardware-, Logistik- und Physik-Problem. Der beste Algorithmus ist wertlos ohne den passenden Sensor. Hardware-Komponenten wie Steuergeräte (ECUs) oder Fahrwerke haben Lieferzeiten, die in Monaten gemessen werden, nicht in Minuten.

An diesem Punkt scheitern viele Unternehmen. Sie erstellen Roadmaps basierend auf Software-Zyklen und werden dann durch eine neunmonatige Wartezeit auf ein kritisches Bauteil überrascht. In diesem Kapitel geht es darum, diese Barrieren zu durchbrechen. Warten ist in der Tech-Branche keine Strategie, sondern ein Todesurteil. Wir lernen, Lieferanten nicht als Verkäufer, sondern als strategische Partner zu behandeln, um Lieferzeiten zu verkürzen, die in der Branche als unveränderlich gelten.

Sichtbarkeit statt Kapital nutzen

Ein Startup kann preislich nicht mit globalen Autokonzernen konkurrieren. Wenn du fünf LiDAR-Sensoren bestellst, während ein großer Hersteller 50.000 ordert, wird deine Anfrage ignoriert. Du kannst nicht mit Geld gewinnen, also musst du mit einer anderen Währung handeln.

Deine Währung besteht aus drei Teilen:

1. Sichtbarkeit: Die Chance für den Lieferanten, seine Marke mit der Zukunft zu verbinden.
2. Innovation: Die Möglichkeit, seine Technik unter Extrembedingungen zu testen.
3. Zukünftige Skalierung: Das Versprechen, die Basiskomponente einer neuen Fahrzeugkategorie zu werden.

Ändere das Gespräch von „Wie lang ist die Lieferzeit?“ zu „Wie können wir Ihnen helfen, die Zukunft zu gewinnen?“. Große Lieferanten haben oft Angst, als träge wahrgenommen zu werden. Dein Startup ist für sie eine Plattform, um ihre Innovationskraft zu beweisen.

Den Mehrwert formulieren: Vom Verkäufer zum Partner

• Co-Branding: Das Logo des Lieferanten wird prominent auf dem Prototyp platziert.
• R&D-Validierung: Du testest die neueste, noch unbewiesene Hardware im realen Einsatz.
• Content-Engine: Du lieferst dem Lieferanten spektakuläres Videomaterial für sein Marketing.
• Daten-Feedback: Du teilst ungefilterte Performance-Daten, die der Lieferant im Labor nicht simulieren kann.

Der Lieferant als strategischer Partner

In der klassischen Beschaffung ist ein Lieferant nur ein Posten auf einer Liste. Der Einkauf drückt den Preis und wartet. In der Deep-Tech-Branche ist dieses Denken riskant. Wenn du Sicherheits-Systeme an der Grenze der Physik baust, musst du die Mauer zwischen Kunde und Verkäufer einreißen.

Die Kosten der Verzögerung (Total Cost of Delay – TCoD)

Konzerne streiten oft um 5 % Rabatt auf einen Sensor, während das Projekt durch Verzögerungen monatlich 500.000 € an „Burn-Rate“ (Gehälter und Infrastruktur) verbrennt. Als TPM musst du dieses Paradoxon beenden.

Wenn du den TCoD verstehst, bist du bereit, eine „Geschwindigkeits-Prämie“ zu zahlen, um die Verzögerung zu eliminieren. Zeit ist wertvoller als ein kleiner Rabatt auf die Hardware.

Beharrlichkeit als Metrik: Die Anatomie des „Nein“

In der Automobilwelt wird ein „Nein“ oft als physikalisches Gesetz akzeptiert. Wenn ein Lieferant 18 Monate Lieferzeit nennt, aktualisieren viele technische Projektmanager einfach ihren Plan. Das ist ein Fehler. Beharrlichkeit ist eine messbare Disziplin. Ein „Nein“ ist meist keine Unmöglichkeit, sondern ein Prozesshindernis.

Die Dekonstruktion des Hindernisses:

• Das bürokratische „Nein“: Der Vertrieb möchte den Papierkram nicht machen. → Lösung: Suche den Kontakt zum Leiter für Innovation.
• Das Ressourcen-„Nein“: Die Kapazitäten sind belegt. → Lösung: Biete eigene Ingenieure zur Unterstützung an.
• Das Lieferketten-„Nein“: Ein Chip fehlt. → Lösung: Beschaffe den Chip selbst auf dem freien Markt und liefere ihn dem Partner.

Die „Drei-Nein“-Regel: Ein „Nein“ zählt erst, wenn du es von drei verschiedenen Abteilungen auf drei verschiedenen Hierarchieebenen gehört hast (Mitarbeiter, Fachabteilung, Geschäftsführung).

Engineering für Verfügbarkeit

Wenn eine Lieferzeit absolut nicht zu bewegen ist, muss das Design angepasst werden. Wir nennen das Engineering for Availability.

• Parallel Pathing: Bestelle drei verschiedene Bauteile von drei Herstellern gleichzeitig, auch wenn es teurer ist. Wenn das Primärbauteil verspätet ist, hast du sofort eine Alternative.
• Modularer Pivot: Wenn ein maßgefertigtes Teil acht Wochen dauert, aber nur vier Wochen Zeit sind: Entwirf eine Version aus Standardteilen, die sofort verfügbar sind, auch wenn sie weniger effizient ist. Das Ziel ist es, Daten zu sammeln, nicht Perfektion zu erreichen.

Fazit

Wer Standard-Lieferzeiten akzeptiert, akzeptiert den Projektverzug. Durch methodische Beharrlichkeit signalisierst du deinem Team: Der Zeitplan ist heilig. Hindernisse werden aus dem Weg geräumt, nicht verwaltet. Im Rennen um die autonome Mobilität gewinnen wir nicht durch Warten, sondern durch das konsequente Einfordern von Geschwindigkeit.

Zusammenfassung:

• Nutze Sichtbarkeit und Daten als Währung, nicht nur Kapital.
• Denke in Total Cost of Delay (TCoD), um Entscheidungen zu beschleunigen.
• Behandle ein „Nein“ als technisches Problem, das gelöst werden muss.

5. Führung vor Ort – Management in der Werkstatt

Autonome Mobilität basiert auf Daten und Software, doch die entscheidende Phase eines Projekts findet in der physischen Welt statt. Als technischer Projektmanager ist es verlockend, das Projekt ausschließlich über digitale Dashboards und Zeitpläne zu steuern. In der Realität stoßen diese Werkzeuge jedoch an ihre Grenzen, sobald die Hardware-Integration beginnt.

Wenn ein mechanisches System versagt oder Bauteile fehlen, lässt sich das Problem nicht per E-Mail lösen. In diesen Momenten ist die physische Präsenz des TPMs in der Werkstatt entscheidend. Dieses Kapitel beschreibt, wie Führung vor Ort funktioniert, wenn digitale Pläne auf die physikalische Realität treffen.

Der Technische Projektmanager als Expeditor: Blockaden aktiv beseitigen

Im klassischen Management bedeutet „Eskalation“ meist das Versenden von E-Mails an höhere Führungsebene. Bei der Montage eines Prototyps ist dieser Weg oft zu langsam. Der TPM muss hier die Rolle eines Expeditors (Beschleunigers) einnehmen. Die Logik dahinter: Nähe zum Problem verkürzt die Entscheidungswege.

Unterschied zwischen Micromanagement und Expediting

Rolle: Micromanager
Verhalten: Erklärt dem Techniker, wie er das Werkzeug zu halten hat.
Wirkung: Zerstört das Vertrauen und die Eigenverantwortung.

Rolle: Expeditor
Verhalten: Fragt, was den Fortschritt behindert, und beseitigt dieses Hindernis.
Wirkung: Erhöht die Geschwindigkeit und unterstützt das Team.

Ein Beispiel: Ein Lieferant verpasst eine Frist, während der Transport-LKW bereits wartet. Anstatt eine formelle Beschwerde zu schreiben, ist es effektiver, direkt vor Ort zu sein. Durch kurze Wege können technische Fragen (z. B. zur Verkabelung) per Video-Call sofort mit den Ingenieuren geklärt werden. Der TPM fungiert hier als Schnittstelle zwischen dem Büro und der Werkstatt.

Die Zusammenarbeit zwischen Engineering und Werkstatt

In der digitalen Konstruktion passt jedes Bauteil perfekt zusammen. In der Werkstatt zeigt sich jedoch oft die wahre Komplexität. Zwischen den Entwicklern im Büro und den Technikern vor Ort herrscht oft eine natürliche Spannung. Der TPM agiert hier als Vermittler.

CAD vs. Realität

Ein häufiger Fehler ist mangelnde Berücksichtigung der menschlichen Ergonomie. Wenn ein CAD-Modell 5mm Platz für einen Sensor vorsieht, reicht das für die Software aus – aber ein Mechaniker kann dort kein Werkzeug ansetzen. Ein TPM erkennt diesen Konflikt frühzeitig und moderiert eine Lösung (z. B. ein Spezialwerkzeug oder eine Design-Anpassung), bevor Tage mit E-Mails verloren gehen.

Vertrauen durch Fachkompetenz aufbauen

• Respekt vor Erfahrung: Besonders im deutschen Umfeld ist der Titel des „Meisters“ ein Beleg für jahrzehntelange Erfahrung. Ein TPM muss diese Expertise anerkennen.
• Transparenz schaffen: Erkläre dem Werkstatt-Team das „Warum“. Wenn Techniker die strategische Bedeutung eines Meilensteins verstehen, steigt die Motivation.
• Feedback-Schleifen schließen: Wenn ein Mechaniker einen Konstruktionsfehler findet, muss der TPM sicherstellen, dass dieser an die Entwicklung zurückgemeldet wird.

Umgang mit Erschöpfung und Sicherheit

In der Endphase vor einer Deadline steigt das Fehlerrisiko durch Übermüdung. Ein falsch angeschlossenes Kabel an einem Prototyp kann Schäden in Millionenhöhe verursachen. Der TPM ist in dieser Phase der Wächter über die Kapazitäten.

• Überwachung der Belastung: Stille im Team ist oft ein Zeichen von Erschöpfung.
• Schutzfunktion: Der TPM übernimmt die Kommunikation mit der Geschäftsführung, damit sich das Team vor Ort ohne Unterbrechungen auf die Arbeit konzentrieren kann.
• Regenerationszeiten: Nach langen Schichten müssen Ruhephasen zwingend eingehalten werden, um die Sicherheit zu gewährleisten.

Die Stakeout-Strategie: Führung bis zum Abschluss

Kurz vor einer wichtigen Präsentation (z. B. vor dem Investor) gewinnt die Zeit an Gewicht. Die „Stakeout-Strategie“ bedeutet: Der TPM ist als Erster vor Ort und verlässt als Letzter die Werkstatt.

Verantwortung übernehmen

„Fertig“ bedeutet bei Hardware-Projekten nicht, dass der Code geschrieben ist, sondern dass das Fahrzeug sicher auf dem Transporter verladen wurde. In der finalen Phase treten oft unvorhersehbare Fehler auf (z. B. Probleme im CAN-Bus).
Der TPM muss in dieser Situation die Entscheidungshierarchie verkürzen:

• Rückwärtsplanung: Arbeite vom Abfahrtszeitpunkt rückwärts (z. B. Abfahrt 8:00 Uhr bedeutet Verladung um 6:00 Uhr).
• Pause erzwingen: Wenn Fehler durch Stress entstehen, muss der TPM eine kurze Pause anordnen, um das Team neu zu fokussieren.
• Risikoabwägung: Der TPM entscheidet auch nachts: „Versenden wir das Fahrzeug mit einem optischen Mangel oder riskieren wir den Termin?“ Diese Verantwortung darf nicht beim erschöpften Techniker liegen.

Fazit

Erfolg in der autonomen Mobilität zeigt sich nicht in schönen Präsentationen, sondern in funktionierender Hardware auf der Straße. Führung bedeutet hier, die Theorie des Büros mit der Praxis der Werkstatt zu vereinen. Wer als Letzter die Werkstatt verlässt, verwaltet nicht nur ein Projekt – er führt es zum Erfolg.

Kernpunkte für den TPM:

• Physische Präsenz vor Ort ist durch kein digitales Tool ersetzbar.
• Der TPM ist ein Dienstleister für das ausführende Team.
• Entscheidungen unter Zeitdruck müssen vom TPM verantwortet werden, um das Team zu entlasten.

Theorie ist in der Deep-Tech-Welt geduldig, doch entscheidend ist die Umsetzung unter realen Bedingungen. Wie solche komplexen Planungen und technischen Hürden in der Praxis gelöst werden, zeigen unsere konkreten Projektbeispiele im Projektmanagement, vom Prototypenbau bis zur Serienreife.

6. Skalierung ohne Systembruch – Von 30 auf 150 Mitarbeiter

Das Wachstum eines Startups ist ein Paradoxon: Jeder Gründer wünscht es sich, aber ohne Steuerung kann es das Unternehmen zerstören. Im Start up beobachtete ich, wie wir bei 100 Mitarbeitern langsamer wurden, obwohl wir das Team verdreifacht hatten. Die Velocity (Entwicklungsgeschwindigkeit) sank.

Skalierung von 30 auf 150 Personen ist keine lineare Erweiterung, sondern eine komplette Neuausrichtung des organisatorischen Systems. Bei 30 Leuten funktioniert Kommunikation organisch durch Zuruf. Bei 150 Leuten führt das zum Chaos. Um effizient zu bleiben, empfehlen wir die Gewohnheiten eines kleinen Teams durch eine absichtliche Struktur zu ersetzen.

Das Triage-Triumvirat: Ein Schutzwall für die Technik

In einem 50-Personen-Startup entstehen oft „Schattenaufträge“. Ein Gründer bittet einen Ingenieur in der Kaffeepause um ein „kleines Extra-Feature“. Solche Ad-hoc-Anfragen erzeugen Context-Switching (ständiges Hin- und Herwechseln zwischen Aufgaben). Das senkt die Qualität und die Moral.

Um dies zu verhindern, haben wir das Triage-Triumvirat eingeführt – eine zentrale Entscheidungsstelle für alle ungeplanten Aufgaben. Es besteht aus drei Rollen:

1. Product Lead (Der „Warum“-Wächter): Prüft, ob die Anfrage zu den Geschäftszielen (OKRs) passt oder nur eine Ablenkung ist.
2. Technical Lead (Der „Was“-Wächter): Bewertet den technischen Aufwand und das Risiko für die aktuelle Software-Version.
3. Project Lead (TPM) (Der „Wann“-Wächter): Prüft Abhängigkeiten und Zeitpläne. Die Kernfrage lautet: „Wenn wir Ja zu diesem Feature sagen, zu welcher wichtigen Aufgabe sagen wir dann Nein?“

Der Entscheidungsprozess

Alle Anfragen müssen über ein Ticket eingereicht werden. Wöchentlich trifft das Triumvirat eine von drei Entscheidungen:

1. Akzeptieren & Priorisieren: Die Aufgabe ist wichtig und machbar.
2. Ablehnen & Begründen: Die Aufgabe passt nicht zur Strategie. Dies schafft Transparenz und Vertrauen.
3. Aufschieben & Untersuchen: Ein Verantwortlicher wird benannt, um Unklarheiten in einer kurzen Recherchephase zu klären.

Zukunft vs. Gegenwart: Die Aufteilung der Roadmap

Ein häufiger Fehler bei der Skalierung ist, dass das Team nur noch Brände löscht, anstatt an der nächsten Generation des Produkts zu arbeiten. In der autonomen Mobilität ist die „Gegenwart“ (Fehler im aktuellen System) laut und fordernd, während die „Zukunft“ (neue Architektur) still ist. Wenn wir die Zukunft vernachlässigen, verlieren wir den Marktvorteil.

Schutzmechanismen für die Entwicklung

• Wartungs-Quote: Jedes Team reserviert 20 % seiner Zeit für Wartung. Die restlichen 80 % sind für Forschung und Entwicklung geschützt.
• Der „Shield“-Ingenieur: Pro Woche übernimmt ein Teammitglied alle Anfragen und kleinen Bugs. Alle anderen schalten Benachrichtigungen aus, um konzentriert arbeiten zu können (Deep Work).
• Sicherheits-Ausnahme: Nur echte Sicherheitsmängel dürfen diesen Schutzwall durchbrechen.

Ressourcen-Management: Fähigkeiten statt Köpfe

Bei 30 Personen ist die Einstellung neuer Leute oft eine verzweifelte Suche nach Unterstützung. Bei 150 Personen ist es ein komplexes Systemmanagement.

Das Brooks’sche Gesetz

In der Softwareentwicklung gilt: „Ein verspätetes Projekt mit mehr Personal zu verstärken, macht es nur noch später.“ Neue Mitarbeiter benötigen Einarbeitungszeit und erhöhen den Kommunikationsaufwand.

Strategische Personalplanung

Die Suche nach Spezialisten (z. B. für Perception Algorhytmen oder funktionale Sicherheit) dauert oft vier bis sechs Monate. Wenn das Unternehmen heute jemanden einstellt, dauert es inklusive Kündigungsfrist und Einarbeitung fast neun Monate, bis die Person produktiv Code schreibt.

Der TPM-Leitfaden für Ressourcen:

• 12-Monats-Prognose: Plane nicht für heute, sondern für den nächsten großen technologischen Wendepunkt.
• Fähigkeiten-Audit: Frage nicht nach „drei neuen Leuten“, sondern nach der Fähigkeit, bestimmte Tests (z. B. Hardware-in-the-Loop) durchzuführen.
• Qualität vor Quantität: Eine Fehlbesetzung in einem sicherheitskritischen Bereich verursacht hohen Korrekturaufwand. Es ist besser, ein Einstellungsziel zu verpassen, als den Standard zu senken.

Fazit

Die Skalierung von 30 auf 150 Mitarbeiter ist der „Große Filter“ für Tech-Unternehmen. Die meisten scheitern, weil sie versuchen, ein großes Team mit den Methoden eines kleinen Teams zu führen. Erfolg bedeutet, die Lücke zwischen der Finanzplanung der Geschäftsführung und der technischen Realität in der Werkstatt zu schließen.

Zusammenfassung der Skalierungs-Strategie:

• Führe klare Prozesse ein, um die Ingenieure vor Ablenkung zu schützen.
• Trenne konsequent zwischen Systemerhaltung und Innovation.
• Plane Ressourcen basierend auf benötigten technischen Fähigkeiten und langen Vorlaufzeiten.

Suchen Sie erfahrene Begleiter für Ihre Tech-Projekte? Besuchen Sie unsere Über uns Seite für einen direkten Kontakt zu unseren Experten.

Der Beitrag Deep Tech Realität werden lassen: Die entscheidende Rolle Technischer Projektmanager. erschien zuerst auf Honest Guys Consulting.

Gerade in disruptiven Branchen wie dem autonomen Fahren fordert das Steuern von Projekten sichere Navigation, wo der Pfad noch geschrieben wird.

Um Projekte unter Unsicherheit erfolgreich zum Ziel zu führen, braucht es einen pragmatischen Rahmen, der Teams befähigt, selbst in komplexen Szenarien handlungsfähig zu bleiben:

1. Unsicherheit analytisch kartieren: Identifizieren Sie systematisch Wissenslücken und kritische Annahmen, z.B. technische Grenzbereiche oder regulatorische Auslegungsfragen, die es zuvor so nicht gab.
2. Kontrollierte Experimente designen: Statt auf die Gesamtlösung zu wetten, setzen Sie auf kleine, gezielte Tests – wie das Erproben einzelner Sensorcluster unter Realbedingungen. Validieren Sie Hypothesen agil.
3. Entscheidungen inkrementell treffen: Zerlegen Sie komplexe Entscheidungen in überprüfbare Schritte. Jede Iteration liefert neue Daten für den nächsten Schritt.
4. Kontinuierliche Feedback-Schleifen etablieren: Lernen Sie systematisch aus jedem Schritt. Passen Sie Strategie und Taktik flexibel an neue Erkenntnisse an.

Dieser iterative Ansatz ermöglicht, Innovationen sicher voranzutreiben. Der Schlüssel ist ein strukturierter, lernender Umgang mit Ungewissheit.

Stehen Sie vor ähnlichen Herausforderungen? Lassen Sie uns sprechen!

Der Beitrag Unbekanntes Terrain navigieren: Entscheidungen treffen ohne Karte erschien zuerst auf Honest Guys Consulting.