My nonprofit accidental techie moment lasted about a year and a half.

At a previous job, I suggested we move from using three Access databases and individual employees’ email programs and spreadsheets to a more robust, centralized, and informative cloud-based Constituent Relationship Management (CRM) system. As a development associate with previous experience working within a functional CRM, I knew how much more effective our entire organization would be if employees could access -- from anywhere -- a single system managing all our contacts with donors, vendors, volunteers, and grant makers.

Unfortunately, I was the less experienced accidental techie David Geilhufe referred to earlier this month. I had a pretty good handle on process modelling, but I glossed right over the critical change management aspect. Given the organization-wide scope of my proposed project, effective change management practices were key to the success of the project.

With the blessing of my supervisor, our development director, I charged forward, evaluating vendors and consultants before developing a plan for the system customization, implementation, and conversion.

What I neglected to concentrate on: making sure others in the organization understood the benefit of the new system, the reasons for the change, and -- perhaps most importantly -- that the executive director understood and bought into the concept of a CRM.

My oversight became striking apparent when my strongest leadership-level advocate, our development director, retired before the project was implemented. With him gone, I became the sole employee who had worked with a CRM and the only person in the organization working in development.

Without an executive-level champion or a program-oriented team member, the effort quickly became viewed as my pet project, one which would force unnecessary and painful change on the rest of the staff.

At the top level, the executive and program directors were dedicated to capturing information in silos of personal email address books, spreadsheets, notepads, even business card stacks, which they may or may not share in a central, accessible place. This type of system worked well enough for them to get their work done, and as a result, they simply didn’t set aside the time to be part of the process and learn about the new system.

The majority of the rest of the employees took their cue from the top. Despite my best efforts to involve my coworkers in the CRM customization -- and brief bursts of excitement when they saw what it could do -- the organizational standard had been set: centralized sharing of information wasn’t a priority.

Without the support of leadership, the project essentially dragged to a halt.

Beyond the general idea of the importance of executive buy-in here are some more specific lessons-learned for anyone looking to propose a transition to a CRM (or really, any big technology project):

• Cultural Change: Making the transition to a comprehensive CRM can take more than just moving the data if you're coming from an organization which stores data in simple databases or spreadsheets. You’ll likely also have to work on changing the culture of the organization to think more about working within the CRM system as part of their daily work rather than treating it as a back-end database where people enter information into as time allows. The more constituent interactions in the CRM from all organizational employees, the better your nonprofit will ultimately serve your constituents.
• Executive Buy-in: For everyone in the organization to make that culture shift, the interest in the transition has to come from the executive-level. Most people don't like change, and adapting to this sort of CRM system is a big change. If the people at the top of the organization don't fully understand the CRM they can’t adeptly promote the project, and you'll likely find the resistance from the rest of the staff.
• Strategic Planning: If your current data storage solution is somewhat complex, consider taking the transition in stages -- but make sure everyone understands the importance of moving toward the ultimate goal of having all of the data in one place instead of independent database/spreadsheet silos. If you’re starting with multiple databases, move the data from one which employees from various sectors use first and commit to moving the other, more specialized databases in the next phase in the not too distant future. After some of the staff start using and seeing the benefit of the constituent management features, they'll quickly become your best champions for why the rest of the information needs to be in one central location.

As painful as this process was, I learned a great deal and am now a stronger nonprofit techie, which serves me well in my new job. I hope you can learn from my fail: make leadership understanding and buy-in and effective change management priorities in your projects.

(And, in case you were wondering, the transition finally did happen. It only took 2 years.)

Have you lead this sort of ambitious project in your nonprofit? What lessons did you learn from the process?

Melissa Barber has called Oregon home for over half her life. She joined the Death with Dignity National Center team after ten years of volunteering and working with local nonprofits, with a two-year break serving as a Health Education volunteer with the Peace Corps in the West African nation of Mali. Prior to the Peace Corps, Melissa worked as the operations manager and in-house techie for Arcadia Investment Advisors. Throughout her career she has striven to find new ways to connect people, build community, and use technology to heighten the awareness of important causes like DDNC.