We get this call more often than you’d think.
A non-technical executive is partway through a software project that the vendor told them would take six months. They’re now fifteen months in. They can’t tell if they’re being told the truth because they don’t have the technical depth to evaluate what they’re hearing. The project was supposed to be shipping. It isn’t. They’re starting to wonder whether it ever will.
That was the situation when the president of Industrial Game & Design was referred to Sirrus7. The client had partnered with the Oregon Manufacturing Extension Partnership to build Ready or Not, a business simulation platform that teaches entrepreneurship skills to high school and college students. OMEP had already pre-sold licenses to schools around the country. The funding was in place. The audience was waiting. The project just wasn’t being delivered.
The original ask to us was modest: come in, look at what the current vendor is doing, and tell us whether to trust them.
The ask we usually hear, and the answer we usually give
That’s a reasonable request from someone in that position. When a project has gone that far off the rails, the temptation is to find an outside expert to evaluate the situation and then hope the existing vendor can act on the remediation. It feels less disruptive. It preserves the relationship. It avoids the political cost of starting over.
Here’s what we’ve learned watching this pattern repeat. The vendor that got a project to month fifteen on a six-month contract is rarely the vendor that gets it to production in month eighteen. Not because they’re bad people. Usually because the project has accumulated technical debt, team dysfunction, and trust deficits that no amount of outside diagnosis can unwind while the same team is still executing.
We recommended taking the whole thing over and rebuilding it from scratch. That’s a bigger ask, a bigger commitment, and a scarier decision. It’s also the move that usually actually works.
What we took over, and what we built
Ready or Not isn’t a simple piece of software. It’s a coordinated multi-screen experience. A teacher’s dashboard has to stay synchronized with a classroom presentation display while dozens of students make real-time decisions on their own mobile devices. The game logic involves investment tracking, KPI calculations, dynamic scenarios, and video content that has to play back in sync across multiple browser contexts.
The previous vendor had specifically been unable to solve the video synchronization problem. That was one of the things keeping them stuck.
We delivered the full rebuild in eight weeks, with a two-developer team using a carefully designed AI-assisted workflow. A traditional estimate for this work would have been three to four frontend engineers over six to twelve months. We compressed the timeline by more than 80 percent and solved the blocker the previous team couldn’t get past.
What we want to talk about in this piece is the pattern.
What it turned into
The reason we can write openly about this project is that the client gave us their blessing to share it, and the outcomes have since been validated by third parties in ways we couldn’t have orchestrated.
- NIST Recognition — Featured in an official National Institute of Standards and Technology blog post on workforce development innovation.
- Trade Press Coverage — Covered by Gear Technology as one of the most exciting new services from the MEP National Network.
- National Distribution — Adopted by the MEP National Network, which serves all 50 states and Puerto Rico, as a recommended service for manufacturers.
- Live Platform — Deployed at Multnomah County Public Schools with active expansion into Washington, California, and Nevada.
- Repeat Engagement — The client commissioned a sequel, Ron2, which we just finished delivering.
- Student Impact — Students from high schools and colleges are stepping into executive roles during live classroom simulations.
The client said it better than we can:
“Previous dev shop had it doomed for failure after a year and a half of work. Sirrus7 stepped in and literally saved the day. Amazing work in a ridiculously short timeframe at a very reasonable price. Now, instead of a failed project, our Ready or Not business simulation game is helping teachers engage and educate students around the country.”
What we’ve learned from doing this more than once
This project wasn’t the first time we’ve been called in on a stalled software effort, and it won’t be the last. A few patterns we see repeatedly, offered in the spirit of what we wish more executives knew before they called us.
1. The diagnostic request usually isn’t what’s actually needed.
When a project is badly off track, the question “is my vendor telling me the truth” almost always masks a deeper question: “can this ever ship?” The second question is the one worth answering. Diagnosing without the authority to act on the diagnosis rarely helps.
2. Technical debt compounds faster than political debt.
Executives often hesitate to switch vendors because they fear the political cost. Our experience is that the technical and financial cost of continuing on a broken project almost always exceeds the political cost of stopping it. The longer you wait, the worse the math gets.
3. Non-technical buyers are in the hardest position.
The client was not a technologist and was honest about not being able to evaluate what they were hearing from the previous vendor. That’s not a failure — it’s the situation most software buyers are in. The vendor relationship should not require the buyer to be technical. When it does, something is broken.
4. AI-accelerated delivery changes what’s possible on a recovery.
The reason we could credibly offer a rebuild instead of a patch is that our delivery timelines now look fundamentally different from what a traditional team would quote. This isn’t about cutting corners. It’s about solving the economics of starting over, which used to be prohibitive and increasingly isn’t.
5. Outcomes validate the approach, not the timeline.
Eight weeks is a memorable number. But the reason to take this story seriously isn’t the speed. It’s that the platform shipped, the students are playing it, OMEP is selling it across the country, NIST has featured it, and the client came back for a second project. Those are outcomes that take years to accumulate. They happened because we finished the work.
Why we’re telling this story now
Sirrus7 does recovery work. When transformation programs stall, when timelines slip, when senior leaders are starting to wonder whether the thing they bought will ever ship, they bring us in. This situation was one example. We have more.
For a long time we described ourselves more broadly than that. We’re getting sharper about it because the pattern is real, it’s what we do well, and it’s the work that actually matters to the people who need us.
If you’re in the middle of a project that’s starting to feel like this — whether or not you’re sure yet — we’d love to talk. The context window is always open.