Who owns the gap between two airport systems?

Oct 5

3 min read

Supplier A has delivered exactly what was specified.

Supplier B has delivered exactly what was specified.

Both systems have passed their individual tests.

Yet when they are connected, something does not work.

Who owns the problem?

This is one of the most important questions in complex airport projects because many of the biggest risks do not sit neatly inside a single supplier’s scope.

They sit between the systems.

The interface is where complexity lives

Airport projects increasingly involve multiple specialist suppliers.

Each organisation may be responsible for a clearly defined element of the programme, with its own technical requirements, contractual obligations and testing regime.

That structure is necessary.

But the airport ultimately needs all of those individual elements to operate as one integrated system.

And that is where gaps can appear.

A supplier can meet every requirement within its defined scope while an issue still exists at the interface with another system.

Individually, everything is compliant.

Collectively, the operation has a problem.

Integration needs an owner

Someone needs to look beyond individual packages of work and ask how the entire system behaves.

That means understanding dependencies across:

baggage handling systems
hold baggage screening
controls
baggage reconciliation
airport IT
airline and ground handling systems
operational processes
physical infrastructure

Without that wider view, assumptions can remain hidden until systems are brought together.

By then, changes can be considerably more difficult and expensive.

Specifications cannot capture every interaction

Technical specifications are essential, but airport operations contain thousands of potential interactions.

A document can define what a system should do.

It cannot always predict how multiple systems will behave together under every operational condition.

This is why integration needs to be considered as a discipline in its own right.

The question should not simply be whether each supplier has delivered its scope.

It should also be whether those scopes collectively deliver the operational outcome the airport requires.

Independence matters

There is another challenge.

Every supplier naturally understands its own technology best. They are responsible for delivering it and demonstrating that it meets the agreed requirements.

But airports also benefit from having someone looking at the project without being tied to the success of a particular product or package.

An independent integration perspective can focus on the complete system rather than any individual component.

That means asking different questions.

Where are the gaps between responsibilities?

Which assumptions are being made by different suppliers?

Are interfaces being tested thoroughly enough?

What happens outside normal operating conditions?

And who takes ownership when an issue crosses contractual boundaries?

Finding problems before operations find them

Integration issues discovered during design are manageable.

The same issues discovered during commissioning become expensive.

Discovered after go-live, they become operational problems.

That is why integration should not be treated as a final activity that happens once individual systems are ready.

It needs to run throughout the programme.

Interfaces can be identified early. Requirements can be challenged. Behaviours can be modelled. Testing strategies can be developed around the complete system rather than isolated components.

The earlier those conversations happen, the more options the project team has.