Building Easier AI

What to Write Down Before You Automate Anything

Ask a superintendent how a change order gets written and you will get four steps in twenty seconds. Somebody notices the scope moved, the office prices it, the client signs, the budget updates. Ask about the last ten change orders on their own job and those four steps turn into eleven exceptions: the one approved verbally at the Thursday walkthrough, the one the trade had already started, the one nobody caught until the invoice.

The four steps are what you would hand a software vendor. The eleven exceptions are the actual process.

RAND interviewed 65 people who build AI systems for a living and asked why those projects fail. 84% of the industry practitioners blamed a leadership failure rather than a technical one — most often, the organization misunderstanding what problem it was solving. EY, from its own automation work, prices that misunderstanding in weeks of schedule.

Neither is an argument against automating. Both are arguments about what gets written down first — and nobody tells you where to stop writing, which is the expensive half of the question.

The failure sits upstream of the software

RAND's report on why AI projects fail (RR-A2680-1, 13 August 2024) rests on 65 semi-structured interviews run from August to December 2023: 50 industry practitioners with five years' experience or more, across 50-plus organizations, and 15 academics. Failures driven by the decisions and expectations of business leadership were "far and away the most frequent causes of project failure" — 84% of those practitioners cited one or more of them as the primary reason AI projects fail, and the one ranked most damaging sits first on RAND's list: "industry stakeholders often misunderstand—or miscommunicate—what problem needs to be solved using AI."

The report also carries a more famous figure: more than 80% of AI projects fail, twice the rate of IT projects without AI. RAND cites that one from published estimates rather than measuring it — the 80% is the number that travels, the 84% is the number RAND collected. RAND flags a limit on itself, too: most interviewees were non-managerial engineers, so the findings "may be skewed toward identifying leadership failures."

One interviewee line is the argument for writing the process down before buying anything. AI algorithms, that person told RAND, are "poorly suited to automating the internal processes of an organization—especially when subjective human judgment is required to determine how those processes should function." Whether a Thursday verbal approval counts as a signed change order is a judgment your company makes. If nobody has written the rule, no vendor can install it.

The last thirty percent is where the schedule goes

EY's "Get ready for robots", published in 2016, is consulting experience from delivering robotic process automation across 20 countries rather than a controlled study. Its advice on scope aged well: "Automating 70% of a process that is the lowest-value, and leaving the high-value 30% to humans is a good initial target."

What the other 30% costs shows up in EY's own delivery-time table. A simple sub-process, skilled people, agile method: live in two to four weeks. But "continuing to automate the remaining 30% often involves convoluted exception handling or multiple diversions from the 'happy-path', so can double the time to deliver — adding two to four weeks."

The weeks are EY's own 2016 projects and matter less than the shape: exceptions cost a multiple of the happy path. A vendor quoting your change-order automation off the four steps has priced the cheap 70%; the eleven exceptions arrive later as a schedule overrun somebody absorbs.

What the undocumented version already costs, in hours

FMI and PlanGrid surveyed 599 construction industry leaders — 500 in the US, 49% general contractors, 36% specialty trades — for "Construction Disconnected" in 2018. PlanGrid, now part of Autodesk, sponsored it: a vendor document that at least publishes its sample frame.

The finding: 5.5 hours a week per person spent looking for project data — drawings, contracts, change orders, prior job records. With conflict resolution and rework on top, 35% of the working week goes to what the report calls non-optimal activities.

Run it on your payroll. Three office seats, 5.5 hours a week each, 48 working weeks, is 792 hours a year hunting for what the company already has. At a loaded $45 an hour, call it $35,600. Substitute your own seats and rate — writing the process down claws back part of that whether or not anything is automated after.

Only 16% call their workflows well documented

Lucid Software's AI Readiness Report, quoted in its own press release of 26 March 2026, found that only 16% of knowledge workers describe their company's workflows as "extremely well-documented." Lucid sells process-documentation software — the finding its marketing department would have ordered if it could — and the underlying report isn't fetchable, so the sample size couldn't be confirmed. Treat 16% as a weathervane, not a measurement.

No published figure measures the direct thing — what share of a trade's process lives only in somebody's head — so Lucid's 16% and FMI's 5.5 hours are the closest available, measuring the same hole from outside.

Write the exceptions, not the steps

Six things to write down, in this order, for one process:

1. The trigger. What starts it, who notices, how they find out.
2. The happy path. Four to six steps, each with a name and a real duration.
3. The exceptions, from the last ten jobs — the files, not your memory. Memory returns the four steps.
4. The rule for each exception. "It depends on the client" is a legitimate answer; write it down as a human decision point rather than smoothing it over. That is the 30% EY says to leave alone.
5. What done looks like, and how somebody checks it in under a minute against the contract, the budget line or the plan set.
6. Where the data lives right now. The spreadsheet, the email folder, the photo on somebody's phone.

Then the acceptance test: hand it to your newest PM and have them run one change order start to finish without asking a question. Every question asked is an exception you didn't write down — a sticky note today instead of a rebuild later.

Where to stop

EY's other warning is the counterweight to this article. Where a conventional software delivery method is used, it says, "excess documentation and governance gateways can quickly mean a process can take six to eight weeks to be ready to go live" — against two to four weeks for the same sub-process kept lean. A company that documents everything before touching anything has invented a more respectable way of not shipping.

So: stop at the ten-job exception list, not every case you can imagine. Automate the happy path and route judgment calls to a person with a flag on them. Schedule the second pass two weeks after go-live, because the list is always wrong somewhere and only live running finds where.

Read that last rule against us, because we sell this work. We wrote the exception list for PO Builder before building it, and two weeks of live use turned up cases it had missed — a conference room cannot recall what a Tuesday actually does. No savings percentage for PO Builder, Robyn, Permit Tracker or Jobs to Pay appears above, and none will until an audited before-and-after exists.

RAND says the rest better than I can: in organizations without effective documentation, losing one person "might mean that no one knows which datasets are reliable," and rediscovering that knowledge "increases the cost and time required." Swap the data engineer for the superintendent carrying your eleven exceptions. The first decision isn't whether to automate — it's whether anyone else could write that list, and the week they retire is a poor time to find out.