Project Status Update Meeting Template

Standard Operating Procedure: Project Status Update Meeting (PSUM)

---

1. Executive Summary & Purpose

The purpose of this SOP is to standardize the execution of Project Status Update Meetings (PSUM). This procedure ensures technical alignment, identifies critical-path blockers, and optimizes resource allocation across Template Registry engineering workstreams. The objective is to convert qualitative progress reports into actionable quantitative data.

2. Scope & Prerequisites

• Scope: All active projects within the Template Registry engineering portfolio.
• Prerequisites:
  • Access to centralized Project Management Tool (e.g., Jira, Linear).
  • Pre-populated status dashboard (automated reporting preferred).
  • Required Tools: Real-time synchronization software (Slack/Teams), Task Management API, Shared Repository (Confluence/Notion).
  • PPE: N/A (Digital environment).

3. Roles & Responsibilities (RACI Matrix)

---

4. Step-by-Step Procedure

Phase I: Pre-Meeting Synchronization (T-minus 24h)

• Review Jira/Linear board for stale tickets or unassigned critical path items.
• Ensure all KPIs (Velocity, Cycle Time, Burn-down) are updated.
• Publish the agenda via shared document link.
• Flag "Red/Yellow" status items specifically to ensure immediate discussion.

Phase II: Execution (Meeting Duration: 25 Minutes Max)

• 00-05 min: Review of "Green" status workstreams (No blockers, on schedule).
• 05-15 min: Deep dive into "Yellow/Red" items (Constraint identification).
• 15-20 min: Resource re-allocation and dependency resolution.
• 20-25 min: Confirmation of action items and owner assignment.

Phase III: Post-Meeting Documentation

• Update central status dashboard to reflect meeting decisions.
• Distribute "TL;DR" summary to stakeholders (Max 3 bullets).
• Log meeting artifacts in the master project repository.

---

5. Quality Assurance & Pro-Tips

Best Practices

• The "Blocker-First" Rule: Always lead with blockers, not progress. Progress is self-evident in the dashboard; blockers require human intervention.
• Data Integrity: If it isn’t in the Project Management tool, it didn't happen. Do not accept verbal updates that contradict digital data.

Metric Thresholds

• Meeting Efficiency: Start time variance < 2 minutes.
• Blocker Resolution: > 80% of blockers identified in PSUM must have an owner assigned before the session ends.

Common Pitfalls

• Status Reading: Do not read the Jira board aloud. Assume all attendees have basic literacy; focus on the implications of the data.
• Scope Creep: If the meeting drifts into technical design, terminate the discussion and schedule a separate breakout session.

---

6. Frequently Asked Questions

Q: What if a stakeholder is missing? Should we postpone? A: No. Proceed with the meeting. Log the absence and assign a specific follow-up task to the stakeholder to review the meeting recording/summary within 4 hours.

Q: What constitutes a "Red" project status? A: Any project where the delivery date is at risk by >10% of the total sprint duration, or where a critical technical dependency lacks a viable path to resolution.

Q: How do we handle "hidden" blockers not showing in the dashboard? A: The "Blocker-First" agenda segment is specifically designed to flush out latent risks. If a team member remains silent, it is the PL’s responsibility to conduct an audit post-meeting.

---

End of Document Authorized by: Julian Vance, Chief Architect, Template Registry.