I hold responsibility for both the asset data and information and the Asset Management activities across an organisation whose portfolio spans more than 50,000 built assets and over 1 million lower-level assets. I do this with a team of 3, myself being one of the three. That means every interaction with systems, assets, data and, most importantly, people is tangible and important.

I’ve written before about the challenges of running a recovery exercise of this volume on an estate this diverse. What I’ve not written much about is the trade-offs we have to make every day to keep the exercise both manageable and dynamic. Introducing ‘trade-offs’ into a programme focused on the improvement and capture of asset data and information may seem odd. It isn’t. It’s critical, and it’s where most published approaches struggle.

Why requirements-led approaches fall apart on an operational estate

I make an effort to not discount the ideas of others; I read the publications, the regulations, the best-practice notes, because there is often genuine benefit in adopting someone else’s approach. But the same framework shows up again and again: requirements first, don’t deviate from the requirements, introduce more requirements, repeat. I’ve over-simplified that on purpose — because now you’re listening.

Requirements have a place and they matter. But they do not have to underpin an asset data and information improvement exercise, least of all one being run on an operationally active estate. An operational estate isn’t static. It evolves, changes and morphs every day, and that drives friction between requirements and reality, one trying to put things into a box, the other wanting to squash the box.

My environment has to be operationally led. Any requirement I write today will, by tomorrow, be subtly different. Not through fault or inexperience, but because the estate is in places centuries old, holds assets in their third or fourth cycle of life and use, and is adapting to a 21st-century regulatory landscape all at once. In my experience, information requirements try to define a ‘thing’ and then, in maturing alongside the organisation, introduce an administrative overhead most organisations simply can’t swallow.

An alternative: Glider’s Asset Intelligence discipline

So why am I writing this? Because for the first time I think there is an alternative; a mediator between the requirements-led and operations-led approaches: Glider Technology Limited’s Asset Intelligence discipline.

Glider define it as a discipline “that ensures the people who are responsible for buildings can find, trust and act on the information they need.”

Like me, most of you are inundated with proposed frameworks, ones that claim to have finally fixed the gap between construction and handover, or that promise your next FM contract will have all the data it needs. And like me, you nod, you read, and you instantly question how it would hold up in the operational real world. What stopped me here was one word: responsible. This talked about the people responsible for the buildings, not the suppliers responsible to a contract. The same thing? No. Most frameworks focus on the relationship between client and provider, construction or FM. Important yes, but they forget the one party that holds ultimate responsibility, the asset owner. That is the party that has to retain, recall, use and, critically, trust information about its assets. That small acknowledgment is what made me want to know more.

The five functions of the discipline

The discipline has five functions; Requirements, Capture, Information Governance, Delivery and Use. Each is a distinct area of focus but holistically connected to the others, so an organisation can mature in one without being held back by another, while never losing sight of the rest.

The recover pathway: built for operational reality

The concept that convinces me it has potential is that it acknowledges two pathways to maturity: recover and create. It’s the recover pathway that, for the first time, tells me someone has considered the operational reality. Glider define it as the “most common starting point because most operational estates were never handed over with structured information”. Bingo! Very few estates, even new ones, begin life with structured, defined, well-governed information. We know this as estate managers. For the first time, I feel like a framework does too.

And this is where it connects back to the discipline I actually practise. The discipline still has a function dedicated to requirements, but it holds it as equal in weight to the others and, combined with the recover pathway, understands that the honest place to start is with what you have, what your immediate gaps are, and a way forward. A subtle change on other frameworks. A significant one in practice.

Asset data recovery as the enabler of Asset Management

Because being able to find, trust and act on the data and information relating to a portfolio is the fundamental enabler of the coordinated activity of an organisation to deliver value from its assets. As an Asset Manager, I believe that is exactly the point, and that this discipline may finally offer the bridge between the competing approaches to data and information and the overarching discipline of Asset Management, by enabling the coordinated activity of an organisation and its supply chain in obtaining, managing and maturing asset data and information.

the narrative

So what are my takwaways;

Q1: What is asset data recovery on an operational estate?

A: Asset data recovery is the systematic process of auditing, capturing, and standardizing physical and operational information from existing, live assets. Unlike traditional approaches that mandate data specifications during design and construction, asset data recovery starts with the estate’s current baseline conditions to make legacy information trustworthy and actionable for facilities and asset management.

Q2: Why do requirements-led data frameworks fail on live estates?

A: Requirements-led frameworks often fail on operational estates because active estates evolve faster than administrative processes can mature. Imposing rigid, greenfield data specifications onto multi-decade or century-old buildings creates unsustainable administrative overhead for lean teams. Successful operational data management requires pragmatic trade-offs rather than theoretical perfection.

Q3: What is the difference between the “Recover” and “Create” data pathways?

A: The “Create” pathway applies to new capital construction and major refits where structured data (such as ISO 19650-compliant models) can be defined and handed over from project inception. The “Recover” pathway applies to existing operational estates handed over with fragmented, unstructured, or missing data, prioritizing immediate operational gaps and risk triage over comprehensive upfront schemas.