The 7 Deadly Sins of Asset Data Capture

Last month I presented at a Facility Management Association event on the 7 deadly sins of asset data capture.

Look, this stuff isn’t complicated. You might read these and think it’s obvious stuff, and you’d be right. But organisations keep f#&king it up anyway, every single week, at massive cost.

So let’s talk about the seven failures that kill asset data projects.

#1. Lust – Infatuated With The Wrong Strategy

Most organisations get asset data wrong before they even start.

They’re copying someone else’s audit specification (probably from six years ago and completely unfit for their specific needs), or they’ve fallen in love with a data structure that looks impressive but serves no actual purpose in their business.

You end up wanting certain asset data because it looks comprehensive (not because it serves your strategy), your data hierarchies can’t integrate with your CMMS (because nobody checked if they’d play nice together), and finance needs to report one way while operations maintains assets another way while engineering is capturing information that neither group will ever use.

It’s a square peg, round hole situation.

And it happens more often than you’d think because consultants roll out the same specification they’ve been using for years without questioning whether it actually fits your organisation.

Look, I’ve seen this play out dozens of times.

The number one thing anyone should be thinking about when planning a data capture project is this: what are we actually trying to achieve? What decisions do we need to make? What systems need to talk to each other (CMMS, finance systems, asset management plans)?

If you can’t answer those questions clearly, you’re not ready to write a specification.

Work backwards from your goals, then build your data requirements around them, because the alternative is spending months capturing data that doesn’t serve any real purpose in your organisation and ending up with an asset register that looks slick but can’t actually support the decisions you need to make.

#2. Greed – Mo’ Data = Mo’ Problems

Clients get infatuated by capturing everything – more data, more carpet types, more GPOs, more light fixtures (even that projector up there), they just love it.

And I get it… When you’re investing in an audit there’s this temptation to capture everything while you’ve got auditors on site. But here’s what they don’t realise: the more information you capture, the less attention you can give to the critical stuff (condition assessments, technical data that drives decisions), which means your auditors are spread thin and rushing through important work because they’re too busy counting ceiling tiles.

It carries a greater cost. And when you’re capturing more fields without increasing budget (which is often the case), quality drops across the board, and as quality erodes, so does trust in the entire dataset.

Most organisations audit every 5-7 years (aka a bloody long time to be stuck with crappy data).

If you’ve built a massive dataset that costs a fortune to maintain, you’re either going to let it decay between audits (defeating the entire purpose) or you’re going to spend the same huge amount again next cycle.

Neither option is great. What ends up happening is your comprehensive register becomes progressively less accurate until nobody trusts it anymore and operations is maintaining their own parallel system in Excel.

The solution is to think critically about what you actually need to capture – what drives your maintenance decisions, what informs your capex planning (not what looks good in a presentation).

Focus on that. Leave the rest alone.

#3. Sloth – There Is A Real Cost To Slow QA

This one’s about timing.

And it kills more projects than people realise.

You’ve put all the effort into scoping a project, getting budget approval, engaging stakeholders, but then you don’t check the data properly until it’s too late to fix problems easily.

Missed assets get discovered after ingestion (when the auditors are already three states away), wholesale quality alignment issues surface months after delivery, and strategic data structure problems take years to resolve because nobody caught them early (and by then it’s expensive to fix and politically awkward to admit).

I’ve seen organisations discover fundamental problems six months after a project wraps up 😬 

By that point their options are either live with subpar data for years or spend a fortune retrospectively fixing issues that should have been caught during capture.

The best time to fix a problem is when it’s captured.

Not weeks or months later when the project team has moved on and the context is lost.

Proper gating means regular check-ins with the project team, data going into your CMMS during UAT (not after everything’s finished and signed off), and fixing problems where you can fix them easily because once the team has left site you won’t be able to go back and do it again easily and it’s another three to five years before you get this opportunity again (see: bloody long time).

Fight the problems early. Not the symptoms later.

#4. Wrath – Fighting Symptoms, Not Causes

People get angry at their data.

Fair enough, it’s probably letting them down.

They get angry at the outputs their systems produce, and they try to fix symptoms by building elaborate spreadsheet workarounds, but they never fix the systems that created the problem in the first place.

Your CMMS isn’t producing the outputs you need to make informed decisions?

That’s a system problem, not a data problem.

Your asset register gets more brittle as you add data rather than more robust (which is the opposite of what should happen)? That’s a structural problem that spreadsheets won’t solve.

What happens is you end up with professional-looking reports that can’t support actual operational decisions, and operations maintains parallel systems because they don’t trust what’s in the official register, and everyone’s spending time reconciling data between systems instead of actually managing assets.

I’ve watched organisations spend years building increasingly complex workarounds instead of stepping back and fixing the underlying issue.

The solution is to define what results you need, then look at the systems you’re using and where the data’s going (not just where it’s been captured).

Step away from what you’ve got. Honestly assess whether it’s fit for purpose.

Because if your systems can’t produce the outputs you need, no amount of data manipulation is going to fix that and you’re just building workarounds on top of workarounds (and that becomes your permanent way of operating).

The workarounds become institutionalised, new staff learn to work around the system rather than with it, and you’re spending money every year maintaining dysfunction instead of investing once to fix the underlying cause.

#5. Gluttony – More Technology Will Fix Everything

Everyone’s hot on AI right now.

And to be fair, some of it is genuinely impressive.

There are technologies emerging that make data capture faster and more cost effective, and we’re working on plenty of them ourselves, but technology won’t fix fundamentally broken datasets.

If you don’t have solid foundations, AI just processes your bad data faster (garbage in, garbage out).

Predictive maintenance doesn’t work if it’s built on incomparable condition data. Smart building systems are useless if they’re fed garbage data (doesn’t matter how smart the system is). And advanced analytics will give you confident-looking insights based on rubbish inputs.

You end up with impressive dashboards and sophisticated predictions that nobody trusts because the underlying data is dodgy, and the technology just gave you a more expensive way to make the same bad decisions you were making before.

Look, I’m excited about what AI can do for asset data capture – we’ve invested heavily in building these capabilities. But the whole point is to build solid foundations first, then add technology second.

Technology should enable better quality data capture and make good data more powerful, but it can’t compensate for not having quality data in the first place (that’s putting the cart before the horse).

It just exacerbates the problem by pushing it further down the road.

The AI will confidently tell you which assets need replacing based on condition data that was inconsistently assessed, or your predictive maintenance model will schedule work based on failure patterns it’s extrapolated from incomplete asset histories, and you won’t realise the recommendations are wrong until assets fail unexpectedly or you’re doing unnecessary maintenance on equipment that’s actually fine.

#6. Envy – Wishing For Someone Else’s Capabilities

You see what leading FM teams are achieving with their data.

Predictive maintenance, smart decision-making, clear ROI.

You want those same capabilities, but you’re not willing to do the foundational work that makes it possible.

So you compromise on scope based on budget (we’ll just enhance it next cycle, right?), you prioritise cost over requirements, and you’re trying to build advanced capabilities without investing in the foundations when this is a three to five year cycle we’re talking about (that’s a long time to be stuck with inadequate data because you compromised now).

What you don’t see is that those leading organisations invested properly when they had their window, they engaged stakeholders across finance and operations and engineering, they thought critically about what data they needed and built systems that could actually support their decision-making processes.

I get it – nobody wants to tell their CFO they need to spend more on an audit.

But here’s what happens when you compromise: you miss your opportunity to build AI-ready foundations (when it actually matters), you spend the next several years wishing you’d invested properly when you had the chance, and meanwhile the organisations you’re envious of are making data-driven decisions because they did the work themselves and set up for the future (not because they got lucky or had bigger budgets necessarily).

You end up in this cycle of always planning to enhance things next time but never quite getting there because you’re too busy dealing with the limitations of what you built on the cheap last time.

Don’t do it just to tick a box.

Take the time, engage stakeholders properly, and build something that will actually serve you because this is your window to get it right and you won’t get another chance for years.

#7. Pride – Pretending It All Works

This is the one people struggle with most.

Because it requires admitting uncomfortable truths.

You’ve been working with a dataset for years, maybe you even commissioned the last audit, and now you’re supposed to admit it’s not fit for purpose?

That’s uncomfortable, especially if you’ve been building your professional reputation on the assumption that your systems are working well.

So you keep building elaborate spreadsheet workarounds instead of fixing the foundation (even though everyone knows the workarounds are how things actually get done), you keep relying on familiar dysfunction because it’s easier than admitting there’s a problem, and previous teams have either been working with datasets that weren’t fit for purpose or they’ve been pretending everything’s fine when it clearly isn’t.

Everyone knows you’re really relying on gut feel and tribal knowledge with the official data as window dressing.

Look, I’ve been in enough boardrooms to know how hard this conversation is. But you need to look inwardly at what you’ve got.

Be honest with yourself. Are your systems up to scratch? Are you happy with the data? Are you making decisions based on the data or based on gut feel with the data as window dressing (because there’s a big difference)?

If you can’t confidently say your data supports real decision-making, then you’re not ready for AI and advanced technology and you need to fix the foundations first.

Having a forward plan means being honest about where you are now and what you need to be ready for the technologies coming to market (which are coming whether you’re ready or not).

It means stopping the workarounds and investing in getting it right.

Because you can’t fix what you won’t acknowledge is broken, and the longer you maintain the fiction that everything’s fine, the more expensive and politically difficult it becomes to actually address the underlying problems.

Psst… Maybe We Can Help?

Look, asset data capture isn’t something you do every year.

Most organisations get one shot at this every 5-7 years. That’s a long time to be stuck with the consequences of getting it wrong.

We’ve spent the last decade working on asset data capture across government, education, defence and aged care. We’ve seen what works and what doesn’t. More importantly, we’ve seen the patterns that lead to success and the ones that lead to expensive failures.

If you’re planning an audit, or if you’re stuck with data that isn’t serving you, let’s talk. We’ll help you work backwards from what you actually need to achieve, not just roll out the same specification we used for the last client. Get in touch with Kairos – because your next audit cycle is too long to get this wrong.