Green on the Outside, Red on the Inside: Management by Exception as a Governance Control

# PRINCE2

# Governance

# Leadership Insights

Why watermelon reporting survives in organisations that "use PRINCE2", and how tolerances, forecasts and honest exceptions turn it back into a control a regulator would recognise.

October 27, 2026

Panos Mastrogiannis

Green on the Outside, Red on the Inside: Management by Exception as a Governance Control

Why watermelon reporting survives in organisations that "use PRINCE2", and how tolerances, forecasts and honest exceptions turn it back into a control a regulator would recognise.

Most programme boards have met a watermelon. The status report is green. The milestone chart is green. The risk register is a reassuring shade of amber at worst. Then, a few weeks before go-live, the programme turns red all at once, and everyone in the room asks the same question: how did we not see this coming?

The honest answer is usually that someone did see it. They simply had no safe way, and no agreed rule, to say so.

In most industries a watermelon programme costs money and credibility. In regulated sectors such as financial services, payments and market infrastructure, it can also cost a supervisory finding. DORA makes the management body responsible for defining, approving and overseeing the ICT risk management framework, and NIS2 asks management bodies to approve and oversee cybersecurity risk-management measures. A board that approves on green reports which turn out to be fiction has not exercised oversight. It has been managed.

PRINCE2 has had an answer to this problem for decades. We just rarely use it the way it was designed.

Why watermelons grow

Watermelon reporting is rarely dishonesty. It is the predictable result of four conditions most of us will recognise.

Status is a judgement, not a measurement. When "green" means "the project manager feels fine", optimism wins. Nobody wants to be the first to turn red.

Red is punished, green is rewarded. If escalating an issue triggers blame, extra reporting and a difficult board meeting, people delay escalation until they can no longer avoid it.

There are no agreed limits. Without tolerances there is no objective line between "a bit late" and "in trouble". Every deviation becomes a negotiation.

Reports describe activity, not forecasts. "We completed 14 of 20 tasks" says nothing about whether the remaining six will land on time, on budget and at the right quality.

I lived this as Head of IT on a bank merger programme: two banking organisations moving onto a single core banking platform over 16 months, with heavy data cleansing as part of the scope. On paper the plan was solid, with clear milestones and a defined critical path. The reports were another story. Deliverables shown as green were not there on the dates they were due. QA teams sat waiting for releases, and when the releases finally arrived, late and in bulk, the delay surfaced as a "QA bottleneck", which it was not. Red rarely appeared directly; it arrived disguised as a run of ambers. The project manager saw the pattern early, but department heads resisted escalation and fought hard not to be exposed, so the board kept hearing green. My team was last in the sequence, implementing in production, so every hidden delay landed on us: the two months planned for production implementation shrank to two weeks. The programme only turned red when the client escalated it. Two of the four conditions were at work at once: red was punished, and reports described activity instead of forecasts.

What management by exception actually means

Management by exception is often misread as "the board only hears bad news". That is the outcome, not the principle. The principle is that each level of management sets clear tolerances for the level below, delegates authority within them, and is told straight away, and only, when a forecast shows a tolerance will be exceeded.

Three parts of PRINCE2 do the work.

Tolerances on the performance targets (time, cost, scope, quality, benefits and risk, with sustainability added in PRINCE2 7), set by the project board for each stage and by the project manager for each work package. They turn "are we OK?" into a measurable question.

Forecasts, not history. Highlight reports should state where the stage is heading against its tolerances, not only what was done since the last report.

Exceptions as a normal event. An exception report is not a confession. It is the system working: the person closest to the problem raises it early, with options, to the people who have the authority to decide.

When these three are in place, the colour on a status report stops being an opinion. Amber means a forecast is approaching a tolerance. Red means a forecast says a tolerance will be breached, and an exception report is already on its way.

Turning it into a governance control

In a regulated programme it helps to treat management by exception explicitly as a control, the way an auditor would look at it. That means four design choices.

1. Tolerances that mean something to the business. Time and cost tolerances are easy. The ones that matter most in regulated work are often risk and quality. For example: no go-live with open critical findings from security testing, or no more residual risk accepted on the board's behalf than an agreed level. Write them down at each stage boundary, and make the risk owner part of setting them.

2. Forecast-based highlight reports. Ask every highlight report one question per tolerance: on current evidence, will this stage finish within it? Yes, at risk, or no. Back each answer with one line of evidence. Activity lists go to an annex.

3. A protected escalation path. Agree up front that raising an exception early is the expected behaviour, and that the board's first question is "what do you need from us?", not "why did this happen?". Psychological safety is not a soft extra here. It is what makes the control work.

4. An audit trail of decisions. Every exception the board handles should end in a recorded decision: re-plan, accept the deviation with a named risk acceptance, change scope, or close the project. In a DORA or NIS2 context, that record is the evidence that oversight happened.

The change that made the difference was taking status out of opinion and putting it into data. We moved to resource planning with live data and a calendar view for every task, so each task had its own owner, dates and actual progress, visible to everyone. The PM no longer had to ask department heads whether they were on track; the plan showed task-by-task completion as it happened. That turned the highlight report from a list of activities into a forecast: a slipping task on the critical path showed up as a dated gap, not as a colour someone chose. It also took the politics out of escalation. Nobody had to "expose" a colleague; the data raised the exception, early enough to act on it. For the teams at the end of the chain, like mine in production, it meant planning around real arrival dates instead of discovering the squeeze two weeks before go-live.

When AI writes the highlight report

There is a new kind of watermelon on the way. AI tools can now draft highlight reports, summarise risk logs and produce polished dashboards in seconds. That is useful: less time on formatting, more on the work. But a fluent summary of activity is still a history, not a forecast, and a model trained to sound confident can make a red project read green very convincingly.

Management by exception gives us the guardrails. The tolerances stay human-owned and are set by the board. The forecast against each tolerance carries a named author, even if a tool prepared the first draft. And the project manager remains accountable for what the report says, which is exactly the question I asked members in the PRINCE2 forum this week: who signs off when the AI wrote the highlight report?

Used well, AI can strengthen the control rather than weaken it. It can scan plans, test results and supplier updates for early signals that a forecast is drifting, and flag them before anyone has to "feel" that something is wrong. The decision to raise an exception, and the board's response to it, still belong to people.

Where watermelons hide in service transition

The last place a watermelon ripens is the handover into live service. A project can be green on scope, time and cost and still hand operations a service it cannot support: monitoring not in place, knowledge transfer incomplete, no tested rollback.

This is where PRINCE2 and ITIL meet. If operational readiness is part of the project's quality tolerances from the first stage, with acceptance criteria agreed with the service owner, a readiness gap shows up as a forecast breach weeks before go-live, not as an incident the morning after. It also gives operations a legitimate, pre-agreed way to say "not ready", instead of being cast as the department that blocks delivery.

Five questions for your next board meeting

If you sit on a programme board, these questions will tell you quickly whether you are looking at a watermelon.

What are this stage's tolerances, and which one is closest to being breached?

Is this report a forecast or a history?

When was the last exception report raised, and how did we respond to it?

Which risk tolerances have we set, and who on this board owns them?

What would the service owner say about operational readiness today?

If the answer to the third question is "never", that is not a sign of a healthy programme. It usually means exceptions are being absorbed quietly somewhere below the board, which is exactly how watermelons grow.

Closing thought

Management by exception is one of PRINCE2's oldest principles, and in an era of AI-assisted reporting and ever-faster delivery it may be one of its most relevant. Dashboards can be generated in seconds. Honest forecasts against agreed limits, and a board that welcomes early bad news, still have to be designed by people.

Over to you: what is the most reliable early signal you have found that a green programme is really red, and how did you get it onto the board's agenda?

Where conversation, connection, and real-world practices come together.