How do I clearly scope and estimate hours before starting an engagement?

Why estimates go wrong

The delivery essay in the newer book describes how delivery worked in the first era: under-instrumented, with little real-time visibility into what delivery actually cost, inconsistent and backward-looking time tracking, and margin discovered after the fact rather than managed in advance. It also describes delivery leaders as politically weak. They could not push back on sales or reset client expectations, saying yes was rewarded, and margin erosion was normalized as the price of client satisfaction. Its name for the result is trapped profitability, hidden in small daily decisions such as an unchallenged scope change or a misstaffed project.

As an inference, most bad estimates have one of three causes: the estimate came from memory rather than records, the scope had no edges so the work kept growing, or the person estimating was the person selling and wanted the number to be small.

Estimate from history, at task level

The replication chapter of the 2020 book describes the method it uses to build certification, and it doubles as an estimating method. Start with postmortems of a representative sample of recent engagements, break each one down, and look at how the work was performed at the task level, including the knowledge and skills each task required. The true cost answer on this site says the same about costing: take hours to task level rather than project level, because task level tells you why rather than whether.

As an inference, build each new estimate as a list of tasks, each with hours taken from the actual hours on the last few similar engagements rather than from what the senior person remembers. Where there is no history, say so, and price that uncertainty rather than hiding it inside a single number.

As an inference, the hours most often left out are the ones nobody plans: internal reviews, client meetings and status reporting, rework after feedback, handoffs between people, and the senior time spent answering questions. The all-in cost answer on this site lists scope drift, rework and missed handoffs as the places margin leaks. If your history shows them, put them in the estimate as their own lines rather than hoping they will not recur.

The cash flow chapter adds a warning sign. Capital 54 passed on a commercial photography firm because cash flow varied so much from project to project, which meant the delivery model was not standardized. As an inference, if your actual hours for the same type of engagement vary widely, the problem is the delivery model, and no estimating method will fix it until the work itself is standardized.

Give the scope edges

An estimate is only as good as the scope it describes. The proposals answer on this site treats scoping as four decisions: the outcome stated so a reasonable person could not disagree it was delivered, the boundary with an out list written down, a customization rule that says what can flex, who authorizes it and what it costs, and the inputs the client must supply. The client contract answer on this site covers putting scope change mechanics into the agreement so the rule is enforceable.

The revenue chapter of the 2020 book records what happens without edges. On his first fixed bids, Greg Alexander says, the team was inexperienced in defining scope, clients took advantage, and the firm lost money; as it got better at defining scope and efficient at producing deliverables, profitability rose.

Separate the estimate from the sale

The engagement management essay says the engagement manager supports proposal development with concrete scope, economics and delivery insight, and owns pricing and contracting for scope adjustments and change orders. The delivery essay says the delivery leader must have the authority to push back. As an inference, have the person who will run the work build or approve the estimate, and have the seller own the price, so the hours are not quietly shaped to fit a number the client wants to hear.

Treat the estimate as a hypothesis

The pricing role essay says pricing decisions are hypotheses, and that a system should test them continuously by linking quoted price, delivered effort, realized margin and client satisfaction. It also says pricing assumptions age quickly as AI changes how work is done, and that the system should flag when delivery speed rises, AI substitutes for human labor, or scope expands without a price adjustment.

The engagement management essay describes the AI doing this inside each engagement: tracking burn, forecasting contribution margin and flagging erosion early, modeling scope-change scenarios and their economic impact, detecting timeline risk before the client sees it, and identifying rework, delay and overstaffing. The human engagement manager keeps the moments that need judgment, such as resetting expectations when reality diverges from the plan and negotiating tradeoffs between scope, timeline and budget.

As an inference, compare estimate to actual at each phase rather than at the end, and feed the actuals back into the history the next estimate draws on. Over time the estimate becomes a record rather than a guess.

Watch what AI does to the hours

As the pricing essay notes, AI is changing how long work takes. The fixed fee answer on this site warns that a price built as estimated hours times a rate passes every efficiency gain to the client. As an inference, estimate hours to understand cost and capacity, but do not let the hour estimate set the price, which the value-based pricing answer covers.

What we do not prescribe

Collective 54 publishes no estimating template, contingency percentage, scoping questionnaire or tracking tool. The published positions are task-level postmortems of representative engagements, the project as the unit of profit, cash flow variance as a sign of an unstandardized delivery model, scoping with precision as a test of readiness, the four scope decisions, the engagement manager supporting proposals and owning change orders, delivery authority to push back, pricing decisions as hypotheses checked against delivered effort and realized margin, and AI tracking burn and contribution margin during delivery.

When this answer flips

If the work is genuinely exploratory and cannot be estimated, as an inference, scope a short paid discovery phase first and estimate the rest from what it finds.

If the client buys ongoing access rather than a defined deliverable, a retainer may fit better than an hour estimate; the retainer answer on this site covers it.

And if you have no history at all, start recording actual hours by task on every engagement now, because that record is what every later estimate depends on.

The short answer

Estimate from your own records, at task level. The 2020 book describes postmortems that break recent engagements into tasks; use the actual hours from the last few similar engagements, not memory, and price any uncertainty you cannot remove. Give the scope edges: the outcome, the out list, a change rule with a price, and the inputs the client must supply. Have the person who will run the work build or approve the estimate, so it is not shaped to fit the sale. Then treat it as a hypothesis, as the pricing essay says: compare estimated and actual effort at each phase, let AI track burn and contribution margin so overruns show early, and feed the actuals back into the next estimate. If actual hours vary widely for the same work, fix the delivery model first.