In progress is not a useful action-item update

A meeting ends with a clear action: Leon will send the revised rollout plan by Friday.

On Tuesday, the task says in progress. On Friday, it still says in progress. By the following Wednesday, the label has become camouflage. It tells the team that the task is not finished, but nothing about why.

A useful update answers three questions: what changed, what is preventing the next step, and what happens now? If it cannot answer those questions, it is not an update. It is a color on a board.

Separate movement from activity

Activity is easy to report: reviewed the notes, opened the document, spoke to design. Movement is a change in the task's distance from done.

Compare these updates:

• “Working on it.”
• “Draft completed; legal review is the remaining step.”
• “Blocked until Priya confirms the data-retention wording; requested today.”

The second and third updates give the team something it can use. One shows progress against the finish line. The other exposes a dependency before the due date becomes a surprise.

A status should describe the state of the commitment, not prove that the owner has been busy.

Make a blocker actionable

“Blocked” can become another vague label unless the update names the release condition.

Use a short structure:

1. Blocked by: the missing decision, file, approval or response.
2. Waiting on: the person or team able to remove it.
3. Requested: when the owner asked for the input.
4. Next move: what will happen when it arrives—or what happens if it does not.

For example: “Blocked by legal approval on the retention clause. Waiting on Priya; requested Tuesday. If it is not approved by Thursday noon, move the client review to Monday.”

That sentence does more than explain delay. It creates a decision point while there is still time to act.

Change the date when reality changes

Teams often keep an impossible due date because changing it feels like admitting failure. The result is worse: the date stops being believed.

Move a due date when a real dependency changes the plan. Keep the original context in the update, then choose a new date that reflects the remaining work. Do not move it simply to clear an overdue badge.

A credible new date requires:

• a known remaining step;
• an owner for the dependency;
• a reasonable amount of work after the dependency clears;
• visibility to the people affected by the delay.

Review exceptions, not every task

A follow-up meeting should not become a roll call where everybody reads their task list aloud. Use the shared record before the meeting, then spend synchronous time only on exceptions:

• overdue work with no update;
• blocked work without an unblock owner;
• tasks whose finish line changed;
• commitments that affect another decision;
• work that should be cancelled rather than carried forward.

This makes accountability less time-consuming. The record handles routine visibility. The team uses the meeting for judgment.

In Scripta, action items can retain the task, assignee, due date, priority, status and source meeting together. That does not make the update honest automatically. It makes vague status easier to see—and useful status easier for everyone to act on.

Use a five-line update

When a task needs attention, write:

State: blocked. Completed: rollout draft. Blocker: legal approval. Waiting on: Priya by Thursday noon. Next: send to the client one business day after approval.

It takes less than a minute. It saves the next person from opening three tools and asking for a meeting.

“In progress” is acceptable for a brief interval. It is not a permanent home. If the work has moved, show the movement. If it has stopped, show the reason. If the plan has changed, change the plan where everyone can see it.