Getting 5,200 Users Live Across Three Countries in Two Years
Some programs have a clear finish line.
This one had been running since 2014.
When I joined Weill Cornell Medicine in 2022, the SAP SuccessFactors and ADP eTime implementation was already years in the making. My job was to take a program that had been moving slowly through one of the most complex healthcare and academic environments in the world and get it across the finish line.
Two years later: 48 departments, 5,200 users, three countries, one system that actually worked.
Here's what it took.
The Starting Point: Legacy Systems Holding Things Together
The legacy system did what legacy systems do: held things together through workarounds, manual processes, and knowledge that lived in people's heads instead of the system.
Time and attendance tracking wasn't connected to HR records. Payroll data required manual reconciliation. Employee master data in SAP SuccessFactors and timesheet data in ADP weren't talking reliably.
For a medical school, a hospital, and research labs across three countries, disconnection wasn't just inefficient. It was risky.
The cost:
Payroll errors
Compliance exposure
Hours of manual work every pay cycle that should have been automated
The goal was straightforward: Sync SAP SuccessFactors Employee Central data into ADP eTime. Send timesheet data back for payroll. Eliminate the manual reconciliation layer.
The execution was anything but straightforward.
Challenge 1: Three Countries, Three Different Realities
The implementation spanned the United States, Qatar, and Tanzania.
On paper: a configuration challenge.
In practice: three separate programs running in parallel, each with its own requirements, each capable of breaking the others if synchronization wasn't managed carefully.
The US ran on hospital schedules, academic calendars, and research lab rotations.
Qatar had different compliance requirements, different currency handling, and a timezone that meant any development decision made in New York landed in Doha at the end of the working day.
Tanzania added regional configuration, local requirements, and shift structures that didn't map cleanly to standard templates.
Every development cycle had to account for all three simultaneously.
How we solved it:
We structured standups so no region made decisions in isolation. Configuration changes were reviewed against all regional requirements before moving to build. Currency handling, compliance rules, and access configurations were mapped upfront and maintained as living documentation.
When a change worked in New York, we didn't assume it worked everywhere. We verified it against every regional configuration before moving forward.
Yes, that added time upfront. It prevented rollbacks that would have cost weeks.
The CIO, CTO, and senior directors across all three regions got regular performance updates reflecting the full picture, not just headlines from the primary site. When a regional issue surfaced, they heard it from me before discovering it themselves. That visibility built trust. And in a multi-region program, trust is what keeps decisions moving when bureaucracy wants them to slow down.
Challenge 2: The Shift Alignment Problem Nobody Had Solved
Hospitals don't run on standard schedules.
We had employees across clinical, administrative, research, and academic functions. Different shift patterns. Different hour structures. Different rules for how time was tracked and fed into payroll.
Non-standard shifts were the single biggest source of data misalignment in the legacy system. Hours were wrong. Shift assignments didn't match reality. And because the data was wrong at the source, everything downstream was wrong.
Payroll reconciliation was a manual exercise every cycle. Nobody had solved it because nobody had gone department by department to verify what was actually happening on the ground.
We did.
The process (repeated 48 times):
Map with HR: Every department in scope
Identify with HR analysts: Actual users in each department
Validate with directors: Confirm users and profiles (because what HR recorded and what the department actually ran were frequently different)
Finalize with HR: Resource names, access types, profiles based on requisition IDs and payroll records
Align shifts with analysts: Identify missing alignments and incorrect hours
Confirm with directors: Actual shifts their teams were working
Finalize with HR director: Resources, departments, access levels, champion users per cohort
Prepare with training: Current materials tailored to each department's specific workflows before go-live
48 departments. 500-600 users per cohort. Twelve interconnected workstreams per cohort.
Each one dependent on the last. Each one requiring a different conversation with a different stakeholder who had a different version of the truth.
This is what 5,200 users going live actually looks like before it becomes a number.
The technology was never the hard part. This was.
Challenge 3: Making Go-Live the Beginning, Not the End
Most implementations celebrate go-live and move on.
We treated it as the beginning.
Before each go-live, we identified champions and super users inside each department. People who understood how their team actually worked, not just how the system was configured. We trained them first and in depth so they could support colleagues without waiting for helpdesk tickets.
Goal: Every department can help itself.
But we didn't stop there.
We attached dedicated training support resources to every go-live. Their job wasn't just answering questions. It was tracking every request, issue, and ticket from the newly live department and categorizing it:
What was a training gap?
What was a configuration issue?
What was a process misunderstanding the training materials didn't address clearly?
That data fed directly back into the program.
Issues that appeared repeatedly in one cohort became agenda items before the next cohort went live. Training materials were updated in real time based on what tickets revealed. The support model for cohort five was sharper than cohort one because we had four rounds of real feedback built in.
By the later cohorts, the process was tight. Issues that confused early departments were caught and eliminated before they could surface again. Champions were more confident. Tickets were fewer. Go-lives were cleaner.
The program got faster and more precise as it went, not slower.
That's what a feedback loop built into delivery looks like. Not a retrospective at the end. A continuous improvement cycle running alongside every deployment.
The Real Hard Part: Operating in Bureaucracy
Here's the honest part.
The integration architecture was solvable. SAP Cloud Platform Integration syncing Employee Central to ADP eTime, timesheet data flowing back for payroll, that's a known problem with known solutions.
The hard part was resource finalization in a heavily bureaucratic environment.
As a project manager, you can't:
Force a department director to confirm their user list by Thursday
Compel HR to resolve a payroll profile discrepancy by end of week
Make a regional office prioritize your configuration review when their own operational pressures are mounting
What you can do is navigate.
That means:
Knowing which conversations to have and in what order
Knowing when to escalate and when to solve it yourself
Knowing how to make it easy for the right person to say yes without making them feel pushed
It means building relationships with department directors before you need something from them. Making the HR team feel like partners in the deployment, not a dependency in your project plan. Keeping the CIO and CTO informed consistently enough that when you do need an executive decision, the context is already there.
In a heavily matrixed, bureaucratic organization, the project manager who finishes isn't always the most technically skilled.
It's the one who knows how to move people.
What a 10-Year Program Taught Me About Finishing
Long-running programs develop their own gravity.
They accumulate decisions nobody remembers making. Workarounds that became permanent. Stakeholders who learned to live with the current state because change feels harder than tolerance.
Getting across the finish line isn't about momentum.
It's about discipline.
Discipline in data validation before it enters the system
Discipline in cohort structure so the next one benefits from the last
Discipline in upward communication so leadership always knows where things stand
Discipline in navigating bureaucracy without becoming part of it
The implementation completed in two years. 48 departments. 5,200 users. Three countries. One system that finally worked the way it was supposed to.
The technology made it possible.
The process, people management, feedback loops, and navigation made it happen.
One Question to Sit With
If you're leading a long-running implementation that's been in flight longer than expected, ask yourself honestly:
Is the program moving slowly because the problem is hard, or because nobody has built the structure and relationships needed to finish it?
Those are two very different problems requiring two very different solutions.
Originally published on my portfolio at asifsheraz.com/writing/how-to-finish-enterprise-implementation
I write about enterprise program delivery, governance at scale, and how to finish what you start. Read more on my portfolio at asifsheraz.com/writing.
