In episode 179 of the Content Strategy Experts podcast, Sarah O’Keefe and Alan Pringle share the inside scoop on how to write an effective request for a proposal (RFP) for content operations. They’ll discuss how RFPs are constructed and evaluated, strategies for aligning your proposal with organizational goals, how to get buy-in from procurement and legal teams, and more.

When it comes time to write the RFP, rely on your procurement team, your legal team, and so on. They have that expertise. They know that process. It’s a matter of pairing what you know about your requirements and what you need with their processes to get the better result.

— Alan Pringle

Related links:

• 
  
• Survive the descent: planning your content ops exit strategy (podcast)
  
• The business case for content operations (white paper)
  
• Content accounting: Calculating value of content in the enterprise (white paper)
  
• Building the business case for content operations (webinar)
  

LinkedIn:

• 
  
• Sarah O’Keefe
  
• Alan Pringle
  

Transcript:

Disclaimer: This is a machine-generated transcript with edits.

Alan Pringle: Welcome to the Content Strategy Experts Podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about writing effective RFPs. A request for a proposal, RFP, approach is common for enterprise software purchases, such as a component content management system, which can be expensive and perhaps risky. Hey everybody, I am Alan Pringle.

Sarah O’Keefe: And I’m Sarah O’Keefe, hi.

AP: So Sarah, we don’t sell software at Scriptorium, so why are we talking about buying software?

SO: Well, we’re talking about you, the client buying software, which is not always, but in many cases, the prerequisite before we get involved on the services side to configure and integrate and stand up the system that you have just purchased to get you up and running. And so, because many of our customers, many most, nearly all of our customers are very, very large, many of those organizations do have processes in place for enterprise software purchases that typically either strongly recommend or require an RFP, a request for proposal.

AP: Which let’s be very candid here. Nobody likes them. Nobody. 

SO: No, they’re horrible.

AP: Vendors don’t like them. People who have to put them together don’t like them, but they’re a necessary evil. But there things you can do to make that necessary evil work for you. And that’s what we want to talk about today.

AP: So the first thing you need to do is do some homework. And part of that homework, I think, is talking with a bunch of stakeholders for this project or this purchase and teasing out requirements. So let’s start with that. And this is even before you get to the RFP itself. There’s some stuff you need to do in the background. And let’s talk about that a little bit right now.

SO: Right, so I think, you know, what you’re looking to get to before you go to RFP is a short list of viable candidates, probably in the two to three range. I would prefer two, your procurement people probably prefer three to four. So, okay, two to three. And in order to get to that list of these look like viable candidates, as Alan’s saying, you have to do some homework. Step one, what are your hard, requirements that IT or your sort of IT structure is going to impose. Does the software have to be on premises or does it have to be software as a service? Nearly always these days organizations are hell bent on one or the other and it is not negotiable. Maybe you have a particular type of single sign-on and you have some requirements around that. Maybe you have a particular regulatory environment that requires a particular kind of software support. You can use those kinds of constraints to easily, relatively easily, rule out some of the systems that simply are not a fit for what your operating environment needs to look like.

AP: And by doing that, you are going to reduce the amount of work in the RFP itself by doing this now. So you’re going to streamline things because you’ve already figured out, this candidate is not a good fit. So why bother them and why make work for ourselves having to work and correspond with the vendor that ends up not being a good fit.

SO: Right, and if we’re involved in a process like this, which we typically do on the client side, so we engage with our customers to help them figure out how to organize an RFP process, right, we’re going to be strongly encouraging you to narrow down the candidate list to something manageable because the process of evaluating the candidates is actually quite time consuming on the client side. And additionally, it’s quite time consuming for the candidates, the candidate software companies to write RFP responses. So if you know for a fact that they’re not a viable candidate, you know, just do everybody a favor and leave them out. It’s not fair to make them do the work.

AP: No, it’s not. And we’ve seen this happen before where a organization will keep a vendor in the process kind of as a straw man to strike down fairly quickly. It would be kinder and maybe more efficient to do that before you even get to the RFP response process, perhaps.

SO: Yeah, and of course, again, the level of control that you have over this process may vary depending on where you work and what the procurement RFP process looks like. There are also some differences between public and private sector and some other things like that. But broadly, before you go to RFP, you want to get down to a couple of viable candidates, and that’s who should get your request for proposal.

AP: Yeah, and when it does come time to write that RFP, do rely on your procurement team, your legal team. They have that expertise. They know that process. It’s a matter of pairing what you know about your requirements and what you need with that process to get the better result. And I think one of the key parts of this communication between you and your procurement team is about use case scenarios. So let’s talk about those a little bit because they’re fundamental here.

SO: Yeah, so your legal team, your procurement team is going to write a document that gives you all the guardrails around what the requirements are and you have to be this kind of company and our contract needs to look a certain way and various things like that. We’re going to set all of that aside because A, we don’t have that expertise and B, you almost certainly as a content person don’t have any control over that. You’re just going to go along with what they are going to give you as the rules of the road in doing RFPs. However, somewhere inside that RFP it says, these are the criteria upon which we will evaluate the software that we are talking about here. And I think a lot of our examples here are focused on component content management systems, but this could apply to other systems whether it’s translation management, terminology, metadata, you know, all these things, all these content-related systems that we’re focused on. So, somewhere inside the RFP, it says, we need this translation management system to manage all of these languages, or we need this component content management system to work in these certain ways. And your goal as the content professional is to write scenarios that reflect your real world requirements that are unique to your organization. So if you are in heavy industry, then almost certainly you have some concerns around parts, about referencing parts and part IDs and maybe there’s a parts database somewhere and maybe there are 3D images and you have some concerns around how to put all of that into your content. That is a use case that is unique to you versus a software vendor who is going to have some sort of, we have 80 different variants of this one piece of software depending on which pieces and parts you license, and then that’s gonna change the screenshots and all sorts of things. So what you wanna do is write a small number of use cases. We’re talking about maybe a dozen. And those dozen use cases should explain, you know, as a user inside the system, I need to do these kinds of things. You might give them some sample content and say, here is a typical procedure and we have some weird requirements in our procedures and this is what they are. Show us how that will work in your system. Show us how authoring works. Show us how I would inject a part number and link it over to the parts database. Show us, you know, those kinds of things. So, the use case scenarios typically should not be, “I need the ability to author in XML,” right?

AP: Or, “I need the ability to have file versioning,” things that every CCMS on the planet does, basically.

SO: Right, somewhere there’s a really annoying and really long spreadsheet that has all those things in it, fine. But ultimately, that’s table stakes, right? They should not get to the short list unless you’ve already had this conversation about file versioning and the right class of system. The question now becomes, how do you provide a template for authors and what does it look like for authors to start from a template and do the authoring that they need to do? Is that a good match for how your authors need to or want to or like to work. So the key here from my point of view is don’t worry too much about the legalese and the process around the RFP, but worry a whole bunch about these use case scenarios and how you are going to evaluate all the different tools that you’re assessing against the use case scenarios.

AP: Be sure you communicate those use case scenarios to your procurement team in a way they understand so they have a better handle on what you need because if everybody is kind of on the same page as far as those use cases go the clearer it’s going to be to communicate those things to the candidate vendors when they do get their hands on the RFP.

SO: And I think as we’re going in or talking about going into a piece of software, there probably should already be some consideration around exit strategy, which Alan, you’ve talked about that a whole bunch. What does it mean to have an exit strategy and to evaluate that in the inbound RFP process?

AP: It is profoundly disturbing to have to think about leaving a before you’ve even bought it, but it does, does behoove you to do that because you need a clear understanding of how you are going to transition outside of a tool before you buy it. So when that happens, when you come to a point where you have to do it, you have an understanding about how you can technically exit that tool. For example, how can you export your source files for your content? What happens when you do that? In what formats? These are part of the use cases that you’re talking about perhaps here too. So it really is so weird to have to think about something that’s probably years down the road, but it is to your advantage to do that at this point in the game.

SO: Yeah, I mean, what’s the risk if something goes sideways or if your requirements change? This doesn’t have to be sideways. So you are in company A and you buy tool A, which is a perfect fit for what you’re doing. Company A merges with company B. Company B has a different tool and B is bigger than A. So B wins and you exit tool A as company A and you need to move all your content into tool B. Well, that’s a case where you made all the right decisions in terms of buying the software. You just didn’t account for a change in circumstances, as in B swooped in and bought you. So what does it look like to exit out of tool A?

AP: Yeah, it doesn’t necessarily have to be the tool no longer works for us. It could be what you describe. There can be external factors that drive the need to exit, have nothing to do with bad fit or failure on anybody’s part.

SO: So we have these use case scenarios and we’ve thought about exit, though this is entrance. 

AP: Or even before entrance, you haven’t even entered yet.

SO: And so now you’re going to have a demo, right? The software vendor is going to come in and they’re going to show you all your use case scenarios. Well, we hope they’re going to show you your use case scenarios. Sometimes they wander in and they show you a canned demo and they don’t address your use cases. That tells you that they are not paying attention. And that is something you should probably take into account as you do your evaluation.

AP: Yeah, and don’t get sucked in on a similar note. Don’t get sucked in by flashy things because that flash may blind you and very nicely disguise the fact that they can’t quite match one of your use cases. So look at this sparkly thing over here. Don’t fall for that. Don’t do it. Yeah.

SO: Sparkles. So, okay, so we have our use cases and they are going to bring a, they, the software vendor is going to bring some sort of a demo person and they are going to demo your use cases and hopefully they’re going to do it well. So you sort of check those boxes and you say, okay, great, it works. I think the next step after that is not to buy the tool. The next step after that is to ask for a sandbox so that your users can trial it themselves. There is a big, big difference between a sales engineer or a sales support person who has done hundreds, if not thousands of demos going click, click, click, click, click, at how awesome this is. And your brand new user who has never used a system like this, maybe, trying to do it themselves. So user acceptance testing, get them into a not for production sandbox, let them try out some stuff, let them try out all of your use cases that you’ve specified, right? 

AP: It’s try before you buy is what we’re talking about here. Yep.

SO: Mm-hmm. Yeah, I’ve just made a whole bunch of not friends among the software vendors because of course setting up sandboxes is kind of a pain. 

AP: It’s not trivial. 

SO: Yeah, but you’re talking to just one of two candidates, right? So it is not unreasonable. It is completely unreasonable if you just did a, know, a spray this thing far and wide and ask a dozen software vendors for input. That is not okay from my perspective. And when we’re involved in these things, we try very, very hard to get the candidate list down to, again, two or three at most because almost certainly you have requirements in there somewhere that will make one or another of the software tools a better fit for you. So we should be able to get it down to the reasonable prospect list.

AP: And I think too, this goes back to efficiency. Having fewer people or fewer companies in this means you’re gonna have to spend less time per candidate system because you’ve already narrowed it down to organizations that are gonna be a better fit for you. So it’s gonna be more efficient for them because they’re not having to probably do as much show and tell because you’ve narrowed things down very specifically here in my use cases. Also for you as the tool buyer and your procurement team, you’re going to have less to do because you’re not having to talk to four, six candidates, which you should not be doing for an RFP, in my opinion. I know some people in procurement will probably disagree with that though.

SO: Well, we’re just going to make everybody mad today. And while I’m on the topic of not making friends and not influencing people, I wanted to mention something that probably many of you as listeners are familiar with, which is something called the Enterprise Architecture Board. If you work in a company of a certain size, you probably have an EAB. And the EAB is kind of like the homeowners association of your company, right? They are responsible for standards and making sure that you occasionally mow the lawn and whatever else, whether there are other ridiculous rules the homeowners association set. But EABs, Enterprise Architecture Boards in a company context, are responsible for software purchases, software architecture, and looking at what kinds of systems are we bringing into this organization and usually how can we minimize that? How can we maintain a reasonable level of consistency instead of bringing in specialty solutions all over the place? Now, a CCMS, a component content management system is pretty much the definition of a specialty system. 

AP: It’s niche. Yeah.

SO: Yep, and EABs in general willl take one look at it and say something very much like, “CCMS, no, we have a CMS. We have a content management system. We have SharePoint, just use that. We have Sitecore, just use that. We have fill in the blank, just use that.” And your job, if you have the misfortune to have to address an EAB, is that you need to explain why it is that the approved existing solutions within the company architecture do not meet the requirements of the thing that you are trying to do and because that one’s not hard. The and part is the hard part and it is worth the and they’re going to talk about TCO total cost of ownership. It is worth the effort and the risk and the complexity of bringing in another solution beyond the baseline CMS that they’ve already approved to solve the issues that you’ve identified for your content. This is difficult. I’ve spent a lot of quality time with the AABs and they’re literally their job is to say no. I mean, that is just flat out their job. Their job is to streamline and minimize and have as few solutions as possible. So if you have to deal with this kind of situation, you’re going to have some real challenges internally getting this thing sold.

AP: Yeah, and while we’re making friends and influencing people with our various comments on this process today, one final thing I want to say before we wrap up is, that common courtesy goes a really long way in this process. When you have wrapped things up, you have made your selection. Be sure you also communicate that to the vendors you did not choose.

SO: Yeah.

AP: Too many times in RFP processes, there’s not the level of communication with the people who did not win. And it’s just common courtesy, let them know, no, we chose someone else. And if you’re feeling super polite, you might even tell them why this use case you didn’t quite hit. This is why we went with this organization if you choose to. So be nice and be courteous because I realize this is more of a professional business situation, but it still doesn’t hurt to tell someone exactly why you did what you did.

SO: Yeah, and I know those of you in more on the government side of things, nonprofit, typically do have a requirement to notify on RFPs and even give reasons and all the rest of it. But on the corporate side, there’s typically not any sort of requirement to let people know, as Alan said. you know, people put a lot of work into these RFPs and a lot of pain. 

AP: Yeah.

SO: And one last, last thing beyond you should notify people. I want to talk about RFP timing. So we’re rolling into the end of 2024 here. I fully expect that there will be RFPs that will come out on roughly December 15th, which will be due on something like January 1st. So in other words, “Hi vendors, please feel free to spend your holiday time filling out our RFP so that we can, you know, go into the new year with shiny RFP submissions.”

AP: RUDE!

SO: That is not polite. Don’t do that. It is extremely rude. And it signals a level of disrespect that from the vendor side of the process makes them perhaps less inclined to bend on some other things. So reasonable amount of time for the scope of work that you’re asking for. And holidays don’t count.

AP: Yeah, exactly. to go back, I think we can kind of wrap this up and go back to what we were talking about. All of that legwork that you do upfront for this RFP process, your vendors, believe it or not, would generally appreciate it because it shows you’ve done the homework, you have thought about this, and you’re just not wildly flinging out asks with no money, no stakes behind those asks. And they will probably be much more willing to work with you and go that extra mile when you have done that homework. Is there anybody else that we need to tick off before we wrap up?

SO: I think we covered our list. So I’ll be interested to see what people think of this one. So let us know, maybe politely, but let us know.

AP: And I’ll wrap up before there’s violence that occurs. So thank you for listening to the Content Strategy Experts Podcast brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.

The post Creating content ops RFPs: Strategies for success appeared first on Scriptorium.