The submissions coming into our Wreck Index point at one cause of AI project failure more than any other, and it isn't the model, the vendor, or even the stakeholders. It's the data. Specifically, it's the gap between what everyone assumed about the client's data in the sales cycle and what turned out to be true in week six, after the SOW was signed, the team was staffed, and the number was fixed.
Every experienced consultant has met this gap. The CRM that turns out to have three different definitions of "customer", none of them enforced. The document repository that's 40 percent scanned images of documents rather than documents. The "single source of truth" that's actually four sources of assertion, maintained by people who don't attend the same meetings. The permissions layer nobody can explain, guarding data nobody can therefore use.
None of this is discovered by asking the client if their data is good. Clients believe their data is good, in the same way everyone believes their own driving is good. It's discovered by looking. So look before you scope, and charge for the looking.
The two week audit
Here's the shape of the paid data audit we'd run before scoping any serious AI delivery. Two weeks, fixed fee, standalone deliverable. Small enough that a client can approve it without a procurement odyssey, real enough that its findings change the shape of the main engagement, and, not incidentally, it's the best qualification tool ever invented, because a client who won't fund two weeks of looking at their own data was never going to survive six months of building on it.
Days one to three: find out what actually exists. Not the architecture diagram version, the real version. Which systems hold the data the use case needs, who owns each one politically as well as technically, what state the documentation is in, and how data actually moves between systems today (the answer is CSV exports and a heroic individual named something like Dave more often than anyone admits).
Days four to seven: sample the actual data. Pull real samples from each source and measure the boring things: completeness of critical fields, duplication rates, format consistency, how current the records are, and whether identifiers actually join across systems or just look like they should. This is where assumptions die. Every number you produce here is a number that would otherwise have emerged in delivery, at ten times the cost and with your name attached to the surprise.
Days eight to ten: test the specific data against the specific use case. Generic data quality scores are decoration. What matters is whether this data can support that use case. If the plan is a support copilot grounded in the knowledge base, sample fifty real support questions and check whether the knowledge base actually contains correct, findable, current answers to them. Frequently it doesn't, at which point you've just discovered the real first phase of the engagement, and it isn't AI. It's content remediation, priced accordingly.
Days eleven to fourteen: the political layer, and the write up. Who has to approve use of this data, and have they actually approved it or has someone assumed they will? Are there regulatory or contractual constraints on it (customer data with usage restrictions buried in contracts is a classic late stage wreck)? Where does data governance actually live in the org chart, and does it function? Then write the findings into the deliverable: a data readiness verdict per source, the specific gaps that block the use case, remediation effort in honest ranges, and a recommendation. Green, proceed to scoping. Amber, remediate these named things first. Red, this use case is not ready, and here's the one that is.
Why consultants skip it, and why they're wrong
The pressure to skip straight to the build is real. The client is excited about AI, not data plumbing. The vendor demo worked beautifully (on the vendor's data, a detail that does a lot of unexamined work). And proposing an audit can feel like stalling while a competitor promises to start Monday.
But walk the incentives. If the data turns out fine, the audit cost two weeks and bought certainty, plus an evidence based scope that protects both sides. If the data turns out broken, the audit just saved the client months and saved you from being the consultant of record on a wreck. There is no branch of that tree where looking first was the mistake. The competitor who started Monday is the one who inherits the CSV exports and Dave.
And the deliverable itself builds the kind of trust that wins the main engagement. A document that says, with samples attached, "here is precisely what your data can and cannot support, and here's the honest path" is rarer in this market than any demo. Clients notice the difference between someone selling them AI and someone telling them the truth about their own systems. One of our recurring findings, across submitted wrecks, is that the projects that died of data problems had consultants who suspected as much in week one and said nothing sellable about it.
Ask the questions before the questions get expensive. The Enterprise AI Discovery Question Bank has the full data infrastructure section ready to run, and the AI Solutioning & Scoping Guide shows where the audit verdict plugs into phasing and the SOW. And when the audit's done, whatever it found, submit the interesting parts to the Wreck Index, anonymously, so the next consultant's benchmark gets sharper. The bodies are always in the data. Better paid to find them early.