Healthcare has no shortage of transformation activity.
Walk into almost any large healthcare organization, and you will find cloud migrations underway, data platforms being modernized, electronic health records (EHRs) being optimized, enterprise applications expanding and AI pilots competing for attention. Each initiative has a business case, an executive sponsor and a team responsible for moving it forward.
But what happens when all of that work has to operate as one system?
A migration may be halfway complete while master data remains unresolved. Two teams may maintain different definitions of the same metric. A new application may depend on another team’s release cycle. Security policies may have evolved faster than the access model supporting them. Several pilots may be solving related problems using different data, architectures and vendors.
From the portfolio level, there is plenty of activity. From the delivery level, much of that activity can be hard to move.
Pilots are unusually forgiving
Organizations start with pilots for good reason. They limit risk and allow teams to test an idea before committing to a broader implementation.
They also create favorable conditions: The scope is narrow, the team is small, data can be curated, access can be negotiated, and a motivated sponsor can intervene when something gets stuck. Engineers and analysts can manually resolve edge cases that would not work at enterprise scale.
A clinical operations pilot might succeed because three analysts prepared the dataset. A member experience use case might work because a team manually resolved identity problems for a limited population. A revenue cycle pilot might perform well because a subject matter expert sits beside the development team and interprets exceptions.
Those results matter, but they leave an important question unanswered: What had to happen behind the scenes to make the pilot work?
That often tells us more about scalability than the demonstration itself.
Production removes many of those accommodations. Data has to arrive reliably. Identity has to resolve consistently. Access has to work without executive intervention. Definitions have to survive outside the original team. Exceptions need an operating process. Someone has to own what was built after the project team moves on.
A promising result becomes less impressive when it requires a small army of people to keep it functioning.
Success at the project level can create complexity at the enterprise level
Most large healthcare organizations have plenty of ideas. The challenge appears when those ideas overlap.
One team builds a patient view while another builds a member view. A third creates a provider model. Finance establishes its own facility hierarchy while operations creates another. Human resources develops workforce reporting while a separate enterprise analytics initiative incorporates much of the same employee data.
Each project can be justified independently, but over time the organization accumulates multiple answers to foundational questions. Which record is authoritative? Which definition should be reused? Who owns the domain? Where should access be enforced? What happens when a source changes? Has another team already built some version of this capability?
People compensate for ambiguity in small environments. They know who to call, remember which field is unreliable, maintain a spreadsheet that reconciles two systems, or add an extra validation step before a report goes to leadership.
Enterprise scale is less forgiving. Eventually, the work exposes every unresolved dependency underneath it.
The people closest to the work usually see it first
Transformation programs tend to create strong visibility upward. Steering committees have status reports. Executives have milestones. Portfolio leaders have investment summaries. Teams report progress through roadmaps, epics, stories and release plans.
The view downward is often weaker.
An analyst knows a supposedly automated report still requires manual reconciliation every Friday. An engineer knows which source system regularly breaks a pipeline. A product owner knows which dependency has moved the release date three times. A security engineer knows why access requests routinely stall. A business user knows a workflow technically launched six months ago and never became part of how the department works.
Individually, those observations can sound tactical. Together, they describe the operating condition of the enterprise.
The portfolio perspective explains where the organization intends to go. The operator perspective reveals what the organization can actually do today.
The distance between those two perspectives is where a great deal of transformation risk lives.
Look at the work required to create the work
One of the simplest places to see that distance is the backlog.
Most organizations measure how much work moves through it. Fewer examine what kind of work is consuming the team’s capacity.
How many stories exist because another system is poorly understood? How much capacity goes toward spikes, enablers, access requests, reconciliation, rework or undocumented dependencies? How often does one team’s delivery depend on another team’s release calendar? How many foundational problems are being solved separately by several initiatives?
This work is easy to dismiss as delivery overhead. At scale, it can become a major part of delivery itself.
An organization may believe it has ten teams building new capabilities while much of their collective effort is spent navigating the environment around those capabilities.
Traditional delivery measures will still show activity. Stories close, ceremonies happen, releases ship and teams demonstrate completed work.
The more useful measure is whether the environment becomes easier to navigate afterward.
A successful transformation should make the next thing easier to deliver.
Consulting should increase the client’s capability
External partners can bring valuable pattern recognition to healthcare transformation. They may have seen the same architecture problem, implementation issue or operating model challenge many times.
That experience matters when it changes the client’s trajectory.
A strong partner recognizes predictable obstacles early, brings examples instead of forcing teams to invent every artifact from scratch, and knows when deeper expertise is required. They challenge an approach when experience suggests it will create problems later.
They also leave capability behind.
A useful engagement might leave a repeatable architecture pattern, a governed data product, a stronger delivery playbook, clearer ownership or an internal team capable of extending what was built.
That creates a simple question leaders can ask throughout an engagement: Are we becoming more capable as this work progresses?
Additional capacity and specialized expertise can be exactly what a program needs. The long-term return appears when the organization can operate, extend and improve the capability without recreating the original project team every time something changes.
The best partnerships plan for that transfer from the beginning.
Some architecture decisions belong at the portfolio level
A workforce analytics program and a clinical operations program may appear unrelated. A member engagement initiative and a revenue cycle program may live in different portfolios. An enterprise reporting project may have its own sponsors, funding and delivery organization.
Underneath them, the same domains keep appearing: patient, member, provider, employee, facility, service line, customer and product.
Those recurring domains offer a clue about what the organization should solve once and make reusable.
This is where the value of a modern data platform extends beyond migration. Moving workloads creates a new technical environment. Creating reusable enterprise capabilities requires decisions around identity, quality, ownership, access, lineage, definitions and stewardship.
Those decisions receive less attention than a new application because their value is distributed across future initiatives. That is also what makes them important.
A governed domain reused across ten initiatives may not produce the same launch-day excitement as a new application, but it can improve the economics and speed of everything built on top of it.
Make the next transformation easier
Healthcare organizations will continue to invest in AI, modern data platforms, enterprise applications and new digital experiences.
The organizations that scale those investments will understand which data domains need attention, where duplicate patterns are developing and which capabilities should become reusable. They will connect strategy more directly to the operators doing the work, examine how much capacity is being consumed by dependencies and rework, expect partners to strengthen internal capability, and look across the portfolio before solving the same foundational problem again.
Most importantly, they will ask whether each transformation leaves the enterprise easier to change.
That is a demanding standard, and also a useful one.
Healthcare has already invested heavily in technology, platforms and transformation. Capturing more value from those investments requires more than adding another consultant, tool or piece of technology. Sometimes it requires subtraction: creating space for internal discovery, talking to the people closest to the work and pressure-testing the plan with a few trusted partners.
What comes out may look surprisingly similar to the original strategy, just with clearer edges and a more trusted map to get there.
Need help with your strategy? Reach out to evolv.
Meghan Schrotenboer is an Industry GTM Principal, Health Care and Life Sciences at evolv Consulting.
