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

Estimate unfamiliar work from the closest thing your team has actually delivered, then use a range wide enough to admit what is still unknown. Break the Job into phases, anchor each phase to comparable actual effort where you can, and put a checkpoint early enough to change the plan before most of the capacity is committed. You will not nail a brand-new service on the first try. A defensible range with a learning point beats a very confident number pulled from the nice part of your brain.

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 completed Jobs that resemble the new work in scope, team, complexity, or approval path. Pull the actual effort by phase, not the estimate everyone remembers fondly. Actuals include the client coordination, review rounds, rework, and handoff prep that memory tends to sand smooth.

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.

You do not need a massive database. A few relevant Jobs, understood well, give you a better anchor than a blank spreadsheet and a room full of people nodding at the first number someone says.

Break the unknown into phases you can reason about

Do not estimate “the new thing” as one heroic line item. Separate discovery, validation, planning, production, review, testing, and launch. Some phases will be familiar even when the overall Job is not. That lets you keep the known pieces tight and isolate the parts that need a wider range or a small experiment.

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 you can explain. The low end reflects favorable assumptions. The high end reflects plausible difficulty, not the asteroid scenario. If you cannot say what moves the work from one end to the other, the range is decoration rather than an estimate.

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

Put the checkpoint immediately after the first activity that reveals real conditions: an audit, prototype, content inventory, data sample, stakeholder workshop, or technical test. Define the decision before you start. The team may confirm the range, replace it with a firmer estimate, reshape the scope, or stop before committing more capacity.

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 the learning arrives while you can still use it. A checkpoint after eighty percent of the Job is not a control. It is a postmortem with nicer branding.

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 range, actual effort, assumptions, and why the result landed where it did. Separate the unfamiliar piece from the routine work around it. Otherwise the team remembers the shiny final artifact and loses the evidence that could make the next estimate less exciting.

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?

Reference-class estimating starts with comparable completed work and its actual effort instead of building a number from scratch. The closer the reference Jobs are in scope, team, complexity, and approvals, the more useful the anchor becomes.

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.