Back to latest

Exploring project identifiers for infrastructure projects

A guest post from Tim Davies on Open Contracting and Infrastructure research

In our last post on Open Contracting for Infrastructure, we looked at what we can learn from bringing together existing contracting and project data. In each of the cases we looked at, we had to carry out manual research to connect contracting processes to a particular infrastructure project. In this post, we document research into ways that project identifiers could be used to ease this process.

Project identifiers: opportunities and challenges

Although the Open Contracting Data Standard (OCDS) includes a ‘Project Identifier’ field, this is rarely used, and, even if it was populated, without new business processes to assign and validate identifiers to projects, there is little to guarantee it would be more reliable than checking against project names.

With an authoritative list of infrastructure projects in a country to draw on, and if the identifiers it assigned were used within contracting systems, it would be possible to automatically check which projects have published contracting information, and to analyse that data to identify projects where further scrutiny, monitoring and data collection should take place. So, as part of our research, we set out to explore whether there were established national or global practices for assigning identifiers to infrastructure projects.

We looked at the literature. We sought out commercial and community-driven infrastructure project databases. And we reviewed existing infrastructure transparency portals to check the identifiers in use. Ultimately, we found very limited uniform practice to draw upon, suggesting that any model for project identifier use will need to be sensitive to differences country-by-country.

Transparency portals and project IDs

In looking at existing CoST partner countries we found a range of practices in play to create a list of construction projects to monitor, including:

Across these cases, there were no examples where a unique project identifier was clearly assigned. In some cases there were:

In a number of cases, projects did appear to have a budget identifier, suggesting that it may be possible to find related contracting processes when the budgetary process goes down to the project level. However, the usability of this as a project identifier is vulnerable to changes in budget coding over time.

Exploring project registers

We found little evidence of robust national construction project registers that assign project identifiers. Responsibility for registers where they do exist appears to be at the Ministry level. However, without central registers, integration with procurement systems is likely to be complicated. And as a recent Open Data Institute report highlights, creating central data registers can require considerable work on both technology and governance.

In the United Kingdom we found the Major Projects Portfolio, but the public face of this appears to primarily be a spreadsheet download without identifiers. In Australia, the National Infrastructure Construction Schedule, appears to use post-codes as identifier fields, for example, WA 6104, NSW 2440 . Whilst using geography as an identifier might be a promising approach for physical infrastructure, there are many cases (such as long roads rather than junctions, or the identification stage of a project that might not yet have an agreed location) where it breaks down. In few cases, we found documented methodologies for assigning project identifiers and creating local project registers. For example, the California Department of Transport have a 10-digit ‘Project Identifier’ with a predictable format:

‘The first two digits of the Project Identifier represent the Charge District, the third and fourth digit represent the year the Project was created in the financial system (EFIS). The fifth through tenth digit represent a randomly system generated number’.

This instance points again to financial systems as the primary place where projects first enter into a ‘register’ of some form, and highlights that this might be the point at which a business process can pick up the creation of a project.

With wider scope, the Global Infrastructure Hub has been creating a ‘crowdsourced’ Projects Pipeline, although this is neither comprehensive, nor does it provide an identifier scheme for projects outside the database IDs given to entries in the pipeline dataset. We also explored a range of third-party projects databases, created by industry publications or international institutions. None appeared to have robust identifiers, and in the case of commercial databases, access to the underlying data about projects was restricted.

Other approaches to identification and registers

Having access to identifiers is not just a problem for infrastructure project transparency: it’s an issue across many different information management domains. We already deal with identifier issues in OCDS in a number of contexts, from setting out a pattern for contracting process identifiers (the ocid), through to using org-id.guide to encourage use of authoritative organisation identifiers. As part of our research we took a look at other identifier initiatives to see what could be learnt from these. These included:

These approaches range from ‘black box’ centralised systems (PermID), through to delegated identifier assignment linked to regulation and business models for maintaining identifiers and their associated registers of metadata (the Legal Entity Identifier). Where infrastructure is treated as an asset class, then it may in future come within the scope of projects like the LEI, although this does not appear to be the case at present.

Finding a way forward

At the conclusion of this rapid research project, we’ve not surfaced a universal approach to project identification that we can recommend, although we have found a range of practices that can be included in implementation guidance for Open Contracting for Infrastructure projects.

In essence, we see three main options, each requiring different levels of technical development and governance.

Option 3 is, of course, highly ambitious, and we believe beyond the scope of any current work on Open Contracting and Infrastructure. Options 1 and 2 are open to countries to pursue, depending on the availability of a central actor, and the political will, to maintain a register — with technical options available for national registers to be implemented in a distributed way that respects departmental responsibilities. Ultimately, options 1 and 2 look relatively similar from the perspective on OCDS data that may be generated, and so the distinction will primarily emerge in adoption guidance.

Whilst consistent use of project identifiers could greatly ease the use of contracting process data for infrastructure transparency, there isn’t likely to be a one-size-fits-all approach to providing them. A ‘gold standard’ approach is likely to be unattainable for many, but a universal solution would have to take a ‘lowest common denominator’ track that holds implementers back from picking the best strategy available to them.

As we take forward this work, there are things that can be done through guidance on data creation and use in order to improve the use of project identifiers. Each individual implementation of OCDS, and of CoST, will need to give consideration to the context-appropriate strategy for project registers and identification, in order to have the best chance of supporting data-driven infrastructure transparency.