Your ATM system was installed two years ago. Why isn't it operational yet?

It was 5pm on a Tuesday evening, and I was preparing for my night shift in the ACC when the phone rang. It was the ops manager.

OM: I believe you have some TopSky experience? Me: I do. OM: Have you ever written a transition plan before? Me: Nope. OM: Ah. We're presenting the transition plan tomorrow morning at 11:00. I'd like you in the meeting. Oh, and we don't have a transition plan. Forget about your nightshift, I'd like to see a draft at 09:00 tomorrow morning that you're ready to present.

That conversation was the beginning of eighteen months I wasn't remotely prepared for, and the work that would define everything I've done since. I knew TopSky was installed at the Centre, but that's all I knew. I didn't know what features we had, or even how many positions had been set up. As an operational controller I went in completely blind.

What I've learned since is that this wasn't unusual. It's happening at ANSPs right now, not always full system transitions, but across every flavour of ATM modernisation. The system gets procured. It gets delivered. It gets installed. And then it sits there, because nobody planned for what comes next.

The gap nobody plans for

Ideally, before delivery is complete, there will already be a plan. But in many cases, this is not true. Before a system becomes operational there are many other requirements. Safety cases need writing. Procedures need developing. Data needs migrating and configuring. Staff need training, not immediately before go-live but months before it.

These rarely appear in the procurement plan. They surface later, once the project is already underway, and by then they're guaranteed to stall it. And once it stalls, costs compound: vendor change requests, regulatory delays, and a workforce that's already lost confidence in the programme before it goes live.

If the people who must use the system aren't involved in procurement, you're building a transition problem into the programme from day one.

Why controllers resist (and why they're usually right to)

The first training sessions weren't training sessions. They were complaint sessions.

The controllers weren't resisting change, they were reacting to a system that lacked features they relied on daily, because the requirements had been written without enough operational input. This resistance was diagnostic, not a behaviour problem to be managed.

While a few senior staff were involved in the specification requirements, this was done in isolation. That meant once the system was installed, features controllers depended on every shift simply weren't there. Controllers couldn't believe features they considered basic weren't part of the core build. Blame landed on the manufacturer. The manufacturer pointed back to the specification they'd been given. Both were right.

Every one of those complaints could have been prevented. Not in the training room, but in the procurement process, months or years earlier.

What actually gets a system operational

There's no shortcut for this part. Someone has to sit with the system, learn it from the inside, and build the bridge between what it can do and what operations actually need.

I sat there with a system nobody else on site understood and had to teach myself how it worked. The manuals that existed were either too technical or covered features we didn't have. I had to learn by exploring the system, breaking it, fixing it again, and working out what it could and couldn't do.

Once I grasped the system, the job became translating between what the system could do, and what operations needed. That meant rewriting procedures, configuring databases, and pulling in other departments to start work on safety cases and training. All of which required approvals from people across different departments, and even organisations, with competing priorities and very different risk appetites.

Then came shadowing: running the new system alongside the old one, watching how it handled real traffic, finding the gaps between what we expected and what actually happened. Controlled cutover periods followed: the new system took live traffic for short windows while experienced staff stood ready to switch back.

None of this could be shortcut. There were no workarounds. Trust in a system is built hour by hour, shift by shift. Not in a PowerPoint or classroom.

Before you sign your next modernisation contract, ask one question: who owns the transition? If the answer is the vendor, the project office, or nobody, then you already know where the programme is heading.

The good news is this is a solvable problem, but only if it's addressed before the contract is signed, not after the system is installed.