Building a Nonprofit Tech Plan on a Small Budget

A nonprofit technology plan should help you decide what to improve, what to leave alone and where limited money will make the biggest difference.

It should not begin with a shopping list.

When teams start with software, they often buy a tool before they have agreed how the work should happen. The new system then inherits the same unclear ownership, scattered information and manual checks. Staff keep using side spreadsheets, and the organisation pays for one more thing to maintain.

A useful plan starts with the work. It looks at what people are trying to do, where it becomes difficult, what information is needed and who owns the decisions. Only then does it ask whether technology should be kept, improved, connected or replaced.

What is a nonprofit technology plan?

A nonprofit technology plan is a practical record of:

• the operational problems that need attention;
• the workflows and information involved;
• the systems already in use;
• the changes worth making first;
• the cost, ownership and timing of those changes; and
• how the organisation will know whether they helped.

For a small nonprofit, the plan can be short. A clear two-page plan that guides real decisions is more useful than a detailed strategy that no one maintains.

The Nonprofit Systems, Data and Tool Decisions hub provides the wider work-first framework behind this approach.

Step 1: Name the work that is difficult

Start with recurring work, not general complaints about technology.

“Our CRM is terrible” is difficult to act on. “Staff cannot see whether a referral has been followed up without checking email and a separate spreadsheet” is much more useful.

Choose one or two problems that create repeated effort, delay or risk. Look for signs such as:

• information being copied between systems;
• reports being rebuilt by hand;
• staff keeping private trackers;
• approvals or follow-ups being chased in email;
• important work depending on one person’s memory; or
• the same information meaning different things to different teams.

Write each problem as a sentence about the work. Include who is affected and what happens when the problem occurs.

Step 2: Map one representative workflow

Before changing a system, describe how one important piece of work moves from start to finish.

Record:

• what starts the work;
• the main steps;
• who owns each stage;
• the information needed;
• the decisions and approvals;
• common exceptions; and
• the final output.

This does not need to become a large process-mapping exercise. The aim is to see whether the difficulty comes from the tool, the workflow or the gap between them.

If you cannot describe the workflow without saying “ask Sam” or “it depends who is doing it,” the plan needs to address ownership and process before procurement. The guide to tool issues and process issues can help you separate the causes.

Step 3: Review the current setup

Create a simple inventory of the systems, spreadsheets and manual routes involved in the chosen workflow.

Do not assume a rarely used tool has no value or that a popular spreadsheet is harmless. Ask why each item exists and what would happen if it disappeared.

Step 4: Choose the smallest useful response

A technology plan should consider more than buying or replacing software.

If systems need to exchange information, read Connecting Your Nonprofit’s Apps before assuming everything belongs in one platform.

Step 5: Define requirements before products

Requirements should explain what the organisation needs the setup to support. They should not simply repeat a product’s feature list.

For each important requirement, record:

• the user and workflow;
• the information involved;
• the decision or action the system must support;
• what must happen when something falls outside the normal route;
• any access, privacy or retention rules; and
• what success would look like.

Separate genuine requirements from preferences. A required audit trail is different from a preference for a certain screen layout. This helps a small budget protect the things that matter most.

Step 6: Budget for the whole change

The subscription price is only one part of the cost.

A realistic budget may need to include:

• configuration;
• data cleaning and migration;
• integration;
• training and documentation;
• internal staff time;
• support;
• future administration; and
• the cost of running old and new routes during transition.

A cheaper tool that needs constant manual repair may cost more to operate than a higher-priced option that fits the work. The reverse can also be true: a powerful platform can create a Complexity Tax through configuration, training and maintenance that a small team never needed.

Use a simple three-year view where possible. You do not need perfect forecasts. You need enough visibility to avoid making the decision on licence price alone.

Step 7: Put changes in a sensible order

Do not try to modernise every system at once.

Sequence changes using four questions:

1. Which problem creates the most repeated effort, delay or risk?
2. Which change needs to happen before another change can work?
3. What can the team realistically absorb and maintain?
4. What evidence will show whether the first change helped?

A sensible first phase might clarify one workflow, clean one important dataset or reconfigure one existing system. That can create better evidence for a later purchase.

Step 8: Plan for adoption and ownership

A tool is not implemented when the configuration is finished. It is implemented when people can use it during real work and know what to do when something goes wrong.

For each change, name:

• the business owner;
• the system administrator;
• the people who will test it;
• the tasks staff need to learn first;
• the route for questions and exceptions; and
• the date for reviewing whether the change is working.

The guide to staff buy-in for new nonprofit software explains how to treat adoption problems as useful evidence, not simply resistance.

A simple nonprofit technology plan template

Your first plan can use seven headings:

1. Problems: the work that is difficult and who it affects.
2. Current setup: systems, files, manual routes and owners.
3. Root causes: process, information, ownership, tool or a combination.
4. Decisions: leave, simplify, reconfigure, integrate or replace.
5. Priorities: fix now, fix next and leave alone.
6. Budget and ownership: total cost, responsible people and capacity.
7. Success checks: what should become easier, safer or more reliable.

You can also use the existing Nonprofit Tech Planning Template to capture the first version.

When outside support may be useful

Many nonprofits can create a useful plan internally. Outside help becomes more valuable when several teams disagree about the cause, a purchase or migration is close, the setup has been inherited, or no one has time to investigate the workflow properly.

If the main problem is still unclear, use the Nonprofit Operations Diagnostic before building a technology solution around the wrong diagnosis.

Frequently asked questions

How long should a nonprofit technology plan be?

It only needs to be long enough to guide real decisions. For a small nonprofit, two clear pages covering problems, current setup, priorities, costs, owners and success checks may be enough.

Should the plan include every system?

Keep a basic inventory, but focus detailed planning on systems connected to important work, repeated effort or material risk.

How often should we review it?

Review the plan when priorities, staffing, funding, services or systems change. A short regular check is also useful to confirm that planned work is still relevant and maintainable.