Who owns the number after we leave?
Twenty years in health care finance, and here's the pattern I'd bet on: most transformation programs quietly die about a year after the consultants go home.
The analysis was usually fine. The plan was usually fine. What went missing was ownership. Nobody owns the number anymore, and nobody has the authority to adjust when it moves the wrong way.
So this newsletter is about the boring last part, because it's the only part that lasts. The belief I'm working from this month is simple: the result that lasts is the one the client can run without you.
Whether a client can run it comes down to three moments: where the number starts, the day the work goes live, and the day the outside team hands it over. Ownership gets won or lost at each one.
1. Where the number starts
Here's the thing almost nobody admits about consulting engagements. No one wrote down the numbers before anything changed. Everyone was too busy starting.
So you rebuild the baseline from the client's own records, and you say so at the top of the page. "We rebuilt this" buys more trust than any number under it. Better to be believed than impressive.
It matters for more than trust, too. A result can't outlast you if the starting point was yours instead of theirs. When the baseline comes out of their own records, the number belongs to them from the first page. Keeping it theirs is harder, and the first real test comes on go-live day.
2. The day it goes live
Go-live day comes in on time and everyone is relieved.
Eighteen months later the system is faithfully reporting numbers nobody acts on, and someone calls it a technology failure. The technology did what it was built to do. What nobody ever did was decide who owns which number.
I hear the same story when someone tells me performance management is "a finance project." I can usually tell you how that ends. It stalls. Finance can build the dashboard, but it can't make everyone else's decisions for them.
Both stories end the same way. The work got delivered, and the number never got a new owner. Giving it one is what the handover is for.
3. The day you hand it over
A good handover starts long before the last day, with the map you draw at the beginning. The first time I mapped how a state rural health program should run, I drew it around our own work. Configure, build, operate, transfer: the stages an outside team moves through. It looked clean on paper, and it was the wrong map.
A state program runs on functions: governance and decisions, program orchestration, procurement and contracting, grants administration, data and measurement, financial compliance, stakeholder communication. I count ten in all. Those functions were there before any outside team arrived, and they'll be there after it leaves. The stages end and the functions keep going.
So I redrew it. The functions became the structure, and our lifecycle became something that moves across each one until the state's own people run it reliably. That changed what we measure. The question stopped being "is the build done?" and became "can the state run grants administration next year without us in the room?"
In year one, almost all the attention goes to the money: how much, how fast, to whom. The harder question is what's still standing when the money is spent and the contractors are gone.
A good map tells you where the number lives. Somebody still has to know how to run it. For a year, a piece of work in my own practice lived in one person's head. Everyone knew the work got done, and nobody else could have done it. That's the most common shape of institutional knowledge I run into, in client organizations and, if I'm honest, in my own shop.
Everyone assumed the fix was documentation. Write it down, hand it over. The trouble is that written procedures get filed. What worked was simpler and harder. The person who held it sat down with the person who'd inherit it and ran the procedure once, live, with the inheritor watching and asking the questions that only get asked the first time. The document got written during the run.
A week later the inheritor ran it alone, and it worked.
That's what capability transfer actually looks like, and it looks nothing like the slide that promises it. One person does the work in front of another until the second can do it without the first, and then the first person leaves the room. If it works with the holder out of the room, it transferred. If it doesn't, you know exactly which line of the procedure to fix.
That's how a number gets a new owner. Handing work over is half of it. The other half is making sure somebody keeps steering once it's handed over. I think about that as five moves that run in sequence, every cycle, and I call it the Accountability Loop:
- Prioritize. Name the few things that actually matter this period, so the work isn't forty equal items competing for the same attention.
- Resource. Put the people, the money and the time against those priorities, out loud, so the gap between ambition and capacity is visible before it bites.
- Execute. Do the work, with a named owner on each priority who knows it's theirs.
- Measure. Track the few numbers that tell you whether the priorities are moving. The forty that just describe the situation can wait.
- Adjust. Change something based on what you measured.
Prioritize, resource and execute are the steps everyone runs. Measure and adjust are the steps that get skipped, and they're the only reason a result lasts. Adjust is the one almost everyone drops, and it's what turns the whole thing into a loop. Without it, you've drawn a straight line that ends in a report.
I've watched good teams miss the same number three quarters running, and every time the conversation lands on who's responsible. Responsibility was never the problem. The work wasn't running inside anything that turned a missed number into a named change. So the number slipped, somebody felt bad, and nothing moved.
We tend to treat accountability like a character trait. I'd rather build it as a structure. When the loop closes, a measured number has to be followed by a change, and a discussion or a deck doesn't count as one. Run it four times a year and accountability stops depending on who happens to be brave in the room.
The uncomfortable part is that you can't tell in a pitch which teams will run those last two steps. Everybody says they will. The tell is earlier and smaller: whether people will do work with no visible credit attached. Someone once asked me why a transformation team spent a morning packing food boxes when the program had deadlines. That's my answer. A warehouse morning has no credit attached and nobody's utilization improves, which is exactly why I watch for it.
I call it the warehouse test, and you can run it on any team you're about to hire, including mine. Three questions, in writing, before you sign:
- Name it. Who owns each measure after you leave? It has to be a person, because a function can't own anything.
- Date it. When is the first review after handover, and who convenes it?
- Move it. What happens the day a measure moves the wrong way? If the answer is "we'd discuss it," there's no move.
If the contract has no name, no date and no move, you bought a plan. The impact was never in it.
Those are the same three moments from the top. Start from a number the client recognizes, give it an owner before go-live, and hand it over live with a loop that keeps running. Then you can leave the room and the number still has an owner.
Think about your last big project. Who owns its number today, and do they know it?
James