← All insights

The watermelon status report

Green on the outside, red on the inside. Why the steering deck drifts away from what the delivery floor knows, and what to change so the red reaches you while it's still cheap to fix.

I've sat in steering committee meetings where the program status was a confident green, the slides were clean and the room nodded along. Then I walked down to the delivery floor an hour later and found a very different program.

Steering committee1

Program status

Green
  • ScheduleMilestones on track
  • QualityRisks being managed
  • ReadinessNothing needs a decision today

Presenter notes, slide 1

The delivery floor, an hour later

  • ScheduleNo sprint goal hit in 6 weeks
  • QualityDefect backlog growing faster than the team could close it
  • ReadinessTest environment down for 3 days

It was the same program that week. The committee got a summary, and the summary had dropped all three of these.

On the outside it's green, on the inside it's red. I call it the watermelon status report, and after 25 years on large ERP programs I assume it's there until someone shows me otherwise.

What a watermelon status report is

The status that travels up the chain, the red, amber or green that lands on an executive's desk, says one thing. The people building the system are living something else.

It's rarely a lie, and nobody sets out to deceive a steering committee. Usually every layer between the keyboard and the boardroom rounds up a little, so by the time the truth reaches you it has been sanded smooth.

Why it happens

On most programs every incentive points toward green. These are the ones I see over and over.

Nobody owns red
A team lead marks their stream amber instead of red, because amber doesn't trigger a meeting they'd have to explain themselves in.
Optimism bias
"We'll make it up in the next sprint" is the most repeated sentence on any troubled program, and it's almost never true. The shortfall gets carried into the next sprint, where it compounds.
Fear of the messenger
If the last person who raised a hard problem got grilled for it or ended up carrying the blame, the next person watches and learns.
Laundering on the way up
Each layer summarizes the one below. Three red items become "some risks we're managing," then amber, then green by the time they clear the program director.
The SI feels it hardest
They're paid to show progress, and their next phase depends on this one looking healthy. A committee that punishes bad news teaches everyone, client and partner alike, to stop bringing it.
Steering committee2

On track

Program status

Program director

Green

Amber rounds up

Roll-up

Amber

The sentence becomes a color

Team lead

"Some risks we're managing"

Three reds, one sentence

Delivery floor
  • No sprint goal hit in 6 weeks
  • Defect backlog growing
  • Test environment down 3 days

What the team is living

  1. Steering deck"On track." What the committee sees.
  2. Program directorGreen. Amber rounds up.
  3. Roll-upAmber. The sentence becomes a color.
  4. Team lead"Some risks we're managing." Three reds, one sentence.
  5. Delivery floorThree red items. What the team is living.
Nobody in this chain lies. The floor reports three red items. The team lead folds them into one sentence, the roll-up calls that sentence amber, and the program director rounds amber up to green before the committee sees it. Illustrative, using the example above.

What it costs

I treat this as the central risk on a program. You're making go/no-go and funding decisions worth tens of millions of dollars on confidence that isn't real.

A status report that's green on the outside and red on the inside is the most expensive document in your program.

The ERP Watermelon Status Report: green on the outside (what the vendor reports), red on the inside (the internal reality)
What gets reported up against what's happening on the floor.

Honest status surfaces problems early, while they're small and cheap to fix. With green-washed status you find them at integration testing, cutover or go-live, when they cost an order of magnitude more and there's no runway left to absorb them. A defect you could have caught in design for the price of a conversation turns into a slipped date and a war room.

Caught in design

The price of a conversation

Found at integration testing, cutover or go-live

An order of magnitude more, with no runway left

The same defect, priced by when it surfaces.

That's also why programs seem to collapse overnight. A program doesn't go from green to red in a single week because something catastrophic happened that week. The red was there all along, and the reporting finally couldn't carry it.

6 weeks
without a sprint goal hit
3 days
with the test environment down
8 weeks
amber, recovery promised next sprint
90%
complete, for a month

Four ways to find the red while it's still cheap

Reading the deck at face value won't get you there. Check it against something it doesn't control.

  1. Read leading indicators

    "Milestone hit" tells you about the past. Velocity, defect inflow against closure, and test pass rates tell you where you're heading.

  2. Watch the trend over several weeks

    One green status means nothing. A stream that's been amber for 8 weeks and keeps promising to recover next sprint is telling you the truth, whatever color it reports.

  3. Triangulate

    Hold the deck up against what the delivery floor tells you, then against the defect data and the test pass rates. When the deck and the data disagree, believe the data.

  4. Ask whether done is done

    The most reliable tell on a troubled program is the milestone that's been 90% complete for a month.

Steering committee3

Milestone progress

On track
90%complete

Presenter notes, slide 3

90% complete, for a month

The last 10% is where the problems are, and it never seems to close.

Change what happens to the person who reports amber

Most of the fix is in how you treat the people who tell you the truth. Red has to be safe to report.

Reward the early raised hand. The person who flags a problem in week three, while you can still do something about it, is the most valuable person on the program. Punish that person and the rest of the team learns to sit on problems until week thirty, when it's too late to do much about them.

Then put mechanical discipline around it. Define done objectively, so it isn't a matter of optimism. Keep RAID and decision logs that are maintained and actually reviewed. A spreadsheet someone updates the night before the meeting doesn't count. And separate the person reporting status from the person graded on it. When the SI grades its own homework, expect straight A's and trust none of them.

This is where an independent read pays for itself: someone with no stake in the color of the status who can sit with the teams, read the defect data and tell you what's true. I've done that work many times. It almost always finds red the reporting had smoothed over, usually early enough to matter.

The last piece sits with you. When the steering committee meets, ask for the bad news first. Programs learn fast what a committee wants to hear, and the deck follows.

Steering committee4

Agenda

1Show me the green

Presenter notes, slide 4

Open with the other question

"What are we most worried about?" Lead with that instead of "show me the green."

Ask what's behind the green

Treat green as a claim and ask to see the evidence for it, the same way you would for red. The programs that come through are the ones willing to report red while there's still time to act on it.

Honest status usually costs one hard conversation early on, which is a lot cheaper than the slipped go-live a watermelon report sets you up for. I'd take the conversation every time.

Let's talk

Put independent eyes on your program.

If you're betting tens of millions on an ERP program, a candid second opinion is the cheapest insurance you'll buy.