Working software in months, not years
Why large modernization programs stall, and the operating model we use to turn them around: prove it in-house, buy what exists, and ship vertical slices that real users touch early.
On this page
Most large technology programs do not fail in a single moment. They fail slowly, through a series of reasonable decisions: a requirements phase that runs a little long, a custom build chosen because nothing on the market fits perfectly, a release plan that defers real users until "the platform is ready." Years later, the organization owns an expensive system that nobody trusts.
We have inherited programs in exactly that state, including a multi-year custom build where both sponsoring organizations had lost confidence and an acreage-reporting effort that had absorbed most of an agency's modernization capacity for eight years. The patterns behind the turnarounds were consistent.
1. Treat time as the scarcest resource
Budgets can be found. Lost years cannot. Every program we take on gets a hard question in the first week: what is the smallest thing real users can rely on within ninety days? If the answer is "nothing," the plan is wrong, not the timeline.
Setting a short horizon changes behavior. Teams stop designing for every edge case and start designing for the case that matters most. Vendors are asked to demonstrate working software rather than describe it.
2. Buy what exists, build what differentiates
Custom software is the right call far less often than it is chosen. When a failing custom loan system was redirected to a commercial platform on a 90-day vendor-identification cycle, a working system covering more than a million loans was deployed within a year.
We build in-house when requirements must be proven before anyone can buy them responsibly. A small internal team can prototype the hard part, settle the open questions, and hand a vendor a specification grounded in reality instead of assumptions.
3. Ship vertical slices
A vertical slice is one narrow workflow delivered end to end: intake, data, processing, reporting, and the people who use it. It is the opposite of building the database layer for a year before anyone sees a screen.
4. Put data at the center
Applications come and go. Data outlives all of them. We require new solutions to sit on a common data layer so that reporting, integrity analytics, and AI capabilities come naturally instead of through another integration project. When that foundation is in place, the program's own analysts can build what they need without waiting on a contractor.
5. Transfer the capability
A turnaround is not finished when the system launches. It is finished when the organization can run and extend it without us. That means documented patterns, staff who have built real things on the platform, and governance that rewards delivery instead of paperwork.
None of this is novel. It is simply rare, because large organizations are structured to reward the appearance of thoroughness over the evidence of progress. The fix is operational discipline: short horizons, honest vendor evaluation, and a relentless focus on what users can actually touch.