Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
The Theory of Constraints is one of the most disciplined reasoning methods management has produced. That is exactly why the question that sits upstream of it matters so much.
The Theory of Constraints (TOC) — Eliyahu Goldratt’s body of work, from The Goal (1984) through the Thinking Processes formalized across the 1990s — is not a framework you memorize. It is a discipline of causal reasoning. The Five Focusing Steps identify and manage the constraint; the Thinking Processes force you to connect assumptions, causes, effects, and interventions explicitly; the three governing questions — what to change, what to change it to, how to cause the change — hold the whole method to logical account. Taught at a high standard — Washington State University’s EM526 and EM530 among the premier programs — it produces people who reason more rigorously about systems than almost any other management education on offer.
I want to be clear at the outset, because what follows is not a critique: on disciplined causal reasoning, TOC is right, and it is rare.
So here is the question that has stayed with me, and I hold it as a testable proposition, not an assertion.
The failure gap that decades of good method have not closed
Organizations have now had TOC for roughly four decades. Alongside it: Lean, Six Sigma, Agile, ERP modernization, digital transformation, and now AI transformation. Each is a serious, disciplined method. Each has been widely adopted.
And yet the commonly cited failure rates for large transformation initiatives have stayed stubbornly high — the 70–80% range quoted for digital transformations has barely moved across the whole sequence.
That persistence is itself the finding. When a long series of genuinely good methods is applied and the failure rate does not fall, the honest inference is not that the methods are weak. It is that they are all operating on something the methods themselves take as a given.
What every reasoning method takes as input
The Thinking Processes are exceptionally good at analyzing cause and effect once the system has been characterized. A Current Reality Tree maps the undesirable effects and their root causes. But the tree can only reason about the reality it was built from — and the reality it is built from is usually the one people are willing and able to describe.
That is the gap. Not in the reasoning. In the input.
Process maps document how work is supposed to happen. People, asked, explain how they believe it happens. But implementation succeeds or fails according to how work actually happens — the incentives, the workarounds, the point-of-capture behavior that no one writes down and few think to look for. Build the causal model from the declared process instead of the operating one, and every downstream analysis — however logically flawless — optimizes a system that does not fully exist.
I documented this at Canada’s Department of National Defence in 1998 — early work funded through the Government of Canada’s Scientific Research and Experimental Development (SR&ED) program — and I have watched it repeat through every technology wave since. The parameter that reset that entire program was not found in any diagram. It was found in a plain question about operating reality — what time of day was an order placed, and what did that do to cost and delivery? — which exposed that orders were being timed to how people were measured, not to when goods were needed. No Current Reality Tree built from the declared process would have surfaced it, because no one describing the process would have volunteered it. It had to be observed.
The two layers
This is why I do not frame Invariant Physics™ and Implementation Physics™ as a replacement for the Theory of Constraints. They operate at a different layer.
Invariant Physics™ is the lens: across ERP, SaaS, cloud, mobile, agentic AI — and, the record shows, back through a 2005 keynote to that 1998 DND work — the same operating principle holds. The technology changes; the requirement that the operating reality be understood before anything is scaled on top of it does not. That is a falsifiable claim, and it is meant to be: a genuine technology-first or method-first rollout that succeeded with no operating-reality work would count against it. Across the record, that case has never appeared.
Implementation Physics™ is the per-engagement discipline that follows from the lens — the readiness and validation work, run through Phase 0™, that establishes whether the model you are about to reason from actually reflects the operating environment. It surfaces the point-of-capture drivers before the optimization begins, not after it fails.
Put the layers in order and the relationship is not competitive at all:
- Implementation Physics™ validates that the system being analyzed is the real operating system — including the incentives and workarounds the declared process omits.
- The Theory of Constraints then does what it does better than anything else — identify the constraint and reason, with full logical discipline, about how to manage it.
TOC was never the thing that failed. It was doing excellent reasoning on a representation of the system that had inherited the declared process rather than the operating one. Give its Thinking Processes a model that has been validated against operating reality first, and the same rigor that produced a logically consistent solution now produces one grounded in the environment it will actually enter.
Why this is the useful way to say it
If the persistent-failure proposition holds — if organizations have been repeatedly improving execution within models that do not capture how work is actually performed — then the leverage was never a better constraint analysis. It was validating the model before the analysis began.
That does not diminish the Theory of Constraints. It tells you where its power is best spent: on a system you have confirmed is real. The reasoning is only as sound as the reality it was built from — and confirming that reality is a discipline of its own, upstream of the constraint.
The methods keep changing. The order does not: understand how the work actually happens, then bring the reasoning. That has been the invariant since 1998, and it is the invariant now.
You can debate whether a model is right. You cannot debate the dated record it was built on.
With respect to the Theory of Constraints and the educators who teach it at a high standard. This analysis draws on the Procurement Insights archive — an independent record I have published openly since 2007, consolidating documented client work, lectures, and writing reaching back to 1998, and carrying no vendor sponsorships across the past decade. Every claim is held to the Provenance Ledger™, a verify-before-publish discipline that traces each assertion to a primary source and reconciles the record forward rather than editing it in place. Invariant Physics™ is the constant it keeps testing; Implementation Physics™ is its per-engagement application. Getting it right, rather than being right.
-30-
A note on what’s next. For teams who want to put this into practice, Hansen Models™ is offering a one-day course — Invariant Physics™ & the Theory of Constraints (half day) and Implementation Physics™ (half day) — available from August 17, 2026. It is built to sit alongside the Theory of Constraints, not to replace it: for TOC certification itself, TOCICO and its certified educators remain the path. This course adds the upstream layer — validating that the system you’re about to reason about reflects operating reality before the analysis begins. For the outline or to register interest: HPT@hansenprocurement.com.
Related
The Theory of Constraints Optimizes the System You Give It. Invariant Physics™ Asks Whether It’s the Real One.
Posted on July 21, 2026
0
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
The Theory of Constraints is one of the most disciplined reasoning methods management has produced. That is exactly why the question that sits upstream of it matters so much.
The Theory of Constraints (TOC) — Eliyahu Goldratt’s body of work, from The Goal (1984) through the Thinking Processes formalized across the 1990s — is not a framework you memorize. It is a discipline of causal reasoning. The Five Focusing Steps identify and manage the constraint; the Thinking Processes force you to connect assumptions, causes, effects, and interventions explicitly; the three governing questions — what to change, what to change it to, how to cause the change — hold the whole method to logical account. Taught at a high standard — Washington State University’s EM526 and EM530 among the premier programs — it produces people who reason more rigorously about systems than almost any other management education on offer.
I want to be clear at the outset, because what follows is not a critique: on disciplined causal reasoning, TOC is right, and it is rare.
So here is the question that has stayed with me, and I hold it as a testable proposition, not an assertion.
The failure gap that decades of good method have not closed
Organizations have now had TOC for roughly four decades. Alongside it: Lean, Six Sigma, Agile, ERP modernization, digital transformation, and now AI transformation. Each is a serious, disciplined method. Each has been widely adopted.
And yet the commonly cited failure rates for large transformation initiatives have stayed stubbornly high — the 70–80% range quoted for digital transformations has barely moved across the whole sequence.
That persistence is itself the finding. When a long series of genuinely good methods is applied and the failure rate does not fall, the honest inference is not that the methods are weak. It is that they are all operating on something the methods themselves take as a given.
What every reasoning method takes as input
The Thinking Processes are exceptionally good at analyzing cause and effect once the system has been characterized. A Current Reality Tree maps the undesirable effects and their root causes. But the tree can only reason about the reality it was built from — and the reality it is built from is usually the one people are willing and able to describe.
That is the gap. Not in the reasoning. In the input.
Process maps document how work is supposed to happen. People, asked, explain how they believe it happens. But implementation succeeds or fails according to how work actually happens — the incentives, the workarounds, the point-of-capture behavior that no one writes down and few think to look for. Build the causal model from the declared process instead of the operating one, and every downstream analysis — however logically flawless — optimizes a system that does not fully exist.
I documented this at Canada’s Department of National Defence in 1998 — early work funded through the Government of Canada’s Scientific Research and Experimental Development (SR&ED) program — and I have watched it repeat through every technology wave since. The parameter that reset that entire program was not found in any diagram. It was found in a plain question about operating reality — what time of day was an order placed, and what did that do to cost and delivery? — which exposed that orders were being timed to how people were measured, not to when goods were needed. No Current Reality Tree built from the declared process would have surfaced it, because no one describing the process would have volunteered it. It had to be observed.
The two layers
This is why I do not frame Invariant Physics™ and Implementation Physics™ as a replacement for the Theory of Constraints. They operate at a different layer.
Invariant Physics™ is the lens: across ERP, SaaS, cloud, mobile, agentic AI — and, the record shows, back through a 2005 keynote to that 1998 DND work — the same operating principle holds. The technology changes; the requirement that the operating reality be understood before anything is scaled on top of it does not. That is a falsifiable claim, and it is meant to be: a genuine technology-first or method-first rollout that succeeded with no operating-reality work would count against it. Across the record, that case has never appeared.
Implementation Physics™ is the per-engagement discipline that follows from the lens — the readiness and validation work, run through Phase 0™, that establishes whether the model you are about to reason from actually reflects the operating environment. It surfaces the point-of-capture drivers before the optimization begins, not after it fails.
Put the layers in order and the relationship is not competitive at all:
TOC was never the thing that failed. It was doing excellent reasoning on a representation of the system that had inherited the declared process rather than the operating one. Give its Thinking Processes a model that has been validated against operating reality first, and the same rigor that produced a logically consistent solution now produces one grounded in the environment it will actually enter.
Why this is the useful way to say it
If the persistent-failure proposition holds — if organizations have been repeatedly improving execution within models that do not capture how work is actually performed — then the leverage was never a better constraint analysis. It was validating the model before the analysis began.
That does not diminish the Theory of Constraints. It tells you where its power is best spent: on a system you have confirmed is real. The reasoning is only as sound as the reality it was built from — and confirming that reality is a discipline of its own, upstream of the constraint.
The methods keep changing. The order does not: understand how the work actually happens, then bring the reasoning. That has been the invariant since 1998, and it is the invariant now.
You can debate whether a model is right. You cannot debate the dated record it was built on.
With respect to the Theory of Constraints and the educators who teach it at a high standard. This analysis draws on the Procurement Insights archive — an independent record I have published openly since 2007, consolidating documented client work, lectures, and writing reaching back to 1998, and carrying no vendor sponsorships across the past decade. Every claim is held to the Provenance Ledger™, a verify-before-publish discipline that traces each assertion to a primary source and reconciles the record forward rather than editing it in place. Invariant Physics™ is the constant it keeps testing; Implementation Physics™ is its per-engagement application. Getting it right, rather than being right.
-30-
A note on what’s next. For teams who want to put this into practice, Hansen Models™ is offering a one-day course — Invariant Physics™ & the Theory of Constraints (half day) and Implementation Physics™ (half day) — available from August 17, 2026. It is built to sit alongside the Theory of Constraints, not to replace it: for TOC certification itself, TOCICO and its certified educators remain the path. This course adds the upstream layer — validating that the system you’re about to reason about reflects operating reality before the analysis begins. For the outline or to register interest: HPT@hansenprocurement.com.
Share this:
Like this:
Related