RaeVyn Consulting | The Operating Gap — Paid tier | Aug 2026
In this issue:
The Problem Breakdown — Broken
What You Need to Learn — Discipline
New Narrative — Revolution = Time
Intro
Revolution feels like Hollywood. Incrementalism feels like RadioShack. Getting there takes months, and three departments looking at the same problem from different angles. Nobody wants to fold their perspective into someone else’s plan — especially when there’s redundant work and lost effort.
I. The Breakdown
Eighteen months in, the market shifts, the team reorganizes, and the architecture no longer has the flexibility to fail, learn, and adjust. On average, 45% of integrations run over budget and underdeliver.1 Revolution isn’t the safe bet. It just looks that way.
The funding for large infrastructure rebuilds would suggest the only thing missing is time. A rebuild can hit every milestone and still arrive with the same problem. You need new structured foundations and time.
II. What we are Learning
Migration: Choose a point where the data is mature enough to withstand a hard deviation. This deviation becomes the foundation needed to build alongside an aging system, which is quickly costing more to maintain than to rebuild.
Rapid testing: Prototyping is what’s scarce here, and most teams haven’t updated their math to reflect that. Teams spent months making a prototype. That’s not true anymore. You can stand up a rough version in days, put it in front of customers who actually use it, and find out you’re solving the wrong problem before spending the entire budget for the year.
Time: The new way forward looks a lot like the old way — just faster. Once you actually know what you’re building, you no longer need to ship it immediately. You build in phases and ship over time. Test often to ensure you’re on the right path. Build only when validated.
“An MVP is NOT version 1.0 of your product. Instead, think of MVP as the smallest thing you can make to learn if your hypothesis is correct.”
— Josh Seiden, Outcomes Over Output
III. Revolution = Time
Small projects succeed at roughly 10x the rate of the largest ones — 61% against 6%.2 A project is considered successful only if it is completed on time and on budget, meets the promised features, and results in satisfied customers. The bigger the build, the harder it is to hit all four at once.
Starting with the first point: time is always a factor, but a project’s duration shouldn’t be measured by sprints completed; instead, it should be assessed based on phases rolled out with minimal issues.
— RaeVyn
Selling the revolution is the easy part — the real investment is the time it takes to get there. I’ll be discussing this on Substack Live on August 13th, 5:00–5:30 PM CST. If you want to bring your migration questions, let’s think them through.
Standish Group, CHAOS Report — small projects succeed at roughly 61%, the largest at roughly 6%, using the “on time, on budget, features delivered, user satisfaction met” success definition. “Delivering Large-Scale IT Projects on Time, on Budget, and on Value” — Michael Bloch, Sven Blumberg & Jürgen Laartz, McKinsey. October 2012. Large projects run 45% over budget on average and deliver 56% less value than predicted; 17% become severe enough to threaten the organization.
“Delivering Large-Scale IT Projects on Time, on Budget, and on Value” — Michael Bloch, Sven Blumberg & Jürgen Laartz, McKinsey. October 2012. Large projects run 45% over budget on average and deliver 56% less value than predicted; 17% become severe enough to threaten the organization.
Standish Group, CHAOS Report — small projects succeed at roughly 61%, the largest at roughly 6%, using the “on time, on budget, features delivered, user satisfaction met” success definition.