A transformation programme creates conditions that are difficult to replicate in business as usual.
For a defined period, there is dedicated resource, executive attention, cross-functional collaboration and a clear mandate for change. Data problems that have persisted for years have people working on them full time. Teams make governance decisions in weeks that would normally take months to sign off.
The question is whether organisations use that window well.
After more than a decade delivering CLM and KYC programmes, I’ve seen the same pattern. Data quality improves during delivery and then, without the right foundations, standards begin to slip when the programme team stands down. Users lose interest. Controls that were robust at go-live gradually lose their grip.
The organisations that avoid this use the programme as an opportunity to put sustainable controls in place, with the ownership and oversight needed to keep them working in business as usual.
Data design has to come first
One of the clearest indicators of whether controls will last is how early the programme addresses data design. It needs to be a priority from the outset, before programme leaders make the main platform decisions, and it needs senior backing.
When the programme brings in data governance early, it shapes platform configuration, workflow design and the assignment of ownership. Controls can be built into the architecture rather than added afterwards.
When governance arrives late, the programme must layer it over a design that does not support it. The controls create friction and are more likely to fall into disuse when programme pressure lifts.
The data model and the standards that enforce it
A logical data model is more than a technical artefact. It gives the programme a shared language for defining what data exists, what it means, who owns it and what good quality looks like. When business, technology and data stakeholders agree the model early, it becomes the reference point for later decisions.
Platform configuration, workflow design, integration rules and reporting structures all flow from that model.
Data standards then set the rules for how the organisation captures, validates and maintains information. Their durability depends on the controls that enforce them.
The most resilient programmes build data standards into workflows. The business does not rely on people remembering to follow the standard or on repeated manual checks, because the system prevents non-conforming data from entering in the first place.
Ongoing monitoring closes the loop, showing whether the business meets the standards. Dashboards, data quality measures and reporting to senior leaders help the organisation identify problems early, rather than years later during another remediation or transformation.
In the better cases I've seen, ownership transferred to permanent data teams before the programme closed, with named stewards, ongoing monitoring and executive reporting in place. The programme built the platform; the permanent data organisation kept the controls working.
Getting senior stakeholders invested
Programme teams often assume senior support for data governance rather than earn it. Sponsors sign off the programme, agree the principles and move on.
Getting sponsors invested requires a clear link between data quality and problems they are already accountable for: regulatory reporting errors, missed revenue from inaccurate client records, or the operational cost of managing duplicate customers.
Practitioners also need to translate the technical case into business consequences. They need to connect better data to what it makes possible, and poor data to its cost and risk. Partnering with a Chief Data Office or equivalent is important here. It brings institutional authority and a mandate that extends beyond a single programme.
Technology as a catalyst and its limits
On one programme, we used AI and machine learning to identify duplicate customer and client records at scale. This reduced duplicates and operational overhead, improved data quality and gave the organisation a more accurate view of risk exposure across the portfolio.
The technology established a clean baseline, but we understood that remediation alone would not prevent the problem returning.
For this reason, we introduced hard controls that mandated key attributes and prevented duplication at the point of entry. Ownership then transferred to the data team, with a dedicated data quality control manager and regular Tableau reporting to the COO’s office. The control had a named owner, regular reporting and executive oversight.
Ownership, shared goals and the risk of failure
Clear ownership is essential if data controls are to survive beyond a change programme. Different teams may own different parts of the control environment, but each needs to understand how its responsibilities contribute to a shared, measurable outcome.
That outcome should connect to something the organisation genuinely cares about, such as regulatory compliance, revenue accuracy or operational efficiency. Accountability also needs to reflect the risks of failure. Teams are not simply working towards a positive target. They are designing and operating controls to avoid regulatory breaches, inaccurate reporting, unmanaged risk exposure, lost revenue and avoidable operational cost.
If teams do not understand those potential consequences, they can see governance as discretionary and deprioritise it when other pressures arrive. A transformation programme provides a temporary opportunity to make the risks visible, assign ownership and put controls in place with clear authority.
Used well, that opportunity leaves the organisation with data controls the business trusts, owns and maintains. If the organisation misses the opportunity, the same problems tend to return not long afterwards.
