Burn the ships: The Six P's of Salesforce Implementation

So, we did it. We sorted through the proposals and chose a developer to build out our Salesforce. Now came the hard part--actually building it. It's exactly like being on a diet--it's not fun while you're doing it, but you'll like the results.

Here are some of the lessons I learned along the way:

1) Paint a compelling picture

Before we could even begin, we had to do some internal marketing among the staff to make the case for why we needed to go through this process. Emphasize the pain points and demonstrate that LIFE CAN BE BETTER. Make them long for the sea. Or, in this case, long for a future where they are not futzing around with spreadsheets and can actually get a 360 degree view of constituents. Imagine a world where you could pull up a student contact record and see all of the interactions and relevant data on them from the time they applied to the program to current day. Imagine a world where we could track all of our communication with them: emails, SMS, phone calls. Imagine a world where we could see our donors, their giving history, their capacity and make some strategic decisions about how to move them forward. Imagine it all...

If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. --Antoine de Saint-Exupery

2) Plan!

This was admittedly a mistake on our part. We were so eager beaver to begin, I think we didn't put enough into the pre-planning which led us down some rabbitholes while we were designing. If you have the time and budget, I would recommend putting some time and resources behind a robust discovery process. In fact, if I had my druthers, I would have done a full technological audit before starting the work. It would have helped, especially with board buy-in, and ultimately would have saved us some money by avoiding spinning our wheels during the design process with the hourly consultants. Hindsight is 20/20, I suppose. One other note about planning: decide really early on "Who Has the D." In other words, very clearly spell out the different roles that people play in the decision-making (for more on this, check out the Harvard Business Review article Who has the D?") Conflict comes when people are unclear on who holds decision-making. I know nonprofit folks like to have consensus and everyone holding hands and singing kumbaya, but those people are just masking their simmering resentment and passive aggressiveness under a gritted smile. Don't be those people--make clear decisions.

3) People power

During the design process, we involved key people in the discussion and decision-making. To be clear, too many cooks in the kitchen can ruin the process. Strategically involving key staff members in design and input made them feel invested in the platform and ultimately got us a better product. When thinking about your team, don't just pick the heads of the departments. Think about the "owners" of data--the folks who will have to input and who live with the front line data every day. We only know what we know about what we do and it would be a mistake to not include critical "on the ground" folks who are experiencing the most acute pain points. At the end of the day, you could build the most beautiful system in the world but if your people are not entering data into it, then it's just an expensive thought experiment.

4) Process

Ok, I'll admit it. I'm not a process person by nature so I rely on others to shore it up. As you're building the system, think about the processes by which people will have to input and manage the data. Let's admit that data entry is a huge pain the...neck. But, it's critical. So, learn from our mistake, and design a data entry schedule that everyone lives by and is trained on. Write it down, codify it, train new staff on it, retrain old staff. It's said that it takes about two years for adoption so be patient but persistent. A couple of things that we introduced was setting aside time every week for the whole team to input data and tying data entry and cleanliness to yearly compensation. Bring in cupcakes, and/or make people walk the plank. It's all about carrots and sticks, folks.

5) Persist in training

The reality of nonprofit life is that staff turns over. And current staff forgets. And people communicate different things. Do yourself a favor and implement a robust training model for new users and old users who need to be reminded. And please, I beg of you, don't create another binder. Real talk: nobody reads it. Instead, consider online videos, in person trainings and continue to help people build their skills once they start using Salesforce. Make Salesforce training a key piece of your onboarding process. Remember, nobody likes dirty data. Or nonexistent data. Keep the data gods happy by training your people.

6) Pull the plug

Once your system is up and running, everyone is trained and all your data is imported, it's time. Time to pull the plug and have a funeral for all of the spreadsheets and legacy systems. This must be done to force change. I stood over one of my staff members as she deleted Google spreadsheets. Have a farewell party, buy cake and celebrate moving on from living in the old, data-less, disorganized past.

Goodbye spreadsheets, hello future! 

Burn the ships--there is no going back.

Rhea Wong was Executive Director of Breakthrough New York for 12 years and grew the organization from a $200K per year budget to just $3M per year. She can be reached at [email protected]