Estimates are a count of open questions

Every estimate I have got badly wrong was wrong for the same reason, and it was not optimism about the work I could see. It was a question I had not asked. Which system holds the customer records now, and can it export them? Who approves the design, and how many of them are there? Is the launch date a wish or a contract?

Each of those, unanswered, is a range in the estimate, and the range does not shrink because the work is well understood; it shrinks when the question is closed. So the method I use to scope contract work does not start from the feature list. It starts from a list of open questions, tagged by who can close them, and the quoted range is a function of that list's length.

The cone is a count

The oldest result in software estimation says this in a different vocabulary. Boehm's cone of uncertainty, from his 1981 Software Engineering Economics, and the version McConnell later popularised in a Construx white paper, gives the error band of an estimate at each project milestone: a factor of four either side at initial concept, meaning the true effort lies anywhere between a quarter and four times the estimate; a factor of two at approved product definition; 0.67 to 1.5 at requirements complete; 0.8 to 1.25 when the interface design is done; 0.9 to 1.1 at detailed design. The white paper's most important sentence is not the numbers. It is the observation that the cone narrows only as decisions are made, not with the passage of time; give an estimator another week without closing any questions and the estimate is no better.

Read as a count, the cone says something practical. "Initial concept" is the state in which almost every question is open; "requirements complete" is the state in which the questions the client owns are closed; "detailed design complete" is the state in which the ones I own are closed too. The milestones are names for how many questions remain, and the error band is a function of that number.

The question ledger

So before quoting, I write the ledger. Every unanswered question about the work goes on it, tagged with who can close it: me, the client, or a third party. Mine are the technical ones I can answer by reading code or trying something for an hour, which data model, which library, whether the existing export is usable. The client's are the ones only they can answer: who the users are, which of two contradictory requirements wins, what the migration deadline really is, who signs off. The third party's are the ones outside both our control: whether the payment provider approves the account, whether the old vendor will release the data, whether the app store review takes a day or a month.

The quote is then a range whose width is set by the ledger. With the ledger long, the range is wide and I say so, with the ledger attached, because a wide range with reasons is more useful to a client than a narrow number with none. As questions close, the range narrows and the quote is revised. The rule at the end is the one that protects both sides: no fixed price while more than a handful of client-only questions remain open. Those are the questions I cannot close by working harder, and a fixed price on top of them is a bet on answers I have not been given.

Why the client-only tag matters

The three tags are not decoration; they decide what happens next. My questions are closed by discovery, which is work I do and can schedule. Third-party questions usually cannot be closed before signing, so each becomes a stated assumption in the scope with a price for the assumption being wrong: if the vendor does not release the data in a usable format, the migration is re-quoted; if store review exceeds two weeks, the launch date moves with it. That converts an unknowable into a known cost.

Client-only questions are the dangerous category, because they look closeable and often are not. A client who has not decided which of two departments owns the process will say they will decide next week, and the question will still be open at launch. The tag makes the ledger show, in one column, how much of the range is in the client's hands, and it turns the scoping conversation from "can you do it cheaper" into "here are the six things only you can settle, and each one you settle brings the price down". Most clients, shown the list, settle four of the six in the meeting.

Pricing the questions, not the features

The reason to say "price the questions" rather than "price the features" is that the features are the part everyone can see and the part that is usually estimated well. A CRM migration's feature list is knowable in an hour: import contacts, map pipelines, migrate tickets, set up roles, train the team. What makes one such migration take three weeks and another take three months is not on that list. It is whether the old system's export is complete, whether the client's data has two years of duplicates, whether the person who knows the old workflow still works there. Those are questions, and each open one is a multiplier on the whole estimate, not an addition to one line of it.

That multiplicative shape is why the ledger matters more than the feature list at the quoting stage, and why the cone's bands are ratios rather than sums. A feature costs what it costs. An open question can double the project, and the double applies to everything.

Keeping the ledger after signing

The ledger does not retire when the scope is signed; it becomes the project's risk register, and it is a better one than most because every entry already has an owner. The third-party questions that were priced as assumptions are watched, and the day one resolves the wrong way is the day the priced clause is invoked, calmly, because it was agreed in advance. The client-only questions that were closed in writing are the reference when a decision drifts, which it will: when the department that was to own the process changes its mind in week six, the ledger shows the answer that was given in week one and the price that was set on it, and the conversation is about a change, not about blame.

New questions appear during the work, and they go on the same ledger with the same tags. That is the honest form of scope creep control: not a refusal to answer new questions, but a record of who owns each one and what its answer is worth. A project whose ledger has grown by a dozen client-only questions since signing is one whose price should be revisited, and the ledger is the evidence for that conversation rather than a feeling that things have got bigger.

The refusal

The hardest part of the method is the last line of the rule, refusing the fixed price. Clients want a number, and a range with a ledger attached looks like hedging until it is explained. The explanation that works is the honest one: a fixed price with the client's questions open is a price for a project neither of us has defined, and one of us will pay for the difference; I would rather close the questions this week and give a real number next week than give a fake number today. Put that way, the ledger stops being an obstacle to the deal and becomes the agenda for closing it, and the fixed price, when it comes, is one both sides can hold each other to.