Importance of Customer Involvement in AI Projects
A cargo cult engagement has the title and vocabulary of a successful AI engagement but lacks the operating model that makes it work.
A Project That Sounds Like AI
A common assumption in AI work is that a project becomes a real AI project once it is described in the right language. The team has engineers with AI-oriented job titles, the kickoff uses the vocabulary of modern machine learning, and the work is labeled as an AI engagement. Under that surface, however, the project may run like any ordinary consulting job with a few new words attached. This article follows one case in which exactly that happened, and it teaches a way to tell the two apart.
What do you think happens?
If a project has AI job titles, ML vocabulary, and an AI label, is it running as a working AI engagement?
Reveal answer
No, the labels alone do not show that the work is set up to succeed.
The source describes a cargo cult engagement as one that has the title and vocabulary of a successful AI engagement but lacks the operating model that makes it work. The surface can look right while the underlying structure is missing.
Surface Versus Operating Model
A cargo cult engagement has the title and vocabulary of a successful AI engagement but lacks the operating model that makes it work. The surface is the part visible from outside: titles, kickoff language, and the AI label. The operating model is the set of arrangements underneath that decide whether the work can succeed: who approves what counts as success, whether the system can reach the data it will really use, who is involved in design, and whether the customer can see progress.
Both columns can share the same titles and vocabulary. The difference lies in the lower rows, the parts of the operating model the customer and the team either share or leave out. The rest of this article uses a single case to show how each missing part shows up in practice.
The Engagement at Week Four
The engagement was a portfolio-narrative generation system: an agent that drafted commentary for a regional financial-services firm's clients about their portfolio performance. The deal was 620,000 dollars for a fourteen-week engagement. At week four the project was visibly stuck.
Rather than rely on a general feeling that something was wrong, an examiner put five concrete questions to the project. Each question checks one part of the operating model. The questions cover evaluation approval, production data access, internal alignment, stakeholder involvement, and customer-facing visibility.
Tracing the stalled engagement by its operating model
The engagement looked productive from outside, with a kickoff, engineers, and steady activity, yet it was stuck at week four. Which parts of the operating model are missing?
- 1Check the data
The production portfolio data sat behind strict access controls. The access request was filed in week one and did not move.
- 2Check the response to the blockage
The vendor did not escalate the blocked request. It kept building against synthetic data it had generated itself.
- 3Check the design group
The customer's compliance team would have to sign off on client commentary, but it had been told about the engagement without being drawn into the design conversation.
- 4Check approval of success
The eval set, which determines how the system is judged, was built entirely by the vendor and never approved by the customer's sponsor.
- 5Check visibility
The engagement had a Slack channel but no dashboard. The sponsor had not seen a metric since the kickoff meeting.
Every part of the operating model that would have kept the project connected to the customer was missing, even though the surface looked like a working AI engagement.
Five Diagnostic Questions
The five questions form a diagnostic path. Ask them in order of a stalled project. A clear yes with evidence keeps the engagement on track. A no is a warning sign, and several no answers together signal a cargo cult engagement. The path below shows how each answer routes the examiner.
Production Data Left Out
The data question most directly exposes an engagement that looks productive from outside. The production data is the path the finished system must travel, yet the request meant to open that path was stuck. The data-access request was filed in week one and did not move, and the vendor team kept building against synthetic data it had generated itself. Over four weeks the engagement accumulated work against inputs the deployed system would never receive.
Synthetic data can be useful for early development. The problem in this case was that it was the only data the team used, and no one had confirmed that it resembled what production would supply. Assuming that synthetic data is sufficient for a production-ready system is a misconception this case corrects.
Compliance and Sponsor Arrive Late
The second part of the operating model concerns who takes part in the design. The customer's compliance team was the group that would have to sign off on any portfolio commentary sent to clients. It had been told about the engagement but had not been drawn into the design conversation. The vendor planned to bring compliance in at the end of week eight, once the system was already working.
The source notes that this plan could only lead to one of two outcomes: a six-week delay, or a forced redesign, depending on what compliance found. Compliance was not the only group left out of the design. The eval set, which determines how the system is judged, was built entirely by the vendor and never approved by the customer's sponsor.
Customer involvement is therefore not a courtesy added at the end of a project. The people who must accept the result have to shape what counts as success from the beginning. Otherwise the team is optimizing for a target the customer never chose.
Visibility Without a Dashboard
The final diagnostic question asks whether the sponsor can see the project's progress. The engagement had a Slack channel, which is a form of communication, but no dashboard. The sponsor had not seen a metric since the kickoff meeting. Her anxiety was rising for a specific reason: when her CEO asked how the project was going, she had nothing concrete to point to.
Informal conversation does not substitute for a regular, visible account of progress. A channel can hold many messages while the person responsible for the decision still has no measurable picture of where the project stands. Without that picture, the sponsor cannot tell whether the engagement is on track, and she cannot explain its status to people above her. A customer-facing dashboard gives the customer a steady view of the work, which is why its absence counts as a warning sign.
Mistakes in Judging an AI Engagement
Common mistake Judging an engagement by its titles and vocabulary
What it looks likeA kickoff that uses modern ML language and staff with AI job titles is taken as proof the project is set up to succeed.
Why it failsThe source says the surface can look like a working AI engagement while the operating model underneath is missing.
Do this insteadAsk the five diagnostic questions and check the evidence behind each answer.
Common mistake Continuing to build when a data request is blocked
What it looks likeThe vendor keeps building on synthetic data for weeks while the production data request sits unmoved.
Why it failsThe system is then tested against inputs it will never receive, and no one has confirmed the synthetic data resembles production.
Do this insteadEscalate the blocked request and treat the gap as a signal to act on.
Common mistake Bringing compliance in after the system is working
Why it failsCompliance must sign off on the output, so a late review can only produce a delay or a forced redesign.
Do this insteadDraw compliance into the design conversation from the start.
Common mistake Letting the vendor define success alone
Why it failsThe sponsor and customer must accept the result, so a metric they never approved may not match what they need.
Do this insteadHave the customer's sponsor approve the eval set from the beginning.
Common mistake Treating a Slack channel as visibility into progress
Checking a New Engagement
A new AI engagement has an AI-labeled kickoff, a strong engineering team, and a weekly Slack thread. The vendor is training its system on sample data it created, the production data request was filed three weeks ago and has not moved, the compliance team has not yet been briefed, and the vendor wrote the eval set by itself. Using the five diagnostic questions, which answers are warning signs, and what would you do first?
Hints
- Go through the five areas in order: evaluation approval, production data access, internal alignment, stakeholder involvement, and customer-facing visibility.
- Look at what the scenario says about the eval set, the data request, and compliance.
- The source's lesson on the blocked data request is to escalate it rather than keep building against synthetic inputs.
Key Takeaways
- An AI engagement can carry the right title and vocabulary while lacking the operating model that makes it succeed, which is the defining mark of a cargo cult engagement.
- Five diagnostic questions cover evaluation approval, production data access, internal alignment, stakeholder involvement, and customer-facing visibility, and several no answers together signal a cargo cult engagement.
- Building on synthetic data while a production data request is blocked leaves the system untested against the inputs it will actually receive.
- Late involvement of sign-off stakeholders, an eval set the customer never approved, and communication without a dashboard each prevent the customer from shaping the project or seeing its progress.