Why the best technology implementations aren’t about predicting what happens next—they’re about following what actually does.
When I was a kid, I had one of those odd-shaped rubber balls. The kind that looks more or less like a ball until you drop it on concrete and it careens sideways, doubles back, and skips right past your outstretched hand. You couldn’t predict where it would go. But you could follow it—if you stayed with it.
I’ve been building and delivering Salesforce implementations for over a decade. And somewhere along the way I realised that technology projects behave exactly like that ball. Not the perfectly round, predictable kind. The odd-shaped one.
In his 2008 book The Drunkard’s Walk, physicist Leonard Mlodinow argues that “it is quintessentially human to stamp the results of largely arbitrary processes as, in retrospect, inevitable.” He was writing about randomness about how we look back at what happened and construct a coherent narrative, as if it couldn’t have gone any other way.
What struck me about that idea is how directly it maps to how we plan technology projects. We draw a straight line from discovery to go-live. We write a blueprint. We sign it off. And then we spend the next twelve weeks building toward that line, not toward the reality that’s already diverging from it.
The ball is bouncing. We’ve stopped watching it.
Mlodinow’s title comes from Brownian motion, the random, unpredictable movement of particles suspended in fluid. Scientists described it as a “drunkard’s walk”: the particle doesn’t go anywhere in particular; it just moves. Unpredictably. And yet you can understand it, if you observe it closely and often enough, rather than trying to predict its path in advance.
That’s the principle behind how we approach delivery at Arcturious. Don’t predict. Follow.
Here’s what I see happen, again and again, across technology implementations of every size. Teams look at the real-world use case exactly twice: once in discovery, and once in UAT.
In between eight, twelve, sometimes sixteen weeks of building nobody sits down with a real client scenario and actually runs the process end to end. They write user stories. They build to requirements. They run happy-path unit tests. And then, in UAT, a real user sits down for the first time since the discovery workshop and tries to do the actual job.
That’s when the ball goes sideways.
Not because anyone was careless. Because the blueprint was a mental model of reality, not reality itself. And mental models drift from reality the moment you stop testing them.
Researcher Bent Flyvbjerg has spent thirty years studying why big projects fail. His database of more than 16,000 projects across 136 countries arrives at a number that should stop everyone cold: just 0.5% of major projects are delivered on time, on budget, and deliver what they promised (How Big Things Get Done, 2023). Not 5%. Not 50%. Half a percent.
That’s not a story about incompetent teams. It’s a story about what happens when you build for the blueprint rather than follow the ball.
Let me give you a concrete example—anonymised, but entirely real.
We were building a field service solution that covered two types of work: fixed-price jobs and time-and-materials jobs. It also needed to handle both ad hoc work orders and recurring maintenance plans. Four scenarios. Each one was reasoned through carefully in discovery. Each one was built and tested in isolation.
The problem? Nobody had followed the ball all the way through end to end.
When we did, we found something the blueprint hadn’t made visible: the work on the ground is the same regardless of whether it’s fixed price or T&M, ad hoc or maintenance plan. A technician arrives. They do the job. They create a work order. What changes isn’t the work—it’s how it gets priced and invoiced at the other end.
By building in isolation, we’d created work orders that looked completely different depending on how they were created. But downstream—in invoicing, in the accounting system, in how the client sees their bill—they needed to produce a consistent output.
Following the ball also surfaced a decision nobody had explicitly made: what happens when a job has two different labour types? On the surface, a reasonable question. Follow it far enough and you hit a fork: either redesign the work order structure, or define a business process to handle the exception. That’s not a technical decision. It’s a delivery decision. And it only surfaces when someone is watching the whole ball, not just their corner of the process.
The resolution was cleaner for having been found early. A consistent work order output regardless of origin, with the pricing and invoicing layer handling the variance. Something a real user can actually operate. We found it not by re-reading the blueprint, but by watching where the ball actually went.
I want to be honest about something. The reason teams don’t follow the ball isn’t laziness or lack of skill. It’s something more structural and more human than that.
Most people working on a complex implementation are focused, quite rightly, on their own piece of the puzzle. The developer building the work order logic trusts that someone else is handling the invoice flow. The BA writing the fixed-price user story trusts that the T&M scenario has been separately accounted for. Everyone is doing their job. Nobody is watching how the pieces interact.
Kahneman and Tversky named this dynamic in their foundational research on the planning fallacy: we default to the inside view—the specific, vivid, compelling story of how our piece of the plan will unfold—and we underweight the outside view, which asks how projects like this one actually go when you look at the full picture. In one well-known study, people asked to estimate how long a task would take predicted around 34 days; the actual average was over 55. The gap persisted even when people were explicitly prompted to recall past experience.
Think about making a cup of tea. You could turn the kettle on, wait for it to boil, then go find a cup, then look for a teabag, then get the milk. Or you could turn the kettle on and, while it’s heating, grab the cup, the teabag, and the milk, and be back by the time it boils. The outcome is the same cup of tea. The difference is holding the whole process in your mind while you’re in it, rather than resolving each step before you think about the next one.
That’s what following the ball looks like in practice. Not predicting every bounce. Holding enough of the whole process in view that when the ball does go sideways, you see it immediately.
None of this is resolved by better documentation or more detailed requirements. The fix is collaborative, and it starts earlier than most teams think.
Following the ball begins at the proposal stage. Not with a features list—with a shared vision and clear success measures. We ask: what does done look like? Not for the system, but for the people who’ll use it and the business it’s meant to serve.
In discovery, we create safe spaces to challenge and to learn. We spread the net wide, surface more than we can deliver in the current engagement, and build a joint roadmap so nothing is lost, it’s just sequenced. We’re transparent that not everything we discover will be in scope right now. That honesty builds more trust than a promise of everything.
In delivery, we build in-sprint testing against real client scenarios. Not just happy paths. We put the ball in front of a real user with real data as early and as often as we can. When it bounces somewhere unexpected, we want to find that in week three, not in UAT.
Research from a 2024 study of 600 software engineers found that projects with clear requirements before development started were 97% more likely to succeed than those without. That’s not a documentation finding. That’s a follow-the-ball finding.
There’s a new dimension to all of this that I can’t ignore and I’ll be honest, I’m very much inside it.
AI coding tools have fundamentally changed who can build software. The owner-operator who always knew exactly what they needed an RCTI tool in Google Sheets with a decent web interface, a workflow that their system vendor would never prioritise can now build it themselves. No agency. No budget cycle. Just a clear vision and a willingness to follow the process through.
That’s genuinely remarkable. For the first time, founders with real operational knowledge can act on that knowledge directly. Imperfect output, maybe. But solving problems faster than it causes them. The people who understand the problem most deeply now have the tools to address it.
I’m guilty of exactly this. I’ve let AI loose fully on projects from my smart home automation to building Nova and ADC, the AI-enhanced delivery systems at the core of how Arcturious operates. I have a background in this stuff, which means I’m following the ball while I manufacture it. But I’m under no illusion that everyone who now has access to these tools will do the same.
Because the risk is real. When the barrier to shipping code drops to near zero, the volume of code shipped by people without the judgment to know what they’re shipping increases dramatically. AI slop plausible-looking solutions to problems that weren’t fully understood, built by developers who skipped the end-to-end test because the AI said it looked right, is already a pattern.
The bouncing ball principle doesn’t change because you manufactured the ball yourself. If anything, it becomes more important. When you’re moving fast, with powerful tools, and high confidence, the temptation to stop watching the ball is at its highest. That’s exactly when you need to follow it most carefully.
The question isn’t whether AI gives more people the ability to build. It does, and that’s a good thing.
The question is whether the people building are willing to follow what they’ve made.
On the delivery side, I’m also watching something genuinely new unfold.
The limiting factor on shared accountability has always been documentation overhead. A small consulting team can only capture so many decisions, so many dependencies, so many exceptions before the cognitive load becomes unsustainable. Things get lost. Assumptions drift. The ball bounces somewhere and nobody has a record of what we thought was going to happen.
Our AI-enhanced delivery model is changing this. AI now automatically catalogues decisions, dependencies, and exceptions as they happen from discovery through to managed services. The traceability exists in a way it simply didn’t before for a team of our size. And because the documentation catches up with the decisions in real time, the team has more capacity to actually follow the ball rather than write about it.
It’s not that AI removes the uncertainty. The ball still bounces unexpectedly, that’s the nature of complex implementation work. But when it does, we now have a complete record of every assumption we’d made about where it was going. That changes everything about how quickly you can respond, and how clearly you can communicate with your client about what changed and why.
You will never predict every bounce. That’s not the goal.
The goal is to follow the ball faithfully—early, often, end-to-end, and together with your client. To hold enough of the whole process in view that when the unpredictable happens, you see it before it becomes a UAT crisis or a post-go-live fire.
The best implementations I’ve been part of weren’t the ones with the most detailed blueprint. They were the ones where the team and the client were watching the ball together the whole time—dropping it, throwing it, kicking it, bouncing it off a wall, testing every assumption at every opportunity.
Whether you’re delivering a complex enterprise transformation, or you’re a founder using AI tools to build something that solves a real problem in your business—the principle is the same.
When you can make the ball and bounce it, following it faithfully is more important than ever.
Michael Diamond is Director and Lead Solution Architect at Arcturious.
An AI-first Salesforce consultancy based in Australia. Arcturious helps organisations across renewable energy, construction, manufacturing, and government design and build Salesforce solutions that actually get used.
Leonard Mlodinow, The Drunkard’s Walk: How Randomness Rules Our Lives, Pantheon Books, 2008
Bent Flyvbjerg and Dan Gardner, How Big Things Get Done, Macmillan, 2023
Daniel Kahneman and Amos Tversky, “Intuitive Prediction: Biases and Corrective Procedures,” 1979; Roger Buehler, Dale Griffin, Michael Ross, “Exploring the Planning Fallacy,” Journal of Personality and Social Psychology, 1994
J.L. Partners / Junade Ali, Impact Engineering research, June 2024 (600 software engineers, UK and USA)
Don’t experiment with AI in isolation.
If your last implementation didn’t go the way the blueprint said it would, we’d like to talk about why.