Why are my project estimates always too low?

Your estimates keep coming in low because you are pricing the obvious work and forgetting the small-shop tax around it: review rounds, client calls, missing inputs, status updates, handoffs, and the inevitable return trip after someone says, “one small thing.” Estimate the whole path from request to approval, then compare planned effort with what the Job actually took. Feed that difference into the next quote. The goal is not a bigger guess. It is an estimate that finally includes the work your team has been doing all along.

The work your estimates keep leaving out

Most teams estimate the work they can picture. The designer sizes the time in the design file. The developer sizes the build. The strategist sizes the workshop and recommendations. Then the Job arrives with a kickoff, a weekly status call, three reviewers, late copy, and a handoff nobody included. The production estimates may have been reasonable. The project total was still short.

Delivery includes the work around the artifact. Someone prepares for the kickoff, turns notes into actions, asks for missing inputs, explains decisions, organizes feedback, updates the plan, and makes the final handoff usable. The team also spends time moving between clients, tools, and priorities.

Look at the full path from request to approval. If a step consumes time, it belongs in the estimate or in a clearly defined shared allowance. Calling it overhead does not make it disappear from the team’s week.

Revision rounds you didn’t count

Revision effort is often described vaguely even when it is one of the most repeatable parts of a project. “Includes revisions” leaves open how many rounds, how feedback is collected, and whether the client can reopen an approved decision. A separate guide to keeping revision rounds from eating the timeline can help you set the boundary.

Estimate a revision round as real work. It includes receiving and consolidating feedback, interpreting conflicting notes, discussing questions, applying changes, checking the result, and presenting it again. A one-hour edit can require another hour of coordination and review.

Define the included rounds by deliverable. State that feedback must be consolidated and that later changes to approved work may affect effort and timing. This is not about being rigid with the client. It is about giving both sides a shared process.

After the project, compare the estimated and actual revision hours. If the first round is usually close but the second expands, your next estimate should reflect that pattern.

Coordination, admin, and meetings

Project management is not a mystery percentage you sprinkle on at the end because every Job needs “some PM.” Count the actual work: kickoff prep, status updates, scheduling, approvals, notes, follow-up, and the meetings themselves. A thirty-minute client call with three team members uses ninety person-minutes before anyone prepares an agenda or turns the notes into work.

Count the expected meetings, attendees, preparation, follow-up, status updates, scheduling, and approval management. A weekly thirty-minute client call with three team members consumes more than thirty minutes. The call uses ninety person-minutes before preparation and notes.

Client complexity matters. One responsive decision-maker creates different coordination effort than a committee with separate reviewers. A project with clear content ownership differs from one where the firm must chase inputs.

Make the assumptions visible. If the client adds stakeholders or requests a new meeting cadence, you can explain the effect on effort without sounding as though routine communication is a surprise.

Context-switching and rework

Small firms rarely get the luxury of one Job at a time. A designer leaves a client review, handles a campaign revision, answers a contractor question, and then tries to remember where the original task left off. Time logs may capture the visible production, but the restart still uses capacity. Enough of those switches can make a perfectly familiar task run long.

You do not need to add a separate line for every switch. You do need to notice delivery patterns that create them. Tiny fragmented tasks, unclear priorities, frequent interruptions, and too many simultaneous jobs make the same work take longer.

Rework is different from normal revision. It happens when the team built from a wrong assumption, missed a dependency, used an outdated source, or delivered before internal review. Track it separately when possible. If rework repeats, the answer may be a workflow change rather than a larger estimate.

Breaking work into smaller, clearer units helps expose both problems. See How do I break a big project into estimatable pieces?.

Track actuals to see the real gap

Keep the original estimate attached to the same phases or Deliverables where the team records actual effort. If the quote lives at the project level and every time entry falls into one general bucket, the useful lesson disappears. You will know the Job ran long, but not whether the trouble came from design, approvals, development, or the review loop that would not die.

Review the gap in plain terms:

• Which phase used more effort?
• Which role was affected?
• Was the cause missing scope, extra revision, coordination, rework, or an incorrect task estimate?
• Did the timeline create additional switching?
• Was the problem unique or part of a repeated pattern?

Do this while memories are fresh. A short closeout review is enough. The goal is not to explain every minute. It is to identify the few differences that should change how the next job is planned.

Workflow management software helps when estimates, actual effort, tasks, and timing remain attached to the same job. The team can see drift before closeout rather than reconstructing it later.

Feed the gap back into your next estimate

Turn each finding into a specific change. If client coordination used twice the planned effort on several similar Jobs, update that assumption. If design was accurate but the review rounds were not, leave design alone and fix the review tasks. If rework came from skipping internal QA, add the checkpoint. Blanket buffers are easier, but they hide the exact part of the workflow that keeps biting you.

Avoid a blanket buffer unless the evidence truly shows a general variance. A broad percentage hides the part of the workflow that needs attention and makes future learning harder.

Use ranges when client conditions differ. A single decision-maker may support the low end. Multiple stakeholders, incomplete content, or an unfamiliar approval process may move the estimate higher.

The estimate improves when it preserves the lesson from completed work. For work that is new or unusually uncertain, combine that history with a ranged, checkpoint-based approach rather than forcing false precision.

FAQ

How much should I add for the invisible work?

Track a few comparable Jobs and look for the repeated gap. You may find that coordination runs longer than expected, the second review round expands, or handoff prep never made it into the quote. Use that evidence instead of picking a comfortable percentage and hoping it behaves.

Is it better to overestimate to be safe?

A padded estimate can cost you the work and still teach you nothing. Accurate estimates built from planned and actual effort protect capacity better because you can see which assumption needs to change instead of watching a generic buffer vanish.

How many projects do I need to track before estimates improve?

Even three or four similar jobs reveal clear patterns in where your time goes. The point is not perfect data, it is noticing that a given type of work consistently takes longer than you quote, and adjusting the next estimate accordingly.