Host Chris Lacinak is joined by Amy Rudersdorf, Director of Consulting Operations at AVP to talk about resources that she recently published focused on helping organizations select the right DAM, MAM, PIM, digital preservation solution, etc. for them.

Amy has put almost a decade of expertise and experience performing and refining these projects at AVP into resources that help people do this work themselves. And in addition to making those freely available, we dive deep in this episode to offer even more context and information on how to put them to use.

Guest Bio: 

Amy Rudersdorf brings to AVP over 20 years of experience managing digital assets at all points in their lifecycle, from DAM and digital preservation system selection and implementation to long-term access to and preservation of digital assets. She has had a career focused on helping organizations develop strategies to preserve and provide maximal access to their digital content with good stewardship practice and quality metadata. She brings a unique perspective to her work, after years of running digital asset management and preservation programs in academic, government, and nonprofit settings, and with organizations of all sizes.

Recent projects at AVP include developing a digital strategy for a small, nonprofit organization, helping select technologies via an RFP process for large public libraries, supporting the development of an AI system for metadata capture from audiovisual materials, and implementing a DAM for a large music-streaming service. 

Amy is an active member of the Digital Library Federation and NDSA working groups and presents widely on topics ranging from digital preservation best practices to technology selection and DAM. She holds an MLIS from the University of Pittsburgh, and a BA in English from the University of Wisconsin. Amy lives in Madison, Wisconsin, with her family and a very gentle pitbull.

Resources mentioned in this episode:

• Amy's Blog Post: https://www.weareavp.com/creating-a-successful-dam-rfp/
• Amy's Handouts: https://lp.weareavp.com/dam-rfp-checklist
• The Cost of Getting DAM Selection Wrong: https://www.weareavp.com/the-importance-of-choosing-the-right-digital-asset-management-system/
• Kara's Blog Post on the Eight Worst Ways to Choose a DAM System: https://www.linkedin.com/posts/kvanmalssen_the-8-worst-ways-to-choose-a-dam-system-activity-7193968033856446464-Zc6L
• Radiolab "Choice" episode: https://radiolab.org/podcast/91640-choice
• DAM Right Soundtrack - https://open.spotify.com/playlist/4ZzCabPS7up3thnq5uwdKs

Engage:

🆓 Download amazing and free DAM resources from the best DAM consultants in the business at https://weareavp.com/free-resources

⭐ Please rate, like, follow, and subscribe on your podcast platform of choice. See all the places we are at https://dam-right.com/listen

🔗 Follow me on LinkedIn at https://linkedin.com/in/clacinak

Yeah, thanks for the opportunity.

I'm really excited to be here. So for folks that don't know, you are the Director of Consulting Operations at AVP. And I've asked you to come on today because you've just written a piece called Creating a Successful Dam RFP, and you've included with it a bunch of really useful handouts. And so I wanted to just dive into that and have our listeners better understand what the process is, what the value of it is, why it's important, what happens if you don't do it, so on and so forth. But I'd love to just start, if you could tell us, what is the expertise and experience and background that you bring to this topic?

Sure. So before I came to AVP, I was working in government and academic institutions where we had to go through a procurement process to buy large technologies. And so I've seen this process from the client side. I know what the challenges are. I know that this can be a really time-consuming process and really challenging if you don't know how to do it. And then when I came to AVP, I had the opportunity to help guide clients through this process. And over the years, we've really refined what I think is a great workflow for ensuring that our clients get the right technology that they need.

And you've been doing this for years, as you say. So I'm curious, why now? What inspired you to write this piece after refining this for so many years? Why is now a good time to do it?

I think the main... Well, there are a couple of reasons, but one of them is that there's just been in the last couple of years a proliferation of systems. There are hundreds of systems out there that we call DAM or MAM or PIM or PAM or digital preservation. There's all kinds of systems. From a pricing standpoint, DAMS range from as low as $100 a month to six figures annually. And the market is really catering to a diverse set of needs from B2B to cultural heritage to Martech, and then your general purpose asset management systems. And I've seen organizations recognize that it's really important to do it right. They want to make sure that when they acquire technology, it's something that's going to work for their institution for the long term. But they really struggle with how to do it. So what I hope through this piece is that I can help individuals and organizations with this step-by-step guide to successfully procure their own technology without us, and maybe in addition, see the value of working with an organization like AVP.

And how would you describe who this piece and these checklists are for?

Well, I would say specifically, they're for organizations looking to procure a DAM. And this could be your first DAM or moving from a DAM to an enterprise DAM technology or MAM. So that's the specific audience. But really, if someone's looking to procure a technology, the process is going to be very similar. And so many of these checklists will be useful to those folks as well.

Yeah, I think it is important. You've kind of touched a couple times on, you know, the piece is called, or calls out specifically DAM. As you mentioned, and it's worth reiterating, we've talked about it here on the podcast before, but we use a very broad interpretation of DAM to include things like you mentioned MAM, PIM, PAM, digital preservation, so on and so forth. So it's good to know that folks looking for any of those technologies in the broader category of DAM that this is useful for. For someone out there considering procuring a DAM and thinking, you know, we don't need an RFP process or we don't need to use this complex, time-consuming process, is it still useful for them? Or are they things that they can grab out of this piece, even if they don't want to go through the full process?

Well, my initial response to this question is, you should be considering the RFP process. And if not a full RFP process, at least an RFI, which is a request for information as opposed to a request for proposals. The RFI is a much more lightweight approach. But in either case, I feel like this document, this set of checklists is useful for anyone thinking about getting a DAM. Because the checklists step you through not just how to write an RFP, but also how to gather the information you need to communicate to vendors. So if you look at checklist number two, for instance, it really focuses on discovery and how to undertake the stakeholder engagement process, which you'll want to do whether or not you're writing an RFP. You really need to understand your user needs before you set out to identify systems that you might want to procure.

Yeah, that's a good point. And maybe it's worth saying that for smaller organizations maybe that aren't required to use an RFP process, that what you've put down here, when I look at it, I think of it's kind of the essential elements of an RFP, right? You might give this to an organization that then wraps a bunch of bureaucratic contractual language around it and things like that. But this is the essence of a organization-centered or user-centered approach to finding an RFP or finding a DAM that fits. So let's talk about what are the pitfalls that people run into when they're procuring a DAM system?

So I'll start by saying, I think it's really important that when you're procuring a technology that you talk to your colleagues in the field and see what they're using. But just, as much as that's important, I will say that's also a major pitfall if you do that, if that's your only approach. Because you may have a colleague who uses a system they love, it does everything they need it to do, and they say to you, "Yeah, you should definitely buy this system." But the reality is that that system works for them in their context and your context, your stakeholders are very different. And so that assumption is, I think, flawed. You have to go through a stakeholder engagement and discovery process where you're talking to your users and finding out what they need, what their requirements are in order to communicate to vendors what it is that you need that system to do for you, as opposed to what it's doing for your colleagues. I'll say, Kara Van Malssen posted a LinkedIn post a few weeks ago, and it was really useful. It's the eight worst ways to choose a DAM based on real world examples. And one of those is choose the system that your colleague recommends. And as she says, your organization's use cases are totally different from theirs. I think there's also the pitfall of, you go to a conference and you met a salesperson, they were really nice, the DAM looked great, it did everything that they said it could do. But when you're at a conference, that salesperson is on their best behavior, and they've got a slick presentation to show you. So just approaching this with a multifaceted approach is going to be far more effective than just saying, my colleague likes it, or I saw it at a conference. You combine all of those things together as part of your research to find the system that works for you.

Yeah. And that makes me think of requirements and usage scenarios, which I want to dive into. But before we go there, I want to just ask a similar question, but with a different slant, which is, what's the risk of not getting this right, of selecting the wrong DAM?

Yeah, so the risk is huge. I think DAMS are not cheap. I would say that's the first thing. You do not want to purchase or sign a contract, which is typically multi-year, with a vendor for a system that doesn't work for you. You will be miserable. And I think more importantly, your users will be miserable. And this will cause work stoppage, potentially loss of assets, and it could be a financial loss to the organization. Not doing this right will have repercussions all the way down the line for the organization, and you'll be hurting for years to come.

Yeah, I think one thing we've seen is an organization, maybe they go out and they buy a cheap DAM, and maybe they think, "Well, you know what? It's cheap. If it doesn't work, we only spent, what, $15,000 or $20,000," or whatever the case may be. Not realizing that that might be the cheapest part, right? Because you got to get organizational buy-in, you got to train people, you got to onboard them. And then it goes wrong, or it goes, you know. And we've seen this. We've come in on the heels of this. Where like, there's a loss of trust. There's poor morale. People don't believe that it's going to go right this time. So yeah, there's a lot to lose there, and it's more than just the cost of the DAM system, as you point out. So let's jump back to requirements and usage scenarios. So you talk quite a bit about the importance of getting requirements and usage scenarios documented and getting them right. Could you just talk a bit about those two things, how they relate to each other, and then we'll kind of dive in and I'll ask you for some examples of each of those.

Okay. Well, this is where I'll probably start to nerd out a little bit. But you're going to, as the centerpiece of your RFP, communicate your needs. And when I say your, I mean your organizational needs for a new system. So you will be representing the needs of your stakeholders, if you're doing it right. Their challenges or pain points, their wishlist, all of that needs to be communicated to vendors in a clear and concise manner that they can interpret appropriately and provide answers that are meaningful to you so that you can then analyze the responses in such a way that you can understand whether that system will work for your organization. So structuring your requirements and your usage scenarios, we call them usage scenarios at AVP, lots of people call them use cases, but structuring those correctly is going to be the part that gets you the responses you need in order to make a data-driven decision.

And I've heard you talk about before, I mean, to that point, I guess, we have seen RFPs in which the question that is posed is, can you do this thing to the vendor? And the vendor just simply has to check a yes or no box. To your point, I think from what I've seen from your work is like, you really get to how do you do this thing so that there's much more information around it. So it sounds like structuring those, getting those right and structuring them in the right way is going to give you not a yes or no answer, which is often misleading and unhelpful and things, but like a much more nuanced answer.

I think the other part is, you want to help the vendor understand. You want to work with them to get the best outcome from this process. And so giving them as much context as you can is important too. And that's why we structure our requirements the way we do so that the vendor sees what the need is, but also understands why we're asking for it.

That's a really good point. That is something that you hear vendors complain about with RFPs that they don't provide enough information. And I want to ask you later about what ruffles the feathers of vendors, but let's keep on the requirements and usage scenarios. So can I ask, you said most people call them use cases, AVP calls them usage scenarios. Why is that?

Well, a use case is just a standalone narrative of, it's a step-by-step narrative of what the needs are for a system. So you're telling a story about a user going through a process or a series of processes. A usage scenario offers context beyond that. So you provide some background information. Why is this usage scenario important? Well, you're explaining that we're asking you to respond to this because this is our problem. And so providing, again, it's that context. So the vendor understands why you're asking for something or why you need something. It just makes their answers better. They're more informed. I think they feel more confident in their responses. And so it's just a little bit more context around the use case than just a standalone use case.

What does a well-crafted requirement look like?

So at AVP, we use the user story structure, which comes out of the agile development process. It's basically an informal sort of general explanation of a software feature that's written from the perspective of an end user or a customer. And we call them personas. So as part of your user story, it's a three-part structure. So as a persona, or the person that needs something to happen, I need to do something so that something is achieved. So a standard requirement is just a statement of a need. But here you can see there's a real person. So this is user-driven content. There's a real person who has a real need because something really needs to be achieved. And I think that structure is really powerful. I just said "really" a lot of times. But there are a lot of examples for how to build user stories on the web. And again, just giving that vendor as much context as possible. You have to think about you're handing over to these vendors 20-page documents that they have to sift through to try to understand what your needs are and how to match them to their system. And so any background you can give them, any context you can give them, is just going to be a win for everyone. So it really will impact whether you're seeing responses from the vendors that align with your needs or not. I think it provides clarity in the process that the standard requirement structure doesn't offer.

Right. So I'll go out on a limb here and venture a guess that a bad requirements list might be a list of bullet points, something like integrations, video, images, things like search, things like that. Not a lot of context, not a lot of useful information.

The other thing to keep in mind is these have to be actionable. So you can't say "fast upload." Every vendor is going to say "yeah, our upload is super fast." But you could say, "As a creative, I need to upload five gigabyte video files in under 30 seconds" or something like that. You want them to be something that a vendor can respond to so that you get a useful response.

How might you explain what a well-crafted usage scenario looks like?

Sure. So usage scenarios are, as I said earlier, they're these step-by-step narratives. So it's a story about a user moving through the system. They flow in a logical order. They cover all of the relevant steps, all the decision-making points. They are user-centric. So the scenario should define who the user is. We always use real users in our usage scenarios. So we'll have identified some of the major personas from the client's organization. And that might be, like I said, a creative. It might be the DAM Manager. It's real people who work in their organization. We don't name them by name, but we name them by their title. So that this is truly representing the users. So it's the story of the user performing tasks. And every usage scenario should have clear objectives, outlining what the user is trying to achieve. And it's their specific tasks. They're solving a problem. So it might be, for example, just this isn't how you would write it, but it might be a story about a marketing creative who needs to upload assets in batch and needs to ensure that metadata is assigned to those assets automatically every time they're uploaded. And the DAM Manager is pinged when those new uploads are in the system so that they can review them. So that might be a story that you would tell in a usage scenario. It's realistic. It's based on real people. And it represents real challenges that users face.

Yeah, that makes a lot of sense. There's a lot of things that we see in marketing and in communication around the power of stories. I can imagine that that is a more compelling and meaningful way to communicate to vendors. It makes me wonder, in your experience in working with organizations, you craft this story and someone listening might think that's information that's at the ready that just simply needs to be put into story form. But I'm curious, you put a lot of emphasis on discovery and talking to different stakeholders. And I'm just curious, how useful is this process to people within an organization coming up with these stories? Are they at the ready? Or is it through the discovery process that they're able to synthesize and really understand to be able to put it into that form?

Yeah, I would say if you take nothing away from this discussion except the fact that discovery is absolutely necessary as part of your technology procurement process, it's that. Discovery is the process of interviewing your users and stakeholders to understand what their needs are, their current pain points are, and what they wish the system could do. That's it in a nutshell. And I have never had a core team or the person leading the project on the client side say, "Oh, I already knew all that." Time and time again, their eyes are opened to new challenges, new needs from these users. So, it's a really powerful process. I think this is taking it a little off topic, but just to ensure that you have buy-in from your stakeholders, bringing them in at the beginning of the process is key. So it's a benefit for you in that you learn what they need, you learn how they use systems today and what they need the system to do in the future, but you've also kind of got them engaged in the process as well. They see that they're important and that you're making decisions on their behalf and thinking of them as the system is being procured. And all of that together, I think, is really powerful and can only make for a better procurement process.

Yeah. So, wow, it really does point out the value of the process. So earlier I was saying like, what's the pitfalls or maybe someone doesn't want to go through the RFP process, but like the RFP, I mean, let's say somebody did just throw together an RFP without going through the process, it would be a very different RFP than after going through the process. And the process, and also it sounds like the process solidifies things that don't manifest in an RFP. They actualize through greater adoption and more executive buy-in and in other ways that you wouldn't have if you didn't go through this.

Absolutely.

Let me ask about that, the buy-in side. So in discovery, well, not so much the buy-in, I think more about adoption here, but like one of the challenges has to be you talk to, let's say 10 different people, each person has many requirements they want to list. And maybe one of those is in creative ops, maybe one is in marketing, maybe one is in more administrative role. Who knows? They are different stakeholders with different focus points and they all give you lots of requirements. And on one hand, I have to think it's important for those to be represented so someone doesn't look at it and say, "Well, it doesn't have any of my stuff in there. This system's not right for me." On the other hand, it's got to be such a huge load. It just makes me wonder, how do you get to prioritization to both represent but also make sure that the most important stuff is represented up front?

Right. Well, it's definitely a team process. So the first thing I'll say is just to provide a little context, when we do these requirements, these user stories, in the past, we would write 150 requirements. And we try really hard not to do that. It's really hard on the vendors to ask them to respond to 150 requirements. And so we really try to synthesize what the users are telling us and really hone in on the key needs. Now that doesn't mean that we disregard different users' needs. But in some cases, their need is something that every dam can meet. So there's no need to include that in the requirement list. You want to be able to search. They all can search, so that should be fine. But once you have got your requirements list, which I think in a healthy RFP is probably in 50 or so requirements range, then it's up to the organization to prioritize those requirements. So as a company, we will write those user stories on behalf of the client. But then we give them that list and say, now prioritize these. This is your part of the process. And typically, this is the core team's job. So when we work with a client, there's usually two to four people who are part of the client core team. And they are either sitting in on the discovery interviews or reading transcripts or just really engaged in the process. So they understand what these priorities look like. So by the time they get that list, they should be able to, as a group, sit down and identify the priorities. And we prioritize based on the list we do is mandatory, preferred, and nice to have. So if there are some requirements that someone is noisy about really wanting to have in the list, we can always just call it nice to have. And they're there. But then it's not mandatory that the system is able to do it.

So it sounds like that's done through a workshopping or group process where folks are able to discuss and talk about those. So that seems like that innately. Being able to be heard, have the conversation, and then even if it's not called mandatory, you still feel like you got to have the conversation and it's represented in some way.

Yeah. And I wanted to also say that gathering these requirements from the users is really obviously important, as I've said. But then engaging them throughout this process is also really valuable. And so not just asking them at the beginning what they need, but actually letting them come to demos and things like that, I think, is important as well. It's going to make implementation and buy-in much more successful.

You've got these requirements. You've got these usage scenarios. You create a bunch of things to hand over to a vendor. I guess I'm wondering, how do you manage apples to apples comparisons? Because there's going to be such a wide variety in how they respond to things. And how do you manage comparing pricing to make sure that there's not surprises down the road? How do you manage those things?

Well, so I'm going to set the pricing question aside for a second. So the way that we do it at AVP is, I think, a methodology that is unique to the RFP process. And that is that we've created a qualitative methodology. So we create the requirements, and the client prioritizes them. The vendor responds to them in a certain way. And then we're actually able to score those responses. And it's based on priority. So if something's mandatory, it's going to get a higher score. The vendor may say it's out of the box. They're going to get a higher score. If they say it has to be customized to do that, they're going to get a lower score. So we create this scoring structure that allows us to hand over to the client data that they can look at. So they're actually seeing side-by-side scores for all of the respondents to the RFP. Pricing is really tricky. It is so complicated. Every vendor prices their system completely differently. And so we really have to spend a lot of time digging out the details to understand where the pricing is coming from and what the year-to-year pricing looks like. And then we do actually provide a side-by-side analysis of that as well. It's really tricky to do it. But in the end, the client gets data that they can base their decisions on. And then you asked a question about avoiding surprises when it comes to pricing. I think this is the hardest thing to talk about when you're buying technology. And I think this is probably the case for lots of different types of technology, not just the DAM, MAM, PIM, PAM world. But this information is not widely available on the web. You can't go to a vendor's website and see how much it's going to cost for you for the year, an annual subscription or license. And the reason for that is that there are so many dependencies around their pricing, including how much storage you need and what that storage growth looks like over time, how many users and what type, some vendors base their pricing on seats, like the number of users you have and the different types of users in their different categories, SLA levels, service level agreement levels. So if you want the gold standard, it's going to cost this. So the costs are going to be unique to your situation. Just to sort of toot our horn that we know this market really well. And so if somebody says, how much does it cost for an annual license to vendor X? I can say, but that just comes with years of experience. Otherwise, it's a wild west out there as far as pricing goes.

You know that I know that you want to get your hands on Amy's how to guide and handouts for DAM selection. Come closer and I'll tell you where to find it. Closer. I don't want anyone else to hear this. Okay. It's weareavp.com/creating-a-successful-dam-rfp. That's where the guide is. Here's where you get the handouts. It's weareavp.com/free-resources. Okay. Now delete those URLs once you download them. I don't want that getting out to just anyone. All right. Talk to you later. Bye.

Two thoughts here. One is, um, I mean, you talked about the kind of like spreadsheet analysis and scoring. But I know you, you dive deeper than that. I mean, part of your comparison, comparative analysis process is also demos as well. And I imagine that that, that plays, that makes me think of a couple of things. One is like one using those as a tool in the apples to apples comparison. But two, like I imagine, you know, you have this list of requirements and uses scenarios and some solutions can probably meet that out of the box. And some probably need some custom development to do it or some sort of workflow development or something in order to meet those. So could you just talk a little bit about the role of demos and custom configurations related to pricing?

Yeah. So a demo is a general term, um, that can mean many different things in this, in this realm. Um, so vendors love to give demos, uh, and they would love to, you know, spend an hour and a half with you telling you how great their system is. That's their job. Their system may be great. And, and so, you know, that's, that's okay, but that's not how you base a decision, a purchasing decision. Um, you, you, you go, you see those, those demos, those sort of bells and whistles demos to get a sense of what the system looks like. What we do is, um, after the RFP comes back and you know, we're sort of playing with different ways to do that now. Um, but the way that we've done it typically is that after the, the, um, RFP comes back, let's say you get six responses, you choose your top three, and then you spend two hours in a demo with the, with the vendor. The vendor does not get to, um, uh, make the agenda. We do. And in that demonstration, they're going to, um, respond to the, some of the usage scenarios that we wrote for the RFP. So for 15 minutes, talk to us about that uploading, um, usage scenario I mentioned earlier. And in order to do that, here are assets from the organization and metadata from the organization, um, that you must use in your examples. So now you're seeing side by side, um, demonstrations of how the systems work with your data. And I think that's really powerful, um, because now you're going to start to see the system maybe move a little slower with that five gigabyte movie that you have. Um, and, and, and it's not quite as slick as the, as the, the assets they use typically in their, in their demos. So you get to see a real sense of how the system works in that way. And as part of those demonstrations, we always have the clients fill out feedback forms. So again, um, we're going to get some, some qualitative, um, responses like what, what did you like? What other questions do you have? But we're also going to get quantitative responses, score this vendor, um, on use the, on the usage scenario that you saw, what, you know, from one to five, did they, did they do what they said the system could do? And so again, we're, we're trying to set up opportunities for that apples to apples, um, uh, comparison. And how about the, um, kind of custom configuration aspects? I guess this goes, really goes back to kind of, I guess it's both pricing and timeline, right? Like how do you manage that through the RFP process? I think that's really probably one of the toughest things. The vendors differ on how involved they want to be in customization and configuration. Some systems require lots of configuration, um, but not so much customization. And maybe we should define those terms. So configuration means, you know, pressing some buttons behind the scenes to make something happen. Um, maybe turning on a feature, turning off a feature. Customization means writing some code to make the system do what you need it to do. So configuration should be cheaper and easier than customization. And so, uh, from a configuration perspective or from, from a cost and timeline perspective, configuration is, is less of a challenge. Um, because typically the, the vendor can do that. And that's part of the, the offering. Customization is different. Uh, if something is custom, we ask them to tell us how much time it's going to take and how much it's going to cost to do it. Uh, so that that's in, that's in their proposal as well. In order to get to that point can be challenging. You really have to be very specific and clear about what you need. Um, so an example would be integration, which is something that everyone asks for, um, in an RFP. DAMS aren't systems that just stand alone in your organization. They integrate with collections management systems or marketing technologies. Um, and so understanding for instance, who is responsible for building the integration and maintaining the integration. Uh, knowing that upfront is super important. If a vendor says, yeah, we can do that. Make sure they explain how that happens and what it's going to cost and what the real cost is going to be for you. Um, so I, I guess I just say that you're your best advocate and, and if you have a question, ask it and ask them to, to, um, document it.

Speaking of vendors, like what, what have you heard as responses from vendors to, you know, the, the RFPs that you're proposing people do in this process. Do they love them? Do they hate them like that? How have they been received by vendors generally speaking?

Um, well, I'll, you know, we have actually reached out to vendors and asked them this question and I have heard on a number of occasions that they really like the RFPs that we put together for them because they're so, they're so clear and they understand what we're asking and why we're asking it. And you know, going back to this, this point I made earlier about not having 150 requirements, you know, the vendors appreciate that as well. It's a, it's a lot of work for them to respond to these and, and we, we don't want this to be onerous, um, or overly complicated for them. So we've really tried to create RFPs that serve the client foremost, but also, um, make the process as pain free as possible for the vendors as well. And we've gotten feedback from them, from a number of them that they like, um, the way that we present the data.

Having been someone that's been on the responding side of RFPs, I will say, you know, one of the things you worry about when you're in that position is the, uh, customer being able to make an apples to apples comparison, making sure that the appropriate context is there, making sure that they fully understand, um, and that you have all the right information to be able to provide the right responses. So I guess everybody has a vested interest in being clear and transparent, right? That's actually helpful to everybody. And I imagine that also helps people like opt out. Maybe a vendor says, you know what, we're not, they look at that RFP and they say, this really is not our strong spot. We should not spend the time on this. So that's probably helpful to them to be able to filter out what is and isn't in their wheelhouse.

Yeah, absolutely. I, I think it's important to recognize that we don't work in a vacuum. Um, we, we work very closely. We are vendor neutral as a company, but we work very closely with, um, the sales teams at lots of different, um, vendor companies. And we want to be partners with them as well. We want, we want them to be successful, um, whoever they are and whatever we can do to make sure that they're able to, um, show off their system as well at, and as appropriately as possible, you know, that's a win for everyone. And so I do really keep in mind that perspective when I'm putting these, um, documents together.

So what are some of the things that you've heard vendors complain about with regard to RFPs? Not ours, of course, other people's RFPs. Like, what are the things that would turn a vendor off or make them not want to respond or make them feel poorly about an RFP?

I think I've mentioned this now a couple of times. I think one of the common deterrents is just the overwhelming number of requirements. And when they're not written as user stories, they can be really confusing, hard to interpret. Um, and, and just really probably pretty frustrating to, um, try to answer or respond to. The other challenge, and I talk to clients all the time about this is you can't make every requirement mandatory because there is not going to be a system out there that can do absolutely everything you want out of the box turnkey solution. Um, and it's, it's unreasonable to ask for that, I think, in my opinion. Um, and so, you know, making sure that you're really prioritizing those requirements helps vendors see that you've really thought about this and that you, um, understand what you're asking for and what your needs really are. So I think that maybe isn't a deterrent, it's a positive, but flipping that every, every requirement being mandatory is, um, is probably really frustrating. I would say too that, I mean, there's, there's sort of the flip side of this. Um, there's excessively detailed or overly complex, and then there's not enough information to, to provide a, a useful response. Um, so finding that sweet spot where you're giving them the context, the background, the information they need, um, but not overwhelming them is, is, is, um, important. And I, you know, we've all seen a poorly structured RFP, you know, something that lacks clear vision or is ambiguous or vague, or, you know, is filled with like grammatical errors and spelling mistakes. It just makes everybody look bad. And, you know, if I was responding to that, I would question, um, the organization and their sort of dedication to this process.

We should, we should point out that you're a hardcore grammarian.

I am.

So, um, let's talk about timeline. What, you know, you talked about who is this, who's the guide and checklist for, and you said it's for people who are maybe getting their first DAM. Maybe it's for people who are getting their second or third DAM. They've already got one. When is the right time to start the RFP process? People are surprised at how long this process takes. At AVP, it is a 20 week process. And so that's five months. And that is, uh, that is sort of keeping all the, the, the milestones tight, moving the process along quickly. Uh, that's, that's just how long it takes. Um, so, you know, thinking about things like, Oh, my contract is coming up in a year, you know, working backwards from that, you need a solid six months or more for implementation. So, you know, you should, you should be, um, working on that RFP now. Uh, but, you know, give yourself, you know, expect this process, if you do it right, to, to take a solid four or five months. Um, and, and then you also have to, you know, build in buffer for your procurement office. You've got your InfoSec, uh, reviews. All of these things can take even longer. So, um, yeah, as soon as you realize that you're going to get a new system, uh, start the work on that RFP.

And we should say that five months that you mentioned includes, uh, a pause while you wait for vendors to respond to the RFP as well. Right. And how long is that period typically?

Um, I, I usually say a month, I think less than a month is not, is not being a, a good um, you know, I think it's sort of, uh, inhumane to make them respond in, in less than a month. These are complicated. They want to make sure they're getting it right. We want them to get it right. So a month is a solid amount of time. We also build in time where they can ask questions and so they can't really start working on it until they get the questions, the answers back. So a month I think is the, is the sweet spot there.

You're right. I, I feel like we run into frequently where people might hear five months and they're a little put off by how long that sounds. Uh, and then it is extraordinarily common that, uh, contracting and security takes significantly longer than that to get through. So that is something I think people often underestimate, especially if you're not used to working through procurement, like that's something that people really need to consider as a, as a part of their timeline.

This is a real, this happened yesterday. I have a client who was very adamant that we, um, shorten that time, time frame by a month. So we had compacted all of our work into four months and they came back to me and said, you know, we're going to need more time. So let's, let's go with your original timeline. And then he said, it's like, you know what you're doing.

Yeah, yeah, yeah. That happens sometimes. So I mean, I do what, you know, I have, there has been this concept lately though, that I've heard repeated consistently about a fast track selection process and it's something that's significantly faster. And I wonder, I don't know, do you have thoughts about that? Is that a realistic thing? Does that sacrifice too much? Is it possible as long as you're willing to accept X, Y, and Z risks? I mean, what's the fastest you might be able to do a selection process if someone really pushed you?

That's a tough question. I mean, there are, there are people who talk about this fast track process. I think you're putting yourself at risk if you don't at least spend the time you need to with your end users and stakeholders. Whatever else you do around this process to make it go faster for you, you know, whether it's not do the RFP and just invite vendors to do their demos. I still think spending the time with your stakeholders is going to be really important and drafting their requirements in some way that communicates those to the vendors so that when you have them demo, you have them demo with your user needs in mind. You know, I think you could do that. I'm not entirely sold on it. I think our process works really well. But if someone came to us and said, "We want to do it a different way," I think we'd be willing to discuss other methods.

It makes me think, you know, if you were going to have, say, I'm thinking of a shape, Amy, and I want you to draw it, and I'm going to give you a number of dots to draw the shape that I'm thinking of, right? If I give you three dots, the chances of you getting that shape right are pretty slim. If I give you 50 dots, you're more likely to get the shape that I'm thinking of, right? You can draw the line and connect the dots. And it seems that if you fast track it, you're going to miss some dots and you're less likely. And as we talked about earlier, like, I guess I do want, I mean, now that we're talking about it, it's like weighing the risk reward here. Like, okay, let's say that the fastest you could do this with some level of certainty that everybody was willing to accept was three months. But you increase your chance of getting it wrong by 30%. We talked earlier about what are the risks of getting it wrong. Like, that just seems on its face obvious that that's not worth it. Like, the amount, it's not just the cost of the DAM system. Because to get back all those stakeholders again, do discovery again, go through the process. Like, everybody's burnt. They're unhappy about it. The thing didn't work. It failed. I don't know. It just seemed, yeah. Now that we talk about it, it just seems obvious that that's not a great idea.

You've broken their trust. And if you, and I've seen this in implementation too, where if you invite your stakeholders into the system before it's ready, or it's not doing what they need it to do, they're going to hesitate to come back. And to have to go through this process all over again, I just can't see, you're going to lose their trust.

You can imagine the Slack message already. Hey, did you see that? I went in there and nothing's in there. I couldn't find anything. It's like all of a sudden that starts creating a poor morale around the system.

Yeah, it gives me shivers.

Yeah. In your piece, you go through the whole RFP process. We haven't gone through that here because it's rather lengthy and I think that it's a lot to talk about. So we'll leave that to folks to see in the piece. But I'm curious if you could tell us, when you see people do this on their own and they don't have the advantage of having an expert like yourself guiding them along, what's the number one most important part of the process that you see people skip?

Well, I think it's the discovery process. It's getting in front of your users and stakeholders. Without that information, you don't know what you need. And you can only guess at what you need based on your personal experience.

So people think, "Oh, I know what my users need. I've been working with these people for years. I can tell them." Or maybe like, "I know what we need better than anybody else. I'm just going to write it down."

I don't know if I said this already, but I've never had anyone say, "Oh yeah, I knew all that," after they went through the discovery process. Time and again, they're like, "Wow, I had no idea."

I bet.

Yeah. It's pretty interesting to talk to the core team after the discovery process is complete. Because they often sit in on these interviews and you can just see their eyes pop when they hear certain things that they had no idea about. And that happens every time we go through this process.

So we'll put a link to your piece in the show notes here. I'm curious though, if you could tell us when people download the handouts, what's in there? What can people expect to see?

It's six checklists that guide you through the entire RFP process, from developing your problem statement to the point where you're selecting your finalists. Some of the checklists are things that you need to do. So they kind of step you through discovery and how you structure your RFP. But then there are checklists that you can actually include in your RFP. We always have an overview document that sort of introduces the RFP to the vendors. And there's a very long checklist that we include that they have to answer those specific questions that are in that download. They're in the actual RFPs that we create as well. So it's a little bit of, we're offering a little IP to users.

So it's the things that you would use for yourself as part of the process.

Yeah.

That's great. So for the question I ask everybody on the DAM Right podcast, which is, what is the last song that you added to your favorites playlist?

Oh, I'll tell you right now. I have it right in front of me.

Great.

Heart of Gold by Neil Young.

What were the circumstances there?

He's back on Spotify. He had left Spotify. They pulled all of his stuff off Spotify. And I realized he was back. And so I grabbed that song. Yeah. Four days ago.

That's right. Well, thank you so much for joining me and sharing your expertise and your experience and all this great information. It's been fun having you on. I really appreciate you taking the time.

Yeah. Thanks again for the opportunity to talk about a topic that some people might not find very exciting, but I do.

You know that I know that you want to get your hands on Amy's how-to guide and handouts for DAM selection. Come closer and I'll tell you where to find it. Closer. I don't want anyone else to hear this. Okay. It's weareavp.com/creating-a-successful-dam-rfp. That's where the guide is. Here's where you get the handouts. It's weareavp.com/free-resources. Okay. Now delete those URLs once you download them. I don't want that getting out to just anyone. All right. Talk to you later. Bye.