Most RFPs are inventories. Hundreds of “the system shall” rows, harvested from the current system and whatever the incumbent vendor already does. They are easy to write and nearly impossible to evaluate, because every proponent can tick every box and nobody has said what the organization is actually trying to become.
When a provincial Crown insurer launched a multi-year transformation to become a high-performing, customer-centric digital insurer, the RFP workstream started somewhere else: with outcomes.
Six business areas, one question
We co-facilitated sessions with product management, underwriting, claims, customer operations, the broker channel, and the public auto fund. The question in each room was the same. What does good look like for you in five years, and what data would you need to know you had arrived? Outcomes and data needs were captured together, on purpose, because an outcome without a measure is a slogan.
To keep six areas speaking one language, we took an industry business capabilities framework and tailored it with the business relationship managers until it described this insurer rather than a generic one. Capabilities became the spine the RFP hung on: every requirement traced to a capability, every capability to an outcome.
Journeys and personas kept it human
Capability maps are abstract. To keep design decisions honest, we built user journey maps and personas for the roles that would live in the new platform: the adjuster on a hail claim, the broker quoting at a counter, the underwriter reviewing an exception. When a requirement debate stalled, the persona settled it. Would this help the broker at the counter, or only the person who wrote the row?
The requirements nobody volunteers
Enterprise-wide non-functional requirements are where transformations quietly fail. I led sessions with security, privacy, audit, IT infrastructure, and corporate standards leadership to elicit, document, and validate them, together, in one set. Privacy and security requirements written by separate teams contradict each other; written in the same room, they reconcile. The content management strategy was defined the same way, including a plain list of where we would deviate from organizational and records management standards and why.
Every requirement lived in Azure DevOps as a backlog item, prioritized, so that when five vendors later asked for clarification we could answer from one source instead of five email threads.
Designing the evaluation before the responses arrived
An RFP is only as defensible as its evaluation. We defined a RACI for everyone involved: meeting leads, evaluation leads, evaluation teams, observers. With procurement, we agreed a process for triaging non-compliant responses before anyone had seen one, so the rule could not be accused of targeting a proponent. After award, I wrote the proponent debriefs from the evaluators’ own feedback, which is uncomfortable to do well and is exactly what keeps a Crown procurement out of trouble.
Why it held up
The RFP described a destination and asked proponents how they would get the organization there. Because every line traced back through capability to outcome, the evaluation could weigh what mattered instead of counting ticks, and when a proponent disputed a score, the trace was the answer.
The lesson has followed me into every procurement since. Requirements are the middle of the chain. Start at the outcome, end at the test, and the middle writes itself.