The Tale of Dick Whittington and the Missing Data

Christmas is fast approaching, and it’s safe to say the season wouldn’t be complete without a few cheeky jokes, a whole lot of glitter, and an enthusiastic crowd shouting “It’s behind you!” at the top of their lungs. 

For those of you who have no idea what I’m talking about, a pantomime is a musical stage production which takes traditional fairy tales and retells them with larger-than-life characters, slapstick comedy, jokes, gags and a big baddie we can all boo at. They’re a staple of the British festive season, and, believe it or not, the perfect metaphor for data gone wrong. 

So, sit back, relax, and grab your popcorn, because today I’ll be weaving my own little tale, featuring our fortuitous hero Dick Whittington…

Once upon a time… there was a man called Dick Whittington. He was a humble man. Loyal, dependable and hard-working - he loved his job at the Dense Doughnut Bakery. One day, his boss, Mr Dense, tasked him with finding a way to improve customer experience within their organisation. And this, my friends, is where our story begins…

Our humble Dick set out on his journey to improve customer experience. Being the eager employee that he was - and desperate to please Mr Dense - Dick went looking for a magical and instant solution. He trawled and trawled the internet but was getting nowhere fast. Distracted, he decided he would start his Christmas shopping, and headed to eBay. There, he discovered a listing for a magic lamp (as you do), which he thought his dear wife would love. And, not one to hang around, Dick clicked ‘buy it now’ and selected express shipping. 

When his magic lamp arrived, Dick polished it furiously and to his surprise out popped a Genie, who offered him three wishes. 

“Aha!” exclaimed Dick. “That is the answer to all my problems! I will use these wishes to improve customer experience at Dense Doughnuts and still have the lamp to give my wife for Christmas!” 

So, Dick set about making his first wish and he asked for lots of shiny new technology tools to help him manage his customer experience. Secondly, he wished for an instantaneous data migration from their old systems to put the data into his shiny new systems. And thirdly, he wished for a self-service portal, so that customers could access their own records and manage them themselves. 

These were good wishes, but the old saying is true ‘you get what you ask for’. It was a disaster. The Genie hadn’t thought about the data that was going into these tools. And why would he… he’s a magical Genie, not a data scientist! 

Dick couldn’t launch his online portal because the customer data was so very poor, and they didn't want their customers to know how bad it was - that would’ve had the opposite effect of improving customer experience!  Even worse, half the data they thought they had about their customers didn't appear in the shiny new tools.  So, Dick had to go on a hunt to find the missing data. 

He searched high and low, low and high shouting at the top of his lungs: “Data, data - where are you?” 

“It’s behind you!” echoed the mysterious chorus of voices. 

“It’s behind you, it’s behind you… IT’S BEHIND YOU!” the voices continued to chant. 

As the voices grew louder, Dick began to question his sanity, as every time he turned around… the missing data was gone (a classic panto gag, if ever I’ve heard one). Poor Dick Whittington was on a wild goose chase.

Feeling lost and confused Dick cried out: “Oh, woe is me. If only there was one place I could go to see what data we have in this company and where I can find it. If only we had a catalogue of Data. That’s what I should have wished for.”

After hours and hours of searching, Dick finally found some data that he thought might do the job. But, he was worried of repeating past mistakes, or using the wrong data and damaging the customer experience. Dick wasn’t sure what to do. He shouted: “IS THIS DATA GOOD ENOUGH?!” 

“Oh, yes, it is!” shouted the mysterious chorus. Quickly followed by “Oh no, it isn’t!” This went on for another hour. 

“Oh, yes, it is!”

“Oh no, it isn’t!”

“Oh, yes, it is!”

“Oh no, it isn’t!”

Uh, oh, here we go again! Now, poor Dick was more confused than ever! Sherry Trifle, (the resident know it all) spotted poor confused Dick and came over to see if she could lend a helping hand.

She said: “Well if you're not sure, do you really dare use this data?” 

“But I’ve wasted hours searching and this is all I have to show for it - I have to do something!” 

“What if you find out that it’s really bad quality, or even worse that it's the wrong data and we make the wrong decisions on it?” replied Sherry. 

“If only there was some way I could know if the data was good enough to use” replied Dick.

Sherry said she knew someone who could help, and introduced Dick to a wonky looking chap with a big basket of dirty data. 

“Hello! I’m Wishy Washy - pleased to meet you! That looks like a lot of data you have there. I could cleanse that for you if you like?” he offered.

Dick wasn’t really sure if it was the right thing to do, but he was running out of options. So, with great apprehension, he took Wishy-Washy up on his offer and followed him to the laundry. 

The laundry was full of hustle and bustle. It was noisy with machines spinning round and round cleansing data and making it ‘better’. Dick asked Wishy how they knew what they were doing and how they would figure out which parts of his data were good or bad. 

“I don't know - we just put it in the washing machines, and it comes out clean!” replied Wishy. Dick was worried. And he was right to be. When Dick got his data back it was definitely different. But he was still not convinced that it was right.

It turns out Dick was correct. As it goes, all the wishful thinking in the world couldn’t fix his data.

It all got too much, and Dick sank to the ground. He felt utterly hopeless and defeated, and wondered why on earth Mr Dense chose him to take on this project to improve customer experience…

But Dick was about to undergo his most transformative experience yet. 

Suddenly - POOF! In a big puff of sparkly fog, Dick’s Data Fairy Godmother appeared! She explained to Dick that all the things he’d wished for from the Genie were wrong.

BUT, all hope was not lost, as the things he'd wished for during his journey (one place to document all the data and where it’s held, a way of knowing how good or bad the data is, and finally, a sensible way to fix bad data) were the wishes he should have asked for to begin with. And the most important part? He didn't need a Data Fairy Godmother or a Genie in a lamp to give him those wishes – he could simply start a Data Governance initiative!

So, with the right processes, integrity, and accountability, Dick’s business went on to live happily ever after.

The END!

Now you see, pantomimes can be fun to visit once a year but are a long, drawn-out nightmare to live in. Don’t be like Dick and don’t make the wrong data wishes! Avoid working in a data pantomime, implement Data Governance and remember Data Governance is not a project - Data Governance is for life, not just for Christmas!

Making Data Governance Processes Accessible

One of the most practical questions I encounter in data governance is deceptively simple: how should we document our processes? The answer reveals a crucial insight about implementation success, as formal documentation and user friendly communication require very different approaches.

The Appeal of Swim Lane Diagrams

My early career in banking introduced me to BPMN (Business Process Notation Modelling), which produces swim lane diagrams. These structured visual representations organise processes into logical rows, with each lane representing a specific role. The flow shows precisely who does what and how handoffs occur between parties.

For those with analytical inclinations, swim lane diagrams offer clarity and logical precision. My work with BPMN specialists, at the first consultancy I worked for, reinforced their value as robust documentation tools. When executed properly, they capture process complexity with remarkable accuracy.

The Documentation Dilemma

However, there's a challenge: swim lane diagrams are divisive. They're what I'd call a "Marmite thing". You either love them or you hate them and find them impenetrable. Even before specialising in data governance, I appreciated their structure. However, I've learnt that many business users don't share this enthusiasm.

This creates a fundamental tension in process documentation. The formats that satisfy governance requirements often fail to resonate with the people who must actually follow these processes.

A Dual Track Documentation Strategy

I recommend an approach which recognises both requirements:

Formal Documentation Layer: Document data governance processes using your organisation's standard methodology. If your organisation already employs swim lane diagrams organisation wide, continue that practice. If alternative formats are standard, adopt those instead. Consistency with organisational norms, is important in everything we do as it eliminates unnecessary friction.

Communication Layer: Transform formally documented processes into simplified, accessible formats for business users. Create straightforward visual diagrams that fit on a single PowerPoint slide. These high-level representations help people grasp the essential flow without overwhelming detail. And if a business stakeholders asks for more detail you can then share the formal process documentation.

This dual track approach has proven remarkably effective. In my experience, business users consistently respond positively to simple pictorial diagrams that distil complex processes into digestible visual narratives, but you have the formal documentation in place for the times when it is required.

Practical Implementation

The workflow becomes: document rigorously using established organisational standards, then translate that documentation into user friendly communication materials. Your formal documentation satisfies compliance, audit and operational requirements. Your simplified diagrams drive adoption and understanding.

This distinction matters because data governance succeeds only when people actually follow the processes you've designed. Perfect documentation that nobody uses delivers no value at all!

Effective process documentation isn't about choosing between rigorous and accessible. It's about maintaining both layers simultaneously, each serving its distinct purpose.

If you'd like support developing process documentation that works for your organisation, book a call with me using the button below.

Oui Chef!

I’m thrilled to share this guest blog from Hyatt Saba, Data Governance Manager at Sage. I always enjoy my conversations with Hyatt about all things Data Governance - she has such a great way of bringing the topic to life through clever analogies.

In this blog, Hyatt draws on the world of professional kitchens to show how clear accountability and defined responsibilities are the key ingredients for successful Data Governance.

It's Saturday night and in the thick of dinner service at a popular new restaurant, table 7, order 2 raspberry and white chocolate soufflés to finish off their wonderful meal in celebration of their wedding anniversary. The Chef de Partie turns the oven dial to 200° C, she weighs the flour to precision, and lovingly folds in the top-quality ingredients. She pours the batter into the pots and opens the oven door to deposit her perfectly prepared desserts, only to discover that the oven is stone cold.

Aargh! What now? Well, it’s fair to assume that the majority of dessert services are out for the night. Let’s hope that the diners enjoy ice cream!

The hot potato...

So, whose responsibility is it to ensure the oven works? Is it the Chef de Partie who uses the oven and couldn’t fulfil her order? Is it the Head Chef who is accountable for the kitchen’s machinery and meeting financial targets (which will be negatively impacted from the inability to serve desserts) or was it the Sous Chef who is responsible for scheduling periodic maintenance?

Food for thought

No doubt, in a kitchen environment there might be some choice words - or knives thrown in the heat of the moment, but in the spirit of getting the kitchen back on track, it’s worth resisting the temptation to assign blame and instead get to the bottom of how the oven not working has fallen through the gaps to mitigate its recurrence. It’s of critical importance to understand accountability, and ensuring roles and responsibilities are in place for the kitchen to run more smoothly in the future rather than making assumptions, who ultimately should have checked the oven was working that day?

The same applies for data management. The purpose of assigning accountability and definite roles is to provide clarity and steer the management of data to avoid such situations from occurring.

Without clearly defined accountability and responsibility, things are left open to chance and are at risk of not consistently being done. We can easily assume that someone else will do it, or that it's someone else's job and that might be ok when everything is running smoothly, however as highlighted in the above scenario, what happens when luck runs out and things go wrong?

A recipe for success: Data Governance assigned roles

Taking chance out of the equation, reducing risk, and introducing rigor and quality are at the core of Data Governance with establishing and surfacing the accountability and responsibility of our data assets being a fundamental part of that. We do so through engaging with stakeholders and ascertaining how data is managed and who the decision makers are.

In the practice of Data Governance several roles exist, in this article, we will explore the  following; Data Owner, Lead Data Steward and Data Steward.

Applying that to avoiding too many cooks in the kitchen:

It's important to know who is accountable for data and who is responsible for its upkeep - all doing the same thing without clear definition and agreement can cause confusion, duplication and the risk of things being missed. Governance is the answer to providing clarity, transparency and trackability: I think this concept bears a great likeness to the formal roles we all know exist in a restaurant kitchen.

• In a restaurant we have a Head Chef who is accountable for overall kitchen management, menu creation, and culinary direction. A Head Chef may not have personally cooked the dish, but they are still accountable for every plate served. It needs to be what it says on the menu, allergies respected, food safety adhered to at each step of the preparation process, consistent portion control and presentation, whilst ensuring profitability and timeliness. While a Head Chef might not necessarily have held a pan in the preparation of the meal, they hold ultimate accountability, just like a Data Owner does for a data asset.

• A Sous Chef who is second-in-command in the kitchen, assists the Head Chef and oversees day-to-day operations. They are the middleperson who takes that strategic direction and brings it into action often through delegation. They may oversee preparation, adjust the seasoning, organise machinery maintenance, arrange the appropriate garnish and serve-up on the right plate. A Sous Chef makes things happen, think of the Sous Chef as the Lead Data Steward.

• Last but certainly not least is the Chef de Partie who is in charge of a specific section of the kitchen, such as the grill, pastry, sauces, etc. Think of a Chef de Partie as a Data Steward, who is often right in detail and a Subject Matter Expert (SME) in their own right. They know how to turn that boring pile of flour into a perfect souffle every time.

A culinary giant or a petite bistro

It’s worth calling out that there is often a distinction in terms of operations between a large organisation and a smaller organisation. In a smaller company one person might have several roles, they might be a Data Owner, a Lead Data Steward and a Data Steward. For example, the independent corner café will probably have the same person who owns and manages the running of the café, sources the coffee beans and makes the coffees whereas a Michelin-star restaurant might have someone who specifically cooks carrots to perfection.

Having the right roles for the size and type of kitchen – or business - ensures that those who know the job or data the best, are brought in at the right time for clarity and transparency, efficiency and creating trust through data.

Think about it as avoiding chaos and catastrophe in the kitchen by adopting Data Governance guidance to optimise workflow, ensure quality and minimise mis-stepping or miscommunication.

Just as in that kitchen, data assets without clear accountability and responsibilities will negatively impact the value chain to which we all contribute in one way or another. The proof is in the pudding.

---

Guest Blog from Niels Lademark Heegaard - Is Your DG/EA/BPM Approach Mature and How Can You Tell?

It’s a pleasure to feature a guest post from Niels Lademark Heegaard, a talented friend and former colleague from my early days at Platon, the first consultancy I worked with. Niels has an exceptional ability to make complex ideas clear and practical - something I’ve admired since we first worked together.

In this blog, Niels explores how to define, measure, and apply maturity in Data Governance and Enterprise Architecture.

Yet another AI free blog post (except for correcting my spulling and the cover image).

This time around I muse about Data Governance and Enterprise Architecture maturity. How do you answer the age old question: How mature is your Data Governance efforts?

Claimer: A search and replace and you can use this for EA, MDM, BPM, AI, etc.

Maturity…

Maturity is a very frequently aired term that is thrown around in the context of both Data Governance and Enterprise Architecture (and a host of other disciplines). Statements such as “This company is immature,” or “The Data Governance model is immature,” are encountered, but little is said about how this label is defined.

What is maturity anyhow?

So, what is maturity; how do you measure it, and what can you use it for?

Definition: Maturity is the extent of your capabilities within an area.

You need a lot of capabilities to be successful in Data Governance, Enterprise Architecture, Master Data Management, Business Process management etc., etc. Since the disciplines differ the capabilities do as well, however there is a surprising amount of overlap between fields.

Know your measures

Whenever I do a maturity assessment, I categorize these capabilities and subdivide them. One of the maturity indicators for all the mentioned fields is “Governance,” which I’ll use in my example below.

Governance

1. Strategic recognition

2. Funding

3. Organization

4. Assigned resources

Organization

1. Placement in the organization

2. Size and skills

3. Team education and training

4. Influence

Business alignment

1. Business Drivers/Priority management

2. Business Process alignment

3. Ownership

4. Co-development

Methodology

1. Framework/Policies

2. Methodologies/Guidelines

3. Project alignment

4. Budget process alignment

Technology support

1. Requirements for IT Application Design

2. Master Data Archtecuture

3. Dedicated tooling

4. Tool coverage/Tool adoption

Change Management

1. IT project embedding

2. Continuous discipline development

3. Education (outside the team)

4. Communication (outside the team)

Mind you there are other potential subtopics (governance could e.g., include “Audit”). I usually end up with 6-10 different dimensions, but I’ll go with the four under “Governance.”

Six dimensions and a lot of questions

Just to avoid (or add to) the confusion: “Governance” in this context is about how your enterprise’s management approaches your particular discipline, e.g., BPM, EA, etc. It is not about the execution of Data Governance, but about the conditions that are set to perform Data Governance in the first place.

There is a point to this: Always explain what the overarching dimensions cover. It will also help you define the sub-topics.

Be consistent, get it right, and get value

I usually measure each sub discipline individually on a score from one to five. The snag is how do you decide if the score is two or three, consistently? Is it really that important to get it exactly right?

The answer to the latter question is resounding: Yes, it is very important!

I’ll explain why that is later, but I can allude that getting it right will enhance the value of the maturity assessment immensely.

To assign the scores exactly right you need to define them. This is hard work which is why I’ll limit my example to a few examples namely “Strategic Importance” and “Funding”:

Explaining step by step

Strategic recognition

Level 1 (a.k.a. What??) Data governance is not recognized as a value adding discipline in the company. The term is largely unknown, and the benefits are unrecognized (stop wasting my time).

Level 2 (a.k.a. Why?) Data governance is familiar to those that experience low data quality directly, but not as a trans-organizational effort, there is a departmental acknowledgment of the need, and a few understand the discipline and perceive the benefit of a collective effort . One or two projects may occasionally take Data Governance into account (why is this necessary??).

Level 3 (a.k.a. OK…) The term data governance is generally a familiar term and is recognized at the SVP level in some divisions. It is somewhat seen as an enabler of better execution within a division or department. There is a local knowledge of what needs to be done, but also some resistance. Some business plans and most projects take Data Governance into account (too much bureaucracy… will do it if I have to).

Level 4 (a.k.a. Yes!) The term data governance is a familiar term and is recognized at the CxO level. It is seen as a prerequisite for better execution both within and across departments. There is an understanding of what Data Governance entails and acceptance of the actions that need to be taken. All business plans and projects take Data Governance into account or will need explicit permission not to (OK, will go do).

Level 5 (a.k.a. Of course!!) The term data governance is a familiar term and is recognized at the CxO and executive board level. It is seen as the foundation for business execution both within and across departments. Data governance is understood by everyone, and its consequential actions are seen as beneficial. The business strategy and business plans and projects take Data Governance into account or are paused until they do (Darn I forgot… it is top of my list!).

Let’s do funding

Level 1 (a.k.a. Go away (I need to manage these errors!). Data governance is not funded. It is perceived mostly as an unnecessary distraction that lures some untoward employees away from value-adding work. Enthusiastic front runners and local advocates can hope that their manager turns a blind eye.

Level 2 (a.k.a. CAPEX not OPEX (We did it... are you still here?)). A data governance initiative, usually in the form of a project, is funded. The resulting recommendations might result in part-time allocation of some employees (but remember that you also have to deliver on [insert day job]). Funding is based on a yearly allocation in a local department. Project budgets will generally not have funds for taking Data Governance into account.

Level 3 (a.k.a. OPEX (OK, We’ll continue... for now)). A data governance department (or part of a larger department) is funded with a few (too few) people. The funding is given by an SVP or equivalent, subject to unchanged division budgets. The function is centralized and there might or might not be some funded liaison officers in other divisions (with day jobs). There is little in the way of dedicated technology support. Project budgets will sometimes have funds for taking Data Governance into account (especially migration projects).

Level 4 (a.k.a. OPEX (We got it fully covered)). A data governance department (that exists in its own right) is fully funded (usually slightly understaffed). The funding is given by a CxO but as a minor expense it is rarely listed in the annual report. There are funded liaison officers in most divisions. There might be some dedicated technological support (specialist tools and/or one-stop shops for all things DG). Project budgets have funds for taking Data Governance into account.

Level 5 (a.k.a. OPEX and CAPEX (No, we don’t... )). A usually slightly understaffed data governance department is fully funded (not a copy-paste error 😊). The funding is given by a CxO and is listed in the annual report as a strategic effort. There are funded liaison officers in all divisions. There is dedicated technological support (specialist tools and one-stop shops for all things DG). Project budgets have funds for taking Data Governance into account. There are ongoing project(s) to develop DG further.

Benefits

I stated that it is essential to define and by extension, measure maturity precisely and consistently. Given 24 questions or twice that it is a lot of work, however there are three good reasons.

The first reason: If you wish to report on the progress of your Data Governance efforts, you will want to score the same parameters next year. This should be consistent and use the same measuring stick. On a related note, I only give a score if ALL the parameters for that score are met. Your mileage may vary.

The second reason: This maturity assessment is an action plan in disguise. It tells you what to improve if you wish to take your capabilities up a notch. On another related note (and this is important), level five is NOT necessarily where you want to be. It depends on your organization’s needs. Those needs might not call for a level five capability.

The third reason: You can also set the goals using the same scoring (in the same sessions). Where do you want to be? Voilà, you just made half a gab analysis. List up what it would take to close the gap, and you’ve made a full gap analysis.

Do it together and initialize change, do it alone and stay alone

A word of caution, do not attempt to measure the maturity without discussing the scores with relevant stakeholders. You could base it on a pain point analysis, workshops, or other ways of dialogue. Be prepared to explain the nuances. Once the hand wringing is done ask: Where do you want to be?

Show then what they have got

Final note. This is easy to communicate. Both the current and the target maturity can be shown in one easy to understand diagram. This is appealing to most people (or appalling depending on the gap). Use a spiderweb diagram with the main topics as the spokes. Plot in the as-is and the... optimistic ambition.

---

Niels started his career as a master of agriculture, but soon realized his mistake and changed to the IT industry. Niels started working with data governance in 1997, before the term was coined. In the summer 1997 he became master data manager, responsible for collecting and reporting the total research and conveyance of science done at the University of Copenhagen, from papers to museum exhibitions in one unambiguous format.

After a tenure at the Danish State Railways as information and enterprise architect, he joined a dedicated information management consultancy and later Deloitte by merger. The project tally as information management consultant ended at 28. Currently, he is working as the enterprise architect in a small company that calculates the electric grid capacity across Scandinavia.

Why Is Data Governance Coaching Expensive?

Unfortunately, Data Governance coaching isn’t free. In fact, it might seem quite the opposite… until you look at what you’re really getting.

Because what feels “expensive” at first glance often turns out to be great value when you look at the outcome. Cheap services tend to cost you more in the long run, wasting your time and your budget. Data Governance Coaching is different.

Rather than thinking of it as paying for theory, it’s more like investing in tailored, hands-on support that helps you turn good intentions into real results. And that’s where the value lies.

Let me explain…

You’re not just paying for time. You’re investing in experience.

When you work with an experienced coach, you’re not just paying for the hour in front of you. You’re gaining access to years of hard-earned knowledge.

In my case, that’s over two decades of helping teams just like yours implement Data Governance that works. I’ve made the mistakes, learnt the lessons, and developed practical ways to help others move faster and with more confidence.

That’s why the support I give is never generic. Every person I coach gets tailored guidance that fits their exact situation. And that’s why the results stick – because they’re designed around you.

You can choose between two flexible coaching packages depending on how much support you need:

1. Coaching: Six one-hour calls over six months.

2. Coaching Plus (most popular): Ten one-hour calls with even more flexibility over six months.

All sessions are recorded so you can revisit them whenever needed, and you’re welcome to bring team members along.

And it’s not just calls: you can use your sessions however helps you most. That might mean having me join an internal meeting, review a document, speak directly with stakeholders, or help you implement your framework step-by-step.

What are you actually getting for the fee?

It’s easy to look at coaching and ask: “Is this really worth the money?” But when you consider what it helps you avoid, the value becomes clear.

Here are four reasons my clients say the investment is more than worth it:

1. I understand where you’re coming from. I’ve been there.

There’s no shortage of frameworks and theories out there. But how do you take those and make them work for your organisation? That’s the hard part.

Many of the people I work with are struggling to turn theoretical knowledge into real, practical action. They feel stuck, especially when trying to win over senior stakeholders. I’ve been there myself. And I know how overwhelming it can feel when you’re expected to deliver results without enough clarity or support.

Coaching means you don’t have to go it alone. I’ll help you translate ideas into language that resonates in your business, so you can build support and avoid the risk of your initiative fizzling out.

2. Practical solutions to your real-world problems.

This isn’t a course where you sit and listen. My coaching is designed around you. You’ll bring specific challenges to the table and we’ll work through them together.

Whether it’s about building a framework, presenting to the board, or dealing with resistance, you’ll get answers to your questions, reassurance when you need it, and advice that fits your organisation – not just best practice on paper.

Plus, you’ll get a detailed Data Governance Checklist as part of your package. It’s a practical tool that helps you track what you’ve covered and what you still need to implement – perfect for staying organised and focused.

3. You’ll build confidence – and that changes everything.

Many clients come to me unsure if they’re doing the right thing. They hope their approach makes sense but they’re not sure how to explain it to others, or how to know when they’re on the right track. That’s where coaching changes everything.

We work together to build your understanding and your confidence, so you can speak to stakeholders with clarity and direction.

One client, the Enterprise Data Governance Lead at Volkswagen Financial Services UK, described how coaching became a crucial sounding board during their implementation:

“It gives you real confidence that you are heading in the right direction. We would book a session and say, ‘This is what we’re working towards’, get a few pointers, go away and have a stab at it, then come back and say, ‘This is what we’re thinking – does that look about right?’”

They added:

“Nicola helped us sense-check ideas, avoid common mistakes, and build a more collaborative, supportive approach to governance. Now, people want to work with us.”

4. You don’t have to do this alone.

Whether it’s through coaching, group training, or Mastermind Days, you’ll connect with others facing similar challenges. For many people, that’s one of the most valuable parts.

If you’re the only one in your organisation responsible for Data Governance, it can feel incredibly isolating. But you are not alone. I can even introduce you to others in similar roles, if it helps to know you’re not the only one figuring this out.

You also have the option to access expert guest coaching sessions – these can be included in a package or booked separately. These deep-dive sessions cover topics like Data Catalogues, Data Quality, and Data Storytelling, helping you deepen your understanding in key areas.

And if you opt for Coaching Plus, you’ll also get a bonus licence to my online Data Governance Training course, plus access to my Data Governance-specific AI assistant, trained on my own knowledge. Ask it anything and get immediate, relevant answers when you need them.

So… is it expensive? Or is it valuable?

Here’s the truth: Data Governance coaching is an investment. But not in theoretical knowledge, or slides, or generic advice. It’s an investment in you, your knowledge, your skills, and your success.

When you look at it that way, it’s not expensive. It’s exactly what you need to move forward with confidence and clarity.

Compared to hiring a full-time consultant, coaching is a highly affordable way to access expert advice and ongoing support, tailored to your situation and designed around your availability. Whether you choose the six-session or ten-session package, you’ll get personalised help and the flexibility to use it however makes the biggest impact.

If you’d like any further help or information about coaching, take a look at my website coaching page.

Or, check out this case study on coaching to see how it’s benefited my clients.

Making Data Governance Work With, Not Against, Your Teams

Shifting Data Governance Left

I recently recorded a video with Paolo Platter, CTO and Co-founder of Agile Lab, discussing how organisations can embed data governance into their development processes to make it a true enabler.  It was a fascinating conversation and I’m thrilled that Paolo agreed to write a guest blog on the topic:

If you've been following data governance discussions lately, you'll have noticed a troubling pattern: despite significant investments in governance teams, data catalogs, and policy frameworks, organisations are still struggling with the same fundamental challenges. Poor data quality, compliance violations, and that persistent lack of trust in enterprise data.

Sound familiar? You're not alone.

The uncomfortable truth is that most data governance approaches are fundamentally broken—not because the concept is wrong, but because we've been implementing it backwards.

What Traditional Data Governance Gets Wrong

Let me start by addressing the elephant in the room: traditional data governance is reactive. We've built entire frameworks around fixing problems after they occur, rather than preventing them from happening in the first place.

Here's what this typically looks like in practice:

• Data gets created and pushed to production without proper metadata

• Data stewards scramble to document and classify assets after the fact

• Quality issues are discovered downstream when reports fail or decisions go wrong

• Data governance teams spend their time in endless catch-up mode, always one step behind

This approach creates what I call the "governance gap"—the dangerous space between when data is created and when it's properly governed. During this gap, data consumers lose trust, compliance risks multiply, and the entire data governance program starts to feel like an expensive afterthought.

The Knowledge Hand-off Problem

One of the biggest issues I see is the problematic knowledge transfer between domain experts, data engineers, and data stewards. Think about it: the person who best understands the business context of the data (the domain expert) isn't the same person building the data pipeline (the data engineer), who also isn't the same person responsible for cataloguing it (the data steward).

Each hand-off is an opportunity for critical context to get lost. By the time your data reaches production, much of its business meaning has been diluted or completely misunderstood.

Absolutely not ideal, is it?

Introducing Governance Shift Left: A Better Way Forward

Here's where things get interesting. What if instead of treating governance as a separate, downstream activity, we embedded it directly into the data engineering process from the very beginning?

This is the essence of Governance Shift Left—a proactive approach that integrates governance practices into the earliest stages of the data lifecycle, particularly during the software implementation phase when data pipelines are being built.

The concept isn't entirely new (software development has been "shifting left" on testing and security for years), but its application to data governance represents a fundamental paradigm shift.

The Four Pillars Of Governance Shift Left

Governance Shift Left is built on four core principles:

1. Lifecycle Alignment
Metadata, code, and data should follow the same development lifecycle. They're all part of the business value you're creating, so why manage them separately?

2. Ownership
Your data engineering team becomes directly accountable for compliance, not just data delivery. They adopt governance policies as part of their standard development process.

3. Policy as Code
Governance policies are no longer guidelines—they're automatically enforced through code and cannot be bypassed. This transforms abstract policies into concrete, executable rules.

4. Transparent Documentation
Policies should be documented, accessible, and self-explanatory. A good policy explains not just what to do, but why it exists and what the trade-offs are.

Why This Approach Works

When you align data documentation with the software development lifecycle, you can apply the same quality gates you use for code before it goes into production. The benefits compound quickly:

Improved Time to Market: No more waiting for separate governance teams to catch up with your data initiatives. Quality and compliance are built in from day one.

Reduced Manual Effort: Your data catalog automatically stays aligned with governance policies, eliminating the need for manual data entry and reducing errors.

Enhanced Trust: When data and metadata are created together and never fall out of sync, data consumers can rely on what they find in your catalog.

Lower Costs: Fewer manual checks, less rework, and reduced maintenance costs as quality issues are prevented rather than fixed.

Making It Practical: Data Contracts and Policy Automation

Two key enablers make Governance Shift Left practical rather than just theoretical:

Data Contracts serve as software-defined agreements that include technical schemas, business metadata, SLAs, and quality expectations. These become artefacts produced by your data teams, enabling governance enforcement at deployment time.

Policy as Code provides the ability to build automated quality gates for metadata and enforce them during your CI/CD process. These can be sophisticated—checking if semantics align with your business glossary or ensuring compliance with industry regulations.

Your Next Steps

If you're ready to move beyond reactive governance, here's what you should do:

1. Start Small: Identify one critical data pipeline and implement basic data contracts

2. Align Teams: Bring your data governance and engineering teams together to define policies that can be automated

3. Implement Quality Gates: Add metadata validation to your CI/CD pipeline

4. Measure Impact: Track the reduction in downstream quality issues and governance effort

The shift won't happen overnight, and you'll need buy-in from both technical and business stakeholders. But the alternative—continuing with reactive, resource-intensive governance—simply isn't sustainable as data volumes and complexity continue to grow.

The Bottom Line

Traditional data governance assumes that good governance happens to data after it's created. Governance Shift Left recognises that good governance happens with data as it's being created.

This isn't just about improving your governance program—it's about fundamentally changing how your organisation thinks about data responsibility and quality.

The question isn't whether you can afford to make this shift. It's whether you can afford not to.

Ready to explore how Governance Shift Left could work in your organisation? The principles are universal, but the implementation needs to fit your specific context and constraints. 

This article has been condensed and updated, and originally posted here: 👉Data Governance Framework: Governance Shift Left

CTO & Co-Founder of Witboost. Paolo explores emerging technologies, evaluates new concepts, and technological solutions, leading Operations and Architectures. He has been involved in very challenging Big Data projects with top enterprise companies. He's also a software mentor at the European Innovation Academy.

Data Engineering and Data Governance

Just a short blog this week, but one that addresses the alignment between data governance and other data roles. Of course, I am biased, but I have always believed that data governance can help the other data management disciplines be more successful. The rising prominence of data engineer roles across organisations presents an interesting question: how do these technical specialists integrate within an established data governance framework? The answer lies in recognising data engineers as data custodians rather than creating a separate data governance role. 

Understanding the Data Engineer Role

A data engineer is not a data governance role; it is a fundamentally technical role that exists whether or not you have data governance in place. Data engineers function as technical intermediaries who source, transform, and prepare data for analytical consumption. Their responsibilities span several critical dimensions:

Data Pipeline Architecture: Designing and building automated systems that move data from source systems to analytical platforms. This includes creating robust ETL (Extract, Transform, Load) processes that handle varying data volumes and formats whilst maintaining reliability.

Technical Transformation: Converting raw data into standardised, analysis-ready formats (including the increasingly popular data products). Data engineers apply business rules, handle data type conversions, and implement transformation logic that aligns technical outputs with analytical requirements.

System Integration: Connecting disparate data sources across the organisation. This involves working with APIs, databases, cloud platforms, and legacy systems to create unified data flows that support comprehensive analytics capabilities.

Quality Assurance: Implementing checks throughout data pipelines. Data engineers build monitoring systems that detect anomalies, track data lineage, and ensure data quality.

Performance Optimisation: Ensuring data processing operates efficiently at scale.

Infrastructure Management: Maintaining the technical environment that supports data operations

So you can see that a data engineer is a technical role, distinct from formal data governance roles. However, within the data governance structure, data engineers align naturally with the data custodian role through their operational responsibilities. Whilst most data governance roles are predominantly fulfilled by business stakeholders who understand data context and requirements, the data custodian role is often fulfilled by IT professionals

The data custodian role works well as data engineers are not the business stakeholders accountable for the data itself. Data engineers maintain and transform data according to business requirements without assuming ownership responsibilities. They are responsible for liaising with Data Owners to obtain permission for use of their data, ensuring appropriate authorisation throughout the data lifecycle.

Successful integration requires positioning data engineers within your existing data governance framework rather than treating them as separate entities. You need to make sure that their activities are aligned with your data governance framework. Agreeing that they are data custodians provides flexibility to accommodate the technical nature of data engineering work whilst ensuring alignment with your data governance objectives.

Effective data governance succeeds through role clarity and simplicity. Data engineers contribute most effectively when their technical capabilities operate within your established Data governance framework and considering them as data custodians is a simple and effective way to achieve this.

If you want a deeper insight into the data custodian role, I've previously explored this topic in this blog post.

If you'd like support aligning data engineer roles with your data governance framework, book a call with me using the button below.

What is a Data Governance Roadmap?

If you've been following me for a while, you already know that I frequently emphasise that Data Governance is an ongoing journey, not a finite project.  However, we are implementing a Data Governance framework and juggling numerous activities. It may not be a project, but we do need to plan and track our activities. So, we need to find a solution to planning which takes into account the longevity and flexibility of Data Governance initiatives without being too rigid or detailed. 

This is where the trusty Data Governance roadmap comes in. It’s a high-level approach that outlines our activities, priorities and rough timelines without bogging us down in the details. 

In this blog, I’ll cover what a Data Governance roadmap is (and isn't), why it's beneficial and how it can keep your Data Governance efforts on track and adaptable.

Firstly, What is a Data Governance Roadmap?

In simple terms, a Data Governance roadmap is a high-level plan which outlines the steps an organisation will take to effectively implement data governance. It lays out the high-level actions, timelines, and priorities needed to implement a Data Governance framework, i.e. it provides an overview of the “big picture”.  

Its purpose is to show the overall direction of travel, a high-level idea of what you are going to do and roughly when. They use broad phrases like “identify Data Owners” and “draft data definitions”.

They are useful to you as the Data Governance Manager for planning and tracking your activities, and also to the senior stakeholders and other teams who need the strategic overview of your initiative.

What it isn't

It’s important to mention that a Data Governance roadmap is not a project plan.  As mentioned at the start of this blog, Data Governance is not a project, so why would it need a project plan?

A project plan is very detailed, specifying exact tasks by specific dates. This approach is not well-suited to Data Governance, which requires flexibility in its implementation and is deeply rooted in cultural change, meaning progress can only move at the pace your business stakeholders are ready to embrace.

A project plan can also create the false impression that Data Governance is a one-time effort with a definite end date. As you are aware, Data Governance is ongoing and evolves over time. It’s carried out by many business users across your organisation who have their own agendas and priorities. Expecting them to strictly follow a detailed project plan is unrealistic.

So, does this mean we should not have any plan at all? Absolutely not. 

Not having a plan would lead to a lack of direction and progress. To avoid this, I recommend using a roadmap, which serves as a high-level plan, but is high enough level to easily adapt and evolve as required.

The Benefits of a Data Governance Roadmap

A roadmap allows us to articulate what we are doing, why we are doing it and roughly when we aim to complete it. For example, we might set a target to complete data discovery and create conceptual data models for five key business functions by the end of June. Following that, we might aim to identify and train data owners by the end of September. 

This approach gives us a flexible framework that can be adjusted as we engage with business users and refine our plans. In doing so, we're able to get a general idea of what's to come without being overwhelmed by unnecessary details and deadlines. And this is just one of the benefits of working with a Data Governance roadmap. They can help us in several other ways too, including: 

• Direction and Structure: It provides a clear sense of direction and structure for the Data Governance initiative, outlining key milestones and goals.

• Communication: It serves as a communication tool to share with senior executives and business users, helping them understand the initiative’s objectives and timelines.

• Engagement: It can be used to engage business users in agreeing on realistic target dates that align with their other responsibilities and priorities.

• Flexibility: It allows for adjustments based on feedback and changing circumstances, making it a more practical approach than a rigid project plan.

Your Data Governance Roadmap is a Strategic Planning Tool

A Data Governance roadmap is key to Data Governance success. It is a high-level guide that helps manage the initiative effectively while remaining adaptable to the evolving needs of the organisation. This ensures that Data Governance efforts are integrated and aligned with business objectives.

I hope this has clarified the concept and importance of a Data Governance roadmap for you. If you'd like further support with your Data Governance initiative, book a call with me below.