Nonprofit database implementation: what most firms still gets wrong (and how to fix it).
Teach first. Teach continuously. And for the love of everything do not ask your client to fill out a spreadsheet template for a data migration unless you hold their hand every step of the way.
The Parable of the Client
I want you to imagine that someone — let’s say your boss — has declared that you are moving to a foreign country in four weeks. And you’ll have a few people around to help you with the move. And don’t worry that you don’t speak the language, that’ll all get sorted out when you get there.
Keep imagining that you don’t immediately look for another job.
You’re introduced to John, your project manager for the move. John gives you a timeline that is mostly written in the language of the country you’re moving to. You have to ask John to translate, which he sort of does. Your timeline, it seems, includes buying a house, packing up and shipping your belongings, and unpacking them in your house.
You ask about the culture in your new country, the food, and the location of the house. You want to know whether you’ll need a car or bike. You are understandably concerned about selling your existing house and car because you clearly can’t take those with you. You also start to wonder about whether you’ll need adapters for all your electronics or if you just buy new ones there.
John tells you the location is convenient, the food is filling, and the rest of the questions will either be answered when you arrive and are given a week of language instruction, or are out of scope. But he’ll ask Jane (your move specialist) about the adapters.
Jane is from the country you’re moving to. She has never needed adapters in her country. She struggles to answer your questions, but seems nice enough.
John and Jane give you a template — also written in the language of the country you’re moving to — and ask that you inventory all of your belongings. If you miss any belongings, they won’t get moved and you’ll bear the cost of replacing them. You aren’t sure what you need to take, so you try to ask Jane and John. They give a few obvious examples, like your clothes and toothbrush, but can’t answer any questions about dishes or electronics or furniture. It’s entirely your responsibility. You have 3 days to fill out the spreadsheet.
It takes you more than 3 days to fill out the spreadsheet. John’s role now seems to be to nag you to fill out the spreadsheet and includes being very grumpy that you’re late on filling out the spreadsheet. Your blood pressure is up and you are stressed beyond belief. Your spouse is begging you to quit this stupid job…but this is a parable, so you don’t.
Once you have completed the spreadsheet of your belongings, Jane asks you to provide detailed instructions on where those belongings go in your new house. Your new house you’ve never set foot in. Your new house you might have seen some photos of once at the start of the project and haven’t really seen since.
To help, Jane gives you a floor plan of your new place, with all of the rooms labeled in the new language. You are told not to worry too much about it, since you’ll get a week of language instruction after you move.
Technology firms do this to clients all. the. time. and it’s horrible.
Enterprise technology firms seem to focus on doing the move, and anything else is somebody else’s problem. The people doing these moves know how to execute on the steps of the move — they are experts in that part of the work. To them, these steps are no big deal.
A migration or implementation is, at best, annoying and disruptive to the client. Usually it’s annoying, disruptive, intensely time consuming, expensive, and very, very frightening. Your software might be “intuitive,” but it isn’t intuitive to the client yet. They’ve never done this before.
I have lost count of the number of rescue projects I’ve been dragged into, either right at the end of an implementation or after an implementation left everybody unhappy. Nearly all from brand name firms — or worse, volunteers from for-profit firms — that think an implementation is about technology. They do exactly what “John” does in the parable — give a timeline, talk about what’s in or out of scope, and fob off detailed questions to “Jane” who has only technical answers to provide.
Those implementations are almost never problematic where the tech is concerned, but they typically leave a big mess in their wake where humans, data, and business processes are concerned. I think this is allowed to continue because you can’t deny that the technical piece is correct, and everything else is somebody else’s problem. You didn’t know you needed training and process consulting and change management? Well, that’s your fault.
“Assume” — it make an ass out of you and me
I have worked with many folks at these firms who are very skilled and competent. Empathetic. Caring. Wanting very badly to make a difference. They could be in other places, but they choose to spend their time making less money in the nonprofit sector.
So why are so many tech projects so like our parable? I think that it’s because most consulting firms in our space are modeled directly on consulting firms from corporate and industry, or are just arms of corporate-focused firms.
Industry consulting is based on an assumption set that is simply not true in the nonprofit space. These assumptions can be boiled down to:
- The buyer has the technical expertise to make a well-informed decision about the chosen product.
- The buyer has the staffing and skillset to be able to absorb the business process, training, and change issues that are part of every tech project.
- The buyer knows that they must plan for and budget for business process, training, and change management to accompany a tech project.
- The buyer is staffed and has budgeted to absorb all of the risks related to a change of this magnitude, and is hiring the technology firm solely to provide the niche technology expertise that the buyer lacks in-house.
None of this applies to the majority of nonprofits. There are a whole host of reasons this doesn’t apply and if you’re really curious you can read all about operational capacity, operational maturity, and the nonprofit starvation cycle.
Fine. It sucks. How do we fix it?
I was talking with a colleague about how to fix all of this. This colleague is in one of the firms I’m railing against, so I can’t name names.
Literally nobody wants it to be like this — not the clients, not the firms, and not even me. If I never rescued another implementation again my life would be phenomenally good.
A big part of the solution, I think, is actually really easy to shift into.
First, we make nonprofit-appropriate assumptions when we structure our project plans. We assume that, in the nonprofit space:
- The client does not and cannot be expected to have in-house the expertise and resources to handle the corresponding change management, training, and long-tail support that goes along with a major tech implementation.
- This is likely to be the biggest, most disruptive, and riskiest thing the client has taken on in a long time. They’re putting a lot of trust entirely in an outside firm, so a partnership approach is more warranted than a niche-tech-skills approach.
- Just because they chose your solution doesn’t mean they have any practical idea of what it does or how it applies to their use cases.
Nonprofit folks are entrepreneurial, energetic, inventive, willing to do whatever is needed to make the project work, and willing to adapt. But they don’t have enough information to do those things based only on sales materials, a single orientation, and a training that comes after the important decisions.
The answer is to teach continuously throughout the project.
Teach them before asking them to prepare any data. Teach them while they’re preparing their data. Teach them after you have migrated their data. Teach them during the sales process that they need teaching as part of the implementation. Teach them during weekly meetings by hearing their questions and showing them or letting them get hands on.
Adults learn by repeated exposure to a new system, stretched over time and illustrated through multiple real-world use cases. A single training sets the context but is insufficient to let people apply that to their own situation.
Training is not teaching. Training is more generalized, more structured, more “the decision has been made.” Offer a training FIRST before the project starts, to orient people to their real future lives. Offer a training LAST, with the manual updated to the specifics of the client’s implementation if needed, to re-enforce the final decisions made during implementation.
Teaching comes in the middle, and teaching adults is really all about translating. The teacher on a project like this should be someone who has mastered the solution (is a resident of the destination country, from our parable) who also has mastered the content that the solution supports. If you are implementing an accounting system, the teacher should know the technical system inside and out and also know accounting as a practitioner, so that when the client asks about a specific accounting question, the teacher can hear, understand, and translate for the student into the new system.
Hire project managers and incentivize them to teach and translate, so the client understands why the scope is what it is.
Or just hire teachers and work the teaching into the project budget. Whatever it takes to actually support the client through the process.
That’s it. That’s all it takes. Empathy for the gap between a technology solution and the knowledge of the people who have never used that technology before, and a willingness to support those folks in bridging that gap. We have plenty of this in the nonprofit tech sector, but we still haven’t made that pivot to fix the way we do projects. With so much demand for technology projects in our sector, the time is now to change how we do things, and to change for the better.
A word to clients
If you’re reading this and recognizing your project, advocate to your consulting firm to incorporate more teaching — not training — into the work.
And if you’re reading this and thinking “I just need to find a technology to fix my current situation, and a migration shouldn’t be as hard as you’re making it out to be” I would encourage you to reflect for a moment on all of the operations that technology supports. You cannot change technology without changing process. The most successful technology projects are partnerships between the client and the consulting firm, and that takes time and energy. Take a moment and see if there’s room in your organization for the change management and process evaluation that is required for a successful technology migration before embarking on one, and you will be more likely to succeed with whatever path you choose.
My firm (Deep Why Design) specializes in weird use cases and things nobody else wants to touch — from big and innovative shared platforms and custom apps to teaching accidental admins how to get the most out of their systems. My areas of expertise are fire jumping and forensics — call when there’s an unsolvable problem — and the design and management of large, integrated, and complex data systems in highly constrained situations.
