Well, I'd like to turn it over at this point to Eric, our speaker from Idealware, and thank you so much for taking on this new topic for us. I'm actually really excited for this. There's several large projects that we're working on here in Washington State where this is just extremely important and right on to what we're doing. Great. Thanks so much, and thanks everybody for being here today. My name is Eric Leland, and I'll lead us through strategic software selection. A topic that can be a little heady, sometimes heady can do things, but we're trying to make it fun and informative today. It's very important work, so I'm happy to be here today. My name is Eric Leland, as I said, an expert trainer of Idealware. I'm the founder and director of 5paz.com, and you're always welcome to contact me, Eric, E-R-I-C, at 5paz.com. Happy to chat. Idealware is at idealware.org. I have lots of training on software selection, different kinds of software reviews. Donors reviews, content management systems, all kinds of reviews, and webinars live as well as recorded. Lots of great resources there, so if you haven't spent much time on idealware.org, definitely check them out after this seminar and see if there's resources that are interesting to you. Most everything is free, so definitely check it out. Here's some things we'll cover today. We're going to look at your software needs, defining your needs and processes. We want to make sure that we do a lot of preparation in terms of thinking about what you're really facing as an organization, whether you're ready for making a selection for software. Is this the right move for you? Looking into how to choose, how to define your needs, processes, things of that nature, and then getting into actually choosing the right software and some tips and strategies around the rollout as well once you have chosen it. Lots to cover today. We'll move a little fast, but I'm happy to take questions and you can enter folks that are chatting them in. By all means, I can answer them at any time throughout the session. So, do you need a new system? This is always the best question to start with. It seems obvious that we're all here maybe because we already know we need a new system. But it's very important to ask yourself critically this question in the beginning, launching into a process of selecting a new software. Even if you don't have one already and you're not necessarily replacing one, it still takes a lot of time and energy to go through this process and actually get a software selected and implemented successfully and folks trained, all that stuff. So we want to make sure this is the right thing to do. Switching systems, you already have one and then you're moving into a new one, which most of us are in that position, is definitely time and cost intensive. You know, a not-so-fun fact, data migration costs typically range between 20% to 60% of the total for most database projects of some sort. Switching isn't something you want to do in a whim or in an effort to find that mythical, perfect system. We want to make sure we're being really sort of level-headed about what these things cost. Training is also pretty time-consuming. For new systems in the beginning, they're just new. And the more folks we have that need to use the system, of course, the more that we have to train. So in the beginning, a new system takes a lot of time and effort to get folks involved, trained well so they're using it efficiently. Also, if you're moving to a new system, especially for organizations that are sort of growing in terms of complexity, these new systems tend to be more complex. Even though you might be shedding some old processes that are complex and bad, you may be getting into a new software that has some complexity of its own, and that can ramp up the training costs as well. So just a few areas where switching to a system is hard. We want to make sure that we're ready to do that kind of work. So how do we figure that out? Well, definitely start by talking to your staff. Find out firsthand what's really wrong with the system, and then justify this. Are these gripes around sort of the water cooler? Are they a time waster for real, or are they just an annoyance? As we're talking about this with our team, try to figure it out, kind of mine into it, and find out how big of a deal is it. You can talk to your information technology staff, program staff, executive director, everyone. People who use it and maintain it, but also people who benefit from that that might not actually touch the system. So there are times where we have systems where we're storing data. Maybe some of us use it, but others of us benefit from stuff that's being extracted from it. The executive director asks for a report, someone else goes and gets it. So we want to find out how everyone is benefiting or not from the system. I did mention that it's good to know what's going well. That's very important because in most cases, even if we don't like the system we have now, there's something that is doing well. There's probably solving some kind of critical need, even if it's not doing it well. And we want to identify that, yes, in fact, we do have this need met, even though I'd like to see an improvement. Or there might be something that's actually fabulous about it, but there's other things there, apparently. Let's figure that out. Talk with your team, figure that out. Don't be afraid to capture what's good and what's bad. It's really good if you have a vendor right now that's providing a software, maybe you pay licensing fees for that vendor. Maybe you have a consultant that's helped you build, set up, or just over time support the software. Or you have consultants that you haven't used for that purpose, but have that knowledge or expertise. Figure that out, find those folks, and then challenge them with the stuff that you've heard from your team. Here are the problems we've heard. These ones seem to be the time wasters. Tell them this stuff. And challenge them, can they solve it? Maybe your current software still has life. What's interesting about this is that you may still be in a position to say, hey, I need to change my software. But if you find out that your current software has some life to it, that actually allows you to extend your timeline, allows you to be more thoughtful. You're probably super busy with the regular work you're supposed to be doing. So adding a software selection process isn't necessarily the kind of thing you planned on. So being able to extend that time and be effective, or at least more effective with what you've got, gives you sort of a lease on life. And it could turn out, and it has in many cases in the work that I've done particularly, that the software is actually pretty good for another cycle, another year, another couple years, as we kind of figure out some of the problems. And that's great news. We don't just want something because it's there. So figure it out. Is it training? Is there some add-ons you can get? New features that are already there that we haven't taken advantage of? Take a look at those things. So when is it time to switch then? Most importantly, if the software just isn't supporting your current processes. So how do you do the work you do with your processes? We'll get into that a little bit more. But we want to make sure that the software, in some reasonable way, mirrors that support that. If there's sort of big pieces of the process where you're gathering data, trying to look for that data, look at the data, or analyze the data, those four things. And that's not happening with your software. Then we have a misfit. You may also have significant growth. You recall that the software was built for a certain purpose.  So dynamic organizations where lots of program services might change. You might have more staff or less staff, which changes sort of the nature of how you can use the system. Those are some telltale signs. Other telltale signs are a little bit easier to grasp as you're talking to staff. If you find that a lot of folks are doing work around, you know, you're saying, hey, what do you think of the system? And they say, I don't know. I don't use it. You find it. Well, why not? And they're like, it's too hard. I've never been taught it. It doesn't work. It's broken. My computer doesn't load it. I just find it easier to use a spreadsheet. I just Google Doc works great. You'll find out that stuff. If folks are doing work around, then something's not going right. You have the system supposed to be used, and it's not. Maybe folks are saying, I can't get information out of it. I can't put information into it. I don't see the purpose or the value of it, but I do in my spreadsheet. Performance or access could be limited, as I said, if it's broken, or I just don't have it on my computer, or I work from home or remote as I visit sites, and I just don't have access to it. If you find that your organization, sort of the data system you're using is, in fact, a document or a spreadsheet, or God forbid, post-it notes on your desk. I actually had that case where the database was a pile of 400 post-it notes on a desk, color-coded, to mean things, with chicken scratch scrolls on them. Okay, these three times, especially the post-it note model, is a bad one. That means we want to switch systems from our spreadsheet, which isn't very relational, very easy to mess up our Word documents, typically that's not very relational at all, and our post-it notes, which has some unique advantages we'll see going forward, but not for data management overall. Maybe it's time to switch. So how do you know if it's worth the investment to switch? Let's think about this. The best way to think about this really is to think about your return on investment, or ROI. You may have heard this, especially if you read business zines or, you know, watch financial reports or so forth, or maybe this is a very familiar concept. Let's put our math hats on for a minute, promise I won't be too raffy, but simply put, your return on your investment or ROI, that's the acronym, is your benefit divided by a cost expressed as a percent. So what does that mean?  That's 1.5 or in percent terms, 150%. That's your ROI, 150%. A good one, you're increasing. So we want to look at your benefit divided by cost, and that's one way to think, and one smart way to think about whether it's worth your investment. Brainstorming costs is a great way to start. With your team, you can gather together and say, what are the kinds of things that we're facing now in terms of costs? For instance, some things are going to be easy to measure directly in terms of costs. Software licensing costs, for instance, maybe pay for training, maybe pay for hardware, those sorts of things. Ongoing maintenance has costs directly. So there's no real conversion. You're sort of saying, okay, I'm just adding up costs. You think I already cost money. I can just add those numbers up. Other things can be harder to measure. So it starts to get a little harder. When you talk about time, it takes to do something. With the current system, I have to go to five different spreadsheets to get all my contacts. Then merge them, duplicate them, and somehow then mail merge them to documents. It takes me three days, and it takes four people. So that's something you have to do a conversion on if possible. What we're trying to do is quantify as much in terms of cost where it's reasonable. So time can be quantified in terms of cost. You can think about what it costs to have an hour for someone's time. And if it's for someone's, what it costs to have all four of those folks for an hour, and then add that. Some things are still really hard to measure, and it may be quite possibly impossible. The poll on morale, for instance, so if you have a system that's just feeding people down, and for whatever reason, even if it has some good aspects, people are just not able to sort of do their work and it's affecting sort of overall performance at the organization. These are harder to measure, yet very important to capture because we want to understand things that are intangible as well that are cost. So the tangibles are those things that actually have monetary value, or you can convert to that reasonably. And intangibles are things that are softer, you know, possibly qualitative, but certainly the kinds of things that you might not be able to put a number on but you don't want to forget. You, as we mentioned before, don't only think of negative costs, but think of benefits. So what are the benefits for getting a new software? Some things could be, you know, increased dollars raised because of, you know, what we need to do with the new software. You know, maybe we're going to save money on paper and toner because we're going to do email blasts now. Those things are measurable right now in dollars, right? Those are just a few examples. You know, harder examples, again, the things that start to get less tangible, maybe harder to convert into dollars. Better quality services. It's possible that you can measure quality in terms of, you know, how easily you qualify for certain grants or proposals based on quality metrics that you can provide, whether that sort of snowballs into folks recommending your services more, that sort of thing. You can figure out a way to take sort of quality and measure those into dollars. Can you plausibly calculate time saved? Ask yourself this question. If you can convert that time into dollars, then, again, we have sort of a common metric. We can look at benefits or costs in terms of dollars. Again, if you can't measure intangible benefits, definitely capture them because we want to know about them and use that as we're thinking about cost. So don't get too sort of nerdy about the cost here. This is meant to be a discussion starter, as the slide says. Think about return on investment. It's not going to make the decision necessarily obvious. Sometimes, though, it can help you really kind of start to frame where you're at. You might find that the preponderance of what you're finding is in the benefit side or on the cost side. You might find that you have a kind of thing that you feel are intangibles but worth while thinking about, even though that doesn't really get you to two comparable sides, a bunch of intangibles on the benefits, a bunch of intangibles on the cost. You've gone through the exercises dividing those up, thinking as much as possible about what things cost, and helping your team discuss that more. You can start to think of rank ordering, these kinds of things, or which intangibles are more or less important. So it's a discussion starter, not a scientific endeavor. So again, keep the math light, but reasonably as possible, work on the same terms, cost in terms of money as much as you can, and then the intangibles. So let's dive into the planning process. This is especially helpful for folks that might be listening and watching this later who are not sure how big or small the planning process needs to be, and also for thinking through to justify whether your planning process is going to be larger or not quite as large. So looking at this, let's right-size your process. So for planning processes, we don't want to look at everything under the sun. We want to do it in accordance to how big or small the whole project should be. For a small purchase, maybe a software to store photos, maybe a lightweight e-market infusion where you need to blast some emails out. It might make sense to pick one or two options, see if they meet your needs, and if so, call it done. So we don't need to do an elaborate research project for something smaller, lightweight, sort of solving maybe one process that's critical but simple. For a larger purchase, a common database solution that sort of tracks everything about the organization, for instance, or significant portions of data for the organization, maybe multiple people will be using it in different ways. Some people are reporting, some people are tracking data, there are lots of different processes. You want to do some substantial research, seriously consider several systems and define your needs carefully. Large investments definitely mean time is well spent doing upfront planning, research, and evaluation. The total cost of ownership for a large system can be large. So for instance, you're spending the time, you're spending the money getting the software, you're going to spend money with larger solutions, training, and providing ongoing support. The implementation process is probably going to be fairly large. You already have data, you have a new, you know, robust but complex system and you want to try to get your data into that system to start the cost of a lot of money. So customizing the solution can cost money to the migration training, the adoption after launch. And overall, the change management of just, hey, we got to get our team to start using this new system, that can make for a larger solution. So figure out where your needs are, try to figure out if you're sort of towards the intensive research side, you know, where you are on the spectrum. We should definitely focus on the planning steps before we look at actual software options. Don't get influenced by the fancy new tools right at the beginning. You should always start, you know, with goals and we'll get to the tools sort of towards the end here where we're at, explore options and decide off here to the right. So we do all these other things first. And that's going to be very important. If we start with the bells and whistles, that can be good for just seeing what's out there, but it's really easy to get trapped by things that are available, being good and good for you when you haven't actually done that focused work to say, hey, is that really true? Do I need these kinds of things? So it's best to start with the explore options towards the end. So who should be involved in decision making? You know, you can consider planning teams in a variety of ways. You know, consider including someone from IT, information technology, from communications and marketing, from development, from finance, and from your programs. Now, what you want is at least one or some of those people that be able to make decisions and have sort of solid authority or oversight. So in other words, if you have a team compiled that always has to take sort of every decision back out of the team for someone else, then that someone else doesn't have the benefit of what you've discussed that can really slow down the process and make for you sort of repeating kind of discussions over and over again. So you want a decision maker in that team. So if you're 30 staff or less, this is kind of like a rule of thumb. 30 staff or less, I found it beneficial to have one planning team from like four to six people. It's usually a pretty good number. Again, this is not hard and fast rule, but this is kind of a rule of thumb. Greater than 30 people. You may need specific focus for different departments. You may need a core team and the ancillary team to help you. So maybe someone on the core team is going to another team. If you're talking about a donor database and with a large donation department, development department or the large communication department, a large finance department, you may want a representative that then goes back to their teams and gets information. You should think about the roles of folks on the team. And often it's common to have a team put together and you sort of just assume everybody has a part in everything that we do. Everyone sort of talking, listening, making decisions, that sort of thing. It's often not the best way to go because then there's sort of too many cooks in the kitchen on every single issue, right? So think about the roles people play. One model is called Rossi, R-A-C-I, is the acronym. And it helps you remember the four different roles. So R, responsible. Those are folks on the team who are assigned the work to achieve something. So if you have tasks to do, they're responsible for getting them done. And so that person's been assigned to do some work. They're responsible for getting it done. The A in R-A-C is accountable. So that's the person who's answerable for the completion of tasks. It's the idea that someone might be assigned a task but someone else is accountable for making sure that's done so they can work sort of as a team or a supervisor, a supervisee relationship. So think about who's responsible, who's accountable for getting it done. The C is consulted. So some folks, you'll need to seek their opinion. You want to get their advice. It's sort of subject matter experts, that sort of thing. So maybe you're saying, well, our team doesn't really have IT support in our team because we have our four to six people and IT sort of, you know, wasn't necessarily to bring in on a working basis, but we need to go consult with IT on specific questions and decisions. So those are the people whose opinions are sought that may influence the direction of the project. And then there's informed. That's the I in R-A-C, informed. Those are folks that need to be kept up to date, but you're not soliciting their opinion so much to change the course of the project, right? And this is really important. There's a lot of folks that do need to be informed, and sometimes it's assumed that they also have input in terms of changing the course of the project. And the larger your organization is, the more fraught that can be. So thinking about your R-A-C model, who's responsible, who's accountable, who's consulted, and who's informed can really help you, especially as you get larger and larger teams. Okay. That was a lot. We have a team now. So now what do we do? Let's start getting into defining the project. Look at things like, you know, when do you need to complete the project? What time do you have available from the staff team? What's your budget for getting this done as the slide shows us? So we want to look at these projects and logistical goals. Who's managing the project? Let's allocate what's sustainable for your organization. So can you have a lot of people that are focused on this quickly? Do you need to spread it out? Especially look at calendars and just be reasonable. When are you starting this project? Is it going to overlap with an end of year appeal, and everyone has to be hands down to deal with that work? Is it going to overlap with the winter holidays, and everyone's going to forget what happened prior to the winter holidays? Maybe not a good idea. So just think about the calendar and be reasonable around having folks' attention, time, and having money to pursue this. You want to work with your team to identify your goals and your software goals. Goals are generally more mission-oriented. You know, what benefits will this achieve for your new organization? So your new software may eliminate lots of time creating a mailing list, which relates directly to gaining more awareness for the organization. Right? So one way to think about this and identifying your software goals is not, you know, you can kind of brainstorm and come up with goals. You can look at your organization's strategic plan and say, what are the goals of the organization and how might software goals play into that? That's kind of nice. You can think of a format where you think about a goal, you identify a goal, like maybe one, two, or three sort of software goals, and then underneath each goal, you identify strategies to get those done. And then finally, for each strategy, you identify how you're going to measure success. So list a goal, identify one or more strategies, and then successes that you can measure for the strategy. For instance, a goal could be increase our budget so we can hire more staff to strengthen our core support services, as well as develop new ones. All right. So we want to increase our budget so we can hire more staff. So a strategy might be build up our support base through increases in new and returning donors. That's how we're going to get that goal met. So we're going to build up our support base through increases in new and returning donors. We need to measure that, like how we're going to know we did that. The one metric could be we'd like to increase new donors by 20% over the next 12 months. Why? Because we decided 20% will build our support base through increases in new and returning donors, which will increase our budget so that we can hire staff, right? So you go from the metric, go back up your strategy to your goal, and say, well, is this reasonable? So goal, strategy, and success metric in kind of a hierarchical order is a great way to go. I'm going to shrink my screen here because this is an example of how this is outlined out that could be useful to check out from the pages of the chat here. There we go. So if you check that out later, there's just an outline of the goal strategy and success model for defining your software goals. Okay, so let's take a look at defining needs. Now that we've kind of looked at the goals at first and how we can get that done, we now need to kind of get into the nitty-gritty of sort of needs and requirements definition around our organization and what the software needs to do for us. So what do we really need? Again, list out as a team what your needs are. Get them all up on a list. You want to group those needs as well. So critical is the first category I recommend. So what I mean by critical is very much the definition of critical. We must have these things in the software as we cannot live without it. And by live, I don't mean sort of our own personal lives. I mean that our organization will really be sort of a detrimentally harmed if we don't have these features, right? So this is a small group of needs. It's important to think about it that way because we're going to be looking at software where, you know, likely if you're comparing two, three, or four software, some of them are going to be kind of elemental. Some of them are going to be expansive. And if you have defined everything you've ever mentioned as a need as critical, you start to immediately fall into the more expansive and you're wondering why everything's costing so much. If that's true, then that's where you're at. If you're critical on yourself and say, what are the things we can't live without? So to find your needs, identify the critical group. Also identify what I call the important but secondary group. So these are the things that we're saying, hey, these are important too. They're just not critical. You want a lot of those things. They're important. They're going to improve efficiency. We've had definite benefits. They're just not the things that, you know, we can lose out on some of those. And then the final group is the wish list item. I prefer this over unnecessary. So we don't need a fourth group that says, we don't want this at all necessarily. Wish list items are things that were, you know, could be good ideas or are in fact good ideas. You want to not lose those kinds of thoughts. And because sometimes you want to refer back and say, well, this came up before, like, what were we thinking? And then you'll find that as you look at software, it just nails all of these and seems to fit your organization capacity as well. That's great. So think of the three groups, critical, important but secondary, and wish list items. So looking at requirements gathering, traditional requirements gathering is, you know, generally what we're talking about is requirements gathering is just figuring out within your organization what do we really need out of a software. There's several strategies for getting that done. Just asking people what they want is a pretty limited way to understand needs. You have to recognize that folks often don't necessarily know what they need out of a system. And so sort of directly saying, well, what do you need out of a system? You can get some blank stares, folks that are kind of fearful about talking about software at all. And so you'll have sort of hit or miss. Some folks are very responsive to that. You know, exactly what they're thinking and needing and other folks don't. So you can try that. Just recognize that you're not going to get everything out of folks, especially folks that might be challenged in using the current system, may not be speaking up as much as you want using this method. There's also group requirement definition. Group requirement definition is basically getting a group together and in concert trying to figure out what the needs are. Now, this can be tricky. It seems like one of the more obvious ways is like, I'm going to go talk to the development team. I'm going to go talk to the finance team and find out what their needs are. It can be pretty hard to facilitate a successful group definition project. There's lots of ideas that are going to go in a lot of direction. Also, you'll find that there's hierarchies to deal with in these groups. So if you just sort of go to the development team, for instance, you'll find that the executive director, if they're on the team, or just the director of development, may end up talking a lot. And other folks who are subordinate aren't talking as much. Yet the subordinate folks, the development coordinator, for instance, is the one that's probably using the database a whole lot. That tends to be the case. So facilitating these groups can be a little tricky. Sometimes you want to divide that up into the folks that sort of vanish it from the system, like the executives tend to receive the output from the system, more so than use it as far as an input device, or as the person actually generating the report. So you might want to split those up so that you're kind of talking on the same levels and with folks that are doing the same kinds of processes, so that when they speak up, a lot of folks resonate with each other's words and there's more people talking who might be reticent to do so otherwise. So it's a place where consultants can be helpful as well that have done some of this work. So that's group requirements definition. Contextual requirements definitions, another way to get requirements, understanding what people actually do, so what they rely on in the current system for a date on the day-to-day basis, how they use maybe shadow systems or ad hoc systems, where are the gaps. So this is probably the best way to define these. Though it can be really time-consuming. Some folks are going to think really well in terms of context or process. This is how I do my work. They're going to, you know, I do step one, I do step two, I do step three, and I get stuck here. And other folks don't think in process terms. Again, how people think and approach their work is very different. And so you'll find that you get a lot of good information from some folks that are process-oriented and from others that might be a little hard to drive them through context. But that, again, just different methods for different folks is really good to explore as you're gathering requirements. You can ask folks, especially folks that aren't so process-oriented for their vision of a tactical thing. So if you wanted to, you know, find out how they might solve a tactical problem they have, like what would their ideal solution be in the future. So it's sort of like, okay, there's an expression that I cannot, you know, get my emails out because it's sort of too difficult to get all those emails in a list, right? And you might say, well, what's the process? How do you start getting all those emails and they kind of flick out? They're like, I don't know how to talk that way. You can say, well, ideally what would happen? Like, what would you do today if you had to get a list? And they might say, well, I would just love to, you know, push a button and there's this sort of saved list that I did last time because that's exactly the people I need, right? And so they're sort of going to the output or the solution, but it's helping you understand the process as well because you didn't exactly ask it in those terms, but you asked it in terms of a vision statement. So just think about if folks are challenged or processed, try to get their vision for how to get something done and kind of work backwards into the process because we'll be more accepting of that kind of conversation. So individual visions. You can look at group prototyping as well. So this is a great way to focus, folks. This can be especially good if you know that you're going to get a lot of different ideas and push in a whole variety of sort of frames of thinking about software. You can actually help frame people into a set of software you might even be considering or at least a type of solution. So for instance, a great way to do this is to think about a dashboard to say if we're talking about client services, let's say, and we need to know certain things about our clients and our services and our performance, you can kind of outline on paper just a dashboard idea and say, hey, if we needed to know sort of how our organization is running, how we're doing with our clients and services, what would you have in this dashboard? What would we want to see? You can tend to get a lot of folks thinking that way, and the different ways that you prototype can also help you constrain folks to a certain model of solution. If you already know that you're going to be using a solution, for instance, that has that capacity to do some reports and put them on a page, that's something you're heading towards. You can kind of prototype it that way and then folks start thinking in line with the solutions you're going to get to. So it's a bit of an insertion of bias as well, but it gives structure as what it's really doing for a conversation. It allows people to kind of fill in the structure with their thoughts prototyping. And again, prototyping is just saying use paper, right? So we're not building models per se. We're just saying let's outline how this might look and how folks would draw, essentially, together to solve a problem. You can look at a requirement spreadsheet. This is always good. So as you're gathering requirements through any of these methods, you want to start listing those out and start grouping them, right? So we talked about looking at these score idea. I talked about three groups. This one has sort of four groups that they don't need. I don't really recommend that. I like the three group model. I just think you may need it. So why just declare it don't need? So the three group model or the four group model, however you wish to do that. Listing your requirements. Sometimes grouping them by function is helpful or department who requested it. That can be helpful for going back or just finding out who's weighed in to. Sometimes you lose track of who you've talked to and say, oh, geez, I have all this stuff from development but nothing from finance. Grouping them that way can help you remember that. It also helps you remember the source and keeps it doesn't make sense later. Over it was super important to somebody. Maybe when you're doing a demonstration, you'll want to talk to that person about one of the solutions that's being presented. So you go back to your requirements spreadsheet and say, who talked about this? It was Betty, so you go back and talk to her about it. So it's great to have a sort of a vendor comment area. And so what this is evolving to is a way to work through an actual demonstration, which we'll talk about more in later slides. But as you can see, you have this spreadsheet where you can start filling in, sort of going on columns more to the right where there's vendor comments. You can fill in what you've learned from the different vendors into these requirements. So at the beginning you're listing them, but then you're starting to group them and maybe add a few more columns to describe more about the requirements. And then finally, some columns to help you track what vendors are saying and to pick your final solution with the software that you choose. So again, remember to identify your criticals as really critical. Must-haves mean exactly that. If you don't have it, serious problems will occur in the organization. So just be critical on yourself that your needs and the fact that our markets are critical really are that. So I can't emphasize that enough because too many folks get into trouble just identifying everything as critical. That's sort of the planning process in a nutshell and gets you really into the goal setting but then into this actually figuring out what your needs and requirements are. But there's a third piece that's really important to consider and we talked about it in a few slides and that's improving your processes. So what we want to be sure of is when we're getting into a new solution is that we're not stuck, as it says here, with the outdated processes. Your current software may not work for the work processes that you have now. Now again, you might have gotten it in an earlier time when you're doing things differently for a variety of reasons. Growth in the organization, shrinking in the organization, new grants, grants that have ended and started, that sort of thing. It could be that your processes need to change. So you might be sending a printed annual report, for instance, and generating a mailing list for that has been hard, but you might find in the future that a printed annual report at all should be an email one. So that's a new process. The old one, printing them out, getting those mailing labels, the new one, blasting out an email PDF through the system. So thinking about those processes is important. So consider best practices. I'm not a fan of best practices, but I am a fan of better practices. So don't think that you're somehow going to... Everyone writes articles about best practices and don't believe them. They're just better practices and they're good practices to think about. So what we want to do is take the practices we do now and find better ones. It's a great time to talk to people doing work similar to you so that you can find out if their way of working is efficient and reduces time and steps, increases quality. So for instance, if you're a client services organization, there might be others in the space doing similar work. So find out, you know, how do you do intake? How do you do assessments? You know, is their process different than yours? And if so, is it saving time? Thinking about how others do it is really helpful. It's also a great moment to consider a consultant that's specifically experienced in this sort of process area. So not just sort of a generic, you know, business process consultant or someone who helped people select software, but folks that have also worked for, if you're doing a lot of membership work, let's say, has worked with membership organizations. So they can already speak to the processes that you're involved in. Right? And they can say, hey, I've seen processes like this in five different ways and this is what's been effective. So they can help you kind of open your eyes to that as well. You can also consider pilot projects when you're considering better practices. So for instance, you might have an idea of, okay, this process is going poorly and we've had some ideas for how to make them better. We're not sure if they're going to work, but maybe you can do a small trial of how that might work. Don't get the whole organization going on it, but say, hey, we have this one small, easier project. What if we did things very differently in terms of intake? And just try it out and see how it works. Get a few motivated folks to devote some time to that. And if it fails, abandon it. Early when it fails, no problems. That's the point of a pilot. Don't be scared of failure. And if it works, take that data and evolve that into a better practice for the whole organization. You'll want to map your business processes. So you'll choose processes that you want to improve. You'll get this stakeholder input. Document the process, right? So you want to see, like, what is this process in an outline format or some visual mapping? Find out areas that you can improve, right? It really benefits from talking to folks as well that know about a lot of improvements. Make those changes. You might have piloted some. You might want to pilot some after you've done some analyzation, and then finally figure out if those are changes that you should do. Evaluate and continue to improve. As you might imagine, processes don't necessarily have to wait to be improved for the new software. They certainly can be enhanced when you get the new software. But you can start thinking about your processes and improving them well before the choice in the software, because a lot of stuff is going to be the regular work that humans do moving step-by-step through a process that only gets enhanced by new software. It's not a dependency. So you can think of these in actually kind of two tracks. So whatever you're doing to understand your processes and improve them for the purpose of getting software is also beneficial on its own as a project, right? That could be really nice because you can get value out of a software selection process just by improving your own work, regardless of what you choose going forward. Something to think about. So common ways to get input, you know, start with, again, with the stakeholder input, folks that are really stakeholders, me and folks that are sort of involved in the software in some way, they either receive benefit from that or they're using it directly. Again, what's working well? What drives you bonkers? You know, where could there be some improvements? I wanted to share a couple of resources for getting an input. Now we talked about that in some of the slides, but you can read more about it. So I'm just sharing my screen here. I'm going to paste three links at this point. There we go. So we have a couple of resources here. How to conduct a focus group by Judith Simon is, and it's also, you can go to this link, but it's also a book. It's really talked about quality surveys. Surveys can be hard to build a successful survey, but reading this can give you some tips on how to survey a group of folks when you're getting stakeholder input. You can also read about focus groups as well on these links so that you understand how to really arrange a focus group and drive it forward and get the results you need out of that focus group with the input. Okay, so we talked about, and part of this process of making a physical map, being able to see a process visually on the board. Now, this photo here has a ton of sticky notes. I mentioned earlier that sticky notes aren't all bad. It's bad as your database, certainly, but they can be really good for looking at processes. So your process may not be this complex with the resilience of sticky notes, but basically how this approach works is that basically on sticky notes, you can put ideas and process points on a sticky note. So like a sentence, right? And it's easy to move around that sentence. So the process might be in the middle, but then someone decides it should be in the beginning or eliminated entirely. So just by the virtue of the sticky note, you can kind of have a collection of words together and move them around. That's what makes it a great thing, especially when thinking through a complex process or one that might turn into several processes, even though you thought it was one. So in this case, you can think of sticky notes having tasks, things to do in a process. You know, maybe colors of sticky notes or who's responsible. So you can see where departments weigh in. It's like everyone's weighing in in the middle part of the process or in the beginning. And you can see that by color. Sometimes you might put in the bottom corner, let's say, of each sticky note, what system is used for that task. So as you're moving through the tasks, there's different tools that are used. In the beginning, maybe I'm extracting some data from my central database, but then I'm going to Excel to modify it, and then I'm going to Word to make mail merges. And you can kind of identify that throughout the process by writing a note in the bottom or even putting another little round sticky color thing just to have a visual sense of what's going on. It's great to do this on a large whiteboard. So you can kind of, you know, it's like, what are all the tasks in this process? It seems like we do so much stuff and people write it down and they put it up on the whiteboard and you start moving these around to get them in the right order. Then you might write some words that sort of describe the collection of tasks or improvements sort of right on the whiteboard, right? Kind of a neat way to do it. So again, it's just a model for figuring out processes that isn't so kind of, you know, linear. It's more visual and it's not paper-based. And it's also good for conducting with groups if you want to think about things together and collaboratively. You know, a new process map, you know, sort of if you map your processes and define what's better, you'll find that you can take advantage of new capacities that software may have to offer. So, you know, some new data analysis capacities are typically things that people start to find benefit from when they're defining and advancing their processes. It's sort of like, well, now that I have a better process from capturing the data in one place, I now have this opportunity to analyze that data that I couldn't do before, maybe correlations between volunteering and donating. I didn't have my volunteers in the system before, so I had no idea or it was difficult or we're just sort of guessing based on our understanding. Now that all that data is integrated, this becomes possible. Maybe it was difficult to get reports on a timely basis because they were difficult to generate, but the new system, you know, can automate this delivery. So that plays into your process too. You're spending a lot of steps getting the reports and you realize that that's a problem and you need to minimize that. The new feature you might be looking for is sort of sharing reports or scheduling them for delivery, that sort of thing. You know, push button integration of reports to email blast tools, right? So another feature, you haven't been doing that before because your old system has all the contact information in five places. There was no push button approach to that. So you look at your process and have all those steps and combine them into one, which is basically give me a report of all these variables and push a button to get it into my Mailchip or my EMMA or my constant contact solution that needs blast people. So take advantage of these new capacities, especially after you started to define and refine your process as you can group those steps that really should be handled by a technology as opposed to humans. So just sort of take a look at this in summary. There's some key questions you want to consider before you, you know, jump into the actual review and selection of software. So, you know, do you need a new system? As we said, you know, the future, look at the future, where you're heading and is there a lot of dynamic change? What does that mean? The return on investment. Make sure that process is right sized for you so you're not doing too much for a small system or too little for a large system in terms of planning and process mapping. Definitely look at how you can improve your processes. Even in a small system, just take a look at that and make sure that that one process that's going to handle is the best one for your organization. And what kind of changes the organization needs to make for the software to work? So that's when we haven't talked about too much, but basically what you're trying to say, figure out is for this new software and these new solutions, do we have people that need to be more or less responsible for different points in the process? You know, it's part of the problem that we don't have enough, but IT supports us to keep this thing running or keep folks trained adequately so think about those things. Prioritizing, of course, your requirement is making sure your critical list is, in fact, the most critical. So that gets us through all those planning steps that we can now start thinking about evaluating our choices. So this is now where you can actually start looking confidently at software. And the value of having this at the end, as I mentioned before, it's really about being confident that when someone throws a bunch of bells on a whistlelet, you can think through that and be like, I'm interested, I like those things, but I also know what my needs are and I'm not unduly influenced by the marketing. Keep in mind that as you explore options, you're now entering the realm of sales. Folks really want you to buy their stuff and so they're going to tell you why these things are good for you. You know, and a better sales person is really thinking about your needs with you as a partner, but there's many, many more that are more thinking about making the sale. And so it's up to you to sort of parse that out. So doing this planning up front will give you that confidence that you can do this. How do we get going with actually figuring out, okay, what are the products we're going to look at? You'll want to research a short list. So you don't want to just sort of go to a big list of here's all the donor management solutions. I found a big site of all of them. And then start going one by one through them. I mean, you're going to find hundreds. It's just not going to work. So you want to target, you know, maybe two to five systems, maybe two for the more sort of smaller project that we said, five for the larger investments. You know, the more products, of course, the more time and expense it costs. So again, when you're right sizing your process here, if you're looking at more solutions, it's because you have a bigger system to handle and it requires a stronger evaluation, right? So maybe up to five for the larger projects. So how do you build a short list? It's great to do research on sites and resources that have more than this basic list of, like, I found all the donor database software, right, and just list them, but provides pros and cons, reviews, that sort of thing. There's many resources for this. So some of them are up here on the slide. I want to paste in some as well. Let's see. If I got these here. Oh, yeah, here we go. This is about four. We have the Nonprofit Times has an article that's really great about software and has a great list that you can use to build your short list. Let me paste it right here. Here we go. Yeah, so the Nonprofit Times has a special report on donor software, and that's that link. There's also PC Magazine has a report on membership-based software. Again, these are lists that are annotated and it has some reviews. Grassroots Fundraising Journal, which, if you haven't heard of that, is especially good for the smaller organizations, has inexpensive reports that they do cost money, but they're inexpensive on data management, donor management, and a variety of tools. So that could be a useful report as well. N10 and TechSoup and Idealware, of course, as we mentioned, N10.org, TechSoup.org, Idealware.org. These are three places where you can find software reviews. In particular, N10, which is N-T-E-N.org, and TechSoup.org have discussion forums. So that's different and allows you to kind of ask other folks that are doing this work for nonprofits, as well as nonprofits themselves, hey, what do you use? What's your shortlist? What did you consider when you were making the choice to figure out what software to review and choose from? So N10 and TechSoup are great places if you don't already know organizations that are like you that you can talk to, you can certainly find them through these kind of discussion forums that are targeted towards nonprofit organizations and technology. So that's why it's great to go to those sites and check them out. You can also look at your local nonprofit association. Often they've done some review, N-Tap, for instance, that you guys are all part of, provides a lot of great resources and folks that are like you to talk to you and find out what your shortlist is. People will be at different places. You're picking a software that someone else has and works really well. Likewise, you might have a software that someone else doesn't have and you can share your expertise as well. So knowing peers in your space is really, really good.  So if you're in a more rural environment, it can be good to just go to business associations. Sometimes they'll be more than happy to help because we don't get a lot of requests and they'll be kind of a partner in getting this done. So just think about that. If you still have a list that's really long, think about what's critical for your organization that's really straightforward to check. For instance, if it's really critical to have an online interface, you can eliminate everything that is locally installed and you're not going to support some kind of crazy way to log into your own network. It's just too much for your organization. You can just eliminate those. If you have an absolute price issue, you can eliminate ones that start at a higher price, for instance. So think of, if your list is still like 8 or 9 or 10, think of the key criteria that are easy to check that eliminate, you know, they're called the gateway criteria. So eliminate tools so you can get down to a more manageable list. You can also just start to understand of what you're asking for is even possible, as it says here. So you may have something that you've identified as critical, but it turns out none of the softwares are doing it in your list. That's something you can tease out usually better with an experienced person like a consultant or another peer in your space that's done this work. They might look at your requirement and go, that's crazy, I've never heard of that. And then you might put that one out as a gateway criteria and say, well, a lot of people are saying they never heard of doing this. So I'm going to put this up front and decide, can I find any of these softwares in my list of 10 that do it? If not, that tells you a couple of things. Maybe that criteria shouldn't be something you have. Or if you really need it, that might be something you need to focus on in terms of getting some customization and allows you to eliminate softwares that don't do customization. So think about that. You can consider what's called a request for information. This is sort of a more formalized document where you might sort of define your needs and requirements and have folks respond to it. If you have a huge project and budget, a longer or sort of a formal RFP or request for information may be a good thing to do. If you don't, sending a bunch of vendors something you've written up to win her down your list is likely to backfire. The vendors that are busy, which are a lot of them, just won't respond. And you'll probably only get responses from folks that are super hungry for work. And that could be okay, but that could also be folks that just aren't doing so well. So usually what you want to do is instead of going sort of large of the RFI or the RFP process, you can ask a handful of questions that have straightforward answers from vendors. How do they support volunteer matching? How would you track the inventory of food available or whatever their requests are and send those to vendors or call vendors and just ask them a series of questions to sort of eliminate folks from the list? So the benefit of having it sort of documented in like one way to ask the question is that you can internally evaluate and compare across vendors how well they're doing. But again, you don't have to necessarily do that in a formal way. What you basically want from an RFP or an RFI are things that you can track with checkboxers.  I need to have vendors sort of weigh in on a lot of things so that it makes it easier for us to evaluate what's a good solution. You want your sort of request document to the vendors to be more checklist items so that when you get the responses back, you can kind of check off, did they meet this, did they not meet this. The more creative input you ask for, like how would you solve an end of your appeal for our organization? And then you get like lengthy paragraphs to describe that. You may want to just know, can I blast email people from a report or something sort of more tactical, more checklisty so that you can get answers quickly and analyze this fast. So consider that, again, probably for larger projects. Choose systems to demo. You can do like a short demo of a number of systems. So for instance, that can help you narrow it down. Sometimes the demos are online and that might be enough. It's like, okay, they have a walkthrough. You don't even have to schedule. And you can kind of look at that and say, oh, it's hitting or missing some of our gateway criteria. So that's something you can do. But definitely when you get to your short list, you'll want to get into sort of full-on demonstrations from the organization to really make your choice. So let's talk a little bit about what it means to have a demonstration with software. So if you've been through software demos before, it's great as a team to ask yourself, what worked well and poorly in the past demonstration? It's good because it takes a lot of time to set these up and then you have to spend time listening to them. And if you've found it kind of ineffective before or it was aspirating for some reason, it's good to find out why so that we can solve those problems. It also can be nice if you have a consultant or a peer in your space that maybe has been through this before, or maybe especially in the first demo, but even if they could sit through all of them if they're that generous, it's good to have that kind of more expert or seasoned person that can help guide you a little bit more in thinking about what the vendor is saying. So just something to consider there. But basically with demonstrations, you want to contact vendors and set these up so that they can have a demonstration set up for you. And that seems obvious, but it's critical. A lot of our vendors won't do that. It's surprising, but still true. They'll say, hey, you go watch this video or something. And then those canned things, again, can be nice, but they don't necessarily answer all your questions. So schedule those live demos and make sure you have the way to have all your team watch that demo from their computers wherever they're at. You'll want to send a list of questions in advance to everybody who's providing a demo to you. So they have a canned dog and pony approach for all their demonstrations. Quite commonly, they're not getting a list of questions, so they're going to talk through it the way that they think. And they're still going to do that, and that's important because there's a way to think about how their software works that they've figured out, and that's a good thing. But you also want to set up questions for them in advance so that you get your answers met. The good questions to share in advance is anything that requires setup or thinking. If it takes you a lot of steps to get something done and you want to know how the system does that, it's good to ask that question in advance because if it takes a lot of steps in the software too, they have to think about it and make sure that they're going to actually be able to do that on the demo in some way. They can't really do that on the fly. Those reports you want to see, that report might not be built in the demo, so it would be good for them to sort of do something there. And so asking that in advance is good. Processes that you need to see, I need to see how your membership process works, how you support volunteers and volunteer profiles, do you accept payments? What's the process for accepting a payment? Those are multiple step processes, and so that can take a little time to set up. And again, making sure you're always focused on your critical items there so that you're getting as much warning as possible on the things that really matter to you up front, and that way you can get your answers met. The devil is in the details, so you want to be specific. You don't want to just ask for donor reports if you're researching donor databases because everyone's going to say, yes, we have them. And then you're like, well, actually, I was looking for a certain donor report. We have this complicated one, and I don't know how that could be done. And it's very critical to our organization. We can say it's this kind of report. It has this information on it, and we use it in the following way, and that's the most important thing. So a strong vendor is going to be inviting of this, and we'll receive your questions, and we'll respond to them as part of the demo. That's something you should be able to expect from your vendor. Good questions to ask during the demo, again, still relate to your critical needs first. The questions you want to ask are clarifying. So these are, as the demo is going on, you need to be aware that they're trying to explain something in an order that makes sense. They might want to talk about receding a donor right after they add a donation. Those kind of go hand in hand, and so it makes sense for them to talk about it. It doesn't always make sense for you, but it's good to have them complete the thought. And if you don't understand something, they can keep moving forward. Understanding, certainly, if it just doesn't make any sense at all, right? It's not just sort of saying, what did you mean by the term or whatever, but I don't know what you're showing me. Make sure you're, especially if it's around a critical issue, interrupt and ask those questions. The clarifying questions, the understanding questions. Asking folks on the spot to walk through a major process that has a lot of steps again is not a great idea. You're going to get a lot of pauses, a lot of clicking on screens and waiting for things to load and so forth. It's good to send that stuff in advance. The other kinds of things you want to do during the demonstration is enforcement-style questions. And what I mean by this is if you've asked something in advance and you're not seeing it, so you ask for certain reports and they showed you reports and those reports that you asked for aren't there. Enforce, right? Say, hey, we sent you this kind of report. Can you show us that? And if they fall down on that, that's good information, right? Even if it's awkward. Remember, this is your demo. Don't get distracted. Make sure you're driving the meeting, but they could distract you with something that's really kind of interesting that you haven't thought of before. But remember, you might only have an hour. It might be difficult to schedule another one or take two weeks or something like that. So you may want to follow up on that, but make a note of that and then move the person along. Right? So, you know, a good demonstration and a person doing the demonstration wants to convince you. So a good presenter wants to know when they're off base as soon as possible. So remember that it's a service and it should be seen that way and a lot will receive it that way. So don't think of it as like, oh, gosh, I'm going to do another interruption. Some folks might treat it that way and then you've learned something about that friend here. Maybe they're not such a great communicator. So, you know, definitely consider that interaction. Can presentations where they're just not flexible, even though you've given them some warning and so forth, tell you something about how that support, for instance, is going to be flexible in the future? You know, it might not be a great fit. Bad presenters often indicate bad support as well.  So it's not something you should take lightly. And we know that ongoing support, as far as certainly getting a new software, as well as being able to keep our team using it well going forward, is a lot of time spent. So you want to make sure that the partner you're using can help you with that and our good communicators. Definitely take notes. You can use a template for note taking. Everyone, first of all, should have this in front of them, and it should be the same template you use for all the vendors. It can be based on the question list you send the vendors. It can be that requirements list, again, where you have vendor comments. You know, finalize that before you go to the demonstrations and everyone sort of fills that out, and then you can meet afterwards to compare notes and sort of make a conclusion on that vendor. You can also make sure that you don't forget anything, right? So often, without a list, you can get undistracted pretty easily and you forget where you're at. In this particular picture on the slide, there's a list of requirements, sort of maybe it's from your requirements list, but there's also the actual text of the question you might ask. So you may have sent some of these in advance to the vendor, but it also helps you have some confidence about what you're asking to get the answers for several of these feature areas. And that can be great guidance so that you're making sure you're asking the question that's going to actually elicit the information you need per each feature. So take notes and make sure that that note format really helps you drive the conversation as well. Preparing that can be super helpful. So looking at evaluating your choices, you know, really the most important question for these softwares is certainly, you know, does it have the features you need? How do you evaluate this? You know, is it weak or missing any critical items? That's usually what we mean by a weak system. This is probably a deal breaker. It meets your critical items on your list, but some of your important secondary items isn't where it can get a little dicey, right? Because you'll be comparing three, maybe four systems, and maybe they all meet your critical needs with a different combination of important but secondary needs. That's where you start to have to think about which one is right for you.  You know, how are you going to prioritize this? Maybe it has all the features you need, and then some. It meets all your critical needs, nearly all of your important but secondary needs, and several of your wish lists. You're thinking, well, that one just on paper looks good. But it might seem complex to use, right? And you have some issues of the support. You're not sure if you can learn it. It seems hard, right? That's a good thing to explore because remember that with the power can come complexity and complexity costs your team time and getting folks adopted to it, trained, right? And then ongoing training going forward. The more folks you have that are using it, the more that cost is going to magnify. Only a few folks use the system and adopting more complexity at front might not overwhelm the cost, right? Because only a few folks are using it. Does the system organization make sense? This is really the display. How is the flow of the system screens? Does it match your steps, or are you awkwardly jumping around out of order? So think about that when you're especially doing these demonstrations. Is it hard or easy to find your critical list items? That's super important. We should care a lot about security. You know, often, like states like California have important laws about security breaches. California requires organizations to notify constituents in the event of a breach and, like, a data breach and send a copy of that breach data to the attorney general. Now, that can be really embarrassing if you have to inform all your donors because it's a legal requirement. So, you know, it's good to move information security to the front burner. You don't keep it on the back burner. But not meaning to scare you. Stay calm. You know, vendors are very concerned about this, too. Their business is giving the software over and over and over to folks, right? Especially as software as a service is online. And so their customers will flee and droves if they've learned that the vendor has a massive breach. Nobody's going to buy their stuff, right? But make sure they can explain it in non-technical and technical terms. You know, a tier one data center has a lot of sort of security requirements met. So that's a great question to ask. Ask about backups. You understand how you can get a backup and how they do backups. Do they test for vulnerabilities? Is that posted? What do they do in a data breach? Also a good thing. Can you restrict data by users so that you can control who has access to your own data? Really good questions to ask. So compare implementations as well. You want to, you know, look at what it takes to get these things done. You want to specifically ask about data migration. It's good to be able to explain to vendors. This is a good advanced question to ask a vendor before the demonstration. You know, we have this kind of data. You know, 1,000 contact records and 10,000 donations related to that. And these are the kinds of things we do. You know, can we migrate that data and how would we do it? There's often extra costs for doing that work. Migration is a big headache. Some will have a robust service for doing that to get you on board, and others will have sort of a self-help solution, which can cost you a lot of time and money. Could be a good thing, but it's good to explore how that works. You'll also want to look at support and training. Look at, have them talk to you about what training or support is available. Does it cost more? Is it visual? Is it written? Can you call folks? Can you email folks? Can you schedule live trainings or your own trainings? You know, sort of ask about that. What do they offer? What are other nonprofits' experience getting these tools off the ground? You'll want to look at also cost, right? Of course. Cost is fundamental. So find out, you know, what it takes to get this done. What are the licensing? What are the costs for payments that you generate through online payments, through folks giving donations online? Are there not only ongoing software licensing costs, but ongoing support costs? Is it going to cost a lot for migration? Figure that out, because we know that's a big headache. Do you have to buy hardware in order to support this or a better internet connection? Just think of those kinds of fees.  Ongoing support from an external consultant is a big one. If you're going to be using them to help you maybe configure or customize the solution because the vendor doesn't do that, that's really important to understand. And then, of course, your own staff time for just getting it up and running costs money. As we know, we can convert staff time to cost and figure that out as well. What about open source? A lot of folks will say, well, with cost, open source is free, and so I can eliminate a ton of costs by getting open source. Just remember that no software is free, not even free software is free. You're going to have to set it up, configure support, keep it updated. As we say in the slide, open source software is free like a puppy. Care and feeding is critical. It's good to chart your costs. This is kind of one way to do it. Now, on this chart, we've listed the possible systems, like a cloud-based system, an installed system that's locally installed on your own network, an open source system. But you can imagine listing the products instead there, product A, product B, product C. And just think about all these costs. What are the costs up front to get the licenses to use it? There's a cost to set it up, customization, onboarding, those kinds of things. There's all your upfront costs. Up front training. Now there's ongoing licensing fees. There might be additional ongoing support costs. So depending on the solution, some of those costs are going to be much more upfront or much more ongoing, and then that's going to, your total cost over one, two, or three years is going to be very, very different. Definitely leave yourself room for the implementation, so it's not going to just happen on its own. It's going to take some time. It's frequently an underestimated step. The two areas, again, I cannot emphasize enough, it's underestimated the data migration and getting folks adopted to the system. That's the training. The data migration and the training are usually two key areas. You want to have a good understanding of how they approach that so you feel comfortable with that work. So finally, we get to making your choice. It's finally time to choose. We've been able to review them. We have all our criteria. We have all our notes. So now we can take a look and see, you know, who we should choose. Make sure you review your critical list. You know, stick to your budget on your critical list. That's easy, and you probably defined that early on. And so you'll want to look at those tools and make sure that you're really within your budget and not expanding at what you can afford. You can't say everything is critical. So it's another good time to refine. There are these things that are critical, really critical after we've done all these demos and you need to revise that. That could be really helpful to making the choice that you need to make. Consider your score. Again, you might have scored them as part of your process. So when you wrote vendor notes or that template, you could kind of come back as a group and say, hey, how do we think we, you know, they scored on all of these items and have a way to do that. You could do that at the end, too, here. So when you, you know, at this choice process to sort of boil things down to a number, you might not want to rely fully on the number, but it helps you kind of really think and calculate where one vendor sits with another. You want to evaluate the vendors themselves. So just check out how long have they been around, you know, check out their media bulletins that they've been bought out and bought out and bought out again. That can cause instability. You know, log in to their support material. Get the log in if you have to or just cruise their site and find them. Do they have any? Do you understand them? Do they make sense? Do they seem weak? Where are all the options? They'll explore them, their track record. You can ask peers as well what they think if they've used them for a while.  Paper rock scissors, all right? It's just not as surprising as playing that game. So calling references is very important. You can get references from the client. Of course, they're always going to be great references. So the vendor is going to say, here's my top three references and they're all going to say wonderful things. You can go to TechSoup.org and 10.org or your peers and find out who's really used them or what they think and talk to those references instead. What surprised you once the system was up and running? What did you wish you'd known before you got the system? Why was the system a good fit? These are key questions that are really great to ask. Just to let you know, we're running near the very end of time here. If people have got questions, please put them into the question box or raise your hand as we're running through the last few slides here. I also just wanted to comment on that last one about getting references from people who use the software and not just the vendor's own references. Extremely helpful. And the LSNTAP email list, there are lots of people on there who've used lots of software. They are very happy to respond to you privately and give you very confidential and honest evaluations of different software vendors, their services, that type of stuff. So please feel free to publicly ask for those things and then people will give you very candid responses offline. That's a great tip. Very good, very good. Make sure you own your data. Make sure that you can pull that out. Normally you can, but just ask those questions and look at the agreement and make sure you can get all your data out and you can actually have the vendor prove it so that if you ever have to move, you've got your data as well. Just a couple more and I'll be able to get some questions here as well. So uptime, it's great to know especially for hosted software is how much is it up or how much is it down. So these are usually in like 99% up, 99.9% up, 99.99% up. So just sort of figure that out to see how much downtime there is and usually that's a published statistic for many. Sometimes you have to extract it from the vendor. So just remember you need to get truly what you need. Be thoughtful and confident. They'll get caught up in the latest trends. You can do this. You guys know best what you need as an organization. You've done the work. Just be confident and direct that vendor to make sure you get the right software that you need. So at this point, I believe you're all ready to get started. I wanted to switch to a slide that just shows some Idealware resources here. So I've got one here. Idealware has a bunch of topics you can just look up on the site that may be helpful for you. And I wanted to just pause my screen as well and put one report that's come out fairly recently that's new. This is the Idealware Consumer's Guide to Donor Management Solutions. There's a bunch of consumer's guides on different kinds of software, but this one has come out recently and it's focused on donor management. It's a really good way to get a short list if you're focused on that. There's other consumer's guides that can really help direct you. So check that one out as well. All right, good. So I think we've got this covered. I'd be happy to take any questions if some have come through the chat. Yeah, I'm not seeing any questions right off. This is a new topic for us and a lot of information there. Really appreciate the practical advice on it, especially on calculating your ROI, trying to scope the project as much as possible at the beginning so that you get your kind of boundaries there, and also looking at not just automating the systems that you currently have or that you are replacing, but going to the vendors and figuring out what is possible so that you can really scope in new business workflows or other things that may be significantly different and improvements. Yeah, that's right. And I think there's a... I'm going to get back to... This slide, I think, it really kind of summarizes the whole thing. So we talked about a lot of ways to get through this planning process in detail, but when you summarize it all up, you're thinking through your needs. You're defining your goals, doing your research, and basically you're trying to plan ahead before you actually choose and do the implementation, right? That's what it's really all about. You've been thoughtful about what you're choosing. Just a quick story. When I started my consulting, one of my big early projects was evaluating why an online community system wasn't working for a foundation that should remain nameless. And this project, they had spent $75,000 on to get all their grantees to use this online community system. And as I went through the requirements gathering, the interviews, the goals, all that stuff, I found out that the system was entirely too complex, number one and number two. All folks really wanted to do with email each other, the group. That was how they were going to solve the overall goal of let's collaborate on shared projects. So the recommendation was to replace the $75,000 system with a $3,000 email listserv, right? That's an example of an organization that bought the bells and whistles before doing the planning. This happens all the time. And so after going through this work, you guys are much better set up for doing the thinking and making wise choices going forward with your software selection. Great. Any other questions that have come in of this last minute here? No. Just a positive comment over a great presentation. Please, I'd like to remind people that the slides are available for download along with the kind of guide for selection. It's a very short article that covers these points in kind of a two-pager to it. It's a great takeaway. We should have this video up in the next two, three weeks. It'll be on our YouTube channel and available for people to review. Thank you so much for taking the time and chatting with us today. Greatly appreciated, Eric. Great. No problem. Thanks for having me. I appreciate all your time and effort setting with that. Thanks so much.