← All insights Status discipline

The watermelon status report

Green on the outside, red on the inside. The watermelon status report is the most expensive document in your program, and the easiest one 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 team that hadn't hit a sprint goal in six weeks, a defect backlog growing faster than they could close it, and a test environment that had been down for three days. Same program. Same week. Two completely different realities.

That gap has a name. On the outside it's green, on the inside it's red. I call it the watermelon status report, and over twenty-five years on large ERP and Workday programs I've learned to assume it's there until someone proves otherwise.

What a watermelon status report actually is

The mechanics are simple. The status that gets reported up the chain, the red, yellow, green that lands on an executive's desk, says one thing. The lived experience of the people building the system says another. The reporting is green. The work is red.

It is rarely a lie. Nobody sits down intending to deceive the steering committee. It's something more ordinary and more dangerous: a slow, collective rounding-up that happens at every layer between the keyboard and the boardroom. By the time the truth reaches you, it has been sanded down so many times that the splinters are gone.

Why it happens

Watermelon reporting isn't a character flaw. It's what you get when the incentives all point the same direction, and on most programs they do.

Nobody wants to be the one who owns the red. A team lead marks their stream amber instead of red because amber doesn't trigger a meeting they'll have to explain themselves in. Optimism bias does the rest, "we'll make it up in the next sprint" is the most repeated sentence on any troubled program, and it is almost never true. The shortfall doesn't get recovered; it gets carried, and then it compounds.

Then there's the fear of being the messenger. If the last person who raised a hard problem got grilled, sidelined, or quietly blamed, the next person watches and learns. Add a roll-up process where each layer summarizes the one below, and detail gets laundered on the way up, three red items become "some risks we're managing," which becomes a yellow, which becomes a green by the time it clears the program director.

Your systems integrator feels the pull hardest of all. They're paid to show progress, their next phase depends on this one looking healthy, and a steering committee that punishes bad news teaches everyone, client and SI alike, to stop bringing it. You get the reporting culture you reward. If you only ever reward green, green is all you'll ever see.

What it actually costs

Here's why I treat this as the central risk and not a soft one. You are making go/no-go and funding decisions worth tens of millions of dollars, and you're making them 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)
The watermelon status report, at a glance, what gets reported up versus what's really happening on the floor.

When status is honest, problems surface early, while they're small and cheap to fix. When status is green-washed, problems surface late, at integration testing, at cutover, at go-live, when they cost an order of magnitude more to resolve and there's no runway left to absorb them. The defect you could have caught in design for the price of a conversation now costs a slipped date and a war room.

And this is 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. It goes from green to red because it was never actually green, the red was always there, and the reporting finally couldn't hold the weight. The surprise isn't the failure. The surprise is that you were surprised.

How to spot it

You can find the red while it's still cheap, but not by reading the status deck at face value. You have to read past it.

  • Read leading indicators, not lagging ones. "Milestone hit" is lagging, it tells you about the past. Velocity, defect inflow versus closure, and test pass rates tell you where you're heading.
  • Watch the trend, not the snapshot. One green status means nothing. A stream that's been amber for eight weeks and keeps insisting it'll recover next sprint is telling you the truth even when its color isn't.
  • Triangulate. Hold the status deck up against three independent sources, what the delivery floor actually says, what the defect data shows, and what the test pass rates are doing. When the deck and the data disagree, believe the data.
  • Check milestone integrity. Ask whether "done" is actually done. The most reliable tell on a troubled program is the milestone that's been ninety percent complete for a month. The last ten percent is where the truth lives, and it never seems to close.

How to fix it

The fix isn't a better template or a tighter reporting cadence. It's changing what happens to people when they tell you the truth. You have to make red safe.

That starts with rewarding the early raised hand. The person who flags a problem in week three, while you can still do something about it, should be treated as the most valuable person on the program, because they are. Punish that person and you train everyone else to wait until week thirty, when waiting is all that's left.

Around that cultural change, put real mechanical discipline. Define "done" objectively, so it isn't a matter of opinion or optimism. Run RAID and decision logs that are actually maintained and actually reviewed, not a spreadsheet someone updates the night before the meeting. And separate the person reporting status from the person being graded on it, when the SI grades its own homework, you should expect straight A's and trust none of them.

This is also where an independent read earns its keep. 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 actually true. I've done that work many times, and 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. Open with "what are we most worried about" instead of "show me the green." The questions a steering committee asks decide what its program is willing to say. Ask for comfort and you'll be comforted right up to the day it fails.

Green should be earned

Green is not a default. It's a claim, and a claim should be backed by evidence you've actually looked at, not assumed because nobody walked in with worse. The programs that succeed aren't the ones that report green. They're the ones honest enough to report red while there's still time to act on it.

Honesty about status is the cheapest insurance your program will ever buy. The watermelon report costs you everything, and late. The truth costs you a hard conversation, early. Take the conversation.

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.