How to Scope an Automation Project When You Have No Budget Anchor

An estimate produced before anyone has looked at your actual systems can be wrong by a factor of four in either direction. Steve McConnell described this as the Cone of Uncertainty in his book Software Estimation: Demystifying the Black Art, building on Barry Boehm's earlier data. At initial concept, McConnell's position as it is reported in secondary sources is that estimates can be inaccurate by a factor of 4x on the high side or 4x low, which is a 16x total range. We have not verified the exact wording against the book itself, so treat that as a close paraphrase rather than a verbatim quote. The shape of the claim is not controversial in the field. Sixteen times sounds absurd until you write out what is unknown at that point. Nobody has opened your CRM to see whether the data is clean. Nobody has read the API documentation for the third-party system that has to be integrated, or discovered that it has no webhook and must be polled. Nobody knows whether your team will accept the workflow change the automation depends on. The cone narrows as those questions get answered, and only as they get answered. Time alone does not narrow it. This is why an agency that gives you a confident single number on a first call is either padding heavily to cover the unknowns or anchoring low with the intention of revising upward.

The most-quoted software overrun statistics come from studies of very large projects and do not transfer to a small automation build. McKinsey, working with the BT Centre for Major Programme Management at the University of Oxford, analysed more than 5,400 IT projects in 2012 and found they ran on average 45% over budget, 7% over time, and delivered 56% less value than predicted. Here is the caveat that gets dropped every time that figure is repeated: the study covered large IT projects with initial budgets above US$15 million, about A$23 million at July 2026 rates. Applying "45% over budget" to a A$30,000 automation project is not supported by the data, and a careful buyer should push back on any agency that does it. The other statistic you will see is the Standish Group's CHAOS Report, which found 31.1% of software projects were cancelled before completion and only 16.2% succeeded on time, on budget and with full features. That report is from 1994. It is over thirty years old, Standish has never published its methodology for independent review, and academic reanalyses by Magne Jorgensen and Kjetil Molokken argued the sample was skewed toward failures. If you want one citation for why scoping matters, use the McKinsey and Oxford study. It has a named academic partner and a transparent method. Just quote the project size along with the number.

A discovery phase should hand you a set of documents you own and could give to a different vendor tomorrow. Across agency and consultancy descriptions the deliverables are consistent: | Deliverable | What it tells you | |---|---| | Scoped feature list | What is in scope and, more importantly, what is explicitly out | | Technical architecture proposal | How it is built and every point where it touches your existing systems | | Wireframes or flow diagrams | What the main paths through the thing actually look like | | Risk register | The specific unknowns that could move the price | | Cost estimate with a confidence range | A range, with the reason for its width stated | | Delivery roadmap | The order of work and what ships first | The risk register is the load-bearing item and the one buyers routinely skim. Everything else on that list is an artefact describing a plan. The risk register is the thing that converts "we do not know what this costs" into "here are the four specific questions that determine what this costs, and here is what each answer would do to the number". A good risk register is uncomfortable to read. It names the integration whose API has never been tested, the data quality assumption nobody has checked, the volume estimate that came from a guess. If the register is generic, listing "scope creep" and "changing requirements", nobody did the work.

Published benchmarks put discovery at somewhere between 5% and 15% of expected build cost, and every one of those figures comes from a firm that sells discovery phases. | Quoted range | Share of build budget | Where it comes from | |---|---|---| | Most commonly cited | 5-10% | Multiple agency blogs | | Also common | 10-15% | Multiple agency blogs | | Outlier | 10-40% | ThemeREX, likely reflecting very small projects where a fixed discovery cost is proportionally large | There is no neutral industry body publishing this benchmark. No ABS series, no professional association survey, nothing with a method you can inspect. The 5-15% band is what the sellers say, repeated often enough to look like a standard. We are telling you this because it is the sort of thing that gets quoted at you as though it were an established norm. It is a convention, not a measurement, and knowing that changes how you negotiate. If a firm quotes 20% of an unknown build cost for discovery, the number is not violating an industry rule; it is just high relative to what other sellers ask. The more useful test is absolute rather than proportional. What is this discovery going to cost, what specifically will I hold at the end of it, and is that document worth that money to me even if I never hire this firm to build the thing?

Australian vendors publish indicative ranges for automation work, and they are the only public numbers available. Every figure below is published by a firm selling automation services. There is no ABS, government or industry-association benchmark for Australian automation project cost that we could find. | Scope | Indicative range (AUD) | Published by | |---|---|---| | Scoped single-workflow automation | from about $5,000 | SunburntAI | | Simple workflow automation connecting two or three tools | $5,000 to $15,000 | Cohevo | | Small business automation, upfront | $5,000 to $50,000, plus $500 to $2,000 per month ongoing | Cohevo | | Multi-workflow agent systems with complex integrations | $80,000 and above | SunburntAI | | Enterprise deployments | $200,000 and above | SunburntAI | Read these as the shape of the market rather than as a quote. The useful information in the table is not any single number, it is the distance between the rows. Connecting two tools with a defined trigger and a defined action sits at one end. A system that reads unstructured input, makes judgements and writes to several systems of record sits at the other, and the gap between them is more than tenfold. That gap is also where most budget conversations go wrong. A buyer describes something in one sentence that sounds like row two and is actually row four, usually because of an integration nobody mentioned or an approval step that turns out to be mandatory.

If you genuinely do not know what your project should cost, the sequence that works is to buy the estimate before you buy the build. Do not ask for a number before anyone has looked at your systems. A quote given at that point is either padded to cover unknown risk or set low to win the deal and revised upward later. You are not getting information from it either way, and worse, the number becomes an anchor that distorts every conversation after it. Buy the estimate, not the build. A small fixed-price discovery engagement produces a real artefact you own. That artefact is your anchor. You can take it to two other firms and get comparable quotes, which is impossible when each firm is scoping from scratch off a different conversation. Judge discovery on whether it narrowed the range, not on whether it produced one confident number. Good discovery moves you from a 16x spread to something you can plan around, and names the reasons for the spread that remains. A single confident figure with no stated range is a sales artefact, not an estimate. Check the output is portable. Give the deliverable to a technical person who has never met the agency and ask whether they could quote from it. If it only makes sense to the firm that wrote it, or it reads as a pitch for that firm's preferred stack, it is a sales document rather than a scope.

Unpaid discovery is paid for, just not by the client who receives it. The cost sits in the build price of the deals that do close. Work the numbers from the agency side. A solutions engineer spends thirty to forty hours investigating a prospect's systems and writing a proposal. The close rate on that work is somewhere around one in four. The fully loaded cost of sale on each lost proposal approaches five figures, and a firm doing ten of those a quarter is funding a small engineering team to write documents that nobody reads. That money is recovered somewhere, and the only place it can be recovered is in the price of the projects that go ahead. So a buyer paying for discovery is paying for their own project rather than subsidising the agency's losing proposals. That is the honest version of the argument, and it is worth stating plainly rather than dressing up as a service. There is a quality argument too. Free scoping is rushed scoping. It skips the technical spike on the third-party API that will break in production, because nobody is going to spend two unpaid days on an integration test for a deal they might not win. Then a fixed-price contract gets signed on top of that untested assumption, and the variance shows up as a change request three months in.

Is it a red flag if an agency will not quote without a discovery phase? No, it is usually the opposite. At initial concept, before anyone has looked at your systems, estimates can be out by a factor of four in either direction, which is McConnell's Cone of Uncertainty. A firm that gives you a confident single number on a first call is pricing risk it has not measured. What should worry you is a discovery phase with no defined deliverables. How much should I expect to pay for discovery? Published ranges sit at 5-15% of expected build cost, with one outlier quoting 10-40%. Note that every one of those figures is published by a firm that sells discovery phases, and no neutral body publishes this benchmark. Judge it on the absolute amount and on whether the document you receive is worth that on its own. What should I have at the end of discovery? A scoped feature list with explicit out-of-scope boundaries, an architecture proposal naming every integration point, flow diagrams for the main paths, a risk register, a cost estimate with a stated range, and a delivery roadmap. The risk register is the item to read first. It should name specific unknowns, not generic ones like "scope creep". Does the 45% over budget statistic apply to my small automation? No. The McKinsey and University of Oxford study that produced it covered large IT projects with initial budgets above US$15 million, about A$23 million at July 2026 rates. Applying a large-programme overrun average to a A$20,000 workflow automation is not supported by the data, and anyone quoting it that way is misusing it. Can I take the discovery output to a different agency? You should be able to, and testing that is the point. If the deliverable only makes sense to the firm that produced it, or reads as an argument for that firm's preferred tools, it is a sales document. A real scope lets three vendors quote comparable work, which is the only way to find out whether the first number was reasonable.