We Are Not Going To Say The Word AI Today

"We are not going to say the word AI today."

Those were the first words out of my mouth at a recent client workshop. Everyone was also instructed to resist the urge to suggest a solution, a tool, or a vendor for any problem that came up. Our only goal at the start was to define the current state, the problems we were trying to solve, and what solving them would mean for the organization.

Most of my days are spent talking about system implementations, data migrations, and AI governance. No matter the topic, the same pattern emerges. People want to solve problems. (Which is great!) But too often we are so focused on the solution that we forget to stop and dig into the problem we are trying to solve.

Why I Take The Tool Off The Table

In almost every workshop, someone names a problem, and when we dig into it, it turns out not to be the problem at all. It is a symptom. Here is how that usually sounds.

Someone says, "We need a new project management tool."

Ok, great! Where are projects tracked today?

"Excel, Word, Teams, SharePoint, Monday.com, and I think someone is using Smartsheet."

Ok. What is the plan to get everyone moved over to the new tool?

Crickets.

Is there a standard process for how a project gets requested and started?

More crickets.

Who owns maintaining the system once it is in place? Will it need to connect to any other system, like customer or project data, so there is one source of truth?

By now the room has gone quiet. Nobody is being difficult. The request was for a tool, and my questions were about everything around the tool.

What this means in practice is that there are already six places for tracking projects, and a new tool becomes the seventh unless someone decides how people get moved off the others and what happens to history. Without a standard intake process, projects keep arriving in whatever format the requester prefers, so the new tool fills up with inconsistent information from day one. Without an owner, the setup drifts and fields stop meaning the same thing from team to team. Without integration, someone ends up re-keying customer data from one system into another, which adds manual work instead of removing it.

We can't choose a project management tool until we define our project process, what our requirements are, and the change management it will take to get everyone there. The tool is the last decision in the sequence.

The other version I see often is a team forcing a system or process to do something it was never built to do. Usually, the people who need the outcome and the people who run the system never had the same conversation. They also may not know what their current environment can already do, what it does out of the box, what can be configured, and what would take custom work. So, they work around a feature that exists, or they ask for something new when a setting would have solved it. In both cases, the solution was aimed at the wrong target, and the only way to find out is to slow down and ask what is really going on.

That is why I take the tool off the table.

The concern with naming a tool early is that the conversation starts to organize itself around it. People describe problems in terms of what the tool can do, and the problems that don't fit quietly drop off the list. By the time the gaps show up, the budget is spent, the vendor is under contract, and the team is working around the tool instead of the problem.

What The Numbers Say

The research points the same way:

• Panorama Consulting's 2026 ERP Report found that more than a quarter of organizations went over budget on their ERP project. The most common reason was the unexpected need for additional technology. Panorama attributes that to poor system selection: organizations discover serious mismatches ("fatal misfits") late in the project, then add technology, scope, and custom builds to patch them. What this means in practice is that the system was chosen before anyone fully defined what it needed to do.
• In a June 2025 Gartner survey of 183 CFOs, 84% of finance organizations had implemented or planned to implement AI. Only 7% reported a high or very high impact. Most finance teams are spending on AI, and most are not yet seeing results they would call significant.
• S&P Global Market Intelligence found that 42% of companies abandoned most of their AI initiatives in 2025, up from 17% the year before. The average organization scrapped 46% of its proof of concept before it  reached production.
• McKinsey's 2025 State of AI survey found that 39% of respondents attribute any level of EBIT impact to AI, and most of those said it was less than 5% of EBIT. The roughly 6% of respondents at McKinsey classified as high performers were nearly three times as likely as everyone else to have fundamentally redesigned their workflows. This is self-reported survey data and shows a correlation, not proof of cause. It points in the same direction as the other studies: what happens to the process matters more than which tool gets installed.

Taken together, the technology is rarely what decides the outcome. The condition of the process and data it is dropped into usually does. Automating a bad process doesn't fix it. The same mistakes still happen, just faster and in larger volumes. And because a system is now doing the work, those mistakes are harder to spot. Nobody is reviewing each one by hand anymore, so they can sit in the numbers for weeks before anyone notices.

Mapping What Actually Happens

Once a room is comfortable describing problems without reaching for a fix, I walk them through mapping the current state. You document every step as it actually happens, which is often different from what the procedure manual says. The rule I hold to is document, don't solution, and the reasoning is practical:

• The first fix someone thinks of is rarely the best one, and committing to it early narrows out what the team is willing to consider.
• Exceptions hide in the details. A step that looks like an obvious candidate for automation often has judgment calls or downstream dependencies that only show up once every step is on the table.
• The handoffs between people and systems are where time and errors accumulate, and you will not see them unless you map the whole path.

I always use the same example. A customer emails to ask for  a refund.

1. A rep opens the email and creates a ticket.
2. The rep looks up the order and the customer's history.
3. The rep updates the ticket with the details.
4. The rep checks the return policy.
5. The rep approves or denies the refund and emails the customer.
6. The ticket is closed.

None of these steps are difficult, and all of them are manual. What makes the example useful is that three different kinds of work are sitting inside it:

• Creating the ticket and pulling the order history follow rules, repeat every time, and need no judgment.
• Deciding whether this customer qualifies requires judgment, because history can be messy, and the policy usually has gray areas.
• Nobody is measuring how often refunds are approved, how long they take, or how often a rep overrides the policy, so there is no way to tell whether the process is working.

Three Tools, Three Jobs

At some point the word AI does have to come back into the conversation, and when it does, it needs a specific job. That job looks different depending on which of the three tools fits the step:

• Automation performs repeatable, rules-based work. It executes and does not decide.
• Analytics shows you what is happening and where the problems are. It is also how you decide whether a process is worth automating, because you can estimate the return before you spend anything.
• AI interprets information and supports decisions where context matters. For anything customer-impacting, a person should review its recommendations until the results show it is reliable.

The value comes from using them together. Automation and AI act on the process; analytics measures the result, and the measurement improves the next round. If you skip measuring, you cannot tell whether any of it is working, which is why an AI pilot should have a defined metric and an end date before it starts.

Now You’re Allowed To Say AI

The word AI came up eventually that day. By then the room had a defined current state, a list of problems worth solving, and a shared understanding of what solving them would mean for the organization. Every tool conversation after that was easier, because there was something to measure against.

That is the work we do in GBQ’s AI Clarity practice. We assess how ready an organization is to adopt AI, map how the work happens today, and facilitate the leadership conversation that turns competing ideas into a sequenced, prioritized roadmap. The same approach applies to core systems and data projects, where overruns often trace back to the same cause: the system was chosen before the problem was fully defined.

If your last conversation about a new system or an AI tool started with a vendor demo instead of a problem statement, it is worth going back a step.

And if you are weighing a proposal right now and are not sure what it fixes, send me a note at afrye@gbq.com. I’m happy to talk through the questions I would ask first.

About GBQ Business Technology Solutions

GBQ's Business Technology Solutions practice empowers the growth of our clients across six disciplines: risk management, cybersecurity, IT governance, AI and automation, data and analytics, and business systems.

If this article raised questions that you cannot yet answer about your own strategy, the first place to start is with a conversation. GBQ’s Business Technology Solutions team  can assess where your organization stands today, prioritize use cases worth your investment, and help build the governance that lets you prove what AI is returning.

Net Effect is a biweekly column written by  members of GBQ's  Business Technology Solutions  team and published  in the firm's Bottomline newsletter.  Let us know if you have a technology question, and we can address it in a future column.