How to use a Lean Approach to Data Governance

Getting a data governance initiative started can be extremely challenging.  This is especially true if you work in an unstructured manner, trying to start too many tasks at the same time or doing things in the wrong order.

Over the years I have developed my own methodology for implementing Data Governance successfully.  This is based on my experience of what has worked successfully (as well as what hasn’t) over many years of implementing Data Governance.  Although I got into Data Governance by accident when I was a Project Manager, I had never particularly considered whether a lean approach could be applied.  So, when I was first asked whether a Lean approach would work for implementing Data Governance, I decided to look into it.

It didn’t take me long to realize that I have incorporated some of the lean principles into my approach without realizing it and that a lean approach would definitely be a good way to structure a Data Governance implementation.

To be successful, data governance needs to be implemented iteratively and efficiently and that is why applying lean principles to data governance works so well.

What is Lean?

Lean was originally created by Toyota to eliminate waste and inefficiency in its manufacturing operations. The process became so successful that it has been embraced in manufacturing sectors around the world and is now used in many different industries as it can improve how teams work together.

The goal of lean is to eliminate waste, i.e. the non-value-added components in any process. The idea being that until a process has gone through lean multiple times, it contains some element of waste. When done correctly, lean can create huge improvements in efficiency, cycle time, and productivity, which leads to lower costs and improved competitiveness.

The Lean Enterprise Institute (LEI), founded by James P. Womack and Daniel T. Jones in 1997, is considered the go-to resource for lean wisdom if you want to learn more about the details, but for this blog I want to focus on why it is a good approach for Data Governance.

Lean principles are all about the following initiatives:

• Empowering small teams

• Reducing cycle times

• Gradually eliminating waste

• Focusing on value

So let’s look at each of these in turn:

Empower Small Teams

Lean improvements start with people, and the same can be said for data governance. Applying lean principles allows you to focus on your team first.

Instead of creating a huge project team to implement data governance, setting up a small central team to support users across your whole business will have greater success.

Rather than being responsible for all data, a small data governance team can focus on:

• Identifying and maintaining existing data management activities

• Providing a framework for managing and aligning existing data management activities, and planning for future activities

• Coordinating the implementation of the data governance framework

• Acting as a liaison between the Business and IT to verify that business requirements are fully understood by IT and ensure the business is fully engaged in IT led projects

Reduce Cycle Times

Many data governance initiatives fail because they are too big in scope, cost, and timescales. Working on small phases or projects will more likely lead to success.  For example, try executing one process in a business area. When that is completed, implement that same process in the next business area.  Don’t try to achieve too much at once; if the data governance programme is too large and unstructured, the benefits will not be delivered efficiently and the entire programme might get stopped.  If you focus on small areas of scope, you are likely to achieve small but consistent successes in the implementation of your data governance framework.

Gradually Eliminate Waste

Implementing a data governance program through small frequent phases (or projects) allows you to use the lean problem solving approach: The Plan – Do – Check – Adjust (PDCA) Cycle.

For example, the initial plan step would review the business area you are intending to implement data governance in and take measures to fully understand the current situation.  What are the priorities and challenges in that area? This knowledge will enable you to plan the implementation for a data governance framework that will benefit that area.

In the do phase, you will implement the framework and identify and brief various stakeholders about their roles and responsibilities. During this phase, prepare stakeholders to start following one of the data governance processes or activities, such as defining data items for a data glossary, or using a data quality issue resolution.

Next you check the results of the do phase, confirm they align with expectations, and identify what can be learned from the experience. Determine if anything should be done differently next time.

Finally based on the insight gained, you can either adjust your approach before planning to implement the framework in a new business area or move back to the do stage to make changes in the first business area.

Focus on Value

Taking inspiration from George Orwell’s Animal Farm, we could say that all data is equal, but some data is more equal than others.  Lean uses prioritization techniques to focus on areas where you can gain the most value, and the same approach can be applied to managing data.  You can’t achieve value from managing all of your data with the same level of monitoring and control.  The highest level of monitoring and control should only be applied to the most critical data, needed to successfully run your business (I talked about this in more detail in this recent blog).  Applying lean principles and prioritising data governance activities for data that adds the highest value for the lowest effort will help engage stakeholders and demonstrate the benefits of data governance, while long-term activities (i.e. high value and high effort) progress.

Business engagement is absolutely vital to the success of all data governance activities, and underpinning these activities with the solid foundation of a data governance framework will help you achieve lasting data governance success.

Don’t try to do too much at one time. If your data governance initiative is unwieldy, it will be too big to get started and too slow to deliver benefits.  Applying a lean approach to data governance can help you work iteratively, checking and improving as you go and focusing your efforts on activities that will deliver the greatest value to your organization.

My Data Governance Checklist gives you a structured approach to design and implement a successful Data Governance Framework. You can download the free version of this checklist here.

Critical Data and Master Data - what is the difference?

In a recent blog, I looked at why you should prioritise your data and identify the data that is the most critical or material to your organisation, so you can focus your data governance efforts on that data. In response to that blog, I had a number of people contacting me to ask what was the difference between critical data and master data, so I decided that it would make a good topic for this blog.

As it is common for the two to get confused, let's look at each in turn:

My go to reference point for all definitions to do with data is the dictionary published by DAMA International (the Data Management Association). However, I was disappointed to find that there is no definition of critical data in there. Luckily with the help of Google, I managed to find the following definition:

“data that is critical to success in a specific business area”

In other words, it is the data required to get the vital processes completed.  And don’t forget that data critical to one business area may not be critical for another.  When this happens you have to manage the data to its highest level of criticality.   

That seems simple enough doesn’t it? So let's look at the definition of master data. This time, the DAMA Dictionary of Data Management comes up trumps and provides the definition as:

“The data that provides the context for business activity data in the form of common and abstract concepts that relate to the activity. It includes the details (definitions and identifiers) of internal and external objects involved in business transactions.”

Now, this is a wordy definition and while technically correct, it may not be helpful if you are not already familiar with the term master data.

Whenever I teach courses on Master Data Management I use this definition but like to highlight the key words in bold as follows:

“The data that provides the context for business activity data in the form of common and abstract concepts that relate to the activity. It includes the details (definitions and identifiers) of internal and external objects involved in business transactions.”

 For me the most important idea is that it is the data which provides the context for a business activity. For example if you considered a banking transaction, you have two sets of data.  The data about the transaction itself (how much was paid in, where and when) and you have the contextual data that enables you to identify the customer and the account:

From the image above you can see that the transactional data will change every time there is a transaction, but the master data would stay the same.

Master data is sometimes described as the most valuable data shared across an organization. If you consider the case of customer data (a data domain frequently “mastered”), it is common for customer data to exist on multiple systems across an organisation and unless you “master” the data – i.e. match and merge that data to create one record you cannot understand the extent of your relationship with a particular customer.  In order to match and merge customers you need to look for identifiers (as mentioned in the official definition) such as date of birth, address or post code. This enables you to create what is often called a “single customer view”.

Customer data is not the only data domain that you might want to consider mastering, product data, employee data and supplier data are all typical areas where master data is found.

 If critical data is something that is vital to your organisation, 

how is that different than master data?

The confusion between the two terms comes about because they are used for different purposes. Master data is nearly always critical to your business, but your critical data could include non-master data.

I do hope this has helped clarify the difference and if you are embarking on a master data project of any kind you may find this checklist useful as it details the activities you need to consider when implementing Data Governance as part of a Master Data project.

Data Owners and Data Stewards - What is the difference?

My last blog about how you identify your data owners stimulated a lot of interest, but also a lot of questions. One question in particular, I have been asked many times over the years (in fact, I got an email asking the very same question while I was actually drafting this blog) is the topic of this blog:

What is the difference between Data Owners and Data Stewards?

This topic does cause a lot of confusion. If you do some research online you will find many articles that discuss Data Ownership and Data Stewardship as well as Data Governance. This could easily lead you to believe that there are two or even three separate data management disciplines being discussed. To clarify the situation - Data Ownership and Data Stewardship are important components of Data Governance (although not the only components).

I believe quite strongly (and may have mentioned it once or twice before) that there is no such thing as a standard Data Governance framework. But I do believe that there are three key things you have to include in your Data Governance framework for it to be successful:

The three things as you can see from the image are policy, processes, and roles and responsibilities and they form a key part of my methodology.   It is the last category, roles and responsibilities, which covers both Data Owners and Data Stewards 

To understand the differences we should look at what each of these roles do. Let's start with the more senior of the two: Data Owners. If you've been following my blogs for any time, you will also know that they don't have to be called Data Owners (if you face resistance using this role title, you should call them an appropriate name that works for your organisation).  You can read more about this here.  But for this article we will stick with the more common role titles. 

Data Owners are senior stakeholders within your organisation who are accountable for the quality of one or more data sets. That sounds nice and simple, but covers activities such as making sure there are definitions in place, action is taken on data quality issues and Data Quality Reporting is in place. 

To be suitable to be a Data Owner, they have to be suitably senior in your organisation. They need to have the authority to make changes and also have either the budget or resources available to them to undertake data cleansing activities. If they don't have that authority and resources available, they won't make an effective Data Owner. 

Now, you may be reading that thinking, “if they're that senior, do they really understand the detail of the dataand do they have time to do all the things listed?”  That's a fair point and why I use the role of Data Stewards. I ask Data Owners to appoint one or more Data Stewards to assist them in their responsibilities. 

For many years, I wrote separate role descriptions, where I diligently listed everything that both the Data Owners and Data Stewards have to do.  To be honest the activities were largely the same, I just changed the language from saying “accountable for”in the Data Owner description to “responsible for”for Data Stewards.  

A few years ago I realised that there was a far simpler way: I now just write the detail for the Data Owner role and include words to indicate that a Data Owner may appoint one or more Data Stewards to assist them to undertake these responsibilities on a day to day basis. 

 How does it work in practice?

If you were talking about writing a data definition, you would say that a Data Owner is accountable for that definition. In practice, you would expect the Data Steward to be responsible for drafting that definition and presenting it to the Data Owner for them to approve.

Or if you were looking at a data quality issue, I would expect a Data Owner to be responsible for investigating and agreeing remedial actions. In practice, the Data Steward would do the research and propose appropriate remedial actions to the Data Owner to approve.

Another related question I am often asked is: 

Do you need both Data Owners and Data Stewards?

There is no standard answer to that question as it depends on the size of your organisation. For large organisations you probably do need both roles. If you don't have a lot of staff, you may not. 

I've worked with two organisations who both had approximately 200 staff. When we worked out who the most appropriate Data Owners would be and asked them to nominate their Data Stewards, we were close to half the employees of the organisation being either a Data Owner or Data Steward, which clearly is not useful.  The solution was different for each company:

In one organisation, we changed the level of seniority of the Data Owners to the next level down. They still had authority, but also had the time and expertise to understand the subject matter in more detail. In that company, the role of Data Steward was not used.

In the other organisation the right thing was to keep the Data Owners suitably senior (i.e. the Finance Director was the Data Owner of Finance Data), but instead of having multiple Data Stewards per Data Owner, each Data Owner nominated one Data Steward to act as deputy and help them with their Data Governance responsibilities.

You may not need both roles,  it depends on the size of your organisation. You need to work out whether you need both (and what you call them) to make data governance successful in your organisation.

To summarise, Data Owners and Data Steward are not the same role, but they are involved in the same activities. The Data Owner is accountable for the activities and the Data Steward is responsible for those activities on a day to day basis. 

Identifying appropriate roles and responsibilities is only one of many things on my data governance checklist. You can download the free version of this checklist to help you design and implement a data governance framework successfully here.

How To Identify The Right Data Owners?

One of the items on my free Data Governance Checklist is “Define roles and assign responsibilities”. Now that is a generic statement that covers a number of different roles, but the role which I always start with (and believe that you should too) is that of Data Owner. By that, I mean the senior individuals in your organization who are accountable for the quality of one or more data sets. And don’t get worried if you have decided to call that role something else – that is perfectly acceptable and the naming of roles is something that I covered in this old blog: A Rose By Any Other Name.

At the Data Governance Clinics that I run one of the most frequent questions is how you find the right people to be the Data Owners in your organization. Anyone who has ever tried to implement Data Governance understands how important it is to have the correct people in these roles, but it can be hard to actually identify them. So I thought I would share a simple approach that I use for identifying the correct data owners:
I like to start by looking at the various departments and their relationship with a particular dataset. If I was trying to find the Data Owner for customer data, I would start by finding out which business area feels the most pain when customer data is wrong. I ask lots of questions like:

· Who cares when the data is wrong?
· Which team is likely to be the first to identify data quality issues with customer data?

Some people believe that the Data Owner should always represent the area that captures or enters the data. In my experience, this is sometimes the case, but you should not rule out the possibility that the owner may sit somewhere else within the organization.

Wherever they are, they must have an interest in the data, but this can be either as a data producer or as a data consumer. If they are neither of these, it is unlikely that they have sufficient interest in the quality of that data to undertake the role properly.

Once you have identified the department that seems to have the most interest in the data, you can then identify the individual best suited to take on the role of Data Owner. Remember that for them to be able to improve the quality of the data, the candidate Data Owner needs to be suitably senior and have resources at their disposal. So identify the individual in that area who has:

· The authority to change business processes and IT systems to improve data quality
· Access to budget and resources to be able to resolve data quality issues
· The ability to instigate data cleansing activities.

If you find the person who fits these criteria, they are very likely to be the right Data Owner. This approach has always worked for me, although sometimes it can take you in unexpected directions. For example, in one Personal Lines Insurance Company when I was trying to identify the Data Owner for Customer Data I ended up following this route:

First I approached the Underwriters – after all, they decide who gets an Insurance Policy and what data is needed on the customers for that decision to be made. However, they explained to me that as their company was a high volume personal lines firm, they did not get involved with individual policies and had no interest in specific data about individual customers.

Next, I tried the Service Department. These were the teams of people who speak to customers on the telephone and enter their details on the system. But again they had no real interest in the quality of the data. They did not decide what gets captured, nor did they use the data so did not feel any pain if it was wrong.

Finally after asking lots of people who used Customer data and who cared if it was wrong, I found myself meeting one of the Marketing Directors. I didn’t hold out much hope that they would be the Data Owner of Customer Data, but it turns out I was wrong. In that particular company, the Marketing Department was responsible for sending out renewal letters to customers. If the customer data was wrong the renewals did not reach the customers and there was a strong possibility that business would be lost. As soon as I explained that I was trying to identify the Data Owner for Customer Data, they immediately agreed it was them as they had such an interest in the quality of that data.

I hope this will help you identify the correct Data Owners for your organization, but remember that just because you have worked out who it should be, it does not mean that they will necessarily agree. Your next activity will be to practice your influencing and communication skills!

Remember that finding the right Data Owners is only one of the items on my free Data Governance Checklist, you can download the checklist here to see what other activities you need to be doing to implement Data Governance successfully.

Do You Need To Prioritise Your Data?

This year I've tried to stick to a regular schedule of creating and posting blogs. However, as many of you will have noticed, I failed abysmally a couple of weeks ago. A number of family illnesses and emergencies meant that I was unable to work as many hours as usual. And my blog writing time was spent looking after my husband and other family members.

It wasn't just my blog writing activities that got curtailed.  I am very grateful to my clients who very kindly agreed to reschedule planned workshops. They were fantastic and understood that I had to prioritise my family over my work for a short period of time.

What amazes me, though, is that so few people think to take the same approach to their data. After all, is all of your data equal in value? Would it be fair to say that some is “more equal than others”?

What I mean by this is that not all of your data needs to be as proactively managed, monitored and controlled. In fact, to do so, would make data governance a burden or a hurdle to people actually carrying out their day to day activities. This is never the point of data governance. I believe that the point of data governance is to identify the most important data and manage that data proportionately to the value it has to your company.

I first came across this concept when working in the insurance sector. One of their regulations is Solvency II.  It primarily deals with the capital adequacy of insurance firms, but at the same time asks for data governance to be put on place over all data being used in the capital adequacy calculations. However, the regulator realised a really important point, in these rather complex calculations, some data is very important, and other data is included just for context. Now, if that latter data is wrong or missing, it would have either no or a negligible impact upon the final calculation. Therefore, the regulator said they didn't expect you to put the same level of data governance in place over that data as opposed to the data which is really important and would actually result in the significantly wrong numbers being calculated.  

As soon as I started trying to work this out for the first insurance company I worked with, It made sense to me. I quickly realised that focusing your efforts on the most important data was the right thing to do for data governance. Since that time, I have encouraged every client, regardless of which sector they operate in, to adopt this approach.

 Solvency II gave a name for this approach - materialityi.e.  it is about identifying your most material data and managing that appropriately.  However, be aware that calling it “material data” may not work for you. In fact, I was told in no uncertain terms by a German manufacturing client of mine that the term materiality most definitely does not work if your company uses materials to make something as material data means something else entirely in that context!    

We agreed that this would cause confusion rather than be useful. And for that client, and many others since, we have chosen to call it critical data.

Identifying your critical or material data is a very sensible and pragmatic approach, but not necessarily an easy one. You will need to define some criteria for what each level of criticality means so that Data Owners can assess the data that they own against the criteria and decide whether it is critical or not. 

There is also the interesting question of how many levels of criticality you need?

 My preference is for three levels:

High criticality or high materiality is the data that is the most valuable to your business and would have the most negative impact if it was of poor quality.

Medium criticality or medium materiality is data that is important, but would not have such a large impact if it was of poor quality.

Non-material or Non-critical data is the data that is useful, and perhaps adds context but would not cause great problems if it was not of the best quality.

Over the years, some clients have preferred to go for just two levels of criticality i.e. it either is critical or it isn't. But that feels a bit too much like an all or nothing approach. Data either has lots of controls, standards, data quality monitoring and reporting in place, or it has nothing. 

One client, asked me to implement five levels of materiality. I'll be honest, I really struggled to differentiate between the different levels of data governance that you would apply across five categories and ultimately, we rationalised it back to three.

Whatever you call it, and however many levels you decide is right for your organisation, I really would encourage you to try this approach in your data governance initiative. Anyone who regularly reads my blogs will know that I advocate a pragmatic approach. You really can't manage all data perfectly. So why not identify the data that is the most important to your organisation, and manage that appropriately?

Taking such an approach makes it far easier to manage the workload, particularly when you're in the early stages of a data governance initiative. So If you look at the activities on my free data governance checklist, you might decide that some of this needs to be done for all data. But some of the activities you may only wish to do for things that are high or medium materiality data. In this way, you can agree a phased approach of appropriate management on your data according to how important it is to your organisation.

Why You Need Data Governance

In this blog I’m going to look at why you really should do data governance. When I tell people what I do, I get a mixed response. Some people seem genuinely surprised that everyone isn’t already doing Data Governance, and an awful lot of people ask why would you need that?

Now I’m biased, as I believe that every organization would benefit from implementing data governance. It may not solve all problems, but it really does provide a framework which can be used to proactively manage your data.

A few years ago the main driver of Data Governance initiatives was regulatory compliance and while that is definitely still a factor, there is a move towards companies embracing Data Governance for the business value which it can enable. For example if your organisation is starting a digital transformation or wants to become “data driven”, you are not going to be successful if your data is currently not well understood, managed and is of poor quality.

If you embrace Data Governance and achieve better quality data, all sorts of benefits start to be seen. But you don’t have to take my word for it; take the DAMA DMBoK Wheel for instance: 

As you can see, it lists all the Data Management disciplines around the outside of the wheel. There in the middle, at the heart of it all, is Data Governance.  Now it didn’t just get put in the middle because there were no more spaces on the outside of the wheel – it’s there for a reason. Data Governance provides the foundation for all other data management disciplines.

Let’s look at a few of these disciplines to illustrate the point:

Data Quality

Without Data Governance all data quality efforts tend to be tactical at best. This means a company will be constantly cleaning or fixing data, perhaps adding default values when a key field has been left blank. With Data Governance in place, you will have processes, roles, and responsibilities to ensure that the root causes of poor data quality are identified and fixed so that data cleansing is not necessary on an on-going basis.

Reference and Master Data

Anyone who has been involved in any master data projects will have no doubt heard or read numerous dire warnings about the dangers of attempting these without having Data Governance in place. While I am not a fan of wholesale scaremongering to get people to embrace Data Governance, these warnings are genuine. For master data projects to be successful, you need data owners identified and definitions of all the fields involved drafted and agreed, as well as processes for how suspect matches will be dealt with. Without these things (which of course Data Governance provides) you are likely to be faced with a mess of under, over or mismatching!

Data Security

Of course Data Security is primarily an IT managed area, but it makes things a lot easier to manage consistently if there are agreed Data Owners in place to make decisions on who should and should not have access to a given set of data.

I hope you agree that these examples and explanations make sense, but don’t forget that is theory; and explaining this in data management terms to your senior stakeholders in order to get agreement to start a Data Governance initiative is unlikely to be successful. Instead, you are going to need to explain it in terms of the benefits it will bring. The primary reason to do Data Governance is to improve the quality of data.  So the benefits of Data Governance are those things that will improve, if the quality of your data improves.  This can cover a whole myriad of areas including the following:

Improved Efficiency

Have a look around your company. How many “work-arounds” exist because of issues with data? What costs could be reduced if all the manual cleansing and fixing of data were reduced or even eliminated?

Better Decisions

We have to assume that the senior management in your organization intends to make the best decisions. But what happens if they make those decisions based on reports that contain poor quality data? Better quality data leads to more accurate reporting.

Compliance

Very few organizations operate in an industry that does not have to comply with some regulation, and many regulations now require that you manage your data better. Indeed, GDPR (the General Data Protection Regulation) impacts everyone who holds data on EU Citizens (customers and employees), and having a solid Data Governance Framework in place will enable you to manage your data better and meet regulatory requirements.

So, at this point you are probably thinking, “isn’t it just a generic best practice thing that everyone ought to do?” And the answer is, yes – I do believe that every organization could benefit from having a Data Governance Framework that is appropriate for its needs.

What Happens if you Don’t Have Data Governance?

Well I’ll leave that to you have a look around you and decide what the likely consequences for your company could be, but it is usually the opposite of the benefits that can be achieved.

Remember data is used for dealing with your customers, making decisions, generating reports, understanding revenue and expenditures. Everyone from the Customer Service Team to your Senior Executive Team use data and rely on it being good enough to use.

Data Governance provides the foundation so that everything else can work.  This will include obvious “data” activities like Master Data Management, Business Intelligence, Big Data Analytics, Machine Learning, and Artificial Intelligence.  But don’t get stuck thinking only in terms of data.  Lots of processes in your organization can go wrong if the data is wrong, leading to customer complaints, damaged stock, and halted production lines. Don’t limit your thinking to only data activities.

If your organization is using data (and to be honest, which companies aren’t?) you need Data Governance.  Some people may not believe that Data Governance is sexy, but it is important for everyone.  It need not (in fact it should not) be an overly complex burden that adds controls and obstacles to getting things done. Data Governance should be a practical thing, designed to proactively manage the data that is important to your organization.

Just one final word of advice: I hope that this article has convinced you that your organization needs to embrace Data Governance; but if that is the case, please don’t just spout the generic benefits and examples I have shared here in your efforts to gain stakeholder buy in. It is very important to spend time working out the specific reasons your company should be doing Data Governance. You can find more advice on that and how to engage your senior stakeholders here.

Does it have to be called Data Governance?

This is a question that I get asked fairly regularly. After all it is not an exciting title and in no way conveys the benefits that an organisation can achieve by implementing Data Governance. Sadly however, there is no easy yes or no answer. There are a number of reasons for this:

1. Data governance is a misunderstood and misused data management term

Naturally I am biased, but in my view, data governance is the foundation of all other data management disciplines (and of course therefore the most important). But the fact remains that despite an increasing focus on the topic, it remains a largely misunderstood discipline.

On top of this, it is a term which is frequently misused. A few years ago, a number of Data Security software vendors were using the term to describe their products. More recently the focus on meeting the EU GDPR requirements has led to a lot of confusion as to whether Data Protection and Data Governance are the same thing and I find that the terms are being used interchangeably. (For the record, having Data Governance in place does help you meet a chunk of the GDPR requirements, but they are not the same thing).

Having more people talking about Data Governance is definitely a good thing, but unless they are all meaning the same thing, it leads to much confusion over what data governance really is.

I explored this topic in a bit more detail in this blog: Why are there so many Data Governance Definitions?

In order to understand whether Data Governance is the right title for your organisation to call it, I would start with looking at how you define data governance. And this step leads nicely to the next item for consideration.

1. Sometimes it is right to include things which are not pure data governance in the scope of your data governance initiative.

This is a topic that I covered in my last blog which you can read here.

To summarize that article, it is just not possible to have one or more people focus purely on Data Governance in smaller organisations. It’s a luxury of large organizations to be able to have separate teams responsible for each different data management discipline (e.g. Data Architecture, Data Modelling or Data Security).  Going back to my point above, if data governance is the foundation for all other data management disciplines, it is only natural that the line between them can sometimes get a little blurred. As a result of this, the responsibilities of the Data Governance Team can get expanded.

So consider what is included within the scope of your data governance initiative and decide whether it be more appropriate to name the initiative and your team (either or both)  something that is more aligned to the wider scope of the initiative and activities of the team.

Is the name going to make cultural change harder to achieve?

Achieving a sustainable cultural change is one of the biggest challenges in implementing data governance and insisting on calling it “data governance” could make achieving that cultural change more difficult if the term doesn’t resonate within your organization. This is related to a topic that I explored in another old blog Do we have to call them Data Owners?

Whether we’re talking about the roles, the team, or even the initiative the same principles are true. It is better to choose a name that works for the culture in your organization than to waste considerable effort trying to convince people that the “correct” terminology is the only one to use.

It would be my preference to explain that the initiative is to design and implement a Data Governance Framework, but if the primary reason for implementing data governance is to improve the quality of your data, perhaps calling it the “Data Quality Team” and “Data Quality Initiative” would fit better? After all, that very much focuses on the outcome of what you’re doing.  It also addresses the question that everybody asks (or should ask) when approached to get involved in data governance of “why are we doing this,” which is usually followed by “what’s in it for me?”

When having these conversations, I explain the initiative in terms of its outcomes (e.g. better quality data which will lead to more efficient ways of working, reduced costs and better customer service). That is a far easier concept to sell rather than implementing a governance structure, which can sound dull and boring.

Is the name causing confusion?

In the early days of a data governance initiative, the talk is all about designing and implementing a data governance framework. Once this work has been achieved you start designing and implementing processes which have “Data Quality” in their titles:

• Data Quality Issue Resolution

• Data Quality Reporting

I have been fortunate enough to work with organizations in the past who have had both a Data Governance Team (supporting the Data Owners and Data Stewards) and a Data Quality Team (responsible for the processes mentioned above) but that is fairly unusual in my experience. It is more common for the Data Governance Team to support the above processes. So it is worth considering whether it would confuse people if they had to report data quality issues to the Data Governance Team?

In summary, I would not want to miss the opportunity to educate more people on what Data Governance really is. But the banner under which it is delivered can be altered to make your data governance implementation both more successful and more sustainable. So if having considered all the points above in respect of your organization and you want to call it something else, then that is fine with me.

Deciding what to call your initiative is only the start of many things you need to do to make your Data Governance initiative successful.   You can download a free checklist of the things you need to do here. (Don't forget this is a high level summary view, but everyone who attends either my face to face or online training gets  a copy of the complete detailed checklist which I use when working with my clients.)

What should you include in a Data Governance initiative?

One of the many challenges you will have to face when implementing Data Governance is agreeing the scope of the initial phase of your initiative. By this I don’t just mean which data domains or business functions are going to be in scope. I’m thinking of associated activities like data retention, end-user computing, and data protection. Being a bit of a Data Governance purist I maintain that such activities are most definitely NOT data governance. It is easy therefore to make the logical conclusion that they should not be in the scope of your initiative. So what I say next may surprise you:

Do not immediately go on the defensive and refuse to take any (or even all) of these activities into the scope of your initiative!

Now you may be wondering why someone who spends her time educating people on what Data Governance is would say that! Well, when I’m training and coaching people it is important that they understand what Data Governance is, but when I’m implementing Data Governance in practice, I take a pragmatic approach.

However, I would not want you to think that I would just say yes to an ever-expanding scope. There are a number of factors that would make me consider bringing these additional data activities into the scope of my data governance work, which include:

• If you work for a small organization that does not have the luxury of separate specialist teams to cover each data management discipline;

• If they overlap with other projects ongoing at the same time;

• Or if a senior stakeholder requests it.

Whilst you may become aware of other activities that you want to bring into scope, they are most likely to come to your attention through your senior stakeholders – so let’s consider this question:

How do you manage senior stakeholders who ask you to extend the scope of your initiative?

Now whilst it may be tempting to protect the scope of your initiative, remember they have their own agenda. They are not trying to derail your plans, they just have concerns of their own or issues that they need addressed. The first thing you are going to need to do is to listen and understand what their concerns are before you try to educate or influence them. After all, how can you properly allay their concerns if you don’t fully understand them?

But remember whilst it is imperative that you understand why they’re asking you to extend the scope, when I say educate or influence them, I don’t mean your initial stance is to say no! When talking to your senior stakeholder, ask lots of questions and constantly consider the following:

• What exactly does this person need done?

• Does it have any alignment or overlap with your data governance work?

• What will happen if this additional work does not get done? (And in particular will it cause a problem for your data governance initiative?)

Even if the answer to this last question is no, it may still be necessary for you to consider that if you say no, that this senior stakeholder could divert resources currently allocated to your initiative to address this other issue.

Are there benefits and/or efficiencies to be achieved by taking on this work? This can be especially true if you are talking to the same stakeholders.

My advice is to look for solutions that help everyone. This is not about you or them winning. This is about doing the right thing for your organization. Find out why he/she is concerned about these other topics. Is it because they are not being done, or is it that they are being done but are not visible or are being done but not well enough or quickly enough?

Now obviously I’m biased, but I truly believe that well implemented data governance can be the framework against which you align an awful lot of other activities in your organization (well at least those concerning data)! Once in place, you can use your data governance framework to coordinate, oversee, and escalate other data matters to the appropriate people. That said, it is not the answer to everything and you should resist taking on everything (unless of course you are Superman/Superwoman), or at least agree to timescales for adding additional scope once the implementation of your data governance framework has reached a certain stage.

If you do take on something that perhaps you feel is not in the area of your expertise, that is ok – just be honest and clear on the matter. Explain that whilst, for example, you may not be a data retention expert, you see how including that in your data governance initiative has benefits for the organization. Confirm that you are happy to do the necessary research and support the work if you are given the necessary expert support (for example from your Legal Department).

Remember that whether your data governance initiative is small and focused or has gained additional scope, stakeholder engagement is absolutely vital for success. You need to spend a lot of effort engaging your stakeholders. If you could lose their support by not addressing their other concerns, it’s got to be worth considering whether the additional work is something that you can take on.

Finally, if you want ideas on how to go about engaging your stakeholders, you can download my top tips on stakeholder engagement for free if you click here.

Originally posted on TDAN.com