How do I compare estimated vs. actual effort on agency projects?

Compare at the deliverable level, not the project total. Record planned effort for each deliverable by type of work, log actual effort as the work happens, and review the gap while the Job is live. The total hides the story: one deliverable usually carries most of the drift, and that is where the lesson is.

Why the Job total lies

A Job total can look fine while one Deliverable underneath it is eating the estimate alive.

Imagine several Deliverables. Some need less effort than planned. Another needs far more. The savings and overrun cancel each other at the Job level, so the total looks close enough to the estimate.

But the next project may contain the difficult Deliverable without the lucky savings. If you only preserve the total, you will repeat the same bad baseline and call the next surprise unpredictable.

The Deliverable is where the plan meets something the client and team can recognize. Break its effort down further by Service Type when that helps explain the gap. Design may be accurate while development drifts. Strategy may be fine while coordination was never planned at all.

Do not create categories for the pleasure of creating categories. Compare the work at the level where the result can change your next estimate, assignment, or client conversation.

Watch effort and timeline together

Estimated versus actual is not only an effort comparison. Timeline matters too.

Effort variance asks how much work the Deliverable consumed compared with its baseline. Timeline variance asks how long delivery took compared with the plan.

A Deliverable can stay inside its effort baseline and still take far longer because of waiting, dependencies, repeated approvals, or stop-and-start work. That delay can disrupt assignments and push other commitments even if the measured effort looks fine.

The reverse can happen too. A team may consume more effort than planned while still hitting the date through late rescue work or extra people. The client sees an on-time result. The owner sees a delivery pattern that may not be repeatable.

You need both variables because flow is the relationship between effort and time, not either one alone.

Related: How do I estimate creative and technical projects more accurately?

Review the gap while the Job is live

The timing of the review changes what the numbers can do for you.

During the Job, a gap is a decision. You can adjust assignments, narrow remaining work, change a due date, clarify the approval path, or raise a scope conversation with the client.

After the Job, the gap can teach you something, but it cannot rescue the outcome.

Review actual effort against the baseline often enough that there is still something to choose. The right cadence depends on the pace of the work. A short Deliverable may need attention quickly. A longer one may support a regular review. What matters is that the check happens before all the effort is gone.

Do not wait for the Job total to turn red. Look for the first Deliverable or Service Type moving away from the plan. Early drift often feels small, which is precisely why it is still manageable.

Diagnose the gap before reacting

An overrun does not tell you what caused it. Start with three possibilities.

The plan was wrong

Perhaps the team underestimated the complexity, left out a kind of work, relied on a weak assumption, or used an old baseline that no longer fits. The response is to improve the next plan and, if possible, adjust the current one.

Execution went wrong

The scope may be stable, but the workflow created rework, unclear ownership, poor handoffs, or an assignment mismatch. The lesson belongs in how the firm delivers, not necessarily in a larger future estimate.

Scope moved

The client requested more, the team added work without a decision, or the definition of done expanded. That is not simply an estimating failure. It is a scope change.

When scope moves, preserve the original baseline and use a Change Order to record what was added. Otherwise, rewriting the estimate makes the new work appear as though it was always part of the plan. You lose the very evidence the comparison was meant to create.

Sometimes more than one cause is true. A weak estimate may meet a real scope change inside a messy workflow. Name each part instead of forcing a single explanation.

Make the habit useful to the team

People stop trusting estimate-versus-actual reviews when every overrun turns into a grade on the person who logged it.

Creative and technical work contains uncertainty. A task taking more effort than planned does not prove the person was slow. The work may have been unclear, the assumptions may have failed, or the team may have discovered a better answer than the plan anticipated.

Frame the review around learning and decisions. Ask what changed, what became harder, what was missing, and what the team would plan differently next time. Include the people who did the work, because the owner cannot diagnose every gap from a dashboard.

Keep individual performance questions separate from estimating questions. If every gap becomes an evaluation of the assignee, people will protect themselves by padding estimates or avoiding honest effort records. That destroys the evidence you need.

Close the loop instead of collecting reports

A comparison is useful only when it changes something.

For active work, make a decision and record it. For completed work, update the future baseline, assumption, workflow, or assignment approach. If scope moved, keep the Change Order with the Job history.

Over time, fewer Jobs surprise you. You learn which Deliverables are steady, which Service Types keep drifting, and where timeline delays quietly push pressure into the rest of the schedule.

That evidence helps you make a better promise next time and gives the team a better plan for delivering it.

Related: Do you need project profitability software, or do you need to see drift?

Where Net Net fits

Net Net keeps the planned LOE pools by Service Type for each Deliverable beside actual effort and timeline signals while the Job is active. Change Orders preserve scope movement instead of erasing the original plan. The system makes the gap visible; your team still supplies the judgment about why it exists and what to do.

FAQ

How big a variance is normal on a creative project?

There is no universal percentage that separates normal from bad. Judge the variance by the uncertainty of the work, the quality of the original assumptions, and whether the same gap repeats. A one-time discovery in unfamiliar work may be useful learning. A familiar Deliverable drifting the same way across several Jobs signals that the baseline or workflow needs to change.

Should I share estimate vs. actual data with clients?

Share what helps the client make a decision. They may need to see that added revisions are consuming the effort planned for another priority, or that a changed approval path affects the timeline. They usually do not need raw internal tracking detail. Keep the conversation focused on the agreed baseline, what changed, and the available choices, without turning the data into blame.

Do I need special software to track this?

No. A careful spreadsheet and consistent effort records can support the comparison. Special software becomes useful when plans, Tasks, effort entries, Change Orders, and timelines are scattered or difficult to keep aligned. Choose the lightest system that preserves the baseline, captures actual effort near the work, and lets you review the gap while action is still possible.