The Rapid Cycle Mini-RFP

Uncategorized 3 Minutes

Like many businesses, our organization has problems to solve.  We have good people, products and processes but on occasion we decide that we need more than we have.  Our Chief Strategy Officer sometimes reminds me that my vision for our achievements might not be aligned with our capacity.  Perhaps this is the role of the CEO – to think a bit bigger than we are.  But that’s another blog post.  The point here is that we may need help sometimes.

When businesses develop strategies to solve problems, they generally adopt one of a handful of approaches:

  • Hire a person or people
  • Buy something
  • Build something
  • Try something (pilot / proof-of-concept or POC)
  • Partner with another organization

RFPs are generally reserved for big projects and evoke thoughts of 45 page .pdf documents with tens of questions and months-long processes of evaluation.

For the record, we never do POCs or pilots.  We do projects, and all projects have phases of implementation.  Phase 1 is always first, and while we can certainly kill a project at any stage, “phase 1” sends an implicit message that we’re optimistic that there will be a second phase and others thereafter.  We’re not ambivalent about moving ahead with anything.  “POC” and “pilot” send a message of ambivalence.

There’s an opportunity for organizations to use a process that’s smaller than a big RFP and bigger than a solution-focused decision.  It’s the Mini-RFP.  We’ve done a handful of these and they’ve worked incredibly well. The whole thing takes 3 weeks.

Here’s how to do it

  1. Week 1
    1. Day 1:
      1. Define your problem. This isn’t as easy as you think.  We use a modified A3 strategy approach.  You can use any approach, but be careful not to be looking for faster horses.
      2. Pick an online survey tool you like.  SurveyGizmo, Google Forms, Microsoft Forms, or Survey Monkey are all just fine.
      3. Write a set of questions that capture basic business demographics.  You can re-use these every time.  Name, URL, contact info, how long in business, etc.
      4. Write a short statement about the problem you’re trying to solve.  Work hard to make sure that it aligns with step 1 and do your best to avoid describing a product that you’ve seen that you think solves your problem.
      5. Write a set of questions that asks respondents how they would propose to solve your problem:  what do they have (people? product(s) , processes?) that solves your problem.  It’s important to avoid leading questions that align with a particular solution you may subconsciously have in mind.
      6. Show the RFP to a friend.  Ideally, give them edit rights and ideally this person doesn’t have first-hand knowledge of the problem you’re trying to solve.  They need to be able to look at this fresh with a “beginner’s mind.”  Tell them to go ahead and fix whatever they think needs fixing in the form.  No permission required.  No time (or need) for “suggested edits.”  You’ll be pleased and surprised (and humbled) to see how your initial prose made assumptions that you didn’t see.  Let your friend fix them and leave your ego behind.
      7. Add  “Brown M & M” questions.  While the rationale here is a bit different from what Van Halen did, the idea is the same.  You need to know if the respondents are paying attention and have sufficient domain knowledge.  We use these questions when we post upwork jobs and they work incredibly well to weed out folks who respond by pasting in paragraphs from other proposals.  Instant proposal rejection is what you’re looking to enable here.  Be creative here and have fun.  One recent RFP asked if BTC, XLM, ETH or neo4J had a role in the project. We asked submitters to avoid googling for an answer.  This question was asking two sets of questions:  a) How much of a nerd are you?  (We wanted nerds) – Do you know what BlockChain is?  – Do you know the difference  between cryptocurrency and a graph database? b) Do you know that blockchain probably plays no role in this project?  (But a graph database might.)  Successful respondents get the right answer in 30 seconds because they have domain knowledge.  These should be easy questions for the right people and impossible questions for the wrong ones.  (If you use the right survey tool – you can see how long they took between questions.)  This isn’t a tortoise/hare issue.  Perhaps we’ll need to have a chat with Malcom about that.  We love tortoises.
    2. Give them 3 – 4 days to reply.  We often launch on monday.  Close Friday.
  2. Week 2  Process, review, rank, have phone calls with a few of them to get a better sense of who the people are and if you are likely to work well with them.  Pick a “winner” by Friday.
  3. Week 3
    1. Monday.  Send the lead applicant a contract. Negotiate rapidly.  Lawyers may slow you down.  The more you have templated ahead of time – the better – so at least on your side, there are no legal delays.
    2. Friday.  Execute the agreement.  Go!

Published by Jacob

Published