Forming a Community of Interest around assets data

The best way to see how community-forming works is through a real example.

In 2011 Wellington City Council identified both a challenge and an opportunity. One of the biggest costs in managing a city’s development is the management of investments in assets such as roads, pipes, and buildings. Typically, however, the data they used to understand and analyse and manage these assets was stored and analysed in siloes.

“Historically water asset managers around here analysed pipes using the data one way, whereas building asset managers stored building assets data and analysed it to answer their specific building management questions another way. Roading asset managers similarly have a further derivation and silo of information and its use.”

But the City Council had a broader interest. How do you effectively manage the lifetime and maintenance and investment in a broad portfolio of assets? It was very difficult at the time to integrate the data by location or service when it was all organised in silos. But there was potential for a different kind of management:

“If I have to dig up this piece of road to x this pipe, are there other works I can do at the same time in that location since it usually costs at least as much to dig up the road as it does to x the pipe?”

“How can I coordinate and manage and analyse shared road corridor space across all utility providers? And, if I’m a utility provider, how can I manage my own work programmes if each council has its own way of storing pipe data? It is almost impossible to integrate pipe data across councils to co-manage or learn from each other.”

To solve this challenge, Haydn Read (Strategic Asset Planning Manager) organised a community to co-design metadata standards for pipes, roads, and other built assets. Metadata standards are a set of protocols for how data can be created, collected, analysed, and visualised to help asset managers and councils make informed investment decisions. If there are standards for storing “this is a pipe” data, then this makes it very cheap, easy, and effcient to integrate that data with other asset data adhering to the same storage and analysis protocol.

Wellington City Council recently did this for all data about infrastructure assets. An independent review by the New Zealand Institute for Economic Research (NZIER) found that this approach would save local government $10 million annually in improved asset management effciency – and an estimated $100 million in reduced IT costs due to a common protocol for integrating and using data about water, pipes, and roads. Not only could these councils answer asset management questions better and invest better in assets, the cost of integrating the data itself would be far lower in IT and related technical costs: anybody adhering to these standards would be able to integrate their data with existing data at low cost.

The community of co-designers were by and large practitioners, not managers

What is important for our purposes here is to note how the standards were developed. It was largely completed using a community co-design approach, with a group of practitioners who were “bound by a shared vision”. The development of community protocols for how data can be integrated and reused is the business of relationship-forming and consensus-building and co-design around a common objective.

There were several reasons for the success of this community:

• The community formed around a common objective to make all their lives easier by establishing metadata standards.
• There was a high level of pragmatism. The working practice of the group was to assume that, for all standards, assumptions could be reversed if found to be incorrect. But decisions had to be made, even when some people initially disagreed. Pragmatically, assumptions about standards were made on the 80/20 principle: they were likely to be imperfect, but adequate until such time as they were tested in operations. Peer review of initial uses of the integrated data standards identified that the logic was sound, and operational learning also uncovered the need to revise assumptions as more information became available.
• The community of co-designers were by and large practitioners, not managers. They were people who both understood the technical detail and had the pragmatism, honed in frontline engagement, to make things work.
• The facilitator was non-aligned to any one particular interest group, had the “thick skin” to keep people in the room, and was pragmatic enough to “call it” when things got stuck, but willing to be proven wrong and revise decisions.

This process in the Wellington City Council for developing common metadata standards for assets is about to be applied across New Zealand. However, it is important to note that the metadata standards were not merely imposed upon the rest of the country. A larger group of the same kind of people has worked under the same kind of process to develop improved asset metadata standards for the whole of New Zealand.

This scaled-up community-building and trust-building enabled two things. Firstly, it socialised the stakeholders and enabled a much wider engagement and adoption across New Zealand on the basis of trust and inclusion: people knew what they were building and signing up for. Secondly, including a much wider range of interests at the table was effective in developing a more versatile and reliable set of standards. The second version of the standards was better than the first one developed by the Wellington community only.