Scoping work you can actually price
Most project overruns are decided before the first commit, in a proposal that described an outcome nobody had defined precisely enough to build.
The overrun that shows up in month four was created in week zero. Not by bad estimating — by a proposal that described an outcome rather than a build, and left everyone with a slightly different picture of what was included.
The failure is almost always a noun doing too much work. 'A customer portal.' 'Reporting.' 'Admin.' Each of those is somewhere between two weeks and two quarters depending on assumptions nobody wrote down, and the client's assumption is usually the larger one.
So we write the not-doing list, and we put it in the proposal with the same prominence as the scope. It is a strange thing to lead with commercially, and it is the single most useful document in the engagement, because it is what people point at when a request arrives in month three.
The other habit is refusing to estimate anything we cannot decompose to about two days. If a line item is 'three weeks', it is not an estimate, it is a placeholder for something not yet understood. Breaking it down either produces a real number or reveals a question that has to be answered first.
This is why discovery is paid and time-boxed. Free scoping is priced into the project anyway, and it creates pressure to be optimistic in order to win the work. Charging for it lets us be accurate instead, and lets the client walk away with a specification they own even if they hire someone else to build it.