Selected programmes.

One regulation, many parties, no shared language

European regulation obliges railway undertakings and infrastructure managers to exchange certain operational and vehicle data in a binding format. Fail to comply and you risk losing access to the operational data you need to run services.

At the client three worlds met: vehicles from different manufacturers each with their own data logic, operational systems with legacy interfaces, and infrastructure managers in three countries each reading the same norm differently. No shared target architecture existed.

Accountability for scope, schedule, budget and acceptance

I owned the programme from concept through to go-live: interface specification, steering internal development and external suppliers, alignment with manufacturers and the infrastructure side, and planning test and acceptance.

The defining constraint was the multi-party setup. Nobody involved reported to me, and each party had its own deadlines and priorities. Steering ran through outcomes, clear handover points and verifiable evidence, not through authority.

Read the rulebook first, then cut the architecture

The first step was translating the normative text into testable requirements — including the places where the norm leaves room and interpretations diverge between countries. Surfacing those differences early prevented rework later.

Next came an interface design separating the common core from country-specific edges. The aim was the highest possible standard share, so that each additional country becomes configuration rather than a new project.

Acceptance was planned from the outset: defined test cases per country, documented evidence, and a go/no-go point before go-live.

Live, compliant, and transferable to the next country

The standard is live in all three countries. The client meets the regulatory requirement and receives the operational data it depends on.

More important than the individual rollout is the structure behind it: the design separates standard from country specifics so that further connections are substantially faster.

Many projects, no shared picture

The programmes ran separately in subject matter but drew on the same pool of developers, test environments and domain knowledge. Bottlenecks only became visible once they had already happened, and every project reported differently.

For the board that meant plenty of reporting and little basis for decisions.

Prioritise, surface dependencies, allocate resources

My role was steering across all programmes: prioritisation by impact and deadline pressure, allocation of scarce resources, milestone tracking, and building a single reporting format.

Alongside that came representing the portfolio to the board and to clients in three countries.

One format for all, and flag deviations early

All programmes now report on the same grid: status, next milestone, risks, open decisions. Only then do projects become comparable and bottlenecks visible before they escalate.

Added to that was a forward view on resource conflicts: if two programmes need the same test environment in the same month, that is a decision, not an accident.

Leadership able to decide

The board receives a comparable picture across all programmes and decides priorities and resource allocation on that basis.

Schedule and resource conflicts become visible in advance rather than being explained afterwards.

Requirements from three directions at once

Clients in critical infrastructure demanded substantiated statements on information security, some through their own supplier audits. In parallel European legislation tightened requirements on operators and their suppliers.

The company had a working ISO 9001 quality management system but no information security management system. Above all it was unclear what belonged in scope at all.

Hold the threads rather than produce documents

I coordinated the build: determining scope including whether and how NIS2 and critical infrastructure rules apply, constructing the compliance documentation, integrating it with the existing quality management system, and preparing the audits.

Business units, IT operations, the executive board and external consultants were involved. My job was less writing documents than assembling contributions into an auditable whole.

Scope first, integration rather than a parallel world

It began with boundaries: which systems, sites and processes belong in scope, which do not, and what the supplier role to critical infrastructure means in practice. Too wide a scope creates effort without benefit; too narrow a scope shows up in the audit.

Rather than building a second management system alongside ISO 9001, shared elements — context analysis, risk assessment, document control, internal audits — were merged. That permanently halves the maintenance effort.

A company-wide policy on the use of AI tools was added, because adoption was outgrowing the rules.

Auditable — and confirmed externally twice

The documentation reached audit readiness. Two external client audits were supported in this context: a cybersecurity audit by a state railway company and a supplier audit by a rolling stock manufacturer covering quality and IT security management.

The real gain is a side effect: security requirements are now considered early in bids and projects rather than evidenced at the end.

Legacy, inconsistent, hard to analyse

Projects, tasks and time records were spread across several tools and conventions. Cross-project analysis was laborious and its results contestable, because every unit recorded differently.

At the same time the system was operationally critical: it determines how effort is recorded, work is invoiced and projects are tracked.

Target model, migration and rulebook in one

I led the migration: target architecture, role and permission model, automation, legacy data transfer and rollout across all units.

The harder part was not technical. One system means one set of rules, and those had to be negotiated between units with different habits.

Rules first, then migration

Before the technical switch came agreement on how recording would work in future — project structure, status model, time categories. Without that agreement you migrate the inconsistency along with the data.

Permissions were granted through roles rather than individual cases, so that maintenance does not depend on one person. Recurring steps were automated.

Data transfer ran in stages with a fallback path, so operations continued throughout.

One system, analysis that holds up

All units work on one platform with a consistent structure. Cross-project analysis is possible without rework and is no longer disputed.

Operational downtime during the switch was zero.

Two numbers heading the wrong way

First, infrastructure costs had run well beyond the budget — grown over years without anyone owning the total.

Second, revenue from project business fell behind plan over the year. The cause was not a lack of orders but that payment milestones were not planned and reached consistently.

Find causes, assess measures, follow through

I set both up as programmes: current-state analysis, derivation of measures, assessment by effort and impact, and above all following through until the number moved.

The last part is the decisive one. Lists of measures are quick to produce; what is usually missing is someone who drives them against everyday business for months.

Few metrics, clear ownership, a steady rhythm

Instead of broad reporting, a small number of metrics were defined that actually reflect impact, each with a named owner.

For infrastructure costs, the largest items were broken down, savings assessed against risk and effort, and implemented step by step.

For payment milestones, project owners were shown which milestones fall due when, and what slipping them means for the year-end result.

Double-digit reduction, plan almost recovered

Infrastructure costs were reduced by a double-digit percentage.

Revenue from project business returned close to the original annual plan after a weak start.

Both rest on the same mechanism: one number, one owner, a fixed rhythm — and someone who asks.