Realizing "we're out of budget" at the end of a project is a genuinely painful place to be.
In my time leading contract development projects, I lived through it more than once. The tricky part is that you don't fail to notice in flight. "Design's running a bit hot." "This one feels like it'll be tight." You half-sense it. But it only turns into a hard number at the period close or the delivery deadline — by which point your options are limited. Every time, that's where the scramble happened.
This article lays out a phase-level way of seeing that turns that vague unease into a number while you can still act on it.
Why budget overruns surface only when it's "too late"
There are two main reasons, I think.
One: you're not looking in flight — or it's hard to look. Buried in day-to-day work, you rarely stop to check what percentage of the whole you've used. And even if you try, when hours aren't aggregated by phase and deliverable, you can't tell at a glance. So the danger stays a feeling — "this seems risky" — and never crystallizes into a nameable problem. And a feeling is too weak to act on.
Two: the unit you look at is too large. Manage by "does the project as a whole still have budget?" alone, and the design phase can overeat while the overall total still looks fine. Hours stack up across phase boundaries, and by the time implementation wraps you discover "there's no time left for testing." That "still just a feeling, and now too late" is the classic pattern.
Flip it around and the fix comes down to: turn the feeling into a number while you can still act. And what to watch isn't only "what percent of this phase's budget did I use." It's what percent of the whole you've consumed, and where the current pace lands you in the end — only when you can see that far can you judge "act now and I make it" versus "at this rate I fall short."
How to manage budgets per phase
Here's the concrete procedure.
Step 1: Allocate estimated hours to each phase
Decompose the overall project estimate into phase-level allocations.
For a 100-hour project, for example:
- Requirements: 10 hours
- Design: 25 hours
- Implementation: 50 hours
- Testing & delivery: 15 hours
Decide this allocation at the start. It becomes each phase's budget.
Step 2: Track actuals at the task level
Track actual time at the task level. What matters is recording in a structure where each task's phase and deliverable are known.
With task actuals rolling up to phases, you can see "design phase: 25h estimated, 18h actual (72% consumed)" in real time.
Step 3: Watch consumption and the projected landing — mid-phase and at the boundary
The point is to check consumption not only at a phase's end, but partway through. If design is estimated at 25 hours and the actual is already 20 (80%) while design isn't even finished, you can see right there that only 5 hours remain. This habit of looking mid-flight is what defeats the "didn't look, so it got too late" problem.
- If design crosses 90% of its estimate, revisit the implementation plan
- If design finishes at 50%, decide where to redirect the freed-up hours
And each time a phase's actuals come in, redraw "where this ends up if it continues." If design took 1.4× its estimate, assume the remaining phases trend the same way and roughly project the total landing. A mid-project read of "the 100-hour plan lands at 130 at this pace" still leaves you room to act. (This way of reading the landing is covered in detail in the EAC article.)
When it's visible, you can move on the surplus too
Watching consumption pays off not only when you're short — it pays off when you have slack, too.
On one engagement I'd budgeted the design phase with a thick buffer. The actual design moved faster than expected, and at phase end I hadn't used even half the estimate. The reason I could consciously decide to "move the freed hours into a risk buffer for implementation" was that I was watching per-phase consumption as numbers. The back half of the project then ran with comfortable margins.
If all I could see was "how many hours remain on the whole project," I'd never have noticed that slack. Seeing it in numbers is about catching danger early — and, equally, about spotting usable room you can redeploy.
Visible effort changes team communication
Managing effort per phase also makes status much easier to share.
"We've consumed 80% of the design phase's hours. At this pace, design needs to finish within the remaining 20% (5 hours)" is more concrete than "design is running behind" — and it's information members can act on.
Say "we're behind" by feel and all the other side can do is "try harder." Say it in numbers — "we've consumed 80% of design's hours and need to finish in the remaining 5" — and it turns into a concrete conversation: "then let's cut review to one round," "let's push this feature to the next phase." Numbers shift the air from blame to the next move.
Problems surface sooner, and countermeasure discussions happen on numbers. In client progress reports too, "phase A completed at 75% of budget" carries evidence, and evidence builds trust.
On multi-person projects, per-phase records also help you see who is spending time where. If hours are skewing toward one person, you can rebalance early.
Don't treat the estimate as something you make once
Practicing phase-level management taught me something: an estimate isn't "finished before the project starts" — it's something you keep updating based on actuals.
When implementation begins, the design phase's actual hours are now fixed. Use that number to recompute "how many hours remain for the later phases (testing, delivery)" and revise the plan if needed.
Running this cycle requires per-phase actuals you can pull out as numbers. Feel-based management — "it seems to be going okay" — can't drive it.
Re-drawing an estimate mid-project can feel like admitting "my first read was wrong," and it's a little uncomfortable — it used to be for me. But it's the opposite: being able to fix the plan the moment actuals come in is, if anything, the professional move. The first estimate is only a hypothesis made when you had the least information; not updating it once you know more is the stranger choice.
In the end, you're just turning "feeling" into "numbers"
The short version: overruns surface too late because, in flight, they stay a vague "this feels risky," and only become numbers at the period close or the delivery deadline. The job is to turn that feeling into a number while you can still act — allocate a budget per phase, watch consumption mid-phase and at the boundary, and each time actuals come in, redraw "where this ends up if it continues." Just this drops the late scrambles noticeably, and those same figures double as the basis for team updates and client reports. In short, you stop treating the estimate as "made once and done" and keep rewriting it with actuals.
I can't think of much that breaks the "looks fine overall, jams up at the end" pattern other than seeing effort at this granularity. That said, when I get busy I'm the first to skip the end-of-phase check, so this is a place where I think it's fine — even better — to let the system force the issue.
Related articles
- Time Tracking That Lets You Say, in Numbers, Where the Time Went
- Forecasting Remaining Effort: How EAC (Estimate at Completion) Works
- The WBS Breakdown Method That Doubled My Estimate Accuracy
The "reading ahead, phase by phase" approach covered in this article is exactly what LayerClock supports.
Structure work in a four-level WBS (project → phase → deliverable → task), with task actuals rolling up automatically to the stages above. See per-phase consumption and overall progress in real time, so you can turn "this feels risky" into a number before you move. Free to try.
