Data Governance: Maturity models and scaling at pace

How to choose and implement the right measurement methodology for your business:

Zoey Husband
May 25, 2021 · 6 min read
Photo by Suzanne D. Williams on Unsplash

With market conditions and consumer behavior changing faster than ever, all businesses are striving to have an agile market proposition, allowing them to remain relevant to their customer base. In this Compare the Market is no exception. It’s also not a coincidence that in parallel, there has also been a rise in the popularity and prevalence of Data Governance (DG) roles appearing across all verticals.


Successful DG programmes do not happen by accident — they require careful planning and a business capabilities milestone approach aligned to the business goals. One of the most challenging parts of starting out on your DG journey is conducting an honest and open assessment of the current state. The maturity model assessment is a tool that helps to articulate both the current state and desired state, therefore also helps define the interim steps to close any gaps.

There are many maturity models available free and paid for at varying levels of complexity.

The Compare the Market journey

Despite being a household name, DG only became an official department at Compare the Market three years ago. This scenario is very common — there are no legacy issues to resolve, so with a small headcount it’s hard to justify preventing an issue that is yet to cause you any pain. In parallel the technical landscape tends to also evolve organically over time, often resulting in disparate ways of managing the data. With an enterprise approach often only coming into reality later down the line.

At compare the market, data is our business so proving the value of having a Data Governance team needed to be task number one. We created our own maturity assessment framework to suit the required outcomes for our business and corporate strategic goals. We created this by taking inputs from a combination of publicly available frameworks and using industry best practice from sources such as DAMA DMBOK 1 and 2. The outline was then broken down further into people, process and technology capabilities to allocate accurate measurement and actionable tasks.

Using our framework, we then took on the task of benchmarking the current state. Then came the more challenging aspects:

1. Determining where we wanted/needed to be

2. Creating and packaging the gap analysis into palatable, actionable chunks

On face value the above seems easy, right? Unfortunately not, and here is why:

1. Determining where we wanted/needed to be

All maturity models will go from a low point (immaturity) to a high point (very mature), generally across a number scale. Human nature is often the stumbling block here. If you present a maturity model to senior leadership and above and ask where their aspiration is, nine times out of 10, they will say the high point. The reason being is these are always ultra-ambitious people whose mantra is to make the business the best it can be. So, saying it’s an aspiration to be anything other than the best, without the suitable context will be alien to them and will lead to a fruitless conversation.

The reality is few organisations need to be high point across all DG disciplines to reach their corporate goals. In fact, the biggest jump in terms of noticeable capability comes the transition from low points to mid/ ¾ point. To ensure you see these tangible differences, make sure your maturity model clearly uses business capabilities and tie these back to the strategic goal.

2. Creating and packaging the gap analysis into palatable, actionable chunks

Conducting a maturity assessment for the first time will inevitably surface a substantial list of issues and required actions which can, at first glance, seem overwhelming. In addition, addressing some of these items may require significant organisational change over the long term to prevent reoccurrence. Many approaches can be taken here, varying from militant to unintrusive. Which approach you take will be heavily dependent on the resources available and company culture.

We chose the unintrusive approach. Planning and scheduling actions related to people and process-based tasks that created quick wins, helped share the message of what was required without causing unnecessary friction.

In parallel a single deep dive was conducted on a high importance dataset to surface issues and raise the profile of some of the previously unknown data issues.

Foundations laid. Now what?

DG at Compare the Market has five main pillars for its operational process:

1. Privacy

2. Security

3. Sales file operations & reference data

4. Data Quality (DQ)

5. Strategic Project Support

We took a risk-based, stepped approach to scaling the team as we knew doing too much at once would lead to sub optimal results. Privacy and security were the first pillars to be taken from the proof of concept to a fully resourced team, with regular reporting against a risk KPI framework, alongside the addition of regular companywide awareness training. These functions have now fully scaled and reached the required maturity for the current climate.

While scaling the pillars of privacy and security, we noticed that a significant volume of strategic projects was either being prevented or delayed from launching as they had not created all the required evidences to prove privacy and security policy compliance. This resulted in our fifth pillar being born, covering strategic project support. Initially we distilled our policy requirements and industry best practice into a simple to use framework. Using this, alongside support from a dedicated resource we have been able to assist these projects in understanding the obligations upfront and guiding them through the process, so they are able to launch on time in a fully compliant way. From the initial success of the framework it was expanded further to include requirements from DQ and additional best practice across all areas.

The following pillar to be scaled was sales file operations and reference data. This was completed alongside a project increasing the product coverage of this pillar as well as the data breadth and frequency. The scale and impact of the changes here were so vast and benefits so large that it was prudent to not do this as BAU. The sales files aspect of the team are now fully-resourced and BAU, and we are now focused on maturing the reference data section.

The final pillar to start to scale is DQ. Much foundational work has been done in this area and we are providing reactive services to the business functions as well as recently introducing a risk KPI framework. DQ is one area that to truly scale with the volumes of data we hold, does require the support of technology. Again, due to the magnitude of both the effort and reward, we are in the middle of a programme to introduce this into the business alongside other DG tech.

Key takeaways and leanings from our journey so far

· It always takes longer than you think it will

· Slow and steady progress creates much less resistance and better long-term value

· Having a value measurement system in place is essential to evidence to stakeholders both the immediate and long-term value created, and benefits delivered and to show improvement over time

· Be clear programmes support DG but DG is NOT a programme — it’s an ever evolving BAU item

· Be critical on prioritisation, don’t be scared to park lesser value items on backlog

· Building a team can take a while, the right fit candidates my not be immediately available

· Be prepared for push back, equally be prepared for the quick switch to becoming a victim of success

· Keep at it — with consistency you will win teams over and be able to embed processes into BAU

Compare the Market

The people behind and the Meerkat App