Same technology. Opposite outcomes.

The organizations behind the last decade's most visible AI failures ran the same technology that worked elsewhere. Watson-based oncology AI failed at MD Anderson; Cleveland Clinic ran AI-assisted diagnostics across its cardiology practice with measurable clinical outcomes. Amazon scrapped its AI recruiting tool; Unilever deployed AI screening for entry-level applicants and increased applications from underrepresented candidates by seventy percent. JPMorgan's COIN system eliminated 360,000 hours of annual manual work. McDonald's pulled its hundred-location AI pilot before the quarter ended.

Same technology. Opposite outcomes.

That's the question this book is built around. The technology is not the variable. The vendor is not the variable. The investment level is not the variable. Two organizations spend on the same class of system, run it through the same evaluation process, and one of them earns the press release while the other earns the lawsuit, or quietly buries the project, or worse: keeps running a system that does not work because nobody wants to admit they were wrong.

The pattern is consistent enough that you can name it. Research examining fifty-one enterprise AI deployments found that ninety-five percent of failures traced to organizational factors, not technical ones. The model performed as designed. The data was sufficient. The vendor delivered. And the deployment still failed, because the conditions around it were wrong.

The organizations that succeeded had made five specific decisions before execution began. The ones that failed had skipped at least one.

Who this book is for

This book is written for the C-suite executive who approved the budget, owns the outcome, and is tired of explanations that don't explain anything. It is written for the operator who has to make AI work inside a real organization with real constraints, not a clean lab environment. It is written for the board member who needs to read one piece on AI and have the discussion they need to have with their CEO. And it is written for the consultant who is staring at a client's failed AI initiative and trying to figure out what actually went wrong, because the project status reports say nothing useful.

It is not written for the data scientist building the model, the ML engineer choosing the framework, or the platform team deciding between vendors. Those readers will find the technical chapters of The Operating Advantage more useful. This book sits one level up: the decisions that happen before the build starts, and the conditions that determine whether the build can succeed regardless of who builds it.

What the next 290 pages do

The book names the five conditions as the Discipline Staircase: Intent, Scope, Workflow Truth, Data, Structure. Each is a gate. The next step does not hold without the one before it. Skip Intent and you cannot scope. Skip Scope and you build the wrong thing well. Skip Workflow Truth and you build the right thing in a process that does not exist. Skip Data and you train a model on a fossil record of how your organization actually operates, instead of how it was designed to. Skip Structure and you ship a system into a container that cannot govern it.

Each condition is proved through real organizations. MD Anderson's $62M Watson failure. Cleveland Clinic's cardiology deployment. Amazon's recruiting tool. Unilever's hiring screen. JPMorgan COIN. McDonald's drive-thru pilot. NHS England. Epic's sepsis prediction model. Some of these you know. Some you don't. All of them ran the same technology that worked elsewhere. The difference, in every case, was one of the five.

By the last page, the reader has a framework strong enough to look at their own AI initiative and name what is missing. That naming is the discipline. Once you can name it, you can fix it. Once you can fix it, the technology starts behaving the way the vendors told you it would.

That's the advantage.