Meridian Insurance: building a claims portal against rules that don't exist yet

• The assumption behind 'wait and build once' is that requirements can be known and will stay still. Here they demonstrably cannot: the rules arrive in three tranches, so part of the specification is unknowable at the start no matter how long is spent writing it. A specification signed in month 2 would be signed against rules that change in month 4 - that is false assurance, not risk reduction.
• A single-pass lifecycle puts all the learning at the end, when it is most expensive to act on. The 40% of unused features in the previous attempt is the classic symptom: an internally consistent specification that was never validated against real use.
• Iterative and incremental delivery converts the unknown into a sequence of small, cheap experiments. Each increment is a working slice that real claims handlers can react to, so feedback arrives in weeks rather than after 14 months. Inspection is of something real, not of a document.
• It de-risks the hard date. A usable thin slice exists early and value accrues before the end, so a slip degrades the tail of the scope rather than delivering nothing.
• Reassure the sponsor this is not 'no planning'. Budget, date and product vision stay fixed; detailed planning is done where certainty exists - near term in detail, long term coarsely - and re-planned at each stage boundary.

Separate the two claims: 'sign off everything' and 'avoid building twice' are not the same requirement. Treat the second as the real objective and negotiate the first.

Fix

• The known statutory data fields and audit obligations - treated as must-haves with explicit acceptance criteria.
• Date, budget and the safety/security quality criteria, with tolerances set by the board.
• A single agreed baseline of what is fixed, so nobody can relitigate it later.

Flex

• Order and completeness of everything not mandated: screens, workflow refinements, management reports. Use MoSCoW with the business so the flex is visible and pre-agreed rather than discovered as a failure in month 8.

Answering 'build twice'

• Isolate the regulatory rules behind a boundary you control - configurable validation and a versioned rule set - so tranche 2 changes configuration, not core code.
• Ask legal to approve behaviour, interfaces and acceptance criteria per increment instead of a monolithic UI specification.
• Show them the definition of done and the audit trail from increment 1; their real fear is loss of control, not loss of documents.
• State the cost of the alternative plainly: a complete sign-off buys a document that the regulator will invalidate twice.

• Scope release 1 to what is knowable and valuable now: tranche 1 rules plus the core intake volume that the spreadsheet workaround exists for. That removes the workaround early and delivers the highest-value, lowest-uncertainty slice.
• Design explicitly for the unknowns. Configurable validation, a versioned rule set, and a named backlog item for each pending rule so nobody can pretend it is out of scope.
• Plan by release and stage, not by feature list. Release 1 around month 4, with a tested route to switch a rule on the day the regulator publishes it.
• Use the stage boundary as the re-baselining point for the release plan against what has actually been published, rather than pretending month 1's plan survives contact with month 5.
• Keep each increment's must-have set small enough to finish. Anything unfinished returns to the backlog instead of being reported as 'nearly done' - that is what protects the fixed date from silent erosion.