For those of you unaccustomed to the inner workings of the IT business, the RFP (request for proposal) is a formal, written communication to multiple IT vendors.
The use of RFPs used to be nearly universal. These days, you see far fewer of them. Certain kinds of organizations (e.g. public sector) are legally bound to use an RFP process. And you still see the occasional private enterprise issuing RFPs as well.
I get sent a lot of storage RFPs to comment or contribute. And they can be very telling as to what kind of IT organization is creating them.
A Bit Of Background
If you think of IT as essentially buying products, the whole notion RFPs make a bit more sense -- especially in areas of technology that have essentially commoditized. If I was in charge of acquiring, say, 1000 laptops, I'd probably use an RFP process.
If you think of an RFP as a contest, well, it's expected that the contestants may try and find a way to game the system.
One way that vendors try to game the RFP process was to get their unique widget or feature specified as a "requirement" in the RFP.
Another popular approach is to propose back to the customer exactly what was asked for (and nothing more!), regardless of whether or not the proposed solution actually will achieve the desired results. Taking this approach can result in a proposal price that is significantly lower than vendors who propose more complete solutions.
There are other popular tactics I could share as well, but they can be rather unsavory, so we'll skip over those for the time being.
Compare the product-oriented RFP approach with someone who's got a broader IT problem and needs an overall solution. For example, if the stated problem is "we're spending too much on storage", some vendors might propose products, some vendors might propose methodologies, and a few vendors (like EMC) might propose a combination of both.
There are no speeds-and-feeds involved. Just a statement of the challenge, the relevant context and the desired outcome. Not exactly amenable to an RFP process, more of an RFI -- request for information. That inevitably leads to a discussion, rather than a written proposal.
No storage RFP is perfect. However, they do fall into various categories that I've established over time.
The Procurement-Led Storage RFP
These documents are typically around 20 pages. 19 of them speak to the procurement process, terms and conditions. All very dense and formal stuff, all obviously boilerplate that they use for everything: IT or otherwise.
One of the pages usually lists what they're trying to purchase -- capacities, desired interfaces (e.g. FC, NAS) and a few key features, like snaps. Maybe a half-page of text at best. That's all you get.
Typically, no direct communication is permitted with the person who wrote the half-page of useful information. However, there's usually an entire procurement group who is more than willing to enthusiastically discuss the other 19 pages in great detail.
Pretty hard to get to "what problem are you trying to solve?" as a result.
The Technology-Led Storage RFP
These documents are also 20 pages long, but the content is inverted. 19 of the pages speak to an exhaustive list of each and every storage capability that is available in the marketplace. Occasionally, this extended list of "mandatory requirements" will include technologies that are made of the precious element unobtanium -- they aren't really in the market yet.
The good news is that the authors are usually more than willing to engage with us vendors to discuss their requirements in detail. The unfortunate part is that frequently they're looking for an "answer" without really understanding the core question: what exactly are you trying to get done?
The Stay-In-Your-Box Storage RFP
No surprise, storage is usually integrated with something else in the IT stack: security, backup, virtualization, resource management, specific applications, etc.
Indeed, we at EMC have invested bazillions of dollars in not only core storage technologies, but deep integration with everything around it. For us, storage is not only a stand-alone environment, it's an integral part of the IT landscape.
That being said, we will get RFPs that are extremely clear that they aren't interested in hearing about any of that other stuff. They sternly instruct us to limit our discussion to the specific box we're selling, and don't try and muddy the waters with all this value-added integration stuff.
I guess that sort of levels the playing field in an interesting way.
The RFP-By-Committee Storage RFP
Some RFP efforts appear to get everyone in IT involved in the RFP process. That's commendable, but someone still needs to make the RFP appear consistent and sensible.
I have an interesting collection of storage RFPs where everyone has clearly had their say, in sort of a cut-and-paste kind of way. Not only is there a cacaphony of voices all saying different things, but occasionally the voices are contradictory, making for an interesting challenge for us vendors.
Since there's no one clearly in control of the process, there's no one we can go speak with to easily clarify the situation. A fair degree of consensus across the team results in an RFP we can intelligently respond to, as opposed to sitting around, scratching our heads and muttering WTF.
The Vendor-Influenced Storage RFP
Clearly, it's every vendor's dream to "wire" an RFP so that they're the only game in town. And we get to see more than our fair share of RFPs where one vendor or another has been somewhat successful at this game.
What most customers don't know is that we -- as vendors -- can clearly see where this has happened. We can tell you which vendors you spoke to, and what they told you to specifically put in the RFP. To us, it's about as plain as the nose on your face.
Look, if you've got your heart set on a specific product from a specific vendor, I'm OK with that. I'll do my good vendor thing and try to convince you otherwise, as you'd expect.
But I"d ask you to please not waste everyone's time by using an "open RFP process" for something that's essentially a foregone conclusion.
Interestingly enough, I see a few of EMC's storage competitors running active marketing campaigns to try and influence what specific features and requirements shold go into a storage RFP. I don't know if this sort of approach to "wiring RFPs at scale" will be effective or not -- time will tell.
Certainly, this sort of approach doesn't appear to have the customer's best interests at heart.
The Beauty Pageant Storage RFP
The approach here is to get all the usual suspects on stage and have them compete using an ostensibly "standardized" set of comparison metrics: performance, availability, price, etc.
While this approach is well-intentioned, it runs afoul of the inconvenient truth that there are painfully few useful standardized comparison metrics in the storage business: performance, availability, price, etc.
Please don't blame us vendors for this state of affairs, that's just the way it is.
At the end of the day, this sort of RFP becomes as subjective as any beauty pageant.
My Ideal RFP?
Glad you asked.
The ones I really like are thoughtful narratives, written by a single person who's got a relatively comprehensive view of the landscape:
- here are the problem(s) we think we're trying to solve: capacity, cost, availability, performance, integration, dramatic business growth or contraction, etc.
- here is our relevant IT context: what's on the floor, what kind of stacks we're running, key apps, IT processes, etc.
- here is our relevant business context: growth/contraction, shift in strategy or markets, new requirements from the business, centralized vs. distributed approach to IT, etc.
- here are some constraints we have to live with: budget, politics, skill sets, timing, etc.
- here are some issues that concern us: vendor lock-in, preserving the existing investment, etc.
- here are our ideas of what we think might be a good answer based on what we know, do you have a better one?
Now, if someone is looking for a single modest array, this might be overkill. But, then again, we're talking about RFPs here, which imply a certain scale and importance of the decision.
If can read through an RFP, and get a good sense of most of the above points, I consider it a good RFP. However, if I read through an RFP and have little or no understanding of the above topics, there's not much we can do to be a good vendor and partner.
BTW, if you're interested in a related rant, please see Mike Workman's thoughts on this topic over at Pillar.
So, if you're in the habit of issuing storage RFPs, why don't you take out your last one, and ask the question -- what does your storage RFP say about you?
Chuck,
Great post really. I don't have a lot to add, I think we have seen every one of these, they are all real.
From my perspective, I love the concept of having smart people getting the opportunity to understand the problems the prospect is trying to solve...but sometimes this is not what is offered. A real solution factoring in the best we can do for them and taking into account constraints like budget, space, existing equipment, network and all of that, that is fun. I will admit we are not always the best fit, but if we know that we all part friends, and maybe we go off and fix issues we have that we can fix, or, just keep our Sales folks focus away from some set of circumstances where we aren't the best so as not to waste our time, or the prospects time.
I think the truth is that all organizations are made of people with bias and different politics - it's life. So they invent a process like RFP's that tries to protect themselves, from well, themselves. This is a bit of a paradox obviously.
When you referred to my recent Blog post as a rant, I went back and read it...you're right. I think I do that a lot. I suppose that's why I love reading your Friday Rants the best - passionate displays of emotion, intellect and sarcasm. Come to think of it, perhaps that's why I like working for Larry?
Thanks Chuck,
Mike
Posted by: Mike Workman | October 29, 2010 at 05:58 PM
Mike
Thanks -- as always -- for the thoughtful and insightful comment.
How wonderful the industry would be if it was populated by more folks like you.
-- Chuck
Posted by: Chuck Hollis | October 29, 2010 at 07:43 PM
Excellent post!
I answered most type of RFP you've describe in the course of my 30 years. Recently I see a new trend where two or less respond to RFPs. This is highly due to vendor and products focus RFPs rather trying to solve the problem like you describe. Other vendors and VARs just walked away from them if they have not influence or get in position prior the RFP. Obviously customer loose in the long run by not writing the RFP like you've suggested.
In enterprise sales this is well known that people by from people and not products. They trust very few peoples and vendors regardless the rest. Maybe why we see subjective RFPs with them. Not the case with consumer and SMB markets where many vendors are present and mainly only dollar counts.
Technology and deep IT knowledge got lost few years ago when mainframe got in trouble. No one truly understand what is going on with virtual and how to connect the dots and wires.
Maybe time to reset the clock in this industry by having better training schools focus on how to use the technology rather than focus on how to save money.
Cloud services and appliance products will solve deep expertise required in technologies partially. But who's going to select the right one without the base...
Posted by: visiotech | October 31, 2010 at 04:26 PM
Chuck,
Many thanks for this insightful post, it reflects the world as I experience it too. I wrote a bit about procurement and its pains on http://bert-hubert.blogspot.com/2010/04/few-notes-on-procurement.html
I'd love to say I was exaggerating in that post..
Posted by: PowerDNS_Bert | November 01, 2010 at 05:31 AM
Bert
Your post on the topic is a hoot! My hat is off to you!
-- Chuck
Posted by: Chuck Hollis | November 01, 2010 at 07:04 PM
Yes, sadly the "what problem are we trying to solve, and why?" is rarely as clear as it should be in RFPs, and I've seen more that fall into the category of "Technology-led" and "Vendor-Influenced" than any of the other categories. Way back in my younger days when I worked in IT organizations (it was called "Data Processing" back then...) none of the companies that I worked for issued RFPs - they basically had open and honest discussions with each candidate vendor, and curiously the vendors that asked the most questions and the deepest-probing questions tended to win our business. Decisions back in those days had far-reaching implications for technology that would typically be in place for many (5+) years, so you invested the time to get it right, more face to face rather than in writing - other than the price quote for the proposal. Now after a few decades on the Vendor side, my favorite RFP is one that I remember well from the late 1990's. We were responding to an RFP from a group within a large communications company that was hoping to merge storage for their previously separate Mainframe, Unix, OpenVMS, and WindowsNT environments, with some specific objectives for reducing cost and complexity. There were some very-specific O/S and version levels stated that required support as mandatory requirements. One of them was for an unusually-named mainframe O/S (in addition to MVS/ESA and VM/ESA) that I had never heard of. When meeting with the customer, I asked about this particular O/S, since it was completely unknown to me. The customers all started to laugh, then let us in on the joke - they had made up the alleged O/S as a test to see if the vendors really read and understood the details of the RFP! They later informed us that despite the fact that this "required" operating system didn't actually exist, none of the other vendors had asked about it, and none had taken any exception to fully supporting it in their RFP responses. Food for thought for all of you customers out there when you issue your next RFP - well after focusing on your business requirements and objectives. :-)
Posted by: Ken Steinhardt | November 02, 2010 at 02:02 PM
And I quote: "Interestingly enough, I see a few of EMC's storage competitors running active marketing campaigns to try and influence what specific features and requirements shold go into a storage RFP. I don't know if this sort of approach to "wiring RFPs at scale" will be effective or not -- time will tell."
Chuck, really? It doesnt bother you that EMC does this all the time. Because of EMC's position in the market, we actually see more 'EMC' RFP's than from any other vendor.
I was prompted to reply to this as I just came across another one today. In this RFP there are several 'EMC unique' tick boxes that are unusable and irrelevant to the customer. So zero marks to EMC for actually understanding the customers environment, needs and requirements.
Posted by: Paul P | November 04, 2010 at 10:24 AM
Paul P:
Damn! I guess being #1 in the storage market comes with a few built-in advantages ...
-- Chuck
Posted by: Chuck Hollis | November 04, 2010 at 11:27 AM