Track Your Estimates For Eight Weeks And Stop Guessing

If you want to stop guessing at estimates, log two numbers for eight weeks: what you said the work would take, and what it took. That is the whole method. Eight weeks of that data will tell you more about your team than any estimating technique, because it shows you which kinds of work you get right and which kinds you consistently underprice.

Most teams argue about estimates from memory. Memory keeps the disasters and drops the ordinary weeks, so the argument never settles. A log settles it.

What to record

Keep it to five fields. Anything more and people stop filling it in by week three.

• What the work was, in a few words
• The type of work, from a short fixed list you decide up front
• Who estimated it
• The estimate, in hours or days
• The actual, in the same unit

Add the type of work carefully, because that is where the finding comes from. Five or six categories is plenty. Something like: new build, change to existing, bug, integration with an outside system, and anything with a client review in the middle.

Do not add a field for why it went over. People write things there to protect themselves and the answers are useless. The pattern comes from the numbers.

Record the actual honestly

This is the part that decides whether the log is worth anything. The actual is calendar time from start to genuinely finished, including waiting, meetings, review rounds and the fixes after someone tried it.

Teams that record only the hands-on hours end up with a log that says they are excellent estimators and a project record that says otherwise. The gap between those two is exactly the thing you are trying to measure.

If a piece of work was picked up and put down three times, that is part of the story. Note the start and the finish and let the number be what it is.

What the first two months usually show

Nobody can tell you your team's numbers without seeing them. What people generally find, though, is that the misses cluster rather than spread evenly.

Common clusters:

• Work that depends on someone outside the team runs the longest over, because the waiting was never in the estimate
• Small changes to old systems are underpriced more often than big new builds, because the size of the change hides the cost of understanding what is already there
• Anything with a review or approval in the middle carries days of dead time nobody counted
• The same person tends to miss in the same direction, and by a fairly steady multiple

That last one is useful and it is not a criticism. If someone's estimates come in consistently at two thirds of the real number, you have not found a problem, you have found a conversion rate.

What to do with the finding

Do not tell people to estimate better. That never works. Change the process instead.

If waiting on outsiders is the pattern, start estimating waiting as a separate line and book reviewers in advance, since it is one of four structural reasons deadlines slip. If small changes to old systems are the problem, add a fixed block at the start for reading the existing work. If one category is reliably off by a multiple, apply the multiple.

Then keep logging. The point of a log is that it keeps answering, not that it answers once. The numbers also tell you how much room to leave between a target date and a promise date.

Keeping the log where the work is

A spreadsheet works. It works better if it sits next to the work rather than in someone's private folder, because a log nobody can see is a log nobody updates.

This is one reason to keep planning and people records in the same place. SicherOne puts project management, HR and AI agents on one set of records, so the estimate, the actual and who was available that fortnight are not three separate systems you have to reconcile by hand. If half your overrun weeks turn out to be weeks when two people were on leave, that is the sort of thing you only notice when the records sit together.

If you do use an agent to summarise the log, keep a person on the output before it goes anywhere. A pattern in eight weeks of data is a suggestion, not a verdict.

Start with one team

Do not roll this out across a company. Pick one team, tell them exactly why you are doing it, and say out loud that the log is not a performance record. It is not, and if anyone suspects it is, the numbers will quietly become fiction within a fortnight.

Eight weeks in, sit down for an hour with the sheet and see what it says. That hour tends to change how a team plans more than any estimating workshop does, because the argument is finally about evidence. Evidence is also the only thing that helps when the deadline comes from someone who will not do the work.