How To Estimate Work Your Team Has Never Done Before

Someone asks how long it will take, and the honest answer is that nobody in the room has done this before. Guessing produces a number you will be held to. The way to estimate work your team has never done is to split the job until each piece looks like something you have done, put a separate price on the parts that are genuinely unknown, and agree in advance on a checkpoint where the estimate is allowed to change.

That last part is what makes the first two safe to attempt.

Split until the pieces look familiar

An unfamiliar job is usually a small amount of new work wrapped in a lot of ordinary work.

Take the whole thing and break it into pieces. For each piece, ask one question: have we done something shaped like this before? If yes, estimate it the way you always do, and which of the three ways to size work fits depends on how much history that piece has. If no, split it again.

Keep splitting. Most pieces become familiar after one or two rounds. Building a screen is building a screen, even if the data behind it is new. Writing a report is writing a report. What is left after several rounds is the actual unknown, and it is usually smaller than the fear suggested.

If a piece refuses to become familiar after three splits, stop splitting. You have found the real risk.

Price the unknown separately

Do not fold the unknown into the familiar work. Give it its own line, its own number and its own name on the plan.

Two things make this work.

• The familiar pieces get estimated in the normal way, so your usual accuracy applies to most of the job.
• The unknown piece is visible, which means it can be discussed, cut, deferred or investigated rather than silently inflating everything else.

For the unknown line, do not estimate the work. Estimate the learning. A useful form is a time boxed investigation: we will spend a set number of days finding out whether this approach works, and at the end of it we will know enough to estimate the rest.

That is an honest commitment. It has a fixed cost, a fixed end, and a defined output. It is a different instrument from a buffer line held against named risks, and most plans need both.

Agree the checkpoint before you start

An estimate for unfamiliar work is a first estimate. Everyone in the room knows this, and almost nobody says it, which is how a rough number becomes a promise.

Say it explicitly, and attach it to a date.

• Name the checkpoint. Usually the end of the time boxed investigation.
• State what will be known at that point that is not known now.
• State that the estimate for the remaining work will be revised then, in either direction.
• Agree who is in that conversation.

A client or a manager will nearly always accept this if you say it at the start. The same conversation at the end, when the date is already missed, goes badly. The difference is entirely about when you had it, and what silence costs once a deadline moves is the reason it matters.

Sanity checks worth running

A few habits catch bad estimates before they leave the room.

• Ask one person outside the team to size the same job. A wildly different number means the job is not understood the same way by everyone.
• Look for the words "should be straightforward". They usually mark a piece nobody has examined.
• Count the non building work: setup, testing, review, documentation, a demo. On new work these are proportionally larger, because nothing is templated yet.
• Check that the estimate is in days a person actually has, not calendar days.

Write down what you learn

The reason a team keeps estimating unfamiliar work badly is that the unfamiliar work never becomes familiar in any record. It happens, it ships, and the knowledge stays in one person's head.

After the job, write two lines: what we thought this piece would take, and what it took. Six of those pairs is a better estimating tool than any framework, because it is drawn from your team and your conditions.

Keeping the record where it helps

Estimates go wrong more often because of missing context than missing skill. The plan does not know who is on leave, the previous project's numbers sit in an archived tool, and the person who did similar work last year is on another account.

SicherOne is our enterprise workspace. It puts project management, HR and AI agents on one set of records, so the plan and the availability are the same data, and an agent asked to draft a breakdown works with full context rather than a fragment. A human approves the agent's output before it ships. It is sold per seat with separable modules, and private models can be self hosted.

None of that estimates for you. It keeps the evidence in one place, so the next time this work is unfamiliar, it is a little less so.