When responding to RFP’s, the natural temptation is to respond at the level of most of the information in the RFP, assuming that the bulk of the detail denotes the solution that they are looking for and actually need, but many times it can be quite the opposite. Sometimes the focus of RFP’s is on the tangible and tactical, when often the hidden intent of the request is at a much higher strategic level. Other times it may be the opposite. Being aware of the possibility of this hidden intent and these unspoken customer requirements may make the difference between success and failure in your efforts at crafting a proposal response.
For instance, on one recent large response initiative that I joined in-flight, the customer was ostensibly requesting a proposal for a data center consolidation and the RFP included lots of details on existing data center locations, network topologies, server, storage and application inventory totals, etc. At first glance it appears to be a straightforward server move and consolidation/virtualization project and indeed the response team had already launched into that direction and had started compiling a long list of execution level response artifacts like specialist partners with move/consolidation/virtualization tools and experience, and the entire focus had devolved down to this tactical level. However I felt there were a couple of important clues in the RFP that were being overlooked, namely a brief mention that the customer already had some IaaS (Infrastructure as a Service) and SaaS (Software as a Service) initiatives, as well as some other outsourced service offerings and some cloud computing services as well. Although there was no context or further clarification around these details, their very presence to me signified that a much different approach was needed from a much higher strategic level. Obviously this company had some competing technology visions and strategies at play in their environment that needed to be reconciled first before any tactical level recommendations would be of any value.
From the perspective of a CIO who had inherited a heterogeneous technology landscape through a multitude of acquisitions with multiple data centers in multiple physical locations, each with their own tech stack and disparate technology strategy and direction, and being tasked with the responsibility of rationalizing all this into a cohesive information technology asset that aligns with business requirements, the details on how you would move a few servers from location A to location B would seem to be the last thing on his mind. Crafting a response at this level would be a certain miss. Instead, higher value-added consulting at the strategic level was needed first to help the CIO drive a decision on his larger big-picture direction, like how to juggle and balance his various existing competing technology strategies like whether to push out to the cloud, or keep it in-house, and whether to outsource his app maintenance and support or keep that in-house. Then and only then would the execution plan have any value, after the larger enterprise wide technology strategy had been decided, and the resulting execution level details were rolled into the overall plan.
This approach was floated by a contact on the inside and indeed verified and confirmed and substantially changed the focus of the response team and the response deliverable. Very little of these higher level strategy type details and their importance were overtly spelled out in the RFP but the inclusion of an analysis at this level first proved to be a key differentiator in selecting the winning proposal.
On another occasion, I once authored an development services RFP response that was exactly the opposite of the above scenario. After poring through several hundred pages of disjointed and erratic RFP content, I found myself struggling to find any implementation level detail at all that would give a clue as to what kind of solution was actually needed and what kind of system might need to be built. Instead the material was an endless rehashing of high level business requirements and ethereal strategy direction, with an occasional broad app concept thrown in as a potential solution like SOA or data warehousing. What was glaringly missing was anything at the solution or implementation level and that was what the customer was actually looking to build.
After a couple of days of trying to divine the etiology of this very unique and unusual RFP, my suspicions were confirmed when we learned that most of the RFP material was the result of a Big 4 consulting engagement and everything was intentionally at the higher level of business requirements and technology strategy as that was the level of the engagement and their expertise. The customer had spent over a year and several million dollars with this Big 4 firm and all they had to show for it was several Word documents and a few PowerPoint presentations. Although it wasn’t obvious from the RFP, the customer was weary of talking and discussing strategy and direction when what they really wanted was to get started building a solution prototype that they could go to market with quickly as market forces and opportunity costs were mounting against them for every day they delayed action.
As a result, I made and documented a few assumptions and quickly turned around a response that proposed the quick delivery of a prototype system that could be built out in parallel while the final business requirements were being decided and that included all the needed infrastructure of an enterprise application like a highly available ESB and app server tier, an enterprise data model and HA data tier, a functional data warehouse, enterprise security model, and hosting services thrown in. I proposed in parallel two teams of business analysts, development leads and data architects to drive the requirements of the custom built J2EE apps and an iterative Agile development methodology they would need to get their solution to market. In addition, I included an Enterprise App Architect to drive the definition of the SOA interfaces and data payloads between the various custom apps. This turned out to be exactly what the customer was looking for and it was even termed “incredibly insightful” by the VP of Development because he knew the RFP material was a mash-up of mostly irrelevant and misleading content and what was needed was a solution that cut through all of the distraction and got to the heart of what was the business really needed. Had I responded at any other level it would have been another miss like most of the other vendors.
In both of these examples, what the customer was actually looking for was not obvious or intuitive from the RFP material and it took some out of the box thinking and analysis to arrive at a winning proposal. Sometimes, for whatever reason, the RFP content paints only a partially accurate picture of what the customer wants or needs and it is important to critically analyze this question when approaching any RFP response. Although some things are better left unsaid, real customer requirements in an RFP are not typically part of this classification, but they nevertheless do sometimes fall into it.
John Walley is an Enterprise Architect with Fortune 5 Experience and a 20 year veteran of IT consulting.
Subscribe via RSS