How to Separate Software Problems From Process Problems

When work is late or a record is wrong, staff may say the software is the problem. Sometimes it is. At other times the system exposes an unclear responsibility, a missing decision, or inconsistent information that existed before the software. Find the cause before paying for a feature or training people around a defect. The most useful investigation follows a real case from beginning to end.

Reconstruct one ordinary failure

Choose a recent delayed order, missed appointment, or incorrect report. Ask what each person knew, which record they saw, and what they expected the next person to do. Distinguish the point where the work first went wrong from the point where someone noticed it. A late delivery might start with an unconfirmed address, then appear as a scheduling problem days later. Fixing the calendar screen alone would not resolve the original gap.

The GOV.UK guide to mapping a user's whole problem encourages looking across the full journey and the organizations or teams involved. Its public-service setting differs from an SME's, but the method helps avoid optimizing one screen while the handoff around it still fails.

Test the competing explanations

If staff cannot find a required action, observe them using the product. Is the action hidden, labeled unclearly, or unavailable to their role? That is a software or design issue. If everyone can see the task but nobody knows who should approve it, the business rule needs attention. If the rule is clear but the system routes the task to the wrong person, the implementation is at fault. More than one cause may be present.

Check whether people use a workaround. A spreadsheet beside the application may signal that the product lacks a needed view, that staff distrust its records, or that managers still ask for the old report. Ask what the workaround supplies before removing it. The GOV.UK guidance on moderated usability testing recommends watching people complete realistic tasks. A short observation can be more revealing than a general complaint that the software is 'hard to use.'

Compare the same task across roles or locations. If one team succeeds with the same screen while another struggles, investigate differences in training, information, authority, and workload. That does not rule out a design issue; the product may fit one context and fail another. It narrows the question. If every team encounters the same failure at the same step, the system itself deserves close inspection.

Ask what changed before the problem began. A new policy, staff turnover, imported data, or a recent software release may explain the timing. Reproducing the failure with a specific case helps a developer identify a defect and helps a manager identify an unclear handoff. Keep uncertainty visible until the evidence supports a cause.

Match the remedy to the cause

A confusing form may need clearer wording or a different sequence. An unclear approval may need a business decision and staff communication. Duplicate data entry may need a shared record or a focused connection. A recurring technical failure needs root-cause repair and testing. Write down the evidence for the chosen explanation and what result would show the remedy worked. Avoid a broad redesign when a narrow change can be tested first.

Include the consequence for customers. A process change that saves staff clicks but leaves customers repeating information has not solved the whole problem. Likewise, a customer-facing portal cannot repair an internal record nobody keeps current. Ask the people affected to try the revised task, including an exception. Review whether the same failure recurs after enough normal work has passed.

Holism can help the business owner identify the operating rule while a developer uses AI and reusable foundations to diagnose and fix system behavior. The developer should explain the technical cause when there is one, and the owner should decide responsibilities when the process is unclear. Separating causes prevents the business from buying software for a management decision or blaming staff for a genuine product defect.