A project meeting ends with an agreement that someone will investigate a reporting discrepancy. The notes say, ?Finance and Engineering to review the figures.? At the next meeting, Finance assumes Engineering is checking the pipeline, while Engineering has been waiting for examples from Finance. Neither team has added the work to its plan.
The action was recorded, but the participants left with different expectations. They had not agreed which figures to examine, who would begin, or what the investigation needed to produce. A reminder may bring the item back into view without resolving those questions.
Follow-through depends on turning a discussion into work that someone can understand and undertake. Motivation and memory can matter, but the organisation should also examine what was agreed, whether capacity was available, and what decision or result the action was meant to support.
Preserving Enough Context to Begin
The reporting discrepancy needs a more specific record. The team should identify the affected report, the period in question, and an example of the difference. It should also explain why the comparison matters and who needs the result.
A workable action might ask a named analyst to compare the revenue report with the billing export for an agreed month, using examples Finance will supply. The result could be a short account of where the totals diverge and which causes need further investigation.
Naming a coordinator makes the next step visible without requiring that person to perform every task. A team can own work collectively when its internal process assigns and tracks it reliably. Cross-team work needs a clear agreement about where that coordination occurs.
Role clarification can help expose expectations that participants otherwise take for granted. For this action, Finance might supply examples and confirm definitions while Engineering examines the relevant transformation. Both contributions need to be understood by the people providing them.
The record belongs where the work will be managed. Meeting notes can preserve the discussion, with a link to the task or team plan that holds the current status. Maintaining disconnected copies increases the chance that one is updated while another continues to circulate.
Agreeing Capacity Alongside Ownership
An assignment is not yet a credible commitment if nobody has considered the existing workload. The analyst may already be supporting month-end reporting, while the engineer needed for the comparison may be responding to an incident.
Before setting a date, the participants should establish the effort and dependencies involved. Waiting for a data extract can extend elapsed time even when the analysis itself is brief. A deadline should account for those conditions and identify what happens if an input is late.
If the work is urgent, someone with appropriate authority needs to decide what moves. Prioritisation has a practical effect when it changes the allocation of time or narrows the scope. Adding another urgent task while retaining every earlier commitment leaves the conflict unresolved.
The owner also needs a way to report a blocker early. That may lead to a revised date, additional help, or a decision that the work no longer justifies attention. An overdue item should prompt examination of what prevents completion before a conclusion is drawn about the person’s commitment.
Connecting Investigation to a Decision
Research can be a legitimate action when important information is missing. The reporting investigation might determine whether a discrepancy comes from different business definitions, a processing delay, or an implementation defect.
The action needs a recipient who can decide what follows. An analyst may complete a sound comparison without authority to choose the company’s revenue definition. If Finance and Product disagree about the definition, further technical analysis may not settle the issue.
Clear decision rights connect the finding to someone authorised to resolve the remaining choice. The task can state what evidence is expected, when it will be reviewed, and which decision it informs.
That distinction also helps define completion. Producing the comparison may complete the investigation while leaving remediation open. The record should show that status clearly rather than allowing a completed task to imply that the reporting problem has disappeared.
For recurring actions such as ?gather more feedback,? the team should ask what information could change the decision. If nobody can identify it, the next step may be to resolve an existing trade-off instead of commissioning another round of research.
Closing the Loop on the Result
A brief review should establish whether the agreed result is available and what it means. The reporting owner can present the comparison, record any remaining uncertainty, and identify the decision or corrective work that follows.
For actions arising from incidents, Google’s postmortem guidance discusses the importance of actionable follow-up and tracking. The same principle applies here: ?fix reporting? needs to become work with a result the relevant users can assess.
If a pipeline correction is made, Finance should verify the affected totals rather than treating a code change as proof that the discrepancy is resolved. If the difference reflects an agreed definition, the report and its documentation may need updating instead.
Actions should also be closed when they are superseded, duplicated, or no longer worth doing. Recording that decision preserves context and prevents stale items from competing with current work. A cancelled action can reflect a sensible change in priorities rather than a failure to follow through.
The aim is not a long checklist after every meeting. Simple actions may need only a name, a clear result, and an agreed date. Work crossing teams or supporting a consequential decision needs more context. For Finance and Engineering, the useful outcome is that the discrepancy reaches an explanation and a decision, with each step visible enough for someone to carry it forward.
