EstimationPublished August 1, 2026

The 30-Minute Month-End Estimate vs. Actual Review

The thinking on how to improve estimate accuracy I've collected in a separate article — estimate the near things finely, start from deliverables, reference past logs, that kind of methodology. But among those, exactly one becomes wholly void unless you keep it up: the review.

A method, once learned, sticks; a review only works if you do it every month. And "every month" is the hard part. So this article isn't the general theory of accuracy — it narrows to the concrete procedure for keeping the review going as a thirty-minute month-end ritual. The practical stuff: what to open, in what order to look, what to keep.

Precondition: Be in a State to "Lay It Side by Side"

Before the ritual, estimate and actual have to sit in the same unit. "It sort of felt like it took longer" is nothing to review. The measured time has to be tied to the unit you estimated — the deliverable or the task.

This isn't month-end effort; it's decided in daily recording. Stack time with a timer onto the unit you placed an estimate on, and at month's end the line "this deliverable, estimated 8 hours, actual 13" is already in hand, no searching. Backfill from memory instead and that line itself is fiction and reviewing it means nothing. The prep that makes the ritual light was actually done across the previous month.

In the 30 Minutes, What to Look At and in What Order

The ritual itself I run in roughly this order. For reference, here's how I do it.

In the first five minutes, I skim the deliverables completed that month, with estimate and actual side by side. I don't try to scrutinize everything. All I do here is "flag the ones that missed big." The ones finished in half the estimate, the ones that took double — pick up three to five extremes.

In the next fifteen minutes, I look at the picked few one by one and think about why they missed. This is where the head works hardest. As I'll write below, the goal is to find "the pattern across several" rather than each individual reason, so I don't over-dig on any one. I sort them: "this one's a spec change, this one's my own misjudgment."

In the last ten minutes, I put what I noticed into words, and decide one move for next month. The "one-line note" and the "coefficient adjustment" in the next sections are what happen here. When time's up, I close even if I haven't looked at everything. That's the knack for keeping it going.

Look at the "Pattern of the Gap," Not the Gap

Looking at the picked few, you'll want to spend the time reflecting on the one item you missed by a mile. But what to pick up is less the individual blowout and more the pattern in how you miss.

Any single gap has luck and accidents mixed in. That deliverable dragged maybe because a spec change happened to land; reflecting on that doesn't carry forward. What you want is the tendency across several deliverables. Lay out a few months, say, and trace only the deliverables with "design" in the name. If they all run longer than estimated, that's not an accident — it's a pattern.

In my case there were two clear patterns: design and investigation almost always ran longer than estimated; implementation was, surprisingly, about on estimate. Once I saw that, I placed design and investigation tasks at roughly 1.5× from the start, and that alone cut the overall gap considerably. However carefully you reflect on individual engagements, you won't notice this "coefficient being off." Only by laying them out and grouping by kind does it show.

So the month-end question isn't "which one missed most," it's "which kind of work always misses in the same direction." Anything that misses the same way repeatedly isn't a talent problem — the coefficient is simply off, and you fix it next time.

Write One Line of Reason Next to the Number

What helped most wasn't staring at a graph; it was adding one line of reason to each missed deliverable. "Started before the spec settled, so rework." "Didn't count the review round-trips." "Forgot to include prepping the test environment in the estimate." Lines like that.

Let three months of these accumulate and something interesting happens. The same reason recurs. In my case "didn't count the review round-trips" kept coming up, and only then did I realize "I structurally overlook the review back-and-forth." Each one is a small oversight, but laid out, your blind spot takes shape. Numbers tell you the size of the gap but not why. That you can only put into words yourself, and ten of the thirty minutes are worth spending on this note.

LayerClock also plots an accuracy score over time from completed data (the detailed reports are a Business-plan feature). The score is handy for grasping the overall trend, but honestly, what changed my next estimate directly was less the score's ups and downs than this grubby one-line note.

Three Concessions That Keep the Ritual Going

The reason a month-end review dies is usually that you make it too heavy. To keep it going, I concede three things.

One, cap it at thirty minutes. Try to verify every engagement and deliverable perfectly and you'll never do it again. Look at the few that caught your eye, and close when time's up. A sloppy review done every month beats, by a mile, a perfect one done once, six months on.

Two, fix the day. "Sometime around month's end" means never, so I put it on the calendar as a thirty-minute slot at the start of the month — the morning of the 1st, for me. A task that isn't scheduled is the first thing to vanish in a busy month.

Three, aim for one outcome. If even one adjustment comes out of the month — "okay, place design higher from next month" — that session succeeded. Don't make it all-or-nothing. Try to fix three or four and they all end up half-done. Fix exactly one, for sure.

Build a "light but runs every month" state with these three and the review accumulates on its own.

Review Only in Order to Fix

One last thing. A review isn't for beating yourself up. It's not time for feeling bad about a miss; it's time to fix one coefficient in the next estimate. So even in a month that went badly, one adjustment is enough. Ending in "this month was a total loss" is a waste of the time; if you can pull one coefficient out of the fact that it went badly, those thirty minutes paid for themselves.

Keep missing, but fix it at month's end, and in six months your estimates are reliably closer to reality. Conversely, however carefully you estimate, skip these thirty minutes and accuracy won't rise. Whether you know the methods matters less, in the end, than whether this ritual is turning.

LayerClock ties the timer's actuals directly to the deliverable or task you placed an estimate on. The recording that underpins a thirty-minute month-end review is free to start.

Try LayerClock →