Profile

since 08/2026 · Server Development and Replacement

Programme Manager · Smiths Detection

Re-engaged with a former client: programme steering for safety-critical airport systems — new server development and replacement.

• Aligned requirements, tender documents, quotations and project documentation with engineering and customers.
• Upgrade and deployment of a new server system during live airport operations.

11/2022 – 06/2025 · OTA for AED (Android Embedded Device) – Audi, Porsche, VW, Bentley

TPM · Technical Project Manager OTA · Joynext GmbH

Stabilised a high-criticality OTA Cloud-to-Vehicle delivery setup for four OEMs by building release governance, coordinating cloud deployments across six server environments and safeguarding China rollouts under UN R155 / UN R156.

• Established release and dependency tracking and enforced OTA gates across Audi, VW, Porsche and Bentley.
• Steered an international matrix setup across Germany, India, China and the USA, including Tier-2 partners and test functions.
• Established planning, tracking and prioritisation for change requests, defects, dependencies and resource bottlenecks.
• Directed CVE and patch management on live systems across six server environments.
• Managed an AWS production environment in China (~2M vehicles) under China-specific operational, certification and OTA/regulatory requirements.
• Ran the central interface to Audi China across the APAC-EMEA delivery chain, including daily operational alignment on development scope and rollouts.
• Technically negotiated and steered ~EUR 1.7M Tier-2 development packages (USA).

PROBLEM: Inherited 4 OEM customer streams with no structured tracking across six server environments, including a China production server (~2M vehicles) — no gate discipline, no functional escalation culture.

INTERVENTION: Spearheaded pre-integration cycles and change-freeze windows; bridged a 6-month team lead vacancy; directed CVE patching on production servers; negotiated ~EUR 1.7M Tier-2 packages (USA); orchestrated the APAC–EMEA delivery interface with Audi China, managing China-specific operational, certification and OTA requirements for an AWS production server (~2M vehicles), with daily operational alignment on development scope and rollouts.

RESULT: Stabilised SW delivery across four OEMs. Mitigated live CVEs. Managed the approval and release processes for a China production server (~2M vehicles) under China-specific requirements and UN R155/156 — rollout stability sustained throughout.

AWS · Intercultural Team Leadership · 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

Turned around a programme with no reliable transparency by building governance from zero, restoring controllability and creating full release transparency for BMW.

• Built governance from zero, including schedule, dependencies, work structure and CR management.
• Engineered the missing feature-to-milestone mapping between base development and BMW's programme gates and enforced it as binding release governance.
• Built consistent change management (CR) from scratch and enforced it.
• Took over reporting at CTO level.
• Delivered the fact-based decision basis for the parallel BMW task force.
• Established transparency on SW release content, status and risks for BMW.
• Moved the programme from blind-flight mode into a controllable delivery setup.

PROBLEM: Inherited a programme operating without visibility — fragmented accountabilities, an obsolete schedule and no coherent governance. BMW had already activated a parallel task force.

INTERVENTION: Architected end-to-end governance from zero — schedule, dependencies, CR management. Engineered the missing feature-to-milestone synchronisation between base development and BMW's programme gates — imposing it as the binding governance framework for the entire delivery organisation. Reported directly at CTO level; gave the BMW task force its sole reliable decision base.

RESULT: Rescued the programme from zero visibility; restored full delivery controllability; achieved complete SW release transparency for BMW; held all Quality Gate milestones.

Governance · Task Force Leadership · Milestone Recovery · Release Control

07/2017 – 05/2020 · Explosives Detection Systems – ECAC Standard 2 to 3

Programme Manager · Smiths Detection

Programme steering for safety-critical airport systems with a complex stakeholder landscape and coordinated upgrade to ECAC Standard 3 under live operating conditions.

• Acted as principal interface for Schiphol and additional stakeholders across operators, authorities and suppliers.
• Coordinated upgrade and deployment of 12 CT systems at Schiphol during live airport operations.
• Aligned requirements, tender documents, quotations and project documentation with engineering and customers.
• Steered FAT / SAT, transport logistics, installation and commissioning with factory, logistics and site teams.
• Also supported projects in Spain.
• Took an own product idea through to a self-built prototype and trialled it with the German Federal Police at Frankfurt Airport – recognised with the Smiths Detection Star Award.

PROBLEM: Safety-critical CT systems had to be upgraded to a higher ECAC standard while the airport remained in operation and while logistics, authority and operator constraints had to be tightly coordinated.

INTERVENTION: Took over programme-level stakeholder coordination, brought together technical and logistical dependencies, aligned quotations and specifications, and closely steered rollout, transport, FAT and SAT execution.

RESULT: Delivered reliable steering of a highly critical live rollout with 12 CT systems at Schiphol in a safety- and schedule-critical environment.

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

Stabilised a critical SOP ramp-up for four OEMs by steering an international matrix organisation and safeguarding delivery across multiple offshore locations.

• Coordinated an international matrix across customer project, base development and offshore teams in Singapore, Mexico and Romania.
• Kept a critical SOP ramp-up stable for VW, Audi, SEAT and Škoda.
• Closely tracked and prioritised change requests, defects, prototype build issues and production topics.
• Shielded engineering from customer pressure while safeguarding delivery capability.
• Supported end-phase defect reduction through focused follow-up on the main issues.

PROBLEM: The project started without an assigned engineering team, then fell heavily behind schedule, while tensions between base development and the customer project as well as prototype and production bottlenecks increased the risk.

INTERVENTION: Synchronised delivery across multiple locations and organisations, tightly steered CR and defect management, addressed prototype and production bottlenecks and aligned customer expectations with real engineering dependencies.

RESULT: Stabilised a critical SOP phase across four OEM customer streams and safeguarded delivery across international matrix and offshore structures.

Instrument Cluster · Cluster Display · VW · Audi · SEAT · Škoda · SOP Stabilisation

07/2014 – 02/2015 · Innovation Management

Head of Innovation Management · AL-KO Alois Kober GmbH

Structured and assessed innovation potential in a traditional metal-processing company without established electronics capability and built a robust decision basis for new business fields.

• Collected, structured and assessed existing and new ideas in a systematic way.
• Researched and compared technical options, market developments and product approaches.
• Specified an electronic system including business plan, budget and schedule.
• Developed an iOS / Android app concept and assessed native versus hybrid implementation.
• Identified potential development partners and prepared negotiations.

PROBLEM: A traditional metal-processing company wanted to unlock new innovation and product opportunities but lacked a robust electronics and systems perspective.

INTERVENTION: Evaluated past and current ideas in a structured way, compared technical options and developed a robust innovation and product concept including specification, business plan, budget and schedule.

RESULT: Created a clear decision basis for innovation priorities, technology options and potential development partners as strategic groundwork for new business fields.

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

Crisis-stabilised a global software integration under massive SOP pressure through disciplined defect steering, offshore reset and formal EE problem management.

• Steered global software integration with ~400 staff across Germany, Ukraine, India and China.
• Introduced A/B/C defect classification by customer impact and a planned inflow / outflow reduction model.
• Replaced the offshore engineering provider based on systematic performance evidence.
• Established a daily global integration process and formal E/E problem management with offshore teams.
• Drove defect reduction from >10,000 to ~1,500 tickets (−85%) with focus on customer-relevant issues.
• Achieved SOP on time and secured Daimler acceptance at E2 level.

PROBLEM: >10,000 open defect tickets under severe SOP pressure — caused by extreme system complexity and uneven offshore performance (DE/UA/IN/CN).

INTERVENTION: Introduced A/B/C defect classification by customer impact and an inflow/outflow reduction plan. Replaced the offshore engineering provider on the basis of systematic performance evidence; established a daily global integration process and formal E/E problem management.

RESULT: Reduced >10,000 tickets to ~1,500 (−85%, remaining tickets exclusively non-customer-relevant); delivered SOP launch on time; secured Daimler acceptance at E2 level.

Crisis Management · Defect Backlog Reduction −85% · 400 Staff · Daimler E2

04/2011 – 12/2011 · Electronic Steering Systems

Software Project Lead · ZF Lenksysteme / BOSCH

Built a reliable schedule and release setup for electronic steering systems under resource bottlenecks and high change pressure.

• Built an overall schedule with dependencies and resource logic to enable reliable delivery dates.
• Actively steered release management and approval process.
• Negotiated requirements and dates with Daimler, AMG and internal functions.
• Prepared CR offers and supported around EUR 1 million in related volume.
• Stabilised the project under difficult resource conditions and handed it over in an orderly way.

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

Built and led a rapidly growing large-scale programme for a multi-camera system with 72 engineers, EUR 18.2 million budget and direct reporting up to CEO / VP level.

• Led a project with 72 engineers across multiple disciplines and international locations.
• Built the overall programme schedule from scratch and enforced it under major resistance.
• Helped establish the joint venture setup and development / quality processes in an ASPICE-level-2 environment.
• Initiated new manufacturing processes later rolled out to multiple sites.
• Reported directly to CEO, VP and directors and carried budget responsibility of EUR 18.2 million.

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)

Led the German test and development branch as European interface for a US-driven infotainment programme with Opel / GM.

• Led the German branch on an operational and technical basis.
• Took over the customer and OEM interface to Opel / GM.
• Steered reflash campaigns, test drives and root-cause analysis in Europe.
• Coordinated international communication across the USA, India, China and Germany.
• Implemented the orderly closure of the branch as a cost-reduction measure.

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

Project lead for a test bench with focus on schedule and resource steering, quality compliance and reliable customer alignment.

• Built schedule and resource planning and monitoring.
• Ensured compliance with SPICE-related quality guidelines.
• Clarified and specified new customer requirements.
• Structured the project and delivered it successfully.

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

Specified and introduced a requirements management process in an environment without established tooling.

• Structured requirements from existing documents and transferred them into a traceable process.
• Operated and supported a temporary Excel-based requirements tool.
• Trained project managers and senior engineers in requirements management.

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

Turned around a drive-by-wire project through a requirements freeze, renegotiation of scope and schedule, and disciplined implementation stabilisation.

• Enforced a requirements freeze against resistance.
• Renegotiated scope and schedule with the customer.
• Negotiated, implemented and tracked the turnaround plan internally.
• Successfully stabilised the project and brought it to completion.

Drive-by-Wire · Aftermarket System · Turnaround · Scope Renegotiation · Requirements Freeze · Project Stabilisation

01/2004 – 07/2006 · Rain / Light Sensor

Development Engineer · Daimler AG

Responsible for test concepts, HIL / SIL / vehicle testing, requirements refinement and accelerated test methods in an early development environment.

• Developed and implemented test concepts, test cases and new test methods.
• Refined requirements to enable early and automated testing.
• Organised, executed and analysed vehicle, component, HIL and diagnostic tests.
• Supported benchmarking, field-return analysis and technical clarification with suppliers.

Rain Sensor · Light Sensor · HIL · SIL · Vehicle Testing · Test Method Development

05/2003 – 12/2003 · Voice Control System (SDS)

Development Engineer · Daimler AG

Independently developed and implemented a test concept including multilingual test scripts and Europe-wide test coordination.

• Created test scripts in six languages.
• Organised and executed tests with native speakers across Europe.
• Installed and operated recording computers and analysed test traces.
• Supported supplier-side defect analysis and coordinated vehicle modifications.

Voice Control · SDS · Multilingual Testing · Native Speaker Validation · Trace Analysis · Test Concept

07/2001 – 12/2002 · Flashing Telematics / Infotainment

Development Engineer · Daimler Chrysler AG

Delivered process-safe and fully traceable flashing of MOST ECUs and helped implement a defined flashing process for workshop and prototype environments.

• Implemented a defined flashing process for MOST ECUs.
• Trained Daimler staff and suppliers.
• Supported test concepts, test specifications and prototype setups.
• Accompanied vehicle modifications and defect analysis with Tier-1 suppliers.

Flashing Process · Telematics · Infotainment · MOST ECU · Workshop Process · Prototype Support

Agile Meets Waterfall: Governance for Hybrid Delivery Programmes

The real question isn't Scrum versus the V-Model — it's how both worlds work together inside one programme, instead of teams working against each other.

In regulated technical environments (for example under quality models such as ASPICE), development teams increasingly work in an agile way, while approvals, supplier contracts and milestones still need to be steered through a phase-based model. In these programmes, I build a shared governance layer that synchronises both delivery models instead of pitting them against each other.

• A shared milestone calendar that both sprints and phase gates feed into.
• Requirements and change traceability that shows the same status in both worlds (for example via a linked DOORS/Jira set-up).
• Clear interface roles between the Product Owner (agile) and the programme/change board (phase-based).
• Early-warning indicators rather than status colours: trend before state.
• Escalation paths that bind both sides equally.

CHALLENGE: Teams that each deliver excellent technical work but past each other, because sprint outcomes and approval milestones don't feed the same calendar.

APPROACH: A lean, shared governance layer: one schedule backbone, one source of truth for requirements and status, clearly assigned decision rights.

BENEFIT: Reliable commitments to customers and management, without either team having to give up its preferred way of working.

Stabilising Critical Programmes in 90 Days: A Practical Roadmap

The first 90 days decide whether a programme becomes governable again — or whether trust and deadlines keep eroding.

As an interim manager, I typically take over programmes where transparency, delivery reliability or stakeholder trust has broken down. A structured 90-day roadmap restores control quickly, without overloading the team further.

• Days 1–15 – Diagnosis: a stocktake of scope, resources, open risks and the actual status (not the reported one).
• Days 16–45 – Governance build-up: establish a schedule, clear accountabilities (RACI), a reporting cadence and escalation paths from scratch.
• Days 46–75 – Stabilisation: deliver visible quick wins, actively manage the critical path, synchronise suppliers and interfaces.
• Days 76–90 – Proof: deliver credible milestones and rebuild trust with the customer/management through facts, not announcements.
• Throughout: a single source of truth for status – no conflicting reports to different stakeholders.

CHALLENGE: Programmes without a credible schedule, fragmented accountabilities and a history of broken commitments.

APPROACH: Build governance from zero, make the critical path and dependencies visible, and put decisions where the information actually is.

BENEFIT: From flying blind to a governable, traceable set-up – measurable within a quarter.

Leading International Matrix Organisations: Governance Across Time Zones, Cultures and Supply Chains

Leading a programme across several time zones, cultures and supplier tiers is first a governance question — collaboration comes second.

In international programmes with teams spread across Europe, Asia and the US, a good schedule alone is not enough. What matters is a structure that brings together different working hours, communication styles and escalation cultures without slowing any single team down.

• A binding, cross-time-zone rhythm for status, decisions and escalations (rather than purely ad-hoc communication).
• Clear interface roles between the internal team, Tier-2/Tier-3 suppliers and the customer organisation.
• Actively accounting for cultural differences in feedback and escalation behaviour, rather than ignoring them.
• Supplier negotiation as an integral part of programme management, not a separate silo.
• One shared language for status and risk, regardless of who is reporting from where.

CHALLENGE: Distributed teams across Germany, India, China and the US, including Tier-2 partners, with no shared rhythm for decisions and escalations.

APPROACH: A cross-time-zone governance structure with clear interfaces, unambiguous decision rights and a single point of contact for key stakeholders.

BENEFIT: Reliable delivery despite a complex, international supply chain – and a team that feels led, not just managed.

What ASPICE Level 2 actually demands day to day – and where it usually fails

You do not pass an assessment with documents. You pass it with a development organisation that genuinely works the way the documents claim.

The V-model is often misread as the opposite of agile. What it actually describes first of all is a symmetry: every specification level on the descending branch has a corresponding verification level on the ascending one. Customer requirement and system test, system architecture and integration test, software detailed design and unit test. Whoever elaborates the left-hand side has thereby committed to the right.

That coupling is exactly where things break in practice – and almost never for lack of will. It breaks for lack of connection between tools and responsibilities. Requirements live in one system, architecture in a second, test cases in a third, and changes travel by email. Each level on its own is maintained perfectly well. It is just that nobody can answer which test covers which requirement in under two days.

An assessor does not ask whether a document exists. He asks whether one work product follows consistently from the previous one, and whether the organisation can show that without a week of preparation. That, at heart, is the difference between Level 1 and Level 2: Level 1 means the work gets done. Level 2 means it is managed – planned, monitored, with defined work products under configuration control.

• Bidirectional traceability that holds in both directions: from customer requirement through to test case and back again – not as a spreadsheet reconstructed afterwards, but as a by-product of the daily work.
• A change process that moves requirement, architecture, test and schedule together. A change that only reaches the requirements tool is not a change; it is an inconsistency with a delay built in.
• Work products under configuration control, with a defined maturity. „Version 0.9, for the past eight months“ is a process finding, not an interim state.
• Roles that are actually staffed. A process that assumes a configuration manager who does not exist describes a different organisation from the one in the room.
• Metrics somebody reads. Figures collected only for the assessment are the first thing an assessment notices.

CHALLENGE: Organisations that can produce every required work product but cannot show how one follows from another. The process description is clean; the development that actually happens runs alongside it.

APPROACH: Move traceability to where the work already happens instead of bolting it on at the end of the project. Link the tools rather than maintain spreadsheets, make the change process the only route by which scope can move, and train project leads and engineers so they understand the purpose rather than just filling in the field.

BENEFIT: An assessment becomes a stocktake rather than a project. More valuable day to day: the question ‚what breaks if we change this requirement?‘ becomes answerable in minutes – and that is the real reason the discipline pays for itself.

Getting software into a vehicle: release governance for OTA under UN R155/156

A bug in an app costs you an update. A bug in a vehicle rollout costs you a recall – and during an update a car is not a phone. It belongs to somebody, and it has to work tomorrow morning.

Over-the-air updates are often treated as a solved problem: the technology works, the rest is logistics. In reality OTA shifts the load from development into release. As long as software was flashed at the end of the production line, start of production was the boundary. With OTA every delivery changes a fleet that is already with customers – across several countries, with different type-approval states, different hardware states, and a way back that is expensive or absent.

UN R155 and R156 turn this into a regulatory obligation: a cyber security management system and a software update management system, both demonstrable, both auditable. Which in practice means the question ‚who decided, when, and on what basis, that this build goes to two million vehicles?‘ has to be answerable at any moment – answerable, not reconstructable.

The governance for that is unspectacular, and effective precisely because of it. At its core it is a handful of agreements kept consistently, rather than an extensive process framework that gets bypassed when it matters.

• Pre-integration cycles that find defects before a release date depends on them. Integration is a rhythm, not a phase at the end.
• Change-freeze windows ahead of critical delivery gates – binding, with a defined and documented exception route instead of a culture of quiet exceptions.
• Vulnerability and patch management on production systems, running separately from the feature release. A security patch must not wait for the next feature drop.
• Regional requirements early rather than late: operating, certification and data requirements differ substantially by market, and they belong in the schedule rather than trailing it.
• A fallback that has been rehearsed. A rollback nobody has ever exercised is an assumption, not a plan.
• Evidence as a by-product: who decided, on what data, accepting what residual risk – captured at the moment of the decision, not weeks later for the audit.

CHALLENGE: Several customer programmes on shared infrastructure, separate production environments per region, validation cycles running for months – and alongside them development teams able to deliver faster than the release chain can pass them through.

APPROACH: Set the rhythm rather than mediate it: fixed integration cycles, binding freeze windows ahead of gates, separate routes for security and feature deliveries, and reporting that shows the trend rather than the status. Escalation becomes a planned step, not a relationship problem.

BENEFIT: Delivery reliability that holds even across validation cycles measured in months, a security state that does not wait for the next feature state, and an evidence base that survives an audit without a team spending weeks assembling it first.

The coffee corner is not small talk: how to reach the real information in the first weeks

A status report tells you what somebody was willing to write down. What people actually believe, you learn somewhere else – and usually in passing.

When an external arrives in a programme that is in trouble, the team has no particular reason to tell him the uncomfortable truth. Quite the opposite: an interim manager is often read as the bearer of bad news, sometimes as the advance party for consequences. In that position you get exactly the information that is already in the report – and it is rarely the information you need.

The sentences that matter are not spoken in the status meeting. They are spoken at the coffee machine, in the corridor, in the five minutes before a meeting starts: ‚we have actually known since March that the date will not hold.‘ ‚That interface has never worked, we just never measured it.‘ Sentences like that are not gossip; they are the working basis. Without them you plan against a position nobody in the room believes.

So informal access to the team is not a pleasant side effect for me, it is part of the method. It does not come from friendliness alone. It comes from dealing with uncomfortable facts factually and visibly, early on, instead of carrying them upwards. Once somebody has seen that an honest answer brings no trouble, they speak up sooner the next time – and that gain in time is the whole point.

There is a second thing that decides whether you get access at all. An external is eyed at first as the new consultant who turns up with slides and unrealistic ideas. Engineers, though, open up to someone who understands what they are talking about. My route through electrician, state-certified technician and several years as a development and test engineer helps here more than any methodology training: I can push and follow up without the demand missing technical reality – and I can tell the difference between ‚that is not possible‘ and ‚we would rather not‘. Both occur, and each needs a different answer.

On distributed programmes this channel does not appear by itself, but it can be built. In Teams it works if you set it up deliberately: be there five minutes before the meeting starts, leave the call open after the formal part, hold short one-to-ones with no agenda. It is no substitute for the corridor, but it comes close enough – and across time zones it is often the only option there is.

• Listen more than you direct in the first days. Change the process immediately and you will not hear anything after that.
• One-to-ones with no agenda and no minutes – deliberately short, deliberately unstructured.
• Be early on the call and stay after the formal part. For distributed teams, the start and the end of a meeting are the coffee corner.
• A channel that is not the status channel. Where status gets reported, thinking does not happen.
• What arrives informally does not become a basis for decisions until it has been verified – and it is never used against the person who said it. That is precisely what decides whether the channel stays open.
• Keep confidence, upwards too. The value of this access lies in it not becoming a reporting line.

CHALLENGE: A programme whose official position and actual position have drifted apart – and a team with no reason to explain that to an external in week one.

APPROACH: Build personal access before you need it: listen, keep commitments, make uncomfortable answers consequence-free. With distributed teams, deliberately create the same space instead of missing it.

BENEFIT: Reliable information weeks earlier than the reporting line delivers it – and a team that raises problems while they are still solvable rather than once they have escalated.

Task force blueprint: stabilising hardware/software interfaces in trouble

Interface chaos between hardware, firmware and cloud is not an automotive phenomenon. The pattern repeats in industrial automation, smart energy and anywhere devices sit in the field — and the blueprint against it is the same.

When a programme tips over at the hardware/software boundary, it is rarely for want of technical skill. It is because nobody has defined, bindingly, which software state belongs to which hardware state, who may release a change, and how a field failure finds its way back into engineering. A task force closes that gap — not through more reporting, but through less room for interpretation.

• Week one: a binding version and configuration matrix — which software state is released for which hardware state, and who decided that.
• One single source of defects instead of three parallel lists held by engineering, manufacturing and service.
• A daily 15-minute cross-discipline sync with fixed participants that replaces status reports rather than adding to them.
• Field returns recorded with a cause assignment rather than a symptom description — otherwise engineering optimises in the wrong place.
• A defined end: the criteria under which the task force is dissolved and responsibility handed back to the line organisation.

CHALLENGE: Inconsistent version states across hardware, firmware and backend, a rising field return rate, and three organisational units each able to argue plausibly that the problem sits elsewhere.

APPROACH: A time-boxed task force with a clear mandate, cross-discipline staffing and decision rights — plus a shared configuration and defect baseline that all parties commit to.

BENEFIT: Statements about what is actually running in the field that hold up, a falling return rate, and an organisation able to maintain that state once the task force is gone.

Playbook: making a software programme with thousands of open defects governable again

A backlog with a five-figure ticket count is not a quality problem, it is a prioritisation problem. The question is not how to work through all of it — but what you consciously decide not to work through.

On an infotainment programme at Harman/Daimler I brought a backlog of more than 10,000 tickets down by 85 % without moving the start of production. The lever was not additional developer capacity but a different sorting logic: not by reporting date or by the seniority of the reporter, but by what the end customer actually experiences.

• ABC classification by customer-perceivable impact — not by the internal severity rating, which usually comes from whoever raised the ticket.
• Rigorous merging of duplicates: one real defect, one ticket, however many times it was reported.
• A daily integration routine, so fixes do not sit in branches for weeks and create new defects when merged.
• Plan explicitly around offshore bottlenecks: use the time difference as a rhythm rather than accepting it as an excuse.
• A documented decision not to fix something is a result — it simply has to be taken deliberately and defended towards the customer.

CHALLENGE: A backlog growing faster than it is worked off, and a management team that can no longer read production readiness from the ticket count.

APPROACH: Re-sorting by customer-perceivable impact, duplicate cleanup, daily integration, and explicit decisions about what deliberately stays open.

BENEFIT: A ticket count that means something again, a start of production that holds, and a release decision based on facts rather than hope.

Interim manager or conventional project manager? A decision aid

Both roles lead a programme. The difference lies in whether the conditions for leading are still in place at all — and who restores them.

A conventional project manager drives a programme along a plan the organisation believes in. That very foundation is missing in crisis programmes: the plan exists, but nobody considers it realistic. An interim manager first restores governability — a status you can rely on, clear decision rights, an escalation path that works — and leads after that.

• Interim makes sense when the reporting is no longer believed and dates slip without an identifiable cause.
• Interim makes sense when decisions stall between departments because nobody is formally accountable.
• Interim makes sense when the role has to voice uncomfortable facts without weighing internal career interests.
• Conventional project management is enough when plan and reality broadly match and only capacity is missing.
• Typical mistake: trying to solve it internally for too long — the later the decision, the more expensive the stabilisation.

CHALLENGE: The decision is usually made under pressure and treated as a staffing question, when it is in fact a question about the state of governance.

APPROACH: Match the role to the state: if capacity is missing, project management helps. If governability is missing, it takes someone external with a mandate and no internal ties.

BENEFIT: A deliberate role decision rather than a makeshift one — and a defined end, because interim mandates are designed around handover.

How quickly can you start?

I am available for new mandates from 18 October 2026 – without restriction and including full-time. Getting started is then quick: I'm spontaneous by nature, and if the situation requires it, I can be on a plane or in the car within a few hours. For most mandates, a start within a few days is realistic.

Do you try to entrench yourself in a permanent position?

No. I see myself as a service provider who helps where help is needed – not someone who clings to a position. Once a programme is running stably, I hand it over in a structured way.

What's the advantage over using an internal employee?

Mainly an unvarnished view of the status quo. I'm not pursuing an internal career or promotion, so there's no incentive to downplay problems, avoid conflict, or make decisions with an eye on my own position. I can raise uncomfortable facts openly, without worrying about internal politics. What counts is the mandate's success, not my own advancement inside the company.

Do you handle the handover at the end of a mandate?

Yes, explicitly. I enjoy training in my (internal) successor so the organisation keeps running independently after I leave – that's part of how I see my role as an interim manager.

Which industries do you work in?

Automotive OEM/Tier-1 is my strongest reference industry, but I've equally worked in aviation security (Smiths Detection) and industrial equipment (AL-KO). My focus is complex technical programmes, regardless of industry.

Do you work remotely or on-site?

Both – and the choice is yours. I work remote-first because that tends to be the most efficient mode on distributed programmes, but I equally work on-site with you whenever you prefer it: during the opening phase of a mandate, around critical milestones and escalations, or throughout, if the project calls for it. Locations worldwide. I have travelled extensively, professionally and privately – including a test-drive assignment for Mercedes on the Busan–Seoul–Busan route – and am accordingly comfortable with travel at short notice and unfamiliar environments.

What does a mandate with you cost?

Remote, my rate is between EUR 85 and 110 per hour. Where exactly within that range depends on how much responsibility I take on, how critical the situation is and how far the mandate takes over the working day: a clearly scoped project with free time management sits at the lower end, a crisis mandate with leadership responsibility and continuous availability at the upper. For on-site assignments I deliberately quote no flat rate: it is set by the project location and covers the additional cost the on-site work brings with it – travel, accommodation and time on the road. That is why it is quoted per project. Get in touch directly – you will normally hear back within 24 hours. Or book a free intro call directly.

Do you work to the V-model or agile?

Both – in practice it is almost never an either/or decision. In regulated environments the teams develop in an agile way, while releases, supplier contracts and customer milestones still have to be steered through phase gates. My job is the governance layer in between: one shared milestone calendar, one source of truth for requirements and status, clearly assigned decision rights. Described in full under Insights .

Which standards and process models do you work with?

ASPICE (up to Level 2), ISO 26262 for functional safety, UN R155/156 for cybersecurity and software update management, plus V-model/SPICE as well as Scrum, Kanban and hybrid delivery models. What matters to me is the practice rather than the paperwork: I have applied these models in live series programmes, under deadline pressure and through real assessments – not only in process documentation.

What happens in the first weeks of a mandate?

First an honest inventory: who decides what, which commitments actually hold, where the schedule and reality diverge. Then the things that show an effect immediately – a schedule that holds, a change and escalation process that works, reporting that management can believe. Only then the longer-term topics. The roadmap behind this is set out in full under Insights .

How do you make contact with the team?

In person and early – and with considerably more listening than directing in the first days. The information that matters is rarely spoken in the status meeting; it is spoken at the coffee corner, in the corridor, in the five minutes before a meeting starts. Those conversations are not small talk, they are the way in to what the team actually believes is realistic. On distributed programmes I deliberately create the same space in Teams: be there before the meeting proper, leave the call open afterwards, hold one-to-ones with no agenda. On top of that, an external is eyed at first as a consultant with unrealistic ideas – my technical background as an electrician, state-certified technician and several years as a development and test engineer helps more here than any method: I can push the team and stay technically realistic while doing it.

When do I need an interim manager rather than a conventional project manager?

When a programme is already off track, or at acute risk of getting there – dates are slipping, responsibilities are unclear, management no longer trusts the reporting. A conventional project manager drives a programme according to plan; an interim manager first restores the conditions under which working to plan is possible again: a status you can rely on, clear decision rights, an escalation path that works. Rule of thumb: if the organisation is already debating whether it needs someone from outside, that is usually the right moment.

What do the contractual arrangements look like?

Normally a service contract on an hourly basis, limited to the project in question. Framework agreements via staffing providers or project brokers are equally possible and common in practice. I do not take permanent employment.

How do you handle confidential information?

Discreetly, and under an NDA before the project starts where you prefer that. After 25+ years in OEM and Tier-1 environments I am used to handling confidential programme information, supplier terms and internal escalations – which includes not carrying findings from one mandate into the next.

What is the first step if I want to approach you about a project?

The quickest routes are phone or email – or a free intro call that you can put straight into my calendar. If you would rather form your own view first, the project health check gives you a first read in two minutes. For the call itself a rough outline is enough: the situation, the timeframe and the scale of the programme. Everything else – scope of the role, extent of responsibility, terms – we settle in conversation.

Smiths Detection Star Award

Presented by Smiths Detection with the citation: Your STAR Award is presented in recognition of your achievement, your initiative and your outstanding support for the business goals of Smiths Detection.

The award followed an idea of his own: Marc Schuck built the prototype himself and trialled it together with the German Federal Police at Frankfurt Airport.

Press coverage

Profiled in FOCUS magazine, issue 26/2007 (cover feature on pay and careers), and in karriereführer ingenieure 2007/2008 in its feature on project engineering.