Review this stewardship design. Every one of 1,200 tables has a named steward drawn from the business. Stewards approve access requests, maintain descriptions in the catalogue and attend a monthly forum. After a year, 30% of descriptions are filled in, access approvals take nine days and the forum has six regular attendees. What would you change and what would you keep?

What is actually required

Three separable things got bundled into one role: deciding who may use data, explaining what data means, and being accountable for its quality. They need different people, run at different rates, and only one of them is urgent.

The access approval is the only part with a queue and a service expectation. It is nine days because it is attached to a volunteer role with no allocated time.

What I would remove, and why it is safe to

• Steward approval for routine access. Replace it with pre-approved roles and standing grants for the 80% of requests that are routine — an analyst in the team that owns the data, reading non-sensitive columns. Route only sensitive-data and cross-domain requests to a human. The nine days collapses because the queue mostly empties, and the review effort lands where the decision is genuinely a judgement.
• Stewards for all 1,200 tables. Steward the 100 that are used. Usage telemetry gives the list in an afternoon. Naming a steward for a table nobody queries manufactures an obligation that will not be met and devalues the ones that should be.
• The monthly forum in its current form. Six attendees is the honest signal. Replace it with a short written change log and a quarterly session on decisions that actually need discussion.

The one change that matters

Attach stewardship to a consequence. Descriptions get written when the catalogue entry is a prerequisite for publishing a dataset that others depend on, or when a steward's sign-off is required before a dataset can be used in a certified report. Without a gate, documentation is a request for goodwill, and 30% is about what goodwill delivers in a year.

What I would keep, even though it looks like it failed

• Business stewards rather than platform staff. The knowledge is genuinely in the business; centralising it produces accurate-looking descriptions that are subtly wrong.
• The catalogue. It is not the problem. A catalogue with 30% coverage but full coverage of the 100 used tables would be a success, and that reframing is available immediately.

When not to change any of this

If the programme exists to satisfy an auditor who tests for a named steward per asset, cutting to 100 stewarded tables costs a finding, and the right move is to keep the register and fix only the approval queue. Choose that when the obligation is real and stated in writing; otherwise the register is decoration.

How I would argue this in the review

Not as "stewardship has failed", which reads as blaming the people who volunteered. As a capacity argument: 1,200 tables and no allocated time is a design that cannot work at any level of effort. Data governance programmes have been failing this way since master data management projects of the 2000s, and the pattern is always the same. Then offer the trade openly — fewer stewarded datasets, real time allocated, one gate that makes the work matter — and name what is being given up, which is the appearance of complete coverage.