Insights

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.

Arbeiten Ihre Teams agil, während die Freigaben phasenbasiert laufen? Wo genau es dabei klemmt, lässt sich meist schnell benennen — Erstgespräch buchen, oder vorab der Projekt-Gesundheits-Check.

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.

Sie stehen am Anfang eines solchen Fahrplans? Der Projekt-Gesundheits-Check gibt in zwei Minuten eine erste Einordnung, das Erstgespräch den Rest.

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.

Wenn Ihr Programm über Standorte und Zeitzonen auseinanderläuft: In einem Erstgespräch ordne ich ein, wo die Steuerung als Erstes greifen muss.

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.

Steht bei Ihnen ein Assessment an oder ist eines schiefgegangen? Ein Erstgespräch genügt für eine ehrliche Einschätzung, wie weit der Weg wirklich ist.

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.

Wenn Ihr Update-Prozess vor der Freigabe steht oder gerade hakt: Erstgespräch buchen — unverbindlich.

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.

Sie starten gerade in ein schwieriges Mandat oder wollen jemanden dafür holen? Sprechen wir darüber — Termin buchen.

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.

Erste Selbsteinschätzung gefällig? Der Projekt-Gesundheits-Check braucht zwei Minuten. Für die Lieferantenseite gibt es das Assessment-Grid als Excel-Vorlage. Und wenn Sie die Symptome wiedererkennen: In einem Erstgespräch ordne ich Ihre Situation ein — unverbindlich.

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.

Wenn Ihr Backlog gerade in diese Richtung läuft: Ein Erstgespräch genügt für eine erste Einschätzung.

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.

Unsicher, welche Rolle Ihre Situation braucht? Das lässt sich in einem kurzen Gespräch meist schnell einordnen.