Why the determining variable of technology outcomes does not change — and what it means to say so
For nearly three decades, one question has organized everything I have documented: why do organizations with access to the same technology achieve dramatically different outcomes? It is a deceptively ordinary question. Most of the industry answers it by reaching for the technology — a better platform, a smarter model, a newer architecture. The evidence says otherwise, and it has said otherwise across every technology era I have lived through: ERP, e-procurement, outsourcing, digital transformation, cloud, and now agentic AI. The names of the technologies change. The variable that decides the outcome does not. That persistence — that invariance — is the foundation of the Hansen Models™, and it is why I call the framework Implementation Physics™.
The word “physics” is chosen with care, and it is worth being precise about what it claims and what it does not. To do that, three things inside the framework have to be kept distinct, because collapsing them is where most thinking on this subject goes wrong.
The method is Strand Commonality™. It is a discipline for locating the determining variables. Outcomes are governed by recurring real-world conditions — “strands” — that persist beneath changing technology terrain: governance, decision rights, organizational readiness, incentive structures, leadership alignment, and the interaction between the human and non-human agents expected to absorb the change. The method’s signature move is convergence. When independent strands — different industries, different eras, different observers using entirely different lenses — arrive at the same determining variable, that convergence is itself the signal. Strand Commonality™ is not a law. It is a method, and a method is validated or it is not. The honest aspiration for it is not “law” but “a reliable, falsifiable analytical discipline” — which is, for a method, the highest claim there is.
The regularity is readiness over technology. This is what the method keeps finding. Hold the technology constant and the outcomes still diverge — which means the technology was never the deciding variable. The mechanism is amplification: a platform magnifies whatever organizational conditions already exist. Align the conditions first and the technology amplifies the outcomes the organization wants; leave the gaps in place and it amplifies those just as faithfully. This is a contingent claim about how the world behaves — it could have been otherwise — and it is true because the evidence keeps saying so.
The invariance claim is Implementation Physics™. This is the assertion that the regularity holds across eras — that the same governing relationship determines outcomes whether the technology in front of you is a 1998 ERP rollout or a 2026 agentic AI deployment. And invariance-across-changing-conditions is exactly what physics is the right metaphor for. Physics is not “things always fall.”Physics is “the same law holds whether you drop the object in 1850 or in 2026.” The era changes; the governing relationship does not. That, and only that, is what the name asserts.
What the name does not assert is deterministic certainty about any single case. This is the distinction that keeps the framework defensible. Implementation Physics™ carries the invariance claim — the pattern holds across eras. The grading discipline carries the certainty claim — how sure we are of any specific instance, marked plainly as documented, corroborated, or pending further verification. Those two jobs stay separate. The name tells you the pattern is era-independent; the grading tells you exactly how much weight any particular figure can bear. Letting “physics” mean “invariant and falsifiable” rather than “certain and exceptionless” is the whole game.
And that second word — falsifiable — is the deeper reason the metaphor is earned rather than borrowed. Physics is the most testable discipline there is; it lives or dies by whether the prediction survives the experiment. To name a framework after it is to accept that standard. The claim here is stated in a form that could be broken: show me a case where the technology was the determining variable — strong technology dropped into a genuinely ready organization that failed on the technology’s own merits, or weak technology dropped into a misaligned organization that succeeded on the technology’s merits — and the regularity is falsified. Across the record I have examined — nearly three decades and multiple eras — that counter-example has not appeared, not for lack of looking. A pattern earns confidence not by being confirmed a thousand times, but by surviving every chance it had to break.
The proof sits in the record where the technology is held constant and the outcomes still split. The same Ariba platform carried Virginia’s eVA program from roughly 1% to 80% of spend under management — a documented success built on process and readiness — while Ontario’s OECM dropped the same platform at a reported cost first surfaced in 2010. The same class of SAP software carried Arapahoe County to an on-time, on-budget success and Hewlett-Packard to a roughly $400 million failure, the latter on the record from its own CEO. And the cleanest demonstration of sequence comes from a 1998 Department of National Defence engagement funded under Canada’s Scientific Research & Experimental Development program, where delivery performance moved from 51% to 97.3% within three months — achieved through alignment and readiness work before the technology platform was selected. The platform was chosen afterward, to scale a result that already existed. It did not cause it.
These are not retrospective illustrations assembled to fit a thesis. They are tested against a contemporaneous record I have published openly since 2007 and that consolidates documented client work, lectures, and articles reaching back to 1998 — nearly three decades of contemporaneous observation, gathered in one place rather than created there. That distinction is the source of its authority. A validation layer built after the fact tends to confirm; one built in real time, era by era, can disconfirm — and occasionally does, which is precisely why it can be trusted. I would be worried if every figure across that span lined up perfectly. The seams are the proof of contemporaneity.
There is a boundary, as every honest physics has one. The regularity governs organizational technology adoption at meaningful scale and consequence; it does not pretend to govern a single user installing an app. Stating the domain does not weaken the claim — it is what separates a law-shaped statement from a slogan. And to be exact about status: none of the three — the method, the regularity, the invariance claim — is yet a “law” in the strong, formal sense. What they are is a falsifiable method that has reliably located the determining variable, a regularity with a stated mechanism, and an invariance claim that has held across every era it has faced. Each can be broken on its own terms. None has been. That is a stronger position than asserting a law, because it is one a skeptic cannot dismiss as overreach — they must either produce the counter-example or concede the pattern.
That is what it means to call it physics. Not certainty. Invariance, and the willingness to be tested. The technologies will keep changing. On the evidence of nearly thirty years, the physics beneath them will not.
Truth Is Believing. Accuracy Is Knowing.
Jon Hansen is the creator of Implementation Physics™, a research-based framework developed over nearly three decades to explain why technology initiatives succeed or fail regardless of the technology being deployed. His work spans six technology generations — from ERP through Agentic AI — and includes the Metaprise™ model first articulated in the late 1990s. His research forms the foundation for the Hansen Method™, Hansen Fit Score™ (HFS™), Phase 0™ Readiness Assessment, and the ARA™ RAM 2025™ multimodel verification architecture. He currently serves as a Board Member of the CIPS Americas Chapter.
The Invariant Physics of the Hansen Models™
Posted on June 22, 2026
0
Why the determining variable of technology outcomes does not change — and what it means to say so
For nearly three decades, one question has organized everything I have documented: why do organizations with access to the same technology achieve dramatically different outcomes? It is a deceptively ordinary question. Most of the industry answers it by reaching for the technology — a better platform, a smarter model, a newer architecture. The evidence says otherwise, and it has said otherwise across every technology era I have lived through: ERP, e-procurement, outsourcing, digital transformation, cloud, and now agentic AI. The names of the technologies change. The variable that decides the outcome does not. That persistence — that invariance — is the foundation of the Hansen Models™, and it is why I call the framework Implementation Physics™.
The word “physics” is chosen with care, and it is worth being precise about what it claims and what it does not. To do that, three things inside the framework have to be kept distinct, because collapsing them is where most thinking on this subject goes wrong.
The method is Strand Commonality™. It is a discipline for locating the determining variables. Outcomes are governed by recurring real-world conditions — “strands” — that persist beneath changing technology terrain: governance, decision rights, organizational readiness, incentive structures, leadership alignment, and the interaction between the human and non-human agents expected to absorb the change. The method’s signature move is convergence. When independent strands — different industries, different eras, different observers using entirely different lenses — arrive at the same determining variable, that convergence is itself the signal. Strand Commonality™ is not a law. It is a method, and a method is validated or it is not. The honest aspiration for it is not “law” but “a reliable, falsifiable analytical discipline” — which is, for a method, the highest claim there is.
The regularity is readiness over technology. This is what the method keeps finding. Hold the technology constant and the outcomes still diverge — which means the technology was never the deciding variable. The mechanism is amplification: a platform magnifies whatever organizational conditions already exist. Align the conditions first and the technology amplifies the outcomes the organization wants; leave the gaps in place and it amplifies those just as faithfully. This is a contingent claim about how the world behaves — it could have been otherwise — and it is true because the evidence keeps saying so.
The invariance claim is Implementation Physics™. This is the assertion that the regularity holds across eras — that the same governing relationship determines outcomes whether the technology in front of you is a 1998 ERP rollout or a 2026 agentic AI deployment. And invariance-across-changing-conditions is exactly what physics is the right metaphor for. Physics is not “things always fall.”Physics is “the same law holds whether you drop the object in 1850 or in 2026.” The era changes; the governing relationship does not. That, and only that, is what the name asserts.
What the name does not assert is deterministic certainty about any single case. This is the distinction that keeps the framework defensible. Implementation Physics™ carries the invariance claim — the pattern holds across eras. The grading discipline carries the certainty claim — how sure we are of any specific instance, marked plainly as documented, corroborated, or pending further verification. Those two jobs stay separate. The name tells you the pattern is era-independent; the grading tells you exactly how much weight any particular figure can bear. Letting “physics” mean “invariant and falsifiable” rather than “certain and exceptionless” is the whole game.
And that second word — falsifiable — is the deeper reason the metaphor is earned rather than borrowed. Physics is the most testable discipline there is; it lives or dies by whether the prediction survives the experiment. To name a framework after it is to accept that standard. The claim here is stated in a form that could be broken: show me a case where the technology was the determining variable — strong technology dropped into a genuinely ready organization that failed on the technology’s own merits, or weak technology dropped into a misaligned organization that succeeded on the technology’s merits — and the regularity is falsified. Across the record I have examined — nearly three decades and multiple eras — that counter-example has not appeared, not for lack of looking. A pattern earns confidence not by being confirmed a thousand times, but by surviving every chance it had to break.
The proof sits in the record where the technology is held constant and the outcomes still split. The same Ariba platform carried Virginia’s eVA program from roughly 1% to 80% of spend under management — a documented success built on process and readiness — while Ontario’s OECM dropped the same platform at a reported cost first surfaced in 2010. The same class of SAP software carried Arapahoe County to an on-time, on-budget success and Hewlett-Packard to a roughly $400 million failure, the latter on the record from its own CEO. And the cleanest demonstration of sequence comes from a 1998 Department of National Defence engagement funded under Canada’s Scientific Research & Experimental Development program, where delivery performance moved from 51% to 97.3% within three months — achieved through alignment and readiness work before the technology platform was selected. The platform was chosen afterward, to scale a result that already existed. It did not cause it.
These are not retrospective illustrations assembled to fit a thesis. They are tested against a contemporaneous record I have published openly since 2007 and that consolidates documented client work, lectures, and articles reaching back to 1998 — nearly three decades of contemporaneous observation, gathered in one place rather than created there. That distinction is the source of its authority. A validation layer built after the fact tends to confirm; one built in real time, era by era, can disconfirm — and occasionally does, which is precisely why it can be trusted. I would be worried if every figure across that span lined up perfectly. The seams are the proof of contemporaneity.
There is a boundary, as every honest physics has one. The regularity governs organizational technology adoption at meaningful scale and consequence; it does not pretend to govern a single user installing an app. Stating the domain does not weaken the claim — it is what separates a law-shaped statement from a slogan. And to be exact about status: none of the three — the method, the regularity, the invariance claim — is yet a “law” in the strong, formal sense. What they are is a falsifiable method that has reliably located the determining variable, a regularity with a stated mechanism, and an invariance claim that has held across every era it has faced. Each can be broken on its own terms. None has been. That is a stronger position than asserting a law, because it is one a skeptic cannot dismiss as overreach — they must either produce the counter-example or concede the pattern.
That is what it means to call it physics. Not certainty. Invariance, and the willingness to be tested. The technologies will keep changing. On the evidence of nearly thirty years, the physics beneath them will not.
Truth Is Believing. Accuracy Is Knowing.
Jon Hansen is the creator of Implementation Physics™, a research-based framework developed over nearly three decades to explain why technology initiatives succeed or fail regardless of the technology being deployed. His work spans six technology generations — from ERP through Agentic AI — and includes the Metaprise™ model first articulated in the late 1990s. His research forms the foundation for the Hansen Method™, Hansen Fit Score™ (HFS™), Phase 0™ Readiness Assessment, and the ARA™ RAM 2025™ multimodel verification architecture. He currently serves as a Board Member of the CIPS Americas Chapter.
-30-
Share this:
Like this:
Related