Projekte in voller Länge
Alle Mandate und Projektstationen, chronologisch, mit Problem, Vorgehen und Ergebnis.
seit 08/2026 · Server Entwicklung und Austausch
Programme Manager · Smiths Detection
Erneute Beauftragung bei einem ehemaligen Kunden: Programmsteuerung für sicherheitskritische Flughafensysteme zur Entwicklung und zum Austausch eines neuen Servers.
- Anforderungen, Ausschreibungsunterlagen, Angebote und Projektdokumentation mit Engineering und Kunden abgestimmt.
- Upgrade und Deployment eines neuen Serversystems während des laufenden Flughafenbetriebs
11/2022 – 06/2025 · OTA for AED (Android Embedded Device) – Audi, Porsche, VW, Bentley
TPM · Technical Project Manager OTA · Joynext GmbH
Stabilisierung eines hochkritischen OTA- / Cloud-to-Vehicle-Setups für vier OEMs durch Aufbau belastbarer Release Governance, Steuerung von Cloud-Deployments über sechs Server-Umgebungen und Absicherung von China-Rollouts unter UN R155 / UN R156.
- Release- und Dependency-Tracking eingeführt und OTA-Gates für Audi, VW, Porsche und Bentley durchgesetzt.
- Internationale Matrixorganisation über Deutschland, Indien, China und die USA inklusive Tier-2-Partnern und Testfunktionen gesteuert.
- Planung, Tracking und Priorisierung für Change Requests, Defects, Abhängigkeiten und Ressourcenengpässe etabliert.
- CVE-/Patch-Management auf Live-Systemen über sechs Server-Umgebungen gesteuert.
- AWS-Produktivumgebung in China (~2 Mio. Fahrzeuge) unter China-spezifischen Betriebs-, Zertifizierungs- und OTA-/Regulierungsanforderungen gesteuert.
- Zentrale Schnittstelle zu Audi China über die APAC-EMEA-Lieferkette gesteuert, inklusive täglicher operativer Abstimmung zu Entwicklungsumfängen und Rollouts.
- ~1,7 Mio. € Tier-2-/Entwicklungspakete (USA) technisch verhandelt und gesteuert.
PROBLEM: Vier Kundenprogramme ohne strukturiertes Tracking; sechs Server-Umgebungen inkl. separatem Produktivsystem in China mit rund 2 Mio. aktiven Endgeräten zu koordinieren; internes Entwicklungsteam ohne verbindliche Terminkultur bei Änderungsanfragen; fehlende Eskalationskultur in der Organisation erschwerte die strukturierte Durchsetzung von Gates und Fristen.
INTERVENTION: Vorab-Integrationszyklen zur frühen Fehleridentifikation etabliert und durchgesetzt; Change-Freeze-Windows vor kritischen Delivery-Gates forciert; Schwachstellen-/Patch-Management auf Produktivsystemen gesteuert; Verhandlung von rund 1,7 Mio. € Tier-2-Entwicklungspaketen (USA); China-spezifische Betriebs-, Zertifizierungs- und OTA-Anforderungen für einen AWS-Produktivserver (~2 Mio. Fahrzeuge) gesteuert; zentrale Schnittstelle zu Audi China über die APAC-EMEA-Lieferkette gesteuert (tägliche operative Abstimmung zu Entwicklungsumfängen und Rollouts).
RESULT: Software-Liefertreue für vier Kundenprogramme stabilisiert. Sicherheitslücken auf Live-Systemen geschlossen. Freigabe- und Zulassungsprozesse für einen Produktivserver in China (~2 Mio. aktive Endgeräte) unter China-spezifischen Anforderungen und UN R155/156 konsequent gesteuert und abgesichert — Rollout-Stabilität auch unter mehrmonatigen Validierungszyklen sichergestellt.
AWS · Interkulturelle Teamsteuerung · Cloud Release Management · UN R155 / R156 · IoT Fleet Management · OTA / Android Embedded Device
11/2020 – 11/2022 · Transmission Control and Inverter – BMW MHEV / PHEV
Software Project Lead · ZF Friedrichshafen AG
Turnaround eines Programms ohne belastbare Transparenz durch Governance-Aufbau von Null, Wiederherstellung der Steuerbarkeit und vollständige Release-Transparenz gegenüber BMW.
- Governance von Null aufgebaut, inklusive Terminplan, Abhängigkeiten, Arbeitsstruktur und CR-Management.
- Fehlende Feature-Zuordnung zwischen Basisentwicklung und BMW-Meilensteinen hergestellt und als verbindliche Release-Steuerung durchgesetzt.
- Konsistentes Änderungsmanagement (CR) von Grund auf aufgebaut und durchgesetzt.
- Eigenverantwortliches Reporting auf CTO-Ebene übernommen.
- Faktische Entscheidungsgrundlage für die parallel aktive BMW-Taskforce erarbeitet und bereitgestellt.
- Transparenz über SW-Release-Inhalte, Status und Risiken gegenüber BMW hergestellt.
- Das Programm aus dem Blindflug in ein steuerbares Delivery-Setup überführt.
PROBLEM: Projektantritt mit fragmentierten Verantwortlichkeiten, veraltetem Organigramm und Terminplan — Entwicklung im Blindflug; anschließend aktives Krisenmanagement mit paralleler BMW-Taskforce.
INTERVENTION: Governance von Null aufgebaut (Terminplan, Abhängigkeiten); fehlende Feature-Zuordnung zwischen Basisentwicklung und BMW-Meilensteinen eigenverantwortlich hergestellt und als verbindliche Release-Steuerung durchgesetzt; konsistentes Änderungsmanagement (CR) von Grund auf aufgebaut und durchgesetzt; eigenverantwortliches Reporting auf CTO-Ebene; faktische Entscheidungsgrundlage für BMW-geführte Taskforce erarbeitet und bereitgestellt.
RESULT: Projekt aus Blindflug-Modus geführt; Steuerbarkeit & Lieferfähigkeit wiederhergestellt; SW-Release-Transparenz gegenüber BMW sichergestellt; Projektgates eingehalten.
Governance · Task-Force-Steuerung · Meilenstein-Recovery · Release-Steuerung
07/2017 – 05/2020 · Explosives Detection Systems – ECAC Standard 2 to 3
Programme Manager · Smiths Detection
Programmsteuerung für sicherheitskritische Flughafensysteme mit komplexer Stakeholder-Landschaft und koordinierter Umrüstung auf ECAC Standard 3 im laufenden Betrieb.
- Principal Interface für Schiphol und weitere Stakeholder aus Betreiber-, Behörden- und Lieferantenumfeld.
- Upgrade und Deployment von 12 CT-Systemen in Schiphol während des laufenden Flughafenbetriebs koordiniert.
- Anforderungen, Ausschreibungsunterlagen, Angebote und Projektdokumentation mit Engineering und Kunden abgestimmt.
- FAT / SAT, Transportlogistik, Installation und Inbetriebnahme mit Werk, Logistik und Site-Teams gesteuert.
- Zusätzlich Projekte in Spanien unterstützt.
- Eigene Produktidee bis zum Prototyp in Eigenregie umgesetzt und gemeinsam mit der Bundespolizei am Frankfurter Flughafen erprobt – dafür mit dem Smiths Detection Star Award ausgezeichnet.
PROBLEM: Sicherheitskritische CT-Systeme mussten bei laufendem Flughafenbetrieb und mit komplexen Logistik-, Behörden- und Betreiberanforderungen auf einen höheren ECAC-Standard umgerüstet werden.
INTERVENTION: Stakeholder-Koordination auf Programmebene übernommen, technische und logistische Abhängigkeiten zusammengeführt, Angebote und Spezifikationen abgestimmt sowie Rollout, Transport, FAT und SAT eng gesteuert.
RESULT: Belastbare Steuerung eines hochkritischen Live-Rollouts mit 12 CT-Systemen in Schiphol und erfolgreicher Umsetzung in einem sicherheits- und terminkritischen Umfeld.
Explosives Detection · ECAC Standard 3 · CT Scanner Upgrade · Airport Security · Schiphol · Programme Management
07/2015 – 06/2017 · FPK Entry Instrument Cluster – VW, Audi, SEAT, Škoda
SWPM · Software Project Manager · Continental GmbH
Stabilisierung einer kritischen SOP-Anlaufphase für vier OEMs durch Steuerung einer internationalen Matrixorganisation und Absicherung der Delivery über mehrere Offshore-Standorte.
- Internationale Matrix über Kundenprojekt, Basisentwicklung und Offshore-Teams in Singapur, Mexiko und Rumänien koordiniert.
- Kritische SOP-Anlaufphase für VW, Audi, SEAT und Škoda stabil gehalten.
- Change Requests, Defects, Musterbau-Themen und Produktionsthemen eng getrackt und priorisiert.
- Engineering vor Kundendruck geschützt und gleichzeitig Delivery abgesichert.
- Endphasen-Defect-Reduction über fokussiertes Follow-up der Hauptthemen unterstützt.
PROBLEM: Projektstart ohne zugeordnetes Entwicklungsteam, später massive Terminrückstände, Spannungen zwischen Basisentwicklung und Kundenprojekt sowie Engpässe in Musterbau und Produktion.
INTERVENTION: Delivery über mehrere Standorte und Organisationen hinweg synchronisiert, CR- und Defect-Management eng geführt, Muster- und Produktionsengpässe adressiert und Kundenerwartungen mit den realen Entwicklungsabhängigkeiten abgeglichen.
RESULT: Kritische SOP-Phase über vier OEM-Kunden hinweg stabilisiert und Delivery über internationale Matrix- und Offshore-Strukturen abgesichert.
Instrument Cluster · Kombiinstrument · VW · Audi · SEAT · Škoda · SOP Stabilisation
07/2014 – 02/2015 · Innovation Management
Head of Innovation Management · AL-KO Alois Kober GmbH
Strukturierung und Bewertung von Innovationspotenzialen in einem klassischen Metallbauunternehmen ohne etablierte Elektronikkompetenz und Entwicklung eines belastbaren Entscheidungsfundaments für neue Geschäftsfelder.
- Bestehende und neue Ideen systematisch gesammelt, strukturiert und bewertet.
- Technische Optionen, Markttrends und Produktansätze recherchiert und verglichen.
- Elektronisches System inklusive Business Plan, Budget und Terminplan spezifiziert.
- iOS- / Android-App-Konzept entwickelt und native versus hybride Umsetzung bewertet.
- Mögliche Entwicklungspartner identifiziert und Verhandlungen vorbereitet.
PROBLEM: Ein klassisches Metallbauunternehmen wollte neue Innovations- und Produktpotenziale erschließen, verfügte jedoch noch nicht über eine belastbare Elektronik- und Systemperspektive.
INTERVENTION: Ideen und Konzepte aus Vergangenheit und Gegenwart strukturiert ausgewertet, technische Optionen verglichen und daraus ein belastbares Innovations- und Produktkonzept inklusive Spezifikation, Business Plan, Budget und Terminplan entwickelt.
RESULT: Klare Entscheidungsbasis für Innovationsprioritäten, technologische Optionen und mögliche Entwicklungspartner geschaffen – als strategische Vorarbeit für neue Geschäftsfelder.
Innovation Management · Product Strategy · Electronics Concept · Business Plan · Budget Planning · AL-KO
01/2012 – 06/2014 · Daimler NTG5 Infotainment System
Software Project Lead · Harman Becker GmbH
Krisenstabilisierung einer globalen SW-Integration unter massivem SOP-Druck durch konsequente Defect-Steuerung, Neuaufstellung der Offshore-Leistung und formalisiertes EE-Problemmanagement.
- Globale SW-Integration mit ~400 Mitarbeitenden über Deutschland, Ukraine, Indien und China gesteuert.
- A/B/C-Fehlerklassifikation nach Kundenerlebbarkeit und Inflow-/Outflow-Abbauplanung eingeführt.
- Offshore-Entwicklungsdienstleister anhand systematischen Performance-Nachweises ausgetauscht.
- Täglichen globalen Integrationsprozess und formales E/E-Problemmanagement mit Offshore-Teams etabliert.
- Defect-Reduktion von >10.000 auf ~1.500 Tickets (−85 %) mit Fokus auf kundenrelevante Themen gesteuert.
- SOP termingerecht erreicht und Daimler-Abnahme auf E2-Ebene abgesichert.
PROBLEM: >10.000 offene Fehlertickets bei SOP-Druck — verursacht durch extreme Systemkomplexität (nahezu unendliche Testkombinationen) und heterogene Offshore-Performance (DE/UA/IN/CN).
INTERVENTION: A/B/C-Fehlerklassifizierung nach Kundenerlebbarkeit, Inflow-/Outflow-Abbauplanung, Offshore-Entwicklungsdienstleister auf Basis systematischen Performance-Nachweises ausgetauscht, täglicher globaler Integrationsprozess, E/E-Problemmanagement mit Offshore-Teams.
RESULT: >10.000 Tickets auf ~1.500 reduziert (−85 %; Resttickets ausschließlich nicht-endkundenrelevant); Serienstart termingerecht; Daimler-Abnahme auf E2-Ebene.
Krisenmanagement · Fehlerticket-Reduktion −85 % · 400 MA · Daimler E2
04/2011 – 12/2011 · Electronic Steering Systems
Software Project Lead · ZF Lenksysteme / BOSCH
Aufbau eines belastbaren Termin- und Release-Setups für elektronische Lenksysteme unter Ressourcenengpässen und hohem Änderungsdruck.
- Gesamtterminplan mit Abhängigkeiten und Ressourcenlogik aufgebaut, um belastbare Liefertermine zu ermöglichen.
- Release-Management und Freigabeprozess aktiv gesteuert.
- Anforderungen und Termine mit Daimler, AMG und internen Funktionen verhandelt.
- CR-Angebote vorbereitet und rund EUR 1 Mio. damit verbundene Volumina unterstützt.
- Projekt unter schwierigen Ressourcenbedingungen stabilisiert und geordnet übergeben.
Electronic Steering · Release Management · Resource Planning · Daimler · AMG · Change Request Management
08/2009 – 06/2010 · Surround View Camera System
TPL · Technical Project Lead · Magna Electronics Europe · Daimler · AUTOSAR
Aufbau und Führung eines schnell wachsenden Großprojekts für ein Multi-Kamera-System mit 72 Ingenieuren, EUR 18,2 Mio. Budget und direktem Reporting bis CEO- / VP-Ebene.
- Projekt mit 72 Ingenieuren über mehrere Disziplinen und internationale Standorte geführt.
- Gesamtprogrammplan von Grund auf aufgebaut und gegen erhebliche Widerstände durchgesetzt.
- Joint-Venture-Setup sowie Entwicklungs- und Qualitätsprozesse in einem ASPICE-Level-2-Umfeld mit aufgebaut.
- Neue Fertigungsprozesse initiiert, die später auf mehrere Standorte ausgerollt wurden.
- Direkt an CEO, VP und Direktoren berichtet und Budgetverantwortung von EUR 18,2 Mio. getragen.
Surround View · Multi Camera System · AUTOSAR · Project Leadership · Budget Responsibility · Automotive Vision
07/2008 – 07/2009 · Global A Head Unit
Branch Manager · Interim Manager · Panasonic Automotive America (PASA)
Leitung der deutschen Test- und Entwicklungsniederlassung als europäische Schnittstelle für ein US-geführtes Infotainmentprojekt mit Opel / GM.
- Deutsche Niederlassung operativ und technisch geleitet.
- Kunden- und OEM-Schnittstelle zu Opel / GM übernommen.
- Reflash-Kampagnen, Testfahrten und Root-Cause-Analysen in Europa gesteuert.
- Internationale Kommunikation zwischen USA, Indien, China und Deutschland koordiniert.
- Geordnete Schließung der Niederlassung als Kostensenkungsmaßnahme umgesetzt.
Head Unit · Opel GM · Reflash Campaign · Root Cause Analysis · Test Drive Coordination · Global Team Steering
12/2006 – 07/2008 · Steering Angle Sensor Test Bench
Project Lead · Takata Petri / Rücker GmbH
Projektleitung für einen Teststand mit Fokus auf Termin- und Ressourcensteuerung, Qualitätsrichtlinien und belastbarer Kundenabstimmung.
- Termin- und Ressourcenplanung sowie Monitoring aufgebaut.
- Einhaltung SPICE-naher Qualitätsrichtlinien sichergestellt.
- Neue Kundenanforderungen geklärt und spezifiziert.
- Projekt strukturiert und erfolgreich umgesetzt.
Steering Angle Sensor · Test Bench · Schedule Planning · Resource Control · SPICE Quality · Customer Requirements
06/2007 – 02/2008 · Driver Assistance Systems
Requirements Manager / Consultant · Continental Lindau / Rücker GmbH
Spezifikation und Einführung eines Requirements-Management-Prozesses in einem Umfeld ohne etabliertes Tooling.
- Anforderungen aus vorhandenen Dokumenten strukturiert und in einen nachvollziehbaren Prozess überführt.
- Temporäres Excel-basiertes Requirements-Tool betrieben und unterstützt.
- Projektmanager und Senior Engineers im Requirements Management geschult.
Requirements Management · Driver Assistance Systems · Excel Tooling · Traceability · Process Introduction · Engineering Training
07/2006 – 12/2006 · Drive-by-Wire Aftermarket System
Project Lead · PARAVAN / Rücker GmbH
Turnaround eines Drive-by-Wire-Projekts durch Requirement-Freeze, Nachverhandlung von Umfang und Terminplan sowie konsequente Stabilisierung der Umsetzung.
- Requirement-Freeze gegen Widerstände durchgesetzt.
- Umfang und Terminplan mit dem Kunden nachverhandelt.
- Turnaround-Plan intern verhandelt, umgesetzt und nachverfolgt.
- Projekt erfolgreich stabilisiert und zum Abschluss gebracht.
Drive-by-Wire · Aftermarket System · Turnaround · Scope Renegotiation · Requirements Freeze · Project Stabilisation
01/2004 – 07/2006 · Rain / Light Sensor
Development Engineer · Daimler AG
Verantwortung für Testkonzepte, HIL- / SIL- / Fahrzeugtests, Requirements-Vertiefung und beschleunigte Testmethoden in einem frühen Entwicklungsumfeld.
- Testkonzepte, Testfälle und neue Testmethoden entwickelt und umgesetzt.
- Anforderungen zur Ermöglichung früher und automatisierter Tests präzisiert.
- Fahrzeug-, Komponenten-, HIL- und Diagnosetests organisiert, durchgeführt und ausgewertet.
- Benchmarking, Feldrückläuferanalyse und technische Klärungen mit Lieferanten unterstützt.
Rain Sensor · Light Sensor · HIL · SIL · Vehicle Testing · Test Method Development
05/2003 – 12/2003 · Voice Control System (SDS)
Development Engineer · Daimler AG
Eigenverantwortliche Entwicklung und Umsetzung eines Testkonzepts inklusive mehrsprachiger Testskripte und europaweiter Testorganisation.
- Testskripte in sechs Sprachen erstellt.
- Tests mit Muttersprachlern europaweit organisiert und durchgeführt.
- Aufzeichnungsrechner installiert und betrieben sowie Traces analysiert.
- Lieferantenseitige Fehleranalyse unterstützt und Fahrzeugumbauten koordiniert.
Voice Control · SDS · Multilingual Testing · Native Speaker Validation · Trace Analysis · Test Concept
07/2001 – 12/2002 · Flashing Telematics / Infotainment
Development Engineer · Daimler Chrysler AG
Prozesssicheres und rückdokumentiertes Flashen von MOST-Steuergeräten sowie Entwicklung und Umsetzung eines definierten Flashprozesses im Werkstatt- und Versuchsumfeld.
- Definierten Flashprozess für MOST-Steuergeräte umgesetzt.
- Daimler-Mitarbeiter und Lieferanten geschult.
- Testkonzepte, Testspezifikationen und Prototypenaufbauten unterstützt.
- Fahrzeugumbauten und Fehleranalysen mit Tier-1-Lieferanten begleitet.
Flashing Process · Telematics · Infotainment · MOST ECU · Workshop Process · Prototype Support
Fachbeiträge
Perspektiven aus der Programmleitung, hier in voller Länge.
Agile trifft Wasserfall: Governance für hybride Entwicklungsprogramme
Die Frage ist nicht Scrum oder V-Modell — sondern wie beide Welten in einem Programm verbindlich zusammenspielen, ohne dass Teams gegeneinander statt miteinander arbeiten.
In regulierten technischen Umfeldern (z. B. unter Qualitätsmodellen wie ASPICE) arbeiten Entwicklungsteams zunehmend agil, während Freigaben, Lieferantenverträge und Meilensteine weiterhin nach einem Phasenmodell gesteuert werden müssen. In solchen Programmen baue ich eine gemeinsame Governance-Schicht auf, die beide Vorgehensmodelle synchronisiert, statt sie gegeneinander auszuspielen.
- Ein gemeinsamer Meilenstein-Kalender, auf den sowohl Sprints als auch Phasen-Gates einzahlen.
- Requirements- und Change-Traceability, die in beiden Welten denselben Stand zeigt (z. B. über eine verknüpfte DOORS-/Jira-Struktur).
- Klare Schnittstellenrollen zwischen Product Owner (agil) und Programm-/Change-Board (Phasenmodell).
- Frühwarnindikatoren statt Statusfarben: Trend vor Zustand.
- Eskalationspfade, die beide Seiten gleichermaßen verpflichten.
HERAUSFORDERUNG: Teams, die technisch exzellent arbeiten, aber aneinander vorbei liefern, weil Sprint-Ergebnisse und Freigabe-Meilensteine nicht auf denselben Kalender einzahlen.
ANSATZ: Eine schlanke, gemeinsame Governance-Schicht: ein Termingerüst, eine Quelle der Wahrheit für Anforderungen und Status, klar zugeordnete Entscheidungsrechte.
NUTZEN: Belastbare Zusagen gegenüber Kunden und Management, ohne dass Teams ihre bevorzugte Arbeitsweise aufgeben müssen.
Kritische Programme in 90 Tagen stabilisieren: ein pragmatischer Fahrplan
In den ersten 90 Tagen entscheidet sich, ob ein Programm wieder steuerbar wird — oder ob Vertrauen und Termine weiter erodieren.
Als Interim Manager übernehme ich häufig Programme, in denen Transparenz, Termintreue oder Stakeholder-Vertrauen verloren gegangen sind. Ein strukturierter 90-Tage-Fahrplan schafft in kurzer Zeit Steuerbarkeit, ohne das Team zusätzlich zu überlasten.
- Tage 1–15 – Diagnose: Bestandsaufnahme von Scope, Ressourcen, offenen Risiken und tatsächlichem Status (nicht dem berichteten).
- Tage 16–45 – Governance-Aufbau: Terminplan, Verantwortlichkeiten (RACI), Reporting-Kadenz und Eskalationspfade von Grund auf etablieren.
- Tage 46–75 – Stabilisierung: sichtbare Quick Wins liefern, kritischen Pfad aktiv steuern, Lieferanten und Schnittstellen synchronisieren.
- Tage 76–90 – Nachweis: belastbare Meilensteine liefern und Vertrauen bei Kunde/Management über Fakten statt Ankündigungen zurückgewinnen.
- Durchgängig: eine einzige Quelle der Wahrheit für Status – keine widersprüchlichen Reportings an unterschiedliche Stakeholder.
HERAUSFORDERUNG: Programme ohne belastbare Terminplanung, mit fragmentierten Verantwortlichkeiten und einer Historie gebrochener Zusagen.
ANSATZ: Governance von Null aufbauen, kritischen Pfad und Abhängigkeiten sichtbar machen, Entscheidungen dort treffen, wo die Information ist.
NUTZEN: Aus dem Blindflug in ein steuerbares, nachvollziehbares Setup – messbar innerhalb eines Quartals.
Internationale Matrixorganisationen führen: Governance über Zeitzonen, Kulturen und Lieferketten hinweg
Ein Programm über mehrere Zeitzonen, Kulturen und Lieferantenebenen zu führen, ist zuerst eine Governance-Frage — erst danach eine Frage der Zusammenarbeit.
In internationalen Programmen mit Teams in Europa, Asien und den USA reicht ein guter Terminplan allein nicht aus. Entscheidend ist eine Struktur, die unterschiedliche Arbeitszeiten, Kommunikationsstile und Eskalationskulturen zusammenführt, ohne die Geschwindigkeit einzelner Teams auszubremsen.
- Ein verbindlicher, zeitzonenübergreifender Rhythmus für Status, Entscheidungen und Eskalationen (statt reiner Ad-hoc-Kommunikation).
- Eindeutige Schnittstellenrollen zwischen internem Team, Tier-2-/Tier-3-Lieferanten und Kundenorganisation.
- Kulturelle Unterschiede in Feedback- und Eskalationsverhalten aktiv berücksichtigen, statt sie zu ignorieren.
- Verhandlungsführung mit Lieferanten als integraler Teil der Programmsteuerung, nicht als separates Silo.
- Eine gemeinsame Sprache für Status und Risiko – unabhängig davon, wer wo berichtet.
HERAUSFORDERUNG: Verteilte Teams in Deutschland, Indien, China und den USA, inklusive Tier-2-Partnern, ohne gemeinsamen Rhythmus für Entscheidungen und Eskalationen.
ANSATZ: Eine zeitzonenübergreifende Governance-Struktur mit klaren Schnittstellen, eindeutigen Entscheidungsrechten und einer zentralen Schnittstelle zu Schlüssel-Stakeholdern.
NUTZEN: Verlässliche Liefertreue trotz komplexer, internationaler Lieferkette – und ein Team, das sich geführt statt nur gesteuert fühlt.
Was ASPICE Level 2 im Alltag wirklich verlangt – und woran es meistens scheitert
Ein Assessment besteht man nicht mit Dokumenten, sondern mit einer Entwicklung, die tatsächlich so arbeitet, wie die Dokumente behaupten.
Das V-Modell wird oft als Gegenteil von Agilität missverstanden. Tatsächlich beschreibt es zunächst nur eine Symmetrie: Zu jeder Spezifikationsebene auf dem absteigenden Ast gehört eine Nachweisebene auf dem aufsteigenden. Kundenanforderung und Systemtest, Systemarchitektur und Integrationstest, Softwaredetailentwurf und Unit-Test. Wer die linke Seite ausarbeitet, verpflichtet sich damit zur rechten.
Genau an dieser Kopplung scheitert es in der Praxis – und zwar fast nie an fehlendem Willen, sondern an fehlender Verbindung zwischen Werkzeugen und Verantwortlichkeiten. Anforderungen liegen in einem System, Architektur in einem zweiten, Testfälle in einem dritten, Änderungen laufen per E-Mail. Jede Ebene für sich ist ordentlich gepflegt. Nur die Frage, welcher Test welche Anforderung abdeckt, kann niemand in unter zwei Tagen beantworten.
Ein Assessor fragt nicht, ob ein Dokument existiert. Er fragt, ob ein Ergebnis konsistent aus dem vorherigen hervorgeht und ob die Organisation das ohne Vorbereitungswoche zeigen kann. Der Unterschied zwischen Level 1 und Level 2 ist im Kern genau dieser: Level 1 heißt, die Arbeit wird gemacht. Level 2 heißt, sie wird gesteuert – geplant, überwacht, mit definierten Arbeitsergebnissen unter Konfigurationskontrolle.
- Bidirektionale Verfolgbarkeit, die in beide Richtungen belastbar ist: von der Kundenanforderung bis zum Testfall und wieder zurück – nicht als nachträglich gepflegte Tabelle, sondern als Nebenprodukt der täglichen Arbeit.
- Ein Änderungsverfahren, das Anforderung, Architektur, Test und Terminplan gemeinsam bewegt. Eine Änderung, die nur im Anforderungswerkzeug ankommt, ist keine Änderung, sondern eine Inkonsistenz mit Vorlaufzeit.
- Arbeitsergebnisse unter Konfigurationskontrolle, mit einem definierten Reifegrad. „Version 0.9, seit acht Monaten“ ist ein Prozessbefund, kein Zwischenstand.
- Rollen, die tatsächlich besetzt sind. Ein Prozess, der einen Konfigurationsmanager vorsieht, den es nicht gibt, beschreibt eine andere Organisation als die vorhandene.
- Messgrößen, die jemand liest. Kennzahlen, die nur für das Assessment erhoben werden, fallen im Assessment als Erstes auf.
HERAUSFORDERUNG: Organisationen, die die geforderten Arbeitsergebnisse vollständig vorweisen können, aber nicht zeigen können, wie sie auseinander hervorgehen. Die Prozessbeschreibung ist sauber, die gelebte Entwicklung läuft daneben her.
ANSATZ: Die Verfolgbarkeit dorthin verlegen, wo ohnehin gearbeitet wird, statt sie als Zusatzaufgabe an das Projektende zu hängen. Werkzeuge verknüpfen statt Tabellen pflegen, das Änderungsverfahren zum einzigen Weg machen, auf dem sich Umfang bewegt, und Projektleiter und Ingenieure so schulen, dass sie den Zweck verstehen und nicht nur das Feld ausfüllen.
NUTZEN: Ein Assessment wird zur Bestandsaufnahme statt zum Projekt. Wichtiger noch im Tagesgeschäft: Die Frage „Was bricht, wenn wir diese Anforderung ändern?“ ist in Minuten beantwortbar – und das ist der eigentliche Grund, warum sich die Disziplin lohnt.
Software ins Fahrzeug bringen: Release-Governance für OTA unter UN R155/156
Ein Fehler in einer App kostet ein Update. Ein Fehler in einem Fahrzeug-Rollout kostet eine Rückrufaktion – und ein Fahrzeug ist während des Updates kein Telefon, sondern ein Gerät, das jemandem gehört und morgen früh funktionieren muss.
Over-the-Air-Updates werden gern als gelöstes Problem behandelt: Die Technik steht, der Rest sei Logistik. Tatsächlich verschiebt OTA die Last von der Entwicklung in die Freigabe. Solange Software an der Bandkante aufgespielt wurde, war der Serienstart die Grenze. Mit OTA verändert jede Auslieferung eine Flotte, die bereits bei Kunden steht – in mehreren Ländern, mit unterschiedlichen Zulassungsständen, unterschiedlichen Hardware-Ständen und einem Rückweg, der teuer bis nicht vorhanden ist.
UN R155 und R156 machen daraus eine regulatorische Pflicht: ein Cyber Security Management System und ein Software Update Management System, beide nachweisbar, beide auditierbar. Was in der Praxis heißt, dass die Frage „Wer hat wann auf welcher Grundlage entschieden, dass dieser Stand auf 2 Millionen Fahrzeuge geht?“ jederzeit beantwortbar sein muss – nicht rekonstruierbar, sondern beantwortbar.
Die Governance dafür ist unspektakulär und genau deshalb wirksam. Sie besteht im Kern aus wenigen Verabredungen, die konsequent eingehalten werden, statt aus einem umfangreichen Prozesswerk, das im Ernstfall umgangen wird.
- Vorab-Integrationszyklen, die Fehler finden, bevor ein Freigabetermin daran hängt. Integration ist keine Phase am Ende, sondern ein Takt.
- Change-Freeze-Fenster vor kritischen Auslieferungs-Gates – verbindlich, mit einem definierten und dokumentierten Ausnahmeweg statt einer Kultur der stillen Ausnahme.
- Schwachstellen- und Patch-Management auf Produktivsystemen, das getrennt vom Funktionsrelease läuft. Ein Sicherheitspatch darf nicht auf das nächste Feature-Release warten.
- Regionale Anforderungen früh, nicht am Ende: Betriebs-, Zertifizierungs- und Datenanforderungen unterscheiden sich je Markt erheblich, und sie sind kein Nachlauf, sondern Teil des Terminplans.
- Eine Rückfallebene, die geübt ist. Ein Rollback, das noch nie durchgespielt wurde, ist eine Annahme und kein Plan.
- Nachweisführung als Nebenprodukt: Wer entschieden hat, auf welcher Datengrundlage und mit welchem Restrisiko – festgehalten im Moment der Entscheidung, nicht Wochen später für das Audit.
HERAUSFORDERUNG: Mehrere Kundenprogramme auf gemeinsamer Infrastruktur, getrennte Produktivumgebungen je Region, Validierungszyklen über Monate – und daneben Entwicklungsteams, die schneller liefern können als die Freigabekette sie durchlässt.
ANSATZ: Den Takt vorgeben statt zu moderieren: feste Integrationszyklen, verbindliche Freeze-Fenster vor Gates, getrennte Wege für Sicherheits- und Funktionsauslieferungen, und ein Reporting, das den Trend zeigt statt den Status. Eskalation wird zum eingeplanten Vorgang, nicht zum Beziehungsproblem.
NUTZEN: Liefertreue, die auch über mehrmonatige Validierungszyklen hält, ein Sicherheitsstand, der nicht auf den nächsten Funktionsstand wartet, und eine Nachweislage, die einem Audit standhält, ohne dass vorher ein Team wochenlang Belege zusammensucht.
Die Kaffee-Ecke ist kein Small Talk: wie man in den ersten Wochen an die echten Informationen kommt
Ein Statusbericht sagt, was jemand bereit war aufzuschreiben. Was die Leute tatsächlich glauben, erfährt man woanders – und meistens nebenbei.
Wenn ein Externer in ein Programm kommt, das in Schieflage ist, hat das Team zunächst keinen Grund, ihm die unbequeme Wahrheit zu sagen. Im Gegenteil: Ein Interim Manager wird häufig als Bote schlechter Nachrichten gelesen, manchmal als Vorbote von Konsequenzen. In dieser Lage bekommt man genau die Informationen, die ohnehin schon im Bericht stehen – und das sind selten die, die man braucht.
Die entscheidenden Sätze fallen nicht im Statusmeeting. Sie fallen an der Kaffeemaschine, im Flur, in den fünf Minuten vor dem Termin: „Eigentlich wissen wir seit März, dass der Termin nicht hält.“ „Die Schnittstelle hat noch nie funktioniert, wir haben nur nie gemessen.“ Solche Sätze sind kein Flurfunk, sondern die Arbeitsgrundlage. Ohne sie plant man auf einem Stand, den niemand im Raum für realistisch hält.
Deshalb ist der informelle Zugang zum Team für mich kein netter Nebeneffekt, sondern Teil der Methode. Er entsteht nicht durch Freundlichkeit allein, sondern dadurch, dass man früh und sichtbar mit unbequemen Fakten sachlich umgeht, statt sie nach oben zu tragen. Wer einmal erlebt hat, dass eine offene Auskunft keinen Ärger nach sich zieht, sagt beim nächsten Mal früher Bescheid – und genau das ist der Zeitgewinn, um den es geht.
Dazu kommt ein zweiter Punkt, der über den Zugang entscheidet: Ein Externer wird zunächst als der neue Berater beäugt, der mit Folien und unrealistischen Ideen kommt. Ingenieure öffnen sich aber gegenüber jemandem, der versteht, wovon sie reden. Mein Weg über Elektroinstallateur, Techniker und mehrere Jahre als Entwicklungs- und Testingenieur hilft hier mehr als jede Methodenschulung: Ich kann fordern und nachfassen, ohne dass die Forderung an der technischen Realität vorbeigeht – und ich erkenne den Unterschied zwischen „das geht nicht“ und „das wollen wir nicht“. Beides kommt vor, und beides braucht eine andere Antwort.
Bei verteilten Programmen fällt dieser Kanal nicht automatisch an, aber er lässt sich herstellen. In Teams funktioniert das, wenn man es bewusst einrichtet: fünf Minuten vor dem eigentlichen Termin da sein, den Call nach dem offiziellen Teil noch offen lassen, kurze Einzelgespräche ohne Agenda führen. Das ist kein Ersatz für den Flur, aber es kommt nah genug heran – und über Zeitzonen hinweg ist es oft die einzige Möglichkeit.
- In den ersten Tagen mehr zuhören als anordnen. Wer sofort Prozesse verändert, erfährt danach nichts mehr.
- Einzelgespräche ohne Agenda und ohne Protokoll – bewusst kurz, bewusst unstrukturiert.
- Früh im Call sein und nach dem offiziellen Teil noch dableiben. Der Anfang und das Ende eines Termins sind bei verteilten Teams die Kaffee-Ecke.
- Einen Kanal, der nicht der Status-Kanal ist. Wo Status berichtet wird, wird nicht gedacht.
- Was informell kommt, wird nicht zur Entscheidungsgrundlage, bevor es überprüft ist – und es wird niemals gegen denjenigen verwendet, der es gesagt hat. Genau daran entscheidet sich, ob der Kanal offen bleibt.
- Vertraulichkeit halten, auch nach oben. Der Wert dieses Zugangs liegt darin, dass er nicht zur Berichtslinie wird.
HERAUSFORDERUNG: Ein Programm, dessen offizieller Stand und dessen tatsächlicher Stand auseinanderlaufen – und ein Team, das keinen Anlass hat, das einem Externen in der ersten Woche zu erklären.
ANSATZ: Persönlichen Zugang aufbauen, bevor man ihn braucht: zuhören, Zusagen einhalten, unbequeme Auskünfte folgenlos machen. Bei verteilten Teams denselben Raum bewusst schaffen, statt ihn zu vermissen.
NUTZEN: Belastbare Information Wochen früher als über die Berichtslinie – und ein Team, das Probleme meldet, solange sie noch lösbar sind statt wenn sie eskaliert sind.
Taskforce-Blueprint: kriselnde Hardware/Software-Schnittstellen stabilisieren
Schnittstellenchaos zwischen Hardware, Firmware und Cloud ist kein Automotive-Phänomen. Das Muster wiederholt sich in Industrial Automation, Smart Energy und überall dort, wo Geräte im Feld stehen — und der Blueprint dagegen ist derselbe.
Wenn ein Programm an der Hardware/Software-Grenze kippt, liegt es selten an fehlender technischer Kompetenz. Es liegt daran, dass niemand verbindlich definiert hat, welcher Softwarestand zu welchem Hardwarestand gehört, wer eine Änderung freigeben darf und wie ein Fehler aus dem Feld zurück in die Entwicklung kommt. Diese Lücke schließt eine Taskforce — nicht durch mehr Reporting, sondern durch weniger Interpretationsspielraum.
- Erste Woche: eine verbindliche Versions-/Konfigurationsmatrix — welcher Softwarestand ist für welchen Hardwarestand freigegeben, und wer hat das entschieden.
- Eine einzige Fehlerquelle statt drei parallele Listen aus Entwicklung, Fertigung und Service.
- Ein tägliches Kurz-Sync über Gewerkegrenzen hinweg (15 Minuten, feste Teilnehmer), das Statusberichte ersetzt statt sie zu ergänzen.
- Feldrückläufer mit Ursachenzuordnung statt Symptombeschreibung — sonst optimiert die Entwicklung an der falschen Stelle.
- Ein definiertes Ende: ab welchen Kriterien die Taskforce aufgelöst und in die Linie zurückgegeben wird.
HERAUSFORDERUNG: Inkonsistente Versionsstände zwischen Hardware, Firmware und Backend, wachsende Feldrückläufer und drei Organisationseinheiten, die jeweils plausibel begründen können, warum das Problem woanders liegt.
ANSATZ: Eine zeitlich befristete Taskforce mit klarem Mandat, gewerkeübergreifender Besetzung und Entscheidungsrecht — plus einer gemeinsamen Konfigurations- und Fehlerbasis, auf die sich alle Beteiligten verpflichten.
NUTZEN: Nachvollziehbare Aussagen darüber, was im Feld tatsächlich läuft, sinkende Rückläuferquote und eine Organisation, die den Zustand nach Auflösung der Taskforce selbst halten kann.
Playbook: ein Softwareprogramm mit tausenden offenen Defekten wieder steuerbar machen
Ein Backlog mit fünfstelliger Ticketzahl ist kein Qualitätsproblem, sondern ein Priorisierungsproblem. Die Frage ist nicht, wie man alles abarbeitet — sondern was man bewusst nicht abarbeitet.
In einem Infotainment-Programm bei Harman/Daimler habe ich einen Backlog von über 10.000 Tickets um 85 % reduziert, ohne den SOP zu verschieben. Der Hebel lag nicht in mehr Entwicklerkapazität, sondern in einer anderen Sortierlogik: nicht nach Meldedatum oder Melderrang, sondern nach Kundenerlebbarkeit.
- ABC-Klassifizierung nach Erlebbarkeit beim Endkunden — nicht nach interner Schwere-Einstufung, die meist vom Melder stammt.
- Konsequentes Zusammenführen von Duplikaten: ein realer Fehler, ein Ticket, unabhängig davon, wie oft er gemeldet wurde.
- Eine tägliche Integrationsroutine, damit Fixes nicht wochenlang in Zweigen liegen und beim Zusammenführen neue Fehler erzeugen.
- Offshore-Engpässe explizit einplanen: Zeitverschiebung als Taktgeber nutzen statt als Ausrede zu akzeptieren.
- Eine dokumentierte Nicht-Beheben-Entscheidung ist ein Ergebnis — sie muss nur bewusst getroffen und gegenüber dem Kunden vertreten werden.
HERAUSFORDERUNG: Ein Backlog, der schneller wächst als er abgearbeitet wird, und ein Management, das aus der Ticketzahl keine Aussage mehr über die Serienreife ableiten kann.
ANSATZ: Neusortierung nach Kundenerlebbarkeit, Duplikatbereinigung, tägliche Integration und explizite Entscheidungen darüber, was bewusst offen bleibt.
NUTZEN: Eine Ticketzahl, die wieder etwas aussagt, ein gehaltener Serienstart und eine Freigabe, die auf Fakten beruht statt auf Hoffnung.
Interim Manager oder klassischer Projektleiter? Eine Entscheidungshilfe
Beide Rollen führen ein Programm. Der Unterschied liegt darin, ob die Voraussetzungen zum Führen überhaupt noch gegeben sind — und wer sie wiederherstellt.
Ein klassischer Projektleiter treibt ein Programm entlang eines Plans, an den die Organisation glaubt. Genau diese Grundlage fehlt in Krisenprogrammen: Der Plan ist da, aber niemand hält ihn für realistisch. Ein Interim Manager stellt zuerst die Steuerbarkeit her — belastbaren Status, klare Entscheidungsrechte, funktionierende Eskalation — und führt danach.
- Interim sinnvoll, wenn dem Reporting nicht mehr geglaubt wird und Termine ohne erkennbare Ursache reißen.
- Interim sinnvoll, wenn Entscheidungen zwischen Bereichen liegen bleiben, weil niemand formal zuständig ist.
- Interim sinnvoll, wenn die Rolle unbequeme Fakten aussprechen muss, ohne interne Karriereinteressen abzuwägen.
- Klassische Projektleitung genügt, wenn Plan und Realität grundsätzlich zusammenpassen und nur Kapazität fehlt.
- Typischer Fehler: zu lange intern lösen wollen — je später die Entscheidung, desto teurer die Stabilisierung.
HERAUSFORDERUNG: Die Entscheidung fällt meist unter Druck und wird als Personalfrage behandelt, obwohl sie eine Frage nach dem Zustand der Steuerung ist.
ANSATZ: Die Rolle am Zustand ausrichten: Fehlt Kapazität, hilft Projektleitung. Fehlt Steuerbarkeit, braucht es jemanden von außen mit Mandat und ohne interne Bindung.
NUTZEN: Eine bewusst getroffene Rollenentscheidung statt einer Verlegenheitslösung — und ein definiertes Ende, weil Interim-Mandate auf Übergabe angelegt sind.
Häufige Fragen
Wie schnell können Sie starten?
Für neue Mandate stehe ich ab 18.10.2026 zur Verfügung – uneingeschränkt und auch in Vollzeit. Der Einstieg selbst geht dann sehr kurzfristig: Ich bin spontan verfügbar, und wenn es die Situation erfordert, sitze ich innerhalb weniger Stunden im Flieger oder im Auto. Für die meisten Mandate ist ein Start innerhalb weniger Tage realistisch.
Bauen Sie sich eine feste Position im Unternehmen auf?
Nein. Ich verstehe mich als Dienstleister, der hilft, wenn Hilfe gebraucht wird – nicht als jemand, der sich an eine Position klammert. Sobald ein Programm stabil läuft, übergebe ich strukturiert.
Was ist der Vorteil gegenüber einem internen Mitarbeiter?
Vor allem eine ungeschönte Status-quo-Erfassung. Ich habe keine interne Karriere oder Beförderung im Unternehmen im Blick – deshalb auch keinen Anreiz, Probleme kleinzureden, Konflikte zu vermeiden oder Entscheidungen mit Blick auf die eigene Position zu treffen. Ich kann unbequeme Fakten offen ansprechen, ohne auf Seilschaften Rücksicht zu nehmen. Es zählt der Erfolg des Mandats, nicht das eigene Fortkommen im Unternehmen.
Kümmern Sie sich um die Übergabe am Ende des Mandats?
Ja, ausdrücklich. Ich arbeite gerne meinen (internen) Nachfolger ein, damit die Organisation nach meinem Ausstieg selbstständig weiterläuft – das gehört für mich zum Selbstverständnis als Interim Manager.
In welchen Branchen sind Sie tätig?
Automotive OEM/Tier-1 ist meine stärkste Referenzbranche, ich habe aber ebenso in der Luftsicherheit (Smiths Detection) und in der Industrie (AL-KO) gearbeitet. Mein Fokus liegt auf komplexen technischen Programmen – unabhängig von der Branche.
Arbeiten Sie remote oder vor Ort?
Beides – und die Entscheidung liegt bei Ihnen. Ich arbeite remote-first, weil das bei verteilten Programmen meist am effizientesten ist, bin aber ebenso vor Ort bei Ihnen, wenn Sie das wünschen: in der Startphase eines Mandats, bei kritischen Meilensteinen und Eskalationen, oder durchgehend, wenn das Projekt es verlangt. Einsatzorte weltweit. Ich war beruflich wie privat viel international unterwegs – unter anderem auf einer Testfahrt für Mercedes auf der Strecke Busan–Seoul–Busan – und komme mit kurzfristigen Reisen und ungewohnten Umfeldern entsprechend gut zurecht.
Was kostet ein Mandat mit Ihnen?
Remote liegt mein Stundensatz zwischen 85 und 110 €. Wo genau in dieser Spanne, hängt davon ab, wie viel Verantwortung ich übernehme, wie kritisch die Lage ist und wie stark das Mandat den Alltag bestimmt: Ein klar umrissenes Projekt mit freier Zeiteinteilung liegt am unteren Rand, ein Krisenmandat mit Führungsverantwortung und durchgehender Erreichbarkeit am oberen. Für Einsätze vor Ort nenne ich bewusst keinen pauschalen Satz: Er richtet sich nach dem Projektstandort und deckt die Mehrkosten, die der Einsatz vor Ort mit sich bringt – Anreise, Unterkunft und Reisezeit. Deshalb wird er projektbezogen kalkuliert. Sprechen Sie mich direkt an – in der Regel erhalten Sie innerhalb von 24 Stunden eine Rückmeldung. Oder buchen Sie sich direkt einen Termin für ein kostenloses Erstgespräch .
Arbeiten Sie nach V-Modell oder agil?
Beides – die Frage ist in der Praxis fast nie eine Entweder-oder-Entscheidung. In regulierten Umfeldern entwickeln die Teams agil, während Freigaben, Lieferantenverträge und Kundenmeilensteine weiterhin phasenbasiert gesteuert werden müssen. Meine Aufgabe ist die Governance-Schicht dazwischen: ein gemeinsamer Meilenstein-Kalender, eine gemeinsame Quelle der Wahrheit für Anforderungen und Status, klar zugeordnete Entscheidungsrechte. Ausführlich beschrieben in den Insights .
Mit welchen Normen und Prozessmodellen arbeiten Sie?
ASPICE (bis Level 2), ISO 26262 für die funktionale Sicherheit, UN R155/156 für Cybersecurity- und Software-Update-Management, dazu V-Modell/SPICE sowie Scrum, Kanban und hybride Vorgehensmodelle. Wichtig ist mir dabei die Praxis und nicht die Zertifikatslage: Ich habe diese Modelle in laufenden Serienprogrammen angewendet, unter Termindruck und mit realen Assessments – nicht nur in der Prozessdokumentation.
Was passiert in den ersten Wochen eines Mandats?
Zuerst eine ungeschönte Bestandsaufnahme: Wer entscheidet was, welche Zusagen stehen wirklich, wo weichen Terminplan und Realität voneinander ab. Danach die Punkte, die sofort Wirkung zeigen – ein belastbarer Terminplan, ein funktionierendes Änderungs- und Eskalationsverfahren, ein Reporting, dem das Management glauben kann. Erst dann die längerfristigen Themen. Der Fahrplan dahinter steht ausführlich in den Insights .
Wie nehmen Sie Kontakt zum Team auf?
Persönlich und früh – und mit deutlich mehr Zuhören als Anordnen in den ersten Tagen. Die wichtigsten Informationen fallen selten im Statusmeeting, sondern an der Kaffee-Ecke, im Flur oder in den fünf Minuten vor dem Termin. Diese Gespräche sind kein Small Talk, sondern der Zugang zu dem, was das Team tatsächlich für realistisch hält. Bei verteilten Programmen richte ich denselben Raum bewusst über Teams ein: kurz vor dem eigentlichen Termin da sein, den Call danach offen lassen, Einzelgespräche ohne Agenda. Hinzu kommt, dass ein Externer zunächst als Berater mit unrealistischen Ideen beäugt wird – mein technischer Hintergrund als Elektroinstallateur, Techniker und mehrjähriger Entwicklungs- und Testingenieur hilft dabei mehr als jede Methode: Ich kann das Team fordern und bleibe dabei technisch realistisch.
Wann brauche ich einen Interim Manager statt eines klassischen Projektleiters?
Wenn ein Programm bereits in Schieflage ist oder ein akutes Risiko dafür besteht – Termine reißen, Verantwortlichkeiten sind unklar, das Management verliert das Vertrauen ins Reporting. Ein klassischer Projektleiter treibt ein Programm nach Plan; ein Interim Manager stellt zuerst wieder her, dass überhaupt nach Plan gearbeitet werden kann: belastbarer Status, klare Entscheidungsrechte, funktionierende Eskalation. Faustregel: Wenn intern bereits diskutiert wird, ob man jemanden von außen braucht, ist das meist der richtige Zeitpunkt.
Wie sieht die Zusammenarbeit vertraglich aus?
In der Regel als Dienstvertrag auf Stundenbasis, projektbezogen befristet. Rahmenverträge über Personaldienstleister oder Projektvermittler sind ebenfalls möglich und in der Praxis häufig. Ein Angestelltenverhältnis biete ich nicht an.
Wie gehen Sie mit vertraulichen Informationen um?
Diskret und auf Wunsch über eine NDA vor Projektstart. Aus über 25 Jahren in OEM- und Tier-1-Umfeldern bin ich den Umgang mit vertraulichen Programminformationen, Lieferantenkonditionen und internen Eskalationen gewohnt – das schließt ein, dass Erkenntnisse aus einem Mandat nicht in das nächste getragen werden.
Was ist der erste Schritt, wenn ich Sie anfragen möchte?
Am schnellsten geht es telefonisch oder per E-Mail – oder über ein kostenloses Erstgespräch , das Sie sich direkt in meinen Kalender legen können. Wenn Sie sich vorher selbst ein Bild machen wollen: Der Projekt-Gesundheits-Check gibt in zwei Minuten eine erste Einordnung. Für das Gespräch genügt ein grober Überblick: Situation, Zeitrahmen und Größenordnung des Programms. Alles Weitere – Rollenzuschnitt, Verantwortungsumfang, Konditionen – klären wir im Gespräch.
