In today’s post the Director of Procurement for NEOM speaks out about SAP. Following his post, I will share my thoughts, and a paper I wrote in 2008 that connects the dots from then to 2025.
MIKE GRORGE: Director of Procurement on THE LINE NEOM
🚧 SAP Implementations: The Brutal Truths Nobody Tells You 🚧
After years of being close to major SAP rollouts (four in total), I’ve learnt that SAP is never “just an IT project.” When it fails, it fails big time. And when it succeeds, it transforms the business.
For me, the difference between success and failure often comes down to recurring themes. Here are my hard-earned lessons from the trenches I’ve seen time and time again:
❌ Poor executive sponsorship – without visible leadership, the project becomes an IT exercise, not a business transformation. ❌ Consultants who don’t know the business – technical experts without business accumen creates a disconnect and misalignment. ❌ Designing SAP to fit current processes – instead of challenging inefficiencies, businesses try to replicate “the old way” in a new system. ❌ Too many custom enhancements – every “just one more tweak” adds complexity, cost, and risk. ❌ Poor data cleansing – garbage in, garbage out. If the data isn’t right, nothing else will be. ❌ Broken data hierarchy – without the right master data and structures, reporting and analytics collapse. ❌ Inadequate training – if the end users don’t get it, adoption suffers, no matter how well the system was designed. ❌ Poor change management and communication – underestimating how hard it is to shift behaviours is hugely underestimated. I’ve seen it take years to get out of the valley of despair. ❌ Over-ambitious timelines – rushing cutovers and testing always backfires later. ❌ Project team demobilises too quickly – after go-live, the “A-team” disappears, leaving gaps in knowledge and ownership. ❌ Lack of post go-live support – “hypercare” should be robust, not an afterthought.
💡 My fundamental learning is that a SAP implementation is as much about people, process, and leadership as it is about technology. The scars come when we underestimate the basics. It begs the question why do we never learn from these failed implementations?
👉 What about you? For those who’ve lived through an SAP implementation — what scars, lessons, or triumphs would you add to this list?
⭐️ Scars, Lessons & Triumphs (SLT) ⭐️ A series of reflections from the procurement trenches.
Mike George’s LinkedIn post perfectly captures the central thesis of my 2008 SAP white paper – that implementation methodology matters more than the technology itself. The post’s litany of failures demonstrates exactly what I warned about: organizations focusing on technology while ignoring the human, process, and organizational factors that determine success.
Key Takeaway: The Pattern Continues
The post reveals that 17 years after my white paper, the same fundamental errors persist:
Technology-first thinking – treating SAP as “just an IT project” instead of business transformation
Poor stakeholder engagement – inadequate executive sponsorship and change management
Process misalignment – designing SAP to fit existing broken processes rather than challenging them
Implementation shortcuts – rushing timelines, inadequate training, premature team demobilization
This validates my 2008 assessment that most failures stem from flawed implementation approaches, not the software itself.
How the Hansen Methodology Addresses These Issues
My methodology directly targets the root causes the post identifies:
Process Archaeology addresses:
Understanding actual vs. theoretical business processes before implementation
Identifying why current processes exist (preventing the “design SAP to fit current processes” trap)
Mapping real data flows and hierarchies
Agent Behavior Analysis tackles:
Executive sponsorship gaps by identifying actual vs. stated commitment levels
Change management failures by understanding stakeholder incentives and resistance patterns
Training inadequacies by assessing real user capability and motivation
Organizational Readiness Assessment prevents:
Over-ambitious timelines by honestly evaluating organizational capacity
Poor consultant alignment by ensuring business acumen requirements are met
Premature team demobilization by planning for sustained support
The Enduring Relevance
The post’s question “why do we never learn from these failed implementations?” points to your methodology’s core value proposition. Organizations keep repeating these mistakes because they:
Lack diagnostic rigor – jumping to solutions without understanding their actual operational requirements
Ignore agent behavior – assuming organizational charts reflect how work actually gets done
Underestimate complexity – treating multi-network challenges with single-network thinking
The 2008 Virginia eVA example remains the counterpoint – success came from process understanding and stakeholder collaboration first, technology selection second.
The persistence of these implementation failures after nearly two decades suggests the industry still needs the methodological approach I outlined – one that prioritizes understanding organizational reality before imposing technological solutions.
Procurement Insights
Mike, it is not the unwillingness to tell “the brutal SAP truths,” it was also an unwillingness to listen and act!
Posted on September 16, 2025
0
In today’s post the Director of Procurement for NEOM speaks out about SAP. Following his post, I will share my thoughts, and a paper I wrote in 2008 that connects the dots from then to 2025.
MIKE GRORGE: Director of Procurement on THE LINE NEOM
🚧 SAP Implementations: The Brutal Truths Nobody Tells You 🚧
After years of being close to major SAP rollouts (four in total), I’ve learnt that SAP is never “just an IT project.” When it fails, it fails big time. And when it succeeds, it transforms the business.
For me, the difference between success and failure often comes down to recurring themes. Here are my hard-earned lessons from the trenches I’ve seen time and time again:
❌ Poor executive sponsorship – without visible leadership, the project becomes an IT exercise, not a business transformation.
❌ Consultants who don’t know the business – technical experts without business accumen creates a disconnect and misalignment.
❌ Designing SAP to fit current processes – instead of challenging inefficiencies, businesses try to replicate “the old way” in a new system.
❌ Too many custom enhancements – every “just one more tweak” adds complexity, cost, and risk.
❌ Poor data cleansing – garbage in, garbage out. If the data isn’t right, nothing else will be.
❌ Broken data hierarchy – without the right master data and structures, reporting and analytics collapse.
❌ Inadequate training – if the end users don’t get it, adoption suffers, no matter how well the system was designed.
❌ Poor change management and communication – underestimating how hard it is to shift behaviours is hugely underestimated. I’ve seen it take years to get out of the valley of despair.
❌ Over-ambitious timelines – rushing cutovers and testing always backfires later.
❌ Project team demobilises too quickly – after go-live, the “A-team” disappears, leaving gaps in knowledge and ownership.
❌ Lack of post go-live support – “hypercare” should be robust, not an afterthought.
💡 My fundamental learning is that a SAP implementation is as much about people, process, and leadership as it is about technology. The scars come when we underestimate the basics. It begs the question why do we never learn from these failed implementations?
👉 What about you? For those who’ve lived through an SAP implementation — what scars, lessons, or triumphs would you add to this list?
⭐️ Scars, Lessons & Triumphs (SLT) ⭐️
A series of reflections from the procurement trenches.
SAP PROCUREMENT FOR PUBLIC SECTOR
(CLICK ON IMAGE ABOVE OR THIS LINK ACCESS PAPER)
Mike George’s LinkedIn post perfectly captures the central thesis of my 2008 SAP white paper – that implementation methodology matters more than the technology itself. The post’s litany of failures demonstrates exactly what I warned about: organizations focusing on technology while ignoring the human, process, and organizational factors that determine success.
Key Takeaway: The Pattern Continues
The post reveals that 17 years after my white paper, the same fundamental errors persist:
This validates my 2008 assessment that most failures stem from flawed implementation approaches, not the software itself.
How the Hansen Methodology Addresses These Issues
My methodology directly targets the root causes the post identifies:
Process Archaeology addresses:
Agent Behavior Analysis tackles:
Organizational Readiness Assessment prevents:
The Enduring Relevance
The post’s question “why do we never learn from these failed implementations?” points to your methodology’s core value proposition. Organizations keep repeating these mistakes because they:
The 2008 Virginia eVA example remains the counterpoint – success came from process understanding and stakeholder collaboration first, technology selection second.
The persistence of these implementation failures after nearly two decades suggests the industry still needs the methodological approach I outlined – one that prioritizes understanding organizational reality before imposing technological solutions.
30
BONUS COVERAGE
Share this:
Related