Leading an Effective Nonprofit Software Selection (Video, Podcast, Transcript)

View this video directly on YouTube (and subscribe to our channel!)

Listen to the Podcast

Like podcasts? Find our full archive here or anywhere you listen to podcasts. Or ask your smart speaker.

Webinar: Leading an Effective Nonprofit Software Selection

There are many potential software, system, and platform options out there that may suit your organization’s needs. So, how do you choose the correct one?

Listen to Build Partner, Peter Mirus, and moderator, Jennifer Keller Jackson have a discussion on what it takes to lead an effective software selection!

There are many reasons why selection processes can hit rough patches. Maybe you need to alter the composition of your selection team, perhaps your objectives or requirements aren’t clear, perhaps you confused one or more vendors at some point in the process, or perhaps you just need someone to translate some of the vendor “techno speak” into plain business language.

The range of technology available has a spectacular range of costs, with licensing/subscription, implementation, and support fees each ranging from free to potentially hundreds of thousands of dollars. You’ll want to evaluate both what the software provides and how well the provider (or service partner) will use the software to meet your objectives.

Taking a “platform approach” for your organization creates a particular set of challenges that don’t exist to the same degree in a “best-of-breed approach.” For most organizations, selecting a technology platform represents a long-term commitment and also an opportunity. But how do you capitalize on that opportunity?

All nonprofit organizations stand to benefit from an improved technology environment, which requires improving your software selection skills.

Facing a software selection at your organization? Learn from the  real-life concerns of your nonprofit peers and colleagues.

Peter draws on years of experience in nonprofit technology consulting. Jennifer has deep experience in the nonprofit community, with both developing and running programs and teams. Her background includes working with local and national organizations in experiential education and technology for social impact.

Learn the approach that will work for your organization to maximize your odds of software selection success.

As with all our webinars, this presentation is appropriate for an audience of varied IT experience. And Build is scrupulously vendor-agnostic, so you can be sure this webinar will be an opportunity to learn from your colleagues without a sales pitch of any kind.

Presenters:

Transcription

Jennifer Keller Jackson:  Well, good afternoon everybody. I’m delighted to welcome you to the April 2021 Build Consulting Webinar. Some of you have been with us before, some of you are here for the first time, so welcome. Today’s webinar topic is Leading an Effective Nonprofit Software Selection. So, we are assuming that all of you are somewhere, thinking about or knew deep in that process.

What we are going to do today is try to answer your questions by asking you upfront, why you are here? So that Peter, who will be presenting most of the content, can make sure that your questions get answered to the extent, as possible. And if you have any questions that aren’t answered during the webinar, we will be happy to follow-up with you individually and will also share a recording of this.

So as people join, we will just keep going and say welcome. First little bit of housekeeping, we do want this to be interactive. Most of you have used the chat function in Zoom. Some of you have used the Q&A function. We prefer the Q&A function for actual questions, because then I can kind of keep track of what’s been answered or hasn’t been, but there will also be opportunities to put things in the chat.

We ask you to give us your attention for an hour, because that one piece of information that you are hoping to get, maybe when you are answering somebody else’s email. Plus, we all know multitasking doesn’t always work, right? And then as I said before, we will be sharing a link of this well everybody that’s registered. So, that’s the housekeeping out of the way. And we will do some brief introductions. Peter, would you like to start and then I will introduce myself?

Meet the Presenters

Peter Mirus:  Sure. Hello, everyone. My name is Peter Mirus, I’m a Founding Partner at Build Consulting. I’ve been working with nonprofit organizations, exclusively on technology related projects for about the last eight years. And I’ve done a lot of system selections over the course that time for a wide variety of system types, ranging from financial and accounting systems to CRM systems, to marketing automation, and case management, you name it. I’m happy to be here with you today and hopefully will be able to answer a lot of your questions, during the course of today’s session.

Jennifer Keller Jackson:  And I’m Jennifer Keller Jackson, I am the Director of Business Development at Build. My background is also 20 plus years in the nonprofit technology world. I started off mostly working at nonprofits, running programs at the intersection of experiential education and telecom and technology. I’ve worn a grant maker hat for dozen years, where I made grants to faculty and students at universities. And I should have said, earlier that I’m sitting here at home in Washington D.C., and Peter is just outside of D.C., in Virginia. So welcome, wherever you are calling in from. I think that’s all you need to know about us for now.

What brings you to this webinar?

Jennifer: So, now we are going to start the first kind of interactive piece, which will help shape Peter’s remarks and mine as well.

Could you tell us in a sentence or less, why you signed up of this webinar?

Because…you think you are going to be doing a software selection, as I said, you might be halfway through one. [Maybe] you have participated in one before and it was a miserable failure and want to know how to do it better. What brings you to this webinar today? And I will just give you a minute to think about answering that and you can put this in the chat, not in the Q&A.

Beginning of a software selection at Williams…is that Williams College? I can’t hear you. I’m sorry. Oh nice, I lived in Amherst, Mass. for 14 years. So welcome from Western Mass. Any other? Okay. Oh, much bigger than Williamstown. Yes, Amherst is a throbbing metropolis compared to the hill town of Williamstown.

Working with a nonprofit that is only three people of mixed tech abilities that has big donors, which probably means big expectations, and is engaged politically. That is nice and mysterious.

Okay. Great. So, trying to learn as much as you can. Thank you. Anybody else? We will take one or two more? Anything that you are hoping to get out of the session today? We just want something to do during the lunch hour, I guess. Okay.

Peter: We did have some questions submitted during the registration process, and lot of information that we will be covering today was – as a result of that. So if you asked a question there, we’ll be good to go as well.

Jennifer:  Great. And then Deb just added, that looks like you got a process that you are planning, and you want to make sure that you haven’t forgotten anything major or that you considered everything that you need to. So, that’s great.

Okay. All right, so let’s move on. If you guys have questions along the way, again please remember to put that in the Q&A. And if you don’t leave it in the chat that’s fine, I’ll find you.

About Build Consulting

All right, so we can see from the next slide that we are just going to do a very quick about Build. Technically, we are based in D.C. We have clients in all four time zones, and internationally, which means for us Canada. Couple of things that make us different are that we have worked collectively, with over a 1,000 nonprofit organizations and we only work with nonprofits. So that can be everything from a “one woman, one laptop” organization to a large association, advocacy, environmental, or direct service organization.

We kind of cross all the sectors there, within the third sector. Everybody wants to be strategic, and we do that by actually taking the kind of discovery or assessment period really seriously that Peter will be talking about. And then we really do try to be collaborative, every single one of us at Build. We are about a dozen staff with an additional dozen or so vetted consultants that we work with as subject matter experts.

We are all here because we want to hold up and support your missions as nonprofit organizations. This is a slide that just shows you the different buckets of work that we do and it’s kind of in sequential order. As I said, we start usually with every protect with a technology assessment. So why do you need new software? Why now? What are the pain points? What’s working? What’s not working? What do you have? What’s it connected to? Building a roadmap or a kind of strategic plan that can take you to an actual software selection process, which we can hold your hand, working through with various vendors and systems integrators, selecting both the software and then who is going to implement it.

We are not an implementation shop, but we often play kind of a CIO or technology project manager role in the implementation. Let’s say you have selected your software and now you want to roll it out. So, we can also guide you through that process. The other fun thing that we do is kind of part-time outsourced work, either with database management, which we do sometimes, a couple of hours a week, sometimes several days a week for certain organization, sometimes for a short period of time, and sometimes for a year.

And then the light bulb brain icon is that we also for organizations that are either too small to have a CIO or have a big tech team, but need somebody to really step in think strategically, we will play that role as well. And again, it could be just a few hours a month or three days a week, like we do for some clients.

Our Approach

Okay. I have nothing to say with the slide, it’s self-explanatory. We will keep going. So interestingly, most technology projects fail and if I have to bet, I would guess that everybody on this call today has been part of, or walked into, behind a project that did not go well. And most of the time it’s not the technology. It’s the lack of adoption. It’s the lack of training. It’s the lack of really understanding, whether that tool is going to meet the process, workflows that everybody has, to do their jobs.

It’s also a lot about the lack of change management. The lack of communication and support that has to come with every project, so that people aren’t blindsided or fearful about what is to come. So, this is a fun slide. This is our funny slide of the deck. OO stands for Old Organization. So, if you haven’t selected new software, you would be the old organization, implementing new technology. And what does that give you? Basically, just expensive old organization.

Without the focus on people and change management, you have new technology, but not necessarily the transformation that Build tries to make happen, collaboratively. And I think, I’m going to pause here and turn it over to you, Peter and talk through the various ways that we look at a project, including software selection.

Build Information Strategy Framework

Peter:  Sure. We have a framework called the Build Information Strategy framework, which helps us to take the holistic look at organizations that we work with, and their needs. And you can see that we are technology organization, and we provide consulting around that. But there are number of things that you need to get right upstream of the technology, in order for your technology change to be effective.

So, this applies to any software that you would select and implement inside your organization. Really want to make sure that your leadership and governance are well setup and aligned. You have the organizational operational capacity to maintain the tool over a period of time, that your processes are well defined, that your data collection and management routines are also well defined and consistent. And then, you get to the technology.

So one of the things we like to emphasis is that in this framework, technology is intentionally last and that, again that’s because there are so many things that have to occur upstream, in order for technology to be effective.

So today, we are going to be talking about several different aspects of software selections that you can see on screen here. We have stakeholder engagement, intended benefits for the project, business requirements, technical requirements, working with vendors, evaluating costs, and making a decision. And all of the questions that we’re submitted during the registration process, as well as just common questions that Build gets from clients either during our sales engagement with that clients or in terms of the project itself, fall into one of these categories. If you have a particular question or area of interest that’s not or at least you don’t think, may not be included under one of these headings, feel free to added in the Q&A as Jennifer said. I will be happy to try to weave in and answer as we go along.

Stakeholder Engagement

So, first I want to talk a little bit about stakeholder engagement. So one of the most common questions that Build gets is, to what extent you need to involve other stakeholders in a selection process or whom it should be included in the selection. And we look at it from a standpoint of a variety of different tool – the variety of different lenses, so first of all you not – you definitely need to have executive sponsors and/or an executive team that are engaged as a stakeholder in this effort. Active engagement of executive sponsors and technology selection and implementation is a big factor in their success.

Oftentimes that might extend to the management team, you need to involve system owners or at the department or program level. By system owner, I mean whom is going to be responsible for the procurement care and feeding of the system, or should have the final say over how the system should be utilized to create the business benefits that the organization intends for it. So for fundraising CRM, for example, the development team inside of the organization would often be the system owner for that product.

You also have system users at different levels, administrators, power users, users, and a variety of subject matter experts inside of your organization that or they might not be direct users of the software that you’re going to select, do you have some perspective or expertise that would allow them to make a valuable contribution to defining the requirements for the selection effort.

And then you may engage with the variety of other stakeholders such as board members, particularly for organizations where board members are involved operationally. You might have peer organizations and professionals that you engage with. And by this, I mean organizations that are doing like work to you in the space that you might want to engage with, not necessarily as a stakeholder for your internal outcome but as sort of an outside perspective to say, here’s what we’re doing with technology in our organization, here’s what’s working, here’s what’s not, and here’s what we’re looking to make improvements. As well as your peer professionals at other organizations. So, if you’re a controller inside of your organization or a director of development, you could reach out to others inside of the space and ask them what they are doing for accounting systems or for CRM systems and how they’re putting those into use.

And then finally you’re often dealing with vendors during the selection of process as well as you might want to engage with beneficiaries. So, if you have extended beneficiaries, like program participants or other kinds of constituents or beneficiaries, you might want to solicit their input as part of the software selection. Particularly, if it’s a system like a portal that they’re going to be engaging with directly such as for example, scholarship applicants logging into a portal to be able to submit and track their applications or alumni association members being able to track or visit their alumni center online.

So, these are all different kinds of constituent groups that you could engage with in the course of the selection process. I think it’s important to note that in addition to engaging stakeholders from a requirements development standpoint, you also need to take into consideration stakeholders in terms of buy in that you will need an order for the change that come through that new software to be implemented successfully. So, this for example, might cause you to say well, we want to engage all users in some way as stakeholders even if we’re not involving them as a key stakeholder who is going to be contributing to the requirements, because engaging them now during the selection effort, help to make sure that they feel heard when we later ask them to make changes to their process user workflows that the new system will bring along with it. I’m just going to pause here to see if there are any questions before we move on to the next topic.

Jennifer:  Actually, I just posted a question in the chat saying, are there any surprises in this list? You can respond in the chat if you want to. Deb, does this look like the group that you put together at Williams, for example? Or are there others that you have included that are not on this list?

Peter:  I think ultimately at nonprofit organizations, particularly for organizations that have broad or selecting a system that has broad reach inside of their organization, like an org-wide CRM or time and expense tools that have a lot of users, we can end up with quite a number of stakeholders engaged and managing that process can be a challenge.

Defining Intended Benefits

So, once you have the stakeholders together, I think what’s important to do is engage that group in defining what the benefits are for the new system. What is the organization help to be able to do better or differently as a result of implementing this new technology? And one of the things that I like to introduce to clients is the structure that I called the benefit continuum. You can use this to think about a variety of different activities that your organization might engage in, including programmatic activities and the benefits that that would provide.

But in terms of thinking about technology project, you want to think about a basic benefit and end benefit and what sometimes called an ultimate or end-end benefit. So it’s basically, what you did—you implemented the technology and then what was the immediate result of performing what you did.

What did the technology allow its users to do better or differently? And then from that point, what can the organization do better as a result of that benefit? So say, for example, that you implemented program reporting system that allowed you to get business insight into the performance of your programs and that would be the basic benefit, the fact that you put that technology in place.

But the end benefit might be that the greater ease of creating insight into program performance freed up program leaders and others inside of your organization from spending many, many hours trying to generate that – those reports, collecting and messaging the information, etcetera. And also allowed them to have insight into program performance in course of the real times, so that they could make real time course corrections.

And the end-end benefit of that might be that you’re able to take some of that time that was previously being devote it to sort of operational aspects of managing the program and devote it more to creating direct outcomes for program beneficiaries.

So say for example, you are able to shift some of that level of effort and associated cost towards serving women owned businesses in the Middle East or something like that. So ultimately, you want to try to think through and build the case for not just the investment and the tool itself, but also for the change that that tool requires from your organization and help sort of sew everything together and keep that firmly in mind for organizations as they’re trying to embrace the change that comes along with it, new software.

So these are some selected intended business benefits for an organization that I worked with that was thinking about making improvements to their financial ERP, CRM, and services automation software systems inside of their organization. And each one of these was a pillar in helping the organization build its concept for how it was going to use technology in the future and what systems it was going to select and what benefits it wanted to see out of that.

And then for each one, there is a benefit and end benefit, and end-end benefit. So for this one, improving the integration of financial data systems as an end benefit will unified the data model and data flow between all of these different areas of the organizational operations for finance and that will allow us to as the end-end benefit centralize the project data governance, etcetera.

And then similarly for this next benefit, many organizations aspire to adopt the collaborative approach to relationship management and what that had allowed this organization to do from an end benefit standpoint is to understand what relationships the organization has and what relationships it needs to best fulfill its mission and then how to deepen engagement within this relationship. This in turn would allow the end-end benefits to be achieved, to increase service and product visibility both internally and externally, increase the volume of high-quality opportunities to fulfill the mission and generate revenue growth.

And so, it’s really important when you’re trying to think about even getting started on a system selection effort to get the key stakeholders together and decide collaboratively and fix firmly what the benefits are that you’re going to be achieved from selecting and then implementing the software.

That really goes a long way to help creating success.

And then as a secondary step to making that definition you want to ask the question, well, how will we know when we’re going to be successful? That really speaks to performance measures down the line once you get the system implemented, so that’s one other conversation for another day.

Any questions about business benefits or talking about benefits inside of your organizations or building the case for a new software before we move on to answering questions about business requirements?

Jennifer:  I think we have kind of a shy group here today. If you feel like sharing anything in the chat about why you’re thinking about or doing software selection, for what benefit that might be helpful to others. So, just an invitation to do so.

Business Requirements

Peter:  Yeah. So, there are lot of different ways that business requirements can be developed and documented, and this is one of the most critical components in selecting the right software than having it successfully implemented inside of your organization. One of the challenges of documenting business requirements for your organization is that it often requires a major collaborative effort internally. It requires people inside of your organization to agree on what the processes are or should be in ways that they haven’t before. And that can require some facilitation and it also is to some degree informed to by the software that you’re selecting, as well as by what you already do inside of your organization today. And what I mean by that, is usually the software that’s being delivered to you that you can select from is to some degree representative of the needs of the broader nonprofit community that are also doing that thing.

So as an example, the Raiser’s Edge as a fundraising CRM for nonprofits brings this specific, embedded approach to how it thinks fundraising should be done. And also has been developed to meet the needs of many organizations that are doing fundraising. And so that product brings its own philosophy and its own way that it’s going to steer you through the process, you should be using that product for fundraising. The same thing might go with the human services case management systems. It has a perspective based on serving the needs of the industry, what an intake the process should look like, what an improvement plan for serving that individual should look like and how it should be administered, and how data should be transfer performance for individuals in groups.

So, every system is going to bring and inform what your requirements are. So sometimes for clients for selections, I suggest that—say, you are selecting a fundraising CRM system, it might be good just to get a good initial demo or two early on in your process, for your stakeholder group, of a couple of the leading options that are available in the market, because that sort of helps you freshen your perspective of what actually is possible with technology today. And then you can internalize that and sort of observe that use to help you in the future state of your requirements. I know the most common way that we think about doing business requirements documentation is by working through the mapping of constituent journeys and many – all organizations have some constituents, right and we think about constituents internally as well as externally. So say for example, you have a constituent journey. Your employees are constituents of the organization.

When you’re thinking about implementing the HR systems that help support the recruiting, onboarding, performance planning and management for staff benefits and registration, etcetera, you kind of know what journey the employees walk with your organization as a constituent and then, how technology currently does support that journey or where the gaps are and develop requirements based on that.

Another example of a constituent might be a donor, you want to know what journey that donor walks with your organization or would ideally walk if you could steer them towards the most effective level of engagement, same thing for clients of services that your nonprofit might deliver. So this is just an example, visual on screen here of a journey life cycle for a human services organization and where volunteers are delivering the service to the clients. And I don’t want to go into this in great detail, but it’s a visual example how to think about making sure that you take every requirement into consideration by really following the process of those constituent journeys.

For a broadly capable CRM that’s going to support a lot of different parts of your organization, like a Salesforce type of solution, might want to think about maybe half doesn’t different constituent journeys that might be supported in different ways by that system. And then ultimately when you get into the details or phases of that constituent journey and start breaking it down into detail this is where you might start seeing a business process mapping and analysis marking what’s working and what’s not working.

You can see where the start is here and there some identified areas for potential improvement and a future process. And then, you’ll also want to support that to some degree with a process narrative that basically make sure that when you go to start communicating with vendors about your requirements, that they have the context in the documentation to be able to understand what you’re really trying to achieve and the new answer what experience you want to deliver to that constituent as they’re going through that process with your organization. And this is just another visual example of a simple process flow with accompanying sort of key business requirements narrative.

Information Gathering Approach

Jennifer:  Peter, can I ask you to just briefly talk about how we approach gathering all that information? There’s the interviews and then, there’s the system walkthrough.

Peter:  Sure.

Jennifer:  I think that might be interesting for people to know about.

Peter Mirus:  Usually when we’re doing a selection for a nonprofit, as Jennifer said earlier, almost everything starts with some sort of assessment or discovery process. And one of the things that we work with in clients is to identify the stakeholders and then decide which of the stakeholders need to provide input to the requirements in which way. Usually there is a set of people that we interview to get their perspectives about their processes, what the current technology does and where it falls short and where the opportunities might be. As well we do walkthroughs with the client of their current systems for similar purpose, understand the process, what works, what doesn’t work. Basically [we] get a good idea what are the opportunities and what we need to solve for with the new technology that’s going to be selected.

Often times, depending on the scope of the selection, we’ll have eight to ten individuals or small groups that are interviewed as part of the process. We usually have a walkthrough for each system and if you have an ERP or an accounting system as an example, those walkthroughs might be of the core financials modules, if there’s an integrated time and expense, we would do a walkthrough of those modules, if there’s integrated payroll, we do walkthrough of that and so on and so forth. Those can be a number of walkthroughs if you have a major system that has other interconnected parts to it.

Sometimes there’s an opportunity to get information that is helpful to inform the selection from a broader group of people inside of the organization, and often we’ll use a survey for that, using SurveyMonkey or Qualtrics or something of that nature. The questions can range from specific questions about what technology they’re using today, to what their experience has been of technology change at the organization previously.

You are really trying to see what the landscape of technology solutions are inside of the organization, such as what file management solutions people are thinking about. If you’re going to select a new file management solution you want to know, well we have Google Drive in use over here and Dropbox over here and Box over here, it’s good to know what the current landscape is.

And then for the latter example that I gave, it sometimes is good to give or get sort of a practical or sometimes they call it an emotional barometer check of what people’s experience with technology changes been inside your organization. You [need to] know what hurdles you’re going to have to overcome from a trust standpoint, or what key elements of change management you’re going to need to apply, to make sure that those people who have had maybe a negative experience of that kind of a change inside your organization previously or [need to] feel well supported during whatever you do subsequently for this new effort.

Jennifer:  Thank you. I’ll add two things, one is that we often uncover things that we didn’t know about, like oh, well I really just use Excel to do these things and that was in on the inventory that we were given. So sometimes there are some surprises or things that people feel more comfortable sharing verbally then in writing. And then, obviously the other benefit of this interview and system walkthrough process is that you’re getting buy in, hopefully. You’re listening to people. You’re not promising them that they’re going to get every single thing that they want or need, but you are giving them a chance to have their voices heard.

Peter:  I think one somewhat extreme example of finding out about things that you had not known about previously in your organization is that I had a client come to us one time saying that they wanted to implement an org-wide content management system for their websites. And I said, well, how many websites do you have? And they said, we have 46 websites that we know of—meaning that they were a large organization that ran a lot of programs and every program had booted up its own website over the years for its program. Turns out they actually closer to 72 websites when we did the survey to identify what program websites were still active in different parts of the organization. When you take a broader view or investigatory approach to what technologies in use inside of your organizations, you’ll find out who’s been making their own reports in Excel instead of running them out of the financial system or whatever so, it’s always fun what you learn there.

And then part of a business requirement is about process, yes, but also about data. So it helps to understand and get a cross-system view of what data your organization manages. This diagram that you can see on screen is just an aspect of a revelation of that, it says across all of the different data basis and all of the different systems, these are the major conceptual data objects and their relationships. This notation style is called Crow’s Foot Notation and it helps to describe what the relationships are between the data.

And then, you also might want to do a detailed inventory of your data, so across all of the different parts of your organization, though the different stages of the journey life cycles. What data is collected? How is it collected and through what type of form field? What values are there, when it’s required and how it’s validated all these different kinds of things? It’s important they get the stuff right or get a good common understanding of what you are doing today within your organization before you can move on to represent to an outside vendor, what you really need to do or what their system will need to accommodate in order to support your organization.

If you don’t do a full discovery of your data before you go into a selection for say, a program outcomes management system, there might be data—parts of your data that you get into the implementation and you say, oh, yeah, we forgot, we also need to include this and the vendor says well, our system isn’t capable of handling that kind of data or meeting those kinds of requirements.

And this is why I say that getting the requirements definition right is the key factor in whether or not the implementation is successful, as well. You really want to make sure you do your requirements development as thoroughly as you can upfront before you actually start engaging with vendors around their process. And because that’s such a robust process, we often encourage clients to not to go out to do a selection where they’re just trying to get responses from say 12 different vendors. We try to get them to prequalify vendors and vendor solutions, so that they can take the time to engage deeply around sets of requirements with a smaller set of vendors, and that ultimately often leads to more success. We’ll talk a little bit about engaging with vendors more in a minute.

Jennifer:  I’ll just add one note that what I hear from clients is if you go in to talk to vendors or ask for demos without doing this pre-work of the requirements, they’re just going to give you a demo that says yes, we can do everything.

Peter:  Yeah.

Jennifer:  And so, something to think about.

Peter:  Yeah. Because Build Consulting goes through this at some level with our clients, we often get feedback from vendors that our clients have the best RFPs that the vendor has ever seen because it really provides the information that the vendors need to be successful as well and they’re vested in having satisfied clients.

Technical Requirements

I’m going to talk a little bit about technical requirements as being complementary to business requirements. So, this is just a visual map of how one organization that was a client of ours thinks about all of the different integrated systems that they have and over time they’ve implemented different aspects of this. They started with Drupal and then they added the Form Assembly and they added Salesforce Communities and integrated with that. So, what I’m trying to say is that this technology landscape picture wasn’t created all at one time, it evolved overtime, this is sort of visual representation of where the integrations are and how the date is exchanged at a very high level.

But for each particular system that you see here as well as the across systems, there are variety of different technical requirements which the organizations should be taking into consideration and then talking to vendors about during the course of the selection. And they range from the security, how the data model is structured inside of the product that you’re selecting? Is it sufficiently relational to allow for the kind of reporting that you want? Is the data easily accessible and portable?

So for example, if you need to pull data out of your system to do some kinds of advanced reporting that the system won’t support, or you want to be able to connect to a tool like Tableau for business intelligence, reporting, or data visualization, or if you even want to be able to take that data at some point in the future and move it entirely to another solution. Data accessibility, portability, how it can be integrated with using APIs, and whether it’s based in modern technology. Technology that is current and sustainable rather than outdated architecture that was originally built 20 years ago and hasn’t been updated in some time.

Elements of what the user experience is like in the interface, and then how can the software be configured or customized. To provide a distinction, configuration would be things that you can adjust in the system using settings or out of the box functionality, that allows you to control or configure the solution versus customization which we think have us more coding.

So, these are things that are good for organizations to think about particularly because you will run across some vendor and the software tools in the space that don’t have contemporary security policies, and yet somehow, they’re still making a good living working inside of the sector. That may work for some organizations, but it might not work for yours. So, you want to make sure that you take security into consideration and that you have somebody that’s working with you in your selection process that can really speak to that need.

Working with Vendors

And that leads into a topic about working with vendors and there’s a few questions that we got and commonly get about the vendor engagement process. First of all we do like to try to encourage our clients or work with them to prequalify vendor or solution candidates, so that they’re deeply engaging with a small number of solutions or software that are well positioned to meet their needs rather than doing this huge open RFP process with multiple different vendors representing multiple different systems.

And then within that context one of the questions that’s often asked is, well, do we need to really go through a formal RFP process in order to make the selection? And for starters, I will say that depends on your procurement policy. You may have to go through a formal, some might say rigid process, issue a formal structured RFP, have a structured response approach for getting the proposals, Q&A phase, all that kind of stuff.

But if your organization doesn’t have those kinds of requirements and you have a little bit more latitude, it might be good for you to put an RFP together, and you may not need to go through that process. The main thing is that you provide a sufficient level of requirements information to the vendors so that they can make a response that speaks directly to the needs of your organization, and that that you give them some evaluation criteria, so they know how they’re going to be judged when you’re making decisions.

It’s good for you to know what those things are just for your own internal decision-making process, but those things need to be clearly communicated to vendors. And you really need to as much as you can make sure that your process is well structured enough so that you’re giving each vendor that you want to consider as a serious competitor for your business an equal amount of information and opportunity, so that you can better make apples to apples comparisons between responses and also just to be respectful of the vendors and not give anyone favoritism.

This can create a challenge when you’re not really experienced or don’t have a structured process and you’re kind of learning as you go along with the vendors during a selection process, and sometimes the vendors that you engage with a little bit later in the process have a much better example or a much better opportunity to win your business because by then you’ve refined what you want, by speaking to the earlier vendors. So, to be fair to all of the vendors and really get the best response out of each of them, you want to be as prepared as possible, although it is inevitable that you’ll learn some new things as you go through the process.

Vendor Demos

Jennifer:  So Peter, just to clarify at the beginning you said, it might be good to get some general vendor demos just to know kind of what’s possible or what is it that I don’t know that I don’t know about the finance systems on the market today, for example. You’re saying don’t prepare for that, just kind of take that all in but when you get ready to send, to reach out to those three or five, however many you’ve reduced it to, that’s when you need to send in the technical requirements, whether it’s in an informal document or a formal RFP.

Peter:  Yeah, I kind of break demos into two categories to your point. There is the early sort of educational demos that you might take just to help your organization think better about this space in which it’s making the selection, what the range of technology options that are available and use that to inform your own requirements. And then you might or might not end up getting those vendors or bringing those vendors along that you demoed with early into the later stages of the selection effort and that’s fine.

I mean vendors who know how the game is played in the space, so to speak, know that they have to invest some of that time to help educate organizations as part of an upfront sort of presales effort. And often times those demos will be a little bit more general and you want to get a broad sense of what the capabilities are that are out there. To your point though once you get past the RFP response process and you have those proposals, you’re going to want to also do more specific demos at that time, things that are more specific to your organization or use cases that you have for the software that might push the edges of the capability of that product.

So, we tend to do at that stage sort of let in the late selection stages, demos that we call scripted demos, where we’re giving the vendors specific scenarios of process use that we want to see it demoed in their tool rather than just having those things spoken to or addressed in a more general manner. And we found that doing those scripted demos is very critical to making good decisions and also really helping to make sure that you’re making decisions based on what features are available in that software today, not what might exist in the future or is currently in development.

Avoid Falling For Future Features

Because there have been many times when nonprofits have the selective system based on what was promised in a future roadmap and then not have that roadmap ever be accomplished or realized by the vendor. That can happen for a variety of reasons. It doesn’t necessarily mean that the vendors are nefarious in their intent. It just means for example, that they might seem a competitive threat in a different area of their software functionality from another vendor and then might decide to reallocate their development budgets to have functionality in a different area, so these things happen. And so, it’s generally best to make decisions based on what features and functionality are available today and not what might be available in the future.

Vendors vs Implementers

And then last, we often encourage our clients to understand that in many areas of software there’s a difference between the software vendor—the vendor that creates and builds the software—and who is going to be implementing that software. Sometimes they’re one and the same, so for example, we’ve seen some case management solutions over the years in the human services space, where the only implementer of that solution is the company that created the software. But for platforms like Salesforce or ERP Solutions, like Intacct, or anything that’s built on the Dynamics 365 platform, [and in] many other areas, there are variety of implementation partners. And sometimes when you are doing a selection in one of those categories, it can become very confusing if you are getting multiple different proposals from different implementation partners representing different platforms.

So let’s just say for example, that you’re in the market for an accounting system and you had an open RFP process, and you got responses back from vendors representing NetSuite and Intacct and Workday, and Dynamics 365 BC, and you had all of this information to take into consideration from different vendors talking about different approaches to implementing different systems.

That can be extremely complex to do an analysis on, and it usually doesn’t lead to an effective selection. So, what we often encourage clients to do is work through a process where they are selecting the software first, and then the implementation partner second. So, say we are going to choose in a CRM cloud platform environment, we are going to evaluate Dynamics 365 and Salesforce.

We are going to make a decision between those two platforms, and then we’ll ask for two to three implementation partners for just that selected platform. So say you select Salesforce, you maybe want to get two or three proposals from different Salesforce implementation partners. And even within that, you will get a diversity of approaches. So one vendor might say, well this module is perfect for meeting your needs. And another vendor might say, on that same platform we would actually recommend this other module. So, you will still get a diversity of perspectives and doing that helps you to make sure that you can make apples to apples comparisons that lead to a good selection process. And if you have any follow-up questions around this idea of selecting the software first, and then the implementation partner, feel free to reach out to us, it’s a complex area knowing when to do that and how to do it. It can be a little bit of a dance sometimes.

Particularly since some software vendors do not like to compete their implementation partners against each other. So, you have to know kind of what buttons to push say, if you’re approaching Sage Intacct, as an ERP solution, to make sure that you can get more than one Intacct partner proposing or bidding for your work, because sometimes they can be reluctant to compete their partners against each other, which is understandable, but not always in your best interest as a nonprofit.

Jennifer:  And we also hear the term systems integrator, right?

Peter Mirus:  Yeah.

Jennifer Keller Jackson:  Implementation partner?

Peter Mirus:  That’s right. So we’re running short on time, and I’ve got a little bit of information left to cover, some—I’m going to move a little more quickly now, but again, as we have said before, feel free to reach out to us, if you have any follow-up questions.

Evaluating Costs

So some clients ask us, well what should we think about when we are doing budgeting for new systems?

And these are some of the key areas that you want to think about, not just what it’s going to cost upfront, in terms of implementation fees and the first year of your licenses, but also, what are the recurring cost for licenses over time? A lot of organizations don’t take into consideration the internal roles that they will need to implement that software within their organization, and the level of effort, and they don’t really think about the cost of the time of those people, but it definitely has a cost, because oftentimes that will be pulled away from other, sometimes programmatic type responsibilities to be able to participate in the implementation.

Professional development training, ongoing solution management, internal and external support for the software say your internal helpdesk, plus whatever supplemental support you might need from a vendor, and then change management. So, you really need to take all of these things into consideration.

And another one of the major reasons that technology implementations fail is because organizations only look at the cost of license as an upgrade, upfront implementation fees when they’re budgeting. And then realize later that they have gotten, caught short in some of these other areas, and they aren’t able to get the adoption of the software that they wanted, or folks don’t know how to use it, or it wasn’t supported over time, so it didn’t stick. There is lot of different things there.

And change management also being a huge factor that’s under budgeted for and for that reason is a huge focus of Build Consulting’s approach. We’re very change management focused, and we weave that into everything that we do. And we do try to make it efficient, so it doesn’t blow out the cost of these projects unduly, but it is a major important component.

Making a Decision

And then I want to talk a little bit, just finally about making a decision. So sometimes organizations get to the point of making a decision about which software is best for them and they can get stuck. And there are variety of different reasons for that. One is that they may not have had the level of engagement throughout the process that they needed to have informed decision makers at the table when it comes to actually making the decision.

And sometimes particularly executives inside of organizations feel that they can be remote from the selection process than sort of parachute into the room when it comes to making the purchasing decision that doesn’t often work very well. And but there are other ways that you can have problems with engagement, and I discussed some of those earlier.

Sometimes the organization didn’t take into adequate consideration, how the investment in the new software would compete with other organizational priorities, and their strategic planning. So, when they get to the point of making a decision about the software that can be the first time that they are actually comparing that budget to other budgetary needs inside of their organization.

A great example of this is, over the last two years, say particularly the last year, a lot of organizations have decided to invest strategically in diversity, equity, and inclusion initiatives. But then put that together in their heads with the expense of the CRM that they were thinking about implementing.

And sometimes you can’t predict these kinds of things, but it’s good to understand what all of the major strategic initiatives are that are going to be competing for budget during the period when you are actually gonna be making the selection, and during the implementation. If you have gone through a really extensive selection process and you’re still not sure, oftentimes you can do a little pilot engagement with the software vendor, in order to get a portion of your processes that might be a sticking point for you modeled out in their software, so that you can get a better understanding whether or not that will be successful for you. Or even to just develop greater amount of comfort in a decision that you have already mostly arrived at.

And knowing how to approach vendors and set expectations for the idea of conducting a pilot is, is important to being successful in that, and making sure that its scope is sufficient to give you the information that you need, but not so much that you feel like you’re halfway down the road with the expense of the entire software before you actually get to that decision point. So, piloting is definitely something to think about and it can help support final decision making, particularly when it comes to complex system.

Voice of authority is one of the ways that I refer to, who is going to be making the final decision. Sometimes when you get to the end to selection process, and you have different software products that are preferred by different stakeholders, and you don’t identify prior to that, who is going to be making the final decision, or who is going to be speaking with the authority of the knowledge of business—the business and technology to be able to make that decision.

And that can lead decision processes getting bogged down for a quite some period of time or sometimes, a decision not even being made, or selection projects being entirely rebooted from a scratch. So, you want to make sure that you know who those voices of authority are going to be inside of the organization and making sure that they are engaged throughout the project.

And then finally, we have gotten questions about losing momentum during the course of selection processes. So for example, you will get proposals back from vendors and then those review processes can drag out for a long period of time, sometimes to the point where the product has changed and the new release or the licensing costs have changed, or you just lose continuity in the project and the projects can die all together by getting moved to the back of the stove.

Those are some of the perils of letting the process drag for a selection. And then in terms of rushing, often times clients just want to get to the new software without doing the requirements development upfront, or without building the stakeholder consensus. So, there are dangers to doing selections in a rush as well. I think I wrote a blog post about that recently in our site that you can check out if you’re interested.

One final piece of advice on making selection between software systems, because I know we are out of time. Sometimes when you are having trouble making a decision between two competing software products, it can mean that’s because you have two great products to consider, and that your organization isn’t going to lose by choosing one over the other.

And sometimes when you are really in problem solving mode, which selections can get into, it seems like you can’t decide between the two choices, well that might not be a bad thing. It may just mean that you have two good options to consider.

So that’s all we had to cover today, based on the questions that were submitted. I really appreciate all of the questions and the feedback. And again, if you would like to consider the conversation—continue the conversation with either Jennifer or myself, here our email addresses or you can communicate with us through our website.

Do you have anything that you would like to add in conclusion, Jennifer?

Jennifer:  No, just thank you, Peter, you are a font of information. If you were wondering whether we have preferences over one software over the other, that’s a question we sometimes get. We are at Build, fiercely independent. So, we go in with no preconceived biases or solution, and we let the process inform us, the people, and the process inform us on where to go. So, thank you for your time, thanks again to those of you who submitted questions ahead of time and happy Thursday afternoon everybody.

Peter:  Have a great evening everybody. Thank you for joining us.