This article was originally published on HISTalk.
Most healthcare IT projects start strong. The business case is approved, leadership is aligned, and the team has spent months preparing. By kickoff, most organizations have already done a lot right. Then at some point, things get harder. Not because something went wrong, but rather that complexity doesn’t fully reveal itself until the work is underway.
Plans that looked solid on paper meet the realities of organizational dynamics, legacy environments, and stakeholder expectations. The project enters a phase that requires a different kind of leadership.
The teams that navigate this well aren’t necessarily the best-resourced. They are the ones that recognize the pattern early. Across decades of healthcare IT programs from rural hospitals to large-scale systems, the same four pressure points appear in nearly every one, and knowing that they are coming makes all the difference.
Governance gets significant attention before projects launch and not nearly enough once the work gets difficult.
Early project decisions are broad and relatively straightforward. As execution progresses, decisions become narrower, more consequential, and more politically charged. They touch specific departments, workflows, and financial processes in ways that weren’t visible during planning.
Without clearly defined decision rights, those decisions accumulate. Issues wait for meetings. Meetings generate more meetings. Teams search for consensus that isn’t forthcoming, and momentum quietly erodes.
These questions are worth answering before kickoff. Who owns decisions at each level of the organization? What is the escalation path when groups disagree? What does conflict resolution look like when the stakes are high and timelines are tight?
The governance structure that works in the planning phase is rarely the same one that can handle the decision volume and pressure of the final stretch before go-live. Build it for where the project is going, not where it starts.
Reporting is the most consistently under-planned element of large healthcare IT projects, and the pattern is almost always the same.
Teams devote the bulk of the timeline to design, build, and configuration. Reporting is treated as downstream, something to address once the system is taking shape and understood. By the time it receives serious attention, timelines are compressed and the team is already managing pressure on a dozen other fronts.
What surfaces at that point is a backlog that should have been scoped months earlier. This includes operational reports that are needed on day one, leadership dashboards, financial outputs, compliance requirements, and data extracts for external stakeholders. Each item that wasn’t resourced in advance becomes urgent. The volume is rarely the surprise, it’s how much of it existed all along and simply wasn’t documented.
The organizations that handle this well conduct a formal reporting needs assessment early, catalog what is actually used versus what is merely printed, and staff a dedicated reporting work stream with the same rigor that is applied to any other major project component. AI-assisted analytics tools are making this more manageable, reducing custom build volume by improving access to standard data, but they work best when a strategy is already in place. The strategy still has to come first.
Integration is consistently undersized, underestimated, and under-resourced, even on well-run projects.
What looks manageable on paper is often years of organically grown connections, undocumented workarounds, and custom configurations that no one has reviewed since they were originally built. The team running those integration engines is typically small, highly specialized, and expected to support both existing operations and new project build simultaneously against a fixed deadline.
A few principles that hold across programs of every size. Document the current environment thoroughly before the project begins, not during. Organizations with more than 15 active integration points should staff a dedicated project manager for that work stream alone since the lead PM cannot effectively absorb that complexity as a secondary responsibility. The rebuild timeline needs to reflect reality since what took years to develop organically often must be reconstructed in 12 to 16 months within a structured project framework.
Teams that treat integration as its own parallel program, with dedicated ownership, its own milestone structure, and clear accountability, are the ones that aren’t scrambling at the finish line.
Stakeholders almost universally want historical data carried forward. That instinct is reasonable. It is also, in many cases, not well matched to how that data is actually used after go-live.
Access to legacy data tends to drop significantly in the weeks following cutover. The new environment rapidly becomes the operational source of truth. Data that required months of extraction, mapping, and validation is referenced far less frequently than the migration effort might suggest.
Ask questions early, even when they are uncomfortable. What regulatory requirements mandate having this data in the new system? What will it cost in time and effort to map and validate it properly? Are there alternative access approaches, such as archival repositories, that meet the operational and compliance need at a fraction of the effort?
The organizations that make these determinations deliberately, and with honest input from the people who will actually use the data, avoid the scope and timeline pressure that tends to surface when these decisions are deferred.
The projects that maintain momentum aren’t the ones that avoid difficulty. They’re the ones that anticipate where pressure tends to build and address it before it compounds.
Governance, reporting, integration, and data decisions will surface as challenges in virtually every large healthcare IT initiative. They aren’t signs that something has gone wrong. They are the work. The difference is whether the organization is ready for them.