Why AI projects fail: the Field Report
Short pieces on why AI projects fail, written about problems you may already recognize and followed back to their cause. Read one in a sitting, and use it to decide whether the problem is on your team.
Latest
Missing records between systems: why the job says it succeeded
How a record reaches one system and never the other, and the check that compares both ends.
Amit Govil · October 22, 2026
Read the perspective










About the Field Report
What is a perspective on why AI projects fail, and what does it leave out?
A perspective is a short observation from delivery work. It opens with the answer, describes a situation you will recognize, traces it to the mechanism underneath and says what changes it. A diagram appears only where it does the work a table of findings would.
It leaves out the evidence base. A perspective makes no claim about how common a problem is and names no client, so the weight of the argument sits with the research reports behind it.
The problems the series keeps returning to
Pilots that prove a model and then stop: The handover nobody scheduled between pilot and production is about the date no plan names, and a companion piece lists what a pilot gets for free.
Decisions agreed and never carried out: Agreed in the meeting, owned by no one describes a room where everyone leaves believing someone else will act. Its companion asks why a decision keeps coming back.
Systems that disagree: the piece on a record held by one system and missing from another covers a fact that never arrives, and a companion piece covers copies of one fact drifting apart.
Change that gets dearer: Why the third change costs more than the first follows what each change leaves behind. The next piece asks why every change now needs a meeting.
Buyers who ask an assistant: The buyer who asked an assistant describes a loss that leaves no trace in any record, and its companion asks why a competitor was named instead.
Work that waits for one person: The process that waits for one person traces a step the process never named. The last piece asks what a team can't do while that person is away.
The example in a piece is a prop; the mechanism is what carries over to your team.
Read the perspective, or go straight to the report?
A perspective is enough when
- You want to know whether a problem on your team is the one described.
- You need the mechanism in plain words for a conversation with a colleague.
- You have one sitting and one particular team in mind.
Go to the report when
- You must explain how the failure forms to people who will challenge it.
- You need the method, the sources and the limits in front of you.
- You want the self-check to run on your own organization.
A perspective costs one sitting and helps you recognize a problem. It can't show how the problem forms in your case, and it states no rate. The report can, if you have time for the longer read.
Where a problem is set out in full
Each problem has a longer treatment elsewhere on the site. Find yours in the table when a perspective has told you enough to want the whole argument.
| If this is your problem | Go deeper with |
|---|---|
| A pilot that worked and never reached daily use | The report on why AI pilots stall, and the AI-to-Production Readiness Assessment |
| A decision nobody carries out, or nobody keeps closed | The report on ownership of live AI systems, and the AI Governance Assessment |
| Systems giving a customer different answers | The report on systems and data that stop agreeing |
| Change that costs more each time | The Technology and Architecture Risk Assessment, which asks about change and dependencies |
| A buyer who asks an assistant and never finds you | The report on being found through AI assistants, and the AI Search Visibility Checklist |
| A process that waits for one person | The Technology Architecture Review Checklist, with its section on ownership and knowledge |
How is a piece on why AI projects fail made, and where does it lead?
A situation earns a piece when it recurs across different businesses and its mechanism can be stated. We describe the example so that no client could be recognized, and cite a law or standard only after reading the passage it supports. Drafting tools may help. A person checks every fact, and the piece goes out under that person's name. We revisit a piece when the report or source behind it changes.
If a piece describes a problem you have, the free tools give a first scored read in your browser. AI Consulting is the service for pilots and ownership, and Technology Consulting for problems about systems and change.
What do readers ask about the Field Report?
Should I read a perspective or go straight to the report?
Read a perspective to check whether a problem on your team matches the pattern, or to put the mechanism in plain words for a colleague. Go to the report when you must explain the failure to people who will challenge it, or want the method and self-check.
Does a perspective say how common a problem is?
No. It describes how a failure forms and what changes it, and leaves the weight of evidence to the research reports behind it. Test the mechanism against your own team, because how often the pattern turns up elsewhere won't settle your case.
Are the examples real clients?
No client is named, and each example is described so that no client could be recognized. Treat it as a prop. The mechanism is what carries over, so ask whether the same steps are happening in your own work, whatever your industry.
How does a situation earn a place in the Field Report?
It has to recur across different businesses, and its mechanism has to be one we can state. A person checks every fact against its source and puts their name to the piece. We revisit it when the report or source behind it changes.
Does one of these sound like a team of yours?
Tell us which team it is and which step waits. We will say whether it matches the pattern described or points somewhere else.
