Process Overview

Agile RFP

  1. Invitation to Tender (AKA Request for Tender) is posted privately or publicly, with a prioritized Epic Backlog asking for well-qualified vendors to respond.
  2. Respondents are selected by the customer to attend joint Epic Backlog Refinement, where all respondents ask clarifying questions, and Epics are refined based on the customer’s needs.
  3. Respondents are given a reasonable deadline to further refine their own copies of the final Epic Backlog, and respond separately and privately with their fully-refined backlogs, Spikes, and their proposed Agile Contract, using Sprint Length, Sprint Cost, Number of Sprints Paid Upfront, and the Minimum Velocity to compete against other respondents.
  4. After any negotiations between the customer and the respondent on the Agile Contract Terms, the customer selects a respondent (now Vendor), and work begins.

Notes on Joint Epic Refinement:

During joint Epic Backlog Refinement, there will be the highest density of capable solution providers in the room that the customer will likely ever have. Use that audience to:

  • Ask open-ended questions to help break down problems into a smaller subsets with portions that can be deprioritized, so the vendor can focus on delivering the most important value first.
  • Clarify and identify other problems for resolution up front that will help mitigate or clarify overall risk early on.
  • Create a healthy competition/marketplace of ideas, without the competition of sales tactics. This is difficult.
  • Hear it all, understand they’re all trying to sell you something (and ultimately out-sell each other), but use that audience to educate your team. Listen well, but retain healthy skepticism.
  • Listen and consider the smart, “dumb” questions: “Have you considered NOT requiring a blockchain for this solution?”
  • Start weeding out unqualified respondents; they’ll be asking the dumb, “dumb” questions.

Have an experienced, strong, vocal facilitator run the refinement meeting to keep it focused on the problem statements, and clarity around the problems. Stay far away from potential solutions. As with rounds of traditional RFP Q&A, this can digress into inter-vendor solutioning/chest thumping very quickly if not expertly steered. “Unlike our competitor here across the table, who buggered this up for a similar customer such as yourselves, WE are much better…”

Classic RFP

  1. Invitation to Tender (AKA Request for Tender) is posted privately or publicly, with a high-level list of problems/requirements to be solved, asking for well-qualified vendors to respond.
  2. Respondents are selected by the customer to Request for Proposal.
  3. Respondents are given a period of time to gather resources and develop a plan.
  4. The customer may host one or more Q&A sessions where respondents may ask clarifying questions about potential solutions, in front of each other, often resulting in fierce rewriting of initial proposals, and the addition/ambush of new requirements by the customer.
  5. Respondents provide their proposed interpretation of the solution, for an amount of money, on a specific schedule, structured in one of the classic contract types.
  6. The customer selects a respondent based on the skills and expertise the vendor promises they have available (often incorporating workers’ resumes), the duration and costs involved, under the contract type that mitigates risk best for that particular delivery. These are the primary selection controls.

Loading