Deploy the system

Themes: Planning; Business processes; Human resource; Data streams

Planning for ITS deployment

ITS deployment needs to be carefully planned and properly resourced. ITS deployment is a system delivery project, albeit a relative complex one, and it should be planned along the lines of any other delivery project – i.e. with formal and high-quality planning and project management. Project management tools should be used, with detailed timeline and resource tracking and analysis, manpower allocation of tasks, milestones, dependency analysis, critical path analysis, responsibility assignment, etc.

Deployment of ITS systems needs to be carefully planned. The initial planning should commence during the detailed design phase, so that there is a clear vision of how the ITS deployment will be achieved. This will ensure that adequate resources have been mobilised, responsibilities are clear, and potential barriers have been foreseen and mitigated.

The plan should be comprehensive and cover all aspects of the ITS deployment through to installation, testing/commissioning, sign-off and the initial operational period. The plan should have contingencies for the type of issues that are known to arise in both ITS and general IT projects, it should be flexible and be able to respond to difficulties or delays that may arise in the deployment.

There is substantial international experience in ITS deployment, and it is readily available in practice reports. The Case Studies provide good references on ITS implementation, and highlight some issues that arise and how they have been resolved.

Establish an ITS Deployment Team

An ITS Deployment Team should be established at an early stage, and ideally at least some of its members should be involved in the Functional Specification and Detailed Design phases. This is necessary to ensure that they have a deep understanding of what the ITS system should achieve and how it is intended to work.

Organisations that do not have prior experience of ITS deployment are strongly advised to bring in relevant expertise. This can be achieved in a number of ways including:

  • Engage consultants and technical experts for roles such as project management, system integration, design verification, system and component testing, system commissioning, supplier interface
  • Bring in IT and software specialists who have experience with complex IT projects and system integration (not necessarily in the ITS or even transportation domain). Such experts may be available in other units of the administration or in sister entities.
  • Partner with cities and/or transport operators who have ITS system experience, and who are willing to act as mentors and perhaps provide some of their staff on a support or secondment basis

The team may be built up as deployment approaches, gradually bringing in people from the units that will utilise the ITS functions, and from support functions that will be involved in the installation and commissioning (e.g. maintenance section, IT department). Capacity building is essential and needs to be carefully planned and adequately resourced. This will include core skill training, upskilling, and training and skill transfer by suppliers. Where possible, at least some of the ITS deployment team should visit other transport entities to see how the ITS system(s) work in practice, and to learn from their experiences.

Acceptance testing

If the ITS device or system is innovative or being significantly customised for the Client, it is advisable to specify that a prototype is prepared. This can be examined and approved either at the supplier’s site or on-site at the transport entity.

In any case, it is always advisable to require final product acceptance testing. This ensures that the supplier must deal with all non-compliance issues and design defects before the product can be shipped to the Client. Many Clients have had the unfortunate experience of receiving defective product, and the problem inevitably transfers to them as they have systems on-hand and become anxious to install it. Quite often, Clients accept the product in good faith and believe that if everyone tries their best, it will all work out. Unfortunately, design or production faults do not go away, and once the Client has started installation they are in a much weaker position with the Supplier.

All hardware and software product should be thoroughly tested on receipt, and should not be accepted until they have passed full testing as part of the comprehensive system. The testing procedures should be devised and agreed with the supplier(s), and conducted either in-house or by an independent firm with the relevant expertise. The pass criteria for the individual devices or software should be clearly specified as part of the original contract. An overall pass criterion should also be established, so that if more than an agreed number of units fail, the entire batch is deemed not accepted.

It is important that the testing and acceptance criteria and processes are reasonable, and protect the Client. However, they should not become a major impediment to deployment or be used as an excuse to stop payments from well-performing suppliers. Equally, the Client should not be overly-suspicious of test criteria and methods proposed by a reputable supplier (although they should still get expert advice), as the supplier does have the best knowledge of its own products.

Installation and in-situ testing

Deployment and installation is usually a resource-intensive activity. This is especially the case where devices need to be fitted on all of the buses in a fleet or at a large number of bus stops. It is also the case when a large amount of background and configuration data must be prepared and uploaded (e.g. all routes and bus stopping places, all route section travel times, fares data base). Once again, careful planning, provision of adequate resource, and sufficient training are key to successful deployment. Installation method statements should be prepared, with variants where needed (e.g. for different types and models of buses).

All hardware and software installations should be formally documented, checked and approved. It is advisable to install a pioneer batch of equipment and then review progress. This gives an opportunity to modify the method statement and/or the training before progressing to the full deployment. In some cases, it may identify a problem with the ITS product, in which case a decision needs to be made whether to require the supplier to rectify the problem pre-installation, or to proceed with the installation and rectify afterwards. The latter is not recommended, but sometimes there may be little choice.

Debugging and commissioning

Integration forms part of the deployment and installation phase. This includes integration with other ITS systems, with communication systems, with back-office systems, and with other IT systems.

The installation testing has merely verified that the equipment or software passes the tests on the checklist for the respective system. There would normal be a period of live operation and debugging. This allows the overall ITS system(s) to be tested in live conditions, and may reveal problems that were not apparent in the testing of the individual units. Sometimes it can be fault of the supplier, other times the specification was not exact (Client fault).

When the installation and interfacing has been completed and has passed the initial inspections, a formal commissioning of the system should take place. This is a key milestone, where the Client accepts the ITS system and begins to function with it. While the supplier is still responsible for defects and support as per contract, the Client has accepted a significant degree of responsibility.

Parallel operation and full transition

The ITS system might now enter a period of parallel operation when both the ITS system and the system it replaces (e.g. paper-based system) operate together. It allows the results of the ITS system to be verified against the previous system, and to build confidence (or identify need for remedial action). This could be planned for a few weeks or a few months. It also provides a fall-back in case the ITS system does not work correctly or suffers occasional failures.

While a certain transition period is useful for fall-back purposes and to build confidence among the users, this period should not be too long. Otherwise it can become difficult to dispense with the original system. A nominated “go live” date would usually make the ITS system the permanent process.

Supporting activities

In parallel to the system deployment, a number of other activities take place immediately preceding and during the deployment phase:

  • Preparation of supporting data and utilities
  • Training of front-line personnel
  • Training of back-office and end-users
  • Establishing maintenance and support