Are you someone who has a hand in crafting Requests for Proposals (RFPs) for your company? This article is for you, and is based off of some things I’ve seen lately that compel me to make some recommendations.

NOTE: Below, I say “us” a lot. This refers to a generic company model, and not my specific current employer.

RFPs are Important!

Crafting an RFP for your proposal limits the entire universe in which vendors can respond, because part of submitting a proposal is remaining compliant with the RFP for readability and scorability. So without crafting RFPs in a way that is conscious of this, you will end up receiving proposals that will not necessarily match the best result or value for your organization, and you may be none the wiser about it.

Ways I’ve Seen RFP’s go wrong

A brief, incomplete set of examples:

• An RFP describing how we would fill an entire PMO office to do waterfall style development. Answer: We likely wouldn’t, as there’s a lot of material pointing to that sort of setup being counter-productive and not conducive to fast learning and iterating. If that’s what you’re going for, fine (though I wouldn’t recommend it) – but this RFP also described the desire for outcomes usually consistent with a more agile approach.
• An RFP describing how we “turn static assets from the requirements and design phase into aesthetically pleasing web pages”. This sets us up, again, to think in a waterfall style. If we’re assuming that a large portion of the delivery team won’t be collaborative, we have to speak to that, even though we’d recommend against it. Having user research and human-centered design inform the effort from the outset will likely be much more effective.
• Stressing the full completion of the work. One of the underlying value propositions of agile development that I strongly believe in this: in a large effort, you will run out of time and/or money. In that case, you want to ensure that the most important things have been done as soon as possible, so that you are maximizing the value of your delivery along the way. RFPs that ask us to describe how we get to “fully done” are asking us to make up magic, which is not the sort of thing we want to do. This also makes the assumption that everything we know now will be exactly the same as when we finish, but as we know, the best projects learn things along the way and pivot or adapt.
• Specifying that work needs to be local with no remote work. How will you find the best talent? How can I export the best parts of my organization and culture if remote work is already ruled out from a contractual sense? Why don’t I have the opportunity to pitch the ways in which remote work could be applied effectively and efficiently? To specify a preference is totally reasonable – jobs matter in local markets, for example – but to restrict the response in an RFP means we can’t even really discuss it.
• Giant RFPs requiring 100-person teams. The best efforts seek competent teams to orient toward a goal, learn along the way, and grow when there’s good progress. Asking for a large team points to a large objective that we think is known, and “bodies” to fill that objective. Investment-wise, it is smarter to attempt to connect with a partner who can help you learn quickly and grow along the way, and then scale. Otherwise, you’re inviting a lot of churn and organizational backlash, and I’ve yet to see a company that’s actually prepared for a transformation with full organizational buy-in.
• Requiring expertise in known outdated technologies (Flash, anyone?) By requiring us to speak to expertise in outdated technologies, you’re limiting the quality of candidates we can bring you, and are already into the solutioning space, when oftentimes the problem is partly that you haven’t moved beyond these technologies. By restricting us from assisting in re-thinking some of these steps, you’re hampering your organization before work starts.
• Wanting a consultant or partner, but specifying a contractor. Companies want the results of consultants and partnerships, while setting themselves up to employ contractors who respond to direction. RFPs that require signing off on hiring of team members, or that indicate that the vendor will be performing work always at the direction of the client, set companies up for less than ideal results. For ideal results, you should seek someone who moves you forward and teaches you as they go – a partner who will help you realize your future, not just respond to your present.
• No clear metrics for success in the RFP. I’ve seen “lack of customer complaints” defined as the only quality metric. If you don’t have metrics for success, it’s OK to ask for help defining them. If you allow the space for a company to tell you who they are rather than what they’ll do, you’ll get a sense for whether someone would be a good partner to help you come up with these metrics. Given how tricky metrics are to begin with, I suggest not requiring a respondent to speak to any specific metric.
• Mandating that certain aspects of the RFP will become part of the final product. Really? The quality metrics table in the RFP is never going to change, despite you wanting to change the way your applications are built and perceived? We’re not going to learn anything between RFP and the end of this contract? If those things aren’t 100% true, why specify that a table in the RFP will be continued all the way through a multi-year effort without allowing that things might change and evolve?
• Contracts leave very little room for learning. I wonder if we haven’t appropriately figured out the legal or contracting way to say “we’re going to set common goals, pursue them together, and learn things along the way”.

You Can’t Wordsmith Your Way Out of Risk.

“Customer collaboration over contract negotiation” is right there in the Agile Manifesto, and for good reason. Your contract writing isn’t going to save you, no matter how clever it is. Picking a partner you can trust and collaborate with is what’s going to reduce your long-term risk and lead to the best outcomes for your organization.

You learn more from an open-ended question than a multiple choice response. So, the best way to make space for a great partner to reveal themselves is to…give them the space to do so. If your RFP is so rigid that companies aren’t able to differentiate themselves, it’s much harder to know if you’ll choose the right partner for your organization. Ask them how they’ve approached similar problems. Tell them about your current challenges. Ask them to explain the “why” of their approach. Look for authenticity and clear examples. You’ll quickly spot who cares about your success and who wants to try to wave a magic buzzword wand.

You’re Hiring Someone to Raise Your Consciousness. THAT’s Your RFP.

If you’re seeking outside help, most of the time it’s because your organization has hit some sort of a wall or a plateau. If you write the RFP from the perspective of your organization’s current state of the art, you’re missing out on the opportunity for a respondent to bring you closer to their level of consciousness – which ideally is more advanced than yours. After all, that’s why you’re looking for them in the first place.

Don’t tie their hands. Make space for them to show you why they’re the right partner.

So, what would I recommend for RFPs?

• Start small. A team or two to run experiments, test hypotheses, get some initial iterations and learning underway, with the option to expand once you’ve connected and found great solid footing. Massive engagements lead to massive waste; meaningful engagements lead to meaningful results.
• Be up-front about how big you plan on going. I agree that some larger potential partners may not see a proposal for 1-2 as worthy of their time (in that case, you dodged a bullet anyway). But, to counter this, you may want to include how much you’d be looking to scale this project up, but be clear that it will be based on what you learn and not a desire to go big quickly.
• Use very few words to ask about process. If we’re operating under the assumption that the ideal partner has a deeper understanding of modern approaches and practices that compliments yours, it’s best to not ask about specific processes or tactics so that potential partners have a better change to reveal themselves.
• Use lots of words to talk about challenges and outcomes. What are you looking to achieve? Why? What challenges have you had getting there so far? What things have you tried so far that haven’t worked quite how you’ve wanted them to? This can be invaluable information for a potential partner, and they should be able to speak to how they’ll meet you on that journey and help you achieve your goals.
• Ask for respondents to question your assumptions. You will undoubtedly make assumptions; that’s only natural. I suggest explicitly asking potential partners to question those assumptions. In doing so, you’ll see which partners for an engagement are invested in deeply thinking about your challenges vs. those who’d prefer to throw some generic language at you. You’ll see who’s ready to move you forward, and who really cares about your outcomes.
• Talk about where you feel the need to be more cautious currently. Sometimes companies have certain things they’re not looking to do at a point in time, and sometimes they even have good reasons for this. State this up front. Have you been burned on an agile transformation before? Did you scale yourselves into a disastrous state? Is there a difference of opinion among different business units? A partner should be able to 1) respect this current state 2) push back a bit when warranted, and 3) speak about how they’ll meet you where they are.
• Be vulnerable. If you’re going to ask for support from an outside party, set yourself up for success by stating the outcomes you’re attempting to improve, and what you wish was better. No sense in asking for help if you don’t want to talk about what help you’re looking for.
• Make it human. Your teams aren’t robots, and neither should any companies you partner with on your journey. You’re going to work together with people. Look to see how your respondents come through as people.

…But the best tip?

Get someone you trust involved up front. Do you have training partners, former consultants former employees who’ve helped you out? Involve them in your RFP process. This is important, and it could impact your culture and your outcomes for years into the future. Pull in the people you trust and get them to advise you on the things the RFP needs to say – and more importantly, what it doesn’t need to say.

What Am I missing? What did I get Wrong?

I’d love to hear your opinions in the comments!