The real problem: advisors no longer want to hear about «ROI»
I have spent enough years sitting on the technical side and on the board to recognize that the pattern only begins to emerge during the presentation.
The IT team or the CIO starts with architecture. They talk about models, platforms, capabilities. At some point, someone at the table asks: «And what does this do to the business?» And that’s where most data and AI projects start to die.
They don't die because of a lack of technical ability. They die because of a lack of commercial rigor.
An investment board is not evaluating whether the technology works. It assumes that it does — that’s why you were hired or promoted. What it is evaluating is whether you, as the person responsible for that investment, understand the risk you are asking them to take with the shareholders’ capital.
«The »ROI” no longer convinces anyone in a board room. They have heard it hundreds of times, almost always without any operational backing. A return number without a specific business decision behind it is a promise, not a thesis.
The difference between a project that gets approved and one that gets shelved is almost never in the technology. It’s whether the presenter speaks the language of the board — capital, risk, margin — or the language of IT — features, platforms, roadmap.
This article is about how to cross that bridge. Not with storytelling. With structure.
The case: how the decision that was ultimately approved looks
It is worth starting with a pattern that we have seen repeated in manufacturing, because that is where it is most clearly noticeable.
The first version of this type of project almost always presents itself as a catalog of capabilities: sensors, OT/IT integration, predictive models, a dashboard with plant visualization. Technically solid. Commercially orphaned. One consultant cannot approve a catalog — he doesn’t know what he’s buying in terms of business.
The version that does convince starts differently. It doesn't open with the platform. It opens with a concrete operational decision: reducing the cost of production lost due to unplanned maintenance and variation in OEE (Overall Equipment Efficiency).
That reformulation changes everything that follows. The request for budget is no longer for «a data and AI project in the plant.» It is for a specific decision: how much capital are we willing to risk to recover the margin that is currently lost due to unplanned downtime and quality variability?
This is the approach behind what Grupo Scanda calls plant operational intelligence — a best practice concept, not the diary of a particular client: connecting OEE, quality, maintenance, and the supply chain into a single data model, with the practice of Factory 360 as the way we execute it. The business case presented to the board does not talk about sensors or data architecture as the central argument. It talks about impact on OEE, reduction of unplanned downtime, and savings that in implementations of this type have exceeded $2 million dollars annually when the project is operating at full capacity.
Technical depth — integration OT/IT, With predictive maintenance models, the digital twin of the asset — it’s still there. But that’s not the argument. It’s the evidence that the thesis is executable, not the thesis itself.
That is the change in attitude that a board needs to see: someone who is not selling technology but managing an investment with the same discipline with which they would manage any other capital of the company.
The 4-layer framework for building the thesis
What follows is the structure I use — and that I teach the teams I prepare to present to the board — to turn a data and AI project into a defensible investment thesis. Four layers. If one is missing, the thesis falters.
Layer 1 — Identification of the operational decision (the business lever)
Before mentioning a single data point, a single platform, or a single model, we have to answer a question: what business decision will change if this works?
No «we will have better plant visibility». That is not a decision; it is a desired state. The business lever is specific and actionable: «we will decide when to intervene on a team before it fails, rather than after». Or: «we will decide which SKU to produce first based on real margin, not on arrival order».
If in your organization no one can name the operational decision that changes, you don't have a data and AI project. You have an experiment with a project budget—and the advice, rightly, is getting increasingly harsh on that difference.
This layer is the responsibility of the business area, not of IT. If IT comes alone to build this layer, you have already lost before you even started.
Layer 2 — Documentation of the baseline (reality, without embellishments)
This is where most projects weaken, because documenting the baseline forces us to expose uncomfortable numbers: how much is being lost today, with how much variability, and with how much certainty that number is known.
A consultant will not believe a savings projection if you can't first show them, with precision, what the current cost of the problem you say you're going to solve is. Without a baseline, any improvement figure is a disguised result.
Documenting the baseline means: actual cost measured (not estimated by eye), source of that data, quality of that source, and the range of uncertainty that exists today around that figure. If the baseline has gaps, those gaps are also documented. A more respectful advice is to document honest baselines with declared gaps than a perfect figure without substantiation.
This layer takes more time than the teams want to invest. It is, without exception, the layer that most determines whether the thesis survives the questions of the board.
Layer 3 — The data lever (which specific data changes the decision)
Here—and only here—does the technical discussion enter. But it does so with a restriction: every data source, every model, every capability you propose must be explicitly connected to the decision of Layer 1.
The question that needs to be answered for each technical component is: what operational decision becomes possible, or better, with this specific data? If you cannot draw that direct line, that component does not enter the first phase of the thesis—it becomes a future phase, not the core of what you are asking to be approved today.
In this type of plant operational intelligence project, the data lever is not «having all the data from the plant.» It specifically refers to the combination of maintenance, quality, and equipment availability data that enables you to anticipate a failure before it stops production. Everything else—the rest of the data model, advanced analytics, the full catalog of use cases—lives in later phases, not in the initial thesis.
This discipline avoids the most common mistake: presenting a data and AI project as a comprehensive transformation when what the board needs to approve is a limited, measurable bet with a clear path to the next phase.
Layer 4 — Cancellation criterion (when to stop the project if there is no traction)
This is the layer that makes the difference most between those who manage capital and those who sell technology. And it is almost always the layer that no one brings to the presentation.
A board of directors not only wants to know what success looks like. They want to know, with the same clarity, what the sign that this is not working looks like—and what to do when that sign appears.
The cancellation criteria are defined before the project starts, not after six months of inertia and no one wants to be the one to stop it. It is defined in concrete terms: if in X weeks no movement is observed in the Capa 2 metric, the project is stopped, the hypothesis is revised, or the capital is reassigned.
Bringing an explicit cancellation policy to the presentation does not weaken the thesis; it strengthens it. It tells the board that the person asking for the capital understands that they are also responsible for recognizing when the bet is not working—and that they will not need the board to stop the project for them.
The questions the council will ask — and for which layer you are preparing yourself
If you built the four layers well, you already have the answer to the questions that an experienced board will ask. If you didn't build them, those same questions will show the gap in real time, in front of everyone.
- «What specific decision changes if this works?» — That’s the question of Level 1. If the answer sounds like a vision or a desired state instead of a specific operational decision, the advice will notice it before you finish the sentence.
- «Where does that projected savings figure come from?» — That is the question of Level 2. This is where it is noticeable whether you have documented the baseline rigorously or whether you are presenting a projection without a verifiable starting point.
- «Why this data and not another? Why not start with the full model at once?» — That is the question of Layer 3. The correct answer is not to defend the full scope. It is to explain why you limited the first phase to the data lever that drives the decision of Layer 1, and at what point the rest comes in.
- «And what if in six months we see nothing? Who stops it, and when?» — That's the question of Level 4. Very few teams come up with an answer to this. Those that do usually leave the room with the approved capital — because the board has just taken away the risk of having to be the ones to stop a project that has already taken on its own life.
Note something important about this pattern: the four questions are not technical. They are capital management questions. An experienced advisor is not going to audit your data architecture in the room — for that, there are technical committees and subsequent due diligence. What he or she will audit is whether you understand the risk you are asking to be approved.
Preparing for these four questions is not an exercise in last-minute communication. It is the natural consequence of having built the four layers well from the beginning. If you prepare for the questions without doing the groundwork, the advice is detected—with the same ease with which it detects a ROI without substantiation.
Rigidity is an act of corporate governance
It’s worth saying this without embellishment: constructing an investment thesis with these four layers is not a communication exercise. It’s an act of corporate governance.
An executive board has the fiduciary responsibility to allocate capital where the risk is understood and managed, not where the presentation was most convincing. When a team arrives with a named operational decision, a documented baseline, a limited data lever, and an explicit cancellation criteria, it is facilitating the board in fulfilling that responsibility. When it arrives with an impressive demo and an unproven ROI, it is asking the board to blindly trust it.
That distinction — between asking for trust and facilitating governance — is, in my experience, what determines whether a data and AI project is approved on the first presentation or whether it is shelved indefinitely after the second.
The technology is the easy part in all of this. The hard part, and what really evaluates a recommendation, is whether the person leading the project manages the capital with the same rigor with which they would manage any other strategic decision of the company.
Next step
If you have a data and AI project that has already been rejected once —or that you still don't dare to take to the board because you know the thesis can't handle the questions—that's exactly what we work on at AI Value Discovery from Grupo Scanda: a two-week diagnosis that builds the four layers of the thesis with your team, with a roadmap of GO/NO-GO initiatives ready to present.
Write to us. Let's see if your project is ready for the board, or if it still lacks rigor before asking for the capital.
Español 
English