How to Tell the Difference Between a Process Problem and a Software Problem
The most expensive mistake in business technology is fixing the wrong one
By Steele Consulting
Every few months, a leadership team decides that something in the business isn’t working, and someone in the room says the words: “we need better software.”
Sometimes they’re right. Often they’re not. And the cost of being wrong runs in both directions.
If the problem is really a process problem and you throw software at it, you’ll spend six months and a lot of money automating a broken workflow — and the broken workflow will now run faster, cost more to unwind, and be harder to change. If the problem is really a software problem and you throw process reviews at it, you’ll spend the same six months polishing habits that are being systematically undone by a tool your team is fighting with every day.
Both mistakes are common. Both are expensive. And they look nearly identical at the outset.
In our 24 years at Steele Consulting building custom software, one of the most common early conversations we have with prospects is a version of “before we start scoping software, let’s make sure it’s actually a software problem.” A meaningful percentage of the time it isn’t, and we say so. Because the honest answer to “what would fix this?” is often “not us.”
This post is about how to run that diagnostic yourself.
Why the diagnosis is hard
The symptoms of a process problem and a software problem look nearly identical from the outside. Both look like: things take too long, the team is frustrated, mistakes keep happening, reports don’t match, work bunches up in the wrong places, customer complaints trend the same direction week after week.
You can’t tell from the symptoms. You have to test the underlying cause. And there are two diagnostic tests that, together, land you in the right diagnosis almost every time.
Diagnostic 1: The Substitution Test
Ask yourself, honestly:
“If we replaced our current software with a perfect version tomorrow — same team, same processes, better tools — would the problem go away?”
- If yes → it’s a software problem.
- If no → it’s not a software problem, or not only a software problem.
- If “I don’t know” → it’s probably both, and you need to run the second test to separate them.
This one test cuts through more confusion than any other question we ask in a discovery conversation. Business owners who have spent a year debating whether to invest in new software can usually answer it in ten seconds when it’s phrased this way — and the answer is often the opposite of what they walked in expecting.
Diagnostic 2: The Reverse Substitution Test
Now ask the reverse:
“If we replaced our current team with a perfectly-trained team tomorrow — same software, same processes, just people who execute flawlessly — would the problem go away?”
- If yes → it’s a process or training problem.
- If no → it’s not a training or process problem, or not only one.
The Reverse Substitution Test is a check on the first one. Together they map to a clean 2×2.
The 2×2 that comes out of both tests
Combining the two tests gives you four quadrants:
| Better software fixes it | Better software does NOT fix it | |
|---|---|---|
| Better team fixes it | Layered ProblemBoth process and software need work. Fix in the right order — process first, software second — or the pain won’t fully go away. | Process / Training ProblemThe tool is fine. The workflow isn’t clear, isn’t documented, or isn’t followed. New software here is expensive theatre. |
| Better team does NOT fix it | Software ProblemThe team has the right workflow and the skills. The tool is fighting them. Custom software or serious tooling investment earns its keep here. | Deeper ProblemThe issue isn’t in the tool or the workflow. It’s in the strategy, the market, the org structure, or the incentives. Rare — but real. |
The two most common quadrants for growing businesses are Software Problem (the workflow is clear, the tool is fighting the team) and Layered Problem (both are broken, and one investment on its own won’t feel like enough).
What each quadrant actually looks like
Some concrete examples make the framework easier to use.
Software problem
The sales team has a clear playbook, everyone knows it, and every rep spends 45 minutes at end-of-day copy-pasting data between the CRM and the order system because they don’t talk to each other. This is a tool problem. The team is doing the right thing, badly, because the tool won’t let them do it well.
Process / training problem
Three team members handle customer escalations. Each one handles them differently. Nobody has documented the “right” way. Customer outcomes are inconsistent, and the team blames the ticket system. A new ticket system will not fix this. A defined escalation playbook and 30 minutes of training will. The current tool is not the problem.
Layered problem
Finance closes the books four days late every month. The main causes: a manual reconciliation the team has to do each cycle (software problem — the systems don’t reconcile automatically) AND unclear responsibility between finance and operations for who owns the discrepancies (process problem — nobody owns it). Fix only the reconciliation software and the ownership question stays. Fix only the ownership and the manual work stays. Both need to move — and process first, software second, almost always.
Deeper problem
Sales is missing quota, and the leadership team is looking at CRM upgrades. Perfect CRM software will not fix quota misses driven by a pricing problem in a shifting market. Neither will a better sales team, if the product-market fit has slipped. The diagnostic here has to zoom out further than software or process.
Why we lead with this framework
The reason isn’t academic. Custom software is a substantial investment. If we scope, build, and ship a beautiful application for a business whose real problem was upstream in the process, we haven’t helped that business. We’ve made their broken process faster. That doesn’t serve them, and it doesn’t serve us — the follow-on referral doesn’t happen, and eventually the client circles back for the process work they should have done first.
The best software engagements we’ve ever had came after the client did the process work first. The workflow was clear. The handoffs were owned. The definitions were agreed. All we had to do was build the tool that made a well-defined workflow move at software speed. Those projects ship on time, cost what we estimated, and produce measurable improvements that show up in P&L within a quarter.
How this connects to the other decisions you’re making
The Substitution Tests slot in naturally alongside the other frameworks we’ve written about. If your diagnosis says software problem, the next question is which model of software — which is Build, Buy, or Bend. If your diagnosis says layered problem, the DRIFT framework helps quantify the hidden cost of the software half of it so you can make the case for the investment. If your diagnosis says process problem, the software conversation goes on pause and the leadership conversation starts. Diagnosis first. Response second.
Common patterns worth naming directly
A few patterns show up often enough to flag:
- Jumping to software because process work is uncomfortable. Buying new software is easier than telling your team the workflow needs to change. But the software will not fix what the process didn’t.
- Refusing to invest in software because process work feels cheaper. Sometimes the honest answer is that the tool is broken and the team is doing heroic work to compensate. Refusing to acknowledge that ends up more expensive over time than the software would have been.
- Believing you can fix a layered problem with one intervention. The most disappointing outcomes we see come from teams who invested in the tool but never fixed the process — or vice versa — and then wondered why the pain didn’t go away.
- Running the Substitution Test on the whole business instead of the specific problem. The test works when you scope it: this problem, this workflow, this pain point. It doesn’t work if you try to diagnose everything at once.
How we approach this at Steele Consulting
The first hour of every serious engagement we do starts with these two tests, applied to the specific problems the client walked in with. Not every engagement becomes a software project — and we say so when it doesn’t. The clients we’ve kept for a decade are the ones we told, at some point, “you don’t need us for this.” That honesty is why they came back for the projects where they did.
If you’re sitting with a problem you’re not sure how to categorize, that’s the conversation we’re happy to have. Reach out and we’ll run the tests with you.