Open Data Services (ODS) publishes the third blog in its series on the Open Contracting for Infrastructure Data Standard (OC4IDS). In Part One, ODS made the case for an infrastructure data standard such as the OC4IDS. Part Two explores how the standard was built, its structure and the resources available to support its implementation. In Part Three – originally published on Medium – ODS reflects on the challenges, opportunities and lessons learnt for infrastructure transparency. 

The 18 months since the OC4IDS beta was first launched have flown by. During that time we’ve worked with organisations across the world, delivered in-person training events in London and Bangkok, and issued two patch releases with improvements to the standard and documentation.

What have we learned from putting OC4IDS to use? Here are three key takeaways that will be shaping our work going forward.

Publishing data is just one part of a bigger puzzle… and often some of the other pieces are missing

Infrastructure project data isn’t typically managed in an existing IT system. Alongside publishing data in a standardised format, most OC4IDS implementers are working on building mandates, processes and software to collect data for the first time.

This lack of established systems and processes is most apparent in relation to infrastructure project registers and identifiers.

In our work helping partners to scope OC4IDS implementation in their countries, we’ve yet to find an example of a centrally maintained infrastructure project register which is integrated with the national procurement system. We also haven’t found examples of procurement systems which provide a free text field to enter an infrastructure project identifier.

Without this data infrastructure, there is a risk that OC4IDS implementation might simply add another disconnected data source to the already scattered data landscape.

As a result, rather than simplifying the process, government employees may find themselves entering the same data into separate procurement and infrastructure transparency systems. There is still value in collecting and publishing OC4IDS data in this context, but the full potential of scaling monitoring efforts and saving time isn’t realised.

A core feature of CoST’s work is the Assurance Process, which is a way of validating and interpreting disclosed data to help raise awareness of key issues around infrastructure procurement. For example, the first CoST Honduras assurance report found that documents were deleted during government changeover.
This points to a need to situate OC4IDS implementation as part of wider reforms on managing infrastructure project data to reduce possibilities for corruption, mismanagement and inefficiency. It’s also shown us that we need to reinforce this need in our early scoping conversations with implementers.

More support is needed to build tools for publishing and using data… and that support is best provided locally

Our work on the OC4IDS helpdesk is focussed on supporting implementers to publish OC4IDS data and we’re well equipped to provide feedback directly to system developers when doing so.

The approach works because OC4IDS defines the correct structure and format for data. This means we’re able to assess data against the standard and provide actionable feedback on how to improve its quality.

As we already covered, the publication of OC4IDS data usually forms part of a larger software development project. In this context, we’ve seen that organisations implementing OC4IDS can lack experience of specifying, managing, and signing-off software development projects. This risks OC4IDS being used in poor-quality tools that are harder to use, maintain and upgrade in the future. Ultimately, these issues can hinder uptake of the new processes for collecting and publishing data on infrastructure projects.

There’s no quick-fix to this issue, but it speaks to the need for government agencies and monitoring groups to recognise the important role of data tools and literacy in scaling up oversight of infrastructure projects and to recruit staff or work with partners with appropriate expertise in managing software development projects.

There’s a role for OC4IDS outside of the CoST assurance process… but there’s more work to be done to meet those needs

The aims of developing the OC4IDS toolkit included providing a means for CoST country programmes to publish interoperable, structured and standardised open data, and supporting OCDS implementers to publish better data on infrastructure contracts.

While much of our work so far has focussed on supporting CoST programmes to use OC4IDS, we’ve also been working with many other organisations interested in publishing OC4IDS data or publishing infrastructure contracts using OCDS. In fact, one of the earliest implementations of OC4IDS was in Nuevo Leon, Mexico, and we’ve supported the national roads agency in Argentina and civil society in India to publish infrastructure contracts in OCDS.

We’re working with a range of other partners and institutions to scope how OC4IDS can support their work.

Including local insights and broadening use cases for the standard helps us to develop it further and make it more precise. For example, we’ve already added new fields and codes to the standard in response to requests from Nuevo Leon to support linking related projects and to support more project types. We are looking forward to continuing to develop OC4IDS to meet the needs of our partners.

What next?

Understanding how people use OC4IDS and the challenges they face is crucial to supporting better data for infrastructure transparency. We need more input from people interested in publishing and using data on infrastructure projects, and we’d love to hear ideas on how we can open up the design process and increase participation.

Through our work on the helpdesk, we’ll continue gathering as much feedback as we can on the standard, its documentation, and its supporting tools to inform future development. CoST and OCP will also be exploring how OC4IDS data can be combined with datasets on environmental impacts, climate change, and gender and social inclusion policies.

We’ll feed these reflections into our continuing work supporting the development and adoption of OC4IDS to help simplify publishing, collecting and using data on infrastructure projects.