Hi, everyone, welcome. We're going to get started here in just a minute. All right. As people join in. I'm just going to go ahead and get started with a few housekeeping notes I'm cases director of online education Christy Graham I'm delighted to welcome you to this webinar, getting out of spreadsheets, how to rally your toll team around a big tech change. I want to thank our presenting sponsor I way for making this webinar possible. Before we get started I just have a couple of housekeeping notes, this webinar will be recorded and available to all registrants following the session. For those of you who would like to follow along with the slides the slides are available to download now from the content tab on the event page where you found your link to join. I'll pop that link into the chat in just a moment as well. We will be taking questions at the end so use the q amp a box to send in your questions, and with that I'm going to hand it over to our presenters Michelle Paul and Kristen by rice. Awesome. Thank you so much, Chrissy. I see the number still ticking up as we go as people join in. So don't worry we'll just do introductions here at the start so you don't miss anything. I am Michelle Paul, I am VP of growth strategy at back office thinking, and we are here today to, like Chrissy said, present to you a session about how to rally your team around a big tech change. Big tech change is kind of what we do at back office thinking I've got some slides about that which we'll get to in a second. My own background is that I have been working at this intersection between nonprofits and technology for my entire career. I've spent the last 15 years working specifically focused on arts and culture nonprofit organizations, helping folks with ticketing and marketing and CRM and things like that. But basically, overall this idea of nonprofits need to use tech tools to do your jobs, and that can be hard, and how can we figure out how to make that easier. So with that, I'm going to turn it over to Chrissy. Chrissy, who is our marketing manager here at back office thinking. Hi Chrissy. Hi, hey everybody I'm Chrissy Byrice, marketing manager at back office thinking, and I come from a marketing background I've been an early adopter of almost every marketing technology I could get my hands on from the very beginning. I love technology and enjoy getting into it and learning new things. I also have volunteered at a lot of nonprofits over the last seven to eight years and then I've also worked in nonprofit and program coordination volunteer coordination and organizing and I volunteer with several nonprofits, as well, everything from political or political issues to faith community to local organizations that do voter advocacy. So, I'm happy to be here and thanks for having us. Kristen also happens to be an actor and we're going to put some of that to the test today, although not really because what you'll be playing is the role of basically volunteer managers and program managers at a nonprofit. So with that I'm going to share my screen, and we can get started for real. So hello. As we said, we are Michelle and Kristen. Back office thinking is a technology consulting firm that works specifically with nonprofit organizations. Here's a quick glimpse at some of the clients that we've worked with recently. And while our entire mission statement is that we focus on your technology so that you can focus on your mission. That is both the point of our company and also kind of the point of our presentation today. We build websites, we implement CRMs, we develop system integrations, we provide ongoing support. And a big part of what we do and really my favorite part is helping organizations step back and assess their tech situation and identify solutions. We've had relationships with lots and lots of different tech companies I put some of their logos on the screen here, most notably iWave who is the sponsor of today's session and is the kind of reason that this whole thing came together why we are the ones talking to you today. We've worked with iWave in a bunch couple different capacities we've got clients that use their tool for getting fundraising insights, as well as actually build the literal technology integrations between iWave and some other systems. So that's the background that's what we do as a company that's not what we're here to talk to you about except for actually this assessment and strategy part, but it's the thing that drives all of the examples that we're going to talk through today and what happens when we do these technology projects with nonprofits, we see the same things coming up over and over again I'm pretty much assuming that they're going to be familiar to all of you. And so that's what we're drawing on and kind of putting together the session that we've got for you today. So a quick look at what to expect in the next hour. We're going to start with an overview of the steps of making a big tech change at a nonprofit organization. So keep those steps in mind, as we share some examples of how this actually tends to play out at nonprofits. And then we'll close by summarizing some specific tips, takeaways, or at least good questions for you to keep in mind to guide your own project, whatever that may be. So, work with many nonprofits. So, we know the general shape of the work that you are probably doing right and that can be organizations anywhere from arts and culture to kind of more health human human services based organizations to higher ed institutions and other institutions like that but you know you're trying to fundraise in order to actually make money to continue to keep your programs going. Right. So you're managing all that you're managing those relationships, donor engagement, communications, actual programs, all of those different things coming together. So, all of the work that you and your colleagues do in the service of your mission is the important stuff. That's the stuff that you should be able to focus on. The stuff on the right side of the screen here, right, like cool we're actually doing some work. The stuff on the left side of the screen, which is what this can feel like sometimes, right. Our idea of the connected nonprofit is one that is working towards removing its technological obstacles that cause distractions or confusion, so that all the disparate organizations can operate together and complement one another. So, obviously I'm kind of joking with the old floppy disk compiles here. But as a metaphor, it is definitely where a lot of organizations end up feeling like they are right it's like we've got all these tools. They're supposed to be helping us. They're kind of just getting in the way, we don't even really necessarily know what's wrong. We just know that something needs to change. So, how you work towards that removing your technological obstacles, that's the subject of today's session. So, we wanted to start with a framework for thinking about the steps of this process, when we talk about a tech change, right. So, starting at the beginning with symptoms. Obviously, a tech change comes about because somebody has noticed that something is wrong. Right, you're experiencing some kind of challenges or pain points as an organization. You move from there to the diagnosis. Okay, we know there's a problem. We know what the problem is, maybe. Now we need to identify what is causing the issue, so that we can figure out what needs to change. And then from there, we move to a prescription. Right, we know what needs to change. What does it need to change to? What's the actual solution that we're aiming towards? Once that's identified, then comes the work of actually implementing the change. And then, stepping back to actually review the results, measure your success, make sure you've got where you thought you were going, and then continue to iterate. Because usually it all starts again at that point. What we find most of the time is that once you have made a change and you get to a new place, that is great. You have probably uncovered a new set of problems in the process. So you get to loop back around to the beginning and start over. So I'm going to pause here to touch on all of these steps. So we wanted to pause there for a second. Because you signed up for the session. Presumably, you're somewhere in the midst of considering or enacting a tech change at your organization. So give us an idea, where would you say that you are right now in this process? Are you trying to figure out how to solve what's wrong? Or are you actually in the middle of switching systems or kind of seeing where you are again to start over? I think it's time to click the button in your fall. All right, let's take a look at the results. I think you can all see this on your screen, right? A pretty even mix. Mostly, they're kind of in the middle. You guys are saying you're in this prescription or action stage of the process. But really, we've got answers all along the entire continuum. Excellent. Great, because we're going to talk about all of it. Not necessarily all in equal measure, but definitely touching on all of the different pieces of this with both some examples and some specific tips for what to do about it. So let's dive right in. Let's take a closer look at how this actually happens in real life by demonstrating some examples. So here's our first story, starting at the very beginning. Once upon a time, a small nonprofit had tools that worked well. Time passed. The nonprofit grew, and it wasn't so small anymore. Those tools didn't work so well anymore for a variety of reasons, and they find that they needed to make a change. Very straightforward. This pretty much could be the example of half the clients that we work with all of the time, right? So they knew that they needed to start at the beginning with identifying their symptoms. So they set out to interview the staff about their challenges and pain points. We're going to recreate one of those conversations as it might have happened. And we're going to let you look at our faces while we do it, because that's more interesting than staring at a slide. Hi, Kristen. Hey, Michelle. So I'm here to interview you and figure out what's going on and figure out what your challenges and pain points are. Tell me about your role at the organization and what tools you use to do your job and what's working or not working today. So I'm the new volunteer coordinator helping to run our volunteer program. Our volunteers work in shifts at the center and for seven fundraisers, including our gala, every year. When I started, they had just implemented a new tech system for volunteer management. So it's wonderful. It's great. I love it. The system makes it easy for me to track sign-ups and communicate with volunteers. I can do my newsletter and everything right there in that system. But they hired me with the specific goal of getting more volunteers to also become donors, which means I need to know which of my volunteers are not yet donors so that I can nurture those relationships in that direction. So I basically just want to make sure that I got kind of what you said so far. So you're using a new tech tool for managing volunteers, and it sounds like you love it, which is great. It's not a thing that I hear very often. But that there's this element of your number one specific goal in your job is you got to figure out this connection between donors and volunteers, or like this kind of journey of you want volunteers to become donors, right? So that's what you're about to tell me about. OK, cool. Exactly. So how does that work today? Yeah, so what I do to keep track of which volunteers are donors or not is I run a report of new volunteers every week. And I send those in to my director via a shared spreadsheet. So we have one that's a running list of all the volunteers that we have, and I add in the new ones. And I export from my system all the new volunteers, throw it in the shared spreadsheet, and send that over to the development director. She then runs a report of new donors from her donor management system, eventually updates those spreadsheets and lets me know when it's updated and ready for me to take a look at. So I use that combined list for tracking how many volunteers become donors, banking them when they volunteer. And so next time I see them, I'm like, hey, thanks for the donation that you gave, and continuing to build the relationships with those who are not yet donors that we know of. So now I don't even bother putting that information back into the volunteer system. I just update that shared spreadsheet that we have every week, which is our main source of truth. So I know when I see my volunteers, what's happening that week and who has and who has not donated yet. So you're like running your whole, half of your job out of this spreadsheet, it sounds like, right? Yes, correct. Okay, and how's that going for you? So, I mean, while it's a good source of truth for us, it's also extremely frustrating because I always have to wait to get the info, information that I need each week. So for example, it happens very often that our development director is working on a grant. And so when she gets delayed on the grant, it's too much for her to take this on. So I may have to skip a week of getting that information. And I could end up going into a large fundraiser without knowing who my donors are and who are not. I could have a large pool of volunteers to connect with and not know which direction I need to go and who I need to pay attention to. So it's my job to do this, but I can't thank people or nurture those relationships when I don't have the most up-to-date information. Awesome, okay, well, not awesome, but thank you for letting me know, Kristen. Right. So let's switch back over here for one quick second, because we're gonna have another poll for everybody. So just to summarize what we just talked about, right? So we've got this volunteer system that's great for managing volunteers. That sounds good. Kristen's job requires information from another team system. Right now, the teams are using a shared spreadsheet to collaborate on all of that. And it's frustrating because the process takes a lot of time and the bottlenecks cause problems. So our question for you is based on this conversation that just happened. What happens next? Should the organization build a custom integration between these two systems? Should the organization add some custom fields to the volunteer system to kind of try to eliminate that spreadsheet? Should they replace both of the systems with some other all-in-one tool? Or is there some other next step that should happen? Such suspense, this is great. It really is. I love it. I love it. Okay, we have the answers. All right. So out of, it looks like 59 people who clicked the button, which by the way, thank you for clicking these buttons. This is exactly what we're here for is to keep this interactive. We've got a winner, which is replace both systems with an all-in-one tool. We've got a tie for second place about building a custom integration to sync stuff between them or just adding some custom fields to the volunteer system to capture some donor info. And one person said something else. That one person perhaps is probably the person who's gonna win our prize. So hold that thought. Let's continue this conversation. Oh. Here's what actually just happened. Where we're at in this process right now is we're looking for our symptoms, right? That was an interview about finding the pain points and finding the challenges. All of those answers that we just gave are pretty much prescriptions, right? We've jumped to, oh, we should do an integration. We should add some fields. We should replace these with an all-in-one system. We actually don't have enough information to get there yet, right? So don't skip this step. This is the thing. This is where people go wrong all the time. Before we go ahead and try to decide what the answer is there, the actual something else is let's continue that interview and ask some more questions and see what else we can learn. So hello again, Kristen. It's nice to see you. Can you say more about that spreadsheet now, right? So we identified the title of the session that I went to, this webinar, this great webinar presented by these people from Backoffice Thinking. They told me they did a whole session called Getting Out of Spreadsheets that that was like the goal of a tech change. So tell me more. Let's talk about the spreadsheet. Why does that step exist in your process? It exists because I'm the only one who uses the volunteer system. So the development director wouldn't actually have access to it directly. Okay, and so why don't you just log into the donation system directly to get that info you need about whether your people are in there or whether they're donors or not? Yeah, you know, when I started this position, they said, I asked that question and they said that it would cost them more to add me as a user to that system. So they weren't willing to do that. Okay, but it wasn't an issue of, they didn't say that like, they didn't want you to know that information. You're getting that information anyway because someone's giving it to you, right? If you had to log into that system, you could pretty much handle all this whole process yourself and you wouldn't be stuck waiting for the person that's kind of causing your bottleneck here. Yes, that would be a huge help. But I still might actually use the spreadsheet in that case because I don't know if I could capture that data directly in either one system or the other, but not waiting for the other person is definitely huge. That would save me all the time in the world and get me out there to be able to move people through to donor. So, and the spreadsheet isn't, you're not really complaining about the spreadsheet, right? You're complaining about the process, the waiting, about having to kind of get hung up by the fact that there's a grantee or whatever it is. Correct. That's super interesting. I think we just learned something new here. Thank you for sharing that information, Kristen. You're welcome. So, just to hammer this home for a second, the secret correct answer to our previous poll was indeed something else. And the something else is simply ask more questions. End of story. In the conversation we just had, we asked enough questions to get some more information that we were able to identify a much cheaper and faster solution than any of the ones that we had proposed in the poll. Whatever it was gonna cost to add the one user to the system that they had not wanted to do at the start, I 100% guarantee that that user license costs less than any of those other options that we just described. And it solves the problem, right? So, we dug in further. Not, you know, this original framework like I said, make sure that you're not skipping any steps. There's usually more steps to it than that, right? If we layer on a couple of more pieces of the process, we can look at the ways that you get from symptoms to diagnosis to prescription, right? Really investigating, like really, it's more than this service level conversation, right? Because the first pass through what people say is going on usually requires a little bit more poking and projecting. Requires a little bit more poking and prodding and understanding and kind of digging and to find the real diagnosis. And then from there, sure, yes, evaluate options. That's when you could maybe go actually put all those poll answers on the table and do the things that I'm kind of guessing and prescribing by heart, which is, hey, there's one that's much cheaper here and that actually would be the easiest path forward. So maybe we just do that, right? Sometimes that also involves pivoting, right? Sometimes that involves, maybe we did, maybe part of the reason that everyone, that's not to call you all out on this, right? But we did say that we were gonna be talking about making a tech change. So it's a little bit reasonable to have started from the point of, well, the tech needs to change. Being ready to pivot based on the information that you find, right? Being able to dig in and ask those questions and changing your mind and finding that there is an actual easier path can save you money and headaches and heartaches in the long run. So what we wanted to do next is sort of start over and then continue that story and actually look at some tools that you can use to do this work if you are not me and Kristen faking it for you. So once upon a time, a growing nonprofit set out to make some improvements. They investigated their current situation deeply. They identified the biggest problems and the easiest fixes and they came up with a prescription for change, hooray. Let's look at the tools that you can use to do this right. So this Venn diagram here is the thing that we come back to 100% of the time in our work at Backoffice Thinking. This is actually just another way of describing that first story. We call this kind of work, we call this kind of thinking, we're talking about a tech change, but it's more than that, right? When we're working with clients on a tech assessment, we're really evaluating people and process and technology and how all of those things are related to each other. The way that we do that, as you just saw, is to ask more questions. Really good rule of thumb, anytime somebody tells you X is the problem or I'm having this problem, ask them why. Why is it a problem? What is the actual impact? What is the thing that is bad about this? You might have to do this a number of times to actually drill down past sometimes the feelings or sometimes the kind of keywords, right? Again, spreadsheets was there on purpose in this example, because it's there in the title of the session. It's kind of really, it's an easy thing to latch onto of like, oh, we've got these spreadsheets. We can't be using spreadsheets all the time. Spreadsheets are bad. Spreadsheets are not inherently bad. Finding the thing that is wrong with the story that includes the spreadsheet was going to help you get to the diagnosis. It's going to help you understand the process and how the people are using it, not just the technology itself. And so far, I mean, spreadsheets counts as technology. Not a fancy system, but they get the job done. I once had a client where the organization had already invested in a pretty sophisticated CRM platform that did all the things. It should have been a massive success. But the leadership team was frustrated because they weren't seeing that success. Their staff couldn't seem to get results that were matching their expectations. The staff was basically insisting that the system was broken or confusing or too complicated. This came out in saying things like, oh, well, tool X can't integrate with the system, or the product doesn't have the features that we need, and so I don't actually use it. Or like, hey, I can't do the things that I need in either one of these systems, so I've got this whole spreadsheet about it. So it turned out, among other things, that the main person who was in charge of importing new records into the database was using a template, and it was the template that she had been given two years ago that hadn't been updated to accommodate new fields that they had started requiring on their registration system. So she didn't even know this because she was trained on the process. She was trained when she started of, cool, here's how we do this. We take this thing, we run this export, we use this sheet we imported in. She had no context for the premise or what was going on there. She just knew how to follow these exact steps. And so when this thing started breaking, she had resorted to just basically manually entering the data, spending all of her time taking stuff from the spreadsheet and retyping it into the database, which she also never told anybody about because nobody had ever asked. So picking on this one thread of, oh, the system's too complicated, oh, these things don't talk to each other, and pulling that out further to, OK, what is actually happening here? There's not really a tech thing in there at all. That's people not knowing what the process is supposed to do and so not updating their process accordingly with the tools that they're actually using. Once again, the solution there isn't, we need a new system, yet, necessarily. Maybe eventually we actually do get there. There is such a thing as a too robust CRM for the size of your organization. But that isn't the starting point. The starting point can simply be, we need a new process and we need to train people on exactly what it is to do. So a diagram like this one can be a great tool for both having and documenting those conversations with your team as you're digging in on people and process and technology. So just take a look at this. Let this sink in. Everything that's a cylinder or a square or an oval all are representing the actual systems themselves that this organization is using. And then every time there are people, that is some human at the organization often having some kind of manual intervention in working with the system or receiving data or giving data to somebody else or information or talking to somebody. And all of the arrows are basically the process, right? Where does data or information or other stuff flow between and amongst all of these different systems and all these different people? And we've got it kind of color coded too by department and by the public facing aspects of things, outside there with the public and the volunteers and things like that. And so drawing this out, again, not just saying, OK, here's all the systems that we use, but here's how we use those systems. Here's who's using those systems. This is just the visual representation of what I just described about having these conversations. Imagine Kristen is one of these six figures and the development director is another one, right? And where there's this spreadsheet sitting in between them that they're kind of passing back and forth to each other. Using this as the visualization, you can start to, it'll help you, again, like I said, guide those conversations with folks and know what to dig in and ask further. But it also starts to illustrate and kind of point you in a direction of like, OK, where is it the messiest? Where are the most places that things are kind of, lines are crossing over each other and you've got all these colors interspersed? When are there lots and lots of people in the process? When are there lots and lots of multi-directional dotted lines in the process, right? When you do all of this, you can use that diagram as a starting point to then draft up, that's the before, here's the after. Maybe even print out all of those pieces and get fun with it, like put them up on a, like, I want someone to take these and turn them into magnets and put them up on a board and actually move them all around, right? Hey team, where are you in this situation, right? So you do all of that and you come up with some version of after. This isn't just an example from this particular organization that we worked with, not necessarily saying that it's like the right answer for everyone in this situation. But the goal should be, there's still plenty of people here, there's still plenty of lines and arrows, but they're much more intentional now, they're much more organized. There's this sense that there's intention behind it, some thought, right? Aiming to have fewer places with manual intervention that could be replaced with, let the robots do the work for you. And really kind of specifying the places where people do need to talk to each other, where people do need to interact. You don't need, I'll also mention, you can re kind of create this after image and you don't have to actually know the names of your new systems yet, right? We're still kind of maybe in diagnosis land, not specific prescription. You can identify the places where it might be okay to have some manual processes. It might be okay to keep a spreadsheet in the mix or something like that versus finding the boxes in here where you're like, okay, actually, if we had, in this example, a single CRM that could serve as the hub for all of this stuff, it would really cut down on all of those lines crossing each other. Or if we actually did have a marketing system and a development system that could at least interact in this one way, we could cut out some of the moving things around, right? You don't necessarily have to know, oh, and this is exactly the right tool yet, but you're kind of stepping your way there. Because then, once you know, once you've identified the systems that you actually do need to change or add, you can start defining your requirements. We could spend probably another two-hour session just about this, so I'm gonna cut myself short here. But the key is to think about the level of granular detail, thinking about basically for every row, is this actually one requirement or is this like five requirements in a trench coat all piled on top of each other that you actually need to kind of pick apart? And then within that, okay, what is the actual priority level? Column D in the example on the screen. Calls out to me a little bit because that's a whole lot of required and not a lot of optional. Not everything is necessary to have as a feature in your system. Like I said, this could be a whole other session. But basically, when you're really thinking about which are the most important problems to solve with technology and not with people or process, obviously, we wanna be efficient. We want people to not be wasting their time. We wanna find the places where we can optimize. But once you've done your feature requirements, really, really, really look back at them and be like, do I actually mean that this is a requirement that must be a feature in the system or can I possibly envision another way that we would be able to solve this problem if it wasn't a feature in the system? And what would be the impact of that following that same kind of set of questions from before? Okay, if that's bad, why is that bad? Why is that bad? Why is that actually bad? Get to the actual impact of all of these things that you can really understand. There is no one perfect system. So what is the actual set of things that are the most important to you? And then that's actually only one piece of puzzle. The set of feature requirements when you're evaluating options for any kind of system is only one that's like the first row in this spreadsheet that we see here. There's all these other factors that go into understanding which solution is gonna be right for your organization. Again, this has everything to do with people process technology, right? So finding a system that checks the vast majority of the requirements boxes is one thing. Understanding whether the solution is gonna do that standardly, like out of the box, or if the way that they would solve that requirement is with some kind of customization is important to know. These things relate to the next row of long-term costs, right? Both just on a like, hey, sometimes better systems are more expensive. What are you willing to sacrifice? What is your actual budget? What can you let go of in the service of, okay, it's gonna meet enough of our requirements. It's gonna meet enough of our needs. Again, people are everything. People are gonna be using the system. Think about the example I gave with the org that had the really, really super robust CRM. What is it gonna take to get your folks using the system? Is it clear enough? Is it easy enough? Is it too much for them to be able to take in? Or are they gonna be able to actually learn it and adopt it and get the results that you're looking for? Et cetera, et cetera, et cetera, right? So all of these different factors, we're using these little kind of graphic things to give the quick rating scale here of like, which ones are the best? Which ones are the worst? There's not necessarily a single clear answer coming out of all of that. But the real story of all of this is that you're gonna have to have lots of conversations with each other in order to rally your team around making a big tech change. And so having this kind of organized approach to it of thinking through, okay, what's important? What do we need to consider? How does all of this stuff come together? Let's talk that through. That all together, looking at all of that is what is gonna get you to the actual prescription in the end. So let's dive back into story time for one more minute here, right? So we've talked through, we got all the way to prescription, right? So once upon a time, a nonprofit identified a new tech need. They saw demos. They evaluated their options. They used that whole feature requirements thing and the evaluation matrix. They picked a system. They signed a contract. Now it's time to implement the tool and to start using it. So just to be clear, here we are. We're at the action phase. We're ready to implement the thing. We're gonna make it happen. Doesn't actually matter at all what the thing is. So for this part of the story, Kristen will be our program manager coming to me, the IT director that led the process up till now. Hello. Hey, Michelle. I'm so glad to hear that we picked a new system. Do you know when we'll get to see it? Oh, sure. Yeah, I mean, I think we should be up and running in just a few weeks. You know, the implementation was free. It was part of the whole cost. So the vendor handles all of that stuff. Great. That sounds easy. So will staff training happen after that? Oh, didn't you already see the demo that we did? What else? What questions do you have? What else do you need to know? Oh, actually I only work mornings and all the meetings are in the afternoon. So I couldn't join. Oh, I'm sorry. I'm sure we've got a link to the recording of the demos that we did. So I'll dig that up and I can send that to you. I'm sure that's going to cover everything important. Okay. I was looking at the reviews online and it sounds like one of the real benefits of this tool is that it can integrate with our CRM. Was that covered in the demo? Let me think. No, I don't think so. That's not part of their standard implementation. So it wasn't part of what they showed us. I think the plan is to get to that later once we actually get the thing up and running in the first place. Oh, okay. Well, let me know when we get to that and I guess I'll take a look at the demo recording in the meantime. Awesome. Yeah, no, we're so excited to make this change. I'm sure it's going to be really, really great when we've got this new system up and running. Sure. So to summarize, V-Org demoed a few different systems. They liked this one the best. It's a relatively simple tool. We're not talking like a whole CRM here, right? So there's a quick implementation process. The integration features are slated for a later phase and training on this new tool is mostly self-serve through the vendor's help center. So my question to you is what's about to go wrong? Is it that Kristen works part-time and didn't get to contribute to the selection process even though she's one of the main users of the system? Is it that key team members are going to be on vacation during the week of the few planned training sessions and no one even knows that yet? Is it that V-Org will never actually get around to the integration phase because it is not part of the main project and no one has actually thought that through and made a plan for it? Or is it all of the above? Right. Drum roll. Yeah. Cool. Excellent. All right. Vast majority of people answered correctly. All of the above. I'll give the other folks of you a pass and just assume that you got so excited by some of these answers that you clicked them before you even read to the end. Exactly. Right. And again, this is perhaps an exaggerated version of it. But this stuff happens all the time. So once again, right, we've got our prescription and then action and assessment but we are missing some steps in the process. Like, making an actual plan. Like, what I'm kind of shorthanding here is persuading but is really talking to people at all. Right. Um, again in this example. It's a technology system right. So, the IT director. Led the process. IT, technology, those go hand in hand, right, except that Kristen's going to be the one who's actually using the system. Um, even if Kristen works part time, even if this is like this big picture conversation that there just simply wasn't time for her to be the like voice of deciding. This is a pretty bad situation. Right. I mean, Kristen, this is, this is, this is terrible. Right. Yeah, like I'm sitting here going, um, there's so many things that I don't know and things that I need, and that the answers of, you know, we'll get to that later. Will, oh, it's gonna be fine. Um, are not as reassuring as if we'd had like a real intentional conversation around bringing me into the fold. Like, this is what we're doing this is how it's working and listening to those questions that I have and responding to that so I think it's a difference of coming from pulling somebody along the process. Like, I'm going to bring you along, you're going to do this, it's going to be fine, we're going to be all good. And literally sitting down and having a real intentional conversation and what I would call coaching them into understanding what it is the system can do for them. What it is that we're working towards together as a whole, and getting that buy in and on board to, yes, I can help you and listening to the questions going okay maybe we do need to do something a little bit more different in the training process to make sure you're up to speed and get you what you need, versus just stating this is what we're doing this is what's happening and come along for the ride. Because then even, even if, even if it were true that there were some unknowns in the process and that there were things that we didn't have like good answers for yet. You might feel uneasy about that you might have some kind of reaction to that but at least you would be able to put some faith that some part of the process has been thought through. Right. And this is, you get a, I, with one exception I literally one time did have a conversation with a client where somebody in the room, introduced themselves as, as someone who's averse to change. I feel very worried about this project, which I think is like that is, yes, know thyself that is a good thing to know that's also a very tough self description to pin on yourself I think. I actually don't think that most people are like genetically averse to change. I think that people want to be part of a conversation and I think that people want to feel like they are participating in something and not just like, as you said, being kind of like pulled along against their will. If I can get what I need and understand what's happening. It's a lot easier for me to wrap my brain around change we don't change easily and people don't necessarily aren't necessarily aware of that. But if I feel like I have a partner in the process, somebody who's gonna help me as I do the change, I am much more likely to come on board, learn and do what I need to do to use the new system. And then that relates to, you know, the other two points on this thing that we have less to really kind of actually say about necessarily in the session but the idea of once this thing is actually done and you've gotten to the new place taking the moment to celebrate and taking the moment to know if we have achieved what we wanted to achieve. And so all of this kind of comes together to really one big question, right, which is, if you're going to be going into this project of making a tech change. What is the goal of your project? You who is leading the change should know that. The entire team that is participating and affected by this change should know that. Being able to actually define this. Both is the thing that does what Kristen was just saying in terms of bringing people along and keeping them aligned and keeping them in the loop. And it also gives you something to celebrate right and something to assess against. When you are done and when you have actually arrived in your new situation, whether that is a new system or just a new process or whatever. How will you know that you're there? How will you know that you've met your goal, unless you can actually say and articulate in the first place we have met our goal. And the goal isn't implement a new system. Right. Once again, in the same way that we had to kind of dig further into all of the like complaints and pain points to find out what the actual impact is there. Same thing here, thinking about the goal of your project of. I mean it could be like real, you know, we want to increase. Back to Kristen's first mandate in that volunteer coordinator role. We want to increase the number of our volunteers who also become donors. Which by the way, that also isn't a good goal because increase from what to what. Right, so you got to know something about your baseline too while you're at it right. We know that only 20% of our volunteer base can regularly contribute to the annual campaign and we want to make we're going to set a goal of making that 40%. Okay, how are we going to get there. Well, we've got to change something about the tech that we're using and waste less time and make it easier for Kristen to do her job. Putting all of this back together so that you actually understand, again, showing this slide at the end, it should also be at the beginning of every single and every other point throughout all of this because it drives all of those other conversations that you're having. So to sum all of this up, right, once we put those all those pieces together and not just those five boxes at the top but all the other different steps and probably imagine another like 27 squares on here, right once you start getting into it and thinking where does this all go where does all of these other people process technology where's that's it. But we wanted to ask basically one more question at this point, which is, now that we've gone through all of this and we've dug a little deeper into what's behind those first five steps. Have you changed your mind. I didn't answer it I didn't write down the actual numbers but you know the majority of people answered that you were in prescription and action stages, early on. Just curious if this has sparked anything for you that maybe puts you in a different place than you were. 28% were in prescription and action. In the beginning. Awesome. How many people are now, and maybe you haven't changed your mind that's fine, not necessarily like, maybe it's not that you're in a different step maybe what you have changed is what your next step is going to be. Hey, look at that. It's different. I love it. So yeah, so I, a lot of folks walked it back a little bit to diagnosis it sounds like sounds like you found some places here where you might need to dig deeper and ask some more questions. That's the part of the presentation that we're up to now. Um, if you've got any questions or stories to share about what you've heard in the last 45 minutes or so this is the time, we would love to hear them, tell us your thoughts. And while you type. I'm not going to let you just, I mean, this is a beautiful photo. While you are typing. I'm gonna, I'm going to start us off with one while we wait and see if anyone pops one in there but I think your scenario sort of begs the question, if you find that you're to that active state so you're implementing new technology and you're having conversations like what you were having with Kristen and realizing that you missed steps early on. What would you advise what kind of tips can you give people. Um, the, the answer is, is probably easier said than done, which is, you know, it's not too late. It's never too late. It's hard because they're, you know, not just sunk cost in terms of like this idea of the sunk cost fallacy but sometimes literally like you have already spent dollars on picking a thing. But if you can hit pause. At the very least, and just plowing ahead when you know that you. This is going to be a terrible metaphor because I'm making it as I go along, you know like continuing to drive on the flat tire that you've got is a recipe for getting into an accident or at least kind of not arriving where you want to get to, right, as opposed to, if you can pause and go find the service station, and maybe it's not that you're on the wrong road entirely but maybe you just actually do need to invest a little bit more time in justifying Justify is not a word that we used so far but that's kind of what a lot of this is right like working together with the team to fill in those gaps and to explain some stuff, and to, if you're not, if you if if you are one person who is worried that you're on the wrong path. Thinking also about ways to express that concern. That doesn't sound like you're starting your sentence with as a person who's averse to change, right, like being able to like use all of these tools together to be like, I loved, we purposely did this Kristen was yes anding me the whole time in that last conversation right great I'm so excited about this new project. Right, bringing that up, like, you know, if I wasn't being a caricature about it like I'm pretty sure that the questions that she posed would prompt some pretty good answers and some realizations on my part and so that's actually I think the best recommendation there is like, come at this from a point of curiosity, right. Great. Someone Emily says in our chat. We have many processes and various stages that you covered and she wants to know if that's common. Yeah. Uh, yes. Is it good. Um, sort of depends on how many processes you mean and also kind of what size of team you're talking about that is managing that stuff right. Um, if you find that you are changing a lot of different things at once. And that those are all things that are happening in parallel silos to each other and that no one on those involved in this process is talking to each other, that's probably a red flag. In theory, it could work right like in theory if you if you're working from that kind of map that we showed right the diagram of like the systems and here's all the different things that we have in all the different places that arrows and people and all of that stuff. If you've kind of gotten far enough along on that that you have the full picture and you sort of know the general shape of what you're aiming towards. It can then make sense to have different other different to be tackling different things at different times and kind of being at different points along the way, we did a project we did a test a tech assessment with Botanic Garden, actually, that I point to the photo of the questions on the screen. And what we found was mainly validating they thought that they needed a new CRM, we did a project to assess their whole thing and confirm like yes you do. In the doing of that we discovered that in order to make that vision work, they also needed to actually replace their ticketing system this like core system of the organization. And in that case, it was really clear that we needed to dig into that and solve that and identify and like find the real prescription there before moving on with any part of the project. And there were other elements of like maybe they need a new class registration system, and I think it was like a new, like marketing, there's a piece of the marketing thing that we purposely left unknown, right, it wasn't necessarily, it wasn't, we didn't, we knew that we needed the core, the questions answered, but we knew that there were going to be other ones that would be make sense to come back to a little bit later on. It is common to end up with processes and all those various stages, but making sure that there is some kind of through line amongst all of them is my advice. Again those goals are huge for determining the steps that you take. Emily says thank you. So if you, and I think that was the last question for now. Keep them coming if this sparks anything else. I've got, I'll put words in all of your mouths with some of the things that I have heard when I've both either working with clients or other times I've done this session, right. What are the things that go wrong, favoring buzzwords over real requirements right getting real excited about features of a system or saying that oh we really need something that has AI or whatever right. Where does that fit in your actual requirements list. Skipping steps in the project, making assumptions we covered that right up front. Only hearing the loudest voice in the room. And so as you're having those conversations and as you're bringing people together. If there's someone who's like super vocal, either in a positive or negative way about the project, really going in and digging further and making sure that other people get to talk as well. This is my favorite this is just my own particular pet peeve, which we hinted at in our dialogue a minute ago. A software demo is not a training session. I've sat in with organizations who are seeing demos of various softwares, and there's a huge red flag that I noticed right away. If the kinds of questions that people are asking in that demo are. How would that work, show me how I would do my job with this system in like this really specific detailed way. You're never going to get that out of a demo. And there's other ways to get at kind of vetting a software vendor rather than kind of trying to assume that you can learn the new system before you've actually adopted the new system. We've actually put on realistic budget expectations we touched on this a little bit too right if you've only got small amounts of money you're not going to get a system that costs big amounts of money. And so really kind of knowing what your trade offs and priorities are there. This is kind of the opposite, where the counterpart to only hearing the loudest voice in the room which is dismissing valid objections too quickly. Kind of depends on who you are and what your role in this project is but if you're the one kind of trying to be the agent of change and trying to move all of this forward. Who is that person that's saying hey is somewhat averse to change I don't like this. Like what's really going on there there's sometimes valid objections to a thing that aren't just, I don't like it because it's new or I don't like it because I'm gonna have to do work or whatever right kind of being able to weigh those and know the difference. I think that's a strong problem. Overall, that's like probably the number one takeaway from this whole session. And, you know, believing the hype kind of back around to the beginning. No perfect system. If someone to tell you there is that's also a red flag. Perfect just in time because I think we got another question. So want to read, want to read this one to me. Do you have any suggestions for a situation in which symptoms of a pain point are more acutely felt for some others so that some are much more driven to adopt the solution, even when the solution was collaboratively chosen. Yes, I love this question. That's very real, right. Not only is it likely that some folks are feeling the pain, more than others. But some folks are gonna feel more relief than others afterwards, too. So advice is honesty, actually and setting expectations. And coming back to that question of what is the goal of this project. Right. I'm really doing the work to help people understand that the people who are, you know, feeling the pain less. Great, cool. We're a team. We've got goals, we've got some kind of overall business mission to all of this right here is how this project fits in to the big picture, even though it doesn't seem like it's a thing that is part of your like day to day experience. Right. The flip side of that that I mentioned is, like, for example, I've got, actually, no, it goes in it completely goes along with that I made I ended up making a whole chart for one client that was, you know, we dug in we've done this whole discovery we've evaluated this whole new system and in the presentation. I basically pointed out, like, who's going to have the biggest, who's going to be impacted the most by this in a positive way right like who's, who's going to go from being like, everything is terrible to everything is great. Versus who's going to go from being, everything is fine to everything is still fine. And I think that's what we're going to go through by thinking about people's roles and their actions and people process technology stuff, and, like, just be transparent about that like saying, hey, this is what this is going to mean this is why we're doing it even though to you it is not a huge, big change. Before we run out of time I want to zip through my very very last slide here. This last slide is maybe my answer to you, Taylor who just asked a question here. So, overall, as you're thinking, as we end the hour here. Are you sure your technology is a problem, and not people or process. This is exactly what I just said, who benefits most, who else is affected, where do the trade offs. What do they need to see to get excited. Do they need a demo. Do they need a diagram. Do you have a clear roadmap and what expectations are you setting about timeline and change and what the expectations. Hey, we're going to do this new system, you're all going to need to learn the new system. We expect you to be just as efficient as your jobs as you always have been. Even while you're learning this new system and it's a thing you've never touched before. How can leadership say something other than that to make it feel better to people. Thinking ahead, what might go wrong, how can you future proof your project. Are you defining and measuring and celebrating success. And my very last moment here is, and do you need some outside help to do all of this. Because if so, we can help. I've got a little ebook called the nonprofit guide to preparing for successful technology changes that summarizes a lot of this especially that middle part of how, how do we think about this upfront, like what do we need to be considering. How do I help my colleagues come along for the ride with me on all of this. I think we're going to put, I think it's already somewhere, Christine. Yeah, it exists in the same place that you downloaded slides, it'll be the same place the recording is up so I think we are at time but after after this event after the recording is ready we will send out a link to you with that recording and you can find this book there if you haven't already accessed it. Excellent. Thank you so much for hanging out with us today. This was a lot of fun if you want to get in touch with either me or Kristen, our email addresses are right here on the screen. If you've downloaded that ebook. Tell us what you think. And I would love to chat with any of you about any specifics here that the spark and see if there's a way that perhaps back office thinking can help you get your next technology project off to a good start. Thanks everybody. Thanks Kristen and Michelle Thank you everyone for joining us. Have a great rest of your day. Thank you.

tech change at nonprofit organization

symptoms identification

problem diagnosis

solution prescription

challenges faced by nonprofits

managing tech change process

volunteers tracking

shared spreadsheet data integration

stakeholders involvement

avoiding common pitfalls