DEV Community: Asif Sheraz

How to Audit a Program in Trouble

Asif Sheraz — Wed, 17 Jun 2026 20:16:46 +0000

The Questions Every PMO Should Ask Before Fixing Anything

Most troubled programs don't fail because people stop working.

They fail because leadership loses visibility.

Status reports stay green while milestones slip. Teams stay busy while delivery slows. Meetings continue while decisions stall. Everyone can feel something is wrong, but nobody can clearly explain what.

Over the years, I've been asked to step into programs across healthcare, government, higher education, and enterprise environments when delivery confidence had already begun to erode.

The first mistake most organizations make is jumping straight to solutions.

New governance. New tools. New reporting. New consultants.

Before you fix anything, you need to understand what is actually broken.

The goal of an audit is not to assign blame. The goal is to establish reality.

Question 1: What Problem Is This Program Actually Solving?

It sounds obvious. Usually it isn't.

Ask ten stakeholders why the program exists. If you get ten different answers, you've found a major risk.

Ask:

What business outcome is this program supposed to achieve?
How will leadership know it succeeded?
What metrics define success?
Has the objective changed since the program started?
Is everyone still solving the same problem?

When objectives drift, teams continue delivering work while moving further away from value.

That's how you end up with a program that's "complete" but doesn't matter.

Question 2: Who Actually Owns Decisions?

Many struggling programs have plenty of accountability and very little ownership.

There's a difference. Accountability is retrospective. Ownership is active. One explains what went wrong. The other prevents it.

Ask:

Who approves scope changes?
Who owns prioritization?
Who can remove organizational blockers?
What decisions are currently waiting for approval?
How long does a typical approval take?

Decision velocity is one of the fastest indicators of program health.

If decisions routinely take weeks, delivery eventually slows to match. Not because the team is slower. Because they're waiting.

Question 3: Can Anyone Explain the Critical Path?

Every major program has a handful of activities that determine success.

Most teams cannot clearly articulate them.

Ask:

What milestones absolutely cannot move?
Which dependencies threaten delivery?
What activities sit on the critical path?
What happens if a milestone slips 30 days?
Which risks would cause the greatest disruption?

If nobody can answer these confidently, the program may be operating without a true delivery strategy. You're probably watching activity instead of managing progress.

Question 4: Are Teams Delivering or Just Staying Busy?

Activity is not progress.

A full calendar is not health.

Ask:

What was completed in the last 30 days?
What business value was created?
What commitments were missed?
Why were they missed?
What is preventing faster execution?

When teams cannot connect effort to outcomes, productivity becomes an illusion. People are busy. Nothing moves.

Question 5: Is Governance Creating Clarity or Creating Noise?

Governance should accelerate decisions. Most organizations build governance structures that slow everything down.

Ask:

How many status reports are being produced?
Who actually reads them?
How many governance meetings exist?
Which meetings result in decisions?
Which reports influence action?

A common pattern in troubled programs: excessive reporting combined with declining visibility.

ProgramManagement #PMOGovernance #EnterpriseDelivery #ProgramDiagnosis #ProgramRecovery

Controlling Scope Creep at Scale

Asif Sheraz — Wed, 17 Jun 2026 20:10:42 +0000

How a 67-County Government Program Controlled 95% of Scope Creep Before It Hit the Team

Scope creep doesn't announce itself.

It shows up as a reasonable request from a reasonable person at a reasonable time. And then it happens again, and again.

Until the timeline is broken, the budget is stretched, and the team that started the program barely resembles the one trying to finish it.

I've watched this happen to good programs run by capable people.

Then I led a statewide program supporting 67 counties and over 6 million residents. And I controlled 95% of scope creep before it ever reached the delivery team.

Here's what actually made the difference.

The Thing Nobody Wants to Say Out Loud

Scope creep is not a delivery problem.

It's a governance failure that gets labeled as flexibility.

Most programs I've walked into didn't fail because of bad teams or weak technology. They failed because:

Scope was loosely defined at the start
Ownership was unclear in the middle
By the time leadership noticed the drift, the outcome was already compromised

In government programs it gets harder. You've got multiple agencies, conflicting priorities, vendor dependencies, and political pressure that changes direction without warning.

If you don't control scope at the front door, you spend the entire program chasing it from behind.

What We Were Actually Dealing With

The 988 crisis response analytics program was complex.

67 counties
13 crisis call centers
Multiple state agencies
Vendors with opinions about what should be delivered

Everyone had a request. Everyone had a priority. And without a system to evaluate those requests, everything felt equally urgent.

That's the real problem. Not the requests themselves. The absence of a structure that forces people to think before they ask.

The Shift That Changed Everything

Most teams try to manage scope creep after it enters the system.

That's already too late.

We focused on stopping it before it ever reached the backlog.

That required three things working together.

Move 1: Clarity Before Commitment

We introduced one simple rule: No item enters the backlog without answering four questions.

What problem does this solve?
Who is impacted?
What happens if we don't do it?
Is this a requirement or a preference?

If the answers weren't clear, the work didn't move.

This alone removed a massive amount of noise.

Move 2: A Structured Intake Process

Every request came in through a single channel, got categorized as regulatory, operational, or enhancement, and was mapped to a program goal before anyone touched it.

Nothing moved forward without:

Stakeholder agreement
Defined success criteria
A named owner

When requests have to survive a process, the weak ones disappear on their own.

Move 3: Making Trade-Offs Visible

When someone asked for a change, the answer wasn't yes or no.

The answer was: what are we deprioritizing to make room for this?

One question. Entire dynamic changed.

Suddenly:

Urgent requests became optional
Critical changes disappeared
Stakeholders became more thoughtful because every request now had a visible cost attached

The Backlog Is Not a Parking Lot

A messy backlog is one of the quietest ways a program loses control.

We treated it as a controlled system. Every item had:

A defined outcome
A business justification
A priority tied to a program goal

No duplicates. No vague items. Nothing someone added "just in case."

This kept delivery predictable because the team always knew what mattered and why.

What the Data Showed Us

We built dashboards tracking:

Work intake against delivery capacity
Scope changes over time
Bottlenecks across teams

When stakeholders could see that data, conversations changed.

Instead of: "Can we just add this?"

The question became: "Where does this fit?"

Completely different mindset. Came from visibility, not from me saying no more often.

The results:

25% improvement in reporting transparency
23% improvement in sprint predictability
95% scope control — every unnecessary conversation we never had to have

The Human Behavior Part

Scope creep isn't just a process problem.

It's a human behavior problem.

People push for more because they want to be heard. They want to add value. They're afraid of missing something important. If you just block requests, you create resistance. People find workarounds.

What worked better was acknowledging every request, evaluating it transparently, and making the trade-off visible. People didn't feel ignored. They felt included in the decision. That reduced pushback more than any governance structure could.

The Pattern I See Everywhere

After 14 years in government and healthcare IT, here's the consistent pattern:

Programs don't collapse overnight. They drift.

One small change at a time. One exception at a time. Until the program being delivered no longer resembles the one that was approved.

The fix isn't tighter control after delivery starts.

It's a system built before the first sprint begins. One where unnecessary work never becomes an option in the first place.

One Thing Worth Honest Assessment

If you're running or sponsoring a large program right now, answer this honestly:

Are you controlling your scope, or are you reacting to it?

Big difference. Most programs only find out which one they were doing after it's too late to change.

Originally published on my portfolio at asifsheraz.com/writing/controlling-scope-creep-government-programs

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.

ProgramManagement #ScopeCreep #PMOGovernance #GovernmentIT #AgileAtScale

How to Finish a Long-Running Enterprise Implementation

Asif Sheraz — Wed, 17 Jun 2026 20:08:25 +0000

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.

ProgramManagement #EnterpriseIT #SAPSuccessFactors #ADPeTime #ChangeManagement