January 10, 2012 Leave a comment
RFI’s drive me crazy.
First, I think the concept is a Gordian knot. I need to learn about something I do not know. I will learn by asking questions in a static, rigid format. Okay, but if you don’t know about something, how can you hope to ask the right questions to get the information you need, or hope that your questions don’t inhibit receiving the real information you need, which you don’t know you need because you don’t know. You don’t know what you don’t know, so how do you expect to ask questions so you will know. See – Gordian knot.
Second, the amount of bias is staggering. I will ask people who have a vested interest in swaying my thinking for the answers I need. I will ask the vendors. The vendors that are in a daily dogfight in a crowded and often confusing market where every vendor tells much the same story. Vendors that hold Maslow’s proverbial hammer and will therefore put every answer in the context of the nail for which their hammer best drives. Vendors that know before you ask that the answer to every RFi or RFP question is – surprise! – yes. Vendors that are on commission for heaven’s sake!
Well, Jim, why wouldn’t I ask the vendors? They are most helpful. Some offered to actually write the RFI for me. I see your point and that seems perfectly reasonable. It frees you up to interview foxes to watch your hen house.
What really frustrates me about RFIs is the lost opportunity to get exposed to truly innovative solutions that the organization could actually use to fill very real gaps in their IT security. Why? because most RFI writers don’t know what they don’t know and therefore ask questions about what they do know: the same tired technologies that are at the heart of the very gaps that need to be filled. RFIs are written from the sound bites from analysts and vendor web sites and industry pundits. So what comes back is the same tired answers and nothing new is discovered.
You don’t know what you don’t know. But what you do know is your problem, and that is where you should start. You may not be ready to admit it publicly, but you know what gaps your organization has. You know malware is getting past your shields, and you know that you are not equipped to know when and where. RFIs should not use vendor terminology or be bound by the solution de jour.
Write your RFIs to real, unfiltered gaps and problems, and provide a framework for vendors to provide solutions, but stay away from pre-dispositions. Doing so will quickly sort marketing speak from real, innovative technology that is not more of the same. Questions should be heavy on detail about the problem, but not have artificial fences or filters as to how the problem can be solved. Old assumptions should be abandoned, because those assumptions were largely forged about attacks and attack techniques that have evolved exponentially and have shattered those assumptions.
Tell me your problem and open your mind to the answer. Am I biased about my product? You bet I am. But give me the opportunity to honestly (yes, there are more honest vendors out there than you may think or have been led to believe) provide you alternatives that you may not have even heard about, much less considered when writing the RFI. You may be surprised what is out there. After all, isn’t that the point?
That is all for now, as I have some RFI’s to compete. Let’s see. Question 1…(thoughtfully pondering)…”Yes”.