Berichten

Free Frogs Data Governance Maturity ModelFree Frogs

Data Governance Maturity Models – Useless! Or not?

/in , /door

Data Governance maturity models can be a powerful tool for formulating improvement plans, communicating concepts and measuring progress, but they only work well when tailored to the specific context of the organisation.

I used to be convinced that Data Governance maturity models were highly overrated, with little or no added value. Nice pictures if you were lucky, standard terms that apply to most situations and a bit of extra fluff to sound clever.

A large part of my disapproval came from seeing multiple organisations struggling with Data Governance and seeing the (lack of) results achieved when using generic models, because little attention had been paid to organisation specifics including culture, actual data problems and the organisation’s goals and objectives. Any resulting output from the model was generally either irrelevant or too high-level to be useful. To make matters worse, because the output couldn’t be translated into a prioritized improvement roadmap, the end-result was usually a data governance effort which didn’t gain traction, got shelved, or was hugely inefficient.

I still have the same opinion of generic maturity models. However, if you take a generic maturity model and tailor it to a particular organisation, it is possible to identify specific improvement points within a short time frame. How do you do this? Tailoring the maturity model means focusing in on the organisation’s specific objectives, their actual data problems and the individual context within which the organisation operates. And adjusting the model accordingly.

Framing suggested improvements within an organisation-specific maturity model helps with focus, emphasising which particular data governance concepts need to be addressed and why this adds value. Tailoring the maturity model to the specific terms and language of the organisation helps with communication, highlighting where data governance fits into the overall picture. Prioritizing the improvements and translating them into a roadmap make the effort required even clearer, increasing enthusiasm levels as a result. And as this enthusiasm results in improved data governance, progression can be captured and shared by amending the maturity model graphic, generating yet more energy around the data governance programme.

Let’s make things more concrete.

Below is the generic Free Frogs Data Governance maturity model.

Free Frogs Data Governance Maturity Model

The various components of our overall view of Data Governance are visible in the model. However, we only use this generic version of the model in two specific situations.

(1)   The generic model provides an initial framework for discussions

Sometimes when people are new to data governance, it can be difficult to grasp how wide its impact is on a broad range of business issues. By using the model as a guide, we can focus discussions on the different aspects of data governance, their implications and their importance within different business situations. It provides a useful framework for the conversation around data governance, ensuring all important angles are covered; and it provides a handy memory aid to refer to in follow-up discussions and reviews.

The model also helps highlight that while different organisations have different data problems and priorities, it is still important to approach the specific data-related challenges within the context of the organisation’s overall data governance. For example, it’s almost impossible to have a conversation about data quality without also discussing definitions, master data and business rules; and it’s not very future proof to talk about data quality without also looking at lineage and culture.

(2)   The generic model provides an accelerant to the organisation-specific maturity model

The second situation in which we use the generic Free Frogs Data Governance maturity model is as a quick start to generate an organisation specific maturity model. Often, early on in conversations, it is already clear what pain is being experienced due to a lack of well-structured data governance. By placing these pain points within the context of the organisation’s particular goals, challenges and culture, we can focus in on the most relevant aspects of the generic maturity model. We then tailor these aspects to the organisation’s situation, adding in other organisation specific components and amending the language. This gives a more accurate picture of what needs to happen, than what is possible with a generic model. Additionally, an organisation specific model resonates more when we’re communicating.

After the model has been tailored to the organisation’s own situation, it can then be combined with the output of the data governance business case to quickly provide a concrete, prioritized, organisation-specific roadmap for the data governance effort.

The figure below shows one example of an organisation specific maturity model. In it, a subset of data governance subject areas with particular relevance to the organisation’s situation have been placed alongside other organisational factors to provide an organisation specific model.

Free Frogs Data Goverance Maturity Model Specific

It’s clear to see that a number of the subject areas are different to the generic maturity model. This tailoring helps the organisation focus on its particular data governance challenges. The model improves communication around data governance, highlighting which data governance aspects need focus if the overall added value of data in the organisation is to improve. When the underlying scoring level descriptions are shared, awareness of improvement steps needed becomes even clearer.

The tailored maturity model also gives an easy to understand overview of the original situation compared to the progression achieved in certain areas. Added to that, the underlying maturity model level descriptions and checklists provide concrete improvement points that the organisation can prioritize based on their unique situation of the organisation and translate into their data governance roadmap.

Conclusion: use a generic model only as an introduction; then switch to tailor-made to accelerate the data governance improvement efforts

Having compared the value of both maturity model uses outlined above I’m definitely a convert to the idea that a maturity model can add value, provided it is well thought out, and customized to the organisation’s situation. However, this has only served to further increase my perplexity for those in our subject area who try to apply standard data governance maturity models without thought to context, culture, and organisation specific challenges and goals. My advice: don’t do it!

Data governance MDM MDS Blog post Kees Molenaar

Master Data oplossing met behulp van Microsoft Master Data Services

/in , /door

In de vorige blog “De noodzaak van Master Data Management voor een datagedreven organisatie” is een casus geïntroduceerd. Deze blog gaat over het configureren van het Master Data Management (MDM) model aan de hand van deze casus.

Figuur 1: Focus van deze blog: Configureren

De vraag die in de vorige blog post nog niet is beantwoord is waarom we een MDM-oplossing nodig hebben. Het antwoord op deze vraag is heel simpel: er is vaak geen centrale omgeving waarbij de identificatie van entiteiten (personen, leveranciers, producten, etc.) wordt vastgelegd. Om tot een eenduidig beeld te komen is deze centrale identificatie-omgeving wel noodzakelijk en dit is precies wat MDM doet.

De drive voor een centraal beeld is tegengesteld aan de trend van specifieke oplossingen (veelal cloud) die als een lappendekken het systeemlandschap vormen. Als gevolg van deze versnippering is veel inspanning nodig om de centrale identificatie over elke individuele oplossing gelijk te houden. Deze synchronisatie van het zogenaamde ‘golden record’ is als gevolg van de grote hoeveelheid werk erg kostbaar. Om deze hoge kosten te vermijden kan ook precies het omgekeerde worden gedaan, namelijk alle systemen hun identificatie laten creëren en naderhand alle identificatiesleutels laten linken. De onderstaande implementatiebeschrijving laat stap voor stap zien hoe dit MDM-patroon te creëren is met behulp van Microsoft Master Data Services (MDS).

In de onderstaande afbeelding staat de functionele beschrijving van de casus die verder wordt uitgewerkt. Het doel is het aan elkaar relateren van alle voorkomens van een klant die in verschillende systemen is vastgelegd.

Figuur 2: de casus

Om dit patroon te kunnen realiseren met MDS zijn de volgende stappen nodig:

Figuur 3: Proces voor het configureren van het model

 

1.      Hoofdentiteiten aanmaken

Om dit patroon te kunnen realiseren moeten er twee objecten worden aangemaakt. Het eerste object is het master object, in dit geval Klant (zie figuur 3). Het tweede object is de bronidentificatie, in dit geval CRM, helpdesk, betaling en orderidentificatie.

Figuur 4: de elementen voor MDM, master en bron

Er wordt in dit patroon gekozen om alle bronnen te combineren in een entiteit in plaats van voor elke systeem (CRM, Helpdesk etc) een losse entiteit te maken. Dit komt de generieke toepasbaarheid van de oplossing ten goede en hierdoor is de uitbreiding met een nieuw systeem, bijvoorbeeld loyalty, geen aanpassing aan het patroon. Deze twee objecten kunnen gerealiseerd worden door twee entiteiten (entity’s) aan te maken in MDS, zoals de twee onderstaande afbeeldingen tonen.

Figuur 5 en 6: Entiteit voor de MDM klanten en voor bron klanten

 

2.      Beschrijvende attributen toevoegen

Standaard voegt MDS altijd twee attributen toe, namelijk code en name. Code is de sleutel van de entiteit en moet ook uniek zijn. Er zijn hier twee opties, optie 1 een vrije invoer of optie 2 een gegeneerd getal (Checkbox “create code values automatically”). Aangezien voor dit MDM-patroon de sleutel niet wordt bepaald door MDS blijft de checkbox “create code values automatically” uit. Om matching van de brondata te kunnen uitvoeren zijn er aanvullende attributen nodig die de identificatie ondersteunen. In deze casus zijn de beschrijvende attributen FirstName en SourceSystem.

 

3.      Testdata vullen

Als er data gevuld (web interface, Excel interface of load procedures) is voor SRC_customer ziet de data er in de web interface en in Excel zo uit:

Figuur 7 en 8: Overzicht van de bron klanten incl. data in de webinterface en in Excel

 

4.      Bron en master koppelen

De volgende stap is het koppelen van de verschillende voorkomens van klanten uit systemen aan één master record per klant. Het is van belang dat afgedwongen wordt dat alleen maar gekoppeld kan worden aan een waarde in de lijst van master records. Deze beperking wordt gerealiseerd door in MDS een “domain-based” attribuut toe te voegen aan de entiteit SRC_customer. Vervolgens kan geselecteerd worden onder “Domain Entity” welke entiteit gebruikt moet worden om deze beperking van waardes te realiseren.

Figuur 9: Domein gelimiteerde waardes toevoegen als attribuut voor SRC_customer

Het effect van dit domein-gebaseerde attribuut vertaalt zich naar een keuzeselectie zoals de onderstaande afbeeldingen tonen. Hierdoor kunnen er alleen “master klanten” gekoppeld worden aan voorkomens van klanten in overige systemen.

Figuur 10 en 11: Selectie van master klant middels de keuzeselectie in de web interface en in Excel

 

Nadat alle gegevens uit de bronsystemen zijn voorzien van een “master klant” is het onderstaande overzicht dan het resultaat:

Figuur 12: Eindresultaat: Alle klanten uit de bronsystemen gekoppeld aan een “master klant”

 

Door deze manier van implementeren met MDS te kiezen ontstaat een groot aantal voordelen:

  • Ontkoppeling
    De registratie en het beheren van masterdata zijn ontkoppeld. Zo ontstaat de mogelijkheid om over bronsystemen heen te koppelen zonder deze fysiek te moeten integreren.
  • Flexibiliteit
    Het hebben van een lijst met alle unieke master items is vaak geen gegeven. Met behulp van MDS kan de lijst met Master items (in dit voorbeeld MDM Customer) uitgebreid worden zonder dat deze in een ander systeem bekend hoeven te zijn.
  • Excel integratie
    Het toevoegen, verrijken en toewijzen van master items kan ook middels Excel. Hierdoor kunnen standaard Excel functies gebruikt worden.
  • Hoge mate van business acceptatie en verantwoordelijkheid
    Met behulp van de Excel functionaliteit is het mogelijk om de verantwoordelijkheid voor het beheer van master data te leggen bij de gebruikers zelf. Excel is een vertrouwde en breed gebruikte applicatie wat de acceptatie en het gebruik verder vergemakkelijkt.
  • Inbegrepen bij SQL Server enterprise edition
    De investering in Master Data tooling is beperkt mits er al een enterprise edition versie beschikbaar is van SQL Server.
MDM MDS Reeks

De noodzaak van Master Data Management voor een datagedreven organisatie

/in , /door

De behoefte van bedrijven en instellingen om datagedreven beslissingen te kunnen nemen groeit. Het is noodzakelijk om te beschikken over de juiste data en om een zo compleet mogelijk beeld te hebben van de eigen organisatie, klanten en partners. In de komende blogserie ga ik in op onderwerpen die randvoorwaarden zijn om datagedreven te kunnen worden.

Een belangrijk onderwerp hierin is Master Data Management (MDM). Dit onderwerp zal ik verder toelichten en ik leg uit wat dit betekent in het kader van datagedreven werken.

In de zoektocht naar het complete beeld moeten veel gegevens gecombineerd en geïntegreerd worden. Voor het maken van een klantbeeld is het bijvoorbeeld nodig om CRM-gegevens, helpdeskgegevens, betaalgegevens en ordergegevens te combineren. Om te komen tot het geïntegreerde klantbeeld moeten de klantgegevens gekoppeld worden. Er moet als ware een sleutelkastje komen waarbij alle sleutelgegevens van een klant worden verzameld. Lang niet alle systemen hebben namelijk dezelfde identificatie voor een klant, zoals onderstaande afbeelding laat zien. De sleutel is verschillend voor alle vier de systemen, terwijl dit wel over dezelfde persoon gaat.

Figuur 1 Voorbeeld Klantidentifiactiesleutels

Figuur 1: Voorbeeld klant identificatie sleutels van Klant 1

Behalve voor het bovenstaande voorbeeld voor het sleutelkastje voor klanten is dit principe voor nog veel meer soorten data toepasbaar, denk hierbij aan campagnes, locatiegegevens, producten en machines. Juist in het kader van IoT oplossingen is het koppelen van data over meerdere bronnen heen noodzakelijk, aangezien IoT oplossingen niet het hele beeld geven. Denk hierbij aan sensoren op een productiemachine, gekoppeld aan het onderhoudssysteem met de onderhoudsactiviteiten. Beide databronnen kunnen gecombineerd worden om juist de data van die specifieke machine te kunnen gebruiken om bijvoorbeeld het kapot gaan van de machine te voorspellen.

In de komende blogserie ga ik in op de mogelijkheden die Microsoft Master Data Services (MDS) biedt om in dit MDM-patroon te voorzien. De onderstaande onderwerpen worden behandeld.

Figuur 2 Processtappen MDM Voor MDS

Figuur 2: MDM processtappen voor Master Data Services (MDS)

De eerstvolgende blog zal gaan over het configureren van het model in MDS. Ik zal daarin de vraag “hoe implementeer ik dit patroon met behulp van MDS?” beantwoorden. De onderwerpen ‘Gegevens laden’ en ‘MDS gebruiken’ worden verder uitgewerkt aan de hand van het voorbeeld in figuur 1 met de verschillende identificerende sleutels van Klant 1.

The Benefits of Data Governance

/in , /door

Data Governance can be a hard sell. What can we do about it?

I was talking to a colleague the other day who was bemoaning the fact that Data Governance can sometimes be a really hard sell and I recognized what he meant. In some ways it’s similar to electricity. Or your wifi. When it doesn’t work, it’s immensely frustrating. However, when it does work, you don’t notice it and almost take it for granted.

When our data isn’t well organised, accurate or complete, we’re equally frustrated: it slows us down, stops us from answering certain questions or prevents us from generating the necessary insights. However, when our data is available, accessible, accurate and accompanied by the right context data, we rarely stop to appreciate it.

The Kano curve, captured in an article Professor Noriaki Kano wrote back in the 1980’s [1], describes this situation and provides some background as to why it occurs.

Although there are various interpretations of Kano’s graph, the basic theory describes a link between customers’ emotions and product success. Kano argues that a product or service is about more than just functionality: it is also about users’ reactions in response to the functionality and this reaction is dependent on the type of functionality delivered. It is this reaction which determines the success of the product or service and therefore we have to be clear about the types of functionality on offer and position information about the product or service accordingly. The basic premise is that there are (at least) three different types of functionality, or attributes:

  • When a product only possesses “threshold” attributes, i.e. basic features that users expect a product or service to offer, the best we can expect is that the customer will indifferent. (The worst case is that they will be frustrated when the threshold attributes aren’t available.)
  • If the product offers some performance attributes, users will begin to find the product or service attractive and this increases as the performance increases.
  • When “excitement” attributes are present, surprise features that users didn’t expect but that they are absolutely delighted by when they discover them, that’s when users start to become really pleased with a product.

So how does this relate to selling our Data Governance efforts?

If we recognize that Data Governance primarily delivers Threshold Attributes and Performance Attributes, we can use this knowledge when selling our Data Governance efforts to sell more effectively. If we’re also clear that it is not the Data Governance itself that delivers Threshold or Performance attributes, but rather the benefits delivered by Data Governance, our selling becomes even more focused. If we then add in which benefits we miss out on when our Data Governance isn’t well organised, we have multiple options to promote our Data Governance efforts depending on the priorities and motivational bias of our different stakeholder groups.

We can split this approach into a number of concrete steps.

(1)  Get clear which of the benefits we’re delivering are performance attribute benefits and stack them up

Kano’s theory proposes that no matter how many Threshold attribute benefits we deliver, we’re not going to make our users particularly happy. Therefore, we need to be clear what Performance attributes we’re delivering and promote these.

  • If our data is easier to link, we spend less time joining data sets together to answer questions and generate insights, so we get much more done in a day.
  • When a customer’s data is spread over various systems, if our master data management software pulls together an integrated view of the customer, we’re better able to help the customer when they phone our contact centre with a question.
  • If we can easily find the definition of a term used in a new dashboard, we can more quickly understand and interpret the figures shown and pinpoint why we’re experiencing a certain problem.

If we can list enough of these performance attribute benefits delivered by our Data Governance projects, our stakeholders better understand how Data Governance helps them and therefore why they should support it.

(2)  With threshold attributes, turn the message around

If some of our benefits relate to threshold attributes, we now know that the existence of these types of attributes doesn’t make users happy, but their absence does make users frustrated. Therefore, if we’re going to mention threshold attributes in our business case or sales pitch, we need to turn the message around. Instead of emphasising expected benefits, we need to get specific about the current problems, and their impact.

So rather than selling that we want to be able to compile a complete list of sales per product group or customers per region and the benefits this would bring, we can highlight how inefficient our processes are without these improvements. Rather than selling the benefits to be gained from having effective promotion data, we can make specific the problems we face when we can’t work out which promotions generate positive results and which promotions are failures, and how this affects our potential profits. Instead of promoting that with new customer channels we can increase the numbers of on-time payments, we can explain the risks we run when customers have unidentified poor credit records with us.

If we can explain the implications of our missing Data Governance, the current pain is felt more clearly. If we know we’re dealing with threshold attributes, we have to invert the message.

(3)  Focus on audience specifics

If we want to make our Data Governance sell more effective, we can further tailor it to our particular audience. There are various obvious ways to do this based on relevance, so I won’t go into these here. However, when looking at performance and threshold attributes, we can also group benefits into “towards” and “away” [2] and focus on which best fits our audience.

Toward people are focused on their goals and what they need to do to achieve them. They are motivated by improving, growing and moving forward. This energizes them.  Away people are more focused on what should be avoided or reduced. They are keen to minimise risk, reduce waste and are triggered when solutions will solve problems. They are more motivated by fixing things and preventing problems.

Both are valid points of view necessary in a balanced organisation. If we can recognize which trait is uppermost with a particular stakeholder or group, we can tailor how we present the benefits delivered by Data Governance more specifically, including whether we’re stacking up performance attributes benefits or inverting our threshold attribute benefits.

(4)  Link benefits to the wider strategy to add weight

Once we’ve clarified the benefits of our Data Governance efforts, focused on performance and threshold attributes and then split them into towards and away buckets, we can add extra weight by linking benefits to the overall strategy.

  • If our organisational goal is cost cutting, we need insights about which particular costs are most likely to spike so we can take preventative action to avoid this.
  • If we’re in a highly competitive market and marginal gains are the key to gaining a tiny extra sliver of market share, we need razor sharp context for our data to be able to identify the effects of the smallest tweaks to our approach.
  • If our goal is helping save the world by improving our record on sustainability, we need to be able to track our chosen metrics closely to see where we’re doing well and where we need to up our game.

In all cases, if the benefits of our Data Governance efforts can be linked to larger objectives, which in turn have a connection to the overall strategy, we have a stronger sell when attempting to persuade our stakeholders that Data Governance benefits are useful.

(5)  Make it personal

A final point in terms of making our Data Governance effort an easier sell is: make it personal. Where possible, focus in on specific user groups and collect their Data Governance stories and experiences to add real resonance to the message.

One way to gather these stories is to use the Data Journey. In each specific situation there are data creators and data consumers. They’re frequently not the same people, or even in the same team or department, and this disconnect can understandably lead to a mismatch of priorities.

The priority of the data creator may be to deal with a customer, issue or transaction as efficiently as possible, so he or she can get through as many cases in a day as possible. Maybe this leads to shortcuts in data entry, misspelling an entry or entering fake data in a mandatory field when there’s no time to look up or track down the correct data. (Maybe think about getting an MDM solution?) However, when the data consumer then accesses this data later in the process, attempting to achieve their goals, he or she discovers the data is incomplete, inaccurate or context-less.

We can use the Data Journey to reduce the likelihood of this problem occurring. Specific pairs of creators and consumers are encouraged to share their work experiences with each other to develop a common understanding both of the situation which leads to the inaccurate data capture and to the consequences. Together they come up with suggestions to improve the situation and together they take responsibility for improvements. A series of follow-ups take place to evaluate the suggested improvements and where necessary amend the approach. The resulting benefits can be specifically linked to these users.

The end result is that both the Data Governance effort and the resulting benefits are more personal. Rather than being impersonal business cases, the value generated makes a concrete difference for actual users and therefore resonates in re-telling far more than general examples would do.

To sum up, yes Data Governance can be a hard sell. However, with an approach which focusses on actual value in combination with a more nuanced delivery of benefits, we have good chance of selecting the right cocktail of possible Data Governance benefits, and optimal positioning, to ensure maximum resonance with each and every stakeholder.

 

  1. Kano, N., Seraku, N., Takahashi, F. and Tsuji, S. (1984) Attractive Quality and Must-Be Quality. Journal of the Japanese Society for Quality Control, 41, 39-48.
  2. Charvet, Shelle Rose (2015, 2nd edition) Words that change minds: mastering the language of influence

 

Image by ar130405 from Pixabay

5 Tips for Agile Data Governance

/in , /door

Agile Data Governance contains the same building blocks as traditional Data Governance. The key difference is approach. The more adaptive approach of Agile makes a big difference, both with effectiveness, and with how quickly we experience the benefits.

Agile used to be applied predominantly to software development. It’s now recognised that Agile methods have significant added value in a far wider set of business applications. Below are 5 practical tips for applying Agile methods to Data Governance.

1. Focus on frequent deliveries, each time delivering added value

Just as with software projects, short incremental deliveries can be applied to Data Governance efforts and offer various benefits, one of which is faster return on investment. Data Governance initiatives frequently used to experience business case hurdles when starting out. There are various reasons for this, one of which was that it was often an expensive ask. A far-reaching programme was scoped, involving organisational restructuring, new roles, extensive process remodelling and new policies, and results were typically only expected after the project had been running for a number of months.

Smaller, leaner business cases, ideally where the project quickly becomes self-funding, are generally far easier to get approval for than extensive programmes. If we are clear what business value we expect from each incremental data governance iteration, and if each iteration then delivers the expected return, we have a far more convincing business case for continuing with subsequent iterations.  I’ve sometimes presented this as a “rolling business case” concept, where each new iteration is financed by the improvement gained in the previous iteration. This approach is particularly useful in organisations where budget availability or lack of understanding about the added value of Data Governance is blocking progress. Concrete returns are more difficult to dispute than optimistic projections.

As the value of Data Governance becomes more widely understood, it is more common for management to start with positive expectations. Providing faster returns which regularly add concrete value in the organisation helps keep both senior management and other stakeholders enthusiastic and engaged.

2. Ensure each iteration delivers usable products, so constant evaluation is possible

A key principle of Agile focuses on early and continuous delivery of value. Closely related to this is the concept of failing fast in Lean.  Eric Ries popularised the term “Minimum Viable Product” (MVP). In his book “The Lean Startup” he explains how MVP can be used to implement efficient validated learning using the Build-Measure-Learn feedback loop to quickly discover when we’re on the right track to deliver value and when we need to change direction.

If we start rolling out Minimum Viable Products early in our Data Governance efforts, we will quickly be able to gather stakeholder feedback about what works and what doesn’t. A huge benefit of this approach is that we can use the feedback we receive to tweak or, where necessary, completely overhaul the Data Governance building blocks we’ve implemented. If particular roles, responsibilities, data governance technology solutions or process changes aren’t generating the improvements we expected, we can evaluate why and change course.

A second benefit of this approach is that our users are more engaged because they experience benefits early on. Rather than having to wait for concrete returns as we set up a wide-ranging programme, our users begin to experience the measurable benefits of cleaned up data, complete data sets, more accurate definitions and sharply defined context within a couple of iterations. This is hugely motivating, especially if users have already lived through multiple failed Data Governance programmes.

3. Support, trust and motivate the people involved

Data Governance efforts usually contain a large people component, whether it’s gently nudging users to perform new activities, encouraging them to be more careful with their data quality or getting them thinking about and agreeing on definitions.

One of the underpinning principles of Agile is collaborative working as a way to empower users, stating “projects are built around motivated individuals, who should be trusted”. As with all change programs, if people understand why new work methods or extra effort is being asked of them, they are more likely to go the extra mile. Similarly, if they believe certain returns are possible, they are more likely to display the personal motivation required to make Agile working, in this case Agile Data Governance, a success.

Stakeholders should be given clear input about what is required of them and why. They should be given both the mandate and the necessary time to carry out any additional tasks required of them. They should be trusted to perform the extra activities required and the benefits of doing so should be clearly communicated. And they should be roundly praised for all improvements this leads to. Agile Data Governance often asks users to put in extra effort. They are more likely to stay enthusiastic and committed if they understand the benefits their efforts bring and if they are recognised for their extra work.

4. Focus on simplicity

One of the core aspects of Agile working is minimizing waste. Agile principle number 10 states “Simplicity – the art of maximizing the work not done – is essential”.

Data Governance programmes used to be herculean undertakings where considerable time was spent developing new organisational structures, committees, policies and processes, often before any benefits were felt by the organisation. Current wisdom focuses more on scaling back activities to the minimum required to generate returns.

Rather than investing effort changing organisational structures as a prerequisite to nominating data stewards, data custodians and data governance managers, we are now more likely to see virtual teams created. Often these are staffed with existing roles who have been given additional Data Governance responsibilities. Only if users enjoy their new responsibilities and the virtual team set-up delivers the anticipated extra value, is it worthwhile to formalise the extra responsibilities and implement any required organisational changes.

Similarly, instead of drafting lots of new processes and policy changes which ultimately may not be necessary, users can try out various process and policy suggestions. Once the best options are clear, these can be implemented. Subsequent iterations can then be used to improve, extend and formalize the implementation where necessary. At no point in Agile Data Governance is theory put before practice, or bureaucracy before concrete returns.

5. Regularly reflect on how to become more effective

Last but not least, most Agile methodologies contain a significant amount of reflection. In Scrum, there is a retrospective at the end of every sprint, where we evaluate what has worked and what can be improved upon. Lean has the learning loop, among other tools. Regularly reflecting on and evaluating how things are going, which aspects work well and were we can improve can greatly improve our effectiveness.

If we are going to get the most out of our evaluations, it is very important that we are honest with ourselves and this is easier in a safe environment. If people are afraid to voice concerns because of negative feedback or because it may have a negative impact on the overall project, the reflections will be less effective.

Equally important is that the output is evaluated and where possible, applied so that improvements are made. If reviews take place and the results are then put in a cupboard, people quickly loose interest. The regularity of the reviews is also important. If our reviews are too infrequent, important learning moments will be missed.

Finally, while lessons learned are important improvement tools, we also need to focus on the positives and celebrate our successes. By promoting our good news stories, we not only help keep key stakeholders motivated, we also inspire the rest of the organisation to get on board with Agile Data Governance.

If you would like more information about how we approach Agile Data Governance in Free Frogs, we would be delighted to hear from you. Please mail us at datagovernance@freefrogs.nl.