FIT 4 SAP Proof of Concept
Why It Works

This isn't about technical capability. It is about forcing truth to emerge. Constraints create clarity; flexibility creates confusion. The method is the value, not just the technical output. Based on 30 years of watching implementations fail the same way.
The Core Problem: Faith-Based Contracting
A 2025 Horváth study of 200 companies found that around two-thirds of S/4HANA transformations went significantly over budget, ran 30% longer than planned on average, and 65% reported serious quality deficits.
Executives sign multi-year Statements of Work based on polished demos and consultant promises, unable to evaluate technical claims without running the actual system. By the time problems surface - typically six months into delivery - switching costs make you captive. Sunk cost fallacy takes over: "We've already spent £500k, we can't stop now."
The predictable failure pattern:
Week 1: Optimistic kickoff, everyone aligned
Month 3: "Minor issues" emerging, still "on track"
Month 6: Scope expanded 40%, timeline slipping, budget warnings
Month 9: Crisis mode, consultants asking for more money
Month 12: Go-live delayed, stakeholders losing faith
Month 18: System launches broken, users work around it
Year 2: Post-implementation review blames "change management" (never scope drift)
Root cause: No forcing function to test assumptions before commitment. You can't fix what you can't see. Faith-based contracts hide problems until it's too late.
The FIT 4 SAP Solution: Constrained Validation
Three forcing functions work together: fixed scope, fixed timeline, fixed governance. These constraints aren't arbitrary. They apply Fast Implementation Track (F.I.T.) principles to create validation engineering, not sales theatre.
And FAST within F.I.T. stands for Focus And Simplify Transformation. Not speed for its own sake, but a method that never needs to delay go-live.
How F.I.T. Principles Apply to FIT 4 SAP
These constraints apply to Fast Implementation Track (F.I.T.) governance principles. F.I.T. provides the philosophy; FIT 4 SAP provides the execution framework.
| F.I.T. principle | How FIT 4 SAP applies it |
|---|---|
| FOCUS: The one thing the prototype needs to test, agreed as feasible within 30 days. | Fixed Scope: One critical business scenario, fully validated, no roadmap drift |
| COMMUNICATE: The Scope Agreement must not contain any ambiguity. | Plain-language documentation: No jargon, no hidden assumptions, explicit out-of-scope register |
| SIMPLIFY: Stick to the Clean Core S/4 to see how the standard system handles the scope. | Standard functionality bias: No custom code during prototype, test business process fit first |
| COMMIT: As of Day 1, we stick to what is agreed. | Fixed timeline and locked scope: No extensions, no silent drift, Decision Register documents every deviation attempt |
| EDUCATE: We learn from mistakes, so the Scar Log is essential. | Governance artefacts: Document every problem in real-time, capture learning for full implementation |
This is applied governance, not invented methodology.
Discover the origin story behind the five principles →
FOCUS: Why Fixed Scope Works
The one thing the prototype needs to test is agreed as feasible within 30 days.

The Prioritisation Forcing Function
When you test everything, nothing gets tested well. When you can test one thing, you pick what REALLY matters.
Example: "We need inventory + manufacturing + costing + CRM"
FIT 4 SAP: "Pick ONE. Which breaks your business if wrong?"
Forces honest conversation about risk. Usually, it reveals that half the requirements are nice-to-haves.
The Complexity Revealer
"Simple" requirements often hide gnarly dependencies.
Example: "We just need customer-specific pricing"
Prototype Day 5: Actually 47 pricing rules with 12 exceptions
Full project would have discovered this Month 6
Now you know before signing Statement of Work
The Scope Creep Preventer
Decision Register tracks every "can we add..." request. Shows organisational discipline or lack thereof. Reveals whether stakeholders will respect boundaries in full project. If they can't stay focused for 30 days, they won't for 12 months.
What makes this different:
Traditional: Scope drift = project manager's problem
FIT 4 SAP: Scope drift = governance finding ("Your organisation can't maintain focus")
Governance principle: Scope discipline is organisational capability, not project phase.
SIMPLIFY: Why Standard Functionality Bias Works
Stick to Clean Core S/4 to see how the standard system handles the scope.

The Clean Core Forcing Function
Prototype uses standard S/4HANA configuration only. No custom code. It forces the question: "Does our business process fit standard SAP?" If it doesn't, it reveals the need for process redesign, not a technical solution.
Example: "SAP doesn't handle our workflow"
FIT 4 SAP: "Why is your workflow unique? Is that uniqueness valuable or legacy?"
Often reveals: "We do it this way because our old system forced us to"
The Complexity Preventer
Custom code equals technical debt equals ongoing cost. Standard configuration means SAP maintains it, resulting in a lower total cost of ownership. If the prototype can't prove the scenario with standard functionality, that's a strategic finding: "Your business model doesn't fit standard S/4". The board needs to know this before the £10M commitment.
The Upgradeability Validator
Standard configuration survives SAP upgrades. Custom code breaks every major release. Prototype proves whether you're buying into maintenance nightmare or sustainable platform.
What makes this different:
Traditional: "We'll customise SAP to fit your unique needs"
FIT 4 SAP: "Let's test whether your needs are actually unique or just legacy assumptions"
Governance principle: Standard functionality first. Customisation only with evidence.
COMMIT: Why Fixed Timeline Works
From Day 1, we stick to what is agreed.

The Decision Velocity Forcing Function
Deadlines without consequences aren't deadlines. Day 30 arrives whether you're ready or not. Forces "good enough" instead of "perfect." Reveals decision-making speed critical for full implementation.
The Priority Clarity Creator
Limited time equals forced choices. What gets done first reveals true priorities. What gets cut reveals nice-to-haves vs. must-haves.
Example: "We need 200 test scenarios"
FIT 4 SAP: "We have time for 30. Which 30 matter most?"
That prioritisation exercise is more valuable than running all 200.
The Reality Check Mechanism
If 30 days feels impossible, 12-month project will run 18 months. If consultants need "just two more weeks" to finish, they'll need "just one more quarter" in full project. If stakeholders can't commit 2 hours/week for 30 days, they won't commit 20 hours/week for full project.
Prototype timeline stress-tests organisational capacity.
What makes this different:
Traditional: "We'll need more time to do this right"
FIT 4 SAP: "Timeline is fixed. Finish what you can, document what you couldn't."
Governance principle: Time constraints reveal capability. Extensions hide incompetence.
EDUCATE: Why Governance Discipline Works
We learn from mistakes, so the Scar Log is essential.

The Accountability Mechanism
Can't hide problems if you document them weekly. Can't blame others if Decision Register shows your choices. Can't claim success if no change management topics are found.
Artefacts aren't bureaucracy. They're forcing functions for honesty. Scar Log prevents "everything's fine" theatre. Decision Register prevents "you never told us" gaslighting. Change management assessment prevents "technical success, business failure" disconnect.
The Learning Capture
Full implementation team inherits 30 days of documented learning. Don't repeat prototype mistakes. Don't rediscover prototype insights. Governance artefacts become training material for delivery teams.
What makes this different:
Traditional: Documentation created to avoid blame
FIT 4 SAP: Documentation created to enable learning
Governance principle: Transparency is insurance against amnesia.
COMMUNICATE: Why This Works for Executives vs. Project Managers
One set of evidence, in plain language, for both audiences.

Two different value propositions, same constraints, benefit both.
For Executives (Board-Level Value)
BEFORE signing the Statement of Work, know whether S/4HANA fits your business. Evidence-based decision making, not faith-based. Board Pack provides governance receipts for due diligence. If PoC fails, avoided a £10M commitment by learning early. If PoC succeeds, proceed with confidence, not hope.
For Project Managers (Delivery-Level Value)
Scope discipline prevents "requirements discovered during UAT" disasters. Decision Register documents every stakeholder pressure point. Scar Log captures lessons for full implementation. Change management assessment keeps executive expectations aligned with delivery reality. Governance artefacts protect PM when politics get messy.
The beautiful thing: Both groups benefit from the same constraints. Executives get proof before commitment. PMs get protection against scope creep. Win-win through discipline.
What makes this different:
Traditional: Executives and PMs have conflicting incentives (speed vs. quality)
FIT 4 SAP: Constraints align incentives (truth vs. theatre)
Governance principle: Good governance protects everyone who values reality over optimism.
In-House Secure: A Worked Example
The fictional company ‘In-House Secure’ needed to validate triangular invoicing for UK/NL/FR operations before committing to S/4HANA migration.
Questionnaire revealed: Complexity hiding in "simple" cross-border setup, multiple VAT treatments, intercompany clearing, and currency conversions.
30-day prototype proved: Standard S/4HANA handled most transaction scenarios. The edge cases required BRF+ rules, documented in the Scar Log with exact scenarios and business impact.
Decision: Proceed with implementation, knowing exactly where custom rules are needed. Board Pack gave the executive sponsor ammunition to defend the decision to the board.
Key lesson: Early validation exposed the edge cases before contract commitment, when they cost a conversation rather than a change order.
What This Isn't
Clarifying what FIT 4 SAP is NOT:
NOT a vendor demo: Vendor demos show best-case scenarios with fake data. FIT 4 SAP tests YOUR scenario with YOUR data complexity.
NOT an agile sprint: Agile sprints iterate indefinitely until "good enough." FIT 4 SAP locks scope and timeline from Day 1.
NOT a traditional pilot: Pilots take 3-6 months and still hide problems. FIT 4 SAP forces truth in 30 days.
NOT technical feasibility study: Feasibility studies produce PowerPoint decks. FIT 4 SAP produces working systems plus governance artefacts.
NOT consultant theatre: Theatre optimises for executive comfort. FIT 4 SAP optimises for executive clarity.
If it feels uncomfortable (locked scope, hard deadlines, documented scars), it's working.
When FIT 4 SAP Doesn't Work
Honest limitations. The wrong tool for the wrong job helps nobody.
You shouldn't use FIT 4 SAP if:
Your business scenario genuinely needs 90 days minimum to test (some do).
Your organisation can't commit resources for 30 consecutive days.
Your executive sponsor wants reassurance theatre, not an honest assessment.
You're already committed to the vendor and need validation theatre for the board.
Better alternatives:
If the scope is too large: Break into multiple 30-day PoCs.
If timeline impossible: Question why (that's a finding about organisational capability).
If theatre desired: Hire traditional consultants.
Governance principle: Be honest about fit.
The Meta-Lesson: Constraints Create Clarity
Every principle described above uses constraints to force truth. Unlimited time equals unlimited confusion. Unlimited scope equals unlimited failure. Unlimited budget equals unlimited waste.
FIT 4 SAP uses artificial constraints to compress discovery.
30 days isn't "natural" timeline. It is an engineered forcing function.
Scope locks aren't "realistic". They're a disciplinary mechanism.
Standard functionality bias isn't "best practice". It is a complexity preventer.
The constraints are the value. Remove them and you're back to faith-based contracting.
