The conversation that should happen before any AI project kicks off

Most conversations about why AI projects fail point to the usual suspects: messy data, unclear requirements, and models that don’t generalize. While those matter, a deeper problem shows up earlier, does more damage, and has nothing to do with technology.

The people funding the project, the people whose workflows it changes, the people building it, and the people depending on its outputs all have completely different ideas about what success looks like. If those conflicting definitions never get surfaced, the project optimizes for one group’s goals while quietly failing the others.

The same project, four different scorecards

Take a demand forecasting initiative. Straightforward enough in concept. In practice, it touches at least four groups who show up at the table with different priorities.

Executives want to know if the investment was worth it. Their scorecard is margin improvement, inventory efficiency, and cost reduction. They’re comfortable with the strategic rationale and less focused on whether the model is actually ready for production.

The planning team, the people whose forecasting process is being automated, is worried about something else entirely. They’re asking whether their expertise still matters, whether they can trust the system when it recommends something that contradicts their instincts, and whether “augmenting their workflow” is a polite way of saying their role is being phased out.

The technical team monitors model accuracy, pipeline reliability, and scalability. Their main frustration is being pushed toward production before the data infrastructure, monitoring, and downstream processes are ready. That pressure to ship early often resurfaces later as the problems everyone blames on the model.

Supply chain and procurement need precise, trustworthy data to make decisions. Vendor commitments and replenishment plans depend on accurate forecasts, and a wrong forecast has immediate, tangible consequences. This team needs an AI system that prioritizes dependability over innovation.

None of these groups is wrong about their needs. The issue is that no one brought all four scorecards together at the beginning.

Understanding what pilot fatigue actually is

Deloitte’s State of AI in the Enterprise 2026 surveyed 3,235 business and IT leaders across 24 countries and found that only 25% of organizations have moved 40% or more of their AI pilots into production. The report names pilot fatigue as a real organizational risk: exhaustion from too many AI experiments running at once, with too little clarity about what any of them is for.

That’s a communication problem more than a technology one. Projects stall because teams can show local progress but have no shared understanding of when something is ready for production or who has the authority to decide. Pilots stay pilots because moving to production demands cross-functional agreement that was never defined at the start.

More governance won’t fix that. What helps is earlier, deliberate agreement on what success means for each team and what conditions have to be met before the work moves forward.

What really happens when you break down the silos

A Harvard Business School field experiment with 776 Procter & Gamble professionals found something worth sitting with. Working without AI, R&D specialists produced technical solutions and commercial staff produced market-oriented ideas, each group staying in its lane. With AI, that boundary softened. Teams generated ideas that carried both technical feasibility and commercial potential, which neither group had been reaching on its own.

The interesting part for AI project teams is what that says about shared context. When different kinds of expertise work from the same information, the output itself changes. Silos slow projects down, and they also cap how good the thinking can get. Cross-functional collaboration shows up in the quality of the work, which makes it a performance question rather than a cultural one.

That’s what good AI project team design is reaching for. Putting different roles in a room is the easy part. Creating the conditions where their perspectives actually combine into something better than any one of them could produce alone is the work.

The 70% that usually gets 30% of the attention

BCG’s framework for AI value creation is blunt about where effort should go. Their 10-20-70 rule allocates 10% of resources to algorithms, 20% to technology and data, and 70% to people and processes. Most organizations run that allocation backward. They invest heavily in algorithms, scrutinize data infrastructure, and treat people and process changes as deployment-phase afterthoughts.

A planning team that distrusts the model’s output is telling you something about the 70%. So is the supply chain leader asking for manual overrides. Those are the predictable result of underinvesting in the people and process work, and they surface at deployment because nobody addressed them earlier. Treating them as adoption problems to be solved after the fact, or as obstruction to be managed around, misreads what they are.

BCG describes three modes organizations use to create value with AI: Deploy (using existing tools to boost productivity), Reshape (redesigning workflows for substantial efficiency gains), and Invent (building new products or revenue streams). Most organizations stay in Deploy, which delivers modest returns. Reshape is where meaningful organizational change starts, and it demands careful communication planning.

Building for the long conversation

The AI projects that succeed are the ones where every stakeholder group understood the project’s goals, the realistic timeline, and their own role in making it work. Model quality matters less than that.

That sounds straightforward. In practice, it means tailoring communication to each audience. Executives have to see value as a long-term build rather than a quarterly transaction. Operations teams have to see a future where their expertise matters more. Technical teams need protection from premature pressure to ship. Supply chain leaders need confidence in the override process before they’ll trust the recommendations.

None of that happens in one meeting. It’s an ongoing design problem, and it deserves the same rigor as the technical work happening alongside it.