The Partner Test

Years ago I sat in a run of enterprise reporting meetings at a large academic health system, where several teams were working to roll their reporting into one enterprise package. Each team had a sound methodology and data it trusted, and each was correct inside its own context. The trouble was that the definitions underneath did not mean the same thing from one team to the next, so no enterprise number could be fully trusted. It looked like a reporting problem. In truth it was a governance problem.

That experience is the lens I still use when I size up an AI partner. What we never solved was shared definitions and clear ownership of the data beneath the tools. Tools come and go. The structures that decide how people understand and own that data tend to outlast all of them, which is why the partner a system chooses matters more than the model it buys.

Early on, I was asked to evaluate a population health platform while my own team was deep in an implementation that was already struggling. Our problem was the familiar one: the data sat in siloed sources that needed heavy integration and curation before any platform could deliver anything. The representatives were sure they could stand up a full data warehouse and deliver value across every source inside six months.

So I asked where they had built this before. They had not. I asked which electronic health records they had ingested. The answer was zero. After a few of these answers it was clear they were describing a build they had never done. They did not understand how our organization actually worked, and they assumed they were more capable than the team of experts who had already shipped this kind of build many times.

The part that decided it came in writing. My leadership needed a full assessment from me, which meant I needed a formal proposal from the vendor. I told them plainly not to claim six months. They put six months in the proposal anyway. It also carried a heavy price, and it still assumed my own team would supply dedicated people on top of what they were charging, to deliver something that was not realistic in eighteen months, let alone six. At that point I stopped weighing the timeline and started weighing the judgment behind it.

In my assessment to leadership, I set their six-month claim against something I had lived. Years earlier, we had combined three mature, well-built data warehouses into one consolidated platform, and even from that starting point it took eighteen months before the insights could be trusted. We were nowhere near that maturity, and a vendor with no relevant builds was promising the whole thing in six. The contract was not signed. My team kept building the foundation, and over time it carried the analytics our population health programs needed.

Every firm sells AI help now, and the decks have converged on the same language. When three proposals promise the same outcome in the same words, a buyer is left judging firms largely on reputation.

What I have seen on the floor, again and again, is that the model rarely fails on its own. The failure is usually about ownership: who owns the work, and who is left holding it when the engagement ends.

The clearest version I lived through came in the early days of COVID-19, when health systems suddenly needed real-time visibility into bed capacity and patient movement. We found that something as simple as an available bed meant different things in different facilities. In one place it meant a physical bed; in another, a staffed bed ready for a patient. Before any analytics could help, we had to agree on what the words meant and who owned them. Getting that right gave the organization a clear view of its real capacity during a surge in admissions, when leaders had to decide where to route emergency cases and where to flex staffing.

Since then, I pay attention to the first questions a partner asks. The ones worth hiring ask about definitions and ownership before they say a word about technology. When a firm opens with the model and assumes everything beneath it is already understood, it has skipped the part that decides whether the work holds.

Independence belongs on the same list. An advisor paid the same whether you buy a tool or walk away can afford to tell you the truth about it. That kind of honesty is rare, because most of the market still earns on the sale.

One of the first systems I ever built was a simple database application in a hospital back office. The team was tracking discrepancies with sticky notes and manual workarounds, and nobody liked the process. It was nothing fancy. What made it work was that it matched how people actually did the job, so it surfaced problems earlier and gave people back time.

None of that had much to do with software. It came from understanding the job before building the tool, and twenty-five years later that is still what I look for in a partner. Firms worth hiring spend more time learning how the work happens than describing the technology they want to install. If a partner does not understand how the work happens and how the data is produced, the technology is largely beside the point.

Forget the scorecards. The signal I have come to trust most is whether a partner can name a health system where the work went live and stayed live, then hand you the phone. Plenty of projects go live. Far fewer are still being used and trusted a year later, and that is the measure I pay the most attention to.

Fit to size is the other quiet test. A program built for a large multi-hospital system can drown a small one, and a partner who brings the same operating model everywhere has not looked closely at anyone. It rarely wins the pitch, and it often decides whether the work outlives the contract.

Looking back, none of these decisions turned on the technology. Each came down to judgment: whether the people in front of me understood the work and the data, and whether they would be honest about what it would take. I built Hutchins Data Strategy Consultants around two questions: whether we understand the data beneath the work, and whether your team can run what we build after we leave. Those are the same questions I would put to any partner, including us.

This edition is drawn from my own experience across health systems. Related editions: Issue 43 (The Chief AI Officer Mandate) and Issue 45 (The Procurement Trap).