Two short: eight things NOT to do if you’re an ECM vendor at an RFP final presentation
July 15, 2011
Maybe it’s the lack of sleep from having a newborn or the unreliable power grid (and therefore air conditioning) this summer in Chicago, but I’ve got some sand in my shorts about how I’ve seen ECM vendors handle RFP presentations.
- Have more salespeople in the room than there are client team members. Sure, there’s a lot of technical detail in the solution you’re pitching. And, yes, there is some value in having enough experts in the room to answer any possible question. But I’d rather have two or three people speak at a business digestible level about the solution and then agree to get expert follow up where needed.
- If you do bring an army of salespeople, they shouldn’t be on their phones or computers doing other work during the presentation. If they’re that busy—and have enough bandwidth during the presentation to be buried in email or other work—why are they here?
- Be unable to provide a clear idea of what your solution costs – I know that this depends on a lot of factors, but it’s possible to represent this in a transparent, reasonable way. Don’t use it as an excuse to hedge by being vague or ambiguous.
- Try to pack 6 hours of material into a 3 hour session. Yes, ECM is complicated and we could spend a whole day just talking about a single capability, like OCR, let alone all the functionality included in the solution. But at a certain point you need to be able to net it out in the time allotted or cut something. If you can’t come in on schedule in a 3 hour presentation, how will you fare during the implementation?
- Show up as the incumbent with anything less than a full knowledge of the client context – this is your client, who has already bought stuff from you, who you are supposed to have a relationship with. If you come to the table ignorant of the basics, why should they buy more stuff from you?
- Be less organized than the client – You do RFPs all day long, they don’t. You should be Johnny-on-the-spot with follow up items, questions, requested information, etc. Don’t make the client work for it. And let them know daily where you are with your items. This RFP is a big deal for them—heck, some of their jobs may be on the line over the results. Do everything you can to make it less stressful for them and easier to do business with you.
- Be unclear or ambiguous where you are strong and weak relative to the RFP requirements – In terms of weaknesses, this is obvious: if you can’t meet a requirement (or don’t meet it well), so be it. No one meets them all. But hedging or dodging only casts doubt on your integrity as a vendor on top of your inability to meet a requirement. And in terms of strengths, don’t undersell or miss the chance to point out where you’re strong. It’s obvious to you, and it might be obvious to someone who’s read the response, but not everyone in the room has.
- Make sure the client gets a feel for who you are as an organization and as individuals – The client isn’t so much buying a piece of technology as they are entering into a relationship, and that requires them to trust you and your firm. They can’t do that if they don’t know “who you are”—so spend time while you’re there showing them.
There. I feel better already.
But how about you all: got any good advice for vendors on how not to handle the RFP process? Jump in and share your best horror stories.
And in the interest of fairness, I’d love to hear from the vendors: what are the things that buyers should avoid? How do they make the process more difficult, less effective, etc.? What makes you absolutely cringe during the RFP?
Let’s get the conversation started…
14 Comments
leave one →
agile ramblings 
As a client (and former vendor), my pet peeve is the vendors who shows up and insist on launching into their spiel before taking the time to hear about my pain points. I already know enough about the vendors to have invited them to participate in the RFP process. They should listen first to understand the client’s needs so they can then speak intelligently to us about how they can address them.
So true, and all-too-common!
Thanks for jumping Maryanne–hope all is well on your end…we should catch up one of these days…
Cheers,
Joe
Joe,
Great post. I’ve been on the vendor side for a loooong time, and though it’s late Friday night, I couldn’t resist.
From a customer perspective:
1. I hate when vendors answers are complicated. Good RFP’s are written so a simple yes/no/partial will do. When presenting, it’s good form to answer the question simply, rather than just launch into a convoluted explanation.
2. I’ve seen way too many vendors (as a partner, sitting in the room) feel that they need to “stick to the script” instead of having a human connection/conversation with the customers.
From a vendor perspective:
1. We do RFP’s all the time, but that doesn’t mean we can respond in a week or two. You spend all this time, then put vendors under crazy deadlines – you’re not getting our best work.
2. Some of the questions you’ll ask don’t make sense. Not because you’re dumb, or because we are, but because there’s an approach to a solution that presupposes some architecture assumptions. Without those assumptions aligned, the product description has to be force-fitted into your answer/framework.
3. RFP’s in Excel. Are you kidding me? You know how hard it is to write/format/articulate-complex-ideas-that-aren’t-numbers in excel? Plus, I think RFP responding is an art, and as art, I want it to look pretty, be formatted well, be able to hyperlink and have a table of contents, etc. Excel is really limited in all this.
In general, I’d also say… there are always requirements that are unreasonable – but still important and good requirements – just set the stage that the answer could be more about roadmap, intent, and past-performance-indicates-future-compliance than “yes, we support it”. For example, standards support. If a standard is less than 6 months old, it’s likely to be robustly supported. And… some vendors (Oracle/BEA, Microsoft, IBM) will always say they support things but reality is that they support their version of the standard. The “best” way to evaluate vendors on standards is to look how/when they’ve adopted other (older) standards… and to use a use-case around your specific requirements to show what you need (or what your intent is) so that if the vendor can’t do it today, they can scope out what’s needed and the two of you can agree on an implementation strategy and timeframe.
By the way, always do a POC. You may not be able to test everything, in fact, I’d suggest you shouldn’t. But, simply seeing how easy/hard it is to install in your real environment is highly educational.
Also, always call references on performance. If the vendor can’t provide them (and they should be in production, be suspect).
And, finally, big vendor peeve, if you’re doing a POC, have the proper hardware/lab-space/time. The machines should be new builds, of similar configuration to what your real environment is (at least in terms of infrastructure versions – like OS, databases, etc). There’s nothing worse than showing up and being told – “yeah, we wanted to use our lab, but someone took the machines, so can you use your laptop to build our POC?”, or “we can’t get a database license, do you have something we can use?”.
So, really the last thing.
Rebuild the machines between vendors – or, use separate machines. It’s really unfair to give one vendor access to the POC environment of the prior vendor. Most of the times, it’s hard for us to get our competitors software – so having access to a POC environment, even supervised, is really unethical.
Thank you for a great article, I look forward to the rest of the conversation.
David Bressler
Technology Strategist
http://davidbressler.com
http://infinite-probabilities.com/blog
http://bit.ly/MyProgressBlog
http://opusgrid.com/blog
Former TIBCO, Aether Systems, Radianz, Actional, Progress Software. Current OpusGrid & SL Corporation.
PS Very nice mobile theme.
David,
Thanks for taking the time to post such a thoughtful, articulate comment. I appreciate your taking the time to share your experience with folks here, as well as your kind words…
I totally agree with your take on the vendor perspective–I’m considering taking clients to task in a future post to keep things balanced. Honestly, the whole RFP process as we know it often works against everyone’s best interest, but it’s a real challenge at bigger orgs (>$1B) of doing things differently.
I wonder if anyone out there has been through a technology selection process that didn’t follow the traditional RFP process: what did you do instead? How did it go? Was selection easier, harder, the same? Did it result in a better solution than traditional RFPs you’ve been through?
Jump in and let everyone know what else is out there for selecting software…
Cheers,
Joe
Joe,
Funny enough, I wrote up some ideas on how to get a better result from the RFP process about a year ago on my blog. Though, I didn’t take the perspective like you did by splitting it into prospect and vendor (which is a great idea – because by doing that, you can actually come up with a solution that gets everyone with a maximum result).
In short, I did work on one RFP process that stood out. It was a long time ago, maybe 2003/2004 for Credit Suisse. The RFP was being led by consultant WebLayers (who were consulting to support their product business, as their product business launched).
My full post is here: http://davidbressler.com/2010/08/24/rfp/
But, let me give the highlights.
WebLayers asked the vendors for 10 things they thought were important about SOA Governance. They put these things together into an evaluation. They made decisions about what they (and Credit Suisse) thought about SOA governance, and how it mapped to Vendor priorities / philosophies / approaches.
Let me also add a couple of things:
1. I’ve been known to be anti-standards, because I’m more skeptical about the practical limits to interoperability, even when two vendors support the same version of the same standard. So, I place less value on standards interoperability than many.
2. I wish there were a way for customers to “pick a vendor, and do a pilot instead of a POC” – the difference being that a POC is less involved, and more of an educational exercise. But it’s also totally throw-away. Whereas a pilot might be more involved, but when you’re done, you’ve solved a problem (albeit, probably a small one) and can go into production. The biggest challenge is that it would be hard to convince vendors to put in more effort while it’s still competitive, and if it’s not competitive, the vendor has too much pricing leverage when the pilot is done.
3. I’ve worked heavily in Europe, and the process there (in my experience) is very different. They negotiate pricing and do vendor selection earlier. They often pay for the POC (proof of concept implementation) and it’s usually more involved, and more practical (closer to a pilot project). If you’re pilot is successful, you win the deal per the terms agreed to previously (negotiated while it’s still competitive). It’s very different, and leads to some interesting conversations inside vendors when US executives don’t realize this is how it’s done in Europe, and European sales staff don’t realize the executive’s perspective (this latter is less often the case – most European sales people realize the limits of experience in their local markets that their executives back at corporate have).
Finally, I’m speaking from the perspective of small software vendors up to about 1B USD in revenue. I’ve not worked at larger companies.
david
I share your worries for sure. Having been on both sides of the fence, I can assure you that while a client highlights a pain point; they are mostly the symptoms. Like a doctor; you should listen, do a diagnosis and offer your solution.
Of most importance is to under their strategy and their culture and tune your presentation to that. If OCR helps a lot to address that, then there is no harm in focusing on it, but it must not be because your solution is great at OCR.
Do check out my views on a similar aspect http://theinformationmanager.wordpress.com
Sanooj,
Thanks for taking the time to jump in and share your thoughts–I appreciate it!
And thanks also for providing a link to your blog…always like it when folks share their work with the audience here.
Cheers,
Joe
Great blog post. #2 is a pet peeve of mine. i hate being in meetings when people are on their cell phones, and generally not present for a meeting. I blogged about that issue here not so long ago.
http://www.releasefive.com/?p=206
keep up the good work!
Tim
Tim,
Thanks for jumping in and for the kinds words…glad you found the post valuable.
And thanks for sharing your post on meeting etiquette–great advice on something many folks could use a refresher on!
Cheers,
Joe
Joe,
Good post.
I would add what I think is an important one: Be happy, positive, and confident. A wise man once told me that, even though not in the “win” criteria, Olympic Skaters get points for their smile and positive attitudes on the ice.
You already know at least two things about the customer no matter what:
1.) They have a problem or opportunity.
2.) They respect you enough to think that you can solve it for them.
If these two points were not true you would not be sitting in the room.
I agree Maryanne’s previous comments. I think it is important that you have five or six good questions that you can ask the customer to elicit their sometimes unspoken concerns. It is just good manners to let them talking about themselves. Not unlike a first date: Who wants to listen to me talk about myself for three hours without asking more about them.
Dad always said “All things being equal, people buy from people they like… All things not being equal people still buy from people they like”. Gotta have the substance but form is necessary too.
Chris
Hey Chris,
Sounds like you’ve got a very smart dad! I had a sales manager who used to challenge us to ask our customers, after a competitive POC, which features belonged to which vendors… the point being that often, they can’t keep it straight. Not that there is something wrong – it’s that the features are just a mask for getting to know the vendors, and that people buy from the people and company they like/trust. It’s not (as much) about the features.
David
Chris,
Thanks for jumping in and sharing your perspective on the matter…which, as I know from working with you over the years, is always client focused and human, that is, we’re all just people here, no matter what side of the RFP table we’re on or what role we’re in during the sales/consulting process, so let’s act that way first and foremost.
Looking forward to seeing you and the fam later this summer!
Cheers,
Joe
Great post, Joe. Along the lines of your topic of what not to do during the presentation, let me add that not knowing your solution’s limits in comparison to your competition is a negative for me. Having been on both sides of the RFP process as well, but more often as the client, it is usually the case that my preferred solution is a mix of the various RFPs before me. I’m looking for something no vendor can fully support. So, when addressing the team in front of me trying to “make the sell,” I want to know your road map of functionality improvements towards those “holes” as I view it. The ability of the team to respond to that inquiry helps me address the humanity issue, as Chris previously, and appropriately, notes. The character of that response, whether the feature will be available or not, is what is really judged, from my view point. It sets the stage for how negotiations will go in the future should I engage the RFP at hand.
Adrian,
Really good insight…
From a vendor perspective, one thing to keep in mind has to do with revenue recognition. (this is tangential to the initial post, but it’s often useful to know what’s on the mind of the “other side”.)
At Progress, we were particularly conservative in how revenue was recognized. So, any time a deal depended on “futures” it was difficult to get management to sign off on it. They’d push to have the future stuff as a second, follow-up deal. Or, they would go back to product management and engineering and put a real stick in the gears to get a very strong commitment on dates, which would bump other stuff and be very difficult to manage when there are multiple demands on an already stressed team.
Again, not saying you’re wrong (in fact I think you’re spot on), nor say “poor software company, everyone wants something else”. Just trying to let you know why it might not be as easy as you might think (because what you’re saying sounds pretty straightforward and obvious).
PS different companies address futures and rev rec differently. So, Oracle and IBM are different from TIBCO and Progress, etc… Also, notice how Apple now defers revenue on certain products to allow for future “free” upgrades. This is the same stuff.
David