Reconfigure, Replace, Integrate, or Redesign? A Nonprofit Software Decision Guide

When work feels harder than it should, it is easy to say, “the system is the problem.”

That is understandable. The friction usually shows up in the system first. People copy information between places, keep side spreadsheets, chase updates in email, repeat manual steps, or rely on memory to keep things moving. From the team’s point of view, the software is where the problem shows up.

But that does not always mean the software is the root cause.

In small nonprofits and other small organisations, the issue often sits underneath the tool: unclear handoffs, inconsistent data entry, missing decision rules, duplicated steps, or a process that has changed over time without ever being properly defined. Sometimes the tool is part of the problem. Sometimes the process is. Often, it is both.

If you are trying to work out what is actually broken, that is usually a more useful question than “do we need a new system?” The aim is to separate symptoms from causes so you can see whether the main issue sits in the tool, the workflow, or the gap between them.

When it is easy to blame the system

You might be seeing things like this already:

• Staff keep their own trackers because they do not trust the main system to show the full picture.
• Information gets entered in more than one place.
• People have to ask around to find out what stage something is at.
• Reporting takes longer than it should because the numbers need checking or cleaning up first.
• Important steps happen because experienced staff remember them, not because the workflow makes them clear.

This setup is frustrating because the work itself is usually not unusual. A referral needs a decision. A case needs an owner. A donation needs to be recorded consistently. A report needs clean data behind it.

On paper, none of that sounds especially complicated.

But when the process and the system do not support each other properly, straightforward work starts to feel awkward and unreliable.

That is why teams often blame the system first. The software is where people feel the delay, the extra clicks, the missing information, or the reporting gap. Still, that does not automatically mean the software is the main thing to fix.

What small teams are often dealing with before they know what is wrong

In many small organisations, this builds gradually.

At first, people make it work. They create a spreadsheet to fill a gap. They agree a workaround over email. They remember which exceptions need special handling. They check figures manually before sending a report. Because the team is capable and committed, the setup keeps going longer than it should.

That can hide the real issue for quite a while.

By the time the problem becomes obvious, it often looks like this:

• reporting takes too long
• handoffs happen differently depending on who is involved
• exceptions are handled from memory rather than through an agreed route
• staff are not fully confident that data means the same thing across the team
• no one is quite sure what to fix first

This does not usually mean the team is doing a bad job.

More often, it means the way work has evolved is no longer clear enough or supported well enough. What used to be manageable through effort and goodwill has become too dependent on individual habits.

That matters because recurring friction is usually easier to diagnose than it first appears.

What may actually be going wrong

A useful way to think about this is to separate the symptom from the underlying cause.

The symptom might be “reporting is painful” or “staff hate the system.” The cause could sit in the process, the tool, or both.

Signs that point more to a process issue

A process issue is more likely when the work itself is not defined clearly enough to be done consistently.

Common signs include:

• it is unclear who owns a task at each stage
• two people do the same piece of work in different ways
• decision rules exist in people’s heads rather than in an agreed process
• the same information is entered differently by different teams
• steps are duplicated because no one fully trusts the previous step
• workarounds exist because the real workflow was never clearly described

Reporting is a common example. On the surface, it can look like a system problem because every report needs manual cleanup. But often the deeper issue is that each team records the same information differently. One team uses short labels, another uses full descriptions, another leaves fields blank and explains things in notes. The report is difficult because the input is inconsistent, not simply because the reporting function is poor.

Signs that point more to a tool issue

A tool issue is more likely when the workflow is reasonably clear, but the software cannot support it properly.

That might look like this:

• the system cannot capture information you truly need
• permissions are too limited for the way responsibilities are split
• required fields cannot be enforced where they need to be
• status tracking is too basic to reflect a real, agreed workflow
• reporting is blocked by a real limitation in what the system can produce
• avoidable manual work exists because the tool cannot do a necessary step reliably

For example, if your process is clear about which stages a case should move through, who can approve it, and what must be recorded at each point, but the current system cannot handle basic status tracking or permissions without awkward workarounds, that is a stronger sign of a real tool limitation.

Signs that point to a combined issue

This is often the most common situation.

The process is not fully clear, and the tool was never set up for the job as it really works. Over time, the two problems reinforce each other.

A case-management workflow is a good example. Staff may be relying on spreadsheets and email alongside the main system. At first glance, that makes the software look inadequate. But when you look more closely, the deeper issue may be that approvals, ownership, and next steps are not clearly defined. The tool then gets used inconsistently because it is trying to support a workflow that was never fully agreed.

In that situation, asking “is this a tool issue or a process issue?” can be a little too neat. Often the answer is that an unclear process is being carried by a tool that was never configured for the work as it actually happens.

Reconfigure, redesign, integrate, or replace?

Once you can describe the workflow, do not jump straight from frustration to procurement. Choose the smallest response that resolves the real blocker.

Sometimes the correct answer is to leave the tool alone and simplify how it is used. A replacement that adds flexibility can also add a Complexity Tax: more configuration, more training, more permissions, more integration, and more maintenance. Count that ongoing work as part of the decision.

What evidence should support the decision?

• A plain-English map of one representative workflow.
• Agreed owners, decisions, definitions, and exception routes.
• A list of real tool limits, separated from preferences.
• The volume, frequency, and risk of manual workarounds.
• The cost of migration, training, integration, and ongoing administration.
• A clear description of what success would look like six months after the change.

If that evidence points in different directions, do not force a software decision. Diagnose the wider operating pressure first.

How to tell which problem is strongest

You do not need a large review project to get a clearer view. Start by testing how well the workflow can be described without referring to individual habits.

A few practical questions can help.

If two people do the same task, do they follow the same steps?

Is it clear who decides what, and at which point?

When something falls outside the normal route, is there an agreed way to handle it?

Could a new staff member understand how the work moves from start to finish without relying on verbal tips from experienced colleagues?

Do people use the same definitions for the same data?

If the answer to several of those is no, you are probably dealing with at least a process problem.

A simple distinction can help here:

• If the team cannot describe the workflow clearly without referring to personal habits, shortcuts, or “how X usually does it,” it is probably at least partly a process issue.
• If the workflow is clear, agreed, and consistent, but the system still blocks it or creates unnecessary manual work, the tool may be the stronger issue.
• If the workflow is partly clear but breaks down around handoffs, exceptions, and reporting, while the system also feels awkward, it is probably a combined issue.

One pattern comes up often: teams say, “the system is the problem,” when the bigger issue is that key steps, ownership, and exceptions were never defined clearly enough for any tool to handle well.

For example, a team may say their system cannot support client intake properly. But once you map the work, you find there is no agreed answer to basic questions like who owns the case after triage, what counts as complete information, or what should happen if approval is delayed. In that situation, replacing the software may simply move the confusion into a new platform.

By contrast, a true tool limitation looks different. The process is clear. Staff agree on the stages, the handoffs, the required information, and the decisions. But the current system still cannot enforce required fields, cannot show the right status clearly, or cannot produce a basic report without exporting and rebuilding it elsewhere. That is much more likely to be a genuine tool problem.

Start with the workflow before making a bigger change

The safest first step is usually to define one frustrating workflow in plain English.

Not every workflow. Just one.

Pick the area where the friction is most visible, and write down:

• what triggers the work
• the main steps
• who owns each stage
• the key decisions
• what exceptions come up
• what the final output needs to be

Keep it simple. You are not trying to create a formal process manual. You are trying to see the work clearly enough to tell where the effort is really going.

As you do this, mark two different kinds of pain:

• effort spent because the process is unclear
• effort spent because the system genuinely cannot support the work

That distinction is often where the answer starts to become clearer.

If the pain reduces once the workflow is defined more clearly, you may not have a major tool problem after all. If the workflow becomes clearer and the same blockers remain, you have a stronger basis for saying the tool is part of the issue.

This is also why diagnosis helps. It makes the next decision clearer.

Sometimes a modest process fix removes most of the frustration. Sometimes mapping the workflow exposes a real system limitation with much less guesswork. Either way, you are less likely to spend time and money solving the wrong problem.

If disconnected systems and repeated transfers are part of the problem, read Connecting Your Nonprofit’s Apps before assuming everything belongs in one platform.

Browse the Nonprofit Systems, Data and Tool Decisions hub for technology planning, integration, data and procurement guidance.

Use a simple checklist to decide what to look at first

If you are trying to work out whether you are dealing with a tool issue, a process issue, or both, a short checklist can help you assess the pattern more calmly.

A good checklist should help you look at things like:

• ownership
• handoffs
• exceptions
• data entry consistency
• reporting pain points
• workarounds and side systems

You are not scoring your organisation. This check helps you see whether the main problem sits in the workflow, the software or the gap between them.

If you are still planning the setup, use the nonprofit technology planning guide. If the system is already live but people work around it, review the staff buy-in guide.