Five Tips to Getting a Good Response to a Content Management RFP

Too many times, I read a Request for Proposal (RFP) and actually feel sorry for the organization that issued it, because I know their responses are going to be terrible — they’re going to be rushed, paper-thin, and submitted by firms that the issuer probably doesn’t want working on the project.

Here’s the dirty little secret of RFPs: people are not going to automatically fall all over themselves to respond. Your RFP has to be attractive to them. There are several things organizations do that make their RFPs look extremely unappealing, and the quality of the responses they get reflects that. With this is mind, here are some collected observations on what works in an RFP, and what doesn’t.

Be Selective in Who Gets the RFP

Do not send the RFP to everyone on Earth. Everyone thinks that the greatest idea in the world is to send their requirements to anyone who will listen. This is known as a “cattle call.” Unfortunately, makes your RFP less attractive, and here’s why: the amount of effort a firm will put into the response depends on two things:

1. How much work they have right now.
2. How good the odds are that they’ll get the work.

So, sending your RFP to everyone screws you on two dimensions:

1. Bad Web Firms need work. They’ll respond to anything that comes in the door. They’re desperate.
2. Good Web Firms will find out how many firms got the RFP, and decide that if there are 50 other firms, it’s not worth responding to it.

So, Bad Firms will respond, and Good Firms won’t. This does not bode well for your Web initiative.

What you need to do is pre-qualify Web firms. Do some research — look for firms that work in your vertical, ask other organizations for referrals, look for thought leaders in the CMS space, look for firms that are well-known for the quality of their work. Then call them on the phone and talk to them. Discuss their projects, how they relate to yours, and their working style. Establish some rapport. Get their vibe. You can probably disqualify 50% of firms on a phone conversation and some superficial background research alone. It will become obvious that these are not people you can work with, and including them in your RFP distribution dilutes it.

The Good Firms (the ones you want to respond to), will at least partially evaluate your RFP based on how many other people you sent it to, so by sending it to non-starters, you’re hurting your chances of getting a good response. Let me restate that point for emphasis: every firm you include in the RFP that is not an option for any reason, devalues your RFP to the firms that are.

(But, you say, the RFP will be anonymous! No firm will know about the other firms! This doesn’t work great for a simple reason: Anonymous RFPs are by definition not attractive. We know by now that anonymous RFPs are probably cattle calls, and will usually not respond because of that. If we don’t know how many other firms are playing the game, we’ll assume one million and evaluate the RFP with that in mind.)

Now, let’s take a second to emphasize a point: Good Web Firms aren’t cry-babies. When we don’t respond to an RFP because it’s a cattle call, it’s not because we’re scared, because we want a sweet deal, because we want to be catered to, etc. It’s for two reasons:

1. A good RFP response is expensive. At the very least, even a simple RFP response will cost the responding firm between $500 and $1,000. If it doesn’t, they really haven’t tried very hard. Blend just spent about $10,000 responding to one. I’m much more likely to invest in this if I’m one of three vendors than if I’m one of 50. It’s a simple law of odds.
2. If you send your RFP to everyone, you send the message that you don’t respect your own project enough to do some research. If you don’t care enough to look around and find some appropriate firms for your project, then why should we think you’ll be any different once the project is underway?

Write Stories, Not Requirements

When you write your RFP, you should be writing stories, not requirements (I stole that line — see below). Your RFP should be a collection of scenarios — a collection of uses cases — of things that you or your users need to do. Let the responding vendor tell you how they will do that. Why? Because you can’t solve your problems for the vendor. This is why you’re asking them for help, to help you understand and solve a problem you have. If you explain to them exactly how you want it solved, you might miss out on some great ideas.

I promise that Good Web Firms have ideas and methods of solving problems that you've never even considered before. Some of them might blow your mind. So, give your responding firm some room to run — explain the problem you have, and let them show you how they would solve it.

Additionally, in most cases, it’s not a question of whether or not a solution can do X. Newsflash: all CM systems can edit content. They all have Web interfaces. They all have some form of permissions and workflow. What becomes more important is how a solution does X. Because some ways are so much better than others. Kas Thomas over at CMS Watch wrote this, and it’s brilliant:

Not long ago, I was reading a vendor’s response to an RFP (for a WCMsystem) in which some 200 or so requirements had been enumerated by the customer. The vendor’s response to the majority of the 200 challenges was “Our solution natively provides this capability.” That phrase occurred over and over. (Someone did an awful lot of cut and paste.) […] Likewise, don’t ask “How will you be able to handle XYZ?” unless you’re willing to tolerate answers like “Our standard user interface allows a user to do this” or “our application programming interface allows the product to be easily extended so as to accomplish this.”Instead, write a user narrative or concrete scenario for every one of your key requirements, and demand a narrative answer in response.

With a narrative response, you will find so much better information about a system. You might find that, yes, they have discussion forums, but they’re completely unsuited for what you want to do — they’re rigid and inflexible and would have driven you nuts if you had tried to implement them.

Not only should you request narrative answers to your scenarios, but you should require the responding firm to demo the scenario you described. “Here’s my story, show me how your system would accomplish this.” This is the only way you can realistically see the system in action. Left to their own devices, vendors — especially CMS vendors — will show you the “happy path” through their system. They will tailor demo situations to make their systems look good, and they’ll stay away from any weak points. Don’t let them do this. Force them to demo on your terms, and solve problems you will actually have post-launch.

Seth Gottlieb calls this “experiential” — as in, you have to experience a system.

In a WCMS selection, requirements gathering should stop when you have enough information to filter down the marketplace for a (3 or 4 product) short list. After that, the selection process takes a more experiential aspect where you look at the usability of the software and organizational compatibility with the suppliers that will help assemble the solution (software vendor and systems integrator).[…] I write “usage scenarios” that describe users using the solution to complete a business task (like publishing an article). At the bottom of each scenario, I list out the discrete requirements that were identified. These 2-4 paragraph narratives are then useful in the demo process because they become the script for the customized product demonstration.

When Shopping for a CMS, Don’t You Dare Send a Feature Matrix

Oh man, don’t do this. Don’t, don’t do this. If you have done this already, snap a rubber band on your arm. Hard. A feature matrix reduces everything to a simple binary question: yes or no.

Sadly, in content management, there are few things that are either yes or no. As with the scenario situation above, it’s often a question not of whether a feature exists, but how it works. Take Active Directory integration. This is a pretty common feature request. But it’s still not binary.

• Does the system just bounce a password of a domain controller, so you don’t have to remember another password?
• Does the system collect other information from AD — does it drive your entire user profile in the CMS, for instance?
• Does it handle groups? Can I assign someone to an AD group, and that person will also be assigned in the CMS?
• Does it work for just CMS editors? Or can I use it to manage the CMS access of all the employees in my company, even just the consumers?
• Will is automatically sign users on, or do they have to explicitly log in?

After reading this, think about when you put “does your system support Active Directory” in your RFP and get a “Yes” in response. What does that mean exactly? In addition to this, some features are “supported” with some build-out, and this might be good or bad. Building everything out isn’t acceptable, but some “features” are really just simple CMS building blocks put together in different ways. If the CMS can do this, can the vendor answer “Yes” to your questions?

Take my favorite feature matrix question, “Does your system support blogging?” Some responses are clearly “Yes,” because the system has a special subsystem for blogging (Ektron does this). But, since blogs are just blocks of HTML in reverse chronological order, can I say “yes” if my system will let me organize content this way? Almost any system will let you add content, and list it in reverse order by date. Voila! You have a blog. Right? The vendor can answer “yes” now…right?

Discussion forums are another one. Show me a CMS that supports sub-content (EPiServer is a perfect example), and you can make a discussion forums with it. Take one piece of content (the “forum”), give it some children (the “threads”), which also have some children (the “replies”). Toss in a subscription feature, some permissions, some user profiles, template it up and you have a discussion forum. I could build out a credible forum in EPiServer in two or three hours. So, the vendor can answer “yes” now…right?

(Worth noting is that the “developed” features are often better than the “canned” features because they’re more flexible. Given the option, I’d much rather be given the building blocks to assemble a feature than just be given the feature itself.)

Whether or not a canned or developed blogging system or discussion forum qualifies as a “yes” answer is up to you, but there’s no way to know which one it is from a single word. Some vendors will say “no” since their system is developed rather than canned. Others will say “yes” under the exact same circumstances. You have no way of knowing this.

Be Honest and Upfront About Your Budget

I wrote another blog post a few weeks ago that addressed this more directly: Give Us a Budget Target. As I’ve mentioned a few times above, whether or not a Good Web Firm responds to an RFP depends on a lot of factors, and one of them is undoubtedly the size of the deal. In two dimensions:

1. Is the deal in the price range of the vendor? Some vendors don’t do well with smaller deals, and they often have an unstated minimum deal size.
2. Is the deal reasonable for what the prospective client wants to accomplish? If the RFP is all about re-writing Facebook, and the budget is $5,000, then it’s probably better to know that up-front.

The benefit of being upfront here is to eliminate firms that are non-starters, both for your benefit and the vendors. For your benefit, any vendor — even a non-starter — adds to the cattle call and makes legitimate vendors less interested in responding, so fewer vendors works in your favor. And for the vendor’s benefit, they don’t invest a lot of money in an RFP response that has no way of working out.

Consider Using an Intermediary

Content management can be hard. And picking a content management system can be a really tricky thing, especially if you don’t know anything about how it works. In these cases, you might want to consider hiring a consultant to help guide you through the RFP process.

Someone like this can help you explain what you need. They can interpret your situation and run the demo process — from scheduling the demos, to helping you ask the right questions. Additionally, they protect you from incessant lobbying from the vendors. Good ones have dealt with this process dozens of times before. They stand between you and a hungry horde of vendors, acting as an advocate for you, keeping the vendors honest, and interpreting the often confusing things they say.

Blend has been involved with two selection processes in the last few months (one is complete, one is ongoing) which involved end customers represented by a consultant. They both have gone much more smoothly, and the presence of someone like that really demonstrates your investment in the project.

One of the fears in responding deeply and completely to an RFP is that the project will get canceled, or that the prospective customer isn’t that serious about it. But if I know you have invested in someone to help you manage this process, you have some skin in the game. I will take your RFP that much more seriously as a result.