The determining variable doesn’t change across eras. The cases keep confirming it — including the ones that look, at first, like they might break it.
In a 2008 comment thread on this blog, I described two companies using the same idea. Both Cisco and Boeing, I wrote, were building what each called a “complex adaptive network” — an agent-based architecture that understands the operating attributes of disparate stakeholders first, then links them through what Boeing called “flow paths.” I called the underlying theory Strand Commonality™, and traced it to a 1998 engagement. Same architecture, named in the same breath, in the same paragraph.
Eighteen years later, the two companies could not have diverged more sharply. Cisco sits in the top five of Gartner’s 2026 Supply Chain ranking — credited for exactly the orchestration-beyond-enterprise-boundaries platform it was running two decades ago. Boeing’s supply chain became a case study in failure: delays, cost overruns, loss of control, and worse.
Same architecture. Opposite outcomes. So what was the variable?
Where is Boeing?
The easy answer is that Boeing must not have really had the platform. That answer is wrong, and the record rules it out. In an assessment published in 2025 — before any of this was written — the prior evaluation rated Boeing high on infrastructure and adaptive-network fit. You cannot claim Boeing failed for lack of the platform when the dated, contemporaneous record says Boeing had it. So the comfortable explanation is off the table, and the harder, more useful one stands in its place: the platform was present and the outcome still failed — which means the platform was never the determining variable.
That is not a framework being revised by a hard case. It is a framework absorbing one. The determining variable didn’t change; the case simply forced it into sharper view.
What is the determining variable?
Three things have to be held apart, because collapsing them is where the thinking goes wrong. There is the infrastructure — the provider’s platform itself. There is the talent — the people running it. And there is the behavioral readiness of the organization to let its actual operating reality, rather than its habits, drive how the work changes. The first two are necessary. The third is the one that decides.
We can rule out the first two by holding them constant and watching the outcome move anyway.
Hold talent constant: I spent nine years tracking the thirty practitioners ISM named to its 2017 “30 Under 30” — the best young talent in the profession. They stayed. They advanced. They led through every disruption the era produced. And the implementation failure rate did not move a single point. The best people, dropped into organizations that buy technology before assessing whether they can absorb it, produce the same 70-to-80% failure rate as everyone else. Talent was never the problem.
Hold the technology constant: consider one vendor, ConvergentIS, and one platform. In December 2025, Spend Matters rated it 9.7 out of 10 on customer satisfaction, a perfect 10 on user experience, and number one in five separate categories. The technology, by an independent analyst’s measure, genuinely works. And yet the same vendor, with the same platform, walked away from major accounts — terminated the engagement before deployment — because the client met them with the phrase that has killed transformation for decades: we have always done it this (our) way.
That is the whole experiment, and it is as clean as this work ever gets. Same vendor. Same platform. Same method. The only thing that varied between the accounts that earned those scores and the accounts the vendor walked away from was whether the organization showed up ready to change. The technology rating was accurate. It was also non-determining. A perfect platform dropped into an unwilling organization becomes shelfware, and the vendor was disciplined enough to see it coming and refuse the deal.
Now look back at the case that started all of this, in 1998. A defense-sector supplier was about to lose its contract — next-day delivery had collapsed to 51% against a 90% requirement. They asked me to automate their system. I asked them what time of day the orders came in. The question seemed irrelevant to them, which is exactly why it mattered: most orders landed around four in the afternoon, because the service technicians were incentivized on call volume and sandbagged their parts orders to the end of the day — pushing them into the late-afternoon customs window and turning a hundred-dollar part into a thousand-dollar one. No one would ever have told you that. It was in no process document. I found it by going to the floor and asking — Genchi Genbutsu — not by reading the reports.
That is the difference between modeling what people say they do and discovering what they actually do — and it is the reason traditional solution mapping cannot reach the variable that matters. Solution mapping records the stated process. The determining variables live in the gap between the stated and the actual: the incentives, the workarounds, the things people do but never report. Map the stated process and deploy onto it, and you have optimized a system that does not exist. That is the 70% failure rate, in one sentence.
Only after that operating reality was understood and corrected did the technology follow — and next-day delivery moved from 51% to 97.3% within three months. The technology did not cause the result. It scaled a result that the readiness work had already produced.
And here is the piece that resolves the whole sequence. Why did the defense supplier do the hard readiness work when Boeing and the walked-away accounts did not? Because it was about to lose the contract. The existential pressure forced it to confront its real operating reality. Boeing’s pressures ran the other way — cost and shareholder demands pushed it to protect the status quo, not to confront it. The walked-away clients had no forcing function at all, so “we have always done it this way” won.
So the variable that determines the outcome is not the technology, and not even readiness in the abstract. It is whether something is forcing the organization to confront how it actually operates — before it chooses the tool. That question is answerable in advance. It is the question no hype cycle, no magic quadrant, and no solution map has ever asked, because it is not a property of the technology at all.
A word about how I can make these claims with dates attached.
None of what you just read was assembled after the fact to fit a thesis. The Cisco-and-Boeing comparison is in a comment thread from 2008. The Strand Commonality™ origin is dated to 1998. The Boeing infrastructure assessment is from 2025 — and it is the very thing that stopped me from claiming Boeing failed for lack of the platform. The ConvergentIS scores and the walk-away discipline are documented in 2025. The talent study tracks a cohort named in 2017.
I have published openly since 2007, against a body of work reaching back to 1998 — nearly three decades of contemporaneous observation, gathered in one place rather than created there. The reason that matters is not volume. It is that a record built in real time can disconfirm. A validation layer assembled afterward only ever confirms what its author already believes. This one doesn’t: the 2025 assessment ruled out the cleaner, more flattering version of this argument and required the harder one. That is not a weakness in the record. It is the proof that the record is real. The seams are the evidence.
I did not build the archive to sell an idea. I built it to keep an honest account of what was true at the time — so that the pattern, if it is real, would have to survive its own history rather than be rescued by a retelling. These are not illustrations. They are receipts.
And that is why a case like Boeing should reassure rather than unsettle. In a moment when the technology is moving fast enough to make everyone uncertain, the instinct is to look for stable ground in the tools. That is the wrong place to look — the tools are exactly what won’t hold still. The stable ground is underneath them, in the determining variable that hasn’t changed across ERP, e-procurement, cloud, and now agentic AI. The framework didn’t bend to absorb Boeing. It tested the case, declined the comfortable answer, and confirmed the determining variable through it. That is what a foundation does. It absorbs the hard case, and stays where it is.
The technology will keep changing. On the evidence of nearly thirty years, the variable beneath it will not. Which is why the most important work happens before the platform is ever chosen.
Truth Is Believing. Accuracy Is Knowing.
-30-
Related
Cisco Thrived. Boeing Didn’t. The Provider’s Platform Was Never the Reason — and Never a Non-Factor Either
Posted on June 28, 2026
0
The determining variable doesn’t change across eras. The cases keep confirming it — including the ones that look, at first, like they might break it.
In a 2008 comment thread on this blog, I described two companies using the same idea. Both Cisco and Boeing, I wrote, were building what each called a “complex adaptive network” — an agent-based architecture that understands the operating attributes of disparate stakeholders first, then links them through what Boeing called “flow paths.” I called the underlying theory Strand Commonality™, and traced it to a 1998 engagement. Same architecture, named in the same breath, in the same paragraph.
Eighteen years later, the two companies could not have diverged more sharply. Cisco sits in the top five of Gartner’s 2026 Supply Chain ranking — credited for exactly the orchestration-beyond-enterprise-boundaries platform it was running two decades ago. Boeing’s supply chain became a case study in failure: delays, cost overruns, loss of control, and worse.
Same architecture. Opposite outcomes. So what was the variable?
Where is Boeing?
The easy answer is that Boeing must not have really had the platform. That answer is wrong, and the record rules it out. In an assessment published in 2025 — before any of this was written — the prior evaluation rated Boeing high on infrastructure and adaptive-network fit. You cannot claim Boeing failed for lack of the platform when the dated, contemporaneous record says Boeing had it. So the comfortable explanation is off the table, and the harder, more useful one stands in its place: the platform was present and the outcome still failed — which means the platform was never the determining variable.
That is not a framework being revised by a hard case. It is a framework absorbing one. The determining variable didn’t change; the case simply forced it into sharper view.
What is the determining variable?
Three things have to be held apart, because collapsing them is where the thinking goes wrong. There is the infrastructure — the provider’s platform itself. There is the talent — the people running it. And there is the behavioral readiness of the organization to let its actual operating reality, rather than its habits, drive how the work changes. The first two are necessary. The third is the one that decides.
We can rule out the first two by holding them constant and watching the outcome move anyway.
Hold talent constant: I spent nine years tracking the thirty practitioners ISM named to its 2017 “30 Under 30” — the best young talent in the profession. They stayed. They advanced. They led through every disruption the era produced. And the implementation failure rate did not move a single point. The best people, dropped into organizations that buy technology before assessing whether they can absorb it, produce the same 70-to-80% failure rate as everyone else. Talent was never the problem.
Hold the technology constant: consider one vendor, ConvergentIS, and one platform. In December 2025, Spend Matters rated it 9.7 out of 10 on customer satisfaction, a perfect 10 on user experience, and number one in five separate categories. The technology, by an independent analyst’s measure, genuinely works. And yet the same vendor, with the same platform, walked away from major accounts — terminated the engagement before deployment — because the client met them with the phrase that has killed transformation for decades: we have always done it this (our) way.
That is the whole experiment, and it is as clean as this work ever gets. Same vendor. Same platform. Same method. The only thing that varied between the accounts that earned those scores and the accounts the vendor walked away from was whether the organization showed up ready to change. The technology rating was accurate. It was also non-determining. A perfect platform dropped into an unwilling organization becomes shelfware, and the vendor was disciplined enough to see it coming and refuse the deal.
Now look back at the case that started all of this, in 1998. A defense-sector supplier was about to lose its contract — next-day delivery had collapsed to 51% against a 90% requirement. They asked me to automate their system. I asked them what time of day the orders came in. The question seemed irrelevant to them, which is exactly why it mattered: most orders landed around four in the afternoon, because the service technicians were incentivized on call volume and sandbagged their parts orders to the end of the day — pushing them into the late-afternoon customs window and turning a hundred-dollar part into a thousand-dollar one. No one would ever have told you that. It was in no process document. I found it by going to the floor and asking — Genchi Genbutsu — not by reading the reports.
That is the difference between modeling what people say they do and discovering what they actually do — and it is the reason traditional solution mapping cannot reach the variable that matters. Solution mapping records the stated process. The determining variables live in the gap between the stated and the actual: the incentives, the workarounds, the things people do but never report. Map the stated process and deploy onto it, and you have optimized a system that does not exist. That is the 70% failure rate, in one sentence.
Only after that operating reality was understood and corrected did the technology follow — and next-day delivery moved from 51% to 97.3% within three months. The technology did not cause the result. It scaled a result that the readiness work had already produced.
And here is the piece that resolves the whole sequence. Why did the defense supplier do the hard readiness work when Boeing and the walked-away accounts did not? Because it was about to lose the contract. The existential pressure forced it to confront its real operating reality. Boeing’s pressures ran the other way — cost and shareholder demands pushed it to protect the status quo, not to confront it. The walked-away clients had no forcing function at all, so “we have always done it this way” won.
So the variable that determines the outcome is not the technology, and not even readiness in the abstract. It is whether something is forcing the organization to confront how it actually operates — before it chooses the tool. That question is answerable in advance. It is the question no hype cycle, no magic quadrant, and no solution map has ever asked, because it is not a property of the technology at all.
A word about how I can make these claims with dates attached.
None of what you just read was assembled after the fact to fit a thesis. The Cisco-and-Boeing comparison is in a comment thread from 2008. The Strand Commonality™ origin is dated to 1998. The Boeing infrastructure assessment is from 2025 — and it is the very thing that stopped me from claiming Boeing failed for lack of the platform. The ConvergentIS scores and the walk-away discipline are documented in 2025. The talent study tracks a cohort named in 2017.
I have published openly since 2007, against a body of work reaching back to 1998 — nearly three decades of contemporaneous observation, gathered in one place rather than created there. The reason that matters is not volume. It is that a record built in real time can disconfirm. A validation layer assembled afterward only ever confirms what its author already believes. This one doesn’t: the 2025 assessment ruled out the cleaner, more flattering version of this argument and required the harder one. That is not a weakness in the record. It is the proof that the record is real. The seams are the evidence.
I did not build the archive to sell an idea. I built it to keep an honest account of what was true at the time — so that the pattern, if it is real, would have to survive its own history rather than be rescued by a retelling. These are not illustrations. They are receipts.
And that is why a case like Boeing should reassure rather than unsettle. In a moment when the technology is moving fast enough to make everyone uncertain, the instinct is to look for stable ground in the tools. That is the wrong place to look — the tools are exactly what won’t hold still. The stable ground is underneath them, in the determining variable that hasn’t changed across ERP, e-procurement, cloud, and now agentic AI. The framework didn’t bend to absorb Boeing. It tested the case, declined the comfortable answer, and confirmed the determining variable through it. That is what a foundation does. It absorbs the hard case, and stays where it is.
The technology will keep changing. On the evidence of nearly thirty years, the variable beneath it will not. Which is why the most important work happens before the platform is ever chosen.
Truth Is Believing. Accuracy Is Knowing.
-30-
Share this:
Like this:
Related