Skip to content
EMPOBase
en

How to plan digital change in a small NGO

By the EMPOBase team · · 4 min read

Short answer

Plan digital change as a series of small steps. Pick one painful problem, name an owner, agree what success looks like, test with a small group, then expand. Move clean data, train people on real tasks, and keep the old way running until the new one works. Review after one month and again after three.

Key points

  • Solve one real problem first; do not try to digitize everything at once.
  • Name one owner and a small team of users who test early.
  • Clean and trim data before you move it.
  • Keep the old way running until the new one has proved itself, then retire it on a set date.

Why does digital change fail in small NGOs?

Small teams rarely fail because of software. They fail because of time. The person who must lead the change also runs the budget, writes the reports and answers the donor. The project slips, people drift back to spreadsheets, and the new system holds half the data.

A good plan fits the real capacity of your team. It is small, it has one owner, and it protects daily work.

Three causes appear again and again: no clear goal, no protected time, and no end date for the old way. The sections below deal with each of them in turn. If you fix only these three, you avoid most failed rollouts.

What should you do first?

Start with a problem, not a product.

  1. List your three most painful tasks. Examples: chasing approvals by email, building the donor report by hand, searching for the signed contract.
  2. Pick one. Choose the task that costs the most time or creates the most risk.
  3. Describe it today. Write the steps, the people and the files involved on one page.
  4. State the goal in plain words. For example, “every payment request has a record of who approved it”.
  5. Set a date to review whether you reached the goal.

If you cannot state the goal, wait. A tool added without a goal adds work.

A concrete example: a small NGO runs two projects and one office. Approvals for purchases happen by email, and the finance officer spends hours each month finding who agreed to what. The goal is “every purchase request shows who approved it and when”. That goal is small, clear and easy to check. It also tells you which feature matters and which ones you can ignore for now.

Who should be involved?

  • An owner. One person is responsible for the plan. This is usually a program or operations lead, not an outside contractor.
  • A sponsor. A director or manager who backs the change and removes blockers.
  • Two or three testers. People from different jobs who try the new way first and speak openly.
  • A decision about time. Agree how many hours per week the owner may spend. If the answer is zero, the plan is not real.
  • A person for data. Someone who knows the old files well enough to say which are right. This is often a long-serving finance or admin officer, and their knowledge is the most valuable resource you have.

How do you prepare your data?

Moving messy data into a new system only moves the mess. Before you move anything:

  • decide which records you need, and leave out old ones with no use,
  • fix names, dates and codes so the same thing has one spelling,
  • remove duplicates,
  • check who may see the data in the new place, using roles.

Our article on roles and permissions explains how to set access before people log in. If you hold sensitive records, read about handling sensitive program data first.

How do you roll it out?

  1. Pilot. Run one process with the testers for two to four weeks.
  2. Train on real tasks. Use short sessions with real examples, not a tour of every menu. People learn by doing their own work.
  3. Keep the old way running in parallel for a short, fixed period.
  4. Fix the top three complaints before you widen the group.
  5. Set a cut-off date for the old way, and tell everyone. Without a date, two systems live forever.
  6. Tell donors and partners if the change affects what they receive, such as how reports reach them.
  7. Write a one-page guide for new staff who join later.

How do you know it worked?

Check after one month and after three. Ask:

  • Is the goal from step one reached?
  • Do people use the system for the whole process, or only part of it?
  • What still happens outside it in email or spreadsheets?
  • What would we change?

Look at the work you no longer do, as well as the work you do. If staff still copy data by hand into a spreadsheet, the system is not yet trusted, and you should find out why. Share the results with staff. If something failed, change the plan, not the people. A small honest review each quarter keeps the change alive.

Where EMPOBase fits

EMPOBase is operations software for NGOs and CSOs, and you can start with one module, such as Procurement or Projects, then add others as your team is ready. Roles and permissions let you set access before people sign in, and the documentation covers each module. EMPOBase does not replace the planning above: someone in your team still has to own the change, clean the data and train colleagues. See the platform overview or ask us for a walk-through.

Questions people ask

How long should a first rollout take?

For a small team, a first module can be live in a few weeks if the scope is small. Plan for a longer period of habit change after that, because training and new routines take time.

What if staff resist the change?

Ask what they fear. Often it is extra work or loss of control. Involve them in the test, fix their top complaints, and show how the new way removes a task they dislike.

Do we need a consultant?

Not always. A clear owner, a written scope and vendor support are often enough for a small team. Use outside help for data migration or process design if you lack time.