When you should NOT issue RFPs for software development
by Nicolas Jacobeus, on 11 October 2017
The development of a new piece of software is a risky project, full of uncertainties. Requests for proposals (RFPs) are an attempt to limit these uncertainties.
In an RFP, a business usually attempts to detail what they want and then asks several development agencies to say how much it will cost to produce. Sounds great, right? But if your company is considering a software development project to bring innovation to market, listen: Don’t do it.
The RFP process is broken.
Let me tell you why this process doesn’t work and what you can do instead. You’ll learn how to shave off costs and find the right partner for your critical projects quickly.
9 problems with the RFP process
1) Specifications are usually ambiguous at the RFP stage...
As a client, you are not supposed to be an expert in software, or you wouldn’t ask an agency for help. This also means you don’t know how to properly describe your project in a way that is precise enough for a developer to code it just like you want it. This makes it impossible for the developer to provide an exact cost, because part of the estimation depends on how you will fill the gaps left by these ambiguities during development. The project will never be 100% in their hands and thus neither will the costs.
2) … And specifying features in detail is useless at this stage anyway
The same way you shouldn’t focus on last-mile directions when planning a long trip, you shouldn’t focus on details (e.g., what fields will go in the signup form, or what edge cases you want handled) at the collaboration planning stage. These will come as the project progresses. Yet a precise price bid requires precise specifications, drawing attention away from the things you really need to be thinking on at the start of a project.
3) Tunnel vision: RFPs limit creative thinking
RFPs focus on features, not goals. By writing an RFP, you are already limiting the result to your own view of what a solution could be, when what you actually need is your problem solved. As a project owner, you usually can't see the forest for the trees because you are way too involved in it.
That’s where having external, out-of-the-box ideas is useful: the partner agency has a passion for software development and experience working on many different projects. RFPs limit creative discussions and potentially useful ideas upfront.
4) RFPs help you find good sales people, not good product teams
Proposals tell you how good an agency is at writing a proposal, not how good they are at delivering the results you need. The process doesn’t encourage you to enter discussions with the team that is going to deliver your product.
5) A piece of software is a living thing - but RFPs demand a static view
An RFP describes your vision at a moment in time. Your vision will evolve. You're not a psychic; the agency isn’t either. It is impossible to predict how your needs will evolve as the product is built, and it’s also impossible to predict how you will interact with the agency if you’ve never worked together before.
6) RFPs produce a high collaboration risk
The RFP process will result in a commitment to collaborate with someone you don’t know yet. As with any new partnership, things can go wrong, and a long-term contract will make it difficult for you to try and start over again with a different team. For a startup, that lost time can be fatal.
7) Focus on price - missing out on other important factors
Proposals usually focus on the price. And we’ve already shown how this just can’t be 100% known at the RFP stage. What you really need is a guarantee of a good fit: knowing whether an agency’s methodology makes sense (i.e. how they will help you reach your goals), and whether they are capable (testimonials and past work).
8) Requiring a proposal may inflate costs in the end
If you took the time to write a 30-page RFP, you’ll want to send it to as many agencies as possible. Only one will win the bid. All the others would have been better off spending their time adding value to their existing customers. You might say it’s their problem, but agencies who reply to RFPs usually reflect that opportunity cost in their fees - if not in the RFP then later down the road.
9) RFPs exclude agencies that focus on clients first
Consider this: Belighted decided a while ago not to answer RFPs anymore. We wanted to be sure we always put our efforts first into our clients’ work. Our new business pipeline has continued to thrive even without RFPs. Would you really want to exclude potential partners who do not rely on the broken RFP process but rather focus efforts on helping their clients succeed?
The solution - a faster way to find the right partner
I suggest you replace the painful RFP process with three simple steps:
- Instead of writing a long RFP focused on the features you need, write a short document describing:
- The problem you are trying to solve
- Your high-level goals
- Your budget
- The success criteria
Then start conversations with potential partners immediately.
- Don't confine your selection criteria to a mere document. Choose a partner based on their:
- And last but not least - how you feel when interacting with them.
- Start working with your chosen agency on a short assignment to ensure you are a good fit. A good way to do this, especially for startups, is a scoping workshop, or a design sprint, which will help you make tremendous progress in a very short amount of time - and help you test how you work together with little investment upfront.