By the time a transportation authority reaches the partner selection stage of a major infrastructure project, significant work has already been done. Use cases are defined, budgets are approved, and technical specifications are drafted. The tender document runs to dozens of pages. Evaluation panels score submissions against weighted criteria (typically under a most-economically-advantageous-tender, or MEAT, model) covering technical capability, relevant experience, price, and delivery methodology.
And yet a substantial proportion of these projects underperform against their original objectives. The technology works. The vendor has genuine expertise. The point of failure sits in the integration itself—the interfaces, data flows, and operational hand-over between subsystems. The system integration fails anyway, or takes twice as long as projected, or delivers a system that operations staff work around rather than with. The failure mode is almost never the one the RFP was designed to prevent.
What follows are four evaluation criteria that experienced project managers know matter, but that rarely appear explicitly within transportation infrastructure tenders.
1. The depth of legacy integration experience
Most tender documents ask for a list of previous projects and a count of integrated subsystem types. What they do not ask is how the integrator handled projects in which the legacy systems were poorly documented, vendor APIs were incomplete, protocols were non-standard (proprietary serial links, undocumented Modbus registers, or partial DATEX II / NTCIP / OCIT implementations), or the installed hardware predated current specifications by twenty years.
Every major transportation infrastructure project involves legacy systems that do not behave as specified. A signal installation from 2008 running a legacy urban-traffic-control (UTC) controller. A SCADA platform running a customised version of software that the original vendor no longer supports. A tunnel fire detection system integrated by a company that was acquired twice since the initial deployment, with documentation that reflects none of the field modifications made over twelve years of operation.
The question worth asking explicitly is not “how many subsystem types have you integrated?” It is “describe a project where the legacy integration was significantly more complex than specified, and explain how you resolved it.” The answer reveals more about actual capability than any reference list. In practice the tell is whether the integrator works from interface control documents (ICDs) and protocol adapters, and validates every interface through factory and site acceptance testing (FAT/SAT) rather than assuming the documentation is correct.
An integrator with experience across 50 or more subsystem types from multiple vendors has, by definition, encountered the full range of integration problems that exist in the field. One with a narrower portfolio may have excellent capability within a specific technology stack and genuine gaps outside it.
2. The support model after go-live, not just during implementation
Implementation teams and support teams are often different groups with varying skill levels and commercial incentives. A vendor can staff a project with senior engineers during the deployment phase and transition the client to a junior service desk at go-live, often with little structured knowledge transfer. This transition is rarely visible during the procurement process and becomes apparent only when the first serious operational issue arises at 2am on a Sunday.
The questions that surface this risk are specific. Who handles critical incident response after go-live, and what are their qualifications relative to the implementation team? What is the contractual response time for safety-critical system failures – the guaranteed response and restoration times (MTTR), the 24/7 coverage model, and the escalation path – , and what are the financial consequences if that SLA is missed? Has the authority spoken to existing clients about their experience with post-implementation support rather than with the implementation itself?
The cost of a transportation system that collapses during a peak operating period is substantial. An unplanned tunnel closure costs in the order of $500,000 per hour in direct economic impact on freight and commuter flows. A support model that cannot restore critical systems within a defined window is not a minor service quality issue. It is a financial and reputational risk for the authority.
3. Cybersecurity architecture as a first-class design requirement
Transportation infrastructure systems are increasingly recognised as critical national infrastructure and are increasingly targeted by cyberattacks, and are now explicitly in scope of the EU NIS2 Directive (2022/2555) and the Cyber Resilience Act (2024/2847). Despite this, cybersecurity is often treated in tender documents as a compliance checkbox rather than an architectural requirement. Vendors are asked to confirm that they follow relevant standards (ISO 27001, and for OT the IEC 62443 series). Few are asked to explain how cybersecurity is embedded in the system design from the outset, rather than applied as a layer on top of an architecture not designed with security in mind.
The distinction matters because the two approaches produce fundamentally different systems. Security applied as an afterthought tends to create perimeter defences that protect against known attack vectors but leave the underlying system architecture vulnerable if those perimeters are breached. Security embedded in the architecture from the design phase means that individual components are hardened, communications between subsystems are authenticated and encrypted (for example segmented into IEC 62443 zones and conduits, with mutual TLS between components), and the system can detect and isolate a compromised component before it affects the extended network.
4. Clarity about what the vendor will not do
A vendor who is candid about the scope of their capability is giving valuable information. A vendor who presents as capable of everything is providing a warning sign.
Major transportation infrastructure projects almost always involve scope evolution during delivery. Requirements that were clear at the tender stage become ambiguous in execution. New regulatory requirements emerge mid-project (a new NIS2 or CRA obligation, for instance). The authority requests changes that were not anticipated in the original specification. How the integrator handles these situations depends significantly on whether the contract was won on realistic commitments or on commitments designed to secure the project.
The most useful question in this area is direct: “Describe a project where the scope changed significantly during delivery, and explain how you managed the client relationship and the commercial implications.” A vendor with genuine delivery experience has clear examples. One who manages scope creep primarily through contract enforcement rather than collaborative problem-solving will reveal this in the answer.
It is also worth examining what the vendor explicitly excludes from their capability. An integrator who is specific about the subsystem types, geographic markets, or regulatory environments where they lack depth is easier to work with than one who claims universal competence and discovers limitations during delivery.
None of these criteria requires significant additional evaluation effort. They require different questions in the same evaluation process. The difference between a transportation infrastructure project that delivers against its objectives and one that absorbs years of operational bandwidth managing problems that could have been anticipated is often traceable to what was asked during partner selection rather than what was specified in the technical tender.
If any of these questions resonate with an evaluation you are currently running, Lillyneir’s team is available to answer them directly about our own practice and experience. As an intelligent transport systems (ITS) integrator, Lillyneir can speak to each criterion directly: 50+ integrated subsystem types across multiple vendors; legacy integration via interface control documents and protocol adapters (DATEX II, NTCIP, OCIT); a defined post-go-live support model with safety-critical SLAs and 24/7 response; security engineered to IEC 62443 and aligned with NIS2 and the CRA from the design phase; and a candid account of where our scope ends.
