Most AI projects fail at scope.
Most AI projects do not fail at the technology layer. The technology layer has gotten boringly reliable, fast. Most AI projects fail at the scoping layer. The owner had a problem; the scope did not name the problem precisely; the build wandered for two quarters; the deliverable solved a different problem than the one the owner cared about.
A tight scope has four elements. Each one has to be answered before any architecture is drawn. We will walk through each.
Element I: outcome.
The outcome is what changes about the business when the system is live. Not what the system does (that's the architecture). Not what the system uses (that's data). The outcome is the line item on the P&L that moves, or the operational metric that improves, or the named bottleneck that is removed.
The discipline is to write the outcome as a sentence with a number. "Quote turnaround drops from 6 hours to 30 minutes for the first 80% of inbound RFQs." "Annual unbilled-time leakage at the operation reduces by $1.2M, validated against last quarter's actuals." "COI (certificate of insurance) turnaround drops from 18 hours to 30 minutes, and the agency's COI-related retention loss reduces by 50% over the next 12 months."
If the outcome cannot be written as a sentence with a number, the scope is not ready. A meaningful share of the audit calls we run end here, with us telling the prospect to come back when the outcome is named.
Element II: interface.
The interface is where the human meets the system. This is the element most builds get wrong, because the interface is treated as an afterthought. It is not. A system that does brilliant work behind the scenes, surfaced through an interface the operator hates, is a system the operator works around.
For most workflows in mid-market operators, the right interface is not a new tool the team logs into. It is the existing tool the team is already in: ServiceTitan, CCH Axcess, iManage, Applied Epic. The AI runs in the background and writes its output into the existing tool. The operator does not see "the AI"; they see a better-prepared queue in the system they already use.
The discipline is to ask: where does the operator currently make this decision, and how does the AI's output get into that exact spot? If the answer is "we'll build a separate dashboard," the answer is wrong. Build the AI to write into the spot the operator is already in.
Element III: data.
The data element answers two questions: what data does the system need to read, and what data does it need to write?
The reads are usually obvious once the outcome is named. Quote turnaround needs RFQ (request for quote) documents, the part library, the customer history, current material costs. COI (certificate of insurance) generation needs client policy, additional-insured request specifics, carrier templates. Billable-hour reconstruction needs partner activity in iManage, calendar, Teams call history.
The writes are where scopes get into trouble. The system needs to write back to the system of record (the one system that holds the official copy of a record), not to a parallel universe. ServiceTitan AI writes Jobs into ServiceTitan. CCH Axcess AI writes binder entries into CCH Axcess Document. The AI is a layer, not a parallel system.
The discipline is to inventory both reads and writes before the build, with the source of truth named for each. "Customer master is in ServiceTitan, period." "Time entries write to iManage Time, period." Vagueness here causes scope drift later.
Element IV: guardrails.
The guardrails are what the system is not allowed to do. The discipline is to name them in advance, in writing, and review them with the operator.
Examples of well-named guardrails: "The system never sends an email to a client without a CSR (customer service representative)'s one-click approval." "The system never modifies a tax return; it only surfaces flags to the reviewer." "The system never bypasses iManage permissions; queries run with the user's actual access." "The system never auto-quotes above $50K without a senior estimator's sign-off."
Operators who feel comfortable with guardrails get comfortable with the system. Operators who don't, don't. Skipping this element is the most common reason a technically correct system fails to gain adoption.
The one-page scope.
A tight scope fits on one page. Outcome (one paragraph with a number). Interface (one paragraph naming the exact existing tool the AI writes into). Data (one paragraph listing reads and writes with sources of truth). Guardrails (a numbered list of 5-8 lines).
If the scope does not fit on one page, the scope is not tight. If it fits on one page but the elements are vague ("we'll figure out the interface in week 3"), the scope is not tight. The build that follows a tight scope is a 4- to 6-week engagement that ships, ColabContent's standard published build cycle. The build that follows a loose scope is the project that becomes a slide in the post-mortem deck two quarters from now.
Tomorrow.
Lesson 6: change management. The system works. Your team hates it. Now what? A tightly scoped build removes friction from a workflow, but the people who used to own that workflow still have to adopt the new one, and that adoption is its own separate project with its own separate risks.