The Go-Live Graveyard: Why the Most Dangerous Day of Your Project Is Not Day One — And How to Survive the First Ninety Days
There is a mountain in Nepal that climbers call “the widow maker.”
It is not the tallest. Not the steepest. Not even the coldest.
But it has claimed more lives than peaks twice its height.
The reason? Climbers reach the summit and believe they have won. They celebrate. They relax. They take photographs with trembling, joyful hands.
And then they begin the descent.
Exhausted. Oxygen-depleted. Guard down.
That is when the mountain takes them.
Seventy percent of climbing deaths happen on the way down. Not on the way up.
The Deadliest Day
Your ERP project has a summit too.
It is called Go-Live.
For months — sometimes years — everyone has been climbing toward this moment. The budget approvals. The vendor selection. The requirements gathering. The configuration. The testing. The training. The data migration.
And then, finally, the day arrives.
The old system is switched off. The new system is switched on. Champagne is poured. Emails are sent. Executives shake hands. Photographs are taken.
Victory.
Except it isn’t.
Because Go-Live is not the summit.
Go-Live is base camp for the real climb.
And the next ninety days will determine whether your project lives or joins the graveyard of failed implementations.
The Statistics Nobody Shares
Let me tell you what the vendors won’t put in their case studies:
40% of ERP projects that “successfully” go live fail to deliver expected benefits within two years.
Read that again.
These are not projects that crashed during implementation. These are projects that launched. That celebrated. That issued press releases.
And then quietly, slowly, painfully… failed.
The system was live. But nobody used it properly. The data was migrated. But nobody trusted it. The processes were configured. But nobody followed them.
The project was “complete.” The transformation never happened.
The Four Valleys of Death
Between Go-Live and true success lie four valleys. Each one claims projects. Each one has its own dangers.
You must cross all four to reach the other side.
Valley #1: The Valley of Chaos (Days 1-14)
What happens:
Everything breaks. Or feels like it does.
Users who seemed competent in training forget everything. Processes that worked perfectly in testing fail in production. Data that was “validated” turns out to be wrong. Integrations that passed every test suddenly timeout.
The help desk is overwhelmed. The project team is exhausted. Executives who were celebrating last week are now asking pointed questions.
This is normal.
I need you to understand this: chaos in the first two weeks is not failure. It is physics.
You have taken an organization that knew how to operate one way and forced it to operate another way. Of course there is chaos. There would be something wrong if there wasn’t.
What kills projects in this valley:
- Panic. Leadership loses confidence and starts talking about rollback.
- Blame. Teams turn on each other instead of solving problems.
- Abandonment. Key project resources are pulled back to “normal duties.”
- Shadow systems. Users quietly return to spreadsheets and old tools.
How to survive:
First, expect it. Brief leadership before go-live: “The first two weeks will be difficult. This is normal. Here’s how we’ll handle it.”
Second, establish a war room. Physical or virtual. A single place where problems come, get triaged, get solved. No problem too small. No question too stupid.
Third, protect your team. The people who built this system need to support it. Do not let anyone pull them away. Their “normal duties” can wait. This cannot.
Fourth, communicate constantly. Daily updates to leadership. Hourly updates to users if needed. Silence creates fear. Information creates confidence.
Valley #2: The Valley of Doubt (Days 15-45)
What happens:
The initial chaos subsides. Systems stabilize. The bleeding stops.
But now comes something more insidious: doubt.
Users start to compare. “In the old system, I could do this in three clicks. Now it takes seven.” They forget the old system’s failures. They remember only its comforts.
Managers look at reports and see numbers they don’t recognize. “Revenue looks lower than last month. Is the system wrong?” No — it’s calculating differently. But they don’t know that. They just see different. Different feels wrong.
The honeymoon is over. The reality of daily life with the new system sets in. And reality is less glamorous than the demo.
What kills projects in this valley:
- Comparison bias. Everything new is compared unfavorably to the old.
- Data distrust. Users believe their spreadsheets over the system.
- Workarounds. People find ways around the system instead of through it.
- Executive impatience. “We spent all this money and it’s not better yet?”
How to survive:
First, hunt for quick wins. Find something — anything — that is genuinely better. Faster. Easier. More accurate. Publicize it. “Look at this report that used to take three days. Now it’s instant.” Quick wins rebuild faith.
Second, address comparison directly. “Yes, some things take more steps now. Here’s why. Here’s what we gain. Here’s how it gets better as you build muscle memory.”
Third, kill shadow systems mercilessly. The moment you see a spreadsheet replicating system functionality, intervene. Understand why. Fix the gap. But do not allow parallel systems to survive. They are cancer.
Fourth, manage expectations upward. Remind executives: “We said benefits would realize over 12-18 months. We’re in month one. Here’s the trajectory. Here’s what we’re tracking.”
Valley #3: The Valley of Fatigue (Days 46-75)
What happens:
The project team is exhausted.
They have been running at 150% for months. They missed vacations. They missed family dinners. They missed sleep. They held together through go-live through sheer adrenaline.
Now the adrenaline is gone. And they are tired.
Meanwhile, the organization is also tired. Tired of change. Tired of asking for help. Tired of feeling incompetent. Tired of the project that was supposed to make things better and instead just made things different.
Fatigue is the silent killer.
It doesn’t announce itself. It just accumulates. Until one day, someone important quits. Or someone makes a critical error. Or everyone collectively decides, without ever saying it, to stop trying so hard.
What kills projects in this valley:
- Burnout. Key team members leave — physically or mentally.
- Regression. Users slowly stop following new processes.
- Maintenance neglect. Issues pile up because everyone is too tired to address them.
- Lost momentum. The project quietly shifts from “transformation” to “just keeping it running.”
How to survive:
First, rotate your team. Nobody should be working 80-hour weeks in month two. Establish shifts. Force time off. This is not kindness — it is strategy. Exhausted people make mistakes.
Second, celebrate survival. You made it through the hardest part. Acknowledge it. A dinner. A small bonus. A sincere thank-you from leadership. People need to feel that their sacrifice was seen.
Third, formalize support. The war room becomes a support center. The crisis response becomes a service desk. The heroes become a team with normal working hours.
Fourth, refresh training. By now, you know what people actually struggle with — not what you thought they’d struggle with. Targeted training on real pain points. Not another generic overview.
Valley #4: The Valley of Forgetfulness (Days 76-90)
What happens:
The system is stable. Issues are manageable. Life returns to normal.
And slowly, imperceptibly, people forget why they did this.
The strategic vision that launched the project fades. The executive sponsor gets distracted by the next initiative. The project team disbands. The weekly meetings become monthly. The monthly meetings become optional.
The system runs. But no one is asking whether it’s delivering what was promised.
This is the most dangerous valley of all.
Because the previous valleys kill projects loudly. This one kills them quietly. You don’t notice until years later, when someone asks: “What did we actually get from that ERP investment?” And no one has a good answer.
What kills projects in this valley:
- Victory blindness. “We went live. We’re done.” No — you started.
- Measurement abandonment. KPIs defined in the business case are never tracked.
- Capability erosion. Knowledge concentrates in few people who eventually leave.
- Optimization neglect. The system is never tuned. Never improved. Just maintained.
How to survive:
First, schedule the business case review. Put it in the calendar now. Day 90. Day 180. Day 365. “Let’s review what we promised versus what we delivered.” Make it unavoidable.
Second, assign ownership. The project team leaves. Who owns the system now? Who is accountable for continuous improvement? Who watches the KPIs? Name names. Assign responsibilities.
Third, build a community. Super users. Champions. A community of practice that meets regularly to share tips, identify issues, request enhancements. The system should have advocates, not just administrators.
Fourth, plan the next wave. The best way to prevent forgetfulness is to keep moving forward. “Phase 1 is stabilized. Here’s what Phase 2 looks like.” Momentum is life.
The 90-Day Survival Checklist
Print this. Put it on your wall. Check it weekly.
Week 1-2: Chaos Management
☐ War room established and staffed
☐ Issue triage process working
☐ Daily executive updates happening
☐ Critical issues resolved within 4 hours
☐ No rollback discussions (unless truly catastrophic)
☐ Shadow systems actively discouraged
Week 3-4: Stabilization
☐ Issue volume declining week over week
☐ No critical open issues older than 48 hours
☐ Users completing core transactions independently
☐ Data reconciliation complete and signed off
☐ Integrations stable for 7+ consecutive days
☐ First quick win identified and communicated
Week 5-6: Normalization
☐ War room transitions to support model
☐ Help desk handling 80%+ of issues without escalation
☐ Standard operating procedures finalized
☐ Period-end close completed successfully
☐ Training gaps identified and addressed
☐ Shadow systems actively eliminated
Week 7-8: Optimization
☐ Performance bottlenecks identified and addressed
☐ User feedback collected and categorized
☐ Enhancement backlog prioritized
☐ Support team fully transitioned from project team
☐ Knowledge base documented
☐ Super user network formalized
Week 9-10: Measurement
☐ Baseline KPIs captured
☐ Variance from business case documented
☐ User satisfaction survey conducted
☐ Process compliance assessed
☐ Data quality metrics tracked
☐ Executive readout prepared
Week 11-12: Transition
☐ Project formally closed
☐ Lessons learned documented
☐ Ongoing ownership assigned
☐ Continuous improvement process defined
☐ Phase 2 scope outlined
☐ Business case review scheduled (Day 180)
The Metrics That Matter Post-Go-Live
Forget vanity metrics. Track these:
A Story of Two Factories
Let me tell you about two factories. Both in the UAE. Both implemented the same ERP. Both went live the same month.
Factory A celebrated go-live with a party. The project manager was promoted. The team was disbanded. Everyone returned to their “real jobs.” When problems arose, there was no one to solve them. When users struggled, there was no one to help them. By month three, half the warehouse was running on spreadsheets again. By month six, the CFO was asking whether they should switch to a different system.
Factory B celebrated go-live with a meeting. The agenda: “What happens now?” They planned the next ninety days hour by hour. They kept the war room open for three weeks. They scheduled daily stand-ups for a month, then weekly stand-ups for two months. They tracked twenty-three KPIs. They surveyed users every two weeks. They killed four shadow spreadsheets in week three. They found and fixed a costing error in week four that would have cost them millions. By month six, they had realized 80% of their projected benefits.
Same software. Same country. Same industry.
Different outcomes.
The difference was not talent. It was not budget. It was not luck.
The difference was respect.
Factory A treated go-live as the ending. Factory B treated it as the beginning.
The Question Nobody Asks
When you’re planning your go-live, everyone asks: “Are we ready to go live?”
Nobody asks the more important question:
“Are we ready for the day after go-live?”
Are your support structures in place? Are your escalation paths defined? Are your metrics being tracked? Are your leaders prepared for the valley of chaos? Are your users prepared for things to be hard before they get easy?
If you cannot answer yes to all of these, you are not ready to go live.
Not because your system isn’t configured.
Because your organization isn’t prepared for what comes next.
The Ninety-Day Promise
I ask every client to make a promise before go-live.
Not to me. To themselves.
“We will not judge this project until Day 90.”
Not Day 1, when everything is chaos. Not Day 30, when doubt creeps in. Not Day 60, when fatigue sets in.
Day 90. When the dust has settled. When the processes have stabilized. When the real trajectory becomes visible.
Ninety days of patience. Ninety days of commitment. Ninety days of doing the hard work of true adoption.
That is the price of transformation.
And there are no shortcuts.
The Final Lesson
There is a saying I learned from an old project manager. A man who had seen more go-lives than I will ever see.
He said:
“The go-live celebration is not the wedding. It is the engagement. The real marriage happens in the months after — when you learn to live with each other.”
Your system is not your project.
Your system is your partner.
And like any partnership, it will require patience in the early days. Understanding in the difficult moments. Commitment when it would be easier to walk away.
The projects that thrive are not the ones with the best software.
They are the ones who stayed present. Who kept working. Who refused to abandon the relationship when it got hard.
That is the difference between a system that runs and a system that transforms.
What was your worst post-go-live moment? The thing that almost broke the project — or actually did? Share in the comments. Your story might save someone else.
