By Tracy Kronzak
A few weeks ago I returned from the annual Nonprofit Technology Conference, hosted by NTEN in Washington DC this year. I’m a long-time alumna of this conference – this was the 7th that I’ve attended and the 5th that I’ve spoken at as a presenter. In the intervening years, the conference has grown and evolved, and the definition of technology has expanded accordingly: from the blinking lights and rack-mounted boxes that represent my own roots in IT Management, to implementing platform solutions such as Salesforce and the opportunities they open for an organization.
I was asked candidly what I thought about nonprofits using Salesforce and the kinds of things that its successful use actually requires. Connecting this response to some of the topics I presented about with others from the recent NTEN conference, I came up with a bullet point list of things I believe are often considered separately, but to me are components of the larger picture of these requirements.
An implementation project is not a complete solution for an organization, and often can reveal the fault lines of where an organization needs to solve internal issues completely unconnected to Salesforce. I’ve spoken with clients who time and again sincerely believe that moving to Salesforce will “solve” their issues with understanding constituents, fundraising, or other processes because, “Salesforce can do anything.”
Salesforce can do many things, some better than others, but at the end of the day, it is not an infinitely scalable tool. It has its own set of best practices for the platform, processes and procedures for data entry, and every layer of customization and configuration added to the platform must consider these. You won’t be able to make it look like the system(s) from which you are migrating, you may need to change the way your data and staff behaves, and there are sometimes absolute right and wrong ways for implementing solutions using it. I alluded to this in a blog last year.
Similarly, many organizations want Salesforce to replace older or outmoded systems, and the expectation is that these systems are somehow internally “wrong” for the organization, and that moving to Salesforce will enable the “right” system for the organization. The scope of implementing this “correct” system gradually increases as organizations turn to the platform to help them define business processes, new rules of operation, and other standards that they actually need to have in-hand before ever beginning an implementation project. The outcome of overly-high expectations is that when a very small-hours project doesn’t impact far and deep across an organization, or a large-scale project doesn’t have adequate internal support for the changes it’s bringing to an organization, the implementation is deemed a failure because it didn’t solve the root cause.
Salesforce does not give an organization anything it doesn’t already have – it only reflects what is there. And inadequate internal communications, non-best-practice fundraising methods, failure to understand key organizational metrics, poorly managed change, and overly ambitious project scopes are all going to continue to haunt an organization – Salesforce or no.
The number one reason why technology implementations fail is lack of Executive Sponsorship. But what does this really look like for an organization implementing Salesforce?
If an organization’s data is its legacy, then the executive sponsorship of a Salesforce implementation must give equal footing to it with other priorities that support the long-term success of the mission. Your Salesforce implementation, even if it is small in hours and narrow in scope, is as important as your strategic plan, your program goals, and your HR/Finance policies and administration. To not align management, Board level, and staff leadership resources around it is a strategic mistake.
There will be staff who are resistant to change, and your internal lead must have executive support in bringing them through the implementation. Similarly, there will be potentially far-reaching decisions to be made about how to enter data, what data is important to your organization, who and how gets to use Salesforce, and how your Salesforce instance will be grown over time. A single project lead that has minimal oversight and involvement from organizational management, little latitude to pull in other staff as collaborators, and who is languishing too far buried in a single department to have inherent authority to convene around the project, is almost always a guaranteed failure.
One of the best projects I’ve worked in the past year had an internal lead whose Executive Director and Board members were helping carve out time to connect with staff internally who will be using Salesforce. This organization’s staff were engaged throughout the implementation, and management made it a priority for them to pay attention to what was happening on their behalf. Ultimately, come training day, there was a lot to learn but few surprises – because the internal lead had solid managerial backing, and the latitude to make an investment in Salesforce for the organization with the time and staff resources necessary to meet this demand.
Capacity building for Salesforce begins before ever calling in an implementation partner. It means assessing organizational readiness for technology change, identifying willing change actors internally, and planning out both with money and people how the implementation will be supported when it’s completed. There’s a great change matrix in this book.
Salesforce is “free like puppies” for a lot of organizations, but often the training, feeding, care and health of that free puppy isn’t fully considered.
This is simply a call-out to the fact that organizations adopting Salesforce must rise to meet the tool. Because only then can the decisions about how much project to sponsor and implement, which expectations will be met and unmet (or identified), and ultimately, how much Salesforce is actually configured, customized and established to “do anything,” that an organization wishes.
Also, capacity means understanding that by adopting Salesforce as a nonprofit, you’re joining a community – The Power of Us Hub is just the tip of the iceberg for connecting to other users, user groups, and events like Dreamforce. Give your organization the space to participate in this community, because it will become a vital ally in understanding the platform’s growth and best practices for nonprofits.
Lastly, implementing Salesforce so that it can do “anything” requires leadership: the outcome of the previous three items. Organizations leading with Salesforce are highly self-aware, have extraordinarily engaged sponsorship and management of their Salesforce instances, and have planned for the additional staff/monetary capacity changes effectively using Salesforce requires.
The person who leads your implementation internally carries both your organizational knowledge and the experience of developing Salesforce concurrently, and expecting them to return to their previous role when the implementation is done is also a mistake. And, if the facts and statistics hold true to women’s participation in the nonprofit sector (and certainly as the demographics of the recent NTEN conference continue to indicate), this will likely also be a woman – a topic near and dear to my own heart as a woman in IT. So by both investing in her capacity to grow with your organization, you will not only be serving your mission-critical needs for the long-term, but also helping bridge the divide of women’s leadership in nonprofits and IT. To use some jargon, it’s a win-win.