Video: Building a Better Nonprofit Software Selection Process

Transcript below!

View Video

Listen to Podcast

Like podcasts? Find our full archive here or anywhere you listen to podcasts: search Community IT Innovators Nonprofit Technology Topics on Apple, Spotify, Google, Stitcher, Pandora, and more. Or ask Alexa.

Building a Better Nonprofit Software Selection Process:
Ask the Experts Webinar

To be successful with selecting new software at your organization, you need to start by identifying and planning for the organizational change that will occur within the future implementation. This is true no matter what type of software you want to choose: CRM, ERP, HRIS, digital engagement, program management…you name it. 

In this “Ask the Experts” webinar co-presented with Build Consulting, we answer your questions on ways to create a sound process for software selection, before you consider the specific technologies available to meet your organizational needs. 

Join Build Consulting co-founders Kyle Haines and David Deal as they leverage their combined 70+ years in nonprofit technology projects to answer your questions about what makes a software selection successful.

As with all our webinars, this presentation is appropriate for an audience of varied IT experience. And Build is scrupulously vendor-agnostic.

We know our nonprofit colleagues will be called on over the next few years to provide more support to our communities than ever before. Put your best foot forward now with technology decisions that allow you to focus on your mission.

Presenters:

---

Transcription

Kyle:  Hey everyone, this is Kyle Haines with Build consulting.  We are just about ready to get started.  We are going to wait another minute or two for people to join, for folks joining from the West coast, they might be grabbing lunch, so I’ll go back on mute, and we’ll be starting the webinar shortly.  

All right, let’s go ahead and get started.  We are recording today’s webinar, so for folks that joined in late, your colleagues, friends, family, please let them know that after today’s webinar, we will be making a recording available.  I want to welcome everyone to our webinar for November 2020.  We present it in partnership between Build Consulting and Community IT.

In today’s webinar, two of our experts are going to be answering questions that were submitted in advance of the webinar that will hopefully help you figure out how to select the best software for your organization.  We’re going to be covering questions about software selection, about project leadership, change management, how to involve stakeholders and what you should think about when you’re evaluating platforms, when you’re thinking about changing business processes and more.

You can read more about this topic in our blog, it’s something we talk about frequently.  We’ll provide a link near the webinar, and if your question doesn’t get answered in today’s session, please contact us for an answer.  We’ll give you some information about how to contact us and we’re happy to answer any questions that we are not able to get to.  

So, a little bit about Build and Community IT, these things that we share is that we both exclusively work with nonprofit organizations and we help them make informed decisions about technology and information systems that’s going to ultimately support their mission.  We both approach our work collaboratively and we’re most satisfied, I think when we are able to empower our clients to make informed choices for our organization.

How Build Leads in the Social Good Sector

Some of the ways that Build leads in the social good sector is that we work on projects that range from assessments, to selections and implementations.  We also serve as part time and interim CIOs, both David and I, who’s on today’s webinar with me, are part-time interim CIOs and then lastly for clients, we work as outsourcing CRM managers.  We were founded in 2015. Our goal is to help nonprofits transition, sorry, nonprofits transform themselves using technology. That’s our mission and it pretty much motivates and organizes everything that we do.

Part of what drives our interest in today’s topic is that our analysis combined with our direct observation of hundreds of organizations, that the success rate for nonprofit technology projects is under fifty percent and the reality is that oftentimes this is because technology is moving forward, but the organization is not.  

We show this visual to all of our clients. It usually resonates, it gets a laugh, sometimes rounds of applause.  It stands for old the organization plus new technology equals expensive old organization.  So, our belief is that in order to take advantage of any new technology, it’s your organization that has to transform to work in new and hopefully better ways.

Meet the Presenters

So originally, there were going to be three of us today, unfortunately Peter Mirus is not going to join us.  He was going to serve as the moderator, so you’re stuck with me both moderating and presenting today. 

I am Kyle Haines. I am a partner at Build Consulting.  I was one of the founding partners, I have a long history in nonprofit technology.  It’s pretty much where I have spent the entirety of my career, including working at a nonprofit, for the first five years of my career and I am happy to welcome David, one of my colleagues and he is the other expert for today’s session.  David, why don’t you take a moment to introduce yourself?

David:  Thank you, Kyle.  I am really happy to be here today.  I’ve also spent my career in nonprofit technology, I did my first software selection around 1995 or so, so I’ve seen and evaluated a lot of different software products and vendors for nonprofits during that time. So, also one of the cofounders at Build, originally the founder of Community IT, way back in the day. So, I am really happy to be here today.

Kyle:  Great, and the truth is that David and I don’t really get to work on that many projects recently.  So, today is going to be really interesting because I know obviously both of us work together, but we have different experiences with different clients and so David, I am super excited to hear your answers to some of these questions and I am sure I’ll learn from you today, as well. 

David: Likewise.

Kyle: So, we’ve got a bunch of questions—what’s that?  Were you saying that you are probably going to get more from me than I will get from you?

David:  Exactly, I technically said likewise and that’s a good paraphrase.

Kyle:  So, we’ve got a bunch of questions in advance and we will try to boil them down into eleven that we will plan on answering during this session.  If we have extra time, we are going to answer questions we get during the webinar. There is a chat function within the webinar; hopefully at this point everybody knows how to use those.  Please feel free to submit your chats or your questions rather and David has volunteered to keep an eye on those and if we have time, intersperse them in today’s presentation or get to them at the end.

Succeeding with a CRM Implementation

Kyle: The first question, last time we did a big CRM project, it didn’t work and how can we prevent that in the future?  And David if it’s cool with you all, I will take the first stab at this.

I know earlier we had earlier we quoted the success rate of fifty percent of technology projects failing.  This is entirely anecdotal but I’m guessing that less than ten percent of the time, it’s really about the technology.  My experience has been that if a project is failing miserably, oftentimes it starts at the very top and it starts with perhaps a lack of leadership alignment or leadership buy in or leadership support.  So, for those of you who have worked with us in the past or read our blogs, change management is something that we think is really important and I know for me, really fully appreciating the value of change management and really understanding that a big part of change management is not only focusing on the people who are going to be asked to make the change, but it’s also focused on the people who are expected to endorse and advocate and champion the change.

So, some questions come up for me and this question about how aligned was the leadership in a project that was failing miserably?  I would also – I think the last question that comes up for me is whether the project has truly failed miserably?  All shouldn’t be lost.  More and more, my experience is that there is enough commonalities around CRM products that it’s unlikely again to go to my earlier point, it’s unlikely that it really is owing to the technology.  So, I would be looking for ways to salvage this project and the salvaging of it may start, as I said at the very top.

David:  So I think Kyle, I will quickly add a little something to that.  I agree with everything that you said and I think that another thing that’s important is just making sure that internally, you are really bringing certain types of leadership to the project.  Certainly project management, which everyone probably already thinks about but I also think about communications plans and I think about a change management lead and roles like that in a small nonprofit, maybe project management, change management, communication plan is something that one person can be responsible for.

At a larger nonprofit management, maybe those are distinct roles on a specific project, but filling those roles, all of those roles, it’s really important to the success of any enterprise of a nonprofit project.  

Kyle:  My wife would probably kill me for not having made that excellent point David, because that’s exclusively what she does for a large corporation is, there’s a team that entirely focuses on internal communication and obviously much of that is around change itself and so that’s a really good point.  I had forgotten to mention that.

David:  I’d just point out this is being recorded, so thank you for that compliment.

Kyle:  I think we have pretty sophisticated editing software, so I am anticipating we will edit that afterwards.  All right, let’s see what the next question was.  

Software Selection Tips

So, we are about to select a software system, what are the top two or three things that we can do to make the selection successful, more successful?  David, why don’t you take that one?

David:  So yeah, I am eager to answer this one.  I think, I will quickly say it’s defining requirements, it’s engaging stakeholders and it’s really going through extensive demos – are the three things that I would really like to focus on.  There’s a lot more that goes into a successful software selection project, but if I want to narrow it to three, those are the three that I am going to call out.  So first, I am going to say know, defining requirements is important, because a lot of times people within a nonprofit, don’t even fully agree on what they’re looking for or what we are finding through the definition process, is oftentimes it’s a great opportunity for people to learn what other people in the organization do, as part of a process that kind of spans teams. So that’s really an internal discovery learning and alignment process there, the process of finding requirements. I really recommend that as oppose to just inviting vendors in to demo their software.

The other reason that I think it is really important, is making sure to engage all stakeholders – so if Communications is a stakeholder and Organizing is a stakeholder and Programs is a stakeholder – make sure that those different stakeholders are represented in the selection process. Otherwise, you end up with communications getting an email marketing solution that doesn’t meet Organizing needs, maybe it works for one use case but not another. Or in larger organizations, you may get into departments selecting software that doesn’t really fit well within the larger ecosystem of technology and information.  So, I think the third thing I’d highlight is just, when you get the demos from the finalist vendors, I really think it’s important to ask them to show processes end-to-end and basically give them a script, give them space to share, you know, the dog and pony show I call it, but also ask them to demonstrate specific processes from end-to-end that really relate to the things that you’re trying to do as an organization. I think that needs to be with the same group of attendees, seeing all of finalists.  I think you need to do them relatively close together, not weeks apart but days apart and I think you need to capture feedback from those demos as soon as possible after you see them.

Kyle:  One of the things, I thought an interesting point you made David, is the extent to which this process can be educational and how if I heard what you’re saying, sometimes when you get out of this process is new awareness internally around what your colleague are doing or new understanding of the difficulty in which they do the things that they currently do and how this software may change that or the extent to which the constituents they interact with, if you’re talking about CRM, are impacted by technology that you don’t have or they envision how those constituents are going to be engaged with as a result of making a selection, so the idea of education I really like.

We have eleven questions I think, so I am going to move on to the next one.  

Benefits vs. Cost

Kyle: Any change requires a cost to your institution; how do you weigh the benefits versus the cost? The example they used was retraining all their users. I mean, it sounds a bit obvious but trying to get to the ROI, a return on investment, on making a change is probably a most direct way of understanding the benefits versus the cost. I think prior to investing energy in costing out what the solution is going to be, thinking about how you are going to quantify either that opportunity costs with the actual cost with not making the change, and I say that because as I saw too often the emphasis is on calculating what the cost of moving would be and there’s not really an emphasis on the cost of staying. I think that there’s one opportunity cost that I think oftentimes gets missed and that’s the opportunity cost of diverting staff energy, diverting investment, diverting focus away from what you’re working on now, and diverting it to a technology project that may not truly move the needle that much. Because so many of the questions today have been around fundraising, often I have seen this emphasis on moving fundraising systems, because the perception is that by moving it’s going to create change, create the opportunity to generate new revenue, enable you to engage with constituents differently – which is what I was trying to say – but really trying to get people to give you specifics around that I think, it’s essential. So, my experience has been when I can outline both the ROI of staying and the ROI of moving, it becomes pretty clear, or at least clear around the benefits of moving and weighing the costs of moving.

Personally, I don’t think in this example retraining users is the biggest cost. I really think the biggest cost is taking a finite quantity of organizational energy and diverting it and using it for the purposes of a software selection and implementation.  David, what are your—do you have any different thoughts?

David: I think that’s a different point. Yeah, I hadn’t thought about it from the energy perspective before, but it takes a lot of time and energy, as well as money to change software systems. So, we are certainly not saying that that always outweighs the benefit of changing. But you know, if someone comes to us and says “hey, we need some new software for A, B, and C.”, that’s why we really want to take a step back and say, okay what are you using now and what are the problems with it? And a lot of the times, you know, many of the problems don’t have anything to do with the technology itself.

Kyle:  I wish Peter was on today’s call because he is really – he has really helped my thinking evolve on this notion of thinking about time as being finite, thinking about time as having a cost and making sure that people are in agreement that those costs and that time are worth it. 

Deciding on a Software

Kyle: So, our next question and this one you get to take David, but somebody in our organization wants to go with – we anonymized it to Shiny solution X- but I’m not sure it’s right for us.  How can I help ensure we make a good decision?

David:  So this could be tricky of course, if it’s the executive director, who wants Shiny Solution X, that could be a tricky conversation.  I think if it’s someone else in the organization that’s really no substitute for senior leadership saying “look, before you go and purchase the software for yourself, for your team, you really need to engage with IT or you need to engage with these other teams who are stakeholders in this.” Senior leadership ensuring that that’s the way that organization is going to operate, is the best scenario.  That’s not always the case and so, I really encourage if you’re in a position to engage whoever wants this new software around, what the business value is this going to be, what are the objectives, and who are the stakeholders? I think starting to ask some of those questions, can kind of frame in the right way to have a meaningful conversation before someone just goes out and buys some software. So, when they talk about the objectives, there may be other ways to meet those objectives.  Maybe the organization already has software that can help to meet those objectives, and maybe you should check that out first.

With respect to other stakeholders, maybe there are other requirements that aren’t being considered that would affect what the choice would be. So, I think just having a conversation with the person or the team – those things – business value objectives and stakeholders is a good entry point for kind of taking a step back.

Kyle: I think about that slide that was in the intro and you could almost change the formula to be old organization plus Shiny Solution X equals expensive old organization. I think all of what you were saying was, or at least what I heard you say was, it is not oftentimes is not about the technology, it’s about something else or it’s about some existing technology and trying to come up with the process to explore that in a little bit more depth.

Selection Involvement

Kyle:  So for selections, there is a question about who to involve in it?  You know, I will be interested to know your answer about this David.

So for me, at least at the outset it’s been rare that organizations start thinking in a way that might have over representation in these selection processes, it tends to be under representation and I think you talks about this in an earlier question about having the right people at the table.  One of the things that even helps me at the beginning of our work with clients, is to start the creation of a stakeholder map. What a stakeholder map is, it’s something that is visual the way a map is and it helps me at least visualize all the people who are going to be impacted by a technology change. And as that gets refined, we can actually paint a picture for who should be involved in the selection process. So we often start our projects with an assessment and that’s where we start to do the stakeholder map build out, because it’s really important to make sure their voices are heard and understood in the selection process. There’s an important distinction in that and again it goes back to a change management principal, but this is less about when you think who’s involved in a selection process, it’s less about everybody being in alignment or everybody thinking or agreeing about the direction, and it’s about everybody feeling as though their voice was heard. So, being involved in the selection process can look very differently.  For leadership, they need alignment, they need to be in agreement and support and champion the project, like I talked about in the earlier question. But in terms of other types of involvement through things like surveys, even though simple things like listening sessions, there’s ways to involve people in the selection process that are much broader than a small group of senior leaders or a group of IT professionals.

David: I think those are all great points. I think on the stakeholder map that’s a place where I think like more of a grid and a stakeholder impact grid that maps out the processes or functional areas that are going to change and who the stakeholders are for those changes, it is accomplishing the same thing, just in a slightly different format. But I think that’s an incredibly useful tool for expanding awareness about who needs to be represented, who needs to have a voice in some of these enterprise software and organizational changes.

Kyle:  Yeah, you know I like things with lots of colors and lots of bubbles on them, so I gravitate towards a map. But I think you are absolutely right, for some organizations, seeing it laid out in a matrix and being able to filter it, sort it and understand it at a greater level of depth is really helpful. And I did David, catch that you said that I made a great point in the last question, just so you know.  

Effective Ways to Evaluate Multiple Platforms

Kyle: Next question is, what’s the most effective way to trial and evaluate multiple platforms?

David:  Yeah, so thank you all for this question. I think I will also point out someone specifically asked about minor versus major solution selection, so I wanted to address that as part of this answer.  First of all, I would say you know the difference between a minor and a major solution selection is kind of like the difference between renting a car and buying a house.  If it’s minor software, if it’s a smaller decision like, what are we going to use like a virtual brainstorming tool?  That’s the type of thing, you just download it and try it. I have in the past couple of weeks, in fact, tried a GroupMap and something else called Lucidspark and it’s okay to be a little bit of independent, pursuing solutions like that. If you don’t like the car you rented, you take it back and get another one for rental. As opposed to buying a house, like a major software solution, these enterprise systems, CRMs, ERPs, projecting grant tracking software, which one attendee asked about. Those are major solution selections – major meaning it impacts multiple teams or it impacts a large group.  It requires behavioral change, organizational change; it involves migrating a large amount of data. For those types of larger decisions, I strongly recommend the requirements gathering process. I really strongly recommend an RFP process.  You know, vendors don’t love RFP processes, but it’s really, if you look at it as a way to have a conversation with that vendor and have them to get to know you, as well as, you get to know them, then I think that could be a really helpful way to really think about it.

I think it can be helpful to have brief, introductory demos early in an enterprise software process, you know, just to make sure the product doesn’t look like it was built in 1995. There are still some of those products out there and because of those brief initial demos, can give you an idea of what’s possible these days with a certain type of software.  I do think it’s important towards the end of the process though, towards the end of this RFP process, to really make sure that the finalists are provided scripted demos. And then finally, if it’s an option to do kind of a pilot or have a sandbox kind of test version of a system for you before your fully committed to it, then I think that’s a great thing to be able to do as well, even if it takes some investment and some time and some effort to get that sandbox set up in a way or that test environment set up in a way that makes it possible to evaluate it.

Kyle:  Yeah, those are the only thing that comes up for me is sometimes how you can use trials in a hybrid way with a larger RFP. I think about the selection for project management tools and in that we decided that the best way to get feedback was to actually let people play around with the project management tool and be able to provide feedback on what they liked and what they didn’t like, and while that was helpful – because it was embedded in something you said David – was project management tools were really new for most of the organization and it helped us identify what adoption challenges there were going to be and what training challenges there were going to need to be met, and those training challenges, some of them it was obvious they were extended beyond the technology itself.  It required people to understand about how this technology was going to integrate with their work and so I think you can use a hybrid approach, where you can use these trials to inform a subsequent larger selection and bring more educated evaluators to the process.

Defining the Requirement for Software Selection

Kyle: Yeah, the next question, let’s see – what steps should we go through to define the requirements for the software we need? I’ll take this one David. I think what I would say is the most effective requirements and it probably mirrors our approach, is not a list of three or four hundred things that the software needs to accomplish.  I think they have a role in requirements, but you talked about this earlier David in answer to one of our earlier questions, but really the requirements should be based upon what are the processes that this tool or solution are expected to support, and those requirements should be really tightly linked to the way that your organization wants to work in the future.

I think a lot of the software vendors who are on today’s call, oftentimes they will say, they get RFPs that are spreadsheets with hundreds and hundreds of requirements and some of those requirements look like they were developed a long, long, long time ago, with requirements that pretty much anyone would be able to meet. So, it’s akin to identifying your requirements for your car, that has a steering wheel and a horn, entirely unlikely that you are going to be shopping for a car, where you need to get to that level of specificity around table stakes and functionality.  What you need to do is to give the vendor an understanding of your requirement, doing in a minivan or doing in a Ferrari. Both have a steering wheel, we didn’t need to outline that, but one is much different than the other.  One is going to be awful to load a car seat into, the other one is going to be awful to take someone out on your first date with. I’ll make people make their own judgments about which one is which.

The next thing I would say is, I think of two types of requirements gathering, one is where the organization already understands how it wants to work and can envision that in some level of detail, and the other one is where the organization has perhaps an overall vision, but they have no clue or no experience with what that process might look like. I’ve actually led two selections in the past, I think five or so years, for organizations around CRM and I know that question has come up a couple of times today.  They understood what CRM was and what it could do, but they didn’t know what it looked like in practice. They both shared this idea. They knew they needed to better manage and engage with constituents and manage those relationships, but they didn’t really understand in concrete ways how it was going to change the way that they work and so it goes back actually perhaps to the last question, where does that education happen?  How do you educate them on what the future might look like?  When does it happen?  Does it happen during the selection process or do you rely on an implementation partner and to try to weave that just a little bit more concretely into my last, into the last question rather, is that by trailing and demoing software.  Sometimes that helps uncover requirements that people would have never considered before.  So, I said a lot there, I think that the main question that we have or at least I have when I start with a nonprofit, is how important is it to find the future state and to what level of detail, before you start implementation and there are two different approaches.  One is to do it pre- and to ask people to do it in advance and the other one is to really put the emphasis on finding a strong partner or a strong vendor, who can help walk with you to do that in the implementation itself.

David:  I think the quick think I’d add is I do think the learning process really starts even before you’re in the software selection process. It’s just starting to talk about your software processes, then it’s in the vendor demos and that software selection process, and then it’s even more so during implementation. So, I think it’s throughout the process. We did get a comment from Kathryn.  Thank you for the comment and I thought it was especially relevant here.  Well, one of the things she sees is people document requirements based on what they don’t like about the current solutions and sometimes, completely ignore things that they absolutely must have because they’re so focused on what to avoid. I think that’s a great point.  I’m working with a client right now, where we spoke last spring about what the current products could not do or what they did not have it configured to do, in an attempt to use that product more effectively and now that we’ve decided to explore some of the solutions, we’ve circled back to really focus on that second part that you’ve really mentioned, which is what are the must haves, the things that maybe working well with the current solution that also may be in a new solution, so great point Kathryn.

Kyle:  Yeah, that is a really good point. 

Designing Your Newly Selected Software

Kyle: The next question is, when we are looking at our existing processes, do we want to design for how we work now or the way we want to work in the future and when we know the ways – sorry, I’ll just read it verbatim.  How will we know the ways we will work in the future without experiencing the new offer? David, I will handle this one.

David:  Yeah, the chicken and egg dilemma, you know.  I really think the starting point is understanding how you work now and flagging any challenges with the current way of working, and flagging any opportunities that people already know about. That’s got to be your starting point because you don’t know what you don’t know. I think it’s helpful to see some brief demos really early in the process that help to spark some ideas for what else is possible, with different or newer software. I think it’s important to not try to figure it all out in the requirements definition phase or in the RFP process.  I think you should approach the RFP process as an opportunity for the vendor to be a partner in figuring out new and better ways to work and run the RFP process in a way that acknowledges, that it really can be a conversation with them. Then finally during implementation, I think it’s important to work on it iteratively, where you know the partners bring their expertise, you’re bringing your internal expertise and you know, really bringing a process focus to that work during implementation, because vendor’s tendencies is to really be focused on their technology and configuring their technology. What we believe most organizations need is someone who is there focusing on how you want to use that technology. What are the processes and who are those processes impacting? What changes is it going to have on those different stakeholders of that process? So, this is where that stakeholder impact grid that we were talking about earlier, kind of comes into play.

You can use a tool like that that maps stakeholders and processes and impact.  You can use that to identify “hey, who do we need to engage as we’re doing the design and build of our solution?  Who do we need to engage in user acceptance testing?” In that process, you know, get a workflow here that’s really going to work for the organization by the time they go live with it.  Last little plug I will put in here is for a business analyst role in more organizations.  I think that’s a role that doesn’t exist in many, many nonprofits. What I mean by business analysts, is someone who is fluent in an organization’s processes and what they are trying to do and has some familiarly with how technology can be used to do that more effectively. So, it’s not your sys admin, although some sys admins have some business analyst competencies, but it’s a different person.  It’s a person who sits between the business units and the technical configuration and can kind of marry process to technology.

Kyle:  Something I was thinking about as you were talking is a question, I think it was one of the early questions in today’s webinar. It’s this idea that someone was talking about Shiny Solution X, is what we called it. I was thinking, you know, this is a little bit tangential, but I was thinking about the role of what we talked about and some of the questions exposing people to multiple solutions that do that thing that people think that Shiny Solution X will do. Then perhaps what it does is, it makes it less about “I hate what we have, and I want something new and I want what it is and it does it better”. My thought is David, is what that does by saying it helps by seeing multiple shiny object Xs or shiny project Xs, is that really anyone might be able to do that. It’s about how the organization wants to work in the future. It might cause organizations to ask the last part of that question which is, “okay, I get that all of these new things do that thing. How do we want to work in the future?”  So, using a specific example, if the old solution doesn’t allow you to do text-to-give for fundraisers, showing them there’s lots of ways to accomplish that. How do we want to do that?  How does that integrate into our existing strategy and does it really acquire an entire new solution? So, I know that was a little tangential, but I thought it was such a good idea, that I didn’t listen to your answer at all and I was just waiting to get my plug in for that idea.

David:  Well, usually you think about going to sleep while I’m talking, so I’m just glad I sparked some creative thought.

Kyle:  Yeah, I mean I just – it made me wonder for the future, whether that’s a tactic for the person that’s like “oh my gosh, we have to move to solution x”, and to make it less about a specific solution and more about where the overall space is moving and whether that can be a catalyst for having some of the deeper conversations that you suggested they need to have.

David:  Good idea.

Submitting an RFP vs. an RFI 

Kyle:  Next question, I love this question because it doesn’t have a lot of words. I clearly stumbled on the last one, it clearly had too many words.  When is an RFP or a request for proposal or request for information appropriate in a software selection? Just before I answer that question, as I talk, the way that I think about the difference between those two are that when an organization does have a fairly strong sense of how things need to work and need to see somebody who can demonstrate that they have a solution capable to meet those needs, that’s more of a request for proposal.  When you’re looking for somebody to help co-design it, it’s more of a request for information. So, that’s how I think about those things, those two and that might help provide some context for how I might answer this question.

I’d say overall, I’m a big fan of these mechanisms because the way that I try to construct them is not in the way that most people think of them.  Too often people think an RFP or an RFI, is a way to get information about or its sole purpose is to get information about vendors.  I actually think that this is a way for an organization, and I forget how you termed it David, but I might say “know thyself”. It’s an opportunity to do what you talked about earlier, where it might create awareness among your colleagues about the way that you work or some of the challenges with the way that you work right now.  It’s a way for the organization to come into the selection process, with a clear understanding of where it is.  The other thing and Kathryn might have been alluding to this in the point that she made earlier, RFPs can be a way for the vendor to understand your organization.  

So, it’s not just a way for you to learn about the vendor, but a way for the vendor to learn more about you.  It helps them understand, sometimes in black and white, how much have you already figured out and how much have you yet to figure out. What’s the gap between the requirements that you know and understand now and what’s going to need to be done in an implementation? RPFs can help them understand who they’re going to be working with? What are the capabilities of them? Sorry, what’s the capabilities of your organization, is what I meant to say.  Do you have somebody that is really strong in project management, but has never ever done an ERP implementation ever before?  That’s really helpful information. If the reverse is true, they’ve led an ERP implementation but they’re not particularly adept to at managing a project, it helps the vendor understand more about you.  What do they need to bring to making the implementation successful?

So, I’m a big fan of them, even if they are scaled based on the size of the project or the amount of the investment. They’re just incredibly useful, if no one else, for the vendor to understand more about what is expected of them and their product.

David:  I think, I will just add that RFIs and RFPs can be done really well or they can be done really poorly. That certainly has an impact on the value that they provide.  I think on a separate note, one of the principles that I try to bring to this and I think Build as a whole, I think we do this is “don’t waste people’s time” whether that’s staff members, whether that’s vendors.  If you’re not seriously considering a vendor, don’t make him reply to an RFP.  I think it’s also helpful to, you know vet vendors beforehand and only ask for RFP responses for those that are legitimate contenders, right?

I think it ends up wasting people’s time to get more responses than your review team can seriously consider.  It’s a waste of the vendor’s time. It’s a waste of the staff’s time and it doesn’t give you answers. So, do the vetting up front and find a few that seem like a good fit, get RFP responses from them, and only do the finalist demo after that if they remain a serious contender.  You know, don’t waste anyone’s time, whether its vendors or staff. That’s certainly what we aspire to and what we achieve, when we run the RFP, RFI process.

Kyle:  Yeah, that a really good point, especially staff time.  Asking staff to be highly invested as we suggested throughout this and then making them sit through vendor demonstrations and understanding the capabilities of a vendor that is just not going to be a fit for you, it doesn’t set the stage well for implementation in terms of future asks that you’re going to make of their time.

Managing Expectations of Vendor Demos

Kyle: The next question is systems and vendor demo. How do we ensure that the vendor is going to show us what we’re interested in and not what they’re most interested in showing us?  David, why don’t you take this one?

David:  Yeah, I will take a shot of this. I did mention earlier the idea of brief initial demos early on in a process before you issue an RFI or RFP, just to see what’s possible. It also helps with the vendor screening as well.  It really helps to narrow down that list and take it from – you know, a lot of times in some solution categories, which you may have eight, ten, twelve, twenty, even more potential solutions. So, doing brief demos, can really help you narrow that list to the ones that you want to seriously consider.  Then I think after the RFP process, once you’ve reviewed the RFPs and decided, yeah, we’ve got these three responses.  We think they’re all finalists. Or yeah, we’ve got five responses, but only two are serious finalists. Do demos with the serious finalists and again make sure that they’re operating from a script that represents what you need to be able to do, how do you envision operating. And you know, that being said, I would still give them space in that finalist demo for the dog and pony show.  Show us the things that we may not be thinking about that are really special about your product, just don’t spend the whole demo on that.

Kyle:  Those are all really good points and I think, what can you do to bring educated evaluators to that process, so that the vendor doesn’t have to spend time doing dog and pony show type reviews of things, that you could accomplish through watching a recorded webinar or asking people to watch a product demo overview.  What can you do to bring people to the process, so that the vendor doesn’t have to spend time orienting them to the very basics of the software or the technology and you can get right into what’s most important for you? 

Project Estimates from Vendors

Kyle: So, this is David, this is the last question that we’ve got in advance of today’s webinar.  I’m not sure if there are questions that have come in during the course of today’s webinar, but how can we make sure we are getting good estimates?  And I will take this one since you took the last one.

This is probably another reason to do an RFP. The better your RFP or RFI, the more inclusive, the more accurately you represent your organization, the more realistically you represent your organization, the more honest, the more whatever you are, the more likely you are going to be to get a realistic answer. The truth is that when you’re trying to get estimates around a project of this size, vendors – or at least good vendors – they are equally motivated to giving you a realistic project estimate.  They want you to understand what the costs are going to be, so that they don’t have to come back to you later.  There are no vendors who think that a good approach is to underbid and then, come in midway through the project and say, “we wildly under budgeted this”. A well-designed RFP gives them a sense of the scale of the project and is going to then lead to a better estimate.

I also encourage organizations, or I should say I encourage vendors rather, to give us a realistic estimate.  Show us what you think this will take to do well.  Some organizations like to share their budgets upfront and the vendor might want you to, but this sort of, the idea that I am trying to convey here is, you really want to know from the vendor and you’re hopefully finding experienced vendors – in your experience – what is a realistic project estimate. It’s almost all the way through this webinar and I still don’t think I have used a metaphor or story, so here is the metaphor for this.  Recently my wife and I, we wanted to remodel both our kitchen and our bathroom, and I guessed and said, “I think we can actually do both”. We got a bunch of estimates and guess what? We couldn’t afford to do both. So, it then became up to us, it became up to my wife and I to decide how did we want to approach this?  Did we want to dial back what the vision looked like?

Did we want to get a different kitchen and a different bathroom or did we want to pick one? Ultimately, we decided that we wanted to pick one and wait on the other. But if I had started and said, “we only have $10,000 and we have to do both”, I risked getting a kitchen and bathroom that might not have indoor plumbing. It definitely wouldn’t be something that we wanted. Lastly, I will say this, whatever process you choose to get realistic estimates and whether you use a firm like us or do it yourself, it’s your job. It’s the organizations job to get realistic estimates.  This should be a partnership with the vendor, but ultimately it is incumbent upon you to provide the information to get a realistic estimate.

David:  I’ll just add a couple of things here Kyle. I think you know, you alluded to this, there’s no substitute for someone who has been through it before and having them on your side.  I will put in a shameless plug here, you know Build, of course, has a lot of experience with this or have a staff member who has been through a similar type of implementation before. We give you a reality check of what it’s going to take.  Typically, what I find is that implementation vendors don’t capture all of the costs. They’re incented in a lot of ways to keep the implementation costs lower, so that you can go forward with it and put some assumptions around it.  A lot of times they will call it, maybe, a best practice implementation. For some organizations, that’s realistic.  You check some boxes on a form, they configure it according to that, you know, what you selected from a menu and maybe you’re done.

Most of the time, I don’t think that’s how implementations go. Most of the time, it requires some discovery, some customization, meeting unique needs and so, I typically recommend at least twenty five percent contingency on the implementation labor, if not fifty percent sometimes from implementation vendor initially says. I don’t think—you know, I don’t think a nonprofit needs to share that they’re doing that.  I think it’s better to keep it in reserves because things will come up in the enterprise of software implementation, that you need to be prepared for it with a budget. And then, you know, I think the last thing is just make sure you read. I mentioned the assumptions, make sure you read the contract and how they framed the implementation in their contract.  What are the assumptions that they’re making about the implementation and are those accurate for your organizations?

A lot of times its easy, by the time you get to contracting stage, to just sign off and say “let’s go” when all of your assumptions are based on what you think they’ve said, not what’s written in the contract. I’ve seen get some organizations into trouble.

Kyle:  I love the idea of having sort of an internal budget and a budget that you share with the vendor itself, so that you are already prepared if those sorts of unknowns come up or something that was unexpected comes up.  I think that’s a great idea.

David:  I’d say, you know, keep a card that you can play, right?  You don’t have to play all of your cards at the beginning. 

Additional Questions from Attendees

David: I’ll just add here, not specifically related to this; we did get some other questions.  I think some of those questions were outside the scope of this webinar.  

There was a question about the missed framework, which is the cyber security framework.  Community IT may have a webinar about that.  I am just saying that I don’t know the type of thing that they have any webinar plans for, but it’s a little bit more of the type of topic that they would tend to cover in a webinar.  

Someone else asked about not for profit legal services setting and leading software vendors, I think that very specific conversation is probably more appropriate for a more one-on-one conversation, so please feel free to reach out to us about that. 

Then we also did get a question Kyle, about which platform provide the widest array of functions and what tips we can try to use to figure out if that path is a good fit.  I’ll just point out, we do have other webinars on what it means to take platform approach and when is a platform right for you. I would encourage you to look through our history webinars for some of those topics. CRM platforms like Salesforce and Microsoft dynamics are not the only way to go about, you know, that type of project.  There are definitely other options, ERP options, there are alternatives, such as individual solutions combined with middleware, but that’s a whole topic unto itself. So, please look at our history webinars for more on that.

Kyle:  And I think what’s interesting is, you know, for organizations that are thinking about moving to platforms and I am sure that this is touched upon in a webinar or a blog post that we’ve done, is that those have sometimes some significant staffing considerations and staffing changes. It might be entirely new roles.  You’ve answered an earlier question David, this idea of a business analyst role and it not being present in a lot of nonprofits. For platforms, there’s also sort of architecture roles, there’s technical roles and answering the question about how your organization is going to support those roles, via either staff or through outsourced vendors, I think that those are important considerations for people who are thinking of making a move to a platform.

David:  Yeah, absolutely Kyle. I’ll just say we got a couple more comments here, just on the importance of, you know, sometimes the software is not the implementation vendor. This is, of course, oftentimes the case with Salesforce. It’s the case with Microsoft dynamics. It’s really important to look at all the costs, both one time and maintenance related to, you know, choices like that. A couple of areas that can be overlooked a couple of times, some are the transaction costs, the payment processing costs, which this person mentions in the comment. I think one other thing I would point out is, if you’re going to adopt a platform, like a Salesforce and Microsoft dynamics or even an ERP really, you need someone in-house who has some capacity. You either need someone in-house with that technical capacity or you need to plan to have that implementation partner on an ongoing supporting agreement with you to really be able to support that sort of technology in-house.

Kyle:  So David, I’m looking at the time. We have just about two minutes left.  We probably have time for one more question if we have them, otherwise I can wrap us up and share more information about how people can get additional information and some of the resources that you’ve talked about. I’m not sure if we have any questions left in the queue?

David:  I think that’s it, why don’t you go ahead and wrap us up.

Kyle:  Well, first of all David, great to do a webinar with you today.  You did deliver on my hope that you would give me a new perspective and new learning, so I really appreciate you being here today.  

A couple of things, David alluded to these.  We have a number of resources that take the form of blog post webinar recordings. Today’s webinar will be recorded and provided afterwards.  We also encourage you to subscribe to our newsletter, which is a great way to find out about new content that we’ve developed, what be that blog posts or webinars. 

Here are some ways that you can directly engage with us. David offered to answer a question specifically about the nonprofit legal services setting.  There’s information about how to reach out to us via email, connect with us on Twitter, connect with us on LinkedIn. (for these links, please check the final slide above)

Lastly, Community IT is doing a webinar on January 27, from 3 to 4 pm, Nonprofit Technology Trends and Roundtable.  I will be interested to see, given some of the recent security events of 2020, the extent to which they touch on security. You mentioned Community IT being a great resource for those types of conversations David, so please do join in on the 27 and lastly, I just wanted to thank everybody for joining today’s webinar. I hope everybody here in the US has a great Thanksgiving and we appreciate your attendance today. Thank you so much.