I spent part of this year auditing the quality of public transportation data across a large metropolitan region. The work sounds dull and it taught me more about digital transformation than any strategy document I have read.
Here's the finding that reorganized my thinking. The gaps weren't where capability was thin. Some of the largest and best-resourced agencies in the region had feeds that were missing, stale, or malformed. These are organizations with real technology budgets and competent staff. They had the systems. What was failing was registration and validation: the unglamorous work of confirming that the data is actually published, actually current, and actually correct.
That's the shape of most transformation failure I have seen since, in government and out of it. The technology arrives on schedule. The last mile, where the thing has to be true rather than merely deployed, doesn't have an owner.
Deployed is not the same as working
Every IT leader knows the difference in principle. In practice, the reporting structure quietly conflates them, because "deployed" is easy to measure and "working" isn't.
A project plan has a go-live date. It rarely has a date for when the previous process actually stops, or when the last team that was working around the old system moves over, or when someone checks that the data flowing out the other end is right. Those are the expensive parts and they happen after the milestone everybody celebrates.
The failure mode is quiet, which is what makes it dangerous. A stale data feed doesn't throw an alarm. It serves plausible, wrong information indefinitely, and the only people who notice are the ones downstream who can't do anything about it. In the transit case, a rider who checks an app, sees no useful information, and stays home generates no complaint and no ticket. The service looks fine because the failure is silent.
Ask yourself which of your systems fail that way. Most organizations have several and can name none of them.
The three questions I would put on every transformation
Who owns the output, not the system? Owning a platform means keeping it up. Owning an output means being accountable for whether it's correct. Those are usually different people and frequently the second role does not exist. If nobody's name is next to "this data is right," the answer is that it's not, you just have not found out yet.
What breaks silently, and how would we know? For every integration, write down what a failure looks like from the outside. If the answer is "it would look normal," you need a check that runs on a schedule and complains. This is boring work and it catches the class of problem that costs the most, because silent failures accumulate for months before anyone investigates.
What are people still doing by hand? The workarounds are the truth about your transformation. A team maintaining a parallel spreadsheet is telling you precisely which requirement you missed, in more detail than any survey would produce. Nobody keeps a shadow system for fun. Go find those and read them as a bug report, not as a compliance problem.
Why the org chart matters more than the architecture
The reason the well-resourced agencies had bad feeds isn't mysterious once you look at it. Publishing the feed sat with one team. Validating it sat with nobody. The people who cared most about the feed being correct were outside the organization entirely, and had no channel to report a problem that anyone was obligated to act on.
You can buy any technology. You cannot buy a line of accountability, and the transformation projects I've watched succeed were the ones where somebody drew that line before the procurement started rather than after the launch.
This is also why "we hired a vendor" is a partial answer at best. A vendor can deliver a system. A vendor can't be accountable for whether your organization uses it, because that requires authority over people the vendor doesn't employ. When a program is failing and the discussion is about vendor performance, the discussion is usually in the wrong place.
The measure I would use instead
Most transformation dashboards count deployment: systems migrated, users onboarded, modules live. Those numbers only go up, which should be suspicious on its own.
A better measure is how much of the old way is still running. Count the parallel spreadsheets, the manual reconciliations, the exception processes, the emails that exist because a workflow doesn't. That number starts high and comes down slowly and it is much harder to make look good, which is exactly why it's worth tracking. It reflects whether anything actually changed.
Pair it with something like freshness. For every data product you publish, when was it last validated by someone who would notice if it were wrong? If the honest answer for most of them is "at launch," you haven't finished a transformation. You have finished an installation, and those aren't the same thing, however similar they look at the ribbon-cutting.
The part that is genuinely hard
I want to be fair to the people running these programs, because the incentives are ugly. Deployment is legible to a board. Validation is not. You get credit for the launch and no credit for the check that quietly prevented a problem nobody experienced.
Changing that starts with making silent failures visible when they happen rather than when they become a crisis. A monthly report of what broke without anyone noticing is an uncomfortable document to circulate and the single most useful one I know for shifting an organization's attention from launching things to running them.