The Governance Gap

Enterprise AI is failing at the same 80%+ rate that enterprise data warehouses failed at in the 1990s, and for the identical root cause. Boards are asking why 2025's AI investments are not producing measurable ROI. The answer is not better technology.

It is a discipline that already exists, was already proven across thirty years of enterprise data delivery, and was already paid for by the failures of the 1990s. AI governance is a requirements methodology problem, not a technology problem.

That makes it a governance decision, not a procurement decision, and it belongs at the board level. The Kimball Lifecycle, the requirements-driven approach that solved enterprise data warehousing, provides the structural foundation for governing AI in the enterprise. Organizations that adopt it will avoid the failure modes that are presently consuming their AI budgets.

Three decades ago, enterprise data warehouse projects failed at an 85% rate. Gartner originally estimated 60% and revised the figure upward after analyst interviews. The Standish Group's CHAOS Report identified incomplete requirements as the single largest factor in IT project failure.

Ralph Kimball and Margy Ross documented why these projects failed: the technology was not the hard part. The hard part was the requirements work. Understanding what business questions needed answering, how the organization's processes actually worked, and how data needed to be structured to support real decisions. The Kimball Lifecycle codified the answer: start with stakeholder interviews, organize by subject area, deliver incrementally, treat the system as a living asset.

The parallels between data warehouse failure in the 1990s and enterprise AI failure today are not approximate. They are structural:

Enterprises should not pay again, in AI dollars, for a lesson the data warehouse industry already paid for in DBA salaries.

Peer enterprises that have published on this problem are converging on the same conclusion. Salesforce, NYSE, Cognizant, and Microsoft have each described AI deployments where the determining factor for success was the organizational knowledge work (encoding standards, conventions, and domain context), not the model selection. The publicly visible failures share an opposite signature: large licensed deployments without convention encoding, declining usage within twelve months, and quiet write-downs in subsequent quarters.

Each quarter of ungoverned AI deployment compounds three costs:

• •The repetition cost continues unchecked.
• •The remediation cost grows. Code generated without governance must eventually be audited, refactored, or rewritten to meet compliance posture, and the volume of code in scope grows monthly.
• •The opportunity cost grows. High-value AI use cases that depend on encoded organizational knowledge (agent-driven workflows, AI-assisted compliance, model-risk-managed automation) cannot be deployed until the foundation is in place.

The requirements phase typically requires three to six weeks. A board that defers it for a quarter is choosing to add a quarter's worth of ungoverned code to its eventual remediation surface.

The methodology is the Kimball Lifecycle, extended to make AI feature design a first-class concern alongside business intelligence and dimensional modeling.

It works because it addresses the root cause that kills most projects before they start: skipped requirements. The methodology has four properties that matter at enterprise scale.

Engineering organizations with strong cultures frequently conclude they can build their own AI governance framework. They are technically correct that the underlying technology is not the barrier. They consistently underestimate the timeline because they conflate technology implementation with methodology design.

The technical infrastructure (encoding conventions, routing requests, gating operations) is a matter of weeks. The methodology design takes months: determining what to encode, how to structure the governance, which conventions to prioritize, and how to handle conflicts between teams. It requires experience the organization does not have because they have never done it before.

Build-vs-buy calculations that include only technology cost systematically understate the true timeline, because they count the infrastructure weeks but omit the methodology months.