A calm, honest look at the mistakes most charities make — and how you can avoid them.

CRM projects rarely fail because of the technology. They fail because people are stretched, expectations aren’t aligned, and teams try to fix ten years of data pain in a single three-month window. It’s no wonder CRM projects have such a reputation for stress.

This lesson is here to take the heat out of that.

Once you understand why these projects wobble, you can spot the early warning signs, steady the ship, and give your organisation the best chance of success.

You don’t need more features. You need clarity, honesty and shared purpose.

What you can take from this (the calm version)

CRM projects are not doomed. They just need:

• clarity before technology
• inclusion before implementation
• focus before features
• habits before dashboards
• people before processes

This module will help your team choose better requirements, reduce stress, and build momentum instead of friction.

Lesson 4.1 — Why CRM Projects Go Wrong

1. Starting with the system instead of the problem

Many teams begin a CRM project by looking at vendors. It feels exciting, hopeful — “Maybe this one will finally fix everything.”

But when you start with a system, you skip the most important step: understanding the problems you’re trying to solve.

A CRM is not a rescue plan. It won’t fix:

• unclear processes
• inconsistent data entry
• an overcomplicated gift journey
• broken reporting
• communication silos

A CRM works best when it supports good processes — not when it’s asked to invent them.

2. Underestimating how much change people can absorb

CRMs don’t just change screens. They change habits.

If your team is already stretched, anxious or unsure about data, a big project can feel like asking people to learn a new language overnight.

What we see most often:

• staff don’t have time to test properly
• training is rushed
• processes are redesigned without user input
• people feel talked “at”, not included
• enthusiasm peaks early then collapses in delivery

A CRM project succeeds when people feel:

• heard
• involved
• supported
• confident

Technology is the easy bit. People make or break the project.

3. Focusing on everything rather than the essentials

The quickest way to drown a CRM project? Trying to fix everything at once.

Most charities try to:

• rebuild every process
• replace every spreadsheet
• create dozens of custom fields
• automate everything
• migrate every historic record
• build the perfect reporting suite from day one

This is how projects become overwhelming.

The best CRM projects start small:

• core data
• core processes
• core income streams
• a few critical reports
• tidy permissions

Small footprint → Quick wins → Trust → Momentum.

4. Migrating messy data without cleaning it (or cleaning too late)

A CRM is only as good as the data you put into it.

Common issues:

• duplicates carried over
• missing postcodes
• inconsistent titles
• old mailing preferences
• entire spreadsheets of unknown origin

Teams often leave data quality until the end, when the pressure is highest.

The result? Confusion, complaints, rework, and dashboards you can’t trust.

Data quality needs attention early — and little by little, not as a last-minute panic.

5. Not agreeing what “success” looks like

If you ask six staff members why you’re doing a CRM project, you’ll often get six different answers:

• “We need better reporting.”
• “We need easier selections.”
• “We need supporter journeys.”
• “We need to reduce admin.”
• “We need Gift Aid to be simpler.”

Without a shared goal, the project drifts.

Teams start pulling in different directions. Delivery gets muddled and disagreements surface.

Success should feel small, focused and real, e.g.:

• “We can create selections in minutes, not hours.”
• “Finance gets cleaner coding.”
• “Supporter details are accurate and consistent.”
• “Everyone follows the same process for recording emails.”

Clear success criteria = less stress later.

6. Forgetting that the organisation grows and shifts

A CRM is not a one-off purchase. It’s a living part of your operations.

Projects struggle when:

• future income streams aren’t considered
• teams reorganise mid-project
• new channels are added
• reporting needs evolve

Your CRM shouldn’t simply fit who you are today — it should support who you’re becoming.

Think adaptability, not perfection.

7. Asking the CRM to replace conversations and culture

A CRM can automate tasks, remind people, streamline journeys, and tidy your processes.

But it cannot:

• fix unclear responsibilities
• solve disagreement between teams
• repair culture
• enforce kindness
• replace good internal communication

A CRM supports culture; it doesn’t create it.

If teams rarely talk, a CRM project exposes that very quickly.

Lesson 4.2 — Gathering the Right Requirements

A simple, steady way to understand what your organisation really needs — not just what people wish for.

Most CRM projects fall apart because the requirements stage becomes too big, too vague, or too hypothetical. Teams jump straight into “nice to haves”, vendors hand over long feature lists, and suddenly the project grows arms and legs before you’ve even begun.

The truth is: good requirements come from understanding real work, not imagined work.

This lesson takes you through a calmer, more human way to gather what you actually need — by grounding everything in everyday tasks, frustrations, and opportunities.

Start with reality, not imagination

When people are asked what they want from a CRM, the answers are usually based on hope:

• “It should automate everything”
• “It should give us dashboards”
• “It should be easy to use for everyone”
• “It should stop all our problems”

These aren’t requirements — they’re aspirations.

A strong CRM project starts from something much more solid:

👉 What do we actually do every day?
Where are the pain points?
What slows us down?
What stops us getting the job done?

To get that clarity, we need a simple habit…

The Month-Long Task Log (your secret weapon)

The single best method for gathering real requirements is this:

Ask each team member to keep a log of the data tasks they do for one month.

Nothing fancy. Just a list — five seconds at a time.

Examples:

• “Updated two addresses from returned mail.”
• “Ran event mailing list, removed duplicates.”
• “Fixed gift coding from Finance.”
• “Processed online donations, flagged missing postcodes.”
• “Exported list for newsletter but had to fix casing.”
• “Hunted for correct telephone number across three spreadsheets.”

This gives you gold:

• patterns — what staff do again and again
• friction points — where things always go wrong
• volume — how much each process takes
• opportunities — what a CRM could simplify or automate

It stops the entire project from being built on assumptions.

Why the task log is essential

Because your CRM must serve actual work, not imagined work.

Without it, you risk designing a system around opinions, old habits, or the loudest voices in the room.

With it, you get:

• real, grounded requirements
• clear priorities
• the ability to focus on what will deliver real impact
• a shared understanding across teams

This is one of the simplest, most powerful exercises in the whole project.

Turn tasks into requirements

Once the logs are gathered, the next step is synthesising them into meaningful requirements.

Example mapping

Task: “Fix postcodes before each mailing.”
→ Requirement: “CRM must validate postcodes at point of entry.”

Task: “Search across spreadsheets to find correct contact info.”
→ Requirement: “Single supporter record used across all teams.”

Task: “Manually generate weekly income reports.”
→ Requirement: “CRM must produce reliable income reports with one click.”

Task: “Spend too long de-duplicating event sign-ups.”
→ Requirement: “CRM must flag potential duplicates before creation.”

This approach ensures requirements are:

• evidence-based
• tied to real problems
• free from jargon
• focused on impact, not features

Group your requirements into three easy buckets

Instead of a huge spreadsheet of 300 items, group them into simple, shared categories like:

Fewer buckets → clearer decisions → calmer project.

What NOT to do at this stage

Avoid these common traps:

❌ Jumping into vendor demos before knowing your needs
Demos are designed to excite, not diagnose.

❌ Creating a wish-list of everything you’ve ever dreamed of
You’ll overwhelm yourself.

❌ Letting one team dominate the requirements
CRM projects are cross-organisational by nature.

❌ Over-specifying
You’re not designing software. You’re shaping your needs.

What to do next

With your task logs and grouped requirements in place, you’re ready to:

• spot the high-priority pain points
• filter out the noise
• have meaningful conversations with vendors
• build trust and ownership across your team

And this leads beautifully into the practical action for this module…

Lesson 4.3 — Quick Win: Ask 5 Good Questions Across Your Team (practical action)

A simple way to uncover real CRM requirements — without workshops, documents, or stress.

Before you pick a system, write a specification, or talk to a vendor, you need one thing above all else:

Clarity about how your organisation really works today.

Most CRM projects fail because requirements are gathered from memory, assumptions, or wishlist thinking. The quickest way to avoid this is to ask the right questions — calmly, consistently, across your whole team.

This doesn’t need a workshop or a survey. Just five questions, asked in a friendly conversation.

These questions uncover:

• what people actually do
• where things break
• what slows them down
• what supporters experience
• what the CRM truly needs to support

It’s simple, and it works beautifully.

Your 5 Questions

Use these as written. They’re designed to open honest, practical conversations:

1. What do you update or look up in the CRM most often?

This shows the core day-to-day tasks the CRM must support.

2. Where do things slow you down or frustrate you?

This uncovers pain points you can fix early — the places where small improvements have big impact.

3. What spreadsheets or side-systems do you use that the CRM doesn’t currently handle?

These “shadow systems” often reveal missing functionality or broken processes.

4. What information do you wish you had when talking to a supporter, volunteer or service user?

This highlights gaps in data, reporting, or visibility.

5. If the CRM could make one thing easier tomorrow, what would you pick?

This brings focus. Most people pick something small, not grand.

The Bonus Step: Keep a simple activity log for 2–4 weeks

This is one of the most powerful tools in requirement gathering — and one of the least used.

Ask each team member to keep a light-touch, honest log of the tasks they actually do.

Not every click. Just the types of tasks, decisions and actions they take each day.

Examples:

• “Looked up donor history before a call.”
• “Updated event attendance.”
• “Ran selections for appeal mailing.”
• “Fixed returned post.”
• “Chased missing data from volunteers.”

Patterns emerge quickly:

• duplicated work
• manual tasks that should be automated
• bottlenecks between teams
• data gaps
• training needs
• the tools people rely on outside the CRM

This log becomes your real requirement document — grounded in actual behaviour, not guesswork.

How to use the answers

Once you’ve gathered responses:

1. Group answers into themes

(e.g., data entry, reporting, finance, stewardship, events)

2. Look for the repeated pain points

If everyone struggles with selections, that’s a core requirement.

If one person wants advanced segmentation but no one else uses it, that goes in the “future improvements” pile.

3. Prioritise based on impact vs effort

Start small. Choose improvements that help everyone, not just one team.

4. Build your CRM requirements list from real evidence

You’ll end up with a shortlist that is:

• achievable
• affordable
• rooted in daily work
• far more accurate than any wishlist

Why this works

This simple exercise gives you:

• a shared, honest understanding of how work actually happens
• clarity on what the CRM must support on day one
• a lighter, calmer start to the project
• reduced risk of over-engineering
• stronger staff buy-in (“I can see my voice in this project”)

It creates alignment quietly — without painful workshops.