Forecasting Effort with EAC (Estimate at Completion)
Midway through a project, can you answer "if we keep going at this pace, how many hours will it take in total?"
"Design is done and we've already burned 40% of the budget. Will the remaining stages really fit in the other 60%?" Whether you can answer that question with a number rather than a feeling has a big impact on the quality of your project management.
EAC (Estimate at Completion) is the concept built to answer it. It sounds technical, but the idea is simple. This article covers the basics of EAC and how to use it in practice.
What is EAC?
EAC is an estimate of "if we keep progressing at the current actual pace, what will the total effort be at project completion?"
Say you have a project planned at 100 hours. At the point where 40% of the work is done, your actual hours are 50.
You can now see the fact: "the plan said 40% would take 40 hours, but it actually took 50."
If the remaining 60% proceeds at the same pace, the total at completion can be estimated as:
EAC = actual hours ÷ progress rate = 50 ÷ 0.4 = 125 hours
The original estimate was 100 hours, but at the current pace it will be 125. If this number appears mid-project, there's still time to act on it.
How EAC differs from a gut-feel forecast
You can certainly have the feeling "this is heading somewhere bad." But feelings aren't reproducible, and you can't hand them to someone else.
EAC is useful because the forecast — "how many hours over we might end up" — comes out as a number.
- The feeling: "the design phase is slower than expected"
- vs. the number: "computed from the design phase's pace, the project EAC is 150 hours — 50 over the original estimate"
With the latter, you can take next actions: explain to the client, revisit scope, negotiate additional hours. Stay at the feeling stage and "it'll probably work out somehow" procrastination creeps in.
Using EAC as an early-warning system
In practice, the most effective approach is to compute EAC at the end of every phase.
When the requirements phase ends, calculate "actual hours ÷ progress rate." If EAC already far exceeds the original estimate, you can decide early: "the design phase onward needs revisiting."
Conversely, if EAC comes in under the estimate, you can also conclude "we're ahead of plan — the later phases have slack."
Building a cycle of computing EAC at every phase boundary turns the late-project discovery of "we're out of budget" into a mid-project forecast of "at this pace, we will run out of budget."
What you need to compute EAC
Two pieces of information are required.
1. Actual hours (how long things have taken so far)
You need time tracked at the task level and aggregated per phase. Not just "how many hours total so far," but a structure that can answer "how many hours went into the design phase."
2. Progress rate (how much of the whole is done)
Measuring progress is the tricky part. "Completed tasks ÷ total tasks" is common, but unless tasks are uniform in size the rate won't be accurate.
A practical alternative is to use "how much of the estimated effort has been consumed (consumption rate)" in place of progress. For example: "20 actual hours against the design phase's 30-hour estimate → the design phase is 67% consumed."
A quick EAC using per-phase consumption rates
When an accurate "progress rate" is hard to produce, simply checking per-phase consumption — "is this phase going to fit its budget?" — is already quite practical.
For example:
- Design phase estimate: 30 hours
- Design phase actuals (at phase end): 42 hours (140%)
If design took 140% of its estimate, and the same trend continues through the remaining phases, the whole project can be forecast at 140%:
- Original estimate: 100 hours
- EAC (rough): 100 hours × 1.4 = 140 hours
With "a 40-hour overrun is forecast" in hand, you can move early on client communication and estimate revisions.
Will the overrun continue, or was it a one-off? — two ways to read EAC
There's a hidden assumption baked into the formula so far: that the current pace keeps going, the same way, from here on. Design took 140%, so the rest will take 140% too.
But on the ground, that isn't always true. Overruns come in two kinds, and which one you think you're looking at changes how you read the road ahead.
The first is the it-keeps-going kind. The way you estimate is systematically optimistic, or your work is structurally slow — if the cause applies to the phases still ahead, the slippage repeats. Here it's natural to extend the pace you've had so far.
- EAC = actual hours ÷ consumption rate
- In the earlier example: 40% done at 50 hours → 50 ÷ 0.4 = 125 hours
The second is the just-this-once kind. Spec changes clustered only at the start, one person was out for a stretch — if the cause is one-off and won't carry into the remaining work, you swallow the overrun so far and assume the rest proceeds at the original estimate.
- EAC = actual hours + remaining original estimate
- Same example: you've already spent 50 hours, and the original estimate for the remaining 60% is 60 hours → 50 + 60 = 110 hours
The same "40% done at 50 hours" gives 125 hours if you read it as continuing, 110 if you read it as one-off — a 15-hour spread.
I prefer not to commit to one and to hold that spread as is. Being able to say "125 at worst, 110 if it goes well" hands the person you're reporting to some room to judge. Then when the next phase ends, you redraw both. The spread narrows each time you cross a phase boundary, converging toward a single point near the end. And looking back at which number came closer tells you whether your overruns are a "recurring habit" or an "accident."
How much is left — ETC and VAC
If EAC is "what the total ends up at," two numbers derive from it that quietly help when you report.
ETC (Estimate to Complete) = EAC − actual hours. "How many hours are left." With a 125-hour forecast and 50 hours spent, 75 remain. For a budget or schedule conversation, "75 hours to go" is sometimes faster to act on than the total EAC.
VAC (Variance at Completion) = original estimate − EAC. "How far off the original you're headed" — negative means an overrun. A 100-hour estimate with a 125-hour EAC gives a VAC of −25 hours. That one number lets you open with "we're looking at a 25-hour overrun."
The names sound grand, but each is a single subtraction. Produce one EAC and you can state the remainder and the variance on the spot — that's all it is.
Using EAC to improve accuracy
EAC is useful as an in-flight management tool, but it also has value after the project ends.
At project close, compare three numbers: the original estimate, the EAC values you computed along the way (the completion forecasts at each phase end), and the actual final effort.
- How close were the EAC values to the actual final effort? → evaluates the accuracy of your EAC calculations
- How far did the original estimate diverge from the EAC values? → identifies which phases were underestimated
Repeat this retrospective and you'll see "in which phases my EAC tends to drift the most." That becomes calibration material for your next project's estimate.
So where EAC actually earns its keep
Put plainly, all EAC (Estimate at Completion) does is estimate "at the current pace, how many hours will this take in total." The formula is actual hours ÷ progress rate, and if progress is hard to pin down, the estimate-consumption rate works fine as a stand-in. Run it at the end of every phase and you can sense, while you're still mid-project, that "at this rate we'll run short." Compare the values against actuals afterward and you also start to see which phases you tend to misread.
"EAC" carries the air of heavyweight project management, but what you're doing is one division. The hard part isn't the arithmetic — it's whether the per-phase actuals it depends on were actually captured, and in my experience that's where things usually fall apart.
Related articles
- 5 Things I Did to Improve My Estimate Accuracy
- How I Reached "the Phase Ended with Half Its Budget Left"
- Time Tracking That Lets You Say, in Numbers, Where the Time Went
The "EAC (Estimate at Completion) forecasting" covered in this article is exactly what LayerClock supports. Per-phase actuals are aggregated automatically, with a real-time completion forecast based on your current pace (Business plan). Set up your recording habits on the free plan first, then give it a try.