Technical project management for regulated IT 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.

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.

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.