Estimating & Effort

How do I estimate effort for work I’ve never done before?

Estimate unfamiliar work by comparing it to the closest thing you have actually done, then widening the number into a range that reflects how little you know. Break the project into phases, put an…
Marc Pitre·May 6, 2026·6 min read

Estimate unfamiliar work by comparing it to the closest thing you have actually done, then widening the number into a range that reflects how little you know. Break the project into phases, put an effort range on each based on similar past work, and add a review checkpoint early so you can correct the estimate once the real work teaches you something. You will not get a novel project exactly right, but a ranged estimate anchored to a reference project is defensible and far better than a confident guess.

Anchor the estimate to the closest work you have done

Start by asking what is actually new. A project may use an unfamiliar platform but have a familiar discovery process. It may target a new industry while using the same research and design steps. It may introduce one difficult integration inside an otherwise standard build.

Choose one or more completed projects that resemble the new work in scope, team, complexity, or approval structure. Pull their actual hours by phase. Do not rely on what those projects were estimated to take. The actuals include the coordination, revision, and rework that memory tends to soften.

Name the differences between the reference and the new job. The new client may have more stakeholders, weaker content readiness, a shorter timeline, or a dependency your team has never handled. Each difference tells you where the estimate should widen or where an early investigation is needed.

This reference-class approach does not require a huge database. A few relevant jobs, understood clearly, provide a better anchor than a blank spreadsheet and a confident meeting-room guess.

Break the unknown into phases you can reason about

Do not estimate “the new thing” as one line. Separate discovery, validation, planning, production, review, testing, and launch. Some of those phases will be familiar even when the overall project is not.

Then break each phase into tasks small enough to discuss. The goal is not to predict every action. It is to isolate the places where your team has evidence from the places where it does not.

For unfamiliar technical work, the first phase may be a prototype or feasibility test. For a new service, it may be research plus a sample deliverable. For an unusual design assignment, it may be a time-boxed exploration that defines the direction before full production.

Assign owners and identify dependencies. An estimate can look reasonable in total while asking one specialist to perform more hours than the timeline allows. Capacity must be checked at the person and role level, not only at the project level.

Estimate in ranges, not single numbers

Give each phase a low and high estimate. The low end should represent favorable assumptions you can state. The high end should represent plausible difficulty, not an imaginary disaster.

For example, the low end may assume clean source data, one decision-maker, and a familiar integration pattern. The high end may assume moderate cleanup, two review groups, and additional testing. If you cannot explain what moves the work through the range, the numbers are not yet useful.

Wider ranges are appropriate where the evidence is weak. Familiar phases can be tight. New phases can be broad. This is more informative than adding the same buffer to the entire project.

Translate the range into a client process. Explain what is known, what remains uncertain, and when the estimate will get sharper. How do I use past project data to estimate new work? shows how to choose and use the underlying historical data.

Add an early checkpoint to correct the estimate

The checkpoint should happen after the first activity that reveals real conditions. It may follow an audit, prototype, content inventory, data sample, stakeholder workshop, or technical test.

Define the decision in advance. At the checkpoint, the team might confirm the remaining range, replace it with a firm estimate, reshape the scope, or stop before committing more capacity. Tell the client what evidence will be available and what approval is required.

Keep the first phase small enough that learning arrives before most of the effort is committed. A checkpoint after eighty percent of the work is not a control. It is a postmortem.

Update the delivery plan immediately. If the high end becomes likely, check team capacity and timeline before continuing. If the work is simpler than expected, tighten the range instead of allowing the unused allowance to fill with extra requests.

The review point protects both sides because it turns new information into a planned decision rather than a late surprise.

Log what actually happened for next time

When the job closes, record the estimated range, actual hours, key assumptions, and the reason the result landed where it did. Separate the unfamiliar component from the familiar work around it.

If the prototype took twelve hours and removed forty hours of uncertainty, keep that structure in the future template. If client coordination created most of the variance, update the stakeholder assumptions. If the new platform was not difficult but testing was, change the phase breakdown.

A workflow management platform can preserve those links between estimate, task, owner, actual effort, and timing. Without that connection, the team remembers the final artifact but loses the evidence that would improve the next estimate.

After one project, the work is no longer completely unfamiliar. After several, you may have a dependable project type. The learning loop is what turns a risky new service into something the firm can plan with confidence.

For ongoing improvement, compare estimated effort with actual effort at the same phase and task levels. A project total alone cannot tell you which new assumption was wrong.

FAQ

What is reference-class estimating?

It means estimating a new project by looking at a group of similar past projects and using their actual effort as your starting point, instead of building a number from scratch. The closer the reference work, the more reliable your anchor.

How wide should the range be?

The less you have done something, the wider it should be. For genuinely new work a low-to-high spread where the top is roughly double the bottom is common, and you tighten it as the early phases reveal the real shape of the job.

How do I present a ranged estimate to a client?

Give the range with a plain explanation of what would move it toward the high or low end, and name the checkpoint where you will confirm the number. Clients accept ranges when they understand the estimate will get sharper as the work starts.

See your work before it drifts.

Net Net keeps plan and effort side by side, so you catch the slip while there is still time to act.

Start your free trial