The other side of the coin: 7 things NOT to do if you’re running an ECM RFP

In the last post I gave it to ECM vendors on the chin about how they can be their own worst enemy during the RFP process, and, based on the response from you all, it seemed to strike a chord with many people out there.

But in the interest of being fair and balanced about the RFP process, I thought I’d shine a light on some misbehavior of the other RFP participant: the buyer.

After all, it takes two to tango, and in most RFPs-gone-wrong, there’s ample blame to be laid at the feet of the client as well as the vendors.

With that in mind, here are the top things not to do if you’re the buyer in an ECM RFP:

1. Try to compress the RFP timelines beyond all reasonability. You’re buying a multi-million dollar platform and committing dozens (or even hundreds) of your employees for weeks, months, or years of work to get that platform up and running and delivering value to the organization. You can’t make an informed decision in four weeks—heck, you can’t even make a bad decision in four weeks. So rather than creating an unrealistic schedule, rushing the vendors through the response and demo phase, and pressuring the team to evaluate them…and then pushing the deadline further and further out to give everyone enough time to get things done, take a step back and create a reasonable schedule. And if it’s longer than you planned (or than upper management is comfortable with) get real and own up to that now. Much better than over committing and having to blow past your end date.
2. Do things just for the sake of doing them. RFPs have hoary and venerable traditions associated with them—many of which are completely irrelevant to selecting the best solution. Take the time to huddle up as a team to discuss how RFPs are typically run at your organization and the pros and cons of that, as well as some ways that you might run them differently to get more value. Include not only the core project team but any key decision makers as well as ancillary stakeholders like procurement, finance, legal, etc. Get all perspectives on the table up front, before you’re in the thick of the RFP and running up against your deadlines (see #1).
3. Let procurement own the process. Is procurement important? Yes. Do most corporations require you to jump through certain procurement-themed hoops to purchase enterprise software? Yes. Does that mean that procurement knows the right solution for your business needs? Absolutely not. Make sure you’re clear with your procurement folks about the division of labor, i.e., what they are responsible for and what you are (see #2).
4. Let the vendors own the process. RFPs are not your job…in fact, this may be the first one you’ve ever participated in. But you can bet that every member of the vendor sales teams has participated in dozens if not hundreds of them. They likely know how these things work much better than you or the rest of your team do, but that doesn’t mean that you should become passive. You’re looking for software to solve your business problems, not theirs; so step up and own the process.
5. Forget that you’re the customer. You are at the center of the RFP process, you are the reason for it existing in the first place, and you are the person ultimately that must live with the solution that gets chosen. Every element of the RFP process should be engineered to deliver value to you. If some part of the RFP process does not, you should be seriously questioning why you’re doing it (see #2).
6. Take your vendors’ time and efforts for granted. Yes, you are the customer and yes, you have a right to expect responsiveness from your vendors and yes, they want to sell you stuff and yes, they will likely make a very big commission for doing so. But that doesn’t mean you can treat them poorly, waste their time, or expect them to give you hours of free consulting just for the privilege of being part of the RFP. These are real people with real lives, many of whom are very committed to solving client problems with technology. Despite how it might look sometimes when they’re standing in front of your exasperated team speaking to slide 477 of their deck, they spend a tremendous amount of time and energy creating RFP responses and planning presentations—often missing out on time with friends and family to do so. Try to honor that in your dealings with them during the selection process.
7. Forget that the goal of the RFP is to solve business problems with technology, not acquire software. There’s so many moving parts to an ECM RFP that it’s easy to get lost and treat the RFP like an end in itself, which of course it’s not. Selecting, purchasing, and implementing the technology is really just the prelude to the real work: delivering solutions to the organization that solve meaningful business problems. We tend to get lost in all the bells and whistles, all the feature sets and product roadmaps we hear about, and visions of FULLY EXTENSIBLE ENTERPRISE PLATFORMS LEVERAGING THE FULL CAPABILITIES STACK TO DELIVER INTEGRATED SOLUTIONS SEAMLESSLY dance in our heads. None of which matters if we can’t quickly and effectively deploy the chosen technology to deliver value to our end users—don’t lose sight of that.

Hopefully this post helps spread the blame for RFPs gone wrong, but as always I’d love to hear from you all out there: jump in and share your advice for buyers on how not to handle the RFP process.

But as I sit here in my hotel eating room service and writing this post after a long day working with clients, I feel a little disingenuous, because with this series of posts so far I’ve conveniently left the plank in my own eye.

Yes, ECM vendors have issues and yes, ECM buyers have issues, but what about us consultants? Not the integrators and implementers who actually do things, mind you, but us more strategic folks, the ones who come in with their fancy suits and their white iPad2s and all those 11×17 Visio diagrams and tell you what you should do…and then conveniently leave before the real work starts—what do we do that makes life harder for all you clients and vendors out there? Where do we need to step up our game to live up to our aspirations of serving client needs before all else?

And while I take some time in the next week to cast a critical eye on the practitioners in my own guild, feel free to get the ball rolling with thoughts and criticisms of your own: I can take it!