Part 4: Providing real-time travel information
The project
4.1
In 2008, the New Zealand Transport Agency (NZTA) began to release real-time travel information for free to developers and third parties. Developers and third parties could republish and repackage NZTA's traffic and road data in innovative ways. This project, called InfoConnect, aimed to provide accurate, timely, and relevant traffic information that:
- tells road users about the condition of state highways in particular, in the areas where they plan to go;
- builds confidence in the usefulness of the information and its supplier(s); and
- provides options for road users to consider in their travel plans.
4.2
After a successful pilot, NZTA set up a web portal where a broad range of developers and other third-party users could access and read about the available Application Programming Interfaces (APIs) and view a gallery that showed what other users created. This quickly attracted interested IT businesses and developers. Six months after InfoConnect was set up, 141 users were registered and 15 of them had asked for access to the APIs to start work on new applications.
4.3
In 2010, phase 2 of the InfoConnect initiative was released successfully. Phase 2 included requirements for:
- significantly increasing consumer demand;
- redeveloping the technical solution architecture;
- implementing new feeds; and
- developing and implementing monitoring and reporting tools.
4.4
At May 2012, about 300 users had registered. Developers and other third-party users can be categorised as normal or high-priority users. Examples of applications that use NZTA data are:
- an interactive online map created by the New Zealand Automobile Association;
- a Yahoo New Zealand website service that uses NZTA webcams in Auckland, Wellington, and Christchurch; and
- iPhone and iPad applications.
4.5
The total investment for the phase 1 pilot and phase 2 was $250,000.
4.6
In 2009, NZTA commissioned a study to assess InfoConnect's economic benefits. This study calculated an estimated net benefit from the InfoConnect project of between $6 million and $60 million a year.4
Realised benefits
4.7
Direct benefits of the project included being:
- more effective through allowing road users to make informed decisions by having access to a variety of information channels on real-time traffic conditions before and during their travel; and
- cheaper and more efficient through using third parties to provide information services for road users.
4.8
Indirect benefits included:
- developers and third parties having free access to NZTA data;
- new value-added traveller information services being provided to the public;
- more efficient transport;
- shorter travel times;
- more certain and reliable estimates of travel times; and
- better choice of routes.
4.9
Intangible benefits included:
- innovation allowing new business opportunities;
- potential to provide significant economic benefit to the country;
- more commercial and national productivity;
- less pollution;
- safer roads through improving information for road users;
- NZTA building a reputation as an organisation with an innovative approach to disseminating information;
- users having a better experience of the road system; and
- less fuel wastage.
4.10
Unexpected and/or unplanned benefits included:
- users collaborating and sharing information, experiences, and expertise through an online forum set up by NZTA;
- the new market for road information services creating interest among new participants (such as Google), particularly in large urban areas; and
- feedback from users helping to improve data quality.
The dynamic nature of realising benefits
4.11
The benefits of changing NZTA's business model and information services to road users are difficult to plan, measure, and quantify.
4.12
There was no formal in-house monitoring of benefits for the InfoConnect project, which was only a small initiative for NZTA. However, the project team regularly reported about the project's success through the use of statistics (such as how many visits its website got). Users (such as http://transportblog.co.nz/) independently reviewed the InfoConnect initiative and reported the main trends and developments.
Practices that helped achieve benefits
4.13
Since it began, InfoConnect has been business-led, not technology-led.
4.14
After observing international technological developments and a fast-moving industry, and observing development options, NZTA decided to stick to its core business and collaborate with third parties. This meant it could share risks and costs with third parties.
4.15
NZTA minimised risks and cost by using a pilot.
4.16
IT businesses, developers, and other third-party users took a strong interest in the project from the beginning. However, the process to get to a shared and common understanding with developers was long and repetitive, with each party using lots of technical words and phrases with many meanings.
4.17
All users had to register with NZTA. This allowed them to access the structured data feeds and ensured that the developers knew who used the data and what for. NZTA provided free information to registered developers and third parties under Terms of Use. It could monitor uptake and see who delivered the best products, allowing it to cut off access to a party that breached the terms of use.
4.18
Innovation involves learning as you go, continually building knowledge and skills, and learning about new technology and architecture. The iterative, learning nature of testing and deployment meant that much depended on individuals.
4.19
Ensuring that road system data was accurate and of a high quality helped InfoConnect to succeed. Feedback from users about data accuracy and quality helped, as did having a pragmatic and committed team focused on solutions.
4.20
Open-source tools and developers' support for them helped NZTA to save money.
Practices that affected the outcome
4.21
Many unknown factors – such as technology, usage, and requirements – led to NZTA underestimating how many resources InfoConnect would need.
4.22
At first, technical architecture provided by an external party was used but this was changed during the project continuity in the technical architecture would have been better.
4.23
At first, NZTA did not tap into the web developer community (such as through Google groups). Later, it asked web developers for feedback and what they saw as best or common practice.
Lessons for other projects
4.24
NZTA looked at distributing traveller information services or data directly to customers and through a variety of channels. However, it rejected this option because it believed that it would be inappropriate to use resources for this distributing if the private sector could do it better.
4.25
After scanning the international environment, NZTA:
- acknowledged that deciding about investment was difficult because of fast technological changes and a fast-moving industry;
- decided to stick to its core business to provide traffic information to the public for free and collaborate with others who have the time, funding, and expertise to find innovative and effective ways to offer technology-enabled traveller information services to meet the demands of road users; and
- decided to share risks and costs with others.
4.26
NZTA minimised risks and cost by first running a pilot before working out the business case. Understanding better how users' responded and what they wanted and required helped NZTA to prepare the business case and technical infrastructure requirements for InfoConnect.
4.27
Throughout the project, business objectives and technical system requirements were in line. From the start, InfoConnect was treated as a business-led, not a technology-led, project.
4.28
From an early stage, there was strong support and commitment from IT businesses and developers. Using a pilot helped NZTA to understand what users wanted and required.
4.29
Innovating means learning. It is important to secure resources for innovating (such as research and discovery, new technology and architecture, and a pilot).
4.30
Registering users meant NZTA:
- controlled who accessed and used the data and what they used it for; and
- could disable access when a user breached the terms of use.
Good practices
4.31
The good practices from this project that we refer to in the discussion in Part 9 are:
- being business-led, flexible, and agile:
- looking at what is happening nationally and/or internationally before starting the work, to reduce the risks of duplication and investing in new information service applications;
- being business-led rather than technology-led; and
- using a pilot;
- using the right technology tools;
- having registered access to open information; and
- using open-source tools; and
- working effectively with the right people, including end users:
- collaborating successfully with third parties who have the expertise, time, and funding to provide effective solutions.
4: Opus International Consultants Limited (2009), The Economic Benefits of InfoConnect.
page top