 Hello and welcome. My name is Shannon Kemp and I'm the Executive Editor of Data Diversity. We'd like to thank you for joining the current installment of the Monthly Data Diversity Webinar Series, Real World Data Governance with Bob Seiner. Today, Bob will be discussing how to implement data governance best practice. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the upper right for that feature. For questions, we'll be collecting them by the Q&A in the bottom right corner of your screen. Or if you'd like to tweet, we encourage you to share how it's a question by Twitter using hashtag RWDG, Real World Data Governance. As always, we will be sending a follow-up email within two business days, containing links to the slides, the reporting of the session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Bob Seiner. Bob is the President and Principal of KIK Consulting and Educational Services and the Publisher of the Data Administration Newsletter, TDAN.com. Bob has a recipient of the Damon Professional Award for significant and demonstrable contributions to the data management industry. Bob specializes in non-invasive data governance, data stewardship, and metadata management solutions. And with that, I will give the floor to Bob to get today's webinar started. Hello and welcome. Live from EDW. That's right. Live from EDW. So for those of you that don't know what EDW is, it's Enterprise Data World. It's one of Dataversity's biggest events and it's taking place right now in San Diego. So I'm happy to be here, happy to be amongst all the fantastic data people, not all fantastic data people, but a lot of the fantastic data people and people that show interest in the webinars and the conferences and those types of things. So thank you very much for taking time out of your busy schedule to attend the session today. As Shannon said, today what we're going to do is we're going to talk about how to implement data governance best practice. And a lot of organizations as they're getting started or even if they've already been working in their data governance program or working with their data governance program for some time, it becomes an option at some point to take a look at what you're presently doing and compare it to what it is that you've said that you want to do and how you want to go about it to kind of assess where you stand against something like a best practice. So what I'm going to do is I'm going to share with you not only how to determine what is data governance best practice, also things from my experiences to things that I've found to be data governance best practice, but then also how you might want to use these best practices to compare where you are in comparison to the best practices so that you can develop an actionable plan for you and for your organization. So again, thank you very much for attending today. As I always do, right before I get started here with the content of the webinar, I want to share with you the next two upcoming, up and coming webinars on the Real World Data Governance webinar series. So it may, I'll be speaking about a data governance framework for smart data with a special guest, Tony Serres. And in June, I'm going to be talking about doing yourself and purchased data governance tools. So organizations know that once they're getting started with their programs that there are many tools on the market that can help them to enable their programs to be successful. But there's also a lot of tools that you can create yourself. And we're going to share a couple of those templates. Actually, I'll share a couple of those templates today, but we'll go into more detail on those in that webinar that I just spoke about. A couple of other items real quick. Just to remind you, the book that I wrote on non-invasive data governance was published back in September of 2014. And it's available through Techniques Publishing or Amazon. So please take a look at it. If you don't know what non-invasive data governance is, it's certainly an alternative approach to putting a data governance program in place. It's less about command and control and more about trying to formalize some of those things that are already taking place in your environment. Also want to direct you to the KIK Consulting website. It is the home for non-invasive data governance. And then also share with you that I will be speaking at another Dataversity event that's coming up in June, the end of June, the beginning of July. It's the Data Governance and Information Quality Conference, often known as the DGIQ conference. So I hope to see you there. Last item as we start into the agenda for today is just to remind you about the Data Administration newsletter, an online publication that I've been publishing since 1997. Most recently I struck up a great relationship with Dataversity and the website has a brand new look, lots of free content. It's a monthly publication, lots of information. So please go out and take a look at that. So without further ado, I want to talk about data governance best practice today. This is the abstract that I used to describe the session. And most organizations know that data governance best practices typically defined as a basis and a guideline for identifying what the most important and perhaps the most influential pieces of your data governance program might be. So it's a basis and guidelines for suggesting to the organization what data governance activities you should undertake. Organizations often start with these best practices and do that assessment that I mentioned a minute ago. It's often a good idea to define certain behaviors around data governance and then do a comparison as to where you stand in comparison to those best practices. Oftentimes organizations will articulate those things that they're doing well that support the best practices, but then also identify those things that we call opportunities to improve in the area of data governance. Oftentimes that assessment against the best practices is something that is used to define and develop a roadmap or an action plan for a data governance program. So if you've worked on data governance best practices for your organization, I'd love to hear from you about that. If you have questions about the ones that I'm going to share with you today, I'd love to hear that as well. So the specific items that we're going to talk about today are two specific criteria that I typically use to identify whether or not something should be best practice for an organization. We're going to talk about how to assess against those best practices and I'm going to share with you from several different industries some of the best practices that they have defined for their organization as they have been getting started with their program. I'm going to talk to you a little bit about how to communicate those data governance best practice in a non-threatening way. Again, trying to stay as non-invasive as possible when implementing our governance program. And last but not least, I'm going to talk about how we can take this data governance best practice and invoke it through daily operations, how we can build this into what we do day-to-day as an organization. So oftentimes organizations that are trying to implement data governance want to take those steps that are necessary to determine the appropriate roadmap and action plan for putting a data governance program into place. So as I do pretty often with these webinars, I want to share a couple definitions with you first. And I have found from my experience that it really makes sense for organizations as a best practice to define data governance in terms that will be understood by people in the organization. So if you have different people that are working on different aspects of data governance and they have different definitions or they cannot articulate very clearly what their definition of data governance is, that's a problem. That can be problematic where people will become confused and not really understand what it is that data governance is trying to accomplish in your organization. So the definition that I use that I'm sharing with you on the screen right now is that data governance is the execution and enforcement of authority over the management of data and data-related resources or data-related assets. So even though I use those strong words like execute and enforce authority, that really is what we're trying to set out to accomplish when we're putting data governance programs into place. If we want to put governance in place around protecting data, then we sure as heck need to execute and enforce authority around protecting that data. If we are trying to improve the understanding of the data across the organization or improve the quality of the data and the information across the organization, at some point in time difficult decisions are going to need to be made. So even though I talk about trying to implement governance in as non-invasive a way as possible, I say that we need to word our definition of data governance very strongly. So I use execute and enforce authority rather than a more soft definition of what data governance is. This definition certainly allows people the opportunity to sit forward in their chairs and to ask great questions about, well, if we're really going to execute it in enforce authority, how are we going to go about doing it? Or they may push back and say that's worded too strongly. Again, my suggestion as best practice is that you define data governance in terms that are shared with people so we're all working from the same definition and then we put some teeth behind that. Because truly at the end of the day to govern data, to govern anything, we really need to execute and enforce authority over that thing. So it's not really a best practice itself, but I guess the best practice would be that it makes sense to have a definition that is accepted within your organization, whether it's the one that I shared with you or one that you've already come up with. You want to be consistent in the way that you're defining and talking about data governance in your organization. So when I talk about executing and enforcing authority, the way that we're going to do that in our organization is through data stewardship. So identifying the people and recognizing the people in the organization that have a relationship to the data that they need to be held formally accountable for. So I've done webinars in the past in the series that you can go back and you can find on Dataversity in the on-demand webinar series. I did a webinar called Everybody is a Data Steward, Get Over It. Now the fact is that if you have a relationship to the data, and again, depending on the approach that you take to put data governance in place in your organization, you're going to identify people who already have relationships with the data and you're going to formalize that relationship. One of my clients years ago said, why don't we use the term recognize? We'll recognize people as data stewards. And that is a positive connotation that comes along with it. So certainly we want to have, it's a best practice to have a definition of data governance. It also makes sense to have a definition of data stewardship. And it's very important, those words that are highlighted in blue, the formalization of accountability, because it's easier to implement it when you take a look at the relationship people already have with data and help them to understand how they can do that better, the impact that they have on the rest of the organization, and help to formalize that accountability by providing to them tools and templates and processes that will help them to govern the data as an asset of the organization. So again, we're talking about executing and enforcing authority, but we're talking about formalizing accountability as our ways to that end of executing and enforcing authority. So the definition of non-invasive data governance real quickly here is it's really that practice of formalizing accountability and behavior, recognizing non-invasive roles and responsibilities, applying governance to discipline, as a discipline to existing processes, rather than redefining all of our processes as being something new. We want to apply governance to it. We want to assure that the definition of production and usage of data does the things that we are trying to accomplish by putting a governance program in place. Non-invasive really describes how we're applying governance to our organization. So I wouldn't necessarily say that command and control or non-invasive is a best practice in itself. But we want to make sure that we define data governance in terms that people understand and we take an approach, take a best practice approach that fits the culture of our organization. So we can be all about command and control and assigning people into new roles, or what we can do is we can identify and recognize them and take that type of an approach to it. And oftentimes I find that to be something that's very acceptable by a lot of organizations. There's a couple of best practices that I want to share before I go into those two criteria to determine what is best practice. And there's best practices around the messages that we as data practitioners are going to communicate to people that are at the senior levels of our organization. So the management level of our organization, I suggest that these messages would become part of your best practice approach. And one of the things that you might want to share with them is that you as an organization are already governing data. To a certain extent, you probably have information security programs and protection programs and maybe data quality programs and those types of things. And you have people that have accountability for the data. So you're already governing data to a degree, but you're oftentimes doing it informally, inefficiently and effectively. So if we change our messages and we don't go into them and tell them that data governance is something that's brand new, and the tax that we might want to take is that we're already governing data. But we're doing it very informally and we can formalize how we govern data around and that would be basically the emphasis of our approach. We can improve the things that have identified on the screen in front of you. One of the things that organizations think is that these or senior leadership for organizations think is that we spend a lot of money on data governance. The fact is, we really don't. Oftentimes to put governance into place, what we're really doing, it's costing us the time that we're putting into it rather than initially right out of the gate going out and buying an expensive repository tool or a governance tool. Those are going to enable your program at some point in time, but we don't have to spend a lot of money when we're getting started with our data governance program. In fact, it really only costs the time that we spend and we need to formalize who those people are in the organization that are the stewards of the data. So that's another subject matter for another day, but we want to be very careful in what we say to our management about data governance. We need to tell them we're already governing data. We can become more formal. We can improve. We don't want to spend a lot of money. These are things that senior leadership oftentimes want to hear rather than it's going to be a complex, it's going to be a huge problem. So while we're telling our management those things, here's some kind of best practices, messages that we can share that we should not share with our management. If we sell it to them as being a huge challenge, that's what they're going to understand. We're already trying to sell them on all the good things that data governance will do for our organizations, and we're hoping that they buy into that and that they understand that these things are absolutely necessary to get started. So if we tell them it's a huge challenge and it's going to be complex, that's what they're going to believe. So my suggestion is, don't sell it as being a huge challenge. Sell it as being something that we're already doing that we can kind of build into some of the things that we already do as an organization. Emphasize that data governance is not a technical solution, that we're really not governing the data itself, we're governing people's behaviors associated with that data, and also emphasize that we're not going to get there through revolution. It's really going to be an evolution, at least from my experience in most organizations. They do it incrementally. They start with either a slice of the pie and the pie being the entire organization, where they start with a slice of a slice of the pie, something that's very small, and they prove their value, and then they incrementally expand that across the organization. So again, these are best practice statements that we can use when we're sharing with our senior leadership and trying to convince them that data governance is the right thing to do. The definition, I oftentimes share the definition of what it means to govern something. And if you go to the dictionary, you go to freedictionary.com, this is what it means. It means to make and administer public policy, to exercise a civil authority, to control, to regulate, to control, to keep, to exercise all of those types of things. So it's really not a stretch to say that data governance is about the execution and enforcement of authority over the management of data. We just, again, want to make certain that we have a definition that we can use and we can repeat through the organization. So I want to talk to you about those criteria to determine whether or not something is best practice. And typically, you know, I mentioned this earlier, organizations define best practice as a way of getting started, as a guideline for behavior. They're looking to articulate where they are in comparison to best practices before they go ahead and put that roadmap or that actionable work plan even to update an existing program. We want to make sure that we're aiming for some specific targets. And the two criteria that I use are, and you need to really be able to answer yes to both of these questions in order for something to be considered best practice, is the statement of practice practical, doable, and will it add value to the organization? If it's not practical and it's not doable, given the culture, given the environment that you're working in, and it's not going to add value as a best practice, my suggestion is don't define it as a best practice. So you want to be able to answer yes to that question and as we go through the best practices I'm going to share with you in the next couple of minutes, we want to take a look at these from that perspective. Is it practical, is it doable, and will it add value to our organization? The second criteria that I use is that the program is the program going to be at risk. Is the data governance program, the effort to govern data across the organization, going to be at risk if the practice is not achieved? And again, I believe that the answer to that should be yes as well. So we're picking things that are important to the organization, important in terms of data governance, and we're going to be at risk if we don't achieve these things, and we want to be practical and doable in what we define as being data governance best practice. So here's a slide that I just created, especially for this webinar. There's actually best practice around creating a best practice document for your organization. So let me spend a few minutes in regards to that, and then we'll jump into those examples of best practice that came from different organizations. So the first thing is that oftentimes the data governance best practice document is in the assessment, the critical analysis, the things that lead to the recommendation as to the steps that you're going to take for your program is the very first document that's created as you're getting started with data governance. You know, it oftentimes the best practices that we define are the basis of the assessment. When we define best practice, and we share that with people in the organization, it makes sense as an opportunity to underline specific words in those best practices as words that require additional definition, and you'll see what I mean in a minute, where key words, like when we talk about senior leadership, who exactly is senior leadership? You know, when we're talking about requires ongoing resources, what do we mean by that? So one of the things that you might want to do and something that I see as being a best practice around creating a best practice document is to underline the words that you're going to define somewhere else. I used to always define my best practices in future tense. Saying, we will do this, we will do that. I actually was enlightened by a client several years ago and said you don't really want to say it as something that's future tense, you want to say it in the present tense. Okay, we are doing this. Then what we can do is we can compare ourselves to what we are doing, to what we say we are doing, and use that again as the basis of the assessment. Typically in an organization, they don't have a laundry list of best practice. They typically pick somewhere between four and six as what I've seen for organizations that I've worked with, and they analyze them from both a business and a technical perspective. You know, you want to be somewhat succinct when you define your best practice. If you're going to be verbose and you're going to have a lot of words, and again, you'll see that in the examples I'm going to share with you starting the next slide, that it becomes more difficult to understand. It requires more description of what the best practice is. So my suggestion is you want to be pretty succinct. You want to be to the point when you're defining best practice around data governance. So here are the next couple of slides here, that I'm going to share with you examples of best practices from different organizations, from different types of organizations. So the first one we're taking a look at here is best practice from an insurance company. And you'll notice that there's some consistency in the best practices that are defined from organization to organization from industry to industry. The very first best practice that I find that organizations use, and I'd be lying to you if I said that it was 99% of my clients that used this as a best practice. It's very much closer to 100%. The first one is that there is a high level of senior management support, sponsorship, and understanding of the activities of the program and the team. So okay, is that practical and doable? Can we get our senior leadership to support, sponsor, and actually the most important word there is understand the activities of data governance. Understand what it is we're trying to accomplish. It's very easy for somebody to support and to throw money at something, but to get them to truly understand what it is that the data governance team is doing and the actions that they're taking and the results that are coming from that is a best practice. If your senior leadership supports sponsors and understands you and they can see, well, if they don't understand you, you want to make sure that that's an action that you're taking as you develop your data governance program. So if we're saying that we know that we're going to need a high level of senior management support, sponsorship, and understanding, that in itself is an excellent best practice and one that we could do an honest assessment against and make certain that at least if they're not understanding as much as they're supporting and sponsoring that we built into our program, steps that we're going to take to help to improve their understanding of what data governance does for the organization. So like I said before, I'd be lying if I said that that was that it wasn't practically a hundred percent of the organizations that use that as a best practice. The second best, and that's very short and very to the point, it's written in present tense and all of those types of things and it's got the words that are underlined that the next page in the document might say, okay, when we're talking about senior management this is who we're talking about. When we're talking about supporting, sponsoring, okay, this is what we're talking about. So again, it passes the criteria to determine what would be best practice. The second best practice would be from an insurance company would be a team of cross-departmental resources as well as a dedicated program manager are accountable for building the program, basically the definition, development, implementation, sustainability of the program on an ongoing basis. And so in this best practice it goes on to say this group will be known as the planning team during the initial phases and then it'll become the program team as we get further into our implementation of data governance. So is it practical and doable that somebody in your organization, basically what this is saying is somebody in your organization has to have responsibility for data governance to be successful. Is it practical and doable that you can do that? Sure. Are you going to be at risk if at some point, just like if your senior management doesn't support sponsor and understand you, you're going to be at risk or if we don't have somebody who's responsible for moving the program forward, are we going to be at risk? Well, you're darned tootin' so I think you can answer yes to both of those questions in regards to that second best practice. We need to define that. It doesn't need to say a team of cross-departmental resources, but it may just be something as simple as somebody has to have the responsibility for this on an ongoing basis. And if we don't have that, we know we're going to be at risk at some point in time. There are activities around data governance that need to take place in order for your program to be successful. So senior management supports sponsorship understanding. Somebody has to have responsibility for it. The next two are pretty easily stated. The measurements of success and how we're going to go about measuring them of the program are going to be well-defined and communicated with senior management and the stakeholders. Is it practical and doable that we can do this? Are we going to be at risk if we don't define how we're going to measure the success of our program? So that follows the same two criteria as well. And that is used by a lot of organizations. It's not always the best practice, but it's one that I've found to pop up in the insurance industry more often than not. And the last one on the page here is that the goals, objectives, scope, roles, responsibilities, rules of engagement, all of those things are well-defined and communicated. So just like the previous best practice, is it practical that we can define and put these things together and share them with people? Well, certainly it is in most organizations. Are we going to be at risk if we haven't defined what the goals, scope, objectives, roles and responsibilities are? Again, I would say that in most organizations, their program is going to be at risk if they haven't defined those items as part of the beginnings of their data governance program. So I'm not going to go through in as much detail the best practice from these other types of organizations, but you'll see that there's a lot of consistency from one set to the next. So in this one, these are best practice from a governance, a government agency. Senior management supports sponsors and understands at a high level the activities for protecting data. Well, for that organization, that government organization was the Department of Health and Welfare. Their sole purpose of at least the initial phases of their governance program were to protect data. And so they said that senior management needs a support sponsor and understand what it is that we're doing to protect the data. Is it practical doable? Yes. Are we going to be at risk if they don't? Yes. So again, it's consistent with the previous page that I showed you. Data governance, protecting data is applied consistently across the organization. Resources are allocated to define, develop and sustain data governance. That's like the second best practice from the previous slide. Policies and procedures are done and internal and external stakeholders are informed of the goal scope. Again, very consistent from type of organization to type of organization as to what they define as being data governance best practice. From an education company, again, very similar, for governance to be successful, there will need to be a high level of senior management support sponsorship and understanding. So this is written in future tense rather than present tense. Again, it's up to you the model that you take for defining data governance best practice. Select staff will be committed to the program. Data governance principles will be applied consistently. You're seeing that these data governance best practice that I define are pretty much consistent from industry to industry. So to summarize them real quickly, here's an example of things that I hold in very high regard in the way that when it comes down to defining best practice for your organization. Senior management support sponsorship and understanding, that we talked about several times. Resources must be applied. Roles and responsibilities clearly defined. Goal scope, we must be consistent across the organization. So in a nutshell, from my experience, what I have found is that these are five good best practices to start around. And how you word them for your organization is really up to you, but we want to make sure the support we need, that somebody has responsibility for doing it. We've documented those things that are going to be important to our program. So that's what I see very often coming out of a set of data governance best practices for an organization. So when you define the best practices and you do that critical analysis and again the end result of that oftentimes is to create a series of actionable plans, have actionable steps, or at least recommendations as to the steps that you should take. Oftentimes as a result of that assessment, the recommendations that come from it are all right, we need to define, recognize, and deploy an operating model of roles and responsibilities. We need to create a communication plan. We need to have people that are responsible for the program. So we need to develop our governance team. We need to incrementally roll this out to the business. We need to deliver our governance documentation platform. Whatever the metadata is that you find is most important to your organization. So you can take from that quick hit best practice critical analysis and define the primary recommendations for the development of your program and then build the action plan to follow those recommendations. So it's very important to start at the very beginning, begin with the end in mind as Stephen Covey would say, define best practice as you're getting started and putting your governance program together. All right, so let's talk about data governance best practice when it comes to trying to get the business people to tell us what the heck they need data governance for. Because it's always better for the business people to speak up and the technical people to speak up about what data governance will do for them rather than us trying to sell data governance, sell, sell, sell, and convince people that this is the best thing since sliced bread. So the first thing that I suggest, the first question that I use oftentimes when I'm talking to business people is what can't you do that you want to do because you don't have the data to support your ability to do that? And so when you ask that question and depending on how you ask that question, oftentimes what I've found is you get response from people at the things that they can't do. So let's break that question into three pieces. What can't you do? Well, jeez, I can't compare the price of raw materials across regions or I can't tell, you know, what our employees need to be refreshed on how to protect or when to protect data in the organization. What can't you do as a business goal for your organization? Boy, people tend to open up about that when they understand that what you're doing for them, you're really trying to assist them and help them to do the things that they feel they need to do. So what can't you do that kind of opens a can of worms but that you want to do? So that's the second part of the question is what do you want to do? What are the innovative things that you want to do as an organization or in your function that will assist the organization? That will assist your position within the organization? So what can't you do that you want to do because you don't have the data to support it? You don't have the data to do it? Then they start to open up, well, you know, I've got this data but it takes me hours to compile it to create the reports that I'm sending to my clients and things like that. If you can ask this question, it becomes really a best practice question to ask the business people to get them to speak up about what they can't do and what they need to do with data governance in their organization. A couple other questions that are pretty typical questions and I'm not going to get through them in a lot of detail either but what data and metadata do you use most often? What's your primary source or system that you use to contain your data or your metadata? What processes do you use and how does the data work in those processes? Those are all great questions and I think we need to know the answers to all those questions. But it doesn't open it up for conversation the way it does when you ask the question what is it that you want to do that you can't do because you don't have the data to support it. So these are typical questions that organizations use when trying to define business requirements around data governance. And here's a couple more to share with you. Is there an associated risk? What's the operational impact? What other impacts should be noted? Those types of things, they're all very important questions to ask but it still comes down to what are we going to do for you to help you to be successful in your function in the organization. Now we talk about building roles and responsibilities and I can spend easily an hour talking about this slide in itself and talking about setting up roles and responsibilities in the organization. And if you go and you check back, you can see that in a lot of the webinars that I've done, I've used this model quite a bit. But you know that you need people at the operational level. You've got people that day-to-day are defining, producing, using data. You know you're going to need a council, the people that are the decision-makers around your program. We know that we've got the executives. We know that we need to communicate to our senior leadership about supporting, sponsoring, and understanding of the program. So we know we need to communicate the best practice to all of those groups. The most difficult group to fill in this whole diagram is that middle layer, the tactical layer. When we stop looking at data as an individual siloed asset, we start looking at it across business units. So the reason why I'm defining these roles and responsibilities for you here is that we need to communicate to these different layers of this operating model and we can't necessarily always communicate in exactly the same way depending on who it is that we're communicating with. So when it comes to governing your data, oftentimes in communicating about the governance of your data, it is really best practice to know the things that are listed on the screen in front of you. What data is there? What data there is in the organization? Who defines, produces, and uses that data? Who has the decision-making authority over the subject areas of the data? And what systems does that data reside in? At some point, you're going to want to know all of this information. Who in the business has responsibility? Who in IT has responsibility? I try to shy away from the word owns, but who owns the data and where does the data flow? And if you've attended my webinars in the past, you know that I use this tool, the Common Data Matrix, which in this picture right here is very small and difficult to read. So I'm going to share with you the bigger versions here in a second, but we need to know by subject area in the different parts of the organization who's defining, producing, and using that data. So we know that we need to have people that are here kind of outside all of the business areas that have the responsibility for making decisions. That's that tactic group that I spoke about earlier. Those are the people that are starting to view data and govern data as an asset to the organization across business units. So again, the reason why I'm showing this and there's a couple other versions of this, if you want to see a closer up version to the left of the diagram, we're basically taking the subject matters of data and we're breaking those down. And you can be as granular as you want and you can break it down to a data element level or keep it at a subject or a sub-subject level. But identifying who in the organization is responsible for making decisions associated with that subject area of data is very difficult to do. But it's also very necessary to do if we are going to start managing data as an asset across the organization, rather than siloed efforts across the organization. The next set of columns to the right here is that's just an example of a data governance partner. So it's really an IT example. But for each of these different subject areas of data, what systems does that data reside in and who in IT are the system subject matter experts and the data subject matter experts? That's important information that we want to know and we want to record somewhere. Well, at the same time, the next slide here, we also want to know who in the business areas are using that particular type of data in that specific system. And the reason why these sets of business columns that one of them has a gray area, and it is that there's organizations that parts of the organization have a shadow IT or a stealth IT part of the organization that's associated directly to just that business part of the organization. So at some point, it's best practice to know who does what with data across the organization. And this common data matrix tool becomes a very easy tool to use when you're defining and you're identifying and recognizing the people in the organization who are the stewards of data across the organization and what their responsibilities are. Now, one of the things that's really cool about these two diagrams together is that they're kind of color coordinated. So where you've got the operational people in the model, you've got the operational people in your common data matrix. Where you've got the tactical people who are looking at data, you know, not just for their specific business area, but looking at it across the organization, that's these people on the common data matrix. So looking at the executive team or the Data Governance Council, those are these people that are kind of at the top of each of the parts of the organization. So at some point, it becomes best practice for us to document and record who does what with data across the organization. Because at some point in time, you're going to want to know that information. You're going to want to share the protection rules. You're going to want to share the quality rules. You're going to want to share rules around updating metadata or updating databases. You're going to want to know that information. And a lot of organizations are kind of working on the fly with that knowledge. The common data matrix as a tool is something that you can develop yourself and that you can create and use in whatever ways that you need to, but it really helps you to put your arms around who does what with the data in the organization. So we may be going to these people and trying to identify who the key business users are when we ask them where do we compare to these best practices that we just defined. So what is your feeling, and you're talking to a business person in that finance area of your organization as an example, and ask them, well, what does your senior leadership know about data governance? Do they support you in your activities? Do they understand what it is we're doing? So by defining the different roles and responsibilities, it helps us to pinpoint those people in the organization that we want to talk to to even begin to assess against the best practice that we defined earlier in the presentation. So we're going to communicate the best practice with the different roles. Obviously, it becomes a best practice that there's somebody in the data governance team that is somewhat knowledgeable or has the skill or has the time to be able to create, or they're accountable, basically, for the communication. They have time to create the communication. They have time to share the communication, they answer questions. It can be the data governance team leader. It can be somebody who's a partner of yours in your organization, somebody from a communications area that helps you to put the best possible communication package together associated with your program. And oftentimes, when we're developing data governance best practice communications plans, there's going to be three aspects to it. There's going to be an orientation aspect. There's going to be an onboarding and an ongoing communication aspect. And I've shared this diagram before in presentations as well. Basically, it's a communication plan matrix where you have the things that you want to communicate. And oftentimes, one of the things that you want to communicate might be the best practices associated with your governance program or the roles and responsibilities, role-based activities or the documentation. And we know that we cannot necessarily communicate information in the same ways to the different levels of the common data of the operating model that I just shared with you. Again, so this diagram is color coordinated with the prior two, if that's meaningful to you, but then when you're sharing these documents with people and they recognize themselves as being in a certain place in the operating model, they can also see themselves in the common data matrix. And so again, it becomes best practice around communicating data governance best practice to your organization. So in the last couple of minutes that I have, I want to talk about applying data governance best practice through daily operation. There's really two ways that organizations apply data governance in their organization. One is proactively and one is reactively. So by doing it proactively, we're going to build it into what we do. So if we've got a system development or cycle methodology, or we've got a way to solve problems, we're going to build it into those steps. We're going to apply governance to process rather than redo the process based on data governance. The last thing that we want to do, and I've mentioned this in prior webinars, one of my pet peeves is that organizations call things data governance processes. Well really, they're processes that are being governed. They're not governance processes per se. They want people to point at data governance all the time, say that's why we're doing this, but okay, call them data governance processes. But most organizations don't want to do that. They want to stay under the radar. They want to stay somewhat stealth. So my suggestion is we're applying governance to process rather than redefining and redoing all of the processes that we plan to govern in our organization. And by no means, don't call it a data governance process. It's a process that we're applying governance to. And just to share with you a couple examples of those before we wrap it up and take some questions here. Many organizations start proactively by building governance into their system development lifecycle, their application development lifecycle. The steps that you see in front of you are typical steps that organizations take when they are applying governance to their methodology, to their best practice processes that they're following. So they do planning, requirements, analysis. So my suggestion is, and I'm showing you a bunch of matrices so far, I'm going to share with you a couple more. And I know this one is too small to read and the intention isn't really there for you to read it. The idea is to talk about it conceptually. Here's the steps of the process. Here's the roles that you've defined as part of your governance program. And here's what each of the different roles does in each different step of your methodology. So I've seen this actually work for common waterfall methodology. I've seen it work for agile methodologies as well where we take processes that we've defined and we identify the roles that need, the roles from governance perspective, from a data perspective that need to be engaged and we get very specific around what does that specific role do during that specific step of the methodology. Building governance into what we do. Another example of it is this is kind of a project plan that an organization was following. These were different roles associated with the program. They defined how long it was going to take and exactly how much time. So this person was responsible for that activity and they were expected that they were going to spend two days out of that one week on that specific action. So what we're doing, again, is we're applying governance. We're applying data governance to each of the steps of the processes but we're being very specific to the processes that we're applying data governance to. Another example is this one where this organization defined six primary processes that they wanted to follow when it came to data governance and they put it in a spreadsheet and if you clicked on one of the items on the spreadsheet, it would happen was it brought in another panel that said these are the different roles associated with data governance and if you're familiar with RACI or RASCI or anything like that, we can define who's responsible, accountable, consolidated, supportive, informed and we can use RACI to apply governance to practice in our organization. So most of those are proactive steps. There's also the kind of the reactive, the data quality methodology where when you've got a problem, you can resolve the problem but the same thing applies. Those governance activity matrices that I just shared with you can be used to document the steps that we're following to resolve issues within our organization. So basically what you're doing is you're cross-referencing who does what and when but it is a best practice way of applying governance to existing process first rather than giving people the impression that this practice is all of our processes because of data governance or because data governance says that we need to. So again, my suggestion is apply governance to the process rather than defining the processes again for the organization. So my last couple of slides here, the last thing and one of the last things I want to talk about is again the whole concept of the traditional data governance approach versus the non-invasive data governance approach side by side it's very easy to see that in a traditional data governance approach a lot of organizations take a command and control and assign we assign people into roles rather than it really being kind of behavior driven and what relationship people have with data that's formalized that where the accountability is recognized rather than handed to people as being something that's brand new to them. Rather than defining all brand new roles we're going to be applying existing roles. I was working with a client recently back in 2001 the president of that company put forth a memo to everybody in the organization that said we need to protect personally identifiable information, PII data and so it was defined more than 10 years ago close to 15 years ago but we really need to pull the covers off of that and re-communicate that to people. So things that were already in place you've already got information security you've already got ways to solve problems let's apply governance to those rather than redefining them brand new because of data governance. So in a traditional data governance approach the thought is that this is oftentimes going to be over and above the existing work culture of the organization in a non-invasive approach we want everybody to understand that governance is a part of your job if you have a relationship to the data whether it's as a definer or as a producer or as a user you have a level of accountability formal accountability for how you define data rather than defining a tenth version or a hundredth version of a customer database somebody who's defining data should point to data that's already being used that would best suit their purpose you know if you're producing data people who are producing data need to understand the impact when they produce data it has an impact on the organization I've shared in the past that people who are checkout counter checkout clerks in big box stores ask for your zip code before you leave the store or as you're checking out because they want to know where their customers are coming from but I found stores where people stay in there and enter into the zip code in the store they don't understand how that data is going to be used so therefore they're taking the easiest approach to producing the data and certainly it's a no brainer when it comes to people using the data we need to make sure that people that use the data understand the rules associated with how that data can be used can't be used where the definition of is where the system of record is all those types of things so what we want to do is get people to understand that it's really not over and above it really becomes part of their job and you've won the game data governance of the game you've won the game you've won the point where it's kind of second nature to people when it's built into what they do so in this webinar what we covered was those criteria for data governance best practice we talked about how to assess against the best practice to kind of build an actionable plan or at least recommendations I shared with you some examples of industry best practice I hope those were helpful to you I've never really found two organizations that use exactly the same best practice but those five that I summarized for you they're a very good starting point when it comes to defining best practice around data governance in your organization we talked about communicating data governance best practice at different levels of the organization and how to build the data governance best practice into your daily operations using the governance activity matrices that I shared with you just a real quick reminder next month on May 19 the webinar will be the real world data governance webinar will be about governance framework for smart data with my friend Tony Serres and with that I would like to turn it over to Shannon to see if we have any questions thank you Bob we have a lot of great questions coming in already a question with popular questions are people asking about the slides just a reminder I will send a follow-up email within two business days to this webinar with links to the slides, the recording and I will send out a copy of the matrices from Bob as well just to dive right in Bob have you ever had to get HR involved with defining the new roles and responsibilities if not do you think that HR should be involved with these new definitions well to be honest with you now I don't necessarily believe that the HR should be involved in defining the roles that people do and what they do they may help you to identify or if it's necessary write the responsibilities of the stewarding or the governance responsibilities into people's job descriptions certainly you're going to want to get HR involved in that but if you take a non invasive approach what we're really doing is formalizing the things that people already do as part of their everyday job so don't need them at least from my experience I don't recall ever getting them involved in the defining of the roles for the governance but if it requires that it changes job descriptions or that evaluations are based on it then yes I see that you may want to get your HR area involved in that and then several slides back you were talking about not need a lot of money but time time is the money that we pay for so it still costs money it's the comment so that's very true but and I can share with you wow as an example that there's been people in organizations that have been given the role to be data governance manager but they're not necessarily given the direction or given the funding to be able to go out and hire a consultant or buy a book or attend a great conference like enterprise data world I mean so time is money time without a doubt is money but oftentimes organizations define the people that are going to have the responsibility for doing this and it really requires one person or part of one person's time to define the things that are going to be necessary for governance to take place certainly they want to talk to other people in the organization as they're defining the requirements for data governance but oftentimes there's somebody that's been given the charge to do this that hasn't been given or the responsibility to be able to do it and that's what I'm really talking about is if you've got people that have time to do it taking advantage of that that doesn't cost anything additional you don't need to budget for that because it's part of somebody's job rather than going out and buying one of these great tools that are on the market and expecting that by implementing the tool that therefore you're going to have a data governance program so time is money because there's somebody who has the responsibility for doing it it was the second best practice but I shared with you the support sponsorship and understanding from the senior leadership was one second one is somebody has to have the time to do this and that could be one person it could be I worked with one university where it was one eighth of one person's job and they told me that it would be slow but it was still part of their time that they had time associated with doing this time is money but it's not something that you're necessarily going to budget for sure in the presentation data governance is presented as a program isn't this really a new function a program has a specific start and some say an end what function exists and needs to be funded have some resources assigned and have objects and goals Shannon I hate to have you do this because you were kind of fading it out as you were talking in the presentation data governance is presented as a program and so it's really a new function a program has a specific start and some say an end where function exists and needs to be funded have resources assigned and have objects and goals well and the way I look at it typically is that it is either a project or it is a program and as a project I agree it has a beginning, a middle and an end a function doesn't necessarily have a beginning and a middle and an end but it is it's not necessarily new to your organization so if you're a bank or you're an insurance company or you're any type of company that uses personally identifiable that PII data that I mentioned before then it's not an option for your organization not to protect that data so there's some of that going on they're teaching people maybe it's during orientation but maybe people still have the ability to be able to print things that have social security numbers and have them sit on the printer for a half an hour so anybody can walk by and pick it up that's not protecting the data so yes it's a new function formally as data governance but it's not necessarily a new function for the things that you're trying to do if you're building a data warehouse as an example you want to make sure that the data in the data warehouse is very well defined and that you're not using what I've referred to in the past as cheeseburger definitions for your data so it's a function of what you're presently doing it's not necessarily and I would suggest that when you sell it to your organization you don't sell it as being a new function you sell it as being a formalizing accountability and that comes back to the best practice of what do we tell our management and what don't we tell our management if we tell them it's a new function and it has to be and we've got to support it and fund it and source it and all those types of things then that's exactly what they're going to believe and that's what they're going to expect and it's going to be expensive and complex but if we say you know what I already have time associated with doing this and I'm putting a program together around formalizing people's accountability it does not have to feel like a new function so a long answer to a shorter question but it doesn't have to be that way and there's still there's so many great questions coming in one of the great things about these webinars with Bob is he will write up answers to any questions that we don't have time to get to so keep them coming in although we have just a couple minutes left and maybe just enough time for this last question can you give some examples of how to measure success that's a great question in fact we should probably do a webinar on that at some point it's about metrics and measurements so oftentimes I look at measuring success two ways through the business value and through the technical through the well through the business value and through the ability to be able to show that we have it's feasible for our organization and there's short term and there's long term ways to define success in metrics now oftentimes you can measure how many people in your organization you've identified as stewards or recognized as stewards how many of them you've communicated with oriented or brought on board for the program so you can measure those types of accessibility how many times people have access to the common data matrix that I shared with you so those are very easily measured in order to be able to say that we've saved X number of dollars or that we've prevented this from happening that takes a little bit longer time so what I've seen organizations do is measure the return to mail how much money did we spend on return to mail in the last year and how much of that is because it's a data address issue problem so what I've found in a lot of organizations is that they either define those really kind of quick hit measures of how well data governance has been accepted into the organization and others that have used to say well we've saved the organization X number of dollars but that's really hard it's kind of a gray area that people sometimes have a difficult time making that leap is saying that we've become more successful we've become more profitable because we've put data governance into place so there's business value metrics and there's acceptability metrics that's where I would start like I said I keep the questions coming in I'll leave it open for a couple of minutes more so you can keep both coming in and Bob will get the written answers to you and just a reminder I will be sending a follow-up email within two business days with links to the slides, the recording copied to all of the matrices as well as the answers to the questions that have come in thank you everyone for attending today's Webinar and being engaged in everything that we do and thank you Bob for another great presentation and presenting live from Enterprise Data World and we really appreciate it and I believe it's your birthday tomorrow is it not? Oh you must be muted I think we lost you I hope everyone has a great day thank you thank you everybody hope you enjoyed the Webinar and look forward to hearing from you