lauraflorentin Monitoring
Important: This plugin assists with project management workflows but does not replace professional judgment. All outputs should be validated with stakeholders and your team before making project decisions.
Status Reporting
Status reports exist for one reason: to surface the information that enables good decisions. A status report that does not lead to a decision, an escalation, or an action item is wasted effort. Every element in the report should answer one of three questions: "Are we on track?", "What needs attention?", or "What do we need from you?"
RAG Status Framework
RAG (Red/Amber/Green) is the universal shorthand for project health. The problem is that most teams apply RAG subjectively -- "it feels green" -- which renders it meaningless. Define explicit, measurable criteria for each color across every dimension so that two different people reviewing the same data would assign the same color.
RAG Criteria Table:
| Dimension | Green | Amber | Red |
|---|---|---|---|
| Schedule | On track or ahead. All milestones within 5% of planned dates. No critical path items slipping. | 1-2 milestones at risk of slipping by 1-2 weeks. Critical path has less than 1 week of float remaining. Recovery plan exists and is being executed. | Critical path milestone missed by >2 weeks. No credible recovery plan. End date at risk of moving. |
| Scope | Scope stable. Change requests processed through formal change control. No uncontrolled additions. | Minor scope creep detected (1-3 unapproved items in progress). Change request backlog growing. Scope boundary needs reinforcement. | Significant scope changes without approval. Team working on items not in the plan. Original objectives at risk of being displaced. |
| Budget | Spend within 5% of plan. Forecast to complete within approved budget. No unplanned expenditures. | Spend 5-10% over plan, or forecast to exceed budget by 5-10%. Contingency being consumed faster than planned. Corrective action identified. | Spend >10% over plan. Forecast exceeds approved budget. Contingency exhausted. Additional funding required. |
| Risk | All identified risks have owners, mitigations, and acceptable residual risk levels. No High-probability/High-impact risks without active mitigation. | 1-2 High risks with mitigations in progress but not yet effective. New risks emerging faster than being resolved. Risk register growing. | Multiple unmitigated High risks. Risk has materialized into an issue with no resolution plan. Project viability threatened. |
| Team Health | Team morale stable. Attrition at or below normal. Capacity matches demand. No overtime trend. Skills aligned to work. | Some team members working sustained overtime (>2 weeks). One key person at flight risk. Skills gap identified but not yet filled. | Key person has left or is leaving. Team burnout evident (quality dropping, absenteeism rising). Capacity insufficient for remaining scope. |
How to use the table: Score each dimension independently every reporting period. The overall project RAG is the worst single dimension -- a project that is Green on everything except Red on Risk is a Red project. Do not average. The weakest link defines the status.
Software Mode: Sprint-Level Status
For software teams running sprints (Scrum, Kanban with cadence, or any time-boxed iteration), the sprint-level status report focuses on delivery throughput, quality, and operational health.
Sprint Status Elements:
- Velocity vs. Plan: Planned story points for the sprint vs. completed story points. Track the 4-sprint rolling average. If current sprint is tracking >20% below the rolling average at the midpoint, flag it Amber.
- Burndown Shape: Is the burndown following the ideal line, flat (blocked), or hockey-stick shaped (back-loaded)? See the Burndown section for shape analysis.
- Blockers: List every item that is blocked, who is blocking it, and when the block will be resolved. Blockers older than 2 business days should be escalated.
- Deployment Status: What has been deployed to production this sprint? What is queued for deployment? Any rollbacks?
DORA Metrics:
DORA (DevOps Research and Assessment) metrics measure software delivery performance. They are the industry standard for assessing engineering team effectiveness. Track these four metrics and compare against the benchmark table below.
| Metric | Definition | Elite | High | Medium | Low |
|---|---|---|---|---|---|
| Deployment Frequency | How often code is deployed to production | On-demand (multiple times per day) | Between once per day and once per week | Between once per week and once per month | Between once per month and once per six months |
| Lead Time for Changes | Time from code commit to running in production | Less than one hour | Between one day and one week | Between one week and one month | Between one month and six months |
| Change Failure Rate | Percentage of deployments that cause a failure in production | 0-15% | 16-30% | 31-45% | 46-60% |
| Time to Restore Service | Time to recover from a production failure | Less than one hour | Less than one day | Between one day and one week | More than one week |
How to use DORA metrics in status reports: Report current period values alongside the target tier your team is aiming for. Example: "Deployment Frequency: 3x/week (High tier -- target: daily by Q3)." Do not try to improve all four simultaneously. Pick the weakest metric and focus improvement efforts there. Improving deployment frequency without improving change failure rate creates more problems, not fewer.
Sprint Status Template:
SPRINT STATUS REPORT
======================
Sprint: [Sprint Name/Number] | Dates: [Start] - [End]
Team: [Team Name] | Report Date: [Date]
VELOCITY:
Planned: [X] story points
Completed: [Y] story points (as of report date)
4-Sprint Rolling Average: [Z] points/sprint
Variance: [+/-] [%] from plan
BURNDOWN: [On track / Flat / Hockey stick / Ahead]
Notes: [Brief description of burndown shape and cause]
SPRINT GOAL: [The sprint goal statement]
Status: [On track / At risk / Missed]
COMPLETED THIS SPRINT:
- [Story/feature] ([X] points) -- deployed [yes/no]
- [Story/feature] ([X] points) -- deployed [yes/no]
- [Story/feature] ([X] points) -- deployed [yes/no]
IN PROGRESS:
- [Story/feature] ([X] points) -- [% complete] -- [on track / blocked]
- [Story/feature] ([X] points) -- [% complete] -- [on track / blocked]
BLOCKERS:
| Item | Blocked By | Days Blocked | Resolution Owner | ETA |
|------|-----------|-------------|-----------------|-----|
| | | | | |
DEPLOYMENTS THIS SPRINT:
- [Date]: [What was deployed] -- [Status: successful / rolled back]
- [Date]: [What was deployed] -- [Status: successful / rolled back]
DORA METRICS (this period):
Deployment Frequency: [value] ([tier])
Lead Time for Changes: [value] ([tier])
Change Failure Rate: [value] ([tier])
Time to Restore Service: [value] ([tier])
RISKS/ISSUES:
1. [Description] -- [Impact] -- [Mitigation/Owner]
2. [Description] -- [Impact] -- [Mitigation/Owner]
3. [Description] -- [Impact] -- [Mitigation/Owner]
DECISIONS NEEDED:
- [Decision] -- needed by [date] -- from [person/group]
General Mode: Project-Level Status
For non-software projects (business transformation, process improvement, facility build-out, marketing campaigns, consulting engagements), status reporting focuses on milestone progress, budget management, and resource utilization.
Project-Level Status Elements:
- Milestone Progress: Percentage complete for each milestone. Use a consistent methodology (see Percent Complete methods in the Burndown section). Show planned vs. actual completion dates.
- Budget Burn Rate: Planned expenditure vs. actual expenditure over time. Express as a percentage and as absolute dollars/hours. A project that has consumed 60% of its budget but completed only 40% of its scope is in trouble.
- Resource Utilization: Planned hours vs. actual hours by resource or resource category. Utilization above 90% for sustained periods signals overallocation and risk.
- Critical Path Status: Identify the longest chain of dependent tasks. Any delay on the critical path directly delays the project end date. Report critical path float (how much slack remains before the end date slips).
Earned Value Metrics:
Earned Value Management (EVM) is the most rigorous method for measuring project performance. It integrates scope, schedule, and cost into a single analytical framework. Use these formulas and the interpretation guide below.
Core Earned Value Formulas:
| Metric | Abbreviation | Formula | What It Tells You |
|---|---|---|---|
| Planned Value | PV | Budget allocated for work scheduled to date | How much work should be done by now |
| Earned Value | EV | Budget allocated for work actually completed to date | How much work is actually done |
| Actual Cost | AC | Total cost incurred for work completed to date | How much you have spent |
| Schedule Variance | SV | EV - PV | Are you ahead or behind schedule? (positive = ahead) |
| Cost Variance | CV | EV - AC | Are you under or over budget? (positive = under budget) |
| Schedule Performance Index | SPI | EV / PV | Efficiency of schedule execution (1.0 = on plan) |
| Cost Performance Index | CPI | EV / AC | Efficiency of cost execution (1.0 = on budget) |
| Estimate at Completion | EAC | BAC / CPI | Projected total cost based on current efficiency |
| Estimate to Complete | ETC | EAC - AC | How much more will it cost to finish |
Interpretation Guide:
| SPI Value | Meaning | Action |
|---|---|---|
| > 1.1 | Significantly ahead of schedule | Verify accuracy. Consider redeploying resources to other projects. |
| 1.0 - 1.1 | On track | Continue current execution plan. |
| 0.9 - 1.0 | Slightly behind | Monitor closely. Identify specific tasks causing delay. |
| 0.8 - 0.9 | Behind schedule | Activate recovery plan. May need to add resources or reduce scope. |
| < 0.8 | Seriously behind | Escalate immediately. Re-baseline the project plan. |
| CPI Value | Meaning | Action |
|---|---|---|
| > 1.1 | Significantly under budget | Verify accuracy. May indicate under-scoped work or quality shortcuts. |
| 1.0 - 1.1 | On budget | Continue current execution plan. |
| 0.9 - 1.0 | Slightly over budget | Identify cost drivers. Look for efficiency gains. |
| 0.8 - 0.9 | Over budget | Formal cost review. May need to reduce scope or find savings. |
| < 0.8 | Seriously over budget | Escalate immediately. Project economics are failing. |
Worked Example:
Project: Office Relocation
Budget at Completion (BAC): $500,000
Report Date: End of Month 3 (of 6)
Planned Value (PV): $250,000 (50% of work was scheduled to be done by now)
Earned Value (EV): $200,000 (40% of work is actually complete)
Actual Cost (AC): $230,000 (actual spend to date)
Schedule Variance (SV): $200,000 - $250,000 = -$50,000 (behind schedule)
Cost Variance (CV): $200,000 - $230,000 = -$30,000 (over budget)
SPI: $200,000 / $250,000 = 0.80 (delivering 80 cents of work per planned dollar)
CPI: $200,000 / $230,000 = 0.87 (getting 87 cents of value per dollar spent)
EAC: $500,000 / 0.87 = $574,713 (projected total cost at current efficiency)
ETC: $574,713 - $230,000 = $344,713 (still need to spend this much)
Interpretation: The project is behind schedule (SPI 0.80) AND over budget
(CPI 0.87). At current rates, it will cost $574,713 instead of $500,000 --
a $74,713 overrun. The PM should escalate to the steering committee, present
recovery options (reduce scope, add resources, extend timeline), and get a
decision within 1 week.
Status Report Template (1-Page)
This template works for both software and general PMs. Tailor the metrics section to your mode.
PROJECT STATUS REPORT
=======================
Project: _______________
Report Date: _______________ | Reporting Period: [dates]
PM: _______________ | Sponsor: _______________
RAG SUMMARY:
| Dimension | Status | Trend | Notes |
|---------------|--------|-----------|--------------------------------|
| Schedule | [R/A/G]| [up/down/flat] | [one-line explanation] |
| Scope | [R/A/G]| [up/down/flat] | [one-line explanation] |
| Budget | [R/A/G]| [up/down/flat] | [one-line explanation] |
| Risk | [R/A/G]| [up/down/flat] | [one-line explanation] |
| Team Health | [R/A/G]| [up/down/flat] | [one-line explanation] |
| OVERALL | [R/A/G]| [up/down/flat] | |
KEY ACCOMPLISHMENTS (this period):
1. [Accomplishment with measurable impact]
2. [Accomplishment with measurable impact]
3. [Accomplishment with measurable impact]
4. [Accomplishment with measurable impact] (optional)
5. [Accomplishment with measurable impact] (optional)
UPCOMING MILESTONES:
| Milestone | Planned Date | Forecast Date | Status | Owner |
|-----------|-------------|---------------|--------|-------|
| | | | | |
| | | | | |
| | | | | |
RISKS & ISSUES (Top 3):
| # | Type | Description | Impact | Probability | Mitigation | Owner |
|---|-----------|-------------|--------|-------------|--------------------|-------|
| 1 | [Risk/Issue] | | [H/M/L]| [H/M/L] | [Action + ETA] | |
| 2 | [Risk/Issue] | | [H/M/L]| [H/M/L] | [Action + ETA] | |
| 3 | [Risk/Issue] | | [H/M/L]| [H/M/L] | [Action + ETA] | |
DECISIONS NEEDED:
- [Decision description] -- Needed by [date] -- From [person/group]
- [Decision description] -- Needed by [date] -- From [person/group]
HELP NEEDED:
- [What you need] -- From [person/team] -- By [date]
- [What you need] -- From [person/team] -- By [date]
Audience-Specific Formatting
The same underlying data should be packaged differently depending on who is reading it. Sending the engineering team a three-bullet executive summary wastes their time. Sending the CEO a five-page sprint report wastes theirs.
Executive Audience (CEO, VP, C-Suite):
Format: 3 bullets, 1 paragraph max. Delivered via email or Slack message, not a deck.
- Overall RAG status with one-sentence explanation of any non-Green dimensions
- The single most important risk or decision that needs their attention
- One key metric showing trajectory (velocity trend, budget burn rate, milestone completion %)
Example: "Project Aurora: Amber overall. Schedule slipped 1 week due to vendor delay on API integration (recovery plan in place, back on track by March 15). Budget on track. Decision needed: approve $12K additional spend for temporary contractor to parallelize the blocked workstream. Current velocity: 34 points/sprint (target: 38)."
Team Audience (Engineers, Designers, Analysts):
Format: Full detail. Sprint status report or project status report as templated above. Shared in a team wiki or project channel.
Include: Every metric, every blocker, every action item. The team needs granular visibility to do their work. Do not summarize away the details they need to self-organize and unblock each other.
Steering Committee Audience:
Format: RAG summary table + decisions needed + budget snapshot. Delivered as a 2-3 slide deck or 1-page document.
Content:
- RAG table with trend arrows (is each dimension improving or worsening?)
- Budget: planned vs. actual spend, forecast to complete, variance explanation
- Top 3 risks with mitigation status and any escalation requests
- Decisions needed with options and PM recommendation
- No sprint-level detail. No individual task status. No blockers unless they require steering committee intervention.
Status Report Anti-Patterns
All-Green Syndrome:
The project reports Green across all dimensions for weeks or months, then suddenly flips to Red. This means the status was not being assessed honestly -- problems were growing beneath a veneer of optimism. Causes: PM fears delivering bad news; stakeholders punish Amber/Red status; criteria are too vague ("it feels okay"). Fix: Define explicit, measurable RAG criteria (use the table above). Reward early Amber reports that come with recovery plans. A team that reports Amber early and recovers is performing better than a team that hides problems until they become unrecoverable.
Burying Bad News:
The report is technically accurate but buries concerning information in the middle of a wall of text, or frames serious issues with minimizing language ("slight delay" when the delay is 3 weeks; "minor budget pressure" when you have exceeded contingency). Fix: Lead with the worst news. Put the most concerning item at the top. Use direct language. "We are 3 weeks behind schedule on the critical path. Here is our recovery plan." Stakeholders respect directness. They do not respect discovering bad news that was hidden from them.
Report as CYA (Cover Your Actions):
The status report exists primarily to create a paper trail protecting the PM, not to communicate useful information. Symptoms: excessive detail about what the PM did (rather than what the project achieved), defensive language pre-emptively blaming other teams, and no actionable decisions or asks. Fix: Every status report should contain at least one decision request or action item for someone other than the PM. If the report does not ask for anything, it is not driving the project forward -- it is just documentation theater.
Burndown & Forecasting
References
For detailed burndown analysis and forecasting guidance: references/monitoring-reference.md
- Sprint Burndown (Software Mode)
- Milestone Burndown (General Mode)
- Forecast Accuracy Tracking
- Warning Signs in Burndown Shapes
- Forecasting Anti-Patterns