Green on the outside: four projects, four status reports, and how to stop the watermelon
A watermelon project is green until the week it's suddenly red. The fix isn't more reporting. It's objective status definitions, honest measures of progress, and reports shaped for the people who read them. Four real-looking examples, side by side.
A watermelon project is green on the outside and red on the inside. Every report says “on track” until, suddenly, it isn't. Watermelons happen for understandable reasons: optimism, fear of looking bad, the hope that the problem will be fixed before anyone notices, and status colors that nobody ever defined.
The book follows four very different projects through the same year: Ledger, an internal expense-system rollout; Beacon, a new product feature; Run the Engine, the ongoing work of keeping a product area healthy; and Harbor, a fixed-price migration for a bank. Each reports status differently, and each is right for its audience. Here they are side by side, with the rules that make them believable.
Data is not a report
| Level | What it is | Example |
|---|---|---|
| Work performance data | Raw observations from doing the work | Issues closed; hours booked; test cases executed; costs incurred |
| Work performance information | Data compared with the plan and analyzed | “SIT 82% executed vs 90% planned”; “SPI 0.95”; “variance −$11k on integrations” |
| Work performance reports | Information compiled for decisions | Status reports, dashboards, steering committee packs, burnup charts |
Data answers what happened. Information answers how does that compare with what should have happened, and why. Reports answer what does a decision-maker need to know and do. A status report that lists completed tasks is data dressed up as a report.
When a project runs inside its tools, most raw data arrives for free: issue state changes, merges, pipeline results, time tracking, label changes. The PM's job shifts from collecting data to interpreting it.
Define the colors before you need them
GitLab uses a three-value health status on epics and issues (On track, Needs attention, At risk) and asks owners to update it weekly. The book's portfolio attaches objective triggers to each value, agreed at planning, so the color follows from facts rather than mood.
| Status | Meaning | Objective triggers (any one is enough) |
|---|---|---|
| On track | Will meet committed scope, date and budget with the current plan | All committed milestones forecast within baseline; CPI and SPI ≥ 0.95; no open critical issue without an owner and a date |
| Needs attention | A credible threat to a commitment, but the team has a plan to recover within its own authority | A milestone forecast past baseline but within float or tolerance; CPI or SPI between 0.90 and 0.95; a critical issue open more than 5 business days; a top-5 risk with probability raised |
| At risk | A commitment will be missed without a decision above the team | A milestone forecast past tolerance; CPI or SPI below 0.90; contingency forecast to run out; an outside dependency blocking the critical path |
Rules: (1) Status is a forecast, not a description of effort. (2) Every yellow or red status states the cause, the recovery plan and the decision needed. (3) Changing color is never a surprise to the sponsor; they hear it first. (4) “Green with concerns” is not a status.
Two things make the definitions work. First, red is not failure. It means a decision is needed from someone above the team, and a PM who reports red early, with options, is doing the job well. Second, leaders have to respond to yellow and red with help rather than blame. Without psychological safety, every project is green.
Measure progress objectively
Much dishonest status comes from subjective “percent complete”. A task sits at 90% for weeks, because the last 10% contains the integration, the edge cases and the waiting. Objective methods fix it:
| Method | How it works | Good for |
|---|---|---|
| 0/100 | No credit until finished | Short tasks, less than a reporting period |
| 50/50 or 20/80 | Part credit at start, the rest at finish | Tasks spanning two reporting periods |
| Weighted milestones | Credit at verifiable steps (30% draft, 60% reviewed, 100% signed off) | Longer work packages |
| Units complete | Credit in proportion to units done | Repetitive work: repositories migrated, test cases passed |
| Level of effort | Credit in proportion to time elapsed | Support activities with no product, like project management |
Agile teams use the strictest version naturally: an item is done (it meets the definition of done) or it isn't. There's no credit for partly complete stories.
Trends beat snapshots
A single SPI of 0.95 says little. A sequence of 0.99, 0.97, 0.95 says the project is steadily slipping; 0.91, 0.93, 0.95 says it's recovering. The simplest trend tool for dates is the milestone trend analysis: at each reporting date, record each milestone's forecast.
| Milestone (baseline) | 9 Jul | 6 Aug | 20 Aug | 3 Sep | 17 Sep | 1 Oct |
|---|---|---|---|---|---|---|
| Design sign-off (9 Jul) | 9 Jul ✓ | |||||
| Build complete (27 Aug) | 27 Aug | 27 Aug | 27 Aug | 27 Aug ✓ | ||
| SIT complete (13 Sep) | 13 Sep | 13 Sep | 20 Sep ▲ | 13 Sep ▼ | 13 Sep ✓ | |
| UAT sign-off (27 Sep) | 27 Sep | 27 Sep | 29 Sep ▲ | 27 Sep | 27 Sep | 27 Sep ✓ |
| Go-live (4 Oct) | 4 Oct | 4 Oct | 4 Oct (float 0) | 4 Oct | 4 Oct | 4 Oct ✓ |
| Hypercare exit (5 Nov) | 5 Nov | 5 Nov | 5 Nov | 5 Nov | 5 Nov | 5 Nov |
The only movement came on 20 August, when the SSO connector delay pushed the SIT forecast out a week and consumed go-live float. Fast-tracking SIT and the vendor's fix brought it back. A milestone that moves once and returns is a managed problem; one that moves at every report is a pattern to escalate.
Four projects, four reports
Ledger: the monthly work performance report
Ledger's monthly report is a Google Doc linked from the program epic, and it doubles as the steering committee pre-read. It carries the formal elements: status against baselines, variance explanations, forecasts, risks and decisions.
Project Ledger: work performance report, September (as of 30 Sep)
Summary: On track UAT signed off 27 Sep; go decision 29 Sep; cutover begins 1 Oct for go-live 4 Oct. Cost slightly over plan, within contingency.
Schedule. All September milestones met. SPI 0.97 (Aug 0.95), recovering as SIT and UAT completed. Float to go-live: 0 days by design (cutover weekend fixed).
Cost. BAC $629k (baseline v2, 27 Aug). PV $512k · EV $497k · AC $507k. CPI 0.98 (Aug 0.97). EAC $642k; VAC −$13k. Contingency remaining after the October change: $62k.
Variances above threshold. Integrations CV −$9k (−11%): SSO workaround, local test accounts and manual card-feed imports for two countries; no schedule impact; accepted, reflected in EAC. Testing SV +$6k: UAT executed ahead of plan.
Quality. SIT 380/380 passed; UAT 118/120 passed (98.3%, exit criterion ≥ 98%); 4 medium defects open, all with workarounds; 0 critical or high.
Risks. Adoption (tracked weekly from go-live); data reconciliation (rehearsal reconciled 99.6%); card feeds (residual accepted).
Decisions needed: none this month.
Beacon: the weekly async status, where the work lives
Beacon doesn't have a status document. Its status is a weekly comment on the feature epic, plus the epic's health field, which dashboards roll up for leaders who want a cross-team view.
Status: On track for GA in 20.4 (16 Sep) with reduced scope. Health moved from Needs attention to On track after the scope cut (decision in the planning issue, 9 Aug).
Done this week: at-risk indicator merged (carried from 20.3); 25% rollout plan approved; docs MR in review.
Next week: enable for 25% of groups on 1 Sep, 100% on 3 Sep if error rate and p95 stay within budget; default-enable MR before the release candidate.
Risks: default-enabling needs to merge before the RC on ~10 Sep; owner Alex. Release post item drafted, in review.
Forecast (customer zero): remaining GA scope 85% likely by 8 Sep.
Needs: none.
Run the Engine: indicators, not milestones
Ongoing work has no finish date, so its status is about service levels and flow. Each month the group reports a handful of indicators on its handbook page, fed by dashboards.
| Indicator | Target | Jun | Jul | Aug | Trend | Note |
|---|---|---|---|---|---|---|
| S1/S2 bugs closed within SLO | ≥ 90% | 88% | 91% | 84% | ▼ | August incident work delayed two S2 fixes |
| Open bugs past SLO | ≤ 5 | 7 | 5 | 8 | ▼ | 3 are S3 maintenance items to re-triage |
| Median lead time, S2 bugs (working days) | ≤ 15 | 19 | 17 | 14 | ▲ | Second database reviewer added |
| Security vulnerabilities past due | 0 | 0 | 0 | 0 | — | July fix shipped 8 days early |
| Incidents (S1/S2) caused by the group | 0 | 0 | 0 | 1 | ▼ | INC-2219 |
| Error budget spent (28 days) | ≤ 100% | 42% | 51% | 96% | ▼ | INC-2219 consumed most of the month's budget |
Actions: re-triage the 3 past-SLO items (by 6 Sep); corrective actions from INC-2219 tracked in the incident issue; hold feature work on epic boards until the error budget recovers above 25% remaining.
Harbor: one row for the portfolio, one comment for the customer
Harbor reports in two directions. Internally, the professional services portfolio report gets one row every Tuesday by 08:00 Eastern. Externally, the PM posts a status comment on the shared epic after each iteration review. And because a project can be on track internally while the customer is unhappy (or the reverse), the row carries two temperatures.
| Field | Entry |
|---|---|
| Progress (one line) | 2,340 / 10,000 repos migrated (plan 2,500); wave 2 starts today with Meridian engineers and standard-change batches |
| Issue + fix + timing | Pace must roughly triple from 19 Oct. Capacity plan in place. Checkpoint 1 Nov: ≥ 4,300 or move 400 subsidiary repos after the freeze |
| Help needed | None yet |
| Internal / customer temperature | Yellow / Green |
| Hours | 1,410 of 2,430 used (58%) with ~60% of the revised schedule elapsed |
Notice that the hours line tells a different story from the repository count. The count lagged; the burn rate was healthy. A report that shows only one of them misleads.
How students practice this
Week 13 is “Measuring progress honestly.” Students write status definitions with objective triggers, run a milestone trend analysis, produce Ledger's monthly report from raw earned-value data they compute themselves, post Beacon's weekly async status on a real GitLab epic, and publish a Tableau Public dashboard of CPI and SPI over the year. The review asks one question above all: would a sponsor believe it?
Adapted from Projects, For Real, chapter 36. The projects, people, vendors and numbers are the book's fictional case studies, set against GitLab's publicly documented practices. Gantt Guild is not affiliated with GitLab Inc.
