Scoping Questions Before an Estimate

An estimate is a statement about how much you know, dressed up as a statement about how long something takes. When it goes badly wrong, it is rarely because the work was harder than expected. It is because a question went unasked, got answered by assumption, and the assumption was wrong.

This is the set of questions that has to be answered before a number leaves your mouth — and, more usefully, what to do with the ones that cannot be.

Why this exists

The reflex, when you are unsure, is to pad quietly. You add a margin to cover the things you did not ask about, and you present one confident number. A quietly padded number is indistinguishable from an expensive one. The client weighs it against something cheaper, says no, and you never find out that what they refused was your uncertainty rather than your rate. The padding protected the project and cost you the work.

The alternative is to make the uncertainty visible and priced. Every question you could not answer becomes a row with a good case, a bad case, and a decision about how it is handled. The range then explains itself in one sentence, and the client can buy the answer instead of the margin.

The other thing this fixes is which questions get asked at all. Scoping conversations drift toward features, because features are the interesting part to talk about. Features are rarely where the variance lives. The two highest-variance questions on most projects are how many people can say no after it is built, and whose system you have to write into. Reading from a system is a task. Writing into one is a project, because it arrives with an owner, a review, a test environment and a change window, none of which are yours.

How to use it

Ask these in conversation, not as a form. Sent as a questionnaire they read like an interrogation and come back with one word each. Ask them out loud, fill the sheet in yourself afterward, and send back what you heard — the correction is free information.

Ask integration questions at the level of the operation, not the system. “Does it support patient records” earns you a yes that means nothing. In Epic’s FHIR documentation, for example, the same clinical concept can be readable on one version and creatable only on another, and the call you need may not sit on the same version as everything else you are calling. The right question names the object, the operation and the version in a single sentence. That is the difference between an estimate and a hope, and it generalizes well past health care.

Then hold the line on timing: never give the number in the meeting where you asked the questions. Not as a negotiating tactic, but because the answer to question nineteen usually changes what you concluded at question four, and you need an hour alone with the sheet to see it.

For each remaining unknown, pick one of three handlings: answer it yourself in a short paid discovery, write it as an assumption with the cost of being wrong attached, or carve that piece out as time and materials while the rest stays fixed. An assumption with no consequence attached is not an assumption. It is a sentence you wrote so you could point at it later.

Where it goes wrong

On small work this is heavier than the job. If the whole engagement is shorter than the discovery would be, skip the sheet, ask the five questions about done and approvals, and absorb the variance yourself.

It also will not save you from a client who cannot answer any of it. That is not a scoping problem and more questions will not fix it. It means nobody owns this yet, and the honest move is to say so and offer to help find the owner, rather than pricing a project that has no sponsor.

And the sheet cannot tell you whether you want the work. It measures risk, not fit. A project with clean answers to every line can still be the wrong one to take.