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, Google, Stitcher, Pandora, and more. Or ask your smart speaker.
Selecting Nonprofit Software: Technology Comes Last
Community IT Innovators was pleased to collaborate with our partners at Build Consulting for this webinar on Selecting Nonprofit Software.
Nonprofit organizations often struggle to implement new software. But the seeds for successful implementations are planted long before, during the software selection process.
In this webinar, Build Consulting experts lead a discussion of why, to be successful with new software at your organization, technology must come last.
This webinar is appropriate for nonprofit executives, managers and nonprofit IT personnel – and as with all our webinars, it is appropriate for a varied audience.
Presenters:
Peter Mirus, former Partner at Build Consulting, is an expert at helping organizations and people to learn, communicate, and grow through the use of information technology. He has more than 15 years of experience as an executive, strategist, analyst, and solution developer, serving more than 30 non-profits and 40 professional services firms ranging from start-ups to large international organizations. For more of his thoughts on this topic check out his recent blog post here: https://buildconsulting.com/selecting-nonprofit-software-technology-comes-last/
Over 20 years ago while doing a year of volunteer service at a nonprofit, David Deal found his passion by helping a nonprofit and its staff use technology effectively. His career has built on that theme ever since and in its newest expression is Build Consulting. As a Partner at Build, David gets to guide and support nonprofits in developing their information management capacity. He recently weighed in on issues in software selection in this blog post https://buildconsulting.com/selecting-software-how-to-avoid-paying-for-more-licenses-than-you-need/
Kyle Haines is passionate about all things design. An architect at heart, he finds joy in creating evocative and engaging “things”. This passion spans his personal and professional life and is most notable in the visually engaging way that Build Consulting communicates. While a Partner at Build Consulting, Kyle also volunteers with organizations to improve the sustainability of his community. His experience in design allows him to delve into the software selection process with an eye to successfully fitting the eventual implementation to the organization’s style, culture, and needs.
Transcription
PETER MIRUS: Welcome everyone to our webinar presented as the partnership between Build Consulting and Community IT Innovators. In this webinar, Build Consulting’s panel of experts will be answering the questions you submitted regarding selecting nonprofit software. You can read more information about this topic in our blog. A link will be provided near the end of this webinar. And if your specific question wasn’t addressed during today’s session, please contact us for an answer. Links for contact methods will also appear at the end of this webinar.
Before we get started on the webinar here are a few housekeeping notes. Please feel free to ask question via chat. We will try to weave them in as we can. Try to avoid multitasking. You might just miss the best part of the presentation. As always, links to recording and slides will be shared after the webinar.
Now, a little bit about Community IT and Build Consulting. We both work exclusively with nonprofit orgs to help them make information technology and information system decisions that support their mission. We both take a collaborative approach empowering our clients to make informed choices for their organizations. Community IT is focused on providing outsourced network management and technical support services. Build Consulting leads in the social goods sector by providing three types of services. We serve as part time or interim chief information officers for nonprofits. We perform business process technology and data projects ranging from strategic assessments and technology roadmaps to system selections and implementations. And with Build teams, we provide outsourced data managers with deep development operations experience and nonprofit CRM expertise.
My name is Peter Mirus, and I’m serving as the moderator and as a panelist for today’s discussion. I co-founded Build three years ago after a 15-year career in marketing, development and information management for both the nonprofit and for profit sectors. And over the last three years, a good amount of my client projects have revolved around selecting and implementing or improving existing CRM and accounting systems or ERP systems including integrations between the two. I’m passionate about helping nonprofit organizations fulfill their mission by leveraging technology and I’m very happy to be with you today. And I’m also happy to welcome two of my colleagues from Build consulting who along with myself will be serving as the panel experts for today’s Ask the Expert’s session.
First, David Deal, also a partner with Build Consulting. Will you please introduce yourself David?
DAVID DEAL: Thank you Peter. I’m David Deal. I’m founder and CEO of Community IT and more recently a founding partner at Build Consulting. I have spent my 25-year career in nonprofit technology, and I’m glad to be here today to contribute to our panel of experts.
PETER MIRUS: Kyle?
KYLE HAINES: Kyle Haines, partner at Build Consulting. I’m always excited anytime anybody thinks I’m an expert in anything, so I appreciate being invited to today’s webinar. And I guess, why I was most excited to be on today’s webinar is because I think often times selections are the beginning of implementations. And I think they are incredibly important to do well and to get right, and so I’m excited to see the questions today and share my experience and wisdom that I’ve gleaned over the years.
PETER MIRUS: Thanks David and Kyle. We would just like to share a few thoughts with everyone on the webinar attending before we get into the questions and answers. The first is this slide that we often share with our clients. It means Old Organization plus New Technology equals expensive Old Organization. We just share this to illustrate how transformation is critical to success. As Kyle just said transformation or change management or any successful organizational change process involving technology begins with selection, if not prior to selection. It’s a lot of what we are going to be talking about today.
And when people ask what does successful transformation involve? Well, it goes all the way back to leadership and governance and your operational capacity, the processes that you execute as an organization, the data that you manage and then finally technology. And that’s why one of the subtitles or the subtitle for this webinar was technology comes last. It really is the last thing that needs to be taken into consideration for successful technology selection and implementation projects. A lot of things upstream of the technology selection actually need to be well ordered or done as part of the selection process in order to make sure that that resulting implementation is successful.
And now, we would just like to get into the questions that you shared with us in advance when you registered for the webinar. We received a number of excellent questions, which we have boiled down into 10 that we plan on answering during this session, and if we have extra time we will take additional live questions. Again, feel free to use the chat features of Go to Webinar to submit them as we go, and I’ll try to weave them in as we are answering other questions or at the end. And it’s an informal, collaborative discussion between the panelists. If you would like a more comprehensive answer to a particular question or that speaks more directly to your individual situation, please don’t hesitate to reach out to us and we’ll be happy to have a conversation with you.
So without further ado, let’s get to the first question.
We are about to select a new CRM. What are the top two or three things we can do to make the selection successful?
PETER MIRUS: We are going to talk about the CRM specific question here. But most of our responses I think are going to be applicable to all major system categories such as accounting systems or marketing automation or e-commerce platforms. And I’m going to just lead off by answering this one and then tee it up from my colleagues here. I think the number one thing that you can do to be successful with the selection is to do solid business requirements definition. One of the things that contribute most to technology implementation failures, which is about 50% of projects is that you have good requirements definition and that process is led by somebody that’s been through it before. Guiding the business requirement’s definition process is one of the reasons why people are engaged with Build Consulting, and these kinds of efforts because we have a lot of experience in that. David, how would you go about answering this question?
DAVID DEAL: So a couple of things come to mind for me. I think the first is participation. And what I mean by this is no one likes having software forced upon them. So I think it’s important to determine which individuals and teams that new CRM would impact and make sure the individuals and teams that are engaged in our process in some way. That’s the first thing that comes to mind. I think the second is vendors love nothing more than to reach you early in your process, to get you into their way of selling their software. They want to give you a demo. They want you to try it out. So I would say make sure you are driving the selection process, not the vendors. And that means first to Peter’s point, understanding at a high level what you need the CRM to do. What your requirements are? And then making sure that those vendors show you how their software does those things. Not just the dog and pony show, but how is their software going to execute the processes that you need IT to execute?
KYLE HAINES: Yeah. This is Kyle. I think it’s incredibly important also to understand, and I think David you touched on this, how this project and how the implementation of any system, but especially an CRM system, how it’s going to impact your organization? And I think given the number of people who would be touched by it it’s important to get leaders to sing from the top of the mountain how important that project is, how much they appreciate the hard work that is going to be involved in selecting a new solution and make it a frequent refrain. Make a refrain on how important this is and what the return on investment for the organization is going to be.
PETER MIRUS: That is a great point. And I think we are going to answer some questions to build on this specifically in regards to requirements and who needs to be involved, change management aspects so we are going to leave it there for this question for right now and get back to it in different deeper ways later on.
This next question is:
My executive director wants to go with solution redacted [Shiny Solution X], but I’m not sure it is right for us. How can I pump the brakes on that?
That’s an excellent question and one we hear at a lot of nonprofits over the years. Kyle, what would you say on this one?
KYLE HAINES: Yeah. I mean, not only do we hear it all the time. If you go to a vendor conference you see people wandering around starry eyed with promises that that new solution is going to be the thing that transforms how the organization works. And I think it’s important to acknowledge that there is always going to be a lot of excitement around new or popular technologies. And often also, you need to recognize at least in my experience that this is historically how organizations have selected software. It’s based on what they hear from others and they feel that’s what they are colleagues are doing. It’s what the organization that they inspire to be is doing. So the shiny object syndrome is not unfamiliar or uncommon. I think what I tried to do is orient the organization first around documenting their requirements. And even if it’s framed as an internal exercise only, it is something that you can reasonably and accurately say this will ultimately help with the implementation of that shiny new object, if that’s the direction the organization ends up going. Once you have done that — once you have a sense of what your internal requirements are maybe you can then see with your executive director or whoever is pushing or advocating for the change, see if there is a willingness to make sure that the requirements that you have identified that the new solution is actually going to meet those requirements. And in some ways this is a backdoor way of doing a selection.
DAVID DEAL: This is David. I’ll just add a couple of things to that. I think Build has some webinars that emphasized that technology comes last such as this one. But I would encourage you to point your executive director to one of those or maybe take a still frame from one of them showing that about 50% of CRM projects fail or one of our blog entries that talks about studies showing that 30% to 70% of enterprise software projects fail. So, I think that’s one thing you can do to say, “Hey, let’s slow down a bit.” Let’s do the requirements definition that Kyle was just talking about or — I should say and promote the idea that the organization really needs to start and the leader needs to start by envisioning and articulating the change that he or she wants to see in the organization and articulating how technology can support that organizational change. There are probably — there is probably more than one solution and almost every scenario that can meet those needs. The second thing is if you want to play a little bit of hard ball here, if it’s a big dollar investment just ask if the leader really wants to go in that direction without the due diligence required to make an informed decision.
PETER MIRUS: That is a great point. This is Peter again. The only thing I would add to that is that sometimes where the solution that’s being sought is a platform like SalesForce, you might have an executive director that says, “Well, we should go with SalesForce”, but not really understand the infinite variety of possibilities that could exist within that platform even just for something as specific as gift management or case management. So, really just doing some education there sort of politely probing and to well when you say SalesForce or when you say Dynamics or anything else or when you say even LMS, Learning Management Solution, what does that mean? How should we interpret that? Give them a little bit of exposure to the breadth of various options that are available there. And it might not be as clear cut of a solution as the leader originally anticipated.
KYLE HAINES: That’s — this is Kyle. That’s an interesting point that you just made Peter. I actually have a client right now that began with the supposition that they needed a learning management system. And through the process that we are talking about actually recognize that LMS was a part of what they needed to do, but it was actually an entirely different type of solution that they needed. So, I really think that’s also important for the organization to understand that sometimes the shiny object they think they need they actually need an entirely different maybe not even shiny just a different object altogether.
PETER MIRUS: Yeah. Speaking of CRMs and our next question here:
The last time we implemented a CRM it failed miserably. How can we prevent that from happening in the future?
David, what would you say in response to this?
DAVID DEAL: Yeah. So I think, you know, Build would start by asking what went wrong and why because failure is really one of the best teachers. It’s probably the best teacher. And you know, it can be an uncomfortable place to go to talk about why it failed especially, if you are trying to be thorough and transparent in that process. Sometimes it failed because of the people involved frankly or sometimes it failed because the leadership didn’t provide sufficient vision of how people should use the system. So, I think to answer it effectively you have got to be willing to go there. It helps to have some degree of objectivity in that analysis, and I know that can be difficult for someone inside the organization particularly if it involves assessing the capabilities of team members. I think the second thing I would ask is how are things different now? Have the conditions at your organization changed to give you a greater chance of success? Success is never guaranteed in these enterprise software projects and CRM projects and are the necessary pieces in place to do that effectively? If the answer is no, you are probably going to get the same result.
PETER MIRUS: Kyle, do you have anything to add to that?
KYLE HAINES: Yeah. I mean, I’m thinking about the CRM implementation as it relates to other types of implementations. And I think in some ways they are some of the most tricky implementations. I can think of a couple of reasons that they are tricky. One is that they often times involved an expectation that staff behavior is going to change alongside that CRM implementation. So, a fairly dated but classic example is the technology is envisioned to help major gift officers use the system more effectively and guide how they do their work. Well, that involves behavior change. And I think we have hit upon in multiple places in the webinar already that technology rarely drives behavior change. So, on a CRM project thinking about what behavior has to change, and how you are going to encourage or enforce that change is important. Secondly, with CRM projects I think about in some ways the constituents or the consumers themselves are the change. They are the ones who are also going to feel the impact of the change or at least hopefully feel the impact of the change through better tools that will allow you to manage and engage with constituents effectively.
PETER MIRUS: Yeah, the only thing that I would add to that is that a lot of organizations in my experience do a couple of different things, and this is particular thorn in the side of organizations that are trying to do CRM implementations because of the complexity factor that Kyle mentioned. One is that they don’t often do, for a lack of better expression, post mortems on prior projects. Failed technology projects are kind of like, you know, the thing that people want to avoid talking about. The team members avert their eyes when they see each other in the hallways after a failed implementation. So as David said that can be a challenging thing to revisit, but it’s important to do so. Also nonprofits — and this is true of other kinds of organizations as well in the for profit sector, don’t do a great job of estimating the amount of time that it takes to select and implement a complex system effectively. They just sort of figure well it will get done because it has to get done but there is not necessarily any increase in resource availability to make that happen. So, it often times gets side tracked or time gets cheated away from it. It needs to be applied by competing initiatives so just the ordinary every day business of running the organization. So those are other challenges. And really scoping to make sure that you can select and implement a CRM effectively is a big challenge. And we will touch on that a little bit more in a few minutes.
This next question is a good one and we touched on this earlier as well in the first question.
Who needs to be involved in the selection process?
And I’ll take the lead on answering this one. Usually there is some sort of a core team and then there is an extended team of other stakeholders that need to be involved. For the core team, you might have a range of executive sponsors, department managers or managers within the department that are primarily affected and some external advisors or consultants whether those be vendors that are competing to provide a solution or a consulting firm like us that’s providing some strategic assessment systems.
And then, the extended team or the other stakeholders might include key subject matter experts from within the organization people that know the business and its processes really well. End users, peer organizations sometimes you can — for CRM system specifically you might want to ask a couple of your peer organizations what they are doing and what they are using and what kind of experience or successes they have had with it. Board members can sometimes be involved in the extended team depending on what kind of board you have. There is a variety of different folks that could be included there. But the core team should be the people that are responsible or accountable for making sure that the selection and the subsequent implementation are a success and then the other stakeholders sort of fall into that consulted or informed category. Kyle, what will you add to that?
KYLE HAINES: I think the only thing what I was thinking about and I talk about this a lot with my wife actually who works for the retailer QVC what makes the nonprofit space unique when it comes to these types of selections is that people want to feel connected to the understanding. They want to feel connected to the process in some way and how the organization arrived at the solution. And I would say as a rule anyone who is going to be impacted by the new technology or the new software should feel like they got a voice in the process. And that voice can look different. Sometimes it can look like simply asking through a survey for feedback and input. Other folks are going to expect a seat at the table in selecting the software. And each project is going to look a little bit different. And you talked about different types of participants in the project or in the selection, Peter, so you can tailor the engagement with those groups in different ways depending on whether they need a seat at the table or they just want to feel like their voice contributed to the solution itself.
And one of the ways that I help clients often identify those people is using a tool that we actually you can download from our site. It’s a change management impact grid. And it catalogs who is going to be impacted by a change and the extent of that impact. And it’s amazing to me how difficult sometimes it is for organizations to develop that list and really understand the list, but it’s invaluable at the outset because it really creates a panoramic understanding of all of the folks who are going to be impacted by the implementation of new software.
DAVID DEAL: I’ll just add something quickly here about the term core selection team. I think what I envisioned — what we envisioned when we say that as a group that you know in my experience it’s typically six to perhaps 10 or 12 people at the absolute most. But this is the group that’s responsible for reviewing and contributing to the things that are being published as part of the selection process like an RFI or RFP. This is the group that also participates in the vendor demos, so it’s important that it be a representative group and that it also be a group that is large enough to be representative but also small enough to be nimble in being able to make decisions or at least make recommendations to whoever is making a decision.
KYLE HAINES: Yeah. I would just add really quickly. I think that that’s right and I think — but also you want some diversity on that team as well from the perspective of diversity of different experiences and perspective and history of the organization. So, you don’t want 6 to 10 people that are just going to green light everything. You really want people who are going to ask tough questions and represent a broad swath of perspectives from across the organization.
PETER MIRUS: Yeah. David and Kyle, that is a great context to sort of relate the stakeholders to the different parts of the process. The change management impact template that Kyle mentioned is available, if you go to the buildconsulting.com website and then go to Resources and look under Learning. You will see that featured in that list of resources that are available. Walk, don’t run and after the webinar and check that out.
We move on to the next question.
We want to select a new software for a particular challenge, but I feel like our managers don’t know what business processes they want to follow. How important is it that the managers pick the business process before they go into selection?
Their business process is not the process of doing the software selection, but the business process that they are responsible for executing inside of the organization whether that be gift management or managing an online community or whatever the business processes. So, how important is it that the managers pick the business process before they go into selection? David?
DAVID DEAL: I’ll offer a couple of things here. I think first of all, clearly, it’s crucial. Having a vision about how the organization wants to function and how a piece of software is going to support that is a vital part of the successful implementation. A lot of times, I will hear people, you know, staff described that they are unclear on the current system because they haven’t been told how they are supposed to use it. They will say they haven’t been trained on it. And a lot of times what that will come down to is they haven’t been given clear guidance on here is how we use this system to support our process. So, it’s less the mechanics of training and it’s more having a vision and a clearly articulated one at that for how it’s going to be used both broadly and specific to certain business processes.
The second thing I would say is that there are really a couple of things you are balancing here. One is that you do want to be clear and prescriptive about how you want to work so that a vendor can understand what it is that you want to do, but you also want to be open to suggestions that a vendor might bring for improvement. So we really encourage thinking of the RFI/RFP process as a conversation. So you want the vendor to understand how their software needs to support you and you want to be open to the ideas that they may bring to that process. Not every vendor is going to be able to do that but the best vendors and the best systems and implementation firms will have some ideas and some prior experience to inform how the software might help you to operate more effectively.
KYLE HAINES: Yeah. I will always look for a way and its different ways. It could be an RFI or an RFP. It could be some other way. I think it’s incredibly important for vendors to have an understanding not only of how the organization works but what organization are they walking into? And there are three things I think that are important. The first one I learned from working with you Peter is that it’s important that they understand the people that they are going to be with on the project. How experienced are they with the type of project that the organization is taking on? How familiar are they with the types of technology that they are going to be selected? Is this the very first Learning Management Solution they are ever going to use or are they working with somebody who this is the fifth job they have worked at and who worked at five different learning management solutions? That’s incredibly important to communicate to vendors so that when they are thinking about what it would mean to work with your organization the experience that the organization is bring into the table. And along with the people it’s also important for the organization — sorry for the vendor to understand how experienced the organization is.
So if in my example, earlier, if the lead person has worked in five different learning management solutions but the organization has never worked with one that’s important information for the vendor to have. It’s important because they need to know that they were going to have to lead many conversations in the implementation. They are going to have to bring expertise to the project that the organization might not have onboard themselves.
And then lastly, I think the more you can communicate how your organization functions and I mean makes decisions what the decision making process in general looks like and what the decision making process for selection looks like, the more information you can give the better. And this is more than just copying and pasting stuff from your website. This is giving the vendor as much as you can an inside baseball understanding of the organization.
PETER MIRUS: Thanks, Kyle. So that segues nicely into the next question which is:
How do we define the requirements for the software that we need?
I’ll take an initial stand by that and then hand it out to you Kyle to fill out my answer. I think there is a number of different ways to approach it, but one of the things that I often prioritized is sort of for the business requirements identify the specific workflows that are required to support from the system. So, if I’m looking at a CRM system for example, I might say well the constituent lifecycle for this particular client starts with marketing, so that’s when you are sort of identifying as yet unknown constituents and then all the way through when that constituent is not longer engaged with the organization and all the steps in between. Those are all different process areas that often will need to be accounted for in a CRM system or other pieces that are integrated with the CRM system. It often starts just with mapping out the business lifecycle associated with a particular part of the organization at a high level and then really diving down into the specifics.
And then, you also have to look at non business requirements, the technical requirements such as integration with the other third party tools or the capabilities of the API solution. So, broadly speaking, we are breaking things down into the business requirements and technical requirements. And then within business requirements we are breaking it down into the entire process or processes that have requirements developed and all their individual steps as well as who is performing the steps and what functional areas of the organization those people fit within. Kyle, what would you add to that?
KYLE HAINES: I like how you made — you do the distinction between business requirements and technical requirements, and I think there is a lot of wisdom in that. I think often times what people get hung up on is creating a massive list usually in Excel of every single requirement that they need. And for those of you who know me and David and Peter, certainly know this I love analogies. This has probably been the longest I have ever gone without using an analogy, but at the risk of an analogy falling flat I think that sometimes those lists in Excel of every single requirement that you need is a little bit like going to shop for a new car and listing out that you need a horn, you need a seat belt. You are going to need an airbag and you are going to need a backup camera. And I use this analogy because every single car has these things now even a backup camera. I think post 2017 every car has to come up with a backup camera. So, sharing that information with the vendors is not particularly helpful. They are going to tell you that they have a backup camera. What’s important is for the organization to understand; are you looking for a sports car? Are you looking for a sedan? A minivan ? Did you need an SUV? And if you are getting an SUV, how big of a garage are you going to need? Are you going to be able to park that RV — sorry — that SUV in the garage? How much your insurance is going to be for that new car? How much are the oil changes?
And I use that example because I remember right out of college buying an SUV as an impulse purchase, and going out to buy new tires and figuring out exactly how much new tires for SUV cost. So, had I done that research in advance I might not have landed on the same type of car. And so, where I would take that analogy back to the question is that it’s really important to not get hung up on the stuff that are table stakes in any new software. It’s important to understand how does your organization want to work in the future as David said and then finding software that can meet those needs and match where you want to go?
PETER MIRUS: I think that’s a great answer. And, it kind of dovetails into one of the things that I often do during the sort of RFP/RFI response process and when the vendors are putting their proposals and/or you are having a dialog with them. Even ahead of that maybe when you are actually deciding which vendors to circulate the RFP to and that sort of — create a short list of those really important business and technical requirements that are — the absence of which would be a real deal breaker. And just have conversations with those vendors and have them prove to you to the extent that that’s possible how they can check those boxes? And unless you have really drilled down to identify what’s most important you are not going to be able to do that. And that really eliminates so much work in the RFP vendor response evaluation process. Because if you are just publicly posting an RFP and you are getting responses from 12 different people, you have to try to do apples to apples comparisons across 12 different vendors that can be a real time sync. So, being able to have this prioritized requirements really allows you to filter out a lot of noise and just saying okay, these are the three vendors that based on these knockout requirements we have a reasonable level of certainty you are going to be able to put in a good response and then just circulate it those two to four companies.
KYLE HAINES: I real like what you said about figuring out what’s important. And it’s amazing when we start these processes sometimes how there will be a lot of divergence internally before its even gone to a vendor about whether some things are really important or whether some things are nice to have. And you want to have those conversations before you are making final the selection not in the selection process itself. That’s not the time you want to figure out what things are nice to have and which things are important.
PETER MIRUS: We have a couple of questions or comments from the group here. One of the people put his name in there, Kyle, and you may know who this person is. I won’t show his name here but he asked is there a way I can make our CEO watch this presentation with his eyes pinned open like in Clockwork Orange?
PETER MIRUS: I think the answer to that is no. I wish that that were true on some occasions. Yeah. I think the answer to that is no, but whoever asked that question if you come up with any innovations that fall short of torturous methods, let us know.
Another person asked I have always used the language of functional requirements and informational requirements do those map to your use of the term technical requirements and business requirements or do they represent something different?
That’s a great question. So for us functional requirements maps to business requirements and I don’t know — I haven’t used the term informational requirements before, but we have also used the term non functional requirements to match to technical requirements. I suspect that if information requirements are met within the context of sort of data relationship or management requirements or sort of backend technical considerations then that probably does match to technical requirements. Feel free to keep those questions coming.
Here is the next question:
When is an RFP (Request for Proposal) or RFI (Request for Information) appropriate in a software selection?
I just want to say before I tee this up for David that for the purposes of this conversation we are going to use RFP and RFI interchangeably. We are aware that they are defined differently by some people in the industry but the bottom line is that you are looking to put a document out there that has a set of requirements and get vendors to respond to it. When is it appropriate to do that David?
DAVID DEAL: So I’ll start by saying, Peter, when you were talking about 12 vendors in a RFP process that made me break out in cold sweat. What a nightmare for everyone involved, the vendors and the people who have to read 12 proposals. So, really like you said, it’s important to get that list down to a manageable list two to maybe five at the most. But when to do the process at all, I think clearly you don’t want to go through an RFP process for something that is more trivial, a lower dollar spend or impacts a small number of people. Whether to go with Evernote or One Note or something else or what do you use for personal task management? Of course, these aren’t things that are big enough in scope to have an RFP. I will also say that sometimes there are compliance requirements. We won’t get into that but if one of your funders says we need to make sure that you have gone through a due diligence process RFP it’s published in these places clearly you need to do it there. In general though, what would guide for me whether to go to an RFP process is the scope of the effort. It has to be large enough to warrant your investment of time in RFP/RFI process and by your — I mean, yours personally as well as everyone else in an organization who is going to participate in that.
Secondly, it’s got to warrant the vendor’s time that they will have to invest in creating a response. So, you know, if it’s $10,000 project frankly it better be a pretty short RFP or you are going to find a lot of vendors won’t respond. And some vendors won’t respond to RFP/RFIs at all and maybe they are not the right vendor for you. If your process is large enough to where you really need to have a conversation with prospective vendors to understand what they can do and you really a need a demo of their software, those are pretty clear indicators that you would benefit from a more structured process that would typically involve an RFP or an RFI. The final thing I will say here is that the length of the RFI or RFP should match the breadth of the project. So maybe you can do a very brief RFP for that $10,000 project but that brief is certainly fall short of 50 pages or longer RFPs that I have seen.
KYLE HAINES: I would add that — so yeah I agree with all of that. And I think in an earlier question what I talked about that is that perhaps the biggest value from thinking about this as an RFP process might be internally only. It might be something that never gets shared with a vendor, and it is an opportunity to document how it is that the organization wants to work. I think what I would add to — David to what you said is that the more inflexible your business requirements are the way that you work I think the more important an RFP becomes. If there is not an openness or willingness to change how you approach specific processes then it’s really important to understand how that software is going to work. If it’s more of a conversation and you want to — you want the vendor to bring their approach to a specific business process then the RFP becomes either less important or the amount of detail that’s contained in the RFP goes down commensurately.
PETER MIRUS: Those are great points guys. I think that it’s worth touching on the possible alternative approaches, you know some vendors out there just don’t work within the RFP or RFI context. They make robust trial or demo environments available or free trials so you can test drive the software, and that’s how they really want you to encounter its use. And so, you will see vendors — particularly if you are at smaller scale of organization are going to try to push you towards that sort of experience that usually takes place when a product is more well defined and there is less sort of configurable options. There are still some options, but not so much that you couldn’t get a great feel for what the software is like or whether it’s appropriate for your organization by just investing time and doing some test driving.
Another approach is to just — if you are pretty sure what class of solution you want to go to or you are pretty sure that let’s just say Microsoft Dynamics 365 could meet your accounting needs you might just want to start with a software vendor or maybe one or two that’s well regarded within that space and start exploring the solution with them. Sort of say, “Hey, this is what we are thinking.” Can you help us sort of put some parameters around it rather than going through a lot of formal RFP or RFI process at least at first. I think you want to be — you want to make sure that the vendor had a great reputation for not only investing with a nonprofit community and helping them to advance the nonprofit community to advance itself as well as their own business interests before taking such an approach and there are vendors out there that are like that.
We touched on system demos a little bit already but the next question is:
1) When should we let the vendors demo and 2) How do we ensure vendors show us what we need to see and not what they want to show us?
David?
DAVID DEAL: So, I’ll start by saying Peter you bring out the — in response to the previous question you brought up a good alternative which is if it’s a smaller kind of more tactical software decision then just test driving it is a good option. So, an assumption here is that it’s a type of software or it’s a big enough project that it warrants a demo versus that download and try type of model. So, I think it’s okay to have brief initial demos before you start an RFI/RFP process to learn – particularly, if you need to learn what current capabilities of software out there in a certain space are, if you need to learn what a new category of software can do. So, I think that can provide helpful ideas and plant some seeds. I think it is important to make sure that vendors know when they are doing that that this is just a quick initial demo to give you some ideas and that there will be a more formal process later. Once the RFI/RFP process starts, I really think that you need to control the demos and sequence them such that it’s after vendors have responded to the RFP. So, after they have invested some time in responding, after you have read the responses, and only if you continue to believe that they are a legitimate contender to be your selection, at that point I really think they should participate in a demo where you have laid out this is what we want to do. Here are the three things, the six things, the ten kind of workflows that we have shows how your software supports those workflows. And so, this isn’t something you are going to see in 30 minutes. Demos that are really effective would typically be a few hours.
KYLE HAINES: I would add — and I think — I don’t remember whether it was you David or you Peter using the example of 12 vendors responding to an RFP. I think Build often times has to respond to RFPs. It is a labor intensive time intensive process, and I try to create respectful processes where you are going to vendors who legitimately have a chance of winning the work. And I think one of the ways that you can be respectful is you have got to find a way to let vendors show off. And the point of the RFP process is to give them a bit of space to do that but not to spend too much time showing off stuff that isn’t important. So, for example, if a vendor spends a bunch of time in a demo talking about their Facebook integration, but your organization doesn’t use Facebook because it works with a bunch of confidentiality requirements that’s just going to waste everybody’s time. I think you have to recognize though vendors come to this wanting to show their best side. And it is a balancing act to give them the space to do that while also not wasting everybody’s time with them showing you things that you really don’t care about or are not that important.
PETER MIRUS: That’s a great point. And we often refer to scripted demos rather than just demos and David and Kyle both alluded to this, but we could come up — help our clients come up with scripts about what specifically they want to see and the nuances of that. And then we circulate that to vendors and give them some room to provide input on to what else they might want to show. So, you make sure that there are no surprises in the demos because you want the expectations to be good on both sides. From the vendor for what the client is expecting and how they can show off a little bit, but still keep within the context of what the client wants to see and for the nonprofit organization towards the vendor knowing that they have given the vendor clear expectations to work with for the demos, and if there is something outside of that that interferes within — with the goals of the demo or the benefit for the nonprofit organization that they can really judge the vendor negatively based on that.
How can we make sure a vendor is giving us a realistic project estimate?
I will take the lead on this one. I think we often talk about Total Cost of Ownership or TCO taking all of it that what’s entailed during the consideration not just licensing and the initial vendor employment implementation cost, but also initial and ongoing training and support, internal staff time and commitments associated with the selection process, excuse me, with the implementation process that has a real cost to it even if the organization doesn’t often quantify and from a dollar standpoint its internal time commitments. There are costs in change management. There is a variety of different scope and things that you sort of need to check the boxes on and you can’t always require or count on vendors to take those things into consideration. Some of which they arguably should but don’t, and you have to encourage them to provide additional information such as real costs for enhanced support for example.
Or you might — they might not do it because you need to do it for yourself internally. It’s hard for them to put a time estimate on what’s it going to take for you internally to go through an implementation. They might be able to help ballpark that for you particularly after initial design phase but rarely in response to the RFP are they going to be able to give you that kind of an estimate. And that’s really — so I’ll just make two points. One, take Total Cost of Ownership into consideration and everything that that entails. And two, recognize that there is going to be some collaborative give and take with the vendor to arrive at an accurate figure.
KYLE HAINES: I think one of the biggest areas in terms of getting a realistic project estimate where people go over budget is when — and I think I mentioned this earlier when the vendor underestimates how much time it’s going to take to lead the organization in an implementation through the decision making process. So for example, probably my best example at 4:45 or 4:50 in the afternoon is if you for example are implementing financial software and you have never tracked receivables before, and they are estimating something really low to implement accounts receivable that’s a red flag for me. Assume that gaining consensus on the right way to do things in the implementation is going to take significant time. You know your organization better than they do. If something seems like they are underestimating how long it’s going to take, you should call that out and try to understand why they have estimated it so low. And vendors in my experience, they often think they are going to walk into a meeting room, have a design session, present some options for your team, and you are going to choose at the end of that hour long meeting the best option and move on. And I think any of us who have been through a implementation know that that’s rarely how the process works. So I think that I would encourage you to look carefully at the estimates for the professional services specifically. And do they have a realistic understanding of how long it will take to make decisions in the process — in the implementation process itself?
DAVID DEAL: I think I’ll just add a few things to this. One let’s just say it’s very tough. I mean, vendors — really a lot of times it’s a shot in the dark. If it’s an enterprise implementation they cannot realistically know what it’s going to take when they provide the initial bid. They should go through a discovery process, a phase one of their project where they are defining the requirements in more detail. So, because of this, it’s so important to go into this project with a contingency fund — a significant contingency fund. The second thing I’ll say is that multiple estimates certainly help. So, if you are considering Sales Force or if you are considering another piece of software where one firm sells the software and another firm is responsible for implementing it try to get bids from multiple systems implementation firms. So, the companies that will help you to configure and customize your application because it could be the same piece of software, but they could have very different processes with very different costs for implementing that software. And finally it’s really important to understand the type of implementation they are proposing. Not all implementations are the same. So, one major vendor typically proposes a boiler plate, best practice implementation is what they call it. And in this process, you essentially are expected to fill in a worksheet to indicate what your needs are. So, what I want to say is you know most of the time that’s grossly insufficient for really configuring a system to do what you needed to do. So just be careful of let’s say ‘best practice’ or ‘boiler plate implementation’. And, you know, really I prefer ones where the vendor is planning to do a full requirements discovery as part of their implementation process.
KYLE HAINES: I can’t wait to use grossly insufficient and I mean it. That is absolutely fantastic. Hopefully it’s not directed at me.
DAVID DEAL: No promises.
PETER MIRUS: We have one question left that we need to get to, and we need to cover it quickly although it’s a big topic. It’s about change management, and so we can spend about 3 to 4 minutes on it before we need to close out. And the question is:
Any change involves a cost to the institution. So how do you weigh the benefits versus costs when selecting nonprofit software?
For example, retraining all users. We spoke to this already a little bit, but Kyle, do you have a quick answer for this?
KYLE HAINES: I don’t have — I can answer it quickly. I probably don’t have a quick answer. You know it’s tough. I think if you were replacing a product like an accounting system, it may be easier to quantify the benefit and the cost. If it’s something brand new for the organization like social listening as an example it can be much more difficult. And I would say that when I served as an interim CIO, it’s rarefied area to be able to work in organizations on projects that are technology centric that really involve taking the organization in a brand new direction. And often times those are the projects that’s most difficult to quantify the ROI. I think just to hit on a point that I made earlier the ROI will be immeasurably greater if it’s that type of entrepreneurial project if you can get everyone in the organization to pull in the same direction and the leadership of that organization to put their stamp of approval. And they will sing it from the mountain tops about how important that project is and that the ROI of that project will really be determined by how much the organization puts its weight behind that project.
PETER MIRUS: Yeah. I would say that’s right and you know for Return on Investment or ROI I think we asked again what is the perceived benefit? Another way to ask that is what can the organization do better or differently and how would you quantify that? As Kyle said, where something is newer to the organization, it might be more difficult, but there might be some relevant success stories from other organizations that have attempted similar things. And that might give you some realistic benefit targets that would help you say from quantifiable standpoint what it would be worth for us to undertake this change? So there is several different ways of getting at it. As I said before, also organizations often don’t do a good job of quantifying the soft costs as we would call them associated with the change. So those are your — your internal staff time for the most part. So having some experience from an experienced third party like Build Consulting, for example, can help estimate that since we have experience across tons of implementations. And we will have some corollaries that we can associate with your particular situation and help you identify things like internal time commitments and the cost of those relative to undertaking a selection and implementation initiatives. David, do you have anything that you would like to quickly add on to that?
DAVID DEAL: I do. I’ll say that TCO, Total Cost of Ownership, Direct Cost, Soft Costs the numbers you get out of that process it’s one helpful data point. It’s not a numbers based decision exclusively though, right? I think it’s incredibly important to recognize that really this comes down to a judgment call by leadership. There are some things that — there are some ways in which it’s a subjective decision not a data driven decision. So, although you may suspect, it will take, let’s say 800 to 1200 hours of staff time for an implementation. Okay, great, but how maxed out are your staff already? Is your organization already stretched because you have been growing 50% year over year for the past three years? Will you have to backfill some of the work that those staff need to do as part of implementation incurring more direct cost in the process? For the leaders, I would say are there things that are a lower priority that staff can stop doing while they are supporting implementation? Helping staff understand what they can stop doing to me is one of the most important roles of leadership, so they can focus on what’s most important. How much change have staff recently gone through? What other priorities does the organization have and can a major enterprise technology change effort be, I would say typically a top-three priority for that organization for the duration of the implementation? If it can’t be probably not in a place where you can do that. So it’s not — it can’t purely be a data driven decision. There is definitely some subjective elements to this decision.
PETER MIRUS: Thanks, David. We have just got a couple of things to say in conclusion to share with you. First of all, for more information you can go to our blog, our learning resources section on our website or you can subscribe for our newsletter. We have got blog posts on how leadership should support technology initiatives. We have got a post on how to avoid paying too much for nonprofit software licensing and all of the considerations in that as well as some more recent blog posts that walk you through the leadership operations process data and technology model that we shared earlier specifically as related to the selections process. So, there is a lot of value there for you if you would like to check it out. Feel free to continue the conversation with us via the website, by contacting us through the contact form on Twitter or LinkedIn.
And finally in conclusion, we’ll just say that yes the slides and the recording both in the video and MP3 format for this webinar will be available. We will be emailing out links to you so you can access that information.
Thank you everybody for joining us today. It’s been an honor to be with you. We do really enjoy dialoging with folks out there in the community so feel free to reach out to us. Thanks Kyle for being with us today.
KYLE HAINES: Absolutely.
PETER MIRUS: Thanks David.
DAVID DEAL: Sure thing.
PETER MIRUS: Take care everyone. Have a great evening.