Is your RFP the right move?

Recently, I’ve spent a fair bit of time thinking and reading about RFPs, specifically in the software space.

Initially, I intended to detail my thoughts on common shortcomings and risks involved in the process, but then I realised I didn’t really have any novel thoughts on the matter, and I probably wouldn’t bother reading what I’d written myself.

That being said, I realised that simply considering RFPs in the software space raised an immediate red flag in my head. Why is this? After some thinking I concluded that the red flag is a heuristic I’ve developed, relating to how people approach software.

To illustrate my thinking we need to ask:

Why do people issue software RFPs?

Primarily because they’re taking on a project which is outside of their skillset or core focus (I’m assuming we exclude governments here — as they put most things out to tender considering their core focus is, well, governance).

While this might seem like an obvious and innocuous point, it does imply that one’s core focus is separate from, or at least separable from, the software itself.

And this is problematic, since most businesses are increasingly ‘digital’ and software-driven. And now with the Covid-19 pandemic, we’re only seeing this trend get stronger.

{Sidenote: It’s already been almost a decade since Mark Andreessen wrote his seminal essay titled “Why Software Is Eating the World”, so this should really be old news}

In addition to this, the portion of value generated, or ‘captured’, in many industries’ value chains which is software-based, is increasing (and has been for some time).

While at times this can result in a total gain to customers in terms of utility or value delivered, in many markets, a larger portion of consumers’ spend is soaked up by software providers — and in many cases large scale ‘aggregators’ — leaving non-software focused businesses with a progressively smaller piece of the potential pie (or upside).

As a potent and topical example: Netflix now pays more up-front for content production, while taking more upside previously attributable to production companies.

This is a very real trend and I’d be willing to bet we’re going to continue to see this ‘erosion of profitability’ due to software in many places (in a similar way this also applies to wages — but that is an entirely different kettle of fish).

Given these trends:

My concerns with software RFPs revolve around tendencies toward

1. Unrealistic assumptions or expectations of their being a state of ‘done’ or ‘complete’ with regard to a proposed solution. This is very rarely the case in software, especially when providing services via the internet and can often be evidenced by an emphasis on support over continued feature development.
2. Assuming that the ‘problem’ a project aims to solve and the ‘solution’ the project aims to provide have been (i) correctly identified and (ii) aren’t liable to change over time. These are dangerous assumptions.
3. Underestimating the importance of building internal capabilities and/or strategic relationships on the tech front.
4. Underestimating the competitiveness of the tech space and the complexity involved in building software.
5. Underestimating the time and investment it takes to deliver world class software — to which users have become accustomed owing to the many products they use daily which have multi-million dollar budgets for development.

In addition to this, RFPs usually involve a fair bit of work for vendors that:

• many technically minded individuals don’t particularly enjoy, and
• is generally ‘at risk’ work, considering you’re never guaranteed of winning.

As a result of this, it’s possible that because the RFP process itself is cumbersome and onerous, you inadvertently filter out many good candidate vendors. After all, the process doesn’t only act to get vendors to sell themselves; the opposite is also true. An RFP in itself needs to sell the project to vendors. A lot of the time, they do a very poor job on that front.

In sum, I’m not saying that RFPs aren’t ever useful or appropriate. They can be. It’s just that it’s important to keep asking ourselves why, and whether an RFP is the right option for your business. When you’re going down this route, have you considered the broader and implied strategic implications?

Thanks for reading.

At NONA, we prefer building long-term relationships over ‘won and done’ projects, helping clients build internal teams over extended support contracts, and collaboratively prototyping solutions over inflexible prescriptive specifications.

If you’re considering undertaking a software project or issuing an RFP for which you have reservations or uncertainties, get in touch — we’d love to help.