“Project Log Template: Columns, Example and Step-by-Step Guide”

What is a project log, and why start it at kickoff?

A project log is the project’s memory of commitments: what was promised, by whom, by when, what it depends on, and what has changed. It is written at the moment of commitment, not at the end of the month, which is why kickoff is the only sensible place to start it.

Kickoff is also the last moment when everyone is in the same room with the same incomplete information. Two weeks later, the finance lead is on leave, the vendor has a different account manager, and the “we agreed to phase the rollout” claim has three versions. A log created in that first meeting is the cheapest insurance a project can buy.

The distinction that matters: a task list records work; a project log records obligations and obstacles. “Write migration script” is a task. “Vendor confirms data extract by 12 June or the cutover moves two weeks” is a log entry. The second one changes decisions; the first one fills a board.

One more distinction, because it prevents duplication. A project log is not the risk register (which holds uncertain events and mitigations) and not the issue log (which holds things that have already gone wrong). It holds the dated commitments and dependencies that span both. If your log grows into a 200-row monster, you have merged three documents and will maintain none of them.

What columns belong in a project log template?

Nine columns are enough for most projects, and each one has a job. If a column does not change a decision, delete it.

Two of these are usually missing and both matter. Dependency turns a flat list into a network, so you can see that three amber rows share one cause. Next decision is what converts the log from reporting into management: every row either needs a decision soon or is on track, and a log where no row needs a decision is a log nobody is reading.

Freeze the workstream list at kickoff. If you let people invent workstream names as they go, you get “Data”, “Data migration”, “Migration” and “DB work” as four categories, and the roll-up becomes useless.

What does a kickoff log look like when it is filled in?

Here is an extract from a 12-week platform migration, filled during the kickoff session. Twelve of the thirty rows are shown; the pattern is what matters.

Read the red row carefully. PL-026 is blocked because it depends on PL-014, which is amber because it depends on PL-009, which is amber. Three rows, one cause: schema sign-off. A task board would show three separate red items and three separate owners; the log shows a chain, which is the actual management problem. That single view is worth the forty minutes it took to build.

Note also what the log does not contain: no percentages complete, no hours remaining, no commentary paragraphs. Progress percentages are the most unreliable number in project management, because they are self-reported and rarely updated honestly. A due date, a status from a four-item list, and a rule-based colour tell you more in less space.

How do you build the log in one kickoff session?

Forty minutes, one facilitator, one screen. The speed matters more than the polish, because a log built in the room is owned by the room.

1. Fix the workstreams (5 minutes). Write the four to eight names on the board. Everything that follows must fit one of them. If something does not fit, the workstream list is wrong, and you fix it now rather than in week four.

2. Harvest commitments, not activities (12 minutes). Go around the room and ask each person one question: “What have you just agreed to deliver, and by when?” Write the answers as testable sentences. “Improve data quality” fails the test; “Complete de-duplication of 1.2 million customer records by 30 June” passes.

3. Assign one name per row (8 minutes). Not a team, not a role, not “the vendor”. Say the name out loud and watch for a nod. A row with no nod is a row that will be red in three weeks.

4. Add dates and dependencies (8 minutes). Dates in ISO format, no quarters, no “end of sprint”. Then ask, for each row, “what has to be true before this can start?” and link the IDs.

5. Agree the RAG rules out loud (4 minutes). Green: on track, no change to date or estimate. Amber: date moved, estimate grew by more than 10%, or a dependency slipped. Red: the commitment cannot be met without a scope, budget, or date change. Write the rules at the top of the sheet in one line each.

6. Name the log owner and the review slot (2 minutes). One person updates the table, one 20-minute slot per week, same time. Without a named owner, the log is everyone’s and therefore nobody’s.

7. Publish within the hour (1 minute). Send the link, not an attachment. Attachments fork within two days.

If the session runs long, cut rows rather than quality. It is better to have 22 commitments that people trust than 60 that nobody reads.

How do you keep the log honest week to week?

The weekly review is 20 minutes and follows the same four moves every time. Anything longer becomes a status meeting, and status meetings are what the log exists to replace.

Move one: read the reds and ambers by exception. Green rows get five seconds each, or none. The conversation belongs where the risk is.

Move two: challenge dates that have not moved but should have. A row that has been “in progress, green” for four consecutive weeks is either nearly done or not started. Ask which.

Move three: close or escalate. Anything red for two consecutive weeks goes to the steering group with a decision request attached. Red with no decision request is complaint, not management.

Move four: add new commitments the same day they are made. A commitment made in a corridor and never logged is the most common source of “we never agreed that.”

The maths of a weekly review is unglamorous but persuasive. An 11-person project where status is gathered by asking people individually consumes about 40 minutes per person per week — 7.3 hours, or $403 at a $55 loaded rate, and $18,500 across 46 working weeks. A shared log with owners updating their own rows reduces that to a 20-minute meeting for the same 11 people: 3.7 hours a week, $202, a saving of roughly $9,250 a year on a single project. That is before counting the decisions that get made a week earlier because the information arrived on time.

Worked example: what the numbers look like in week six

Take a 12-week migration with 30 log rows across six workstreams, and a steering threshold of “escalate if more than 15% of open rows are red.”

At the end of week two, the log shows 30 rows: 8 done, 14 green, 5 amber, 3 red. Open rows are 22. Red share is 3 ÷ 22 = 13.6%, under the 15% threshold. No escalation, but the two amber rows in the data workstream share a dependency, so the log owner flags the chain rather than the count.

By week six, 12 rows are done and 4 new rows were added, so there are 22 open rows: 13 green, 6 amber, 3 red. Red share is 3 ÷ 22 = 13.6% again — the same percentage, but the composition changed: the three reds now sit in testing and cutover, which are on the critical path. A percentage threshold alone would have missed it. That is why the review reads the dependency column, not just the colour count.

Cost of a slipped dependency, concretely: PL-009 (schema sign-off) slips five working days. Three people cannot start their rows: a data engineer, a tester and an integration developer. Five days × 3 people × $440 per person-day is $6,600 of idle capacity, plus a possible two-week cutover slip worth roughly $18,000 in delayed benefit. The five-day slip costs more than the entire tooling budget for the project, which is the argument for reviewing dependencies weekly rather than monthly.

How is a project log different from a risk register and a status report?

They overlap in appearance and differ in purpose, and mixing them is why teams end up maintaining none of them properly.

The practical rule: if it has a date and a name, it belongs in the log; if it might happen, it belongs in the risk register; if it already happened, it belongs in the issue log; if it is a summary for someone who will not read the detail, it belongs in a status report. Four documents, four audiences, no duplication.

What are the trade-offs of running one log?

The single-log approach has real costs, and pretending otherwise leads to abandonment.

It slows the first meeting. Forty minutes of structured harvesting feels bureaucratic to a team that wants to start building. The return arrives in week three, which is later than most people’s patience.

It demands honest colours. A log only works if amber is allowed to be amber. In teams where red is punished, every row goes green and the document becomes fiction with better formatting.

It needs an owner with authority. The log owner must be able to say “this row has no owner, so it is not happening” in front of the sponsor. Without that, the log records wishes.

It duplicates the task board if you are careless. Keep tasks in the tool and commitments in the log, and link them by ID. If you copy every task into the log, you will maintain two lists that disagree within a month.

It can hide the long tail. Thirty rows are readable; three hundred are not. Split by workstream once you pass about 60 open rows, and keep a one-page roll-up for the sponsor.

Where does Doitify fit?

Doitify is our product, so this section is disclosure rather than review. The relevant fit is that the log’s weakest link is the handoff between the table and the work: someone updates a row in a spreadsheet, then retypes the same thing as a task. In Doitify, projects, tasks, sub-tasks, checklists, owners and due dates share one structure, with Kanban boards, Gantt charts, roadmaps, calendars, workload views, work and performance reports, automations, import and export, and project documents. A commitment can become a task with the same owner and date, and the weekly report can be generated from the work itself.

The honest limit: Doitify will not define your RAG rules, and it will not make a blocked row escalate itself. Those are agreements between people. The software removes the retyping and the status-chasing, which is where most of the wasted hours actually sit.

What mistakes kill a project log fastest?

Building it after kickoff. A log reconstructed in week five records what people remember, not what they promised, and the difference is always flattering.

Owning rows by committee. “Platform team” is not an owner. If two names are on a row and it slips, both will say the other had it.

Using percentages instead of dates. “70% complete” cannot be verified, cannot be escalated, and is usually rounded. A date can be tested.

Letting red mean “we will discuss it later”. Every red row must carry a decision request and a decision date, or the colour is decoration.

Reviewing monthly. By the time a monthly review happens, an amber dependency has already blocked two people for three weeks. Weekly is the minimum cadence for a project with a date at risk.

Not archiving. When the project closes, freeze the log and keep it. It is the best evidence you have for estimating the next one, because it shows which dependencies actually bit.

Conclusion

The project log is the least glamorous document in project management and one of the few that reliably changes outcomes. It does not need software, a template library, or a governance committee. It needs nine columns, a written RAG rule, one owner per row, and twenty minutes a week.

Build it in the kickoff meeting, while the commitments are still fresh and the people who made them are in the room. Then treat it as the single source for “what did we promise, and what is in the way” — and let the task board handle the work. Projects rarely fail because nobody wrote a status report. They fail because a dependency nobody logged sat red for three weeks while everyone assumed someone else had it.

If this post on project log template was helpful, you might also enjoy Project Management Software for Universities: 2026 Guide and Software Development Project Template: Sections, Example, and How to Use It.