Project Health Status Report Template

Standard Operating Procedure: Project Health Status Report Generation & Governance

Document ID: SOP-TR-ENG-409
Effective Date: October 24, 2023
Version: 3.2.1
Review Cadence: Semi-Annual
Author: Julian Vance, Chief Architect, Template Registry

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional requirements for authoring, validating, and distributing Project Health Status Reports within Template Registry engineering environments. The purpose is to establish an uncompromised, deterministic feedback loop regarding project trajectory, technical debt accumulation, risk exposure, and resource allocation. Adherence to this SOP ensures executive leadership receives high-fidelity telemetry required for strategic capital allocation and governance enforcement.

---

2. Scope & Prerequisites

Scope

This procedure applies to all Engineering Leads, Technical Project Managers, and Principal Engineers responsible for delivering initiatives tracked within the Template Registry Project Portfolio Management (PPM) system.

Prerequisites

• Access to the Template Registry Enterprise PPM & Jira instance with Administrator or Project Lead clearance.
• Active contributor access to the project's designated Git repository and CI/CD telemetry dashboards (Datadog/Grafana).
• Standardized Markdown template: TR-ENG-HEALTH-RPT-v3.md.
• PPE (Figurative): Zero-tolerance posture for vanity metrics, optimism bias, or undocumented scope creep.

---

3. Roles & Responsibilities (RACI Matrix)

• Responsible (R): Drafts, compiles, and verifies the initial telemetry for the health report.
• Accountable (A): Certifies structural integrity, metric accuracy, and final sign-off.
• Consulted (C): Provides telemetry feeds, QA metrics, and technical blockers.
• Informed (I): Receives the published report for enterprise risk assessment.

---

4. Step-by-Step Procedure

Phase 1: Telemetry Harvesting & Data Extraction

• Access the project management workspace and extract the preceding sprint's velocity, cycle time, and cumulative flow data.
• Query the CI/CD pipeline telemetry to capture current test coverage percentage, static analysis vulnerability counts, and deployment frequency.
• Review active risk registers and isolate items with a Risk Priority Number (RPN) $\ge 15$.
• Audit budget consumption metrics against the approved baseline Capex/Opex allocations.

Phase 2: Quantitative Health Scoring (The RAG Protocol)

• Calculate the Schedule Health Index (SHI): $\text{Actual Progress} / \text{Planned Progress}$.
• Calculate the Budget Health Index (BHI): $\text{Actual Spend} / \text{Planned Spend}$.
• Determine the composite Red-Amber-Green (RAG) status using the definitive threshold matrix (refer to Section 5).
• Document quantitative justification for any rating deviating from baseline projections.

Phase 3: Qualitative Analysis & Architectural Impact Assessment

• Draft the executive narrative outlining overarching momentum, major milestones achieved, and systemic blockers.
• Consult with the designated Systems Architect regarding any emergent technical debt or architectural drift.
• Formulate risk mitigation strategies with distinct owners and hard deadlines for all identified Amber/Red indicators.
• Map upcoming milestones for the rolling 30-60-90 day horizon.

Phase 4: Validation, Publishing, and Archival

• Execute markdown linting and schema validation against the report template (TR-ENG-HEALTH-RPT-v3.md).
• Submit the draft report to the Accountable authority for cryptographic or digital sign-off.
• Publish the final artifact to the Enterprise Document Repository by Friday 17:00 UTC.
• Archive raw telemetry data snapshots in the project's immutable compliance bucket.

---

5. Quality Assurance & Pro-Tips

Metric Threshold Matrix (RAG Governance)

• Green (Optimal): SHI $\ge 0.95$, BHI $\le 1.05$, Test Coverage $\ge 85%$, Zero critical/blocker vulnerabilities.
• Amber (Warning): $0.80 \le \text{SHI} < 0.95$, $1.05 < \text{BHI} \le 1.15$, Test Coverage $70% - 84%$, Minor technical debt accumulation requiring remediation next cycle.
• Red (Critical): $\text{SHI} < 0.80$, $\text{BHI} > 1.15$, Test Coverage $< 70%$, Unresolved Sev-1/Sev-2 operational blockers.

Pro-Tips & Common Pitfalls

• Pro-Tip: Never report "Amber" twice for the same root cause without an attached, executing mitigation ticket. Two consecutive Amber ratings on the same metric automatically trigger a Red escalation.
• Pitfall: Avoid "Green-Shift" (reporting Green status while underlying telemetry indicates systemic failure to preserve optics). The Enterprise values radical transparency over artificial stability.
• Pro-Tip: Automate metric pulls via API integration with Jira and Datadog to minimize manual data-entry error rates.

---

6. Frequently Asked Questions (FAQ)

Q: What is the protocol if a project slips into "Red" status mid-cycle?
A: Immediate emergency escalation is required. The Project Lead must convene an alignment sync with the Chief Architect within 24 hours of status determination to deploy pre-approved recovery frameworks or invoke scope-shedding protocols.

Q: Can qualitative narrative override quantitative RAG metrics?
A: Never. Quantitative metrics dictate the baseline status. A narrative can explain why a metric is Red or Amber, but qualitative optimism cannot elevate a mathematically deficient status to Green.

Q: Who is authorized to alter the template structure?
A: Only the Chief Architect (Julian Vance) via formal Engineering Change Order (ECO) following a review cycle by the Template Registry Architecture Board.