Why Software Can’t Fix What Process Hasn’t Defined Yet
Every year, growing companies spend significant money on software that doesn’t deliver what they expected. The platforms are capable. The intentions going in are genuine. The disappointment that follows is real. And in most cases, the explanation for what went wrong has nothing to do with the technology.
The pattern is consistent enough that it has a name inside organizations that implement these systems regularly. Technology-first thinking. The belief that buying the right software is the same as solving the operational problem the software was purchased to address. It isn’t. And the companies that discover this after go-live almost always wish they had understood it before.
Software is a system for operationalizing process. It captures process, enforces it, surfaces data about how it’s performing, and automates parts of it. What it cannot do is create the process. That work belongs to the organization. And when it doesn’t happen before the software is configured, the software reflects whatever exists in its place, which is usually a mix of habits, workarounds, and informal arrangements that developed because there wasn’t a defined process to follow.
The Problem With Technology-First Thinking
Technology-first thinking usually starts with a legitimate problem. The business is growing. Data is scattered. The team is working in spreadsheets. Processes that worked at twenty people are breaking down at fifty. Leadership recognizes that something needs to change and identifies a platform that appears to solve the problem.
The mistake isn’t recognizing the problem or choosing the platform. The mistake is assuming the platform will define the solution. A CRM doesn’t arrive with your sales process pre-loaded. A project management tool doesn’t come with your delivery methodology built in. An ERP doesn’t know how your operations should run. These platforms are capable of supporting all of those things, but only after the organization has defined what those things should look like.
When a company implements software before that definition work happens, the configuration reflects the current state of the business, including all the inconsistencies and informal workarounds that are part of the problem. The software doesn’t clean those up. It encodes them. And once they’re encoded in a system, they’re harder to see and harder to fix than they were before. Why You Can’t Buy Your Way to a Working CRM covers this specifically in the context of CRM implementations and why the purchase decision is the beginning of the work, not the end of it.
Process Doesn’t Have to Be Perfect, But It Has to Exist
One of the objections to process-first thinking is that the process is always evolving, so waiting until it’s fully defined before implementing software means waiting forever. That’s a reasonable concern with an unreasonable conclusion.
Process-first doesn’t mean perfect process. It means defined process. A process that’s documented, understood, and consistent enough to build from. It doesn’t have to anticipate every edge case or account for every exception. It has to answer the basic questions: how does work move through the organization, who is responsible at each stage, what information needs to be captured, and where do things currently break down?
Those answers give the implementation team something to build from. The process will continue to evolve after the system is built, and a well-configured system can evolve with it. What can’t be built on is ambiguity. When the process isn’t defined well enough to answer those questions, every configuration decision becomes a guess. Guesses produce systems that the team doesn’t recognize and can’t use effectively.
The discipline of defining the process before the build also has value independent of the software. It forces conversations that growing companies often avoid: about who owns what, about where the real bottlenecks are, about what the business should look like at the next stage of growth. Those conversations produce clarity that benefits the organization regardless of which platform gets implemented. Before You Go Live on Salesforce, Do These Three Things covers the process definition work as one of three foundational steps that determine whether a Salesforce implementation succeeds.
The Consultant’s Role Is to Help You See What You Can’t
One of the reasons companies skip process definition work is that it’s hard to do from inside the business. When you’ve been operating a certain way for years, the way things work can feel like the way things have to work. The workarounds feel necessary. The informal arrangements feel permanent. It takes outside perspective to recognize which parts of the current process are well-designed and which evolved by accident.
A good implementation partner doesn’t just configure software. They facilitate the process conversations that surface the decisions the organization needs to make. They bring questions that the business hasn’t asked itself. They recognize when a process that looks functional is creating downstream problems that the team has learned to live with. And they push back when the answer to a process question is some version of that’s just how we do it here.
At Fast Slow Motion, we describe this as consultation before configuration. We measure twice and cut once, and sometimes we measure three times. The time spent on process definition before the build is not time lost from the project. It’s time invested in a foundation that the rest of the implementation depends on. The builds that skip this phase produce systems that need to be rebuilt. The builds that don’t skip it produce systems that scale. Why Salesforce Succeeds in Some Companies and Stalls in Others covers the full conditions that separate implementations that deliver from those that don’t.
What Happens When You Get the Sequence Right
When process definition comes before configuration, a few things change. The build is faster because the decisions that configuration depends on have already been made. The system makes sense to the people using it because it reflects how they were told the work should move, not someone’s best guess about it. Adoption is easier because the team can see the logic behind every field and workflow. And the data that flows through the system is actually useful because it was designed to capture what matters.
The sequence also changes the relationship between the organization and the software. When the system is built on a defined process, changes to the process can be reflected in the system deliberately rather than discovered accidentally. The platform becomes a tool the business controls rather than a constraint the business works around.
This is what a well-run implementation feels like from the inside. The system is current. The team uses it because it makes their work easier. Leadership trusts the data. The platform evolves as the business evolves. None of that is complicated to describe. All of it depends on getting the sequence right from the start. How to Build a Salesforce MVP That Sets You Up to Scale covers how to build from a defined process in a way that creates a foundation the business can scale on.
The Expensive Lesson Most Companies Learn Too Late
The companies that learn this lesson after a failed implementation understand it viscerally. They spent the money. They went through the project. They launched the system. And they ended up with something that confirmed what they already knew: the problem wasn’t the software.
The recovery from that experience is possible. It requires going back to the process work that should have happened first, cleaning up the configuration that was built on incorrect assumptions, and relaunching with the right foundation. That’s a recoverable situation. It’s also an expensive and time-consuming one that was entirely avoidable.
The companies that understand process-first before they implement get a different result. Not because the software is different, but because the foundation it’s built on is. The platform is the same. The conditions are different. And in technology implementations, conditions are what determine outcomes. What to Do When Your CRM Isn’t Working is a useful reference for any company that recognizes itself in the expensive lesson described above.
Listen to the full podcast episode here.