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.
