The Impact Architect — Issue 8
A few issues back I wrote about the gap between HR data and finance data, the two slightly different versions of the workforce that almost every organisation carries without quite admitting it. I ended that post by saying I was still working out how to turn that into a repeatable diagnostic rather than something I stumble into with clients. So I started working on he way to identify these early and de-risk your activity.
The HR-finance gap was just an example of where these can occur as it is a very common example. The data inside any single function is usually fine, finance can produce a clean trial balance, HR can run a headcount report and operations can tell you throughput by site. Each function builds its data to serve its own needs, and within those walls it mostly holds together.
The trouble starts at the edges.
Anywhere two functions need their data to agree before a decision can be made, you tend to find that it doesn’t and the edges, the joins, are exactly where the most important cross-functional decisions get made. Workforce planning needs HR and finance to agree. Project costing needs finance and delivery to agree. Commercial planning needs sales pipeline and finance forecast to agree. The decision that matters always seems to sit on a seam between two functions, and the seam is the weakest part of the fabric.
What I kept noticing is that programmes get derailed by these seams far more often than by anything inside a single function. A finance transformation doesn’t usually fall over because the GL is wrong. It falls over because the workforce numbers feeding the business case came from a different version of the org than the cost model, and nobody reconciled them until month four. and by then the assumptions are baked in.
So the diagnostic isn’t about auditing data quality function by function. The useful question is where do your functions have to agree, and how confident are you that they actually do?
The five questions I work through
I have ended up with a handful of questions that surface most of the cross-functional data risk in a programme before it has a chance to compound. They are deliberately not technical and you can ask them in a steering group without anyone needing to open a system.
First, where does this decision need two functions to agree? Take whatever the programme is actually trying to enable, a workforce plan, a margin view, an integrated forecast, and trace it back to the data underneath. Almost always it depends on two or more functions producing numbers that need to line up. Document and name those seams clearly. Many programmes may not ask these questions fully, which is why the gap stays invisible and then appears and stalls the progress.
Second, do the two functions even define the thing the same way? This is where it usually unravels. Finance counts a head one way, HR counts it another, and both are right within their own logic. For instance the simple definition of recording a headcount figure or Full Time Equivalent (FTE) was not clear for a past client and also which worker types we had and how they were grouped for financial reporting purposes. Until the definition is shared, connecting the HR needs with the reporting outcomes so they can be agreed across the teams / organisation, then every number downstream inherits the disagreement.
Third, who owns the join? Not who owns the HR data, not who owns the finance data, but who is accountable for the reconciliation between them. In most organisations the honest answer is nobody, or whoever built the last spreadsheet that seemed to work. That spreadsheet usually lives on one person’s desktop and breaks when they move on. If you can’t name the owner of the seam, you’ve found a fragility.
Fourth, can you trace the number back to its source? Pick any figure that goes to leadership, cost per head, attrition, revenue per employee, pipeline coverage, and follow it backwards. If it pulls cleanly from connected systems, good or if somewhere in the chain there is a manual extract that someone stitches together by hand, that’s the point where the number can drift without anyone seeing it happen.
Fifth, what does it cost when the join fails? This one rarely gets quantified and I think it should. The rework, the reconciliation meetings, the decisions made on numbers that didn’t quite add up, the programme time lost to chasing a discrepancy. I’ve not seen many organisations put a real figure on it. The handful that have tried usually find it dwarfs the cost of just fixing the join properly.
Why this works better than a data audit
A full data audit tells you your data is messy. What it doesn’t do is tell you is which bit of the mess is about to cost you and the answer is nearly always the joins, not the contents.
The reason the seam approach is more useful is that it follows the decision rather than the system. It starts from what the business is trying to do and works back to the data that decision depends on, which means you only ever dig into the data that actually matters to an outcome someone cares about. You’re not boiling the ocean. You’re finding the two or three connections that, if they fail, take the programme down with them.
It also forces the cross-functional conversation early, in a room, before go-live. The HR-finance reconciliation problem isn’t hard because the work is hard. It’s hard because it needs two functions who don’t naturally collaborate to agree on something neither finds particularly interesting. Surfacing it as a programme risk, with a named owner, at the start, is a very different thing from discovering it as a reconciliation crisis halfway through.
And it gives you something to say no to. Once you can see which joins are load-bearing, you can also see which ones don’t matter for this decision and can be left alone. That’s often as valuable as knowing where to dig.
Where AI comes into it
I’ll be brief here because I wrote about this last issue, AI makes getting the joins right and more urgent, not less. A model reasoning across functional data will confidently produce an answer whether or not the underlying definitions agree, and a fast, fluent, wrong answer is worse than a slow one you don’t trust. If the seam between two functions is broken, AI will carry the break through at speed and dress it up in something that looks authoritative. The groundwork doesn’t go away because the tooling got cleverer. If anything it matters more.
What I’d do with this
If you’re scoping a transformation right now, before you commit to the business case, I’d run those five questions against the two or three decisions the programme is meant to enable. Name the seams, check the definitions, find the owner of each join, trace the numbers, and have a rough go at what a failure costs. It’s an afternoon’s work, maybe less. It won’t feel like progress in the way that selecting a system or approving a budget feels like progress. But it surfaces the kind of problem that otherwise shows up six months in, when it’s far more expensive to deal with and a lot harder to unpick.
I’m still refining how I frame this, and I suspect the five questions will turn into four or six as I use it more. But the core of it holds: the data inside your functions is rarely the thing that derails you. It’s the bits in between, where everyone assumes someone else is looking.
If any of that is familiar, it’s worth a conversation. No pitch, just a chat about where your joins are and how much confidence you’ve got that they hold.
Neil Alderson is an independent Transformation Director who works with CFOs and senior finance leaders to identify, prepare for, and deliver change across finance, HR, operations, commercial, and data. He writes The Impact Architect on the connections between functions that most organisations overlook.
neilalderson@neilaldersonltd.co.uk · www.neilaldersonltd.com
