How do I estimate creative and technical projects more accurately?

Accurate estimates come from evidence, not gut feel: break the work into deliverables, plan effort for each by the type of work involved, and compare what you planned against what past projects actually took. Every finished Job then sharpens the next estimate. The firms that estimate well are simply the ones that measure.

Why good people still make bad estimates

Most estimating errors are not caused by laziness or a lack of expertise. They come from optimism plus missing evidence.

You remember the clean version of the last project. You picture the work itself and forget the revisions, coordination, technical cleanup, internal review, and client delays around it. You want the opportunity, so uncertain parts of the scope quietly receive the most hopeful interpretation.

Then the work begins and reality sends the invoice, even if the client never sees one.

Kumail at ITK put the problem plainly: “Net Net showed us how bad we were at quoting.”

That is not an unusual discovery. Many firms believe they are estimating from experience when they are really estimating from memory. Experience becomes useful evidence only after you record what the plan was and compare it with what similar work actually took.

Break the work into Deliverables first

Do not start with one large project total. Start by naming what the client will actually receive.

A website is not one thing. It may include discovery, information architecture, visual design, content work, development, testing, launch, and training. Your list will depend on the engagement, but each Deliverable should be distinct enough that the team and client can recognize what it means.

This matters because a single estimate cannot teach you much later. If the overall Job consumes more effort than planned, you need to know where the gap lived. Perhaps discovery was right, design came in under, and development carried nearly all the drift. The total hides that story.

Deliverables also make scope conversations more concrete. When a request changes, you can identify what part of the plan it affects rather than debating whether the project merely feels bigger.

Plan effort by the type of work

Once the Deliverables are clear, estimate the effort each one needs by Service Type.

That might mean strategy, design, development, writing, quality assurance, account coordination, or the categories your firm actually uses. The important part is separating different kinds of work instead of burying them inside one number.

The same Deliverable may need several Service Types. A landing page can require strategy, copy, design, development, testing, and coordination. Planning that mix helps you see whether the right people are available and gives you a useful baseline when delivery begins.

This is the level where reality can be compared with the plan. If design effort is usually accurate but development repeatedly drifts, you have a focused estimating problem. If coordination appears on every Job but never in the estimate, you have found invisible work.

Related: How do I compare estimated vs. actual effort on agency projects?

Involve the people who will deliver it

The person selling the work should not estimate alone.

Bring in the people who understand the difficult parts. A designer may know that the requested review path will create more versions. A developer may recognize a risky integration. A strategist may notice that the client has not supplied the inputs needed to begin.

This does not require turning every opportunity into a long committee meeting. Ask each relevant person to review the Deliverables, effort, dependencies, and assumptions that concern their work. Resolve meaningful differences instead of averaging them into a number everybody can tolerate.

Participation also creates ownership. The team is more likely to trust a baseline they helped shape, and you are less likely to hand them a plan that looked tidy only because the hard questions stayed outside the room.

Put assumptions where the estimate can see them

An estimate is only as honest as its assumptions.

State what the client will provide, how many review cycles are expected, who approves, what systems must be available, what is excluded, and what could change the plan. Keep the list tied to the actual work. Boilerplate that nobody reads does not protect the estimate.

Use ranges where uncertainty is real. A precise point can look confident while hiding the fact that one unresolved decision changes the work substantially. A range gives you room to explain what moves the estimate toward either end.

Contingency is useful when it represents known uncertainty. It is not a substitute for defining the Deliverables or asking the team. If every estimate needs a giant mystery cushion, the estimating method is not yet doing enough work.

Keep effort and duration separate

Effort describes how much work the team expects to perform. Duration describes how that work stretches across the calendar.

A Deliverable can require modest effort and still take a long time because of client reviews, dependencies, or limited specialist availability. It can also require substantial effort that several people complete within a shorter window.

Plan both. Otherwise, you may estimate the workload correctly and still promise a timeline the workflow cannot support.

Dependencies deserve the same attention. Research may need to finish before creative begins. Creative may need approval before development or campaign setup. A good estimate makes those relationships visible enough to support a realistic delivery plan.

Close the loop after every Job

The estimate becomes valuable again when the Job ends.

Compare planned effort with actual effort for every Deliverable and Service Type. Look for where the gap started, not only where it ended. Ask whether the plan was wrong, the work changed, execution struggled, or an assumption failed.

Then carry the lesson forward. Update the baseline for similar work. Add a missing Service Type. Clarify an assumption. Change the review path. Improve the way the team breaks down a Deliverable.

Do not turn the review into a trial. The goal is a sharper next estimate, not a person to blame for the last one. Creative and technical work contains uncertainty. Measurement helps you learn which uncertainty repeats.

Related: Should I track time if I bill by value?

Every owner has lived some version of this: a job scoped with confidence that then took far more effort than the estimate assumed. The lesson is rarely that the team was slow. It is usually that the estimate was built on memory instead of evidence, and the fix is to start comparing what work was expected to take against what it actually took, one job at a time.

Where the delivery system helps

Net Net holds the planned LOE by Service Type for each Deliverable beside the actual effort recorded during delivery. It is not an estimating or quoting engine. It preserves the evidence that your next estimate can stand on.

That is the useful loop: estimate with the best evidence you have, deliver against a visible baseline, learn from the gap, and estimate the next Job with better evidence.

FAQ

How much contingency should I add to an estimate?

Add contingency for specific uncertainty you can name, not as a universal percentage applied to everything. Consider unclear inputs, technical risk, approval complexity, dependencies, and unfamiliar work. Explain what the contingency protects against and what would cause you to revisit the plan. If the uncertainty is too large to describe, narrow the scope or create a discovery Deliverable before estimating the full Job.

Should my team see the estimate?

Yes, at least the delivery plan behind it. The people doing the work should understand the Deliverables, planned effort, assumptions, dependencies, and timeline. They also should help shape those elements before the estimate is final. You may keep commercial details limited by role, but hiding the effort baseline leaves the team responsible for a promise they had no chance to pressure-test.

What if the client’s budget is lower than the estimate?

Change the work, not the evidence. Reduce or phase Deliverables, narrow review cycles, change the timeline, or separate optional work. Do not force the original scope into a smaller number and hope delivery makes up the difference. A lower budget can produce a smaller valid plan. It should not produce the same plan with invisible pressure pushed onto your team.