There is a moment in almost every project meeting where something important gets decided. The team agrees to descope a requirement. The project sponsor approves a budget movement. A supplier risk that has been discussed for three weeks finally gets elevated to the register. The call ends. Everyone goes back to their work.
And then the decision sits in someone's head, in a chat thread, or in a set of rough notes on a laptop. Whether it makes it into the formal project record in the next 24 hours depends entirely on whether someone with access to the project management system has the time and the motivation to go back and enter it.
Often, they do not. Not because they do not care. Because every project meeting is followed immediately by another one, or by a waiting inbox, or by the deliverable that was due yesterday. The documentation step gets displaced.
This is what I call the meeting-to-project-record gap. It is not a new problem. But it is a more costly one than most programme leaders recognise, particularly in regulated manufacturing environments where the project record is also a compliance document.
Why the Gap Exists
The gap is not a laziness problem or a culture problem. It is a structural problem rooted in how project management systems are designed and how project meetings are run.
Project management software, broadly speaking, was designed to be the source of truth for planned work: schedules, milestones, resource allocations, risk registers. It was not designed to participate in the conversation where the work gets directed. You go to the meeting, decisions get made, and then you go back to the software to record what happened. The software is not in the room.
This means every update to the project record requires a deliberate context switch. You have to open the system, navigate to the right project, find the right section, and enter the information from memory or from notes. If you do this within an hour of the meeting ending, the information is still reasonably fresh. If you do it the following day, or the day after that, some detail is lost. And if the meeting produced five decisions, a new risk, two action owners, and a change to the acceptance criteria, the probability that all of it makes it into the record at full fidelity is very low.
There is also an ownership problem. In most project environments, it is not entirely clear who is responsible for updating the formal project record after a meeting. The project manager usually does it. But when the project manager is running three or four concurrent projects, each of which had a meeting this week, the documentation task is always competing with the next deliverable, the next issue, the next escalation.
The formal project record tends to reflect the project as it was planned, not as it is actually running. The real project lives in the chat threads, the inbox, and the collective memory of the team.
What the Gap Actually Costs
In a general commercial project environment, the cost of the meeting-to-record gap is measured primarily in rework and miscommunication. Team members act on different assumptions about what was agreed. Actions fall through because no one captured them formally. A decision made in week three gets revisited in week six because no one can confirm what was agreed or why.
In regulated manufacturing — devices, pharmaceuticals, industrial equipment subject to regulatory oversight — the cost is higher. There are two distinct categories of consequence.
Compliance and audit exposure
Regulated environments require that design decisions, risk acceptance decisions, and change approvals are documented with a rationale and an audit trail. The ISO 13485 standard for quality management systems in medical devices, for example, requires that design and development changes are identified, reviewed, and approved before implementation, with records maintained. EU MDR imposes similar requirements for technical documentation.
When the actual decision was made in a project meeting and recorded only in someone's notes — or not recorded at all — there is a gap between when the decision was made and when it entered the formal record. That gap is visible to auditors. It raises questions about whether the process was actually followed or whether the documentation was retrospectively created to satisfy the audit.
The practical risk is not always a failed audit. More often it is the time spent during an inspection trying to reconstruct a decision trail that should have been maintained as a matter of course, and the anxiety that comes with not being sure whether everything that needs to be there actually is.
Delivery risk from ungoverned decisions
Outside the compliance context, the meeting-to-record gap creates a specific delivery risk: decisions that were made informally and never entered the formal record are effectively invisible to anyone not in the original meeting. This matters most on programmes where the team changes over time, where work is distributed across sites, or where the gap between a decision and its consequence is measured in weeks rather than days.
Consider a common scenario in NPI programmes. In a design review meeting in month two, the team agrees to defer a performance test to a later phase because a supplier component is not yet available. This is a reasonable decision with a clear rationale. But if it is not captured in the project record with the rationale and the conditions under which the deferral should be revisited, the next programme manager to look at the schedule in month five sees a gap where a test should be and has no context for why it is missing. They either run the test without the necessary components and generate a non-conformance, or they escalate to reconstruct the decision trail, which takes time and causes delay.
This is not an unusual scenario. It is a predictable consequence of a gap that accumulates week by week across a project lifecycle.
Where the Gap Is Widest
Not every type of project information suffers equally from the meeting-to-record gap. In my experience running NPI and capital programmes in regulated manufacturing, the gap is widest in four specific areas.
Risk decisions
Risks are often first identified conversationally, in status meetings or design reviews, before they make it to the formal risk register. The time between "someone mentions a potential problem" and "that problem appears on the register with an owner and a mitigation" can be days or weeks. See the related post on building a risk register that stays alive for more on how teams can structure this process.
Design and scope decisions
In NPI programmes, design decisions are made continuously throughout the development phase. Many of these are small enough that they do not trigger a formal change control process, but large enough that they need to be documented for the design history file. The meeting where the decision is made and the design history file entry for that decision are often separated by days or weeks — if the entry happens at all.
Action owners
Actions assigned in meetings are frequently not captured in the project record at all, only in the meeting minutes — if minutes exist. When the project manager carries the actions list in their head or in a personal task manager, the actions are not visible to the broader team and do not feed into the schedule or the risk picture.
Dependency changes
When a delivery dependency changes because a supplier has pushed back a date, or a parallel workstream has identified a blocking issue, the update to the schedule typically happens after the fact. The project plan reflects the original dependency until someone updates it, which may be after the impact has already been felt.
The Current State of the Art
Most project teams manage the meeting-to-record gap through a combination of meeting minutes, action logs, and a project manager who works extra hours after the meeting ends to update the system.
Meeting minutes are useful for legal and governance reasons but are a poor substitute for structured project record updates. They capture what was discussed, not what changed in the formal record. They are written in prose, not in the structured format that a project management system requires. And they sit in a separate document, usually in SharePoint or a shared drive, disconnected from the project record itself.
The project manager who keeps the system up to date by working late is doing a good thing for the project and a bad thing for the organisation, because it means the system works only as long as that specific person maintains that habit. It is not a process. It is a workaround.
Some teams use integrated task management tools that can be updated directly from a meeting chat interface. These help with action tracking but do not address the full scope of the gap: risk decisions, scope changes, design decisions, and dependency changes that need to enter the formal project record in a structured way.
What Good Documentation Looks Like
The goal is not perfect documentation of every conversation. That would create as much overhead as the problem it solves. The goal is that every decision that materially affects the project finds its way into the formal record on the day it is made, with enough context that someone who was not in the meeting can understand what was decided, why, and what it means for the project.
For risk decisions: the risk description, the agreed mitigation or acceptance rationale, the owner, and the conditions under which the decision should be revisited.
For scope and design decisions: what changed, what alternatives were considered, who approved the change, and how it connects to the project's acceptance criteria or design history requirements.
For actions: who owns the action, what the deliverable is, and when it is due — visible in the project system, not just in meeting notes.
The standard to aim for is that an auditor or a new team member could look at the project record and understand the project as it is actually running, not just as it was originally planned. That is a higher bar than most project records currently meet. But it is achievable if the update process is embedded in the meeting itself rather than deferred to afterwards.
The Emerging Approach: Capturing Context Automatically
The most promising development in this space is tooling that can participate in the meeting environment and propose structured updates to the project record without requiring the project manager to manually translate conversation into system entries.
The concept works like this: the project management system is given a unique email address for each project. That address is added to meeting invites. The meeting context, whether from a transcript, from email chains, or from a connected team chat, is processed and used to propose specific updates to the project record: new risks, updated action owners, flagged decisions that require documentation. The project manager reviews and approves the proposals rather than generating them from scratch.
The time saving is significant. Research into PM time allocation consistently shows that context capture and manual documentation account for two to three hours per project manager per week on programmes with regular meeting cadences. For a team of five project managers across a portfolio of fifteen projects, that is between ten and fifteen hours per week of time currently spent on bridging the gap between the meeting and the record.
This is an area where the investment in better tooling pays back quickly, particularly in regulated environments where the documentation requirement is not optional.
If you are running an NPI programme or managing a portfolio of regulated projects and this problem resonates, I am interested in hearing how it shows up in your environment. The Arcturus Pro platform is being built specifically for this context, and the meeting assistant capability described above is in active development. The patterns I have described here are consistent across the environments I have worked in, but the specifics vary considerably between med-tech, pharmaceutical manufacturing, and industrial capital programmes.
Frequently Asked Questions
What is the meeting-to-project-record gap?
The meeting-to-project-record gap is the delay between when a decision, risk, or action is agreed in a project meeting and when it is formally recorded in the project management system. In most organisations this gap is measured in days, not hours. In regulated manufacturing, this gap creates traceability and audit readiness problems because the project record is also a compliance document.
Why do project decisions not get documented immediately?
There are three structural reasons. First, the project management system is not in the meeting room — it requires a separate login and a deliberate act of data entry after the fact. Second, ownership is usually informal: it is assumed the project manager will update the record, but this is rarely a named responsibility with a deadline. Third, meetings move faster than the ability to document — decisions get made, the conversation moves on, and the update step gets displaced by the next task.
What are the consequences of poor project decision documentation in regulated manufacturing?
In environments subject to ISO 13485, EU MDR, or FDA 21 CFR Part 820, undocumented decisions create compliance risk. Design decisions, risk mitigations, and change approvals need a documented rationale and audit trail. When these exist only in meeting notes or Slack threads, they are not accessible to auditors and cannot be reliably retrieved during a regulatory inspection. Beyond compliance, undocumented decisions cause rework when team members act on different assumptions about what was agreed.
How can project teams close the meeting-to-record gap?
The most effective approaches combine process and tooling. On the process side: assign a named update owner in every meeting who is responsible for updating the project record before the next status call. Use a standardised decision log format so the bar for entry is low. On the tooling side: the gap closes fastest when the project management system can receive updates from within the meeting environment rather than requiring a separate login. Tools that capture context from meeting transcripts and propose structured entries to the project record are the most effective approach for teams running multiple concurrent projects.
Is this a technology problem or a process problem?
It is both. Process improvements such as assigned decision owners and structured meeting templates reduce the gap but do not eliminate it — the friction of manual data entry remains. Technology that reduces entry friction without replacing human judgment about what matters most is the more sustainable approach. The goal is a system where the formal record is updated as a natural consequence of the meeting, not as an additional task assigned to someone already under pressure.
Running a regulated programme and recognise this problem?
I am talking to programme managers and engineering directors in regulated manufacturing about exactly this. If the meeting-to-record gap is a live problem in your environment, I would like to hear your experience.
Book a 20-Minute Call