Alan Rencher, serves as CTO of Henry Schein One, overseeing technology operations for one of the world's largest global dental PMS providersgetty​In 2004, I weighed 280 pounds. I had been a high school and college athlete. I had a sedentary job as a software engineer, a bad diet and a fairly complete set of excuses. I am not proud of how I got there. But I am genuinely grateful for what getting out of it taught me, not just about endurance training, but about the thing I have spent my career trying to get right: why enterprise software almost always fails.I have now completed 70-plus triathlons. I also have a long list of painful firsthand experiences with enterprise software that launched expensively and landed quietly in a drawer. Building it, selling it, buying it, implementing it. I have been on every side of that table.The failure modes are the same. And the reason is not what most people think.​It is not a discipline problem.The conventional story about triathlon training is discipline. You wake up early, you do the work, you push through.That story is mostly wrong, or at least incomplete. I ran three miles this morning at 7.5 miles an hour. At 50, that is genuinely hard on my body. Discipline did not get me to the treadmill at that pace. Understanding exactly what my body needed at this stage of training, and building a system around that specific reality, is what got me there. When the training plan does not match what the body actually needs in this moment, the body routes around it. It compensates. It finds shortcuts. It gets injured doing the wrong kind of work.Enterprise software fails for exactly the same reason. It's not because the people implementing it lack discipline or commitment; it's because the software does not actually solve the problem the user is experiencing at the moment they need to solve it.Peter Drucker is often attributed with saying, "Culture eats strategy for breakfast." In enterprise software, the translation is direct: If what you are asking people to adopt does not make their immediate work better, they go around it. Not because they are resistant to change, but because they are rational. People develop their own workflows, their own work-arounds and their own secret sauce. And then the expensive system sits largely unused while the organization pays for it anyway.I have watched this happen with ERP implementations, with clinical software in healthcare settings and with AI coding tools competing against the ones engineers already love. The pattern is identical. The body, whether human or organizational, routes around solutions that do not match its actual experience of the problem. ​The mismatch is almost always upstream.Here is what I have learned from both contexts: By the time the failure is visible, the real mistake is usually long past.In triathlon training, if you are injured in week eight, the cause is often a decision made in week two. Wrong volume. Wrong surface. Ignoring a signal the body was sending early. The problem compounds quietly until it cannot be ignored.Enterprise software projects fail the same way. Whether it's a visible failure, low adoption, grumbling users or a system that goes around instead of through, it's the outcome of an earlier mismatch. The software was selected without deeply understanding the actual workflow. The vendor solved the buyer's stated need, not the user's lived experience. The implementation skipped the part where you watch someone do the work before you redesign it.By the time adoption fails, everyone is debugging the wrong problem. The question becomes "how do we drive adoption?" when the real question is "did we actually build something that solves what this person experiences as a problem in the moment they experience it?"Those are very different questions.​What does good implementation actually look like?I have also been part of software implementations that worked. The pattern there is equally consistent. In training terms: The plans that worked were the ones built around what my body was actually doing, not what a generic 12-week program said it should be doing. Adjusting for recovery. Listening to signals. Changing the plan when the evidence said the plan was wrong. That is not indiscipline. That is accuracy.In software terms: The implementations that worked started with deep, uncomfortable honesty about what the user actually does and what actually makes their day harder. Not what they say in a requirements meeting. What they do at 2 p.m. on a Tuesday when the schedule is behind and the system is supposed to be helping but instead is adding steps.The difference between software that gets used and software that gets routed around is almost always that simple. Did you solve the real problem, or did you solve a version of it that was easier to build? Honesty is harder than discipline.Seventy triathlons did not teach me discipline. They taught me that the body gives you accurate data about whether your plan is working, and that ignoring that data is how you end up injured, overtrained and slower than when you started. Enterprise software gives you the same data. When people go around it, that is not a change management problem. It is the system telling you something accurate about the gap between what you built and what the work actually requires. The organizations that get this right, in training and in enterprise software, are the ones willing to keep asking whether they are solving the real problem, even when the answer is inconvenient.That is harder than discipline. It is also the only thing that actually works.​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?