The first yes is small
I am not going to ask you to reorganize the company. I am going to ask for a few weeks to find out what your own stalled portfolio is worth, and then, if the number deserves it, a quarter or two to prove the model in one domain the rest of the company can see.
1. The diagnostic (Two to four weeks)
Find the domain architecture your company already has by looking at how work actually moves, audit the stalled and duplicated portfolio, and find the first card, the smoking gun several stuck projects are all waiting on. Priced like a small project, and the only rung you have to say yes to.
Deliverable: Your own number, from your own portfolio, and the first domain and first card to prove it on.
2. The proof (One to two quarters at a small company; longer by size)
One domain, one or two small teams owning the first shared piece of the company, one ownership team taking one card. The smallest version of the governing layer stands up (identity inherited from what you already run, one gate every model call passes through, the outcome board, spend metering), and the executive team meets as a governance body for the first time.
Deliverable: A working example, live and in use, that other teams have started to build on, and the governance structure for what comes next, defined around it.
3. Interim transformation leader (Through the change)
The separate, almost consulting-like seat reporting to the CEO, with authority over the control plane from day one. Runs discovery, the first team, the training of the first owners, and the sequencing of the domains that follow. Its measure of success is that the company no longer needs it.
Deliverable: The control plane run through the change, then handed to its permanent owner or kept, as the proof decides.
4. Platform definition (Alongside the proof)
The model needs specific capabilities: spend tracking per outcome, an org-wide memory layer, identity enforced for agents, observability, the outcome board, the catalog, a single governed gateway for every model call. Some exist, some are emerging, some nobody has built. I define which is which for your company and assemble the partners or the build for each.
Deliverable: The capability map: what exists, what to partner on, what to build, and in what order.
The projects that don't die
Every transformation I have run has had the same shape financially, and it is not the shape Boards expect. There is an upfront cost to build the initial team, and it is offset faster than anyone believes, because the first thing a transformation does is stop projects. Some are consumed by it: the thing they were trying to build is what the new model produces as a matter of course. Others were never really projects; they were products with an end date pretending to be a project, and they are either owned properly or ended.
You already know which projects these are. They are the ones that do not die: the initiative on its ninth change request, the program that always needs "others" to finish it, the system that has been ninety percent done for two years. Gartner expected at least 30% of generative AI projects to be abandoned after proof of concept by the end of 2025, and BCG found 74% of companies have yet to show tangible value from AI at all. These are not failures of the people running them. They are what happens when a project needs a piece of the company nobody owns, most often the customer, whose data is scattered across the CRM, order management, support, email and social with no single owner. The segmentation effort, the customer cost analysis, the field tool for sales, the shipping optimization that supply chain and e-commerce each tried to build: these are the money, and they are already on your books.
What the diagnostic produces
The method is simple. We look at how projects are created and tracked, which parts of the organization are always involved beyond IT, and what people say always gets in the way. Then we draw the lines of that work between the boxes on the existing org chart, and where the same lines keep appearing we have found a domain. Alongside that we audit the stalled and duplicated portfolio and find the first card, usually a smoking gun, three or four stuck projects all waiting on the same unowned thing. What you get is your own number, from your own portfolio, and it is the only number I would ask you to believe. The full documents behind these pages (the operating model, the platform it runs on, the complete role map) are read-aheads I send after a first conversation, and the diagnostic is where they start to be about your company instead of about the model.
What could stop this
Some of the technology does not yet exist in a form a company can buy, which is why the diagnostic confirms what is plumbing before a quarter is spent building it. Some of your leaders do not understand AI, and the model is designed so they do not need to. But a leader who will not accept ownership cannot lead a domain, and that is a decision you will have to make. Vendors will tell you their product is the platform; nothing should be bought that cannot be replaced. And the pattern of expectations I have had to say twice at every company: started small, this grows organically and keeps growing; used as a wholesale change too early, it fails fast and costs far too much. A Board that asks for more, sooner, is asking for the failure mode.
The ask
I am not asking you to reorganize the company. I am asking for four things that let us find out, in a quarter or two, whether you should. The approach: try this model in one domain rather than adopting AI one department at a time. The patience and the money to reach the proof: a quarter or two, a modest budget, and the discipline not to demand a status deck in week three. A few people, moved under a new leader, to form the first domain; one or two you may need to hire. And a grounding on what happens after: if the proof works, the next step is the next domain, and I would rather the CEO and the Board decide now, in principle, that success leads there than discover in six months that a working example is politically inconvenient.
That is the whole request. The room that froze did so because nobody in it had been given those four things, and giving them is the most consequential decision a CEO will make this decade, not because the technology is remarkable, though it is, but because the organization that can use it has to be chosen on purpose.