How do I use past project data to estimate new work?

Start every new estimate with completed Jobs that look like the work in front of you. Pull the actual effort those Jobs took and build from what happened, not from the tidy version everyone remembers later. Group similar work, compare the effort by phase, then adjust for what is different this time: more reviewers, missing content, a custom integration, or the classic “quick” timeline. Your delivery history already includes the meetings, revisions, and handoff cleanup that optimistic estimates politely forget.

Your memory edits out the messy parts

Memory is a generous editor. A few months later, the team remembers the main creative or technical challenge and the successful finish. The second revision round, delayed client content, testing snag, and handoff cleanup tend to disappear from the story.

Actual effort records keep those details. They show what the Job used regardless of what the original estimate promised, which makes them a sturdier starting point than asking the team to imagine the work again from a blank page.

History also exposes your firm’s habits. One team may underestimate project management. Another may be accurate in production but consistently miss quality review. A third may estimate routine work well and lose control only when several stakeholders are involved.

The goal is not to average every old project. It is to find relevant evidence, understand the conditions around it, and apply that evidence to the new scope.

Group completed Jobs by the work they actually contained

Group Jobs by how your team delivered them. Website redesigns, brand refreshes, campaign launches, audits, integrations, and monthly content programs can all be useful buckets. Use categories that reflect repeatable work, not whatever label happened to sound good in the proposal.

Add a few tags that explain complexity. Examples include new versus existing client, one versus several approval groups, content ready versus content incomplete, standard versus custom integration, and routine versus compressed timeline.

Do not overbuild the system. Start with three or four recent jobs in one service area. If the records are messy, reconstruct only enough to compare phases and actual hours. A small usable group is more valuable than a perfect archive that never gets finished.

Keep unusual projects visible but do not let them define the norm. Note why an outlier was different. It may contain a lesson about risk even if it should not anchor a routine estimate.

Read the effort by phase, role, and revision

Compare the same phases across the group. Discovery may stay in a tight range while design varies with the number of reviewers. Development may be predictable until a custom integration appears. Project management often grows when approvals scatter across several people.

Look at roles as well as totals. If senior strategy used fewer hours but more junior production was required, the total alone hides the delivery shape. Capacity planning depends on knowing which people or skills the new job will need.

Review revision and rework separately where possible. Normal revision belongs in the planned delivery pattern. Rework caused by an internal mistake may call for a workflow change. Client-driven expansion may call for a clearer scope boundary.

Compare the estimate with what the Job actually took. The gap tells you which assumptions tend to fail. The actual effort tells you where the next baseline should start.

A guide to comparing estimated effort with actual effort can help you set up the same phase structure on both sides, so the difference is useful rather than just a project-level overage.

Anchor the new estimate to a real range

Select the closest completed jobs and use their actual phase ranges as the starting point. Then map the new scope to those phases.

If comparable discovery phases consistently land in the same neighborhood, a new routine discovery phase should not suddenly be quoted at half that effort without a very good reason. When a phase varies widely, find the condition that explains the spread instead of averaging away the useful part.

Build the new total from phase and task estimates. Check the role mix and timeline against current capacity. Historical effort tells you how much work is likely, but it does not guarantee that the right people are available when the plan needs them.

State the assumptions behind the range. This makes the estimate easier to revise if the client adds stakeholders, changes inputs, or requests a different delivery approach.

For work with a genuinely new component, use history for the familiar phases and a wider range for the unknown. How do I estimate effort for work I’ve never done before? explains how to add that checkpoint-based structure.

Adjust for what is different before you quote

Create a short difference list before finalizing the estimate:

• More or fewer deliverables.
• Different content readiness.
• Additional stakeholders or approval rounds.
• New technical dependencies.
• A different team or role mix.
• A shorter or more fragmented timeline.
• Stronger quality, testing, or documentation requirements.

Adjust the affected phase, not the whole project. More stakeholders may raise coordination and revision effort without changing production. A new integration may widen technical validation and testing while leaving discovery familiar.

Avoid treating every difference as an increase. A returning client with a known process and prepared inputs may require less effort. The estimate should reflect evidence in either direction.

Record the comparison used. After delivery, add the new actuals to the group and note whether the adjustment was right. The next estimate then benefits from one more completed job and one less assumption.

Workflow management software makes the next round easier when estimated effort, actual effort, phases, people, and timing stay connected to the Job. The point is not to collect history for its own sake. It is to leave the next estimator evidence they can actually use.

FAQ

What if my past estimates were wrong?

That is exactly why you use actual effort instead of the old estimate. What the Job took is true whether or not the original prediction was close. Comparing the two also shows whether your shop tends to miss the same kind of work in the same direction.

How many past projects do I need before the data is useful?

Three or four similar Jobs already give you a better anchor than a blank page and a confident guess. The pattern sharpens as you add more, but you can start as soon as you have a few genuinely comparable Jobs.

How do I handle a new job that is only partly similar?

Estimate the familiar phases from history and treat the genuinely new parts as unknowns with a wider range and an early checkpoint. Most projects are a mix, so you lean on data where you have it and reference-class thinking where you do not.