Table XI

How to write an RFP — don’t

We get asked about the RFP process and how to write an RFP all the time by companies that are just starting to think about building or redesigning a product. They want to know what to include and how they can attract a star development shop to submit a response.

Easy: Nothing, and you can’t. If you want to find the right development shop, an RFP won’t help you. In fact, writing an RFP could cripple your project before it gets started. Here’s how, and what you should use instead of an RFP ...

Why we don’t respond to RFPs

At Table XI, we don’t just crank out projects for our clients, we partner with them to build technology solutions. We’re in it for the long haul. So starting with an RFP document that skips over strategy just doesn’t make sense. RFPs lay out the what and the how. But to get results that will really transform your business, you want to focus on the why. We’ve written before about why RFPs are bad for business, but consider this analogy: If you come to a contractor wanting a house, you don’t ask for two tons of bricks, some wood and some shingles. Instead, you tell them what you need the house to do and how you want it to make you feel — the why. In the first example, you end up with a prison because you forgot to mention windows in the RFP. In the second example, you tap the expertise of the contractor to co-create the home of your dreams.

When you define the project with an RFP, you’re asking your service provider to check half their brain at the door, and you’re missing out on the higher-level problem solving they can bring to the table. By discussing the why, rather than assigning the what and how, you let development shops bring all their experience and expertise to bear, instead of asking them to shed value in order to fit into a predefined box.

The one question your dev shop needs to answer

The biggest flaw of an RFP is that it skips right over the real questions to ask, focusing instead on timetables and costs. To find the right dev shop, you need to ask about the thing keeping you up at night — risk. Risk is the most important factor for your business, so it should be the most important factor for your service provider as well. If you don't have someone who's mature enough to start quantifying projects in risk, measuring one approach versus the other, then you're talking with the wrong person.

Instead of thinking about an entire project, structure things around outcomes and risks. What problem are you trying to solve, and what's the lowest risk path to get there? When you quantify things that way, the end result is far better because you're engaging your service provider’s creativity to solve a problem. It also makes it much easier to compare bids and find the best one. When you’re controlling the outcome, you’re comparing the different routes different shops take to get there, and the level of risk inherent in each one.

Let’s go back to the house metaphor. This time you’re looking for a new roof, so you put out an RFP calling for shingle replacement. Two bids come in around the same price, and one comes in at twice that. In a traditional RFP process, you toss the most expensive bid and flip a coin between the other two.

Here’s what you miss. That third bid is focused on the outcome of a warm and dry house — the why. That roofer was enough of an expert to see that there is a leak which can’t be repaired by replacing the shingles. So she prepared a bid that achieved your desired outcome with the least amount of risk. It may cost more to rip the roof off, fix the leak, and replace it, but it’s the only way you’ll get what you need. A great service provider will be able to tell you what the risk is in the quote process, because they will have the experience to see it early on.

What you should use instead of an RFP

Software development, as compared with say, civil engineering, can still be the Wild West when it comes to standards and repeatability. So even though RFPs are out, it’s important to have an alternative way to get the information needed to compare shops and find one with the experience and creative talent required to hit your business goals.

Instead of an RFP, consider a structured request for information, or RFI, to collect relevant details from a broad set of prospective service providers. Figure out which ones fit your broadest needs, and start having conversations with them, in person if you can. Ask for relevant portfolio examples, but also ask for a full customer list, so you can reach out to the businesses that haven’t been handpicked as references.

One thing you shouldn’t worry about: Whether the dev shop is using the right technology for your business. All you need to know is whether the tech is common enough that you’ll be easily able to hire another shop or developer who is familiar with it. To do your due diligence, grab the technologies mentioned by the provider, then, go to Indeed.com and search for job positions that have those skills in them. It will show a really nice graph with how many positions are available, so you’ll know right away whether that skill is in demand and supporting a talent pool.

Once you’ve found a team that you like, consider starting out with a small project — and a small amount of dollars. It will give you a better feel for whether you can work with them, if they follow through, what their process is like, etc. If you like how things are going, build on that relationship by continuing on to the second phase of the project. With an agile process, you can meet with the dev shop after every phase to assess how things are working and evaluate whether you should continue.

Some projects are difficult to break down into bite-size chunks. That’s why Table XI created the inception process, which takes you through a structured planning exercise that ends with a project roadmap as a deliverable. If you don’t have a small piece of work to test out a potential partner, have them go through a project kickoff like our inception process, or have them assess the current state of your product or site. It may seem like a lot of money to spend on work you may not be able to use, but consider it a recruitment cost. Just as you might pay an executive search firm to find you the perfect CTO, it’s worth spending a little money to test out a shop. That way you don’t end up committing your entire annual tech budget to a team who may not be able to execute.

If you must — how to write an RFP

There are so many reasons to avoid RFPs, but we know not everyone has a choice. Government agencies are required to use them, and many others are forced to by bosses who don’t quite get it. If you find yourself stuck writing one, skip the templates and examples that are out there and do yourself a favor by bringing in a technical consultant who can help you shape the RFP so you can still get the most out of the service provider you eventually choose. A consulting CTO can also help you filter out the bunk proposals, so you don’t spend time assessing shops that can’t deliver.

You can still center your RFP around the big question — risk. Ask for an assessment of risk and a risk-management plan, and throw out any responses that don’t have it. Then think about breaking the project down into phases, so you have a chance to cut a dev shop that’s not performing after each phase with minimal interruption to the work. Doing this will also keep it closer to an agile process, where your team is constantly assessing risk and adapting to new information. That way you’re not getting exactly what you asked for a year ago, which by now is hopelessly out of date and misaligned with your business goals. You want to work with a shop that can make adjustments along the way, so you’re always solving the why, not following the what and how.

Want to learn more about finding and working with a technology partner? Contact us today.