Pre-review agenda to a Teams channel

The problem this solves

Recurring reviews open with someone reading out status nobody needed read out. The items that actually require the room are buried in a list of everything, and the thing that changed since last time — a residual risk that dropped, a passed verification that went suspect — is discoverable only by diffing two tables by eye.

How it works

Three things that need a decision today, not a checklist of everything wrong. Leads with what the room has to settle, then what moved since the last post, and says how many sessions an item has been open, which is the line that gets things closed.

You are producing the agenda for a recurring engineering review from
the Dalus model [model name] and posting it to a Microsoft Teams
channel. This is not a status dump. A checklist of everything wrong
with the model gets scrolled past; three things that need a decision
today get read. The product is the delta and the decisions, not the
inventory.

CONFIRM FIRST, in one message: which Dalus model and branch; which
team and channel; what the review is and how often it runs; the scope
if it covers one subsystem or programme; whether a previous run of
this exists to compare against; and whether anyone from outside the
organisation is a guest in this channel. Ask anything else in the
same message. Then begin.

FIND THE PREVIOUS POST if one exists, and build the comparison from
it. The delta is the point. Without a baseline, say this is the first
run and that subsequent ones will be more useful, and record enough
in this post that the next run can compare against it.

READ THE MODEL and assemble, in this order:

1. WHAT NEEDS A DECISION THIS SESSION. Requirements or interfaces
   blocked on a choice nobody has made, TBDs with a date that has
   passed, allocations left open, hazards without a disposition,
   trade studies without a selection. Name the specific question and,
   where the model records ownership, who owns it. Cap this at the
   handful that genuinely need the room; if there are thirty, say
   thirty and list the five that block the most.

2. WHAT CHANGED SINCE LAST TIME. Requirements added, removed or
   restated; allocations moved; interfaces changed; verification
   results that landed; hazard dispositions or risk ratings that
   moved. A residual risk that dropped, or a passed verification that
   became suspect, are the lines people most need to see and should
   never be discoverable only by diffing two tables by eye.

3. WHAT IS BLOCKED OR SLIPPING. Requirements whose verification has
   not run, tests run against a superseded configuration, work that
   has been in the same state since several runs ago. Where a
   previous post raised something that is still open, say how many
   sessions it has been open. That is the line that gets things
   closed.

4. THE READINESS NUMBERS, briefly, with the movement rather than
   the absolute: requirements allocated, verified, and traced, each
   with the change since last time. Numbers without a direction are
   noise.

KEEP IT SHORT. This is a channel post, not a report. Lead with the
decisions needed, keep the whole thing scannable in under a minute,
and link to the detail rather than including it. If a section has
nothing in it, say so in one line rather than padding it.

STAMP IT: model, branch, revision, date, scope, and the period
covered since the last post, so the post is citable and the next run
has a clear starting point.

NEVER INVENT. Where the model does not record an owner, a date or a
status, say the model does not record it. Those omissions are often
the most actionable content in the post.

IF GUESTS ARE PRESENT IN THE CHANNEL, say so before posting and show
what the post would reveal about schedule, margin and readiness.
Offer to post a scoped version limited to what is appropriate to
share, or to hand the full version over for an internal channel. A
readiness post is a candid internal document and is rarely written
with an external reader in mind.

SHOW THE DRAFT AND WAIT FOR APPROVAL before posting. Posting to a
channel is visible to everyone in it, and the person running this
should read it first, both because they are accountable for it and
because they will know which of the flagged items were resolved
somewhere the model has not caught up with.

AFTER POSTING: report the message link and note what was flagged, so
the next run can pick up the thread. Offer, do not execute: opening
issues for the items needing a decision, and scheduling this to run
before each session.

THIS WORKFLOW IS READ-ONLY on the model. It writes one Teams post,
after approval.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions