The Problem Is Not the Meeting. It Is What Happens After.
Most project decisions get made. The problem is that they do not get recorded anywhere useful.
The decision lives in someone's head, in a voice memo, in a thread buried three weeks deep in an email chain, or in a PDF markup that only one person has. When a question comes up again — and it will — the team spends real time reconstructing what was decided, who agreed to it, and whether the drawings or the procurement order ever reflected it.
This is not a communication problem. It is a documentation gap. And a lightweight same-day decision log can close most of it.
What a Decision Log Actually Is
A decision log is not a meeting transcript. It is not a full set of minutes. It is a short, structured record of what was decided, who owns the next action, when that action is due, and what else in the project is affected.
The goal is not to document everything. The goal is to document the things that will cause confusion or rework if they are not written down.
Four fields cover most situations:
- Decision: What was agreed. One or two sentences. Plain language.
- Owner: The single person responsible for the next action. Not a group. One name.
- Due date: When the action needs to be complete. A real date, not "soon" or "ASAP."
- Impact: What else this decision touches — a drawing, a sheet, a product, a schedule, a contractor scope.
That is the whole system. The format can be a shared spreadsheet, a running doc, a project management tool, or a simple table in whatever platform the team already uses. The format matters less than the habit.
On a small team — a solo designer and one contractor — the PM role often falls to whoever ran the meeting. On a larger project with multiple consultants and a dedicated coordinator, that person should own the log. The key is that one person is responsible for capturing decisions before the day closes, not that everyone contributes to it in real time.
The 24-Hour Rule
The log only works if it is written the same day.
Waiting until the end of the week means decisions get compressed, details get lost, and the person who was supposed to own an action has already moved on to something else. Waiting until the next meeting means the gap between decision and documentation is long enough for confusion to take hold.
Same-day does not mean immediately after every conversation. It means before the workday closes, someone — a PM, a project lead, a studio coordinator — captures the decisions from that day's meetings, calls, and site visits into the log.
On a small team, this is often a five-minute task. On a larger project with multiple active conversations, it might take fifteen. Either way, it is faster than the time spent later trying to reconstruct what was decided.
Where Teams Get This Wrong
Logging too much. A decision log is not a project diary. If every minor exchange gets logged, the document becomes noise and people stop reading it. Log decisions that have downstream consequences — things that affect drawings, procurement, schedule, or scope. Skip the routine updates.
Assigning ownership to a group. "The team will follow up" is not an owner. When no single person is named, the action tends to fall through. Every logged decision should have one name next to it.
Skipping the impact field. This is the field that prevents the most rework. If a finish selection changes and no one notes that it affects the FF&E schedule and the reflected ceiling plan, those documents will not get updated until someone catches the discrepancy — usually at the wrong moment. The impact field forces the person logging the decision to think one step ahead.
Treating the log as a one-way record. The log is only useful if people actually reference it. A quick review at the start of each weekly meeting — what was decided last week, what actions are overdue, what is still open — keeps the document alive and keeps the team honest.
A Simple Decision Framework
Not every conversation produces a loggable decision. Use this as a quick filter:
- Does this change what is on a drawing or in a document? Log it.
- Does this change what gets ordered, specified, or procured? Log it.
- Does this change who is responsible for something? Log it.
- Does this change a date or a sequence? Log it.
- Is this a routine status update with no downstream effect? Skip it.
The filter takes about three seconds per item. It keeps the log lean and keeps the team focused on what actually matters.
What This Looks Like in Practice
A boutique studio is running a residential remodel. During a Tuesday site visit, the contractor and designer agree to shift a wall two feet to accommodate an existing condition. The designer notes it on a markup. The contractor mentions it to his framing crew.
Without a decision log, the markup stays in the designer's bag, the framing crew hears a verbal instruction, and the drawing set still shows the original wall location. Three weeks later, the cabinet order arrives and does not fit. Everyone is confident the decision was made. No one can prove when, and the drawing never caught up.
With a decision log, the entry from Tuesday reads:
- Decision: North kitchen wall shifted 24 inches west to clear existing beam pocket.
- Owner: Designer — update floor plan and reflected ceiling plan.
- Due date: Thursday.
- Impact: Floor plan, RCP, cabinet layout, possibly millwork dimensions.
The designer updates the drawings. The cabinet order gets reviewed against the new dimensions before it ships. The framing crew has a drawing to work from. The decision is not relitigated at the next site visit because it is already in writing.
The log did not prevent the wall from moving. It prevented the wall from moving invisibly.
Keeping It Simple
The temptation with any new system is to build it out — add categories, add filters, add a status column, add a review workflow. Resist that for the first few months.
Start with the four fields. Run the log for four to six weeks. See what the team actually uses and what gets ignored. Adjust from there.
The goal is not a perfect system. The goal is a record that is accurate enough and current enough that the team stops asking questions that were already answered.
For studios and contractors that want to connect this kind of operational structure to their broader production workflow — drawing sets, procurement tracking, and handoff documentation — Creo's production support work is built around exactly that kind of backend coordination.
Ready to work with a studio that moves at your pace?
Get In Touch