All things #nptech

13 Lessons On Building Your Nonprofit Technology Culture

This article originally appeared on the Exponent Partners blog on December 19th, 2014. It was written by Kerry Vineburg, based on a phone interview with me.

EXPONENT PARTNERS SERIES: SMART PRACTICES

Is your nonprofit thinking about implementing a large database project like Salesforce? Nonprofit and technology veteran Peter Campbell, CIO at Legal Services Corporation, recently shared his valuable insights on how to prepare your team and culture for long-term success. His organization, the top funder of civil legal aid for low-income Americans in the country, is developing Salesforce as a data warehouse for their grantee information and document management.

We asked Peter to tell us more about what practices he uses to help ensure a successful technology implementation. As you’ll see, it’s just as much about working with people!

Embarking On Your Project

1. When beginning a technology project, agree on the problem you’re solving, that all staff can relate to. Organizational readiness is critical. I’ve worked at organizations that didn’t recognize that their casual approach to data management was a problem, and they weren’t looking for a solution. If your staff don’t understand why they need an application, then you’re in danger of installing something that won’t be utilized. When starting a new organizational project, I identify 2-3 core bullet points that will explain the goals of the project, and repeat them often. For example: “The new system will provide one-step access to all information and documents related to a grantee.” That’s the high-level goal. It should be something where the product users all agree, “Yes, I need that!”

2. When planning technology upgrades and projects, schedule the changes. Plan for gradual change. Early in my career, I had to deal with the Y2K bug and replace every system at a mid-sized law firm in a short period. It led me to this philosophy: replace only one major system each year. It’s a myth that people hate change — people hate disruption. Change is good, but needs to be managed at steady level. If you’re doing regular implementations every year, people can get used to that pace. If you do nothing for 3 years, then switch out everything: 1) you’re putting too much of a burden on your implementers to achieve everything at once and 2) you’re making too big of an imposition on staff. Suddenly, everything they know is gone and replaced.

Getting Buy-In

3. Gain full executive sponsorship. There’s a common misconception that a new system will just work for you once it’s installed. To fully realize the benefits of a CRM requires cultural change. Every level of the organization needs to buy into the project. You’ll need to harness a lot of attention and energy from your team to develop requirements, manage the project, learn the new system and adapt processes. Otherwise, you’ll invest in a big database implementation and only one or two people will use it.

The importance of a major system upgrade should be set by the executive director and/or board. Everyone should know that the system is a priority. At nonprofits, our executive directors are often better at fundraising than managing a business, and many are somewhat technophobic. They don’t need to be technology gurus, but they do need to understand what the technology should be doing for them, and to take ownership of those goals. The last thing that I want to hear from my boss is, “Here’s a budget — go do what you think is best.” Without their interest in my projects, I’m bound to fail.

4. If one buy-in approach needs help, try a combo. If you can’t convince your executive director or other leadership to be regular active participants, power users can sometimes help convince your team. I’m not recommending an either/or approach, there should be some of both, but power users can engage staff in cases where management isn’t setting clear expectations. For any project that impacts staff, I will invite key users to be on our evaluation team, help with product selection, and potentially be on our advisory committee during the project. For example, we have a grants department liaison, who is charged with getting the right people in the room when we need input from the staff that know much better than we do what the system should ultimately do for them.

5. Incorporate perspectives from around the table. In addition to power users, I also want feedback from “standard” users. Maybe they don’t love technology so much, and maybe they wouldn’t volunteer for this. But they have an important perspective: you need to understand their reactions and what they’re going to find difficult. As the IT director and CIO, I know important things about managing a project. The users know important things that I don’t. If we don’t have views from multiple sides of the table, the project will fail.

Working With Good People

6. Look for partners (vendors and consultants) who understand your mission, not just the technology. In the ideal situation, you want people who not only get database and programming work, but also really understand your mission and business priorities. I’m blessed to have developers on my team who not only understand grants management but are also sympathetic to what the people coming to them are trying to accomplish. When they get a request, they can prioritize with a good understanding of our organization’s requirements. They’re able to answer, “How can I make the most out of what this person needs with my available time?” while being skilled enough to capably choose between the technical options. Getting people that have a broader mindset than just technology is really important.

7. Vary your team and role strategy with your size. At nonprofits, we don’t usually have big internal teams. Someone becomes our accidental techie/database guru. Even large nonprofits are hurting for staff. It’s always been less “here’s the best practice and ideal way to staff this,” and more “let’s see what budget and people I have, and make it work as well as I can.” Not many nonprofits have developers on staff. Hiring can be challenging. It’s a popular skillset, and won’t be cheap. If you’re tiny, you probably won’t hire full-time, you’ll outsource to consultants. But if you have 30 people or more using the CRM, you might benefit from in-house expertise, even if it’s a half-time role.

If you already have developers on staff, that’s great. If they don’t have experience with, say, Salesforce, but they do know database design and a programming language or two, it’s not hard to pick up the concepts. You’re modeling a database, designing it, and then scripting on top of it in a similar language. They can probably adapt.

8. Practice good compensation and retention strategies for your technically savvy (and/or newly trained) staff. I’ve seen a trend over the past 10 years. A nonprofit decides to use a solution like Salesforce and they charge their accidental techie with the task of implementing. The accidental techie gets the implementation done, becomes a guru on it, trains all the users, and then because the organization is paying them an entry-level salary, they leave and go get a much higher paying job as a consultant! It’s a valuable skillset, so don’t be short-sighted about compensating them for what they do for you. You need to be careful and invest properly. Give them raises along with the skillset, to make sure they are fully motivated to stick with you.

Project Management

9. Avoid surprises with good communication. My rule of IT management now is: “No one should ever be surprised by anything I do.” From experience with good mentors, I learned important lessons about communication: if you’re going to make a change, communication is critical. Say it 3 times in 3 different mediums (in email, on the internet, on flyers on the wall on every floor!). Be sure staff know how the technology contributes to the well-being of the organization, rather than being a time-waster, so they are motivated to keep working with it. Communicate well.

10. If possible, hold out for the right team. I put off projects to have the right people in place, rather than hold tight to a project deadline with the wrong people in place. See above for how to find and keep the right people.

Training and Baking The Technology Into Your Culture

11. Don’t reinvent the wheel; take advantage of the ecosystem. It can be really common for staff not to reach out for help. They may feel like their job is to learn the technology on their own. They should know there are many resources available to them! For example, with Salesforce, I recommend making use of peer support in the community, the Power of Us Hub, and local user groups. When they do seasonal updates, they do a lot of webinars and are good about providing information about how the app is growing. Salesforce also offers training (the Salesforce Foundation discounts by half) and every consultant I’ve spoken with is capable of doing some customized training. I know that other technologies offer resources like this also. It also behooves anybody on staff to know the specific implementation that you’ve done.

12. Allocate a training budget. I always push to have a staff training budget. For my organization, we even hired for a role of training and implementation specialist. We wanted to have a person on staff whose full-time job was training and strategizing how users use software and how to involve them in the implementation process. This should be part of your budget. I can’t emphasize enough how important it is to have people in your organization who know how to train on your applications.

13. Engage staff and help them understand the big picture of the technology. It’s good to get your team working with the database early on in the process, learning what it’s capable of and what it looks like. Engage your users: get people involved in every step of the process, from selecting products to implementation to training and rollout. Make the product demos big group activities, so that everyone can envision how similar systems work and what they might do with the product beyond what they’re doing today. Beta-test your implementations, giving staff lots of opportunities to provide input. Take an Agile approach of regularly showing what you’re developing to the people who will be using it, and adjusting your development per their feedback.

With a committed team that understands your mission, great communication, well-allocated resources, and gradual change, your organization can lay the foundations for a successful solution that will actually be adopted!

Thanks to Peter Campbell for these great insights. Peter also blogs at techcafeteria.com.