If your company is considering looking outside for help in development of a software project, a Request for Proposal (RFP) is probably the first step you think of to find potential vendors. That’s what best practices say to do, right(1)? The goal is to find a partner you trust who will complete the proposed project successfully, within budget, and on time. However, while RFPs are routine and seem to feel “safe”, they typically don’t answer the questions required to make sure you’re in business with the right people. Sure, you’ll find a quote, references, and promises of “guaranteed success”, but how do you tell the difference between an expert software product developer and an expert ‘RFP responder’? One will give you a great product while the other leaves you with a fancy RFP response and a dried up budget.
There are a few things RFPs are absolutely GREAT for — like basing decisions purely on price — but finding a business partner that shares your vision and passion for your software project? That’s not something a piece of paper can provide.
Another less-than-optimal result of RFP selection processes is the focus on price. You know you’ve done it too… when you get that 250-page sealed-bid response (sent in triplicate, per your RFP process) you flip right to the last page to look at the price. Sure, you’ll probably do your due diligence and read the rest of it, but the first impression is already made. And why shouldn’t you skip to the bottom line? Your RFP-creation team spent weeks crafting the specifications and requirements for your project so you can make a rational, apples-to-apples comparison. In reality, in the best case you’ve set yourself up for a classic Waterfall-managed project. Few talented dev teams work in that model, so you are setting yourself up to be working with the B-teams from the start. Why insist on industry worst-practices? To us, the more detailed the requirements, the more our warning bells go off. If we can’t work in a collaborative, agile mode with our customers, we know there will be trouble. Some of our math-geek engineers like to say that requirements are sort of like fractals: the more you have, the more hidden ones there are once you start looking deeper.
Unfortunately, a lot of companies are doing this day after day and in the end, are left sitting around a boardroom table (after hundreds of thousands of dollars have been wasted) wondering why yet another project has failed.
At this point, you’re probably wondering, “Ok, then how DO I find the right vendor to help us with our software product?”
Our answer: look for vendors who want to engage and solve your software problem.
Does the potential vendor understand the scope of the project? Do they utilize one single technology, or are they experts in a vast array of technologies, frameworks, application tools, and platforms? Are the developers enthusiastic about solving your problems? Do they have unique takes on solutions that you never even thought of? There are many questions that can’t be answered inside of most by-the-book RFP processes.
Here’s an alternative to the RFP process:
- Seek referrals from your network (LinkedIn.com, coworkers, outside industry groups).
- Research online — not just a quick Google search. Read forums, company reviews, etc.
- Schedule conversations with the potential vendors you find. Be honest. Share what you are looking for (the vision of the project), what your budget is, and overall expectations.
- Narrow the group to a few preferred vendors and schedule in-person meetings (one meeting may suffice or, depending on the project, you might need multiple meetings with a vendor to make a decision). We’ve found that the best agenda for these meetings is a mix of presentation and conversation (from both sides). It’s important for all project stakeholders be involved and meet with the potential vendors.
- After the meeting(s), get all of the stakeholders together in a room, toss out your 1-10 scales and vendor qualification checklists, and just talk it out. There will be some dissenting opinions, but a quick consensus will form.
- If there are still some unanswered questions, just talk to your top choices again. Why not? You don’t have a strict RFP process you’re required to follow, so just do what makes sense.
This may seem like a lot of work, but investing the time to research on the front end pays off in the successful and more efficient project on the back end. Usually, it’s a net time saver for you since you were able to focus on the important things in your project and not in writing (and reading) hundreds of pages of documents. Not only will you find a vendor capable of delivering the product your company needs for this project, but hopefully a trusted partner so you don’t even have to think about a RFP for your next project.
So go ahead, ditch the RFP, and get to work!
Footnotes:
- Like all those successful, large government projects you always hear about.
- We are odd in that our developers always contribute to the agreements we present to our customers. That’s the only way for the team to buy into customer success for the project. Plus, it builds character.
