Request-for-Information Tool: Discovery, MVP Scope, Pilot and Rollout Plan

You have been asked to launch a Request for Information (RFI) tool. Walk through how you would plan its development and its launch. ```hint Follow the RFI from start to finish Map who sends an RFI, who answers it and what happens to the answers afterwards. The step in that chain that wastes the most time tells you what the first release has to do well. ``` ### Clarifying Questions - Who uses the tool: a procurement team sending RFIs to potential suppliers, a team answering RFIs it receives, or project teams such as construction, where an RFI asks the designer to clarify a drawing? - Is it for the firm's own teams, or a product to be offered to clients? - What does it replace today: email and spreadsheet templates, or an existing sourcing system? - Is there a fixed launch date, or a first team or client already committed to using it? ### What a Strong Answer Covers - A clear choice of RFI context and users (issuers, respondents, reviewers) and the workflow pain the tool removes - Discovery and validation of the problem before building, with baselines to measure against - An MVP scope with a phased plan, the reasoning for the cut line, and the build-or-buy decision - A pilot and rollout plan covering adoption, training, process change and onboarding of the people who answer RFIs - Success metrics with guardrails, and the main risks such as confidentiality and users drifting back to old tools ### Follow-up Questions - Pilot users keep exporting responses to spreadsheets to compare them. What do you do? - Where would you use generative AI in this tool, and where would you keep a person in the loop? - Response rates from the people answering RFIs fall after launch. How do you find out why?