Is this what your RFP looks like to a vendor?
Most of us in the business landscape have encountered the RFP process at least once in our professional lifetimes, which means we all felt the same apprehension take hold in our stomachs when we opened this article. RFPs are a necessary evil of doing business – but we’d like to make the case that they don’t have to be. There are a few common mistakes that most organizations make during RFP development that amplify the complexity and the burden of the process. Avoid the following common missteps and you’ll have a much cleaner, simpler RFP process ahead of you.
Letting Too Many Cooks in the Kitchen
You’ve identified a problem within your organization that you imagine a solution must exist to solve, so you propose moving through the RFP process to get a feel for what’s available. Leadership gives you the green light to kick things off, but that’s not the last thing that happens before your first meeting. Word tends to spread pretty quickly that someone is putting out an RFP, and suddenly every Director in every department surfaces with a justification for why they should be involved and how the subject of your RFP impacts their workstream. Co-workers you’ve never before encountered shout their invaluableness from the rooftop and overnight your initial set of scope meetings includes people from the far corners of your organization who legitimately have no business being there. Maybe you’ve even done this to the RFP of someone else.
Why it happens is understandable; the RFP process has become so time consuming and resource draining that if the opportunity to skirt it and still gain something presents itself, it’s the better option – even if what you end up with is suboptimal. But this practice only contributes to a self-fulfilling prophecy of complexity. So how do you keep all the line cooks out of your kitchen, and maintain your place as Master Chef? Food for thought: assert that you need to build out a laser-focused RFP to truly get a sense of what you’re looking to solve, and once that is done you can circle back with others to effectively evaluate if your areas of need are interdependent and if including them creates any economies of scale.
Trying to Solve Everything
Let’s take another look at the co-workers pushing their way into your RFP. Why are they here? Because they’ve got an issue they’ve needed to solve for ages, but they didn’t want to take on the cumbersome RFP process alone. So they waited for some poor, brave soul (i.e. you) to do it and then wiggled their way into your initial kick off meetings. And they’ll use that opportunity to tack what they need onto the requirements of your RFP, even if their problem is only tangentially related to yours. By the end of the scoping process you need a solution that will solve 40 disconnected problems, and in the mess that is your now-monstrous multi-faced Hydra of an RFP you can’t even find the original business problem that got you there. The justification from all of your newfound friends sounds something like, “If we’re going to go through the pain of an RFP, why not try to address as much as we can?”
We’ll tell you why – it leads to solutions manipulated beyond recognition to the point that their effectiveness often tanks. It leads to massive resource investments from your organization during both procurement and implementation. It leads to disappointed, frustrated purchasers and providers. Your co-workers aren’t joining your kick off meetings just to listen in – they want something. And if they’ve made it in the door, how do you stay true to why youare there and keep your business problem front and center? Try writing your original objective somewhere highly visible, like the meeting room whiteboard. Each time a new potential ‘tack on’ comes up, ask the room, “Does this new problem area contribute to solving the original objective we’re all staring at?” If the answer is no, the room moves on.
Turning Your RFP into a Mystery Novel
An RFP at its core should be so simple. What made you start this process? What is the central problem you’re trying to solve? What does your ideal future-state look like? Aside from how much you’re willing to spend, those are really the key questions a potential vendor needs the answers to in order to deliver a solution that might get you that ideal future-state. But as we’ve already discussed, an RFP often gets away from these core questions early on. When you lose sight of why you’ve started the process, it gets really complicated. And the more complicated it gets, the longer your RFP form gets. Do you have the bandwidth to read hundreds of pages of response from a single potential vendor? Of course not – and that vendor doesn’t have the bandwidth to do a quality job filling it out. What if they repurposed that time into improving what they bring to the table? What if you repurposed that time into effectively preparing your organization for an incoming solution?
Everything a responding vendor submits should be read by you, should be given serious consideration, and should impact your decision on whether or not they solve your problem. Everything a responding vendor tells you should impact whether or not you choose them. When assembling your RFP documentation, put what you’re asking for through that same filter. If the responses you’re going to get from a particular request won’t impact whether or not you choose a particular vendor, leave it out. You’ll be shocked by how much shorter your RFP gets, and by how much you didn’t need the things you cut out.
Pricing Yourself Out of a Solution
When you go to the grocery store hungry, what happens? You end up buying everything, when all you originally needed was a gallon of milk. Writing an RFP is a lot like that. Every time you add a facet to your RFP, you add on cost. Finding a reasonable solution that effectively addresses your initial problem likely isn’t prohibitively expensive, but finding an end-all-be-all solution that cuts off all of your Hydra’s heads probably is. There are likely very few vendors that will fit the bill (if any), they’ll likely have to develop new capabilities to check off every item on your list, and they are definitely going to charge you for it. At that point, you probably can’t afford them. So you go back to the drawing board to figure out what you can drop in order to get the price down, and you end up pulling off layer after layer of tacked-on requests that should never have made it off of your co-worker’s notepad. At the end of the day, you’ll probably still end up paying more than you needed to.
As you’re compiling the pieces of your RFP, think about it like this – if you don’t take the time to do it the right way now, when will you find the time to do it over? Stripping out scope is expensive, time consuming, and frustrating. It’s better to avoid it in the first place.
Asking for More Than You Can Use
When we talk about letting an RFP become Hydra during the development process, it’s important to think about the other side – let’s say you actually find a solution that solves all of your problems and that you can afford…can you even use it? Is your organization structured in a way that it can be implemented, or did you get too sophisticated? Will you be able to design a structure, process, and use-case that delivers ongoing value, or did you spend a lot of money on a complex solution that will be underutilized? If you end up in this situation it’s easy to blame the usual scapegoats, like employees being untrained or existing systems not integrating with new technology. But the true culprit is your RFP.
The best thing you can do is be honest with your organization from the get go about the type of solution it could reasonably take advantage of in its current state. Don’t design an RFP for a solution that complements some future, improved version of your organization. Design an RFP that solves the problem you have nowfor the version of your organization that existsnow.
In short, the RFP process is nothing shy of difficult. But we’re making it harder than it has to be. Avoiding these common mistakes won’t ‘solve’ RFPs, but it’s a good place to start.