Avoid expensive, multi-year CRM implementations

Have you ever been stuck in a multi-year CRM implementation that never seems to get to YOUR department? And you still have to figure out how to run your programs?

I see this way too often (when I was on an IT team in the private sector, and even more now that I work on projects in the public sector).

A lean, overburdened IT team dealing with an overly ambitious scope...

...and in the meantime, a ton of stakeholders just never get their system needs met. Spreadsheets + shadow systems proliferate.

Why does this happen?
~ Senior leaders want "a single system to do it all"

~ the "single system" chosen often has a great brand name, Salesforce?? Microsoft? on paper it checks every box!, but actually getting it to do everything you want takes customization & time

~ IT teams understandably need some centralized controls but realistically, they don't have the capacity to address every small process need, to lead the change management, or to even make sure that the system works for every stakeholder

If this is you, here are some principles to think about:

➡️ Tech implementations start with understanding processes. IT teams should become experts in process & workflow optimization as a skillset. Notably, this is even more important in the Age of AI because documentation is the foundation for AI agents.

➡️ Expertise lives with the person who does the work. Each team needs a say in how they do their job.

➡️ Each team deserves a fit-for-purpose (and ideally best-in-class-for-the-price) tool for their unique work, as much as possible.

➡️ There is no single tool that does everything for everyone

➡️ Related to the ambition of the project, if an implementation will not deliver value to the stakeholder within a year, it's too big. It needs to be broken into small parts and the timeline must be realistically communicated to every stakeholder.

➡️ Sensitive data shouldn't be maintained in spreadsheets, full stop. Giving a team a "silo'd" platform that protects data is better than the risk of an extra platform or two.

➡️ Being open to specialized platforms (e.g. a fundraising tool for the development team that is best-in-class) can be a test run for how well a team really knows their own requirements. It's certainly a more manageable project.

➡️ Data quality relies on people using and adopting the tool into their day-to-day lives. If a tool is more likely to be adopted, even if it's "separate" from the central system, it's more likely to lead to the data outcome that everyone's looking for.

➡️ Central controls should exist, but right-sized for the capacity of the IT / data team. (And, if there is no IT or Data team, one must be realistic).

➡️ Solve the data problems on the back-end through integration and de-duplication as much as possible, vs. burdening the user.

➡️ Lack of change management WILL be why the "single system to rule them all" fails. After all that.

There's a book to be written someday about this stuff!