How do you know whether the problem is the software or the process?

What is happening

Someone says the tool is the problem. Someone else says the team is not using it correctly. Both are describing symptoms of the same thing: the work has never been defined precisely enough for anyone to tell the difference.

Why it happens

• Processes evolve informally and live in the heads of a few experienced people.
• Tools are selected on features rather than on a described workflow.
• Different departments follow different variants of the same process and each believes theirs is standard.
• Data problems get attributed to the system that displays them rather than the process that produces them.

What to do first

Describe the work tool-free

Write the process as a plain sequence: trigger, inputs, steps, decision points, approvals, outputs, and definition of done. Name the role accountable for each step. If two people write it differently, you have found the real problem.

Then run three tests

• Consistency test: do three people performing the same work perform it the same way? If not, it is a process problem.
• Workaround test: are people leaving the system to complete the work? Ask why. If the answer is 'the system cannot do X,' verify that against the vendor before accepting it — often it can, and was configured otherwise.
• Data test: is the information wrong because the system calculates it wrong, or because the input it depends on is never captured? The second is a process problem.

What not to do

• Do not start a tool evaluation to answer this question. A demo will make any process look solvable.
• Do not accept 'the system can't do that' without confirming whether it was configured, licensed, or trained for.
• Do not redesign the process purely around the current tool's limitations either — that is the same mistake in the other direction.

Questions to ask

• Who owns this process end to end, and can they change it?
• What decision is made at each step, and by whom?
• What would this process look like if it ran perfectly, in a tool we do not have yet?
• How many exceptions are there, and are they truly exceptions or an unacknowledged second process?
• Which of our complaints are about the tool, and which are about how we work?

Warning signs it is the process, not the tool

• The organization has replaced tools in this area before with the same result.
• Requirements are described as 'like the old system, but better.'
• Every team asks for a custom field or a custom view rather than agreeing on a shared one.
• Nobody can say who approves a change to how the work is done.

When internal teams can handle it

If one accountable owner can convene the people who do the work and settle the disagreements, internal teams can usually run this analysis in a few working sessions.

When outside help may be appropriate

When the process crosses departments with different incentives, when the disagreement is really about authority rather than workflow, or when a purchase decision is imminent and the organization needs a defensible answer before committing budget.