It is obvious that as a nonprofit you don’t want to fail with your CRM implementation.
But focusing on avoiding failure when it comes to a CRM project can mean that you and your organization are going to do things the same way as you did before.
This means you’re really only making minimal changes and this is where the big risk of failure comes from.
You’re failing to see the larger possibilities that the platform has to offer.
In this blog post, we’re going to cover why we believe most nonprofit CRM implementations fail and what you can do to fix them.
Focus on Transformation
So instead of focusing on failure, it’s best to focus on transformation.
Transformation itself is a really powerful concept. It’s all about growth and change.
Think about the transformations that happen in nature – like when caterpillars morph into butterflies or when you see tadpoles grow legs and become frogs.
Transformation is based on the idea – you take something that’s not working, something unattractive or out-of-date and magically change it, update it and make it better.
That’s what you really want in your CRM project.
You want something to help you do your work better – to help your organization achieve more, to help you impact your mission and your social change that much better.
What the world doesn’t tell you is that transformation is hard and it requires a lot of work.
Why CRM Implementations Fail
To illustrate two common scenarios when CRM implementations fail we’re going to give you examples of two people who decided to start a non-profit.
Each founder went out and did all the things. They established boards that courted donors, they created excellent programs and found that they all need a better way of tracking and measuring their efforts.
The first person – So the first person decided that he wants to implement a CRM system for his organization.
He wasn’t sure how to go about implementing it but he dove right in and started building.
And rather talking to the users, he assumed that they wanted the same things that they already had in their legacy system.
So he kind of copied everything. He made lots of custom fields, lots of custom objects and really wanted his CRM system to look and feel like their old system.
In addition to that, the organization price itself on having an open and collaborative culture.
So he decided that he should give everybody read/write access to all the data and everybody needed to be a system administrator in the system.
They chose to skip cleaning the data before importing it because they had a couple legacy systems happening, a few excel spreadsheets, some old Access database and another system.
He thought that if he put it all there, it would magically work itself out in his CRM system.
Finally, when he was done and the build was complete he shut off access to the legacy system, took away their spreadsheets and switch them all to his CRM immediately.
And that didn’t work very well.
The organization simply couldn’t get anything useful out of the CRM.
They couldn’t answer questions like how many clients do they serve in an year, what were the updates metrics for the upcoming board meeting and one of funder required numbers on a specific program.
They had no idea how to pull them. So their CRM implementation failed because it had no foundation.
There are no thought given to anything except the build and even that was weak quite frankly.
Data quality was lacking, users option non-existent and no thought was given to ongoing support and maintenance.
So that one did not work.
Second person – the second person decided that he needed a CRM for his organization too.
He wanted to build a sturdier CRM system.
So he went out and he hired a consulting partner to help his organization go and implement the CRM system.
This partner went and did great user interviews and gathered tons of requirements, each on being super important.
Everything had to be there to go live, nothing could be delayed and because of that the project went on for a very long time and such things happen more requirements got added layered on top.
By the time it got rolled out the system was very complex and confusing.
Users had no idea what was built and they had no idea how to use it.
They complained about the excessive data entry and they saw no benefit in using it at all.
In the end, this CRM implementation wasn’t successful as well.
Users simply gave up and they start using Excel again. As a result nothing good came out of that.
So done well a Salesforce implementation can help you transform the way your org does work rather than your work controlling you.
As mission driven people that are in mission driven organizations you cannot be wasting time in data related that take you away from making a positive impact.
Because at best the amount of data that you work with is currently manageable by the amount of people working at your org.
At worse, we’ve seen the task of simply tracking this data a lot of staff morale.
They are no longer doing the impacting work that they wanted to do. They’re simply entering and maintaining data when there is definitely a better way.
Recipe for Success with your CRM Implementation
It’s helpful to remember that your CRM system is just a tool that enables you to use your data to help your mission.
Here’s our recipe for success.
- The right mindset around your build
- Assemble your council
- Know what you want and prioritize
Now let’s go into each one in a bit more detail:
The right mindset – having the right mindset for implementation is key. This is from Galileo camps, it’s a summer camp.
Their mission is to develop innovators who envision and create a better world.
They do this by teaching and applying this approach that was inspired by the innovation process developed at the Stanford D School.
Throughout your implementation you’re going to end up sitting down with people, you’re going to gather countless requirements, you’re going to do research, you will build proof of concept, you will gather feedback, train your users and eventually you’ll roll out your implementation.
If you look at this with your CRM system in mind, we recommend that you focus on the planning phases which is identifying goals and generating ideas.
Now the formula for implementation is 90% people and 10% technology.
This means you should focus on your people and get to know your stakeholders. They are the gatekeepers to your success.
They hold all the knowledge because they are the ones doing the work every day.
You need to get your staff talking because you’re going to need their help to answer some tough questions that will determine which direction your implementation will go towards.
For example: here are some questions you might need answer to.
- What is your organization looking for now? What about 5 years from now?
- What is your board using as a measure of success?
- How will this tool help you fulfill your mission and hit your strategic goals?
If you put yourself in your stakeholder shoes, you should try to discover what is taking them away from making an impact.
Is it a report that they have to spend hours putting together? Is it data that they have to manually copy from two other systems into another?
Do they have documents that they have to generate so they look exactly how their manager wants it?
Ultimately, how do they want this system to make their live easier? What do they hope the system do for them?
Bring your team together – there are three types of people within your non-profit organization that are crucial for success – your executive sponsor, your CRM admin and your power users.
Let’s cover their roles in a bit more details:
- Executive sponsor
In your council, also known as your governance board, the first people you’re going to need is your executive sponsor.
This is someone who’s going to champion this on the senior level to help get all the senior leaders on board.
If the top people are not convinced and asking their teams to use the system you’re implementing this for no one.
For example: If you’re all about getting the information in your CRM system but the executive is still keeping items in separate spreadsheet then your data is out of date.
This doesn’t have to be complex. Basically, you just need to remember what gets measured and what gets done.
So if your senior leaders are asking to see if things done in your CRM with metrics or data activity, this reinforces a mentality that they are looking in here so that work has to be done in here.
- CRM admin
You’re also going to need a CRM admin. This is your important person who’s ultimately in charge of translating your manual business processes into automated actions.
If your CRM is a free car then your admin is the driver.
So if you have a bad driver, it doesn’t matter what kind of car you give them. It’s the fundamental skills and their processes that will need help.
So someone needs to take control and be the point person for all CRM.
- Power users
You will also need your power users.
This is where you can’t assume you know what your users want and need. You need liaisons within each department to inform you of how CRM changes will impact them.
This by no means is delegating work. This is leveraging other people’s expertise so that you can focus on an awesome CRM implementation.
You can identify these people easily.
These are the people that ask a lot of questions about how things work and why things work.
They are the quick learners and they also don’t mind rolling up their sleeves. They often offer solutions and ideas at the same time.
Know what to prioritize – finally, you need to know what to prioritize.
When it comes to requirements, you should gather everything but don’t do everything.
You need to stay focused on the main reason for your CRM implementation.
It’s helpful to think about your implementation in phases.
- Phase one – these are your core requirements. What needs to be definitely done no matter what.
- Phase two – items to complete time permitting
- Phase three – the things that are nice to have for a later date
Another key to keep in mind here is that products don’t drive processes, requirements do.
There is a strange myth that once you get Salesforce, everything is solved.
Staff thinks that once you get your data in there, you will figure it out then. However, you’re setting up yourself for failure this this mentality.
This is definitely worth the time. You need to press to be sure that there is clarity in your requirements and don’t let them slide or things will ripple into much issues later.
We believe that clarity over your processes will make your implementation much faster because this results in less questions, less meetings and less time wasted back and forth.
It’s helpful to question everything and take a microscope to all your requirements. You might want to ask questions such as this:
Why is this important? What business pain is this going to solve? Is this a must-have or is this a nice to have?
If you hire a new person in your organization and you go on vacation, what does he need to know from A-Z to get this done?
If they can’t answer these questions clearly, you’re going to need to dig further to avoid troubles here.
Sometimes having them talk about this is the first time they have to explain what they’re doing and hearing them out loud can help them have their own questions such as “Why are we doing it this way?”
How to Properly Manage the Process of CRM Implementation
Every process is composed of people, process and technology.
Now we’re going to talk about managing the process of building the thing and the technology needed to build the thing.
It’s like a technical term we use a care.
Scope and MVP – if you did your research well, you have collected every want and every need for implementation you’re about to undertake.
Your users have fought the good fight of “But I need that just because I need it” and you so graciously took all of that information in and now you heard you took it into consideration and now you’re to draw the line in the sand point.
The three letters that strike fear in the hearts of your users but love through your project management team – MVP (Minimal Viable Product).
The must have vs the nice to have.
So you have your MVP. You know what you have to build to get folks in the system and working. Now you need to detail out that scope of MVP.
What exact functions need to be present? Once you determine that then you must stick to it.
Scope creep is the demise of your implementation.
You’re going to be faced with people who say
- “I really need this. I totally forgot when you were collecting requirements but I swear to God, I really need it”.
- “oh, I didn’t even know I needed that now in the middle of development, I swear I really need it”.
To be fair, there’s going to be some required functionality that is going to be overlooked.
It happens. It is just the way it is.
So what you need to determine with you and your development team is if you can add it on or if you need to switch something else to make that thing happen so that prioritization of the new requirement you had versus the old requirements you thought you had.
Please, do not attempt a pile on of requirements. It will never work in your favor.
To agile or not to agile – after you have your MVP and you defined your scope, it’s time to think about how you’re going to build this.
From our experience, agile is the way to go when it comes to a CRM implementation.
It’s not a raise to the finish line to a finish product but a walk on a CRM trailhead to get an understanding of how functions should be build, tested and used.
So learn why you build.
Having your team of power users as a part of your built will give you and them a greater knowledge of what you really need in the system.
I found that when users are in the system and working, they realize that the complex processes they follow thought they needed really don’t make sense when this shiny new world they’re building.
You need to test along the way.
How many times have you had a big reveal of a new system that your end-users needed?
“Here’s what I want. You geeks go out in the cave and build it. I’m so certain when it came out, it will be exactly what we need”.
This always leave to course-correct. You find that the direction you were going it’s not really the direction you need to be going.
So after you find out you’re going the wrong way.
Every agile implementation in the beginning is like a Frankenstein monster but that’s the beauty of agile.
It allow you to think on your feet and make things happen to what your organization needs to do.
If you need pieces of that to be waterfall for the comfort of your users, make some pieces of a waterfall.
If you need to have a daily scrum, have a daily scrum.
These things are interchangeable but do not go in with like “I’m a scrum master”, “I’m the head guy in charge”, etc.
If people never done this, they will be “what is a daily scrum?”, “what is a sprint?” and you’ll have to define it 50 times.
The beauty of agile is you get to define what pieces you need of it to make it work for your organization.
Think about Data – data is your foundation and the focus of any CRM.
That’s why you need to focus on the input integration.
Where is this data coming from?
All the systems that are feeding into your world determine which of those are critical for your MVP.
You might have dozens of systems feeding data. Some might be integrated and some might not be.
Some might be manual uploads, some might not be.
Take a take on your inventory and think about what is critical.
You will find that some of these pieces need TLC or customization and some pieces will not.
Some people that are getting manual uploads now will continue to get manual uploads in an MVP. This is totally fine.
These folks will be totally fine with the manual upload once ago life happens.
You also need to approach the folks you refuse to use the old system, the ones keeping secret records in excel.
You just let them know that they can continue doing what they’re doing but you give them the standardized spreadsheet and when they’re done, you can manually upload the data in your system.
Because by the end of the day, if it’s not in the system, it doesn’t exist.
What do you put in the system? – We have found that most essential data can be determined from the reports that are being generated currently.
So they’re a combination of the old system, which some people may or may not be using, spreadsheets, that people are secretly hiding, or people who simply know what they need.
It’s important to understand how you measure progress.
What reports tell the story of your work, your goals and your progress?
Who gets one inside your system? What reports are being generated and sent to your internal co-workers? What about measures and metrics, pipeline, revenue reports?
What do you share with the world? What reports keep you up-and-up with the people outside of your organization? Annual reports, donor summaries.
By tracking other reports that answer these questions above you’re going to have a pretty thorough story about what data is needed in your new system.
So the three steps to success for data are:
- Define what data is essential
- Define what can be archived
- Clean your data
Once you define your minimal, look at your users and you’re going to say “ok, what data do you need?”.
Of course, they’re going to say “we need it all” but you need to get to what is absolutely necessary.
So start asking critical questions like “Do you really need that data from 1974?”.
You also need to play therapist “Your data served a good purpose an year ago but now it’s time to let it rest in the archive. It’s done its work.”
You need to explain to people that archiving does not mean deleting the data forever. It just means you put it to sleep and it will be there when they need it when it’s necessary.
So once you do that, you need to get your co-workers in the headspace of cleaning their essential data.
Tell them that the clean data is welcomed into your shiny new building and that’s the only thing that’s welcomed.
If you put crap in, you’ll never get the reports that you need.
In conclusion
Salesforce implantation is something that you definitely don’t want to do alone.
You want to create your governance council to gather input, priorities and establish timelines for your execution.
Definitely don’t do it all at once. Limit your scope what’s doable and phase in additional features and functionalities over several releases.
Remember that this is a marathon, not a sprint.
Focus on your data and your therapy skills.
What goes into the system determines what data is available for reporting and analysis.
Remember that not all data is essential and archiving is your friend.
Use agile methodologies to make the plan work for you and your organization.
Use iterative development cycles being so you’re able to course-correct. Use checkpoints and user involvement to build the system that’s going to work for your organization.