Every firm publishes its wins. We publish a success rate, 96.5 percent across hundreds of projects since 2005, and we are proud of it, because the industry number is that roughly 70 percent of software and data projects fail or run over. But a success rate implies a failure rate, and prospective clients ask about it on almost every first call. They should. How a firm talks about its failures tells you more than its case studies.
So here is the honest version. Not the stories, because those belong to the clients involved, but the patterns, which are what matter, and what we built in response.
What the failures had in common
Across two decades, the projects that did not succeed had almost nothing to do with technology. Not one of them failed because the code could not be written. They failed on communication, and in three specific ways.
Two views of the scope. The client pictured one thing and we were building another, and the gap did not surface until something was demonstrated. Sometimes the proposal was too high-level. Sometimes it was detailed and both sides read it differently. Either way, the money spent between the misunderstanding and its discovery was gone.
A gap between what was built and what was needed. The system did what was asked and still did not fit the business, because the people who actually did the work were never in the room. The spec came from a manager. The job belonged to a dispatcher.
Problems that stayed quiet too long. A schedule slipping a little each week, a risk everyone assumed someone else was watching, a client contact who was too busy to review. Nothing dramatic, until the accumulation was.
There is a fourth pattern that is less about failure than about regret: projects that succeeded technically and then withered because nobody on the client side owned the rollout. The software worked. The business did not change around it.
What changed
Most of how we work today is a direct response to those patterns. Three things in particular.
A planning step before every new build. We no longer start a new project from a proposal. We start with a Validation, Design & Planning engagement: a fixed-fee, few-week effort that puts the sponsor, the champion, and the people who know the work in one room, produces click-through mockups of the key screens, writes down the functional and non-functional requirements, and ends with a roadmap and the investment on it. Two views of the scope cannot survive that process. The mockups make the misunderstanding visible while it costs a conversation instead of a quarter. For an existing system, the equivalent is a System Evaluation. We will not skip either, even for a client in a hurry, because the hurry is usually why it matters.
Estimation that puts the risk first. We used to estimate by adding up features. Now the first question is where the uncertainty lives: the integration nobody has done, the data nobody has looked at, the rule nobody can state. Those get investigated first, sized honestly, and surfaced in the plan as the things that could move the number. Fixed budget with controlled scope, our default contract, exists so that when the unknown turns out to be bigger than hoped, the budget holds and the scope flexes, in the open, instead of a surprise invoice or a quiet cut in quality.
A weekly rhythm that makes problems cheap. Every project runs on a weekly priority meeting where working software is shown, the next week is chosen, and anything that is slipping is said out loud. A shared backlog both sides can see. A delivery lead whose job is to make sure nothing falls between the chairs. A problem that surfaces in week three costs a week to fix. The same problem in month four can cost the project. The rhythm is boring on purpose.
And for the fourth pattern: we now ask, before we start, who on the client side will own the rollout, and we will not start without a champion. We wrote about that separately, because it is the single strongest predictor we have.
What we still cannot promise
No process eliminates risk, and we do not promise outcomes. What we can say is that the failure modes above are now visible early enough to act on, that our record since making these changes reflects it, and that when a project is going sideways you will hear it from us first, in the weekly meeting, with options. If you want to talk through the hard ones, ask on the first call. We would rather you hear it from us than wonder.