Before switching gears, let me recap what has transpired so far. We had our first planning session on January 12, 2016. The next three weeks we spent outlining the project and decided to work on the receiving end of things. In early February I started configuring in the Sandbox and within a couple of weeks the receiving and donations objects were ready for testing. I then promoted all of this to production at the beginning of March. Our collective intention was to have the volunteers start using Salesforce for receiving within a week or two.
That of course is when the volunteer coordinator raised the red flag and everything came to a grinding halt. The Executive Director, having been pushed pretty hard by me, the overzealous consultant, pulled the emergency brake handle.
Postmortem
Her concern at this point was that we were moving too fast without understanding the bigger picture. She was right, but it had to be done this way. Remember one of the cornerstones of success: momentum. The opposite of that is inertia, our worst enemy.
We essentially blew through all of this at tornado speed, and it was a bit stressful. We learned some important lessons. We also realized what we could accomplish. Our collective experience challenged some preconceived notions.
The truth is that nobody in the organization, even a small non-profit, really has a handle on all of the processes, lack of processes, variation in the way things are done, and, most important, what works and what doesn’t.
We took a couple of weeks to step back and reevaluate the scope of this project. It became clear that it was not as simple as replacing the existing piece of software – there were more interdependencies than we had imagined. All of these had to be addressed.
Reaching in and Reaching Out
This time of reflection fortunately spawned a renewed motivation to “get it right.” We began to pull in more staff and volunteers in the planning sessions, and documented how things really worked as opposed to how management thought they were supposed to work.
The staff took a field trip to evaluate systems at other non-profit agencies.
We determined, not surprisingly, that volunteers used some “artistic license” in their responsibilities. As with any busy, understaffed organization, orientation and training is not ideal and there is little time for follow-up and review of procedures.
Sharing the Load
Up to this point I had been asking all of the questions, documenting my perception of the needs and from that information alone configuring Salesforce. It was time to delegate some of the responsibilities.
It was early March when we began to look at the intake portion of the process. I continued to ask questions, but required the staff to document what they wanted for the intake form. This was a gradual process. First, I needed to teach them how to identify the process and subsequently translate this process into specifications.
Understanding Flow
As we embarked on documenting the intake process I volunteered to take the notes. Here is an excerpt from the notes I took during our first session.
It’s really important to keep the discussion dynamic. What I mean by this is all specifications must be taken in context of the actually workflow.
I began the conversation by telling a story.
“My name is Joe. I need some food. I tell this to the person at the front desk. So, what happens next?”
What generally happens at this point is an explanation of a seemingly convoluted process.
“Have you been in before?”
“Have you registered?”
“Do you have proof of residence?”
“Where do you live?”
“So, if you have been here before … if you haven’t … but you work in the area … or are homeless … qualify for commodities … we need to enter veteran status, income level …”
Okay. A little overwhelming. A lot of my confusion stemmed from the fact that their processes are based upon how the current software works. In other words, the processes were in part driven by the existing software, and not the other way around. There is no way that decent specifications can be created unless the process is detached from the software.
I bring up the Salesforce instance and display the household form. The first order of business is to determine what belongs on the household level versus the household member level.
Recall that I previously cleaned up the household page layout so that only a few fields are displayed. Again, this is by design. There is method to my madness.
Which Comes First?
This is a little counterintuitive, but the Nonprofit Starter Pack is designed to create the household from a new household member and not the other way around. Yes, you can create the household first, but it requires more steps.
If the household is left blank a new one is automatically created.
The opposite is true, by the way, for new contacts associated with existing households. It is much better to add new household members from the related list.
My point here is that we cannot start discussing workflow without an appreciation for how Salesforce is meant to be used. A seemingly small thing such as misunderstanding the relationship of households and household members will lead to a complete derailment of the design discussion.
In this case it was particularly important – the Salesforce approach did not match the current process, and without clarification we are comparing apples and oranges.