In 2024 and then in 2025, management secured its AI budget. It distributed it so that the topic could progress on several fronts at once: widely deployed Copilot licences, three or four POCs led by different teams, and an internal chatbot to show that generative AI had not remained just a conference topic. The watchword was clear: move fast, show activity on all fronts.
The Executive Committee is now asking for an evaluation in order to decide on the 2027 budget. And the evaluation that is emerging can be summed up in a single sentence that no-one wants to say out loud in a meeting: lots of trials, zero output.
The problem is not the lack of results. One of the POCs has convinced the business teams, to the point that they are already using it in their daily work. The problem is that the budget has been used up, and there is no objective criterion to explain why this one deserved to continue rather than another. The ROI of AI in business is judged on this kind of trade-off, not on the number of POCs launched during the year.
This situation affects mid-sized companies just as much as large corporations. The context changes, the budget changes in size, but the decision that has to be made in front of the Executive Committee remains the same: deciding what to stop, what to continue, and on what basis to assert it.
This is not an isolated issue. According to Gartner, at least 30 % of generative AI projects launched by businesses are expected to be abandoned after the POC phase by the end of 2025, for four main reasons: poorly demonstrated business value, costs rising faster than expected, insufficient risk controls, and inadequate data quality (Gartner, July 2024). The PoC proves that a technology works in a controlled setting. It almost never proves that it is worth the expense required to industrialise it.
This is where the method of allocating the AI budget becomes problematic. Funding three or four POCs led by different teams, alongside a licence roll-out and an internal chatbot, creates the impression of covering the subject on all fronts. However, each POC was scoped separately, with its own success criteria, often defined by the team leading it. Comparing their respective value becomes an almost impossible exercise: one was judged on adoption, another on time saved, and a third on mere technical feasibility.
Result: when one of the use cases genuinely wins over the business units, to the point where they use it without being prompted, nobody can objectively say whether it deserves more budget than the others, nor how much would be needed to move to production. The next funding allocation is then decided on intuition or on who best defends their case in the Executive Committee, rather than on shared criteria.
This lack of method is not apparent when launching POCs. It becomes visible during the review, when you have to choose what to stop and what to scale up, with a budget that is not growing at the same rate as the ambitions.
Spreading the budget across several teams often responds to a genuine pressure: showing that AI is moving forward everywhere in the organisation, not just in a pilot department. This pressure is not illegitimate. But it comes with a hidden cost, which only becomes apparent the day a choice has to be made: the more use cases launched in parallel, the less common methodology there is to compare them with one another.
Dealing with this situation is not about choosing a winner among existing POCs. The real work begins before launching a use case, not after.
A rigorous framing poses the same questions to each candidate use case, regardless of the team sponsoring it:
Asked before the POC, these questions make it possible to compare use cases against each other on a common basis, rather than on the enthusiasm of the team defending them.
Without a common framework | With common framing |
Success criteria defined by each team | Common criteria for all use cases |
Production trajectory planned after the POC | Production trajectory considered right from the scoping stage |
Use cases that cannot be compared to each other | comparable use cases on a shared database |
Executive Committee decision based on enthusiasm | Executive Committee decision based on documented criteria |
Scoping does not stop at selection. It must also document, right from the start, what deployment into production entails: who needs to sign off on releasing the prototype, which data needs to scale up, and what controls must be in place for IT or compliance to accept it. Without this forward planning, the use case that most won over the business units remains stuck in precisely the same place as the others, between the POC and actual use.
This comparison also assumes that a single instance handles the framing, rather than each team separately. A streamlined committee, involving the IT department, the data department and one or two business sponsors, makes it possible to apply the same criteria to each candidate and make decisions without having to relive the debate for every new POC.
Asking these questions before funding the next use case changes the whole exercise of the following review: The executive committee no longer arbitrates between impressions, but between comparable dossiers.
At JEMS, this framing draws on the methodology we have built up over the course of our Cognitive Architecture assignments. It examines five key components of the use case, each scrutinised through seven fields of analysis, before combining two complementary methods to capture what cannot be found in any documentation: the unwritten rules applied by teams, the exceptions they handle from memory, and the checks they perform without even realising it.
This rigor, applied before launch rather than at the review stage, changes the nature of the question asked of the Executive Committee. We are no longer asking for a trade-off between disparate experiments. Use cases are presented whose value, risks and industrialisation costs have been documented from the outset on a consistent basis. Reviewing them then becomes an exercise in management rather than a posteriori justification.
The use case your business units adopted without being forced to has already proved the hardest thing to achieve. Losing it for lack of a scoping methodology would mean losing more than just a budget: the trust that the business units have started placing in AI.
The issue for the 2027 budget is not about finding more funds. It's about framing the upcoming use cases with the rigor that was lacking in today's.
If you are preparing this review for your executive committee, the JEMS teams can discuss with you the scoping method to implement before the next budget cycle.
