How to Run a CDR Programme Reset in 10 Days | Cavehill Consulting

How to Run a CDR Programme Reset in 10 Days

Most CDR programmes that are running amber are not in the wrong direction. They are missing one or two architectural decisions that have not been made, or have been made incorrectly, and those gaps are creating downstream problems that accumulate as the programme progresses.

A full programme restart is rarely the right response. A structured diagnostic — 10 days, fixed deliverables, a clear account of what is wrong and in what order to address it — usually is.

This is what that diagnostic looks like and what it produces.

Why programmes run amber on CDR

The most common causes of a CDR programme running amber are not technical failures. They are governance gaps.

The first is the capture architecture decision not being made. The programme has proceeded on an implicit assumption — usually that CDR fields will be extracted from existing documents at bind — without explicitly deciding whether this satisfies the capture-at-source requirement. It does not. The gap only becomes visible when the extracted data requires manual validation at a rate that was not anticipated in the operating model.

The second is the workflow mapping not being completed. The CDR data model has been configured against a generic ACORD template rather than the firm's specific placement workflow. The fields are populated, but they do not reflect how the risk is actually negotiated and bound. This produces CDR outputs that are technically compliant and operationally incorrect — because the data values are derived from documents rather than from the workflow decisions that generated them.

The third is no independent architectural authority. The implementation team — internal or GSI — has been making design decisions without a function that holds the architecture and reviews those decisions against it. The result is an implementation that reflects what was easiest to build rather than what the architecture requires.

Any one of these gaps is recoverable. All three together produce a programme that is delivering output but not solving the problem.

What a 10-day diagnostic produces

A structured diagnostic involves a focused session of two to three hours with the right principals — the programme lead, the technical architect, and ideally an underwriting representative. The session is a diagnostic conversation, not a presentation. The questions asked in that session, and the answers given, produce the structural reading.

The diagnostic produces three deliverables.

A structural assessment: where the programme currently sits against the capture-at-source requirement, what is working, and what the firm is at risk of locking in through the decisions being made now.

A decision register: the specific architectural choices that are currently open — or have been made incorrectly — and that will determine whether the programme delivers a genuine capture-at-source architecture or a compliant extraction layer.

A sequenced action plan: the precise order in which interventions must happen, starting with the one that unblocks everything else. In most programmes, one decision — usually the capture architecture decision — is the constraint that is preventing three or four downstream decisions from being made correctly. Identifying that constraint and resolving it first is the fastest path to recovery.

The diagnostic is a paid engagement at day rate. It is also proof of capability: by the end of the first session, the programme team should have a clearer structural reading of the problem than they had before the conversation started. If a larger programme follows, it is scoped from that foundation. If it does not, the diagnostic has still produced a clear account of what must change and in what order.

The right time for a diagnostic

The optimal time is before the programme architecture is set — when the capture decisions are still open. The second-best time is at the first amber signal: timeline slippage, budget reforecast, or the steering committee raising questions about whether the current architecture will produce the right outcome.

The worst time is after the system is live and the adoption or data quality problems are visible. At that point, the architectural decisions are embedded in production and the remediation is a redesign project rather than a governance intervention.

If a CDR programme is currently running and there are open questions about whether the architecture will deliver capture-at-source, a 10-day diagnostic is the fastest way to get a clear answer.

Contact Grant.Bodie@CavehillConsulting.com or visit our Consulting Partners SITP - https://sitp.london/partner/cavehill