 Welcome and thank you for joining us for another episode of the nonprofit show. Again, we have Brian Greenwald with us of Generate Impact, and he is going to share with us what the process of tech discovery for nonprofits looks like, how it should be conducted, what it really entails. And we are so grateful to have you back with us, Brian. Before we get started, I also want to make sure that you know who we are. Julia Patrick is the CEO of the American Nonprofit Academy. I'm Jarrett Ransom, you're nonprofit nerd CEO of the Raven Group, and we would not be 400 episodes strong if it weren't for these presenting sponsors, you're so grateful. Have deep appreciation for each and every one of these presenting companies. These companies exist for one sole purpose and that's to help you do more good in your community. If you have not checked them out, please do. They exist in your community, they exist online and they literally are here to help you move your mission forward. So please do check them out. And again, today's guest, all 30 minutes of today's episode focused on you, Brian, Brian Greenwald, VP of Business Development with Generate Impact, welcome. Great to be here again. Just ready to get started. Good deal. Well, you are our guru for all things tech. And one of the things that we noticed, you've been kicking around this phrase tech discovery. And I was like, I didn't want to appear to be ignorant, but I was like, what the heck is that. And I finally got up the courage to say, okay, whoa, let's stop talk about this. And then you described something that I was like, wow, I didn't really understand this and I wish I had a different steps along my career. So I think this is a really good thing to talk about we're all getting so freaked out about what's the latest technology we need to get how do we upgrade our software. This isn't working but that will all this, but you're kind of saying no wait let's try a different approach so that's what we really want to dig in today. So what the heck is tech discovery. Absolutely so I want to start by explaining that the phrase discovery kind of comes from the custom development world where you're going to be creating something new and in the platform technology or the product technology world. More often than not you're going to see people use the word assessment. And so deliberately is the word discovery, because discovery for us means, let's find out what we don't know before we make decisions. And what we find is that people come to us and they ask the question, what tool should I be using. And we kind of go back and say, you know, that's the wrong question. The question is, what is it are you trying to accomplish and what questions should you be asking. And what is it that we don't know. And so we are more often than not recommending rather than an implementation project or a design project or a build. So let's do a discovery. Now it's important to understand that discovery is not something new it's something that you actually have to do, no matter what you're going to do but my splitting that out as a separate project. So basically saving yourself from the things you don't know. So, at the end of the day, while it might seem like it's something new or something additional. It's actually the first phase of any project, and by making it a separate project, you're making two things one you're mitigating risk and two in the long run you're lowering costs, which are absolutely two goals that I think every project should and probably does have. So a discovery is basically where you're doing all of that exploration of what are the actual problems we're trying to solve what are the business needs, what are the gaps, what are the risks. What do we need to take to actually implement this, what do we need to design. Do we need to do a technical proof of concept before we implement anything in all of that which can represent anywhere between 40 to 60% of the actual cost of the project will actually in the on the other end, lower the risk because when you go into that build, you will be doing it within by making informed decisions instead of educated guesses and that is the biggest benefit of doing a discovery first. So that's the timeline of this Brian, I'm curious the timeline and the individuals involved I'm curious who plays a part in this. That's a really good question so most discoveries last about 46 weeks. But part of it depends on you know what is the scale of that are you just looking at a particular integration. It could take a week. What are you doing with them and your advocacy tool. Or are you doing a full scale it assessment, where you're going to be looking at things like your basic back office infrastructure, your staffing, your adoption practices your life cycle management, your project prioritization you're you're planning that could be you know we're we're actually about to launch into one that we were scheduling for about 14 weeks. So a lot of it has to do with scale and scope. But it's it's surprisingly efficient. Now, those who will be involved is obviously it's going to be your decision makers, but the advantage again of that processes that you can actually include end users practitioners, the folks who have to maintain their services, and even your, your, your clients and, and, and folks who are the recipient of your services depending on what type of technology we're talking about. So you have an opportunity to really involve voices across the organizational ecosystem, and particularly helpful in that is is is uncovering unforeseen insights. You think you know, but when you actually sit down and start talking to people, you actually uncover things that you didn't know. And sometimes that results in a very different outcome than you might expect going in. So I'm a big believer in the phrase, you know, you don't know what you don't know. Right. And so, are you saying that when you go through this discovery you almost need like a sherpa or somebody that can guide you through and ask you these questions because you know what I tend to hear from nonprofits and especially with leaders. They're like, Oh, our system doesn't work. It's the worst. And then, and then it's just like, throw it out. Get your credit card out and buy another subscription to something else versus figuring out what doesn't work so I'm wondering how do you do all that. I would say that the the other phrase that I really love is that when if you do that if you say the system is the problem. You're kind of looking at it through the wrong end of the telescope. Right. Okay, so it's not only that you don't know what you don't know it's also like yeah you might need to make a change but let's measure twice and cut once which is a phrase in in carpentry. Yeah, so you're making an assumption, especially if you're an executive and you're not actually doing the day to day work. It might be the system. It might be training. It might be processed that supersedes the technology, it might be team alignment. It might be leadership alignment. It might be technology but it might be something else. So rather than make that assumption that it has to be the tool. So let's replace the tool the reality is that no technology is the solution to anything you've heard me say this a few times. I believe that technology is not a solution. Technology is there to empower, it's there to enable, and it's there to accelerate but your people, as you hear me talk about ad nauseam are the actual solution. So you can have the best tool in the world, but if you didn't create the roadmap for adoption for process alignment for team alignment for leadership alignment. The best tool in the world will fail. So you have to actually go through that process of making sure what are the business objectives, what are the gaps, what are the risks, what are the risks of doing something, what are the risks of not doing something, what are the alternatives, and then make an informed decision that because you've worked out all that detail and you've gotten by in by making it participatory. It's a much better chance at succeeding in that project and you might be right it might be the tool, but just picking the next tool that you read about in a blog post, or you know has the buzz is not necessarily answer. One of our values is practicing practice is practicality. And that is like, we're not going to look for the most fanciest whiz bang solution we're going to look for the right solution, which might be something really simple, maybe the answers already in your mind. Maybe it's just reconfiguring the tool that you already have and optimizing it for the people and processes that you have. And maybe it's a new tool, but there's so many options out there that you do need that guide that person in that team that's outside of your business processes, who can, who can walk you through that. Yeah, and see it differently. One of the things that Julie and I have noticed and again we aren't necessarily in the tech world, but most of our best friends are right. And, and you can see, you know, are at we've seen over the last 18, you know, 24 months this huge increase in technology advancements. You, you kind of talked about this just a little bit, you know, about if there is an email sent to you or this whiz bang product and I keep thinking FOMO right it's this fear of missing out of the new technology opportunity, or like the first thing that's going to solve the world's problems and make my life easier. And there's there need not needs to be but I'm imagining there's some risks to that, you know, when it comes to performing this discovery and that's another reason to do that is that you just don't focus on this new bright shiny, you know, object because you suffer from FOMO. Yeah, exactly. And that's why discovery is essentially a risk mitigation process. So think about it this way and you know a cost mitigation process. If you make assumptions, and you ask a vendor to give you a price for an implementation of a tool. If there are lots of unknowns. If there are lots of if you're asking the wrong questions or if you haven't truly investigated what the root cause of the challenges that you're facing. A couple of things are going to happen first of all if you're going to ask and you know I was on the buy side so I absolutely get the idea that you need cost certainty wherever you wherever you can like that I always went for cost certainty like I want to know what it's going to cost don't give me a range don't give me a sliding scale. What it's going to cost. The problem with that and not doing that discovery first is that you're asking people to make educated guesses and so as a vendor, what they're going to have to do is they're going to have to price in that risk. And so they're going to have to price around worst case scenario, that's the one scenario that happens the other scenario is that you guess wrong, or do you ask the wrong questions and halfway through it's like, Oh wait, this isn't going to solve our problem I thought it did or the well meaning account rep at that product company, whose job it is to see that their product is the silver bullet. Didn't tell you this one thing or, you know, was operating on a wishful thinking kind of thing that, yes this tool can do anything they can solve all your problems. No, no tool can solve all your problems. And so then you have cost overruns you have redesigns, or you do exactly what you set out to do and at the other end of it you're like well you know what. This isn't any better than what we had before. And so that's why splitting out that discovery. And you know working with a vendor that's going to hand you all the deliverables that you would need to implement yourself or go to another implementation vendor. It's actually counterintuitively the safer bet, then saying well in this RFP we need to know what it's going to take to figure it out and to build it and to maintain it. And so you're asking them to make a lot of guesses. And when people have to make a lot of guesses and estimating, they're going to give you the highest price in that range because they have to price it for their risk. And so the discovery is actually a more honest way for these technology vendors to work with you. I'm thinking about this in another way I have somewhat of a curveball question so get out your bat as we like to say, ready. When we're doing this discovery. What do you think the percentage of organizations are going to come back with an answer that's like, it's not on the tool side, it's not on the software side. It's on your side, it's on your training knowledge talent. It's really you that's not making this work. I think that it if you're working with a with a technology agnostic vendor who is mission focused right who's not worried about their revenue so much as supporting your mission. If you have a partner like that that's sort of in a fox hole with you. They will say, look, we don't think you should do this, we think that there's another way. We're actually this December going to be launching into a very large people process and technology alignment and optimization project with a international humanitarian organization that I will not name now. But basically they spent a lot of money on a very large engagement technology project and they're finding that they're not getting the results that they need they're not getting the, the, the adoption that they need, because it's such a huge change management process. And so the work that we're going to be doing them is actually not to change their technology. Exactly. The point is to look at the leadership in the people and the processes, allowing them and create the, the, the behavioral change to get them to buy into that technology change and then there could be some optimization of that technology as well. And the point is, as technology vendors, we have to get real about the limits of what we can do for organizations and look beyond the technology products and services that we're trying to sell. And think about it in terms of what is going to enable the people in this system to be the best version of themselves at work, because like our director platform tech likes to say and we all like to say, nobody goes to work every day. Deciding that they want to do a bad job or that they want to wrestle with their technology they want to do they want to deliver the services that they're there for technology is just one part of that equation. And if you ignore the other two people in process, you're making a mistake and discovery can validate all of that before you make a technology investment. Right where does integration come in because there's so many systems out there there's so many softwares, and I heard you say there's not one, you know, one size fits all that this product is going to take care of everything for you and your team and your, you know, client base. So if we're keeping something but we're adding something else into the mix. Where does this integration come in and is that does that often prohibit the new software or are we at a place 21st century now right moving into 2022 even where integration is like, you know, I don't know the blissful marriage that's happening. Yeah, I mean there's definitely a place for integrations we we do a lot of integrations between systems between CRM systems and advocacy systems and between CRM systems in LMS is our, you know, we recently did one between a CRM and Google calendar. So there's lots of different ways that you know if those core systems gets you 80% of the way there. Then you can overcome a lot of manual process friction, make data centralized and available, make it easier for reporting for program evaluation for for modeling for investment and fundraising dollars. If you find a way to deal with that 20% and that's where custom integrations and sometimes native integrations can be really helpful. So let's say you're using Salesforce in a certain way that you're more using it for you know, donor tracking corporate partnership tracking, but Salesforce, maybe isn't the right answer for you for that front end donor volunteer or you know, contributor outreach. So maybe you integrate that with with a with a more of a marketing CRM that where that data can be shared. And it's, again, it starts with a discovery and I think we're going to talk about my favorite project that we didn't do. Yes, tell us more about that because I just am so curious. I love that you say this and it and it's, it's the best project we never did. Yeah, so I love it. So it's just like the perfect example of why investing in a fixed price, fixed scope discovery before you commit to any kind of technology change is so important and valuable so recently working with with a wonderful advocacy nonprofit. In the DC area, they came to us and said we would like to integrate our CRM with this advocacy tool so that the data can flow between them. And so we said great but we want to do a discovery first because there's an API in this side and API on that side and we want to do a technical proof of concept to make sure that what you want the system to do. It can do. And to make sure that the build is within your budget. And so we did a discovery. And at the end of it we found that on the advocacy tool side that the API wasn't out of the box able to support the integration that they wanted. We went back to that advocacy tool vendor and we said hey, we need you to, you know, support us which is very common, most product companies who have robust APIs will support the changes that they need for their clients. In this case, this particular product vendor was not able to do that. And so we were able to come to the conclusion as a result of the discovery. Hey, this is going to cost too much for us to build this for you. We don't think you should do this we think that you should find a different tool. And so the conversation went from, we want to integrate these two products to, let's find a different advocacy platform that's going to do what you need it to do, and you're going to save money by doing that. And so that was a thrill, because, again, as a profit enabled and not profit driven business. We would rather lose business for the right reasons than win it for the wrong reasons, because to a person that people have generated impact and it's not a plug for generate impact but I think that there's a lot of vendors like us out there. You know, we're about the mission that you're delivering on and that's what gives us fulfillment. And so, to be able to say to that client, it's not in your interests to buy this next phase from us. Of course they agreed out of the box because it was a high price set. So, I mean, I don't want to overstate it. But that was a really fulfilling and just a wonderful case study of why discoveries are so important. And if people can get past the ambiguity part of it because there's this feeling that what am I buying. When I buy a discovery we're buying an insurance policy that your technology project is going to be successful, or it's going to fail and fail fast and save you money. I love that story. And when you mentioned tech agnostic, I, I feel so privileged to know that there are several tech companies out there that really do have that core value. And again, another plug bloomering is one of them Steven Shaddock I was, I was searching around some CRMs for a client of mine and he mentioned another system and I said, is that a product of yours and he goes no it's a competitor and I was like, whoa, so to know that this is just I think it is super, super cool. I have a question Brian that really relates to today's time during this great resonation so we're looking at turnover within staff. How do these assessments and the new technology. I'm thinking, you know, are there some best practices that the organization the team can put into place to transfer this institutional knowledge when and if there is a staff turnover. Absolutely. So the big part of the, the discovery process and actually where we're kind of, and we talked about this on other shows, looking at the problem through the other end of the telescope or so not sort of like tool out to people. You start by looking at it through people and that means that part of the discovery is, what's our adoption plan. What's our life cycle management plan. What is our doc, our project and product documentation plan. The first case scenario is where you have were single points of failure in your system where when somebody leaves. They take that institutional knowledge they take the workarounds that they have developed to deal with that product process friction, and they walk out the door with it, and you're left high and dry. You actually eliminate those single points of failure and you ensure continuity of operations continuity of service, and you protect your investment by in that discovery planning for adoption planning for life cycle management. And hopefully that's a train the trainer activity and not where you're dependent on a third party like us we know like we have no interest in coming and camping out we want you to be empowered. So it involves that that plan for adoption and then plan for a reasonable amount of self sufficiency right so you can never stop or absolutely every technology need. But if you have a solid plan of, of, you know, having a certain amount of self sufficiency that you don't have to have additional billable support every time you have an issue. That's that should be part of the discovery process as well. I'm, I'm so glad because you know there's, whether it's FOMO or it's a new staff coming in and the staff member saying, I can't work in the system I need this system and then you know the individual, as we know, I think it's the director of development, the tenure, the kind of national, you know, tenure there, I think is like 18 months, maybe two years. So that's, that's a turnover, you know, and making sure that the organization is able to, you know, continue to thrive through turnover or through this cultural change right now that our nation is experiencing with a decrease in the workforce. Right, I just had to ask that because it was, it was shining so bright that it was like well how does this work but of course generate impact and Brian Greenwald has that answer and it's really within this discovery so what a great concept. Yeah, it's really interesting to run because I'm thinking about a lot of times, we were talking about this chair, I think, last week with one of our guests. I think sometimes we work so hard to get an integration with something. And then we're like, okay, we're done. We have that new website or we have that new eBoss server. And then it's like, yeah, this is not going to work for, you know, the rest of your lives you got to keep coming back to this because things change. Yeah, that's right. I think that's a really, really important point about the other way that you can do discoveries and the other, you know, sometimes your discovery can be a reasonable cost that can have a long range impact so you don't necessarily, you can decide what part of that to build as a minimum viable solution. Right. So, the outcome of the discovery is a roadmap for the future. Right. And I know that you talked with john. Last time we were on about tech goals that discovery can build out that roadmap and say well phase one we need this to get running. And then phase two, we'll plan for that in the next thing and you can really do long range planning through that discovery, because you're right. Yeah, we just relaunched our website in March and I already want to replace it. It's the reality of the pace of change in the world that we're living in. And if you don't think about it in the long term as you're addressing today's issues. Again, you're making an investment that you're going to have to make again sooner than you want to. But if you're thinking long range and you have a vision of where do we want to be in a year or do we want to be in three years. And that technology roadmap accounts for that. Then you're actually just focusing on the delta, the change delta during those period of time and you can actually even think about it in terms of what are the conditions that need to happen for us to then be ready for that next phase, and you do that check in every six months. All right, let's sit down and audit this. Where are we now compared to we were six months ago. Wow, well, you know, every time we have you on, I feel like we're ready to go to the next phase you have been great at giving us some really great ideas, I always appreciate that you're not, you know, a certain product you really are a tech agnostic as we like to say and that has been super cool because you're kind of like the guru of what this whole process can look like and I think that helps us make better decisions and not be so fearful about all of these these impacts that we are inputs that we need to be making. So here's Brian Greenwald's information VP of business development and generate impact. Check out their snazzy website. And it is new, I'm like mortified that you would say you already want to make changes because that like strikes my heart. Yeah, check out generate impact. We're really fortunate. And we've made a commitment with generate impact to get them on every month to kind of talk about what are the latest things that are going on. It's not always about product but sometimes just it's about process. And so this has been really cool for us to get this higher level thinking about what we should be navigating towards when we think about tech in the nonprofit sector. So thank you so much for being here. Again, if you can't remember who we are, we'll tell you one more time. I'm Julia Patrick. I've been with my nonprofit nerd, your nonprofit nerd, the nonprofit nerd Jarrett Ransom, CEO of the Raven group. Again, we want to thank all of our presenting sponsors, a lot who are tech oriented companies. And again, you can get to them at any point on this planet because they are for the most part, so many of them web based. And again, we are so so full of gratitude that you have invested in us. Okay, Jarrett. I know, you know, when I hear of tech, it kind of, you know, it makes the hair on the back of my neck stand up because I'm thinking this is not my zone of genius just like it is with finances and accounting. But Brian, you make it so consumable like very easy to digest very easy to understand. So thank you for what you do, you're clearly working in your genius zone, an area of expertise so so grateful to have your knowledge your time and all of your wisdom around technology so thank you for joining us today. Always a pleasure. It's a lot of fun. Hey everybody, as we like to end every episode. We want to remind everyone to stay well. So you can do well. We'll see you back here tomorrow.