Why Your SAP Go-Live Is Already 6 Months Late Before It Starts
The dirty secrets of SAP project planning no consultant will tell you upfront
It's 3am. The database migration is sitting at 40%. The DBA hasn't slept since Tuesday. The project manager — bless them — just said the words that open every go-live disaster story: "We're still on schedule."
Project Phase Timeline — Planned vs. Actual
I've been on that call. I've watched the percentage bar like it's a stock ticker for my career. And here's the thing nobody says clearly enough: the reason you're on that call at 3am has nothing to do with the migration script. Those seeds were planted in blueprint. Maybe in discovery. Maybe the moment the steering committee approved a project plan nobody actually read.
This pattern repeats across years of go-lives, more than anyone wants to count. The failures aren't random. They're predictable, and they start the same way every time.
The RICEFW Trap Nobody Fixes
Every SAP project starts with an estimation exercise. Reports, Interfaces, Conversions, Enhancements, Forms, Workflows. Business stakeholders in one room, consultants in another, someone writes 40 objects on a whiteboard and everyone nods.
Forty turns into 180 by go-live. I've seen the multiplier range from 2x to 4x across projects. It has never, in my career, gone the other direction. This isn't a failure of math — it's a failure of honesty about how SAP projects actually work.
The multiplier nobody prints in project plans: Take your discovery workshop object count and multiply by 2.5 to 3x for planning purposes. Every time. The variance comes from scope creep, not estimation error — and scope creep is structural.
Here's why the number always grows. During discovery, the business describes their current process. The consultant scopes objects to replicate it. Then the project starts and the business realizes SAP works differently. They don't want to change their process. So each gap becomes a new object — written, reviewed, tested, transported. The RICEFW list is alive, and it only grows in one direction.
The Template Pitch vs. Reality
The standard defense is the "template approach." We've done this before. The template accelerates everything. The template is your safety net.
A template is a starting point. Not a constraint. Consultants don't say this clearly because a template that constrains scope is harder to sell.
I have worked on template-based projects that landed on time. Every single one treated the template as a ceiling, not a floor. The question wasn't "can we add this?" It was "does the template support this, and if not, is it phase 1 or phase 2?" That's a different conversation. Most projects never have it.
"The scope that kills go-live was approved in workshop week two by people who wouldn't be on the 3am call."
Why Governance Is the Only Real Fix
Every "just one more" enhancement carries a compound cost that isn't visible when it's requested. It shows up at go-live when you're running parallel systems and realizing custom code wasn't regression-tested. Each modification is also a future upgrade conversation, a future transport management headache, a future test cycle.
The creep isn't a discipline failure — it's a governance failure. Who has the authority to say no? On most projects, that person is either not empowered, not in the room, or not willing to have the fight. So the fight happens at go-live instead of at discovery. Which is how you end up on a 3am call watching a percentage bar.
Freeze Scope at Blueprint. No Exceptions.
If it isn't in the blueprint document, it's phase 2. Any post-blueprint addition requires a formal change request that displaces something already on the list. This is not a new idea. Every experienced SAP person knows it. Every new project ignores it, because stakeholders don't like hearing it and sponsors don't like enforcing it.
The mechanism is process, not willpower. Every change request after blueprint sign-off gets a formal impact assessment: time estimate, cost estimate, displacement recommendation (what comes out if this goes in). Sponsor sign-off required. No exceptions.
When the cost is visible, sponsors say no. When the displacement is explicit, stakeholders deprioritize. The change control board isn't bureaucracy — it's the mechanism that puts the true cost of "just one more" in front of the people who have to approve it. Most of the time, they choose not to.
I've watched projects install this mid-stream and arrest a death march. It's painful to do late. It's much better done at kickoff, when everyone's still friends.
The Sanity Checks Before You Sign Off
What the Projects That Actually Ship Have in Common
I've been on projects that hit their go-live date. Not many, but enough. They weren't lucky. They weren't faster or smarter. They were ruthless about one thing: saying no.
The best go-live I've ever been part of shipped 4 days early. The PM had one answer for every post-blueprint scope request: "That's a great idea for phase 2." Said warmly, said without apology, said every single time. The team called her the most difficult PM they'd ever worked with and also the best. Those two things are the same thing.
The template for every post-blueprint scope conversation: "I can add this to the plan. To do that, tell me which of these three things comes out: [item A], [item B], or [item C]. Which would you prefer?" The conversation usually ends there.
A cutover timeline that accounts for migration retries. Most plans show one migration run. Production migrations fail the first time. Sometimes the second. Your cutover window needs to assume at least two full attempts with decision checkpoints between them — and the business needs to know this before the go-live weekend, not during it.
The projects that miss their date aren't bad projects staffed by bad people. They're well-intentioned projects that didn't build governance strong enough to survive contact with stakeholder requests. That's a structural problem. It has a structural solution. And it has to be installed in the first four weeks, not the last four.
The 3am call is avoidable. Just not at 3am.