Here's a test you can run on any finance transformation in about an hour. Take the target operating model and list every change it requires. Then, for each change, write down who has to do something differently for it to happen.
In every finance transformation we've seen, the second column is dominated by people who don't work in finance. New approval workflows? That's procurement and every budget holder. Standardised master data? That's sales, operations and IT. A shared services migration? That's HR, works councils and local management. New project controlling? That's every project manager in the company.
Now check the programme's governance chart. If the people in column two appear only as "stakeholders to be informed" — your transformation is already stalled. It just hasn't noticed yet.
Why "finance-led with stakeholder input" fails
The standard setup looks reasonable: finance owns the programme, other functions are consulted, a steering committee keeps everyone aligned. The flaw is structural. Consultation creates opinions. Ownership creates delivery.
A function that was consulted on a design will politely agree in the workshop and then deprioritise the work the moment its own targets compete for the same people. Not out of malice — out of rational behaviour. Their performance is measured on their function's goals, and your transformation isn't one of them.
A transformation stalls at exactly the boundary where ownership ends. Map the ownership, and you've mapped where it will stall.
We learned this leading finance integration alongside integration management offices (IMOs), where the problem is impossible to ignore: an acquisition forces finance, legal, tax, HR and IT to deliver against one deadline, and no amount of "alignment" substitutes for each function owning its workstream. The transformations that landed were the ones where cross-functional ownership was designed in from the start. The insight transfers directly to transformation work — reality is cross-functional, whether the programme chart admits it or not.
The ownership map
Before any design work, we run one exercise with the leadership team. It's uncomfortable in precisely the useful way.
The Ownership Map — four columns, one hour
- Change: every concrete change the target model requires, in plain language. "Procurement approvals move to three-level workflow", not "process harmonisation".
- Who changes behaviour: the function(s) whose daily work is different afterwards.
- Who owns delivery: a named person in that function — not the finance programme lead — with the change in their objectives.
- What they get: the benefit, in that function's terms. If column four is empty, expect column three to quietly stop showing up around month four.
The diagnostic: count the changes where columns two and three point at different functions, or where column three has no name in it. That number is your stall risk — and it's measurable before a euro of programme budget is spent.
What shared ownership looks like in practice
- Co-owned workstreams. Every workstream that changes another function's work is co-led by that function — with their name on the steering slide, including the red statuses.
- Decision rights before design. Agree who decides what — and what happens on disagreement — before the first process workshop. Mapping decision rights mid-conflict is twice as expensive.
- Benefits stated in the owner's currency. Procurement signs up for fewer escalations and faster approvals, not for "finance efficiency". If you can't articulate the change in their terms, you haven't finished designing it.
- A governance forum with teeth. One forum where cross-functional conflicts get decided — not escalated into email purgatory. Its existence changes behaviour more than its meetings do.
One engineering group we worked with had a transformation stuck for over a year at — predictably — the finance/IT/HR boundary. No redesign of the operating model was needed. What unlocked it was the ownership map: three workstreams re-chartered with co-owners, decision rights agreed, benefits restated per function. The blocked decisions cleared within two governance cycles, and the model went live with functions defending the design as their own. Because it was.
Your finance transformation probably does look great. Before you spend the budget, ask the rest of the organisation — formally, in writing, with names in the columns. The answer is cheaper now than in month nine.