RFPs: More free advice nobody will take

When I received a memo from one of my sales guys a while back regarding a small government RFP I immediately checked the article index for a quick link I could send to illustrate why we on the pointy end of getting things done aren’t fans of RFPs.  I had nothing but an empty cupboard but could have sworn I’ve written about the horrors of RFP responses for IT projects: unclear scope, crappy grammar and so forth.  I couldn’t imagine having this level of critical thought about a subject and not having embarrassed myself by sharing it.  In the land of IT the quality of RFP documentation correlates directly with the scale of their information technology dysfunction.  Bad RFP means bad IT, mostly.  The exceptions are almost always project driven: deploy an ERP system, perform a root cause analysis, report on specific areas of performance improvement, etc…

My raging must have all been in private.  Trust me; I’ve seen some funny things in RFPs and RFIs.  And sad.  Mostly sad.

RFPs (Request for Proposal) are generally awful vehicles for soliciting bids for your project work.  RFIs (Request for Information) don’t even rise to the level of “awful.”  RFIs are no more than excuses for the agent/agency in question to mine the respondents’ brains for IP and then attempt to do the work themselves.  Those proprietary methodologies you said were company property?  They were stolen.  Some knuckle-dragger used them to look thoughtful and informed for a few months while he milked you with question after question requiring a 1,500 word response.

Then they never called you again.  That’s why I don’t even read RFIs except as fodder for the next time I need a good story.

RFPs, in contrast, make a lot of sense if you must solicit a handful of like for like proposals or are a government entity with transparency requirements.  You just can’t get around them.  RFPs are not an acceptable approach if you are simply so lazy you expect vendors to define your project scope for you.  Here’s an example RFP I just received to perform an IT quality of service, efficiency and cost savings assessment, by the numbers:

  • 21 Pages, 10,481 words
  • Grammar and spelling errata: just 2 each (impressive!)
  • 690 words describing all the wonderful improvements this institution has delivered in the last 5 years and commitments to provide literal binders full of success stories for the assessment team.  No mention of Mitt Romney taking credit for any of these successes or assembling the binders himself.
  • Words used to describe the actual scope of services: 134
  • Words used to document the RFP response schedule and timeline: 0

When the staff fail to receive a sufficient number of qualified bidders they will lament the terrible state of industry and perceived difficulty of the problem.  They would be wrong.  The problem is simple.  The RFP makes it hard.  Your RFP sucks.

This institution wants to know if they have the right staffing levels to run an efficient shop, service all of their clients’ needs and remain at least on par with the technological evolution curve.  The IT team wants to know if there are cost saving opportunities to be found in their infrastructure, operations, business processes and technology strategy.  These nice folks also want a detailed action plan, the ROI for any recommendations and a gap analysis between their shop and “best practices.”  There are several sites in scope along with thousands of devices, a whack of storage and probably more than a few vested interests.  The budget is pretty tight, so when the RFP mentions “detailed assessment” it really means to say “as much as the vendor can do without actually charging us or using any of our time.”  That sums it up quite well, minus the actual details that will be fleshed out in the vendor Q&A.

I’ve already written more in this post about the scope of work than is present in the RFP.  This tells me the IT shop in question either has no time to weigh in on the definition of scope or they are so unresponsive as to be ignored by the author.  Whichever it is, this RFP will be a challenge both to address and execute if the work is won.  After I wrote everything to this point I found out our sales guys are pretty sharp folks and they happen to know that IT didn’t offer this RFP, the new CIO did because he or she is performing some year 1 due diligence.

If the CIO is serious, she will take a serious look at the people who churn out RFPs on her behalf.  They could use a lesson in providing background, scoping parameters, timelines and avoiding “fluff.”  Avoiding buzz words and jargon is a good idea, too.  If your RFP is not at least 50% scoping content, please rewrite it.  Here’s the best part: we already know the RFP business will be awarded to either the lowest bidder or your cousin Frank, therefore we have no incentive to make Frank’s job easier.  Nor do we have any incentive to make you a hero on price since we have to build in more margin to survive 4 rounds of negotiation.  You are not going to get the best price for the work through an RFP.  Why organizations don’t understand this baffles me.  It’s like buying a suit off the shelf or going bespoke: you’ll always pay more for a custom fit.

So if you’re going to pay more, at least be sure your RFP will deliver the proposals you need.  Write them like you’re serious about solving your problems.  And listen to this guy, he knows what he’s talking about.

This entry was posted in Future of IT, This is Why We Can't Have Nice Things and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *