Stop the RFP Silly Season for Web Projects

RFP From Hell graphicThey’re at it again. I’m talking about the RFP (request for proposal) crazies, whose idea of a good time involves searching for a digital agency by casting the biggest net they can find: the dreaded “blind RFP” – wherein a request for proposal is sent to many contenders, often without rhyme or reason.

 

And, often, with no opportunity to have a direct conversation with the clients who own the project.

We’ve written about this subject before, but it seems lately that more organizations than ever have gotten the urge to wallpaper the world with their wants and requirements and addendums as they seek an agency to plan a digital strategy, run a CMS project or redesign their site. So consider this a rant for the sake of sanity – ours and yours.

We’ve made our preferences clear. Regarding our agency, Connective DX, if you’re a potential client looking for a partner and you come bearing blind RFPs (“Dear Vendor…”) you need not apply. Simple.

The Great Wall of Procurement

Just today, my colleague Jeff Cram delivered this message to the U.S. Postal Service, an organization in need of some help if ever there was one. The Great Wall of Procurement stood between us and any human type project initiators inside the organization. We had a few pedestrian questions about their RFP. They made it clear there would be no answers via person-to-person communication. Everything needs to be asked in writing (a not-uncommon demand). So we let them down gently by email. Saved a stamp.

Our position is: If you take a little time to get to know us – and want an open dialog and you value professional advice and thought leadership – we’ll take you and your RFP very seriously.

We’ve urged reform before. But the habit proliferates. So we’re not beyond calling BS on the whole game once again to get our point across.

If you’re going to spend the time creating a nifty RFP, hang on for a sec: Stop trying to back agencies into a corner by requesting specifics that few agencies could rightfully specify. What’s our not-to-exceed budget for your vague, undefined, yet-to-be discussed web project? Who’s our complete project team, with bios, and criminal background status? Stop.

Ideas you can use

If you don’t know where or how to start, here are some practical ideas:

  • Get to know potential agencies without the artificial RFP barrier. Ask peers inside or outside your industry who they’ve worked with, or who they’ve heard good things about, to get an idea of who you might want working for you on the merits of their reputation.
  • Find a discussion group /birds of a feather networking group you trust and ask them for guidance.
  • Or try this: invite a few agencies in for coffee. Put your challenges on the table and see what kind of ideas come back at you. Learn how they think. At worst you’ll get some free consulting and save yourself the agony of sifting through mountains of proposals with your committee.
  • If you do get agencies to craft a proposal, stop, stop, stop asking for 10 copies of our 50 page document, spiral bound, in 9-point arial font. Do you need 15 pounds of paper delivered to your door? Share an electronic file.

Admit this too: The RFP is a crutch for many organizations that don’t have a clue about what questions they should be asking, what type of project they need to be considering, or what type of agency might offer the best fit. To them, the RFP is one step toward figuring it all out. We don’t blame you: unless you do this every day, who would know the answers? Or even what questions to ask? The digital world is evolving quickly, and many of you are in jobs that didn’t even exist a couple of years ago. (Social media strategist? Content strategist? Mobile PPC expert?) We’re working hard to keep up, too.

If you can take a few proactive steps to narrow down your list of contenders, and you’ve established at least a passing relationship with them, then by all means invite them to create a proposal.

Spare the 20 other agencies the headache.

About the Author
David Aponovich

A former 'CMS Insider,' David is relentlessly focused on the gap between vendor speak and customer adoption. In addition to keeping a keen eye on industry trends, he works with clients on the cultural and process implications of CMS that are so often overlooked. David wrote for the CMS Myth during his time working at Connective DX (formerly ISITE Design).

More articles from David Aponovich

Comments

4 responses… read them below or add one.

  1. Jake DiMare says:

    I think this goes hand in hand with helping clients understand that web sites are really long term programs…not projects.

  2. Edwin S says:

    I agree with this post. Moreover, If you are on the consulting part of the business and receive an RFP, it is important to determine very carefully how to come out with an accurate proposal price. Otherwise, if it’s wrong, your company could end it up loosing a lot of money. Pricetaghq.com is a tool that might help you achieve this goal.

  3. Joe Bachana says:

    David this is the absolute best post I’ve read in a long time about the madness of the RFP ‘crutch.’ I read most of these in horror just to see what kind of train wreck has been set up for the issuing company. You can preemptively grok exactly where they are going to fail after implementation, particularly because so few of these RFPs have any specifics about the actual functional requirements and use cases required to implement a Web content management system.

    In one recent case, the issuing company, a MAJOR university up in Cambridge Massachusetts with the letter H in front of its name, had a low-level administrator contact vendors with a heavily red-lined MS Word document that was a Frankenstinian horror show of conflicting requirements, queries by staff, and obvious incompetence. The woman who contacted us had absolutely no clue how to manage the procurement process, which made matters worse when we actually took the RFP seriously by providing a long list of questions and feedback (yes, once in awhile we take the bait…admit it, you guys do too ;-).

    I’m encouraged that many peer organizations like mine (DPCI) who do a really great job implementing WCMS products just immediately no-bid most of these poorly written RFPs. Sadly, there’s quite a great deal more shops that bid, win, then bungle the projects. For government organizations that issue the RFPs, there’s always the change control, right? OR, the long, protracted battle between issuer and awarded company fighting out scope ambiguity. Has a customer ever taken any vendor to court in our industry over project failure? Really?

    I’m sure you and your team will agree – the best possible scenario is for any organization in need of a new WCMS (or any technology for that matter) to hire a consulting firm to help them elicit, progressively elaborate, validate and verify their solution requirements. Thereafter, the customer can then issue that RFP using the professional-grade documentation, or continue working with their consulting firm to select and implement the technology.

    Good luck fighting the good fight man! We’re with ya on this! And thanks for the great post,

    -Joe Bachana, CEO
    DPCI

  4. I agree with Joe,

    I ignore RFPs and when I go look for them, the number of questions I need to ask are just not worth formulating a reply.

    Most large projects we take on with the ToLoRo Group (shameless plug ;) require a period of “Discovery” before we can propose the actual process to achieve the goal. By Discovery I mean a review of current infrastructure, web services, embedded quirks and also researching solutions that fit, although I am a Drupaler most of the time one size does not fit all.

    If the client wants us to do their research on spec, we would rather pass.

    At the end of the day, if an organization or individual is serious about hiring me and my colleagues, it’s not because we rose to the top in a batch of submissions, but because of our reputation and successes.

    Randall Goya – The ToLoRo Group

Leave a Reply
  1. Fields marked with * are required.
  2. We will not publish your email.