Do RFPs Actually Lead to the Right Software Partner?

First, a bit of good news: This isn’t another article painting solicited proposals as a terrible bit of business. They’re a wholly unavoidable reality — through things like organizational policy and legislation — and it’s counterproductive to pretend that they can be skipped.

Running candidates through the RFP process is a popular way to mitigate risk. Risk from things like software projects, with their hefty investment of time and money and a tendency to trigger a company’s requirement to seek multiple bids. Here, RFPs come with the promise of choice, guaranteed scope, and upfront pricing.

In practice, the exercise is rife with missteps, pain points, and malicious goals. Enough trouble to produce outspoken detractors and generate all of those opinion pieces you may have stumbled across already. Rather than make an argument against RFPs (remember, they’re not going away), we’ll instead zero in on the drawbacks they introduce for a software build. Knowledge is power, after all, and RFP best practices are typically forged through experiencing their failings.

Prescribing the Solution

We can’t use prescribing in this section’s title without trotting out a doctor analogy. Delivering a concrete set of requirements to a firm is a lot like heading to a doctor’s appointment and asking about the price of a specific prescription to fix a self-diagnosis.

Imagine you’ve injured your foot, and research says crutches are a solid way to reduce pain while walking. Making “buy crutches” the passing criteria for a specialist visit ignores that physician’s expertise, and potentially misses out on a better suited solution. A crutch may come after a cast.

Starting with an outline of needs is useful. Treating a pre-engagement list of requirements as law, though, introduces a host of issues:

• Six months in, it’ll be obvious which items have too much or too little detail.
• Tasks assembled by committee never represent the wishes of everyone.
• The prevailing software vendor should be part of that committee, if only to steer needs away from overengineering.

“But we are a doctor technology company too, of course we can write up our own requirements,” is a common refrain. If anything, knowing too much about the problem makes an outside set of eyes even more useful for pushing through internal biases, suggesting sweeping changes, and seeing the whole for the sum of its parts.

Setting the Right Technology Stack

Prescribing the technology stack — servers, languages, frameworks — mirrors most of the same concerns as picking a solution ahead of time. Carrying the technical debt and sunk costs from other platforms in the organization into new builds may be unavoidable (or mandated by IT), but the best suited foundation tends to change from project to project.

At a minimum, like those requirements, the vendor of choice should be part of the discussion to make technology decisions.

Pricing Too Far Into the Future

From invitations to presentations to awarding the project, an RFP is an arduous process for all parties. That time and effort incentivizes a bloated ask.

It’s not a minimum viable product, it’s several phases worth of features. It’s not delivery of a scope, it’s launch, training, several years of maintenance, and establishing a call center for customer support. The prevailing logic seems to revolve around stuffing as much output into one contract as possible.

As you can probably guess, front-loading requirements introduces new concerns:

• Different vendors may be better suited for different phases. One company may excel at putting together a platform from scratch, but lack the staff to competitively price maintenance.
• The right solution is a moving target, and the biggest feature priority six months down the line isn’t on anyone’s radar today.
• With a large enough budget pool, changes and rework seep in. Limits force hard conversations, but greatly reduce the risk of waking up one day and wondering why so little work has been completed for so much money.

Short, focused phases tend to serve software better. It’s a process that endlessly weighs pros and cons. Coincidentally, smaller phases often dip the total spend below the point where multiple bids are necessary.

One-Sided Evaluation

One award, multiple contestants. By setting up a contract as a prize to be won, the scales are tipped towards the purchaser. Show us the best version of what we expect, and you’ll be bestowed with the chance to make it for us.

As in hiring, the best relationships are formed with evaluation in both directions. The process isn’t about buying a new piece of software — it’s about selecting an experienced partner to challenge assumptions, refine a plan, and execute against timeframes, budgets, and feedback.

Picking an engaged firm that believes in the end result relies on room for candidates to push back, affect change, and really assess if the project is a right fit for their expertise.

Disqualifying Expert Firms

As mentioned earlier, quite a bit of work goes into both sides of an RFP. That effort may immediately disqualify a number of right-fit vendors, especially when:

• The ask for documentation or presentation materials is too high for a smaller company to realistically produce.
• The pool of potential firms is too large, diluting the possibility of being selected.
• Submission requirements include portions of the work to be done (wireframes, mockups), forcing speculative work and free advice.
• The company simply avoids RFPs altogether.

Providers that can answer your RFP and providers that are the perfect fit for the work at hand may not overlap. Sometimes, tweaks to the criteria can fix it. Other times, expectations will have to change as part of the mandated bid policy.

If nothing else, the process can be improved through:

• Limiting the number of (vetted) firms.
• Only including those with a realistic chance.
• Requiring just enough information to make a selection.

Comparing Apples and Orange Blossoms

No two responses are the same, and they’re fiendishly hard to compare. One firm may place more emphasis on user experience and design; another may go all in on scale and ease of future iteration. Value and the level of quality across multiple phases of work won’t line up from company to company.

Scoring against rubrics is a start, but insights come from asking why and doing some introspection. Why do they want to focus on user experience? Does that align with what we’ve heard from prospective users? Will future phases of iteration begin immediately after delivery?

A deep dive into the motivations behind a response is time-consuming. As we hit on in the previous section, though, the goal is to limit the number of participants to allow for these lines of questioning. They prove far more valuable than running more firms through a mute scoresheet.

By Request

It’s often painful to see the fruits of the RFP process: Hostile interfaces, bloated budgets, wavering accountability, and ultimately something that doesn’t live up to the need of the user.

RFPs are an unskippable step in the playbook of many organizations, enterprises, and governments, but their methods are in conflict with the principles of solid software development. To bridge the two realities, managers need an understanding of the weak spots, and the ability to tune the process to keep them in check.

To have your best chance at success, vet firms ahead of time, give them room to evaluate you, limit the pool, and — above all — seek to include their expertise as part of it all.