RFP process

14 Reasons Why the Website RFP Process Is Really Broken

One of the most painful roadblocks of the web ecosystem is the practice of creating and submitting RFPs (Request for Proposals).

And among the leading reasons why we transitioned to WordPress retainers back in 2014 was precisely due to how broken this process is.

(The other key goal was focusing on recurring revenue.)

But since the process of recruiting agencies and freelancers is so ridiculous at large, let’s look up some raw data.

80% Of All Projects Fail

The most trusted and authoritative source of data in terms of project success and failure rates is the CHAOS report by the Standish Group initially developed and published in 1994. The report has evolved over time, continuously aggregating data from organizations small and large developing IT projects worldwide.

When it comes to waterfall projects (which represents almost every RFP out there), the average rate of derailed projects (anything but tiny websites) is around or even beyond 80%. This includes projects that failed entirely, as well as a vast number of contracts going out of scope, time frame, and budget.

And here’s a breakdown of projects by size/categories as per data gathered between 2013-2017:

Agile vs Waterfall
Image source: https://vitalitychicago.com/blog/agile-projects-are-more-successful-traditional-projects/

Anything outside of small and fairly trivial (turnkey) projects is broadly threatened by delays, scope creep, budget realignments, and other surprises when following a traditional submission or application process, broadly popularized over the past two decades.

Additionally, as indicated above, agile projects see 2x the success rate of the traditional waterfall for large projects and ~60% higher success rate for mid-sized ones—another reason to believe that requirements change on the fly and clarity ahead of time is nowhere to be found.

Now, let’s look into some of the leading reasons why the RFP process should be scrapped altogether in its current form and what makes it so inefficient.

14 reasons why the RFP process is broken

1. The Race to the Bottom

The RFP process is essentially a bidding war. The larger the organization, the stricter the budget limits, the broader the pool of service providers trying to get in.

You can “theoretically” snoop in and win a request for proposal with a bid within the top 20 percentile, but it’s rarely ever possible. And submitting a bid is mostly about packaging and cutting corners, which leaves enough room for certain vendors to undercut and deliver a poorly built solution presenting compromises all over the place only to fit within a certain price bracket.

Websites are NOT real estate or vehicles.

  • You can’t assess pricing ahead of time.
  • You don’t “see what you get” ahead of time.
  • You pay for promises, and delivery is dependent on future factors.

RFPs are poorly designed, leaving plenty of room to cut corners for pricing reasons without being able to assess ahead of time.

Of course, every market requires price normalization and even a gradual decrease in global fees for broader adoption. This, however, is not aligned with the cost of software development, design, systems engineering talent which gets a lot more expensive over time, with the complexity in web engineering increasing rapidly in a constantly evolving industry.

And the nature of RFPs often assumes dozens or even hundreds of vendors pitching for the same project. While negotiating with multiple vendors is common, top vendors won’t even bother dealing with “mass-produced” projects distributed in a similar fashion to job offers on Freelancer or Upwork.

2. False Promises

The very same bidding process is so competitive.

Imagine an infomercial. Television ad space is expensive, competitive B2C products are fighting for attention, and anything within the realm of the law (and what’s permitted in advertising) is thrown into the sales and ads copy.

Smart shoppers are fully aware of the fact that it’s all “Don Draper” of Mad Men out there, and the only thing that really matters is closing more sales in no time.

Unlike an existing contract or working with a designated agency or a freelancer, bidding against competitors will always be influenced by the persuasion process.

We’ve lost half a dozen of enterprise projects purely on the basis of negotiating longer time frames for delivery. In each and every single one of these cases, the winning agencies were behind the deadline with a minimum of 6 months but reputable vendors were discarded in the meantime.

Promises of “top quality”, “all features”, “best user experience”, “highly converting”, “blazing fast” are thrown around with no data to back them up, and without a valid way to verify or establish a foundation to confirm the authority of the statement.

But hey, these catchphrases are thrown away in proposal templates out there, too. Here’s what Proposable’s default WordPress template includes (for a fixed-fee, time-constrained, waterfall project):

deliverables
“Fully functional and approved” within a short amount of time – 100% subjective

You don’t go and buy a smartphone on the basis of “great display” or “long battery life” or “runs every app out there”—but with mass-produced products, there are reviews, YouTube channels, test drives for cars, or live demo in your local AT&T store. Adhering to the same practices for custom work is a recipe for disaster.

3. Impossible Time to Do a Discovery Session

RFPs are often bound by the inability to conduct a proper discovery session to get a project done.

We’ve worked on projects where the planning and strategy session alone (before scoping the project) takes about a year. It’s a paid process with consultants sitting together and mapping out everything and anything to bring the future process closer to success.

Even if a year is far-fetched, spending a few months clarifying requirements is definitely not out of question. This usually includes meetings and calls, drafting sketches or doing whiteboard brainstorming together, and iterating multiple times over what each party has agreed on.

The bidding period for plenty of projects is 3 to 6 weeks on average, and oftentimes the time to gather additional requirements is constrained within 2 to 3 weeks, too.

Here’s a practical example from W3C’s RFP (which is public) and their time frames:

W3C's RFP

Notice the internal delay on their end having to comply with their own process to verify and award the project? Yet vendors are expected to comply internally, ask questions within a 3-week interval (only via email), and spend the remaining time polishing the ad copy for the proposal itself.

📣 The lack of clear requirements is bound to be met with a vague proposal and ongoing discussions AFTER the project has been awarded.

4. Competitor Price Gauging

OK—so there are public RFPs (submitted on job boards or business websites or public RFP networks) and RFPs submitted directly to agencies (through their contact forms or other contact channels).

That said, they work similarly even though prospects submitting RFPs usually blast 5-20 vendors instead of being approached by 5x-10x more on public boards. This more personalized process usually attracts vendors who may decide to take that seriously, considering a lower number of firms approached, some possibly ignoring that or not being qualified.

But there’s another catch; revealing sensitive information around the bidding, pricing, scoping, or selling process can be a dangerous threat when approached by competitors.

I haven’t done “mystery shopping” (submitting fake projects to receive quotes) but I know some of my peers have. I’ve also seen proposals from other vendors a couple of times once we take on a project and a client decides to share features suggested by somebody else.

While I’m less bothered about pricing alone (we’re fully transparent with rates and hourly blocks public), spending 15-30 hours on average scoping a project with calls and mockups and paperwork and time frames is a serious hit we often decide to skip unless the load looks warm enough.

collaboration and streamlined processes

5. Preselected Candidates

Another common pain point I’ve discussed with vendors multiple times is running RFPs just to source a pool of applicants only to pick a predetermined vendor anyway.

Sometimes large companies are afraid of a media scandal of sorts or need to go through the established process, but the outcome is clear ahead of time.

For instance, they’ve worked with a vendor on a previous project but have to go through the paperwork before signing the next one, and this requires gathering applications along the way.

Or a subsidiary (or a partner company) has an internal channel of communication and will be a great fit—an opportunity not presented to outside providers.

All things considered, it’s a valid reason for some of the leading agencies to avoid RFPs altogether or instead adopt practices that help them bid successfully and deal with the consequences later.

proposals

6. Limited Access

In many cases, an RFP project is prepared by a large organization that already runs an outdated website or requires integration with multiple proprietary (or simply inaccessible) tools and services that are to be quoted ahead of time.

Even with an NDA in place, the agency may receive access to a staging site or Google Analytics, but delving deeper often turns out to be a problem. Some standard infrastructure components or services used broadly or required during the implementation process later are:

  1. Hosting/server access – for ongoing deployments, data migrations, setting up tooling, SSL, etc. Figuring out versioning, supported software, what’s allowed can determine a lot in a project
  2. VPN access – in case the software is behind a firewall accessible by a handful of IPs
  3. Domain/Cloudflare access – usually not a blocker per se, but could turn to be a challenge during the final deployment or migration, the SSL setup, DNS redirects, the right timing to set everything up and flush globally
  4. Access to a CRM/ERP/HRM to be incorporated – especially for sales software or eCommerce solutions transferring loads of data to a third-party, scoping out integration as a standalone sub-project is always best
  5. Production setup – including access to production data required for migration, figuring out the user stories behind content production and management – especially important to prevent impact on UX or even omitting features during the rebuild
  6. Access to third-party data systems like S3 or knowledgebase software

We’ve dealt with various caveats when scoping out large projects in a similar fashion.

  • We were asked twice to host a new build on its original server, running a hosting stack that has been depreciated over 10 years ago—thus invalidating our entire solution
  • Access to a disconnected server (only accessible via the internal network) which took three weeks to reset
  • Server access with two-factor authentication to the mobile phone owned by one of the senior directors. Any attempt to access required an immediate call to obtain a token
  • Limited VPN access only accessible through an ancient version of Internet Explorer (with 80% of our staff not running on Windows)
  • Scoping out an SAP integration with limited access, turning into a 4-month sub-project itself
  • An ongoing client of ours went off the grid for 6 hours—twice—as their DNS mapping “magically” got disconnected and we had to access to their domain registrar or Cloudflare. Had to wait for their CTO to wake up to bring the site back online

There are so many caveats behind the scenes, especially with third-party vendors. Oftentimes, it takes weeks or months just to get on the same page with another vendor providing an integration, missing an API, placing artificial constraints adding uploads of time on top of the project.

proposal design

7. Varying Levels of Detail

In addition to the limited access, there are tons of subjective considerations around the implementation details especially as long as UI or UX are concerned.

The most dreadful comment I’ve ever stumbled upon when discussing a beta or running a pilot run internally is:

“It was expected.”

This can be interpreted in different ways:

  • My previous website had this feature so we do need it, pronto.
  • This is a “standard website functionality”, it has to be included.
  • Every website does X, it doesn’t have to be in the original proposal to include it.
  • Supporting all browsers, resolutions, and devices out of the box and expecting pixel-perfect is expected.

When it comes to design, agreeing on the number of revisions and providing practical input is paramount. This is one of the most arbitrary phases in every project and disagreement on this front can turn every project at 180 degrees.

Feature usability can be a serious blocker, too.

  • My team is used to adding X in a small box and then connecting it with a toggle and dragging something here, your admin UI is broken and doesn’t get the same job done in the very same way.
  • Portfolio items need to be gathered in a separate component below, with previews showing up, and a pop-up appearing with random X fields, editable and injectable wherever needed, whenever we decide.

Similar requests can be detrimental to ongoing development and design—especially whenever they haven’t been stated explicitly and require a major overhaul of the database design or the framework architecture laid out to date. Some of the aforementioned requirements can take 30-80 hours alone (or longer), and piling them up can prolong a project indefinitely.

An RFP is never succinct enough to provide a detailed workflow of every user story, a complete mockup ahead of time of both the front-end and back-end (agreed upon before signing the project) due to the hefty volume of work required and the limited access to key stakeholders.

proposal requirements

8. The Waterfall Methodology

As demonstrated in the CHAOS report earlier, the waterfall methodology is often inefficient when it comes to scoping and estimating time frames for a software project.

Risk management classes often cite examples of massive construction or real estate project that took years on top of an original estimate, along with some landmarks that have been developing for decades.

One popular example is the Sydney Opera House, initially estimated at $7 million and finalized at $102 million (14.5X). Having said that, architecture and construction work do indeed require solid planning that lasts for decades or centuries, and it’s more applicable in similar scenarios.

Agile development—and primarily working iteratively on software requirements over time—has been more successful in building a resilient project with fewer surprises, allowing for more time to react, regular demos, adhering to third-party requirements, and changes in the business landscape.

9. 3rd Party Dependencies

A significant overhead in delivering an RFP-quoted project are delays caused by 3rd parties.

Hosting access, assets, content drafts, copy for landing pages, demo access to 3rd party services, obtaining access to paid tools that should be purchased by the client—or even managing to receive feedback in a timely manner.

One of our latest “rush” projects we were assigned was an MVP we had to launch within 7 weeks for an entertainment company. It was a referral in need so we decided to help out.

Final design upon signing was expected within 7 days, hosting access in 10 days, and our work was planned to end in 5 weeks (following a deployment and stress testing period pre-launch, having content completed before that).

Design mockups were finalized 2 weeks before going live and hosting access provided 8 days before the event. Despite the contract violation, this was caused by third-party vendors and the deadline was fixed—related to a holiday event that happens once a year.

In similar cases, there’s no right or wrong answer. It always means that the vendor should double down and overtime to deliver on time. Otherwise, the entire project falls apart, and since the implementation is assigned to a single vendor, the public pressure falls on the agency’s side as well.

reading a proposal

10. Aesthetics

Whenever design or user interfaces are expected as a part of the project, ambiguity is bound to happen.

Assuming that the client provides some design samples or competitors in the RFP, the agency quotes a design process including mockups or wireframes to start with. Most agencies add an extra clause of a certain number of revisions allowed—say, 2 or 3.

What happens if the client is not satisfied with these objectively unique considerations of look and feel or aesthetics?

  • The overall tension grows between both parties
  • Additional revisions should be paid extra, but pointing fingers to the agency’s creative team is almost inevitable
  • Working on additional revisions takes extra time—resources may be scarce
  • Additional creative revisions may halt the development work following the designs as a starting point

Aside from the core style guide of the web project, certain visual features may cause additional surprises as well. Sliders, galleries, parallax, responsive components across different breakpoints can all raise additional questions—often depending entirely on the content plan.

What about responsive images whenever the same photo should be displayed as the landscape on desktop and portrait on mobile? Any team photos will be cluttered.

Responsive sliders? Anything could go wrong between a mobile viewport and a 4K screen.

Pricing tables? Aligning payment buttons and feature lists varies a lot depending on the content plan.

News featured boxes? Often overlapping or overflowing with long headlines.

Consider the back-end usability of all editorial areas and you’ll quickly end up discussing dozens of misalignments that haven’t been discussed on time due to the short submission time frames provided with every RFP.

RFPs

11. Blind Pitching

Reading a proposal leaves a lot to interpretation.

This is another flaw of the standard RFP process expecting vendors to send an email with their proposal until a given deadline, with no personal interaction or the ability to discuss the details of the scope on the fly as needed.

There’s a good reason why sales meetings happen on-site—or at least over the call. There’s the objections rebuttal process, aligning details in the RFP, discussing caveats together, and ensuring that both parties are on the same page.

Sending a document over begs for empty promises of a bright future and a successful project regardless of the dangers and uncertainties that the vendor is fully aware of.

larger organization proposals

12. Budget Ballparks

We covered the “race to the bottom” paradox which can be prevented with a simple hack: budget ballparks.

Stating an expected budget range serves two purposes:

  • It sets the expectations straight so that more expensive vendors don’t bother if the budget seems unrealistic
  • It allows for the right type of planning that enables the agency to fit within the budget

Each and every feature can be implemented and incorporated in multiple ways, some cheaper and some—more expensive. Ideally, the goal of the client is receiving top-quality within their budget—which is exactly why ballparks are needed.

Less experienced vendors (or those who adhere to the “LEGO” approach bundling solutions together) will naturally fit into the desirable cheap price bracket while enterprise-grade providers would normally quote for a top-tier product with the best industry practices out there. That said, there’s a 20x—100x gap price-wise between both options, and guesstimating a budget is close to impossible.

With lower prices, compromises are bound to happen. Realigning the expectations allows the vendor to explain which alternative will be achievable within the budget.

consultancy on proposals

13. Consulting is Hardly Possible

Professional agencies are worth their price for a very simple reason: experience.

I’m not referring to the ability to sketch unique designs or write high-quality code. I’m talking about achieving business objectives.

Successful vendors have a solid track record working with successful businesses. Understanding the best practices in the industry, what the target audience needs, the best 3rd party integrations or services that would simplify the job, how to automate processes for staff members, saving management time for planning and business growth.

The RFP assumes that the business knows it all. In some cases, RFPs are prepared by external consultants—and oftentimes, they don’t understand the industry well enough. And RFPs prepared in-house probably don’t understand tech well enough or what’s possible in this day and age.

Reputable agencies can navigate the space and support the business needs of the organization (on top of being able to execute them).

proposal bidding

14. Suiting Up (And How Interpretation Works)

Eventually, the collaboration process once a proposal is selected is all about guesswork and negotiations, which I prefer to call the “suit up” phase.

All the subjectivity out there is up to interpretation. And there are different phases of introducing and accepting scope creep.

Agencies bidding on fixed-fee projects always quote extra—a multiplier of 1.5x to 3x their original estimate. This assumes communication overhead and scope creep they can’t get without, complications with 3rd parties, etc.

And while minor changes may pass successfully, expensive change requests won’t. And once the interpretation process has started, it’s a matter of risk/reward for each party to decide on how much they can/should push.

Some clauses are clear in the contract itself, and either party should budge. Others, however, are subjective—and professional RFP companies are often used to negotiating as hard as they can against these.

For me, it’s the most frightening part of the process. Enterprises can afford to lawyer up and do whatever they want. Of course, this isn’t cheap either and maybe the cause of a media scandal—whereas brand recognition can be tied to stocks or employee retention.

RFPs Are Broken

The RFP process is broken

At the end of the day, the lack of a smooth collaboration and a streamlined process based on trust and ongoing work inevitably reaches contradictions and disappointment.

There’s nothing wrong with sourcing for vendors—similarly to submitting job descriptions and looking for applicants. But the RFP process itself is broken—it relies on false principles that aren’t applicable in practice, leading to an average of 80% failed projects across the board.

Instead, seek recommendations and referrals, Google for vendors, or conduct an RFP process that’s better organized and open. State budget ballparks to get a better sense of affordable features within the range. Be open to consultancy and opinions. Don’t trust blindly, but don’t gauge merely based on a salesy document.

That’s how you’ll end up with a success story—and not a horror one.

2 thoughts on “14 Reasons Why the Website RFP Process Is Really Broken

  1. I appreciate the sheer effort you’ve put into this post! It’s very useful.

    There are two, in particular, that wind me up:

    1: The pre-selected candidates – this is where someone is obliged to follow a process but when you talk to them or ask questions, they are weirdly distant, don’t answer questions and seem oddly disengaged. You do the proposal, the presentation, they whizz through it and you feel a bit used. You then hear nothing until you chase up and they tell you they selected somebody else. After a bit of digging I’ve often found that the people they eventually used turned out to be connected in some way – for example, supplying at a former employer. Nothing wrong in using someone again, but getting others to jump through expensive hoops is disrespectful.
    2: The numbers player – send the RFP to 30-40 agencies and see what comes back. Narrow it down in phases. And it doesn’t work. A customised proposal that thinks through everything mentioned in the RFP is going to be between 2 days and 10 days of work. I’ve responded to one from a current client, figuring it was pretty safe, only to discover they’d spaffed it around the country. Found good friends in the industry who’d received the proposal as well. Discovered it had gone to over 30 studios. Well, at two days of work for the proposal, that’s 60 days of studio time taken up around the country. For £50k.

    Imagine going car shopping and instead of working out a specification and doing a shortlist you just sent an RFP with a vague but sometimes oddly specific RFP. It may ask for four wheels, a comfortable ride, top quality infotainment, etc. You could get a range of prices covering a Dacia Duster to a custom built luxury car worth millions.

    What I did realise is that we need to commoditise our offerings for these. Instead of trying to cover every base I’ve simplified it down to “We can offer you this, this and this off-the-shelf solution we call Standfirst for Web. It’s based on WordPress but has these extra features. It’ll cost you £x per month, plus you’ll need to pay for design time which is charged by the hour at £x/h.”

    That way we supply a standard website with some elements of change.

    This is because the RFP/RFQ process is really designed for the purchasing of commoditised items like pencils and laptops. It’s not really designed for a creative process. It’s entirely different. To make it viable to respond, the price has to be massively inflated, or the offering carefully limited. Neither are necessarily good for the client. If they come back to us we then ‘sell’ the extras rather like a car salesman might.

    1. Yes, yes, yes!

      I couldn’t agree more and I’m always relieved to receive a confirmation from a fellow veteran in the space.

      The paradox here is: professional firms traditionally won’t bid for the aforementioned reasons. So by definition, missing out on the top tier of companies is almost guaranteed – which defeats the purpose.

      Too bad customers can’t figure this out – because they don’t know any better.

      It’s like a truly expensive version of interviewing. Except the “applicants” need loads of projects to scale and not just one in 2-4 years, and are usually not allowed to get multiple people scoping together, potentially working on mockups, conducting code review at times, only to get the first list of questions narrowed down.

Your thoughts?