You have a fix in mind, a deadline, and a room that has already decided the work is ready to start. The pressure is to begin, and beginning is the one move nobody will be blamed for.
The question worth asking is not whether the team feels ready. It is whether the work could survive being written down as a target, agreed before anyone starts, and graded clause by clause by someone who was not in the room. That is how we contract: acceptance targets are written into the agreement before a build starts, and the scope is fixed at the same time. Work that cannot carry a written, gradeable target cannot carry a fixed scope.
Readiness is a property of three artifacts: the target, the access, the owner. Every one of them can be checked in an afternoon, before any budget moves. They map onto what you hand over on day one: the workflow and its targets, the systems and working credentials, and one named person who can make a decision without calling a meeting.
Write The Target A Stranger Grades
Work that is ready to build has an acceptance condition someone who did not help write it could grade pass or fail. "Add AI to support" cannot be graded. "Generate source-grounded draft replies from the last 90 days of tickets, and hand them to an agent for approval" is closer, and it is still not there, because nothing in it says what counts as a good draft reply.
A PropTech platform stated the requirement, a valuation engine that could "price properties within 10% of closing price in dense markets, in seconds instead of days", and the engine that came out of it holds within 10% of closing price for 90% of cases. The requirement names the metric (distance from closing price), the tolerance (10%), the regime (dense markets), and the required speed. Their innovation director could check every clause without trusting anybody, and once built, it "lifted our real estate insights and client engagement."
The difficulty on that build sat where the target could easily have missed it. Producing the estimate was the easy half. Calibrating the confidence band, deciding when the system was allowed to be trusted and routing everything below the bar to a human appraiser, was the harder work. A target that names an accuracy number and says nothing about the cases underneath it has specified the demo and left the product unwritten.
Requirements research on AI-intensive systems (Ahmad et al., 2022) puts this gap at the centre of downstream failure: business intent that is clear in business language and ambiguous in technical language. The test is simple: write the target, hand it to someone who was not in the room, and ask how they would grade it. Their hesitation is your answer.
Hand Over The Keys Today
The access test is passed or failed today rather than argued about. Can someone produce a working credential and a sample payload for every system in the path? Can the team show a recent query result against the real data the work will read? Is there a code repository, an environment that exists, and a way to deploy that does not require a meeting to unblock?
When any answer is "we will figure that out during the build," the build absorbs work that belongs upstream, out of the same budget, at a worse rate. Research on hidden technical debt (NeurIPS, 2015) found the interesting component to be a small fraction of a production system, with the rest being data plumbing, serving, configuration, and glue.
A hard dependency is not automatically a stop sign. HeartSciences' AI-ECG platform had to integrate with a major EHR vendor whose sandbox access was limited, shared, and externally scheduled — a textbook access-test failure. We built a full EHR integration simulator that replicated the workflows at the protocol level, and development continued against it: per-organization field mappings, bidirectional message handling, authentication binding, all exercised before a sandbox window was granted. So the access test has three outcomes: reachable, unreachable, or reachable by building the thing that reaches it. It never has a fourth where the dependency is assumed away and discovered mid-build.
One Owner, Not A Committee
A build needs two people and no more: one who can approve a scope trade-off, and one hands-on person who can unblock access, deployment, and review. Research on AI project failures (RAND, 2024) locates the damage in organizational friction more often than in technical capability. A build loses its time to waiting, not to hard problems.
The tell is what happens to a mid-build discovery. Suppose the data contains a category the target never contemplated, and covering it would trade accuracy against coverage, changing the rest of the work. With a real owner, the call is made the same day, the target moves by one clause, and work continues. Without one, the team picks a default, and the default surfaces at review as a disagreement about scope that nobody can settle.
Work is ready to build when its target can be graded by a stranger, its systems can be reached today, and one person can change the target tomorrow.
The three tests feed a single check, and any failure names the next piece of work.
Failing a readiness test is not a verdict on the idea. It is a precise description of what the next step is for: the decision, if the workflow itself is still contested, or a plan and a working sample, if the workflow is chosen and the uncertainty is technical.
Build What You Can Grade
If the target cannot be written because the workflow is still contested, the decision comes before the build, and a fifteen-minute call is the cheapest place to get it right. If the target can be written but nobody can prove the path holds in your environment, the missing artifact is something running there and a fixed scope, which is what to demand before you sign.
If all three pass, the work is ready for an engineering partnership: one contained workflow, agreed in writing before anything starts, with the repository, code, intellectual property and full history transferring to you as it is paid for. The tests are cheap to run and expensive to skip. The only question is whether you discover a gap this week, for free, or later, inside a build you have already paid for. The readiness scan runs a wider check in ten questions.
References
- Ahmad, K., Abdelrazek, M., Arora, C., Bano, M., & Grundy, J. A Systematic Mapping Study on Requirements Engineering for AI-Intensive Systems. arXiv, 2022.
- RAND Corporation. Analysis of AI Project Failures. RAND Corporation, 2024.
- Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J., & Dennison, D. Hidden Technical Debt in Machine Learning Systems. NeurIPS, 2015.
