Project Time Log: Keeping One That Survives a Busy Week

A project time log is easy to keep during a quiet week and that is not the week it is for. It earns its existence in the week when two deadlines collide, a client changes the brief on Wednesday, and half the team is somewhere else. That is exactly the week the log goes blank, and it is also the week whose hours would have explained the most.

Logs fail in a recognisable order. First the entries get later, moving from the same day to the next morning to the weekend. Then the categories get vaguer, because reconstructing which of three tasks an afternoon went to is harder than writing "project work". Then a day gets skipped. Once one day is missing, the log stops being a record and becomes a partial sample, and a partial sample of a busy week is worse than nothing, because the missing days are never the average ones.

The fix is not discipline. It is a log designed to be cheap enough that a bad week cannot break it, and a weekly pass that catches the gaps while they can still be filled. This article covers what belongs in a single entry, how few categories to allow, which habits hold under pressure, and how to read the log once it exists.

A time log is not a timesheet

The two overlap and they answer different questions, which matters when deciding what to record.

A timesheet answers how many hours a person worked, day by day and week by week. Its audience is payroll and, for employees in the United States who are not exempt from overtime, a regulator. The Department of Labor's Fact Sheet 21 on recordkeeping sets out what those records must contain, including hours worked each day and total hours each workweek, and states that employers may use any timekeeping method they choose as long as the records are complete and accurate.

A project time log answers where the hours went. Its audience is whoever quotes the next job, invoices this one, or decides whether a phase is going badly. It cares about the split across projects, phases and types of work, and it is indifferent to whether a person worked 38 hours or 42, except as a check that the split adds up.

One record can serve both, and usually should, because keeping two means reconciling two. But the design pressure is different. A timesheet is judged on completeness and defensibility. A log is judged on whether the categories are consistent enough to compare one project to another. A log with perfect hours and inconsistent categories cannot answer a single question worth asking.

What one entry needs, and nothing more

A log entry that takes more than a few seconds to write will not be written in a busy week. Five fields is the working limit, and two of them should be filled in automatically.

Date. Not a timestamp. The date is what the log is organised by.

Project or client. Chosen from a list, never typed. Typed project names produce "Harbour St", "Harbour Street" and "harbour st" in the same log, and totals that are silently wrong.

Phase or work type. Also from a list. This is the field that makes the log useful later, and the field most often left free text, which destroys it.

Hours. In half hour steps. Fifteen minutes is defensible for hourly billing against short units. Anything finer invites postponement.

A note, optional. One line, only when the entry needs explaining. "Reworked after client changed the layout" is the sentence that stops a confusing number from being a mystery a year later.

What does not belong in an entry: a description of the work in prose, a percentage complete, a mood or energy rating, or a link to the deliverable. Each of those has been added to somebody's log template with good intentions and each one lengthens the entry enough to lose a day in a bad week.

The list of projects and the list of phases both have to be short and fixed. That is the part teams get wrong. A log where anyone can add a category grows to forty of them within a quarter, at which point no two projects were logged the same way and comparison is impossible.

Keep the categories few and stable

The question of how many phases to allow is really a question about what comparison the log is for.

A reasonable default for project work is five to eight phases, chosen so that every hour has one obvious home. For a build or fit out, something like survey, design, procurement, on site, snagging and handover. For software, discovery, build, review, release and support. For a studio, brief, production, revision, delivery and account handling.

Then two more categories that are not phases and that most logs omit.

Rework. Hours spent redoing something that was already finished. Collapsing rework into the phase it belongs to hides the single most actionable number in the log. A project where a fifth of the design hours were rework has a brief problem, not a designer problem, and only a separate category shows it.

Unplanned work. Hours that went to something outside the plan, including support, internal meetings and other people's urgencies. Without this category those hours are pushed into whichever project is open, and every project total carries a hidden margin.

Category type	How many	Rule
Projects	As many as exist	Chosen from a list, never typed
Phases	Five to eight	Fixed for a quarter at a time, same set for every project
Rework	One	Never merged into the phase it repeats
Unplanned	One	Present on every log, every week

One test settles most arguments about whether a category should exist. Ask what decision would change if that category's hours turned out to be double what anyone expected. If there is an answer, keep it. If the honest answer is that somebody would find it interesting and then do nothing, merge it into its neighbour. Categories that inform no decision still cost a choice on every single entry, and the cost is paid in the week when choosing is hardest.

The rule that keeps this stable: the phase list changes at most once a quarter, and when it changes, the old list stays readable. A log whose categories shift mid project cannot be compared to itself, let alone to the last project.

Habits that survive a bad week

Three patterns hold up under pressure. The first two are alternatives, and the third is what saves the log when both fail.

End of day, one pass. Five minutes before stopping, the day gets logged. It works because it is one habit at one moment, tied to something that already happens. It fails on days that end abruptly, which in a busy week is most of them.

End of block. The log is written when a block of work ends, not when the day does. A morning on one project is one entry, written when leaving. This suits people whose days come in large pieces, and it is more resilient than end of day because the trigger fires several times.

Weekly reconstruction from evidence. This is the safety net, and it deserves more credit than it gets. On a fixed weekday, the week's log is compared against what is already recorded elsewhere: the calendar, the cards that moved on the board, the messages sent, the deliveries made. Gaps get filled from that evidence rather than from memory.

Reconstruction from evidence is not the same as guessing. A Wednesday with a two hour meeting on the calendar, four cards moved on one project and a site visit in the diary reconstructs to something close to what happened. The same Wednesday reconstructed on Friday with no evidence to hand does not. This is the strongest practical reason to keep the log in the same place as the work rather than in a separate tool: the evidence and the entry form are next to each other, and the reconstruction takes minutes instead of an hour of cross referencing. Where the board, the calendar and the hours share a workspace, the weekly pass is mostly reading.

Two smaller habits matter more than they look. Log the interruption that cost an hour, because unlogged interruptions are why a day's entries never add up to the day. And never let a log stay open for longer than one week, because a log that can be edited indefinitely will be, and nothing drawn from it can be relied on afterwards.

Reading the log, which is the point of keeping it

A log that is never read will not be kept, and teams that abandon time logs usually abandoned reading them first. Three readings are worth the effort, and each takes a few minutes.

Planned against actual, by phase. For a project that is underway, compare logged hours per phase against what was assumed. The useful signal is not the total, which is often close by luck, but the shape. A project that is on budget overall while design ran to double and on site work ran to half has told something important about how it was quoted.

Rework as a proportion. Tracked across projects, rework is the clearest indicator of whether the front of the process is working. Rising rework on similar projects points at briefs, approvals or handovers, not at execution.

Unplanned work as a proportion of the week. This number is usually a surprise the first time it is measured, and it is the one that makes capacity planning honest. A team that is 30 percent unplanned cannot commit 100 percent of its hours, and the log is the only way to know the figure rather than argue about it.

None of these readings needs a dashboard. A weekly total per phase, written next to the assumption it was quoted against, does the work. What matters is that the reading happens at a fixed moment, because a log that is only read when something has already gone wrong is being used as evidence in an argument rather than as an early signal.

The reading that is not worth doing is per person comparison of hours logged. It converts the log from a planning instrument into a surveillance one, and the immediate effect is that entries start being written to look right rather than to be right. At that point the log still exists and no longer means anything.

What to change first

Cut the log down to five fields and fix the phase list at six or fewer, then add the two categories most logs are missing: rework and unplanned work. Pick one capture habit, end of day or end of block, and put a fifteen minute weekly pass on the calendar where gaps get filled from evidence rather than memory.

Then read it once, for rework and unplanned work as proportions, and act on whichever is larger. If the evidence for the weekly pass sits in the same workspace as the log, that pass stays short enough to survive the week it is needed for. Pinateca keeps kanban, Gantt, calendar and timetable boards together and is free for up to five people and ten boards, with timesheets available as an add-on for the teams that bill by the hour.

Q1. How often does a project time log need to be updated to stay accurate?

Same day is best, end of block is a close second, and a weekly pass against evidence is the practical floor. Accuracy falls off sharply after about 48 hours because the detail that fixes an entry, such as who interrupted what and for how long, is gone. A weekly pass anchored to calendar entries and board activity holds up far better than one anchored to memory.

Q2. How many categories should a time log have?

Five to eight phases, plus one for rework and one for unplanned work. Fewer than five and the log cannot tell you where a project went wrong. More than eight and people stop choosing consistently, which makes any comparison between projects meaningless. Keep the list fixed for at least a quarter.

Q3. What is the difference between a project time log and a timesheet?

A timesheet answers how many hours each person worked and is aimed at payroll and compliance. A log answers where the hours went and is aimed at quoting, invoicing and spotting problems. One record can serve both, but the log's value depends on category consistency, while the timesheet's depends on daily and weekly completeness.

Q4. Is it worth logging time on projects that are already fixed price?

That is where it matters most. A fixed price project has no hourly invoice to check the hours against, so the log is the only way to know whether the price was right. Two or three logged projects of the same type turn the next quote from a guess into a range with evidence behind it.

Q5. What should be done about hours nobody can account for?

Leave the gap visible rather than spreading it across projects. A week where two hours cannot be placed is information: either the work was invisible, or the interruptions were not logged. Filling the gap by padding the nearest project destroys the one number the log exists to produce. Recording it under unplanned work with a note is the honest option. The guide covers setting up a weekly pass that surfaces these gaps while they can still be explained.