Both parties proceed on logic that was never surfaced or verified.
Implied premises — logic that feels obvious to one party but has never been validated by the other. These assumptions form the invisible scaffolding beneath every stated agreement. They are not negligence. They are not dishonesty. They are structural. Both parties are operating in good faith on different foundations.
The gap operates below the visible layer. The project progresses with apparent alignment. Neither party surfaces the assumption because neither party recognizes it as an assumption — it feels like shared understanding. The gap reveals itself only when the project breaks, at which point the cost is already embedded in the work that was built on it.
"I assumed you meant…" or "I thought we all knew that." These are post-mortem markers of an Assumption Gap that went undetected until delivery. The gap is not a communication failure. It is a structural absence — logic that was load-bearing and invisible.
These signals are observable during implementation — before the gap compounds into rework. They do not confirm the gap exists. They indicate conditions under which it is likely forming.
Both parties describe the same agreement in noticeably different terms when asked independently. The alignment was real in the room. The foundation it rested on was different for each party.
Deliverables are named without naming what must be true for them to be achievable. The premises behind each item — stable org structure, clean data, consistent process across sites — are treated as self-evident.
Build begins while dependencies remain unverified. The work is technically sound at the moment it is done. The premise it depends on is never tested. It becomes load-bearing before it is known to be wrong.
Information that surfaces mid-project is treated as a scope change when it was not new — it was always true, simply unknown to the implementation team. The assumption that it was known was never stated.
The Assumption Gap is closed when implied logic has been made explicit, verified, and owned — before it shapes any build decision. Closure is not a document. It is a state in which the scaffolding beneath agreements is visible to both parties.
Every significant configuration dependency has a stated assumption. The logic that must be true for the work to hold is written down — not inferred from the deliverable.
The assumption log is built by both parties together, not written by one and reviewed by the other. Unstated logic surfaces in the process of writing, not in the act of approval.
Each named assumption has an owner and a stated consequence if it proves false. This transforms assumption capture from documentation into risk management.
The Assumption Gap is not closed by the existence of an assumption log. It is closed when every assumption in that log was captured before configuration began — not retroactively. Timing matters. Assumptions that shaped early decisions are harder to surface once work is built on them.
The Assumption Gap is frequently misidentified. These distinctions matter for diagnosis — applying the wrong intervention to the wrong gap does not close it.
Scope creep is a request to add something new. An Assumption Gap produces work that was always required but built on a premise that was never stated. The scope did not change. The premise it depended on was wrong. These are different failure modes with different interventions.
Miscommunication implies the message was sent and garbled. The Assumption Gap forms before any message is sent — the logic was never surfaced as a message. Both parties communicated clearly on everything that was said. What was never said is where the gap lives.
A requirements failure means something was asked for and not captured. The Assumption Gap concerns premises — the conditions that make requirements achievable. A requirement can be perfectly captured and still depend on an assumption that was never validated. The requirement passes review. The assumption never surfaces. The gap persists.
These are publicly documented ERP implementation failures. Each illustrates how an unverified assumption became load-bearing — invisible until the cost was already embedded. Presented as diagnostic reference, not case studies.
Lidl's proprietary inventory model valued stock at purchase price. SAP's standard retail methodology uses retail price. The assumption that Lidl's core operating logic could be preserved within a standard ERP was never explicitly validated before the project began. Seven years of customisation built on that assumption before the project was scrapped.
The premise that two incompatible valuation methodologies could coexist was load-bearing from day one. It was never surfaced as an assumption — it felt like a technical detail. The entire programme was built on it.
Source: Computer Weekly ↗Nike assumed i2's demand-planning engine and supply chain system could be made to work together despite different business rules and data formats. The assumption that interoperability was achievable through customisation was never tested at scale before go-live. The system over-forecasted some products and under-forecasted others, causing major inventory misalignment.
Legacy forecasting rules were encoded in systems that were replaced. The assumption that those rules were known and transferable was never stated. They were not known. They were not transferred.
Source: CIO.com ↗Hershey compressed a recommended 48-month implementation into 30 months and scheduled go-live immediately before Halloween and Christmas — the two highest-demand periods of the year. The assumption that an abbreviated timeline with reduced testing could support peak-season load was never explicitly challenged. The system failed to fulfil orders during the most critical window of the year.
Timeline and go-live timing were treated as scheduling decisions. The assumption embedded in those decisions — that the system would perform under peak load without full testing — was invisible until it failed.
Source: Panorama Consulting ↗