Brainforge Knowledge

meeting-catalog

7 min read

Meeting catalog and checkpoints (delivery)

Purpose: Canonical checkpoint chapter for delivery. These meetings exist to enforce the standard through a small number of recurring forcing functions.

If consolidated-delivery-standards.md defines the floor, this document defines the checkpoints that make the floor real.

1. Why this system uses checkpoints

Strong delivery systems rely on well-timed review points that force:

  • plan quality
  • risk visibility
  • alignment between story and build
  • visible progress
  • escalation before surprise

Checkpoints create rhythm, but more importantly they create control.

2. Core checkpoint map

CheckpointCadenceCore attendeesPrimary enforcement goal
Project Review MeetingPer major plan (post-SOW, quarterly refresh, major re-plan)Head of Delivery, CSO (presenter), SL optional/targetedPlan before promise
Weekly leadership syncWeeklyHead of Delivery, CSO + SL leads (or delegates)Portfolio risk, standards visibility, escalation themes
Service line reviewMonthly (30–45 min per line or sub-service, as staffed)Head of Delivery, Service Lead(s) for the line; CSO delegate optionalAllocation truth vs Operating, top cross-client technical risks, standards drift, next-month bets for the service (not account status)
Client weekly touchpointWeekly per engagementCSO + client; SL optionalTangible value, confidence, decisions
CSO-SL alignmentWeekly or asyncCSO + SL for accountStory matches build
Engagement technical standupOptional / as neededSL + ICsDaily unblock when the work actually needs it
Re-gate on material changeAs neededCSO, SL, HoD, sponsor when requiredChange control and commitment reset
Linear truth reviewOngoing; minimum weekly checkCSO + SL + owners as neededSystem of record reflects reality

3. Project Review Meeting

Literal statement

The Project Review Meeting is the gate between SOW and execution. Major plans should pass this review before execution locks in or hard dates are treated as real.

Why it exists

This is how Brainforge enforces plan before promise. The review exists to pressure-test the narrative, dates, dependencies, risks, milestones, and technical approach before the work hardens into client commitment.

Analogy

This is closest to a thesis defense, an investment committee, and a chef’s pass at once: the proposer must show that the work is defensible before it goes out into the world.

What good looks like

  • the plan is coherent and can be defended without improvising the basics
  • the CSO can explain what, when, and why
  • the SL can validate feasibility and technical reality
  • open questions are explicit
  • approval or send-back is decisive

Required inputs

  • signed SOW or agreed scope basis
  • current SOW ↔ project plan
  • dependency view
  • timeline and milestones
  • technical approach and risks

Required outputs

  • approve
  • revise and return
  • clarified open questions
  • sign-off sequence when approved

What sends work backward

  • unresolved dependency risk
  • soft or unclear milestones
  • optimistic dates without justification
  • technical approach that has not been pressure-tested

Detailed PRM support docs live in project-review-meeting/.

4. Weekly leadership sync

Literal statement

This is the portfolio-level checkpoint for risk, capacity, standards misses, and escalation themes.

Why it exists

Delivery leaders need one place where cross-account issues are surfaced before they become isolated fires.

Analogy

Closest to a risk committee or operating review: not a place for ticket theater, but a place where leadership sees the real health of the system.

What good looks like

  • risks are surfaced without defensiveness
  • patterns across accounts become visible
  • standards misses are named early
  • capacity or resourcing mismatches are called clearly
  • the meeting stays above ticket-by-ticket churn

Required inputs

  • material account risks
  • blocked or slipping plans
  • resourcing constraints
  • escalation candidates

Required outputs

  • ownership for interventions
  • decisions on escalation or de-escalation
  • visibility on portfolio heat

What sends work backward

  • accounts being discussed only after they are already burning
  • the meeting degrading into status recitation
  • repeated standards misses with no action owner

See also weekly-leadership-sync.md.

5. Client weekly touchpoint

Literal statement

This is the recurring client-facing checkpoint where the team demonstrates progress, creates confidence, and gets decisions or alignment.

Why it exists

Clients need legible momentum, not just internal activity. This checkpoint turns delivery into something visible and discussable.

Analogy

Closest to the best agency account rhythms: progress should be visible, concrete, and easy for the client to understand.

What good looks like

  • there is a tangible update, artifact, or decision point
  • the story matches actual build reality
  • the update is structured and concise
  • asks are explicit
  • there is no surprise drift between internal state and client narrative

Required inputs

  • real progress since last touchpoint
  • known risks
  • explicit asks or decisions
  • next-step clarity

Required outputs

  • client confidence
  • decisions or clarified asks
  • documented follow-ups

What sends work backward

  • touchpoints with no tangible value
  • optimistic narrative that does not match reality
  • vague asks or no follow-through

6. CSO-SL alignment

Literal statement

This is the account-level alignment checkpoint that ensures the client story and the delivery reality remain the same story.

Why it exists

Most avoidable delivery pain comes from the CSO and SL discovering misalignment too late.

Analogy

Closest to the front-of-house / kitchen alignment in a Michelin system: the guest story and the actual plate cannot diverge.

What good looks like

  • short, clear, and regular alignment
  • no ambiguity on current status, risk, and next commitments
  • CSO and SL are not learning major truths from the client or the board independently
  • disagreements surface early

Required inputs

  • current board truth
  • current client narrative
  • near-term risks or asks

Required outputs

  • one shared story
  • decision on what gets told externally
  • visible ownership for unresolved concerns

What sends work backward

  • side-channel commitments
  • “I assumed you knew”
  • conflicting interpretations of timeline or scope

7. Engagement technical standup

Literal statement

This is an optional, tightly scoped technical unblock checkpoint. It exists only when the work genuinely benefits from daily technical coordination.

Why it exists

Some work needs a tighter operational rhythm. Not all work does.

Analogy

Closest to a tight station sync in execution-heavy environments: high-value when needed, wasteful when used as default theater.

What good looks like

  • the meeting is short and unblock-oriented
  • it is limited to the work that truly needs it
  • it improves flow rather than creating overhead

Required inputs

  • actual technical blockers or coordination needs

Required outputs

  • unblock decisions
  • short-term ownership clarity

What sends work backward

  • turning this into a portfolio-wide default
  • using it for status theater instead of unblock decisions

8. Re-gate on material change

Literal statement

When scope, timing, feasibility, or a major dependency changes materially, the work must go back through review rather than quietly absorbing the drift.

Why it exists

This is how the system protects against unmanaged scope creep and timeline fiction.

Analogy

Closest to re-opening the investment case or re-firing the dish: once the underlying assumptions change, the prior approval no longer holds automatically.

What good looks like

  • the change is named as material
  • the plan is refreshed
  • dates or commitments are re-validated
  • the client-facing story is updated after internal alignment

Required inputs

  • explicit change statement
  • updated plan assumptions
  • revised risks and dependencies

Required outputs

  • revised approval
  • revised commitments
  • revised system-of-record state

What sends work backward

  • absorbing material change informally
  • pretending the old dates still hold
  • allowing scope to expand without corresponding plan revision

9. Linear truth review

Literal statement

The board must be reviewed often enough that it remains a trustworthy execution truth layer.

Why it exists

The system breaks when the plan, the board, and the client story drift apart.

Analogy

Closest to a control book or operating board in other high-accountability systems: if it is stale, leadership is flying blind.

What good looks like

  • ownership is visible
  • blockers are visible
  • stale “in progress” work is corrected
  • milestones still mean something to the client

Required outputs

  • a board that reflects reality closely enough to govern the work

What sends work backward

  • invisible blockers
  • stale status
  • narrative that no longer matches the board

See ../04-standards-and-sops/linear-hygiene-standards.md.

10. Retired or discouraged defaults

  • Portfolio-wide daily status standups are retired by default.
  • Meetings with no forcing function are discouraged.
  • Recurring syncs that do not change decisions, visibility, or quality should be collapsed into async updates.

The point is not fewer meetings for their own sake. The point is fewer low-value meetings, stronger checkpoints.

Formal templates live in standards/ and supporting detail lives in neighboring delivery docs.

Last updated: 2026-03-30

Graph View

Backlinks