 Yeah, welcome. This is navigating your next technology investment and I'm Nate Parsons from Parsons TKO Chief Strategy Officer and I'm lucky to be joined today by Alfredo and I'll let him introduce himself as well here from prosal. Thank you, Nate. I'm really excited to be with you all today. I am Alfredo I'm the COO and co founder of prosal, which is a business development platform and RFP platform. That helps connect mission driven organizations to agency and consultant partners so that y'all can do the amazing work that you already do with additional support. I'm really excited to be talking with Nate today we've been brainstorming a lot about what technology investments and look like and where the RFP fits into that so we're going to be sharing a little bit about our stories and our backgrounds and very excited to hear what y'all have to say and contribute as well as this conversation. Hopefully me as well, or I as well. Yeah, and so let's dive in a little bit and for those of you who are attending a PTA webinar for the first time we always just like to start out a little bit and talk about kind of our methodology because it influence influences a lot of where we come from and how we think about solving these problems and, you know, sort of the core of that is this idea of engagement architecture that when you're using technology and people and process online to kind of build relationships and connect with other people and other humans. You know there's these interrelated pieces of the puzzle that need all fit together you know there's the strategy you have for that the people who are operating it the processes that they're using the platforms and systems they're using of course. And there's all sort of combined to create experiences for people outside the organization, and hopefully those experiences are you know interesting and involving and create engagement. And from that you can kind of get data back that tells you how you're doing and helps you kind of understand how sometimes these anonymous and online interactions that don't have as much human context are actually working and being responded to and, you know, we think about our piece in that context. I think that's really important because I think there's so much ink that has been spilled on the problem of how do you actually like write an rp and evaluate the responses from vendors and things like that. And it just skips over this whole important piece of the puzzle which is that what you're really trying to do is plug all of that work into this interrelated system and there's a lot of dynamics and pieces of the puzzle that can make that work better. And so, you know, just when we talk about the process you know I sort of CRP is a sort of a three stage process, you know there's the planning phase, the selection phase and then what I call the onboarding phase. I think, because it's such an anxiety producing moment for a lot of people, I mean, many people in their careers often run only one or two RFP processes and their entire, you know, job at a certain organization. You know, it can be really stressful to focus on the selection piece like you really want to find the very best partner you really want to get the best value for the money organization spending. It's kind of easy to skip over these other two steps and so, you know, when you know right now we're talking you know we were thinking about how can we help people see the sort of holistic process and how do they help me make the selection process in its context. You know be supported by these other two phases correctly and most valuably and so that's kind of what we want to dive into a little bit today. And so when we think about planning, you know I see it as being sort of like six major areas to consider. I mean in terms of those things I think there's a lot of things you can solve for in the awarding and the onboarding and the actual process technology development process, early on by good planning it's kind of that measure twice cut once kind of approach. And you know one of the key things there are schedule risks when you think about working with an external partner, you know they're thinking about all of their costs and how they can make the project, valuable and successful for their organization just like you are. So figuring out how you can manage the schedule for risks on both sides is really valuable because you know they want to minimize the schedule risks and you want to minimize the schedule risks, and you know how can you do that and so we have some ideas on that but I think a lot of those things are about setting expectations internally about the time required and the effort required. You know I think when technology projects are, you know first approach people think about the software and the services a lot more than they think about the business process and the people who work with it. And it's really common and we'll get into this a little bit in terms of even technology selection for people to pick a technology solution that really requires business process changes, but they don't ever think about that or even inform people and set expectations about that internally and so there's a lot of frustration, and you know sort of anxiety around those process changes when they realize they're going to have to have them really late in the technology process but you can, you know presage those quite a bit. Those are the cost risks, those are probably the ones that are top of mind for most people. But I think one of the things that cause, most commonly causes a lot of cost anxiety within these projects in my experience is that people don't realize how much smarter they're going to be halfway through the implementation process and they are the beginning of the process. No matter how much research you do, and design work you do up front. When you start actually seeing the products and technologies implemented and start thinking about how your teams are going to use them and getting results and ideas from other people and even having better ideas because of that, you know, those sometimes you want to take advantage of those in the project and if you start thinking about the project very early on that that's going to happen. You can change the budget, the schedule, your expectations internally and externally, all to sort of help manage that and so that can really help the cost risk be lowered and managed in a very successful way. And that's the scope of work. You know, I think that a lot of people, again, don't inventory all the different pieces of the puzzle, you know, and they're switching software systems, there's all the information and intelligence and best practices you've learned in your existing system, even if it's frustrating in certain ways. And how are those going to be moved over to the new system and so thinking about the scope of work is really important in the planning process from a not just software perspective like features and functionality but things like data migration. Who's going to reimagine the business process who's going to document things who's going to change your online and onboarding process for new staff like how are you going to do all those things. Are you going to do them internally or expecting your vendor to do them are you communicating that clearly to your vendor. All those things are important. And then internal events this is another thing that I feel like is often easy to work on early but people don't do it which is like thinking through your busy periods at the time of the year. When are people actually going to be receptive to having their process reimagined or having their data be incorrect or working through like the onboarding process to a new tool. And then when do you know people like to take their vacations when do you know your CEO or your other executive vendors or sponsors are not around like all those things you can start planning for even before you get to the RFP. And that all kind of combines one, two, three, four and five years sort of combined into this vendor incentive you know which is you really want to find a partner who's excited to work with you and they're going to be excited to work with you and they feel like they can be really successful with the project. And it's not going to be something that's a loss leader for them it's not going to be really hard to work with you, and it's going to really help them advance their business as well and so when you do all these other pieces of the planning process up front you're going to find a better partnership because you've kind of got that all set up. And that also leads into this budgeting question you know I think a lot of people when they get to the RFP process start to go get a big chunk of money from like the CapEx budget or something like that. And then it's tempting to say, either we don't want to tell people in the RFP process how much we want to spend, or we're going to tell them the budget and there's not going to be these contingencies built in and so one of the simple things that I think you can do in the RFP process is actually divvy your budget up into four budgets and you know the sort of four budgets I often recommend people think about are the main implementation budget, the good ideas budget, the contingency budget for when things go off the rails unexpectedly, and then the adoption and onboarding budget and that last budget isn't just like training or train the trainer and things like that it's really once people start using the system they're going to realize their slight configuration changes and optimizations and better ways to do using the software you now have versus the old way they used to think about doing things, and you want to have a little bit of budget to take that on as well as you know change orders and things with your vendor because that's really what's going to make your new software really adopted and supported by people internally, so they feel like it's tailored to their needs. That's not it's a little wall of knowledge there, but hopefully interesting. And then one other thing I'll sort of mention here, oh yeah and afraid if you want to respond a little bit. Yeah, I was just going to say I love the idea of the good ideas budget on there, I mean I see this and the slide before it and you can probably break up the three steps, a 12 step process even by bringing up 100 100 steps into the RP, but the way that you have I think from the last slide which was this kind of planning, selecting and onboarding, creating these bridges for them to support one another and building on these risks and making sure you're conscious of the risks that you talked about. I think is especially important because problems downstream might emerge from the decisions that you're making today and mitigating those risks, accounting for them and very importantly budgeting for them will make sure that you can optimize and really build around what you want to go forward as you discover new problems and use approaches to to a solution. Yeah, it's such a good point I think it's a very additive process and, you know, often anxieties frustrations budget and schedule overruns result from, you know, many small paper cuts adding up as opposed to one huge misunderstanding and I think that's also valuable for people to think through is that, you know this these four budgets can let you sort of have like a pressure release valve on the project a little bit too because you can do a little bit of some of the good ideas if you have that budget and you can handle some of the contingency issues that you didn't expect. And that just makes the whole project a lot more likely to both succeed and to have a good working relationship throughout which is also important part of success. He's part of being a good partner. 100% Yeah, and I think that's a really key part of this is that, you know the RFP process tends to create sort of antagonistic relationships early and a lot of the methodology we try and you know educate nonprofits and mission driven orgs that we work with on is how to make it more of a partnering approach as opposed to a lowest value approach or, you know, hey we're ringing the most out of this vendor or whatnot because that's not really what you want is an organization which you really want for the organization to move forward, not to save you right here or whatnot you know so. And that kind of comes into the tyranny of the clock, you know which is, you know, once you've hired a vendor or even once you've put your RFP out into the field for people to respond to people are expecting you to be on the clock with them. You know they want you're going to say hey we're going to respond and let you know if you want it by this point there's going to be a Q&A period that you have to submit questions to and get responses back by this point. And that means that you're now limiting the time to have open ended conversations. And so the really important part of the planning process is to identify and think through the conversations you want some breathing room to have and you know we find those for like web projects are often things like the taxonomy how are you actually categorizing and organizing content like that's something that a lot of people have different ideas on you need to do some like hearts and minds work often on it. You know what you have to do and a vendor is like you have to finalize your taxonomy in one week. You know that can often lead to a lot of frustration and you know it's similar with like CRMs we often have questions around data quality like, you know which data is reliable which has holes in it and how are you going to solve that and that's really hard to do on the clock as well. You know another thing that we run into in that clock period is you know which things do you want to design and have people put opinions on internally versus what do you want to rely on an external expert to design for you. And are you going to be okay with the design they provide you because again, there's going to be limited time and budget for you to iterate on that design if it's an external person like there might be enough, you know, but it's just know that there's like for visual design it's often common for people say, you'll get two rounds of revision or three rounds of revision and you know that may or may not be something you want to do on the clock with your main project and so you kind of want to figure out what you want designed and how much time you need for to build consensus internally. And then, you know, this comes down to this other thing of like what are you actually buying you know we I see you see this in the web world all the time to where people would say like we want a new website, but they wouldn't describe whether they wanted the website CMS the kind of management system powering it to be really opinionated about how the editorial process worked how the layout management work how much control editors. And then they would get really frustrated with the actual software solution that got implemented. And that's really because there's a big split in the software world between what I call opinionated software where the business process is kind of built into the software and you kind of have to work with the opinions of the software developer and how they want you to run that part of the business. You know, small dollar donations and every action for example or something like that. And then there are these toolbox solutions which are more expecting you as the owner of the software to implement your own configuration and own business process on top of it. And that's like Salesforce for a lot of people were super flexible, but out of the box, there's really no business process and you know when you pick either an opinionated solution and you don't like the opinion or you pick a toolbox and you're not budgeting and expecting to build that that can also be a real challenge and so I mean this conversations internally and getting everybody on board for what kind of solution you're actually going to go shop for it's really valuable to do before you on the clock and like pick a vendor who's really expert in one kind of system and really novice in another kind of system. And I will, I think I'll add to this, you're, you're talking about kind of toolbox versus kind of these preexisting solutions, I think these questions scale up 10x if you're talking about custom solutions and custom builds for something. Oh, totally yeah I think and it's you know in these days it's pretty common for people to have hybrid environments where they might be like, hey we're okay using a really opinionated email newsletter solution because we just kind of do industry best practices there we're not doing anything crazy, but then we actually have this really involve volunteer portal that lets volunteers to all kinds of novel things that you know off the shelf volunteer software doesn't fit and you know that's a place where when you think about this process holistically you can even help the vendors and the RFP responses you get be me nor nuance when you can say, we're fine with an off the rack solution here, but we want custom tailoring here. And if you just describe that to people they're going to use their own expertise to give you much better solution. Yeah, that kind of comes down to measuring changes which is, you know, shockingly the most, most ignored part of any RFP process, you know that I've seen which is that people don't actually create measurements that they want to say, this technology investment was successful because these numbers moved, you know and I think that that basically an effort is something that we often see not even budgeted in the RFP process where, you know, there's no attempt to understand where you're starting to see what got better and what got worse because the technology changes. That's not all that not everything gets better automatically right like you might have some trade offs you might actually get some advantages and some optimizations in a certain area. And you might trade those by having some disadvantages and friction in other areas and that's okay but if you're not measuring it, those things can be either magnified or minified in terms of the project success at the end, you know, it's easy to say like, Oh, these things are worse. And if you decided this early that those things are worse people would be more successful and the project would be seen as more of a value added to the organization. And I think the key word there was if you decide early because if I think this is all stuff that you should be deciding the planning phase to determine well are we measuring this by, you know, deliverability rates or by how much time we're spending on a certain program because I've definitely been in the position where we made a change and then after the fact we're deciding okay well how how does this stack up to what we did before and we didn't have a baseline and so you have to go dig back on the historical data from that system you're no longer using and you might actually realize that you don't have an apples apples comparison because the two systems track something in very different ways. That's such a good point and, you know, especially if you're choosing a toolbox approach, you know as opposed to an opinionated solution. There may be things you need to budget for them to be measured, you know it might be totally possible from the be measured but they're not built into the system by default. And, you know, similarly with the toolbox like you're saying like, if you're buying the configuration in essence from the vendor. You should understand the kind of things they measure success versus which you historically have used a success and so I think you know that that's really important to even prepare people for that translation like, you know it's really common for people to be like, you know, 10 is less than 100 so we must be doing worse, even if the scale between those two would actually show that 10 is an improvement over 100 you know and so that's all about context setting and describing to people what they're going to see and why they're going to see it. You know, I think that's another part of the planning process which is if you think about how you're going to report on the success of the project before you start it. You know you're in a much better place to like ask informed questions of your vendor and also to help people internally understand what you're trying to do and if it's working or not so. Just really out of those metrics are also going to be, you know, aligned with one another and then if they're not going to be aligned and figure out what proxies there are. Maybe your vendor can be that expert that helps you out and decide. Yeah, such an important point. You know I think it's also good to let people know that there may be a period of disruption as part of that too you know it's it's really common for you know websites for example to have search engine optimization dips or traffic dips right after they're launched and those can be recovered but you know people might see those and start panicking if you don't prepare them for that but if they might be like oh no big deal I'll check back to you in four weeks and everything's back on track you know so you just save yourself a lot of internal frustration. Yeah and so that sort of leads to after the awards process how do you kind of get the vendor on board with all this great planning you've done on. I sort of see this as three parts it's a little simpler I think than the planning process which is that there's this internal wrangling piece that I think is really good to help the vendor with and kind of get in front of them which is that things like executive reviews like we all know there are certain things that you know our end or reputational risk other things that other people in the organization who may not know the technical intricacies of your project are going to want to get involved in the web design world of course it's the visual design of the website that's like the number one offender here but you know getting on executive schedules and preparing the executives give the right kind of feedback is really valuable because I've seen so many projects derailed when somebody comes to an executive and doesn't prepare them for the kind of feedback they want from the decision they're asking that executive to make and that executive weighs in and says oh well I'm here let me use my smarts and my expertise to kind of add some value to this project since it's on my schedule and they might give you feedback that really disrupts the scope of the project the play of the project the design of the project the value you're trying to expect from the project. And you know that's really up to you as much as the vendor like you kind of know your executives much better than any of the vendors you bring in and you need to be sort of staffing up to your vendor to help them be successful with these executive reviews. The flip side of that is sort of what I call good enough decision making authority like it's really easy for people to get perfectionist in these projects and see them less as like business tools and more like, you know, beautiful granite statues or something that they're carving that can never be altered or edited. And you know I think it's really important to keep projects moving to figure out who can make a decision that something is good enough in terms of its design its functionality, what it's providing for the organization and not have to have that pushed to the ranks of decision making because that's all just going to create schedule risk and scope risk. And then the flip side of that is, how can you make sure all your on the ground subject matter experts can give you feedback and information like I've seen this 100 times where finally somebody's invited to design review meeting or first look at the software that's like three forwarders of the way through the project, and they offer some incredibly insightful and useful advice that would have been awesome, like seven weeks ago, or 10 weeks ago. It's just really hard you know once you start pouring the concrete to make those changes cheaply and so if you can help set up internal feedback loops early on you're going to make your partner look like a rock star because they're going to get all the smarts and intelligence of your own organization fed into their process as opposed to be kind of blindsided by it. So, it's really valuable to do that. And the second thing is, I think a lot of us come in, and they're anxious to, they're really unsure where you're at in your process. And if they don't know which questions are open and closed in terms of the design procedure they're going to assume everything is open and that they need to solve everything and document everything. And that's going to create both a sort of risk adverse mindset on their side, and also a lot of scope creep is they're going to be trying to create and design and document a lot of things and so you can help them see what the really important things are and which things you don't want to revisit that's really valuable like, you know we've come into projects before people have like a terrible terrible solution to something and it's clearly not optimized. But it's actually not that important to their business and they know it, and they're okay just having it be terrible. But if we hadn't been had known that it was something that they were okay with and it already kind of learned to live with, we would 100% of spent time trying to fix that for them and brought that into scope and like been worried about it for them. You know, a good partner on some respects but it creates a lot of schedule and, you know, focus risk and other things on the other side. The other thing that happens is that, you know, people humans, we're not great at being engaged all the way through long processes, and so it's really common for people to sort of like poke in and say like, oh hey, I just had a great idea about this thing now that I'm paying attention to instead of putting into design docs like really early on, and we call that the wouldn't it be cool kind of thing where they say, wouldn't it be cool if this did that. And, you know, that's good on some level to capture all those ideas but it's bad to have them be automatic guesses or things that vendors think they need to operate on, you know, immediately. And so if you can finish that wouldn't it be cool process internally, that will help you know you decide which things you want to push forward to the vendor and actually like figure out like collaborative solutions on. I like this. This wouldn't it be cool suggestion. One of the things that we've done in our in the RFP templates is we always include a section for whether it's like a website or a branding or especially anything related to design. We like to suggest people to add things of what do you like and what don't you like, because a lot of people have a hard time kind of putting together and saying, Well, these are the things that I like and these are the things I don't like. In functionality wise they're using examples can make it easy for folks to really iterate and say, Okay, well let's take this piece from this website or this piece from this brand and and use it to add value and and more life to what we're ultimately building. Oh, I love that. Yeah, because I think the truth of the matter is is that we're all, we all have a little romantic artistry inside us and you know I think when we see these opportunities to kind of like instill that into these solutions it's really good to engage in that because it makes people up the light it makes people more invested in the solution, and it makes the money you spend more valuable to the organization you know so those are all good things if you can route them in the right way you know. Having having participated in a workshop last week where we asked about 10 adults in the room to draw superhero. I can definitely agree that everyone has a little bit of artistry and and child and then still I just got to make sure to draw it out in the in a creative manner. Totally yeah tell them it's okay to do it it just that it doesn't mean that you're me looking to fund it. Exactly. And, you know, speaking of artistry I think this is another important thing when working with an expert vendor, you know I think when a vendor is asked like how should you solve something. They're not going to tell you, well, I could solve it with this bubblegum that I've been chewing and this thing I found on the floor, or I could build it with like titanium steel and platinum right like they're going to give you what they think is a very professional solid solution. And that's usually what it somewhere between what I call fine and great, but there's actually a whole range of solutions for most problems. And a lot of them that the vendor might not even suggest are probably fine for you if it's not a critical part of your organization or it's actually okay because it still solves the problem that you need. And if you don't ask your vendor for like an ugly solution a fine solution and a great solution, you're going to get some, you know, vendor defined professionally planned idea for how they could solve it. And it's going to come with a certain cost to it. And that cost may turn you off from doing something that's actually very doable, just with a different kind of solution. And I think you know giving your vendor the opportunity to actually have these honest conversations with you about like, hey, we can solve this a bunch of different ways and you're open to that is really viable. And that only works if there's trust between both sides that you're not going to then in six weeks forget that you chose the ugly solution and beat up on your vendor for that, you know, you have to have a conversation where you're going to be like, hey, we're going to do great here. And this is just going to get by but it's better than we would have had if we hadn't had a conversation to figure out a solution. And I think that's the way you kind of want to have this work to really get the most value out of these partnerships. You know, and that kind of goes into this next one, which is the harder than expected decision, like, there's a lot of unknowns, like, you know, you're writing down requirements in your RFP of vendors reading them, and then they're going to start designing and budgeting against those, all without having done a lot of the research and sort of discovery that anyone would really want to do to say, I am 100% confident and how good this is going to be. It means that a lot of times there's going to be things that are harder than people expected in the project. They're going to be like, Oh, you know, I've paved 100 streets, we can pave the street in the week, and then they start tearing up this thing and they find there's a huge sinkhole, and there's a big rock, and then on the right sand, and it's just not going to take a week. And you have to have an honest conversation about that and it's got to be someplace where you're probably both tense you're both anxious, but you're not blaming each other, because those things come from really common and non malicious places, but it's really easy for people to say like, you said to be $10 and now you're telling me it's going to be $15 and I'm at it, you know, and I think that's, you know, that's understandable but you got to work through that to really get to a good solution and you have to be more like, Okay, this is happening here. How can we both sort of adjust for this, you know, this part's going to take more than we expected, probably don't have as much space or time for other things. How are we going to manage that. You know, and that kind of comes down to like, you know, honoring the decision making windows that you're both giving and documenting the delays and why they happen and being able to explain the story of the project to people outside of it, you know, because I think there's this, you know, sort of belief that you're going to buy a dishwasher at Best Buy when you do these are fees right but it's all figured out. I mean, if somebody saw on the newspaper that was $500 and he went to Best Buy and you actually spent $900 that you did something wrong, right and I think the reality is is more like, you're going on an expedition, we can have a map can have some stuff in your backpack, and you're going to try and figure it out on the way and you might have to get more supplies you might have to change your route. You're still going to get some value for the organization, but you need to be able to explain the story for that like how did you get to where you're getting and why is it still a good value for the money spent. It comes down to this final piece which is the internal politics like every organization I've ever worked with has things that are sort of touchstones really important the organization and things that are in volatile that can't be changed, and things they're really hoping to do and things that are optimistic sort of future things that they've never been able to really grasp and get their hands on and if you can kind of help your vendor and your partner understand how to work with those things. And help them contextualize all the work they're doing in a way that fits with your politics, and you know the truth matter is that because this is a human on human interaction. It's really important that people see these things as both positive and sensitive and empathetic in terms of what they're doing for your organization, and they're only be able to do that for your sort of education on like what this politics are who cares about what, how people like to be communicated with and even how to frame things and what are the right venues for framing things. In some organizations we've been asked to give all hands talks to the entire organization about the work that's going on. In other places we staff up one particular staff person in the organization, maybe it's a vice president maybe it's a director, and they're the messenger and you know understanding how that works is something that we can do easily from the outside we can only do it with people's So anyway, those are some some parts of improving in partnership. And I'll just pop on here to my last slide and I'll hand it over to self right here but you know our fees are work product I think that's where I sort of end up with this which is like they are not the thing you start doing. They're the result of all the discovery work and the research you've done internally. You know why they're hard for people a lot of times as they set start you know they have a blank piece of paper. No, I'm going to write my RFP. I don't have any of this background material that feeds into it. You know your desired organizational change is what informs your requirements in your RFP. The measurements and KPIs that you want to like measure and see different in the organization after this work, help you define the objectives of the RFP. And then the experiences the return on investment you think is valuable for the organization like if we spend $100,000 here, we expect it to create at least $100,000 of value on the other side. Those help you figure out the budget. And then the internal management needs that you have, you know how many business processes are going to be affected, how much data are you moving like how much, you know, risk management and risk tolerance do you need if it's something about fundraising all those things help you define the timeline. If you do that research ahead of time, your RFP actually is the work product of your research it's not a blank piece of paper that you're dreaming all the stuff up from scratch and so I think that's really important to see is that the RFP is really discovery work and the research work you do to make your budget allocation successful, and it kind of fits in between there between, you know getting the budget budget for a project and the development of the project because you're kind of right fitting the, you know, project to the budget you have to be successful in the organization. So, that's kind of my thinking on the two sort of phases, sort of bracketing the awarding phase, and now sort of handed over to Alfredo here to talk a little about some of the common gatchas warning signs and best practices that he sees looking at hundreds of these a week. No, thank you Nate, you want me to take over the screen sharing by the way. Oh yeah if you have it handy yeah I'll stop sharing here. Okay. Right over here so. Well, while I'm loading this. Oh, looks like there you go. You can see my screen now right. Awesome. So, like I was mentioning. The RFP really is a work product, it is not the first thing that you should do. It is not the last thing you should do it is a great informational resource and really it should emerge from a process of deliberation research and and configuration within your current environment so that you can go out and find that best solution find that partner. We talked a little bit about how this is an element of partnership with the RFP ultimately is a pathway to partnership with a different vendor, and there's a few things that you can get stuck on along the way that can inhibit a good partnership or can actually filter into the scope of work or the work product and so keeping an eye out for those elements or even though you're on the right track, making sure that you spot these red flags or spot these obstacles ahead of time. Can ensure that you have a more seamless RFP process and ultimately get that solution that you are looking for. And so I want to kind of flip the perspective a little bit right now, especially because and I have been talking a lot about the RFP kind of as a standalone and what y'all, what y'all can do to really put forward the best RFP process but really want to put the hat on as if we are all agencies, really thinking from the agency perspective, the people that are actually replying to this RFP that are reading your document, preparing the proposal, looking to have a meeting with you and ultimately become partners of yours. The reason that RFPs can be challenging from as a, not only from the agency side but really from this issue side from your side is that what as you're writing the RFP and they mentioned alluded to this earlier is that we might not have all the expertise that we need. I can tell there's a lot of folks here. There's 20 folks I can see in the room or in this webinar. I can't see, I don't know who all of you are but I assume that y'all are very talented at many things but no one is an expert at everything. And if you're hiring for a project or even if you're looking for that additional capacity, it means that you might not have all the expertise in the area that you are looking to hire for. And so that is why it's imperative to really go through that planning process and have an open mind to the solutions approach. One of the things that Nate mentioned earlier is that ugly, great and fine. What are those ugly solutions or those fine solutions that might actually get the job done but you've only ever seen the great solutions because that's what everyone only ever shares about on LinkedIn or when they're announcing the amazingness of their project. So very much conscious and going in with an element of humility and saying, I don't know everything and I'm open to hearing what might solve my problem. And this is where the second element comes into play. Especially when we're writing the RFP but generally speaking we like to focus on the ideal world that we live in on that shiny bright objects that's going to solve all our problems and make our lives magically better. And we like to describe, we tend to describe things in the way we want them done. That focus is inherently a solutions oriented approach. We're looking at what is the solution that we want implemented, what is the thing that we want done. And in doing so we tend to overlook the problem, or even worse, assume that the solution that we're talking about is going to solve the problem that is causing our, you know, misfortune and leading to this RFP in the first place. And so by focusing only on the solution we might actually be focusing on the wrong part of the problem. So without this expertise and without full consciousness of all the potential solutions that there are to address your problem. By foregoing any assessment by foregoing any planning any research and by just putting forward this thing that says I want this new shiny object built from you could be diagnosing a symptom of that problem instead of the actual problem. And in the worst case that means that the solution even if it comes to fruition in the exact type of specifications that you're asking for a kind of what you dreamed of is built identically to how you imagined it. If you misdiagnosed the problem or you focus only on the solution that problem is still going to exist and your problems will continue even with a new solution if not made worse and not having to deal with new problems that you're going to have to go out and fix as well. So keep that in mind and try to change the orientation, especially as you're going through the RFP planning process and that research and thinking less so about what do I want to get done and more so about what do I want to change? What do I want in my process in my work plan in how my my partners and my team and my team members, what do I want that to change in their lives in their day to day schedule that can be impacted by what we're putting forward. Another piece and I'm going to take this little also tidbit from Nate. I'm going to put in my back pocket that that planning for kind of the great the good ideas. I absolutely love that. And so, and I really like that because we are as humans we are just way too optimistic about life in general. But we think things are going to get done so much easier than they actually do. We think things are going to cost so much less than they actually will. And in doing so, we underestimate the time that it takes to get a project the amount of effort that goes into a project. The cost that might come especially if there are overruns if things go over schedule if there are more revisions than initially requested. So without doing that the right research without planning accordingly without taking the input from those expert partners and vendors that you're talking to. You might underestimate the amount of time and money it will take to complete the process and project and this is specifically one of those things that if you misjudge today. In three, four, five, six months whenever you're going through the project way after you've decided on vendor way after you've signed the contract. That's what that's going to emerge. And you're going to think about it in that moment and making sure that you saw this and you address this today is what will avoid those downstream problems and make your life a little bit easier. The last piece, and this is kind of what I've been looking to this entire time is that the RFP feeds directly into the contract and the scope of work. Obviously there's negotiations, there's new information that emerges, but at the end of the day what you put out in the RFP is most of that ultimately makes it into the final contract in the scope of work. And so a poorly written and a poorly organized RFP document and a poor RFP process can lead to unclear goals, extended timelines, budget and scope creep and suboptimal outcomes. And so the really the takeaway here is that any unsolved challenge in your assessment and or anything that bubbles up in your RFP process will almost always bubble back up during the implementation phase or somewhere else in the scope of work. A good thing is that all of these challenges can be my can be mitigated that can be removed with good research and with good assessment before you share the RFP, or having an unbiased third party support your process. And so, making sure that you're coming in with this mindset of, I don't know everything. I need to focus on the problem. I might be underestimating how much this might cost or how much it might take will ultimately save you time money and effort way down the road. And a few other things to kind of keep an eye out for this is think about this from the agency's perspective as you're putting together the RFP as you're writing this and doing this ideally in a collaborative environment with the rest of your team or maybe that third party that you brought on to help you with the RFP. Think about it from the agency and how when they are going to write the response to this to this RP and their proposal, whatever the format is. How are they reading? How are they digesting this information? And the first thing is that even though agencies and vendors and consultants are really good, at the end of the day they're not mind readers. We're not clairvoyants. We don't know everything. We wish we did. But to making sure that the information that we've talked about in this in this time is included in the RFP makes it easier for you to get that best proposal and for you to get all the information that you need. To then decide who do I go work for? Who do I work with? What solution do I implement? And how is this all going to look? And so some of the reasons that people skip an RFP. I myself and that you can jump in here as I'm going through this. I know you've responded to a ton of RFPs, but some of the things that I do some of the reasons that I see people skip RFPs and their responses is first and foremost, there can be no pictures. You also got to deliver it in 12 USBs by dogs led to the North Pole at midnight tomorrow. Just none of that is very conducive to that creative element that we were talking about earlier. One of the reasons that are involved in business development process is a lot of these folks are people that actually lead agencies or agency owners. They're creative by nature. And so reducing that creativity means that you are reducing the creative and diversion problem solving approaches that might make your life better. Lack of information in the RFP, whether that is, Nate, you want to share anything? Oh yeah, just going to mention on the rigidity front. So, so one thing I think that often is missed by a lot of nonprofits is the people responding to the RFP are not necessarily the experts inside the organization are going to be doing the work for you. So if you specify that rigidity, you're kind of putting a lot of pressure on often the sales team or, you know, whatever the sort of business development team at an agency is to kind of rethink the proposals and maybe edit them in ways that don't involve the experts inside the organization, reviewing and responding to that. So you sometimes even get worse responses and a poor understanding of the actual capabilities of the respondent organizations if you're too rigid in the approach. So you're noticing a lot of editing of, you know, pre approved and good thought work internally in an agency when they do that response. So it's just worth knowing that rigidity might be valuable for you in terms of like, comparing two or three quickly, but it might be that you're reducing the quality of the things you're comparing. You know, 100% agree and where that might be substituted where that might actually be helpful is instead of encouraging people to write their responses in a certain way, like, you know, put that cost proposal in this format and this type, rather than that, include that information and say these are the things that we're evaluating for these are the things that we want to see ideally in a proposal. So what comes into the second element is making sure that your RFP has all of the information and the clarity needed to provide a good proposal. That includes budgets. This is the hill that I am dying on this year, include the budget in your RFP. I mean, we're talking here about software implementation, but the same goes for websites, branding, marketing, anything, you know, a good product like a house can cost you $10,000, it can cost you $100,000, it can cost you a million dollars. And you saying I only have this much to spend is really going to inform what bills and whistles can be put into this RFP. And think about it. I mean, any of you have ever gone to buy a house, you don't go to the real estate agency, I'm not going to tell you how much I have just show me what best one of the best houses that are on the market, even though you know how much you have available to spend. Same, same goes when you're going through the RFP process. Preach, preach, that is so important. I mean, the other thing that happens is that people get bamboozled by product demos because of that, you know, like, and I think like Salesforce is probably the number one under here. But, you know, people will see a demo of an enterprise solution that looks fantastic and does all these things. And there's a big gulf between the base price of that software and the configuration and build out and deployment of that solution to make it do all the things that the demo just showed you it could do. And if you don't tell people they're the budget and you don't interrogate people about how they're going to spend that budget, you might be buying the license to something that doesn't actually do much for your organization. You know, and it's kind of like the car thing, right? Like, you can fit an awful lot in a semi truck, but maybe you can't drive a semi or park a semi or, you know, use that truck effectively maybe be better off with a pickup truck. But you're only going to know that if you kind of tell people your budget and what you're trying to do with that budget. Well, I love that you brought up the car example because my mind immediately jumped to the car commercials where you see this, like these amazing cars that can almost just take flight on the road and they have all these incredible things. And when you go to the actual dealership to look to see the car, it's like $20,000 more expensive than it said in the commercial because it has all of those additional features very much like the base package of a software product versus that premium version that comes with all the other things that you saw in the commercial you saw in the demo. Another element here is to make sure that you get good responses, you got to meet people a little bit where they're at. And so part of that means that you can't just rely on your network to send out the RFP. You can't just, you know, tell email the RFP company wide and say, Hey, send this to everybody you know you can't even just rely on the list search. I think an important element here is, if you've done your research well, you actually already know what vendors to send it to. And you might can you can actually skip the process of just doing a cold call and potentially receiving 50 proposals that you don't want to read because you wanted to decide between five and 10 doing that research means that you're probably going to be reading blogs you're going to be maybe looking at videos like this right now and you get to say okay well I know that I want to invite Parsons TKO I know that I want to invite this other vendor because they had really good content on this or I've been following them. And if that isn't the case if you haven't been able to build that vendor network really well. Then look to those experts that you can trust that can suggest okay well who can I send this to and go from there. I will offer a shameless plug here prosal is a place where you can find those vendors we have over 2600 agencies and consultants in over 26 very distinct categories from PR to it and translation interpretation and everything in between. And so making sure that you are looking to a diverse and active network, not just your LinkedIn followers is going to make sure that your your RFP gets to the right places and you get the proposals you want. Last piece here to that is unfortunately out of your control but you can and you can mitigate it with a good process is that RFPs historically for a lot of organizations have been a terrible experience I'm actually I don't know if this will come up but we made a shirt just to highlight the fact that RFPs have literally left people traumatized and scar I've met so many organizations so many agencies that say I will never do an RFP again. I've met so many nonprofit organizations as well that will say I don't want to do an RFP because I've seen what it looks like and it is awful. And it doesn't have to be that way by just following these steps that Nate and I have been talking about the last 40 minutes, means that you will already have a better RFP process and recognizing that other people have gone through bad processes and saying we are trying to be different, and we are trying to be more engaging and offer this information just that simple statement. I think can do miracles for opening people's minds up and saying okay well, at least they recognize that this is a pretty bad process and they're trying to do something about it so let's give it a shot. Yeah, I'm not front I'll just mention one other thing which is that I think a lot of people feel like there's a sort of judge and jury approach to these RFPs where they need to be like super neutral and like not give anyone an unfair advantage, as opposed to like trying to find a really good partner and find a collaborative experience and one of the things that results in is that was often kind of a reticence to have like one on one phone calls with people who are responding to your RFP. Even though that's the number one way that you can get a better response from a vendor is to like tell them in your own words which are going for and explain what the RFP means as opposed to what they read in the language that you had in the RFP. I think that's a really, really important piece that people often just don't offer people which is like hey, in addition to the Q&A phase where we do like the cattle call and the bulk kind of answering of common questions. Let me do some one on one context calls with vendors who express interest in that. And guess what they're going to be in more invested because you talk to them and they're going to provide you a more nuanced and detailed answer and you're going to get more of what you want and you know you just have to kind of put to this idea that like, you know you're running some kind of like special contest that you can't like have favorites and things where the reality is you are trying to play favorites you're really trying to find the very best partner and the very best person to work with for your organization. And that's going to be a relationship it's not going to be an anonymous experience where you buy something at the store and so you want to start building that relationship early on if you can. I 100% agree I know there's a slide somewhere that says it might be on this one but but the way that I call it is just having those opportunities for engagement, whether and that Q&A is just one piece of that but that can be office hours. That can be making sure that you don't go for vacation on two weeks while the RFP is open and just leave your out of office reply, which I've seen way too many times. It can be taking those call but at the end of the day a relationship is built on trust and you're not going to have that trust by simply reading a 20 page Word document. It's going to happen with face to face conversations or online conversations and I wholeheartedly agree that this is not about playing favorites this is really about you getting the best information and you getting the best result for your RFP and your project. I have a few red flags here that I've called out and so this is somewhat similar to what I had on the last slide but anything that in an RFP that indicates that there's been very little information gathering that someone has contradictory information for example saying that they don't want open source software but they want to be built on Drupal or that they say they want to see a mess but they don't specify which one that they built on or which one that they're interested in is indicative of not a lot of thought has gone into a into an RFP process and so making sure you go through that process and share that information removes this flag immediately. Sharing too much info your RFP does not have to have a force measure class it doesn't have to have a sample 200 page contract at the end of it is okay to cut that out if you are really if you really want to include it. This is an attachment or an annex that is separate from the document but really make sure that the core information is included there so that the good proposals can be written and sent to you. The, if the original RFP timeline has been pushed or extended multiple times if you are sending out the same RFP from back in April and saying we're still collecting responses on this obviously something is wrong there. I can tell that as an agency I'm going to have a lot of questions about why you haven't already moved on into this process, and you should have those same questions to figure out well what's wrong here and why aren't we on time with our project. The evaluation process, what are you looking for what are those things that you are going to judge people by you're going to judge projects by. And then the budget this again hill that I will die on we actually did a survey, a few weeks ago, few months ago at this point, and about half of the agencies on proposal that we surveyed would not respond to an RFP if it did not include any budgetary information. And so, if you take that out a little farther that might that means essentially that if you put out an RFP into the universe without any budget information half of the people out there that might be qualified to respond to our team might just skip it over and say I'm not going to look at this because it didn't include a budget. So keep that in mind, because that is a huge red flag that I have seen lead to our pieces getting not a ton of responses or even worse bad responses and then you have to go and extend that time. Last piece is when it was alluded to earlier that engagement process make sure that you have time to ask and answer questions don't set that out of office build those relationships and build those trust, because that means that you get more information, they get more information and you end up with a better partnership. I'm very conscious of the time so I might move a little more quickly through. I'll do this one and then the next slide I have a check I have a link for us I'll just send that out but ultimately what you whatever should do and if there's any takeaways or you're watching this on YouTube and watching this live is keep five things in mind as you're going to this RFP. What is your timeline. When do you want this by when do you want proposals by when you want the solution implemented and that's probably the first piece to to think about and work backwards from that and make sure that there's real there's realism in that time. Give yourself a few weeks to receive responses, give yourself a few weeks to go through the planning process give yourself time to evaluate to the contract negotiations. Don't expect that if the RFP ends on July 31 you're going to start working on this thing on August 1. There's very few things that I mean you might see that in something like crisis communications, but even then there's still going to be a few days where that that is going to take some time to get onboarded and to get everything ironed out. Who are you inviting to participate. Don't allow yourself to have to receive 50 proposals and read 50 proposals. There's a lot of amazing listservs out there and I have one specifically in mind that I see a lot of our fees go through and that does not mean that you are going to get the best proposals out there just because there's 5000 people on the listserv doesn't mean that there's going to be the best place to send that RFP to be cautious about who you're sending to and be very targeted in your approach so that you can get the best vendors to become your partners. Include all the information timelines issues objectives, your evaluation criteria and that budget, but that budget in the RFP. Let's talk a little bit more about your about what you're asking for from vendors don't ask for for IP that you're going to take from them and then you know ideally have someone else implements, make sure that you are being respectful and mindful with someone's time. You're looking at something with reason, and you're asking for the materials that you need to make a good decision and anything that's missing. There's always the interview process you can always come back to. Let people be creative some people like decks, some people like memos, some people like canva and figma now there's amazing tools out there that are available. Let them show off in the way that they want to show off and you might see something different that will surprise you and lead to a really cool partnership. I will not go through this checklist because I don't want to just read off the pace to you but what I can do is I will share a link in the chat we've actually, we had a partner that we built this alongside a few months ago, we created a step by step process for any nonprofit RFP includes all of this information. I just sent that over in the chat so hopefully that's helpful to you all, and it'll include a lot of the information that Nate and I have discussed here today. Nate, I think I can give it back to you. Lovely. Yeah, no, this is fantastic and yeah, we had a lot to talk about so we didn't have as much time for Q&A as we might have hoped but I'll just throw out one question that we received which is the, what are some of the major differences that higher ed RFPs may include as opposed to nonprofit focused ones and, you know, we had a chance to chat a little bit about this before this meeting but a couple that came to mind I'll let you fill in the gaps here where, you know, that at a lot of higher ed institutions there's a different sort of signing authority level where you can have a project under X budget signed by a department head and not have to get RFP and that's often higher in higher ed institutions if they're a large one. If they're publicly public organization like, you know, University of Berkeley or something like that. They often are very government oriented with a lot of very strict format requirements that are imposed by either state or local government kind of restrictions on that. They can be really efficient to like put out into the field. I've often seen that the solution selection period is much longer in those because they're often a committee driven format for people evaluating and reviewing the RFPs and so that can mean something that might have been six weeks that a commercial organization or two months that a nonprofit might be six months that, you know, a big public university but I'm afraid if you have other thoughts on the higher ed nonprofit split. I mean, I think the biggest definition or the biggest distinction between the two of them is that generally speaking, higher education institutions have a procurement department for at least a procurement agent. And so that means that there is one person solely at least one person solely dedicated to purchasing and procuring software services, whatever that is for the institution. What they're doing so there are very likely more processes and procedures a lot of formalities in place. I know for example, a lot of universities like to use different softwares like demand stars when it comes to mind bonfires and other that they'll use to put the RFPs and they require submission through that platform is not just an email to email relationship building. An email to the building is something that might be missed out unfortunately this information hasn't gotten to that space just yet so you might see code of silence requirements, or just make things that make it a little bit more difficult to show off that creativity and show off yourself as an agency or as an individual. Instead, a lot of the information that we shared I think still applies. And if I know me, like, I mean, whatever everything that I share doesn't mean that you shouldn't still go out and build that relationship you shouldn't still go out and push them to be better about their processes and I think this is one of those elements that we're seeing a shift in how procurement is being conducted, not only in nonprofit space and higher ed, and even in small local government and part of that is just by going out asking questions and, you know, encouraging them to be a little more involved with their processes so that these partnerships that that lead to better project outcomes can put into place. Yeah, such a good point. Yeah, and hopefully we can we can change that space to you know keep keep fighting the good fight for better RP processes. Thank you everybody and thank you for it and we'll we'll do this again real soon hopefully