Skip to content
← Back to Journal
Productivity
7 min read

Estimate a job better: compare planned and actual effort

Compare estimated and actual hours without mixing scope changes and waiting time. Eight fictional jobs show how to calculate differences and assess a range.

By Frihet Team
Estimate a job better: compare planned and actual effort

TL;DR: Keep the initial estimate and compare it with active hours for the same scope, including corrections and agreed reviews. Record added work and calendar waiting time separately. A range from a few comparable jobs can help you revisit assumptions; it does not express a probability, an effort cap or a guaranteed delivery date.

Contents

To improve your estimates of working hours, compare the forecast you saved before starting with the effort that same job actually required once finished. Keep what you underestimated, added work, and waiting time separate. If you mix those three things, a job that took more hours and another that was blocked for several days end up looking like the same problem.

Define the scope in the proposal and distinguish corrections from reviews before comparing hours.

Save a forecast you can check later

The frozen estimate is the one written before starting, along with its date, the deliverable, and the assumptions used. If you make a new forecast during the work, save it as another version: don’t overwrite the initial reference.

Actual effort on the original scope includes fixing your own errors, coordination, and the agreed review. Measure the active hours spent delivering all of that work. Added effort outside the scope is recorded in a separate column, without erasing it from the total hours worked.

Waiting measures calendar hours during which that job was blocked by a piece of data, an approval, or a file. During that time you may have worked on something else. That’s why 24 hours of waiting doesn’t equal 24 hours of effort.

The GAO-20-195G cost estimating guide includes documenting scope and assumptions, collecting data, and updating estimates with actual costs. Here we adapt those principles to an effort log; the guide doesn’t validate the factors or ranges in the freelance example.

Eight fictional jobs, two comparable groups

The table below is entirely fictional: it’s a worked example, not a log of real clients or a representative sample of any trade. It’s meant for practicing the method, not for extracting a typical error rate from freelance work.

There are two groups of four jobs each. Landing (landing_v1) assumes a 500-700 word landing page with a brief provided and one review round. Report (report_v1) assumes laying out six pages with text provided and one review round. Within each group, the same process and experience level are assumed; the estimates vary deliberately to show errors in both directions, overestimates and underestimates.

IDTypeInitial estimate (active h)Actual same scope (active h)Added (active h)Waiting (calendar h)
L01Landing810224
L02Landing101100
L03Landing69348
L04Landing86112
I01Report6610
I02Report88.8236
I03Report56024
I04Report43.218

The full original scope was delivered in all eight cases; nothing was dropped. The added work consists of active hours outside that scope, logged separately: they don’t subtract from the forecast or disappear from the total worked. If a real log were missing some of this — part of the scope dropped, hours mixed together, or a stretch left unrecorded — the right move isn’t to assume zero or force a calculation: it’s to mark that comparison as unusable until you have an equivalent basis.

Where you fell short and where you didn’t

With E the initial estimate and A the actual effort on the same scope, the signed deviation is A − E and the ratio is A / E, which requires E > 0. The percentage deviation is (A − E) / E × 100, with the original estimate as the denominator.

L03 illustrates the sharpest case: 6 h forecast, 9 h actual, that is, +3 h, ratio 1.5, +50%. With the 3 h of added change, that job consumed 12 hours of active work in total. The 48 h of waiting measure calendar time: they don’t add to those 12 h and don’t let you calculate a delivery date. A job can have a lot of waiting and little effort, or the reverse.

L04 shows the opposite direction: 8 h estimated and 6 h actual give −2 h, −25%, and a ratio of 0.75. That describes less effort than expected; it does not by itself demonstrate better quality or productivity. First check that the full scope was delivered.

In the group summary, the time columns measure active hours.

TypeCasesEstimate (h)Actual (h)Added (h)Total active (h)Deviation A−E (h)
Landing432366424
Report423244281
Total8556010705

The total of 70 hours of active work is a sum of logged work, not a calendar duration: it doesn’t incorporate waiting, which in a real log could overlap between different jobs. Do not use a single ratio from these totals to estimate different kinds of work: landing pages and reports are not interchangeable.

A sample range for reviewing the next job

The landing ratios, sorted, are 0.75, 1.1, 1.25, 1.5. Their median is (1.1 + 1.25) / 2 = 1.175. For a new fictional initial estimate of 8 h for a landing page, the resulting central reference is 8 × 1.175 = 9.4 h, with scaled extremes of 8 × 0.75 = 6 h and 8 × 1.5 = 12 h.

For reports, the ratios are 0.8, 1, 1.1, 1.2, with a median of 1.05. For another fictional initial estimate of 8 h, the central reference is 8 × 1.05 = 8.4 h, with extremes between 6.4 and 9.6 h.

Distinguish this median of ratios from the ratio of the landing group totals: 36 / 32 = 1.125. The ratio of totals is equivalent to a mean of ratios weighted by estimated hours: a 10-hour job weighs more than a 6-hour one. The median sorts the four ratios and averages the two central ones, without weighting by size. Neither one is “the correct” measure in the abstract: they’re different metrics and shouldn’t be presented as interchangeable.

In a 2006 conference paper hosted by PMI, Christine Green explains the value of logging effort and characteristics with consistent definitions, and of checking similarity before reusing historical data. It’s a reference on software estimating, not a current PMI standard or a validation of this editorial formula.

When that history stops being useful

The 6–12 h range for landing pages simply scales the observed extremes from four fictional cases. It is a demonstration, not a confidence interval, a probability of finishing within the range, or a guarantee of effort or delivery date. The next job may fall outside it.

This kind of calculation stops being useful when the conditions that made the cases comparable change: if the job size is very different, if there’s more or less client input, if the internal process changed, if the agreed review level is no longer the same, if experience with that type of task is different, or simply if the available data is incomplete. In any of those cases, it makes no sense to apply the factor from the previous sample automatically: you need to investigate the difference before assuming the history is still representative.

Start your own record by saving the frozen initial estimate for each new job and, when closing it, the actual effort on the same scope, the added work separately, and the waiting separately, without rewriting the forecast already noted at the start.

Share

Was this article helpful?

FAQ

Which actual hours should I compare with the initial estimate?

Active hours for the same agreed scope, including corrections of your own errors, coordination and agreed reviews. Record added work and calendar waiting time separately, without overwriting the initial estimate.

Does the historical range guarantee effort or a delivery date?

No. The example uses a few fictional, comparable cases. Its range helps review assumptions; it is not a probability, an effort ceiling or a guaranteed date. The next assignment can fall outside it, so check comparability and data completeness.

Compare with

Frihet — Business without drama

Start Free