Running a Data Governance Tool RFP: How We Actually Scored TCO

Every data governance tool comparison article has the same shape: a grid of checkmarks, a paragraph on "unified metadata," a verdict on which vendor wins. I've read a lot of them while running actual RFPs, and none of them are useful for the job that's actually in front of you — which isn't picking a winner, it's building a decision that survives an SVP readout and holds up three years into a multi-year contract. I've led that process end-to-end for a large health services enterprise: multi-year roadmap, full TCO/cost-benefit/IRR/ROI modeling, capability evaluation tooling, and SVP-level funding readouts. I've also run the earlier, uglier version of it — screening 20+ vendors down to a shortlist — for a large retailer's omnichannel platform selection. Here's the buyer-side mechanics nobody puts in the comparison grid.

Weight the Scorecard Before Anyone Sees a Demo

The single biggest failure mode in a governance tool RFP is letting the vendors set the criteria. It happens by default, not by intent: you bring three vendors in, each runs a polished 90-minute demo, and by the third one your evaluation team is scoring based on "which one felt best" — which is really "which one choreographed their demo around whatever we happened to ask about."

The fix is mechanical, not aspirational: run scorecard-weighting workshops before a single vendor is in the room. Pull stewardship, architecture, security, and finance into a working session and force a ranked, weighted list of capability categories — metadata management depth, active policy enforcement (not just a passive catalog), lineage granularity, integration breadth with your existing platform, deployment model, roadmap alignment with where your data estate is actually headed. Every stakeholder group carries a different implicit weighting in their head. The workshop is where you make it explicit and get sign-off on it before it gets contaminated by "wow, did you see that dashboard."

On the health services roadmap I led, that weighting document wasn't a formality — it was the artifact SVP stakeholders pointed back to months later when a vendor's account team pushed back on a scoring outcome. "This is the rubric your own team built in week one, before we saw a single demo" is a far stronger position to defend than "we liked vendor A's UI more."

TCO Is Not the License Line

The number on the vendor's quote is the least interesting number in the deal. Publicly reported pricing gives you a sense of scale: Collibra's base license is commonly reported around $170K/year, with total first-year cost of ownership landing in the $570K–$1.2M range once everything else is added. Alation's base license is reported in a similar order of magnitude, around $198K/year, with a typical payback period cited around 25 months. Those are useful anchors — and they're also the floor, not the ceiling, of what the deal actually costs.

Steward time is the one that gets buried most often. A catalog or governance platform doesn't govern itself — someone has to certify data assets, resolve policy exceptions, and maintain lineage annotations. If that's your existing stewardship team's time, it's a real labor cost with a real opportunity cost, and it belongs in the model at a fully-loaded rate, not treated as a rounding error because no invoice gets cut for it. I wrote more about what that steward workload actually looks like in the first ninety days of a rollout in the month-3 stewardship post — the RFP is where you should be sizing that workload, not discovering it after go-live.

IRR/ROI Framing That Gets SVP Funding

A license comparison doesn't get a multi-million-dollar budget approved. A financial model does. The structure that worked for the health services roadmap: build a 3–5 year cash flow with cost streams (license, services, integration, incremental headcount) against benefit streams (steward-hours reclaimed from manual lineage tracing, incident and remediation cost avoidance from caught policy violations, faster time-to-trusted-data for analytics teams who currently wait on tribal knowledge). Discount both, compute IRR and payback period, and — critically — show the sensitivity range, not a single point estimate. An SVP who's been burned by an optimistic business case before will trust a number with an honest range around it more than a number that looks too clean.

The readout format matters as much as the math: lead with the funding ask and the payback horizon, put the model in an appendix, and be ready to walk through what breaks the case (adoption lagging, steward hours not materializing, integration scope growing). That target operating model — who owns stewardship, how governance sits inside a SAFe delivery cadence, what "done" looks like for a policy rule — has to be sketched at the same altitude as the financials, or the funding conversation turns into an implementation-details conversation, which is a different meeting with a different owner.

The 20-Vendor Screen: Cutting to 5, Then 2

You cannot demo 20 vendors. You shouldn't try. The retail omnichannel platform evaluation I ran started with 20+ vendor responses, and the only way through it without burning a quarter was a paper screen before any live session got scheduled.

The paper screen scores each vendor on two axes: capability fit (does it do what your stewardship and policy model actually needs) and architecture fit (does it deploy the way your platform requires — cloud model, API surface, how it sits next to the rest of your data stack). A vendor can be excellent on capability and dead on arrival on architecture, or vice versa, and you want that visible before you invest a demo slot. That screen alone typically cuts 20 to 5 without a single meeting.

From there, the 5 get scripted demos — meaning you supply the scenario, not the vendor. Ask each vendor to walk the same policy-enforcement scenario using your data model, not their canned dataset. Score against the rubric from the weighting workshop, in the room, before the next vendor's demo starts. That's what narrows 5 to the 2 that earn a full TCO build and reference calls.

Catalog-tool selection follows the same shape at smaller scale. When I directed the tool selection and implementation of Alation as the enterprise data catalog at an agriscience company, Alation, Collibra, and Microsoft Purview were the natural shortlist archetypes — active metadata catalog, governance-first platform, and cloud-native catalog tied to a specific hyperscaler, respectively. The point of the screen wasn't to crown a category winner in the abstract; it was to figure out which archetype matched the architecture we actually had and the stewardship model we were capable of running, which is a different question than "which one has more logos on its website."

Where RFPs Go Wrong

Three failure modes show up over and over, and none of them are about picking the "wrong" vendor:

• Demo theater. A live demo run on the vendor's clean, curated dataset tells you almost nothing about how the tool handles your messy metadata. Insist on your scenario, your data shape, before the session.
• Reference-call theater. The three references a vendor hands you are their three happiest customers. Ask for a reference in a comparable industry and comparable scale, and ask that reference what they'd do differently — not whether they're happy.
• Scoring after the decision. The most common dysfunction I've seen: someone senior already has a preferred vendor before the RFP starts, and the scorecard gets built (or quietly re-weighted) to justify a decision that was made in a hallway conversation. A pre-demo weighting workshop with cross-functional sign-off is the single best defense against this, because re-weighting after the fact is visible and has to be explained.

None of this is exotic. It's mostly discipline about sequencing — weight before you see, screen before you demo, model before you fund — applied consistently enough that the process itself becomes the evidence the decision was sound. Two adjacent problems worth flagging for later: how governance tooling extends to newer surface area like AI agents reading from your catalog, and how catalog grants actually map to a real access model once you've picked a platform.

The scorecard, the TCO model, and the funding readout aren't paperwork around the real decision — they are the decision. Build them in the wrong order and the tool you end up with says more about your internal politics than your data architecture.

What Would Make This Wrong

• If you already have significant sunk investment in an incumbent platform, TCO has to account for switching costs — data migration, re-training, dual-running periods — that can dwarf the delta between the finalists. This framework assumes something closer to a green-field selection.
• Steward-time-as-labor-cost only works if your organization actually tracks steward hours. If nobody's tracking it today, that line item in the model is an estimate dressed up as a fact — flag it as such in the readout.
• Public pricing anchors move and vary by negotiated discount, region, and module bundling. Treat the numbers here as directional scale-setting, not a quote — validate against your own RFP responses before they go in a funding deck.
• The workshop-heavy, multi-stage process described here assumes a deal large enough to justify the overhead. Below a certain contract size, a lighter-weight version of the same sequencing (weight, then screen, then demo) still applies, just compressed.

Related reading: Data Stewardship Rollout: What Month 3 Actually Looks Like · From Unity Catalog Grants to Real ABAC · Governing AI Agents' Data Access