When programme reporting stays green while operational pressure has already turned red underneath.
As an SAP programme moves into delivery and testing, the risk profile changes. The SI’s focus narrows entirely to protecting the go-live date — and the way risk is reported changes with it.
This is when the watermelon metric appears: a status report that is green on the outside, but red on the inside.
When a programme is governed by the delivery team, friction is hidden. Requirements are deferred. Integration failures are reclassified as “post-go-live enhancements.” The board is presented with a narrative of success right up until the moment the system collapses in production.
To prevent this, the board must ask four questions — focusing entirely on delivery integrity and go-live readiness.
The SI is moving difficult scope into a post-go-live “Phase 2” that you will pay extra for. What the SI calls a Minimum Viable Product is often just failed scope in disguise. If the business cannot operate on the MVP without manual workarounds, it is not viable. It is simply incomplete.
The system works in a vacuum, but end-to-end integration with legacy systems is failing. SIs often push programmes into User Acceptance Testing (UAT) before the architecture is stable, forcing the business to test a broken system. UAT should be a final validation, not an extended debugging phase.
Going live with known defects is how you end up in a $172M shareholder lawsuit. Hypercare is designed for user adoption and minor stabilisation, not for finishing the build. If the defect backlog is growing as you approach go-live, the date must move. The SI will push to launch to trigger their milestone payment; independent governance will stop them.
You are locked into a high-margin Application Management Services (AMS) contract because nobody else understands the custom code they built. The SI has created a dependency trap. Independent governance ensures the architecture is standard enough to be supported by the market, not just the firm that built it.