Ugly Salesforce Babies

Nobody ever intends for Salesforce deployments to go awry. Much like a parent, you anticipate the launch with hope and expectation. You really, really want it go all go well. After all the months of planning, designing, testing and building, all you hope for is that your beautiful database baby will be well-received and that it will make everyone's life easier. 

But, as any parent will tell you, the hard work starts once the baby is out of the box, so to speak.

Unlike the angelic database baby that you had envisioned--you know, the one who sleeps through the night and hums along with nary a hitch--your database baby throws tantrums, vomits up the wrong data and doesn't look that pretty. You compare notes with other people: does yours do this? Is mine normal or the Rosemary's Baby of databases?

In truth, it is much more common for people to be a little bit unhappy after a Salesforce deployment than to be blissfully contented. The difference is bad unhappy versus acceptable unhappy.

Bad Unhappy: The Wrong Developer

To push this baby analogy a little bit further, it all starts with inception. You want to choose a developer partner who understands your needs and can communicate well. Does your developer speak English or "tech"? Are do they agree with you on all your points (red flag here: you don't want a Yes person--you want them to use their technical knowledge to guide you against making silly architecture and collection mistakes). On the other hand, do they oppose you at every turn? What to they think the role of technology plays with respect to the very human work of nonprofits (i.e. do they want to automate everything or do that technology should be used to enhance work processes and free up time for the human work of relationship building)? Do they understand the unique needs of your business? Do they think that you should alter your work process to fit into a tech design or do they believe that tech can be changed to fit the way you work? Do they talk about the data or is it about the technology for them? Does your developer see you as a partner who wants to work with you or will they go into their magical database cave and come out weeks later with a deployment that you've never seen before?

These are the considerations that really set apart the best from the rest.

Bad Unhappy: Bad migration

This speaks to the technical skills of your developer, but if you are migrating out of a legacy system or spreadsheets, it is imperative that someone (your developer or your staff) take the time to painstakingly ensure that all the records match up with all the donations, funds and campaigns. You should also run a de-duping process upon upload. This is quite literally your bread and butter. Don't mess around here.

Acceptable unhappy: Grumbling about data collection

Assuming that you need to change some of the data collection processes for your team, you will hear some grumbling. First, people don't really like change as a general rule and learning a new way of doing things is always annoying. Second, data entry is not fun. I just recently spoke with a very wise woman who does evaluation for a large nonprofit agency and her tip was to tie your staff's ability to do their job to the data. Otherwise, it becomes a slippery slope and people will start to input data "when they have time." Which really means never.

Bad unhappy/acceptable unhappy: Bugs

Nobody likes bugs. Ok, maybe entomologists like bugs. Inevitably, there will be bugs in your system. There is an important distinction to be made here: acceptable bugs are ones that are mildly annoying but can be managed and dealt with. Critically bad--I'm talking bedbug infestation level here--are ones in which work grinds to a halt and your database is hanging halfway out the window threatening to jump. In either case, you should have some support contract with your developer who should be able to address the issue. However, too many critically bad bugs could be a problem (also: see point number one).

There might be some of you out there reading this and thinking: oh no, my database baby is beyond the pale. I'm doomed! I have the bad apple. I have the stinky, antisocial database baby who doesn't know how to make friends.

Do not despair and do not abandon hope. This situation can be altered and it can be some relatively simple fixes or it might be a total overhaul. In either case, I would recommend contacting reputable developers and doing a discovery process which lays out the fix. In either case, you are not stuck with an ugly database baby. With the right support, it can grow out of it. Fix it sooner rather than later before your poor users run screaming for the hills! But, once fixed, it's up to you to keep it alive and healthy. 

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]