The Economics of 90-Day Modernization Blocks

Over 30+ years architecting platform conversions and modernization programs — including building the 1,200-task Migration Playbook we use on every Convergent engagement — I've watched the same financial pattern play out repeatedly. A retirement firm commits to a multi-year modernization. The first year is planning. The second year is foundation work. The third year is supposed to be delivery, and that's where most of these programs quietly run aground.

The data on this isn't subtle. McKinsey's research on financial services modernization puts the failure rate at 70%+. The average gap between expected and achieved synergies on these programs is roughly 20%, and it can take 3-5 years to close even that gap. Big-bang modernization isn't a productivity strategy in this industry. It's a risk strategy that often produces neither modernization nor productivity.

There's a working alternative. We've delivered it across enough client engagements to know the economics hold up.

The 90-day block

The structure: every modernization initiative is decomposed into 90-day delivery blocks, each one targeting a measurable outcome that's valuable on its own. No block depends on a future block to produce its value. If the program is canceled after block three, the first three blocks still delivered something.

The discipline this requires up front is significant. The team has to identify outcomes that are valuable in isolation, that don't require a heroic foundation layer to ship, and that the operations team can absorb without a 6-month change-management program. That's harder than it sounds. It's also where the leverage is.

The math that makes this work

Compared to a 36-month big-bang program, a sequence of 12 ninety-day blocks looks similar on paper. The actual financial difference is enormous, and it comes from three sources.

Time-to-value compounds. A 36-month program produces zero value for 36 months. A 90-day block program produces measurable value every quarter. By month 12, the block program has delivered value four times. By month 36, it's compounded against itself for a year. On most operational improvement programs we run, the cumulative value of early blocks exceeds the projected value of the entire big-bang program by month 24.

Risk doesn't accumulate. In a 36-month program, every risk that materializes after month 12 puts months of work in jeopardy. In a 90-day block program, the risk window is bounded. A failed block costs one quarter. The next block resets. We've never had a client lose more than 90 days of work on a block-structured engagement. We've had multiple clients lose 18+ months on conventionally structured ones.

Change management is incremental. Operations teams can absorb a steady stream of small changes. They cannot absorb a single massive change. Big-bang modernization typically requires a transition period of 3-6 months where the operations team is running both the old and new systems in parallel. That's a real cost — often 20-40% of the program budget — that block-structured programs avoid almost entirely.

What goes in a 90-day block

The discipline of choosing what fits in 90 days is most of the work. The blocks that consistently succeed share a profile:

• One measurable operational outcome. Specific. Quantifiable. Auditable. "Reduce contribution file processing time from 4 hours to 30 minutes" is a block outcome. "Improve payroll automation" is not.
• No dependencies on future blocks. Each block lives or dies on its own. Future blocks build on it but aren't blocked by its absence.
• A defined production state. The block ends with something in production, used by real users, with measured results. Not a prototype. Not a sandbox. Production.
• A team that owns the entire block. Cross-functional — engineering, operations, compliance, change management — sized to ship in 90 days. No matrix overhead.
• A predefined success criterion. "We'll know it worked if X." Written down. Agreed before the block starts.

The blocks that fail share a different profile: foundation work that doesn't ship on its own, dependencies on parallel work streams, vague success criteria, and teams that are matrixed into other work.

What goes in a multi-block program

Some modernization outcomes genuinely require multiple blocks. The discipline is sequencing them so that each one is valuable independently while the overall arc moves toward the larger goal. A real example from a recent engagement:

• Block 1: Stand up an event-driven data pipeline for the highest-volume sponsor data feeds. Shipped value: reduced upstream latency on the four feeds that account for 60% of volume.
• Block 2: Replace the manual reconciliation workflow on those same feeds with an automated process built on the new pipeline. Shipped value: 3 FTE reallocated; reconciliation cycle time dropped 80%.
• Block 3: Extend the pipeline to the next tier of sponsor feeds. Shipped value: 30% additional volume now flowing through the automated path.
• Block 4: Build a sponsor-facing real-time submission API on the same infrastructure. Shipped value: sponsors can submit in real time; eliminates 200+ tickets per month.

By block 4, the cumulative value is significant. After block 1, the value is already meaningful. If the program had been canceled after block 2, the firm would still have a working automated pipeline for 60% of its volume. That's the optionality 90-day blocks produce that multi-year programs don't.

When this doesn't work

There are modernization outcomes that genuinely cannot be sliced into 90-day blocks. A full platform replacement is the obvious one — you can't replace a recordkeeping core in 90 days, period. Multi-year migrations have to be structured differently.

But the question worth asking is whether the modernization actually requires a full replacement, or whether the desired outcomes can be reached by modernizing around a preserved core. In our experience, 70-80% of programs framed as "we need to replace the platform" can be re-scoped into a sequence of 90-day blocks that produce the actual desired outcomes without the replacement. The other 20-30% are real platform replacements and need to be funded and structured accordingly — but even those are often staged as a sequence of bounded migrations rather than a single big-bang event.

What I tell CFOs and CIOs in the funding conversation

If your team is asking for a 24-36 month modernization program with a $10M+ budget, the question worth answering before the funding decision is this: what's the value delivered in the first 12 months? If the answer is "nothing — it's all foundation work," the program is structured wrong. Restructure it. The financial argument for blocks isn't ideological. It's that they produce measurable value at every checkpoint, and the alternative produces a binary success or failure event 24-36 months from now that's much more likely to land on the failure side.

The block-structured path is harder to plan. It's also the one that consistently ships.