As an SAP programme moves into delivery and testing, the risk profile changes. The system integrator’s focus narrows entirely to protecting the go-live date.
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 critical questions — focused entirely on delivery integrity and go-live readiness in the Delivery Zone.
Question 1 — Why are requirements being deferred?
“We are adopting an agile MVP approach.”
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.
Question 2 — Are we truly ready for UAT?
“Yes, the system passed all functional tests.”
The system works in a vacuum, but end-to-end integration with legacy systems is failing. SIs often push programmes into User Acceptance Testing before the architecture is stable, forcing the business to test a broken system. UAT should be a final validation, not an extended debugging phase.
Question 3 — Can we go live safely?
“Yes, we will resolve minor defects during hypercare.”
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.
Question 4 — Who owns post-go-live support?
“Our AMS team will provide seamless support.”
You are locked into a high-margin Application Management Services 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.
If the answers sound like deflections
If your SI’s answers to these questions sound like deflections, you do not have a governance model. You have a reporting exercise.
The illusion of green is the most expensive narrative in enterprise transformation. It is also the most preventable.
