Supply the needed system

Themes: Technical specification; Technology and platform; Tendering; Contracting

Approach to acquiring the needed ITS system

When clarity has been reached about the scope, requirements, functionality, and the means of operation of the proposed ITS, the project can then safely move to procuring a suitable system. The approach can vary greatly, depending both on the ITS system to be deployed and the host environment. This section of the guidance will focus on situations where there is little or no existing ITS, since this is the primary audience for the toolkit.

Key steps during this stage are:

Preparing the detailed functional and technical specifications
Determining the form of procurement to be used
Preparing the bidding documents (or equivalent, non-competitive forms of procurement are used)
Organising the procurement competition, including generating interest among potential suppliers
Selecting a preferred supplier, negotiation, and finalising supply contracts

The procurement of ITS systems is a complex task for which specialist knowledge is required. It is strongly advised to engage independent external expertise throughout this stage (different experts might be used for different activities).

Transport entities who enter their first ITS procurement are acquiring technologies which they do not yet fully understand. They do not yet have the experience to know how exactly to specify their requirements, how to assess various proposals, or how to deal with suppliers who are expert in the domain. First-timers attempting to do this entirely in-house is extremely risky and in many cases would actually be quite irresponsible. It will be necessary to engage some experts for specific tasks. However, this can also be supplemented by partnering with transport operator or cities who have successfully implemented similar ITS.

Functional and Technical Specifications for the procurement of ITS systems

The Functional and Technical Specification phase draws together all of the design work into a coherent and detailed set of documents that allow the ITS (sub-) system(s) to be procured and built in accordance with the desired functionality and features, and to perform within the specified parameters.

As a general principle, the focus should be on Functional Specifications – i.e “what the ITS system should do” – rather than on Technical Specifications, which are “how the system should do it”. The reasons for focussing on the Functional Specifications are:

Technologies and products are evolving rapidly. Focussing on the Functional Specifications allows different suppliers to propose alternative approaches to achieve the desired result. The Client can decide in advance whether it prefers to take a conservative approach (proven technology only) or if it is willing to be innovative.
The supplier invariably has a far better understanding of the hardware and software. It is logical to allow the supplier to figure the best technical solution to the Client’s requirements.
Excessive technical specification may place unnecessary technical burden and development costs on the system. It may also constrain future expandability.
Strict technical specification may (inadvertently or otherwise) favour certain suppliers, and almost predetermine the outcome of the procurement.

Of course, there are some exceptions. If there are existing ITS or computer-based systems, then the technical specifications for the interfaces, protocols, data elements, etc. need to be fully defined and will probably be made mandatory. Similarly, conformance with existing communications, computer platform, operating system, security systems, etc. may also be mandatory and these will be defined in the specifications.

Multiple systems and sub-systems

If an ITS deployment involves multiple systems and sub-systems (e.g. AVM, RTPI, traffic signal priority and back-office systems), the individual elements are likely to be specified separately. They may be procured separately – or at least offered as separate packages – so there may be multiple suppliers. Close attention needs to be paid to the consistency across the systems and sub-systems, to ensure that they integrate will with each other after installation. It is important to remember that once the supply contracts are let, the development is very much out of the Client’s hands. The various suppliers will independently develop what they have been contracted to do according to the specifications. Any weaknesses or inconsistency in the specifications (e.g. data elements, protocols, processes) will manifest themselves as incompatibility when the individual systems have been delivered and attempts are made to integrate them.

Good practice for procurement of ITS systems

The procurement phase has two separate aspects:

The broad procurement framework. This is usually already well-defined either within the organisation or by sponsoring agencies (e.g. Development Partners), and it is not necessary to cover it in this Guidance.
ITS-specific aspects, which are covered in the next paragraphs.

For ITS procurements, the following advice is given:

The approach and selection criteria should be defined at the beginning of the process, and should be clear to all potential bidders. This information would normally be included within the poader procurement documents.
The Client preferences should be clear – e.g. proven technology versus innovation, high- or low-end technology, importance of cost compared to functionality, self-contained system or base for future expansion, communication methods, etc.
Relevant constraints of the host environment should be made known – e.g. availability of GIS data, availability of computerised network data, communications and power supply limitations
It is generally advisable to go for a two-stage procurement, in which the first stage produces a short-list of potentially suitable supplier who are then invited to submit detailed and costed proposals
Suppliers should be required to submit a base-case bid based on the Functional Specification, and then have the possibility to offer alternatives. This allows all bidders to be compared on a like-for-like basis, and the variations to then be compared to the baseline.
It is usually a good idea to allow bidders to propose additional functionality to the core requirements. Most suppliers have developed many extra features, functions and utilities anyway for previous Clients, so they can offer them for marginal cost as long as there is not too much customisation involved. This can be encouraged either by awarding additional points in the marking process, or being willing to allow some additional budget (e.g. 5-10%) for additional functionality.
For some very specific tasks, it may be a good idea to unbundle them and procure them separately (e.g. GIS mapping, if such is not readily available at the site), so that the bidders can focus on the core functionality required in the bid.
The specifications, procurement documents and selection criteria from other successful implementers of ITS are usually valuable reference materials. However, they should NEVER just be copied verbatim, and any materials should be carefully adapted to the host environment.

It is strongly advised to involve qualified internal and external experts in both first and second stage phases of the evaluation. ITS systems are complex, the documentation is usually lengthy and very technical, and bidders will always claim that their system is fully compliant with the specification. The documentation needs to be studied in detail, in part to ensure that the most suitable supplier is selected, in part because some or all of the technical documentation will form annexes to the supply contract.

Negotiations and Contracts

Principle for negotiations and Contracts generally follow those for any complex hardware and software systems. There needs to be a clear understanding among all parties which items must be delivered exactly as per contract, and where there is flexibility. The more complex the system, the more important it is to develop a ‘partnership’ approach with the supplier, since it will require co-operation and teamwork from both Client and supplier to make the ITS system work properly and achieve its potential. Advantage gained in the price or the contract clauses – especially if the supplier feels he has been hard-pressed - may prove quite counter-productive downstream if the Client later has to turn to the supplier for support that is not mandated in the Contract.

Nonetheless, the Client needs to be properly protected, and ensure that it will get what it has paid for. There should be clear milestones in the contract, with various points at which the supplier must demonstrate that the system functions as specified prior to delivery and prior to installation. This is a delicate balance. It is most strongly recommended that the Client forms partnerships with cities or operators who have already implemented such systems, and get their advice on Contract phrasing and incentives, and on where flexibility is required. It is observed that in the public transport industry, cities and operators are very willing to assist and share experience with their counterparts, and such support should be availed of.