How to Use Completed Work to Make the Next Project Estimate

A completed project can make your next estimate more grounded, but it cannot make it certain. The useful question is not, “How long did the last one take?” It is, “Which parts of that work are genuinely comparable, and what will be different this time?”

A work record helps because it gives you something more concrete than memory. It can show the phases that consumed attention, the points where work changed direction, and the coordination surrounding delivery. Use that record as evidence for a planning judgment, not as a promise to a prospective client.

1. Select a comparable completed project

Do not begin with the most recent project or the one with the clearest total. Begin with the project that resembles the proposed work in the ways that affect effort.

Compare these elements before carrying anything forward:

• Deliverable type: Is the new job a similar feature, audit, design revision, integration, or research task?
• Technical context: Will you work in a familiar codebase, toolchain, or workflow, or enter an unfamiliar one?
• Scope boundary: Does the new project have a similarly defined outcome, or are key requirements still open?
• Review conditions: Who will review the work, and how many approval or revision cycles are reasonably expected?
• Coordination load: Will the work involve the same number of stakeholders, handoffs, or client conversations?

A past project that looks similar only at the level of its final deliverable may be a poor comparison. Two integrations can have very different effort if one starts with stable documentation and the other begins with unclear access, incomplete requirements, or dependencies owned by another team.

2. Rebuild the previous project by phase

A single total hides the part you need to learn from. Review the completed work in phases, then decide which phases apply to the new project.

A practical retrospective template looks like this:

Phase	What the record shows	What influenced it	Does it apply next time?
Discovery	Questions, investigation, and definition of the work	Requirements were incomplete	Possibly, depending on the brief
Implementation	Work that produced the deliverable	Familiar tools and a stable environment	Likely, if the technical context is similar
Review	Checking, testing, and responding to feedback	Several reviewers participated	Do not assume the same cycle count
Revisions	Changes after initial review	A late scope decision	Treat as a risk, not a standard phase
Coordination	Calls, messages, handoffs, and status work	External dependency required follow-up	Include only if the new project has one

The table is deliberately simple. Its purpose is to stop you from copying an undifferentiated block of time into a new proposal.

For example, imagine a completed project that included discovery, implementation, review, two rounds of revisions, and coordination with an outside provider. A new project may call for the same implementation pattern but arrive with a clear specification and no outside dependency. In that case, the old implementation and review phases may be useful reference points. The discovery, extra revisions, and coordination are observations about the prior job, not automatic inclusions in the new estimate.

3. Treat interruptions and AI activity as context

Context switching, rework, ambiguity, and AI-assisted activity can matter a great deal, but none is a universal multiplier.

If the previous work was repeatedly interrupted by another client project, note that as a condition of the record. Do not quietly treat those interruptions as inherent effort for the deliverable. If the new engagement will also require frequent switching, describe that constraint separately rather than hiding it inside a copied total.

Apply the same discipline to AI-assisted work. A session with an AI agent may have supported exploration, implementation, review, or an abandoned path. Its duration, token use, or cost does not establish the value of the result by itself. Review what task it served, what outcome followed, and whether that workflow is likely to be used on the new project.

LogAgent groups activity segments into projects, clients, and rates. That can give you a more reviewable starting record, but you still need to assess whether a segment belongs to a comparable phase and whether the new project shares its conditions.

4. Write the estimate as a documented judgment

Keep two columns in your estimating notes: observed on the completed project and assumed for the proposed project. This separation prevents an old record from quietly becoming a claim about work that has not happened yet.

Before sending an estimate, check:

• Have you chosen a project that is comparable in deliverable, scope, and technical context?
• Have you separated discovery, implementation, review, revisions, and coordination?
• Have you identified work caused by ambiguity, rework, or switching rather than treating it as normal delivery effort?
• Have you considered AI-assisted activity in relation to its task and outcome, rather than as a standalone measure?
• Have you written down the assumptions that would change the estimate?
• Have you stated what is included and what would require a new discussion if it changes?

An estimate is a planning judgment: informed by completed work, explicit about uncertainty, and easier to revisit when the project changes.