Project Status Meeting

Purpose: Surface blockers, align on milestone health, and make decisions needed to keep the project moving

How to run this meeting

The most common failure of a status meeting is that it becomes a reporting session rather than a problem-solving session. If everyone is reading updates out loud from a doc, you're wasting the meeting. Send the status update as a written pre-read 24 hours before — people should arrive already knowing the state of the project. Use the meeting time to discuss what the written update surfaces, not to recite it.

Use red/yellow/green to communicate milestone health, but define the colors explicitly so everyone uses them consistently. Green means "on track — no action needed." Yellow means "at risk — we have a mitigation plan, but watch this." Red means "blocked or off track — we need a decision or intervention today." If a milestone is yellow or red, come to the meeting with a proposed path forward, not just the problem. Your job as a project lead is to escalate blockers, not status.

Keep the meeting to 30 minutes. If it regularly runs over, that's a sign the pre-read isn't being sent or the agenda isn't being enforced. Timebox each section. Decisions needed should be the most important part of the meeting — if a decision isn't made before the meeting ends, name who will make it and by when. Everything else can be asynchronous.

Before the meeting

• Write and send the status pre-read to all attendees at least 24 hours before
• Update milestone health (red/yellow/green) with specific rationale for any yellow or red
• For each blocker, prepare a proposed resolution — not just a description
• Identify the decisions that must be made in this meeting and who has authority to make them
• Review action items from the prior status meeting and update their status

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 30 minutes

---

Milestones

Health status for each major milestone. Green = on track. Yellow = at risk with a mitigation plan. Red = blocked or off track — needs a decision today.

---

Progress

What was completed since the last status meeting? Keep this brief — the pre-read has the detail. Highlight anything that changed the outlook.

• Vendor data migration spike complete: 3,200 records, estimated 2 days of eng work — better than expected
• Authentication redesign reviewed and approved by security team
• Component library shared with vendor ops team for feedback; positive initial response

---

Risks

Active risks that are being monitored or mitigated. Focus on anything that has changed status since last meeting.

• Legal review (Red — escalated): Dana confirmed that legal review cannot begin until the data flow diagram is finalized. That diagram is blocked on a decision about third-party vendor data retention policy. This is on the critical path to the July 11 release. A 2-week slip is possible if this isn't resolved by May 2.
• Design-engineering handoff (Yellow — monitored): The 3-day design delay is being managed by parallel-pathing; no timeline impact projected if handoff completes by May 27 at the latest.

---

Decisions Needed

Specific decisions that must be made before or during this meeting. For each: what is the question, who decides, and what are the options?

Decision 1: Third-party vendor data retention policy

• Question: Do we apply the 90-day retention limit to vendor-submitted documents, or does legal require a longer retention period?
• Decision-maker: Dana Osei (Legal), with Raj Patel's approval if it affects compliance posture
• Options: (A) 90-day limit — enables legal review to start immediately. (B) 12-month limit — requires architecture change, adds ~1 week of eng work. (C) Configurable — most flexible, adds ~2 weeks.
• Needed by: Today — every day this is open delays the legal review start

Decision 2: Internal beta vendor selection

• Question: Which 5 vendors should be in the internal beta cohort?
• Decision-maker: Marcus Webb, with input from Leila Moss (Ops)
• Needed by: May 16 (to allow vendor outreach before June beta start)

---

Next Steps

What happens between now and the next status meeting? Include only commitments made in this meeting — not a full project plan.

• Dana to confirm data retention decision with legal team by April 25; if not resolved, Marcus escalates to Raj
• Marcus to send vendor shortlist to Leila for ops review by April 23
• Suki to share updated design timeline with 1-day buffer built in by April 21
• Next status meeting: April 28, same time

---

Action Items

Follow-up

Send a written decision log within 2 hours of the meeting — anyone not in the room needs to know what was decided and what changed. If a decision was deferred, name the person responsible and the date by which it must be resolved. Update the project timeline and risk register before the next status meeting.